Quantcast

Re: [flightaware/Tcl-bounties] Intent to work on speedups to `clock format` and `clock scan` (#4)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [flightaware/Tcl-bounties] Intent to work on speedups to `clock format` and `clock scan` (#4)

Kevin Kenny-2
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [flightaware/Tcl-bounties] Intent to work on speedups to `clock format` and `clock scan` (#4)

Dipl. Ing. Sergey G. Brester

No time currently to answer detailed, so firstly I'll try to summarize as short answer...

1) Yes

2) All the test-cases modifications, that I done, going to bug-fixing (IMHO) and to cover new functionality (like "-now" by "clock format -now -format ...").

3) Yes (otherwise several test-cases will fail)

4) There was also in scope (no chances to get reasonable performance-increase without optimization of msgcat-clock binding).

5) Yes. It is only my own code (licensed as TCL self).

6) Yes, almost nothing uncovered (only pair code blocks serves debugging purposes).

As regards of ensemble compilation for [clock], I've seen it (you've made it for commands like seconds, microseconds, etc.), but I've another branch, where ALL ensembles will be compiled (using rewritten much faster version of INST_INVOKE_REPLACE), see https://github.com/flightaware/Tcl-bounties/issues/21#issuecomment-270655556.
I'll try to rebase it into fossil.

Regards,
sebres

08.04.2017 04:46, Kevin Kenny wrote:

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.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [flightaware/Tcl-bounties] Intent to work on speedups to `clock format` and `clock scan` (#4)

Kevin Kenny-6
On Mon, Apr 10, 2017 at 6:58 AM, Dipl. Ing. Sergey G. Brester <[hidden email]> wrote:

No time currently to answer detailed, so firstly I'll try to summarize as short answer...

1) Yes

2) All the test-cases modifications, that I done, going to bug-fixing (IMHO) and to cover new functionality (like "-now" by "clock format -now -format ...").

3) Yes (otherwise several test-cases will fail)

4) There was also in scope (no chances to get reasonable performance-increase without optimization of msgcat-clock binding).

5) Yes. It is only my own code (licensed as TCL self).

6) Yes, almost nothing uncovered (only pair code blocks serves debugging purposes).

Those are almost the right answers for "goes in without a TIP." The only thorny one is the "new functionality" part. Do you have a description of the new functionality in one place, that we could use as the skeleton of a TIP? 

I'm willing to bend the rules if the new functionality cannot readily be separated from the other improvements. If it can, the logical thing to do would be to get the performance upgrades into 8.6.x (no TIP needed) and the new stuff onto the 8.7 development line (TIP likely non-controversial, provided that it makes sense).



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [flightaware/Tcl-bounties] Intent to work on speedups to `clock format` and `clock scan` (#4)

Dipl. Ing. Sergey G. Brester

>  Do you have a description of the new functionality in one place, that we could use as the skeleton of a TIP?

Yes, this [RFE](http://core.tcl.tk/tcl/info/ddc948cff9781daa) describes that. There are only:
- freescan: relative date with ordinal month and relative weekday (early it was rather undefined behavior).
- I've introduced an optional tokens, for example zone (`%z` resp. `%Z`) is optional now (can be switched off);
- additionally scan/format token `%Es` introduced to parse or format local seconds (in opposition to `%s` for posix seconds);
- value `-now` will be accepted as clock value for format or add functions, e. g.:
```
clock format -now -f %u;
```

I don't think that this minimal "enhancements" would block the release it in 8.6.

> the new functionality cannot readily be separated from the other

Some things are just per design, thus not really separable (e. g. decision rules are logic-based now, no more priority-based, see ticket [e7a722cd35](http://core.tcl.tk/tcl/tktview?name=e7a722cd35) ).

But I thinks, this can be classified rather as "bugs", not as "enhancements".

Regards,
sebres.

 

Am 10.04.2017 20:20, schrieb Kevin Kenny:

On Mon, Apr 10, 2017 at 6:58 AM, Dipl. Ing. Sergey G. Brester <[hidden email]> wrote:

No time currently to answer detailed, so firstly I'll try to summarize as short answer...

1) Yes

2) All the test-cases modifications, that I done, going to bug-fixing (IMHO) and to cover new functionality (like "-now" by "clock format -now -format ...").

3) Yes (otherwise several test-cases will fail)

4) There was also in scope (no chances to get reasonable performance-increase without optimization of msgcat-clock binding).

5) Yes. It is only my own code (licensed as TCL self).

6) Yes, almost nothing uncovered (only pair code blocks serves debugging purposes).

Those are almost the right answers for "goes in without a TIP." The only thorny one is the "new functionality" part. Do you have a description of the new functionality in one place, that we could use as the skeleton of a TIP? 

I'm willing to bend the rules if the new functionality cannot readily be separated from the other improvements. If it can, the logical thing to do would be to get the performance upgrades into 8.6.x (no TIP needed) and the new stuff onto the 8.7 development line (TIP likely non-controversial, provided that it makes sense).



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [flightaware/Tcl-bounties] Intent to work on speedups to `clock format` and `clock scan` (#4)

Dipl. Ing. Sergey G. Brester

I'm done.

Because I was already multiple times asked by flightaware (Peter and indirectly Karl) about the subject, and because I would like to save my own time (there are too long implemented and already in fossil, so I've to invest the time again in again to resolve some conflicts resp. to make it again run capable ;)...

I'll suggest to come to a decision.

If I've correct understood Kevin, we need neither TIP nor CFV for it.
Just until now I had very few feedback (except Kevin, Harald and Jan) about this.

  RFE: [ddc948cff9]

  Branch for 8.6: sebres-8-6-clock-speedup.

  Branch for trunk: sebres-clock-speedup (with resolved conflicts between 8.6/trunk)

I would like to suggest "1495810800 - Fri May 26 12:00:00 GMT 2017" for the merge time-point.

Any comments, objections and suggestions are welcome anytime.
Of course I am also available, if someone needs help by the review or e. g. possible troubles by merging in some branch, etc.

Regards,
sebres.

 

Am 10.04.2017 21:20, schrieb Dipl. Ing. Sergey G. Brester:

>  Do you have a description of the new functionality in one place, that we could use as the skeleton of a TIP?

Yes, this [RFE](http://core.tcl.tk/tcl/info/ddc948cff9781daa) describes that. There are only:
- freescan: relative date with ordinal month and relative weekday (early it was rather undefined behavior).
- I've introduced an optional tokens, for example zone (`%z` resp. `%Z`) is optional now (can be switched off);
- additionally scan/format token `%Es` introduced to parse or format local seconds (in opposition to `%s` for posix seconds);
- value `-now` will be accepted as clock value for format or add functions, e. g.:
```
clock format -now -f %u;
```

I don't think that this minimal "enhancements" would block the release it in 8.6.

> the new functionality cannot readily be separated from the other

Some things are just per design, thus not really separable (e. g. decision rules are logic-based now, no more priority-based, see ticket [e7a722cd35](http://core.tcl.tk/tcl/tktview?name=e7a722cd35) ).

But I thinks, this can be classified rather as "bugs", not as "enhancements".

Regards,
sebres.

 

Am 10.04.2017 20:20, schrieb Kevin Kenny:

On Mon, Apr 10, 2017 at 6:58 AM, Dipl. Ing. Sergey G. Brester <[hidden email]> wrote:

No time currently to answer detailed, so firstly I'll try to summarize as short answer...

1) Yes

2) All the test-cases modifications, that I done, going to bug-fixing (IMHO) and to cover new functionality (like "-now" by "clock format -now -format ...").

3) Yes (otherwise several test-cases will fail)

4) There was also in scope (no chances to get reasonable performance-increase without optimization of msgcat-clock binding).

5) Yes. It is only my own code (licensed as TCL self).

6) Yes, almost nothing uncovered (only pair code blocks serves debugging purposes).

Those are almost the right answers for "goes in without a TIP." The only thorny one is the "new functionality" part. Do you have a description of the new functionality in one place, that we could use as the skeleton of a TIP? 

I'm willing to bend the rules if the new functionality cannot readily be separated from the other improvements. If it can, the logical thing to do would be to get the performance upgrades into 8.6.x (no TIP needed) and the new stuff onto the 8.7 development line (TIP likely non-controversial, provided that it makes sense).



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [flightaware/Tcl-bounties] Intent to work on speedups to `clock format` and `clock scan` (#4)

Harald Oehlmann
Am 12.05.2017 um 13:45 schrieb Dipl. Ing. Sergey G. Brester:

> I'm done.
>
> Because I was already multiple times asked by flightaware (Peter and
> indirectly Karl) about the subject, and because I would like to save my
> own time (there are too long implemented and already in fossil, so I've
> to invest the time again in again to resolve some conflicts resp. to
> make it again run capable ;)...
>
> I'll suggest to come to a decision.
>
> If I've correct understood Kevin, we need neither TIP nor CFV for it.
> Just until now I had very few feedback (except Kevin, Harald and Jan)
> about this.
>
>   RFE: [ddc948cff9] <http://core.tcl.tk/tcl/tktview?name=ddc948cff9>
>
>   Branch for 8.6: sebres-8-6-clock-speedup
> <http://core.tcl.tk/tcl/timeline?r=sebres-8-6-clock-speedup>.
>
>   Branch for trunk: sebres-clock-speedup
> <http://core.tcl.tk/tcl/timeline?r=sebres-clock-speedup> (with resolved
> conflicts between 8.6/trunk)
>
> I would like to suggest "1495810800 - Fri May 26 12:00:00 GMT 2017" for
> the merge time-point.
>
> Any comments, objections and suggestions are welcome anytime.
> Of course I am also available, if someone needs help by the review or e.
> g. possible troubles by merging in some branch, etc.
>
> Regards,
> sebres.
>
>  
>
> Am 10.04.2017 21:20, schrieb Dipl. Ing. Sergey G. Brester:
>
>> >  Do you have a description of the new functionality in one place,
>> that we could use as the skeleton of a TIP?
>>
>> Yes, this [RFE](http://core.tcl.tk/tcl/info/ddc948cff9781daa)
>> describes that. There are only:
>> - freescan: relative date with ordinal month and relative weekday
>> (early it was rather undefined behavior).
>> - I've introduced an optional tokens, for example zone (`%z` resp.
>> `%Z`) is optional now (can be switched off);
>> - additionally scan/format token `%Es` introduced to parse or format
>> local seconds (in opposition to `%s` for posix seconds);
>> - value `-now` will be accepted as clock value for format or add
>> functions, e. g.:
>> ```
>> clock format -now -f %u;
>> ```
>>
>> I don't think that this minimal "enhancements" would block the release
>> it in 8.6.
>>
>> > the new functionality cannot readily be separated from the other
>>
>> Some things are just per design, thus not really separable (e. g.
>> decision rules are logic-based now, no more priority-based, see ticket
>> [e7a722cd35](http://core.tcl.tk/tcl/tktview?name=e7a722cd35) ).
>>
>> But I thinks, this can be classified rather as "bugs", not as
>> "enhancements".

Sergey,

Congratulations to this big step to get clock to C and thus speed it up
by a magnitude. This will for sure have a big benefit to everybody !

I would appreciate to merge this!

I also admit that your skills are higly above mine so the changes look
great but far from evident. Eventually someone may comment on the
mergability in the next days.

Thank you,
Harald

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [flightaware/Tcl-bounties] Intent to work on speedups to `clock format` and `clock scan` (#4)

Donald G Porter-2
In reply to this post by Dipl. Ing. Sergey G. Brester
On 05/12/2017 07:45 AM, Dipl. Ing. Sergey G. Brester wrote:
> Any comments, objections and suggestions are welcome anytime.

I want to take a review pass over this code, but fossil will not
let me.

$ fossil update sebres-clock-speedup
Autosync:  http://dgp@.../tcl/
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 393  received: 494  ip: 50.21.187.75
not found: sebres-clock-speedup

My local clone knows nothing about the sebres-clock-speedup branch,
and `fossil sync` does not change that.

I can only guess that these branches were born private, and somehow
still have enough privacy I'm not allowed to pull them?

Who can help?

--
| Don Porter            Applied and Computational Mathematics Division |
| [hidden email]             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [flightaware/Tcl-bounties] Intent to work on speedups to `clock format` and `clock scan` (#4)

Dipl. Ing. Sergey G. Brester

Hi Don,

Just try another (8.6-th) branch `sebres-8-6-clock-speedup` (that was back-ported, but never private).

The comparison to the trunk may be done via web-interface later (I've resolved conflicts only).

In the meantime, I'll try to reproduce your situation on new fossil clone.

Regards,
Sergey.

Am 15.05.2017 20:11, schrieb Donald G Porter:

On 05/12/2017 07:45 AM, Dipl. Ing. Sergey G. Brester wrote:
Any comments, objections and suggestions are welcome anytime.
I want to take a review pass over this code, but fossil will not
let me.

$ fossil update sebres-clock-speedup
Autosync:  http://dgp@.../tcl/
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 393  received: 494  ip: 50.21.187.75
not found: sebres-clock-speedup

My local clone knows nothing about the sebres-clock-speedup branch,
and `fossil sync` does not change that.

I can only guess that these branches were born private, and somehow
still have enough privacy I'm not allowed to pull them?

Who can help?

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [flightaware/Tcl-bounties] Intent to work on speedups to `clock format` and `clock scan` (#4)

Dipl. Ing. Sergey G. Brester
In reply to this post by Donald G Porter-2

Indeed on fresh-cloned repository I missed this branch also.

Any try to repair (with the same name) are failed.

So I've just created an alias branch "sebres-trunk-clock-speedup" now.

$ fossil checkout sebres-clock-speedup
not found: sebres-clock-speedup

$ fossil checkout sebres-trunk-clock-speedup
OK

$ fossil status
checkout:     f2b00e3ceb2541fc2db28409c501a60116e3c857 2017-05-15 18:35:36 UTC
parent:       0afe69aceb2cf12b4922c93c7951d40918ebf0c7 2017-05-11 21:55:12 UTC
merged-from:  beb29f4251c288ee07bc675ad77b4db4f194d8ce 2017-05-12 19:58:01 UTC
tags:         sebres-trunk-clock-speedup
comment:      merge sebres-8-6-clock-speedup (user: sebres)

Regards,
Sergey.

 

Am 15.05.2017 20:11, schrieb Donald G Porter:

On 05/12/2017 07:45 AM, Dipl. Ing. Sergey G. Brester wrote:
Any comments, objections and suggestions are welcome anytime.
I want to take a review pass over this code, but fossil will not
let me.

$ fossil update sebres-clock-speedup
Autosync:  http://dgp@.../tcl/
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 393  received: 494  ip: 50.21.187.75
not found: sebres-clock-speedup

My local clone knows nothing about the sebres-clock-speedup branch,
and `fossil sync` does not change that.

I can only guess that these branches were born private, and somehow
still have enough privacy I'm not allowed to pull them?

Who can help?

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [flightaware/Tcl-bounties] Intent to work on speedups to `clock format` and `clock scan` (#4)

Donal K. Fellows-2
In reply to this post by Donald G Porter-2
On 15/05/2017 19:11, Donald G Porter wrote:
> My local clone knows nothing about the sebres-clock-speedup branch,
> and `fossil sync` does not change that.

Looks to me like it's named something slightly different. And is two
branches.

   http://core.tcl.tk/tcl/timeline?n=100&r=sebres-trunk-clock-speedup
   http://core.tcl.tk/tcl/timeline?n=100&r=sebres-8-6-clock-speedup

Donal.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core

donal_k_fellows.vcf (241 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [flightaware/Tcl-bounties] Intent to work on speedups to `clock format` and `clock scan` (#4)

Dipl. Ing. Sergey G. Brester
In reply to this post by Dipl. Ing. Sergey G. Brester

So the date 1495810800 is past.

If no objections, I would like to merge the subject into 8.6/trunk on 1496088000 / Mon May 29 20:00:00 GMT 2017.

Regards,
sebres.

--

Am 12.05.2017 13:45, schrieb Dipl. Ing. Sergey G. Brester:

I'm done.

Because I was already multiple times asked by flightaware (Peter and indirectly Karl) about the subject, and because I would like to save my own time (there are too long implemented and already in fossil, so I've to invest the time again in again to resolve some conflicts resp. to make it again run capable ;)...

I'll suggest to come to a decision.

If I've correct understood Kevin, we need neither TIP nor CFV for it.
Just until now I had very few feedback (except Kevin, Harald and Jan) about this.

  RFE: [ddc948cff9]

  Branch for 8.6: sebres-8-6-clock-speedup.

  Branch for trunk: sebres-clock-speedup (with resolved conflicts between 8.6/trunk)

I would like to suggest "1495810800 - Fri May 26 12:00:00 GMT 2017" for the merge time-point.

Any comments, objections and suggestions are welcome anytime.
Of course I am also available, if someone needs help by the review or e. g. possible troubles by merging in some branch, etc.

Regards,
sebres.

 

Am 10.04.2017 21:20, schrieb Dipl. Ing. Sergey G. Brester:

>  Do you have a description of the new functionality in one place, that we could use as the skeleton of a TIP?

Yes, this [RFE](http://core.tcl.tk/tcl/info/ddc948cff9781daa) describes that. There are only:
- freescan: relative date with ordinal month and relative weekday (early it was rather undefined behavior).
- I've introduced an optional tokens, for example zone (`%z` resp. `%Z`) is optional now (can be switched off);
- additionally scan/format token `%Es` introduced to parse or format local seconds (in opposition to `%s` for posix seconds);
- value `-now` will be accepted as clock value for format or add functions, e. g.:
```
clock format -now -f %u;
```

I don't think that this minimal "enhancements" would block the release it in 8.6.

> the new functionality cannot readily be separated from the other

Some things are just per design, thus not really separable (e. g. decision rules are logic-based now, no more priority-based, see ticket [e7a722cd35](http://core.tcl.tk/tcl/tktview?name=e7a722cd35) ).

But I thinks, this can be classified rather as "bugs", not as "enhancements".

Regards,
sebres.

 

Am 10.04.2017 20:20, schrieb Kevin Kenny:

On Mon, Apr 10, 2017 at 6:58 AM, Dipl. Ing. Sergey G. Brester <[hidden email]> wrote:

No time currently to answer detailed, so firstly I'll try to summarize as short answer...

1) Yes

2) All the test-cases modifications, that I done, going to bug-fixing (IMHO) and to cover new functionality (like "-now" by "clock format -now -format ...").

3) Yes (otherwise several test-cases will fail)

4) There was also in scope (no chances to get reasonable performance-increase without optimization of msgcat-clock binding).

5) Yes. It is only my own code (licensed as TCL self).

6) Yes, almost nothing uncovered (only pair code blocks serves debugging purposes).

Those are almost the right answers for "goes in without a TIP." The only thorny one is the "new functionality" part. Do you have a description of the new functionality in one place, that we could use as the skeleton of a TIP? 

I'm willing to bend the rules if the new functionality cannot readily be separated from the other improvements. If it can, the logical thing to do would be to get the performance upgrades into 8.6.x (no TIP needed) and the new stuff onto the 8.7 development line (TIP likely non-controversial, provided that it makes sense).



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Loading...