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
68 messages Options
1234
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
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)

Jan Nijtmans-2
2017-05-29 13:46 GMT+02:00 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.

My only concern is this change in the test-suite, mainly test-cases
clock-11.x (x = 1 .. 24)
   <http://core.tcl.tk/tcl/fdiff?v1=a0f5d3e2870da116&v2=9c6421795ab776b3&sbs=1>

Since the current behavior is not documented (I think), I'm sure you have good
reasons for this behavior change, but ... such a change could affect
user-programs
which now give a different behavior than before. Therefore, such a change should
be marked as ** POTENTIONALLY INCOMPATIBLE **, with an explanation
what and why. I think a TIP would have been useful to describe this, even
though it probably would have been accepted anyway.

Could you deliver a little piece of text, describing this behavioral change,
the reason behind it, so Don can put it in the ChangeLog for 8.6.7?
All other changes look OK to me, and are no problem for a patch
release. I don't know if Don and/or Kevin already did a review, it
would be good to be done before release.

I would like to suggest to delay the 8.6.7 release a few weeks
(june 20 or so) so those changes can still be reviewed/tested
by as many people as possible.

Thanks for all your work!
         Jan Nijtmans

------------------------------------------------------------------------------
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 30.05.2017 um 10:30 schrieb Jan Nijtmans:

> 2017-05-29 13:46 GMT+02:00 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.
>
> My only concern is this change in the test-suite, mainly test-cases
> clock-11.x (x = 1 .. 24)
>    <http://core.tcl.tk/tcl/fdiff?v1=a0f5d3e2870da116&v2=9c6421795ab776b3&sbs=1>

In addition, there are many changes to msgcat which all would require a
TIP. I am in contact with Sergey about those points.

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)

Dipl. Ing. Sergey Brester
In reply to this post by Jan Nijtmans-2

Thanks Jan!

As regards the clock-11.x, as I already wrote (see ticket [e7a722cd35]) - this test case was IMHO artificial made (just to pass).

Because if you look with attention to it, you'll see that sometimes wins julian day (%j) and sometimes wins month-day combination (%m%d).

This going to one bug in the previously used precedence-determination routine within "MakeParseCodeFromFields".

I guess the precedence will be retrieved almost "sporadically" (resp. hash-like) if the priority of both rules is the same.

According to `DateParseActions` both "%Y%m%d" and "%Y%j" have the same priority! (but "%Y%m%d" takes place always before "%Y%j"), so in my opinion it should always win. And it does also in the most cases, but unfortunately not always.

It is enough as "little piece of text"? :)

I'll close this ticket now (as fixed).
If we need it for 8.5 also (without new clock-engine), I could repair this bug also in old "MakeParseCodeFromFields"...

 

As regards potential incompatibility: I don't think, that the combination %m%d used together with %j, and if yes, that the julian day in this case does not match day/month.
With other words it does no matter which precedence it does have.

 

Regards,
Sergey.

Am 30.05.2017 10:30, schrieb Jan Nijtmans:

2017-05-29 13:46 GMT+02:00 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.
My only concern is this change in the test-suite, mainly test-cases
clock-11.x (x = 1 .. 24)
   <http://core.tcl.tk/tcl/fdiff?v1=a0f5d3e2870da116&v2=9c6421795ab776b3&sbs=1>

Since the current behavior is not documented (I think), I'm sure you have good
reasons for this behavior change, but ... such a change could affect
user-programs
which now give a different behavior than before. Therefore, such a change should
be marked as ** POTENTIONALLY INCOMPATIBLE **, with an explanation
what and why. I think a TIP would have been useful to describe this, even
though it probably would have been accepted anyway.

Could you deliver a little piece of text, describing this behavioral change,
the reason behind it, so Don can put it in the ChangeLog for 8.6.7?
All other changes look OK to me, and are no problem for a patch
release. I don't know if Don and/or Kevin already did a review, it
would be good to be done before release.

I would like to suggest to delay the 8.6.7 release a few weeks
(june 20 or so) so those changes can still be reviewed/tested
by as many people as possible.

Thanks for all your work!
         Jan Nijtmans

------------------------------------------------------------------------------
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)

Dipl. Ing. Sergey G. Brester
In reply to this post by Jan Nijtmans-2

Thanks Jan!

As regards the clock-11.x, as I already wrote (see ticket [e7a722cd35]) - this test case was IMHO artificial made (just to pass).

Because if you look with attention to it, you'll see that sometimes wins julian day (%j) and sometimes wins month-day combination (%m%d).

This going to one bug in the previously used precedence-determination routine within "MakeParseCodeFromFields".

I guess the precedence will be retrieved almost "sporadically" (resp. hash-like) if the priority of both rules is the same.

According to `DateParseActions` both "%Y%m%d" and "%Y%j" have the same priority! (but "%Y%m%d" takes place always before "%Y%j"), so in my opinion it should always win. And it does also in the most cases, but unfortunately not always.

It is enough as "little piece of text"? :)

I'll close this ticket now (as fixed).
If we need it for 8.5 also (without new clock-engine), I could repair this bug also in old "MakeParseCodeFromFields"...

 

As regards potential incompatibility: I don't think, that the combination %m%d used together with %j, and if yes, that the julian day in this case does not match day/month.
With other words it does no matter which precedence it does have.

Regards,
Sergey.

Am 30.05.2017 10:30, schrieb Jan Nijtmans:

2017-05-29 13:46 GMT+02:00 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.
My only concern is this change in the test-suite, mainly test-cases
clock-11.x (x = 1 .. 24)
   <http://core.tcl.tk/tcl/fdiff?v1=a0f5d3e2870da116&v2=9c6421795ab776b3&sbs=1>

Since the current behavior is not documented (I think), I'm sure you have good
reasons for this behavior change, but ... such a change could affect
user-programs
which now give a different behavior than before. Therefore, such a change should
be marked as ** POTENTIONALLY INCOMPATIBLE **, with an explanation
what and why. I think a TIP would have been useful to describe this, even
though it probably would have been accepted anyway.

Could you deliver a little piece of text, describing this behavioral change,
the reason behind it, so Don can put it in the ChangeLog for 8.6.7?
All other changes look OK to me, and are no problem for a patch
release. I don't know if Don and/or Kevin already did a review, it
would be good to be done before release.

I would like to suggest to delay the 8.6.7 release a few weeks
(june 20 or so) so those changes can still be reviewed/tested
by as many people as possible.

Thanks for all your work!
         Jan Nijtmans

------------------------------------------------------------------------------
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
In reply to this post by Harald Oehlmann
Am 30.05.2017 um 10:51 schrieb Harald Oehlmann:
> In addition, there are many changes to msgcat which all would require a
> TIP. I am in contact with Sergey about those points.

The discussion did not lead to anything fruitful.

The reasons for the changes are much beyond my capabilities:
  -   A caller has an invalid namespace.
  -   There is a highly complex index of an index
  -   It is all due to C. I did not know, that C can not use namespaces,
but anyway, I am out.

So sorry, I am out here.

Anybody with more knowledge may take it.

Sorry for the noise,
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)

Dipl. Ing. Sergey G. Brester
The discussion did not lead to anything fruitful.

I thought we've a conclusion - I want to restore original msgcat and rewrite all the changes into clock.tcl file...

But I'm trying nevertheless to explain it...

There is a highly complex index of an index

I hold many nested dictionaries but also another objects (e. g. StrIdxTreeObj, that are derivational created from locale catalog) in one merged dictionary from the original msgcat-catalog.
 
For locale "en-US" it would be merged for each of {{} en en-us}. The some clock-engine routines (in C) create resp. share/cache there own objects based on the merged-catalog values.
For example see pair ClockMCGetMultiListIdxTree/ClockStrIdxTreeSearch that used for fast search of month, weekday for the given locale etc.

All information needed for the clock scan resp. format, will be retrieved once and cached in this single dictionary.

I did not know, that C can not use namespaces...

Sure it can, but "uplevel 1 [list: namespace current]" expected additionally - it should be wrapped into a "proc" (because of the uplevel).
This costs time (at least), and because of other things (e. g. I need a weak-pointer to merged dict to be returned) so I had either way to rewrite resp. to extend it...

--

Previous discussion (translated):

1) "mcget" returns a merged dict-object (e. g. for the locale list "{} en en-US"), that fulfills the following purposes:

- firstly, it creates a weak reference (smart-pointer to merged catalog dict) for the clock-engine (where it will be cached). Among other things this enables an intermediate storing of clock-internal objects (e. g. compiled representation of StrIdxTreeObj for localized month, week, etc.).

- on the other hand this allows a quick change of locale / TZ, without having the required format/scan objects will be reconstructed every time, for example already mentioned StrIdxTreeObj, but also TZData resp. TZ-offsets by name, etc.)

- the weak- resp. smart-pointer allows you to change this (shared) dict object without creating a copy (and thus, the other older references to previous object have less information, thus avoids the the rebuilding of some objects every time).

- You can see why this feature expected, in this comment by me - Tcl-bounties/issues/4#issuecomment-267103133.

Thus although I cannot really remove this feature, but I can move it to "clock.tcl", if it bothers you.

2) No problem at all, I will do this...

BTW Just to explain why I did it (take a look to the dual overhead):

% set ns tcl::clock; set loc en; dict set PackageConfig locales $ns $loc test
locales {tcl::clock {en test}}
% timerate {if {[catch {set x [dict get $PackageConfig locales $ns $loc]}]} {}}
0.372311 µs/# 2388640 # 2685929 #/sec 889.316 nett-ms
% timerate {if {[dict exists $PackageConfig locales $ns $loc]} {set x [dict get $PackageConfig locales $ns $loc]}}
0.655860 µs/# 1424101 # 1524715 #/sec 934.011 nett-ms

3) msgcat::Merge is just a helper for in P.1 described "mcget" to create merged dict object (for the locale list like "{} en en-US").
If desired, I can also move it to "clock.tcl" (together with "mcget")...

4) the "ns" parameter is required, because the calls to this function take place outside of tcl-proc (this called directly from tcl-core without CallFrame), thus the code "uplevel 1 [list: namespace current]" does not work (or even catch a wrong scope).

5) "mcpackagelocale load" in opposite to "mcpackagelocale set" loads a given locale (in contrast to 'set', he does the same for current default locale of the current namespace). Previously it worked, because the clock scan/format/add had always set a default locale (using "mclocale", resp. EnterLocale). This is now done via a cached-dict (see P.1), thus the setting of locale is not required anymore (or even disturbing, because in addition raise or expects several tcl-proc calls).


As already said, except for P.2 all other points are almost necessary (due to the current realization).
If it still disturbs, I have no problem to rewrite all this into "clock.tcl".
Please tell me if you want it...


As regards P.2, I will make it still today.

Regards,
Sergey.

Am 30.05.2017 09:00, schrieb Harald Oehlmann:

This includes some questions:

1) What is mcget?

If it does only:
namespace eval $ns {
	if { ! [::msgcat::mcpackagelocale present $lo]} {
		set lotemp [::msgcat::mcpackagelocale get]
		::msgcat::mcpackagelocale set $lo
		::msgcat::mcpackagelocale set $lotmp
	}
}

If that's the case, I beg you, to remove the function and to replace the calls by the above-mentioned function.

2) I'm asking you to replace all calls like:
	if {[catch {set d [dict get $b c]} ]} {set d $e}
with:
	if {[dict exists $b c]} {set d [dict get $b c]} ]} else {set d $e}

Otherwise it can unnecessarily overwrite ::errorMessage. This should happen in a core modules only by the real errors.

3) What does the function msgcat::Merge ?

If this is an optimization, then please get out from msgcat. You can find out with the callback, when mcset executed.

4) What's the new parameter "ns" in "mcpackagelocale {subcommand {locale
""} {ns ""}" ?

If this is an optimization, please replace with
eval $ns {mcpackagelocale {subcommand {locale ""}}

5) What does "mcpackagelocale load"?

Ich vermute:
set lotemp [::msgcat::mcpackagelocale get]
::msgcat::mcpackagelocale set $lo
::msgcat::mcpackagelocale set $lotmp

Wenn das so ist, bitte entfernen.

I've read nothing about changes in msgcat.
All the above-mentioned things require a TIP.


Am 30.05.2017 12:15, schrieb Harald Oehlmann:

Am 30.05.2017 um 10:51 schrieb Harald Oehlmann:
In addition, there are many changes to msgcat which all would require a TIP. I am in contact with Sergey about those points.
The discussion did not lead to anything fruitful.

The reasons for the changes are much beyond my capabilities:
  -   A caller has an invalid namespace.
  -   There is a highly complex index of an index
  -   It is all due to C. I did not know, that C can not use namespaces,
but anyway, I am out.

So sorry, I am out here.

Anybody with more knowledge may take it.

Sorry for the noise,
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

------------------------------------------------------------------------------
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've reverted msgcat to previous state, the merged msgcat-logic ("mcget", etc.) entirely moved now to "clock.tcl".

Additionally it saves the interpreter-state by avoidance of the usage of "catch" (uses pair "dict exists/dict get" instead of "catch").

See [67aa09246b813053].

I'll merge it into trunk later.

Regards,
sebres.

 

Am 30.05.2017 13:50, schrieb Dipl. Ing. Sergey G. Brester:

The discussion did not lead to anything fruitful.

I thought we've a conclusion - I want to restore original msgcat and rewrite all the changes into clock.tcl file...

But I'm trying nevertheless to explain it...

There is a highly complex index of an index

I hold many nested dictionaries but also another objects (e. g. StrIdxTreeObj, that are derivational created from locale catalog) in one merged dictionary from the original msgcat-catalog.
 
For locale "en-US" it would be merged for each of {{} en en-us}. The some clock-engine routines (in C) create resp. share/cache there own objects based on the merged-catalog values.
For example see pair ClockMCGetMultiListIdxTree/ClockStrIdxTreeSearch that used for fast search of month, weekday for the given locale etc.

All information needed for the clock scan resp. format, will be retrieved once and cached in this single dictionary.

I did not know, that C can not use namespaces...

Sure it can, but "uplevel 1 [list: namespace current]" expected additionally - it should be wrapped into a "proc" (because of the uplevel).
This costs time (at least), and because of other things (e. g. I need a weak-pointer to merged dict to be returned) so I had either way to rewrite resp. to extend it...

--

Previous discussion (translated):

1) "mcget" returns a merged dict-object (e. g. for the locale list "{} en en-US"), that fulfills the following purposes:

- firstly, it creates a weak reference (smart-pointer to merged catalog dict) for the clock-engine (where it will be cached). Among other things this enables an intermediate storing of clock-internal objects (e. g. compiled representation of StrIdxTreeObj for localized month, week, etc.).

- on the other hand this allows a quick change of locale / TZ, without having the required format/scan objects will be reconstructed every time, for example already mentioned StrIdxTreeObj, but also TZData resp. TZ-offsets by name, etc.)

- the weak- resp. smart-pointer allows you to change this (shared) dict object without creating a copy (and thus, the other older references to previous object have less information, thus avoids the the rebuilding of some objects every time).

- You can see why this feature expected, in this comment by me - Tcl-bounties/issues/4#issuecomment-267103133.

Thus although I cannot really remove this feature, but I can move it to "clock.tcl", if it bothers you.

2) No problem at all, I will do this...

BTW Just to explain why I did it (take a look to the dual overhead):

% set ns tcl::clock; set loc en; dict set PackageConfig locales $ns $loc test
locales {tcl::clock {en test}}
% timerate {if {[catch {set x [dict get $PackageConfig locales $ns $loc]}]} {}}
0.372311 µs/# 2388640 # 2685929 #/sec 889.316 nett-ms
% timerate {if {[dict exists $PackageConfig locales $ns $loc]} {set x [dict get $PackageConfig locales $ns $loc]}}
0.655860 µs/# 1424101 # 1524715 #/sec 934.011 nett-ms

3) msgcat::Merge is just a helper for in P.1 described "mcget" to create merged dict object (for the locale list like "{} en en-US").
If desired, I can also move it to "clock.tcl" (together with "mcget")...

4) the "ns" parameter is required, because the calls to this function take place outside of tcl-proc (this called directly from tcl-core without CallFrame), thus the code "uplevel 1 [list: namespace current]" does not work (or even catch a wrong scope).

5) "mcpackagelocale load" in opposite to "mcpackagelocale set" loads a given locale (in contrast to 'set', he does the same for current default locale of the current namespace). Previously it worked, because the clock scan/format/add had always set a default locale (using "mclocale", resp. EnterLocale). This is now done via a cached-dict (see P.1), thus the setting of locale is not required anymore (or even disturbing, because in addition raise or expects several tcl-proc calls).


As already said, except for P.2 all other points are almost necessary (due to the current realization).
If it still disturbs, I have no problem to rewrite all this into "clock.tcl".
Please tell me if you want it...


As regards P.2, I will make it still today.

Regards,
Sergey.

Am 30.05.2017 09:00, schrieb Harald Oehlmann:

This includes some questions:

1) What is mcget?

If it does only:
namespace eval $ns {
	if { ! [::msgcat::mcpackagelocale present $lo]} {
		set lotemp [::msgcat::mcpackagelocale get]
		::msgcat::mcpackagelocale set $lo
		::msgcat::mcpackagelocale set $lotmp
	}
}

If that's the case, I beg you, to remove the function and to replace the calls by the above-mentioned function.

2) I'm asking you to replace all calls like:
	if {[catch {set d [dict get $b c]} ]} {set d $e}
with:
	if {[dict exists $b c]} {set d [dict get $b c]} ]} else {set d $e}

Otherwise it can unnecessarily overwrite ::errorMessage. This should happen in a core modules only by the real errors.

3) What does the function msgcat::Merge ?

If this is an optimization, then please get out from msgcat. You can find out with the callback, when mcset executed.

4) What's the new parameter "ns" in "mcpackagelocale {subcommand {locale
""} {ns ""}" ?

If this is an optimization, please replace with
eval $ns {mcpackagelocale {subcommand {locale ""}}

5) What does "mcpackagelocale load"?

Ich vermute:
set lotemp [::msgcat::mcpackagelocale get]
::msgcat::mcpackagelocale set $lo
::msgcat::mcpackagelocale set $lotmp

Wenn das so ist, bitte entfernen.

I've read nothing about changes in msgcat.
All the above-mentioned things require a TIP.


Am 30.05.2017 12:15, schrieb Harald Oehlmann:

Am 30.05.2017 um 10:51 schrieb Harald Oehlmann:
In addition, there are many changes to msgcat which all would require a TIP. I am in contact with Sergey about those points.
The discussion did not lead to anything fruitful.

The reasons for the changes are much beyond my capabilities:
  -   A caller has an invalid namespace.
  -   There is a highly complex index of an index
  -   It is all due to C. I did not know, that C can not use namespaces,
but anyway, I am out.

So sorry, I am out here.

Anybody with more knowledge may take it.

Sorry for the noise,
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

------------------------------------------------------------------------------
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 Jan Nijtmans-2

I've seen currently you have removed "timerate" among other things, thus a pair questions:

1. I've several performance test-cases to cover clock-speedup;

2. How you want to test resp. cover the performance increase now (and possible future regressions)?

3. As regards removing in "reg/pkgIndex.tcl", (which are supposedly unrelated to clock functionality) - you are wrong here, the changes in reg-module are expected for the proper test running if under windows (namelly timezone "system").

4. If it expected a TIP, no problem - but why it can not be a part of core-8-6-branch (at least the TIP not completely rejected)? I mean it can be always easy removed from release / release candidate branch...

Another thing would be "#ifdef TCL_TIMERATE ... #endif".

BTW. I've several other branches based on it (expected "timerate" to cover performance), therefore all this are disadvantaged after your changeset.

Too bad in my opinion... In deep mourning :(

Regards,
sebres.

 


------------------------------------------------------------------------------
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

Thanks! Danke! Спасибо! ¡Gracias!


except: the "timerate" command and the clock performance-tests are kept

BTW. What do you think about the idea with "#ifdef TCL_TIMERATE" for 8.6-th branch? Pleeeaaase...


------------------------------------------------------------------------------
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
1234
Loading...