bfrk: I sent the build failure output for your unix-compat repo to the list - if you want to iterate on fixing it I should be around here off and on

Thanks! I pushed a new commit that hopefully fixes all problems.

that builds, I still get warnings in System.PosixCompat.Files

Please post them, will try to fix.

Thanks, also fixed now. Next thing to try is build darcs with that as "submodule" and see if that builds okay.

was doing that in parallel, it did build. I'll do it again with your new push.

Then I'll run the tests

src\System\PosixCompat\Files.hsc:136:1: warning: [-Wunused-imports] The import of `hFileSize' from module `System.IO' is redundant |

136 | import System.IO (IOMode(..), openFile, hFileSize, hSetFileSize, hClose) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

still have that one warning

Heffalump: warning fixed. These warnings are really helpful. Removing the now redundant imports and functions nicely documents the expected performance improvements.

BTW, with git I am always using the "record" extension. Very "darcsy"...

:-)

I'm using git a bit more at the moment, I should probably look into things like that.

(except it seems they couldn't be bothered to make the UI react to single key presses...)

I've kicked off the tests (--darcs1=no --darcs3=no --network=no). Will let you know when they finish (at least 10s of minutes...)

Oops, 'git record' is not an extension, but a mere alias for 'add --patch'. This is what I have in ~/.gitconfig:

[alias]

meld = !git difftool -t meld --dir-diff

record = add --patch

ah, that's even handier as I don't have to install anything

I might have known about --patch ( I guess it's -p)

but certainly don't know it instinctively

I really hope running the tests on Windows will be faster when my index patches land.

re git: yes, that's why I love the record alias

I think the Windows overhead is mostly all the process creation. UNIX-style shell scripts and Windows are a bad mix.

Is process creation still that bad in Windows? I thought I read somewhere that they improved a lot on that a few years ago. But I may may remember wrongly.

not sure

BTW, where did all the smiley's come from???

which smileys?

In the warning message you posted above

your IRC client? I see text

I am using thunderbird now for chats

I would guess that some juxtaposed punctuation got interpreted as a smiley by that and presented as a graphic

Yep

I keep sending people beer icons at work when I use (a) and (b) in Skype for business

LOL

even though it's all one client/app, it only translates them after I hit enter, not while I'm typing

very friendly UI...

re git: I should also add an alias 'amend = commit --amend'

...and one for unrecord, too, need to figure out the magic options for that are

We should all number items using cute icons. Makes for more relaxing conversation. Especially in business ;-)

Perhaps the programmer was an anarchist and did it purpose

re windows slowness: have you by chance also noted that darcs itself got slower on windows? I ask because I remember replacing Win32 specific code with unix-compat imports a while ago. And now that I looked closer at what that package does for windows I'd not be too surprised.

haven't noticed anything

I guess that's because you don't have 'ALL ignore-times' in your defaults. Which is is what we do in the test suite. (Just a guess)

A year ago I imported the linux kernel into darcs (not the history, only the state back then) just because I wanted to see if that is even possible. It is. But I had to use 'record -l' and still had to split it into several separate records because darcs uses too much memory.

I am still occasionally using that repo as a power load for darcs. Recently I tried running a darcs whatsnew --ignore-times. I let that run for a few a minute or so before killing it...

Takes just a few seconds when the index is used i.e. by default

Heffalump: I have squashed all the commits into one in the unix-compat clone.

ok, I'll blow away my tree once this test run finishes

(it's at 'p'...)

I have done some additional cleanup and pushed all my current patches to hub.darcs.net/bf/darcs-work, including the ones that switch the default for the test suite to use the index (almost) everywhere. You may want to pull and restart the test run... or perhaps first test a new one and run that in parallel...

* I meant: start a new test run and run that in parallel

(there are some unrelated patches there, I can't be bothered to separating them out at the moment)

As usual there is lots of cleanup mixed in, but I took care to record them in separate patches.

BTW, you can git fetch && git reset --hard origin/master instead of "blowing away" your tree

(I just figured that out with trial and error; will forget in about 5 minutes)

my first test run passed (i.e. darcs screened, your unix-compat repo). I'll do it again with your patches.

Cool, thanks!

If that succeeds, too, I will issue a pull request.

this time darcs doesn't build: pastebin.com/tuWGVLYM

this is with the reset unix-compat and with your darcshub tree (pulled into screened)

I've pushed a fix, please pull again.

CI-via-IRC :-)

Okay, this one is a bit less trivial. And yes, we *do* need proper CI. More on that later.

unix-compat thinks that System.Posix.Types from base has a 16 bit CIno and that it has to edfine its own version for windows. That must have been decades ago. Will fix.

I have pushed another commit to my unix-compat clone. Hopefully fixes the problem.

src\System\PosixCompat\Files.hsc:138:1: error: Could not load module `System.PosixCompat.Types'

Okay, yet another commit...

Hmm, wait a sec. I think removing the module may not be a good idea as that could break other packages. Will make it re-export all of System.Posix.Types instead.

Okay, have remove my last attempt and push a new commit. It keeps the module and merely throws away redefiniton of the FileID type.

one warning:

src\System\PosixCompat\Types.hs:25:1: warning: [-Wunused-imports]

The import of `Word64' from module `Data.Word' is redundant

|

25 | import Data.Word (Word32, Word64)

| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

darcs itself built ok, tests running

Nice! Hope it works...

the test suite stopped accepting the --darcs1=no flag - I'm busy now, will look later

I forgot to mention that I changed the UI of the test suite to make it easier to switch between different sets of tests. Help extract:

-s --suites=SET Select which test suites to run: (s=shell, n=network,

u=unit, f=failing, h=hashed) [snu]

-f --formats=SET Select which darcs formats to test: (1=darcs-1,

2=darcs-2, 3=darcs-3) [123]

-a --diffalgs=SET Select which diff alorithms to use (p=patience,

m=myers) [p]

-i --index=SET Select wether to use the index (n=no, y=yes) [y]

--full Shortcut for -s=snu -f=123 -a=mp -i=yn

You will want to use -f=2 or -f2 to run only for darcs-2 format.

All my patches are mere proposals at the moment, this one included.

running now

Will be away now for 2-3 hrs

one failure so far: pastebin.com/9a75NTnS [will repeat when bfrk re-appears]

Heffalump: How did it go?

some index failures, e.g. pastebin.com/9a75NTnS

that one at least is reproducible, I didn't check the others. They all seemed fairly similar.

I think there were 6 in total, I can copy the whole outputs if you want

Yes, that would help. The one you posted is strange, that must be a Windows thing. It tells us that we are not allowed to remove the index because we don't have the permissions. I would expect that to happen on Windows if the file is already opened, but ATM I cannot see how that is possible. Anyway, will rollback a change that I made and restore the old (rename to x.old) behavior here.

most of the errors looked like that

there's the rest of them

Okay, yes it seems we must not remove the index. I have pushed a patch that reverts the behavior back to renaming it away instead.

Anyway, I am really happy to see that this seems to be the only problem!

in general renaming is way safer on Windows

issue2293 passes now, I'll try the rebase tests then everything

I quite like the new command-line args (at least I think I will once I remember some common options)

weird, lots of tests with 'rebase' in the name are failing that weren't before, e.g. pastebin.com/Zf0afVzH

Oops. I get these failures, too.

oh, ok :-)

I assumed Windows was up to no good again.

Arg, totally stupid mistake.

Pushed yet another patch to fix the fix ;-)

Trying now - I almost want this to go wrong just for the next patch name :-)

It looks like I am a bit too tired. I get lots of test failures with that one too.

...okay that was because I still had some unrecorded changes lying around that printed a message to stderr whenever indexFormatValid runs into an exception. Reverted them & it works now for me

the next patch name would have contained some serious swearing i guess

unprintable characters liek backspace mixed in?

never tried that one in darcs

we have enough trouble with encodings as it is

-t rebase and -t issue2293 are both good, I'll try everything now

I have just rebased everything, incorporating the fixes into the patches that introduce the errors. Next time use rebase pull!

don't I really just want obliterate --not-in-remote first?

rebase pull seems like a nice way of making a mess

(in this scenario)

Doing obliterate --not-in-remote first is perhaps the better idea in this case. I am not using it so often because I normally can't remember what by default remote is. Also like to have a safety net. For me this doesn't produce a mess, I often do a rebase obliterate soon afterwards.

When I do the latter I am careful not to delete patches that I may want to look at later. BTW, nowadays you can also do rebase suspend --not-in-remote...

I know I don't have anything but your stuff in this repo

Then obliterate is probably the cleaner solution.

I also keep forgetting that --not-in-remote accepts an optional repo parameter (in case you aren't sure about the defaultrepo).

yeah

though it's the only option where you have to use =, precisely because it's optional

Ah yes, I have stumbled over that one.

More than once

Even though it makes perfect sense. The command completion doesn't handle that case yet, not even with zsh.

What I mean is, zsh does have completions where completing an option inserts the '=' for you to remind you of possible option args, but when you hit space it deletes the '='. Very nice.

How does the test run fare? Any failures yet?

all passed