Re: New codegen failing test-cases
With further poking, I think the new codegen is actually tickling an existing bug in the native code generator optimizations, since the cmmz output looks ok: cSH: _sQR::I32 = I32[_sRi::I32 + 3]; // CmmAssign _sQS::I32 = I32[_sRi::I32 + 7]; // CmmAssign _sQT::I32 = I32[_sRi::I32 + 11]; // CmmAssign _sQU::I32 = I32[_sRi::I32 + 15]; // CmmAssign (_sR1::I32) = call "ccall" arg hints: [`signed', PtrHint,] result hints: [] (_sQR::I32 & (-4))(_sQS::I32, _sQT::I32, _sQU::I32); // CmmUnsafeForeignCall And the only change is that in the original code generator, the assignment to _sQR is elided. _cSn::I32 = I32[R1 + 7]; _cSp::I32 = I32[R1 + 11]; _cSr::I32 = I32[R1 + 15]; (_sR1::I32,) = foreign "ccall" I32[R1 + 3]((_cSn::I32, `signed'), (_cSp::I32, PtrHint), (_cSr::I32,))[_unsafe_call_]; I further verified that there was no problem if I used -fvia-C. On closer inspection, the fact that _sQR is referenced nowhere in this dump should have raised alarms (I think the register allocater happened to assign it to the same register as _sRi, which is why the assembly looked vaguely plausible.) I'm still not sure where a fix might lie, but if I take another crack at it tomorrow I will probably figure it out. Cheers, Edward Excerpts from Edward Z. Yang's message of Wed Jan 12 17:10:11 -0500 2011: > I appear to have tracked down the bug for ffi021: the new > code generator doesn't appear to clear the tag bit for the > pointer to heap before: > > // outOfLine should follow: > (_sR1::I32,) = foreign "ccall" > _sQR::I32((I32[_sRi::I32 + 7], `signed'), > (I32[_sRi::I32 + 11], PtrHint), > (I32[_sRi::I32 + 15],))[_unsafe_call_]; > // emitReturn: Sequel: Assign > ; > > (gdb) disas > Dump of assembler code for function sRi_info: > => 0x0804aa6c <+0>: mov%esi,%eax >0x0804aa6e <+2>: lea0x0(%ebp),%ecx >0x0804aa71 <+5>: cmp0x54(%ebx),%ecx >0x0804aa74 <+8>: jb 0x804aab3 >0x0804aa76 <+10>:add$0x4,%ebp >0x0804aa79 <+13>:add$0x8,%edi >0x0804aa7c <+16>:cmp0x5c(%ebx),%edi >0x0804aa7f <+19>:ja 0x804aaa4 >0x0804aa81 <+21>:pushl 0xf(%eax) >0x0804aa84 <+24>:pushl 0xb(%eax) >0x0804aa87 <+27>:pushl 0x7(%eax) >0x0804aa8a <+30>:call *%eax > > The pushes to the stack properly untag eax, but then we just > call the tagged pointer, which seems pretty wrong to me. Here is > the old C--: > > (_sR1::I32,) = foreign "ccall" > I32[R1 + 3]((_cSc::I32, `signed'), (_cSe::I32, PtrHint), > (_cSg::I32,))[_unsafe_call_]; > > Unfortunately, I can't figure out where this +3 is supposed to > be happening, so I don't have a patch. Some guidance here would > be appreciated. > > Cheers, > Edward ___ 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 1/12/11 5:34 PM, Tim Chevalier wrote: On Mon, Jan 10, 2011 at 8:52 AM, Malcolm Wallace wrote: If I were considering contributing minor patches to a project, the use of git would probably not deter me too much - I can cope with the simple stuff. But if I wanted more major involvement, git would definitely cause me to think twice about whether to bother. I agree with Malcolm (and with Neil's later post); I wanted to issue a me-too because of all of the pro-git messages I've been seeing. I've been using git for two years at my job. I still can't do anything but the most basic tasks. When I try to read the documentation, the documentation (a) is incomprehensible and (b) tells me that I'm stupid because I find it incomprehensible. I found darcs easy to learn and it has always made sense to me. I've lost work and had to recreate it by hand because of git. Me three, FWIW. Casual use of git is as easy as casual use of any modern VCS or DVCS, but even moderately sophisticated use is beyond my ken and (evidently) beyond the documenting abilities of the community. Anything that can't be clearly documented sets off warning bells. Conversely, moderately sophisticated use of darcs was extremely easy for me to acquire, and I find working with darcs repos much more pleasant than the alternatives I deal with regularly. I haven't had the opportunity to contribute to GHC yet, though I've been meaning to change that recently. I can't say whether git would cause me to decide against contributing, but it would raise the barrier to entry and make it more likely that I just wouldn't find the time to follow through with such contributions. -- Live well, ~wren ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
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. Untested, so I might have gotten one or two details wrong. > Suppose I want to hack on GHC and base (base is a submodule of GHC). For > this, I want to: > > - pull the latest patches to both GHC and base # pull the latest patches for GHC, and sticks your patchset on top git pull --rebase # # register any new submodules (if any) git submodule init # make your submodules reflect the latest version GHC has git submodule update --rebase # > - write code > - record my patches in both GHC and base cd libraries/base git commit -asm "Base patch" cd ../.. git commit -asm "GHC patch" Note that your commit to libraries/base changed what commit it is pointing to, so your GHC commit will then pick up the changed sumbodule. If you do the commits in the opposite order, this won't happen. So commit in all submodules first. > - pull again to get whatever patches have been pushed while I was hacking git pull --rebase git submodule update --rebase > - validate > - push my patches to both GHC and base git send-mail --to=cvs-...@haskell.org $PATCHES cd libraries/base git send-mail --to=cvs-...@haskell.org $PATCHES Cheers, Edward ___ 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 12/01/2011, at 22:22, Iavor Diatchki wrote: > When you issue the command "git submodule update", you are telling git to > advance the sub-module repo to the "expected version" (i.e., where the > pointer points to). The reason this does not happen automatically is that > you might have also made changes to the submodule, so you might want to do > some merging there, instead of just pulling. Thank you so much for the explanation. Sadly, I'm still confused. Are you saying that "submodule update" is the wrong thing to do if I have changes in some of the submodules? > One thing to note is that if we were to set things up with sub-modules, then > every now and then we would have to advance the GHC's "expected pointer" for > various libraries to the latest (or a newer) version. Of course, we could > have a script do this but, at least in theory, when someone makes a commit > which updates the version of a sub-module, they are asserting that they > things ought to work with the newer version of the sub-module. How would we get the current functionality of darcs-all pull? Is it even possible? Suppose I want to hack on GHC and base (base is a submodule of GHC). For this, I want to: - pull the latest patches to both GHC and base - write code - record my patches in both GHC and base - pull again to get whatever patches have been pushed while I was hacking - validate - push my patches to both GHC and base Which commands would accomplish this? The git docs still don't make any sense to me. FWIW, I'd be very wary of using any features that are so badly documented. Or programs, for that matter. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On Mon, Jan 10, 2011 at 8:52 AM, Malcolm Wallace wrote: > As another non-GHC contributor, my opinion should probably also count for > little, but my experience with git has been poor. > > I have used git daily in my job for the last year. Like Simon PJ, I > struggle to understand the underlying model of git, despite reading quite a > few tutorials. I have a high failure rate with attempting anything beyond > the equivalents of darcs record, push, and pull. > > When I use darcs, my local workflow typically involves lots of amend-record, > cherry-picking, and multiple repos/branches. I have tried to do these > things in git a few times and failed miserably. I am an old-fashioned unix > command-line lover, but I find using the git command-line is next to > impossible, and as a consequence do almost everything in git gui. If the > gui interface does not let me do an action, then I often can't work out how > to do it at all, even after googling. > > Mind you, some other people at work somehow manage to use git's support for > branching reasonably successfully. But we have occasional mishaps where a > repo is made totally unusable by somebody making a tiny mistake with their > branching commands. Our standard advice at work for people who get their > repo muddled is to throw it away, re-clone the master, and manually re-code > their local changes from scratch (with the help of diff). > > If I were considering contributing minor patches to a project, the use of > git would probably not deter me too much - I can cope with the simple stuff. > But if I wanted more major involvement, git would definitely cause me to > think twice about whether to bother. I agree with Malcolm (and with Neil's later post); I wanted to issue a me-too because of all of the pro-git messages I've been seeing. I've been using git for two years at my job. I still can't do anything but the most basic tasks. When I try to read the documentation, the documentation (a) is incomprehensible and (b) tells me that I'm stupid because I find it incomprehensible. I found darcs easy to learn and it has always made sense to me. I've lost work and had to recreate it by hand because of git. I've only ever been an occasional GHC contributor, so my opinion shouldn't count for much, but a switch to git would be one more small thing that would discourage me from contributing in the future. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
Hello, On Wed, Jan 12, 2011 at 11:44 AM, Roman Leshchinskiy wrote: > On 12/01/2011, at 09:22, Simon Marlow wrote: > > > On 11/01/2011 23:11, Roman Leshchinskiy wrote: > >> > >> A quick look at the docs seems to indicate that we'd need to do > >> > >> git pull > >> git submodule update > >> > >> which doesn't look like a win over darcs-all. Also, I completely fail to > understand what git submodule update does. It doesn't seem to pull all > patches from the master repo. The git submodule docs are even worse than the > rest of the git docs which is rather discouraging. > > > > True, however the build system could automatically check whether you had > missed this step, because it could check the hashes. > > That would be an improvement. How do you pull submodule patches which the > main repo doesn't depend on, though? Out of curiousity, has anyone here used > submodules for something similar to what we would need? A "submodule" is basically a "pointer" to a particular state of a remote repo. So when you do "git pull" in GHC, you get changes to the code, and also changes to this "pointer", but it won't automatically modify your local version of the sub-module repo. So at this point, if you started "git gui" you'd see that there is a mismatch between your local copy of the sub-module and the expected version. When you issue the command "git submodule update", you are telling git to advance the sub-module repo to the "expected version" (i.e., where the pointer points to). The reason this does not happen automatically is that you might have also made changes to the submodule, so you might want to do some merging there, instead of just pulling. One thing to note is that if we were to set things up with sub-modules, then every now and then we would have to advance the GHC's "expected pointer" for various libraries to the latest (or a newer) version. Of course, we could have a script do this but, at least in theory, when someone makes a commit which updates the version of a sub-module, they are asserting that they things ought to work with the newer version of the sub-module. -Iavor PS: I've only used sub-module on what project at work. At first I too was quite confused about what was going on, but I've come to think that submodules are a pretty reasonable way to deal with a situation which is inherently complex. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
You can emulate darcs's patch re-ordering in git if you put each independent sequence of patches on a separate branch. Then you can re-merge the branches in whatever order you want. This is a fairly common git workflow. What happens after the merges? Does one maintain the branches somehow, or does one lose the (in-)dependency information? Claus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: New codegen failing test-cases
I appear to have tracked down the bug for ffi021: the new code generator doesn't appear to clear the tag bit for the pointer to heap before: // outOfLine should follow: (_sR1::I32,) = foreign "ccall" _sQR::I32((I32[_sRi::I32 + 7], `signed'), (I32[_sRi::I32 + 11], PtrHint), (I32[_sRi::I32 + 15],))[_unsafe_call_]; // emitReturn: Sequel: Assign ; (gdb) disas Dump of assembler code for function sRi_info: => 0x0804aa6c <+0>: mov%esi,%eax 0x0804aa6e <+2>: lea0x0(%ebp),%ecx 0x0804aa71 <+5>: cmp0x54(%ebx),%ecx 0x0804aa74 <+8>: jb 0x804aab3 0x0804aa76 <+10>:add$0x4,%ebp 0x0804aa79 <+13>:add$0x8,%edi 0x0804aa7c <+16>:cmp0x5c(%ebx),%edi 0x0804aa7f <+19>:ja 0x804aaa4 0x0804aa81 <+21>:pushl 0xf(%eax) 0x0804aa84 <+24>:pushl 0xb(%eax) 0x0804aa87 <+27>:pushl 0x7(%eax) 0x0804aa8a <+30>:call *%eax The pushes to the stack properly untag eax, but then we just call the tagged pointer, which seems pretty wrong to me. Here is the old C--: (_sR1::I32,) = foreign "ccall" I32[R1 + 3]((_cSc::I32, `signed'), (_cSe::I32, PtrHint), (_cSg::I32,))[_unsafe_call_]; Unfortunately, I can't figure out where this +3 is supposed to be happening, so I don't have a patch. Some guidance here would be appreciated. Cheers, Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
We can't even do this reliably with darcs. Several times I've tried to unpull one of Simon's patches to work around a bug, and the dependencies end up being more than just the textual dependencies. Then I have to fall back to unpulling by date, which is what git would do. And then sometimes there's the separate problem that you have to retreat the library repos too, and there you have to unpull by date and some guesswork too. Perhaps it is possible to take the guesswork out of this latter problem? For all the repos to be linked, maintain a single file "patch-history.txt", add a posthook to all repos so that every commit will be logged as a line in patch-history.txt: repo-id : patch-id : short commit message, or other greppable info Then, if you have a patch id in the GHC repo, you just have to search backward from that id in patch-history.txt until you have matching last-patch ids for the other repos. That search (and darcs-all (un-)pulling up to the patch ids for all repos) could probably be scripted, so it would become a single command (input: repo-id/patch-id for a patch in one of the repos; output: list of repo-ids/patch-ids identifying a consistent set of repo states). Could that be made to work? Claus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
* Simon Marlow: > Thanks for this. I distilled your example into a shell script that > uses git, and demonstrates that git gets the merge wrong: > > http://hpaste.org/42953/git_mismerge > > Still, git could get this merge right, it just doesn't (I know there > are more complex cases that would be very hard for git to get right). > I suspect that in practice this rarely matters, because context-based > merging usually does the right thing. Git will have a very hard time getting this right because it is not that history-aware. It's also unlikely that this is implemented because this mismatching of changes happens only rarely, unless you have a coding style which heavily relies on copy-and-paste. (It has happened in real-world merges, though. It is also easy to construct similar examples involving file renames, I believe.) I know only one criterion for merge correctness: developers working serially on the code base would end up with the same result. (This is based on the concept of a serializability in transaction processing systems.) It is clear that no system can satisfy this. For instance, suppose you have a LaTeX document for one-page flyer. Obviously, there is a very hard requirement that you can have only one page of text. Two parallel edits can satisfy this constraint, but their automatic merge might not. (Zooko's example is different in that there is an apparently correct solution, so it is not absolutely necessary to bail out, but of course, the authors could likely squeeze their content on a single page, too.) Inevitably, you have to make trade-offs. The Git approach seems to suit more developers and codebases than the darcs approach. Git mismerges are much rarer than non-completing darcs merges. On the other hand, speaking as a non-contributor, the requirement to deal with multiple version control systems seems awkward. But the current sub-tree approach also feels a bit clunky (same as for OpenJDK, by the way). ___ 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 12/01/2011, at 09:22, Simon Marlow wrote: > On 11/01/2011 23:11, Roman Leshchinskiy wrote: >> >> A quick look at the docs seems to indicate that we'd need to do >> >> git pull >> git submodule update >> >> which doesn't look like a win over darcs-all. Also, I completely fail to >> understand what git submodule update does. It doesn't seem to pull all >> patches from the master repo. The git submodule docs are even worse than the >> rest of the git docs which is rather discouraging. > > True, however the build system could automatically check whether you had > missed this step, because it could check the hashes. That would be an improvement. How do you pull submodule patches which the main repo doesn't depend on, though? Out of curiousity, has anyone here used submodules for something similar to what we would need? >> Thomas says that it doesn't do automatic dependency tracking which looks >> like a huge weakness to me. Personally, I haven't been able to successfully >> unpull non-consecutive chunks of patches with git so far but I only tried 2 >> or 3 times before giving up. > > Right, not being able to automatically commute patches is a regression > compared to darcs. Git isn't universally "better" than darcs, which is why > we're having this discussion - the question is, do the advantages outweigh > the disadvantages. Oh, definitely, I wasn't implying than one is somehow objectively better than the other. All I'm saying is that darcs is much better suited to my personal workflow than git. Or at least the very small part of git that I've been able to figure out (I do have to say that I've probably read about 3x as much about git as I ever read about darcs, though). Roman ___ 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 Wed, 12 Jan 2011, Claus Reinke wrote: > > In my understanding, the unorderedness of patch history in darcs is > there to make distributed repos easier (fewer constraints: same set of > patches, but not same order; can mix local commits and pulls from > various repos, no need for a central repo), Apart from variable patch ordering all of that is true of all DVCSs. > and because darcs has a causal rather than a temporal view of patch > history (which patch depends on which other patches, instead of which > patch came first). You can emulate darcs's patch re-ordering in git if you put each independent sequence of patches on a separate branch. Then you can re-merge the branches in whatever order you want. This is a fairly common git workflow. > In other words, always keep a branch/repo that only pulls from the central > repos (no other source of patches). It is normal in git to keep a pristine branch for each remote repository that you pull from - git sets these branches up by default. There can be many remotes in a git repository. Tony. -- f.anthony.n.finchhttp://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
The main advantages to darcs are that it can manipulate the sequence of patches better than git. The main advantage of git is that every version is accurately named. If two people have a commit with a given hash, they will have exactly the same files and history. I've been wondering about this darcs disadvantage, and have a question: In my understanding, the unorderedness of patch history in darcs is there to make distributed repos easier (fewer constraints: same set of patches, but not same order; can mix local commits and pulls from various repos, no need for a central repo), and because darcs has a causal rather than a temporal view of patch history (which patch depends on which other patches, instead of which patch came first). Now, the GHC workflow does single out one central (set of) repo(s) that receives all patches that ever make it into production use. Currently, there is no requirement that all patches in remote repos come in via that central repo, so there is no ordering guarantee for remote repos, but darcs makes no efforts to permute the patches in the central repos. So, shouldn't it be possible to use the central repos as reference point for patch ordering? To restore an earlier combination of repo states, refer to the central repos, and their (otherwise irrelevant for darcs) ordering of patch history. darcs-all could then record/ restore the state of a set of repos, by referring to the relation of patches in the central version of these repos. And if one really wanted to enforce the same patch ordering on all repos, one could change the workflow: never mix local and common patches, always remove local patches after pushing to the central repos, then pull those patches again from the central repos (to get them in the same order as everyone else). In other words, always keep a branch/repo that only pulls from the central repos (no other source of patches). One could still have other branches/repos for development/testing, but the pristine copy of the central repos would reflect the reference order of patches (wouldn't it?). Would this help with the problem of finding a consistent set of older revisions of the GHC/library repos? Claus ___ 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/01/2011 19:07, Roman Leshchinskiy 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. We can't even do this reliably with darcs. Several times I've tried to unpull one of Simon's patches to work around a bug, and the dependencies end up being more than just the textual dependencies. Then I have to fall back to unpulling by date, which is what git would do. And then sometimes there's the separate problem that you have to retreat the library repos too, and there you have to unpull by date and some guesswork too. Cheers, Simon ___ 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/01/2011 23:11, Roman Leshchinskiy wrote: On 11/01/2011, at 22:20, Simon Marlow wrote: On 11/01/11 21:57, Roman Leshchinskiy wrote: IMO, darcs-all works pretty well. I don't think I ever really had problems with missing library patches. I often see problems where someone has done 'darcs pull' rather than './darcs-all pull' and ended up with a weird compilation error as a result. If we could eliminate this source of errors, it would be a major win. A quick look at the docs seems to indicate that we'd need to do git pull git submodule update which doesn't look like a win over darcs-all. Also, I completely fail to understand what git submodule update does. It doesn't seem to pull all patches from the master repo. The git submodule docs are even worse than the rest of the git docs which is rather discouraging. True, however the build system could automatically check whether you had missed this step, because it could check the hashes. This would be useful. Unfortunately, git's rewinding seems rather crippled compared to darcs. In what way? Thomas says that it doesn't do automatic dependency tracking which looks like a huge weakness to me. Personally, I haven't been able to successfully unpull non-consecutive chunks of patches with git so far but I only tried 2 or 3 times before giving up. Right, not being able to automatically commute patches is a regression compared to darcs. Git isn't universally "better" than darcs, which is why we're having this discussion - the question is, do the advantages outweigh the disadvantages. For example, you might well consider the lack of a working annotate to be a "huge weakness" in darcs, and the lack of good conflict handling is something that causes us real problems. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
