Re: Using extcore
On Wed, Nov 2, 2011 at 8:19 AM, Knut Halvor Skrede khskr...@gmail.com wrote: Hi, I'm working on a project where I need to dump Core to an alternative format. So I'm wondering if it is possible to use the ghc api to compile haskell to core, and then use the extcore package to make a representation of the result as a Core module. That way I could simply traverse it and make whatever representation necessary, based on the Core language definition. It seems to me like the extcore package is only for parsing external-core files? I don't want to have to dump core to a file, then parse it back. I was unable to find any documentation on how to do this. Hi Knut -- If I may ask, why don't you want to dump ext-core to a text file? I can understand if the answer is performance reasons, but I would strongly encourage you to start with this route in order to get a prototype working. It's much easier; at least the last time I tried to use it (which was over a year ago), the GHC API was quite imperative, and when you're just starting your implementation, it's easier not to worry about that sort of thing. If you go this route, you should be able to just use the extcore library out of the box. There is some minimal documentation as a README inside the extcore package (the version that's on hackage); if you have any questions that it doesn't answer, as is likely, feel free to ask me and CC the ghc-users mailing list (so that the answer will be public and searchable). Once you have a prototype working, if you find that intermediate file reading/parsing is a bottleneck, you can change what you have to use the API to generate Core in-process instead of generating an intermediate file with -fext-core. If you want to just use the GHC API from the start, I can't be as helpful there, because I haven't played with that part of GHC in a long time, and it's known to change quickly. People on the ghc-users mailing list may be able to help. Depending on what you want to do, you may not need to use the extcore library at all if you use the API. You can generate a Core module, as well as typecheck it (using Core Lint) only using API functions that are documented in the GHC API documentation. If you did need to use the extcore library together with the API, you would need to use one of the functions in the MkExternalCore module (which should also be part of the API) to explicitly convert GHC's internal Core into external Core. I haven't done this, but there's no reason in principle why it wouldn't work. If you do get results this way, and feel like helping out, you could add your procedure to the wiki: http://hackage.haskell.org/trac/ghc/wiki If you have any followup questions, please reply to me and CC the mailing list, as I don't always read the mailing list, but it's also good if replies are on the record. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt “I cannot hide my anger to spare you guilt, nor hurt feelings, nor answering anger; for to do so insults and trivializes all our efforts. Guilt is not a response to anger; it is a response to one’s own actions or lack of action.” -- Audre Lorde ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Question about Haskell AST
On Mon, Jan 10, 2011 at 9:21 AM, Jane Ren j2...@ucsd.edu wrote: Hi, I need to be able to take a piece of Haskell source code and get an simplified, typed, intermediate representation of the AST, which means I need to use compiler/coreSyn/CoreSyn.lhs So I'm first trying to get the desguaredModule of the source code with ... modSum - getModSummary $ mkModuleName ... p - parseModule modSum t - typecheckModule p d - desugarModule t Now I'm really stuck on figuring out how to connect the variable d of type desugaredModule to compiler/coreSyn/CoreSyn.lhs to get Expr patterns like App, Let, Case, etc. Also, is it correct to get the deguaredModule first? At least CoreSyn.lhs seems to suggest this. Sorry for the very late reply, but have you considered using External Core? http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/ext-core.html http://hackage.haskell.org/package/extcore IMO, it's less pain than linking with the GHC library unless your application really needs to get transformed Core back into the GHC back-end. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt an intelligent person fights for lost causes,realizing that others are merely effects -- E.E. Cummings ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On Mon, Jan 10, 2011 at 8:52 AM, Malcolm Wallace malcolm.wall...@me.com wrote: As another non-GHC contributor, my opinion should probably also count for little, but my experience with git has been poor. I have used git daily in my job for the last year. Like Simon PJ, I struggle to understand the underlying model of git, despite reading quite a few tutorials. I have a high failure rate with attempting anything beyond the equivalents of darcs record, push, and pull. When I use darcs, my local workflow typically involves lots of amend-record, cherry-picking, and multiple repos/branches. I have tried to do these things in git a few times and failed miserably. I am an old-fashioned unix command-line lover, but I find using the git command-line is next to impossible, and as a consequence do almost everything in git gui. If the gui interface does not let me do an action, then I often can't work out how to do it at all, even after googling. Mind you, some other people at work somehow manage to use git's support for branching reasonably successfully. But we have occasional mishaps where a repo is made totally unusable by somebody making a tiny mistake with their branching commands. Our standard advice at work for people who get their repo muddled is to throw it away, re-clone the master, and manually re-code their local changes from scratch (with the help of diff). If I were considering contributing minor patches to a project, the use of git would probably not deter me too much - I can cope with the simple stuff. But if I wanted more major involvement, git would definitely cause me to think twice about whether to bother. I agree with Malcolm (and with Neil's later post); I wanted to issue a me-too because of all of the pro-git messages I've been seeing. I've been using git for two years at my job. I still can't do anything but the most basic tasks. When I try to read the documentation, the documentation (a) is incomprehensible and (b) tells me that I'm stupid because I find it incomprehensible. I found darcs easy to learn and it has always made sense to me. I've lost work and had to recreate it by hand because of git. I've only ever been an occasional GHC contributor, so my opinion shouldn't count for much, but a switch to git would be one more small thing that would discourage me from contributing in the future. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt an intelligent person fights for lost causes,realizing that others are merely effects -- E.E. Cummings ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: getting Core Haskell from GHC API with cross-module inlinings
On 6/17/10, Roman Beslik ber...@ukr.net wrote:
Hi.
The following code compiles A.hs with GHC API:
{{{
import GHC
import Outputable
import DynFlags ( defaultDynFlags )
libdir = /usr/lib/ghc-6.12.1
targetFile = A.hs
main = defaultErrorHandler defaultDynFlags $ do
runGhc (Just libdir) $ do
dflags - fmap (\dflags - dflags {optLevel = 2}) getSessionDynFlags
Hi, Roman --
The problem you're seeing, where insufficient optimization occurs, is
in the above line. If I replace it with:
dflags - fmap (updOptLevel 2) getSessionDynFlags
then I get a result where maybe has been inlined away. The reason is
that the optimization sequence is controlled by several different
fields within DynFlags, and just changing the optLevel field doesn't
update the other fields. The updOptLevel function (defined in
DynFlags, so you'll have to import that module explicitly) does.
Also, I don't know what you're trying to do, but I recommend looking
at GHC's External Core feature:
http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/ext-core.html
and at the extcore and linkcore libraries:
http://hackage.haskell.org/package/extcore
http://hackage.haskell.org/package/linkcore
IMO, it's easier than using the API to generate Core. If you find any
problems with External Core or the packages above, let me know (I'm
the maintainer).
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
I knew I'd hate Cobol the moment I saw they'd used 'perform' instead
of 'do'. -- Larry Wall
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: getting Core Haskell from GHC API with cross-module inlinings
On 6/21/10, Roman Beslik ber...@ukr.net wrote: I'm trying to: - get source code on different stages of processing in GHC; Probably not hard to do by giving different combinations of compiler flags -- you could do this with either the API or External Core. - dig to the GHC function which is responsible for some alteration in a source code. That would be harder. It would require modifying GHC quite a bit, but I could imagine getting there by using Core's Note construct and then getting the results as External Core. It is hard to trace a link between source code appearing as values in GHC functions and what -ddump-simpl outputs. And I guess that -ddump-simpl Indeed, I think that including enough information in an External Core file, or internal Core module, to map any value back to the original Haskell expression would be a research project in and of itself. Part of that project would involve specifying exactly what the original Haskell expression means -- for example, in the presence of aggressive inlining... Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt In a land of quince jelly, apple butter, apricot jam, blueberry preserves, pear conserves, and lemon marmalade, you always get grape jelly. -- William Least Heat-Moon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Formal semantics for Core?
On 11/30/09, Matthijs Kooijman matth...@stdin.nl wrote: Hi All, I was wondering if there are any formal semantics defined for GHC's core language? I'm working with some core to core rewriting passes for which I'd like to verify the soundness, but that would require some formal definition of the Core semantics of sorts... It may not be exactly what you're looking for, but the extcore package includes a typechecker and interpreter that provide an executable static and dynamic semantics for External Core (which is similar to the Core language that GHC uses externally, but not quite the same): http://hackage.haskell.org/package/extcore Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Do we learn from our mistakes? I surely hope not / Takes all the fun out of making them again. -- Trout Fishing In America ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Building just a stage 1 compiler?
Hi, Is there a way to tell the GHC build system that I only want to build a stage 1 compiler and the libraries, not a stage 2 compiler? Executing: $ sh boot $ ./configure $ make stage=1 in my build tree still builds the stage 2 compiler as well. Thanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Current GHC core documentation.
On 8/3/09, Richard Kelsall r.kels...@millstream.com wrote: This page http://www.haskell.org/ghc/documentation.html has a link to the September 2001 (Draft for GHC 5.02) document describing GHC Core (in what is for me user-hostile .ps.gz format.) And this page http://www.haskell.org/ghc/docs/latest/html/users_guide/ext-core.html promises an easier format PDF document, but the link is broken. Thanks, I reopened the Trac ticket on that documentation bug: http://hackage.haskell.org/trac/ghc/ticket/3135 I did eventually find the 1st April 2009 GHC 6.10 document here http://www.haskell.org/ghc/docs/6.10.2/html/ext-core/core.pdf and a bit on this page http://www.haskell.org/ghc/docs/latest/html/users_guide/options-debugging.html#id468571 about GHC core. I haven't read these yet, but could I ask whether they constitute the complete current documentation for GHC core? (I'm just curious to get a flavour of what core does.) The PDF file is the complete documentation for External Core, along with the typechecker and interpreter (providing a static and dynamic semantics for External Core) under utils/ext-core in the GHC source tree. The version of Core described in the user manual is a little different. If you have questions about any of the abovementioned documentation, please CC both me and this list, as I don't read the GHC lists often. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt The price one pays for pursuing any profession or calling is an intimate knowledge of its ugly side. -- James Baldwin ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
How bad is the PowerPC backend?
Hello, For obscure reasons, I'm running some benchmarks both on an x86 machine (2.20 Ghz, 2 GB of RAM, Linux 2.6.22-15) and on a PowerPC Mac (1 Ghz, 512 MB of RAM, Mac OS 10.5). I noticed that even some pretty simple programs run much slower on the Mac than on the PC. For example, the following program (edited down from the life nofib benchmark): - limit xs = go [] xs go acc (x:y:xs) | x==y = acc ++ [x] | otherwise = go (acc ++ [x]) (y:xs) go acc [x] = acc ++ [x] go acc [] = error limit main = print (length (limit (iterate (\ x - if x == 1 then x else (x+1)) 1))) --- runs in about 1.5 seconds on the PC, and 14 seconds on the Mac. This is with ghc -O2, version 6.10.1. The numbers are about the same on either machine whether I use -fvia-C or -fasm. The Mac does have a lot less RAM, but I can see that the program isn't swapping. So is the PPC backend really this bad, or should I be looking for something weird with the hardware or configuration on the Mac? Thanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt I don't like your I-can-use-anything-as-an-adjective attitude. -- Larry Wall ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How bad is the PowerPC backend?
On 2/9/09, Bulat Ziganshin bulat.zigans...@gmail.com wrote: Hello Tim, Monday, February 9, 2009, 11:16:22 PM, you wrote: So is the PPC backend really this bad, or should I be looking for something weird with the hardware or configuration on the Mac? check GC times too. one possibility is that GC takes much more time due to smaller L2 cache Hmm, doesn't seem to be happening with this example. On the Mac, I get (running with +RTS -s -RTS): 11.86 MUT time (13.95s elapsed) 0.08s GC time (0.15s elapsed) %GC time 0.6% (1.1% elapsed) and on the PC: 1.07s MUT time (1.34s elapsed) 0.01s GC time (0.02s elapsed) %GC time 1.1% (1.6% elapsed) so GC doesn't seem to explain the large difference in running times. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Maybe I don't want to meet someone who shares my interests. I hate my interests. -- Ghost World ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How bad is the PowerPC backend?
On 2/9/09, David Brown hask...@davidb.org wrote: Which CPU is the x86? The modern x86 CPUs (such as Core2) will be significantly faster than the PowerPC, even at comparable clock rates. Have you just compared even C code tests? I think that goes a long way towards explaining it... a simple C loop that I tried runs for 4.5s on the PC and 30s on the Mac. So probably this isn't GHC's fault. Thanks for the suggestion. Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt In fact, a sense of essence is, in essence, the essence of sense, in effect. -- Douglas Hofstadter ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Core questions
You may find it useful to use External Core (supported in GHC 6.10), which allows GHC to dump its Core representation into a text file with a well-defined format: http://www.haskell.org/ghc/docs/latest/html/users_guide/ext-core.html There is a (relatively) stand-alone library for handling Core programs, under utils/ext-core in the GHC distribution. If you don't find it useful, and have any suggestions as to how it could be improved, I would be interested to know; please CC both me and this list if so. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. -- Fred Brooks ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Haskell profiler
On 12/29/08, Srinivas Nedunuri nedun...@cs.utexas.edu wrote: Could someone tell me what the expected accuracy of the Haskell profiler is? I get quite widely varying results for the amount of time spent on a given function across different runs (eg one random example, from 1.5% to 10%). I even upped the size of the dataset in an attempt to increase the accuracy. [redirecting to ghc-users] I assume you mean the GHC profiler. It's normal when profiling any programs, Haskell or not, for timing numbers to vary. Memory allocation counts, however, should be stable across different runs. Also a related q: why doesnt't the time spent in putStr show up? You would have to rebuild your GHC libraries with the -auto-all flag in order to get cost centres attached to library functions (but this may defeat some optimizations). Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt It's okay to be mean to the evil people who make life unbelievable, but try to be nice to me. -- Nerissa Nields ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Retainer profiling -- too slow?
Hi all, Are there any known problems with retainer profiling in GHC 6.8.2? I have a program that takes 3 minutes to run with normal profiling enabled (+RTS -P -RTS), but with +RTS -P -hr -RTS, it's 20 minutes and counting. I can tell that progress is being made since the .hp file keeps getting bigger, but that seems like a lot of overhead. I can try to come up with a smaller test case if necessary; just wanted to see if there's any known problem. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt The trouble with academia is that there's a lot of 'If you'll validate my program of Kumquat Studies I won't point out the uselessness of your doctorate in Nail File Studies.' -- Sarah Barton ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building libraries with ticky-ticky
On 7/20/08, Andrew Hunter [EMAIL PROTECTED] wrote: Right--thing is, it seemed I was getting linker errors on compiling the *libraries*--which seems weird, given that the libraries shouldn't be getting linked, should they? I'm not entirely sure this is what I was seeing, so, well, not a huge consideration, but it does seem weird. That is indeed weird, and I don't know why that would be happening. It didn't happen after you rebuilt in a clean directory, though, right? (Or at least that's what you seem to imply below.) After removing p from GhcLibWays, which makes sense--the docs make it clear we can't combine prof and ticky, though it also implies that it maybe *should* work; might someone what to look into this?--this worked great, thanks. My tests are running nicely and giving what seems like accurate data. Thanks for the very helpful response. I think combining prof and ticky might be nontrivial, because the RTS has all sorts of conditional compilation in it that may be predicated on prof and ticky being mutually exclusive. At least, it's not something I would want to dive into implementing unless I had a good reason, and after all, you can just recompile the same code repeatedly with different options to get both prof and ticky results (although that could get annoying.) Sweet. Admittedly I'm not yet a GHC wizard, but I'd love to help out by fixing this--do you have a rough idea of what would need to be done, or what in fact is the current problem? I'm not a GHC wizard either, which is why the code that's there doesn't work so well. And I suspect that solving the problem will require some build system hacking, which is an area I'm not familiar with at all, so I can't give much advice about how to solve the problem. You're welcome to try, though. I added a ticket at: http://hackage.haskell.org/trac/ghc/ticket/2455 so if you make any progress, you should add a comment there. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt What doesn't kill you makes you look really, really bad. --Carrie Fisher ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building libraries with ticky-ticky
On 7/18/08, Andrew Hunter [EMAIL PROTECTED] wrote: The documentation does *not*, however, say (anywhere I can find) how to do this! My natural guess was to go into mk/build.mk, and add -ticky to GhcLibHcOpts, but that didn't work (regardless of whether I had previously built a ticky rts, this produced a multitude of linker errors.) I also tried, on a lark, adding t to GhcLibWays, and this didn't die, but I'm unclear if it...did anything at all, really. I see no way to really tell one way or another. Hi, Andrew-- I'm not surprised that building the libraries with ticky enabled doesn't work, because when I fixed ticky-ticky profiling a year and a half ago after it was bit-rotted, I hardly tested it and all and certainly didn't try building the ticky libraries. If I try make way=t in libraries/, which should be the proper way to build the ticky libraries, I get errors, so I'm surprised it succeeded for you (unless the build system thought that the libraries were up-to-date and didn't try building the ticky version.) The reason you got linker errors was because, I assume, you had compiled the libraries with -ticky but you weren't passing the -ticky flag to GHC when you compiled your program. If you don't pass the -ticky flag, GHC doesn't link with the ticky RTS, so the library code will include all sorts of undefined symbols. But since you said below that it's OK if things are broken for non-ticky use, you should just be able to do: $ cd libraries/ $ make clean $ make EXTRA_HC_OPTS=-ticky $ cd [wherever] $ ghc -o foo -ticky foo.hs $ ./foo +RTS -rfoo.ticky -RTS and foo.ticky will contain your profiling report. You just won't be able to compile any programs without -ticky this way. In the meantime, I'll look into making the ticky way work so that it'll be possible to have ticky and non-ticky libraries coexisting. If you have any more questions about ticky-ticky profiling, please CC both me and this list, since I don't always read the list carefully. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Faith, faith is an island in the setting sun / But proof, yes, proof is the bottom line for everyone.--Paul Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Rebuilding ghc
On 6/10/08, Dominic Steinitz [EMAIL PROTECTED] wrote: I've built ghc previously and I assumed to keep it up to date I just did darcs pull followed by make but I got errors and according to the rebuilding instructions http://hackage.haskell.org/trac/ghc/wiki/Building/Rebuilding I shouldn't have done that. I therefore followed the instructions but got the following error. It's probably best to do a make distclean at this point, then follow the building instructions. By the way darcs-pull all seemed to require a lot of manual intervention. Is there a way of getting the latest patches automatically and building overnight without intervention? ./darcs-all pull -a will pull all patches without prompting you to ask whether you want to pull each patch, if that's what you mean. The following should pull patches and rebuild everything without manual intervention: ./darcs-all pull -a; sh boot; ./configure; make but YMMV. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Aristotle maintained that women have fewer teeth than men; although he was twice married, it never occurred to him to verify this statement by examining his wives' mouths. -- Bertrand Russell ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unexpected lack of optimisation
Did you try comparing the results if you pass the -fno-state-hack flag? Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt I am never gratuitously rude. My rudeness is carefully calibrated to the stupidity and obtuseness of the people I am dealing with. -- Adam Carr ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Assembly decoding help?
On 3/4/08, Justin Bailey [EMAIL PROTECTED] wrote: I'm trying to get a feel for the assembly output by GHC on my platform. Below is a module containing one function and the associated assembly. I've put in comments what I think is going on, but I'd appreciate it if anyone could give me some pointers. I'd really like to know three things: * Why does _Add_unsafeShiftR_info check if (%esi) is 3? * What's going on in _s86_info? * At the end of _s87_info, 8 is added to %ebp and then jumped to. Is that a jump to the I# constructor and, if so, how did it's address get to that offset from %ebp? I agree with Stefan's advice: read the STG code, especially to answer the second two questions (-ddump-stg), and read the STG paper (if you haven't already): Implementing lazy functional languages on stock hardware: the Spineless Tagless G-machine, SL Peyton Jones, Journal of Functional Programming 2(2), Apr 1992, pp127-202. Then if anything's still not clear, ask on the mailing list. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt The future is not google-able. -- William Gibson ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)
On 2/12/08, Yitzchak Gale [EMAIL PROTECTED] wrote: Manuel M T Chakravarty wrote: I'd also be nice to have a cool logo/icon. Don Stewart wrote: Someone want to clean up the classic GHC logo? http://www.cse.unsw.edu.au/~dons/images/happy-dino.jpg :) The Clyde Arc in Glasgow, combined somehow with a lambda, could be the basis of a striking logo. A logo involving some stylized version of the Clyde Arc drawn so that it looks like it's bridging between a lambda and a CPU, or something like that (shades of this cartoon by Phil Wadler: http://cs.wellesley.edu/~cs301/fall03/lambda-and-chip.gif) could be cool. I am a mediocre artist, but I'd be willing to give it a try if there are no better ones around. Unfortunately, that bridge is suffering from some serious structural and safety issues these days, so perhaps that is ill-advised... It seems perfectly appropriate to me. *ducks and runs* Also, this from Manuel's original message is just beautiful: Installation instructions: nil I'm almost tempted to switch back to a Mac. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt I like my terminals like my women: VT100 compatible with Tektronix extensions. -- Sean Teki Dobbs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] strange GHC assembler failure
On 2/2/08, Tim Newsham [EMAIL PROTECTED] wrote: I'm getting a weird build error: [ 9 of 95] Compiling Plugin.Pl.Common ( Plugin/Pl/Common.hs, dist/build/lambdabot/lambdabot-tmp/Plugin/Pl/Common.o ) /tmp/ghc52608_0/ghc52608_0.s: Assembler messages: /tmp/ghc52608_0/ghc52608_0.s:36:0: Error: unassigned file number 1 [... more of these ...] I narrowed this down -- this happens when I add my new library silc-client to the Build-depends: line in the cabal file even if none of its code is referenced. Removing the dependency makes the error go away. The module I'm referencing is a new one I'm still working on and it makes use of FFI and references external headers and libraries. (I put a copy at http://www.thenewsh.com/~newsham/silc-client.tgz if it helps anyone debug.. this is not release-quality code though). Any idea what is going on here? This would probably be a better question for ghc-users, since that's a lower-traffic list for GHC-specific questions. Redirected there. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Now, don't bother to flame me, because by the time you read this post I will be a different person from the one who wrote it. You cannot step in the same river twice. -- Sarah Barton ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Internships at GHC HQ
On 1/25/08, Dan Licata [EMAIL PROTECTED] wrote: A further plug: I did an internship with Simon PJ last summer (implementing view patterns in GHC, among other things), and this is a great opportunity if you're interested in PL research. There is a lot of interesting work going on at MSR Cambridge, the atmosphere is very friendly, and Cambridge is a lovely place to spend a summer. If anyone wants an intern's-eye view of the experience, feel free to e-mail me! I second most parts of this (including the feel free to email me part). I hear that the summer is busiest with respect to interns, but those who can arrange it with their graduate programs ought to consider applying for an internship during the school year. I don't know what things are like now, but I found that there were plenty of other interns around to keep me company even during the fall, and Cambridge is a lovely place to spend an autumn as well. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt The more you talk, the more I get / a sense of something that hasn't happened yet / The more you talk, the more I want to know / the way I'll remember you when I go. -- Ani DiFranco ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Core question
On 1/7/08, Neil Mitchell [EMAIL PROTECTED] wrote: Hi How are you printing out the Core? showSDoc $ ppr c where c :: [CoreBind] It looks like the unique ids are missing (you can see them if you pass the -ppr-debug flag, which can be set using the API) I have now set the -ppr-debug flag, but that has no effect. It's not entirely surprising, as I guess setting the flag only applies through the GHC session, and this code is being run outside that. How can I print the output (to a file) using the unique id's? Good point about the session, I forgot about that. It looks like you can call showSDocDebug instead of showSDoc (see utils/Outputable.lhs), which acts as if -dppr-debug is set, but I haven't actually tried it. Can I invoke CoreTidy using the GHC API? Yes, but you'll need to grab a post-Dec-25 build if you haven't already, since I added this recently. Once you have, see compileToCoreSimplified in main/GHC.hs. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt It's easy to consider women more emotional than men when you don't consider rage to be an emotion. -- Brenda Fine ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Core question
On 1/5/08, Neil Mitchell [EMAIL PROTECTED] wrote:
Hi
I've compiled the Debug.Trace module to Core, but can't understand the
resulting output. The original code is:
trace string expr = unsafePerformIO $ do
putTraceMsg string
return expr
The core is:
Debug.Trace.trace =
\ (@ a) -
__letrec {
trace :: GHC.Base.String - a - a
[]
trace =
\ (string :: GHC.Base.String) (expr :: a) -
GHC.Base.$
@ (GHC.IOBase.IO a)
@ a
(GHC.IOBase.unsafePerformIO @ a)
( @ () @ a (Debug.Trace.putTraceMsg string) (return @ a expr));
$dMonad :: GHC.Base.Monad GHC.IOBase.IO
[]
$dMonad = $dMonad;
return :: forall a. a - GHC.IOBase.IO a
[]
return = GHC.Base.return @ GHC.IOBase.IO $dMonad;
$dMonad :: GHC.Base.Monad GHC.IOBase.IO
[]
$dMonad = GHC.IOBase.$f16;
:: forall a b.
GHC.IOBase.IO a - GHC.IOBase.IO b - GHC.IOBase.IO b
[]
= GHC.Base. @ GHC.IOBase.IO $dMonad;
} in trace;
And my Haskell reformatting of that is:
Debug.Trace.trace = let
trace string expr = unsafePerformIO $ putTraceMsg string return expr
$dMonad = $dMonad;
return = GHC.Base.return $dMonad;
$dMonad = GHC.IOBase.$f16;
= GHC.Base. $dMonad;
in trace
However, that let expression has two bindings for $dMonad, one of
which looks like a black-hole. Are the semantics of __letrec different
from let in some way?
How are you printing out the Core? It looks like the unique ids are
missing (you can see them if you pass the -ppr-debug flag, which can
be set using the API) -- if the unique ids were being printed, you
would see that the bindings for $dMonad (likely) have different
uniques.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
...Losing your mind, like losing your car keys, is a real hassle. --
Andrew Solomon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Redefining built in syntax
Hi, Neil-- On 1/3/08, Neil Mitchell [EMAIL PROTECTED] wrote: Hi Victor, -package-name base should do the thing Thanks very much, that is the correct flag to allow built in syntax. However, turning that flag on also does other stuff, which breaks new things. Taking the module Prelude.hs, from a darcs checkout of the libraries: C:\Documents\Uni\packages\baseghci Prelude.hs -i -cpp -fglasgow-exts GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Ok, modules loaded: Prelude. i.e. you can load the Prelude. However, specifying -package-name base: C:\Documents\Uni\packages\baseghci Prelude.hs -i -cpp -fglasgow-exts -package-name base GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help interactive:1:22: Failed to load interface for `System.IO': it is not a module in the current program, or in any known package. interactive:1:22: Not in scope: `System.IO.stderr' interactive:1:22: Not in scope: `System.IO.stdin' : panic! (the 'impossible' happened) (GHC version 6.8.1 for i386-unknown-mingw32): interactiveUI:setBuffering Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Yeah, I've seen this before. One thing is that I generally avoid running code that uses the GHC API in GHCi, because I saw some reference somewhere to the fact that data structures can get mixed up that way, and it just seems to lead to madness :-) I've definitely seen the setBuffering panic message before, though haven't filed a bug report since I can't reproduce it reliably. In GHC, though, I can compile base package modules to Core just fine, if I provide the right import flags (-i and -I) so it can find all the dependencies. (If you want to see the complete list of flags I'm using, let me know :-) This is the same behaviour as loading Prelude without specifying -i. Moving -i to other places still gives the same behaviour. Does package-name base also imply other flags (perhaps -i. ?) which are negatively effecting my particular use. I don't know, but in GHC (as opposed to GHCi), it all works. I can post some sample code if that would help; let me know. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt More than at any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other, to total extinction. Let us pray we have the wisdom to choose correctly.--Woody Allen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: whole program optimization
On 12/24/07, Isaac Dupree [EMAIL PROTECTED] wrote: Stefan O'Rear wrote: It's been done. http://www.cs.utah.edu/~hal/HAllInOne/index.html Stefan which alas seems to have a ridiculous, probably unenforcable license :-) Interesting though - I wonder how correct it is. [wildly off-topic, but...] It's not entirely clear, but this license doesn't seem any less enforceable than any other clickwrap license. I think the usual arguments for why the GPL is enforceable (see, for example, http://www.open-bar.org/docs/GPL-enforceability.pdf) apply to this license too, silly as it may be. Also see the caselaw on clickwrap licenses, summarized at http://en.wikipedia.org/wiki/Clickwrap#Legal_consequences_in_the_United_States_of_America (yeah, Wikipedia, but at least it's well-cited). Modulo the copyright-vs.-contract debate, there's nothing in the Big-Kazooba-Ritual license that seems to violate the usual principles for a unilateral form contract, probably because no lawyer would ever think up something that perverse :-) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt After three days without programming, life becomes meaningless. -- James Geoffrey ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: More spam problems on trac
On 12/11/07, Simon Marlow [EMAIL PROTECTED] wrote: We have the spam filter Trac plugin installed, but apparently we don't have the BadContent wiki page from which the spam filter gets its regular expressions, so I just added one. Hopefully that should catch some of the spam. Looks like that's not quite enough: http://hackage.haskell.org/trac/ghc/wiki/WikiStart?action=diffversion=105old_version=104 I rv'ed that one -- just a heads-up, since if there's spam now, there will be more spam later. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt the faith that is so easy to forget / in moment after moment of distraction -- Ilene Weiss ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
More spam problems on trac
It seems the new thing for spammers to do is to add spam text wrapped in the p style=display:none tag. For example, http://hackage.haskell.org/trac/ghc/wiki/WikiStart?action=diffversion=106 I don't know if anyone else has noticed this. Maybe it's time to require captchas for account creation or something? Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt Research is what I'm doing when I don't know what I'm doing.--Wernher von Braun ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Can't seem to figure how to compile
On 10/21/07, John Vogel [EMAIL PROTECTED] wrote: Running ghc 6.6.1 On Windows Vista I get this error when I run: ghc Main.hs gcc: installation problem, cannot exec `as': No such file or directory Did you follow these instructions when you installed GHC? http://hackage.haskell.org/trac/ghc/wiki/Building/Windows (there are some special procedures here for Vista users). Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt Knowledge was power, as long as one did not muck it up by confusing one piece of knowledge with another and trying to ingest it and turn it all into blood and feelings. -- A.S. Byatt ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Additional thunk for function
On 9/21/07, Victor Nazarov [EMAIL PROTECTED] wrote:
Here is some more details:
% ghc -c -ddump-stg T1.hs
STG syntax:
T1.map =
\u []
let {
map1_sdR =
\r [f_sdN ds_sdI]
case ds_sdI of wild_sdU {
[] - [] [];
: x_sdM xs_sdQ -
let { sat_sdT = \u [] map1_sdR f_sdN xs_sdQ; } in
let { sat_sdP = \u [] f_sdN x_sdM; } in : [sat_sdP
sat_sdT];
};
} in map1_sdR;
SRT(T1.map): []
% ghc -c -ddump-stg T1.hs -O
STG syntax:
T1.map =
\r [f_sel ds_seg]
case ds_seg of wild_ser {
[] - [] [];
: x_sek xs_seo -
let { sat_seq = \u [] T1.map f_sel xs_seo; } in
let { sat_sen = \u [] f_sel x_sek; } in : [sat_sen sat_seq];
};
SRT(T1.map): []
Sure, it makes sense that the extra thunk would be allocated when
optimization is disabled (if you don't pass in any optimization flags
like -O, it's like saying don't do any optimization). Don't expect
GHC to generate efficient code with optimization turned off :-)
Cheers,
Tim
--
Tim Chevalier * catamorphism.org * Often in error, never in doubt
Other than to amuse himself, why should a man pretend to know where
he's going or to understand what he sees? -- William Least Heat Moon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Adding type signature changes semantics (was [Haskell-cafe] Lazy in either argument?)
On 8/3/07, Isaac Dupree [EMAIL PROTECTED] wrote: The surprise is that an unconstrained type-variable being variable rather than instantiated to an arbitrary type, makes any difference (since it doesn't, normally, at runtime). Right... it's surprising because types aren't supposed to matter at runtime. I would guess the programs `Bool` and `a` are the same once optimizations are turned on? Maybe GHC could avoid the creation of type-lambdas that are unused (in some sense)... with -Onot... I'm dubious about that. Right, both programs result in the same runtime behavior if optimizations are turned on. (Which, of course, is another surprising thing: the program with the type signature omitted loops if compiled with -Onot and terminates if compiled with -O.) Cheers, Tim -- Tim Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Ticky Ticky profiling
On 7/31/07, Cristian Perfumo [EMAIL PROTECTED] wrote: Hi all!. I modified build.mk in order to allow Ticky-Ticky profiling (GhcLibWays=t). Now, when I try to make I get this error: == make way=t all; PWD = (the_whole_path)/ghc-6.6.1/rts ../compiler/ghc-inplace -H32m -O -fasm -W -fno-warn-unused-matches -fwarn-unused-imports -optc-O2 -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -hisuf t_hi -hcsuf t_hc -osuf t_o -ticky -#include posix/Itimer.h -c PrimOps.cmm -o PrimOps.t_o ghc-6.6.1: panic! (the 'impossible' happened) (GHC version 6.6.1 for i386-unknown-linux): ToDo: tickyAllocThunk Hi, Cristian-- To get ticky to work, you need the HEAD (or a recent nightly build snapshot). If it's still not working after that, post again. Cheers, Tim -- Tim Chevalier* catamorphism.org *Often in error, never in doubt More than at any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other, to total extinction. Let us pray we have the wisdom to choose correctly.--Woody Allen ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: *****SPAM***** Annotation for unfolding wanted
Have you tried using the INLINE pragma? http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#inline-noinline-pragma Cheers, Tim -- Tim Chevalier* catamorphism.org *Often in error, never in doubt You have not proven yourselves smart enough to act that stupid all the time and get away with it. -- Andrea Nemerson ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
