Re: 6.10.1 Bug?
Dominic Steinitz wrote: According to the hackage page, the Haskell Cryptography Library has a build failure. I couldn't find a bug reference when I searched for milestone 6.10.1 on trac. Should I report it? Has it been fixed? Thanks, Dominic. http://hackage.haskell.org/packages/archive/Crypto/4.1.0/logs/failure/ghc-6.10 [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug I found it. It was filed under milestone 6.10.2 (clearly I don't understand milestones). http://hackage.haskell.org/trac/ghc/ticket/2753 It seems a bit vague on what's happening. Is it going to be fixed? Has it been fixed? Thanks, Dominic. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Unicode's greek lambda
Hello, When the -XUnicodeSyntax option is specified, GHC accepts some Unicode characters including left/right arrows. Unfortunately, the letter greek lambda cannot be used. Are there any technical reasons to not accept it? Regards, --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cross module optimization issues
On Sat, Nov 15, 2008 at 10:09 PM, Don Stewart [EMAIL PROTECTED] wrote: jwlato: Hello, I have a problem with a package I'm working on, and I don't have any idea how to sort out the current problem. One part of my package is in one monolithic module, without an export list, which works fine. However, when I've started to separate out certain functions into another module, and added an export list to one of the modules, which dramatically decreases performance. The memory behavior (as shown by -hT) is also quite different, with substantial memory usage by FUN_2_0. Are there any suggestions as to how I could improve this? Are you compiling with aggressive cross-module optimisations on (e.g. -O2)? You may have to add explicit inlining pragmas (check the Core output), to ensure key functions are exported in their entirety. Thanks for the reply. I'm compiling with -O2 -Wall. After looking at the Core output, I think I've found the key difference. A function that is bound in a where statement is different between the monolithic and split sources. I have no idea why, though. I'll experiment with a few different things to see if I can get this resolved. John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode's greek lambda
Hello Kazu, Tuesday, November 18, 2008, 12:00:25 PM, you wrote: characters including left/right arrows. Unfortunately, the letter greek lambda cannot be used. Are there any technical reasons to not accept it? i think it is accepted as usual letter - reason is that greeks can use it in their identifiers :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode's greek lambda
When the -XUnicodeSyntax option is specified, GHC accepts some Unicode characters including left/right arrows. Unfortunately, the letter greek lambda cannot be used. Are there any technical reasons to not accept it? The greek lambda is a normal lower-case alphabetic character - it can be used in identifier names. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Trouble with ghc on linux x86_64
Bit Connor wrote: On Fri, Nov 14, 2008 at 5:36 AM, Simon Marlow [EMAIL PROTECTED] wrote: Compiling and running executables should work fine, only GHCi is affected by the above bug. Could you try -v when linking and see what stage is hanging? Here is an example with a standard cabal Setup.lhs file. It outputs the following and then hangs. When I look at top then there is an ld process taking up almost zero cpu, but hundreds of MB of memory. Since it seems to be hanging in the linker, and this is a Xen instance, perhaps you're running out of memory and swapping? BTW, I've checked in a potential fix for the mmap() problem you reported earlier, see http://hackage.haskell.org/trac/ghc/ticket/2063 Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cannot escape from a black hole in ghci 6.10.1
Ahn, Ki Yung wrote: Dear GHC users I have both GHC 6.8.2 (debian unstable package) and GHC 6.8.10 (binary distribution from ghc homepage) installed. I was able to escape from a black hole in ghci 6.8.2 with Ctrl-C. For example, GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude let x = x + x Prelude x ^CInterrupted. Prelude x *** Exception: stack overflow Prelude Interestingly, you will get a stack overflow when you try to escape from the black home for the second time. In ghci 6.10.1, I am not able to escape from a black hole with Ctrl-C. GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude let x = x + x Prelude x ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C ... (doesn't work) You can't escape from the black hole and ghci will start eating up your memory unless kill the ghci process. Now the black hole behaves like a real black hole :-) Is this a ticketed bug, or should we make a new ticket? Yes, this is the same bug as #2783 (fixed yesterday) and probably also #2780 (I still have to test the fix against that program). It'll be fixed in 6.10.2. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.10.1 Bug?
Dominic Steinitz wrote: Dominic Steinitz wrote: According to the hackage page, the Haskell Cryptography Library has a build failure. I couldn't find a bug reference when I searched for milestone 6.10.1 on trac. Should I report it? Has it been fixed? Thanks, Dominic. http://hackage.haskell.org/packages/archive/Crypto/4.1.0/logs/failure/ghc-6.10 [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug I found it. It was filed under milestone 6.10.2 (clearly I don't understand milestones). http://hackage.haskell.org/trac/ghc/ticket/2753 It seems a bit vague on what's happening. Is it going to be fixed? Has it been fixed? We'll do something for 6.10.2, yes. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode's greek lambda
On Tue, Nov 18, 2008 at 10:30:01AM +, Malcolm Wallace wrote: When the -XUnicodeSyntax option is specified, GHC accepts some Unicode characters including left/right arrows. Unfortunately, the letter greek lambda cannot be used. Are there any technical reasons to not accept it? The greek lambda is a normal lower-case alphabetic character - it can be used in identifier names. But it could be a reserved word synonymous with \. After all, \ can occur in operator symbols, but the operator \ is reserved. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64
I've made a speculative fix. If you're able to test it, that would be very helpful: I imagine, I need to download the nightly snapshot and build it. HEAD or STABLE? Rahul ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64
HEAD 2008/11/18 Rahul Kapoor [EMAIL PROTECTED]: I've made a speculative fix. If you're able to test it, that would be very helpful: I imagine, I need to download the nightly snapshot and build it. HEAD or STABLE? Rahul ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.10.1 Bug?
On Tue, Nov 18, 2008 at 08:08:54AM +, Dominic Steinitz wrote: I found it. It was filed under milestone 6.10.2 (clearly I don't understand milestones). The milestone is when we hope it will be fixed. The version is which version it is broken in (although if it's broken in multiple versions then only one will be listed). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode's greek lambda
On Tue, 2008-11-18 at 11:51 +, Ross Paterson wrote: On Tue, Nov 18, 2008 at 10:30:01AM +, Malcolm Wallace wrote: When the -XUnicodeSyntax option is specified, GHC accepts some Unicode characters including left/right arrows. Unfortunately, the letter greek lambda cannot be used. Are there any technical reasons to not accept it? The greek lambda is a normal lower-case alphabetic character - it can be used in identifier names. But it could be a reserved word synonymous with \. After all, \ can occur in operator symbols, but the operator \ is reserved. Presumably that would let you do (\ x - ...) but not (\x - ) since the \x would run together and lexically it would be one identifier. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode's greek lambda
Quoth Duncan Coutts [EMAIL PROTECTED]: | On Tue, 2008-11-18 at 11:51 +, Ross Paterson wrote: | But it could be a reserved word synonymous with \. After all, \ can | occur in operator symbols, but the operator \ is reserved. | | Presumably that would let you do (\ x - ...) but not (\x - ) since the | \x would run together and lexically it would be one identifier. Good, that's clearly the right way to do it anyway! Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer
On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty [EMAIL PROTECTED] wrote: Ian Lynagh: On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery KF8NH wrote: On 2008 Nov 4, at 20:26, Jason Dagit wrote: On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty [EMAIL PROTECTED] wrote: Are you sure it does deinstall the 6.8 compiler? After installing 6.10, there should be a 608/ and a 610/ directory. This certainly happens on my Mac and I am not aware of an option to change that behaviour. I expect if you used the OSX installer then /Library/Receipts is screwing you (it wipes the old files listed in the .bom file). Try finding and removing the receipt directory and bom file before installing. The only file I can see that looks relevant is /Library/Receipts/boms/org.haskell.glasgowHaskellCompiler.ghc.pkg.bom Wouldn't removing it make uninstall impossible? In fact, if you did manage to get 2 versions installed, how would /Library/Frameworks/GHC.framework/Tools/Uninstaller know which version to uninstall? Wouldn't it only know how to uninstall the version it came with? I'd suggest that the overlapping file Uninstaller could be why the older version gets removed, but that wouldn't explain why Manuel can install both at once. A current limitation of the MacOS package system is that it does not support uninstalling of packages; cf http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#/ /apple_ref/doc/uid/1145i-CH6-DontLinkElementID_29 This is not a big drama on MacOS, as MacOS encourages the distribution of software packages as bundles: http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html This essentially means that instead of sprinkling files all over the file system (as is common in other OSes), MacOS applications and frameworks (Mac-speak for libraries) are kept in a single directory. Uninstalling then means doing an rm -rf on that directory. Unfortunately, some applications (including GHC and Apple's Xcode IDE) can't be entirely contained in a single directory. In the case of GHC, we want symlinks in /usr/bin. The established way of uninstalling such applications is by supplying an Uninstaller script, just as I did for GHC. (Apple does the same for Xcode.) The purpose of the Uninstaller script is too completely remove GHC.framework from a machine - not just to remove one version. In fact, if more than one version of GHC is installed, the Uninstaller will refuse to run and require the manual removal of all versions, but the current (easily achieved by a rm -rf /Library/Frameworks/GHC.framework/Versions/version). The main feature of the Uninstaller script is to get rid of all symlinks pointing into GHC.framework. The framework itself is just deleted by a rm -rf as expected. (It also removes the above mentioned receipt file.) So, to directly answer the above questions: * The package manger (which uses the receipts) can't uninstall and the uninstaller script doesn't need the receipt. So, even after deleteing the receibt, you can still uninstall. * The Uninstaller can uninstall any version (at least as long as no symlinks are put into new directories outside of the bundle that the Uninstaller doesn't know about). Is there an update on this thread? I would still like to have my cake and eat it too, meaning ghc 6.8.3 and ghc 6.10.1. As far as I know the installer hasn't been updated and if I try again I will lose my copy of 6.8.3. Thanks, Jason ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode's greek lambda
Hello, First of all, thank you for those who replied kindly. When the -XUnicodeSyntax option is specified, GHC accepts some Unicode characters including left/right arrows. Unfortunately, the letter greek lambda cannot be used. Are there any technical reasons to not accept it? The greek lambda is a normal lower-case alphabetic character - it can be used in identifier names. OK. I understand. But it could be a reserved word synonymous with \. After all, \ can occur in operator symbols, but the operator \ is reserved. Presumably that would let you do (\ x - ...) but not (\x - ) since the \x would run together and lexically it would be one identifier. If we reserve the greek lambda as special like '\', the lexer can separate lambdax into two tokens: lambda and 'x', I guess. Some people may want to use the greek lambda in identifiers. And some would want to use the greek lambda as an alternative of '\'. So, how about providing a new option to make the greek lambda special? P.S. I want to type the examples in Programming in Haskell as is. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode's greek lambda
On 2008 Nov 18, at 20:53, Kazu Yamamoto (山本和彦) wrote: If we reserve the greek lambda as special like '\', the lexer can separate lambdax into two tokens: lambda and 'x', I guess. Not without redefining it as a symbol instead of a lowercase letter, which won't be done as previously discussed. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode's greek lambda
Hello, If we reserve the greek lambda as special like '\', the lexer can separate lambdax into two tokens: lambda and 'x', I guess. Not without redefining it as a symbol instead of a lowercase letter, which won't be done as previously discussed. OK. Fine with me since this topic was previously discussed. --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
