Sean (May 12 2020 at 20:59): Sean (May 12 2020 at 20:59):@starseeker bot command arg ordering is potentially minimally impacting.
bot get is a bit impactful, but bot check would be a bit surprising that the args couldn't be adjusted in a minimally-impacting way.
starseeker (May 12 2020 at 22:03):@Sean - Haven't put extensive thought into it, so maybe. Was mostly just trying to refactor so it's easier to add new subcommand functionality - a general cleanup can probably wait until we finalize a general pattern for such commands. Right now bot and brep are doing different things, and minimally we'd have to audit Archer and the other Tcl codes when we change any of them.
starseeker (May 12 2020 at 22:05):I've broken enough stuff lately. I'm going to finish up the C++ version of repository.sh - I'm fairly close now, that shouldn't break anything in the mainline code, and initial performance tests are looking quite promising - but after that I need to get back to understanding how Tk events and threads interact.
Notification Bot (May 13 2020 at 06:44):This topic was moved by Sean to #Google Season of Docs > introduction
starseeker (May 13 2020 at 12:13):That said, we need to have a discussion at some point if/when/how to merge the refactoring of the display manager / framebuffer code back into trunk. It will turn stale relatively quickly, given the extensive nature of the changes, so if we want to use it that merge shouldn't linger indefinitely... I know we need to get a working release with Tcl/Tk 8.6 out first, but I'd like to have a game plan once we're over that hurdle.
Sean (May 13 2020 at 18:46):I would plan for it as 7.34 after at least two 7.32 releases with Tcl/Tk 8.6. Or vice versa.
That's a pretty significant change. To merge, really needs to have cross-platform confidence from more than one person, doesn't have shortcuts (not claiming it does, didn't pay close attention because it's on a branch), doesn't have other maintenance concerns, and isn't otherwise going to introduce badness.
It's not tied to a user-visible feature, so burden is intrinsically on the branch. It's a pretty significant change LIKELY to introduce a bug somewhere, even with testing.
Is it working now? I can do some builds next week to see how it's looking. Just recently you still seemed to be debugging and hacking on it, though? I think at a minimum, someone (else) on Windows and Mac needs to test it.
starseeker (May 14 2020 at 04:39):Well, blast. The C++ version of repository.sh takes the time from 30sec to <10sec on Linux, but takes it from 40sec to 90sec on FreeBSD. What on earth...
Sean (May 14 2020 at 04:53):run it through perf. haven't looked, but I'd blindly guess you're copying copies of copies of strings, or making copies of containers. latest gcc tries harder to hide it, it's a common mistake, and is pretty good at deferring with copy-on-write but that causes that kind of performance disparity. could also simply be some buffer not tuned right that is stalling out.
starseeker (May 14 2020 at 05:01):Looks like it was either the regex statements or something related to them - latest update gets it down from 90 seconds to under 10 on bz
Sean (May 14 2020 at 05:14):hm. then it might be disk caching. are you scanning over the filesystem multiple times? should take care to only scan once or twice.
Last updated: Oct 09 2024 at 00:44 UTC