Copying tcl-core on this as well:
On 04/07/2017 02:25 PM, Serg G. Brester wrote:
>> Thanks for the reminder (just too many tasks)!> Nop, I think, we don't need a TIP as long as it is not realy an > enhancement (besides the little incompatibilities, which belong rather > to bug fixing resp. some artifical cases).> I hoped for some feadback from TCT (or/and from flightaware;), but > excepting pair colleagues I got nothing up to now from there.> Inbetween I had found a small "bug" there, that is already fixed (must > be rebased in fossil).> And I've tested it on some systems of me using tcl (where it looks > very good all the time).>> So I'll try to make a back-porting to 8.6 the next week (should be > relative easy, because I almost alone dare to change there > something;), and then to start CFV survey for ca. two weeks for both > 8.6 and trunk branches (I hope one or the other is accepted, or I'm > listening some agruments against, that I can then "fix").>> —> You are receiving this because you were mentioned.> Reply to this email directly, view it on GitHub > <https://github.com/flightaware/Tcl-bounties/issues/4#issuecomment-292614764>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AANPUYJBdJqeY1VEu2mWggcT8p49fvzrks5rtn-PgaJpZM4K2cWi>.>
I don't recall ever getting answers to several questions that I asked.
It could be that there were technological issues that kept us from
making contact.
(1) Are you willing to maintain the code moving forward? (If not, I need
more time to review. Things have been very busy for the last few months,
and I've not had time to source-dive in your separate branches.
(2) What, if any, existing test cases needed to be modified to support
your performance improvements, and why? (If they were there simply for
'bugward compatibility', that's an acceptable answer. I recognize that
some of the Tcl test cases have historically not been tests, but rather
experiments.
(3) Does the code continue to support multilocalization (having places
in the same process or in the same interpreter where different time
zones or locales are in use)?
(4) Is the claimed speedup achievable without also addressing the msgcat
subsystem, or were speedups there also in scope?
(5) Is the new code still self-contained, or does it rely on third-party
libraries that are subject to licensing that must be reviewed?
(6) Has the new code been run with the test suite under a profiler such
as gcov (or nagelfar for any portions that are still written in Tcl)?
What fraction of the code remains uncovered?
If all of these questions have acceptable answers, then I don't think
there's any need for a vote. I speak both as a TCTer and as the
maintainer of record for [clock]. We just need to get you commit access
for (1) - I can do that if you agree - and then get everything merged
in. I presume documentation changes should be minimal, just the new %Es
plus documenting any other new functionality needed. If it's a drop-in
replacement that passes the test suite, I don't have a problem with it
appearing in a point release.
If you haven't merged recently, you'll also find that I added ensemble
compilation for [clock] (and for [encoding] which was also missing it).
In addition, I added bytecoding for [clock
seconds/millis/micros/clicks], which should be an additional little
boost. I just dropped those into core-8-6-branch as well as trunk, and
nobody objected.
Thanks for taking this on! I'd been meaning to do the rewrite in C
(which for me would have been relatively straightforward but
time-consuming) for years, but always had other fish to fry. Doing the
initial implementation in C would have got me horribly bogged down, so I
still think that proving the concept in Tcl first was a good idea, but
somehow, the Tcl implementation always remained Almost Good Enough and
the performance hacking never got enough attention.
-- 73 de ke9tv/2, Kevin
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core