Friends
I have a branch, wip/new-flatten-skolems-Aug14, which has a long succession of
work-in progress patches. Plus a couple of merges from HEAD.
I'd like to completely re-organise the patches before committing to HEAD. How
do I do that? Some kind of rebase? Clearly I want to start from
You might try and run 'git rebase' (you can run 'git rebase --abort' if
things get too hairy), which will remove the merge patches
and put your patchset on HEAD. Unfortunately, if you've done nontrivial work
resolving merge conflicts, rebase doesn't really know how to take
advantage of that, so
Hi,
Am Donnerstag, den 16.10.2014, 08:08 + schrieb Simon Peyton Jones:
I’d like to completely re-organise the patches before committing to
HEAD. How do I do that? Some kind of rebase? Clearly I want to
start from current HEAD, rather than having weird merge patches
involved.
I was
Hello,
Simon, I wouldn't worry about my branch---my changes are fairly orthogonal,
so it shouldn't be too hard for me to the same sort of operation on top of
`master`, once your changes are in there.
-Iavor
On Thu, Oct 16, 2014 at 2:24 AM, Joachim Breitner m...@joachim-breitner.de
wrote:
Simon
Aargh! I think the Windows build is broken again.
I think this is your commit 5300099ed
Admittedly this is on a branch I'm working on, but it's up to date with HEAD.
And I have no touched Linker.c!
Any ideas?
Simon
rts\Linker.c: In function 'allocateImageAndTrampolines':
Hi Jan,
This fix should work, although I can't reproduce it; I imagine you
must not have pthread_setname_ap available. It's glibc 2.12+ only,
while Debian oldstable only has glibc 2.11.
https://phabricator.haskell.org/D344
Let me know if it works for you.
On Thu, Oct 16, 2014 at 5:47 AM, Jan
I remember having a similiar issue once that I think I used git rebase -p.
Unfortunately -p is incompatible with -i, but I think there's a way around
this that I don't remember right now.
On Thu, Oct 16, 2014 at 1:08 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
Friends
I have a
I see what's going on and am fixing it... The code broke 32-bit due to
#ifdefery, but I think it can be removed, perhaps (which would be
preferable).
On Thu, Oct 16, 2014 at 3:43 PM, Simon Peyton Jones
simo...@microsoft.com wrote:
Simon
Aargh! I think the Windows build is broken again.
I
I was working on a fix yesterday but ran out of time. Frankly this code
is a nightmare, every time I touch it it breaks on some platform - this
time I validated on 64 bit Windows but not 32. Aargh indeed.
On 16 Oct 2014 14:32, Austin Seipp aus...@well-typed.com
mailto:aus...@well-typed.com
I don't know what's going on, but T3064 is giving some substantial
performance trouble, making all the validations fail:
max_bytes_used value is too high:
ExpectedT3064(normal) max_bytes_used: 13251728 +/-20%
Lower bound T3064(normal) max_bytes_used: 10601382
Upper bound
10 matches
Mail list logo
