GHC 6.2.2 on Linux with glibc2.2
I've put a compiled version of ghc6.2.2 for Linux machines still using glibc2.2 on http://www.informatik.uni-bremen.de/~ger/ghc In fact it should work on glibc2.3 as well, thanks to a minor hack from Christian Maeder. Documentation is not complete, but does at least include HTML. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Please could the Concurrency library have a yield action!
"Sigbjorn Finne (Intl Vendor)" wrote: Is it worth adding something like `yield' to the Concurrent API? I'm unconvinced, but don't feel strongly about it. If there are others that also think that it should be supported, let me know, and I'll change my mind :-) Here are two reasons: (1) Pre-emptive scheduling is hard to implement (is Hugs really going to support it and still be as portable as it is now??). Presumably this is why Java is not guaranteed to have it. (2) Even when you have pre-emptive scheduling, yield() could still provide a hint to the scheduler that this might be a good time to do something else.
Re: Dear Santa (Error Messages)
Simon Marlow wrote: [snip] Hmm, you're probably doing a large chunk of renaming too. I just added an error call right after the parser in Main.lhs. The MLj parser/lexer doesn't actually rename, but it does tokenise all identifiers in the lexer. Symbols already known aren't even copied out of the input buffer. This saves time and space (the complete MLj compiler only has about 1 distinct identifier/symbol/reserved word for every 10 lines of code) and also means the rest of the compiler is working with integers rather than strings, even though it doesn't know it, which also speeds things up. I'm still interested in the figures, if you want to retry your experiment. OK, here goes. If I insert the line error "Parsing done" after the line dumpIfSet opt_D_dump_parsed "Parser" (ppr rdr_module) in main/Main.lhs, I get the revised table: GHC MLj wc -l 10146 4856 wc -c 312962212902 [wc -w] 37107 11578 real 11.832 2.835 user 10.740 2.610 sys 0.870 0.150 The [wc -w] is an attempt by me to get a slightly fairer value for the program size by removing all non-pragma comments and using wc -w. For MLj counting words rather than characters makes a big difference since ml-yacc encodes the parser tables as gigantic strings. I tried much harder to get the figures down for both GHC and MLj this time by shutting down everything else on the system I could find, and taking the best of three. (This makes a big difference to the real time, which presumably includes file access, but not the user time, which I think is probably the important figure) However in GHC's defence I should point out that 1) I'm still using gcc 2.7.2. On Sparc-Solaris GHC should certainly go faster when I can get gcc 2.9.5 to work with it. 2) I didn't compile GHC with optimisation. This sounds serious but I don't think it is since I've been told that Happy- generated code is optimised to the bare bone anyway and so can't be improved much by GHC's optimisations. I did try compiling the parser with -O2-for-C (but not -O); however surprisingly that actually seems to make it slightly slower! Re parser combinators. I think I was obviously too rude about these, because of my previous bad experience. Naively it seems to me that there is a trade-off. I am not prepared to settle for anything less than having my grammar statically checked for potential conflicts. This obviously rules out rules generated with complete generality at run time, and so rules out some kinds of parser combinators. I can conceive that you can restrict the use of parser combinators in such a way that a preprocessor can verify the grammar statically, and (by computing follow sets and so on) do as good a job as Yacc, while still allowing you the advantages of abstracting sequences. Fine.
Re: Dear Santa (Error Messages)
Sven Panne wrote: [snip] I guess that even the computer on *your* desktop would be fast enough for the current parser by the time a completely tuned rewrite of Happy would be finished. Moore's Law comes to the rescue here... :-) Well we're going in circles here. So far we've established that Happy is unnecessarily slow. If it doesn't matter that the current version of the Haskell parser is slow, doesn't do any error-recovery, and doesn't preserve much location information, we may as well finish this discussion. I suspect that Simon M owes me a drink though . . . Lennart Augustsson [EMAIL PROTECTED] wrote: Parser combinators are fine if the grammar is very simple or you don't care about CPU times. But using them in a serious compiler for Haskell would be like building a computer out of stone knives and bearskins. So this is your opinion, what kind of evidence have you got for this claim? Parser combinators don't actually seem to analyse the grammar at compile time at all, and instead just try all possibilities. This looks like stone-age technology to me. The first version of MLj was written with parser combinators. As a result the parsing was much much slower, even after various exponential blow-ups had been painfully tracked down and removed. Error correction was hopeless. And worst of all, there were a number of lurking ambiguities in the grammar which weren't discovered until it was exposed to the rigour of LALR parsing.
Re: Dear Santa (Error Messages)
Simon Marlow wrote: Ok. It's going to be hard to get a fair comparison here, but I've just done a rough measurement on GHC: I can't obviously run MLj on Simon Marlow's computer, so I have rerun both tests on this (obviously much slower) Sparc box, with GHC 4.04 and SML/NJ 110.7, using the happy/ML-yacc output in both cases. This still isn't tremendously fair; for one thing yacc output is not exactly typical. Also I must admit that the bit of the MLj compiler I am testing does not include the bit which does fixity analysis, which is arguably part of the parsing. (I think this could have been bundled into the rest of the parser without it slowing things down much.) On the other hand, I should repeat that the MLj parser is doing more since it is include much fuller location information and is also capable of error recovery. Anyway here are my results GHC MLj wc -l 10146 4856 wc -c 312962212902 real 46.654 7.679 user 12.870 2.540 sys 1.170 0.230 Notes: 1) unlike Simon, I didn't try to adjust the heap size to make the MLj parsing go faster. 2) for the Haskell parser, I've counted the number of lines and characters after preprocessing. This is slightly nicer to GHC than if I'd used Simon's figures. 3) Since I suspect a significant part of the compilation time is taken up with loading in the heap image, etc, I think the results would be even more favourable to MLj if I had a program of the same length. [snip] So what we're talking about is just parser recovery? Not even passing the corrected output through the rest of the front end? Then I'm even less convinced. Given that the longest you have to wait for a parse error on any human-written Haskell file is at the most 1 second, what's the point? Yes, that is precisely what I want. I think it is already clear that some of us have rather slower computers! Also we have to fight against NFS much of the time. Actually, I think the best solution is to have a parser that runs in the background while you're editing, so you'll know if the program is at least syntactically correct before even running the compiler. It occurred to me ages ago that ideally there'd be an Emacs mode or something which dynamically lexed, parsed and typechecked code as it was typed in. Actually I can't see any reason why this should be impossible, though it would be more than a PhD project to actually implement it. Why can't you get Microsoft to spend a few millions doing it? It was you who suggested the parser be rewritten. So what's the alternative? Rewrite Happy. Best wishes George Russell
Re: Dear Santa (Error Messages)
Simon Marlow wrote: [snip] Eeek! I've just rewritten it! And I don't plan to do that again for a long time :-) It is really appalling that (a) there is no error-correction. Nonsense. I contend that you really don't want an error-correcting parser. - parsing is quick I'll bet you 1 pint that MLj's parser+lexer are quicker on correct files than GHC's. Deal? - error-correction is by definition unreliable Yes of course. Any intelligent user of a compiler knows that if they have two parsing messages close to each other, the second may well be wrong. But it shouldn't happen too often if the parser is well written. - error-correction is hard to implement well you might think a good policy is "if you find a parse error, just read up to the next semicolon carry on", but layout totally screws this idea. You often can't tell whether the next definition belongs to the current scope or some other scope, and if you get out of step everything goes wrong. See how ml-yacc does it. http://cm.bell-labs.com/cm/cs/what/smlnj/doc/ML-Yacc/ It tries quite hard to find corrections involving the minimum amount of correction of recently-read tokens. It seems to work quite well. The thing is you can afford to work quite hard doing error-correction on incorrect programs, since they don't occur very often. The only disadvantage is that it makes the parser very slow when fed total bilge unless you put in some kind of cut-out. (Thus MLj's parser took forever when fed the last Labour manifesto.) Scoping would be a problem if you tried to do anything more to incorrect programs after you've parsed them. Actually I don't think that's a good idea, so scoping is not a problem. [snip] (b) locations of errors are often several lines away from the actual error. Conceded. There are two causes of this: 1. Bugs, and 2. Not tracking the line number of every single token (we only save the line number at certain places - eg. the start of a definition, a case branch etc.) Please send me any examples of (1). Examples of (2) are harder to fix, because they require changing the abstract syntax. Yes, that's what I think needs to be done. MLj actually has the location (line + character) of the start and end of almost every syntactic construct. This is not really that expensive. I stole SML/NJ's trick of recording the character number in the file (rather than just the line number, or a pair of line and column number); if you put in some extra magic in the lexer to remember when the lines end, you can very easily get a real line and column number back out. (c) the parser is so slow. Disagree. I think it's nice fast. I challenge you to write a faster Haskell parser using a combinator library. Parser combinators are fine if the grammar is very simple or you don't care about CPU times. But using them in a serious compiler for Haskell would be like building a computer out of stone knives and bearskins. Besides, the time taken to parse a module is tiny compared to the rest of the compilation time. It's not when you have a 1000 line program with 30 syntax errors, as you have to run the compiler 30 times. However, GHC's interface file parser is another matter - every compilation needs to read several thousand lines of interface files, which is why you see a second-or-so pause in the reader at the start of every compilation. It's on my ToDo list to look at this sometime. The other suggestion made of having publicly available modules for Haskell syntax seems like a good one, and could be combined with this. There's a freely available haskell parser library - take a look at http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne/haskell_libs/hsparser.html Since it appears to use Happy, it is presumably just as bad if not worse than GHC. Err apologies for the tone, I only criticise GHC so much because it's so useful . . . George Russell
Re: NON-daemonic forking
Michael Weber [EMAIL PROTECTED] wrote [snip] forkChild :: IO () - IO (MVar ()) forkChild p = do mvar - newEmptyMVar forkIO (p putMVar mvar ()) return mvar This does not of course synthesise a non-daemonic forkIO from a daemonic one, because it requires the parent thread to wait for the MVar. I suppose that a possible alternative to having separate daemonic and non-daemonic forking would be to have an atexit-type function: atThreadExit :: IO () - IO() which forkChild could use to wait for the mvar. But I'm not sure I like this, unless there are other likely uses for atThreadExit.
gmake 3.77 and GHC Makefiles
The recent version, 3.77, of gmake seems to be a bit too clever (or maybe too stupid) for GHC's device of not updating a .hi file which is identical to the last one generated. It appears to me as if gmake is saving on a call to fstat by assuming that .hi has been updated even if it hasn't, and so it launches a totally unnecessary series of compilations. Has anyone got any ideas about how to prevent this, short of not using gmake 3.77?
Re: gcc2.95 and GHC
Unhappily, having managed to build hsc from scratch with gcc2.95 on Sparc/Solaris, I can confirm that I still get a segmentation fault when I run it. So it looks like we are stuck with gcc2.7.2. Is there anything that can be done about this?
Mutually Recursive Modules and hi files
OK wise guys, now you've changed (incompatibly) the format of .hi files, how can I rewrite these pre-404 hi-boot files so that they work for 404? Can you summarise the changes?
Re: Speeding up .hi files
Sven Panne wrote: [ cut ] Doing a similar thing for GHC would complicate things for implementors and users. How e.g. would you write your Makefile rules with .hi files in an archive? Yes, it would complicate things for implementors, as they'd have to implement it. However I don't think adding a rule interfaces.a : $(HS_IFACES) $(AR) -c $ $ to the standard GHC makefiles, and altering the targets to include lib/{prelude,std,misc,exts,...}/interfaces.a would be incredibly onerous for the poor implementors. The poor old users would not have to do anything to their Makefiles since the old mechanism would still be available. (Though of course GHC would run considerably faster for them since it wouldn't have to load in everything in the standard libraries.) However as a GHC user already I would be delighted with the new mechanism myself and make use of it to speed up my compilations, by adding similar rules to the one suggested above. It's no more complicated than what I already do to construct libraries, and I would save a lot of time.
Speeding up .hi files
Glasgow Haskell is very slow. I know it needs a lot of CPU time anyway, but when I do ps it is only using 50% of the CPU available, and frequently less. So I think what is happening is that it is spending half of its time waiting for the Network Filing System to open and fstat interface files. I think there is a better way, namely to allow interface files to be stored in archives rather than in directories. There are other solutions. I can store the hi files, or everything, on local disk, but this is tiresome for me, and I shall still spend quite a lot of time reading things off local disk. Or GHC could use either the select function or threading so that it can do other things while waiting for the result of a file operation on an interface file; however I suspect this would be complicated to implement and might not save all that much time. There was a similar situation in my experience with the ML-to-Java compiler; the earlier versions could not read or write ZIP (aka jar) archives, so all classes read in (from the system libraries) and all classes written out (compiled code) were put in their own file. I was persuaded to write a simple Zip file writer in ML and while the bit twiddling was a bit of a chore, it didn't actually take me much more than a day's work to do it, as a result of which the compiler ran about twice as quickly as before. (Later I wrote a simple Zip file reader - which was just as easy - and when the SML/NJ folks get their new foreign function interface sorted out I might do compression/decompression as well, with the help of zlib.)
Multiple values of prefix
We have had confusion here because GHC uses the "prefix" Makefile variable (which gives the final location of the compiled code) at two different times. It uses it in "gmake" to construct the "ghc-4.05" driver script (which hardwires in the location of the installed code), and it uses it in "gmake install" to decide where to actually put the files. As inbetween I've been changing the value of "prefix", this is awkward. I think it would be better if "prefix" were only used by "gmake install". It should be the job of "gmake install" to produce the "ghc-4.05" driver script.
Re: The Haskell compiler of my dreams...
George Russell wrote: [snip] It won't be so hard to speed up GHC later if that becomes important. Since this has been disputed, here are three ways I believe you could speed up GHC without rewriting the whole of it. I would be surprised if you didn't get at least twice the speed, and you could probably get a lot more. The suggestions are in increasing order of difficulty. I don't say that all of them will produce dramatic improvements; you would of course have to experiment. (1) (I've suggested this before.) Make GHC access interface files more efficiently. If you do top and truss (on a Sun system) you will find that GHC has to read in a huge number of interface files, mainly from the prelude but also from other places, to get going. This is all done just using fopen in a single thread so the whole of GHC is grounded while the disk spins and (if you are using NFS like me) you wait for the network. A quick fix would be to use a Zip archive or something similar; there are not many parts of the source to change. Then you would only have to open one file for the whole of the prelude and believe me that would make a difference. (2) Stop using Make, instead steal SML/NJ's clothes and have your own compilation manager. This solves problem (1) nicely and also means you don't have to read in anything else over and over again. (Like hsc itself.) For programs which consist of lots of small modules, as they should, this would also save lots of time. Actually I think this would also provide much better handling of instance declarations. At the moment instance declarations are only picked up from files which GHC "knows about" via a transitive chain of imports. This has two user-unfriendly consequences; (a) it means that when a .hi file changes, every module which transitively imports (rather than just directly imports) has to be recompiled; (b) it is counter-intuitive. It would be better if all instance declarations in the compilation manager files were automatically known about. I can testify that SML/NJ's compilation manager really works very well and you don't miss the ability to set different compiler options for different files. Note that neither of these two suggestions actually do anything for GHC's cpu time. If I run top when GHC is running I rarely find it is using up more than 50% of the available CPU time; most of the time it is waiting on IO. However: (3) Stop using GCC-C as a backend. Instead make the GHC backend a new frontend to GCC. See http://www13.informatik.tu-muenchen.de/forschung/papers/eigene/piz_gic.ps for some explanation and arguments for this approach. Of course there are other obvious approaches. I'm sure it's unnecessary to re-code GHC in C to get C-like performance. Surely it would be better to optimise key sections of GHC by the normal tricks of unboxing things and specialising. I'm not suggesting that the GHC implementors actually do any of these suggestions now (though I suppose they could put them on the wish list). I'm much more concerned about getting GHC and Hugs talking to each other.
Re: Segmentation Fault
Simon Marlow wrote: Our nightly build did a two-stage bootstrap last night on a Sparc/Solaris system successfully ~/builds uname -a SunOS gigha 5.7 Generic_106541-04 sun4u sparc SUNW,Ultra-5_10 uname -a SunOS titania 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-1 ~/builds gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) gcc -v Reading specs from /usr/local/lang/gnu/lib/gcc-lib/sparcv9-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) Stage 1 was build with 4.04pl1 (make sure you have pl1!), and stage 2 was cksum ghc-4.04-sparc-sun-solaris2.tar.gz 2269644928 6114825 ghc-4.04-sparc-sun-solaris2.tar.gz bootstrapped. I've just done a stage 3 build too, which went through without a hitch. Was the stage 2 build installed in a separate directory as it was here, or eas it in place? So I'm at a loss now: Marc reported that downgrading his gcc fixed the problem. That suggests that it's a gcc bug, but we're using 2.95.2 here without any difficulties. There's also the outstanding build problem related to sigset_t, which I also can't reproduce. Any insight appreciated. OK, after hacking ghc-inplace to stop it deleting all its files (is there a --keep-everything option?) and running hsc inside gdb I get: Glasgow Haskell Compiler, version 4.06, for Haskell 98, compiled by GHC version 4.06 Program received signal SIGSEGV, Segmentation fault. 0x90062010 in ?? () (gdb) bt #0 0x90062010 in ?? () #1 0xa7db74 in schedule () #2 0xa7e080 in waitThread () #3 0xa7c8a8 in rts_evalIO () #4 0xa7c2b8 in main () I'll keep the gdb session alive for the rest of today if you have any more queries.
Re: Segmentation Fault
Michael Weber wrote: On Tue, Jan 18, 2000 at 11:21:06 +0100, George Russell wrote: [...] OK, after hacking ghc-inplace to stop it deleting all its files (is there a --keep-everything option?) and running hsc inside gdb I get: [...] EXTRAHCFLAGS="-keep-hc-files-too" I dimly remember an option -keep-s-files-too ... Yes, both those options exist but they keep the products of hsc, not what goes into it. In this case, the cpp'd unlit'd source. I would like a -keep-everything flag to actually keep everything . . .
./configure quibble
Why doesn't the configure script have a --with-happy option? There are --with-gcc and --with-hc to tell configure where to find gcc and GHC.
Re: ./configure quibble
Simon Marlow wrote: Why doesn't the configure script have a --with-happy option? There are --with-gcc and --with-hc to tell configure where to find gcc and GHC. It's kind of a policy decision: build.mk is the appropriate place for setting such things at the moment. There are good arguments in favour of both approaches, but I certainly don't want to duplicate everything that's in config.mk as options in configure. But if it would make your life considerably easier (unlikely to be easier than 'echo "HAPPY=my-happy" mk/build.mk', however), we could add --with-happy. The only thing that bothers me is the asymmetry.
Re: glasgow-haskell-docs.html.tar.gz please
Simon Marlow wrote: The binary dists all have pre-formatted HTML and PS docs, so you could just download one of those (except it seems the link to the Linux binary dist is currently broken; I'll fix that shortly, in the meantime there's the solaris binary dist). I think perhaps you are mistaken. There are ps versions of the documents but not HTML ones in the Solaris distribution. tar -tzf ghc-4.06-sparc-sun-solaris2.tar.gz | grep html fptools/html/ (and nothing else)
Floating-point nitpicking: floor(Inf) and floor(NaN)
floor(Inf) and floor(NaN) do not appear to be defined in Standard Haskell. (They both come down to "properFraction" which is only defined for Ratio.) This differs from (for example) the Standard ML Basis Library, where it is specified that floor(Int) should raise Overflow and floor(NaN) should raise Domain. Hence Hugs and GHC do different things. Hugs returns floor(Inf) = 0 and floor(NaN) = 0 GHC returns floor(Inf) = very very large integer and floor(NaN) = even larger integer. (This is because the GHC implementation of properFraction simply ignores the case of Inf/NaN and treats the artificially high exponent encoded in those floating-point numbers as if it were a real one.) My own opinion is that Standard ML is right here and that floor(x) should raise an exception (In Haskell terms, fail) when x does not correspond to a real number.
Re: Importing instances without pangling Make
George Russell wrote: This scheme is not the cleverest that could be devised. For example it is still necessary to recompile whole chains of modules if you add an import declaration. (Not to a system library, imports from those are counted as "stable" in GHCs and my system.) To fix this you would need to keep more information in the .hi file. Actually we can catch most of these cases too. Alter algorithm A so that if we have no changes to instances declarations in this file, the version numbers in directly imported modules are all the same, and the only change is that we import some modules we didn't import before, then only bump the version number if the import leads to new modules being imported which contain instance declarations. I think you can compute this at very close to zero cost at the start of compilation, when you are doing the imports.
Re: Importing instances without pangling Make
Malcolm Wallace wrote: Wrong. If B imports C and has no export list, nothing from C is re-exported, only definitions from B itself, with the single exception of C's instance decls. OK, but this has no influence at all on my suggestions except to make them work slightly better.
Re: Importing instances without pangling Make
Jon Fairbairn wrote: I'm afraid I've not gone through your detailed suggestions, but in the short term, would a crude hack that I used to use with Algol68C help? No, fraid not. GHC already does this hack anyway. Algol68C didn't have interface declarations. Still, nice to find someone else who remembers it.
Re: Importing instances without pangling Make
Sigbjorn Finne wrote: Seems like you're not using -recomp. No I'm not. What about documenting it somewhere?
Re: Importing instances without pangling Make
George Russell wrote: Sigbjorn Finne wrote: Seems like you're not using -recomp. No I'm not. What about documenting it somewhere? I take that back. I AM using it in the big program I mentioned, but I still get huge swathes of unnecessary compilations. Maybe it needs to be still cleverer.
Trivial Haskell Concurrency problem
Sorry if you don't want to be bothered with my problems, but I think this problem which I've just encountered is rather amusing. Is there a neat solution? I confess to finding concurrency problems difficult so there might be. I want to implement a type Flag. Each flag is either Up or Down. When you create a flag (there is a newFlag :: IO Flag operation) it is Up. The only operation permitted on Flags is lowerFlags :: Flag - Flag - IO Bool If both arguments are Up, lowerFlags should lower them both and return True, otherwise it should leave them as they are and return False. The problem is that lowerFlags should appear to be atomic, so that if lowerFlags is called simultaneously in different threads, the result should be the same as if one of the calls completed before the other started. So for example the following code type Flag = MVar Bool -- True means Up newFlag = newMVar True lowerFlags flag1 flag2 = if (flag1 == flag2) then error "Illegal call to lowerFlags" -- this is not allowed else do val1 - takeMVar flag1 -- point A val2 - takeMVar flag2 let success = (val1 val2) putMVar flag2 (not success val2) putMVar flag1 (not success val1) won't work, because if lowerFlags is called simultaneously with the same arguments but in a different order, and both calls reach point A simultanously, then both threads will block when they attempt the takeMVar in the next line. What is the neatest solution? There is an obvious solution, which is to crudely sequence all calls to lowerFlags by making them lock a single global variable (created using, sigh, unsafePerformIO) but this doesn't seem very elegant. If MVar's were instances of Ord as well as Eq, a neat solution would be to always get the least MVar first, but they aren't. So what should one do?
Re: Trivial Haskell Concurrency problem
Marcin 'Qrczak' Kowalczyk wrote: If the IO monad can maintain a random number generator, it can as well mainain unique Integer supply. The interface is clean. It can, but according to the current specification, it doesn't. Maybe it should. I think Integer is a little too specific - how about type Unique implements (Ord,Eq) newUnique :: IO Unique ? And what about having unsafePtrCompare in addition to IOExts.unsafePtrEq? I don't think unsafePtrCompare will get us out of jail here. Compacting garbage collection might change the order of the pointers around inbetween one thread comparing them and the other.
Re: Trivial Haskell Concurrency problem
Tom Pledger wrote: For two threads to have access to the same MVar, they must have a common ancestor, right? Could a common ancestor spawn a transaction broker thread? That would be similar to what database management systems do. It'd still be centralised, but wouldn't need to do unsafe IO. Well, all threads trivially have a common ancestor. But I don't see how you can pick a particular ancestor. The flags could easily have been passed around in a fairly general fashion along polymorphic channels.
Re: Trivial Haskell Concurrency problem
Marcin 'Qrczak' Kowalczyk wrote: ...relative time of IO events that occured in a single thread. (=) imposes the sequencing. Yes OK. I see no problem with required elements of the Unique type to increase in a single thread. But I suspect anything stronger than this could slow things down and/or cause difficulties. BTW: The random generator from the IO monad seems to be not thread-safe. Oops. I think it should be either fixed or documented. Haha. That'll teach them to write global variables into the standard, won't it? That's why I said Integer, not Int :-) It's important in the application I have in mind (the Two-Flags problem is a real one in UniForM) that the Unique type be as fast as possible. So I really do not want it to be tied to any particular thing. For example I suggest that for GHC the most efficient implementation might be an Int64 or a 64-bit pointer (to nothing) on machines which support that, or when not a Double with incrementing done by the nextAfter function. Integer is just too slow. (You have to allocate two blocks of memory for it I think.)
Re: Trivial Haskell Concurrency problem
George Russell wrote: George Russell wrote: Exactly the same happens at the same time to Processor 2. Now somehow you have to distinguish between Processor 1 and Processor 2, because only one is going to get to lower the flags. But I don't think with the existing Concurrency extensions plus standard Haskell you can. I take that back. There's a fundamental error in this analysis. Concurrent Haskell allows you to get the ThreadId of the current thread, and ThreadId DOES implement Ord. I thought of this last night and tried to work out a way of making the thread with the least ThreadId win, but couldn't quite do it. But it may still be possible. I think I now have a solution to my original problem. As said before, if we had a Unique type which implements ordering, it is easy, since we can attach one to each Flag, and make sure we take from the Flag with the lowest Uniq value first. I attach a file which implements Unique with NO global variables or unsafePerformIO, with comparison done in (at most) a logarithmic number of steps. The only fly in the ointment is that comparison itself has to construct the ordering on the fly, and so is an action and not a function. Also of course Marcin's suggested restrictions (Unique values must increase through the thread) cannot be implemented by this approach, since without global variables you can't know what order actions are called in. Unique.hs
Re: Importing instances without pangling Make
Part of the problem right now seems to be that GHC is wrongly rewriting (or perhaps touching) the .hi file even though nothing in it is altered. (This is clear because -hi-diffs is also on and not reporting anything). Thus even though I'm using -Onot -recomp it's still recompiling everything.
GHC include files
The latest binary distribution puts the GHC include files in "lib/ghc-4.06/includes", not "lib/includes" as older versions used to. This is a nuisance, because it means that there isn't any way a Makefile can refer to the includes without coding in the GHC version. Or is there? One needs access to the include files to get at, for example, Stg.h
Re: GHC include files
I must admit I'm surprised by the reaction to my suggestion. Here /usr is shared between lots of machines and there is no question of my installing GHC in /usr/bin or anything like it. (The few system adminstrators here are all honest, overworked, and sadly incorruptible.) My original problem was that GHC installs the include files in prefix/lib/ghc-4.06/includes meaning you have to know the version number as well as the prefix. I suppose this makes sense where prefix is in fact /usr, but I actually make prefix depend on the version, so having to specify the version twice is redundant. At least my scheme means that (on the rare times when I can build from source . . .) I can store multiple CVS releases.
Re: GHC include files
"Manuel M. T. Chakravarty" wrote: Malcolm Wallace [EMAIL PROTECTED] wrote, Can I propose a change to the -i / -I flags? Currently, the -idir (or -Idir) options add a directory to the search path for imports. This directory is either relative to the current dir, or absolute. My suggestion is that it could also be used for "relative to a standard installation directory". For instance, -Idata/edison would look first in ./data/edison if it exists, then in $prefix/data/edison, where $prefix has the value /usr/local/lib/ghc, or whatever. I don't think this scheme would solve my problem at all. As has been pointed out before, I can already get the GHC include files appended by calling "ghc" and not "gcc". It's a good suggestion and one I shall probably follow. BUT it is not ideal because (a) ghc seems to munge up its arguments rather a lot - for example, it rearranges libraries which is a problem for Solaris when you are using the system linker; (b) if you had a huge C program to which you wanted to link a little Haskell, it would be silly to compile all the code in the C program with ghc, and it would also be silly to compile some C code with gcc and some with gcc. I'm not sure what would be best; perhaps what I want is ghc options which won't do any compiling, but just tell me where the include files and libraries are. So then I can type GHC_INCLUDES = `$(GHC) -display-includes` or something like that . . .
Re: Recent Sparc breakage
Simon Marlow wrote: Sparc users in particular: I've identified some recent breakage in the Sparc port of GHC. If you've been experiencing crashes in binaries generated by a compiler built from recent (at least February) sources, then I've checked in a fix which might help. George, Marc: this probably fixes to the bugs you've both reported. The anon cvs repository should be updated around 1700 GMT today with the fix included (look for an update to fptools/ghc/rts/StgCRun.c). Cheers, Simon
Re: Recent Sparc breakage
Simon Marlow wrote: Sparc users in particular: I've identified some recent breakage in the Sparc port of GHC. If you've been experiencing crashes in binaries generated by a compiler built from recent (at least February) sources, then I've checked in a fix which might help. George, Marc: this probably fixes to the bugs you've both reported. The anon cvs repository should be updated around 1700 GMT today with the fix included (look for an update to fptools/ghc/rts/StgCRun.c). Hurrah. Many thanks to Simon Marlow for tracking down a particularly tiresome bug . . . Assuming he has, that is; if not I'll be complaining this time tomorrow . . .
Re: GHC include files
"Manuel M. T. Chakravarty" wrote: This is exactly what the `...-config' script that I was talking about is supposed to do. Now we can argue whether that should be part of `ghc' proper or an extra script. An extra script at least has the advantage that it is easier to maintain manual in case somebody moves a tree or so. On the other hand, wrapping it into the ghc command will make a version mismatch when someone moves files around slightly less likely.
Re: cvs update - patch: invalid options
Marc van Dongen wrote: Hello there, When doing cvs updates I get a lot of errors of the form patch: Invalid options. patch: Usage: patch [-blNR] [-c|-e|-n] [-d dir] [-D define] [-i patchfile]\ [-o outfile] [-p num] [-r rejectfile] [file] cvs update: could not patch ParseIface.y; will refetch Should I ignore these or look for a different patch? My first reaction would be to look for a different CVS, like GNU CVS 1.10. If you're already using that, get the GNU patch as well (which has many more options than most patches).
Re: Which regular expression library?
Two further comments on RegexString: (1) I actually have to use Ian Jackson's excellent matchRegexAll function to do what I want. If this were documented and supported I would appreciate it. (2) While I can live without the facility (I think) it would nevertheless be nice to be able to toggle at least case sensitivity and line mode, as Regex allows you to do. Something like the attached modified version of RegexString should do the trick, without breaking anything. Simon Marlow wrote: I'm worried that Regex might be obsolescent. If I change to RegexString, can I be sure that it's going to stay and be supported for the next two years? Sure. We might change the name though - I'd like to rename RegexString to Regex if/when we replace Regex with a PCRE version. Cheers, Simon RegexString.lhs
Re: Importing instances without pangling Make
Simon Peyton-Jones wrote: | At the time of writing, I am waiting for yet another long | Haskell re-make of | lots of modules to complete. The frustrating thing is, that | at least 90% of these | remakes are actually completely unnecessary. OK, I have heard your cries, and have fixed GHC. Try it. Many thanks. I will, tomorrow . . .
Re: Readline library
When I asked on the mailing list about this a year ago, I think I was told that it wasn't exactly supported any longer. So rather than trying to get GHC to compile ReadLine in, I used green-card instead. The attached file gives you the very simplest readline function. If you want to try to get GHC to include it, you could start by adding GhcLibsWithReadline = YES readlineIncludePath = -- where readline is HAVE_READLINE = YES to your build.mk file. "Wojciech Moczydlowski, Jr" wrote: I've been just writing some program using Readline library and I've noticed that I haven't got Readline.hi in /usr/local/lib/ghc/imports/util. Moreover, as I checked my source, I've found that it hasn't been built at all - it's not even in fptools/hslibs/util/.depend. What could have caused it and, more important :), how to build it now? Khaliff TM [EMAIL PROTECTED] http://www2.ids.pl/~khaliff ReadLine.gc
Re: improving error messages
(Sent to glasgow-haskell-users rather than haskell, as it is GHC-specific.) If we were writing a C library rather than a Haskell library, we could make "head" a macro which included an appropriate message referring to __FILE__ and __LINE__. The equivalent in Glasgow Haskell would be to make head inline, and include a primHaskellFile (and if possible, though I doubt it, primHaskellLine) which got replaced at a late stage by the actual name of the current module. This would be useful for locating other error messages as well. For example I have a debug action which (if debugging is turned on) prints out messages to a file; if we had a primHaskellFile I could make this debug message automatically refer to the calling module, which would be nice.
Re: Provenances of imported identifiers
Simon Peyton-Jones wrote: Try it now with -fddump-minimal-imports I don't promise it'll work, but it does in simple cases. It produces a file M.imports Brilliant, thanks. I'll try it out (indeed probably use it) when I next manage to compile GHC from CVS.
Re: tryTakeMVar :: MVar a - IO (Maybe a)
Would it be possible to implement an operation to lock an MVar without any extra expense? So that the thread owning the MVar can do things to it, but no other thread can. If it is possible, I suggest that it be added and it would solve Marcin's problem (isEmptyMVar would then suffice).
Re: tryTakeMVar :: MVar a - IO (Maybe a)
Simon Marlow wrote: The only way I can see to do this is to add a lock field to the MVar. And since this lock would look very much like another MVar, you may as well just use another MVar to lock it (after all, that adds exactly zero extra complication to the system :-). Absolutely. There's still some discussion to be had on what putMVar should do when presented with a full MVar. The options are The logical dual to tryTakeMVar would be tryPutMVar :: MVar a - a - IO Bool Or even tryPutMVar :: MVar a - IO a - IO (Maybe a) (the latter only if you can keep the MVar empty while you run the action.) I have absolutely no need for either of these functions, but would either of them be implementable without extra expense?
Re: putMVar on full MVar
Claus Reinke wrote: Right. I am relieved to read that your application source is not full of calls to putMVar, but rather uses safe abstractions built on top of MVars (it might be interesting to isolate them out of your current application and migrate them to a CH library?). Not a bad idea. Public implementations of channels are already available (I believe there is already code provided with GHC.) I think Einar Karlsen's composable events are an even neater idea and I should like to publicise and extend them some more later on, maybe by writing a paper about them. I don't understand the "tryButDoNotSuspend" operation. What does it mean, "would lead to an immediate suspension of the current thread"? It would incidentally be fairly trivial to implement tryForAWhileButDoNotBlockForever using Einar Karlsen's events. (Except of course that delays are always going to be approximate; GHC might not be able to run the thread bang on time because it could be in the middle of some C function.) I think the rest of Claus's discussion is a very good illustration of what I said before that you can think of other primitives that could arguably be provided for MVars and perhaps we should think the whole issue through carefully. Another thing which MVars can't do very well at the moment is multiple access. Perhaps there should be a function takeMVarList :: [MVar a] - IO a which waits for the first MVar to come along. (Again, you could easily implement such a thing using MVars defined in terms of Einar's events.) Well I have no quarrel with orthogonal extensions to MVars PROVIDED THAT THEY DO NOT GET SLOWER. So what do the wizards of GHC say can be done for free?
Re: putMVar on full MVar
Simon Marlow wrote: Let me see if I've got the semantics right: takeMVarMulti makes a non-deterministic choice between the full MVars to return the value, and if there are no full MVars it waits for the first one to become full? Yes that's precisely right. putMVarMulti is the converse. (So it only writes to one location, which will confuse some people.) Defining this in Haskell is pretty hard. I managed to do it for two MVars (code at the end of this message). There might be an easier way to do it using special code in the scheduler, but I need to think about that some more. It's _because_ defining it in Haskell is pretty hard that I was thinking maybe it should be added to the concurrency primitives. Unless I'm missing something, with the current concurrency primitives you cannot make a non-deterministic choice between N MVars with less than N threads, unless you do it by polling at intervals Actually even takeMVarMulti and putMVarMulti could be generalised. A more general non-deterministic MVar operation function might be multi :: [Multi a] - IO a data Multi a = forall b . PutMVar (MVar b) b IO a forall b . TakeMVar (MVar b) (b - IO a) This would wait for the first doable PutMVar or TakeMVar and then execute the corresponding continuation.
Re: What's in an interface? Unnecessary recompilation again
Simon Peyton-Jones wrote: Fair enough. But would you like to suggest an algorithm GHC could use to decide what to put in the .hi file? Well that's a big question. As I understand it, the errant value, lvl20, is a string representing an error message (which I suppose is to be thrown in the event of a matching failure). Since it should only be used on error, surely there is no speed benefit to inlining it, and probably there is a space penalty (since you store the string multiple times). In this case there is a very real disadvantage, since inlining forces everything that imports that module to recompile. So my suggestion would be that values required only for errors should never be inlined or put in a .hi file.
net library port numbers
Socket.accept function returns a PortNumber as its third argument. (This is not what the interface comment says, but the comment is wrong.) However I can't find any way of extracting the contents of the PortNumber to an integer.
Re: Unicode
Marcin 'Qrczak' Kowalczyk wrote: As for the language standard: I hope that Char will be allowed or required to have =30 bits instead of current 16; but never more than Int, to be able to use ord and chr safely. Er does it have to? The Java Virtual Machine implements Unicode with 16 bits. (OK, so I suppose that means it can't cope with Korean or Chinese.) So requiring Char to be =30 bits would stop anyone implementing a conformant Haskell on the JVM. (I feel strongly about this having been involved with MLj, which compiles ML to JVM; Standard ML requires 8-bit chars, a requirement we decided to ignore.)
More PackedStrings please
It would probably speed up my code somewhat if the GHC libraries provided more support for PackedStrings. For example, some code I have reads in stuff from a Posix fd (using Posix.fdRead) and then feeds it to the GHC regular expression interface (using RegexString.matchRegex). It is frustrating that although I am getting no benefit from all the boxing and thunks contained in the String type, I am still having to use it to get from fdRead to matchRegex. Therefore my suggestion is that such functions come in two flavours; one primitive version which uses PackedStrings, and one higher-level one which uses Strings. (The transformation from one to the other is hopefully trivial . . .) Of course I could just use the new foreign interface to call the relevant functions, but that's still comparatively yucky even with all the new improvements.
Re: numericEnumFromThenTo strangeness
Lennart Augustsson wrote: By definition, if you follow the standard you can't be wrong. :) But the standard can be wrong. Perhaps this is a typo in the report? I think I looked at this a while back. The standard is kaput. It gets even worse if you try to make sense of the definitions of succ and pred as applied to floating-point number. My suggestion: get rid of Enum on floating-point numbers. Maybe it'll make floating point loops a little lengthier to code, but at least it will be clear what exactly is being coded.
Re: How to add libgmp.a to lds search path
"Manuel M. T. Chakravarty" wrote: Is it possible that you are using a Linux box on which the gmp devel libraries are not (properly) installed? Very likely. Our local sysadmins do not appear to consider integers a sufficiently common concept in computer science to justify a MB or so installing gmp. So I (like about 7 others no doubt) compiled my own copy of gmp and copied libgmp.a to where GHC puts its libraries: [installation directory]/lib/ghc-4.08/
Re: GHC RPMs for RedHat 7
On this subject, where am I to get the libgmp2.a required by 4.08.1 (on Linux anyway). I tried compiling the very latest version of GMP but it only produced a libgmp.a file. Is that the same? NB that RPMs aren't a lot of good to me unless they come with a hefty bribe for the hard-nosed system administrators around here. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC RPMs for RedHat 7
Keith Wansbrough wrote: On this subject, where am I to get the libgmp2.a required by 4.08.1 (on Linux anyway). I tried compiling the very latest version of GMP but it only produced a libgmp.a file. Is that the same? Same happened to me. ln -s libgmp.a libgmp2.a worked for me. I satisfied myself I was doing the right thing by noticing all the 2.x.x version numbers on the libgmp source I'd compiled. Yes, that's what I did. Probably everyone has . . . Er, isn't this the sort of thing ./configure scripts are for? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
getContents
I don't really understand getContents. (Does anyone?) I have some code here (far too large to submit). If I do (on Linux, ghc4.08.1, both with and without optimisation) -- contents - hGetContents handle seq (last contents) (hClose handle) -- the code works. However I looked at the manual and it seems that hClose should force the whole of contents to be read anyway. So I changed it to -- contents - hGetContents handle hClose handle -- and then the code doesn't work. If these are meant to be the same, then we have a GHC bug. If not, could someone explain in words of one syllable why not? PS - if you want the source code you'll have to download and compile the whole of UniForM!! ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: getContents
Simon Marlow wrote: [snip] "Once a semi-closed handle becomes closed, the contents of the associated stream becomes fixed, and is the list of those items which were succesfully read from that handle". [snip] Ah, now I see. I had assumed that hClose'ing a semi-closed handle would result in the entire file being read till EOF, after which the file would be closed. Thanks. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Instant readFile
The readFile :: FilePath - IO String action returns the contents of the associated file. This is almost what I want, but not quite, because readFile is lazy. Hence if the string is only partly read, the file is still open. What I want instead is a function which (a) opens the file; (b) slurps the complete contents compactly into an array; (c) closes the file; (d) makes the contents of the array available as a String. So instead I wrote the following: copyFileToString :: FilePath - IO String copyFileToString file = do (addr,len) - IOExts.slurpFile file CString.unpackCStringLenIO addr len However on further consideration this also seems to me to be unsatisfactory, because although I don't understand this issue very well, I don't think the (addr) address containing the complete file contents will ever get deallocated, because there's no way the GC can know that this particular Addr can be free'd. (Is that correct?) So please, how _should_ I write this function? For example, I could try and wrap the addr into a ForeignObj, but then how would I ensure that when the String gets gc'd, the ForeignObj does too? It all is a bit of a mystery to me how you are supposed to use Addr like things without space leaks. A little more explanation in the documentation would not perhaps be amiss . . . ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
The Set type
A minor quibble I know, but every time I use sets I want to add/subtract single elements to/from them. There is no function provided for doing this, so instead you have to do union/delete with a singleton set constructed from the element. I appreciate the zeal of the designer of this module to construct the smallest possible interface (I wish the same person had designed the standard Prelude) but I think this zeal is overdone. You do often need to operate with single elements. After all, if you wanted real hair-shirt minimalism you should get rid of "elementOf" (replace it by \el set - isEmptySet (intersect set (singletonSet el)), but no-one would seriously suggest that - I hope. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Or-patterns
Why not steal a good idea from Standard ML/New Jersey now and again? This has "Or-patterns" which allow you to match against a disjunction of patterns, EG fun sleepIn (Date.Sat | Date.Sun) = true | sleepIn _ = false Where you have variables in the patterns, you bind only the variables which appear in all the patterns, and you unify the types accordingly. Of course you can do without this feature, but I feel it shouldn't be too hard to implement and for me at least it would be occasionally useful. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Command Line Help
"Steinitz, Dominic J" wrote: I was experimenting with using FiniteMap. The program compiled ok but the linker gave me the following error. What do I need to include on the command line or have I not installed ghc correctly? [dom@lhrtba8fd85 FiniteMap]$ /usr/bin/ghc -o main test.o -L/usr/lib/ghc-4.08.1 - lHSlang -lHSdata /usr/lib/ghc-4.08.1/libHSdata.a(FiniteMap__1.o): In function `__init_FiniteMap': FiniteMap__1.o(.text+0x16): undefined reference to `__init_GlaExts' collect2: ld returned 1 exit status I suggest using /usr/bin/ghc -o main test.o -package data -package lang -fglasgow-exts or something similar (rather than trying to name the libraries directly). ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
instance Bits Int
Why isn't Int an instance of Bits? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 4.08.2
Sven Panne wrote: [snip] The current branch-o-mania is a little confusing, but the CVS branch called "ghc-4-07-branch" (yes, "7", not "8") should contain what you are looking for. At least I think so... :-} Any bootstrapping problems? Yes, I get a segmentation fault when the compilation process first comes to use the resulting hsc executable. I have tried several times to avoid this (by changing gcc or ghc versions) but without success. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Semi-applied datatypes in instance declarations
I apologise if this has been raised before, but the code I am writing now would look rather nicer if "partially applied type constructors" were permitted in instances. For example: class Event e where sync :: e a - IO a data Event extraData a = blah blah . . . instance (context on extradata) = Event extradata where blah blah . . . Any chance of this? Or are there reasons why this would be wholly ridiculous? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
runProcess/ createPipe
If Posix.runProcess really is supposed "our candidate for the high-level OS-independent primitive" (see documentation), it would help if there was a documented way of using it with pipes. The problem is that runProcess takes handles as arguments, while the obvious function, createPipe, returns two Fds. There seems to be no _documented_ way of converting an Fd to a Handle. I suggest therefore that either there be a createPipeHandle :: IO (Handle,Handle) (which would be nice, because it might avoid bothering the operating system completely, and would makes sense on non-Posix systems). Or else, the existing Posix.fdToHandle fdToHandle :: Fd - IO Handle should be documented. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fail: thread killed
Marcin 'Qrczak' Kowalczyk wrote: [snip] Since the very purpose of killThread is to kill the damn thread, I find it inconvenient to have to wrap any thread which is supposed to be killable with Exception.catch to avoid the message. Worse: it should use block and unblock, otherwise there is a small window where killing the thread will still display the message. [snip] I agree with this. I also find it mildly irritating having to catch exceptions to stop GHC informing me that it's just garbage collected a thread which is permanently deadlocked. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc5.00 binary on Sparc?
GHC 5.00 looks wonderful. Would it be possible to make a binary distribution available for Sparc? As you may remember, I've had difficulty compiling it myself for Sparc, for some reason I don't know, and even if I find a way of hacking things to compile it, I'd rather users (= students) didn't have to . . . ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Why does --make only allow one module?
ghc --make would be wonderful for UniForM, which at the moment consists of a large selection of libraries, were it not for the restriction that ghc --make insists on only having one module as an argument. Er why? At this rate I shall be driven to writing an otherwise useless module which imports all the modules in each directory, since ghc --make does indeed look a lot faster than compiling each module individually. (In particular, we win big here, I think because the NFS system is very inefficient and makes reading all the .hi files very expensive.) Actually I'd like to just give ghc --make a list of ALL the source files and let it figure out the dependencies. This could also include object files (compiled from C) which were to be linked in, for example. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHCi turned upside down?
GHCi allows us to mix fixed compiled and dynamic interpreted code to be run from what I presume is dynamic interpreted code - the command prompt. Would it be possible to run dynamic interpreted code from a compiled program? I'm hoping the answer is Yes, because this is what GHCi does, the only problem being to clean up the syntax and document it. I'm afraid I haven't been following the FFI debate lately but perhaps we could steal some of the FFI's syntax for declaring types of imported entities. The difference (I'm not sure if this is a difference with the latest with the latest FFI version) would be that the source file/string (and perhaps function name) need to vary dynamically, which means also that of course it needs to be done below top level, and invoke an IO action. So we might try something like runMain :: FilePath - IO () runMain sourcePath = do source - readFile sourcePath foreign import ghci source main main :: IO () main which would read the file sourcePath, interpret it as Haskell, and run the main action therein. This isn't meant to be a polished proposal, just an idea for something which might be nice to have around in the future. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
do's and error messages
If you have a type error message at the very start of a do statement, the result can be rather confusing, because the typechecker doesn't know that do's are almost always have type (IO (something)) and so tries to shoehorn the monad to fit the type. This has actually happened to me several times; the worst case is when the result is (for example) a list, which allows the error to propagate further. Is there some way of doing something about this? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
wait(2)
Is there a way in Glasgow Haskell to get a thread to wait on a child process in the same way as the Posix function wait(), and get the termination status of the child? If so, how? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
unterminated {-
Seems to me it would make more sense for the message .hs:214: unterminated `{-' message to tell me where the {- is, rather than where the EOF is. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Multi-parameter OOP
Recently I've been experimenting with a sort of OOP with GHC, using existential types and (overlapping, undecidable) multi-parameter type classes, but it doesn't seem to work as you might expect because of the way GHC resolves overloaded functions at compile-time. For example, given class A a data WrappedA = forall a . A a = WrappedA a data A1 = A1 instance A A1 class B b data WrappedB = forall b . B b = WrappedB b data B1 = B1 instance B B1 class AB a b where toBool :: a - b - Bool instance (A a,B b) = AB a b where toBool _ _ = False instance AB A1 B1 where toBool _ _ = True instance AB WrappedA WrappedB where toBool (WrappedA a) (WrappedB b) = toBool a b a naive user (like me a month ago) might expect that this to work, so that toBool (WrappedA a) (WrappedB b) will return False unless a is an A1, and b a B1, in which case it returns True. In fact ghc5.02 (rightly) gives an error message with the second instance declaration: Could not unambiguously deduce (AB a b) from the context (A a, B b) The choice of (overlapping) instance declaration depends on the instantiation of `a, b' So is there any other way of doing this sort of dynamic lookup at runtime, in a reasonably neat way? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Existential Typing (was Multi-parameter OOP)
Leon Smith wrote: [snip] If GHC had true existential typing, as opposed to just existential datatypes, you could reasonably code what I think you want like this: class A a where basicA :: Bool nextA :: a - (EX a'. A a' = a') basicA = True nextA = id data WrappedA = forall a. A a = WrappedA a instance A WrappedA where basicA = False nextA (WrappedA a) = a data A1 = A1 instance A A1 --... similarly for B ... class AB a b where toBool :: a - b - Bool instance (A a, B b) = AB a b where toBool a b | (basicA :: a) (basicB :: b) = True | (basicA :: a) || (basicB :: b) = False | otherwise = toBool (nextA a) (nextB b) [snip] Either I've missed something, or this isn't what I wanted. The problem I have is that AB is not extensible. If you want to add a new instances A2,B2 of A,B and a new definition of toBool which just works for A2 and B2, you can't do it, without changing the definition of toBool in the above instance. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
What isn't possible with Finite Maps, and should be.
Once again I find myself wanting something like the following function with finite maps: fmToListByRange :: Ord key = FiniteMap key elt - (key,key) - [(key,elt)] fmToListByRange map (k1,k2) is supposed to return all elements in the map with keys from k1 to k2 (inclusive). Although this isn't as common as looking up an element by a key, it nevertheless is sometimes useful, and shouldn't be too hard to implement, given that FiniteMaps are going to be implemented (given the Ord constraint) as some sort of tree-like query structure, so it's just a question of scanning down the tree splitting the interval as you go. Of course this can be generalised. A general range would have type (Maybe key,Maybe key,Bool) where Nothing instead of a key would mean starting at one of the ends, and the Bool would indicate whether you gave the elements in increasing or decreasing order of key. In any case it looks fairly simple to write. If only I were set up to be able to compile GHC I could write the necessary code myself . . . ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc --make + #include directories
Simon Marlow wrote: What's wrong with just saying -Idir whenever you say -idir? This seems to work but for more complicated combinations the two options have slightly different formats. For example, if I have several directories separated by colons, and end the list with a superfluous colon (which arises naturally enough when the path is auto-computed) I get messages like: gcc: cannot specify -o with -c or -S and multiple compilations /home/ger/uni /usr/local/pub-bkb/ghc/ghc-latest/bin/ghc -c util/WBFiles.hs -iutil:cvs: -Iutil:cvs: -package concurrent -package data -package net -package posix -package text -package util -package lang -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -cpp -ddump-hi-diffs -H25M -recomp -fwarn-deprecations -Onot -DDEBUG -fvia-Cgcc: /usr/local/pub-bkb/ghc/ghc-5.02.1/lib/ghc-5.02.1/include: linker input file unused since linking not done Source file changed or recompilation check turned off INTERFACE UNCHANGED gcc: cannot specify -o with -c or -S and multiple compilations [falls over] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Why have file names with 3 components?
This looks like a bug, but please don't change it! If you have a file A.blah.hs containing a module A, ghc5.02 compiles it, producing A.hi and A.blah.o. I have an application for this, since I have just, for the first time, been reluctantly compelled to introduce recursive modules. Rather than writing .hi-boot files (which might have to be rewritten for ghc5.03) I have instead written .boot.hs files, which yield .hi files, which then get moved to .hi-boot. Thus a module A has two sources, the real source A.hs, but also the source for the .hi-boot file, A.boot.hs. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Telling ghc where to start
There are various reasons why one might have a Haskell file which doesn't have the expected Module.hs filename, in particular when putting ghc into some larger system which does its own thing with files. I may well want this as part of UniForM in the next few months. However ghc doesn't provide anyway support for this, and while you could create a symbolic link with a name ghc approves of to the real file, that seems somewhat messy. gcc has an option which allows you to specify that the input is, say, a C program (even though it's called hello.txt) but it's rather messy and might take too long to implement. I suggest instead a new option called -virtual-name or something similar, so that ghc -virtual-name Module.hs /blah/horrible932 will compile the contents of /blah/horrible932, but treat it as if it were called Module.hs. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Casting dynamic values
It would occasionally be nice to have a function cast :: (Typeable a,Typeable b) = a - Maybe b which returns Just a if a and b have the same type, and Nothing otherwise. This may seem rather a curious need, but it arises with existential types; if you have data A = forall a . (context) = A a (context including Typeable a) then this allows you to getB :: (Typeable b) = A - Maybe b getB (A a) = cast a and so extract a value from A, if you can guess its type. Clearly we can implement cast = fromDynamic . toDyn My question is: is this the most efficient way of doing it, or is there a better way? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Multiply Recursive Modules
Writing .hi-boot files is a pain, and the works (allegedly) containing a compiler which does mutually recursive modules properly seem permanently gummed up. Therefore may I suggest a new .hs-boot suffix which compiles Haskell to produce just a .hi-boot file? I already have two .hs-boot files (except I call them .boot.hs to make ghc happy) and they seem to work reasonably well. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cygwin GHC
Simon Peyton Jones wrote: I am therefore deeply reluctant to provide both GHC-for-mingw32 and GHC-for-cygwin. One build on Win32 is enough! We ended up with a mingw32 basis because it meant we could make GHC=20 completely self-contained -- no dependence on cygwin1.dll etc. This was *huge* step forward: GHC installs and runs with no problem on Windows now. I agree about it being a huge step forward. I do not think I would be in favour of undoing this and going back to having to install cygwin (in the right version) to get GHC to run. 1. GHC does not understand cygwin paths in the file names passed to it on the command line. 2. GHC on Win32 does not come with a Posix library. If we used a Cygwin basis, Posix would be easy because cygwin does all the hard work. 3. I/O on Win32 is *blocking*. A blocking input operation freezes all the other Haskell threads. I am a little but not hugely bothered by (1) and (2), as they can all be worked around in various ways. The real problem is (3), since it means that not just IO events but almost all events from the non-Haskell world cannot be waited on without bringing the Haskell world to a halt. Is it possible to do something about (3) without switching back to Cygwin? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-pkg (5.03.20020204) problems
Can you stop ghc-pkg complaining when it can't find the library for a package, and insert the package into its configuration file? Some of my scripts rely on being able to build the package.conf file ahead of time. What with this, and because ghc-pkg doesn't seem able to cope with private config files (see previous report) ghc-pkg in 5.03 is causing me lots of problems. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc5.03 .hi and .hi-boot files don't you just love those incompatible changes?
Formerly .hi and .hi-boot files had the same format; however ghc5.03 has a binary format for .hi files and a textual one for .hi-boot files. This is a nuisance for me, because I have an ingenious scheme by which .hi-boot files are themselves from Haskell files by ghc, which thinks it is generating .hi files. Since I don't particularly want to go from writing to Haskell to writing interface files, I would like to keep the old scheme, but then I need a way of getting GHC to generate .hi-boot files from .hs files. One might think the options -ddump-hi or --show-iface would do the job, but they don't. --show-iface produces a file which causes Haskell later to choke with the message failed to load interface for `DisplayView': Bad interface file: DisplayView.hi-boot DisplayView.hi-boot:1: parse error on input `__interface' -ddump-hi is even worse, since it adds an extra two totally useless lines at the start (but otherwise appears to be the same as --show-iface). So is there any way of getting GHC to generate .hi-boot files? Or should I give up on using .hi-boot altogether and simply compile the Haskell direct to the .hi file? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc5.03 .hi and .hi-boot files don't you just love those incompatible changes?
Ah, I've figured it out. The new .hi-boot file format is actually Haskell!! Well almost. You have to fully qualify type names (you can't use Int, you must use GHC.Base.Int) and the input isn't run through -cpp. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: package name mismatch
Simon Marlow quoted Max Kirillov [snip] Building htk, I've got an error: =20 TestGetPut.hs:6: Module `GetPut' is located in package `Main' but its interface file claims it is part of package `uni-events-test' =20 It happened (as far as I got) when ghc saw in current path the *.hi file built for installation. There are some ways to work around it, but, there was a lot of such places, so can I just skip the 'package name' check and go as it is? This was converted to a warning in, I think, ghc 5.02.3. Please upgrade, preferably to 5.04. [snip] It must have been only a warning in 5.02.3, or I could never have compiled it there. (Before 5.02.3 we didn't use the package system like this at all.) Actually I would like this message to go away altogether in this case, if possible. The actual situation is that GetPut.hs is in fact part of the package uni-events-test, and the compiler is told to load uni-events-test on the command line. However GetPut.hs is *also* in the current directory during this compilation, so GHC loads it from there instead. I'm not sure what logic would be best here, but my suggestion would be that where a .hi file is found in an import declaration and has an unexpected package name, GHC keeps on searching. If it finds a .hi file with a matching package name, it accepts it, otherwise accept the .hi file with the wrong package name and issue a warning. If that's too complicated, just ignore .hi files with the wrong package name. But then people might complain . . . [ - for Max's eyes only - As a matter of fact, this file is not needed for uni-htk anyway (it's just part of a test case) so Max could just work around it. If you just do gmake package rather than gmake or gmake all I don't think it will occur, though that will also mean the test programs don't get made. If you want the HTk examples go into htk/examples and do gmake main and/or gmake test there. - ] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: package name mismatch
Simon Marlow wrote: [snip] Can't you just fix your build so that the situation doesn't occur? [snip] Grumble. Yes, I suppose so. I hate being an implementor instead of a bug-reporter. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
DeepSeq
Would it be possible to bring the DeepSeq library into the libraries distributed with GHC? (I think Dean Herington is responsible for it.) Of course it's easy enough to drop it into one's own program (I am just about to do this) but (1) It is fairly common to want to force deeper evaluation. (2) DeepSeq is simple enough to be dropped in the GHC distribution, without it causing much trouble or making it much bigger. (3) At the same time, it is not so simple that it can be reimplemented in a couple of lines. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Glasgow-haskell-users digest, Vol 1 #672 - 1 msg
[EMAIL PROTECTED] wrote: [snip] I've been experimenting with making an asynchronous IO library. At the moment it uses Haskell threads but the idea is that it could be transparently extended to use system AIO. I think what you are really asking for is asynchronous events, a la Reppy. I don't like to blow my own trumpet (well, I do actually), but I've already implemented these in Haskell, see the paper in ICFP 2001. Of course John Reppy got there first with PML/CML. http://charlesstreet22.force9.co.uk/~duncan/projects/aio/AIO.hs My question is if there is an effecient way to block / wait on multiple MVars. takeMVar readMVar can wait on one MVar. The puspose is to be able get the reults of a list of AIO operations, in the order in which they complete. Not at the moment. Also I'm not sure such a thing could usefully be added without more or less adding events anyway. It's not enough to have takeOneMVar :: [MVar a] - IO a which looks for the next a, because pretty soon someone is going to want you to implement data MVarActionPair a = forall b . MVarActionPair (MVar b) (b - IO a) takeOneMVar' :: [MVarActionPair a] This I suppose could be done without too much trouble, but then you run into problems because the supplier of events has no way of knowing if these events are actually being picked up or not, something that can be very important. To solve this problem in general you need Reppy-style higher-order events. So you might as well have implemented those from the beginning anyway. Also I am very much opposed to loading extra burdens onto the implementors of MVar's unless we can be reasonably sure that MVars won't get slower as a result. MVars are an excellent low-level abstraction; it's better to build more complicated things on top of MVars as required. Good luck, George Russell ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Suggested improvements to .hi-boot files
I am using .hi-boot files quite a lot at the moment. I'm very grateful for the recent change to a more Haskelly syntax, but I have a couple of suggestions for the GHC team to implement in their no doubt ample free time. 8-) (1) Importing a module {-# SOURCE #-} into itself currently produces a warning, but no other action so far as I can see. I suggest instead that this provoke a check that the .hi-boot module accurately reflects reality. (Otherwise there is no way of checking is there?) Or perhaps you could add a pragma {-# RECURSIVE #-} at the top of the module that indicates the presence of a .hi-boot file which should be checked. (2) Instance declarations (with empty bodies) should be permitted. (3) There should be an option to pass .hi-boot files through cpp. This would not be particularly useful to me, as I have already implemented a pre-compilation phase which does just that, but it might be useful for others. (4) The manual should recommend using say the GHCi :info command to find out that, say, IO must be called GHC.IOBase.IO. (If I'd known this it'd have saved me having to trawl through the GHC sources.) Obviously one would ideally be able to type IO rather than GHC.IOBase.IO, but my guess would be that this would be (a) harder to implement than the other suggestions, (b) less useful. Happy New Year by the way. If any Simon is still reading, about long have we got before the current old library hierarchy is done away with in an official release? Sometime before then I will need to carry out a massive global-exchange. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Avoiding No explicit method ... warnings
This isn't a bug, just a suggestion. It's not even a very important suggestion, but one that might be worth implementing if it's easy and you can find the the time. Or perhaps I am just doing things the wrong way? The point is that I sometimes have something like the following situation class ComplicatedClass x where simpleTitleFn :: x - String muchMoreComplicatedTitleFn :: extra arguments - x - IO (WithError (Source blah blah blah String) muchMoreComplicatedTitleFn _ x = [ ... some expression involving simpleTitleFn ...] The idea is that only muchMoreComplicatedTitleFn must always work; however instances may choose to implement it directly, or implement the much simpler function simpleTitleFn (if that does all they want). At the moment the situation is that someone who defines just muchMoreComplicatedTitleFn will get an unnecessary warning message from the compiler about No explicit method or default method for simpleTitleFn. I suggest instead introducing a new class of optional method (for example, via a pragma {-# OPTIONAL_METHOD simpleTitleFn #-}) which compiles exactly as normal except that (1) no warning is given for instances which don't define it; (2) a warning is given whenever anyone outside the class declaration *uses* simpleTitleFn. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Avoiding No explicit method ... warnings
Simon Peyton-Jones wrote: [snip] One other idea though. Suppose you say class ComplicatedClass x where _simpleTitleFn :: x - String muchMoreComplicatedTitleFn :: extra arguments - x - IO ... In general GHC doesn't report warning unused for variables whose name begin with an underscore. In the case of class methods, I don't think it suppresses the warning, but that would be an easy change to make. Indeed, it would arguably be more consistent to do so anyway #-}) which compiles exactly as normal except that (1) no warning is given for instances which don't define it; (2) a warning is given whenever anyone outside the class declaration *uses* simpleTitleFn. The _ idea would achieve (1). You could get (2) by not exporting the _ method from the module defining ComplicatedClasss. How would that be? [snip] Yes, this looks just as good as my original idea, if not better. Especially as it would be an easy change to make. In fact there are some cases where I might want to use simpleTitleFn on a Trust me, it's defined for this type basis, but that could be achieved by exporting an equivalent, but deprecated, function. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
HTk for ghc-5.04.2
I've compiled HTk for ghc-5.04.2 on Solaris, Linux and Windows, and put binary bundles at http://www.informatik.uni-bremen.de/htk/ So you can write portable graphical user interfaces using the latest release of your favorite Haskell compiler. Sorry it's a bit late; it's not that it's difficult, it's just that I am a shortage of manpower. I hope I produce binaries for ghc-5.04.3 a bit faster. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
Alex wrote [snip] Using ghc-5.04.2 under cygwin, and cygwin (v. 1.3.10-1), I'm having some horrible problems with inconistent treatment of filenames, especially when using (gnu, cygwin) make. In a nutshell, make seems to be passing paths such as /usr/local/hmake (etc) to ghc, which is, as I understand it, interpretting these in a manner consistent with windows, but not with cygwin. (i.e., it'd expect the above to be something like: /cygwin/usr/local/hmake, where the root of the cygwin installation is in c:\cygwin. Experimenting with similar arguments to ghc by hand seems to confirm this. [snip] The UniForM/HTk distribution includes the attached very simple Haskell98 program, which is compiled and run during the ./configure stage. This program transforms stdin to stdout, globally replacing the string #PWD with whatever GHC thinks the current directory is called. This program is used in various ways; in particular ./configure uses it to set a variable GHCTOP corresponding to GHC's name for the top of the source distribution, which is then what gets passed to GHC. The program is also used for various unholy tricks involving package config files, which also of course need the Windows name. Fortunately GHC doesn't mind if some slashes are the wrong way; thus if GHCTOP is C:\foo\bar\uni, then I can refer to C:\foo\bar\uni\baz as $GHCTOP/baz, as it would be on Unix. {- This program converts stdin to stdout. It replaces all occurrences of the string #PWD in stdin with the current directory in which it is executed, C escaped. The string #pwd is similarly replaced, except that it is not escaped. Everything else is left unchanged. If an argument is supplied, this is used instead of the current directory. The program occupies an unusual place in the UniForM sources; it is not part of the main sources, but is only used during building (see suffix.mk) and is compiled during configuration. Since it only uses completely standard Haskell 98, this ought to be pretty easy. We do things this way rather than with some sort of script so that this will work even in the extremely hostile environment of Windows (with no cygwin). Also, using GHC's getCurrentDirectory means we get at what GHC thinks the current directory is (IE the Windows file name) rather than what it is in cygwin's Unix world. -} module Main (main) where import Directory import System main :: IO () main = do input - getContents args - getArgs toInsert - case args of [arg] - return arg [] - getCurrentDirectory let escapeString s = let withQuotes @ ('\':rest) = show s in take (length rest - 1) rest quoted = escapeString toInsert transform [] = [] transform ('#':'P':'W':'D':rest) = quoted ++ transform rest transform ('#':'p':'w':'d':rest) = toInsert ++ transform rest transform (c:rest) = c:transform rest putStr . transform $ input
FreeBSD + FIFO pipes
Yes I know it's a FAQ, but despite the information in the GHC FAQ I can't get my program to work. I'm trying to get HTk to work on FreeBSD (actually FreeBSD running inside a VMware virtual machine, but I don't think that should make any difference). How HTk works is it creates a couple of pipes (readIn,writeIn) - Posix.createPipe (readOut,writeOut) - Posix.createPipe It then forks off a process which first dup2's readIn onto its stdin and writeOut onto its stdout, and then runs the Tcl/Tk shell wish (which does graphics). The idea is that sending commands along writeIn will cause them to be executed by wish, and wish's output can be read from readOut. We do the reading/writing of readOut/writeIn using the Posix fdRead/fdWrite primitives. In addition, before every call to fdRead we do a Posix.threadWaitRead on it, to make sure there is actually input there. All this works fine on Linux and Solaris by the way. (On Windows we use a completely different mechanism.) The problem I am getting with FreeBSD is that fdRead sometimes reports EOF, even though threadWaitRead has just reported the presence of data. (And no, I don't think we have a race condition here, the relevant bit of code is in an exclusive lock.) If I tell it to ignore the EOF and try to read again and again it just throws it into an endless loop, seemingly. The GHC FAQ says: A workaround for all systems is to open the FIFO for writing yourself, before (or at the same time as) opening it for reading. What does it mean open the FIFO for writing yourself? I've tried putting in the following lines immediately after creating the pipes byteCountOut - fdWrite writeOut # (strIn,byteCountIn) - fdRead readOut 1 case (byteCountOut,byteCountIn,strIn) of (1,1,#) - done x - error (ChildProcess.999 error++show x) byteCountOut - fdWrite writeIn # (strIn,byteCountIn) - fdRead readIn 1 case (byteCountOut,byteCountIn,strIn) of (1,1,#) - done x - error (ChildProcess.9998 error++show x) which just write a single character down each pipe; unfortunately this doesn't seem to help. Any other suggestions? By the way this is all GHC5.04.1, which seems to be the last FreeBSD version available, at least with pkg_add. Thanks. George Russell ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FreeBSD + FIFO pipes
Volker Stolz wrote: In local.glasgow-haskell-users, you wrote: I'm trying to get HTk to work on FreeBSD (actually FreeBSD running inside a VMware virtual machine, but I don't think that should make any difference). How HTk works is it creates a couple of pipes (readIn,writeIn) - Posix.createPipe (readOut,writeOut) - Posix.createPipe The problem I am getting with FreeBSD is that fdRead sometimes reports EOF, even though threadWaitRead has just reported the presence of data. (And no, I don't think we have a race condition here, the relevant bit of code is in an exclusive lock.) If I tell it to ignore the EOF and try to read again and again it just throws it into an endless loop, seemingly. Can you cut this down to a simple program, maybe executing /bin/echo instead of 'wish'? Notice that the FAQ doesn't apply here as the FAQ talks about FIFO createt by mkfifo (which exist in the file system), while you talk about pipes. I'll try to think of something, but I'd be glad if you already had a usable program to reproduce this error. I think this one is going to remain unsolved. I have fixed the problem, by reimplementing the relevant code in a different way (actually resurrecting an old implementation, with a vital fix) and now it works. However the cause of the problem I reported is a mystery to me, and producing a simple test case does not look very easy. Thanks for your help, George ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
HTk for ghc5.04.3
I have created binary bundles for HTk, our Haskell interface to Tcl/Tk, for ghc5.04.3 on Linux/x86 and Windows, and put them on the download page: http://www.informatik.uni-bremen.de/htk/download/INSTALL.BINARY.html I will add FreeBSD and Solaris bundles when I can get hold of ghc5.04.3 on those platforms. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Hash functions
Many thanks for Data.HashTable, which I am about to use. Unfortunately I seem to need an unseemly hack because the key I want, namely ThreadId's, don't have a hash function defined, and defining one requires me to muck around with GHC internal functions. Could some more hash functions be provided? The logical method would be to have class HashKey key where hash :: key - Int32 and define it for as many types as possible. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
HTk + ghc6.01
Binaries for HTk (a Haskell graphics package that uses HTk) for ghc6.01 on Linux, Solaris, Windows and FreeBSD are now available from the HTk page: http://www.informatik.uni-bremen.de/htk/ Many thanks to Guy Coleman for the FreeBSD package. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Pestilential behaviour of gcc3.3 on Macs
Yes I know this is really Apple's fault, but according to http://developer.apple.com/documentation/ReleaseNotes/DeveloperTools/GCC3.html The GCC 3.3 preprocessor inserts a new pragma, #pragma GCC set_debug_pwd, as part of the new Distributed Builds feature. (See below.) This may surprise tools and scripts that depended on the exact form of preprocessed output from GCC. These scripts should be rewritten to ignore unrecognized pragmas. Would it be possible for GHC to ignore this line? Otherwise ghc -cpp is going to fall over with gcc3.3 on Macs. Of course in the ideal world I know we should be using Template Haskell. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Template Haskell and the command line
Template Haskell is frightfully good and we want to get rid of cpp and use it instead, but there's one tiny problem, namely that for cpp it is possible to define variables on the command line (-DSIMON=MARLOW and so on) while with Template Haskell it doesn't seem to be. Could there be some kind of dictionary, like the cpp environment variables, which the Template Haskell code has access to? One obvious way would be to accept the -D/-U arguments, and provide Haskell functions which look at them. Of course one /could/ presumably use System.getArgs and analyse the arguments to ghc oneself, but that would mean making guesses about the current GHC syntax. In the meantime we shall still replace cpp with Template Haskell, but find another way. Thanks for Template Haskell! ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users