Re: Re-entrant TcRnIf
There are quite a lot of dependencies between different parts of the AST. The renamer takes the whole parser output and then discovers its dependencies. After that you can split things into smaller units based on this dependency graph. The renamer and type checker do not necessarily need to be interleaved. Every Haskell file is de-facto split apart after each top-level TH splice. If I understand you correctly you want to build some IDE functionality that only recompiles the parts that changed. You can do that currently (crudely) by splitting the file into three parts based on the dependency graph that the renamer discovered: 1. Everything upstream of the focused definition, i.e., everything that does not depend on the focused definition. 2. The focused definition and everything that is in its recursive group. 3. Everything downstream of the focused, i.e., everything that directly or indirectly depends on the focused definition. You can put each part into a separate file and only recompile part 2. Of course you also need to detect when new (renamer) dependencies are formed as that will change the split between parts 1, 2, and 3. Let me know if you need more details on this approach. / Thomas On 11 June 2013 11:55, p.k.f.holzensp...@utwente.nl wrote: Dear GHC-ers, The current API *seems* to assume that all different stages of the compiler pipeline are always passed successively (with the exception of the interleaving of the renamer and the type checker for the sake of Template Haskell), in other words, it is assumed all parsing has been done once we start renaming and that when we desugar the AST, we can through out all type checker state. I'm working on an interactive environment (different in many ways from ghci), in which I would like to incrementally parse a statement, rename it and type check it, after which I may chose to wash, rinse and repeat. This is somewhat problematic in the renamer (at least; this is how far I have come), at the very least with regards to the unique source and the provenance of things. What I'm hoping to do is to generalize the monads in the GHC API to some class, along these lines: class Generalizes m n where glift :: n a - m a class (GhcMonad m, Generalizes m TcRnIf, Generalizes m CoreM, ...) = GHCAPI m What such a monad needs is to be able to evaluate some function in (for example) the renamer monad, extract the part of the renamer state that needs to persist and store that for whenever another renamer function is evaluated. One such thing would be the supply of unique names. I tried simply carrying over everything in the Env, except the env_top (HscEnv), but this broke things. Upon inspection of the TcGblEnv and TcLclEnv, this seems logical, considering they are dependent on the HscEnv (at least in terms of tcg_type_env_var, but there may be other dependencies I've not spotted). The thing that seems to bite me is the assumption that the top-level environment is assumed to be fixed [1]. In my scenario, this assumption does not hold. Concretely: 1) Do ways exist to carry over the part of the TcRnMonad state that is required to restart the renamer / type checker / etc later on? 2) If not, what parts of the Env, TcGblEnv and TcLclEnv should I copy over to the new state, assuming the HscEnv changed between consecutive runs? 3) Is there a particular reason why the front-end (of the front-end) is defined in an overloaded monad (GhcMonad) and the later bits all take concrete monads (TcRnIf etc.)? Regards, Philip [1] http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/TcRnMonad ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why is GHC so much worse than JHC when computing the Ackermann function?
Sounds similar to the bug we had in 6.12.1. It was a simple accounting bug, i.e., the GC was not invoked, because it didn't know that the memory was allocated. On 20 April 2013 22:03, Edward Z. Yang ezy...@mit.edu wrote: I don't seem to get the leak on latest GHC head. Running the program in GC debug mode in 7.6.2 is quite telling; the program is allocating *a lot* of megablocks. We probably fixed it though? Edward Excerpts from Mikhail Glushenkov's message of Sat Apr 20 01:55:10 -0700 2013: Hi all, This came up on StackOverflow [1]. When compiled with GHC (7.4.2 7.6.2), this simple program: main = print $ ack 4 1 where ack :: Int - Int - Int ack 0 n = n+1 ack m 0 = ack (m-1) 1 ack m n = ack (m-1) (ack m (n-1)) consumes all available memory on my machine and slows down to a crawl. However, when compiled with JHC it runs in constant space and is about as fast as the straightforward Ocaml version (see the SO question for benchmark numbers). I was able to fix the space leak by using CPS-conversion, but the CPS-converted version is still about 10 times slower than the naive version compiled with JHC. I looked both at the Core and Cmm, but couldn't find anything obviously wrong with the generated code - 'ack' is compiled to a simple loop of type 'Int# - Int# - Int#'. What's more frustrating is that running the program with +RTS -hc makes the space leak mysteriously vanish. Can someone please explain where the space leak comes from and if it's possible to further improve the runtime of this program with GHC? Apparently it's somehow connected to the stack management strategy, since running the program with a larger stack chunk size (+RTS -kc1M) makes the space leak go away. Interestingly, choosing smaller stack chunk sizes (256K, 512K) causes it to die with an OOM exception: $ time ./Test +RTS -kc256K Test: out of memory (requested 2097152 bytes) [1] http://stackoverflow.com/questions/16115815/ackermann-very-inefficient-with-haskell-ghc/16116074#16116074 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
On 16 September 2011 16:31, Ryan Newton rrnew...@gmail.com wrote: I started playing around with Leksah and scion/emacs (searching for what's the type of this expr support) and was a little disappointed that this functionality doesn't seem to exist yet. Or am I wrong and it exists somewhere? The problem is when you have incomplete programs. Scion does allow you to ask for the type of a subexpression(1), but it can only do so if the program type checks. In many cases you can get an incomplete program to type check by adding undefines, but that doesn't work in the general case. You may get issues with ambiguous types with no defaulting rules. Ambiguity checking is a separate stage in the type checker (at least it was before 7.0.*) so it's possible in principle to add an option to the GHC API to allow such programs to pass the type checker. I'm not a fan of TDNR because it would make programs even more sensitive to imports than they are now (the current issue is due to type classes and the lack of control about importing them). I also fear that it would interact badly with things an IDE has to do. I may be wrong, though, as some people seem to claim the opposite. I haven't had the chance to think about that fully. Personally, I like the type class + special label type solution best, so far. (1) It's disabled in the current master branch, but it's available in the fork used by EclipseFP and it does indeed work there. -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Parallel --make (GHC build times on newer MacBook Pros?)
On 1 September 2011 08:44, Evan Laforge qdun...@gmail.com wrote: Yes, the plan was to eventually have a parallel --make mode. If that's the goal, wouldn't it be easier to start many ghcs? Yes. With Scion I'm in the process of moving away from using GHC's compilation manager (i.e., --make) towards a multi-process setup. This has a number of advantages: - Less memory usage. Loading lots of modules (e.g., GHC itself) can take up to 1G of memory. There are also a number of caches that can only be flushed by restarting the session. - Sidestep a few bugs in the compilation manager, such as non-flushable instance caches which lead to spurious instance overlaps. (Sorry, can't find the corresponding ticket, right now.) - An external compilation manager (e.g., Shake) can also handle preprocessing of other extensions, such as .y, .chs, etc. - Support for different static flags (e.g., -prof). Static flags should eventually be removed from GHC, but it's low-priority and difficult to do. - Uniform handling of compilation with multiple versions of GHC. - Parallel building, as you mentioned. There may be more. It also comes with disadvantages, such as the need to serialise more data, but I think it's worth it. This is the main reason why I stopped working on a thread-safe GHC. Personally, I believe the GHC API should just include a simple API for compiling a single module and return some binary value (i.e., don't automatically write things to a file). Everything else, including GHCi, should be separate. But that's a different matter... -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Parallel --make (GHC build times on newer MacBook Pros?)
The performance problem was due to the use of unsafePerformIO or other thunk-locking functions. The problem was that such functions can cause severe performance problems when using a deep stack. The problem is that these functions need to traverse the stack to atomically claim thunks that might be under evaluation by multiple threads. The latest version of GHC should no longer have this problem (or not as severely) because the stack is now split into chunks (see [1] for performance tuning options) only one of which needs to be scanned. So, it might be worth a try to re-apply that thread-safety patch. [1]: https://plus.google.com/107890464054636586545/posts/LqgXK77FgfV On 29 August 2011 21:50, Max Bolingbroke batterseapo...@hotmail.com wrote: On 27 August 2011 09:00, Evan Laforge qdun...@gmail.com wrote: Right, that's probably the one I mentioned. And I think he was trying to parallelize ghc internally, so even compiling one file could parallelize. That would be cool and all, but seems like a lot of work compared to just parallelizing at the file level, as make would do. It was Thomas Schilling, and he wasn't trying to parallelise the compilation of a single file. He was just trying to make access to the various bits of shared state GHC uses thread safe. This mostly worked but caused an unacceptable performance penalty to single-threaded compilation. Max ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Parallel --make (GHC build times on newer MacBook Pros?)
On 30 August 2011 01:16, Evan Laforge qdun...@gmail.com wrote: Interesting, maybe I misremembered? Or maybe there was some other guy who was trying to parallelize? Just out of curiosity, what benefit does a thread-safe ghc provide? I know ghc api users have go to some bother to not call re-entrantly... what neat stuff could we do with a re-entrant ghc? Could it eventually lead to an internally parallel ghc or are there deeper reasons it's hard to parallelize compilation? That would be really cool, if possible. In fact, I don't know of any parallel compilers. Yes, the plan was to eventually have a parallel --make mode. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Panic when using syb with GHC API
Yep, I've been thinking about that. It could work, but I don't know how type functions interact with SYB. It doesn't solve the issue of having traversals with different semantics, though. I.e., sometimes you want to look inside SyntaxExpr, sometimes you don't. ATM, you have to customise the traversal for each data type that has a constructor which may contain a SyntaxExpr. It would be simpler to have a newtype for these, so that you only have to change the behaviour for that single type. On 26 August 2011 17:53, Max Bolingbroke batterseapo...@hotmail.com wrote: On 26 August 2011 09:22, Simon Peyton-Jones simo...@microsoft.com wrote: The underlying issue is that before type checking GHC (obviously) doesn't know the types of things, while afterwards it does. The whole HsSyn tree is parameterised over the types of identifiers: Parsed: HsExpr RdrNames Renamed: HsExpr Name Typechecked: HsExpr Id One alternative would be to parameterise the tree over the type of type-decorations, so instead of 'PostTcType' you'd have 'ty' (a variable) instead. So we'd have Renamed: HsExpr Name () Typechecked: HsExpr Id Type To me this seems like a bit of a sledgehammer to crack a nut; and I think there are a couple of other similar things (like SyntaxExpr). But it might be possible. Type functions? data HsExpr name = ... | HasTypeArgument (TypeInfo name) type family TypeInfo name :: * type instance TypeInfo RdrName = () type instance TypeInfo Name = Type This basically lets you get away with just a single type index to HsExpr and friends. Max -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Panic when using syb with GHC API
GHC's parse tree contains lots of placeholders. You are not supposed to look at them until a specific phase has been run. For example, anything of type SyntaxExpr is an error thunk until the renamer has been run. Unfortunately, SyntaxExpr is just a type synonym, so there's no way to distinguish them via SYB. The simplest workaround is to adapt the default traversal code for the nodes which may contain such error thunks. A better solution would be to change the GHC AST to wrap such possibly undefined nodes with newtypes, but that would only take effect once the next version of GHC is released. On 24 August 2011 23:11, Simon Hengel simon.hen...@wiktory.org wrote: Hello, I'm trying to query a type-checked module with syb, this works for a plain binding. But as soon as I add a type signature for that binding, I get an panic! I experienced similar problems with a renamed module. Are those data structures meant to be used with syb? And if yes, what did I miss? Bellow is some code to reproduce my issue. Any help is very much appreciated. -- A.hs module Main where import GHC import Outputable import Data.Generics import GHC.Paths (libdir) import Bag main :: IO () main = do m - parse putStrLn $ showSDoc $ ppr $ m putStrLn \n---\n putStrLn $ showSDoc $ ppr $ selectAbsBinds m parse = runGhc (Just libdir) $ do _ - getSessionDynFlags = setSessionDynFlags target - guessTarget B.hs Nothing setTargets [target] Succeeded - load LoadAllTargets modSum - getModSummary $ mkModuleName B m - parseModule modSum = typecheckModule return $ typecheckedSource m selectAbsBinds :: GenericQ [HsBindLR Id Id] selectAbsBinds = everything (++) ([] `mkQ` f) where f x@(AbsBinds _ _ _ _ _) = [x] f _ = [] -- B.hs module B where foo :: Char foo = 'f' Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: parsing types
On 24 April 2011 03:26, Ranjit Jhala jh...@cs.ucsd.edu wrote: Does anyone have a clue as to how to get a hold on an appropriate environment? (I would have thought that the HscEnv obtained _after_ compiling some file f would populated with at least the names needed to compile f) that is, if I do: cm0 - compileToCoreSimplified f env - getSession then the resulting env would suffice, but unfortunately thats not the case... It should work if you go the setTarget ...; load ... path. The 'compileToCoreSimplified' function is intended for rather narrow use cases. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Strange performance effects with unsafePerformIO
unsafePerformIO traverses the stack to perform blackholing. It could be that your code uses a deep stack and unsafePerformIO is repeatedly traversing it. Just a guess, though. 2011/3/24 Björn Peemöller b...@informatik.uni-kiel.de: Hello, we have a strange performance behaviour when we use unsafePerformIO, at least with GHC 6.12.3 and 7.0.1. Please consider the example program following at the end of this post. Running the original code the execution time is about 26 seconds, while uncommenting one (or both) of the comments shrinks it to about 0.01 seconds on our machine. Is there an explanation for this effect? Regards, Bjoern -- --- module Main where import System.IO.Unsafe traverse [] = return () -- traverse (_:xs) = traverse xs traverse (_:xs) = traverse xs return () makeList 0 = [] -- makeList n = () : (makeList (n - 1)) makeList n = () : (unsafePerformIO . return) (makeList (n - 1)) main = traverse $ makeList (10^5) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Weird failure of ghc-7.0.2 on OS X 10.5 using the bindist tarball
OK, thanks. On 12 March 2011 14:25, Ian Lynagh ig...@earth.li wrote: It turns out that even an i386 build made on 10.6 won't work on 10.5: http://hackage.haskell.org/trac/ghc/ticket/4996 And even if this is fixable, it won't help, as we'll have to drop 10.5 support in order to support XCode 4: http://hackage.haskell.org/trac/ghc/ticket/5011 If you build GHC yourself then it should work, though. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Weird failure of ghc-7.0.2 on OS X 10.5 using the bindist tarball
I installed ghc (x86) from the bindist tarball like so:
$ wget http://www.haskell.org/ghc/dist/7.0.2/ghc-7.0.2-i386-apple-darwin.tar.bz2
$ tar -xjf ghc-7.0.2-i386-apple-darwin.tar.bz2
$ cd ghc-7.0.2-i386-apple-darwin
$ ./configure --prefix=$HOME/local
$ make install
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.2
GHCi works fine:
$ ghc -e 3+4
7
However, if I want to compile a test file I get a weird dtrace error.
$ cat test.hs
main = print 42
$ ghc --make test.hs
[1 of 1] Compiling Main ( test.hs, test.o )
Linking test ...
error: Could not compile reconstructed dtrace script:
Unhandled typedefs encoding version v2
provider HaskellEvent {
probe thread_wakeup(EventCapNo,EventThreadID,EventCapNo);
probe thread__runnable(EventCapNo,EventThreadID);
probe migrate__thread(EventCapNo,EventThreadID,EventCapNo);
probe create__thread(EventCapNo,EventThreadID);
probe gc__work(EventCapNo);
probe gc(int, double, long,...)(EventCapNo);
probe gc__done(EventCapNo);
probe gc__start(EventCapNo);
probe gc__end(EventCapNo);
probe stop__thread(EventCapNo,EventThreadID,EventThreadStatus);
probe run__thread(EventCapNo,EventThreadID);
probe startup(EventCapNo);
probe user__msg(EventCapNo,char *);
};
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent provider
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent module
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent function
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent name
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent args
ld: error creating dtrace DOF section
collect2: ld returned 1 exit status
$ uname -mrsv
Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT
2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
Any idea what's going on there?
/ Thomas
--
Push the envelope. Watch it bend.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Weird failure of ghc-7.0.2 on OS X 10.5 using the bindist tarball
No, I have xcode installed (which is mainly needed for gcc, ar, ld,
etc.). I have lots of other GHC versions installed as well, so I
don't think that's the issue.
I think Duncan has been working on dtrace support, so maybe he has an
idea. (CC'd).
On 11 March 2011 18:51, Don Stewart don...@gmail.com wrote:
Missing XCode? Or is that not relevant?
On Fri, Mar 11, 2011 at 10:39 AM, Thomas Schilling
nomin...@googlemail.com wrote:
I installed ghc (x86) from the bindist tarball like so:
$ wget
http://www.haskell.org/ghc/dist/7.0.2/ghc-7.0.2-i386-apple-darwin.tar.bz2
$ tar -xjf ghc-7.0.2-i386-apple-darwin.tar.bz2
$ cd ghc-7.0.2-i386-apple-darwin
$ ./configure --prefix=$HOME/local
$ make install
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.2
GHCi works fine:
$ ghc -e 3+4
7
However, if I want to compile a test file I get a weird dtrace error.
$ cat test.hs
main = print 42
$ ghc --make test.hs
[1 of 1] Compiling Main ( test.hs, test.o )
Linking test ...
error: Could not compile reconstructed dtrace script:
Unhandled typedefs encoding version v2
provider HaskellEvent {
probe thread_wakeup(EventCapNo,EventThreadID,EventCapNo);
probe thread__runnable(EventCapNo,EventThreadID);
probe migrate__thread(EventCapNo,EventThreadID,EventCapNo);
probe create__thread(EventCapNo,EventThreadID);
probe gc__work(EventCapNo);
probe gc(int, double, long,...)(EventCapNo);
probe gc__done(EventCapNo);
probe gc__start(EventCapNo);
probe gc__end(EventCapNo);
probe stop__thread(EventCapNo,EventThreadID,EventThreadStatus);
probe run__thread(EventCapNo,EventThreadID);
probe startup(EventCapNo);
probe user__msg(EventCapNo,char *);
};
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent provider
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent module
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent function
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent name
#pragma D attributes PRIVATE/PRIVATE/UNKNOWN provider HaskellEvent args
ld: error creating dtrace DOF section
collect2: ld returned 1 exit status
$ uname -mrsv
Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT
2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
Any idea what's going on there?
/ Thomas
--
Push the envelope. Watch it bend.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--
Push the envelope. Watch it bend.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release/git plans
On 21 January 2011 09:13, Simon Peyton-Jones simo...@microsoft.com wrote: I'm pretty keen on the whole plugin idea, because it makes the compiler more extensible and lowers the barrier to entry. My only reason for delay is that I wanted to review the design (as seen by a plug-in author). Once we provide it, we have to support it, and it's harder to change. The Scala compiler has a plugin system. Here's a document that describes their approach to dealing with phase ordering of plugins: http://www.scala-lang.org/sid/2. It seems rather complex, but seems necessary (or the document is just very long). There's also a tutorial on writing Scala plugins, which may help to get a feel for how their API works. http://www.scala-lang.org/node/140 / Thomas ___ 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 13 January 2011 08:54, Roman Leshchinskiy r...@cse.unsw.edu.au wrote: On 12 Jan 2011, at 23:31, Edward Z. Yang ezy...@mit.edu wrote: Excerpts from Roman Leshchinskiy's message of Wed Jan 12 18:20:25 -0500 2011: How would we get the current functionality of darcs-all pull? Is it even possible? Here is the rebase-y workflow. Thank you making things clearer! # pull the latest patches for GHC, and sticks your patchset on top git pull --rebase # resolve any conflicts that occured during rebase # register any new submodules (if any) git submodule init # make your submodules reflect the latest version GHC has git submodule update --rebase This doesn't pull in all base patches, though, just the ones that GHC depends on, right? How would I get all base patches? cd libraries/base git pull [--rebase] ___ 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 11 January 2011 19:07, Roman Leshchinskiy r...@cse.unsw.edu.au wrote: On 11/01/2011, at 16:14, Tony Finch wrote: On Mon, 10 Jan 2011, Roman Leshchinskiy wrote: It also seems to make finding buggy patches rather hard. Have a look at `git bisect`. I'm aware of git bisect. It doesn't do what I want. I usually have a pretty good idea of which patch(es) might have caused a problem and I want to unpull it and its dependencies. This is easy in darcs; I have no idea how to do that in git. This form of dependency tracking is done manually in Git via topic/feature branches. Undoing the patch would the mean undoing the merge, which can be done via git rebase -i. (The -i part is just for a nicer user interface). Now whether manual dependency tracking is better than darcs' automatic tracking is another question. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
I'd be for a move, but haven't contributed much lately. I use Git for all my personal projects, so I consider Git to be useful. I personally find sending patches via Git to be harder than with Darcs, but if we use Github the pull-request-based model should work well. I used Git on Windows two years ago and didn't have any problems (the case sensitive file name issue has a well-documented setting to avoid issues). I think I used msysGit and used msys to build GHC, so those should work well together. (Granted, though, I used Git only for a small code base at the time.) We'd probably have to adopt the workflow that Johan linked to (separate branch for every larger change, merge with --no-ff) but that might actually improve things (e.g., unmerging a branch if necessary). The important issues, mentioned by Max, remain and I agree that GHC HQ should have the last decision on these. On 10 January 2011 11:19, Simon Marlow marlo...@gmail.com wrote: It's time to consider again whether we should migrate GHC development from darcs to (probably) git. From our perspective at GHC HQ, the biggest problem that we would hope to solve by switching is that darcs makes branching and merging very difficult for us. We have a few branches of HEAD that are very painful to keep merged with HEAD, and we would almost certainly have more branches if the overhead were lower. In some sense the overhead is self-inflicted because we have the no-conflict policy in the mainline repository, but that is to avoid problems with darcs' merging algorithms (both performance and correctness). We are still using darcs v1 patches rather than v2, but there are known problems with v2 which are preventing us from upgrading. The darcs team have been making great strides with performance, but conflict handling remains a serious problem. The darcs roadmap doesn't show this being fixed in the near future http://wiki.darcs.net/Roadmap Rebase support is coming, and it does work, though the workflow is a bit laborious. Besides the branching/merging/conflict issue, switching to git would give us plenty of side benefits, notably via access to a wealth of tool support. Making contribution easy is important to us too, and there are a lot of people using git. The cost of switching is quite high, which is one reason we decided to stay with darcs last time. We have multiple repos that need to be converted, and for some of them, where the repo is being shared with other projects, we may have to mirror rather than convert in place. We're prepared to put in the effort if the gains would be worthwhile though (offers of help are more than welcome!). We're intrested in opinions from both active and potential GHC developers/contributors. Let us know what you think - would this make life harder or easier for you? Would it make you less likely or more likely to contribute? Cheers, Simon ___ Cvs-ghc mailing list cvs-...@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
I just want to point out that since the last discussion we collected some migration advice at http://hackage.haskell.org/trac/ghc/wiki/GitForDarcsUsers Some of it may be untested (or wrong), but it should be a good starting point. On 10 January 2011 22:15, Neil Mitchell ndmitch...@gmail.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. I'm in exactly the same camp as Malcolm. I don't understand git, and I end up deleting the entire repo and starting again every time I try and do anything clever - something I've never needed to do with darcs. I consider the git equivalent of darcs unrecord to be rm -rf, but I'm sure that's a lack of knowledge/intuition on my part. All my git dislike aside, I wouldn't worry about git and Windows. GHC on Windows already drags in plenty of dependencies from Cygwin or Mingw, both of which provide workable git binaries, and none of which ever seem to have caused a problem. The standard gui's (gitk and git gui) both work on Windows, and I certainly miss them when using darcs. Thanks, Neil ___ Cvs-ghc mailing list cvs-...@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using the GHC API: pretty printing with qualified names
On 17 November 2010 19:21, JP Moresmau jpmores...@gmail.com wrote: Hello, I'm the maintainer for EclipseFP, which involves using the scion library and the GHC API to provide IDE functionality. I have a little issue that no doubt stems from me not understanding the GHC API well, and I would be grateful for any light on the matter. I'm trying to give the user the possibility to jump to the definition of a symbol in the source file. You click on the name of a function and you're send to the module where it's defined. So I have an AST, and somewhere down the line I have an Id object representing that function call. Then I just use ppr alwaysQualify id to get the fully qualified name of the function, and I can then use the module name to retrieve the source file etc. This works well in cases, but not in others. It will sound silly to the gurus on the list, but it's when the function has generics that it doesn't work. So a function with a type class in its type signature will never be printed qualified. It kinda like makes sense because I suppose some work has been done so that it represents the function with proper types, etc., but how can I get back to the original Id? How can I get back from that unqualified Id to the qualified Id representing the function in the original module? I've been looking round Name and OccName and all that but I'm not sure really what I'm looking for. Hope I'm making sense!! Thanks! Note that typeclass methods all live in a top-level namespace. Qualified names are used to disambiguate between multiple names which this is not necessary for method names. I presume when you want to jump to the definition of a method, you want to do something special anyway. You probably want to jump to the implementation of the method for the type at which it is used. If it is used polymorphically you cannot do this (there is no statically known definition), so you could just display its type or a list of all known implementations. To find out the type at which a polymorphic or overloaded identifier is used, you have to interpret type applications (HsWrap) and abstractions (AbsBind). The GHC API provides access to all imported instances, but they probably won't have source code annotations. Such a database must be created separately. HTH / Thomas -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Collecting all external names in a module
On 18 September 2010 12:25, Johan Tibell johan.tib...@gmail.com wrote:
Hi Simon,
Thanks for the pointers!
On Fri, Sep 17, 2010 at 6:29 PM, Simon Peyton-Jones simo...@microsoft.com
wrote:
GHC already collects all RdrNames for imported things, for use when
reporting unused imports. But it doesn’t collect the SrcSpan of the
occurrences, nor does it collect occurrences of locally-bound things.
I found the spot where the collected RdrNames are used to generate the
unused import warnings, but I don't quite understand where they are
gathered. Is there an AST traversal function somewhere that gathers these
RdrNames? If so, I could use it as a blue print to write my own traversal.
I suggest you write a general traversal looking like
data Gather var res
= Gather { g_empty :: res
, g_union :: res - res - res
, g_occ :: Located var - res
, g_del :: Located var - res - res }
getExpr :: Gather v res - HsExpr v - res
.. and similarly for each other data type...
Could you expand a little bit on this design? Is the idea that the Gather
data type carries functions to apply in different parts of the AST? What's
occ short for, OccName? What about del?
There are different kind of ASTs (e.g. after renaming, after type checking,
etc), which one should I use if I want to gather all qualified names?
You probably want the renamed AST. The typechecked AST is essentially
only a list of top-level bindings.
The utility functions Simon suggest look to me like a special sort of
fold. g_empty and g_union are clear. g_occ records the occurrence
(hence occ) of a variable and adjusts the fold state accordingly.
g_del is most likely to be intended for binders, i.e., a place where a
variable goes out of scope when going up. A particular Gather
operation is of course not obliged to actually delete anything. So,
maybe the g_del better be called g_bind.
While Gather on the surface may look polymorphic in the v argument,
in practise it isn't really. Some parts of the AST will be bound to
error thunks depending on whether you have a parse AST, a renamed
AST or typechecked AST. You also may want different traversal modes.
E.g., the renamed AST explicitly fills in which , =, return,
etc. are used by a do statement, and it depends on the kind of
analysis your doing whether these desugarer-introduced nodes should be
included or not.
You could also use http://hackage.haskell.org/package/ghc-syb.
Here's an example that customises the traversal depending on the
stage: http://github.com/nominolo/ghc-syb/blob/master/utils/GHC/SYB/Utils.hs
/ Thomas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Allowing Instances to Unify Types
You might want to wait a bit until the new type checker has made it
into mainline. The ideas behind the new type checker are explained in
the paper linked from here:
http://www.haskell.org/haskellwiki/Simonpj/Talk:OutsideIn
Here's an earlier thread about the new type checker:
http://comments.gmane.org/gmane.comp.lang.haskell.cafe/77413
On 23 July 2010 21:47, Matt Brown m...@softmechanics.net wrote:
Hi all,
I've been hacking on GHC for a couple months now, experimenting with
some different ideas I find interesting. One thing I'm trying to do
is allow instance unifs (when there's an unambiguous choice, a
question which is simplified in this case by there being only one),
and force the required unification. Here's a simple example:
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies,
FlexibleInstances, UndecidableInstances #-}
class Apply a b c | a b - c where
applyInst :: a - b - c
instance (Monad m) = Apply (a - m b) (m a) (m b) where
applyInst = (=)
apply :: (Monad m) = (a - m b) - (m a) - (m b)
apply = (=)
ioStr :: IO String
ioStr = return foo
printStr :: String - IO ()
printStr = print
main = do print `apply` (return foo)
printStr `applyInst` ioStr
print `applyInst` (return bar) -- this fails
With my code to use the unif instance enabled, I get Ambiguous type
variable errors for Show a (from print) and Monad m (from return).
My question is: in the case of apply (which isn't implemented by a
class), how does the typechecker propagate a ~ String and m ~ IO
to the predicates for print and return? If someone (such as myself)
had sufficient time and energy to spend trying to achieve similar
behavior for applyInst, where might he/I start?
Thanks and Regards,
-matt
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--
If it looks like a duck, and quacks like a duck, we have at least to
consider the possibility that we have a small aquatic bird of the
family Anatidae on our hands.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal: priority queues in containers
On 18 March 2010 22:02, Louis Wasserman wasserman.lo...@gmail.com wrote: I'm still pretty strongly in favor of putting priority queues into containers: other programming languages consider it necessary for inclusion into standardized libraries, people will be more likely to use appropriate data structures for their needs when reliable, friendly implementations are already at their fingertips, and other reasons already discussed. The Haskell Platform is really is intended to be available at your fingertips. Unfortunately, the following does not work (although I thought it's supposed to) $ cabal install haskell-platform Nevertheless, the libraries bundled with GHC are those libraries that GHC itself needs and which therefore cannot be upgraded independently. The real standard libraries are the Haskell Platform and if your package is part of the platform, then your package *is* in status equivalent to things like java.util.*. This weekend's Hackathon in Zürich will partly be dedicated to getting the next release of the Platform release ready. If you can get your package into the following platform release (due 6 months after the current release), then this would surely make it the default package for anyone in need of a PQ. / Thomas -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: undocumented cost centres with -hd and -hy
PAP stands for partial application, i.e., a function with one or more missing arguments. MUT_ARR_PTRS_FROZEN are mutable objects which are not moved by the garbage collector. They are an implementation detail of IORefs and mutable arrays (ST(U)Array, IO(U)Array, ...). Before entering a suspended computation (a THUNK), GHC overwrites it with a BLACKHOLE, to avoid space leaks and to detect cyclic dependencies. HTH On 10 March 2010 13:30, Soenke Hahn sh...@cs.tu-berlin.de wrote: When using the heap profiling options -hd (profiling by closure description) and -hy (profiling by type) there are some compiler-generated cost centres, for example PAP, MUT_ARR_PTRS_FROZEN and BLACKHOLE. I wasn't able to find documentation on them. Is there any? Thanks, Sönke ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg-ap-1-upd-info
I think it means you're created lots of thunks of the form (f x). Perhaps some foldl vs foldl' issue? If you're not using foldl anywhere, look at tail recursive functions and try and make their accumulators strict. HTH On 3 March 2010 16:11, Herk, Robert van robert.van.h...@philips.com wrote: Hi All, I am optimizing a program to consume less memory. If I profile it with +RTS -hd, it reports to fill 50% of my memory with stg-ap-1-upd-info. Does this mean anything? Regards, Robert The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc API in platforms with no GHCi
The byte code interpreter (which hlint uses) has its own dynamic linker to load binaries. I suppose the platforms that you listed this is not supported and GHCi (or more precisely the part of GHCi that requires the byte code interpreter) is not built. Specifically, the following modules are not built: DsMeta TcSplice Convert ByteCodeAsm ByteCodeFFI ByteCodeGen ByteCodeInstr ByteCodeItbls ByteCodeLink Debugger LibFFI Linker ObjLink RtClosureInspect I wonder whether TemplateHaskell is supported on those platforms, since that uses the interpreter, AFAIK. 2010/1/17 Marco Túlio Gontijo e Silva mar...@riseup.net: Hi. I noticed that in Debian/KFreeBSD the module ByteCodeLink is not available, which cause the build error of haskell-hint in Debian's buildds. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564136 This is also the case of alpha, armel, hppa, mips, powerpc and s390. I haven't checked if these are the architectures without GHCi but I suspect they are. Is the full ghc API available only in arches in which GHCi is available? Greetings. -- marcot http://marcot.iaaeee.org/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Poll: Error message spans
Additionally, tools based on the GHC API already have this information available and wouldn't be affected either way. -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Fwd: Generating valid Haskell code using the GHC API pretty printer
Forgot to include the list.
-- Forwarded message --
From: Thomas Schilling nomin...@googlemail.com
Date: 2009/7/22
Subject: Re: Generating valid Haskell code using the GHC API pretty printer
To: Jan Schaumlöffel j...@informatik.uni-kiel.de
The pretty printer never prints { .. } for a do expression. You can
control which things are printed unqualified by setting the
PrintUnqualified part properly. The most straightforward way is to
use GHC.mkPrintUnqualifiedForModule which only prints things qualified
that are not imported in the given module. See 'withPprStyle' and
'mkUserStyle' in Outputable.
That said, if you're trying to do source-to-source transformations you
probably want to keep the original layout as much as possible. GHC's
pretty-printer isn't designed for that. GHC's syntax tree has very
accurate source locations, so you could start from there and build
your own pretty printer.
2009/7/22 Jan Schaumlöffel j...@informatik.uni-kiel.de:
Hello everyone,
we are trying to use the GHC API for a source-to-source transformation
on Haskell programs. The result of parsing and typechecking a module
enables us to apply the transformation, but writing the transformed
module back using the pretty printer (Outputable) generates invalid
Haskell code.
For one thing, since even the names defined in the current module are
fully qualified, the resulting code is not valid anymore.
This can be worked around, but there is another issue: Simply reading
the following program and then writing it out using the pretty printer
renders the resulting code invalid.
module Main where
main = do
if True then putStrLn longlonglonglonglonglongline
else return ()
longlonglonglonglonglonglonglonglonglonglonglongname $ test
longlonglonglonglonglonglonglonglonglonglonglongname = putStrLn
The result looks like this:
Main.main = do if GHC.Bool.True then
System.IO.putStrLn longlonglonglonglonglongline
else
GHC.Base.return ()
Main.longlonglonglonglonglonglonglonglonglonglonglongname
GHC.Base.$
test
Main.longlonglonglonglonglonglonglonglonglonglonglongname =
System.IO.putStrLn
There are two different problems in this output:
1) the indentation of if ... then ... else violates the do-block
layout rule
2) the indentation of the long function call is invalid
It looks like those problems could be avoided if the pretty printer
could be configured to consistently use do { ... ; ... } notation,
but we have been unable to figure out how. Is there a canonical way
to use the GHC API to pretty print to valid Haskell code?
Kind regards,
Jan
Appended is our current code to execute the transformation above (the
module to be read is expected in a file dummy.hs for simplicity).
Please excuse if this might not be a minimal example.
module Main where
import GHC
import GHC.Paths
import Outputable
main = do
x - runGhc (Just libdir) $ do
dflags - getSessionDynFlags
setSessionDynFlags (dflags { hscTarget = HscNothing,
ghcLink = NoLink })
target - guessTarget dummy.hs Nothing
setTargets [target]
load LoadAllTargets
graph - getModuleGraph
let unparsedmod = head graph
parsedmod - parseModule unparsedmod
typecheckedmod - typecheckModule parsedmod
let Just renamedsource = renamedSource typecheckedmod
(group,_,_,_,_) = renamedsource
moduledings = (ms_mod unparsedmod)
return (showSDoc (ppr group))
putStr $ x ++ \n
--
If you're happy and you know it, syntax error!
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--
Push the envelope. Watch it bend.
--
Push the envelope. Watch it bend.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1
There should be a file called testlog somewhere, either at the toplevel or within the tests directory. Could you search for apirecomp001 and send me the test output from running that test. I can't reproduce this failure when running it manually even though I'm on OS X, too. On 18 Mar 2009, at 10:51, Gregory Wright wrote: I built ghc-6.10.1.20090314 on OS X 10.5.6 (Intel) using ghc 6.8.2 as a bootstrap compiler. The build was done using the MacPorts infrastructure. Summary test results: OVERALL SUMMARY for test run started at Tue Mar 17 15:31:38 EDT 2009 2334 total tests, which gave rise to 12487 test cases, of which 0 caused framework failures 2460 were skipped 9709 expected passes 258 expected failures 0 unexpected passes 60 unexpected failures Unexpected failures: 2469(ghci) apirecomp001(normal) bits (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) conc049(hpc) conc068(normal) derefnull(profc,profthreaded) divbyzero(profc,profthreaded) genUpTo (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) length001(optc,hpc,optasm,profc,profasm,threaded2,profthreaded) num009 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) num012 (normal ,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded) signals002(ghci) signals004(ghci,threaded1,threaded2,profthreaded) I haven't looked at the errors in detail, but generally the release candidate seems OK. BTW, a test target will be added to MacPorts's portfile for the 6.10.2 release, which will let you run the test suite by typing sudo port test ghc and if you then install the tested build, a record of the test will be saved in $PREFIX/share/ghc-version/. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users / Thomas -- Push the envelope. Watch it bend. PGP.sig Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type signature inside an instance declaration
{-# LANGUAGE ScopedTypeVariables #-}
2008/12/16 Neil Mitchell ndmitch...@gmail.com:
Hi
You want to use `asTypeOf`, with a lazy pattern to name a value of type 'a'.
pr xs = [ ++ pr (undefined `asTypeOf` x) ++ ]
where (x:_) = xs
I prefer:
pr xs = [ ++ pr (undefined `asTypeOf` head x) ++ ]
Or even more simply:
pr xs = [ ++ pr (head x) ++ ]
I do believe there is some GHC extension that can be turned on to
refer to variables like you did, but its not standard Haskell.
Thanks
Neil
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--
Push the envelope. Watch it bend.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mmap() returned memory outside 2Gb - GHC on ubuntu hardy amd64
HEAD 2008/11/18 Rahul Kapoor [EMAIL PROTECTED]: I've made a speculative fix. If you're able to test it, that would be very helpful: I imagine, I need to download the nightly snapshot and build it. HEAD or STABLE? Rahul ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Push the envelope. Watch it bend. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Control.Exception
I think the best way to get backwards compatibility is to flesh out and use the extensible-exceptions package that Ian started, which models extensible exceptions on top of the old exception mechanism. Alternatively, you can decide not to use extensible exceptions and have your package depend on base-3 instead of base-4. For a library, however, I don't think there's a good solution, since most of the time changing the exception mechanism for the library will make the library incompatible with existing clients. I guess the best way to deal with this is to properly use the package versioning policy and hope that clients specify their dependencies precisely. 2008/11/2 Sigbjorn Finne [EMAIL PROTECTED]: (+1) to that request - what is the best practices for portable exception handling code that straddles version 6.10, i.e. that compiles with compilers at either side with minimal fuss? I can imagine a couple of alternatives, but would like to hear what others are doing here. thanks --sigbjorn likes backward code compatibility On 11/1/2008 18:15, Jason Dagit wrote: On Wed, Oct 8, 2008 at 1:19 AM, Simon Marlow [EMAIL PROTECTED] wrote: Johannes Waldmann wrote: with 6.10, the following does not typecheck: foo `Control.Exception.catch` \ _ - return bar Ambiguous type variable `e' in the constraint: `Control.Exception.Exception e' It is probably bad programming style anyway but what is the workaround? As long as you're aware that it is bad programming style. We deliberately didn't include an easy way to do this, because we want people to think about why they need to catch *all* exceptions (most of the time it's a bug). Since the above is bad form, what should I be doing? Could someone please provide some examples or point me at the list of exceptions that I can catch? What about catching multiple types of exceptions? Thanks, Jason ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type classes in GADTs
2008/10/30 C Rodrigues [EMAIL PROTECTED]: evidenceOfEq :: CAOp a - (Eq a = b) - b isn't that the same as: evidenceOfEq :: Eq a = CAOp a - b - b Neither does it accept data EqConstraint a b = EqConstraint (Eq a = b). Foiled again. same here: data Eq a = EqConstraint a b = EqConstraint b. although this must be a typo, since it doesn't make any sense to me. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: [Haskell-cafe] I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.
2008/10/14 Bulat Ziganshin [EMAIL PROTECTED]: Hello Thomas, Tuesday, October 14, 2008, 2:46:45 PM, you wrote: The issue is binary compatibility. At the moment, GHC cannot make sure that a library compiled with an older GHC can work with a newer GHC. GHC does many cross-module optimisations, and its runtime system changes occasionally, so it is very pessimistic in that regard. This becomes an issue for packages that GHC has been build with itself (like base, process, array), since these cannot be upgraded without recompiling GHC (hence requiring recompiling every other package). is this correct? i was under impression that upgrading packages never require to recompile GHC itself. it just happen that we have only one version of base or array shipped with each GHC and at least with array this can be changed easily (and for base too - just noone plans to do it) Well, I was a bit imprecise. You can install a new array, but if you have a transitive dependency on the old array, this won't help. I'm not sure, but AFAIK the only thing that can introduce such a transitive dependency is the GHC API. So if you want to use the GHC API and a newer version of array in your program then you need to recompile ghc against the new array package. If you don't use the GHC API but want to use another package that has been compiled against array, you need to upgrade that other package, too. Modern versions of cabal-install should be able to do this where possible, but older ones ( 0.5, I think, Duncan knows) had problems with this. P.S.: I guess the moral of the story is that while cabal upgrade (no args) seems like a reasonable thing to do it is not yet very realiable. Many of these issues only became urgent because we now have such a powerful tool like cabal-install and we now have to add features to GHC, Cabal, and cabal-install to solve them. So, despite these unfortunate (and understandably frustrating) issues, we've come a long way since only 2 years ago, where every package had to be downloaded and installed manually using runghc Setup. P.P.S: Again, to the OP, please help us find out what exactly went wrong, so we can try to make sure that it won't happen again to you or anyone else. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: space in making 6.10.1-candidate
Yes, the problem is a space leak in Haddock. On a 32 bit system it takes up to 700MB of RAM. You should probably disable haddock for now. David Waern is working on a fix, but I don't know how long it'll take him. 2008/10/9 Serge D. Mechveliani [EMAIL PROTECTED]: Another point in testing ghc-6.10.0.20081007: I make it from source on Debian Linux. On 1 Gb - 2 GHz machine, it builds in 1400 sec. On 512 Mb machine, it seems to overfill RAM, it becomes slow, and this `make' creates difficulties for other processes (like emacs editor): they start to hang, a bit, and the `top' command shows 85% RAM used by this `make', now and then (and probably it takes more, sometimes). This effect is in making ghc-6.10.0.20081007 from source by ghc-6.10.0.20080921 on Debian Linux, on 512 Mb RAM i386-like machine. This was not so in earlier GHC versions. Can this be improved? Because 512 Mb is much enough. The last messages (after which I interruptred it) is make -C compiler doc stage=2 make[2]: Entering directory `/home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/compiler' /home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/libraries/cabal-bin /home/mechvel/ghc/6.10cand/inst0/bin/ghc /home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/ libraries/bootstrapping.conf haddock --distpref dist-stage2 --haddock-option=--optghc=-DSTAGE=2 --with-haddock=/home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/ utils/haddock/install-inplace/bin/haddock Preprocessing library ghc-6.10.0.20081007... Running Haddock for ghc-6.10.0.20081007... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: rts-1.0 Preprocessing library ghc-6.10.0.20081007... make[2]: *** [doc.stage.2] .. make[1]: *** [stage2] Interruption make: *** [bootstrap2] Interruption -- Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Control.Exception
2008/10/7 Johannes Waldmann [EMAIL PROTECTED]: with 6.10, the following does not typecheck: foo `Control.Exception.catch` \ _ - return bar Ambiguous type variable `e' in the constraint: `Control.Exception.Exception e' catch \(e :: SomeException) - ... This requires language ScopedTypeVariables (and perhaps PatternSignatures). Of cause, you should try to be more specific about which exceptions you want to catch as e.g., Ctrl-C and many other things are also reported as exceptions. It is probably bad programming style anyway but what is the workaround? I found some references (in list emails) to catchAny, ignoreExceptions but these don't seem to have made it? Best regards, J.W. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh [EMAIL PROTECTED] wrote: One way that it is worse is that you will get a lot more automatic merge commits when you pull changes from the central repo into a repo in which you have local commits. I don't think that there is anything bad about these, as such; they're just noise in the history. (I'm not sure if it's possible to automatically rebase these away, or something?). This is the use case for git pull --rebase. Instead of creating an automatic merge commit, it rebases your local changes on top of the newly pulled changes (ignoring patches already present, which could happen if you had sent one change as a patch via mail.) The timestamp issue seems tricky, though. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
If you have lots of local changes (e.g. the sorts of long-running branch that gives darcs 1 problems), then you need to use merge. If you use rebase then you might end up with lots of conflicts to manually resolve. Using merge gives you automatic merge commits, If you think these are ugly (opinion is divided on that amongst git people; I guess for GHC we'd want to make a global decision about that) then you can use rebase when you have few local changes, and thus you are unlikely to get many conflicts. Using merge you also get a more accurate reflection of the project history, i.e. you can see that the two branches were being developed independently. That's not quite accurate: If you have conflicts, you have conflicts and have to resolve them manually. In case of a branch, however, you only have to resolve them once you do the merge, so when _you_ decide, not whenever some upstream change breaks things. Some projects encourage to have one development branch and periodically update the master branch and rebase the development branch on top of it. I think it's a matter of taste and we should probably advocate one usage. I think rebase should only be used for smaller changes. The automatic usefulness of the automatic merge message is varying. I think it makes sense if it contains public repos, like, e.g. Merge 'master' from git://github.com/chak/ghc, but less useful for pulls from local repos like, e.g. Merge 'master' from '/home/igloo/tmp/trash/ghc/fix-stupid-osx-bug/'. However, if we prefer merges we get those pretty git history graphs: http://www.flickr.com/photos/malcolmtredinnick/1516857444/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
you don't use local branches? On Sat, Aug 16, 2008 at 12:04 AM, Johan Tibell [EMAIL PROTECTED] wrote: On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh [EMAIL PROTECTED] wrote: One way that it is worse is that you will get a lot more automatic merge commits when you pull changes from the central repo into a repo in which you have local commits. I don't think that there is anything bad about these, as such; they're just noise in the history. (I'm not sure if it's possible to automatically rebase these away, or something?). I'm not sure if this is what you want but I always use git pull --rebase when I'm pulling to have my local commits lie on top of the one in the published repo. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
Are you advocating for ease of use by new developers or for existing developers? Current GHC hackers have to learn Git anyways and know Darcs already. Library patches still have to be recorded separately, so it would be a bit weird, but not much harder, really. On Fri, Aug 15, 2008 at 1:59 AM, Manuel M T Chakravarty [EMAIL PROTECTED] wrote: Neil Mitchell: If it really makes the life easier for people who are having lots of VCS pain at the moment, then its hard to object. But many of the comments in this discussion, about how everyone is going to flock to GHC just as soon as it switches to Git, seem overly optimistic. I think GHC is a few years off becoming drive-by hacker friendly, for many other reasons. It's not about becoming drive-by hacker friendly. It is about not becoming even less friendly as it is right now. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Faster checkout times under Git
On 11 Aug 2008, at 23:15, Don Stewart wrote: Eric Mertens kindly did some experiments on the various git repos, and servers, and approaches to serving. * We're looking at 45 mins for a full history darcs get of ghc, over http, from darcs.haskell.org. * git clone of full ghc over http, from darcs.haskell.org, completes in the range of 6-7 minutes (roughly 150KiB/s) * git clone over git protocol, using github's bandwidth, completes in 2.1 minutes. (roughly 560KiB/s) So that indicates a significant improvment by switching to the git:// server protocol. Can we get that on darcs.haskell.org? In general git is doing a good job here addressing slow 'darcs get ' times, which are now way way down. This will make life easier for some of us. Mirroring automatically to github could also address some of our redundancy concerns. I'm working on both issues with Ian and Paul. The current setup also isn't friendly to incremental pulls over http. I'm working on it. / Thomas -- Push the envelope. Watch it bend. PGP.sig Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On 11 Aug 2008, at 12:38, Sittampalam, Ganesh wrote: Thomas Schilling wrote: (I am also no longer convinced that Darcs' automatic patch dependency calculations are actually a good idea. Just because two patches don't touch the same files, doesn't mean they aren't semantically dependent. Take for example monadification patches, which are typically submitted split up for each file. A branch captures those dependencies just fine.) But the darcs approach to dependency is what underlies cherry-picking, which many people consider the most worthwhile feature of darcs. In fact many people would like it to be possible to override even the dependencies that darcs *does* find to cherry-pick patch A without patch B that A depends on, at the expense of producing a conflict that then has to be fixed up by hand. Cherry-picking just a single patch is simple in Git: git cherry-pick commit-id[1]. What's missing in Git is the automatic detection of dependent patches. Otherwise it would be straightforward to write a Darcs frontend for Git. [1]: http://www.kernel.org/pub/software/scm/git/docs/git-cherry- pick.html / Thomas -- Push the envelope. Watch it bend. PGP.sig Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On 11 Aug 2008, at 13:00, Duncan Coutts wrote: It's not clear to me that we've really bothered to find out. The last evaluation in relation to ghc that I'm aware of was prior to the 2.0 release. My impression is that we've all complained about the darcs v1 problems (justly) but spent the most effort investigating things other than darcs v2 which would be the easiest to upgrade to and not have the problems of using two different systems for ghc vs other libs. I converted the ghc repo to darcs2 (locally): Getting file local history: * darcs changes --last 20 compiler/main/HscTypes.lhs very quick but prints only two patches * darcs changes compiler/hsSyn/HsTypes.lhs 1m22s (16s for the second time) Git 1s * darcs get ghc2 ghc-test (creating a *local* branch) real13m25.365s user0m14.677s sys 0m29.541s (at least it seems it actually worked, though) git clone ghc g2 (the slow method of creating a local branch) real0m6.742s user0m0.335s sys 0m0.652s * I haven't tested a remote pull yet. At 80 Kb/s, it should take about 15min to clone via Git (70 MB). A test of darcs would be interesting. Finally, of course, we have to hope that Darcs2's conflict problems are actually solved. I also had some weird automerges with Darcs when pulling from Max' repository, so Darcs isn't flawless there, either (this seemed to be one of the main critiques of Git). / Thomas -- Awareness is the enemy of sanity, for once you hear the screaming, it never stops. PGP.sig Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
I had my share of problems with Darcs; working on the GHC API I constantly have to avoid conflicts. My temporary workaround is to not update at all. Maybe switching to Darcs 2 format would help here, but there are other issues. I initially converted GHC to Git to be able to more easily checkout older versions (e.g., to find a build bug using git-bisect) but with external core libraries this just doesn't work. Right now, there is simply no practical way to check out an old, building version of GHC! Even if we'd switch to Darcs 2 this problem could not be solved. We would also still need turn to the Git repo to get change histories for specific files or to run commands such as 'git-blame' (unless you don't mind getting a cup of coffee and some biscuits each time you run those commands). I think we can make things easier for existing library contributors by providing a darcs/git cheat sheet or even a command line wrapper. Previous attempts at creating such a wrapper have been abandoned, possibly because some commands cannot easily be modelled in Git. However, if we accept some limitations this is doable. In particular the tricky commands are: darcs pull -- (save) cherry picking requires patch dependency information darcs push -- same as above (darcs pull -a and darcs push -a both can be modelled easily) darcs replace -- not directly supported in Git, but could be modelled -- with a script. If these missing features don't feel like too big a handicap the change should be fairly easy for existing contributors. (And with some time they can start and learn Git's other features.) For our build woes integrating the libraries and the main GHC repo in one Git repo will be very helpful, since we can now just instruct build bots to try and build revision 12345deadbeef and be happy. / Thomas -- My shadow / Change is coming. / Now is my time. / Listen to my muscle memory. / Contemplate what I've been clinging to. / Forty-six and two ahead of me. PGP.sig Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On 6 Aug 2008, at 12:35, Samuel Tardieu wrote: Simon == Simon Marlow [EMAIL PROTECTED] writes: Simon We already have an up-to-date git mirror thanks to Thomas Simon Schilling: Simongit clone http://darcs.haskell.org/ghc.git Simon (notice how fast that is :-) It would be even much faster if you (Thomas?) setup a git server. It is as easy as touch git-daemon-export-ok in the GIT repository and launching git-daemon /path/to/parent/of/git/repo at boot time, as shown by Chris Double at http://www.bluishcoder.co.nz/2007/09/how-to-publish-git- repository.html Then the git:// protocol can be used, which makes intelligent decisions on what needs to be transferred. Thanks, I will look into it. I need to talk to our admin anyway. / Thomas -- My shadow / Change is coming. / Now is my time. / Listen to my muscle memory. / Contemplate what I've been clinging to. / Forty-six and two ahead of me. PGP.sig Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
