You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
digger bisect is awesome, and the main reason I use this tool. However, it can feel very unfriendly at times.
I'll list a few points resulting to last night's use here:
The readme is quite lacking: It mentions that bisect.ini.sample needs to be copied to bisect.ini. At the very least a link should be added, as the easiest way to use digger (via dub) means that the user might not know where this file is;
Running bisect requires a configuration file, which is quite unfriendly... Not to mention, overkill, as the tests show that just 3 values are really needed.
Bisect has no option (that I could see) to do an interactive run. Sometimes the bug to reproduce doesn't quite fit in a tester command and one just want to bisect things, in which case digger is still useful. In my case, the program runs out of memory, and then waits forever, but only on Windows, and I spent a ridiculous amount of time figuring out the quirks of getting this to work (turns out a D script is much easier).
Bisect has no option (that I could see) to do an interactive run.
You could use this as the test command for that: test "$(read -r -N 1 -p "Does the bug happen? [y/n] " && echo "$REPLY")" == n. Adding a native interactive option would be nice, perhaps make that the default behaviour if a tester isn't specified.
Yeah, that change was unpleasant, and we had an argument over it when it was copied over to rdmd. I'm still not sure if it was a good idea. In any case, the workaround is to specify --compiler=dmd. Not sure if it's something Digger can do something about other than get it documented.
digger bisect
is awesome, and the main reason I use this tool. However, it can feel very unfriendly at times.I'll list a few points resulting to last night's use here:
The readme is quite lacking: It mentions that
bisect.ini.sample
needs to be copied tobisect.ini
. At the very least a link should be added, as the easiest way to use digger (viadub
) means that the user might not know where this file is;Running
bisect
requires a configuration file, which is quite unfriendly... Not to mention, overkill, as the tests show that just 3 values are really needed.Bisect has no option (that I could see) to do an interactive run. Sometimes the bug to reproduce doesn't quite fit in a tester command and one just want to bisect things, in which case digger is still useful. In my case, the program runs out of memory, and then waits forever, but only on Windows, and I spent a ridiculous amount of time figuring out the quirks of getting this to work (turns out a D script is much easier).
A common pitfall one may find itself in is to use the
dub
packaged with DMD. In which case it seems to take priority over the one in$PATH
: https://github.com/dlang/dub/blob/0bf4ddaf522d5139eca8749b6b4218eb8e247086/source/dub/dub.d#L1415-L1416The text was updated successfully, but these errors were encountered: