From Newsgroup: comp.lang.tcl

Hello all,

Does VecTcl work with Tcl9? If not, are there any plans to update it so
it can? I see there is an old fork on github, but there are no binaries available for me to quickly test.

Thanks,

Jacob
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 20.01.2025 um 17:03 schrieb Jacob:

Hello all,

Does VecTcl work with Tcl9? If not, are there any plans to update it so
it can? I see there is an old fork on github, but there are no binaries available for me to quickly test.

Thanks,

Jacob

Hi Jacob,

unfortunately, this masterpiece is orphaned. The creator, Chrisitan G.,
does not plan to continue.

Brian Griffin did a proof of concept using the new Tcl Obj interface,
which allows to directly pass a vectcl number (float, bignum) to a Tcl
number without passing by a string representation and vice versa.

I am sure, Christian will assist anybody in the transition, but does not
want to do the work himself.

I already tried to motivate Torsten Berg to look into that...

Thank you all,
Harald
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 1/20/2025 11:20 PM, Harald Oehlmann wrote:

Am 20.01.2025 um 17:03 schrieb Jacob:

Hello all,

Does VecTcl work with Tcl9? If not, are there any plans to update it
so it can? I see there is an old fork on github, but there are no
binaries available for me to quickly test.

Thanks,

Jacob

Hi Jacob,

unfortunately, this masterpiece is orphaned. The creator, Chrisitan G.,
does not plan to continue.

Brian Griffin did a proof of concept using the new Tcl Obj interface,
which allows to directly pass a vectcl number (float, bignum) to a Tcl number without passing by a string representation and vice versa.

I am sure, Christian will assist anybody in the transition, but does not want to do the work himself.

I already tried to motivate Torsten Berg to look into that...

Thank you all,
Harald

Harald,

Thank you for your response. I find the package very useful as well.
Much of my work in tcl involves matrix operations on large datasets and translating code I first write in matlab. Vectcl is perfect for this. I
will stick with 8.6 for now.

Thanks,

Jacob
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* Jacob <JacobLambeth@clevelandgolf.com>
| On 1/20/2025 11:20 PM, Harald Oehlmann wrote:
| > Am 20.01.2025 um 17:03 schrieb Jacob:
| >> Hello all,
| >>
| >> Does VecTcl work with Tcl9? If not, are there any plans to update
| >> it so it can? I see there is an old fork on github, but there are
| >> no
| >> binaries available for me to quickly test.
| >>
--<snip-snip>--

| Thank you for your response. I find the package very useful as
| well. Much of my work in tcl involves matrix operations on large
| datasets and
| translating code I first write in matlab. Vectcl is perfect for
| this. I will stick with 8.6 for now.

According to

https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9

Paul has ported vectcl 0.2.1 to tcl 9. Maybe check that version?

HTH
R'
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 22.01.2025 um 11:03 schrieb Ralf Fassel:

* Jacob <JacobLambeth@clevelandgolf.com>
| On 1/20/2025 11:20 PM, Harald Oehlmann wrote:
| > Am 20.01.2025 um 17:03 schrieb Jacob:
| >> Hello all,
| >>
| >> Does VecTcl work with Tcl9? If not, are there any plans to update
| >> it so it can? I see there is an old fork on github, but there are
| >> no
| >> binaries available for me to quickly test.
| >>
--<snip-snip>--

| Thank you for your response. I find the package very useful as
| well. Much of my work in tcl involves matrix operations on large
| datasets and
| translating code I first write in matlab. Vectcl is perfect for
| this. I will stick with 8.6 for now.

According to

https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9

Paul has ported vectcl 0.2.1 to tcl 9. Maybe check that version?

HTH
R'

Yes, great ! Could you check, if Paul has integrated the enhancements by
Brian Griffin? IMHO this is quite important an boosts VecTCL on Tcl9.
IMHO, VecTcl will work much better with Tcl9 than Tcl8, as numbers are
passed as is.
I can moderate this and send an E-Mail to Paul and Brian (cc: magic Christian).

Thanks,
Harald
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 22.01.2025 um 11:12 schrieb Harald Oehlmann:

Am 22.01.2025 um 11:03 schrieb Ralf Fassel:

* Jacob <JacobLambeth@clevelandgolf.com>
| On 1/20/2025 11:20 PM, Harald Oehlmann wrote:
| > Am 20.01.2025 um 17:03 schrieb Jacob:
| >> Hello all,
| >>
| >> Does VecTcl work with Tcl9? If not, are there any plans to update
| >> it so it can? I see there is an old fork on github, but there are
| >> no
| >> binaries available for me to quickly test.
| >>
--<snip-snip>--

| Thank you for your response. I find the package very useful as
| well. Much of my work in tcl involves matrix operations on large
| datasets and
| translating code I first write in matlab. Vectcl is perfect for
| this. I will stick with 8.6 for now.

According to

   https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9

Paul has ported vectcl 0.2.1 to tcl 9.  Maybe check that version?

HTH
R'

Yes, great ! Could you check, if Paul has integrated the enhancements by Brian Griffin? IMHO this is quite important an boosts VecTCL on Tcl9.
IMHO, VecTcl will work much better with Tcl9 than Tcl8, as numbers are passed as is.
I can moderate this and send an E-Mail to Paul and Brian (cc: magic Christian).

Thanks,
Harald

I made changes (Tcl_size, etc.) to the original version 0.2, so that it compiles with Tcl9.
But the generated library throws errors, so it is marked as NoTcl9 in the latest BAWT release.
As I do not use vectcl personally, I did not invest more work to get it running with Tcl9.

Paul
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* Paul Obermeier <obermeier@poSoft.de>
| Am 22.01.2025 um 11:12 schrieb Harald Oehlmann:
| > Am 22.01.2025 um 11:03 schrieb Ralf Fassel:
| >> According to
| >>
| >>    https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9
| >>
| >> Paul has ported vectcl 0.2.1 to tcl 9.  Maybe check that version?
| >>
| >> HTH
| >> R'
| > Yes, great ! Could you check, if Paul has integrated the
| > enhancements by Brian Griffin? IMHO this is quite important an
| > boosts VecTCL on Tcl9.
| > IMHO, VecTcl will work much better with Tcl9 than Tcl8, as numbers are passed as is.
| > I can moderate this and send an E-Mail to Paul and Brian (cc: magic Christian).
| > Thanks,
| > Harald

| I made changes (Tcl_size, etc.) to the original version 0.2, so that it compiles with Tcl9.
| But the generated library throws errors, so it is marked as NoTcl9 in the latest BAWT release.

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"

| As I do not use vectcl personally, I did not invest more work to get it running with Tcl9.

A quick glance on the test failures does not offer anything obvious - the
test failures mostly derive from internal vectcl parsing errors (see
example above). So someone with deeper knowledge of vectcl is required here.

HTH
R'
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* 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'
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

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
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

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


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

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

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

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 23.01.2025 um 16:25 schrieb Brian Griffin:

I'll work on getting my VecTCL fork up-to-date with current Tcl 9.0,
then figure out what's next after that.

Great, I appreciate !

I'm curious what the harm is in keeping the "int" obj type in Tcl?

Jan explained it to Marc Culler when this issue hit TkInter.

What I understood:

- the registration method requires internals of Tcl.
- now, we have Tcl_GetNumber (TIP 638) which allow to query the internal integer type
- as a consequence, those integer types were removed from registration. Tcl_GetNumber is the tool to use instead of internal methods.

Take care,
Harald

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 1/23/2025 8:09 AM, Harald Oehlmann wrote:

Am 23.01.2025 um 16:25 schrieb Brian Griffin:

I'll work on getting my VecTCL fork up-to-date with current Tcl 9.0,
then figure out what's next after that.

Great, I appreciate !

I'm curious what the harm is in keeping the "int" obj type in Tcl?

Jan explained it to Marc Culler when this issue hit TkInter.

What I understood:

- the registration method requires internals of Tcl.
- now, we have Tcl_GetNumber (TIP 638) which allow to query the internal integer type
- as a consequence, those integer types were removed from registration. Tcl_GetNumber is the tool to use instead of internal methods.

Take care,
Harald

I can't contribute much, but I appreciate you guys helping with this.

-Jacob
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Just shortly joining in as my name was mentioned by Harald. Yes, I am
very much interested in having vectcl running on Tcl9 and would like to
invest some time to help. However, right now my resources are so limited
that I cannot even finish my other Tcl projects ...

Maybe, or hopefully, later this year, an opportunity comes up with some
spare time. But don't count on me.

Nonetheless, I really appreciate any effort on vectcl by others. It is
great to see it being pushed forward!!

Regards, Torsten
--- Synchronet 3.20c-Linux NewsLink 1.2