- Glasgow-haskell-users

WinHugs for GHCi, prompt feature
by Neil Mitchell 13 Feb '06

13 Feb '06

Hi, I'm working on a Windows Haskell GUI, a lot like WinHugs (stealing a lot of the code from WinHugs), which I want to make cross-compiler happy - i.e. Hugs, GHCi and Yhc at least. [See http://www-users.cs.york.ac.uk/~ndm/projects/winhaskell.php for a really old screen shot] The way I am operating with Hugs is by spawning a Hugs process as a separate process, and redirecting the stdin, stdout and stderr to my application. The hardest bit is figuring out when Hugs has run a computation and finished, the way I am doing this currently is by setting the prompt to escape characters, then when my program sees these special escape characters it can determine that the computation has finished and let the user enter the next one. The problem with GHCi is that I haven't been able to set the prompt, and therefore I can't detect when the computation is over, which makes it quite hard to operate with. So what I would really like is any one of: 1) Ability to set the prompt in GHCi 2) Some other mechanism to detect when the computation has finished 3) A way under Windows to detect when a console program is waiting on user input (which I have been entirely unable to find, and may just not exist) WinHaskell is currently perfectly useable with Hugs, and maybe a month or so away from release. I intend to start a darcs repo on tomorrow, if anyone is interested in it. Thanks Neil

4 7

ld.exe distributed with Windows ghc-6.4.1 buggy?
by Bayley, Alistair 13 Feb '06

13 Feb '06

(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. *****************************************************************

1 0

RE: newtype and rules
by Simon Peyton-Jones 13 Feb '06

13 Feb '06

| I am curious if rules pragmas are applied before or after newtype | desugaring? The matching function respects newtypes. | basically what I want to know is if I have a newtype of an | Int say, and make a rule acting on the newtype, will it be applied to | any Int as well? No, it shouldn't be. Simon

2 1

forall a (Ord a => a-> a) -> Int is an illegal type???
by Brian Hulley 13 Feb '06

13 Feb '06

Hi - I've been puzzling over section 7.4.9.3 of the ghc users manual for the past few months (!) and still can't understand why the following is an illegal type: forall a. ((Ord a => a-> a) -> Int) whereas (forall a. Ord a => a->a) -> Int is legal. I can understand why the second one *is* legal but I can't seem to understand why the first syntax is not just exactly the same thing even though the parse tree is different. Can anyone shed some light on this? Thanks, Brian.

7 14

GHC HQ shut down for a week
by Simon Peyton-Jones 10 Feb '06

10 Feb '06

Cherished users Simon and I are both on holiday next week, so you won't hear from GHC HQ during that time. Happy Haskell hacking! Simon

1 0

newtype and rules
by John Meacham 10 Feb '06

10 Feb '06

I am curious if rules pragmas are applied before or after newtype desugaring? basically what I want to know is if I have a newtype of an Int say, and make a rule acting on the newtype, will it be applied to any Int as well? John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

RE: instance inference
by Simon Peyton-Jones 09 Feb '06

09 Feb '06

Thank you Ross. I've committed your patch, and added documentation. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ross Paterson | Sent: 06 February 2006 11:36 | To: Simon Peyton-Jones; glasgow-haskell-users(a)haskell.org | Subject: Re: instance inference | | A patch implementing a relaxed termination constraint is at | | http://www.soi.city.ac.uk/~ross/instance-termination.patch | | Here is the description: | | With -fglasgow-exts but not -fallow-undecidable-instances, GHC 6.4 | requires that instances be of the following form: | | (1) each assertion in the context must constrain distinct variables | mentioned in the head, and | | (2) at least one argument of the head must be a non-variable type. | | This patch replaces these rules with the requirement that each | assertion in the context satisfy | | (1) no variable has more occurrences in the assertion than in the | head, and | | (2) the assertion has fewer constructors and variables (taken together | and counting repetitions) than the head. | | This allows all instances permitted by the old rule, plus such | instances as | | instance C a | instance Show (s a) => Show (Sized s a) | instance (Eq a, Show b) => C2 a b | instance C2 Int a => C3 Bool [a] | instance C2 Int a => C3 [a] b | instance C4 a a => C4 [a] [a] | | but still ensures that under any substitution assertions in the context | will be smaller than the head, so context reduction must terminate. | | This is probably the best we can do if we consider each instance in | isolation. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Passing a matrix from C to Haskell
by Cyril Schmidt 08 Feb '06

08 Feb '06

I need to pass a big 2-dimensional array of doubles from a legacy C code to a Haskell module. Of this huge array, the Haskell code will actually use only a few elements (say, 10 out of 100x20 matrix). Unfortunately, the C code does not know which data are actually needed in the Haskell module. What would be a good way to pass the array to Haskell and, once the data are handed over, what is the fastest way to fetch these elements? I was thinking of something like passing the array as Ptr Int#, but how do I fetch the elements that I am interested in? Cheers, Cyril

6 9

Fwd: patch applied (ghc): make the smp way RTS-only, normal libraries now work with -smp
by Bulat Ziganshin 08 Feb '06

08 Feb '06

i think that this should be interesting for GHC users This is a forwarded message From: Simon Marlow <simonmar(a)microsoft.com> To: cvs-ghc(a)haskell.org Date: Wednesday, February 08, 2006, 5:40:19 PM Subject: patch applied (ghc): make the smp way RTS-only, normal libraries now work with -smp ===8<==============Original message text=============== Wed Feb 8 06:33:48 PST 2006 Simon Marlow <simonmar(a)microsoft.com> * make the smp way RTS-only, normal libraries now work with -smp We had to bite the bullet here and add an extra word to every thunk, to enable running ordinary libraries on SMP. Otherwise, we would have needed to ship an extra set of libraries with GHC 6.6 in addition to the two sets we already ship (normal + profiled), and all Cabal packages would have to be compiled for SMP too. We decided it best just to take the hit now, making SMP easily accessible to everyone in GHC 6.6. Incedentally, although this increases allocation by around 12% on average, the performance hit is around 5%, and much less if your inner loop doesn't use any laziness. M ./ghc/compiler/codeGen/CgForeignCall.hs -6 +5 M ./ghc/compiler/codeGen/CgHeapery.lhs -3 +1 M ./ghc/compiler/codeGen/CgPrimOp.hs -4 +1 M ./ghc/compiler/codeGen/ClosureInfo.lhs -24 +15 M ./ghc/compiler/codeGen/SMRep.lhs -3 +2 M ./ghc/compiler/ghci/ByteCodeAsm.lhs +2 M ./ghc/compiler/ghci/ByteCodeGen.lhs -11 +13 M ./ghc/compiler/ghci/ByteCodeInstr.lhs -1 +3 M ./ghc/compiler/ghci/ByteCodeItbls.lhs -3 +3 M ./ghc/compiler/main/Constants.lhs -2 +1 M ./ghc/compiler/main/StaticFlags.hs -7 +4 M ./ghc/includes/Bytecodes.h -22 +23 M ./ghc/includes/Closures.h -11 +10 M ./ghc/includes/Cmm.h -4 M ./ghc/includes/Constants.h -21 +4 M ./ghc/includes/Storage.h -2 +67 M ./ghc/includes/mkDerivedConstants.c -39 +6 M ./ghc/rts/Apply.cmm -1 +1 M ./ghc/rts/GC.c -6 +6 M ./ghc/rts/GCCompact.c -55 +1 M ./ghc/rts/Interpreter.c -21 +30 M ./ghc/rts/LdvProfile.c -89 +19 M ./ghc/rts/LdvProfile.h -1 +1 M ./ghc/rts/Linker.c +2 M ./ghc/rts/ProfHeap.c -3 +3 M ./ghc/rts/RetainerProfile.c -93 +1 M ./ghc/rts/Sanity.c -7 +7 M ./ghc/rts/Schedule.c -3 +3 M ./ghc/rts/Sparks.c +10 M ./ghc/rts/Sparks.h -1 +4 M ./ghc/rts/Updates.h -18 +25 M ./mk/config.mk.in -6 +8 _______________________________________________ Cvs-ghc mailing list Cvs-ghc(a)haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc ===8<===========End of original message text=========== -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

Re: [GHC] #683: RULES for recursive functions don't work properly
by Bulat Ziganshin 08 Feb '06

08 Feb '06

Hello GHC, Tuesday, February 07, 2006, 8:03:49 PM, you wrote: G> someone mentioned to me that this expression: G> mapM_ action [n..m] G> isn't being optimised properly, so I thought I'd look into it. Sure may be, what's me :) i use specially written function as faster version of this idiom and suggested Simon Marlow to substitute "mapM [n..m]" with call to my function using RULE mechanism -- Best regards, Bulat mailto:bulatz@HotPOP.com

2 2