Re: a possibility to redefine built-in GHCi commands
Simon Marlow wrote: Peter Hercek wrote: Hi GHCi users, I would like to be able to redefine the built-in GHCi commands. The idea is that when searching for a command the user defined commands would be searched first and only then the built-in commands would be searched. If user wants to invoke a built-in command regardless of user defined commands he/she would need to start it with two colons (instead of one). It is an user interface change which may break some scripts, but it would allow to provide different default behavior. For example: * when I use GhciExt I want all my :continue commands to be actually :x :continue * it would allow to specify different order of searching for abbreviated commands as the default one * it would allow to specify different default switches for builtin commands Would such a change be merged upstream if I would provide a patch? Seems reasonable to me. OK, I created a ticket for it and attached the implementation to the ticket. http://hackage.haskell.org/trac/ghc/ticket/3084 Thanks, Peter. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ThreadScope: Request for features for the performance tuning of parallel and concurrent Haskell programs
Donnie Jones, Simon Marlow and I have been working on infrastructure for logging run-time events and a graphical viewer program called ThreadScope. Hopefully these features will make it into the next release of GHC. We hope the event-log viewer ThreadScope will be useful for the performance tuning of parallel and concurrent Haskell programs. You can see a few screen shots at the program's website http://raintown.org/threadscope Before making the release I thought it would be an idea to ask people what other features people would find useful or performance tuning. So if you have any suggestions please do let us know! Cheers, Satnam Singh Satnam Singh Microsoft 7 JJ Thomson Avenue Cambridge CB3 0FB United Kingdom Email: satn...@microsoft.commailto:satn...@microsoft.com UK tel: +44 1223 479905 Fax: +44 1223 479 999 UK mobile: +44 7979 648412 USA cell: 206 330 1580 USA tel: 206 219 9024 URL: http://research.microsoft.com/~satnams Live Messenger: sat...@raintown.orgmailto:sat...@raintown.org ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cygwin version
Tuomo Valkonen wrote: On 2009-03-09, Tuomo Valkonen tuo...@iki.fi wrote: On 2009-03-09, Tuomo Valkonen tuo...@iki.fi wrote: On 2009-03-09, John Meacham j...@repetae.net wrote: perhaps the most recent non-cabalized ghc build might be worth a try. I think darcs still compiles with ghc 6.6, but am not positive., Mingw-bootstrap, source, or both? Tried with both. Got: ghc.exe: unknown package: unix With './configure --build=i686-pc-cygwin32 --with-gcc=c:/cygwin/bin/gcc --with-ld=c:/cygwin/bin/ld' I got to the point: ../compiler/ghc-inplace -optc-mno-cygwin -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-fno-strict-aliasing -H16m -O -optc-O2 -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -c Adjustor.c -o Adjustor.o make: *** [Adjustor.o] Error 1 The stage1 ghc-inplace doesn't seem to be able to produce neither code nor an error message. It just fails. It also isn't a cygwin program according to ldd; should it be? You're doing a *port* here, to create a GHC that can generate Cygwin binaries, using a GHC that generates MinGW binaries to bootstrap from. This isn't something you should expect to work out of the box :-) For a start, you should set your platforms like this: build = i386-unknown-mingw32 host = i386-unknown-mingw32 target = i386-unknown-cygwin32 It looks like your stage1 compiler is crashing, but I have no idea why. If you're really interested in getting this working, expect to have to do a lot of hacking in GHC's internals, build system, and libraries. We're here to help, of course. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cygwin version
On 2009-03-11, Simon Marlow marlo...@gmail.com wrote: For a start, you should set your platforms like this: build = i386-unknown-mingw32 host = i386-unknown-mingw32 target = i386-unknown-cygwin32 GHC configuration does not support differing host/target (i.e., cross-compiling) with both the 6.6 and 6.10.1 binaries. Is an existing cross-compiler really necessary? If a stage1 compiler is created in any case, can't it just be made to be a cross-compiler? If you're really interested in getting this working, expect to have to do a lot of hacking in GHC's internals, build system, and libraries. We're here to help, of course. Seems like it will be easier to switch to another version control system. -- Stop Gnomes and other pests! Purchase Windows today! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cygwin version
tuomov: On 2009-03-11, Simon Marlow marlo...@gmail.com wrote: For a start, you should set your platforms like this: build = i386-unknown-mingw32 host = i386-unknown-mingw32 target = i386-unknown-cygwin32 GHC configuration does not support differing host/target (i.e., cross-compiling) with both the 6.6 and 6.10.1 binaries. Is an existing cross-compiler really necessary? If a stage1 compiler is created in any case, can't it just be made to be a cross-compiler? If you're really interested in getting this working, expect to have to do a lot of hacking in GHC's internals, build system, and libraries. We're here to help, of course. Seems like it will be easier to switch to another version control system. Have you asked on the darcs-users@ list for a cygwin binary build? I know these are getting pretty rare now, but someone may have already produced one. -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: Cygwin version
Hello Don, Wednesday, March 11, 2009, 7:52:32 PM, you wrote: Have you asked on the darcs-users@ list for a cygwin binary build? I know these are getting pretty rare now, but someone may have already produced one. does ghc supports building cygwin executables? -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cygwin version
On 2009-03-11, Don Stewart d...@galois.com wrote: Have you asked on the darcs-users@ list for a cygwin binary build? I know these are getting pretty rare now, but someone may have already produced one. Yes, to no luck. They thought this was the better place to ask. -- Tuomo ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Loop unrolling + fusion ?
Claus, Max
| My preferred spec would be roughly
|
| {-# NOINLINE f #-}
| as now
|
| {-# INLINE f #-}
| works as now, which is for non-recursive f only (might in future
| be taken as go-ahead for analysis-based recursion unfolding)
|
| {-# INLINE f PEEL n #-}
| inline calls *into* recursive f (called loop peeling for loops)
|
| {-# INLINE f UNROLL m #-}
| inline recursive calls to f *inside* f (called loop unrolling for loops)
|
| {-# INLINE f PEEL n UNROLL m #-}
| combine the previous two
Sounds as if you two are evolving a good design, thank you. I am not following
the details closely, but I have the advantage of being able to chat to Max
directly.
Suggestion: if after discussion you think this is a valuable thing to do, write
a GHC-Trac-Wiki page describing the design as precisely as possible (eg with
examples; I find the above one-liners hard to grok). Along with any major
design alternatives. Ideally with a few indicative measurements gotten by
by-hand transformations, that show there are real benefits to be had.
For implementation, there are two routes. Either totally built-in, or using a
Core-to-Core plug-in. The thing I like about the latter is that it can be done
without having GHC HQ in the critical path, because we (I) tend to slow things
down, being a uniprocesor. We don't have the plug-in capability yet, but I'm
encouraging Max to polish it up so that we do. I think it'd be a very valuable
facility.
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: Loop unrolling + fusion ?
Hello Simon, Thursday, March 12, 2009, 1:29:56 AM, you wrote: For implementation, there are two routes. Either totally built-in, or using a Core-to-Core plug-in. The thing I like about the latter is that it can be done without having GHC HQ in the critical path, because we (I) tend to slow things down, being a uniprocesor. We don't have the plug-in capability yet, but I'm encouraging Max to polish it up so that we do. I think it'd be a very valuable facility. as GHC popularity grows, it may become more profitable to spend resources making it more open, pluggable compiler factory rather than doing everything yourself -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] ThreadScope: Request for features for the performance tuning of parallel and concurrent Haskell programs
Hi Satnam, On 12/03/2009, at 12:24 AM, Satnam Singh wrote: Before making the release I thought it would be an idea to ask people what other features people would find useful or performance tuning. So if you have any suggestions please do let us know! Is it available in a branch somewhere to try out? Ben. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
