tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Documentation of the documentation command for 9.0

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

Am 14.06.2024 um 20:21 schrieb Poor Yorick:
> On 2024-06-14 18:25, Harald Oehlmann wrote:
>> Dear TCL team,
>>
>> the encoding command was revised with TCL 9.
>>
>> Many people contributed to this page. A rewrite is proposed by Nathan 
>> in the branch "encoding-for-review":
>>
>> https://core.tcl-lang.org/tcl/info/4d6aa33b2f
>>
>> Inspired from this change, a new version is proposed in the branch 
>> "encoding-for-review-alt":
>>
>> https://core.tcl-lang.org/tcl/info/f5243d7263ce854a
>>
> 
> The following excerpt is from the encoding-for-review-alt branch:
> 
> 
>      "Strings in a certain encoding are represented within Tcl as binary 
> data
>      and may not be handled as Tcl strings any more."
> 
> One of the main points of my original rewrite was to ensure that the reader
> understands that every value really is a string, including all values that
> represent "binary" data. Sentences like the one above are very 
> misleading to
> the newcomer trying to understand how to work with binary data in a 
> language
> where everything is a string.  It's also just straight-up incorrect. It's
> important to carefully articulate throughout the documentation that 
> there is no
> magical "binary" mode, and that every "binary" value really is just a 
> normal
> Unicode string.  Therefore the sentence above and all sentences like it 
> should
> be removed.
> 
> Also, documentation is uses singular case as much as possible is generally
> easier to read.  One technique to achieve this is to use the word "each" 
> and
> "every" in place of using other words in the plural case.
> 

Dear Nathan,
thanks, great. Yes, I feel it really difficult to make people understand 
what really happens. I tried to reword the "binary string" part.
What do you think now?

About "every" or "one" and "easier to read". That is an opinion, thanks 
for that.

Take care,
Harald

[TCLCORE] Proposal to add tcl::unsupported::icu command for Tcl 9

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

TL;DR motivation is to help users migrate scripts to Tcl 9.

 

For a longer description, see
https://core.tcl-lang.org/tcl/wiki?name=Unsupported+icu+command
<https://core.tcl-lang.org/tcl/wiki?name=Unsupported+icu+command&p> &p

 

Again, this is in the unsupported namespace so I am not sure whether a TIP
(and vote) is required or not. If required, I'll move the above wiki page to
a TIP.

 

Please voice objections if any. However, no functional enhancements or api
changes (it is very very basic) as the goal is to have migration tools in
some form for beta 3.

 

/Ashok

Re: [TCLCORE] Remove command tcl::unsupported::inject

[Steve L. <st...@di...>]

Agreed, as long as there is broad agreement (or rather no objection) and it is documented in the release notes.
On 16 Jun 2024 at 5:18 PM +0800, Jan Nijtmans <jan...@gm...>, wrote:
> Op zo 16 jun 2024 om 08:20 schreef Ashok:
> >
> > The tcl::unsupported::inject command has been superceded by the coroinject and coroprobe commands in Tcl 9.
> >
> > Is there any objection to removing it? There is no purpose in carrying around obsolete code imo.
> >
> > If there is no disagreement, is a TIP needed for this purpose?
>
> The "unsupported" means that it can be changed any moment,
> no objection from me. I wouldn't bother to write a TIP.
>
> Hope this helps,
> Jan Nijtmans
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Remove command tcl::unsupported::inject

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

Op zo 16 jun 2024 om 08:20 schreef Ashok:
>
> The tcl::unsupported::inject command has been superceded by the coroinject and coroprobe commands in Tcl 9.
>
> Is there any objection to removing it? There is no purpose in carrying around obsolete code imo.
>
> If there is no disagreement, is a TIP needed for this purpose?

The "unsupported" means that it can be changed any moment,
no objection from me. I wouldn't bother to write a TIP.

Hope this helps,
    Jan Nijtmans

[TCLCORE] Remove command tcl::unsupported::inject

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

The tcl::unsupported::inject command has been superceded by the coroinject
and coroprobe commands in Tcl 9.

 

Is there any objection to removing it? There is no purpose in carrying
around obsolete code imo.

 

If there is no disagreement, is a TIP needed for this purpose?

 

/Ashok

Re: [TCLCORE] Documentation of the documentation command for 9.0

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

Am 14.06.2024 um 20:21 schrieb Poor Yorick:
> On 2024-06-14 18:25, Harald Oehlmann wrote:
>> Dear TCL team,
>>
>> the encoding command was revised with TCL 9.
>>
>> Many people contributed to this page. A rewrite is proposed by Nathan 
>> in the branch "encoding-for-review":
>>
>> https://core.tcl-lang.org/tcl/info/4d6aa33b2f
>>
>> Inspired from this change, a new version is proposed in the branch 
>> "encoding-for-review-alt":
>>
>> https://core.tcl-lang.org/tcl/info/f5243d7263ce854a
>>
> 
> The following excerpt is from the encoding-for-review-alt branch:
> 
> 
>      "Strings in a certain encoding are represented within Tcl as binary 
> data
>      and may not be handled as Tcl strings any more."
> 
> One of the main points of my original rewrite was to ensure that the reader
> understands that every value really is a string, including all values that
> represent "binary" data. Sentences like the one above are very 
> misleading to
> the newcomer trying to understand how to work with binary data in a 
> language
> where everything is a string.  It's also just straight-up incorrect. It's
> important to carefully articulate throughout the documentation that 
> there is no
> magical "binary" mode, and that every "binary" value really is just a 
> normal
> Unicode string.  Therefore the sentence above and all sentences like it 
> should
> be removed.
> 
> Also, documentation is uses singular case as much as possible is generally
> easier to read.  One technique to achieve this is to use the word "each" 
> and
> "every" in place of using other words in the plural case.

Dear Nathan,
thank you for the comment, I appreciate. We may wait for one week to 
allow other persons to review.

Thank you again for taking your time,
Harald

Re: [TCLCORE] Documentation of the documentation command for 9.0

[Poor Y. <org...@po...>]

On 2024-06-14 18:25, Harald Oehlmann wrote:
> Dear TCL team,
> 
> the encoding command was revised with TCL 9.
> 
> Many people contributed to this page. A rewrite is proposed by Nathan 
> in the branch "encoding-for-review":
> 
> https://core.tcl-lang.org/tcl/info/4d6aa33b2f
> 
> Inspired from this change, a new version is proposed in the branch 
> "encoding-for-review-alt":
> 
> https://core.tcl-lang.org/tcl/info/f5243d7263ce854a
> 

The following excerpt is from the encoding-for-review-alt branch:


	"Strings in a certain encoding are represented within Tcl as binary 
data
	and may not be handled as Tcl strings any more."

One of the main points of my original rewrite was to ensure that the 
reader
understands that every value really is a string, including all values 
that
represent "binary" data. Sentences like the one above are very 
misleading to
the newcomer trying to understand how to work with binary data in a 
language
where everything is a string.  It's also just straight-up incorrect.  
It's
important to carefully articulate throughout the documentation that 
there is no
magical "binary" mode, and that every "binary" value really is just a 
normal
Unicode string.  Therefore the sentence above and all sentences like it 
should
be removed.

Also, documentation is uses singular case as much as possible is 
generally
easier to read.  One technique to achieve this is to use the word "each" 
and
"every" in place of using other words in the plural case.

-- 
yorick

[TCLCORE] Documentation of the documentation command for 9.0

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

Dear TCL team,

the encoding command was revised with TCL 9.

Many people contributed to this page. A rewrite is proposed by Nathan in 
the branch "encoding-for-review":

https://core.tcl-lang.org/tcl/info/4d6aa33b2f

Inspired from this change, a new version is proposed in the branch 
"encoding-for-review-alt":

https://core.tcl-lang.org/tcl/info/f5243d7263ce854a

Thank you for any comment and take care,
Harald

Re: [TCLCORE] CFV: TIP #697: 32-bit truncation in format and scan

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

 
> > I'm calling the votes on this TIP now.
> >
> > The voting period will finish Monday June 24,
> > noon UTC, [clock format 1719230400]

TIP #697: YES

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

Re: [TCLCORE] OpenACS/TCL/Tk conference: abstract deadline on 17th of June (next Monday)

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

Am 12.06.2024 um 19:35 schrieb Harald Oehlmann:
> Dear TCL/Tk enthusiasts,
> 
> great news from the Vienna conference:
> It will happen! Around 30 participants registered so far.
> 
> Next Monday, 17th of June 2024: deadline for title + abstracts
> It is a user meeting and it is alive by your contributions!
> Have a 15 or 30 minutes presentation and show us your solution!
> 
> As Gustaf, Stefan and myself will try to get a program ready the 18th, 
> it would be great to know who will give a presentation.
> There are again TCL and Tk pannels planned.
> 
> Any contribution around TCL/Tk 9 and others are welcome. CloudTk, 
> Androwish, Undroidwish, Markdown documentation, zip-Kits are also hot 
> topics. Future evolution of Tk with TkPath or other smoothed widgets, 
> New Text widget....
> 
> The registration for the conference ends on 30th of June.
> 
> You and your contributions are all welcome !
> 
> See you in Vienna,
> Harald

Please allow me to add the official way to register a title and an abstract.

If you are registered to the conference and logged in, you may press the 
button "Your registration" on:
https://openacs.org/conf2024/info/
At the very end of the following page, there is a button "Submit or 
Update Abstract".
One title/abstract may be added in the text boxes. Additional proposals 
may be added in the comment section.

Thank you for all !

Harald

Re: [TCLCORE] Some tests require Internet access

[Reinhard M. <rei...@m4...>]

Am 13.06.2024 21:12, schrieb Harald Oehlmann:

> Will you file a ticket or shall I do it for you?

https://core.tcl-lang.org/tcl/tktview/d0d47f81

cu
Reinhard

Re: [TCLCORE] CFV: TIP #697: 32-bit truncation in format and scan

[Steve L. <st...@di...>]

TIP #697: YES

-- Steve
On 13 Jun 2024 at 8:15 PM +0800, Jan Nijtmans <jan...@gm...>, wrote:
> I'm calling the votes on this TIP now.
>
> The voting period will finish Monday June 24,
> noon UTC, [clock format 1719230400]

Re: [TCLCORE] CFV: TIP #696

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

 
apnmbx-public--- via Tcl-Core writes:
> I have updated TIP 696 to reserve the code range [5 – 0x3fffffff] for packages/applications. Rationale is in the discussion section.
>
> Folks who have already voted, please resend if you change your vote else I’ll assume your original vote stands.
>
> Vote ends June 19, 2024 at 8am UTC.

TIP #696: Yes.

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

Re: [TCLCORE] Some tests require Internet access

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

Am 13.06.2024 um 16:29 schrieb Reinhard Max:
> Hi,
> 
> while preparing the SUSE RPMs for Tcl9 I came across some tests which 
> break in restricted build environments that have no internet access for 
> security reasons. More specifically some of the httpProxy tests try to 
> access www.google.com and fail like this:
> 
> ---- Test generated error; Return code was: 1
> ---- Return code should have been one of: 0 2
> ---- errorInfo: couldn't open socket: Temporary failure in name resolution
>      while executing
> "http::geturl http://www.google.com/"
> 
> I think depending on the intention of these tests they should either 
> have a constraint that skips them when there is no internet 
> connectivity, or they should use a local dummy web server instead of 
> reaching out to google.
> 
> cu
> Reinhard

Great finding. Will you file a ticket or shall I do it for you?

Thank you and take care,
Harald

Re: [TCLCORE] CFV: TIP #697: 32-bit truncation in format and scan

[Kevin W. <kw...@co...>]

<div><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/z95F4UYmlEU8sBIYHp4O1FYBH_EnNUFCUn_bfueMGgIjKCtez0LG4BZY4WUEmIFdgkhA0luq37lpkyrmv_lblRl4Sof0gF55exIfFadrLbEWaEBMkVLlfIHYZXbVgVgrsLQ37XJkKCWfr17Rp-HbgUuH9XDipFIszkyOb60sQTFZFDzcoqQIBgsF_YHWOT13kpXuuC0oUJQpYl9a2ApMWhSJ27I3yLQT' /></div>TIP 697: YES<br/><br/>> On Jun 13, 2024, at 8:13 AM, Jan Nijtmans <jan...@gm...> wrote:<br/>> <br/>> I'm calling the votes on this TIP now.<br/>> <br/>> The voting period will finish Monday June 24,<br/>> noon UTC, [clock format 1719230400]<br/>

Re: [TCLCORE] CFV: TIP #697: 32-bit truncation in format and scan

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

TIP #697: Yes

While there is a bit of incompatibility with 8.6, I much prefer the uniform
cross-platform and cross-architecture behaviour this TIP proposes.

/Ashok

-----Original Message-----
From: Jan Nijtmans <jan...@gm...> 
Sent: Thursday, June 13, 2024 5:43 PM
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] CFV: TIP #697: 32-bit truncation in format and scan

Op zo 9 jun 2024 om 18:42 schreef Jan Nijtmans:
>
> This is a CFV warning for TIP #697:
>     32-bit truncation in format and scan
>     <https://core.tcl-lang.org/tips/doc/trunk/tip/697.md>
....
> If you think this is a bad idea, speak up now. If not,
> I'll start the vote in a few days.

I'm calling the votes on this TIP now.

The voting period will finish Monday June 24,
noon UTC, [clock format 1719230400]

My vote:

TIP #697: YES

Regards,
         Jan Nijtmans


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

[TCLCORE] Some tests require Internet access

[Reinhard M. <rei...@m4...>]

Hi,

while preparing the SUSE RPMs for Tcl9 I came across some tests which 
break in restricted build environments that have no internet access for 
security reasons. More specifically some of the httpProxy tests try to 
access www.google.com and fail like this:

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: couldn't open socket: Temporary failure in name 
resolution
     while executing
"http::geturl http://www.google.com/"

I think depending on the intention of these tests they should either 
have a constraint that skips them when there is no internet 
connectivity, or they should use a local dummy web server instead of 
reaching out to google.

cu
Reinhard

Re: [TCLCORE] CFV: TIP #697: 32-bit truncation in format and scan

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

Am 13.06.2024 um 14:12 schrieb Jan Nijtmans:
> Op zo 9 jun 2024 om 18:42 schreef Jan Nijtmans:
>>
>> This is a CFV warning for TIP #697:
>>      32-bit truncation in format and scan
>>      <https://core.tcl-lang.org/tips/doc/trunk/tip/697.md>
> ....
>> If you think this is a bad idea, speak up now. If not,
>> I'll start the vote in a few days.
> 
> I'm calling the votes on this TIP now.
> 
> The voting period will finish Monday June 24,
> noon UTC, [clock format 1719230400]
> 
> My vote:
> 
> TIP #697: YES

Yes

Thanks for all the work,
Harald

[TCLCORE] CFV: TIP #697: 32-bit truncation in format and scan

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

Op zo 9 jun 2024 om 18:42 schreef Jan Nijtmans:
>
> This is a CFV warning for TIP #697:
>     32-bit truncation in format and scan
>     <https://core.tcl-lang.org/tips/doc/trunk/tip/697.md>
....
> If you think this is a bad idea, speak up now. If not,
> I'll start the vote in a few days.

I'm calling the votes on this TIP now.

The voting period will finish Monday June 24,
noon UTC, [clock format 1719230400]

My vote:

TIP #697: YES

Regards,
         Jan Nijtmans

Re: [TCLCORE] CFV: TIP #696

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

 

Well, the presence of a trap for code has nothing to do with the need of
such "registry". 

Maybe it is expected to catch continue or break (or other default tcl
codes) additionally to the error...
Maybe the package throws the integer codes internally and the traps
takes place also inside the package
or in some related packages using the former as a library, then it the
code is totally irrelevant for outside. 

What I just wanted to say is - the necessity for lookup against such a
registry makes the code dynamic 
and not static anymore, so the whole thing has no advantages against the
errorcode, at least at the script side.

On the C-side it is indeed possible to store the offset/range to some
static variables and use them, but... 

 	* if it happens completely internal (throwing and traps inside the
package), one doesn't need the registry at all.

	* if the code leaves the package, then the caller would need some
lookup,
and if it lands in tcl-script it must be then stored in some const or
variable, so it is again senseless (makes no difference to the errorcode
compare/lookup). 

Also just to clarify the discussion.

Regards,
Serg. 

13.06.2024 10:09, Gustaf Neumann wrote: 

> On 11.06.24 17:10, Dipl. Ing. Sergey G. Brester via Tcl-Core wrote: 
> 
>> I don't see the pros of that model, at least at tcl-script level (however also at C-level)...
> 
> Well, to make it more clear: on the Tcl level we are talking about the differences between 
> 
> % proc f1 {} {return -code 5} 
> % try {f1} on 5 {errorMsg d} {puts "ON 5 // $d"}
> ON 5 // -code 5 -level 0
> 
> and 
> 
> % proc f2 {} {throw 6 ""}
> % try {f2} trap 6 {errorMsg d} {puts "TRAP 6 // [dict replace $d -errorinfo ...]"}
> TRAP 6 // -errorcode 6 -code 1 -level 0 -errorstack {INNER {returnImm {} {-errorcode 6}} CALL f2} -errorinfo ... -errorline 1
> 
> Note the difference between "on 5" vs. "trap 6". There is the question, whether we need constructs like "return -code /integer/". I see very little benefit on that feature, room for confusion, and some dangers. Since we have this in Tcl for many years, and there is code using it, this ship has sailed. The other question is, since we have the user-supplied value for "-code", do we want to make it more secure (cross package) and more general. That was the idea of the "registry". 
> 
> ... just to clarify the discussion. 
> -g 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [1]
 

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV: TIP #696

[Gustaf N. <ne...@wu...>]

On 11.06.24 17:10, Dipl. Ing. Sergey G. Brester via Tcl-Core wrote:
>
> I don't see the pros of that model, at least at tcl-script level 
> (however also at C-level)...
>
Well, to make it more clear: on the Tcl level we are talking about the 
differences between

    % proc f1 {} {return -code 5}
    % try {f1} on 5 {errorMsg d} {puts "ON 5 // $d"}
    ON 5 // -code 5 -level 0

and

    % proc f2 {} {throw 6 ""}
    % try {f2} trap 6 {errorMsg d} {puts "TRAP 6 // [dict replace $d -errorinfo ...]"}
    TRAP 6 // -errorcode 6 -code 1 -level 0 -errorstack {INNER {returnImm {} {-errorcode 6}} CALL f2} -errorinfo ... -errorline 1

Note the difference between "on 5" vs. "trap 6". There is the question, 
whether we need constructs like "return -code /integer/". I see very 
little benefit on that feature, room for confusion, and some dangers. 
Since we have this in Tcl for many years, and there is code using it, 
this ship has sailed. The other question is, since we have the 
user-supplied value for "-code", do we want to make it more secure 
(cross package) and more general. That was the idea of the "registry".
... just to clarify the discussion.
-g

[TCLCORE] OpenACS/TCL/Tk conference: abstract deadline on 17th of June (next Monday)

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

Dear TCL/Tk enthusiasts,

great news from the Vienna conference:
It will happen! Around 30 participants registered so far.

Next Monday, 17th of June 2024: deadline for title + abstracts
It is a user meeting and it is alive by your contributions!
Have a 15 or 30 minutes presentation and show us your solution!

As Gustaf, Stefan and myself will try to get a program ready the 18th, 
it would be great to know who will give a presentation.
There are again TCL and Tk pannels planned.

Any contribution around TCL/Tk 9 and others are welcome. CloudTk, 
Androwish, Undroidwish, Markdown documentation, zip-Kits are also hot 
topics. Future evolution of Tk with TkPath or other smoothed widgets, 
New Text widget....

The registration for the conference ends on 30th of June.

You and your contributions are all welcome !

See you in Vienna,
Harald

Re: [TCLCORE] CFV: TIP #696

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

Not to drag this out or split hairs, but I don’t see *partitioning* the space as special privileges to the core (you can view it as *removal* of privilege from the core to use codes outside its range!) any more than saying the ::tcl:: namespace is a special privilege to the core.

 

 

From: Kevin Kenny <kev...@gm...> 



 

So I think I'd answer Ashok's question with, 'no, you don't need to reserve a range.' (It also goes somewhat against the grain with me to reserve special privileges to the Core. In most cases, what the Core can do, extensions should be able to do.)

 

-- 

73 de ke9tv/2, Kevin

Re: [TCLCORE] CFV: TIP #696

[Kevin K. <kev...@gm...>]

On Tue, Jun 11, 2024 at 11:10 AM Dipl. Ing. Sergey G. Brester <
se...@us...> wrote:

> The return code as integer has more or less only one advantage - you don't
> need a string compare or a hash-lookup if catching the error.
>
> The necessity to make a lookup in registry by literal string makes it
> totally senseless, because one displaces such a lookup from catch-block to
> the throw-block. Nothing else.
> Sore a C-extension could obtain a range (or offset) once by init and store
> registered offset somewhere inside itself in a static variable, but the
> catching block should anyway know this offset to be able identify it.
> So I'm a bit confused about the sense of this model
>

Rather than errors, I'm thinking of entirely different control structures
that could possibly need codes other than 'break', 'continue' and
'return'.

Random ideas, which may not be good ones, would include multi-level break
(exit more than one nested loop at once); similarly, multi-level continue.

 Or a 'little language' compiling to bytecode, where a return code could be
'next state' of an automaton, or a parser action (shift <next state>,
reduce <producion>, accept, reject),

Or a tidying-up of the kind of confusing implementation of tailcall and
coroutine operations.

And with these things not being 'errors', they might not be rare, so the
cost of invoking the whole error mechanism (with stack backtrace,
messages+codes, and the like) could be significant.

But with that said, these ideas may NOT be good ones.  The only odd return
code that I'm aware of is [exp::continue -expect] in the 'expect'
extension, which is indeed a multi-level 'continue' - out to the implicit
loop in an [exp::expect[ operation.  In  the thirty-odd years since
[continue] was added, nobody seems to have needed a new Core return code.
I was trying to point out that Gustav's idea of a registry means that we
don't actually need a reserved space. If someone comes up with an idea that
needs a new return code in the Tcl core, the same registry would be
available to the core.

So I think I'd answer Ashok's question with, 'no, you don't need to reserve
a range.' (It also goes somewhat against the grain with me to reserve
special privileges to the Core. In most cases, what the Core can do,
extensions should be able to do.)

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] CFV: TIP #696

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

Sergey, not to speak for Kevin or Gustaf but I think they were contemplating looking up or registering the literal just once at extension startup and tucking away the corresponding integer value somewhere for further use.

 

From: Dipl. Ing. Sergey G. Brester via Tcl-Core <tcl...@li...> 
Sent: Tuesday, June 11, 2024 8:41 PM
To: Kevin Kenny <kev...@gm...>
Cc: tcl...@li...; Gustaf Neumann <ne...@wu...>
Subject: Re: [TCLCORE] CFV: TIP #696

 

I don't see the pros of that model, at least at tcl-script level (however also at C-level)...

the process of checking or obtaining of the return code by name in such registry makes the sense of the whole action questionable.

Then why just not simply code "error" and some list as "errorcode" with literal and numeric code? I mean:

return -code error -errorcode {MYEXT ECODE 123456} whatever
# or even only numeric with an extension-prefix:
return -code error -errorcode MYEXT-123456 whatever

The return code as integer has more or less only one advantage - you don't need a string compare or a hash-lookup if catching the error.
The necessity to make a lookup in registry by literal string makes it totally senseless, because one displaces such a lookup from catch-block to the throw-block. Nothing else.
Sore a C-extension could obtain a range (or offset) once by init and store registered offset somewhere inside itself in a static variable, but the catching block should anyway know this offset to be able identify it. 
So I'm a bit confused about the sense of this model.

Regards,
Sergey.

10.06.2024 23:30, Kevin Kenny wrote:

On Mon, Jun 10, 2024 at 4:31 AM Gustaf Neumann <ne...@wu... <mailto:ne...@wu...> > wrote:

> A registry type system is not workable in practice I was considering lightweight registry like [returncode foo]. When the command is called the first time (no "foo" returncode registered), it returns a fresh number from the user number space introduced by the TIP. When "foo" was already registered as a return code, it returns the previous result. Naming could be married to the packaging system by adding a prefix to the name [returncode tree::prune] (tcllib example that Rolf posted). Also, the system return codes can be looked up and used the same way ([returncode error]). One could add flags for e.g. returning numbers from the negative space, etc.

 

That's a really interesting idea: allow extensions to create a symbolic name and then use that name throughout the extension (and its callers), while avoiding any conflict with other extensions.  The actual return code may differ depending on what other extensions may have claimed return codes, but as long as everything goes by symbolic name, it'll all work.  The name probably has to be process-global rather than interp-local, because [return -code] to a caller in another interp is possible, which means that there's the cost of a synchronization operation every time we look up a code, although since codes ought never to be deleted, I suppose we could have an interp-local mirror of the dictionary that's consulted first. Another thing to hang off the ekeko!

 

-- 

73 de ke9tv/2, Kevin

 

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