tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] www.tcl.tk is down

[Arjen M. <Arj...@de...>]

I just tried - it is up again.

Regards,

Arjen

-----Original Message-----
From: Andreas Kupries <and...@gm...>
Sent: Friday, July 19, 2024 9:08 AM
To: Massimo Manghi <mas...@ri...>
Cc: tcl...@li...
Subject: Re: [TCLCORE] http://www.tcl.tk/ is down

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment.


> still not working here, same error

Please try again.

Logging into the machine I found that the web server was not running.
I restarted it now.

>   -- M

--
Happy Tcling,
        Andreas Kupries <and...@gm...>
                        <https://core.tcl-lang.org/akupries/>
                        <https://akupries.tclers.tk/>
        Developer @     SUSE Software Solutions Germany GmbH
-------------------------------------------------------------------------------






_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [TCLCORE] www.tcl.tk is down

[Andreas K. <and...@gm...>]

> still not working here, same error

Please try again.

Logging into the machine I found that the web server was not running.
I restarted it now.

>   -- M

-- 
Happy Tcling,
	Andreas Kupries <and...@gm...>
			<https://core.tcl-lang.org/akupries/>
			<https://akupries.tclers.tk/>
	Developer @	SUSE Software Solutions Germany GmbH
-------------------------------------------------------------------------------

Re: [TCLCORE] Tcl/Tk 9.0b2 RELEASED

[elns <el...@xs...>]

And here are a few warnings when natively compiling Tk9.0b2 for x86_64-linux:

<snip>

gcc -c -I/usr/local/src/SOURCES/tk9.0b2/unix/../unix 
-I/usr/local/src/SOURCES/tk9.0b2/unix/../generic -I/usr/local/src/SOURCES/tk9.0b2/unix/../bitmaps 
-O3  -pipe -m64 -finput-charset=UTF-8  -Wall -Wextra -Wshadow -Wundef -Wwrite-strings 
-Wpointer-arith -Wc++-compat -fextended-identifiers -fPIC -fno-common -DBUILD_tk 
-I/usr/local/src/SOURCES/tcl9.0b2/generic -I/usr/local/src/SOURCES/tcl9.0b2/unix 
-DPACKAGE_NAME=\"tk\" -DPACKAGE_TARNAME=\"tk\" -DPACKAGE_VERSION=\"9.0\" -DPACKAGE_STRING=\"tk\ 
9.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DTCL_CFGVAL_ENCODING=\"utf-8\" -DSTDC_HEADERS=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DMODULE_SCOPE=extern\ 
__attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DHAVE_HIDDEN=1 -DTCL_CFG_DO64BIT=1 
-DHAVE_CAST_TO_UNION=1 -DHAVE_STDBOOL_H=1 -DHAVE_VFORK=1 -DHAVE_POSIX_SPAWNP=1 
-DHAVE_POSIX_SPAWN_FILE_ACTIONS_ADDDUP2=1 -DHAVE_POSIX_SPAWNATTR_SETFLAGS=1 -DTCL_SHLIB_EXT=\".so\" 
-DNDEBUG=1 -DTCL_CFG_OPTIMIZED=1 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_IS_LONG=1 
-DHAVE_SYS_TIME_H=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DHAVE_PW_GECOS=1 -DHAVE_LIBXFT=1 
-DHAVE_XFT=1 -DZIPFS_BUILD=1      -DTCL_UTF_MAX=4  -DUSE_TCL_STUBS 
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c: In function ‘TkPostscriptImage’:
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1196:37: warning: ‘cdata.blue_mask’ may be 
used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetBValue(rgb) ((rgb & cdata->blue_mask) >> cdata->blue_shift)
                                      ^~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1276:20: note: ‘cdata.blue_mask’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1195:37: warning: ‘cdata.green_mask’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetGValue(rgb) ((rgb & cdata->green_mask) >> cdata->green_shift)
                                      ^~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1276:20: note: ‘cdata.green_mask’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1194:37: warning: ‘cdata.red_mask’ may be 
used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetRValue(rgb) ((rgb & cdata->red_mask) >> cdata->red_shift)
                                      ^~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1276:20: note: ‘cdata.red_mask’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1196:50: warning: ‘cdata.blue_shift’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetBValue(rgb) ((rgb & cdata->blue_mask) >> cdata->blue_shift)
                                                   ^~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1276:20: note: ‘cdata.blue_shift’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1194:49: warning: ‘cdata.red_shift’ may be 
used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetRValue(rgb) ((rgb & cdata->red_mask) >> cdata->red_shift)
                                                  ^~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1276:20: note: ‘cdata.red_shift’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1195:51: warning: ‘cdata.green_shift’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetGValue(rgb) ((rgb & cdata->green_mask) >> cdata->green_shift)
                                                    ^~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1276:20: note: ‘cdata.green_shift’ was 
declared here
      TkColormapData cdata;
                     ^~~~~

<snip>

gcc -c -I/usr/local/src/SOURCES/tk9.0b2/unix/../unix 
-I/usr/local/src/SOURCES/tk9.0b2/unix/../generic -I/usr/local/src/SOURCES/tk9.0b2/unix/../bitmaps 
-O3  -pipe -m64 -finput-charset=UTF-8  -Wall -Wextra -Wshadow -Wundef -Wwrite-strings 
-Wpointer-arith -Wc++-compat -fextended-identifiers -fPIC -fno-common -DBUILD_tk 
-I/usr/local/src/SOURCES/tcl9.0b2/generic -I/usr/local/src/SOURCES/tcl9.0b2/unix 
-DPACKAGE_NAME=\"tk\" -DPACKAGE_TARNAME=\"tk\" -DPACKAGE_VERSION=\"9.0\" -DPACKAGE_STRING=\"tk\ 
9.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DTCL_CFGVAL_ENCODING=\"utf-8\" -DSTDC_HEADERS=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DMODULE_SCOPE=extern\ 
__attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DHAVE_HIDDEN=1 -DTCL_CFG_DO64BIT=1 
-DHAVE_CAST_TO_UNION=1 -DHAVE_STDBOOL_H=1 -DHAVE_VFORK=1 -DHAVE_POSIX_SPAWNP=1 
-DHAVE_POSIX_SPAWN_FILE_ACTIONS_ADDDUP2=1 -DHAVE_POSIX_SPAWNATTR_SETFLAGS=1 -DTCL_SHLIB_EXT=\".so\" 
-DNDEBUG=1 -DTCL_CFG_OPTIMIZED=1 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_IS_LONG=1 
-DHAVE_SYS_TIME_H=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DHAVE_PW_GECOS=1 -DHAVE_LIBXFT=1 
-DHAVE_XFT=1 -DZIPFS_BUILD=1      -DTCL_UTF_MAX=4  -DUSE_TCL_STUBS 
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkTextImage.c
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkTextImage.c: In function ‘EmbImageDisplayProc’:
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkTextImage.c:670:5: warning: ‘imageY’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
      Tk_RedrawImage(image, 0, 0, width, height, dst, imageX, imageY);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Regards,
Erik Leunissen.
--

Re: [TCLCORE] www.tcl.tk is down

[Massimo M. <mas...@ri...>]

still not working here, same error

  -- M

On 7/19/24 05:59, Marc Culler wrote:
> If you go to www.tcl.tk <http://www.tcl.tk>, say to read the Tk 
> documentation, you get a message from
> cloudflare.com <http://cloudflare.com> saying that the web server is down:
> 
>     What happened?
> 
>     The web server is not returning a connection. As a result, the web
>     page is not displaying.
> 
> 
> I don't know who is in charge of that server.  Hopefully they subscribe 
> to this list.
> 
> - Marc
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Tcl/Tk 9.0b2 RELEASED

[elns <el...@xs...>]

When invoking a freshly built Tcl9.0b2 on Linux, I get:

 > tclsh9.0
application-specific initialization failed: Can't find a usable init.tcl in the following directories:
      {} /usr/local/lib/tcl9.0 /usr/local/lib/tcl9.0 /usr/lib/tcl9.0 /usr/local/library /usr/library 
/usr/tcl9.0/library /usr/tcl9.0b1/library /tcl9.0b1/library


Indeed, /usr/local/lib/tcl9.0 was not created in the installation process. Surficial inspection 
revealed one  line in Makefile.in, which is different from previous Tcl releases (and somewhat 
suspicious to me). I changed this line to make it equal to the line in the Makefile.in for tcl8.6.14:

--- Makefile.in.orig	2024-04-24 19:48:01.000000000 +0200
+++ Makefile.in	2024-07-19 08:15:40.000000000 +0200
@@ -999,7 +999,7 @@
  # Installation rules
  #--------------------------------------------------------------------------

-INSTALL_BASE_TARGETS = install-binaries $(INSTALL_LIBRARIES) $(INSTALL_MSGS) $(INSTALL_TZDATA)
+INSTALL_BASE_TARGETS = install-binaries install-libraries install-msgs $(INSTALL_TZDATA)
  INSTALL_DOC_TARGETS = install-doc
  INSTALL_PACKAGE_TARGETS = install-packages
  INSTALL_DEV_TARGETS = install-headers

and all went well after another "configure; make; sudo make install".

Note that I'm not saying that my change is the right fix for the issue; maybe it needs to be fixed 
differently. I'm just indicating what I found remarkable at first glance.

Best regards,
Erik Leunissen.
--

[TCLCORE] www.tcl.tk is down

[Marc C. <cul...@gm...>]

If you go to www.tcl.tk, say to read the Tk documentation, you get a
message from
cloudflare.com saying that the web server is down:

What happened?

The web server is not returning a connection. As a result, the web page is
> not displaying.


I don't know who is in charge of that server.  Hopefully they subscribe to
this list.

- Marc

Re: [TCLCORE] Tcl/Tk 9.0b2 RELEASED

[elns <el...@xs...>]

Two remarks:

A. Build problem
================
I use to building for a x86_64-mingw32 target from a linux host, using a gcc cross compiler. This 
went well for Tcl. For Tk, the build aborted with:

 > /opt/toolchains/x86_64-w64-mingw32/bin/x86_64-w64-mingw32-gcc -std=gnu11 -c -O2 
-fomit-frame-pointer -D_ATL_XP_TARGETING=1 -D__USE_MINGW_ANSI_STDIO=0 -Wall -Wextra -Wshadow -Wundef 
-Wwrite-strings -Wpointer-arith -Wc++-compat -fextended-identifiers 
-I"/usr/local/src/SOURCES/tk9.0b2/generic" -I"/usr/local/src/SOURCES/tk9.0b2/win" 
-I"../../../SOURCES/tk9.0b2/win/../xlib" -I"../../../SOURCES/tk9.0b2/win/../bitmaps" 
-I"/usr/local/src/SOURCES/tcl9.0b2/generic" -I"/usr/local/src/SOURCES/tcl9.0b2/win" -pipe 
-DHAVE_CPUID=1 -finput-charset=UTF-8 -DPACKAGE_NAME=\"tk\" -DPACKAGE_TARNAME=\"tk\" 
-DPACKAGE_VERSION=\"9.0\" -DPACKAGE_STRING=\"tk\ 9.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" 
-DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
-DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 
-DMODULE_SCOPE=extern -DTCL_CFG_DO64BIT=1 -DHAVE_NO_SEH=1 -DHAVE_STDBOOL_H=1 -DHAVE_CAST_TO_UNION=1 
-DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DNDEBUG=1 
-DTCL_CFG_OPTIMIZED=1 -DZIPFS_BUILD=1  -DTCL_UTF_MAX=4 -DUSE_TCL_STUBS -DBUILD_tk -DBUILD_ttk 
"/usr/local/src/SOURCES/tk9.0b2/win/tkWinWm.c" -o tkWinWm.o
In file included from ../../../SOURCES/tk9.0b2/win/../xlib/X11/Xlib.h:44:0,
                  from /usr/local/src/SOURCES/tk9.0b2/win/tkWinPort.h:70,
                  from /usr/local/src/SOURCES/tk9.0b2/generic/tkPort.h:18,
                  from /usr/local/src/SOURCES/tk9.0b2/generic/tkInt.h:19,
                  from /usr/local/src/SOURCES/tk9.0b2/win/tkWinInt.h:18,
                  from /usr/local/src/SOURCES/tk9.0b2/win/tkWinWm.c:16:
/opt/toolchains/mingw-w64-20131228/x86_64-w64-mingw32/include/psdk_inc/intrin-impl.h: In function 
‘_BitScanForward64’:
../../../SOURCES/tk9.0b2/win/../xlib/X11/X.h:74:23: warning: shadowed declaration is here [-Wshadow]
  typedef unsigned long Mask;
                        ^
/opt/toolchains/mingw-w64-20131228/x86_64-w64-mingw32/include/psdk_inc/intrin-impl.h: In function 
‘_BitScanReverse64’:
../../../SOURCES/tk9.0b2/win/../xlib/X11/X.h:74:23: warning: shadowed declaration is here [-Wshadow]
/opt/toolchains/mingw-w64-20131228/x86_64-w64-mingw32/include/psdk_inc/intrin-impl.h: In function 
‘_BitScanForward’:
../../../SOURCES/tk9.0b2/win/../xlib/X11/X.h:74:23: warning: shadowed declaration is here [-Wshadow]
/opt/toolchains/mingw-w64-20131228/x86_64-w64-mingw32/include/psdk_inc/intrin-impl.h: In function 
‘_BitScanReverse’:
../../../SOURCES/tk9.0b2/win/../xlib/X11/X.h:74:23: warning: shadowed declaration is here [-Wshadow]
/usr/local/src/SOURCES/tk9.0b2/win/tkWinWm.c: In function ‘UpdateWrapper’:
/usr/local/src/SOURCES/tk9.0b2/win/tkWinWm.c:2201:5: warning: implicit declaration of function 
‘ChangeWindowMessageFilter’ [-Wimplicit-function-declaration]
      ChangeWindowMessageFilter(TaskbarButtonCreatedMessageId, MSGFLT_ADD);
      ^
/usr/local/src/SOURCES/tk9.0b2/win/tkWinWm.c:2201:62: error: ‘MSGFLT_ADD’ undeclared (first use in 
this function)
      ChangeWindowMessageFilter(TaskbarButtonCreatedMessageId, MSGFLT_ADD);
                                                               ^
/usr/local/src/SOURCES/tk9.0b2/win/tkWinWm.c:2201:62: note: each undeclared identifier is reported 
only once for each function it appears in
make: *** [/usr/local/src/BUILD/x86_64-mingw32/tk9.0b2/Makefile:812: tkWinWm.o] Error 1


B. Typo
=======
In the announcement text below, referring to a 9.0b1 release, when actually announcing a 9.0b2 
release. Marked by me with "typo".

Regards,
Erik Leunissen
--


> May 20, 2024
> 
> The Tcl Core Team is pleased to announce the 9.0b2 releases of the Tcl
> dynamic language and the Tk graphical interface package.  These are the
> second beta releases of Tcl 9.0 and Tk 9.0.  More details can be found below.
> 
> We would like to express our gratitude to all those who submit bug
> reports and patches.  This information is invaluable in enabling us
> to identify and eliminate problems in the core. Such reports can be
> submitted here.
> 
>          https://core.tcl-lang.org/tcl/ticket
>          https://core.tcl-lang.org/tk/ticket
> 
> We ask that you log in (anonymous if you wish) to create tickets.
> This deters abuse of the ticketing system:
> 
>          https://core.tcl-lang.org/tcl/login
>          https://core.tcl-lang.org/tcl/login
> 
> Where to get the new releases:
> ------------------------------
> 
> Tcl/Tk 9.0b1 sources are freely available as open source from the Tcl          <===== typo
> SourceForge project's file distribution area:
> 
>          https://sourceforge.net/projects/tcl/files/
> 
> This distribution is source code only.  We keep links to some third
> parties offering pre-built binaries for various systems here:
> 
>          https://www.tcl-lang.org/software/tcltk/bindist.html
> 
> General Summary
> ---------------
> 
> These are new major versions of both Tcl and Tk.  There are new features
> to be enjoyed.  There are incompatibilities to be considered.  The list
> of both is long and detailed and not fully included here.  We believe many
> scripts written for Tcl 8 will run unchanged in Tcl 9.  We believe many more
> can be modified in small and simple ways to produce a new script that runs
> in both Tcl 8 and Tcl 9.  We expect that extensions and applications using
> the public C APIs of Tcl and Tk will involve more effort, but that it is
> still within reasonable reach to produce source code supporting both Tcl 8
> and Tcl 9 while both releases remain in widespread use.
> 
> These are beta releases.  The developers believe the new feature set is
> complete enough and the code quality is high enough that it is time for
> a larger audience of Tcl/Tk users to give them a try and report back
> to the developers what difficulties need resolution before stable
> releases of Tcl/Tk 9.0.0.
> 
> The experiences of Tcl/Tk 8 users adapting their code to the beta releases
> of Tcl/Tk 9 will shape the final interfaces of Tcl/Tk 9.0.0, and will
> determine the need for possible Tcl/Tk 8.7 releases that might supply
> additional lifecycle and migration support.
> 
> It is not recommended to deploy these beta releases directly to mission
> critical use without significant testing and review.
> 
> Tcl Changes Summary
> -------------------
> 
> The source code for Tcl is managed by fossil.  Tcl developers coordinate all
> changes to the Tcl source code at
> 
>  > [Tcl Source Code](https://core.tcl-lang.org/tcl/timeline)
> 
> Release Tcl 9.0b2 arises from the check-in with tag core-9-0-b2.
> 
> Highlighted differences between Tcl 9.0 and Tcl 8.6 are summarized below,
> with focus on changes important to programmers using the Tcl library and
> writing Tcl scripts.
> 
> ## 64-bit capacity: Data values larger than 2Gb
> 
> ## Internationalization of text
>   - Full Unicode range of codepoints
>   - New encodings: utf-16/utf-32/ucs-2(le|be), CESU-8, etc.
>   - `encoding` options -profile, -failindex manage encoding of I/O.
>   - `msgcat` supports custom locale search list
>   - `source` defaults to -encoding utf-8
> 
> ## Zip filesystems and attached archives.
> 
> ## Unix notifiers available using epoll() or kqueue()
>   - relieves limits on file descriptors imposed by legacy select()
> 
> ## Notable incompatibilities
>   - Unqualified varnames resolved in current namespace, not global.
>   - No --disable-threads build option.  Always thread-enabled.
>   - I/O malencoding default response: raise error (-profile strict)
>   - Windows platform needs Windows 7 or Windows Server 2008 R2 or later
>   - Ended interpretation of ~ as home directory in pathnames
>   - Removed the "identity" encoding
>   - $::tcl_precision no longer controls string generation of doubles
>   - Removed Tcl 7 legacies: [case], [puts] [read] variant syntaxes
>   - Removed subcommands [trace variable|vdelete|vinfo]
>   - No -eofchar option for channels anymore for writing.
>   - On Windows 10+ (Version 1903 or higher), system encoding is always utf-8.
> 
> ## Incompatibilities in C public interface
>   - Many arguments expanded type from int to Tcl_Size
>   - Ended support for Tcl_ChannelTypeVersion less than 5
>   - Introduced versioning of the Tcl_ObjType struct
>   - Removed macros CONST*: Tcl 9 support means dropping Tcl 8.3 support
>   - Removed routines:
>  >    Tcl_Backslash(), Tcl_*VA(), Tcl_*MathFunc*(), Tcl_MakeSafe(),
>  >    Tcl_(Save|Restore|Discard|Free)Result(), Tcl_EvalTokens(),
>  >    Tcl_(Get|Set)DefaultEncodingDir(),
>  >    Tcl_UniCharN(case)cmp(), Tcl_UniCharCaseMatch()
> 
> ## New commands
>   - `array default`, `array for`
>   - `coroinject`, `coroprobe`
>   - `clock add weekdays`
>   - `const`, `info const*`
>   - `dict getdefault`
>   - `file tempdir`, `file home`, `file tildeexpand`
>   - `info commandtype`
>   - `ledit`
>   - `lpop`
>   - `lremove`
>   - `lseq`
>   - `package files`
>   - `string insert`, `string is dict`
>   - `tcl::process`
>   - `*::build-info`
> 
> ## New command options
>   - `regsub ... -command ...`
>   - `lsearch ... -stride ...`
>   - `clock scan ... -validate ...`
>   - `socket ... -nodelay ... -keepalive ...`
>   - `vwait` controlled by several new options
> 
> ## Numbers
>   - 0NNN format is no longer octal interpretation. Use 0oNNN.
>   - 0dNNNN format to compel decimal interpretation.
>   - NN_NNN_NNN, underscores in numbers for optional readability
>   - Functions: isinf() isnan() isnormal() issubnormal() isunordered()
>   - `fpclassify`
>   - Function int() no longer truncates to word size
> 
> ## tcl::oo facilities
>   - private variable and methods
>   - `method -export`, `method -unexport`
> 
> Tk Changes Summary
> -------------------
> 
> The source code for Tk is managed by fossil.  Tk developers coordinate all
> changes to the Tk source code at
> 
>  > [Tk Source Code](https://core.tcl-lang.org/tk/)
> 
> Release Tk 9.0b2 arises from the check-in with tag core-9-0-b2.
> 
> Highlighted differences between Tk 9.0 and Tk 8.6 are summarized below,
> with focus on changes important to programmers using the Tk library and
> writing Tcl scripts containing Tk commands.
> 
> ## Many improvements to use of platform features and conventions.
>   - Built-in widgets and themes are scaling-aware.
>   - Improved support of two-finger gestures, where available
>   - The `tk windowingsystem` "aqua" needs macOS 10.10 or later
> 
> ## New commands and options
>   - `tk sysnotify`: access to the OS notifications system
>   - `tk systray`: access to the OS tray facility
>   - `tk print`: access to the OS printing facility
> 
> ## Widget options
>   - New `ttk::progressbar` option: **-text**
>   - `$frame ... -backgroundimage $img -tile $bool`
>   - `$menu id`, `$menu add|insert ... ?$id? ...`
>   - `$image get ... -withalpha ...`
>   - All indices now accept the forms **end**, **end-int**, **int+|-int**
> 
> ## Improved widget appearance
>   - `ttk::notebook` with nondefault tab positions
> 
> ## Images
>   - Partial SVG support
>   - Read/write access to photo image metadata
> 
> Tcl Improvement Proposals (TIPs)
> --------------------------------
> 
> Each new user-visible feature in Tcl or Tk should find its origins in
> a Tcl Improvement Proposal (TIP).  TIPs are published, edited, considered
> and voted in public, and should contain valuable information about how
> a feature came to be the way it is.  See the full collection here:
> 
>      https://tip.tcl-lang.org/
> 
> Additional support resources
> ----------------------------
> 
> See the following links for an accumulation of migration advice:
> 
> https://core.tcl-lang.org/tcl/wiki?name=Migrating+C+extensions+to+Tcl+9
> https://core.tcl-lang.org/tcl/wiki?name=Migrating+scripts+to+Tcl+9
> 
> There has been much progress already porting many known applications,
> extensions, and packages in the Tcl world to compatibility with Tcl/Tk 9:
> 
> https://wiki.tcl-lang.org/page/Apps+confirmed+to+work+with+Tcl+9
> https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9
> 
> For additional information:
> ---------------------------
> 
> Please visit the Tcl Developer Xchange web site:
> 
>          https://www.tcl-lang.org/
> 
> This site contains a variety of information about Tcl/Tk in general, the
> core Tcl and Tk distributions, Tcl development tools, and much more.
> 
> -- 
> Tcl Core Team and Maintainers
> Don Porter, Tcl Core Release Manager
> 

Re: [TCLCORE] Tklib tooltip and msgcat

[<apn...@ya...>]

I see the content displayed in widgets as falling into two categories. To take the example of a dialog,

- Buttons like "Ok", "Cancel" fall into the dialog widget's domain assuming they are not configurable by application. The widget code should then look up these in message catalog using its own namespace.

- The text, tooltips, labels etc. which are all under the application control should be displayed *as passed*. The content is owned by the application and it is the application's responsibility to look them up in the message catalog before passing to the widget.

So in the case of the tooltip, I would argue it is the wrong design to msgcat::mc the tooltip in the first place. It should be up to the application itself to pass locale-dependent text. As a practical matter, when widgets get wrapped through widget adapters a la Snit, I am not sure if you could deduce the namespace at all. 

/Ashok

-----Original Message-----
From: Harald Oehlmann <har...@el...> 
Sent: Wednesday, July 17, 2024 9:35 PM
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] Tklib tooltip and msgcat

The tooltip package uses msgcat since this changelog:

2007-05-18  Jeff Hobbs  <je...@Ac...>
* tooltip.tcl (::tooltip::show): Use late-binding msgcat (lazy 
translation) to support programs that allow on-the-fly l10n changes. 
Requires msgcat package (Tk uses this already). (poser)

It always had this line included, which was executed each time the 
tooltip was shown:

proc ::tooltip::show {w msg {i {}}} {
     ....
     $b.label configure -text [::msgcat::mc $msg] -justify left

This implies that the message catalogue calls had to be in the global 
namespace or in the tooltip namespace.

namespace eval :: {mcset de key value}

This is against the module concept of msgcat and may be seen as a mis-use.

The idea to call on show time is to comply to message catalogue change 
(like a language change) on the fly.

I changed this with tooltip 1.7. I thought, that the message catalogue 
of the caller namespace should be used. So, the caller namespace was 
recorded on tooltip definition:

	set nscaller [uplevel 2 {namespace current}]

and used later for the msgcat call:

	namespace eval $nscaller [list ::msgcat::mc $infotext]

Unfortunately, this does not work for oo methods. Recording the 
namespace for later is not correct. There is more resolution required 
within msgcat.

This led to the following tickets:

https://core.tcl-lang.org/tcl/info/91b3a5bb14e6e8ae
https://core.tcl-lang.org/tklib/info/6e85abae9e49281b

Here are my questions:

- may I merge the solution in the TCL ticket to the main branch?
- Which solution offered in the tklib ticket would be a good idea?

An interested user on clt tried to use the tooltip package from an oo 
method and got processing errors. Even, if you just want to show a 
tooltip, the msgcat processing is in your way.

Thank you for any idea,
Harald

[TCLCORE] Tklib tooltip and msgcat

[Harald O. <har...@el...>]

The tooltip package uses msgcat since this changelog:

2007-05-18  Jeff Hobbs  <je...@Ac...>
* tooltip.tcl (::tooltip::show): Use late-binding msgcat (lazy 
translation) to support programs that allow on-the-fly l10n changes. 
Requires msgcat package (Tk uses this already). (poser)

It always had this line included, which was executed each time the 
tooltip was shown:

proc ::tooltip::show {w msg {i {}}} {
     ....
     $b.label configure -text [::msgcat::mc $msg] -justify left

This implies that the message catalogue calls had to be in the global 
namespace or in the tooltip namespace.

namespace eval :: {mcset de key value}

This is against the module concept of msgcat and may be seen as a mis-use.

The idea to call on show time is to comply to message catalogue change 
(like a language change) on the fly.

I changed this with tooltip 1.7. I thought, that the message catalogue 
of the caller namespace should be used. So, the caller namespace was 
recorded on tooltip definition:

	set nscaller [uplevel 2 {namespace current}]

and used later for the msgcat call:

	namespace eval $nscaller [list ::msgcat::mc $infotext]

Unfortunately, this does not work for oo methods. Recording the 
namespace for later is not correct. There is more resolution required 
within msgcat.

This led to the following tickets:

https://core.tcl-lang.org/tcl/info/91b3a5bb14e6e8ae
https://core.tcl-lang.org/tklib/info/6e85abae9e49281b

Here are my questions:

- may I merge the solution in the TCL ticket to the main branch?
- Which solution offered in the tklib ticket would be a good idea?

An interested user on clt tried to use the tooltip package from an oo 
method and got processing errors. Even, if you just want to show a 
tooltip, the msgcat processing is in your way.

Thank you for any idea,
Harald

Re: [TCLCORE] Possible clock bug in 9.0b3

[Harald O. <har...@el...>]

Great work, Sergey, we really appreciate!
Also thanks for all the other recent fixes and contributions!

Take care,
Harald

Am 16.07.2024 um 22:51 schrieb Andreas Kupries:
> 
>> Yep - it was missing % 7 in the validation check (Sunday may be 7 or 0),
>> thx for notice!
> 
> You are welcome.
> Thanks goes to the writer of the 10.* tests in the mime.test suite.
> 
>> Strange is that I (or many who used tclclockmod with valid mode) never
>> noticed that.
>   
>> Anyway fixed in:
>>
>>   		[55c23b44b5] [4] merge 8.7 (clock: fix validation check for scanned
>> Sunday) (tags: trunk [5], main [6])
>>
>>   		 [8f854a2a24] [7] clock: fix validation check for scanned Sunday
>> (missing % 7 by compare) (tags: core-8-branch [8])
> 
> Thanks. Will update the Tcl 9 checkout tomorrow and then retry.
> 
>> Regards,
>> Serg.
> 

Re: [TCLCORE] Possible clock bug in 9.0b3

[Andreas K. <and...@gm...>]

> Yep - it was missing % 7 in the validation check (Sunday may be 7 or 0),
> thx for notice!

You are welcome.
Thanks goes to the writer of the 10.* tests in the mime.test suite.

> Strange is that I (or many who used tclclockmod with valid mode) never
> noticed that. 
 
> Anyway fixed in: 
> 
>  		[55c23b44b5] [4] merge 8.7 (clock: fix validation check for scanned
> Sunday) (tags: trunk [5], main [6])
> 
>  		 [8f854a2a24] [7] clock: fix validation check for scanned Sunday
> (missing % 7 by compare) (tags: core-8-branch [8])

Thanks. Will update the Tcl 9 checkout tomorrow and then retry.

> Regards,
> Serg. 

-- 
Happy Tcling,
	Andreas Kupries <and...@gm...>
			<https://core.tcl-lang.org/akupries/>
			<https://akupries.tclers.tk/>
	Developer @	SUSE Software Solutions Germany GmbH
-------------------------------------------------------------------------------

Re: [TCLCORE] Possible clock bug in 9.0b3

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

 

Yep - it was missing % 7 in the validation check (Sunday may be 7 or 0),
thx for notice!
Strange is that I (or many who used tclclockmod with valid mode) never
noticed that. 

Anyway fixed in: 

 		[55c23b44b5] [4] merge 8.7 (clock: fix validation check for scanned
Sunday) (tags: trunk [5], main [6])

 		 [8f854a2a24] [7] clock: fix validation check for scanned Sunday
(missing % 7 by compare) (tags: core-8-branch [8])

Regards,
Serg. 

16.07.2024 17:47, Andreas Kupries wrote: 

> My script is
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> puts [info patchlevel]
> foreach {n date} {
> 1 {Sat, 01 Jan 2000 23:59:00}
> 2 {Tue, 29 Feb 2000 21:57:00}
> 3 {Sun, 31 Dec 2000 20:42:00}
> 4 {Mon, 01 Jan 2001 23:59:00}
> 5 {Thu, 28 Feb 2002 21:57:00}
> 6 {Wed, 31 Dec 2003 20:42:00}
> } {
> puts "$date -- [catch {clock scan $date -gmt 1} clock] = $clock"
> }
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> All is ok using 8.6.12
> 
> For 9.0b3 however it fails __just__ for Sunday. If it failed for all I would 
> say that the relevant
> code has to be updated to the clock changes in Tcl 9. However, for just one 
> specific weekday ? That
> looks more like a bug in the new clock stuff to me.
> 
> Given that the issue is with Sunday I wonder if it is an issue with the 
> conversion to a numeric
> code, i.e. Sunday can be start or end of the week, depending.
> 
> % tclsh z.tcl
> 
> 8.6.12
> Sat, 01 Jan 2000 23:59:00 -- 0 = 946771140
> Tue, 29 Feb 2000 21:57:00 -- 0 = 951861420
> Sun, 31 Dec 2000 20:42:00 -- 0 = 978295320
> Mon, 01 Jan 2001 23:59:00 -- 0 = 978393540
> Thu, 28 Feb 2002 21:57:00 -- 0 = 1014933420
> Wed, 31 Dec 2003 20:42:00 -- 0 = 1072903320
> 
> % tclsh9 z.tcl
> 
> 9.0b3
> Sat, 01 Jan 2000 23:59:00 -- 0 = 946771140
> Tue, 29 Feb 2000 21:57:00 -- 0 = 951861420
> Sun, 31 Dec 2000 20:42:00 -- 1 = unable to convert input string: invalid day 
> of week
> Mon, 01 Jan 2001 23:59:00 -- 0 = 978393540
> Thu, 28 Feb 2002 21:57:00 -- 0 = 1014933420
> Wed, 31 Dec 2003 20:42:00 -- 0 = 1072903320
> 
> The original code is from the tcllib `mime.test`, 10.* checking 
> `mime::parsedatetime`.
> 
> -- 
> Happy Tcling,
> Andreas Kupries <and...@gm...>
> <https://core.tcl-lang.org/akupries/ [1]>
> <https://akupries.tclers.tk/ [2]>
> Developer @ SUSE Software Solutions Germany GmbH
> -------------------------------------------------------------------------------
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [3]
 

Links:
------
[1] https://core.tcl-lang.org/akupries/
[2] https://akupries.tclers.tk/
[3] https://lists.sourceforge.net/lists/listinfo/tcl-core
[4] http://mail.sebres.de/tcl/info/55c23b44b5cefcef
[5]
http://mail.sebres.de/tcl/timeline?r=trunk&amp;c=2024-07-16+19%3A18%3A56
[6]
http://mail.sebres.de/tcl/timeline?r=main&amp;c=2024-07-16+19%3A18%3A56
[7] http://mail.sebres.de/tcl/info/8f854a2a24046dd2
[8]
http://mail.sebres.de/tcl/timeline?r=core-8-branch&amp;c=2024-07-16+19%3A17%3A05

Re: [TCLCORE] Possible clock bug in 9.0b3

[Andreas K. <and...@gm...>]

> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> puts [info patchlevel]
> foreach {n date} {
>     1 {Sat, 01 Jan 2000 23:59:00}
>     2 {Tue, 29 Feb 2000 21:57:00}
>     3 {Sun, 31 Dec 2000 20:42:00}
>     4 {Mon, 01 Jan 2001 23:59:00}
>     5 {Thu, 28 Feb 2002 21:57:00}
>     6 {Wed, 31 Dec 2003 20:42:00}
> } {
>     puts "$date -- [catch {clock scan $date -gmt 1} clock] = $clock"

Adding `-validate 0` to the command fixes the issue for 9.0b3.

That adds more evidence that something in the validation mishandles the Sunday.

-- 
Happy Tcling,
	Andreas Kupries <and...@gm...>
			<https://core.tcl-lang.org/akupries/>
			<https://akupries.tclers.tk/>
	Developer @	SUSE Software Solutions Germany GmbH
-------------------------------------------------------------------------------

[TCLCORE] Possible clock bug in 9.0b3

[Andreas K. <and...@gm...>]

My script is

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
puts [info patchlevel]
foreach {n date} {
    1 {Sat, 01 Jan 2000 23:59:00}
    2 {Tue, 29 Feb 2000 21:57:00}
    3 {Sun, 31 Dec 2000 20:42:00}
    4 {Mon, 01 Jan 2001 23:59:00}
    5 {Thu, 28 Feb 2002 21:57:00}
    6 {Wed, 31 Dec 2003 20:42:00}
} {
    puts "$date -- [catch {clock scan $date -gmt 1} clock] = $clock"
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

All is ok using 8.6.12

For 9.0b3 however it fails __just__ for Sunday. If it failed for all I would 
say that the relevant
code has to be updated to the clock changes in Tcl 9. However, for just one 
specific weekday ? That
looks more like a bug in the new clock stuff to me.

Given that the issue is with Sunday I wonder if it is an issue with the 
conversion to a numeric
code, i.e. Sunday can be start or end of the week, depending.

% tclsh z.tcl

8.6.12
Sat, 01 Jan 2000 23:59:00 -- 0 = 946771140
Tue, 29 Feb 2000 21:57:00 -- 0 = 951861420
Sun, 31 Dec 2000 20:42:00 -- 0 = 978295320
Mon, 01 Jan 2001 23:59:00 -- 0 = 978393540
Thu, 28 Feb 2002 21:57:00 -- 0 = 1014933420
Wed, 31 Dec 2003 20:42:00 -- 0 = 1072903320

% tclsh9 z.tcl

9.0b3
Sat, 01 Jan 2000 23:59:00 -- 0 = 946771140
Tue, 29 Feb 2000 21:57:00 -- 0 = 951861420
Sun, 31 Dec 2000 20:42:00 -- 1 = unable to convert input string: invalid day 
of week
Mon, 01 Jan 2001 23:59:00 -- 0 = 978393540
Thu, 28 Feb 2002 21:57:00 -- 0 = 1014933420
Wed, 31 Dec 2003 20:42:00 -- 0 = 1072903320

The original code is from the tcllib `mime.test`, 10.* checking 
`mime::parsedatetime`.

-- 
Happy Tcling,
	Andreas Kupries <and...@gm...>
			<https://core.tcl-lang.org/akupries/>
			<https://akupries.tclers.tk/>
	Developer @	SUSE Software Solutions Germany GmbH
-------------------------------------------------------------------------------

Re: [TCLCORE] support documents update

[Torsten B. <be...@ty...>]

Hi,

thanks for your kind words. The work is especially meant to also help newcomers. I have experienced the same, trying to teach some people Tcl. They often found the manual pages too difficult a read to start with. However, it is not the job of the manual pages to be like a teaching aid, the manual pages are the technical documentation. They are terse and a dry read by nature. We will see how we can link from these pages to more educational material, tutorials and such in the future.

Torsten


> Am 14.07.2024 um 03:59 schrieb nb...@to...:
> 
> after read this，
> I really support this work to became true. as a newbie， we need tcl/tk doc  more readable，more update，more access able. support offline read. thank your all !  
> 
> Enhancing Tcl/Tk Documentation: From nroff to Markdown and further <https://openacs.org/conf2024/info/download/file/openacs-tcltk-2024-manual-pages.pdf> 
> Torsten Berg
> 
> 
> 
> 发自我的手机
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Thanks for OpenACS/TCL/Tk conference

[Patrick M. <dus...@gm...>]

I'd like to say, I think Tcl/Tk is amazing, and in my personal 
experience I've found the community to be welcoming, encouraging, and 
kind. I hope this trend will reverse and the community will grow, and 
Tcl/Tk will find more adoption and popularity in the future, it's very 
underappreciated.

Regards,
- PM

On 14/07/2024 21:01, Neophytos Demetriou wrote:
> My highlights are different from Harald's but I will keep most to myself 
> except for one: Our community is shrinking and personal agendas can 
> exacerbate this issue. Thanks for having us in Vienna.
> 
> - Neophytos
> 
> On Sun, Jul 14, 2024 at 3:17 PM Harald Oehlmann 
> <har...@el... <mailto:har...@el...>> wrote:
> 
>     Dear OpenACS/TCL/tk team members,
> 
>     please allow me to say "thank you" for the great OpenACS/TCL/Tk user
>     conference in Vienna at the University of Economics.
> 
>     It was a great meeting with awesome organisation, speaker with
>     presentations and panels, participants present and on the net.
> 
>     The presentations are here:
>     https://openacs.org/conf2024/info/schedule
>     <https://openacs.org/conf2024/info/schedule>
>     Live recordings will be added soon.
> 
>     My highlights:
>     - TCL/Tk 9 is ready and may be released soon. I was surprised, that the
>     pannel sees even Tk in a better state and ready for release.
>     - TCL and Tk should be continued to be coupled in (major) releases.
>     Package managers like Reinhard from Suse require clear releases to put
>     in common distributions
>     - Any TCL/Tk 9 ready extension should do an official release, as
>     package
>     managers require this (often also for legal reasons). It is not
>     sufficient to have it in a branch.
>     - More reviews on commits on the main branches are seen helpful
>     - Source code management of packages is an issue. A first step would be
>     a list (at tcl-lang.org <http://tcl-lang.org>) of officially
>     supported packages. Not
>     maintained packages should be put at a common place (on chiseal or
>     github).
>     - Markdown documentation is seen as a great step. Semantic
>     documentation
>     may follow as a second step.
>     - JSON with tdom was my personal highlight, as I currently need that
>     (thanks Rolf, for the favour). And it was surprising, that Antonio also
>     spoke about it in his awesome VR talk and other OpenACS people liked
>     it,
>     as it is anyway included in OpenACS.
>     - NaviServer/OpenACS is not well known in the TCL community. An OpenACS
>     instance as a groupware may be helpful to internal organisation like
>     inter-TCT communication. The Naviserver/OpenACS community also found
>     out
>     that more should be done for beginners. Naviserver/OpenACS is very fast
>     and highly secure and ready for business critical applications. The
>     first wish of the panel was to move the source away from CSV to GITHUB
>     and friends.
>     - Some future users were well integrated in the conference and got lots
>     of support.
>     - Tk evolution includes the new text widget (if the bugs are fixed) and
>     an enhanced and compatible canvas, maybe with components from tkpath to
>     feature more coordinate flexibility, anti-aliasing and alpha-channel.
> 
>     Thank you all to make this happen.
> 
>     The next conference (2025) will not take place in Vienna due to
>     internal
>     points. So, a location for 2025 is pending. Thanks for any proposal. It
>     is hard to reach the standard of the WU, so smaller without streaming
>     etc. is also ok.
> 
>     Thanks for anybody, who made this happen: Stefan, Gustaf, Sebastian,
>     Monika and the WU team!
> 
>     Take care,
>     Harald
> 
>     P.S.: I hope, you all got home well. There was a thunderstorm and the
>     airport was close to be closed just after the conference. My train
>     got 2
>     hours delayed but I arrived well in Berlin.
>     _______________________________________________
>     Tcl-Core mailing list
>     Tcl...@li... <mailto:Tcl...@li...>
>     https://lists.sourceforge.net/lists/listinfo/tcl-core
>     <https://lists.sourceforge.net/lists/listinfo/tcl-core>
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Migration tool for Tcl 9

[Andreas K. <and...@gm...>]

> At first glance, I don't think it would be cost-effective (implementation
> time) to add those kind of value checks to the migrate tool. Of course the
> issue with wrong value being produced is a different matter.

As a general note, I have started putting my notes and things up as proper gh 
issues for the
project.

-- 
Happy Tcling,
	Andreas Kupries <and...@gm...>
			<https://core.tcl-lang.org/akupries/>
			<https://akupries.tclers.tk/>
	Developer @	SUSE Software Solutions Germany GmbH
-------------------------------------------------------------------------------

Re: [TCLCORE] Migration tool for Tcl 9

[<apn...@ya...>]

At first glance, I don't think it would be cost-effective (implementation
time) to add those kind of value checks to the migrate tool. Of course the
issue with wrong value being produced is a different matter.

/Ashok

-----Original Message-----
From: Schelte Bron <tc...@tc...> 
Sent: Monday, July 15, 2024 3:26 PM
To: tcl...@li...
Subject: Re: [TCLCORE] Migration tool for Tcl 9

Ashok,

I have code to get the epoch time of the next midnight:

	set midnight [clock scan 24:00:00 -format %T]

This throws an error on Tcl 9.0. But it is not flagged by the migration 
tool. To make it work in Tcl 9, a `-validate 0` option must be added.

With that option added, the command currently produces an incorrect 
result. But that's not an issue with the migration tool. It's a bug in 
the implementation. I have created a ticket for that: 
https://core.tcl-lang.org/tcl/tktview/3ee8f1c2a7


Schelte.



_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Migration tool for Tcl 9

[Schelte B. <tc...@tc...>]

Ashok,

I have code to get the epoch time of the next midnight:

	set midnight [clock scan 24:00:00 -format %T]

This throws an error on Tcl 9.0. But it is not flagged by the migration 
tool. To make it work in Tcl 9, a `-validate 0` option must be added.

With that option added, the command currently produces an incorrect 
result. But that's not an issue with the migration tool. It's a bug in 
the implementation. I have created a ticket for that: 
https://core.tcl-lang.org/tcl/tktview/3ee8f1c2a7


Schelte.

Re: [TCLCORE] Thanks for OpenACS/TCL/Tk conference

[Neophytos D. <neo...@gm...>]

My highlights are different from Harald's but I will keep most to myself
except for one: Our community is shrinking and personal agendas can
exacerbate this issue. Thanks for having us in Vienna.

- Neophytos

On Sun, Jul 14, 2024 at 3:17 PM Harald Oehlmann <har...@el...>
wrote:

> Dear OpenACS/TCL/tk team members,
>
> please allow me to say "thank you" for the great OpenACS/TCL/Tk user
> conference in Vienna at the University of Economics.
>
> It was a great meeting with awesome organisation, speaker with
> presentations and panels, participants present and on the net.
>
> The presentations are here:
> https://openacs.org/conf2024/info/schedule
> Live recordings will be added soon.
>
> My highlights:
> - TCL/Tk 9 is ready and may be released soon. I was surprised, that the
> pannel sees even Tk in a better state and ready for release.
> - TCL and Tk should be continued to be coupled in (major) releases.
> Package managers like Reinhard from Suse require clear releases to put
> in common distributions
> - Any TCL/Tk 9 ready extension should do an official release, as package
> managers require this (often also for legal reasons). It is not
> sufficient to have it in a branch.
> - More reviews on commits on the main branches are seen helpful
> - Source code management of packages is an issue. A first step would be
> a list (at tcl-lang.org) of officially supported packages. Not
> maintained packages should be put at a common place (on chiseal or github).
> - Markdown documentation is seen as a great step. Semantic documentation
> may follow as a second step.
> - JSON with tdom was my personal highlight, as I currently need that
> (thanks Rolf, for the favour). And it was surprising, that Antonio also
> spoke about it in his awesome VR talk and other OpenACS people liked it,
> as it is anyway included in OpenACS.
> - NaviServer/OpenACS is not well known in the TCL community. An OpenACS
> instance as a groupware may be helpful to internal organisation like
> inter-TCT communication. The Naviserver/OpenACS community also found out
> that more should be done for beginners. Naviserver/OpenACS is very fast
> and highly secure and ready for business critical applications. The
> first wish of the panel was to move the source away from CSV to GITHUB
> and friends.
> - Some future users were well integrated in the conference and got lots
> of support.
> - Tk evolution includes the new text widget (if the bugs are fixed) and
> an enhanced and compatible canvas, maybe with components from tkpath to
> feature more coordinate flexibility, anti-aliasing and alpha-channel.
>
> Thank you all to make this happen.
>
> The next conference (2025) will not take place in Vienna due to internal
> points. So, a location for 2025 is pending. Thanks for any proposal. It
> is hard to reach the standard of the WU, so smaller without streaming
> etc. is also ok.
>
> Thanks for anybody, who made this happen: Stefan, Gustaf, Sebastian,
> Monika and the WU team!
>
> Take care,
> Harald
>
> P.S.: I hope, you all got home well. There was a thunderstorm and the
> airport was close to be closed just after the conference. My train got 2
> hours delayed but I arrived well in Berlin.
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Migration tool for Tcl 9

[Schelte B. <tc...@tc...>]

Ashok,

I came up with this small proc:

proc nseval {ns body} {
     namespace eval $ns {}
     apply [list {} $body $ns]
}

Then using nseval instead of namespace eval does make the global and 
variable commands work to provide access to global variables. (I haven't 
thought too deeply about whether this approach has other problems.)

I have created a ticket for the info vars issue: 
https://core.tcl-lang.org/tcl/tktview/0e4b7fce57


Schelte.


On 14/07/2024 14:40, apn...@ya... wrote:
> Schelte,
> 
> Thanks for the report. I'll take a look at the messages as you reported but
> I was also not aware of the Tcl behaviours you outlined in those last two
> paras. Perhaps someone else might comment but looks as though there is no
> alternative to explicitly qualifying with :: and the "info vars" issue might
> just be that that command has not been adapted to reflect the change in var
> resolution in Tcl 9. Probably worth logging a ticket just so it does not get
> lost either way.
> 
> /Ashok
> 
> -----Original Message-----
> From: Schelte Bron <tc...@tc...>
> Sent: Saturday, July 13, 2024 8:59 PM
> To: tcl...@li...
> Subject: Re: [TCLCORE] Migration tool for Tcl 9
> 
> Hello Ashok,
> 
> This is a very useful tool. Thanks for creating it. Not only does it
> help to quickly find the points that need addressing when wanting to
> make an application compatible with Tcl 9.0, it also instills confidence
> to know that at least the majority of the potential pitfalls have been
> identified.
> 
> As you asked for feedback, here's one situation I came across: When I
> run the migration tool on my largest application, I mainly get
> [UNDECLARED] errors. The detailed information about this error mentions
> writes within a namespace block (outside procs). In my case they are
> actually all reads within a namespace block. But anyway, the advise is
> "to declare variables explicitly using either `global` or `variable`
> depending on whether the intent was to modify a global or namespace
> variable."
> 
> I made a small test script that is similar to my use case:
> 
> set dir [pwd]
> namespace eval bla {
>       variable datadir [file join $dir data]
> }
> 
> Running the migration tool on this script reports the [UNDECLARED]
> error, as expected. So I changed the script according to the recommendation:
> 
> set dir [pwd]
> namespace eval bla {
>       global dir
>       variable datadir [file join $dir data]
> }
> 
> That satisfies the migration tool. However, running the script with tcl
> 9.0 throws an error: can't read "dir": no such variable
> 
> That makes sense, because the very first line of the manual page for the
> "global" command states: "This command has no effect unless executed in
> the context of a proc body". So the proposed solution is ineffective and
> the tool should not be fooled by it.
> 
> In fact, what is the suggested way to use global variables in a
> namespace block if you don't want to add :: to each reference? In
> addition to the `global` command, you can use `variable ::dir` inside a
> proc body. This also creates a link from the global variable to a local
> variable. Unfortunately, this is equally ineffective in a namespace
> block. Is there really no better way than: `namespace upvar :: dir dir`?
> 
> Another confusing thing is that running `info vars` from within the
> namespace block returns (among others) the dir variable. That would
> suggest that the dir variable is "visible", as the manual page calls it.
> I wouldn't consider it visible if I have to use the fully qualified name
> to access it. However if that's the definition, then why are variables
> in other namespaces not listed as visible? I can also access those using
> their fully qualified name.
> 
> Sorry, those last two paragraphs aren't actually about your tool. They
> just came up when trying to resolve the issues flagged by your tool.
> 
> 
> Schelte.
> 
> 
> On 07/07/2024 07:43, apnmbx-public--- via Tcl-Core wrote:
>> V0.2 of the migration tool has been released following feedback from
>> Paul and Andreas (thanks both).
>>
>> https://github.com/apnadkarni/tcl9-migrate/releases
>> <https://github.com/apnadkarni/tcl9-migrate/releases>
>>
>> Docs: https://github.com/apnadkarni/tcl9-migrate/blob/main/README.md
>>
>> Additional feedback on false positive/negatives appreciated.
>>
>> /Ashok
> 
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 

[TCLCORE] Thanks for OpenACS/TCL/Tk conference

[Harald O. <har...@el...>]

Dear OpenACS/TCL/tk team members,

please allow me to say "thank you" for the great OpenACS/TCL/Tk user 
conference in Vienna at the University of Economics.

It was a great meeting with awesome organisation, speaker with 
presentations and panels, participants present and on the net.

The presentations are here:
https://openacs.org/conf2024/info/schedule
Live recordings will be added soon.

My highlights:
- TCL/Tk 9 is ready and may be released soon. I was surprised, that the 
pannel sees even Tk in a better state and ready for release.
- TCL and Tk should be continued to be coupled in (major) releases. 
Package managers like Reinhard from Suse require clear releases to put 
in common distributions
- Any TCL/Tk 9 ready extension should do an official release, as package 
managers require this (often also for legal reasons). It is not 
sufficient to have it in a branch.
- More reviews on commits on the main branches are seen helpful
- Source code management of packages is an issue. A first step would be 
a list (at tcl-lang.org) of officially supported packages. Not 
maintained packages should be put at a common place (on chiseal or github).
- Markdown documentation is seen as a great step. Semantic documentation 
may follow as a second step.
- JSON with tdom was my personal highlight, as I currently need that 
(thanks Rolf, for the favour). And it was surprising, that Antonio also 
spoke about it in his awesome VR talk and other OpenACS people liked it, 
as it is anyway included in OpenACS.
- NaviServer/OpenACS is not well known in the TCL community. An OpenACS 
instance as a groupware may be helpful to internal organisation like 
inter-TCT communication. The Naviserver/OpenACS community also found out 
that more should be done for beginners. Naviserver/OpenACS is very fast 
and highly secure and ready for business critical applications. The 
first wish of the panel was to move the source away from CSV to GITHUB 
and friends.
- Some future users were well integrated in the conference and got lots 
of support.
- Tk evolution includes the new text widget (if the bugs are fixed) and 
an enhanced and compatible canvas, maybe with components from tkpath to 
feature more coordinate flexibility, anti-aliasing and alpha-channel.

Thank you all to make this happen.

The next conference (2025) will not take place in Vienna due to internal 
points. So, a location for 2025 is pending. Thanks for any proposal. It 
is hard to reach the standard of the WU, so smaller without streaming 
etc. is also ok.

Thanks for anybody, who made this happen: Stefan, Gustaf, Sebastian, 
Monika and the WU team!

Take care,
Harald

P.S.: I hope, you all got home well. There was a thunderstorm and the 
airport was close to be closed just after the conference. My train got 2 
hours delayed but I arrived well in Berlin.

Re: [TCLCORE] Migration tool for Tcl 9

[<apn...@ya...>]

Schelte,

Thanks for the report. I'll take a look at the messages as you reported but
I was also not aware of the Tcl behaviours you outlined in those last two
paras. Perhaps someone else might comment but looks as though there is no
alternative to explicitly qualifying with :: and the "info vars" issue might
just be that that command has not been adapted to reflect the change in var
resolution in Tcl 9. Probably worth logging a ticket just so it does not get
lost either way.

/Ashok

-----Original Message-----
From: Schelte Bron <tc...@tc...> 
Sent: Saturday, July 13, 2024 8:59 PM
To: tcl...@li...
Subject: Re: [TCLCORE] Migration tool for Tcl 9

Hello Ashok,

This is a very useful tool. Thanks for creating it. Not only does it 
help to quickly find the points that need addressing when wanting to 
make an application compatible with Tcl 9.0, it also instills confidence 
to know that at least the majority of the potential pitfalls have been 
identified.

As you asked for feedback, here's one situation I came across: When I 
run the migration tool on my largest application, I mainly get 
[UNDECLARED] errors. The detailed information about this error mentions 
writes within a namespace block (outside procs). In my case they are 
actually all reads within a namespace block. But anyway, the advise is 
"to declare variables explicitly using either `global` or `variable` 
depending on whether the intent was to modify a global or namespace 
variable."

I made a small test script that is similar to my use case:

set dir [pwd]
namespace eval bla {
     variable datadir [file join $dir data]
}

Running the migration tool on this script reports the [UNDECLARED] 
error, as expected. So I changed the script according to the recommendation:

set dir [pwd]
namespace eval bla {
     global dir
     variable datadir [file join $dir data]
}

That satisfies the migration tool. However, running the script with tcl 
9.0 throws an error: can't read "dir": no such variable

That makes sense, because the very first line of the manual page for the 
"global" command states: "This command has no effect unless executed in 
the context of a proc body". So the proposed solution is ineffective and 
the tool should not be fooled by it.

In fact, what is the suggested way to use global variables in a 
namespace block if you don't want to add :: to each reference? In 
addition to the `global` command, you can use `variable ::dir` inside a 
proc body. This also creates a link from the global variable to a local 
variable. Unfortunately, this is equally ineffective in a namespace 
block. Is there really no better way than: `namespace upvar :: dir dir`?

Another confusing thing is that running `info vars` from within the 
namespace block returns (among others) the dir variable. That would 
suggest that the dir variable is "visible", as the manual page calls it. 
I wouldn't consider it visible if I have to use the fully qualified name 
to access it. However if that's the definition, then why are variables 
in other namespaces not listed as visible? I can also access those using 
their fully qualified name.

Sorry, those last two paragraphs aren't actually about your tool. They 
just came up when trying to resolve the issues flagged by your tool.


Schelte.


On 07/07/2024 07:43, apnmbx-public--- via Tcl-Core wrote:
> V0.2 of the migration tool has been released following feedback from 
> Paul and Andreas (thanks both).
> 
> https://github.com/apnadkarni/tcl9-migrate/releases 
> <https://github.com/apnadkarni/tcl9-migrate/releases>
> 
> Docs: https://github.com/apnadkarni/tcl9-migrate/blob/main/README.md
> 
> Additional feedback on false positive/negatives appreciated.
> 
> /Ashok




_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] support documents update

[<nb...@to...>]

<div dir="auto">after read this&#xff0c;<div>I really support this work to became true. as a newbie&#xff0c; we need tcl/tk doc  more readable&#xff0c;more update&#xff0c;more access able. support offline read. thank your all !  </div><div><br /><b>Enhancing Tcl/Tk Documentation: From nroff to Markdown and further</b><a href="https://openacs.org/conf2024/info/download/file/openacs-tcltk-2024-manual-pages.pdf"><i></i></a>
     <br />Torsten Berg<br /><br /><br /><br /><div>发自我的手机</div></div></div>

Re: [TCLCORE] Migration tool for Tcl 9

[Schelte B. <tc...@tc...>]

Hello Ashok,

This is a very useful tool. Thanks for creating it. Not only does it 
help to quickly find the points that need addressing when wanting to 
make an application compatible with Tcl 9.0, it also instills confidence 
to know that at least the majority of the potential pitfalls have been 
identified.

As you asked for feedback, here's one situation I came across: When I 
run the migration tool on my largest application, I mainly get 
[UNDECLARED] errors. The detailed information about this error mentions 
writes within a namespace block (outside procs). In my case they are 
actually all reads within a namespace block. But anyway, the advise is 
"to declare variables explicitly using either `global` or `variable` 
depending on whether the intent was to modify a global or namespace 
variable."

I made a small test script that is similar to my use case:

set dir [pwd]
namespace eval bla {
     variable datadir [file join $dir data]
}

Running the migration tool on this script reports the [UNDECLARED] 
error, as expected. So I changed the script according to the recommendation:

set dir [pwd]
namespace eval bla {
     global dir
     variable datadir [file join $dir data]
}

That satisfies the migration tool. However, running the script with tcl 
9.0 throws an error: can't read "dir": no such variable

That makes sense, because the very first line of the manual page for the 
"global" command states: "This command has no effect unless executed in 
the context of a proc body". So the proposed solution is ineffective and 
the tool should not be fooled by it.

In fact, what is the suggested way to use global variables in a 
namespace block if you don't want to add :: to each reference? In 
addition to the `global` command, you can use `variable ::dir` inside a 
proc body. This also creates a link from the global variable to a local 
variable. Unfortunately, this is equally ineffective in a namespace 
block. Is there really no better way than: `namespace upvar :: dir dir`?

Another confusing thing is that running `info vars` from within the 
namespace block returns (among others) the dir variable. That would 
suggest that the dir variable is "visible", as the manual page calls it. 
I wouldn't consider it visible if I have to use the fully qualified name 
to access it. However if that's the definition, then why are variables 
in other namespaces not listed as visible? I can also access those using 
their fully qualified name.

Sorry, those last two paragraphs aren't actually about your tool. They 
just came up when trying to resolve the issues flagged by your tool.


Schelte.


On 07/07/2024 07:43, apnmbx-public--- via Tcl-Core wrote:
> V0.2 of the migration tool has been released following feedback from 
> Paul and Andreas (thanks both).
> 
> https://github.com/apnadkarni/tcl9-migrate/releases 
> <https://github.com/apnadkarni/tcl9-migrate/releases>
> 
> Docs: https://github.com/apnadkarni/tcl9-migrate/blob/main/README.md
> 
> Additional feedback on false positive/negatives appreciated.
> 
> /Ashok