Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Brian Griffin Newsgroups: comp.lang.tcl Subject: Re: vectcl and tcl9 Date: Thu, 23 Jan 2025 07:25:44 -0800 Organization: A noiseless patient Spider Lines: 128 Message-ID: References: <2af45bfa-e1ae-4a45-90c3-83af0678f820@clevelandgolf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 23 Jan 2025 16:25:45 +0100 (CET) Injection-Info: dont-email.me; posting-host="d5408bf2ca92640a1cd3dd0c20d776ca"; logging-data="1775592"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18NSPh9GZbOvWI3oKL+nGbBqW2HMwtbvYZNg+lAUsyyAw==" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:6b9gZpbX45bfhPqJk0hP6UfPJxk= Content-Language: en-US In-Reply-To: Bytes: 5854 On 1/23/25 06:04, Harald Oehlmann wrote: > Here is what Brian wrote by private E-Mail: > > My fork of VecTCL using Abstract Lists is in github: > > https://github.com/bgriffinfortytwo/VecTcl9 > > It has not been updated with the current state of Tcl 9. Nor has it been > updated with any potential changes in VecTCL since this original proof > of concept was created. It's on my todo list. :) > > -Brian I'll work on getting my VecTCL fork up-to-date with current Tcl 9.0, then figure out what's next after that. I'm curious what the harm is in keeping the "int" obj type in Tcl? -Brian > > > Am 22.01.2025 um 18:08 schrieb Harald Oehlmann: >> Am 22.01.2025 um 16:33 schrieb Ralf Fassel: >>> * Ralf Fassel >>> | I recompiled vectcl 0.2.1 as provided by Paul against tcl 9.0 and >>> tcl 8.6.15. >>> | 'make test' in vectcl fails in many cases with tcl9, where the same >>> | tests succeed in 8.6.15. >>>> >>> |   package require vectcl >>> |   => 0.2.1 >>> | >>> |   numarray concat {{1.0 2.0} {3.0 4.0}} 5.0 0 >>> |   tcl 8 => {1.0 2.0} {3.0 4.0} {5.0 5.0} >>> |   tcl 9 => error: expected integer but got "1.0 2.0" >>> >>> Ok, being curious... >>> >>> The deeper reason for those failures is that vectcl uses type info for >>> TclObjs, and tcl9 no longer registers type 'int' (cf. >>> >>>      tclObj.c, >>>          const Tcl_ObjType tclIntType = { >>>                   "int",            /* name */ >>>                   ... >>>          }; >>>        void TclInitObjSubsystem(void) >>> >>>        8.6.15 >>>             Tcl_RegisterObjType(&tclIntType); >>>        9.0.0 >>>           --- >>> >>> >>> Now vectcl does in two places: >>> >>>     const Tcl_ObjType * tclIntType = Tcl_GetObjType("int"); >>> >>> and compares that in many places to the obj type >>> >>>     if (objPtr->typePtr == tclIntType) >>> >>> Since 'int' is not registered in 9.0, Tcl_GetObjType will return NULL >>> there, thus the vectcl code treats a not-set obj-type as int, which >>> explains the errors. >>> >>> Quick and dirty setting the vectcl lookup variables for >>> Tcl_GetObjType("int") to 0xdeadbeef if they are NULL makes all tests >>> succeed. >>> >>> >>> --- vectcl-0.2.1/generic/vectcl.c~    2025-01-22 12:50:45.750839906 >>> +0100 >>> +++ vectcl-0.2.1/generic/vectcl.c    2025-01-22 16:15:43.747690082 +0100 >>> @@ -2577,6 +2590,7 @@ >>>       tclListType =  (Tcl_ObjType *) Tcl_GetObjType("list"); >>>       tclDoubleType = Tcl_GetObjType("double"); >>>       tclIntType = Tcl_GetObjType("int"); >>> +    if (0 ==tclIntType) tclIntType = 0xdeadbeef; >>>   #ifndef TCL_WIDE_INT_IS_LONG >>>       tclWideIntType = Tcl_GetObjType("wideInt"); >>>   #endif >>> >>> >>> --- vectcl-0.2.1/generic/nacomplex.c~    2015-07-08 >>> 22:38:34.000000000 +0200 >>> +++ vectcl-0.2.1/generic/nacomplex.c    2025-01-22 16:18:04.682876166 >>> +0100 >>> @@ -67,7 +67,7 @@ >>>       /* Maybe this should go into a static const array */ >>>       const Tcl_ObjType * tclDoubleType = Tcl_GetObjType("double"); >>> -    const Tcl_ObjType * tclIntType = Tcl_GetObjType("int"); >>> +    const Tcl_ObjType * tclIntType = Tcl_GetObjType("int") || >>> 0xdeadbeef; >>> >>>       if (objPtr -> typePtr == tclIntType) { >>>           int value; >>> >>> % make test >>> Tests ended at Wed Jan 22 16:18:11 CET 2025 >>> all.tcl:    Total    210    Passed    210    Skipped    0    Failed    0 >>> >>> Of course this defeats the performance gains intended by the type >>> lookup, but since I don't know why "int" is no longer registered as type >>> in the tcl core, and what is to be used as substitution, I can not offer >>> any better fix for vectcl. >>> >>> R' >> >> Ralf, >> great that you found out, my appreciation ! >> >> The same question was raised by TkInter and PerlTk and solved with a >> new function. I loosely remember, that Tcl_GetNumber should now be >> used for this purpose: >> https://core.tcl-lang.org/tips/doc/trunk/tip/638.md >> >> This routine returns the integer type. I suppose, a test fir int is a >> result of "TCL_NUMBER_INT". >> >> Nevertheless, we still need Brian, as this "conversion" part was >> replaced by the new abstract layer. >> >> Thank you all, >> Harald >