Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Brian Griffin <bgriffinfortytwo@gmail.com>
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: <vmtn1o$1m5v8$1@dont-email.me>
References: <vmls4q$38g47$1@dont-email.me> <vmnhsp$3srvj$1@dont-email.me>
 <2af45bfa-e1ae-4a45-90c3-83af0678f820@clevelandgolf.com>
 <ygajzan4148.fsf@akutech.de> <vmqg9i$uqf1$1@dont-email.me>
 <vmqh3r$usa2$1@dont-email.me> <ygafrla5329.fsf@akutech.de>
 <ygaa5bi50en.fsf@akutech.de> <vmr8lo$13nsn$2@dont-email.me>
 <vmtia1$1h979$1@dont-email.me>
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: <vmtia1$1h979$1@dont-email.me>
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 <ralfixx@gmx.de>
>>> | 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
>