Re: The GHC build system

Hi Simon, >> With Shake, it's possible to run it single threaded and dump a list of >> all system commands performed. With a little bit of care (you couldn't >> use your Haskell Shake code to query the global environment in >> non-obvious ways), this could be used as the initial bootstrap. It's >>

Re: The GHC build system

Hi > We've talked before about the need to bootstrap occasionally, which as I > understand was one of the reasons for using make. I agree that something > like Neil's Shake system would be nice if it didn't require a working > Haskell implementation to build the driver. With Shake, it's possible

Re: Searching GHC with Hoogle

t a Hoogle textfile containing the info (I use http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/ghc.txt at the moment) then I'm happy to switch over. Thanks, Neil > On 1 May 2011 11:13, Neil Mitchell wrote: >> Hi, >> >> I've now extended Hoogle to searc

Searching GHC with Hoogle

Hi, I've now extended Hoogle to search the GHC API, as detailed in this blog post: http://neilmitchell.blogspot.com/2011/05/searching-ghc-with-hoogle.html As a simple example, to find out about the GHC register allocator, you can search for: http://haskell.org/hoogle/?hoogle=%2Bghc+alloc+reg T

Re: interleaved/detached commenting style

Hi, I had a chance to refresh Hoogle, so now the links work fine. Thanks to Ranjit for generating the original GHC text database. Thanks, Neil On Sat, Apr 30, 2011 at 4:51 PM, Neil Mitchell wrote: > Hi, > > I uploaded ghc.txt and converted it to Hoogle format. The links don'

Re: interleaved/detached commenting style

gt; >        http://goto.ucsd.edu/~rjhala/ghc.hoo > > This links to the ghc-7.0.2 documentation and is an > absolutely wonderful way to peer into the innards of GHC! > > Ranjit. > > > > On Apr 28, 2011, at 11:23 AM, Neil Mitchell wrote: > >> Hi Ben, >> >>

Re: interleaved/detached commenting style

Hi Ben, Have you thought about setting up a Hoogle instance for the GHC code base? I know Ranjit (cc'd) has been using it to help him get to grips with GHC, but I can imagine it's useful for all the newcomer GHC developers. If someone sends me the haddock --hoogle text output I'm happy to host it

Re: how frowned-upon is "recursive coreView"?

Hi Adam > The function at the end of this email walks over a Type, basically > (recursivey) replacing it with its coreView.  The resulting tree has no > PredTy's except for (PredTy (EqPred _ _)). Unrelated to your real point, but have you considered using a generics library? I don't know the deta

Re: RFC: migrating to git

> 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

Re: Passing --hoogle to haddock when building base

Hi Claus, > While you're revisiting Hoogle, might you be able to > work from .haddock and .hi files (via haddock API and > GHC API/ghci), instead of from sources, making Hoogle > independent of/separate from Haddock's frontend? All Hoogle needs is a way to generate a text file listing exactly wha

Passing --hoogle to haddock when building base

Hi, For nearly all packages on hackage, haddock is run over them with --hoogle, which generates documentation (http://hackage.haskell.org/package/stm) and a hoogle database (http://hackage.haskell.org/packages/archive/stm/2.2.0.1/doc/html/stm.txt). However, the base library is special, and hackage

Re: Gut Build System

>>> http://chadaustin.me/2010/03/your-version-control-and-build-systems-dont-scale-introducing-ibb/ >> >> This link is crazy. He's abusing big O notation, complaining about >> constant factors (Python starting up) then suggesting he needs to >> reduce the algorithmic complexity. He also forgets to

Re: Gut Build System

Hi, As Simon says, I've got some experience using Haskell for writing build scripts. I had a fork of the Yhc build script written in Haskell, for example. I think it's a very good idea in general. For GHC in particular, they currently have a build system that works, what's the benefit of changing

Re: Hackage testing

Hi Ian, Is the list of which 215 packages failed available somewhere? It would be nice to know if any of my packages were on it. Thanks, Neil On Sat, Jan 30, 2010 at 2:17 PM, Ian Lynagh wrote: > > Hi all, > > We now have an automated program for performing regression tests against > all of hack

Re: Exploding SpecConstr

Hi >> BTW: What's up with the buildbots? The daily reports haven't been very >> informative lately. Is this fallout from the monk ->  abbot move? > > We decided not to try to stick with buildbot - it isn't suitable, in that it > can't cope with dropped connections, and it would be too hard to fix

Re: Newtype wrappers in hsSyn

Hi > I know Uniplate.  But there are two issues: > >  1. SYB will start using the table trick soon from what I hear, so I hope it > won't be too slow. That would be cool - although I do wonder how it can be done with the very general type of everywhere/everything. If you restrict the types (like

Re: Newtype wrappers in hsSyn

Hi >> | These have always distressed me. Would it be feasible to refactor so >> | that this isn't necessary, e.g. >> | >> |     typecheck :: HsSyn Name () -> HsSyn Name PostTcInfo > The problem is that these annotations tend to be constructor-specific. You > might get it to work with GADTs, but I

Re: Windows DLLs should be working.

Hi Andrew, > It may be that the best way to do things on Windows (at least for now) > is just to link Haskell code statically, and only use DLL support for > FFI - ie, how things currently work. This isn't a patch that changes the default - I suspect Windows will build static exes forever more. H

Trac down

Hi, The following page times out: http://hackage.haskell.org/trac/ghc/wiki/ReportABug Thanks, Neil ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

Fwd: [Haskell-cafe] Broken GHC doc links

Hi GHC Team, Was this deliberate? Will it be rolled back? I suggest it should be rolled back, for the good of Google if nothing else. If there is no intention to fix it, then I'll update Hoogle. Unfortunately there is no similar way to fix Google. Thanks, Neil -- Forwarded message

Re: Recycling GHC repos

Hi Simon, I believe the repo with my name attached to it was actually created by Samuel Bronson - during Yhc development the haskell.org policy was that Yhc developers got added to my key list. Thanks, Neil On Mon, Dec 14, 2009 at 3:31 PM, Simon Marlow wrote: > On 14/12/2009 13:37, Simon Peyton

Re: Misbehaving msys tar

I've often had problems with many tar versions on Windows - certainly I've had the msys one and the UnixUtils one fail to operate properly with Cabal. My preferred solution is to get bsdtar (first google hit works), and rename the executable from bsdtar.exe to tar.exe. I've found that is very relia

Re: initial "foreign import prim" patches for review

Hi > I've changed it to require -XGHCForeignImportPrim. The idea of naming a language feature with a compilers name seems like a bad idea - surely these extensions could possibly work in other compilers, for example LHC. It all sounds like a very sensible direction to go in though :-) Thanks N

Re: specifying an ELF soname when linking shared libs

Hi > With gcc, on ELF platforms you would use: > > $ gcc -shared Blah.o -o libblah.so -Wl,-soname,libblah.so > > We could require (or at least suggest) -package-name be given when > linking a shared lib. However that would involve baking in the "HS" > library prefix name convention into ghc. > > O

Re: Build races when using make -j8 ?

Hi Some possibly related information: I've been running parallel builds of a different code base using GHC as a compiler. I occasionally see zombie GHC processes created (starting but not doing anything) and I also get your mismatched .hi interface files message as well. I'm hoping to figure out w

Serious Haddock bug

Hi, I found a fairly serious Haddock bug: http://trac.haskell.org/haddock/ticket/69 It causes GHC's documentation to go wrong (http://hackage.haskell.org/trac/ghc/ticket/2894#preview), Hoogle to break (http://code.google.com/p/ndmitchell/issues/detail?id=101) and will effect Hackage before too lo

Old version of directory on hackage

Hi, GHC 6.10.1 ships with Directory 1.0.0.2, but hackage only has the directory package 1.0.0.0. Shouldn't they be syncronised? Thanks Neil ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

Re: patch applied (ghc): Add assertion for arity match (checks Trac #2844)

Hi Simon, > On Windows (MSYS) I get several failures that I'm pretty sure have been there > for a while. They seem to relate to things like 'printf' not existing. That > makes it harder to interpret a Windows validate run. > > I wonder if someone (Neil? Ian?) might investigate? I've no longer

Re: HEADS UP: patches, package versions, and cabal-install

Hi > You make it sound like "ghc gives you your linker error in raw form" is a > deliberate feature we implemented just to make your life more difficult! No, > obviously it's just the easiest thing to do, and we haven't implemented > anything more elaborate. I think most link errors are because t

Windows crashing bug + patch

Hi, Last week I raised a bug, and attached a patch: http://hackage.haskell.org/trac/ghc/ticket/2603 The issue is hard to work around, and the fix is trivial and small. Is it possible to get this fix included in 6.10.1? Thanks Neil ___ Cvs-ghc mailing

Re: Splitting off ext-core library?

Hi Tim Sounds a great idea. My only question is the name for the library - ext-core in the GHC tree means implicitly GHC, and the library name means external core. On hackage ghc-core would implicitly mean external, and the name means GHC Core. Just a thought, and doesn't matter too much - I'd use

Re: Updating External Core docs for 6.10

> OK so regardless of doing the "ship ExtCore ps doc with GHC" issue, we should > in-place > update the doc at http://www.haskell.org/ghc/docs/papers/core.ps.gz I was actually suggesting that the documentation should _not_ be updated in place, which I think is what Tim was initially proposing. I

Re: haddock

Hi > This does mean that any patches to the main haddock repo need to pass > validate. I contribute patches to Haddock, but have no way to run validate (I don't have my own computer currently, and can't install mingw/cygwin on any of the machines I have access to). What should I do? I doubt the p

Re: Updating External Core docs for 6.10

Hi Tim, > Yes, but first I was hoping that the contents of the link at: > http://www.haskell.org/ghc/docs/papers/core.ps.gz > (which the manual points to) could be updated. I don't have access to > do that myself, as far as I know. Could you please upload a new document, and point at the new one?

Re: The GHC library and hierarchical module names

Hi > In fact, one drawback of using a hierarchy is that it does suggest (by way > of module names) a hierarchy that the code does not have. For example, I > believe there are going to be cyclic imports between files in different > subtrees. That may make the situation actually more confusing tha

Re: Docs for language flags

> | It might be easier if the information was duplicated there, as then it > | would be hoogle-able (although making the GHC manual hoogle-able is on > | the Hoogle bug list > > I don't know how it gets there... GHC might have more extensions than Cabal > for > example? Anyway, I'm perhaps-selfi

Re: Docs for language flags

Hi > The documentation for language extensions appears in GHC's user manual in > *three* places: > > (a) The flag summary > http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id352860 > > (b) A section at the beginning of Chapter 8: > http://www.haskell.org/ghc/docs/lat

Haddock/GHC/C Pre Processor interactions on Windows

Hi, I've tracked down a bug, involving newline characters that is the combination of GHC and Haddock, but involves the C Pre Processor - hence sending the bug report for general discussion to everyone concerned first. I suspect this bug is Windows only. Given the file (UNIX \n or PC \r\n format):

Re: HEADS UP: big codegen patch

Hi > Can you summarise the state of play, and direction for the new codegen > project? John gave a short talk at AngloHaskell, in the functional grit section. The audio is online: http://www.wellquite.org/anglohaskell2008/ Thanks Neil ___ Cvs-ghc ma

Re: Data/Typeable/Uniplate instances for GHC types

> Please do - I suspect that GHC structures can become quite large, > and though they might not be as big as that benchmark, the penalty > seems substrantial. I will probably leave it for a short while, til I am on a better machine to run the necessary benchmarks. But I do want to track it down

Re: Haddocked GHC

Hi > Nevertheless, this is a good start to even more accessible GHC source code. Yay! I have wanted this in the past. Now that you have GHC working with haddock, having the GHC source code indexed by Hoogle won't be that far away. > PS: Looking at >

Re: Data/Typeable/Uniplate instances for GHC types

Hi >*Main> uni_bill laemmel >{CompanyDatatypes.Employee} >{CompanyDatatypes.Salary} >8000 >*Main> uni_bill laemmel >{CompanyDatatypes.Employee} >{CompanyDatatypes.Salary} >8000 >*Main> (uni_bill laemmel,uni_bill laemmel) >

Re: Data/Typeable/Uniplate instances for GHC types

Hi > I think I've figured out what is going on: this technique simply > doesn't work as well as we might hope it would! Here's why: > > While you ignore the explicit parameter, in practice there's an > implicit dictionary parameter that is actually being used in res > (Data/Typeable). At first

Re: Data/Typeable/Uniplate instances for GHC types

Hi > > That approach worries me. We could add generic traversals all over the > > place, and while none of them is a "bottleneck", the overall effect could > be > > quite significant. > > I recently added Data and Typeable instance to all AST datatypes > directly in the code of GHC, the compi

Re: Data/Typeable/Uniplate instances for GHC types

Hi > From your thesis/paper, it seems that queries, such as 'bill' in the > Paradise benchmark, are the worst offenders, performancewise, and applying > your techniques for Uniplate to the SYB query for 'bill' seems to achieve a > similar reduction in runtime. > 'contains' is interesting, and s

Re: Data/Typeable/Uniplate instances for GHC types

Hi > Might help if library author and user are related?-) Yes :-) I'd like to think that anyone can use Uniplate in a very high-level manner, but someone other than me needs to argue that. > So far, I still think that SYB for GHC types is a good and necessary > first step. If adding Uniplate

Re: Data/Typeable/Uniplate instances for GHC types

Hi > > too general to allow the Uniplate solution, but it would be easy to > > add universe/transform to SYB and implement them using them much more > > efficiently. > > > > It has been a while, and most of my experience was with Strafunski's > StrategyLib, but I seem to recall using the predefin

Re: Data/Typeable/Uniplate instances for GHC types

Hi > > No boilerplate removal code 1:30min > > Uniplate with PlateDirect (fastest method) 1:45min > > Uniplate with PlateData (based on SYB) 5min > > > > And I suspect directly using SYB would have been somewhere in the > > 10-15min range. > > > > It would be useful to have more information about

Re: Data/Typeable/Uniplate instances for GHC types

Hi > How did you define the Data instances for the abstract types > (break the abstraction or define the instances abstractly), and how do your > instances compare to the ones at > http://hackage.haskell.org/trac/ghc/wiki/GhcApiAstTraversals > ? The Uniplate one's can't transform the type, and

Re: Data/Typeable/Uniplate instances for GHC types

Hi > You can implement Uniplate on top of Data/Typeable. (It's slightly slower > than giving Uniplate instances directly, but if my memory serves, not a lot. > See Neil's theis.) So you can think of Uniplate/Biplate as a rather nice API > for generic programming, but one that shares a common

Re: Priorities for 6.10

Hi > > Does anyone have any objections to us doing this? I agree it would be a > > substantial win. We should consider cabal-install to be a part of Cabal - > > indeed the 'cabal' command is the preferred UI for Cabal now, so to ship > > one without the other seems wrong. > > We'll also have

Re: Priorities for 6.10

Hi > While I was away last week I jotted down a list of priorities for 6.10. > Some of these are in the bug tracker and some aren't, but I think it'd be a > good idea for us to first discuss what we really want to see happen in the > 6.10 time frame and then update the ticket database to matc

Re: Priorities for 6.10

Hi > * initial GHC API improvements: provide generic traversals of GHC > ASTs (via Data/Typeable) Seconded. A simple Data/Typeable will cover most uses, but it seems because of the particular data types a Functor/Traversable instance may be useful. The other useful thing would be to get the GHC

Re: Darcs

Hi > * darcs pull -a http://darcs.haskell.org/ghc > fails with the case-sensitivity bug Either cpphs or hscolour fails with the case-sensitivity issue. The solution Malcolm used was to set a checkpoint, darcs optimise to it, then recommend Windows users pass --partial. This way darcs ski

Re: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core

Hi Don, > Just a quick announcement, I've uploaded to hackage 'ghc-core' , a > wrapper over ghc for displaying the optimised core and assembly language > ghc produces from your programs. This is cool, but it still lags behind the facilities found in yhc-core. http://yhc06.blogspot.com/2006/12/

Re: patch applied (ghc): Replace one occurance of CVS with darcs in HACKING

Hi > This was actually me. Maybe I should get an account of my own on > darcs.haskell.org... Probably! Was a little shocked to see me committing to GHC without realising. More importantly, you seem to keep getting emails at neil-darcs.haskell.org, which end up in my inbox, and not yours. Thank

patch applied (ghc): Replace one occurance of CVS with darcs in HACKING

Mon Apr 7 15:20:06 PDT 2008 Samuel Bronson <[EMAIL PROTECTED]> * Replace one occurance of CVS with darcs in HACKING M ./HACKING -1 +1 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080407222006-90c7a-5e12ae7a5d1e136e4eb73b36190e47553d1bd54b.gz __

Re: STG code

Hi Simon, > It relates to strictness info etc. I strongly suggest you do not try to > parse this stuff -- it was never intended for that. Why do you think > ext-core is harder? It's designed to be easier! The ext-core stuff is more complicated, and the support libraries that were meant to exist

Re: A couple patches

Hi > The unsafePerformIO patch is something Neil asked me to send in. It's a > cleaned up, slightly renamed and documented version of inlinePerformIO > that we use in ByteString, but exported from System.IO.Unsafe. > Similarly, the unsafeDupablePerformIO are also exported (separate > patches). And

patch applied (nofib): Add a type signature to imaginary/integrate, for compilers lacking the monomorphism restriction

Sun Jan 27 04:47:50 PST 2008 Neil Mitchell * Add a type signature to imaginary/integrate, for compilers lacking the monomorphism restriction M ./imaginary/integrate/Main.hs -1 +2 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http

patch applied (nofib): Add type signatures for compilers lacking the monomorphism restriction (nhc/yhc)

Sun Jan 27 04:33:47 PST 2008 Neil Mitchell * Add type signatures for compilers lacking the monomorphism restriction (nhc/yhc) M ./imaginary/bernouilli/Main.hs +4 ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman

Re: Remove GHC.Err import from Data.Maybe

eil On 12/31/07, Neil Mitchell <[EMAIL PROTECTED]> wrote: > Hi, > > I noticed that Data.List uses "error" normally, but Data.Maybe > explicitly imports it from GHC.Err. Is there a reason for this? > Removing the import GHC.Err line still appears to work. > >

Remove GHC.Err import from Data.Maybe

Hi, I noticed that Data.List uses "error" normally, but Data.Maybe explicitly imports it from GHC.Err. Is there a reason for this? Removing the import GHC.Err line still appears to work. This caused me issues with circular modules and recursive boot files, in various mixtures. It's not a fatal is

Re: unboxed types

Hi Isaac, > Or will I have to > #define UTopen (# > #defined UTclose #) > > and (UTopen x, y UTclose) Yuk! There is a ticket on adding a prefix form of (#,#), which is currently lacking. Perhaps adding that first, then moving to the unboxed thingy would be best. Also your use of # in a CPP macro

GHC 6.8.1 package source and haddock documentation

Hi, I've just finished generating Hoogle documentation for the GHC 6.8.1 libraries, linking to http://haskell.org/ghc/docs/latest/html/libraries/base-3.0.0.0/ and getting the package source from http://darcs.haskell.org/packages/base/. This combination isn't correct, as things like Control.Categor

Re: Darcs

Hi >- Windows support: is quite flaky still I haven't found this to be the case. There are released binaries of darcs, which I've had lots of success with. There are only two Windows issues I've run into: * "darcs send" doesn't work. I get around this by darcs send -o file, gzip file, then s

Re: should haddock.ghc be a sub-repo of ghc?

Hi > David (in the desperate need of a Trac for Haddock) code.google.com - like Trac but much better... - as used in XMonad and Yhc Thanks Neil ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

Re: should haddock.ghc be a sub-repo of ghc?

Hi > the point is that haddock.ghc is using the ghc api, which is > (a) an internal api, or at least an api to ghc's internals and > (b) still under rapid development. It's an exported, stable, documented and supported API - or at least I believe that is the eventual intention. > one could think

Re: should haddock.ghc be a sub-repo of ghc?

Hi Claus, > my suggestion: > - keep it as a separate repo, but let darcs-all fetch it > - build haddock.ghc during ghc's make, but distribute > it as a separate tool > > that way, it would get daily builds and, more importantly, > anyone making a change that affects haddock.ghc would > notice

Re: ghci command output capture & full :browse! (draft patches)

Hi > I realise this already happens: the emacs GHCi mode talks to GHCi directly, > and GuiHaskell does too. But I hereby declare that this is the Wrong Way > To Do It. The right way is to use the GHC API, starting from your own copy > of the GHCi front-end if you like. For GuiHaskell there are

Re: GHC hacking in Windows -> too much pain

Hi Esa, > For some weeks I've tried many times to get ghc builds going, > with the idea I could help with Windows bugs. But I find simply > building ghc in my non-static configuration Windows machine is > simply too frustrating. My experience building the libraries for Hugs using Windows (in par

Re: change to deriving in 6.7 ??

Hi > Thanks for the tips, Isaac. I fixed my Ord decl. Too bad about the > run-time time & space overhead. I guess that's not fixable. Perhaps Simon > will decide to follow Pepe's suggestion of liberal deriving when > UndecidableInstances enabled. If you implement compare, isn't everything els

Re: Performance regressions in HEAD

Hi Simon, > | > Is this the same as you and Simon have been subsequently discussing > | (stack, heap checks), or is it another performance bug? > | > | This is an entirely separate performance bug. The heap check makes one > | of the two variants run 10% slower. This bug effects both variants, > |

Yhc Buildbots on darcs.haskell.org

Hi, The Yhc buildbots have been very useful over time, and we certainly can't live without them. Unfortunately the person who has admin access is no longer working in our department, so slowly they are starting to break, since we are unable to give them any external commands - such as fullclean. H

Re: Update; cpphs for GHC?

Hi I have some misgivings about whether linking LGPL Haskell libraries is within the spirit of the license, given that re-linking is often impractical. But nobody else seems to care about this, I haven't seen any authors of Haskell LGPL libraries complain that users can't easily comply with it.

Re: Update; cpphs for GHC?

Hi I haven't tried, but doesn't this already work if you set the CPP environment variable to cpphs before running configure? You might also need to set CPPFLAGS to something. If you pass the --cpp flag then cpphs works like GHC expects, otherwise it has a different set of flags. Thanks Neil

Re: Space profile

Hi Duncan, I wrote that several years ago when I was trying to track down a space leak in c2hs's C parser. I should really update it to read the machine-readable profile output format (rather than the silly excuse for a parser it has currently) and cabalise it and stick it on hackage. As a not

Re: Space profile

Hi Simon, For my OSCON tutorial I want to throw up a picture of * a time profile (text I guess) Are you aware of the graphical profile viewer for time profiles? It's one of the demo programs shipped with Gtk2Hs. I've attached a screen shot of the a profile run for Catch. Thanks Neil <>_

Re: Performance regressions in HEAD

Hi Simon, I bet this is related to getchar. When compiling via C, the C compiler can inline getchar, but with -fasm we have to just call getchar(). Take a look at the asm generated for each way, and try swapping over the fragments that do getchar(). It does appear so. I've hacked the C versi

Re: GHC Head Bugs

Hi > First, it appears that GHC.Prim no longer exists, I can't :m it. I was > using it as the import location for RealWorld and State# - I've now > moved to using GHC.Base. http://www.haskell.org/pipermail/glasgow-haskell-users/2007-May/012674.html The issue was reported back in May but must h

Re: Performance regressions in HEAD

Hi Simon, I've attached a new sample file, which is what this particular message relates to, although it should be nearly identical to the last one I sent you. There was a small difference between -fasm and -fvia-C, with -fvia-C winning by a few percent. I tracked this down to the getchar() ca

GHC Head Bugs

Hi I just tried to upgrade to the latest Head which has a Windows installer, http://www.haskell.org/ghc/dist/current/dist/ghc-6.7.20070709-i386-unknown-mingw32.exe First, it appears that GHC.Prim no longer exists, I can't :m it. I was using it as the import location for RealWorld and State# - I

Re: Performance regressions in HEAD

Hi Simon, > The attached charcount.zip shows the optimised cmm and the assembler. > As far as I can tell, the optimised cmm for the hotspot function in > both cases is identical, and the code should be spending all its time > in the hotspot. The names are Main_zdspreludezu942zull85_entry for 6.7

Re: Performance regressions in HEAD

% slowdown. Thanks Neil Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Mitchell | Sent: 05 July 2007 21:21 | To: cvs-ghc@haskell.org | Subject: Performance regressions in HEAD | | Hi | | Running my benchmark of character counting, with the

Re: Performance regressions in HEAD

, but as far as I can tell, both do have the same gcc (3.4.2 mingw). I reran the tests this morning with a clean directory compiling both with "ghc --make -O2 -fasm 4.hs -o ". 6.7 runs the benchmark in 8.7 seconds, 6.6.1 takes 3.2. Thanks Neil Neil Mitchell wrote: > Hi > &

Re: Performance regressions in HEAD

Hi Yet more information. Both were compiled using -O2, and for the ASM/CMM dumps with -fasm as well. Thanks Neil On 7/6/07, Neil Mitchell <[EMAIL PROTECTED]> wrote: Hi Further information: Focusing on 4.hs (I will have another email in detail about the differences between the two), G

Missed optimisation

Hi, I am working on a Core -> Core optimising pass in Yhc Core, which then spits out GHC Core at the back end. In response to Simon M's comment that the lack of using GHC's IO Monad meant the results were unreliable, I have now moved to integrating with GHC's notion of IO. While the STG gets simp

Performance regressions in HEAD

Hi Running my benchmark of character counting, with the files ExampleSingle.hs (hand written) and 4.hs (generated by Supero), I get vastly superior performance using GHC 6.6.1 compared to ghc-6.7.20070626. GHC 6.6.1 GHC: Elapsed time = 8.047 seconds Supero: Elapsed time = 2.641 seconds GHC 6.7.

Re: More External Core questions

Hi Aaron, So, yeah, perhaps External Core should be essentially a textual representation of a .hi file. Textual is something I doubt has much benefit. Yhc.Core has no textual syntax, and we've never wanted one. How about .hcr being just .hi but with complete bodies for all functions? If you d

Re: More External Core questions

Hi From my viewpoint as a current user of GHC Core: Things would actually be significantly easier if I dropped backward compatibility and essentially just did a Read/Show approach. Backward compatibility got broken a while ago, since GHC Core currently doesn't seen to work. Given that you h

GHC Core questions

Hi, Thanks to all the help I've now managed to get GHC Core converted to Yhc Core (the source is at the end of this mail, if anyone wants a look). I have three remaining issues: 1) Data types (i.e. data/newtype) are not represented in [CoreBind] at all, as far as I can tell. Is Core meant to kee

Re: External Core in binary format

Hi Tim (and all other GHC API gurus) I managed to get most of the way towards where I was aiming for. Ideally I want an interface such that loading a filename gives me the GHC Core out of it. Here is what I have so far (strongly stolen from Tim): import GHC import Outputable import CoreSyn ghc

Re: External Core in binary format

Hi Tim Mon Jun 25 15:06:08 PDT 2007 Tim Chevalier <[EMAIL PROTECTED]> * Add a compileToCore function to the GHC API Yay! Thanks very much. I've never used a nightly snapshot of GHC before, but if I grab one tomorrow will it have this ability in it? So it's not quite as simple as just call

Re: External Core in binary format

Hi Well, in GHC the Prelude ~= the base package, so you'll have to translate (a large chunk of) base into YHC.Core. It uses lots of primitives, so you'll need translations for many of those (exceptions? MVars? GMP operations?). Trivial :) Yhc.Core has the notion of primitives, which is som

Re: External Core in binary format

Hi So presumably you'd be happy if you could do something like this: import qualified GHC getYHCCore :: FilePath -> YHC.Core getYHCCore file = do s <- GHC.newSession ghc_core <- GHC.compileToCore s "Foo.hs" convertToYHCCore ghc_core ie. without any on-disk representation at all

Re: External Core in binary format

Hi I guess I started this discussion by asking for a concrete thing, rather than describing what I'm hoping to do. In reality, any solution that accomplishes my end goal suits me perfectly - so perhaps I should say what I'm hoping to do. Currently Yhc has an external core format, Yhc.Core. Howev

Re: External Core in binary format

Hi I'm not sure offhand why just doing Read/Show wouldn't work or didn't occur to us; is there a reason why that wouldn't be straightforward? Talking to Matt, the only thing is that currently Show is used for the pretty printed version. Adding a new Ppr class and using that shouldn't be that h

Re: External Core in binary format

Hi Tim Not if you want to parse Core emitted by the HEAD, since in the process of trying to get Core working, Aaron and I had to change the data types to reflect type system changes. We hope to have something checked in within a finite amount of time :-) I know time is a bit variable, but is t

Re: External Core in binary format

Hi > Matt has kindly volunteered to implement this, if you would be happy > to accept such a patch. In principle yes, but I see some practical problems. Which binary library? There's one in GHC already, but if you wanted your parser to be compatible, you'd have to use the same library (or car

External Core in binary format

Hi, I was wondering if you would be happy with the addition of a flag to generate Haskell Core (.hcr) files in a binary format, in addition to the text format currently generated? This would allow for easy parsing of the resultant files, something which is currently not possible. Matt has kindly

  1   2   >