From ostermann at informatik.tu-darmstadt.de Mon Jun 19 19:25:42 2006 From: ostermann at informatik.tu-darmstadt.de (Klaus Ostermann) Date: Tue Jun 20 06:15:24 2006 Subject: [Hat] Problem building hat Message-ID: <01a601c693f7$af357840$63a55382@rachmaninoff> Hi there, I am trying to build hat using ghc6.4.1 with windows/cygwin. I also tried nhc, but with the same error. ./configure works fine, but "make" exits with the following error: Warning: package(s) base not available (according to ghc-pkg) Can't find module lang in user directories . . ../compiler98 Or in installed libraries/packages at Asked for by: commandline Fix using the -I, -P, or -package flags. Stop - hmake dependency error. make[1]: *** [c:/dev/hat-2.04/lib/ix86-CYGWIN_NT-5.1/hat-trans.exe] Error 255 make[1]: Leaving directory `/cygdrive/c/dev/hat-2.04/src/hattrans' make: *** [targets/ix86-CYGWIN_NT-5.1/hat-trans-ghc] Error 2 Any ideas? Thanks, Klaus P.S.: It would be great if you could add binaries to your download section From ndmitchell at gmail.com Tue Jun 20 08:17:46 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jun 20 08:09:19 2006 Subject: [Hat] Problem building hat In-Reply-To: <01a601c693f7$af357840$63a55382@rachmaninoff> References: <01a601c693f7$af357840$63a55382@rachmaninoff> Message-ID: <404396ef0606200517n7955ee9bvaa757dcda14a42ec@mail.gmail.com> Hi Klaus, > P.S.: It would be great if you could add binaries to your download section Since hmake doesn't work under Windows, and hat-trans is much harder to use without it, its hard for a Windows user to generate .hat files. Once this capability has been added to Yhc (its half the way there), then Windows users will be able to generate .hat files. Once that has been done, I do intend to release native Windows binaries - I have compiled them (they require a few patches), but can't really test them without a hat file generator. Of course, with Cygwin you might have some success, I'm just waiting for native Windows binaries :) Thanks Neil From Malcolm.Wallace at cs.york.ac.uk Wed Jun 21 06:05:06 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Jun 21 05:59:50 2006 Subject: [Hat] Problem building hat In-Reply-To: <01a601c693f7$af357840$63a55382@rachmaninoff> References: <01a601c693f7$af357840$63a55382@rachmaninoff> Message-ID: <20060621110506.3d602a34.Malcolm.Wallace@cs.york.ac.uk> Klaus Ostermann wrote: > I am trying to build hat using ghc6.4.1 with windows/cygwin. > I also tried nhc, but with the same error. > > Warning: package(s) base not available (according to ghc-pkg) Interesting warning. > Can't find module lang in user directories > . > ../compiler98 > Or in installed libraries/packages at > The fact that no attempted location is reported for the standard installed libraries is worrying. It suggests that ghc-pkg is being invoked incorrectly by hmake. Another thing that looks wrong is that of course there is no module 'lang' - it is a library package instead. One suggestion is that the version of GHC is not being detected correctly. If the contents of the file targets/ix86-CYGWIN_NT-5.1/ghcsym are not "604" (without whitespace), then this would cause at least some of the symptoms you see. Correcting that, (and the corresponding variable definition for GHCSYM in lib/ix86-CYGWIN_NT-5.1/config ) might be enough to get you further. > P.S.: It would be great if you could add binaries to your download section If a Windows user will create them, we will gladly host them for download. Regards, Malcolm From tatd2 at kent.ac.uk Wed Jun 21 06:18:12 2006 From: tatd2 at kent.ac.uk (Thomas Davie) Date: Wed Jun 21 06:12:49 2006 Subject: [Hat] Problem building hat In-Reply-To: <20060621110506.3d602a34.Malcolm.Wallace@cs.york.ac.uk> References: <01a601c693f7$af357840$63a55382@rachmaninoff> <20060621110506.3d602a34.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <3EC66E51-B7E7-4FAF-8953-91016648314B@kent.ac.uk> On 21 Jun 2006, at 11:05, Malcolm Wallace wrote: > Klaus Ostermann wrote: > >> I am trying to build hat using ghc6.4.1 with windows/cygwin. >> I also tried nhc, but with the same error. >> >> Warning: package(s) base not available (according to ghc-pkg) > > Interesting warning. > >> Can't find module lang in user directories >> . >> ../compiler98 >> Or in installed libraries/packages at >> > > The fact that no attempted location is reported for the standard > installed libraries is worrying. It suggests that ghc-pkg is being > invoked incorrectly by hmake. Another thing that looks wrong is > that of > course there is no module 'lang' - it is a library package instead. I have to admit seeing this error with ghc-6.5 on OS X... Simply removing the "-package lang" in the options worked for me - I assume the lang package is brought in by default now. Bob From ndmitchell at gmail.com Sat Jun 24 15:41:47 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Jun 24 15:33:08 2006 Subject: [Hat] Thoughts, Int vs Integer Message-ID: <404396ef0606241241r75925fd7r3b9a873a65e590e4@mail.gmail.com> Hi, Often when compiling with Hat I run into the Int vs Integer issue, in fact this is pretty much the biggest problem I have getting hat traces generated. I was considering if there was any possible change that could be performed by Hat to remove this restriction. The best I came up with makes semantic changes to the program, but these changes are "very minimal" at a guess :) The idea basically revolves around "type Int = Integer" - replace all occurances of Int with Integer at the type level, make all functions that operate on Int now operate on Integer instead, and all numeric literals can now become Integer, since there is no Int. There are two semantic changes from this which I have thought of: 1) big_number * 2 will never overflow, which will give a different semantics. Personally this sounds like a good idea, and having a hat-overflow tool to detect when an Integer goes above 2^31 would probably be a useful addition. I don't consider this change to be all that bad, since its compatible with the Haskell98 report (I think). 2) More seriously, type classes will lead to different code being invoked. For example while 0 == 0 might have invoked Int equality now it will invoke Integer equality. My guess is that if there is a program where the type class for Int is not a subset of the behaviour of that for Integer, its very weird and confusing and probably buggy. The changes to the generator that would need to be made are (as far as I can tell) as follows: * Replace all occurances of Int with Integer * Make all numeric literals 0 :: Integer * On encountering a typeclass if there existing an instance for one of Int or Integer, then use that one. If instances exists for both Int and Integer then throw away the Int version. For a prototype, allow-undecideable-instances & allow-overlapping-instances should handle this automatically. * Any primitive operations that are performed on Int and not Integer would need to be worked around, probably on a case by case basis, but this should be a small number. Comments or thoughts? Thanks Neil From tatd2 at kent.ac.uk Sat Jun 24 15:57:40 2006 From: tatd2 at kent.ac.uk (Thomas Davie) Date: Sat Jun 24 15:52:03 2006 Subject: [Hat] Thoughts, Int vs Integer In-Reply-To: <404396ef0606241241r75925fd7r3b9a873a65e590e4@mail.gmail.com> References: <404396ef0606241241r75925fd7r3b9a873a65e590e4@mail.gmail.com> Message-ID: <30FD24BC-48C9-485B-8E53-1F6A46B9D240@kent.ac.uk> On 24 Jun 2006, at 20:41, Neil Mitchell wrote: > Hi, > > Often when compiling with Hat I run into the Int vs Integer issue, in > fact this is pretty much the biggest problem I have getting hat traces > generated. I was considering if there was any possible change that > could be performed by Hat to remove this restriction. > > The best I came up with makes semantic changes to the program, but > these changes are "very minimal" at a guess :) > > The idea basically revolves around "type Int = Integer" - replace all > occurances of Int with Integer at the type level, make all functions > that operate on Int now operate on Integer instead, and all numeric > literals can now become Integer, since there is no Int. > > There are two semantic changes from this which I have thought of: > > 1) big_number * 2 will never overflow, which will give a different > semantics. Personally this sounds like a good idea, and having a > hat-overflow tool to detect when an Integer goes above 2^31 would > probably be a useful addition. I don't consider this change to be all > that bad, since its compatible with the Haskell98 report (I think). > > 2) More seriously, type classes will lead to different code being > invoked. For example while 0 == 0 might have invoked Int equality now > it will invoke Integer equality. My guess is that if there is a > program where the type class for Int is not a subset of the behaviour > of that for Integer, its very weird and confusing and probably buggy. > > The changes to the generator that would need to be made are (as far as > I can tell) as follows: > > * Replace all occurances of Int with Integer > * Make all numeric literals 0 :: Integer > * On encountering a typeclass if there existing an instance for one of > Int or Integer, then use that one. If instances exists for both Int > and Integer then throw away the Int version. For a prototype, > allow-undecideable-instances & allow-overlapping-instances should > handle this automatically. > * Any primitive operations that are performed on Int and not Integer > would need to be worked around, probably on a case by case basis, but > this should be a small number. > > Comments or thoughts? The basic problem with this is that the bug may well be that an Int is overflowing... You don't want the bug to not manifest it's self in the self tracing version. Bob From ndmitchell at gmail.com Sat Jun 24 16:11:26 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Jun 24 16:02:45 2006 Subject: [Hat] Thoughts, Int vs Integer In-Reply-To: <30FD24BC-48C9-485B-8E53-1F6A46B9D240@kent.ac.uk> References: <404396ef0606241241r75925fd7r3b9a873a65e590e4@mail.gmail.com> <30FD24BC-48C9-485B-8E53-1F6A46B9D240@kent.ac.uk> Message-ID: <404396ef0606241311u593d8bd6l73bffd1b2fe04ed3@mail.gmail.com> Hi, > > 1) big_number * 2 will never overflow, which will give a different > > semantics. Personally this sounds like a good idea, and having a > > hat-overflow tool to detect when an Integer goes above 2^31 would > > probably be a useful addition. I don't consider this change to be all > > that bad, since its compatible with the Haskell98 report (I think). > > The basic problem with this is that the bug may well be that an Int > is overflowing... You don't want the bug to not manifest it's self in > the self tracing version. If we assume that most Haskell numbers are below 2 billion - both Int and Integer, then its easy enought to detect all the places where a number exceeds this in the trace. I suspect that for most programs this will be never. If it does occur, I suspect it will be very rare, and all these occurences can be listed, which would directly track down the bug really quickly (faster than with the current Hat tools). The theoretical "hat-overflow" tool can be written which does this. I suspect a bigger problem would be where the code for an Int instance is dubious, since that is actually a completely different code path. But again, I guess this happens really really rarely. I guess most Int/Integer instances are in the standard libraries, so relatively safe. To be clear, because of the semantic changes associated with this approach, this should be a configurable option. Thanks Neil From tatd2 at kent.ac.uk Sat Jun 24 20:09:55 2006 From: tatd2 at kent.ac.uk (Thomas Davie) Date: Sat Jun 24 20:04:26 2006 Subject: [Hat] Thoughts, Int vs Integer In-Reply-To: <404396ef0606241311u593d8bd6l73bffd1b2fe04ed3@mail.gmail.com> References: <404396ef0606241241r75925fd7r3b9a873a65e590e4@mail.gmail.com> <30FD24BC-48C9-485B-8E53-1F6A46B9D240@kent.ac.uk> <404396ef0606241311u593d8bd6l73bffd1b2fe04ed3@mail.gmail.com> Message-ID: On 24 Jun 2006, at 21:11, Neil Mitchell wrote: > Hi, > >> > 1) big_number * 2 will never overflow, which will give a different >> > semantics. Personally this sounds like a good idea, and having a >> > hat-overflow tool to detect when an Integer goes above 2^31 would >> > probably be a useful addition. I don't consider this change to >> be all >> > that bad, since its compatible with the Haskell98 report (I think). >> >> The basic problem with this is that the bug may well be that an Int >> is overflowing... You don't want the bug to not manifest it's self in >> the self tracing version. > > If we assume that most Haskell numbers are below 2 billion - both Int > and Integer, then its easy enought to detect all the places where a > number exceeds this in the trace. I suspect that for most programs > this will be never. If it does occur, I suspect it will be very rare, > and all these occurences can be listed, which would directly track > down the bug really quickly (faster than with the current Hat tools). > The theoretical "hat-overflow" tool can be written which does this. I think the question is more whether such a tool would ever be run. The users thought path is likely to be along the lines of "oh... it works now... I can't debug it if it worked" Bob From Malcolm.Wallace at cs.york.ac.uk Mon Jun 26 06:02:39 2006 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Jun 26 05:59:25 2006 Subject: [Hat] Thoughts, Int vs Integer In-Reply-To: <404396ef0606241241r75925fd7r3b9a873a65e590e4@mail.gmail.com> References: <404396ef0606241241r75925fd7r3b9a873a65e590e4@mail.gmail.com> Message-ID: <20060626110239.09461be3.Malcolm.Wallace@cs.york.ac.uk> "Neil Mitchell" wrote: > Often when compiling with Hat I run into the Int vs Integer issue, in > fact this is pretty much the biggest problem I have getting hat traces > generated. I think you are probably referring to the lack of defaulting for ambiguous numeric literals. This is not really an Int vs Integer thing. It occurs when an expression contains both numbers and numeric operations without a type signature to disambiguate which specific type to use for the operation. In normal Haskell'98, they would default to Integer. There is no Int involved at all. So your proposed solution (aliasing Int to Integer) would not actually solve the problem, which is about resolving class constraints. > 1) big_number * 2 will never overflow, which will give a different > semantics. Personally this sounds like a good idea, and having a > hat-overflow tool to detect when an Integer goes above 2^31 would > probably be a useful addition. I don't consider this change to be all > that bad, since its compatible with the Haskell98 report (I think). This kind of overflow detection would be somewhat easy to write in Tom's proposed Hat query language (WHat). find an application of (*) [ or (+) ] where the absolute value of both operands exceeds 1 where the absolute value of the result is smaller than the absolute value of either operand [ app | ((*) x y) <- app , absvalue(x) > 1 , absvalue(y) > 1 , (absvalue(app) < absvalue(x)) || (absvalue(app) < absvalue(y)) ] A similar property could also be written in QuickCheck, to find overflow errors through testing. > * Make all numeric literals 0 :: Integer You could make a case for simply attaching a type signature to any numeric literal that does not already have one. It would certainly fix the numeric defaulting problem, because it removes all ambiguity. However, it would be incorrect for programs that do not currently suffer from numeric ambiguity. For instance, it is relatively common to define new numeric types e.g. Matrix, where a literal number n has a reasonable interpretation e.g. as the identity matrix scaled by n. Forcing the literal to be of type Integer would make the program type-incorrect. Unfortunately, hat-trans is a syntactic transformation which (deliberately) does not have access to type inference. If it did, then the defaulting problem would be easily solved. Regards, Malcolm From ndmitchell at gmail.com Mon Jun 26 12:22:32 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jun 26 12:13:46 2006 Subject: [Hat] Hat and Windows Message-ID: <404396ef0606260922l4cb971f7ub42decdbdba2289e@mail.gmail.com> Hi, I've tried to get Hat compiling on Windows today, and have had some success. I found the following problems and fixes: 1) hat-trans cannot be compiled with ghc -cpp (it breaks on the string gaps), and cpphs can't be used as pgmP as it is. I have submitted a patch for cpphs to make this possible. With this change, hat-trans builds fine for Windows. 2) When running hat-trans, its remarkably painful on Windows, and I got frequent unexplained crashes, but there are a few patches required: Windows does not have ntohl, so I added a specific one for Windows. SIGQUIT does not exist on Windows, I just commented out this line. fopen(file,"w") should be fopen(file,"wb") to use Binary mode under Windows. With these patches, the remaining issues are build issues - I am intending to write a very hacky hat-make which sorts these out, possibly in a Windows specific way, to make it a single hat-make Main command to generate a hat binary. I did not build the hat translated libraries under Windows, I took the Linux versions. With these changes I am able to generate a simple hat file that can be processed by the Linux hat tools properly. Thanks Neil From O.Chitil at kent.ac.uk Mon Jun 26 12:31:30 2006 From: O.Chitil at kent.ac.uk (Olaf Chitil) Date: Mon Jun 26 12:22:48 2006 Subject: [Hat] Hat and Windows In-Reply-To: <404396ef0606260922l4cb971f7ub42decdbdba2289e@mail.gmail.com> References: <404396ef0606260922l4cb971f7ub42decdbdba2289e@mail.gmail.com> Message-ID: <44A00BE2.6050809@kent.ac.uk> Neil Mitchell wrote: > > I've tried to get Hat compiling on Windows today, and have had some > success. I found the following problems and fixes: Sounds great. Neither Malcolm nor I know much about Windows. So it's great that you are getting Hat to work under Windows. Ciao, Olaf PS: Concerning Int vs Integer I agree with Malcolm that it would only partially solve the problem with the defaulting rule; I think changing all Integers to Int is a too complex hack for a too unclear gain. I hardly ever had problems with the defaulting rule (except for one-line test programs), but that probably depends a lot on the kind of programs one writes. From ndmitchell at gmail.com Tue Jun 27 06:10:57 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jun 27 06:02:09 2006 Subject: [Hat] Hat and Windows In-Reply-To: <44A00BE2.6050809@kent.ac.uk> References: <404396ef0606260922l4cb971f7ub42decdbdba2289e@mail.gmail.com> <44A00BE2.6050809@kent.ac.uk> Message-ID: <404396ef0606270310l6889dac1w18f2727f5d9e84e@mail.gmail.com> Hi, Continuing on the "Hat on Windows" stuff I have now written hat-make, which builds a program for Hat tracing on Windows. I'll send this over once I have written a Windows makefile which builds the Hat stuff. Attached is a patch to fix hat-c.c, and a new ntohl.h file to be added in hat\include. Since ntohl.h is not available on Windows and is used in a few of the Hat tools it makes sense to separate this off. Thanks Neil On 6/26/06, Olaf Chitil wrote: > Neil Mitchell wrote: > > > > > I've tried to get Hat compiling on Windows today, and have had some > > success. I found the following problems and fixes: > > Sounds great. Neither Malcolm nor I know much about Windows. So it's > great that you are getting Hat to work under Windows. > > Ciao, > Olaf > > PS: Concerning Int vs Integer I agree with Malcolm that it would only > partially solve the problem with the defaulting rule; I think changing > all Integers to Int is a too complex hack for a too unclear gain. I > hardly ever had problems with the defaulting rule (except for one-line > test programs), but that probably depends a lot on the kind of programs > one writes. > _______________________________________________ > Hat mailing list > Hat@haskell.org > http://www.haskell.org/mailman/listinfo/hat > -------------- next part -------------- #if defined(WIN32) /* Windows does not have ntohl, so define it here */ #define htonl(x) ntohl(x) int ntohl(int x){ int ret; unsigned char* pr = (unsigned char*) &ret; unsigned char* px = (unsigned char*) &x; pr[0] =px[3]; pr[1] = px[2]; pr[2] = px[1]; pr[3] = px[0]; return ret; } #else /* Unix does, so just use it */ #include /* for ntohl() macro */ #endif /* WIN32 */ -------------- next part -------------- A non-text attachment was scrubbed... Name: hat-c.c.patch Type: application/octet-stream Size: 1693 bytes Desc: not available Url : http://www.haskell.org//pipermail/hat/attachments/20060627/caf558dd/hat-c.c.obj From ndmitchell at gmail.com Tue Jun 27 10:46:05 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jun 27 10:37:18 2006 Subject: [Hat] Hat on Windows, patches Message-ID: <404396ef0606270746s5698469ep598ed377cec6971d@mail.gmail.com> Hi, Attached is a patch and some files required to build Hat on Windows. These superceed the ones I sent earlier. With this you get the following tools: hat-trans, exactly as per Linux hat-make, a new tool for windows, think hmake -hat but for Windows (and not as clever) hat-check, exactly as per Linux hat-cover, not very useful unless you do -hion and -hioff since the escape codes are turned off hat-stack, like Linux minus the syntax hilighting hat-observe, lots of escape code garbage, but you can still see the answers The tweaks are: ntohl, not on Windows fopen needs a "b" in the list of options no escape codes, try and eliminate them where possible The new files are: Makefile.bat, the root of the hat repo, serves as a Makefile on Windows - please rename Makefile.bad to .bat, because Gmail won't let me send a "dangerous executable" ntohl.h, for include ntohl.c, for src\hattools, provides the implementation of ntohl HatMake.hs, for src\hattools, the implementation of hat-make Most of the user visible changes are because of the lack of escape codes, which are used in the Linux versions to make a GUI out of the console. The Windows solution would just be to use the standard GUI, and turn the tools into slightly more abstract versions which can have the two interaction methods layered on top of them. I also want to change hat-cover to have an option to output HTML, possible combined with HsColour (modified to be a Haskell library as well as a program) so you can get syntax coloured and nicely highlighted Haskell code. Thanks Neil -------------- next part -------------- A non-text attachment was scrubbed... Name: hat-windows.patch Type: application/octet-stream Size: 6084 bytes Desc: not available Url : http://www.haskell.org//pipermail/hat/attachments/20060627/dd8fcd73/hat-windows-0001.obj -------------- next part -------------- #if defined(WIN32) /* Windows does not have ntohl, so define it here */ #define htonl(x) ntohl(x) int ntohl(int x); #else /* Unix does, so just use it */ #include /* for ntohl() macro */ #endif /* WIN32 */ -------------- next part -------------- int ntohl(int x){ int ret; unsigned char* pr = (unsigned char*) &ret; unsigned char* px = (unsigned char*) &x; pr[0] =px[3]; pr[1] = px[2]; pr[2] = px[1]; pr[3] = px[0]; return ret; } -------------- next part -------------- A non-text attachment was scrubbed... Name: HatMake.hs Type: text/x-haskell Size: 2431 bytes Desc: not available Url : http://www.haskell.org//pipermail/hat/attachments/20060627/dd8fcd73/HatMake-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.bad Type: application/octet-stream Size: 1579 bytes Desc: not available Url : http://www.haskell.org//pipermail/hat/attachments/20060627/dd8fcd73/Makefile-0001.obj From ndmitchell at gmail.com Fri Jun 30 09:43:57 2006 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Jun 30 09:35:04 2006 Subject: [Hat] Missing functions Message-ID: <404396ef0606300643n1028b949kcd16672d55566559@mail.gmail.com> Hi, Now I have Hat on Windows working pretty much, I have tried compiling various programs, unfortunately only very simple examples go through because of missing libraries. I have started a page on the wiki to track the missing dependancies: http://haskell.org/haskellwiki/Hat Thanks Neil From tatd2 at kent.ac.uk Fri Jun 30 09:46:08 2006 From: tatd2 at kent.ac.uk (Thomas Davie) Date: Fri Jun 30 09:42:19 2006 Subject: [Hat] Missing functions In-Reply-To: <404396ef0606300643n1028b949kcd16672d55566559@mail.gmail.com> References: <404396ef0606300643n1028b949kcd16672d55566559@mail.gmail.com> Message-ID: <6BC68361-14DD-4125-A1FC-193ED563711A@kent.ac.uk> Data.Map certainly is supported in the latest CVS version - I have programs that use it compiling quite happily under Hat. Bob On 30 Jun 2006, at 14:43, Neil Mitchell wrote: > Hi, > > Now I have Hat on Windows working pretty much, I have tried compiling > various programs, unfortunately only very simple examples go through > because of missing libraries. I have started a page on the wiki to > track the missing dependancies: http://haskell.org/haskellwiki/Hat > > Thanks > > Neil > _______________________________________________ > Hat mailing list > Hat@haskell.org > http://www.haskell.org/mailman/listinfo/hat From tatd2 at kent.ac.uk Fri Jun 30 09:46:49 2006 From: tatd2 at kent.ac.uk (Thomas Davie) Date: Fri Jun 30 09:42:20 2006 Subject: [Hat] Missing functions In-Reply-To: <404396ef0606300643n1028b949kcd16672d55566559@mail.gmail.com> References: <404396ef0606300643n1028b949kcd16672d55566559@mail.gmail.com> Message-ID: Oops, sorry, my bad, Data.List is, Data.Map isn't. Bob On 30 Jun 2006, at 14:43, Neil Mitchell wrote: > Hi, > > Now I have Hat on Windows working pretty much, I have tried compiling > various programs, unfortunately only very simple examples go through > because of missing libraries. I have started a page on the wiki to > track the missing dependancies: http://haskell.org/haskellwiki/Hat > > Thanks > > Neil > _______________________________________________ > Hat mailing list > Hat@haskell.org > http://www.haskell.org/mailman/listinfo/hat