Re: [TCLCORE] TIP 702 - static linking for registry and dde

[Dipl. I. S. G. B. <se...@us...>]

 

My few cents inlined below. 

20.10.2024 13:26, Jan Nijtmans wrote: 

> 3) Every command should either be included, then no "package require" should be needed. 
> Or it should be a module, activated by "package require". With TIP #702, "dde" and "registry" will be the only modules which are compiled into the Tcl library.

I though the TIP means that it shall only link it statically (quasi to
include binary stuff directly to tcl-core 
instead of zipped VFS library, what is IMHO a mistake), the `package
require` may remain 
(just would do `load {} registry`)...
The suggestion to remove `package require` in TIP is just an option, I
guess.
Or did I understand your objection wrong?

Anyway, IMHO the `package require` shall be retained for both commands
(just a load-rewrite for pkgIndex). 

> 3) Currently, registry.dll is loaded at startup because the new "clock" command needs it.

No. The "clock" command needed that always, also previously. Nothing
changed there, 
just new handling is more "flexible", because allows to load DLL from
uninstalled state (e. g. direct from build-folder),
where previously clock did not find the registry module, and so system
TZ would fallback to :localtime timezone 
(so has wrong TZ-name and cannot get times before posix-epoch) and
system locale would fallback to C
(so may remain english for different real locale in windows).
Just compare 8.6 vs. 8.7+: 

 % clock format [clock seconds]
- Mon Oct 21 17:08:14 +0200 2024
+ Mon Oct 21 17:08:14 CEST 2024
 % clock scan "01/01/1960"
- TIME VALUE TOO LARGE/SMALL TO REPRESENT
+ -315622800
- % set ::tcl::clock::CachedSystemTimeZone
+ :LOCALTIME
- % tcl::unsupported::clock::configure -setup-tz
+ :CET 

Previously it was only possible correct in the test-suite (it has loaded
registry-package explicitly). 

So new handling only disabled this discrepancy... Also it doesn't load
registry on startup
(it is just an auto-load on demand if clock would need registry package,
e. g. need current TZ on window). 

> It would be better to have a native clock subcommand, which reads the timezone
> 
> from the registry, in C, without the need to load registry.dll for doing that.

Partially agree.
The effort is also not so large, and can be also provided as new
"clock::configure" thing.

But if I remember correctly other packages, e. g. msgcat, need it also,
for instance to get system locale. 

So at least it'd be good to have at least 2 new functions: get system
locale and get (and/or setup) system TZ.
Probably platform-independent (so as same commands for windows/*nix). 

Regards,
Serg.