RE: [Haskell-cafe] London HUG domain expired
> From: sefer@gmail.com [mailto:sefer@gmail.com] On > Behalf Of Yitzchak Gale > > On Fri, Apr 23, 2010 at 1:24 PM, Bayley, Alistair wrote: > > Looks like the London HUG domain (londonhug.net) registration has > > expired. Neil Bartlett was the registrant. > > Neil: do you plan to renew? > > The whois database reports: > > Domain name: LONDONHUG.NET > > This domain name is up for auction for a limited time. > > To place a bid, visit: http://www.namejet.com > > And it appears that someone has already placed a $75 bid. > > The domain should be renewed promptly, before the grace > period expires. Probably the best option, but can anyone other than Neil do this? If not, does anyone know if Neil is reachable? (could try his phone number listed in the whois record, but that seems a little invasive). 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
London HUG domain expired
> From: glasgow-haskell-users-boun...@haskell.org > [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf > Of Denys Rtveliashvili > > On the side note, is London HUG still active? The website > seems to be down... Looks like the London HUG domain (londonhug.net) registration has expired. Neil Bartlett was the registrant. Neil: do you plan to renew? 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Installing syb(-0.1.03) package in head version of Haskell
Just a wild guess, but the package description has this non-ascii text: author: Ralf Lämmel, Simon Peyton Jones It could well be Latin-1 encoded, rather than UTF8. Try editing the author field to this: author: Ralf Laemmel, Simon Peyton Jones and rebuilding/installing. > -Original Message- > From: glasgow-haskell-users-boun...@haskell.org > [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf > Of Simon Peyton-Jones > Sent: 23 February 2010 14:32 > To: GHC users > Cc: cvs-...@haskell.org > Subject: FW: Installing syb(-0.1.03) package in head version > of Haskell > > Friends > > > > Can anyone help Kathleen out? She has a cabal-install issue. > I think she's on a Mac. > > > > Many thanks > > > Simon > > > > From: Kathleen Fisher [mailto:kathleen.fis...@gmail.com] > Sent: 16 February 2010 22:54 > To: Simon Peyton-Jones > Subject: Fwd: Installing syb(-0.1.03) package in head version > of Haskell > > > > Hi Simon, > > > > I'm trying to get the PADS file we were working on compiling > under the HEAD version of Haskell, but I'm having trouble > getting the Data.Generics module to install. I sent the > question below to the librar...@haskell.org last week, but I > haven't seen any replies. Is that the right address? Or is > there a different place to ask such questions? > > > > Thanks for any pointers! > > > > Kathleen > > > > Begin forwarded message: > > > > > > From: Kathleen Fisher > > Date: February 11, 2010 2:28:20 PM PST > > To: librar...@haskell.org > > Subject: Installing syb(-0.1.03) package in head version of Haskell > > > > Hi all, > > I'm trying to get a program that uses the Data.Generics > module to compile under the head version of GHC, but I am > having trouble getting the syb package installed. > > I believe I am using the most recent version of cabal: > > > > > kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/ > .cabal/bin/cabal --version > > cabal-install version 0.8.0 > > using version 1.8.0.1 of the Cabal library > > > When I ask cabal to install the syb package, I get the > following error: > > > > > kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/ > .cabal/bin/cabal install -w ~/sw/ghc-head/bin/ghc > > Resolving dependencies... > > Downloading mtl-1.1.0.2... > > Configuring mtl-1.1.0.2... > > Preprocessing library mtl-1.1.0.2... > > ... > > Registering syb-0.1.0.3... > > cabal: ghc-pkg: : hGetContents: invalid argument > (invalid UTF-8 byte > > sequence) > > cabal: Error: some packages failed to install: > > language-c-quote-0.1 depends on syb-0.1.0.3 which > failed to install. > > syb-0.1.0.3 failed during the building phase. The exception was: > > exit: ExitFailure 1 > > > > The full trace is included below. > > Here's the version information for the ghc I am running. > > > > > Kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/ > sw/ghc-head/bin/ghc --version > > The Glorious Glasgow Haskell Compilation System, > version 6.13.20100210 > > > The cabal website suggests sending questions to this list... > > Any suggestions for how to fix this problem? > > Kathleen > > > > > > kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/ > .cabal/bin/cabal install -w ~/sw/ghc-head/bin/ghc > > Resolving dependencies... > > Downloading mtl-1.1.0.2... > > Configuring mtl-1.1.0.2... > > Preprocessing library mtl-1.1.0.2... > > Building mtl-1.1.0.2... > > > > ...stuff deleted... > > > > src/Data/Generics.hs:40:1: > > Warning: The import of `Prelude' is redundant > > except perhaps to import instances from `Prelude' > > To import instances alone, use: import Prelude() > > Registering syb-0.1.0.3... > > cabal: ghc-pkg: : hGetContents: invalid argument > (invalid UTF-8 byte > > sequence) > > cabal: Error: some packages failed to install: > > language-c-quote-0.1 depends on syb-0.1.0.3 which > failed to install. > > syb-0.1.0.3 failed during the building phase. The exception was: > > exit: ExitFailure 1 > > > > * 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. * __
RE: GHCi's search path
> From: glasgow-haskell-users-boun...@haskell.org > [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf > Of Peter Gammie > > http://haskell.cs.yale.edu/ghc/docs/latest/html/users_guide/se > parate-compilation.html#search-path > > GHCi is not overly keen to go looking for modules in directories > different to where the source resides. > > The semantics I want is: > - use the Cabal-built objects/hi files in dist/build if they're > fresh enough > - interpret the source otherwise. > > Is that possible? I think the -odir and -hidir options will help e.g. -odir dist/build -hidir dist/build http://haskell.cs.yale.edu/ghc/docs/latest/html/users_guide/separate-com pilation.html#options-output 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: 6.10.3 plans
> From: glasgow-haskell-users-boun...@haskell.org > [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf > Of Alexander Dunlap > > > > An exception to this rule is that we will probably also > rebundle time in > > the bindists, as that has little chance of breaking anything else. > > Would this be a good time to add the "time" package too, or has that > issue been resolved? I think Ian said time will be rebundled (see excerpt above). 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell-cafe] How to getCh on MS Windows command line?
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Simon Marlow > > Bulat Ziganshin wrote: > > 흐壹o 鉅, > > > > 工賊嫂, 膠墮將奄 굅, 껐갭, 맏굡별9 죌, 闔u 破訂佯 > > Please stick to English on this list, thanks. > > Simon Actualy it was english, it's just that the encoding was wrong. In Outlook I manually changed the encoding to US-ASCII, and got the message below. I'm not sure why other 8-bit encoding options failed (like Western Europen (ISO). Alistair Hello Ki, Monday, November 10, 2008, 8:16:09 AM, you wrote: > What I mean by getCh is the non-buffered non-echoed version of getChar, > which Hugs used to provided as an extension but not any more. 1. works for me in ghc: getHiddenChar = liftM (chr.fromEnum) c_getch foreign import ccall unsafe "conio.h getch" c_getch :: IO CInt 2. setBufferingMode stdin NoBuffering not tested 3. use interact. i definitely remember that i had effect you need this way. probably it was with some hugs version, but i don't remeber details 4. these days it's not very hard to install free VMWare Player, get preinstalled linux image and install hugs/ghc there -- Best regards, Bulat * 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: breakage with Cabal-1.6
> * Takusen-0.8.3 > > Imports writeHookedBuildInfo from Distribution.PackageDescription > > While the fix > for these three packages' Setup scripts is trivial, there is not fix > that will make them compile with old and new versions of the lib. For Takusen I'd be happy to fix the Setup and require the latest Cabal in order to build. That's what we've done in the past. 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell-cafe] Haskell garbage collector notes?
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Galchin, Vasili > > Is > http://hackage.haskell.org/trac/ghc/wiki/GarbageCollectorNotes > a reliable source of info on the ghc garbage collector? Depends which version of GHC... the next release (6.10) will include the new parallel GC: http://research.microsoft.com/~simonpj/papers/parallel-gc/index.htm http://hackage.haskell.org/trac/ghc/wiki/Status/Releases 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc-6.8.1 on WinXP: windres: can't open font file `for'
> From: Simon Marlow [mailto:[EMAIL PROTECTED] > > I assume the bug you're encountering is this one: > > http://hackage.haskell.org/trac/ghc/ticket/1828 > > in which case the workaround is not to install GHC to a patch > containing > spaces. > > If it's not that bug, then we'll have to investigate further. I searched trac for windres and found two tickets (including that one above), neither of which seems to describe my problem. Here's the (trimmed) output from ghc -v3: Linking Main.exe ... *** Windres: c:\ghc\ghc-6.8.1\bin/windres --preprocessor=c:\ghc\ghc-6.8.1\gcc -Bc:\ghc\ghc-6.8.1\gcc-lib/ -E -xc -DRC_INVOKED --input=C:/DOCUME~1/bayleya/LOCALS~1/Temp/ghc1480_0/ghc1480_0.rc --output=C:/DOCUME~1/bayleya/LOCALS~1/Temp/ghc1480_0/ghc1480_0.o --output-format=coff c:\ghc\ghc-6.8.1\bin/windres: can't open font file `for': No such file or directory You can see that my ghc installation is on a path sans spaces. Would you like more information? 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc-6.8.1 on WinXP: windres: can't open font file `for'
> From: Neil Mitchell [mailto:[EMAIL PROTECTED] > > > Bummer. I was hoping to be able to use 6.8.1 with gtk2hs > (AFAIUI, gtk2hs > > doesn't work with/hasn't been compiled against 6.8.2 yet). > Is there a > > workaround or something I can tweak in my 6.8.1 installation? > > It's much easier to gently prod Duncan until he gives in and releases > a new gtk2hs version. Maybe... the fact that I don't have this problem with 6.8.1 on my laptop implies that there *might* be something external to ghc that I can change that would fix it. 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc-6.8.1 on WinXP: windres: can't open font file `for'
> From: Simon Marlow [mailto:[EMAIL PROTECTED] > > > c:\ghc\ghc-6.8.1\bin/windres: can't open font file `for': > > No such file or directory > > This one was fixed in 6.8.2. Bummer. I was hoping to be able to use 6.8.1 with gtk2hs (AFAIUI, gtk2hs doesn't work with/hasn't been compiled against 6.8.2 yet). Is there a workaround or something I can tweak in my 6.8.1 installation? 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.8.1 on WinXP: windres: can't open font file `for'
I've just installed ghc-6.8.1 on my WinXP workstation (I already have it successfully working on my laptop). When I compile anything, the linking stage fails with: c:\ghc\ghc-6.8.1\bin/windres: can't open font file `for': No such file or directory Any clues as to what's wrong? Google isn't very helpful... (I've stripped my path back to just windows, windows\system32, and ghc, but no joy). Alistair P.S. output from ghc -v3 (trimmed): Linking Main.exe ... *** Windres: c:\ghc\ghc-6.8.1\bin/windres --preprocessor=c:\ghc\ghc-6.8.1\gcc -Bc:\ghc\ghc-6.8.1\gcc-lib/ -E -xc -DRC_INVOKED --input=C:/DOCUME~1/bayleya/LOCALS~1/Temp/ghc1480_0/ghc1480_0.rc --output=C:/DOCUME~1/bayleya/LOCALS~1/Temp/ghc1480_0/ghc1480_0.o --output-format=coff c:\ghc\ghc-6.8.1\bin/windres: can't open font file `for': No such file or directory The .rc file it is given contains: 1 24 MOVEABLE PURE "Main.exe.manifest" so this "... font file 'for':..." message is a puzzle. * 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. * ___ 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....
> 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Status of GHC runtime dependency on GNU multi precisionarithmetic library
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Stefan O'Rear > > http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes > > > It's less of an issue on Linux where libgmp is dynamically > linked but when > > thinking about using Haskell ghc for creating Windows apps > it is for me a > > real problem, because it would mean I'd have to distribute > the code for my > > app as a library along with the code as an executable, thus > doubling the > > download size for my apps as well as having to include a > license that has > > to explain to a possibly non-technical user that although > the program > > includes code that is libre/gratis free the program is not > itself free etc > > etc... > > Huh? AFAIK the LGPL is only an issue for the commercial/proprietary > users of Haskell; gratis/libre works would continue to be gratis/libre > after linking with GMP. I could be wrong, but I believe that Brian's intention is indeed to release a commercial/proprietary app, hence it is possibly an issue for him. I'm not sure about having to distribute the code for his app; I thought the point of the LGPL license was to allow proprietary (non-GPL?) apps to link to LGPL libs. Wouldn't he just have to distribute the code for GMP? But then, I understand less about FSF licensing than pretty much everyone else on this list, so I'll shut up now... 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: haskell for web
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of ??? > > help > haskell for web code http://www.haskell.org/haskellwiki/Applications_and_libraries/Web_programming Try a few of these out (whatever meets your needs). For web apps WASH and HAppS seem popular. Feel free to ask the haskell-café list for further help. 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghci attempts to link entire package
> From: Bayley, Alistair > > The result is that a user of Takusen can't easily use the > library with ghci/runhaskell "out of the box", unless they > have the full set of DBMS client libraries installed. I forgot to mention that there's another difference between ghci and gnu ld: if the external library is called libxx.dll, rather than xx.dll (which is the convention on Windows, it seems), then gnu ld is still able to locate & link to it when you say -lxx, but ghci fails to find it. You have to say -llibxx to ghci for it to work. This also makes distributing the Takusen library as a single package awkward, because 1. the cabal installation detects the presence of the library and configures the package with the -lxx option 2. ghc --make passes -lxx to gnu ld, which is nice... 3. ... but ghci tries to use -lxx also, and fails. So PostgreSQL users can't use ghci with the installed package unless they're willing to re-configure/build/install and change the -l option to from -lpq to -llibpq, which breaks normal compilation with ghc, because gnu ld can't find the library when you say -llibpq. (This affects the PostgreSQL client library on Windows, which is called libpq.dll.) 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghci attempts to link entire package
> From: Simon Marlow [mailto:[EMAIL PROTECTED] > > > Is this a feature or a bug? > > Neither really, just a consequence of the design. Well, that would make it a feature, then ;-) > There has been talk of adding support to link .a files which > would simplify > package management, but I guess it might make linking slower. > > If there's a use case that requires partial linking of a > package, then we could > consider the lack of partial linking a bug - can you > describe why you need it? With Takusen, all modules, including the DBMS-specific modules, are compiled into a single library. At present we have 3 DBMS's: Sqlite, Oracle, and PostgreSQL. For example, suppose you had just the Oracle DBMS client libraries installed, and you write a program which only uses the Oracle modules from Takusen. When you link, the gnu ld program attempts to resolve the symbols in only the modules that you've used. You don't need to have PostgreSQL or Sqlite installed, and the linker ignores these modules from the package archive. This is quite nice, because we can distribute the entire library as a single package, and it will work even if the user does not have all of the DBMS client libraries installed. In contrast, when ghci (or runhaskell) attempts to link it tries to resolve all of the symbols in the PostgreSQL and Sqlite modules, and fails because you don't have them installed. The result is that a user of Takusen can't easily use the library with ghci/runhaskell "out of the box", unless they have the full set of DBMS client libraries installed. There are a couple of workarounds, but they're both a bit fiddly, so it'd be nicer (from my POV) if the ghci linker behaved like gnu ld. 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghci attempts to link entire package
Related to some of the problems Takusen users have had, I have a question about ghci's linker/loader: why does it appear to try to link an entire package archive, rather than just the modules that are used? This is in contrast to the GNU ld program which the compiler uses, which only tries to link modules which are actually used. Is this a feature or a bug? 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] ANNOUNCE: Visual Haskell 0.2 final
> To: 'Krasimir Angelov' > > > No. It should be toplevel window. Try Spy\Processes from the menu to > > see only these windows that are part of devenv. > > OK. I assume that I'm only looking at the threads under > DEVENV. There are 9 of them, and only one has any (lots) > windows under it. I still don't see it under here. (shall we take this off-list?) I can start up another DEVENV, attach the debugger, and Break All. It shows me assembler: 7FFE02F8 add byte ptr [eax],al 7FFE02FA add byte ptr [eax],al 7FFE02FC add byte ptr [eax],al 7FFE02FE add byte ptr [eax],al 7FFE0300 mov edx,esp 7FFE0302 sysenter 7FFE0304 ret <== breakpoint here 7FFE0305 pushfd 7FFE0306 or dword ptr [esp],100h 7FFE030D popfd 7FFE030E ret 7FFE030F mov edx,esp 7FFE0311 syscall 7FFE0313 ret I can Continue, but pressing Break All simply returns me to the same spot. This is the call-stack: > 7ffe0304() ntdll.dll!77f5c534() kernel32.dll!77e689a9() user32.dll!77d4915e() kernel32.dll!77e68bd7() vs_haskell.dll!64f94b21() vs_haskell.dll!64f96d53() vs_haskell.dll!64f8d9ed() vs_haskell.dll!64f8e64c() vs_haskell.dll!64f8a149() vs_haskell.dll!64f8a30a() vs_haskell.dll!64615ad8() vs_haskell.dll!64615a61() msenv.dll!50012291() msenv.dll!500128a5() msenv.dll!500127c4() msenv.dll!500133ca() msenv.dll!50012ba0() msenv.dll!500c9aa9() msenv.dll!500c776f() msenv.dll!500c41d7() uxtheme.dll!5ad73e01() user32.dll!77d48723() user32.dll!77d48765() uxtheme.dll!5ad8a6a3() uxtheme.dll!5ad8a670() user32.dll!77d4969a() user32.dll!77d49688() user32.dll!77d49700() uxtheme.dll!5ad73e01() uxtheme.dll!5ad8a6a3() uxtheme.dll!5ad8a670() uxtheme.dll!5ad71c65() uxtheme.dll!5ad71b71() uxtheme.dll!5ad71af6() msenv.dll!500bf8e3() msenv.dll!500bf8e3() msenv.dll!500bf902() msenv.dll!500ae2b2() msenv.dll!500ae468() msenv.dll!5000ac60() user32.dll!77d497ab() user32.dll!77d4ab7a() msenv.dll!5000ad19() msenv.dll!5007afa0() msenv.dll!500c0fe3() MSCTF.dll!7472a743() MSCTF.dll!7472ba32() user32.dll!77d48654() user32.dll!77d48723() user32.dll!77d4a0ec() user32.dll!77d4aa77() msenv.dll!500b2e03() MSO.DLL!30b5fd93() MSO.DLL!30b60261() MSO.DLL!30b5f546() msenv.dll!500c98f1() msenv.dll!500c9b9d() MSO.DLL!30c19ac6() MSO.DLL!30c19a1e() msenv.dll!500c9bd4() msenv.dll!500e12e0() ntdll.dll!77f5f70f() ntdll.dll!77f60f7f() kernel32.dll!77e69436() kernel32.dll!77e69448() devenv.exe!004088a8() devenv.exe!00406ed7() devenv.exe!00410032() ntdll.dll!77f7e45c() ntdll.dll!77f5f7ee() ntdll.dll!77f5f8ea() ntdll.dll!77f5f70f() ntdll.dll!77f5f70f() ntdll.dll!77f60f7f() kernel32.dll!77e69436() kernel32.dll!77e69448() devenv.exe!004055a1() devenv.exe!004055c2() devenv.exe!004055d8() devenv.exe!004077bc() devenv.exe!0040780e() shlwapi.dll!70a7411b() kernel32.dll!77e735dd() shlwapi.dll!70a7411b() kernel32.dll!77e735e8() 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] ANNOUNCE: Visual Haskell 0.2 final
> From: Krasimir Angelov [mailto:[EMAIL PROTECTED] > > No. It should be toplevel window. Try Spy\Processes from the menu to > see only these windows that are part of devenv. OK. I assume that I'm only looking at the threads under DEVENV. There are 9 of them, and only one has any (lots) windows under it. I still don't see it under here. 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] ANNOUNCE: Visual Haskell 0.2 final
> From: Krasimir Angelov [mailto:[EMAIL PROTECTED] > > This usually happens when there is an uncaught Haskell exception. In > this case the RTS shows it in a message box. The problem is that with > threaded RTS the running thread might be different from the main > thread and in this case you can't see the message. Instead you have to > use the Spy++ tool distributed with Visual Studio. Look for a message > box with title "vs_haskell.dll" and see the message inside it. I don't see anything with title vs_haskell.dll in Spy++. Is is meant to be a child of the Visual Studio window? Any other suggestions? 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] ANNOUNCE: Visual Haskell 0.2 final
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Krasimir Angelov > > The final version of Visual Haskell 0.2 is ready: > > http://www.haskell.org/visualhaskell > > This is the first version that is: >- available for both VStudio 2003 and VStudio 2005 >- distributed with a stable GHC version (6.6) >- the plugin itself is much more stable than its first 0.0 version I'm trying to use this, but it seems to hang whenever I try to do a build (or a clean). Is there some way I can debug it to see why/where it's stuck? There's no build output in the output window. 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: OPTIONS_GHC -auto-all
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Serge D. Mechveliani
>
> Now, I improve the typo and enter
>
> {-# OPTIONS_GHC -fglasgow-exts -prof -auto-all #-}
>
> in order to force -auto-all for a certain particular module.
> It still reports
> LemmaSearch.hs:
> unknown flags in {-# OPTIONS #-} pragma: -prof -auto-all
>
> Who knows, please, what is the matter?
This page explains the difference between static and dynamic flags:
http://www.haskell.org/ghc/docs/latest/html/users_guide/static-dynamic-f
lags.html
And this page tells you that the profiler options are static only, which
means you can only tell GHC about them on the command line:
http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.h
tml#id3155578
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.
*
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: hsman
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Neil Mitchell > > > - command-line autocompletion > > No, how do I add it? I use Windows which doesn't support this, but if > someone gives me the technical details of how to do it, I'm sure I can > add it. How would it work on Unix? I assume that the command-line program just takes it's input "from the command line", so it doesn't get invoked until after you've finished typing the command... Unless this is a proposal to create a console version of hoogle, a bit like ghci, which could take advantage of System.Console.Readline. BTW, on Windows XP command line filename completion is enabled - just use the Tab key. On NT4 and W2K you have to tweak the registry to switch it on (and you can choose which key to use, if you don't like Tab). 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ld.exe distributed with Windows ghc-6.4.1 buggy?
(MS Windows) GHC users, I've experienced a small problem with the version of ld that ships with GHC-6.4.1 for Windows. I used it to build a Postgres sample C program, and the resulting executable segfaults on a certain line. The same program works correctly when linked with the version of ld (a slightly older one) that comes with my Mingw installation. The respective ld versions are: Ghc-6.4.1: 2.15.91 20040904 Mingw: 2.13.90 20030111 For now I've just replaced the ld.exe in C:\ghc\ghc-6.4.1\gcc-lib\ with the Mingw one, and it's all good. Simons (when you return from holiday): is it worth persuing a narrower test case? (one that doesn't require you to install Postgres to reproduce :-) 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.4.1 barfs building haskell-src-exts on MingW/WinXP
Hello all, I'm trying to build haskell-src-exts-0.2 with GHC 6.4.1 under MingW on WinXP. It segfaults on the "runhaskell Setup.hs build" command (in the src/haskell-src-exts subdir). Does anyone else get this, or is it just me? sh-2.04$ runhaskell Setup.hs build -v5 Preprocessing library haskell-src-exts-0.2... c:\happy\happy-1.13\bin\happy.exe -agc -oLanguage\Haskell\Hsx\Parser.hs Language\Haskell\Hsx\Parser.ly shift/reduce conflicts: 5 Building haskell-src-exts-0.2... [segfault: instruction at 0 ref'd memory at 0] sh-2.04$ How do I modify the Cabal setup to get GHC -v output (so I can see which module it fails on)? Alistair. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Character index vs Column number in GHC error messages
> From: Krasimir Angelov [mailto:[EMAIL PROTECTED] > > The difference comes from the tab > characters which can have different width depending from the editor > settings. For such reason all compilers, which I am aware of, display > the character index instead of column number. ... GHC displays the > column number instead and this confuses the editors. Dude! Don't use tabs :-) * 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: error in your article? about meaning of safe/unsafe in "forei gn import"
> From: Bulat Ziganshin [mailto:[EMAIL PROTECTED] > > and one more question: is it possible to download sources of http > server mentioned in this article? i want to browse the code, it's no > matter how it compiles and works I believe the web-server mentioned became HWS: http://cvs.sf.net/viewcvs.py/haskell-libs/libs/hws-wp/hws-wp/src/ (I don't see any error/inconsistency in the two quotes; they just seem to be talking about different things. SPJ's quote is about declaring "pure" FFI functions, while the FFI quote is about enabling callbacks into Haskell code. Can you elaborate?) 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Linker errors when using FFI on Windows
That did it, thanks. Instead of using ghc's -L/-l flags, I used: -optl c:\windows\system32\ntwdblib.dll > -Original Message- > From: Sigbjorn Finne [mailto:[EMAIL PROTECTED] > Sent: 28 April 2005 01:04 > To: Bayley, Alistair > Cc: glasgow-haskell-users@haskell.org > Subject: Re: Linker errors when using FFI on Windows > > Adding the -Lc:\windows\system32 option when linking upsets > the resolution of misc standard libraries, causing 'ld' to > use the DLLs > rather than the mingw link libraries, including msvcrt.dll. > > Try just using c:/windows/system32/ntwdblib.dll on the link > line instead. > If ld's DLL auto-import support doesn't quite work, attempting to link > with the import library 'ntwdblib' (ntwdblib.lib ?) instead > is worth a shot. > The SQL Server SDK ought to include that somewhere. > > hth > --sigbjorn > > - Original Message - > From: "Bayley, Alistair" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, April 27, 2005 08:10 > Subject: Linker errors when using FFI on Windows > > > > I'm trying to link an FFI program against a Windows (XP) DLL > > (c:\windows\system32\ntwdblib - this is the MS Sql Server > client library). > > The output from ghc6.4 -v is below; the errors start in the Linker > > section. > > > > Comments: > > > > - Where do these objects dxx.o come from? (They're not in my > > source...) > > > > d13.o(.text+0x0): multiple definition of `_onexit' > > c:/ghc/ghc-6.4/gcc-lib/crt2.o(.text+0x2a0):crt1.c: first > defined here > > d18.o(.text+0x0): multiple definition of `atexit' > > c:/ghc/ghc-6.4/gcc-lib/crt2.o(.text+0x280):crt1.c: first > defined here > > > > > > - Have I omitted some important linker flag? There are tons of these > > undefined references from crt2.o, like this: > > > > c:/ghc/ghc-6.4/gcc-lib/crt2.o(.text+0x238):crt1.c: > undefined reference to > > [EMAIL PROTECTED]' > > > > > > Thanks, > > 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Linker errors when using FFI on Windows
I'm trying to link an FFI program against a Windows (XP) DLL (c:\windows\system32\ntwdblib - this is the MS Sql Server client library). The output from ghc6.4 -v is below; the errors start in the Linker section. Comments: - Where do these objects dxx.o come from? (They're not in my source...) d13.o(.text+0x0): multiple definition of `_onexit' c:/ghc/ghc-6.4/gcc-lib/crt2.o(.text+0x2a0):crt1.c: first defined here d18.o(.text+0x0): multiple definition of `atexit' c:/ghc/ghc-6.4/gcc-lib/crt2.o(.text+0x280):crt1.c: first defined here - Have I omitted some important linker flag? There are tons of these undefined references from crt2.o, like this: c:/ghc/ghc-6.4/gcc-lib/crt2.o(.text+0x238):crt1.c: undefined reference to [EMAIL PROTECTED]' Thanks, Alistair. -- ghc -v -Wall -keep-hc-file -ddump-hi"-Lc:\windows\system32" -lntwdblib "-IC:\Program Files\Microsoft SQL Server\80\Tools\DevTools\Include" -odir ..\out -hidir ..\out -o takusen --make Main Glasgow Haskell Compiler, Version 6.4, for Haskell 98, compiled by GHC version 6.2.2 Using package config file: c:\ghc\ghc-6.4\package.conf Hsc static flags: -static *** Chasing dependencies: Chasing modules from: Main *** Literate pre-processor c:\ghc\ghc-6.4\unlit.exe -h Main.lhs Main.lhs C:\DOCUME~1\bayleya\LOCALS~1\Temp\ghc1016.lpp *** Literate pre-processor c:\ghc\ghc-6.4\unlit.exe -h ./Database/MSSqlServer/Test/MSSqlFunctions.lhs .\Database\MSSqlServer\Test\MSSqlFunctions.lhs C:\DOCUME~1\bayleya\LOCALS~1\Temp\ghc1017.lpp *** Literate pre-processor c:\ghc\ghc-6.4\unlit.exe -h ./Database/MSSqlServer/MSSqlFunctions.lhs .\Database\MSSqlServer\MSSqlFunctions.lhs C:\DOCUME~1\bayleya\LOCALS~1\Temp\ghc1018.lpp Stable modules: *** Compiling Database.MSSqlServer.MSSqlFunctions ( ./Database/MSSqlServer/MSSqlFunctions.lhs, ..\out/Database/MSSqlServer/MSSqlFunctions.o ): compile: input file C:/DOCUME~1/bayleya/LOCALS~1/Temp/ghc1018.lpp *** Checking old interface for Database.MSSqlServer.MSSqlFunctions: Compiling Database.MSSqlServer.MSSqlFunctions ( ./Database/MSSqlServer/MSSqlFunctions.lhs, ..\out/Database/MSSqlServer/MSSqlFunctions.o ) *** Parser: *** Renamer/typechecker: ./Database/MSSqlServer/MSSqlFunctions.lhs:97:14: Warning: Defined but not used: `sess' ./Database/MSSqlServer/MSSqlFunctions.lhs:97:19: Warning: Defined but not used: `severity' ./Database/MSSqlServer/MSSqlFunctions.lhs:97:34: Warning: Defined but not used: `oserr' ./Database/MSSqlServer/MSSqlFunctions.lhs:97:49: Warning: Defined but not used: `oserrstr' ./Database/MSSqlServer/MSSqlFunctions.lhs:103:14: Warning: Defined but not used: `sess' ./Database/MSSqlServer/MSSqlFunctions.lhs:103:19: Warning: Defined but not used: `msgno' ./Database/MSSqlServer/MSSqlFunctions.lhs:103:25: Warning: Defined but not used: `msgstate' ./Database/MSSqlServer/MSSqlFunctions.lhs:103:34: Warning: Defined but not used: `severity' ./Database/MSSqlServer/MSSqlFunctions.lhs:103:51: Warning: Defined but not used: `srvname' ./Database/MSSqlServer/MSSqlFunctions.lhs:103:59: Warning: Defined but not used: `procname' ./Database/MSSqlServer/MSSqlFunctions.lhs:103:68: Warning: Defined but not used: `line' *** Desugar: Result size = 973 *** Simplify: Result size = 1273 Result size = 1145 Result size = 1145 *** Tidy Core: Result size = 1145 *** CorePrep: Result size = 1353 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** C Compiler c:\ghc\ghc-6.4\gcc -Bc:\ghc\ghc-6.4\gcc-lib/ .\Database\MSSqlServer\MSSqlFunctions_stub.c -o C:\DOCUME~1\bayleya\LOCALS~1\Temp\ghc1016.s -DDONT_WANT_WIN32_DLL_SUPPORT -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=604 -DDBNTWIN32 -ffloat-store -I ./Database/MSSqlServer -I C:\Program Files\Microsoft SQL Server\80\Tools\DevTools\Include -I c:/ghc/ghc-6.4/include -I c:/ghc/ghc-6.4/include/mingw Reading specs from c:/ghc/ghc-6.4/gcc-lib/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c++,f77,objc --disable-win32-registry --disable-shared --enable-sjlj-exceptions Thread model: win32 gcc version 3.2.3 (mingw special 20030504-1) c:\ghc\ghc-6.4\gcc-lib\cc1.exe -lang-c -v -I ./Database/MSSqlServer -I C:\Program Files\Microsoft SQL Server\80\Tools\DevTools\Include -I c:/ghc/ghc-6.4/include -I c:/ghc/ghc-6.4/include/mingw -iprefix c:\ghc\ghc-6.4\../lib/gcc-lib/mingw32/3.2.3/ -isystem c:/ghc/ghc-6.4/gcc-lib/include -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=3 -D__GXX_ABI_VERSION=102 -D_WIN32 -D__WIN32 -D__WIN32__ -DWIN32 -D__MINGW32__ -D__MSVCRT__ -DWINNT -D_X86_=1 -D_WIN32 -D__WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__ -D__MSVCRT__ -D__WINNT__ -D_X86_=1 -D__WIN32 -D__WINNT -Asystem=winnt -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i586__ -D__tune_pentium__ -D__stdcall=__attribute__((__stdcall__)) -D__cd
RE: Help with a Shootout program
Here's your program, but a little slimmer. I think size counts for something in the shootout. Still runs at the same speed though :-( The program seems to spend about 50% reading the files, 22% building the hash table (7% chopping input into lines, 11% inserting into table), 25% spellchecking (11% chopping input into lines, 12% hash lookup). So until String IO gets a bit faster, you're stuck. You could look into using Peter Simons' BlockIO, and operating over bytes rather than chars. But then you'd have to include that in the submitted code, because it's not part of the standard libraries. module Main where import Data.HashTable import System.IO buildHash input = do table <- new (==) hashString sequence_ [ insert table w True | w <- lines input ] return table check :: HashTable String Bool -> String -> IO () check table w = do r <- Data.HashTable.lookup table w maybe (putStrLn w) (const $ return ()) r spellcheck table input = sequence_ [ check table w | w <- lines input ] main = do table <- (readFile "Usr.Dict.Words" >>= buildHash) hGetContents stdin >>= spellcheck table - * 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Help with a Shootout program
> From: Simon Marlow [mailto:[EMAIL PROTECTED]
>
> PackedStrings are still slow in 6.x. I know there are various other
> PackedString implementations out there, we just need to
> incorporate one.
They certainly seem to be. Below are the profiles (compiled with -O2; ran
them twice; took the second run) of Simon's old PackedString version, and
Alson's Hash version. Simon's uses way more memory, too. I might try some
more profiling later to narrow down the slow bits.
> From: Alson Kemp [mailto:[EMAIL PROTECTED]
>
> I tried Simon's version, but it throws a "Fail:
> Ix{Int}.index: Index
> (5) out of range ((0,4))" error. Haven't tracked down the cause yet.
Here's the fix (subtract one from (lengthPS ps)):
-- Looks bad, but GHC does a great job of optimising it:
hashPS :: PackedString -> Int
hashPS ps = foldr f 0 (map (ord.indexPS ps) [0..((lengthPS ps) - 1)])
where f n m = n + m * 128 `mod` 1048583
--- Alson's:
spellcheck +RTS -p -hr -H10m -K20m -RTS
total time =1.84 secs (92 ticks @ 20 ms)
total alloc = 69,112,588 bytes (excludes profiling overheads)
COST CENTREMODULE %time %alloc
main Main 58.7 21.2
spellcheck Main 23.9 34.2
buildHash Main 17.4 44.6
individualinherited
COST CENTREMODULE no.entries %time %alloc %time
%alloc
MAIN MAIN 1 0 0.00.0 100.0
100.0
main Main146 1 58.7 21.2 100.0
100.0
spellcheck Main149 0 23.9 34.223.9
34.2
buildHashMain148 1 17.4 44.617.4
44.6
CAF Main140 1 0.00.0 0.0
0.0
main Main147 0 0.00.0 0.0
0.0
CAF GHC.Handle 103 6 0.00.0 0.0
0.0
CAF System.Posix.Internals 81 4 0.00.0 0.0
0.0
--- Simon's:
spellcheck +RTS -p -hr -H10m -K20m -RTS
total time =6.90 secs (345 ticks @ 20 ms)
total alloc = 351,514,332 bytes (excludes profiling overheads)
COST CENTREMODULE %time %alloc
main Main 93.0 93.6
hashPS Main 3.22.4
elemHashTable Main 2.00.1
addToHashTable Main 1.70.2
CAFData.PackedString 0.03.6
individualinherited
COST CENTRE MODULEno.entries %time %alloc %time
%alloc
MAIN MAIN1 0 0.00.0 100.0
100.0
mainMain 166 1 93.0 93.6 100.0
96.4
elemHashTable Main 171 38618 2.00.1 2.9
1.3
hashPSMain 172 38618 0.91.2 0.9
1.2
addToHashTable Main 168 38617 1.70.2 4.1
1.4
hashPSMain 169 38617 2.31.2 2.3
1.2
CAF Main 160 4 0.00.0 0.0
0.0
hashPS Main 170 0 0.00.0 0.0
0.0
main Main 167 0 0.00.0 0.0
0.0
CAF GHC.Handle123 5 0.00.0 0.0
0.0
CAF System.Posix.Internals 101 4 0.00.0 0.0
0.0
CAF Data.PackedString 86 1 0.03.6 0.0
3.6
-
*
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.
*
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Problem with DB and Char size (2)
Actually... there is a "native" Oracle driver, or rather, one that uses the OCI. It's usable, but certainly not complete. http://cvs.sourceforge.net/viewcvs.py/haskell-libs/libs/takusen/src/ However, I've only tested it with bog-standard ASCII Cstrings (my NLS_LANG setting specifies WE8ISO8859P1), so I've no idea how well it works with Unicode. Have you tried fiddling with your NLS_LANG environment variable? This determines the charset your data is converted to when sent from the DBMS to the client. You can set it either in a .bat script (just for that session), or modify the registry setting in: HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\HOME0 What's it currently set to? Alistair. > -Original Message- > From: Santoemma Enrico [mailto:[EMAIL PROTECTED] > Sent: 27 January 2005 16:49 > To: Krasimir Angelov > Cc: glasgow-haskell-users@haskell.org > Subject: R: Problem with DB and Char size (2) > > This is exactly what happens: > (btw, the same thing happens in Python, so the trouble must > be in the Oracle odbc driver. But this is also what happens > today to any Haskell business application which connects to > Oracle, as - to my knowledge - there is no native Oracle > driver for Haskell) > > ... > stmt0 <- query c $ "select 'Ã' as TEST from dual" > stmt1 <- query c $ "select '" ++ chr(195):chr(131):[] ++ "' > as TEST from dual" > stmt2a<- query c $ "select '" ++ [chr(195*256 + 131)] ++ "' > as TEST from dual" > stmt2b<- query c $ "select '" ++ [chr(131)] ++ "' as TEST from dual" > stmt3 <- query c $ "select chr(195*256 + 131) as TEST from dual" > ... > > after execution on a UTF-8 Oracle9i instance: > 0: "TEST", "\195\131" > 1: "TEST", "\195\131\198\146" > 2a: "TEST", "\198\146" > 2b: "TEST", "\198\146" > 3: "TEST", "\195\131" > > 0 is the reference: UTF-8 encoding of an A with a tilde on the top. > 1 is UTF-8 encoding (by Oracle) of an already encoded UTF-8 string > 2a and 2b show that the high byte is stripped: \198\146 is > the UTF-8 encoding of chr(131) > 3 is the only (almost useless) workaround I've found. > > Of course, with 3 byte chars things get even more confused. > > Enrico > > > > -Messaggio originale- > Da: Krasimir Angelov [mailto:[EMAIL PROTECTED] > Inviato: giovedì 27 gennaio 2005 15.41 > A: glasgow-haskell-users@haskell.org > Oggetto: Re: Problem with DB and Char size (2) > > > On Thu, 27 Jan 2005 06:34:40 -0800, John Meacham > <[EMAIL PROTECTED]> wrote: > > On Thu, Jan 27, 2005 at 04:23:52PM +0200, Krasimir Angelov wrote: > > > HSQL uses withCString internally. withCString strips the > higher order > > > bytes from Char. > > > > You should be able to replace withCString with > withUTF8String from my > > CWStringBasic module, which you can get from here: > > http://repetae.net/john/recent/src/HsLocale/CWStringBasic.hs > > > > and is part of my bigger HsLocale project > http://repetae.net/john/recent/out/HsLocale.html > > but just that one file should be enough if all you need is UTF8. > >John > > Santoemma Enrico said that Oracle ODBC driver expects UCS-2 instead of > UTF-8 so this will not help. > > Krasimir - * 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. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Profiling makes FFI Marshalling of Doubles and Int64s fail
Thanks, including the header does fix it. I was lazy, as you can link quite easily against a DLL without having to provide a header; just the import decls suffice, plus -l and -L directives. I have had this problem (not using the -I directive) in a different guise, when trying to optimise. I've added the header to the foreign import decls e.g. foreign import "sqlite.h sqlite3_open" ... I left it out earlier because this version of the Sqlite library ships just as a DLL, with no accompanying header. I downloaded the source and found one I could use (I *hope* it's the right one), but it does make you wonder what C (and other) programmers who want to use the library are expected to do... Alistair. -Original Message- From: Roberto Zunino [mailto:[EMAIL PROTECTED] AFAICS, it seems as the asm code generator knows about the Haskell types and therefore knows how to fetch the bits correctly, while the via-C code generator simply uses the C function calls (without prototypes), so functions return types are defaulted to int. Also, you can try adding -Wall and see if the C compiler warns about this (mine does). The GHC user's guide (section 8.2.2) is also insightful. It seems that using C headers is pretty much required, or, as the guide itself says, "You're crazy not to do it". ;-) Regards, Roberto Zunino. - * 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. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Profiling makes FFI Marshalling of Doubles and Int64s fail
I've built a small test case. When I compile with:
ghc Main.hs test.c -o Main.exe
... the (correct) output from Main.exe is:
123.0
5678901234567890
And when I compile with:
ghc -prof Main.hs test.c -o Main.exe
... the (incorrect) output from Main.exe is:
1.0
986516178
-- Main.hs:
{-# OPTIONS -ffi #-}
module Main where
import Foreign.C
foreign import ccall "myDouble" myDouble :: IO CDouble
foreign import ccall "myInt64" myInt64 :: IO CLLong
main = do
d <- myDouble
putStrLn $ show d
l <- myInt64
putStrLn $ show l
-- test.c:
double myDouble() {
double d = 123.0;
return d;
}
long long myInt64() {
long long x = 5678901234567890;
return x;
}
-
*
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.
*
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Profiling makes FFI Marshalling of Doubles and Int64s fail
I'm using the newer v3 API, which has functions to get column values as String, Int, Double, Int64, etc. It also has a prepare/step/finalise trio of functions for doing queries, which suits me better. Alistair. > -Original Message- > From: Krasimir Angelov [mailto:[EMAIL PROTECTED] > Sent: 13 September 2004 12:28 > To: Bayley, Alistair; [EMAIL PROTECTED] > Subject: RE: Profiling makes FFI Marshalling of Doubles and > Int64s fail > > > --- "Bayley, Alistair" > <[EMAIL PROTECTED]> wrote: > > > Thanks Krasimir. I did have a look at your code, but > > I don't see any foreign > > types other than CString and Int, which work OK for > > me regardless of > > profiling option. (BTW, you tend to use Int rather > > than CInt - is this > > safe?) > > Good suggestion. Have done in the CVS. SQLite returns > all fetched values as strings. Are you sure that you > read them as strings? > > Cheers, > Krasimir - * 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. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Profiling makes FFI Marshalling of Doubles and Int64s fail
Thanks Krasimir. I did have a look at your code, but I don't see any foreign types other than CString and Int, which work OK for me regardless of profiling option. (BTW, you tend to use Int rather than CInt - is this safe?) I guess I should build a small C library which uses CDouble and CLLong, just to make sure the problem isn't with the Sqlite dll. > -Original Message- > From: Krasimir Angelov [mailto:[EMAIL PROTECTED] > Sent: 13 September 2004 10:53 > To: Bayley, Alistair; [EMAIL PROTECTED] > Subject: Re: Profiling makes FFI Marshalling of Doubles and > Int64s fail > > > --- "Bayley, Alistair" > <[EMAIL PROTECTED]> wrote: > > > (using GHC 6.2.1 under Windows XP) > > > > I'm trying to use the Sqlite (version 3) dll - see > > http://www.sqlite.org/ . > > Hi Alistair, > > HSQL already provides binding to sqlite. I don't know > whether you will have the same problem with profiling > version of HSQL but you can try. > > Cheers, > Krasimir - * 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. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Profiling makes FFI Marshalling of Doubles and Int64s fail
(using GHC 6.2.1 under Windows XP) I'm trying to use the Sqlite (version 3) dll - see http://www.sqlite.org/ . Marshalling of 32-bit ints and Strings works well, but 64-bit Ints and Doubles fail (I get garbage back from the FF calls) when I compile with "-prof -auto-all". If I compile without profiling, everything works as I expect. When I try to load the compiled (with -prof) object files in GHCi, it fails with this error message: Compiling TestCase ( TestCase.lhs, interpreted ) ghc.exe: panic! (the `impossible' happened, GHC version 6.2.1): ByteCodeFFI.mkMarshalCode_wrk(x86) LI_ Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. GHCi works correctly with non-profiled object files. Thanks, 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. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Marshalling Haskell String <-> UTF-8
> From: George Russell [mailto:[EMAIL PROTECTED] > > http://www.haskell.org//pipermail/glasgow-haskell-users/2004-April/006 > 564.html Thanks George, this looks useful. There are some things I want to clarify... module UTF8( toUTF8, -- :: String -> String -- Converts a String (whose characters must all have codes <2^31) into -- its UTF8 representation. fromUTF8WE, -- :: Monad m => String -> m String -- Converts a UTF8 representation of a String back into the String, -- catching all possible format errors. Does toUTF8 return a String whose Chars are all code-points < 256, which, when converted to bytes, will represent a UTF-8 string? Likewise, does fromUTF8WE expect a String whose Chars are all code-points < 256 i.e. they are the result of saying "chr n" for each byte in the UTF-8 stream? > From: Simon Marlow [mailto:[EMAIL PROTECTED] > > In any case, none of this allows you to specify a UTF-8 conversion. Are there plans to add UTF-8 (and UTF-16) conversion functions to the libraries? I imagine they would be useful... > Your best bet is to marshal it yourself. We're a bit behind in this > area: 6.2.x doesn't have CAString and CWString, and CString is just > char*. The HEAD has CAString and CWString, and will hopefully follow > the FFI spec by the time we release 6.4 (we still have to do the > locale encoding/decoding between CString and String, IIRC). Again, I want to clarify some things... - will any encoding/decoding be performed by the peekCString/withCString/newCString(Len) functions? i.e. if I want to avoid encoding/decoding (because I know my string is already in UTF-8) then I simply have to avoid using these functions? - can I still declare the foreign functions with CString types without worrying that encoding/decoding might be attempted? - when the CAString functions are available then I should use them, but for now I will have to write something that uses castCharToCChar/castCCharToChar + peekArray0/pokeArray0. Thanks, 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. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Marshalling Haskell String <-> UTF-8
I want to call a foreign C function that takes a UTF-8 encoded string as one of its arguments (and there's also a version of the function that receives UTF-16). Can someone point me to documentation or examples of how this would be done? AFAICT (reading the FFI spec) marshalling a String to a CString is locale-dependent, whereas I know that I want UTF-8/16. Also, if a C function returns a UTF-8 (or UTF-16) encoded string, how do I marshall this reliably into a Haskell String? Can I use the UTF-16 functions directly with CWStrings? (I'm not sure exactly what wchar_t is, as it's apparently dependent on the locale at compile-time, and could be 8, 16, or 32 bits). Thanks, 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. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: prebuilt Haddock for Windows
I have one, although I'm not sure how best to get it to you. I don't have a website, but if you point me to an ftp site I could upload it. Or I could try emailing you a zip file... It's not hard to build, but I did it with Cygwin installed - I don't know if you have this. > -Original Message- > From: Gracjan Polak [mailto:[EMAIL PROTECTED] > Sent: 20 August 2004 14:08 > To: Simon Marlow > Cc: [EMAIL PROTECTED] > Subject: Re: cvsweb back up > > > > Simon Marlow wrote: > > > On 20 August 2004 12:04, Gracjan Polak wrote: > > > > > >>Is there any haddoc documentation for GHC (compiler part, > not >>libraries)? I still have trouble finding my way > through the source... > > > > > > Sorry, no. You could probably run Haddock on the source, > although we've > never tried and there isn't any actual > documentation. > > I did want to do this myself, but I did not manage to compile > haddoc under Windows :(. > > Is there anybody having pre-build haddoc for windows? Or > guide how to do this myself? > > > There's the > > commentary which may help: > > > > http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/ > > > > Thanks, I'm going to read it :) > > > Cheers, > >Simon - * 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. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Network, sClose
> -Original Message- > From: Glynn Clements [mailto:[EMAIL PROTECTED] > > However, even if sClose was exported, that wouldn't be of any > help in Jon's case, as neither of the sockets which recvFrom > creates are visible outside of recvFrom. Ahh, OK. I haven't used recvFrom/sendTo yet... (trying it now) ... When I try Jon's example with 6.2.1 (Win XP) I don't get the same error; it works twice and then hangs (my networking code would hang if I tried to re-use a socket that hadn't been properly closed). Is recvFrom meant to be a one-shot function i.e. the socket is only closed when the process exits? Jon's second example uses listenOn/accept and handles, which is also what I used: >do sock <- listenOn$PortNumber 7607; (hdl,host,port)<- accept sock; > s<-IO.hGetContents hdl; putStr$s; IO.hClose hdl; Network.Socket.sClose > sock Network.Socket.sClose is obviously useful here, so don't you think it would be a good idea to put it in Network? I don't see why including sClose would imply that you should start exposing other low-level stuff. AFAICT, it is the one little thing that's missing from Network that makes writing simple networking code possible. There's a lack of symmetry (closure?): you can create a socket with Network.listenOn, but there is no corresponding close function in Network. - * 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. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Network, sClose
> -Original Message- > From: Glynn Clements [mailto:[EMAIL PROTECTED] > Sent: 10 August 2004 19:06 > To: Jon Fairbairn > Cc: [EMAIL PROTECTED] > > > > * Shouldn't sClose be reexported from Network? > > Once you start down that route, you end up at the inevitable > conclusion that everything from the raw syscall imports > upwards needs to be re-exported. > > > * is there a general way to get ghci out of a state where > > it's got stuff open on inaccessible sockets? > > The solution to most problems with the Network module is not > to use the Network module, but to use Network.Socket instead. I had a similar (same?) problem while playing with networking, which was that you could open a socket and do stuff to it with just the functions from Network, but to properly close it you had to use Network.Socket.sClose. It also struck me as odd that Network exported all I needed to use sockets *except* sClose. 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. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Using GHC and FFI
> After that I wrote ghc -fffi -c test.lhs. But when I call > blah from ghci I get the error message: "test.o unknown symbol '_test' > > I think ghc doen't link test.o to projekt.obj. What do I have to do? I don't know about linking object files I've created myself, but to link an existing library (a .dll on my Windows system) I use these options: -L/path/to/library/file -lprojekt -I/path/to/header/include/directory/if/it/exists If the object file is in the same dir as test.lhs then you might get away with just the -l option. Also, you might have to rename projekt.obj to projekt.o (I don't know if this matters or not). See GHC Users Guide "4.10.7. Options affecting linking", for -L and -l: http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html# OPTIONS-LINKER And see "4.10.3 Options affecting the C pre-processor", for -I: http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html# C-PRE-PROCESSOR I believe you only need to use -I if you're compiling via-c (which happens if you use -O). - * 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. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Prelude/main magicks?
> By using an explicit Lava compiler you declare that this is > indeed a Lava > program, and you don't expect it to work in any other > setting, in particular > not with a Haskell compiler like GHC. > > ... > > And in the same line of thinking, I would want a way of > specifying suffixes > of input source files. It would be much neater to call your > files Foo.lava > or similar, and be able to tell GHC to treat them as normal > .hs files, i.e. Where is the difficulty in writing lavac as a program which: - generates .hs files from .lava - inserts appropriate import statements - invokes GHC "as the back end"? This seems to be a nicer (more modular?) solution than contorting GHC. And I think it would make it easier to use other Haskell compilers, should you wish too. - * 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. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.2.1 retaining profiling broken?; program segfaults with -hr flag
I've tried to get a heap retaining profile (-hr) of my (largish) program with GHC 6.2.1 (on Windows NT4), but it segfaults when run. I can produce a -hc profile without grief. Is this a known problem? P.S. I've trimmed my program back a bit to provide a test case (and to remove FFI code), but there are still five modules involved. - * 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. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.2.1 compilation fails when compiling FFI code with -pro f or -O2
Sorry for the stupidity... just found the -I option... Although it is a bit frustrating when an FFI program that used to compile stops when you add supposedly "harmless" options such as -O or -prof. Might be worth adding a section to the FFI section of the manual about using the -I flag when compiling via C, as -I is not needed when you compile with native code generation. And a mention in the FFI section that -prof and -O will change the compilation strategy from native to via-C (thus possibly requiring the addition of the -I flag) would be nice, although I realise that's duplicating information available elsewhere. (Actually, compiling via C has been valuable for me because the C compiler moaned about a foreign function being called with too few args, which was the result of an incorrect "foreign import" declaration i.e. the C compiler found a bug in my Haskell code, which the GHC native code-generator wouldn't have picked up. Plus it gives warnings on other dodgy things I'm doing. Better fix 'em...) Alistair. > -Original Message- > From: Bayley, Alistair [mailto:[EMAIL PROTECTED] > > > The "oci.h" file in question is located in > c:\orant817\oci\include, and > oci.dll is located in c:\orant817\bin. When I compiled with > -prof I tried > adding -#include c:\orant817\oci\include\oci.h, but this > produces the output > below, where files included by oci.h can't be found. The > oci.h file is at > the root of quite a large .h include tree; do I have to > specify every .h > file in this tree with -#include? - * 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. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.2.1 compilation fails when compiling FFI code with -prof or -O2
I have an FFI program which compiles fine with GHC 6.2.1 under standard compilation options (i.e. no optimisation etc), but not with -O2 or -prof. With -prof/-O2 GHC compiles via C, and this seems to be causing the problem. With -prof I get these error messages: Compiling Database.Oracle.OCIFunctions ( ./Database/Oracle/OCIFunctions.lhs, ./Database/Oracle/OCIFunctions.o ) C:/TEMP/ghc202.hc:5:17: oci.h: No such file or directory C:/TEMP/ghc202.hc: In function `r2Zg_entry': C:/TEMP/ghc202.hc:133: warning: implicit declaration of function `OCIStmtFetch' C:/TEMP/ghc202.hc: In function `r2Zi_entry': C:/TEMP/ghc202.hc:337: warning: implicit declaration of function `OCIStmtExecute' ...etc... With -O2 I get these: Compiling Database.Oracle.OCIFunctions ( ./Database/Oracle/OCIFunctions.lhs, ./Database/Oracle/OCIFunctions.o ) C:/TEMP/ghc311.hc:5:17: oci.h: No such file or directory C:/TEMP/ghc311.hc: In function `DatabaseziOracleziOCIFunctions_zdwccall_entry': C:/TEMP/ghc311.hc:1295: warning: implicit declaration of function `OCIStmtFetch' C:/TEMP/ghc311.hc: In function `DatabaseziOracleziOCIFunctions_zdwccall1_entry': C:/TEMP/ghc311.hc:1480: warning: implicit declaration of function `OCIStmtExecute' ...etc... I've used these command line options for normal (no -prof or -O) compilation: -Lc:\orant817\bin -loci The "oci.h" file in question is located in c:\orant817\oci\include, and oci.dll is located in c:\orant817\bin. When I compiled with -prof I tried adding -#include c:\orant817\oci\include\oci.h, but this produces the output below, where files included by oci.h can't be found. The oci.h file is at the root of quite a large .h include tree; do I have to specify every .h file in this tree with -#include? My ghc command: ghc -v -Wall -ddump-hi -prof -Lc:\orant817\bin -loci -#include c:\orant817\oci\include\oci.h -fasm -o ociffi --make Main.lhs Output: *** CodeOutput: *** C Compiler c:\ghc\ghc-6.2.1\gcc -Bc:\ghc\ghc-6.2.1\gcc-lib/ -x c C:\TEMP\ghc319.hc -o C:\TEMP\ghc319.raw_s -DDONT_WANT_WIN32_DLL_SUPPORT -fno-defer-pop -mno-omit-leaf-frame-pointer -fomit-frame-pointer -fno-builtin -DSTOLEN_X86_REGS=4 -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=602 -DPROFILING -ffloat-store -I . -I c:/ghc/ghc-6.2.1/include -I c:/ghc/ghc-6.2.1/include/mingw Reading specs from c:/ghc/ghc-6.2.1/gcc-lib/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=f77,c++,objc,ada --disable-win32-registry --disable-shared Thread model: win32 gcc version 3.2 (mingw special 20020817-1) c:\ghc\ghc-6.2.1\gcc-lib\cc1.exe -lang-c -v -I . -I c:/ghc/ghc-6.2.1/include -I c:/ghc/ghc-6.2.1/include/mingw -iprefix c:\ghc\ghc-6.2.1\../lib/gcc-lib/mingw32/3.2/ -isystem c:/ghc/ghc-6.2.1/gcc-lib/include -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -D_WIN32 -D__WIN32 -D__WIN32__ -DWIN32 -D__MINGW32__ -D__MSVCRT__ -DWINNT -D_X86_=1 -D_WIN32 -D__WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__ -D__MSVCRT__ -D__WINNT__ -D_X86_=1 -D__WIN32 -D__WINNT -Asystem=winnt -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i586__ -D__tune_pentium__ -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__fastcall=__attribute__((__fastcall__)) -D_stdcall=__attribute__((__stdcall__)) -D_cdecl=__attribute__((__cdecl__)) -D_fastcall=__attribute__((__fastcall__)) -D__declspec(x)=__attribute__((x)) -DDONT_WANT_WIN32_DLL_SUPPORT -DSTOLEN_X86_REGS=4 -D__GLASGOW_HASKELL__=602 -DPROFILING C:\TEMP\ghc319.hc -quiet -dumpbase ghc319.hc -mno-omit-leaf-frame-pointer -O -Wimplicit -version -fno-defer-pop -fomit-frame-pointer -fno-builtin -ffloat-store -o C:\TEMP\ghc319.raw_s GNU CPP version 3.2 (mingw special 20020817-1) (cpplib) (80386, BSD syntax) GNU C version 3.2 (mingw special 20020817-1) (mingw32) compiled by GNU C version 3.2. ignoring nonexistent directory "c:/ghc/lib/gcc-lib/mingw32/3.2/../../../../include" ignoring nonexistent directory "c:/ghc/lib/gcc-lib/mingw32/3.2/include" ignoring nonexistent directory "c:/ghc/lib/gcc-lib/mingw32/3.2/../../../../mingw32/include" ignoring nonexistent directory "/mingw/lib/gcc-lib/mingw32/3.2/../../../../include" ignoring nonexistent directory "/mingw/include" ignoring nonexistent directory "/mingw/lib/gcc-lib/mingw32/3.2/include" ignoring nonexistent directory "/mingw/lib/gcc-lib/mingw32/3.2/../../../../mingw32/include" ignoring nonexistent directory "/usr/local/mingw32/include" #include "..." search starts here: #include <...> search starts here: . c:/ghc/ghc-6.2.1/include c:/ghc/ghc-6.2.1/include/mingw c:/ghc/ghc-6.2.1/gcc-lib/include End of search list. In file included from C:/TEMP/ghc319.hc:5: c:/orant817/oci/include/oci.h:261:23: oratypes.h: No such file or directory c:/orant817/oci/include/oci.h:265:20: ocidfn.h: No such file or directory In file included from C:/TEMP/ghc319.hc:5: c:/ora
RE: [Haskell-cafe] Building Haddock on Windows
> Try upgrading GHC. Thanks, I'll try that. Would it be too much to ask that Haddock be distributed with GHC? Reasons for: - GHC library docs are produced with Haddock - GHC library docs already include Haddock interface files - would ensure version of Haddock matches that used to produce interface files - would save lazy developers like myself from downloading and compiling. Think of it as one less barrier to overcome; a small step closer to more widespread adoption. Reasons against: - would favour one documentation tool over others - would add an unnecessary item to GHC build/packaging procedure (is this much of an overhead?) Mind you, if you include Haddock, why stop there? Why not include other developers tools, like (say) Hmake, Happy, Hat, ...? Alistair. > -Original Message- > From: Simon Marlow [mailto:[EMAIL PROTECTED] > Sent: 13 April 2004 10:59 > To: Bayley, Alistair > Cc: [EMAIL PROTECTED] > Subject: RE: [Haskell-cafe] Building Haddock on Windows > > > Yes, I suspect you have a mismatch between the version of Haddock on > your system and the version of Haddock used to produce the interfaces. > Try upgrading GHC. > > Cheers, > Simon > > > -Original Message- > > From: Bayley, Alistair [mailto:[EMAIL PROTECTED] > > Sent: 05 April 2004 16:19 > > To: Simon Marlow > > Cc: [EMAIL PROTECTED] > > Subject: RE: [Haskell-cafe] Building Haddock on Windows > > > > Trying to invoke Haddock with > > --read-interface=c:\ghc\ghc-6.0\doc\html\base\base.haddock > > > > Initially I get a stack overflow, so I added: +RTS -K2M -RTS ... > > > > and now I get: > > Fail: end of file > > Action: Data.Binary.getWord8 > > > > Is the --read-interface option specified correctly? This is > > where my GHC > > installation is, and the base.haddock file exists in there. I > > assume this is > > the interface file. > > > > Is this a compatibility problem? i.e. haddock file > > distributed with GHC 6.0 > > too old for Haddock 0.6? - * 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. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: URGENT: INFORMATION ABOUT WASH, GHC, CGI AND HSP
The .exe's you create with WASH (have a look at the examples) are CGI programs, so you can drop them into (say) Apache's cgi-bin. You should be able to use them with any http server that supports CGI. Using Tomcat (or some other Java-based server) is probably a waste of time (unless it supports CGI) because you're not using Java to create your web software. Apache is a reasonable choice if you can't find anything better. The Windows installation is pretty easy; you just need the courage to edit the large .conf file. If you want to integrate your programs with a Haskell http server (so you don't spawn a new process for each request - is this still what happens with Apache on Windows?) then you'll probably have to contact Peter Thiemann. It is possible, as he says in section 9 of: http://www.informatik.uni-freiburg.de/~thiemann/haskell/WASH/draft.pdf "We have successfully integrated the WASH/CGI library with a Web server written in Haskell by Simon Marlow [24]. In this server, a WASH/CGI application can run like a servlet in its own thread." > -Original Message- > From: Gerardo Valeri [mailto:[EMAIL PROTECTED] > Sent: 24 July 2003 00:37 > To: Bayley, Alistair; [EMAIL PROTECTED] > Subject: RE: URGENT: INFORMATION ABOUT WASH, GHC, CGI AND HSP > > > Hi, > > Thank you for the information you have provided us; we have > been able to compile wash. > Now we need a web server for haskell; we tried with Tomcat > but it did not work and we do not know which one to use. > Also we do not know if we have to associate ghc with the web > server and how to do it. > Could you give us any suggestions? > > Sorry for all the inconvenience. > > Thank you very much. > > Gerardo. * The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: URGENT: INFORMATION ABOUT WASH, GHC, CGI AND HSP
I just downloaded the files onto another machine and am doing the install. These are the steps I have followed, which are as per the instructions on: http://www.informatik.uni-freiburg.de/~thiemann/haskell/WASH/ Edit WASH-CGI-1.2/Makefile (set PATH_TO_ variables). Edit WASH-CGI-1.2/Examples/Makefile (set PATH_TO_ variables). Edit WASHMail-0.2/Makefile (set PATH_TO_UTILITY) In each directory say "make depend": Get error in WASH-CGI-1.2/Examples: file 'Login.hs' does not exist. Edit WASH-CGI-1.2/Examples/Makefile: delete line (in section "HS_FILES =") referring to Login.hs. In WASH-CGI-1.2/Examples say "make depend" again - ok this time. In Utility-0.1 say "make". No errors. I am using GNU Make. Perhaps you could try it? Also, does the goals section of the Utility-0.1/Makefile look like this? ## # goals all: libUtility.a libUtility.a: libUtility.a($(LIBSOURCES:.hs=.o)) dist:: rm -rf $(FULLNAME) mkdir $(FULLNAME) cp $(FILES) $(FULLNAME) tar cfvz $(DISTNAME) $(FULLNAME) install-distribution: dist cp $(DISTNAME) $(WWWDIR) ## And does the last part of the Utility-0.1/Makefile look like this? # DO NOT DELETE: Beginning of Haskell dependencies Auxiliary.o : Auxiliary.hs Auxiliary.o : ./Shell.hi Auxiliary.o : ./FileNames.hi FileNames.o : FileNames.hs Hex.o : Hex.hs Locking.o : Locking.hs Locking.o : ./Auxiliary.hi Shell.o : Shell.hs Unique.o : Unique.hs Unique.o : ./Locking.hi Unique.o : ./Auxiliary.hi # DO NOT DELETE: End of Haskell dependencies > -Original Message- > From: Gerardo Valeri [mailto:[EMAIL PROTECTED] > Sent: 22 July 2003 05:28 > To: Bayley, Alistair; [EMAIL PROTECTED] > Subject: RE: URGENT: INFORMATION ABOUT WASH, GHC, CGI AND HSP > > > Thanks for your reply, > > I do the following > First i descompressed the files in the following directories > /mail/utility-0.1 > /mail/washhtml-0.9 > /mail/wash-cgi-1.2 > /mail/washmail-0.2 > > if I do make in the Utility-0.1 directory show me this error > > [EMAIL PROTECTED] /cygdrive/c/mail/utility-0.1 > $ make > MAKE Version 5.2 Copyright (c) 1987, 2000 Borland > Fatal: 'libUtility.a(Auxiliary.o' does not exist - don't know > how to make it > > in the Makefile of this directory exist one reference to > libUtility.a, what the meaning of this error. > > I read that the files .a are static liraries but I don´t know > if there are Unix, GCC or GHC library. > > In the others directories it´s the same > > > I can do is compile the files ".hs", if I do ghc --make *.hs > > this generate files ".o" and ".hi" > I read that the files .o are similar that the files "obj" > generate in C++ and the files ".hi" are interface files from > the compiler GHC. > > I can´t generate the file .exe, this file is I NEED, isn´t it? > THANKS FOR YOUR REPLY > If somebody need something from Uruguay, I go to Europe next > month and perhaps i can take this > GERARDO * The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: URGENT: INFORMATION ABOUT WASH, GHC, CGI AND HSP
(Your caps-lock key seems to be stuck :-) You should give more information, like the error messages you received. Did the installation of Wash etc complete successfully? Did the example programs compile? (They will produce exes.) I recently (2-3 weeks ago) downloaded Wash and installed it on a W2K box, with GHC6. I followed the (brief) instructions on the website (including editing quite a few makefiles) and also: -- commented a reference to a non-existent Haskell source file in the makefile -- added some depedencies (I forget for exactly which files) to a makefile I determined what makefiles needed editing from the make error messages. If you're not familiar with make then you will struggle. Note that you need cygwin (or something that gives you make). You don't need hmake (unless you plan to use the CGIGraphics module, apparently). So after fixing some of these minor build issues, the whole thing built, and compiled the example programs. These worked perfectly when installed in my Apache cgi-bin. > -Original Message- > From: Gerardo Valeri [mailto:[EMAIL PROTECTED] > Sent: 20 July 2003 21:40 > To: [EMAIL PROTECTED] > Subject: URGENT: INFORMATION ABOUT WASH, GHC, CGI AND HSP > > > > HI! > > WE ARE A GROUP OF STUDENTS TRYING TO MAKE A WEB APPLICATTION > USING HSP, CGI AND WASH (WEB AUTHORING SYSTEM HASKELL). > WE DOWNLOADED WASH, AND GHC COMPILER. WE COMPILED THE WHOLE > APPLICATION WITH GHC BUT WE NEED TO GENERATE A .EXE FROM WASH > AND WE HAVE BEEN UNSUCCESSFUL. WE ARE WORKING ON A WINDOWS > PLATFORM. WE COMPILED THE FOUR MODULES FROM WASH: UTILITY, > WASHHTML, WASHCGI AND WASHMAIL, WITHOUT BEING ABLE TO CREATE > A .EXE FROM THEM. > WE REALLY APPRECIATE ANY SUGGESTION. > THANK YOU > > GERARDO * The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
How do I profile Prelude functions?
I can't find advice in the GHC manual on determining how much time your program spends in Prelude functions. I've discovered that I can alias a Prelude function e.g. > import Data.Set > myMkSet = mkSet ... which will give me a cost-centre for mkMySet. Isn't there an easier way to do this? * The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Profiling trouble
> From: Ferenc Wagner [mailto:[EMAIL PROTECTED]] > ... > One more question: is there a way not to truncate the call > stacks? Ie in the hp file I see lines like > > (144)showData2/showData/ma... 12 > > and I'd like to see showData2/showData/main or so. hear, hear... I'm also having some fun with profiling... First: The GHC manual might want to mention that running ghc --show-iface on an interface file won't work if it was compiled with -prof. You get: "mismatched interface file versions: expected 5042, found 5042p" Compiling sans -prof works. Second: Heap profiling falls over (seg fault) in some cases unless I compile with -O2. Cost-centre profiling works in both cases, and reveals that without -O2, a lot more heap is used: Sans -O2: queens +RTS -p -RTS total time = 28.42 secs (1421 ticks @ 20 ms) total alloc = 791,617,668 bytes (excludes profiling overheads) Avec -O2: queens +RTS -p -hc -RTS total time = 21.28 secs (1064 ticks @ 20 ms) total alloc = 464,256,564 bytes (excludes profiling overheads) I suspect that using a lot of heap causes it to fall over. (My program is called queens because I'm trying to solve the Queens and Knights problem on this page: http://www.itasoftware.com/careers/programmers.php ) Third: How do I tell if my functions are strict or not? The manual says: "Look for your function in the interface file, then for the third field in the pragma; it should say __S . The gives the strictness of the function's arguments. L is lazy (bad), S and E are strict (good), P is primitive (good), U(...) is strict and unpackable (very good), and A is absent (very good)." Now, my functions weren't exported, so I've exported some of them, and used ghc -Wall -ddump-simpl -ddump-hi ... to compile, and now I get this (I've removed the Core syntax stuff, 'cos there's a lot of it): NEW FINAL INTERFACE __interface "Main" Main 1 5042 where __export Main addQueens addQueens2 allSquares eightQueens keepBoard knightsQueens main placeKnight placeQueen showBoard showBoards showRow showSquare testAndAdd; import Data.Set :: 1; import GHC.IOBase :: 1; import GHC.TopHandler :: 1; import GHC.Base ! :: 1; import GHC.Real :: 1; import GHC.Enum :: 1; import GHC.Num :: 1; import GHC.Show :: 1; import GHC.List :: 1; import System.IO :: 1; import Data.Tuple :: 1; import GHC.Ptr :: 1; import Foreign.Ptr ! :: 1; import Data.FiniteMap :: 1; ; (Main.$main) :: GHC.IOBase.IO (); Main.knightsQueens :: [Main.Board]; Main.main :: GHC.IOBase.IO (); Main.placeQueen :: Main.Board -> [Main.Coord] -> [Main.Board] -> [Main.Board]; Main.placeKnight :: Main.Board -> [Main.Coord] -> [Main.Board] -> [Main.Board]; Main.testAndAdd :: Main.Board -> [Main.Board] -> [Main.Board]; Main.keepBoard :: Main.Board -> GHC.Base.Bool; Main.allSquares :: [Main.Coord]; Main.eightQueens :: [Main.Board]; Main.addQueens :: Main.Board -> GHC.Base.Int -> [Main.Board] -> [Main.Board]; Main.addQueens2 :: Main.Board -> GHC.Base.Int -> GHC.Base.Int -> [Main.Board] -> [Main.Board]; Main.showBoards :: [Main.Board] -> GHC.Base.String; Main.showBoard :: Main.Board -> GHC.Base.String; Main.showRow :: Main.Board -> GHC.Base.Int -> GHC.Base.String; Main.showSquare :: Main.Board -> GHC.Base.Int -> GHC.Base.Int -> GHC.Base.Char; type Main.Coord = (GHC.Base.Int, GHC.Base.Int); type Main.Square = GHC.Base.Int; type Main.Squares = Data.Set.Set Main.Square; type Main.Board = (Main.Squares, Main.Squares, Main.Squares); What should I be looking for? Can/should I inspect the Core syntax too? Thanks, Alistair. * The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Help: Windows ghc profiler errors
I want to profile my Haskell program (it solves the Queens and Knights problem stated here: http://www.itasoftware.com/careers/programmers.php ). I'm compiling with GHC 5.04.1 under Windows NT using the following command line (as per the Users Guide): >ghc -prof -auto-all -o queens --make Main When I run the program with the following command lines I get: >queens queens: fatal error: evacuate: strange closure type 1696 >queens +RTS queens: fatal error: evacuate: strange closure type 1728 >queens +RTS -p queens: fatal error: evacuate: strange closure type 1760 (I have no idea if the change in closure type is significant, but it is quite clearly related to the command line options used.) The program works without profiling (whether or not it produces the correct answers is another matter). I just want to practice profiling and optimising Haskell programs. I've also tried running the profiler with a minimal program: > module Main where > main :: IO () > main = do putStrLn "hello world" ... and I get a segmentation fault. Anyway, I've had a quick look through the last couple of months of mailing list archives and haven't noticed anything related to this error. Any ideas? Thanks, Alistair. * The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. * ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
