tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Bad test(1) evaluation in some packages.

[Bch <be...@sh...>]

Hello Tclers.

Thanks Don for your work again getting 9 out the door, and everybody
that has contributed code, bug reports, documentation and arguments
to make Tcl what it is. I've been running tip-of-development for
a long time now and look forward to having the rest of the world
appreciate all the hard work thats gone into Tcl to make Tcl9.

I've run into cases where test(1) is misusing "==" to test for
equality. The proper format is "=". Attached find a patch applied
againts Sqlite as shipping in rc2, but I've seen this in other
extensions too. From my findings with *b3*:

  ./thread3.0b4/tclconfig/tcl.m4:    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./thread3.0b4/tclconfig/tcl.m4: if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./thread3.0b4/tclconfig/tcl.m4: if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./thread3.0b4/tclconfig/tcl.m4:    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbcsqlite3-1.1.8/tclconfig/tcl.m4:    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbcsqlite3-1.1.8/tclconfig/tcl.m4:   if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbcsqlite3-1.1.8/tclconfig/tcl.m4:   if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbcsqlite3-1.1.8/tclconfig/tcl.m4:    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbcpostgres1.1.8/tclconfig/tcl.m4:    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbcpostgres1.1.8/tclconfig/tcl.m4:   if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbcpostgres1.1.8/tclconfig/tcl.m4:   if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbcpostgres1.1.8/tclconfig/tcl.m4:    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbcodbc1.1.8/tclconfig/tcl.m4:    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbcodbc1.1.8/tclconfig/tcl.m4:       if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbcodbc1.1.8/tclconfig/tcl.m4:       if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbcodbc1.1.8/tclconfig/tcl.m4:    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbcmysql1.1.8/tclconfig/tcl.m4:    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbcmysql1.1.8/tclconfig/tcl.m4:      if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbcmysql1.1.8/tclconfig/tcl.m4:      if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbcmysql1.1.8/tclconfig/tcl.m4:    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbc1.1.8/tclconfig/tcl.m4:    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbc1.1.8/tclconfig/tcl.m4:   if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbc1.1.8/tclconfig/tcl.m4:   if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./tdbc1.1.8/tclconfig/tcl.m4:    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./sqlite3.45.3/tclconfig/tcl.m4:    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./sqlite3.45.3/tclconfig/tcl.m4:        if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./sqlite3.45.3/tclconfig/tcl.m4:        if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./sqlite3.45.3/tclconfig/tcl.m4:    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./itcl4.2.5/tclconfig/tcl.m4:    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./itcl4.2.5/tclconfig/tcl.m4:   if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./itcl4.2.5/tclconfig/tcl.m4:   if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
  ./itcl4.2.5/tclconfig/tcl.m4:    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then


it looks like some (many) have been fixed/regenerated, but as I look, perhaps there are new errors introduced (AC_HELP_STRING -> AS_HELP_STRING)?


If this looks like a reasonable assessment, I'm happy to trawl and help fix; just let me know.

Happy Tcling,

-bch



Index: pkgs/sqlite3.45.3/configure
==================================================================
--- pkgs/sqlite3.45.3/configure
+++ pkgs/sqlite3.45.3/configure
@@ -9561,11 +9561,11 @@
     # substituted. (@@@ Might not be necessary anymore)
     #--------------------------------------------------------------------
 
     PACKAGE_LIB_PREFIX8="${PACKAGE_LIB_PREFIX}"
     PACKAGE_LIB_PREFIX9="${PACKAGE_LIB_PREFIX}tcl9"
-    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
+    if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" = x; then
 	PACKAGE_LIB_PREFIX="${PACKAGE_LIB_PREFIX9}"
     else
 	PACKAGE_LIB_PREFIX="${PACKAGE_LIB_PREFIX8}"
 
 printf "%s\n" "#define TCL_MAJOR_VERSION 8" >>confdefs.h
@@ -9592,11 +9592,11 @@
 	    eval eval "PKG_LIB_FILE8=${PACKAGE_LIB_PREFIX8}${PACKAGE_NAME}${UNSHARED_LIB_SUFFIX}"
 	    eval eval "PKG_LIB_FILE9=${PACKAGE_LIB_PREFIX9}${PACKAGE_NAME}${UNSHARED_LIB_SUFFIX}"
 	    eval eval "PKG_LIB_FILE=${PACKAGE_LIB_PREFIX}${PACKAGE_NAME}${UNSHARED_LIB_SUFFIX}"
 	fi
 	# Some packages build their own stubs libraries
-	if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
+	if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" = x; then
 	    eval eval "PKG_STUB_LIB_FILE=${PACKAGE_LIB_PREFIX8}${PACKAGE_NAME}stub.a"
 	else
 	    eval eval "PKG_STUB_LIB_FILE=${PACKAGE_LIB_PREFIX8}${PACKAGE_NAME}stub${UNSHARED_LIB_SUFFIX}"
 	fi
 	if test "$GCC" = "yes"; then
@@ -9620,11 +9620,11 @@
 	    eval eval "PKG_LIB_FILE8=lib${PACKAGE_LIB_PREFIX8}${PACKAGE_NAME}${UNSHARED_LIB_SUFFIX}"
 	    eval eval "PKG_LIB_FILE9=lib${PACKAGE_LIB_PREFIX9}${PACKAGE_NAME}${UNSHARED_LIB_SUFFIX}"
 	    eval eval "PKG_LIB_FILE=lib${PACKAGE_LIB_PREFIX}${PACKAGE_NAME}${UNSHARED_LIB_SUFFIX}"
 	fi
 	# Some packages build their own stubs libraries
-	if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" == x; then
+	if test "${TCL_MAJOR_VERSION}" -gt 8 -a x"${with_tcl8}" = x; then
 	    eval eval "PKG_STUB_LIB_FILE=lib${PACKAGE_LIB_PREFIX8}${PACKAGE_NAME}stub.a"
 	else
 	    eval eval "PKG_STUB_LIB_FILE=lib${PACKAGE_LIB_PREFIX8}${PACKAGE_NAME}stub${UNSHARED_LIB_SUFFIX}"
 	fi
     fi

Re: [TCLCORE] RC2 Blockers

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

Hi,

"8.7" is now gone from trunk (in Tcl and Tk) in the parts of the manual pages visual to the users. It is still mentioned inside some .VS and .VE nroff macros but from there the version number will not be visible in the rendered man or html. That is harmless IMO.

Sorry for coming with this so late in the process, I understand we want the RC process to end as soon as possible, and that's fine!

Regards, Torsten


> Am 24.09.2024 um 23:00 schrieb Donald G Porter via Tcl-Core <tcl...@li...>:
> 
> 
> Ok, I am hearing two complaints about RC2 that folks want addressed
> before the release of Tcl/Tk 9.0.0.
> 
> The documentation should be purged of mentions of Tcl 8.7.
> 
> The changes/release notes should warn about lack of intrep preservation.
> 
> I am (just barely) willing to cut one more -- RC3 -- and then release
> that, but I'm not willing to do N more.  If there's anything else, speak
> up in the next 24 hours, and catch the last train.
> 
> -- 
> | Don Porter            Applied and Computational Mathematics Division |
> | don...@ni...             Information Technology Laboratory |
> | http://math.nist.gov/~DPorter/                                  NIST |
> |______________________________________________________________________|
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Tcl 9.0.0 Draft Release Notes

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

Oops, sorry, I was going by this – 

 

% info patch

9.0b3

% info loaded x y z

wrong # args: should be "info loaded ?interp? ?packageName?"

 

having picked up the Beta 3 tclsh from my path instead of the current rc2 version.

 

Apologies for the noise

 

From: Jan Nijtmans <jan...@gm...> 
Sent: Wednesday, September 25, 2024 1:45 PM
To: apn...@ya...
Cc: Donald G Porter <don...@ni...>; Tcl List Core <tcl...@li...>
Subject: Re: [TCLCORE] Tcl 9.0.0 Draft Release Notes

 

Op wo 25 sep 2024 om 10:00 schreef apnmbx-public--- via Tcl-Core:

A very very minor nit I hesitate in reporting but ...

In the section "New command options",

- `info loaded ... ?prefix?`

Should probably be

- `info loaded ... ?package?`

 

No, you're mistaken: "?prefix?" is correct here, since "info loaded"

doesn't know anything about the package name.

 

Regards,

        Jan Nijtmans

 

Re: [TCLCORE] Tcl 9.0.0 Draft Release Notes

[Jan N. <jan...@gm...>]

Op wo 25 sep 2024 om 10:00 schreef apnmbx-public--- via Tcl-Core:

> A very very minor nit I hesitate in reporting but ...
>
> In the section "New command options",
>
> - `info loaded ... ?prefix?`
>
> Should probably be
>
> - `info loaded ... ?package?`
>

No, you're mistaken: "?prefix?" is correct here, since "info loaded"
doesn't know anything about the package name.

Regards,
        Jan Nijtmans

Re: [TCLCORE] RC2 Blockers

[Jan N. <jan...@gm...>]

Op di 24 sep 2024 om 23:00 schreef Donald G Porter via Tcl-Core:

>
> Ok, I am hearing two complaints about RC2 that folks want addressed
> before the release of Tcl/Tk 9.0.0.
>
> The documentation should be purged of mentions of Tcl 8.7.
>
> The changes/release notes should warn about lack of intrep preservation.
>
> I am (just barely) willing to cut one more -- RC3 -- and then release
> that, but I'm not willing to do N more.  If there's anything else, speak
> up in the next 24 hours, and catch the last train.
>

I just committed a 1-line fix to trunk, which prevents the conversion
to list in the case reported by AKU:
    Tcl Source Code: Check-in [53e5096b31] (tcl-lang.org)
<https://core.tcl-lang.org/tcl/info/53e5096b315bd094>
This gives you the possibility to solve the problem in stead
of mentioning it in the "known bugs" section.

But .... the decision is yours, Don!

Hope this helps,
     Jan Nijtmans

Re: [TCLCORE] Tcl 9.0.0 Draft Release Notes

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

A very very minor nit I hesitate in reporting but ...

In the section "New command options",

- `info loaded ... ?prefix?`

Should probably be

- `info loaded ... ?package?`

-----Original Message-----
From: Donald G Porter via Tcl-Core <tcl...@li...> 
Sent: Tuesday, September 24, 2024 11:43 PM
To: Tcl List Core <tcl...@li...>
Subject: [TCLCORE] Tcl 9.0.0 Draft Release Notes


Please take a look at the draft release notes for Tcl 9.0.0. It
is the file tcl-release-notes-9.0.0.md found at:

https://sourceforge.net/projects/tcl/files/Tcl/9.0.0/

Send me your corrections and suggestions.  Examine both substantive
content and Markdown mark-up.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|



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

Re: [TCLCORE] Tcl 9.0.0 Release Candidate

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

Tested on Windows 10 w/ Visual Studio x64 and x86. Also Debian.

Same failures as reported for RC1 earlier (no show stoppers)

/Ashok

-----Original Message-----
From: Donald G Porter via Tcl-Core <tcl...@li...> 
Sent: Wednesday, September 25, 2024 12:11 AM
To: Tcl List Core <tcl...@li...>
Subject: [TCLCORE] Tcl 9.0.0 Release Candidate


Now available at

https://sourceforge.net/projects/tcl/files/Tcl/9.0.0/

are RC2 candidate source code distribution pre-release of Tcl 9.0.0

This is the third of a sequence of candidate releases leading to the release of
Tcl 9.0.0. Testing of builds and operations on multiple platforms is invited.  Any
critical problem that should block the release should be reported immediately.

The Tcl pre-release includes pre-releases of the packages Thread 3.0.0 and Itcl 4.3.1.
The same level of vetting on them is also appreciated.  The released packages
sqlite 3.45.3 and TDBC* 1.1.9 are also included.

Compared to the RC1 candidate, this release includes one bug fix in the formatting
of list elements, as well as several refinements to the documentation and comments.

It is expected that the RC2 candidate files will become the Tcl 9.0.0 release later
this week.

Thank you for your contributions and assistance.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|



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

Re: [TCLCORE] Tcl 9 `expr` bug, int.rep typing

[Donald P. <d.g...@co...>]

> On Sep 24, 2024, at 6:44 PM, Andreas Kupries <and...@gm...> wrote:
> 
> 
>> A few thoughts.
> 
>> I was not involved in the changes under review, and my first
>> reaction is that it seems weird for [expr] to convert a value to a
>> list. Can't say for sure, but I don't think I would pursued this
>> approach. If it can be reformed as described, that seems good.
> 
>> That said, I am very strongly of the opinion that Tcl 9 should be
>> out of the business of protecting the intreps of extensions and
>> apps. This was never part of the interface contract, and if we can't
>> escape it in a new major version we never will. The movement from
>> Tcl 8 to Tcl 9 is the right moment for extensions to pull up their
>> pants and implement their own intrep preservation properly.
> 
> Fair point.
> 
> Back of mind has started churning a bit on how this could be achieved
> for AKTIVE. Will see how that goes. ...
> 
> Well, trivial way might be a kind of handle as string-rep, and an
> internal hash table mapping from handles to values. The int rep would
> still be a direct pointer to the value, and if that is lost it can be
> recovered through the handle.
> 
> More direct might be encoding the pointer, i.e. address into the
> string rep. No hash table taking memory. Recovery of value is straight
> decoding the string value. Would need some kind of whitening to avoid
> giving out actual memory addresses to the script.
> 
> ... Might have issues with reference counting ... IOW could construct
> a string referencing an image, and getting the int rep will have to
> ensure that the RC becomes correct.
> 
> ... And on the other side shimmering away from the int rep of a
> Tcl_Obj drops a ref count, might release the int rep ...
> 
> Yes, regardless of exact implementation of preservation, the ref count
> / proper life time of the int rep in the face of shimmering is the big
> gnarly issue to solve.
> 
> Because on the one hand we want to bind the life time of the
> <structure> to the life time of all the Tcl_Obj referencing it, yet we
> also want it to be detached enough to survive shimmering to other int
> reps long enough to recover when handed back to a command operating on
> <structure>s.
> 
> Ok, best to stop here, and let this simmer for quite some time.

I am open to the possibility that Tcl still does not supply the complete set of public interfaces to permit extensions to craft robust and efficient solutions.  But we’re never going to find those gaps and fill them until we press the pain.

It helps (I think) that Tcl_ObjType is now versioned, so when any needed improvements are created, they can slide into a Tcl 9.1 or maybe even in a Tcl 9.0.N in a workable way.

DGP

Re: [TCLCORE] Tcl 9 `expr` bug, int.rep typing

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

> A few thoughts.
 
> I was not involved in the changes under review, and my first
> reaction is that it seems weird for [expr] to convert a value to a
> list. Can't say for sure, but I don't think I would pursued this
> approach. If it can be reformed as described, that seems good.
 
> That said, I am very strongly of the opinion that Tcl 9 should be
> out of the business of protecting the intreps of extensions and
> apps. This was never part of the interface contract, and if we can't
> escape it in a new major version we never will. The movement from
> Tcl 8 to Tcl 9 is the right moment for extensions to pull up their
> pants and implement their own intrep preservation properly.

Fair point.

Back of mind has started churning a bit on how this could be achieved
for AKTIVE. Will see how that goes. ...

Well, trivial way might be a kind of handle as string-rep, and an
internal hash table mapping from handles to values. The int rep would
still be a direct pointer to the value, and if that is lost it can be
recovered through the handle.

More direct might be encoding the pointer, i.e. address into the
string rep. No hash table taking memory. Recovery of value is straight
decoding the string value. Would need some kind of whitening to avoid
giving out actual memory addresses to the script.

... Might have issues with reference counting ... IOW could construct
a string referencing an image, and getting the int rep will have to
ensure that the RC becomes correct.

... And on the other side shimmering away from the int rep of a
Tcl_Obj drops a ref count, might release the int rep ...

Yes, regardless of exact implementation of preservation, the ref count
/ proper life time of the int rep in the face of shimmering is the big
gnarly issue to solve.

Because on the one hand we want to bind the life time of the
<structure> to the life time of all the Tcl_Obj referencing it, yet we
also want it to be detached enough to survive shimmering to other int
reps long enough to recover when handed back to a command operating on
<structure>s.

Ok, best to stop here, and let this simmer for quite some time.

-- 
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 9 `expr` bug, int.rep typing

[Jan N. <jan...@gm...>]

Op di 24 sep 2024 om 22:44 schreef Andreas Kupries <
and...@gm...>:

> > I'll work on that after 9.0.0 is out (since this isn't blocking)
>
> +1, and good luck.


Proposed solution here:
     <https://core.tcl-lang.org/tcl/info/1870ed5dd9662b93>

Appears to work fine, but needs more testing.     ;-)

@Don, thanks for the hint to use TclMaxListLength()!

Regards,
   Jan Nijtmans

[TCLCORE] RC2 Blockers

[Donald G P. <don...@ni...>]

Ok, I am hearing two complaints about RC2 that folks want addressed
before the release of Tcl/Tk 9.0.0.

The documentation should be purged of mentions of Tcl 8.7.

The changes/release notes should warn about lack of intrep preservation.

I am (just barely) willing to cut one more -- RC3 -- and then release
that, but I'm not willing to do N more.  If there's anything else, speak
up in the next 24 hours, and catch the last train.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] Tcl 9 `expr` bug, int.rep typing

[Donald G P. <don...@ni...>]

On 9/24/24 16:44, Andreas Kupries wrote:
> Jan wrote:
>> Thinking about it, there is a way out. The only reason for
>> converting to a Tcl list because I want to know whether it can be
>> represented as a list with length > 1. We can also check that by
>> verifying the string representation for spaces, tabs \n or \r (not
>> counting the ones at the beginning or end). A complication is that
>> we should not count spaces preceded by '\'. So, a little string
>> trickery, but this is cheaper than converting to a Tcl list, so
>> worth the trouble.
>> I'll work on that after 9.0.0 is out (since this isn't blocking)
> +1, and good luck.
>

A few thoughts.

I was not involved in the changes under review, and my first reaction
is that it seems weird for [expr] to convert a value to a list. Can't
say for sure, but I don't think I would pursued this approach.  If it
can be reformed as described, that seems good.

That said, I am very strongly of the opinion that Tcl 9 should be out
of the business of protecting the intreps of extensions and apps. This
was never part of the interface contract, and if we can't escape it in
a new major version we never will.  The movement from Tcl 8 to Tcl 9
is the right moment for extensions to pull up their pants and implement
their own intrep preservation properly.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] Tcl 9 `expr` bug, int.rep typing

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

Jan wrote:
> Thinking about it, there is a way out. The only reason for
> converting to a Tcl list because I want to know whether it can be
> represented as a list with length > 1. We can also check that by
> verifying the string representation for spaces, tabs \n or \r (not
> counting the ones at the beginning or end). A complication is that
> we should not count spaces preceded by '\'. So, a little string
> trickery, but this is cheaper than converting to a Tcl list, so
> worth the trouble.

> I'll work on that after 9.0.0 is out (since this isn't blocking)

+1, and good luck.

-- 
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.0.0 Release Candidates

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

Ha,

as I did not hear any objections, I will change the documentation accordingly in trunk tomorrow morning. I will assume the reason for requiring Tcl 8.7 is some new feature that is now also part of Tcl 9 so a `package require Tcl8.6` will not be the right version to state in the manual pages.

It would be nice to have this change included in the official Tcl 9.0 release.

Regards, Torsten


> Am 19.09.2024 um 08:22 schrieb Torsten Berg <be...@ty...>:
> 
> Hi,
> 
> is it a problem that some man pages, when opened in the terminal via `man ...`, report belonging to Tcl 8.7 as this version has never been released? E.g. the footer of these manual pages:
> 
> array, fpclassify, ledit, lpop. lremove, lseq, process
> 
> We might ignore this as it will only show up in the terminal version, not in the HTML version, but it is still confusing.
> 
> Definitely an error, in my view, is mentioning version 8.7 in the body text of manual pages:
> 
> doc/fpclassify.n:package require \fBtcl 8.7\fR
> 
> doc/msgcat.n:\fBpackage require tcl 8.7\fR
> 
> doc/safe.n:Before Tcl version 8.7, the Safe Base kept each safe interpreter's
> 
> Should this be changed to "9.0"? I think so.
> 
> 
> For Tk, we only have 8.7 mentioned in the footer of nsimage.
> 
> 
> I would change these occurrences from 8.7 to 9.0 if there are no objections.
> 
> Regards, Torsten
> 
> 
>> Am 18.09.2024 um 21:32 schrieb Donald G Porter via Tcl-Core <tcl...@li...>:
>> 
>> 
>> Now available at
>> 
>> https://sourceforge.net/projects/tcl/files/Tcl/9.0.0/
>> 
>> are RC1 candidate source code distribution pre-releases of Tcl and Tk 9.0.0
>> 
>> This is the second of a sequence of candidate releases leading to the release of
>> Tcl/Tk 9.0.0. Testing of builds and operations on multiple platforms is invited.  Open
>> tickets on any problems discovered, or raise the issue in a reply to this message.
>> 
>> The Tcl pre-release includes pre-releases of the packages Thread 3.0.0 and Itcl 4.3.1.
>> The same level of vetting on them is also appreciated.  The released packages
>> sqlite 3.45.3 and TDBC* 1.1.9 are also included.
>> 
>> Several fixes and improvements brought to light under examination of the RC0
>> release candidates are in these new offerings.
>> 
>> Thank you for your contributions and assistance.
>> 
>> -- 
>> | Don Porter            Applied and Computational Mathematics Division |
>> | don...@ni...             Information Technology Laboratory |
>> | http://math.nist.gov/~DPorter/                                  NIST |
>> |______________________________________________________________________|
>> 
>> 
>> 
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 
> 

Re: [TCLCORE] Tcl 9 `expr` bug, int.rep typing

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

> One of mine is such an extension (*, **), which is why I ran into the
> issue when I executed the test suite against a near-current Tcl 9
> commit (3 days old) and got a load of test failures I knew had worked
> before with a commit from near the beginning of the year.
 
> I am willing to a accept the change, given the reasoning from the
> ticket, and given that I can change my code to detect the
> single-element list int.rep and then undo the wrapping to get at the
> actual and desired value.

[please read to the end before responding to parts]

Actually the change fully breaks my current code, and thus all other
extensions using values which have no string rep (*) doing the same
kind of pass-through through `expr`. Passing such a value through
`expr` now fully strips their precious int.rep, with no recovery.

Because the conversion of the value with the unknown type to List
first generates a string rep, then converts that to List int.rep, and
this second step is where we lose the original int.rep and thus the
actual value.

I was still able to fix the issue for me, by avoiding `expr`
completely.  I.e. instead of a trinary operator `?:` I now use an
`if`-command. Luckily it seems that it was only that one place where I
did such a pass-through.

I will also have to note this in big bold red text in AKTIVE's
documentation for its users, as passing of image values through `expr`
is now forbidden.

(*) These are hopefully not that many.

Note: In AKTIVE the code returns a pseudo-string rep of "<aktive::image>".
Not sure if I can leave the Tcl_UpdateStringProc as NULL. I suspect
that would trigger an error in many a place.

> Given how I stumbled into this I would recommend and ask to place a
> note about this into the compatibility notes as something extension
> writers may have to be aware of.

I would like to strengthen my recommendation for a compatibility note.

> (*) https://core.tcl-lang.org/akupries/aktive/doc/trunk/README.md
>     uses Tcl_Obj values to carry images. Which may be large. So I
>     decided against dealing with a string rep which will not only
>     materialize the entire block of pixels into memory, but worse, as
>     some form of text.

To elaborate a bit more, as inspired by VIPS, AKTIVE is about
performing image ops on (very) large images __without__ having to
materialize the entire image in memory, just the pieces currently
processed, i.e. a few rows, columns, or other small tiles.

Having such then materialized because `expr` wanted/needed a string
rep to decide quicker that it cannot work with the value ...

... that now looks to me to be pretty much the original ticket, for
any extension providing Tcl_ObjTypes with possibly large string
reps. I.e. the slow detection is only fixed for builtin types, not
extension types.

Note, I am __not__ arguing for undoing the change.
It is arguably better than before.
Only that we should be aware of its limitations too, wrt extensions.

More stuff for the compatibility notes.

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

[TCLCORE] Tk 9.0.0 Release Candidate

[Donald G P. <don...@ni...>]

Now available at

https://sourceforge.net/projects/tcl/files/Tcl/9.0.0/

are RC2 candidate source code distribution pre-release of Tk 9.0.0

This is the third of a sequence of candidate releases leading to the release of
Tk 9.0.0. Testing of builds and operations on multiple platforms is invited.  Any
critical problem that should block the release should be reported immediately.

It is expected that the RC2 candidate files will become the Tk 9.0.0 release later
this week.

Thank you for your contributions and assistance.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] Tcl 9.0.0 Draft Release Notes

[Donald G P. <don...@ni...>]

And now please also examine the file tk-release-notes-9.0.0.md for Tk.


On 9/24/24 14:13, Donald G Porter via Tcl-Core wrote:
>
> Please take a look at the draft release notes for Tcl 9.0.0. It
> is the file tcl-release-notes-9.0.0.md found at:
>
> https://sourceforge.net/projects/tcl/files/Tcl/9.0.0/
>
> Send me your corrections and suggestions.  Examine both substantive
> content and Markdown mark-up.
>


-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] Tcl 9 `expr` bug, int.rep typing

[Donald G P. <don...@ni...>]

On 9/24/24 15:21, Jan Nijtmans wrote:
> Op di 24 sep 2024 om 21:02 schreef Andreas Kupries <and...@gm...>:
>
>     Well, as I said in my initial mail, for extensions providing
>     full-fledged Tcl_ObjTypes, i.e. full conversion to/from a string rep
>     this is indeed not a problem. The next extension command will shimmer
>     the value back to the type it wants. Just a bit of a performance-loss
>     due to the additional shimmer.
>
>
> Thinking about it, there is a way out. The only reason for converting to
> a Tcl list because I want to know whether it can be represented as
> a list with length > 1. We can also check that by verifying the
> string representation for spaces, tabs \n or \r (not counting the ones
> at the beginning or end). A complication is that we should
> not count spaces preceded by '\'. So, a little string trickery,
> but this is cheaper than converting to a Tcl list, so worth
> the trouble.

Take note of the existing internal utility routine TclMaxListLength().

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] Tcl 9 `expr` bug, int.rep typing

[Jan N. <jan...@gm...>]

Op di 24 sep 2024 om 21:02 schreef Andreas Kupries <
and...@gm...>:

> Well, as I said in my initial mail, for extensions providing
> full-fledged Tcl_ObjTypes, i.e. full conversion to/from a string rep
> this is indeed not a problem. The next extension command will shimmer
> the value back to the type it wants. Just a bit of a performance-loss
> due to the additional shimmer.
>

Thinking about it, there is a way out. The only reason for converting to
a Tcl list because I want to know whether it can be represented as
a list with length > 1. We can also check that by verifying the
string representation for spaces, tabs \n or \r (not counting the ones
at the beginning or end). A complication is that we should
not count spaces preceded by '\'. So, a little string trickery,
but this is cheaper than converting to a Tcl list, so worth
the trouble.

I'll work on that after 9.0.0 is out (since this isn't blocking)

Thanks!
       Jan Nijtmans

Re: [TCLCORE] Tcl 9 `expr` bug, int.rep typing

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

> Op di 24 sep 2024 om 19:57 schreef Donald G Porter via Tcl-Core <
> tcl...@li...>:
> 
> > On 9/24/24 12:53, Andreas Kupries wrote:
> > > I believe that I have found a bug in the `expr` command of
> > >
> > >       Tcl 9 (commit <1f19a433ec>).
> >
> > This is a bad joke.
> >
> >
> This behavior is caused by this commit:

>      <https://core.tcl-lang.org/tcl/info/a197811f135d262b>

> and it's done on purpose. Read the ticket for the
> reason behind it. It only happens when the value doesn't
> match any other known type, so I don't see how it
> can cause problems.

Well, as I said in my initial mail, for extensions providing
full-fledged Tcl_ObjTypes, i.e. full conversion to/from a string rep
this is indeed not a problem. The next extension command will shimmer
the value back to the type it wants. Just a bit of a performance-loss
due to the additional shimmer.

It is an issue for extensions using Tcl_ObjTypes without a string
rep. These extensions usually do not try to shimmer from other types
into theirs, and simply expect that the type coming in is as they
expected.

One of mine is such an extension (*, **), which is why I ran into the
issue when I executed the test suite against a near-current Tcl 9
commit (3 days old) and got a load of test failures I knew had worked
before with a commit from near the beginning of the year.

I am willing to a accept the change, given the reasoning from the
ticket, and given that I can change my code to detect the
single-element list int.rep and then undo the wrapping to get at the
actual and desired value.

Given how I stumbled into this I would recommend and ask to place a
note about this into the compatibility notes as something extension
writers may have to be aware of.

(*) https://core.tcl-lang.org/akupries/aktive/doc/trunk/README.md
    uses Tcl_Obj values to carry images. Which may be large. So I
    decided against dealing with a string rep which will not only
    materialize the entire block of pixels into memory, but worse, as
    some form of text.

(**) The problematic `expr` is at
     https://core.tcl-lang.org/akupries/aktive/file?ci=trunk&name=op/embed.tcl&
ln=58
     and caught out at
     https://core.tcl-lang.org/akupries/aktive/file?ci=trunk&name=runtime/objty
pe_image.c&ln=57

> From the ticket:
> 
>     A side-effect of this is that Tcl_GetNumberFromObj() now tries to
>     convert the object to a list, if it isn't already one of the
>     other known types (like dict, lseq, or index). That's very useful in
>     further error-handling, since the typePtr or lengthProc then
>     can be inspected for this case without trying to do more parsing.
> 
> Hope this helps,

Yes, very much, and thank you.

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

[TCLCORE] Tcl 9.0.0 Release Candidate

[Donald G P. <don...@ni...>]

Now available at

https://sourceforge.net/projects/tcl/files/Tcl/9.0.0/

are RC2 candidate source code distribution pre-release of Tcl 9.0.0

This is the third of a sequence of candidate releases leading to the release of
Tcl 9.0.0. Testing of builds and operations on multiple platforms is invited.  Any
critical problem that should block the release should be reported immediately.

The Tcl pre-release includes pre-releases of the packages Thread 3.0.0 and Itcl 4.3.1.
The same level of vetting on them is also appreciated.  The released packages
sqlite 3.45.3 and TDBC* 1.1.9 are also included.

Compared to the RC1 candidate, this release includes one bug fix in the formatting
of list elements, as well as several refinements to the documentation and comments.

It is expected that the RC2 candidate files will become the Tcl 9.0.0 release later
this week.

Thank you for your contributions and assistance.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] Tcl 9 `expr` bug, int.rep typing

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

> On 9/24/24 12:53, Andreas Kupries wrote:
> > I believe that I have found a bug in the `expr` command of
> >
> > 	Tcl 9 (commit <1f19a433ec>).
> 
> This is a bad joke.

I did not say that this commit was responsible.
Just that this is the commit where I ran into the issue.

I did not have the time yet (*) to bisect down to the actual commit

I will try to be more precise with future commit references.

(*) Managed the small repro just before I went down for dinner and news.
    I am back now and will work on bisecting.

> That commit is made up entirely of edits to comments plus a single
> whitespace change in non-comment code.  I cannot imagine how
> that checkin can be the source of any behavior change.


-- 
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 9 `expr` bug, int.rep typing

[Jan N. <jan...@gm...>]

Op di 24 sep 2024 om 19:57 schreef Donald G Porter via Tcl-Core <
tcl...@li...>:

> On 9/24/24 12:53, Andreas Kupries wrote:
> > I believe that I have found a bug in the `expr` command of
> >
> >       Tcl 9 (commit <1f19a433ec>).
>
> This is a bad joke.
>
>
This behavior is caused by this commit:
     <https://core.tcl-lang.org/tcl/info/a197811f135d262b>
and it's done on purpose. Read the ticket for the
reason behind it. It only happens when the value doesn't
match any other known type, so I don't see how it
can cause problems.

>From the ticket:

    A side-effect of this is that Tcl_GetNumberFromObj() now tries to
    convert the object to a list, if it isn't already one of the
    other known types (like dict, lseq, or index). That's very useful in
    further error-handling, since the typePtr or lengthProc then
    can be inspected for this case without trying to do more parsing.

Hope this helps,

     Jan Nijtmans

[TCLCORE] Tcl 9.0.0 Draft Release Notes

[Donald G P. <don...@ni...>]

Please take a look at the draft release notes for Tcl 9.0.0. It
is the file tcl-release-notes-9.0.0.md found at:

https://sourceforge.net/projects/tcl/files/Tcl/9.0.0/

Send me your corrections and suggestions.  Examine both substantive
content and Markdown mark-up.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] Tcl 9 `expr` bug, int.rep typing

[Donald G P. <don...@ni...>]

On 9/24/24 12:53, Andreas Kupries wrote:
> I believe that I have found a bug in the `expr` command of
>
> 	Tcl 9 (commit <1f19a433ec>).

This is a bad joke.

That commit is made up entirely of edits to comments plus a single
whitespace change in non-comment code.  I cannot imagine how
that checkin can be the source of any behavior change.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|