Re: -i naked flag
On Sun, 23 Dec 2007 11:36:50 -0500 Alex Jacobson [EMAIL PROTECTED] wrote: The current docs use -i without any arguments to reset the path back to []. That is an interesting feature but it is much less useful than being able to use shell based tab completion when entering command line options. I suggest that the -i reset feature be removed in favor of e.g. --clear-search-path zsh completion is configurable in such a way that you can work around this issue, but in general I don't disagree. -Alex- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Seth Kurtzberg [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: ANNOUNCE: GHC version 6.8.2
On Sun, 16 Dec 2007 16:43:53 +0100 Juanma Barranquero [EMAIL PROTECTED] wrote: On Dec 16, 2007 3:38 PM, Yitzchak Gale [EMAIL PROTECTED] wrote: As long as GHC has a built-in notion of home directory, which doesn't exist on Windows, there needs to be a user-configurable way to specify what to do instead, as there always was until now. It depends on a lot of factors - exactly how are you using this home directory, how does it interact with other apps, details about the platform, etc.. If nothing is specified, then, as a last resort, there is no choice but to use the Profile folder as the default. FWIW, I agree 100% with this. Juanma Indeed, what's the alternative? Also, in general deployed programs are compiled and linked. Behavior related to ghci initialization is not going to break deployed software. Changes to the behavior of a development tool are in a different class than changes that may impact deployed programs. Seth ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Seth Kurtzberg [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.8.2
Isaac makes an important point (although I'm not sure it's the point he intended to make :) ), there is really nothing in the definition of UNIX itself that specifies or requires a home directory. It's a convention followed by shells, primarily. Seth On Sun, 16 Dec 2007 14:36:55 -0500 Isaac Dupree [EMAIL PROTECTED] wrote: Felix Martini wrote: On Dec 16, 2007 3:38 PM, Yitzchak Gale wrote: No, the two are not the same. It is the User Profile folder. It is not a Unix-style home directory - there is no such concept on Windows. The two are used very differently. I guess we disagree about that. I believe what Micosoft calls the user profile folder is equivalent to what is called the user home folder in Unix. This is especially obvious in Vista, most folder names are the same as in OSX, e.g. C:\Users\Felix\Music and /Users/Felix/Music. FWIW, here on Linux I didn't like all my automatically generated-in-$HOME stuff being spewed all over my own organization, so ]echo $HOME /Users/me/HOME (I'm in GoboLinux which uses /Users rather than /home, which isn't important to this) and my .zshrc has cd; cd .. (a.k.a. cd /Users/me) to take me to my personal home directory in the non-Unix sense. It's a bit of a nuisance sometimes, but worth it for me; the worst that happens is sometimes I have to go up a level first in file-chooser dialogs or ~/../ paths. Isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: ANNOUNCE: GHC version 6.8.2
On Sat, 15 Dec 2007 21:31:25 +0300 Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello Juanma, Saturday, December 15, 2007, 4:24:43 AM, you wrote: Because what Yitzchak Gale proposed and I seconded does not mean that getHomeDirectory will not follow the Windows API, unless very specifically requested by setting HOME. i'm against this idea. one can setup HOME for some specific program and then find that all his ghc-compiled programs are changed their behavior. ghc don't have a goal of emulating Unix standards in windows environment so such behavior will look unexpectedly I too agree, and would add that (as someone pointed out earlier) it's trivial to wrap the function in question. Further, not only is it trivial but it's more correct in the sense that O/S specific behavior should be isolated whenever possible, and such isolation is certainly possible here. Create a class that defines, but does not implement, the required methods, and create an instance for the O/S in use. That's clean, simple, and is guaranteed to not break existing working programs. -- Seth Kurtzberg [EMAIL PROTECTED] -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: ANNOUNCE: GHC version 6.8.2
On Sun, 16 Dec 2007 03:21:14 +0200 Yitzchak Gale [EMAIL PROTECTED] wrote: Removing support for %HOME% has suddenly broken many programs. If people don't like it, we can consider deprecating it in some future version of GHC, but for now it should put back. I would say it is quite ironic that some people are arguing against this by saying that it will lead to more bug reports. It is *not* trivial to wrap the function in question, and it is not more correct. Why is it *not* trivial to wrap the function? Regardless of whether you like the resulting solution, it is undeniably trivial to change the name of a function, create a new function with the (original) name, and have that new function call the original function, or call the original function based on some criteria, or implement different behavior entirely? I did so here, and in roughly 10 minutes I verified that the behavior was exactly as one would expect. Now, you may not approve of the resulting behavior, but that's an entirely separate question of whether something is, or isn't, trivial to implement. I wrote a few lines of code; certainly seemed trivial to me. I have a bit more sympathy for your assertion that changing the default behavior is not something to be done lightly, but if a small modification allows you to implement either the old or new behavior, the question becomes what should the default behavior be? (Or perhaps the *default* behavior? I've always found that the use of punctuation as a substitute for rational discussion is an attempt to be insulting rather than to enter into a discussion on the merits. If you believe something is not trivial, then state your reasons. If you don't have a reason, hold the bluster and the asterisks. Seth The current behavior is not more WIndows native - it is arguably much worse. The %HOMEPATH% variable should definitely not be used. The folder that it points to is not a home directory and should not be used that way. But if there is no other way to provide a value for getHomeDirectory, I guess that is still better than throwing a run-time exception, but at least obtain the path in a somewhat Windows-friendly way by using the API properly. It is just not true that using %HOME% creates problems. This is a widespread convention, in active use. Admittedly ad-hoc, but it works. Does anyone know of even a single incident in which this created a problem? Better native Windows integration is definitely an important goal. The whole idea of a .ghci file is very Unixy, for example. There is a lot of work to be done in this direction. Pulling the rug out from under %HOME% without providing a reasonable alternative is not the way to begin. By reasonable alternative, I mean a way that users can configure GHC's notion of home directory at run-time on Windows. Truthfully, I don't think this should be the first priority for better Windows integration. Wouldn't our time be better spent on Visual Studio integration and WinAPI support? Not to mention .NET... Thanks, Yitz -- Seth Kurtzberg [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: upgrading visual studio integration to use 6.8.2....
Wouldn't an eclipse plug in make more sense? (Unless one exists that I'm unaware of.) -- Seth Kurtzberg [EMAIL PROTECTED] On Fri, 14 Dec 2007 14:46:14 + Simon Marlow [EMAIL PROTECTED] wrote: Hi Krasimir, Yes, I'm sure that's true. I suspect the best way is for Visual Haskell to add its own configuration sections to the .cabal file, and recognise them when they are already there. Understanding the .cabal file is not a problem, but we also have to be able to modify it, for example when the user adds a module. In the presence of configurations this could be tricky, but for the complex cases where we can't figure out how to modify it we can just require the user to edit the .cabal file by hand (since presumably it wasn't generated by Visual Haskell in the first place anyway). BTW, I was recently made aware of Visual Studio Shell: http://msdn2.microsoft.com/en-us/vsx2008/products/bb933751.aspx This is a freely redistributable Visual Studio installer that includes no language support, but allows plugins. In theory at least Visual Haskell ought to run on top of it. So then a complete Visual Haskell would be available for free. Are you (or anyone else) interested in looking into this? Cheers, Simon Krasimir Angelov wrote: The hard work is to integrate it with the new version of Cabal. The problem is that the configurations model that Cabal employs can't be easily matched with the configurations in Visual Studio. For the new GHC versions I expect that the changes will be more trivial. Cheers, Krasimir On Dec 13, 2007 6:23 PM, Nicholls, Mark [EMAIL PROTECTED] wrote: Ahhh okin eclipse it was trivial.but I'd much prefer it to be in VS. -Original Message- From: Simon Marlow [mailto:[EMAIL PROTECTED] Sent: 13 December 2007 16:22 To: Nicholls, Mark Cc: glasgow-haskell-users@haskell.org Subject: Re: upgrading visual studio integration to use 6.8.2 Nicholls, Mark wrote: I've just downloaded the vs integration packagewhich looks greatbut it comes with 6.6.1, and I was hoping to move to 6.8.2does anyone know how to do this? No, someone needs to rebuild Visual Haskell using 6.8.2, and test it etc. There have been lots of changes in both the GHC API and Cabal, so I expect it will not be a straightforward recompile. Also building Visual Haskell itself is no mean feat. We'd love it if someone were able to take this on. The code for Visual Haskell is available at http://darcs.haskell.org/vshaskell. Also, we need to update it for VS 2008... Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: upgrading visual studio integration to use 6.8.2....
Thanks. On Fri, 14 Dec 2007 14:57:05 - Bayley, Alistair [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Kurtzberg Wouldn't an eclipse plug in make more sense? (Unless one exists that I'm unaware of.) http://eclipsefp.sourceforge.net/ Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * -- Seth Kurtzberg [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: if-them_else
Maybe it's from Chicago and doesn't see anything wrong with them in that context. :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge D. Mechveliani Sent: Wednesday, November 21, 2007 9:04 AM To: glasgow-haskell-users@haskell.org Subject: if-them_else Dear GHC developers, when compiling the function f x = if x them False else True ghc-8.8.1 reports:parse error on input `else' . When there is a large expession after `them', it is sometimes difficult to locate a typo. Why does not it report parsing if-then-else: cannot find `then' ? Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: if-them_else
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wolfgang Jeltsch Sent: Wednesday, November 21, 2007 10:32 AM To: glasgow-haskell-users@haskell.org Subject: Re: if-them_else Am Mittwoch, 21. November 2007 15:03 schrieb Serge D. Mechveliani: Dear GHC developers, when compiling the function f x = if x them False else True ghc-8.8.1 reports:parse error on input `else' . When there is a large expession after `them', it is sometimes difficult to locate a typo. Why does not it report parsing if-then-else: cannot find `then' ? Regards, them is a perfect identifier. So probably x them False gets parsed as an expression (x applied to them and the result applied to False). Haskell’s lightweight syntax makes programs short and easy to read (in my opinion) but it often makes the compiler unable to guess where your mistake lies. That means that the compiler does not know about the error at the time the them token is parsed. It doesn't imply that the error message cannot be better. In this case, since the compiler, indeed, detects the error at the token else, it should be straightforward to improve the error message. Now, whether it is worth the effort is a separate question, and a judgement call, but it is surely possible and not even terribly difficult. Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: GHC version 6.8.1
Is is possible that by upgrading the version of gcc changed? I've had problems compiling ghc6.8.1 with some versions of gcc that have disappeared by upgrading gcc. Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philip K.F. Hölzenspies Sent: Wednesday, November 14, 2007 7:17 AM To: Simon Marlow Cc: glasgow-haskell-users@haskell.org Subject: Re: ANNOUNCE: GHC version 6.8.1 On Tuesday 13 November 2007 12:27:02 Simon Marlow wrote: maybe add a test right after the creation of DerivedConstants.h in includes/Makefile: DerivedConstants.h : mkDerivedConstantsHdr ./mkDerivedConstantsHdr $@ test -f $@ || exit 1 at least that will tell us whether it was never there to start with, or it got removed later on. If it weren't for the fact that this seems repeatable, I'd say you have need to run fsck on that filesystem. There's definitely something strange going on... Dear Simon, All, This looks like a sensible thing to do, a makefile check. I don't expect this to be a fsck-solvable problem though, since I've tried at different times with rather different states of my filesystem (rather full, nearly empty, again rather full). Good news for me, bad news for this bug-report. My office system crashed, so I was updated from SuSE 10.0 to SuSE 10.3. GHC 6.8.1 now compiles out of the proverbial box. Although, ... I had initially forgotten to install the readline-dev package (for libreadline.a). The configure script doesn't test for linkage against readline, so make terminates because ghc-pkg-inplace doesn't have readline and libraries/readline contains a file called unbuildable. I would call this a small buildbug with a very easy fix: add readline linkage test to configure. Regards, Philip ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Extensible Records
6.10? I think that's a typo as the current version is 6.8.1. Or did I misunderstand what you were saying? Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Voldermort Sent: Saturday, November 10, 2007 6:24 PM To: glasgow-haskell-users@haskell.org Subject: Extensible Records Is there any chance of seeing extensible records in GHC 6.10? There seems to be widespread agreement that the current situation is unacceptable, but the official GHC policy is that there are too many good ideas to choose from - so nothing gets done! I hence humble propose that http://www.cs.uu.nl/~daan/download/papers/scopedlabels.pdf be adapted to GHC. In my naivete, I assume that porting an existing implementation would be much easier than starting from scratch. Is this reasonable? N.B. I am aware that GHC has limited resources - many thanks to Simon Simon and all other contributors either way. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Extensible Records
I misread it as 6.1. Sorry about that. -Original Message- From: Stefan O'Rear [mailto:[EMAIL PROTECTED] Sent: Saturday, November 10, 2007 6:55 PM To: Seth Kurtzberg Cc: 'Voldermort'; glasgow-haskell-users@haskell.org Subject: Re: Extensible Records On Sat, Nov 10, 2007 at 06:35:34PM -0500, Seth Kurtzberg wrote: Is there any chance of seeing extensible records in GHC 6.10? There seems to be widespread agreement that the current situation is unacceptable, but the official GHC policy is that there are too many good ideas to choose from - so nothing gets done! I hence humble propose that http://www.cs.uu.nl/~daan/download/papers/scopedlabels.pdf be adapted to GHC. In my naivete, I assume that porting an existing implementation would be much easier than starting from scratch. Is this reasonable? N.B. I am aware that GHC has limited resources - many thanks to Simon Simon and all other contributors either way. I second this request. Yes, I know you *could* do something in a library; but it's MUCH nicer as a built-in feature. Sadly. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.8.1 is impressive!
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Hercek Sent: Friday, November 09, 2007 9:19 AM To: glasgow-haskell-users@haskell.org Subject: Re: GHC 6.8.1 is impressive! New ghc sped up my small app (~2000 lines) by ~38%. Nice job! Anyway, my application is a bit slower when compiled with -O2 compared to -01 only (both with ghc 6.6 and 6.8). Is that normal? I assume you meant -O1, not -01, in compared to -01. :) It's certainly not necessarily abnormal. It is well known that one can create situations where optimizations have a negative impact. The interesting question is, what are the characteristics of this particular application that are atypical, and thus appear to cause atypical optimization behavior? This type of situation is similar to the situation sometimes seen with multi-processor machines. In most cases, if you add processors, you get better performance. In some cases the reverse results. This is because there is some overhead to multiprocessing, and if a program is structure in such a way that parallelism is impossible, the multiprocessor overhead decreases performance and thus, for that particular application, performance is decreased. To continue the analogy, in most cases one can make minor modifications that will allow the application to use available parallelism. It is likely that small modifications to your program would allow it to take advantages of the increased optimization provided by -O2. So, as I said, it will be very interesting to discover the reason for the behavior you are experiencing. It might point to ways to make small code modifications to your application to increase performance. It might point to ways to improve the optimization. That's all premature of course. We don't know enough, to cite one quick example we don't know whether the optimization behavior is related to ghc behavior or to gcc behavior (although, of course, even if it is related to gcc behavior there could be interesting code generation issues). It would be fun to discover the details. Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface Peter. Lennart Augustsson wrote: I'd like to second that. 6.8 is quite an improvement. Well done! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: 6.8.1 compilation error - final results
For those (if any) following my latest build saga :) After install gcc 4.2.1, and dispensing with extralibs, I was able to build 6.8.1 from source. (This is on an x86 linux box running the 2.6.21 with the preemptive scheduler.) (I mention the scheduler because I have a lurking suspicion that it is related to the fact that I see more seg faults and internal compiler errors than people I've communicated with running the same kernel and compiler but the default scheduler.) I did experience one seg fault during link, near the end of the build process. I restarted the build and it completed. I'm going to run the build on one of my other Linux boxes today with the same tools (gcc 4.2.1 and ghc 6.6.1) and see if there are any linker seg faults. I've tried to eliminate my memory hardware as a factor; of course, the only way to truly eliminate hardware is to get the same behavior on more than one box. -Original Message- From: Simon Marlow [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 06, 2007 4:01 AM To: Seth Kurtzberg Cc: glasgow-haskell-users@haskell.org Subject: Re: 6.8.1 compilation error Seth Kurtzberg wrote: At this point I don't believe the problem that I reported is related to ghc, although I'm repeating things to bolster that conclusion. (As an aside, except for memory testing, the manufacturing test suite for the product I'm about to discuss is written in Haskell with just a handful of situations that required using the FFI to call C++ or C functions.) I've done memory hardware testing in manufacturing situations, and until quite recently I would have agreed with your characterization of memory testing programs. (I understand your comment was not intended to be 100% serious, but I think it's worth answering regardless.) We, of course, keep statistics about the accuracy of the manufacturing line testing. With the most recent version of memtest86, we've found the rate of false negatives to have declined dramatically, and is now in the area of 1-2%. The increased accuracy, of course, has a cost; on the current platform a single testing round takes almost four hours, and I consider three rounds to be the minimum required for thorough testing. Interesting... I might actually use memtest86 now, thanks! Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Problem compiling 6.8.1 extralibs
Run: ghc-pkg list See what it thinks about the status of happy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexis Hazell Sent: Wednesday, November 07, 2007 9:02 AM To: glasgow-haskell-users@haskell.org Subject: Problem compiling 6.8.1 extralibs Hi all, i'm having some difficulties compiling the 6.8.1 extralibs on a Mandriva 2007.0 box. Despite happy 1.15 being installed (with the happy binary in /usr/bin/), i get the following error: Preprocessing library haskell-src-1.0.1.1... Setup: The program happy is required but it could not be found make[1]: *** [haskell-src/GNUmakefile] Error 1 make[1]: Leaving directory `/usr/src/ghc-6.8.1/libraries' make: *** [stage1] Error 2 Command exited with non-zero status 2 Any suggestions as to how to fix this would be greatly appreciated. :-) Alexis. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: 6.8.1 compilation error
Simon, At this point I don't believe the problem that I reported is related to ghc, although I'm repeating things to bolster that conclusion. (As an aside, except for memory testing, the manufacturing test suite for the product I'm about to discuss is written in Haskell with just a handful of situations that required using the FFI to call C++ or C functions.) I've done memory hardware testing in manufacturing situations, and until quite recently I would have agreed with your characterization of memory testing programs. (I understand your comment was not intended to be 100% serious, but I think it's worth answering regardless.) We, of course, keep statistics about the accuracy of the manufacturing line testing. With the most recent version of memtest86, we've found the rate of false negatives to have declined dramatically, and is now in the area of 1-2%. The increased accuracy, of course, has a cost; on the current platform a single testing round takes almost four hours, and I consider three rounds to be the minimum required for thorough testing. The point is that stand-alone memory testing is no longer useless, although of course it is not perfect. Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface -Original Message- From: Simon Marlow [mailto:[EMAIL PROTECTED] Sent: Monday, November 05, 2007 6:17 AM To: Seth Kurtzberg Cc: glasgow-haskell-users@haskell.org Subject: Re: 6.8.1 compilation error Seth Kurtzberg wrote: While compiling the new release (6.8.1, with both the primary source and the extra libraries) I experienced a gcc error, gcc of course called by ghc. I'm compiling 6.8.1 with ghc 6.6.1. The gcc version is 4.1.1. I've seen similar behavior in the past where some sort of heap corruption occurs within gcc and triggers an internal compiler error. So this may not be a true ghc error at all, but one can't completely rule it out. This type of error, especially appearing at random, is suggestive of a memory hardware problem. To eliminate this possibility I ran memtest86 for several hours on the machine. No errors were detected. Dedicated memory test programs are notoriously inadequate for finding bad memory, whereas both GHC and GCC are actually quite good at it :-) I'll repeat the build again from a fresh directory to see if the problem is repeatable. Then I plan to run a build after upgrading gcc from 4.1.1 to 4.2.1. I'll report the results. Thanks, I look forward to hearing the results. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
6.8.1 compilation error
All, While compiling the new release (6.8.1, with both the primary source and the extra libraries) I experienced a gcc error, gcc of course called by ghc. I'm compiling 6.8.1 with ghc 6.6.1. The gcc version is 4.1.1. I've seen similar behavior in the past where some sort of heap corruption occurs within gcc and triggers an internal compiler error. So this may not be a true ghc error at all, but one can't completely rule it out. This type of error, especially appearing at random, is suggestive of a memory hardware problem. To eliminate this possibility I ran memtest86 for several hours on the machine. No errors were detected. I'll repeat the build again from a fresh directory to see if the problem is repeatable. Then I plan to run a build after upgrading gcc from 4.1.1 to 4.2.1. I'll report the results. The environment is Linux using kernel 2.6.21. The compilation command and the resulting error: /usr/local/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include cutils.h' -DUSING_COMPAT -i../compat -ignore-package Cabal -c rename/RnSource.lhs -o stage1/rename/RnSource.o -ohi stage1/rename/RnSource.hi /tmp/ghc1316_0/ghc1316_0.hc: In function 'raVb_entry': /tmp/ghc1316_0/ghc1316_0.hc:1983:0: internal compiler error: in referenced_var_lookup, at tree-dfa.c:578 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. ghc: 586234044 bytes, 718 GCs, 10149393/21203304 avg/max bytes residency (9 samples), 55M in use, 0.02 INIT (0.00 elapsed), 6.94 MUT (27.32 elapsed), 3.53 GC (3.67 elapsed) :ghc make[1]: *** [stage1/rename/RnSource.o] Error 1 make: *** [stage1] Error 1 Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Case of Language pragma - bug?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robin Bate
Boerop
Sent: Tuesday, October 30, 2007 3:14 PM
To: glasgow-haskell-users@haskell.org
Subject: Case of Language pragma - bug?
I'm using GHC 6.6.1. The manual says:
Pragmas all take the form {-# word ... #-} where word indicates the type of
pragma, and is followed optionally by information specific to that type of
pragma. Case is ignored in word.
However, when I use Language CPP instead of LANGUAGE CPP in the pragma,
the pragma is ignored. Is this a documentation bug?
The interesting question is which way it should work. Obviously the
documentation should match the code, but it isn't obvious (at least to me)
whether it's better to modify the documentation or to change the behavior of
the code.
Is the behavior the same in the latest ghc release?
Seth Kurtzberg
Software Engineer
Specializing in Security, Reliability, and the Hardware/Software Interface
To test the problem, one can use ghc --make testpragma1.hs and ghc --make
testpragma2.hs on the following:
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Qualified identifiers opinion
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan O'Rear Sent: Friday, August 17, 2007 2:45 PM To: Christian Maeder Cc: Haskell Prime; GHC Users Mailing List; Isaac Dupree Subject: Re: Qualified identifiers opinion On Fri, Aug 17, 2007 at 12:53:11PM +0200, Christian Maeder wrote: Hi Isaac, just to give you a reply at all, see below. I reply glasgow-haskell-users@haskell.org since I'm not subscribed to haskell-prime. And I don't want to subscribe, because I'm more interested that Haskell becomes more stable (and standard). So here is my opinion: 1. The lexer should recognize keywords. 2. I would not mind if Haskel98 rejected all keywords that are also rejected by extensions, so that the lexer is extension independent. (Starting with Haskell98, removing conflicting identifiers as soon as I switch on valuable extensions does not make sense.) 3. I'm against qualified identifiers, with the unqualified part being a keyword like Foo.where. (The choice of qualification should be left to the user, usually one is not forced to used qualified names.) 4. However, Foo.where should always be rejected and not changed to Foo.wher e! (Longest matching, aka maximal munch, must not consider keywords!) (see end of: http://www.haskell.org/onlinelibrary/lexemes.html#sect2.4) I would not mind if a name F. is plainly rejected. It only makes sense, when a data constructor is the first argument of the composition operator (.) Maybe . and $ as operators should require white spaces on both sides, since $( also indicates template haskell. What's wrong with the status quo? Our current lexical rules *seem* complicated to newbies, but just like everything else in Haskell it carries a deep simplicity; having only one rule (maximal-munch) gives a certain elegance that the proposals all lack. I'd hate to see Haskell become complex all the way down just to fix a few corner cases; I see this pattern of simplicity degerating through well-intentioned attempts to fix things all over the language... Stefan I agree with Stefan, for the reasons he stated and for one additional reason: There would be a multitude of unintended behavior changes. Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Visual Haskell will not Install with Visual Studio 2005, Express Edition
It won't install with the full edition either. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Esa Ilari Vuokko Sent: Sunday, August 12, 2007 6:22 PM To: Sean Johnson Cc: [EMAIL PROTECTED]; glasgow-haskell-users@haskell.org Subject: Re: Visual Haskell will not Install with Visual Studio 2005, Express Edition Hi, On 7/27/07, Sean Johnson [EMAIL PROTECTED] wrote: Is there some way to install Visual Haskell with VS2005, Express? Perhaps some workaround or hack? It's probably impossible. Feature matrix for Visual Studio products says Use 3rd party controls and content. No Macros, Add-ins or Packages. [1] Best regards, Esa [1] http://msdn2.microsoft.com/en-us/vstudio/aa700921.aspx ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Visual Haskell will not Install with Visual Studio 2005, Express Edition
I was not aware of the Eclipse support, so thanks for that information. However, Visual Haskell will not install on the full version of Visual Studio 2005 either. To make sure this was not an issue specific to my installation, I completely wiped a disk, installed Windows, installed Visual Studio 2005, and then attempted to install Visual Haskell. A fatal error occurs near the end of the install. I don't have the error text in front of me, but I'll send an email tomorrow when I'll have access to it. Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Duncan Coutts Sent: Sunday, August 12, 2007 6:34 PM To: Sean Johnson Cc: [EMAIL PROTECTED]; glasgow-haskell-users@haskell.org Subject: Re: Visual Haskell will not Install with Visual Studio 2005, Express Edition On Thu, 2007-07-26 at 23:51 -0700, Sean Johnson wrote: Hi Everyone, Is there some way to install Visual Haskell with VS2005, Express? Perhaps some workaround or hack? I believe that free version of VS is specifically designed not to allow any plugins, you have to pay for the the full version for that sadly. As a free alternative, emacs and eclipse have Haskell modes and many other editors have Haskell syntax highlighting. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: *****SPAM***** Annotation for unfolding wanted
Anybody know what spam detection program is producing this absurd result, so I can make sure I never even think about using it? It's the second such email in two (or possibly three) days. The potential of Bayesian filtering is vastly overstated, but this one has to be a bug or usage error of some sort. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Georg Martius Sent: Sunday, July 29, 2007 6:21 AM To: glasgow-haskell-users@haskell.org Subject: *SPAM* Annotation for unfolding wanted Spam detection software, running on the system h7568.serverkompetenz.net, has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi Tim, thanks for the hint, but I tried this without success. My point is, that I don't want to try a pragma and see whether it works. I would like to specify the requirement that a function has to be in constant space and if it cannot be done, that the program should not compile. Would it be complicated to include in the compiler? [...] Content analysis details: (7.4 points, 5.0 required) pts rule name description -- -- 0.1 FORGED_RCVD_HELO Received: contains a forged HELO 3.0 BAYES_95 BODY: Bayesian spam probability is 95 to 99% [score: 0.9674] 1.9 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP [87.172.161.188 listed in combined.njabl.org] 2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [87.172.161.188 listed in dnsbl.sorbs.net] 0.2 AWLAWL: From: address is in the auto white-list ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Feature proposal: ghc --full-flag-help ?
No disagreement; the text man page should also be a file in the distribution with a name that suggests its contents. On Wed, 14 Mar 2007 11:18:20 + Simon Marlow [EMAIL PROTECTED] wrote: Marc Weber wrote: On Tue, Mar 13, 2007 at 01:57:10PM +0100, Marc Weber wrote: Hi I did notice a lot of times that I just didn't remember the name of option X. How to look it up? Walk through html or pdf documentation? Just printing a link to ghc online docs is not enough because: * maybe no internet availible * internet slow? * You still need to search/ scroll (too much effort) * getting help on flags is default behaviour of any linux application and most haskell developers are working on this os I think. Have you ever tried info bash, info grep, info whatsoever and got the result please visit http:// .. ? That's like invoking ghc printing This is only a fake. Please execute realghc instead I'd love to implement this. But I might need some time. I already know where to start (hacking on ghc intro on the ghc documentation site .. ;-) How should it look like? We already have support for man pages, I think we should try to avoid duplication here. If your GHC man page is installed correctly, then 'man ghc' should give you a nice consise list of options (see attached file, and scripts in docs/man in a GHC tree). So I think if we are to have a 'ghc --full-help' then it should just output the man page, as Ketil suggested. But we should make this work and output the correct man page regardless of whether 'man ghc' works, because you might have multiple GHC versions installed, and/or the system might not even have a man command (Windows). So every GHC installation should include a text version of the man page, that should be fairly easy to arrange. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: scripts on unix
I compile the programs, instead of trying to run them as scripts. Is there any reason you prefer to interpret the scripts? I'm not saying it's not a legitimate thing to do, just wondering why you prefer to do it that way. Seth Kurtzberg On Wed, 14 Mar 2007 19:31:55 + Frederik Eaton [EMAIL PROTECTED] wrote: Hello, What is the proper technique for creating a Haskell script on a Unix system? e.g. with Perl I do #!/bin/sh echo DEFANGED.348224 exit #!/usr/bin/env perl print hello world\n; or #!/usr/bin/perl print hello world\n; I tried $ cat test #!/usr/bin/env runhaskell module Main where main = do putStrLn hello world But that doesn't work: $ ./test Warning: ignoring unrecognised input `./test' interactive:1:73: Failed to load interface for `Main': Use -v to see a list of the files searched for. When I use runghc I get the same error. If I change the first line to -x hs then the error is: ghc-6.6: unrecognised flags: -x hs Usage: For basic information, try the `--help' option. because the #! mechanism only allows a single argument. Thoughts? Thanks, Frederik -- http://ofb.net/~frederik/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unsafePerformIO safety.
On Tue, 06 Mar 2007 12:03:05 -0800 David Brown [EMAIL PROTECTED] wrote: I've noticed quite a few pages referencing constructs such as: var :: MVar ([Foo]) var = unsafePerformIO (newMVar ([])) and the likes. Is there a danger of different uses of 'var' getting new MVars instead of all sharing one. Having a reliable way to create a piece of global state would be very convenient. This operation is unsafe by definition. I use it extensively, without problems. The unsafe in the name reminds you that there are situations for which the function is inappropriate, but all of my deployed commercial programs have functionality of this sort. Understand the risk, but don't hesitate to use it. Seth Kurtzberg Dave ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Become a GHC build slave!
I'm joining this discussion a bit late, but ... I can provide a build machines for netbsd and freebsd. I didn't see those on the URL cited below. They are fairly common, so perhaps I just missed them. In any event, if netbsd and/or freebsd will be helpful, please let me know. Seth Kurtzberg On Mon, 05 Feb 2007 15:28:15 + Simon Marlow [EMAIL PROTECTED] wrote: Neil Mitchell wrote: Hi Simon, Thanks largely to Ian Lynagh, GHC now has a BuildBot infrastructure to automate nightly builds on multiple platforms. This replaces the old set of shell scripts that we used to run nightly builds; now adding new clients to the setup is relatively easy, instructions are here: http://hackage.haskell.org/trac/ghc/wiki/BuildBot Good news! Do you have any idea of how much time a build might take roughly? It depends how much you want to do: as a rough guide, our really-do-everything builds take about 8 hours on a fast machine, that includes - 3 compiler stages (only 2 are necessary, the 3rd is a sanity check) - the extra libraries - all libraries built for profiling and unregisterised - split objects - a full testsuite run, in all the supported ways - 5 runs of the nofib benchmark suite, with various flag settings - build upload distributions We can do a fast build in much less time: probably about 1 hour for - 2 compiler stages - core libraries only - no profiled libraries - no split objects - a fast testsuite run - no benchmarks You tell us how much time you have, we can keep your machine busy :-) As a second point, the Yhc team do a variety of builds - some from clean, some from fullclean, some from delete the directory and a completely fresh darcs pull etc. We've found that can help catch things like interface changes, dependancies etc earlier. If you have (or can find) too many Windows/Linux machines etc that might be worth doing - and is pretty easy with buildbot. All our builds start with a fresh checkout right now. There are certainly things that can go wrong if you don't fully clean the tree and re-configure after updates (e.g. modifications to the configure.ac files), so I'm not sure it would be useful to start from an partially-clean tree. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: seq vs. pseq
On Mon, November 6, 2006 9:21 am, Ross Paterson wrote: On Mon, Nov 06, 2006 at 01:53:52PM +, Malcolm Wallace wrote: So the doubly bizarre thing is that, actually, `seq` does not control the evaluation order (which is the only valid reason for wanting to use it in the first place), but nevertheless it undesirably changes the semantics of programs such that equational reasoning no longer holds. When I've used seq, it's to ensure that a function is strict in that argument, and therefore has been evaluated before the function is called. (If the language had unlifted types, I might have used those instead). Beyond that, I don't care exactly when it was evaluated; it might be long before, thanks to propagation of strictness information. seq has a clear denotational semantics. One can still do equational reasoning with it, though there will be side conditions about whether something is _|_ or not. The downside is that the eta rules get such side conditions, and polymorphic seq greatly weakens parametricity. Apart from that, the only thing wrong with seq is its name. What would be the correct way to get the effect that he expected from seq? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Seth Kurtzberg [EMAIL PROTECTED] Software Engineer Specializing in Reliability and Security ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsman
On Mon, 6 Nov 2006 21:32:39 -0600 Quan Ta [EMAIL PROTECTED] wrote: how about searching code that's outside of the standard library? Hoogle doesn't seem to know about HaXml, or haskelldb for example (maybe I am missing something obvious) You want to distinguish between capabilities, and the fact that the database for hoogle may not include all the data that is available. If the issue is only the availability of the data, perhaps the best option is to add the data to hoogle. Quan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: [Hugs-users] Record puns, time for removal?
On Tue, 31 Oct 2006 13:59:45 +0300
Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello Neil,
Tuesday, October 31, 2006, 4:04:23 AM, you wrote:
puns like Foo { .. } would be great too.
I'd vote for enabling them with a command line switch, rather than by
default, as they can be confusing to folks learning the language.
How discussions come full circle :) I started this discussion on the
Hugs users list because I want to _remove_ the command line switch for
puns from Yhc. I'm not overly fussed whether I remove the entire
feature, or just remove the command line and make it always on by
default, but I do want the command line switch gone!
compiler switch can't be made a part of Haskell' :)
and anyway, i don't see how cmdline switch may help noivices - when
they use .. by mistake and program mysteriously not fails? or when
they stare at the other's program and understand that this unknown
.. work only because this program compiled with some special switch?
I wasn't talking about the .., I was talking about the primary issue raised by
the email, which has nothing to do with ..
Instead of assuming that I was saying something totally useless and worthless,
it might not be a bad idea to respond to _my_ email, not an email which
contains a quote of one line from my email.
and yes, record puns seems very ggod candidate for H'. it's widely
used (i used it until switched to GHC), it was already in Haskell, and
now it is impelemnted by every compiler
wildcard puns is more discussible, but i personally need this feature
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: [Hugs-users] Record puns, time for removal?
On Tue, 31 Oct 2006 11:06:01 -0800
Iavor Diatchki [EMAIL PROTECTED] wrote:
Hello,
I think the it may be confusing to novices argument tends to be
over-used and we should be careful before we make language decisions
solely based on it. At the very least, when there is a suggestion
that something might be confusing to someone, there should be an
explanation of what/why/to whom it is confusing.
I don't disagree at all. I'm not suggesting that the confusion issue should
have any impact at all on decisions about the language.
I was only talking about whether the pun feature should be accepted by default,
or require an -fwhatever. I don't see this as being different than, say,
-fglasgow-exts.
Or, perhaps, it should simply be one of the glasgow extensions.
As to why it might be confusing, I realize this is extremely subjective.
Suppose you have a record type, and add a constructor to it. As things stand,
I can use the compiler to be certain that I've found all areas of the code that
require changes because of the addition of the constructor (with the flag that
tells gcc to find non-exhaustive pattern matches). Using the compiler in this
manner is (IMO) one of the things that makes refactering in Haskell so much
easier than some other languages.
OK, now, if the pun feature is on, it's no longer illegal to provide processing
for only one constructor. (That's not the only thing it does, but that is one
thing that it does.)
Seth
I think record puns are a nice feature, it is easy to explain, and
without them the Haskell record system is less useful, at least to me.
By the way, if I recall correctly, in Johan Nordlander's O'Hugs the ..
notation (called record packing, I think) could also be used to create
record values. I think it worked like this:
data Point = Point { x,y :: Int }
pt = let { x = 3; y = 4 } in Point { .. }
The .. is expanded to {x = x, y = y} based on the fields for the
particular constructor. It seems that if we have the Point { .. }
pattern, we should also have the constructor version. What do people
think?
-Iavor
On 10/31/06, Seth Kurtzberg [EMAIL PROTECTED] wrote:
On Tue, 31 Oct 2006 13:59:45 +0300
Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello Neil,
Tuesday, October 31, 2006, 4:04:23 AM, you wrote:
puns like Foo { .. } would be great too.
I'd vote for enabling them with a command line switch, rather than by
default, as they can be confusing to folks learning the language.
How discussions come full circle :) I started this discussion on the
Hugs users list because I want to _remove_ the command line switch for
puns from Yhc. I'm not overly fussed whether I remove the entire
feature, or just remove the command line and make it always on by
default, but I do want the command line switch gone!
compiler switch can't be made a part of Haskell' :)
and anyway, i don't see how cmdline switch may help noivices - when
they use .. by mistake and program mysteriously not fails? or when
they stare at the other's program and understand that this unknown
.. work only because this program compiled with some special switch?
I wasn't talking about the .., I was talking about the primary issue raised
by the email, which has nothing to do with ..
Instead of assuming that I was saying something totally useless and
worthless, it might not be a bad idea to respond to _my_ email, not an
email which contains a quote of one line from my email.
and yes, record puns seems very ggod candidate for H'. it's widely
used (i used it until switched to GHC), it was already in Haskell, and
now it is impelemnted by every compiler
wildcard puns is more discussible, but i personally need this feature
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Hugs-users] Record puns, time for removal?
On Mon, 30 Oct 2006 16:30:42 -0800
John Meacham [EMAIL PROTECTED] wrote:
On Mon, Oct 30, 2006 at 12:11:23PM -, Simon Peyton-Jones wrote:
I always thought it was a mistake to remove record puns in H98. I would
not be against re-introducing them into GHC, since they appear to remain
in Hugs and are in Yhc.
yes. jhc has them too and I wish ghc did.
puns like Foo { .. } would be great too.
I'd vote for enabling them with a command line switch, rather than by default,
as they can be confusing to folks learning the language.
Seth
I made this page on the wiki to record fixes to the record system:
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/ExistingRecords
most would be pretty straightforward to implement.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: threadDelay not ending
What is your environment? My project (which is about 70% Haskell) makes extensive use of threadDelay. I've not seen this behavior with 6.4.2. My environment is Linux using a recent 2.6 kernel. For obvious reasons I need to know whether there is a threadDelay issue here that is preparing to bite me. Seth Kurtzberg On Mon, September 18, 2006 7:23 am, Rich Fought wrote: I've got some unit test code that forks off test processes using the 'system' function and then delays using 'threadDelay' to synchronize with the test process. This has worked fine until I upgraded to 6.4.2, now some of the 'threadDelay' calls never return - it's like they are stuck in limbo. Any ideas? What would have changed between 6.4 and 6.4.2 that would cause this behavior? Thanks, Rich ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Seth Kurtzberg [EMAIL PROTECTED] Software Engineer Specializing in Reliability and Security ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: threadDelay not ending
On Mon, 18 Sep 2006 11:56:21 -0500 Rich Fought [EMAIL PROTECTED] wrote: I am running on Red Hat Enterprise Linux with the latest RH 2.6 kernel. This is very bizarre and I am having a hard time figuring out what is going on. I don't see any issues in the project code itself, just my unit tests. Rich, I'm having trouble coming up with even a credible theory of what might be happening. I can't come up with any theory, no matter how far fetched, that would account for things working with 6.4.1 and not working with 6.4.2. If there is anything I can do to help you narrow this down, let me know. Seth Rich Seth Kurtzberg wrote: What is your environment? My project (which is about 70% Haskell) makes extensive use of threadDelay. I've not seen this behavior with 6.4.2. My environment is Linux using a recent 2.6 kernel. For obvious reasons I need to know whether there is a threadDelay issue here that is preparing to bite me. Seth Kurtzberg On Mon, September 18, 2006 7:23 am, Rich Fought wrote: I've got some unit test code that forks off test processes using the 'system' function and then delays using 'threadDelay' to synchronize with the test process. This has worked fine until I upgraded to 6.4.2, now some of the 'threadDelay' calls never return - it's like they are stuck in limbo. Any ideas? What would have changed between 6.4 and 6.4.2 that would cause this behavior? Thanks, Rich ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: can not find prelude module
If you repeat the make install step, things should work again. On Fri, 18 Aug 2006 09:59:31 -0700 (PDT) Liang Guang [EMAIL PROTECTED] wrote: I originally used Redhat9.0, and the compilation is fine. But now I switched to Fedora 5, the compiler said it can not find prelude module! I used Yum to install the ghc-6.4.2, and it is put to into /usr/lib/ghc-6.4.2. I tried to add the directory to the makefile as : GHC_OPTS = -O2 -prof -auto-all -i../src:/usr/lib/ghc-6.4.2/ I also tried GHC_OPTS = -O2 -prof -auto-all -i../src:/usr/lib/ghc-6.4.2/imports but they didn't work. I am quite confused, isn't it that the base library(like prelude module) should be included in the search path by default? How can I deal with the problem? Thanks! TOm - Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X and OpenSSL
On Sat, 29 Jul 2006 21:45:21 -0400 [EMAIL PROTECTED] wrote: GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum library, BN. I have two questions concerning this: (1) Why not use the ARbitrary PRECision Computation Package (ARPREC) by David Bailey, Yozo Hida, Karthik Jeyabalan, Xiaoye Li and Brandon Thompson? Here is a reference web page: http://crd.lbl.gov/~dhbailey/mpdist/ ARPREC is written in C++ but supports calls from C (see include/arprec/c_mp.h in the distribution directory). ARPREC is very fast and supports more complex mathematics than BN. The Licensing for ARPREC is not a problem: essentially similar to BSD3. Note that there would be a basic configuration fix for building OpenSSL's BN library on OS 10.4: you would probably--I had to, myself--have to temporarily move the default installation of /usr/lib/libssl0.9.dylib (and variants) if you want to create a shared (.a) library because Apple's ln links dynamic libraries in preference to shared libraries. I think you meant if you want to create a static (.a) library, not if you want to create a shared (.a) library Those of you who have some experience with Apple's gcc also know that Apple's gcc does not recognise the -shared flag. (2) A much more aesthetic solution would be to replace any external Bignum library with a pure Haskell library. There are many problems with building a truly efficient and fast Bignum library in Haskell but challenges like that are how languages evolve... -Peter Tanski ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.3 is stalled
If it turns out that there is a freebsd issue, I can help with that. Possibly also with OSX. Seth On Tue, 25 Jul 2006 11:50:58 +0100 Simon Peyton-Jones [EMAIL PROTECTED] wrote: Folks GHC 6.4.2's threaded runtime system does not work right on Solaris MacOSX Possibly FreeBSD We'd love to fix these bugs and release 6.4.3, but we are stalled because we don't have easy access to these platforms, nor do we have detailed expertise in their intimate details (which is where the bugs will be lurking). If you care about these platforms, would you like to lend a hand? We probably need more help than simply here's access to the platform, but we'd give you very strong support if you were willing to look into it. Failing that, I think we'll have to stick with 6.4.2. (And the same bugs may well show up in GHC 6.6, which we hope to release before ICFP.) Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: about threads (here: increasing thread IDs)
Jost, At the moment I am only using the thread ID in trace messages, so if I can safely ignore the overflow, then I will so. Seth On Wed, 21 Jun 2006 10:28:43 +0200 Jost Berthold [EMAIL PROTECTED] wrote: Hi Seth, perhaps this will help you, some information from the implementation side concerning your question about threadIDs: Related code lived in rts/Schedule.c, has recently moved to rts/Threads.* in the head. The ThreadID assigned by the RTS is continuously increasing, and declared to be StgInt32 (32 bits usually). So you might get int overflows when running your server for a *fairly* long time. OTOH, depending on what you want to do with the ThreadIDs that forkIO returns, IMHO you could just *ignore* these overflows. From your short description of how the servers work, you know an upper bound on the no. of running threads (6), but not on their time to live. So IMHO the worst case scenario would be: a new thread for a client gets ID n ... 2^32 other server threads get spawned another new thread for a client gets the same ID n again ... one of the threads supposed to terminate (killThread n) AFAICT, the killThread action will arbitrarily choose one of the two. HTH Jost -- you wrote -- Date: Tue, 20 Jun 2006 23:22:26 -0400 From: Seth Kurtzberg [EMAIL PROTECTED] Subject: Re: FFI: number of worker threads? To: Li, Peng [EMAIL PROTECTED] Cc: glasgow-haskell-users@haskell.org Another related question. I have some threaded applications running which are servers and run continuously. A thread is spawned for each new connection, and the thread exits when the client terminates. I've noticed that the thread ID increases. On one process I checked today I am up to thread number 3300. The number of running threads is not increasing; only six threads are running on this particular process. The threads are cleaned up and exit. The thread _ID_ is continually increasing. Is this going to cause a problem when the thread ID exceeds some value? Do I have to force the server process to recycle periodically? ... ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI: number of worker threads?
Simon, Thanks for the response. The doc I was referring to is the library haddock doc for Control.Concurrent. Seth On Wed, 21 Jun 2006 12:41:52 +0100 Simon Marlow [EMAIL PROTECTED] wrote: Seth Kurtzberg wrote: I have a related question. The docs state that in some environments O/S threads are used when the -threaded flag is used with ghc, and non-O/S threads are used otherwise (presumably these are non-preemptive). Does this apply as well to the worker threads that are the subject of this email? It sounds like the docs are a bit unclear. Which bit of doc in particular are you referring to? forkIO always creates a lightweight thread. With -threaded, if a thread makes a safe foreign call, then that call might execute concurrently with other threads, because another OS thread (a worker thread) takes over in the runtime. In the HEAD (which will be 6.6), we now allow multiple OS threads in the runtime, so you also get to run multiple Haskell threads simultaneously, which is particularly useful if you have more than one CPU. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI: number of worker threads?
Simon, Thanks for the info. I don't compare thread IDs. At the moment I merely print out the thread ID in a trace message. Shortly I will be using the thread ID when a need arises to kill a thread. It sounds like the rollover is harmless for these situations. When you talk about comparing thread IDs, are you thinking that one might compare two thread IDs to see which one is more recently spawned? I can see where you might have a situation where you would compare thread IDs to determine whether two somehow related values belong in some sense to the same thread. I'm curious about why one might compare thread IDs in such a way that the rollover would cause the comparison to produce the wrong answer. Seth On Wed, 21 Jun 2006 12:48:42 +0100 Simon Marlow [EMAIL PROTECTED] wrote: Seth Kurtzberg wrote: Another related question. I have some threaded applications running which are servers and run continuously. A thread is spawned for each new connection, and the thread exits when the client terminates. I've noticed that the thread ID increases. On one process I checked today I am up to thread number 3300. The number of running threads is not increasing; only six threads are running on this particular process. The threads are cleaned up and exit. The thread _ID_ is continually increasing. Is this going to cause a problem when the thread ID exceeds some value? Do I have to force the server process to recycle periodically? These processes are designed to run continuously, and are running in a fairly demanding commercial environment for extended periods of time. They have proven to be very stable and reliable. I'm hopeful that it will not be necessary to recycle to force the thread ID to restart. The thread ID assigned to new threads will wrap around when it reaches 2147483647. In 6.6 we made thread IDs 64 bits, so you get a bit longer before they wrap around. Even if you manage to wrap the thread ID, it'll only be a problem if you actually compare ThreadIDs. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI: number of worker threads?
Another related question. I have some threaded applications running which are servers and run continuously. A thread is spawned for each new connection, and the thread exits when the client terminates. I've noticed that the thread ID increases. On one process I checked today I am up to thread number 3300. The number of running threads is not increasing; only six threads are running on this particular process. The threads are cleaned up and exit. The thread _ID_ is continually increasing. Is this going to cause a problem when the thread ID exceeds some value? Do I have to force the server process to recycle periodically? These processes are designed to run continuously, and are running in a fairly demanding commercial environment for extended periods of time. They have proven to be very stable and reliable. I'm hopeful that it will not be necessary to recycle to force the thread ID to restart. Seth On Tue, 20 Jun 2006 22:57:17 -0400 Li, Peng [EMAIL PROTECTED] wrote: Hello, The paper Extending the Haskell FFI with Concurrency mentioned the following in Section 6.3: GHC's run-time system employs one OS thread for every bound thread; additionally, there is a variable number of so-called worker OS threads that are used to execute the unbounded (lightweight) threads. How does the runtime system determine the number of worker threads? Is the number hardcoded in the RTS or dynamically adjustable? Can a programmer specify it as an RTS option or change it using an API? I would like to use a large number (say, 2000) of unbounded threads, each calling a blocking, safe foreign function via FFI import. What is supposed to happen if all the worker threads are used up? I tried this in the recent GHC 6.5 and got some kind of runaway worker threads? RTS failure message when more than 32 threads are used. Is it a current limitation of the RTS, or should I file a bug report for it? Thanks, Peng ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Failed to load interface for ...
How about changing it so --make is the default? I always use it. To me, that makes it logical as the default. Of course there are reasons not to do this, such as not breaking peoples build scripts, and no doubt others I'm overlooking at the moment. A flag to select the old behavior would take care of the build script problem, especially if it were also possible to use an environment variable (instead of, or perhaps available in addition to, a command line flag) to select the old behavior. (It isn't old, obviously, but I'm sure everyone knows what I mean.) Seth Kurtzberg On Fri, 6 Jan 2006 13:54:26 +0300 Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello , how about adding suggestion to use --make to the following error message? it would be very helpful for novices. i have run into this problem several times before memoized that suggestion to use -v actually means that i forgot to add --make :) C:\!\Haskell\cpphs ghc -O2 Main.hs Main.hs:17:0: Failed to load interface for `RunCpphs': Could not find module `RunCpphs': use -v to see a list of the files searched for -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Optimizations for mutable structures?
On Thu, 2005-12-08 at 09:40 +, Simon Marlow wrote:
On 07 December 2005 19:57, Claus Reinke wrote:
there seem to be two issues here - can we agree on that at least?
1) scheduling non-sequential programs on sequential processors
i wasn't arguing that the scheduler should realise all possible
interleavings at once. the issue i was referring to is known as
fairness in concurrent systems literature. as with referential
transparency, various non-equivalent definitions are in use,
but one informal description might be something like:
if, for a given experiment, some event is possible according to
the semantics, it should happen eventually if the experiment is
repeated often enough.
see, eg,
http://research.microsoft.com/users/lamport/pubs/pubs.html#lamport-fairn
ess
Yes, good point. Regarding fairness, I've been working with the
assumption that we don't need to preserve (certain kinds of) fairness
properties when performing optimisations, whereas you and others want to
preserve all fairness.
Why don't I care about preserving fairness? Well you said it - it's not
practical to implement. And since the implementation already doesn't
guarantee strong fairness (or whatever it's called), it doesn't do any
harm to weaken the fairness that we do provide, because programmers
can't rely on strong fairness anyway. In practical terms, you won't
notice the difference.
Furthermore, I'd go so far as to say that a program that relies on the
kind of fairness we've been talking about (arbitrary interleaving) for
correctness or termination, is broken.
We ceratinly *do* care about some kind of fairness. The property that
we try to maintain is something like this:
If a thread is unblocked according to the semantics, then the
implementation ensures that it runs after a finite time.
This is the context in which I've always seen the term fairness applied,
to wit, w.r.t thread starvation, livelock, etc.
Fairness certainly isn't a requirement for correctness. This is not to
say it isn't desirable or important, although I'd argue that it is less
important than correctness. Perhaps it would be better to say that if
the program isn't correct, its performance w.r.t. fairness is
irrelevant.
The fundamental requirement is the same for all languages, I believe;
the concurrently executing threads must produce a system state that is
identical to _one_ system state which would be produced by running the
threads sequentially. It is easy to show that to even enumerate all the
possible sequences is NP-complete. Beyond the requirement of
serializability, there is no practical alternative to a dose of human
intelligence. At least people coding in Haskell have an understanding
of the underlying issues. Alas, this is far from true for even
experiences coders of imperative languages.
Seth
I'm not familiar with the fairness literature, perhaps this property is
known?
You may well call our implementation incomplete because it doesn't
implement full fairness. I don't think that's useful though; I'd much
rather characterise exactly what fairness property we can and do
implement, and use that for reasoning with.
[snip]
2) compiler optimisation validity in sequential and non-sequential
environments
the original motivation of this thread - are sequential
transformations still valid in a non-sequential setting?
in general, the answer is no, to the surprise/annoyance of many many
compiler implementors who want their valuable optimisations to work
even when their sequential language acquires threads.
I don't think this applies in our setting. The reason we have IORef and
{M,T}Vars, and not just a single mutable reference type, is that
{M,T}Vars provide strong consistency guarantees when used to communicate
between threads, whereas IORefs do not. Hence, IORefs can be
implemented with much fewer restrictions.
If you share IORefs between threads and run on a multiprocessor, you are
at the mercy of both sequential optimisations and your architecture's
memory consistency guarantees. In other words, don't do it. Use
communication primitives that have strong properties in a multi-threaded
setting.
i'd really, really prefer concurrent haskell not to go down a route
in which demands of simpler implementation leads to subtle problems
in reasoning about programs.
If you think any of this impacts your ability to reason about programs,
please elaborate - I don't think it does.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: #!... (Re[2]: cabal configure screw-up)
Frederik Eaton wrote: But it isn't running "in a unix emulation environment." cygwin is simply _not_ such an environment. The program is started by a different shell, but that is _not_ an emulation environment. Is it an elephant? A tree? I guess the most accurate way to describe it is that it tries to emulate the _development_ environment of UNIX. It has gnu make and various other utilities and shells compiled to run under win32. So you can build things that rely on shell scripts, because the shell scripts are executed by either (1) a shell, which knows the conventions about how to execute scripts or (2) the make utility, which similarly has been forced to behave such that makefiles that rely on scripting still work. This does not, unfortunately, extend to the run time environment. That's why I said it isn't an emulation environment. A program that is executing is not different in any way from any other native win32 program that is executing. A program could be set up to check whether it was started from a UNIX like shell, by querying it's parent process, but obviously this has problems. O/S functions, such as the ones that allow one process to execute another process, are unmodified. There is no library that intersperses itself between the process and the O/S. So there is really no way to change the O/S behavior, specifically with regard to running scripts, but more generally in any way. Frederik ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Making Windows executables...
Juan Carlos Arevalo Baeza wrote: Thanx! That's exactly what I needed. The swhich was undocumented! :-P :-) I understand the caveats well enough. You can avoid the exceptions very easily using this code: ---8-- import Foreign.C.Types import Foreign.C.String foreign import ccall unsafe HsBase.h __hscore_open c_open :: CString - CInt - CInt - IO CInt foreign import ccall unsafe HsBase.h dup2 dup2 :: CInt - CInt - IO CInt open fname oflag pmode = withCString fname $ \c_fname - c_open c_fname oflag pmode main = fd - open nul 2 0 dup2 fd 0 dup2 fd 1 dup2 fd 2 I guess Windows can make even Haskell programs look ugly. Or at the very least esthetically unpleasing. :) ... rest of the program goes here. ---8-- Suggestion for somebody: maybe we should add this (or something such) as standard to the next version of GHC. I mean a proper switch (--mk-gui or something such) and somehow setting the standard handles like above when it's invoked. JCAB Duncan Coutts wrote: On Sat, 2005-08-27 at 13:42 -0700, Juan Carlos Arevalo Baeza wrote: When compiling a haskell program under Windows, is there any way to compile it as a GUI program instead of a console program? Yes, see the following FAQ from Gtk2Hs: http://haskell.org/gtk2hs/archives/2005/06/23/hiding-the-console-on-windows/ and do make sure you understand the caveats. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Performance on amd64
John Skaller wrote: On Tue, 2005-07-05 at 17:08 +0100, Simon Marlow wrote: Thanks, downloading it now.. will try. What exactly is a 'registered' build? An unregisterised build generates plain C which is compiled with a C compiler. The term registerised refers to a set of optimisations which require post-processing the assembly generated by the C compiler using a Perl script (affectionately known as the Evil Mangler). In particular, registerised code does real tail-calls and uses real machine registers to store the Hsakell stack and heap pointers. Ah! So 'register' refers to machine registers .. not some certification by some kind of authority, which is what I guessed .. ? Sure, it's good to look at these small benchmarks to improve aspects of our compilers, but we should never claim that results on microbenchmarks are in any way an indicator of performance on programs that people actually write. One can also argue that 'programmer performance' is important, not just machine performance. Absolutely. In some limited testing, I found that the penalty for poor programmer performance (I think I'll adopt that phrase) is much higher for Haskell code than for C code. ghc can mitigate, but not eliminate, this problem. Of course the compiler for an imperative language has much less work to do, and the path to machine code from the high level language source code in a language such as C is more evident. When the final product of a compiler has a less obvious relationship to the input to the compiler, it is correspondingly more difficult for the programmer to discover better compiler input. I measured performance differences due to the discovery (or lack of discovery) of an optimization as high as an order of magnitude with ghc. C (I tested with gcc and with Microsoft's compiler) has a much lower penalty for poor coding. In an age of cheap hardware, one can throw money at a poorly coded C program and fix its performance; in fact a good argument can often be made that this is the correct decision as the total cost (of hardware plus software development and maintenance) may be lower, compared with the costs of putting more time and effort into coding. With Haskell the same tradeoff has a much different result. Program performance is unlikely to be acceptable if programmer performance is poor. You can throw hardware at a poorly written program when the program runs half as fast as it should; you can't compensate (at least not cost effectively) for a program that runs an order of magnitude more slowly because of poor programmer performance. The shootout has lots of good benchmarks, for sure. I'm not so sure ;( Don't restrict yourself to the small programs, though. Of course, larger more complex programs may give interesting performance results, but have one significant drawback: a lot more work is required to write them. It's still hard to get a big picture from the results - there are too many variables. I believe many of the Haskell programs in the suite can go several times faster with the right tweaks, and using the right libraries (such as a decent PackedString library). Maybe I'm asking the wrong question. Can you think of a computation which you believe Haskell would be the best at? .. and while you're at it: a computation GHC does NOT handle well -- IMHO these are actually most useful to compiler writers. If programmer performance is the most significant factor (as I believe it is), then it isn't quite accurate to say that ghc can't handle a particular computation. What ghc cannot handle well is poor code. It isn't clear that any optimizer is capable of compensating for seriously stupid coding. It's not clear to me that the compiler should even try, although you can certainly make an argument that Haskell would be more widely used if poor programmer performance were well tolerated. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: using the Intel compiler (icc)
Keean Schupke wrote: Is it possible to get GCC to use the intel C compiler (ICC) instead of gcc? Do you mean is it possible to get GHC to use ICC? Otherwise I don't understand the question. Keean. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: explicit signatures and default for integer literals
Dinko Tenev wrote: On 5/31/05, Daniel Fischer [EMAIL PROTECTED] wrote: Why is ghc unable the determine the type of the Literal 0 in the definition of g? Answer: Since somewhere an instance e.g. New [(a,Double)] (Map a Int) could be defined, leading to problems when threating 0 as (0::Int). There could be such an instance, but that's obviously not the case. At the point where g is defined, GHC only knows about New [(a,b)] (Map a b), and New [(a,Double)] (Map a Int) doesn't fit. Consider this: *Main :type new . flip zip [0..] new . flip zip [0..] :: (New [(a, b1)] b, Num b1, Enum b1) = [a] - b Trying to infer New [(u, v)] w out of all that we know, i.e. New [(a,b)] (Map a b) should give us w === Map u v --- New [(u, v)] (Map u v) so finally v === Int --- New [(u, Int)] (Map u Int) to infer the context of g. Is there any good reason not to do this? Because I'm not smart enough to understand it? ;-) Cheers, D. Tenev ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: gcc rc 6.4 compilation error report on Mac OS X
Johan Glimming wrote: I forward this to the list in hope of getting feedback on the enclosed output from failed 6.4 rc make on a Mac OS X system from any OS X experts around: Johan, Could you post this to the list? There are people on the list who know more about Mac OS X than I, and they should be able to help resolve this. Cheers, Simon On 19 February 2005 13:06, Johan Glimming wrote: Simon, It did not even work with make (no concurrency) on the Mac OS X 10.3.4 platform with fink installed. Output from the compilation process: ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c FrontPanel.c -o FrontPanel.o ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-Wno-uninitialized -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c GC.c -o GC.o GC.c:148: warning: `regparm' attribute directive ignored GC.c:1667: warning: `regparm' attribute directive ignored ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c GCCompact.c -o GCCompact.o ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c Hash.c -o Hash.o ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c HsFFI.c -o HsFFI.o ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c Interpreter.c -o Interpreter.o ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes
Re: compiling GHC with a custom path to GCC
Simon Marlow wrote: On 18 February 2005 04:26, Seth Kurtzberg wrote: At least this proves that it isn't a hardware problem. :) Seth, you're a bit confused. This error from gcc is a deterministic, repeatable, crash due to a known bug in gcc 2.95. You were complaining about random unrepeatable crashes, which are most likely caused by hardware failure. We never said that deterministic crashes in gcc are due to hardware. Cheers, Simon Simon, you'll never give up. The crashes are absolutely repeatable. The fact that I haven't identified a deterministic way to reproduce them does not in any way imply that a deterministic way to reproduce them does not exist. And, as I've said, you are essentially claiming that a total of over 100 machines all have the same hardware problem, that never ever occurs unless gcc is running. You know that isn't true. You can, on the same machines, compile the same code with a different compiler hundreds of times (which I did; I left it running on two machines for a month) without a single problem. That is a software problem. I make a living by determining whether problems are software or hardware, and I very rarely make a mistake. I certainly never make a mistake with this sort of overwhelming proof. You are just ignoring the things that I've said that don't fit your theory. You will not find a single case of this caused by hardware, because if the hardware is really responsible, it is 100% impossible that every other program, including programs that consume all the memory and most of the swap (consume more total memory than the gcc runs) always work perfectly, and only gcc causes this supposedly hardware problem to appear. 100 machines, of six different microprocessors, and six different types of memory, all have a hardware problem that causes gcc, and only gcc, and absolutely nothing other than gcc, to crash? These machines can otherwise run for months at a time at very high load and the hardware problem somehow never appears? Tell me that you've ever seen a hardware problem with these characteristics. Furthermore, tell me that you've seen hardware problems that never get worse, and are associated with a single program. Find a single example of such a program that reveals a hardware problem in processors made by three different companies. Or an example of a program that reveals a hardware problem in a dozen different motherboards. None of which exhibit even the slightest problem unless gcc is running. None of which deadlock, freeze up, never have kernel panics ... it just isn't possible, unless you ignore the evidence. And the fact that one is deterministic implies that the others are not? That has absolutely no basis in logic. I'm sure that with enough work each and every one can be produce deterministically. Nobody has paid me to do that, and nobody is going to. It's a lot cheaper to just use a compiler that works. Even having to use Sun's compiler, with all it's problems, is less expensive then trying to fix gcc, and Sun charges about 3,000 each for the compiler. Hardware problems cause random problems, and any problem that occurs with only one program is by definition not random. You are confusing random with not yet explained. The two aren't remotely alike. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:4215baf2198669959829382! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
Simon Marlow wrote: On 18 February 2005 10:17, Seth Kurtzberg wrote: Simon, you'll never give up. The crashes are absolutely repeatable. The fact that I haven't identified a deterministic way to reproduce them does not in any way imply that a deterministic way to reproduce them does not exist. And, as I've said, you are essentially claiming that a total of over 100 machines all have the same hardware problem, that never ever occurs unless gcc is running. I'm not *claiming* anything about your case - please read what I said. I simply commented that random crashes in gcc are often caused by hardware failure. Indeed it sounds like hardware isn't the problem in your case, so I suggest you try to narrow down the problem and submit a report to the gcc folks. Cheers, Simon The gcc folks know about the problem, they just don't know how to fix it. I've sent them about 30 core files and many valgrind runs showing heap corruption. I have actually never seen a random crash in gcc, with a coherent core dump file, caused by hardware. This is much much too regular to even suspect hardware. You also have the fact that these machines can run ghc or ghci all day long. ghc is a heavier user of resources, and a much more complex program, but it never crashes these systems (except occasionally during these initial release or pre-release periods, which is of course to be expected). _If_ a random crash were caused by hardware, other programs would _always_ occasionally crash. There are no exceptions to this rule, unless you never run any program other than gcc that uses significant resources (and even then I'd be dubious). It's been happening for so long, and the gcc people have no concept of what's happening, so people don't even bother to report it anymore. Gcc 3.1 and 3.2 were simply rejected by almost all users because of the frequency of crashes. With 3.3, the crashes did not disappear, but became less common. The initial 3.4 release was unusable. All of these things are well known to anyone working on a C++ project. I would think that, in addition to showing the ghc is a far superior piece of software, the fact that ghc or ghci, once built, never crashes would eliminate any doubt about whether the problem is caused by hardware or software. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:4215dcff207641880317564! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
Simon Marlow wrote: On 17 February 2005 11:12, Remi Turk wrote: when compiling the new ghc pre-releases made my gcc 2.95.3 die with internal compiler error, I tried to compile it with gcc 3.4.3 (or rather, I thought it compiled with 3.4.1, and when that died, compiled+installed gcc 3.4.3, tried again, say it die again and only then noticed it was actually still using 2.95.3 ;) but had quite some difficulty to actually get it to compile with, in my case, /usr/local/bin/gcc3 When using the following command-line CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl --prefix=/var/tmp/ghc --with-gcc=/usr/local/bin/gcc3 stage1 still used gcc 2.95.3 to compile stage2 (okay, for --with-gcc that's documented) Really? --with-gcc should set the gcc for stage1, AFAIK. Is there a bug here? I've noticed gcc 2.95 crashing on my FreeBSD box too. I should look into whether there's a workaround, otherwise we're hosed on FreeBSD 4.x. This is a known problem in all the 3.x compilers, and also occurs, although less often, with 2.9x versions. I've seen no difference in frequency comparing FreeBSD to Linux and NetBSD. The only solution, which is of course highly annoying, is to simply restart the make. For whatever reason this always works, sometimes until the end of the build, and sometimes until some other crash. My theory is that it is related to the temporary files that gcc creates, mostly for templates. While a royal PITA, the resulting code is correct. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:421483e7114671125015511! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
Simon Marlow wrote: On 17 February 2005 11:49, Seth Kurtzberg wrote: Simon Marlow wrote: On 17 February 2005 11:12, Remi Turk wrote: when compiling the new ghc pre-releases made my gcc 2.95.3 die with "internal compiler error", I tried to compile it with gcc 3.4.3 (or rather, I thought it compiled with 3.4.1, and when that died, compiled+installed gcc 3.4.3, tried again, say it die again and only then noticed it was actually still using 2.95.3 ;) but had quite some difficulty to actually get it to compile with, in my case, /usr/local/bin/gcc3 When using the following command-line CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl --prefix=/var/tmp/ghc --with-gcc=/usr/local/bin/gcc3 stage1 still used gcc 2.95.3 to compile stage2 (okay, for --with-gcc that's documented) Really? --with-gcc should set the gcc for stage1, AFAIK. Is there a bug here? I've noticed gcc 2.95 crashing on my FreeBSD box too. I should look into whether there's a workaround, otherwise we're hosed on FreeBSD 4.x. This is a known problem in all the 3.x compilers, and also occurs, although less often, with 2.9x versions. I've seen no difference in frequency comparing FreeBSD to Linux and NetBSD. The only solution, which is of course highly annoying, is to simply restart the make. For whatever reason this always works, sometimes until the end of the build, and sometimes until some other crash. My theory is that it is related to the temporary files that gcc creates, mostly for templates. While a royal PITA, the resulting code is correct. A known problem? Is there any open bug in the gcc bug database I can look at? There has to be one, because the problem occurs when you compile gcc with gcc. I'll look for a specific bug report. It happens much more frequently with 3.x than with 2.95, in my testing, but that was not a test of compiling Haskell, so I have no frequency information, specifically. The compiler is broken, but since you can recover by restarting the make, it isn't horrible, just almost horrible. The other problem for the gcc people is the fact that it occurs randomly. The behavior has changed; 3.4 will crash in a different place than 3.3. If the program is large enough, it will happen. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:421489b7116526977230217! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
Remi Turk wrote: On Thu, Feb 17, 2005 at 04:48:54AM -0700, Seth Kurtzberg wrote: Simon Marlow wrote: On 17 February 2005 11:12, Remi Turk wrote: when compiling the new ghc pre-releases made my gcc 2.95.3 die with "internal compiler error", I tried to compile it with gcc 3.4.3 (or rather, I thought it compiled with 3.4.1, and when that died, compiled+installed gcc 3.4.3, tried again, say it die again and only then noticed it was actually still using 2.95.3 ;) but had quite some difficulty to actually get it to compile with, in my case, /usr/local/bin/gcc3 When using the following command-line CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl --prefix=/var/tmp/ghc --with-gcc=/usr/local/bin/gcc3 stage1 still used gcc 2.95.3 to compile stage2 (okay, for --with-gcc that's documented) Really? --with-gcc should set the gcc for stage1, AFAIK. Is there a bug here? I've noticed gcc 2.95 crashing on my FreeBSD box too. I should look into whether there's a workaround, otherwise we're hosed on FreeBSD 4.x. This is a known problem in all the 3.x compilers, and also occurs, although less often, with 2.9x versions. I've seen no difference in frequency comparing FreeBSD to Linux and NetBSD. The only solution, which is of course highly annoying, is to simply restart the make. For whatever reason this always works, sometimes until the end of the build, and sometimes until some other crash. My theory is that it is related to the temporary files that gcc creates, mostly for templates. While a royal PITA, the resulting code is correct. Cheers, Simon I'm afraid finding a workaround for compilers dying on compiler-generated code isn't going to be much fun... Anyway, I just replaced a ifneq "$(INSTALL_LIBS)" "" by ifneq "$(strip $(INSTALL_LIBS))" "" (see my glasgow-haskell-bugs message of today, this usage is recommended in make's "info" for strip.) Now I could install ghc, remove the build-tree and get enough free space to start compiling again. This time I'll log everything and come back when I'm sure what exactly is going on. (As I "remember" that 1) --with-gcc doesn't do what it should and 2) the gcc-2.95-crash on linux seems to be repeatable.) I'm not positive about 2.95, but I know that on 3.x it crashes in different places, and even compiling different source files. With each 3.x release, they fix some of them, but others pop up to take their place. Clearly the gcc people don't know what's going on. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
Malcolm Wallace wrote: Seth Kurtzberg [EMAIL PROTECTED] writes: There has to be one, because the problem occurs when you compile gcc with gcc. I'll look for a specific bug report. It happens much more frequently with 3.x than with 2.95, in my testing, but that was not a test of compiling Haskell, so I have no frequency information, specifically. Sounds like a CPU-overheating problem to me. It is well known that running an inadequately cooled processor at 100% for an extended period will cause random crashes. There are third-party reports that it happens with Linux kernel builds, and I have personally seen it with builds of nhc98 and Hat. When I replaced the CPU fan, the problems disappeared. The other problem for the gcc people is the fact that it occurs randomly. The behavior has changed; 3.4 will crash in a different place than 3.3. If the program is large enough, it will happen. Non-repeatable crashes certainly point the finger first at hardware rather than software. Could also be deteriorating memory chips - but that is likely to bring the whole machine down eventually. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:42148f7e119355211311528! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
Malcolm Wallace wrote: Seth Kurtzberg [EMAIL PROTECTED] writes: There has to be one, because the problem occurs when you compile gcc with gcc. I'll look for a specific bug report. It happens much more frequently with 3.x than with 2.95, in my testing, but that was not a test of compiling Haskell, so I have no frequency information, specifically. Sounds like a CPU-overheating problem to me. It is well known that running an inadequately cooled processor at 100% for an extended period will cause random crashes. There are third-party reports that it happens with Linux kernel builds, and I have personally seen it with builds of nhc98 and Hat. When I replaced the CPU fan, the problems disappeared. The other problem for the gcc people is the fact that it occurs randomly. The behavior has changed; 3.4 will crash in a different place than 3.3. If the program is large enough, it will happen. Non-repeatable crashes certainly point the finger first at hardware rather than software. Could also be deteriorating memory chips - but that is likely to bring the whole machine down eventually. Regards, Malcolm Ordinally I would agree, but in this cases it hash to be software because I got probem on 40 different solais system As for the processor overheating, you would expect that it's on it's last legs if it starts overheating. It also happens on older machies; I've seen it happen on a PII machine, which isn't terribly hot. I think that because I've seen it so many times, on machines that continue to run flawlessly, some for two years, we can eliminate hardware. This is almost certainly heap corruption. The KDE tool that is like purify (only better and free), valgrind, should help fix it if it is caused by any sort of memory corruption. That would be Remember, it is always crashing (I believe always) with an internal compiler error. Were hardware involved, you would expect to not get the same message. (Unless its the only error they have a name for). If you really want to fix it, we could use a watchdog timer, and have it restart the compiler whenever it crashes. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:42148f7e119355211311528! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
Simon Marlow wrote: On 17 February 2005 12:05, Seth Kurtzberg wrote: I'm not positive about 2.95, but I know that on 3.x it crashes in different places, and even compiling different source files. With each 3.x release, they fix some of them, but others pop up to take their place. Clearly the gcc people don't know what's going on. Are you sure this isn't a hardware problem on your system? gcc crashing randomly is usually an indicator of bad memory or similar. Cheers, Simon I reproduced it on forty machines, all sparc ultras. I've reproduced it on at least 10 linux boxes, two BSD boxes, and the thread started with the problem on freeBSD. It isn't hard to find the error on a zillion pages. For example: For example: http://sources.redhat.com/ml/cygwin/1999-03/msg00083.html http://www.cygwin.com/ml/cygwin/2002-01/msg00611.html http://www.winehq.org/hypermail/wine-users/2000/12/0498.html Some of these believe the error occrs on cc1 after it receives an error six. I'm amazed that you haven't seen it. That's very unusual for gcc 3.x. You've been lucky. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:42148f0e119011198721357! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
Simon Marlow wrote: On 17 February 2005 12:43, Seth Kurtzberg wrote: Simon Marlow wrote: On 17 February 2005 12:05, Seth Kurtzberg wrote: I'm not positive about 2.95, but I know that on 3.x it crashes in different places, and even compiling different source files. With each 3.x release, they fix some of them, but others pop up to take their place. Clearly the gcc people don't know what's going on. Are you sure this isn't a hardware problem on your system? gcc crashing randomly is usually an indicator of bad memory or similar. Cheers, Simon I reproduced it on forty machines, all sparc ultras. I've reproduced it on at least 10 linux boxes, two BSD boxes, and the thread started with the problem on freeBSD. It isn't hard to find the error on a zillion pages. For example: For example: http://sources.redhat.com/ml/cygwin/1999-03/msg00083.html http://www.cygwin.com/ml/cygwin/2002-01/msg00611.html http://www.winehq.org/hypermail/wine-users/2000/12/0498.html Some of these believe the error occrs on cc1 after it receives an error six. I'm amazed that you haven't seen it. That's very unusual for gcc 3.x. You've been lucky. You're mixing up different errors - searching for 'gcc internal error' isn't particularly helpful. gcc internal errors happen for lots of different reasons, not just a single bug. Random unrepeatable crashes are almost certainly hardware failure. The crash on FreeBSD we were talking about earlier is repeatable, and only happens with GCC 2.95.x. The crash that happens on your 40 Sparc Ultras is repeatable, right? It's probably just a compiler bug in the particular version of gcc you're using. Wrong. Some are sparc 10s, 20s, ultra 10s, blades, 2000's, off the top of my head. The x86 hardware includes seven Dell machines, three machines I built, 8 compaq machines (before the merger), three HP machines, four Fujitsu laptops, and those are only the ones I remember specifically running the test on. The sparcs, especially, run for three solid months, every one of them, without a single problem or error. They are rebooted every three months as a precaution, although I think it is an unnecessary one. The only program that crashes is gcc. It makes no difference what gcc is compiling, as long as it is big. Of course, I suppose it is possible that every Pentium 3 and Pentium 4 processor, or all the PC100, single channel DDR, and dual channel memory sticks, and all the different sparc processors tested all have a hardware problem that appear only when you use gcc, but that strikes me as rather unlikely. In the face of well over 50 machines, all of which have the same problem with gcc, and none of which has a single problem with any other program (including Sun's compiler), that doesn't seem likely. The same thing is true in the machines running windows; Microsoft's compiler will build all day long, while gcc crashes. If this just happened on windows, you might question the windows gcc port, but it doesn't happen only on windows. Also, it makes no difference how many errors cause gcc to crash. If it has 1000 different bugs or one bug, it still crashes. I don't see how pretending this doesn't happen is terribly useful. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:421498d8122471196589817! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling GHC with a custom path to GCC
Remi Turk wrote:
On Thu, Feb 17, 2005 at 11:29:41AM -, Simon Marlow wrote:
On 17 February 2005 11:12, Remi Turk wrote:
when compiling the new ghc pre-releases made my gcc 2.95.3 die
with "internal compiler error", I tried to compile it with gcc
3.4.3 (or rather, I thought it compiled with 3.4.1, and when that
died, compiled+installed gcc 3.4.3, tried again, say it die again
and only then noticed it was actually still using 2.95.3 ;) but
had quite some difficulty to actually get it to compile with, in
my case, /usr/local/bin/gcc3
When using the following command-line
CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl
--prefix=/var/tmp/ghc --with-gcc=/usr/local/bin/gcc3
stage1 still used gcc 2.95.3 to compile stage2 (okay, for --with-gcc
that's documented)
Really? --with-gcc should set the gcc for stage1, AFAIK. Is there a
bug here?
I've noticed gcc 2.95 crashing on my FreeBSD box too. I should look
into whether there's a workaround, otherwise we're hosed on FreeBSD 4.x.
Cheers,
Simon
In case you've got nothing else left to do.. ;)
The ghc command which perfectly repeatable kills gcc:
make[2]: Entering directory `/var/tmp/ghc-6.4.20050216/ghc/compiler'
../../ghc/compiler/stage1/ghc-inplace -H16m -O -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/compMan -istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Istage2 -DGHCI -package template-haskell -package unix -package readline -DUSE_READLINE -package Cabal -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -recomp -Rghc-timing -H16M '-#include "hschooks.h"'-c cmm/MachOp.hs -o stage2/cmm/MachOp.o -ohi stage2/cmm/MachOp.hi
/tmp/ghc32662.hc: In function `s5dU_ret':
/tmp/ghc32662.hc:11210: Internal compiler error in `build_insn_chain', at global.c:1756
At least this proves that it isn't a hardware problem. :)
The dying gcc command:
gcc -x c cmm/MachOp.hc -o /tmp/ghc15388.raw_s -DDONT_WANT_WIN32_DLL_SUPPORT -fno-defer-pop -fomit-frame-pointer -fno-builtin -DSTOLEN_X86_REGS=4 -S -Wimplicit -O -D__GLASGOW_HASKELL__=604 -ffloat-store -I cmm -I stage2 -I . -I codeGen -I nativeGen -I parser -I /var/tmp/ghc-6.4.20050216/libraries/readline/include -I /var/tmp/ghc-6.4.20050216/libraries/unix/include -I /var/tmp/ghc-6.4.20050216/libraries/base/include -I /var/tmp/ghc-6.4.20050216/ghc/includes
The (naively) relevant part of the generated HC-file appears to
be the next "function". I have no idea whether this is of any
help for nailing this kind of nastiness down, so I'm not going to
spend more of my night on it ;)
I did attach the complete failing HC-file.
Greetings,
Remi
// compile code which doesn't seem to matter for the crash
#define FOO 0
// compile The Killing Line
#define BAR 1
IF_(s5dU_ret) {
W_ _c5ec;
FB_
#if FOO
_c5ec = (W_)((*((StgWord16*)((*R1.p) + (-0x2);
#endif
#if BAR
if (_c5ec 0x5) goto _c5en;
#endif
#if FOO
if (_c5ec 0x16) goto _c5eo;
if (_c5ec 0x14) goto _c5ep;
switch (_c5ec-20) {
case 0x0: goto _c5eq;
case 0x1: goto _c5er;
case 0x2: goto _c5es;
}
#endif
_c5eo:
#if FOO
R1.p = (P_)(W_)GHCziBase_False_closure;
Sp=Sp+1;
JMP_((*((P_)((*Sp) + (-0x10 + (*Sp));
_c5et:
R1.p = (P_)(W_)GHCziBase_True_closure;
Sp=Sp+1;
JMP_((*((P_)((*Sp) + (-0x14 + (*Sp));
#endif
_c5eu:
#if FOO
R1.p = (P_)(W_)GHCziBase_True_closure;
Sp=Sp+1;
JMP_((*((P_)((*Sp) + (-0x14 + (*Sp));
_c5ev:
R1.p = (P_)(W_)GHCziBase_True_closure;
Sp=Sp+1;
JMP_((*((P_)((*Sp) + (-0x14 + (*Sp));
_c5ew:
R1.p = (P_)(W_)GHCziBase_True_closure;
Sp=Sp+1;
JMP_((*((P_)((*Sp) + (-0x14 + (*Sp));
_c5ex:
if (_c5ec != 0x5) goto _c5eo;
R1.p = (P_)(W_)GHCziBase_True_closure;
Sp=Sp+1;
JMP_((*((P_)((*Sp) + (-0x14 + (*Sp));
_c5eq:
R1.p = (P_)(W_)GHCziBase_True_closure;
Sp=Sp+1;
JMP_((*((P_)((*Sp) + (-0x14 + (*Sp));
_c5er:
R1.p = (P_)(W_)GHCziBase_True_closure;
Sp=Sp+1;
JMP_((*((P_)((*Sp) + (-0x14 + (*Sp));
_c5es:
R1.p = (P_)(W_)GHCziBase_True_closure;
Sp=Sp+1;
JMP_((*((P_)((*Sp) + (-0x14 + (*Sp));
_c5ep:
if (_c5ec 0x9) goto _c5eo;
if (_c5ec 0x9) goto _c5ex;
#endif
R1.p = (P_)(W_)GHCziBase_True_closure;
Sp=Sp+1;
JMP_((*((P_)((*Sp) + (-0x14 + (*Sp));
_c5en:
switch (_c5ec) {
#if FOO
case 0x0: goto _c5et;
case 0x1: goto _c5eo;
case 0x2: goto _c5eu;
case 0x3: goto _c5ev;
case 0x4: goto _c5ew;
#else
case 0x0: goto _c5eo;
case 0x1: goto _c5eo;
case 0x2: goto _c5eu;
case 0x3: goto _c5eo;
case 0x4: goto _c5eo;
#endif
}
FE_
}
Re: debugging memory allocations
Duncan Coutts wrote: On Wed, 2005-02-02 at 13:30 -0700, Seth Kurtzberg wrote: Duncan Coutts wrote: In these cases we cannot turn on traditional profiling since that would interfere with the optimisations we are relying on to eliminate most of the other memory allocations. I don't understand why you can't use profiling as a debugging tool. How would profileing, ifor test purposes, cause other things to break? The problem is that profiling add in extra parameters and extra code to each function (each SCC). This can interfere with optimisations like inlining and unboxing I believe. Simon could explain it better. Generally profiling is great, but for some of these low level optimisation problems you can end up profiling a different program program to the one you are interested in (the unoptimised one rather than the optimised one). Yes, I can see that. I've had problems in other languages where using the debugger stopped a seg fault. Obviously not the same situation, but a similar problem. Have you come up with a solution? Duncan !DSPAM:420176b7116488359410460! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: debugging memory allocations
Duncan Coutts wrote: All, I'm looking for advice on how to figure out why some piece of code is allocating memory when I think it ought to be able to work in constant space. In these cases we cannot turn on traditional profiling since that would interfere with the optimisations we are relying on to eliminate most of the other memory allocations. I don't understand why you can't use profiling as a debugging tool. How would profileing, ifor test purposes, cause other things to break? snip Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:4200ddb972401401013949! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [ ghc-Feature Requests-1104381 ] Add wxHaskell link to homepage
I would prefer to keep them on the list. There are already a number of different lists, and (of course IMO) I can't see a need to read _only_ feature requests, so why separate them? Adding a tag to the email that would let maildrop or procmail deliver it to a different folder would be a nice solution; those who want the current situation would do nothing, and those who would prefer not to see those messages can add a simple rule to maildrop. (I hesitate to use "procmail" and "simple" in the same sentence, but it presumably wouldn't be terribly difficult there either.) Simon Marlow wrote: On 18 January 2005 14:42, Ketil Malde wrote: I seem to be getting messages from Sourceforge from this mailing list. Is that an intended use for ghc-users? It's intentional, but it can be easily turned off. Do people want to see feature-requests, task-list entries and so forth on this mailing list, or should they be confined to, say, [EMAIL PROTECTED]? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:41f13d8a187771680466285! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC on Arm
I recently did a port of linux to ARM, and the floating point issue came up. What happens is that if you don't do anything other than the default gcc build, then every floating point call is converted to an O/S trap which then does the floating point computation with the fixed point hardware (because there is no floating point hardware). There is a much more efficient floating point library that can be built and used with gcc; I'm sorry that I don't have the specifics at hand but hopefully a web search will find it; if not, email me and I'll dig out the info. Along with this extra code (which is quite short), there are one or two flags required for the initial ./configure for gcc. Again, if these are not apparent I can go through my absurdly disorganized filing system (known as the box) and find the flags as well. Actually, I'm exaggerating; I have a complete gcc build procedure written that describes building for arm with the separate floating point code and specifies all the flags; I just have to retrieve it from a backup disk. I'm in the midst of moving but I think I can get at the appropriate CD without unpacking anything. The performance difference, if your application is in any way floating point intensive, is dramatic. The project for which I did the port involved scaling and panning of geographical (map) data, which is floating point intensive. If your issue is floating point functionality rather than floating point performance, the standard gcc build and linux software emulation of floating point hardware works fine. You only need to do the more complex procedure if your concern is performance. It is not necessary if your use of floating point is light. Note that while the entire cross compilation is time consuming (fortunately, mostly machine time consuming), changing it from the default o/s trap floating point to the more efficient floating point library is not difficult and is quick. You don't have to start from scratch. So it is perfectly reasonable to take the default behavior, do performance testing and profiling of the specific application, and add in the more efficient floating point library if profiling shows that you actually need it. Note also that the main reason for the increase in performance is not that the kernel's floating point implementation is not good; the library I downloaded and built was only (based on somewhat rough calculation) about 15% faster. The performance killer is the extra context switches that occur each time a floating point instruction causes an O/S trap. What I mean is that even though the downloaded library is only 15% faster than the kernel library, the performance increase is closer to an order of magnitude because of the higher costs of calls to the kernel vs. a simple call to a function within a library that is already linked into your application. Seth John Goerzen wrote: Hello, I would like to port GHC to Arm so that I can compile Haskell programs for use on my Zaurus or in Debian's ARM port. I have talked to Ian Lynagh about this, and he believes that there was some sort of problems with floats. I don't know exactly that was, if it was in gcc or ghc, or if it has been fixed. Does anybody have some light to shed on this? Also, does anybody have any ARM binaries of ghc to ease the bootstrapping pain? Thanks! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:41f13d7e187601466359710! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Mac Port
Is there, or is anyone working on, ports for Mac OSX and/or Mac OS9? - Seth Kurtzberg CTO ISEC Research and Network Operations Center 480-314-1540 888-879-5206 [EMAIL PROTECTED] - ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building snapshot ghc-5.05.20030123 on macOSX
This is usually caused by not separating out the template haskell code from the normal haskell code. The compiler needs to see them in separate files. On Wednesday 12 February 2003 12:06 pm, Arthur Baars wrote: I want to play a bit with Template Haskell, so I downloaded a cvs snapshot (ghc-5.05.20030123.tar.gz) and tried to compile it on my mac (OSX 10.2). I figured out that I needed a stage2 or stage3 compiler to get TH working, so I tried 'make stage3' . GHC started to compile itself three times. At lot of hours later it finished. Unfortunately, when I tried run the thing on a Prinf example, I got the following message. compiler/stage3- ./ghc-inplace -c Printf.hs -fglasgow-exts -package haskell-src Template Haskell bracket illegal in a stage-1 compiler [| \s - s |] The thing incompiler/stage3 was just a stage-1 compiler, so ghc had achieved nothing useful after re-compiling three times :-( The problem is that GHCi support is not turned on for MacOSX. I guess GHCi is used to do compile-time evaluation of code for TH. In file mk/config.mk.in it says: # Include GHCi in the compiler. Default to NO for the time being. ifneq $(findstring $(HostOS_CPP), mingw32 cygwin32 linux solaris2 freebsd netbsd openbsd) GhcWithInterpreter=YES else GhcWithInterpreter=NO endif In the list of supported systems MacOSX is missing. After adding darwin to this list, and waiting for hours, I got a working TH-compiler. Can someone add OSX(darwin) to the mk/config.mk.in file? It would also be nice to get a warning if one tries to compile a stage-(N1) compiler without GHCi support. Cheers, Arthur ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Seth Kurtzberg M. I. S. Corp. 480-661-1849 [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
On Tue, 2002-11-26 at 08:32, Dean Herington wrote: On 26 Nov 2002, Alastair Reid wrote: ps Better names than 'native' and 'green' surely exist. Something which conveys the idea that the thread will be remembered for later use seems appropriate but no good words spring to mind. Perhaps bound and free? Won't that be confused with bound and free as used in lambda calculus? Or am I missing the point and you mean that they are analogous to bound and free in lambda calculus? (If the latter, I need to reread my lambda calculus books. :)) ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Seth Kurtzberg M. I. S. Corp 480-661-1849 Pager 888-605-9296, or [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc 5 for Solaris 2.6
I have it working on Solaris 2.8, bootstrapped from 4.08 as Simon describes. The same procedure should work on 2.6. If you have problems I can send you the contents of the directory after compilation. I think the compiled directory from 2.8 would run on 2.6, as long as 64 bit mode isn't used. On Tue, 2002-11-05 at 03:01, Simon Marlow wrote: I need to run ghc 5.02 or later on Solaris 2.6. I don't have any version of ghc on the machine. Are there binaries for 2.6 still? Alternatively, is it possible to build it without ghc? You might find that the 2.7 binaries work on your system. Failing that, you'll need to bootstrap GHC from .hc files, starting from version 4.08.2. Instructions are here: http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.htm l Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Seth Kurtzberg M. I. S. Corp 480-661-1849 Pager 888-605-9296, or [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: FFI C++
What is the O/S and compiler? That the C++ new operator is not found is very strange. Throw is another story, as throw doesn't appear in the compiled code with some compilers. On Wed, 2002-10-30 at 04:18, Simon Marlow wrote: I am currently trying to create a Haskell interface to a C++ library and cannot get it to work completely. The problem seems to be that the linker must be able to find the code for basic C++ constructs like new and throw. Apparently it is able to do so when compiling an executable, but when I try to do the same with ghci it fails. Anybody have an idea why this happens and what to do about it? I don't know the gory details, but it might be that we would have to link GHCi with the C++ linker for this to work. Would anyone with a clue about C++ linking like to comment? The feature to install local packages is currently a bit awkward. I would like to be able to simply use a local package the same way I use a normal package, and my first try was to set the package-conf file in my .ghci file. But this doesn't work very well for two reasons: (1) it only works for the interpreter, but not for the compiler (2) it isn't read until *after* the command line is read, so any packages given there is not recognized. Is it possible to have a common (.ghc) file that is used for both the compiler and the interpreter, and that is read *before* the command line is interpreted? Hmm, I must admit I'm a bit averse to adding features like this unless they are really necessary. One problem is that when someone submits a bug report, we'll have to start asking do you have a .ghc file? what does it contain?. The current situation has the advantage of being simple. Can't you just alias ghc to 'ghc -package-conf ...'? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Seth Kurtzberg M. I. S. Corp 480-661-1849 Pager 888-605-9296, or [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI C++
Wolfgang, On Solaris, you can build GNU C++ either way; that is, to use shared libraries or linked libraries. (In fact you can also build it to enable both, and select one or the other at link time.) So, this is certainly worth checking. The easiest way to check it is to run ldd -r on the executable. On Wed, 2002-10-30 at 15:53, Wolfgang Thaller wrote: Many platforms have the C++ runtime and the C++ standard library as a static library (probably because the C++ ABI is not as stable as it should be...). I think this applies to both Mac OS and to Windows [mingw32], perhaps it's the same with Solaris. If that is the case, it would explain the problem, I think. GHCi can't load static libraries [yet - the ar format shouldn't be too difficult to implement], so everything that's needed from static libraries has to be linked into the ghc binary and probably also listed in Linker.c (who else doesn't like those hard-coded symbol references?) Just my EUR 0.02 :-) Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Seth Kurtzberg M. I. S. Corp 480-661-1849 Pager 888-605-9296, or [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Database library?
I have an interface working with my database engine (www.cql.com). It is also in an early stage, but does not use ODBC. I believe that much of what I am doing will generalize reasonably well, but this is untested. I will be testing both Oracle and MSSQL soon, and I hope to have reasonable beta code in three or four weeks; of course this is subject to change depending on what develops. If anyone has access to Sybase or Informix, and is interested in testing those environments, drop me an email. To clarify, there are really two ODBC specifications, the SQL language spec and the API spec. In general, I'm assuming compliance with ANSI and ODBC SQL syntax (which are slightly different), but I'm not using the ODBC API which is ungainly and inefficient (and just plain ugly). On Wednesday 16 October 2002 09:49 am, Bryn Keller wrote: Does anyone have a GHC-friendly library for accessing databases, specifically Oracle and MSSQL? I noticed Hasql on the Haskell libraries page, but it seems rather in the beginning stages, and I was hoping for native DB connections rather than ODBC ones. How are others handling database access? Thanks, Bryn ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- --- Seth Kurtzberg M. I. S. Corp. 1-480-661-1849 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Newbie building GHC
Use strace with the -ff option. This will produce separate traces for each child, which will be easier to interpret. It looks like whatever is going wrong is happening in a child process (but someone who knows more about the innards of ghc may correct me on this). On Monday 23 September 2002 08:04 pm, Saswat Anand wrote: Hi I am also facing the same problem. I tried to build a virgin tree, but with no success as Simon PJ has pointed out. I have attached my strace file. Saswat On Mon, 23 Sep 2002, Simon Marlow wrote: I have been trying to build GHC, but the ghc.exe that gets built for ghc-inplace always exits with Error 1. It *can* print its version number and the help, but building anything fails. The build fails making Adjustor.o from Adjustor.c. I'm trying to build a cvs checkout fpconfig ghc hslibs on Win XP Pro, bootstrapping with the provided GHC 5.04.1 binary and Happy 1.13 binary. I mentioned this to a colleague and he said he had exactly the same problem (ghc exits with error 1), on Windows and Linux, when building from source tarballs and CVS. We don't normally have any problems running the haskell.org GHC binaries. Can any of you suggest what we might be doing wrong? We are in the southern hemisphere, so our electrons may be orbiting backwards. :-) I've never seen this myself, I'm afraid. If you have a Linux build which behaves in the same way, could you try stracing it (i.e. prepend 'strace' to the command which fails) and send us the output? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- --- Seth Kurtzberg M. I. S. Corp. 1-480-661-1849 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
