tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] CFV: TIP #696

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

The reserved range can always be “opened” for this purpose if this proposed registry idea goes through so I do not see this as any future incompatibility. In fact the opposite, because then a registry could be implemented within the reserved space without fear of conflict with existing extensions.

 

Having said that I’m somewhat skeptical of the usability at the C level. While as an extension writer, I can just “return MYCODE” or do a Tcl_Eval+switch at the call site; with the registry scheme, there is more involved. Not rocket science but feels like over-engineering for the problem being solved. It would be different if these codes were needed in large numbers but that is not the case.

 

But, all that for a future discussion. Right now, I only need to know whether to reserve a range or not 😊

 

/Ashok

 

 

 

From: Kevin Kenny <kev...@gm...> 
Sent: Tuesday, June 11, 2024 8:18 PM
To: Gustaf Neumann <ne...@wu...>
Cc: tcl...@li...
Subject: Re: [TCLCORE] CFV: TIP #696

 

And then another thing occurs to me:  If we have this registry, and Tcl ever needs a new return code, it can use the same mechanism that extensions do to claim it. There would be no need for a reserved range, except for the legacy numbers 0-4.

 

 

On Tue, Jun 11, 2024 at 4:22 AM Gustaf Neumann <ne...@wu... <mailto:ne...@wu...> > wrote:

 

On 10.06.24 23:30, Kevin Kenny wrote:

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!

Yes, to be on the safe side, the registry has to be global (with a lock), but can be cached e.g. per interp (or in Tcl_Objs) if wanted, since the values are immutable. I have doubts that a performance improvement through caching will be a notable difference for real applications.

-g




 

-- 

73 de ke9tv/2, Kevin

Re: [TCLCORE] CFV: TIP #696

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

 

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...> 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...
> 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 16:48, Kevin Kenny wrote:
> And then another thing occurs to me:  If we have this registry, and 
> Tcl ever needs a new return code, it can use the same mechanism that 
> extensions do to claim it. There would be no need for a reserved 
> range, except for the legacy numbers 0-4.

right. But on the C-level the reserved range is still a good thing.

In the scripting level, we could consider passing the symbolic name to 
"-code" without the need of a [returncode ...]. This could be made full 
backward compatible, since the "legacy" numeric values (like 6 or 7) are 
just badly chosen names.

-g

Re: [TCLCORE] CFV: TIP #696

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

And then another thing occurs to me:  If we have this registry, and Tcl
ever needs a new return code, it can use the same mechanism that extensions
do to claim it. There would be no need for a reserved range, except for the
legacy numbers 0-4.


On Tue, Jun 11, 2024 at 4:22 AM Gustaf Neumann <ne...@wu...> wrote:

>
> On 10.06.24 23:30, Kevin Kenny wrote:
>
> 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!
>
> Yes, to be on the safe side, the registry has to be global (with a lock),
> but can be cached e.g. per interp (or in Tcl_Objs) if wanted, since the
> values are immutable. I have doubts that a performance improvement through
> caching will be a notable difference for real applications.
>
> -g
>


-- 
73 de ke9tv/2, Kevin

[TCLCORE] TCL/Tk documentation action

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

Dear Tcl/Tk team,

this week is documentation week of Tcl and Tk. Lets celebrate it!
A documentation team around Torsten Berg has made great progress and 
proposes a future documentation system:
- documentation is written in markdown (Pandoc flavour)
- this source is converted to nroff, html and possibly other formats 
using the pandoc.org toolchain.
One aim of this move is to lower the barrier for documentation writers 
compared to the current nroff format while retaining the current nroff 
format for those who need it.

To achieve this aim, the following steps will take place:

1) Torsten will create a branch named 
"documentation-cleanup-for-transition" from main on Tcl and Tk to:
a) correct obvious content errors (like namespace separator only one ":")
b) change structural constructs in nroff which would not work with the 
automated transformation process. E.g., some man-pages feature 
structural issues and direct formatting instead of chapter marking etc.

The aim of this branch is to be a mirror of the main branches, but with 
these issues corrected.

2) a TIP will be started describing the documentation process.

The new documentation will be incorporated in a Tcl/Tk release when it 
is considered ready with no fixed timescale at this stage.
I am very happy that Torsten will be in Vienna in person and we may 
discuss this further at the TCL/Tk user meeting.

Thank you all,
Harald

---END---

You guys rock !
Harald

Re: [TCLCORE] CFV: TIP #696

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

On 10.06.24 23:30, Kevin Kenny wrote:
> 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!
Yes, to be on the safe side, the registry has to be global (with a 
lock), but can be cached e.g. per interp (or in Tcl_Objs) if wanted, 
since the values are immutable. I have doubts that a performance 
improvement through caching will be a notable difference for real 
applications.

-g

Re: [TCLCORE] CFV: TIP #696

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

On 10.06.24 16:49, apnmbx-public--- via Tcl-Core wrote:
>
> Hi Gustaf,
>
> Regarding your first point, not really adding any new functionality to Tcl
>
true
>
> or new advertising for use of return codes.
>
partly true. As a Tcl veteran, I have never dared to use my own return 
codes, ... but since the number ranges are now nice separated, and it 
will go to the changelog this is some kind of (unintended) advertisement.
>
> This is already present in the documentation, and in use in several 
> extensions so the problem you mention already exists.
>
Probably a warning note in the documentation (number separation is a 
user concern) can improve the feeling in my stomach.

> The TIP merely removes Tcl itself from conflicting with extensions 
> (assuming they follow the reserved space).
>
Sure, i am not arguing against the TIP. Make it clear, what's reserved 
to Tcl internally is the right thing to do!

-g

Re: [TCLCORE] CFV: TIP #696

[Rolf A. <tcl...@po...>]

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.

That thing is fine now; other ideas in this area are out of scope of
this TIP.

rolf

>
>  
>
> From: apnmbx-public--- via Tcl-Core <tcl...@pu...> 
> Sent: Friday, June 7, 2024 8:33 PM
> To: tcl...@pu...
> Subject: Re: [TCLCORE] CFV: TIP #696
>
>  
>
> Conflicts between user defined codes, like user defined namespaces,
> are unfortunately not tractable. A registry type system is not
> workable in practice – at least one was proposed many moons ago
> (https://www.nist.gov/publications/managing-tcls-namespaces-collaboratively)
> – but difficult to publicise and have people follow it. Best to choose
> a code at random if it is not private.
>
>  
>
> Not quite sure what you mean by exception handling. Return codes are a mechanism between C level calls as well.
>
>  
>
> /Ashok
>
>  
>
> From: Gustaf Neumann <neu...@pu... <mailto:neu...@pu...> > 
> Sent: Friday, June 7, 2024 11:59 AM
> To: tcl...@pu... <mailto:tcl...@pu...> 
> Subject: Re: [TCLCORE] CFV: TIP #696
>
>  
>
> On 06.06.24 23:05, Rolf Ade wrote: 
>
> I was too dense; sorry. You are right that in general the standard
> return codes ok, error, return, break and continue can be specified as
> symbols.
>
>  
>
> Has someone considered interactions between user-defined return codes?
> One could introduce a "registry" for return-codes to guarantee that
> there is no clash. Application could use e.g. a package specific name
> and get via this a fresh or already allocated value. This would reduce
> the chance of clashes. For NaviServer this is not an issue, since the
> NaviServer return codes are used only internally using its own type
> Ns_ReturnCode. Application specific error handling is performed via
> try + application specific error codes. Shouldn't exception handling
> anyhow be the recommended way for such kinds of problems on the Tcl
> level?
>
> all the best -g 
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@pu...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV: TIP #696

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

On Mon, Jun 10, 2024 at 4:31 AM Gustaf Neumann <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

[TCLCORE] Behaviour of deleting an image attached to a label (Bug or feature?)

[Paul O. <pa...@po...>]

1. Create an image and attach it to a label.
2. Then delete the label. The label keeps size and displays an empty image, as is described in man page "image delete".
3. Now doing something with the label gives an error message: image "img" doesn't exist

Is this the expected behaviour or a bug?

Thanks, Paul

package require Tk

image create photo img -width 100 -height 30
img put red -to 10 10 90 20

label .l -borderwidth 0 -background white -image img
pack .l -padx 8p -pady 8p

after 1000 {
     puts "Deleting"
     image delete img
}

after 3000 {
     puts "Configuring"
     .l configure -background yellow
}

Re: [TCLCORE] Improvements to the wording of the Tcl rules.

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

On 2024-06-10 17:01, Jan Nijtmans wrote:
> Op ma 10 jun 2024 om 15:35 schreef Jan Nijtmans:
>> Your change:
>>     For example, \fBTcl_SetObjResult\fR accepts a Tcl_Obj
>>     and \fBTcl_SetResult\fR accepts a char *.
>> That's not only wrong (it should be "Tcl_Obj *", not "Tcl_Obj")
>> but also unnecessary: The header already contains the
>> exact function signature, there's no need to repeat that
>> again in each function description.
> 
> If you want an example of a good commit message,
> have a look at this one:
>     Updated the language of the documentation so that
>     "object" refers to an OO concept throughout, and a
>     Tcl_Obj is called a "value" (which is what it is)
>     date: 2012-11-08 user: dkf
>     https://core.tcl-lang.org/tcl/info/d664748a86b7b8b5
> 
> Your changes partially undid dkf's changes from
> 2012, so it's your task to start a discussion, whether
> dkf's change referring to "value" is a mistake or not.
> 
> Hope this helps,
>         Jan Nijtmans


These issues could easily be taken care of in a few minutes without a
reversion.  By wielding the power of reversion with a heavy hand you all 
are
basically arbitrarily shutting down the ability of people to contribute. 
  But I
get the message.  I'll take my development efforts elsewhere.  I never 
got the
sense that people valued them much anyway.

-- 
Yorick

Re: [TCLCORE] CFV: TIP #696

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

Hi Gustaf,

 

Regarding your first point, not really adding any new functionality to Tcl or new advertising for use of return codes. This is already present in the documentation, and in use in several extensions so the problem you mention already exists. The TIP merely removes Tcl itself from conflicting with extensions (assuming they follow the reserved space).

 

Regarding your second point, sure a scheme like you suggest could be explored a la atoms in Windows. That would be a different TIP though and attending implementation.

 

/Ashok

 

From: Gustaf Neumann <ne...@wu...> 
Sent: Monday, June 10, 2024 2:00 PM
To: tcl...@li...
Subject: Re: [TCLCORE] CFV: TIP #696

 

On the Tcl level, many situations can be solved with both, with exceptions and with return codes. There are cases, where exceptions are more powerful. I am not happy by advertising a light-weight alternative path leading to foreseeable problems with interactions of packages. How can one safely use Tcl packages, where every Tcl package is free to register the same return-code, … or where someone refactors code introducing new Tcl return codes between releases? I see potential problems from the maintenance and debugging point of view. > 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. 

All the best -g 

Re: [TCLCORE] Improvements to the wording of the Tcl rules.

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

Nathan,

There is a fundamental disconnect between your preferred mode of working and
well, pretty much everyone else. This is true not only for documentation but
code as well. You have expressed disdain before for the TIP process and
(paraphrasing) preferred a style where people commit stuff and people who
disagree can change it or revert back and forth. You specifically said this
about the wiki as well, where you made changes that the original authors of
the pages expressly objected to. Paraphrasing again, "if you don't like the
changes, revert it"

I will not say your style just creates chaos for everyone working off the
code base only because we will just get into another argument. I'll just say
instead that it is not the process followed in this group. For any
*significant* changes, whether code or documentation, the process to be
followed is to branch or TIP, have it reviewed, then merge into trunk.

Not the reverse.

No one is arguing about whether your changes to the manpages are warranted
or not. The point is major changes like that must be reviewed *before*
commit to trunk, not after.

We already discussed Tcl.n where it is not clear *if* there  are semantic
changes or not or whether it is more readable (sorry, your single opinion
does not carry more weight than anyone else's). I already pointed out your
removal of the words "when the underlying device is ready" from the chan
manpage section on events, which *is* a semantic change whether inadvertent
or made to bolster rationale for your code changes to generate I/O events
irrespective of channel state.

That is why review is necessary. And expecting review *without* even
announcing a significant change has been made is not workable. No one
reviews every commit. And then if there is a back and forth on the trunk for
disputed changes, it is just chaotic for everyone else working on the code
base.

Please, for significant changes,

- work on a branch
- ask for a review
- commit

/Ashok

PS Committing under the fig leaf of a "bug fix" is equally avoidable.



-----Original Message-----
From: Poor Yorick <org...@po...> 
Sent: Monday, June 10, 2024 6:11 PM
To: tcl...@li...
Subject: Re: [TCLCORE] Improvements to the wording of the Tcl rules.

On 2024-06-10 14:19, Jan Nijtmans wrote:
> Op wo 15 mei 2024 om 10:44 schreef Poor Yorick:
>> I've done some extensive work on the Tcl documentation in the past.  
>> One
>> example is chan.n, where I reduced the word count by 40%:
>> 
>>         https://core.tcl-lang.org/tcl/info/eb627bda27968937int
>> 
>> Another example is SetResult.3, where I reduced the word count by 46%.
>> 
>>         https://core.tcl-lang.org/tcl/info/8dba618fe6b6f8bb
>> 
>> Both of these pages are significantly more readable as a result.
> 
> Today, in the TCT meeting, it was decided to back out those
> changes from trunk, and move them aside to its own
> branch in order to be reviewed properly later. So, your
> rewrite is not going to be thrown away.
> 
> Harald already asked you, 2 weeks ago, to do this
> backout, and put up those changes for review. But
> it doesn't look like you have time to do that.
> 

What is the rationale for backing these contributions out?  Where there
mistakes identified that were not easily correctable?  If not, that's 
the wrong
way to go about things.  A contribution should stand unless there is a
particular problem with it.  The work on SetResult.3 required 80 hours 
to
complete.  Someone should review it and note any deficiencies *before*
reverting it, not after.

-- 
Yorick



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

Re: [TCLCORE] Improvements to the wording of the Tcl rules.

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

Op ma 10 jun 2024 om 15:35 schreef Jan Nijtmans:
> Your change:
>     For example, \fBTcl_SetObjResult\fR accepts a Tcl_Obj
>     and \fBTcl_SetResult\fR accepts a char *.
> That's not only wrong (it should be "Tcl_Obj *", not "Tcl_Obj")
> but also unnecessary: The header already contains the
> exact function signature, there's no need to repeat that
> again in each function description.

If you want an example of a good commit message,
have a look at this one:
    Updated the language of the documentation so that
    "object" refers to an OO concept throughout, and a
    Tcl_Obj is called a "value" (which is what it is)
    date: 2012-11-08 user: dkf
    https://core.tcl-lang.org/tcl/info/d664748a86b7b8b5

Your changes partially undid dkf's changes from
2012, so it's your task to start a discussion, whether
dkf's change referring to "value" is a mistake or not.

Hope this helps,
        Jan Nijtmans

Re: [TCLCORE] Improvements to the wording of the Tcl rules.

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

Op ma 10 jun 2024 om 14:41 schreef Poor Yorick:
> Where there
> mistakes identified that were not easily correctable?

There's a review branch now, "setresult-for-review":
    <https://core.tcl-lang.org/tcl/vdiff?from=1050f25f82e7276f&to=61b226d13e1fb496>

The most important thing I note is that the original
file had a "REFERENCE COUNT MANAGEMENT"
section which you totally removed. The information in
this section, you distributed among the separate
commands. I don't think that's an improvement:
It's better to clarify the ideas in one place, and
then keep each function description shorter.

That's the type of discussion that should be
held before making such a change, which
didn't happen. The original commit message
just tells:
    "Rewrite documentation file SetResult.3",
not
    "Scatter documentation about reference count management all over the place"

And .... if this really was an improvement, why was
this change never backported to 8.7 and 8.6?

Another thing I noted are changes like this:
Original:
    For example, \fBTcl_SetObjResult\fR and \fBTcl_SetResult\fR
    set the interpreter result to, respectively, a value and a string.
Your change:
    For example, \fBTcl_SetObjResult\fR accepts a Tcl_Obj
    and \fBTcl_SetResult\fR accepts a char *.
That's not only wrong (it should be "Tcl_Obj *", not "Tcl_Obj")
but also unnecessary: The header already contains the
exact function signature, there's no need to repeat that
again in each function description.

So far, my first review remarks.

Regards,
      Jan Nijtmans

Re: [TCLCORE] Improvements to the wording of the Tcl rules.

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

Am 10.06.2024 um 14:40 schrieb Poor Yorick:
> On 2024-06-10 14:19, Jan Nijtmans wrote:
>> Op wo 15 mei 2024 om 10:44 schreef Poor Yorick:
>>> I've done some extensive work on the Tcl documentation in the past. One
>>> example is chan.n, where I reduced the word count by 40%:
>>>
>>>         https://core.tcl-lang.org/tcl/info/eb627bda27968937int
>>>
>>> Another example is SetResult.3, where I reduced the word count by 46%.
>>>
>>>         https://core.tcl-lang.org/tcl/info/8dba618fe6b6f8bb
>>>
>>> Both of these pages are significantly more readable as a result.
>>
>> Today, in the TCT meeting, it was decided to back out those
>> changes from trunk, and move them aside to its own
>> branch in order to be reviewed properly later. So, your
>> rewrite is not going to be thrown away.
>>
>> Harald already asked you, 2 weeks ago, to do this
>> backout, and put up those changes for review. But
>> it doesn't look like you have time to do that.
>>
> 
> What is the rationale for backing these contributions out?  Where there
> mistakes identified that were not easily correctable?  If not, that's 
> the wrong
> way to go about things.  A contribution should stand unless there is a
> particular problem with it.  The work on SetResult.3 required 80 hours to
> complete.  Someone should review it and note any deficiencies *before*
> reverting it, not after.

To be respectful.

Thank you for your understanding,
Harald

Re: [TCLCORE] Improvements to the wording of the Tcl rules.

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

On 2024-06-10 14:19, Jan Nijtmans wrote:
> Op wo 15 mei 2024 om 10:44 schreef Poor Yorick:
>> I've done some extensive work on the Tcl documentation in the past.  
>> One
>> example is chan.n, where I reduced the word count by 40%:
>> 
>>         https://core.tcl-lang.org/tcl/info/eb627bda27968937int
>> 
>> Another example is SetResult.3, where I reduced the word count by 46%.
>> 
>>         https://core.tcl-lang.org/tcl/info/8dba618fe6b6f8bb
>> 
>> Both of these pages are significantly more readable as a result.
> 
> Today, in the TCT meeting, it was decided to back out those
> changes from trunk, and move them aside to its own
> branch in order to be reviewed properly later. So, your
> rewrite is not going to be thrown away.
> 
> Harald already asked you, 2 weeks ago, to do this
> backout, and put up those changes for review. But
> it doesn't look like you have time to do that.
> 

What is the rationale for backing these contributions out?  Where there
mistakes identified that were not easily correctable?  If not, that's 
the wrong
way to go about things.  A contribution should stand unless there is a
particular problem with it.  The work on SetResult.3 required 80 hours 
to
complete.  Someone should review it and note any deficiencies *before*
reverting it, not after.

-- 
Yorick

Re: [TCLCORE] [chan postevent] must be asynchronous

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

On 2024-06-10 09:54, Andreas Kupries wrote:

[SNIP]
> 
> And this follow-up I then translated as
> 
>    I know better than you (what reality should be)


Well, I'm making an argument, I laid out my case, and think it's 
correct.  Call
it arrogant, call it condescending, call it gaslighting, call it me 
thinking I
know better than you, but the only thing that's really interesting is 
whether
its correct.  People bring too much ego to debates like this.  I hope to
persuade you of what I see in the code: Tcl_NotifyChannel() is actually 
called
as part of an asynchronous operation.  I expected you to sit back, 
review the
code, and then perhaps think to yourself, "You know, he's got a point.  
Maybe I
missed that when I was intensely coding in order to stand up the first
implementation of refchans."  I expected you to then ponder the 
relationship of
select() and Tcl_NotifyChannel(), and possibly come to the conclusion 
that
[chan postevent] really is an analogue to select() even though at the 
time you
considered it to be the refchan analogue to Tcl_NotifyChannel.  Early
implementations often miss subtle points like this.  I come up with 
stuff all
the time that I think is brilliant, only to find out a few months later 
that
there was a more elegant and "correct" design.

You didn't respond to my technical arguments, and neither did Harald or 
Kevin.
It seems that people want to discuss everything *but* the technical 
details
here.  I think the argument I made in my last post about the 
relationship of
[chan postevent] to Tcl_NofifyChannel() and to select(), and then about 
the
different levels these functions operate at according to the perspective 
of the
event loop, is a very good one.

You've made some great contributions to Tcl, and your place in the 
history of
Tcl is secure.  I haven't contributed new feature sets to Tcl but I have 
spent
a lot of time fixing bugs and I happen to think people have generally
overlooked the weight of my contributions.  For a decade and a half I've
steadily been tracking down difficult and subtle bugs, and some of them 
have
been pretty significant.  For example, until 2013, the tar module in 
Tcllib
silently corrupted tar files in some cases.  Here is my bug report about 
that:

  	tar::skip silently truncates skip length to 65536

		https://core.tcl-lang.org/tcllib/tktview/6b7aa0aecca6fdce12589884c3c9ea2b50c92ad4

That bug report is characteristic of the way I operate:  When I diagnose 
a bug,
I spend days, weeks, and on a few occasions even months, yes months,
diagnosing and fixing the problem *before* even reporting it?  Why?  
Because I
don't want these issues to be a burden to you or any of the other 
heavyweights
who are doing important development on Tcl.  If you look through my 
history in
the Tcl or Tcllib tikets, you'll find that 90% of the time I've solved 
the
problem and contributed the fix at the same time that I've filed the 
report.

Because I mostly only file reports and include fixes along with the 
reports, my
tickets usually get closed quickly and with minimal fuss, so the body of 
my
work goes largely unrecognized, but I've contributed approximately 100 
fixes
over the last 10 years for some very tricky bugs in Tcl.  Making sure 
that Tcl
operates correctly has been the priority for me, and in my history 
you'll find
numerous fixes for deep issues, many involving silent data corruption.  
For
example, here is one involving silent data corruption in the 
coroutine::util
module:

  	[coroutine::util read] swallows data when the channel becomes blocked

		https://core.tcl-lang.org/tcllib/tktview/104809e450

Another issue that I resolved related to refchans and the IO subsystem 
was:

	memchan stops generating read events when cursor is at end of file

		https://core.tcl-lang.org/tcllib/tktview/864a0c83e3

The first issue I ever reported in Tcl was about a subtle heisenbug that 
caused
Tcl to sporadically segfault.  I wasn't very good at debugging such 
things back
then, but even then I provided enough information to enable sebres to 
deduce
the problem:

	https://core.tcl-lang.org/tcl/tktview?name=3484402

If I'm making noise about [chan postevent] right now, it's because I 
think this
issue is important from the perspective of correctness, and I've 
invested a lot
of time over the years into weeding out incorrect behaviors in Tcl.  
Also, I'm
bugged that people would revert this after 5 years of flawless operation
without providing any code that demonstrates a problem with what they 
are
reverting.

You've fixed a few things that I've gotten wrong in some of my 
contributions,
and I appreciate that, along with all the other great work you've done.  
I've
also fixed bugs in your work.  We have the same goals for Tcl.  We just 
happen
to have conflicting positions at the moment on this particular issue.

-- 
Yorick

Re: [TCLCORE] Improvements to the wording of the Tcl rules.

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

Op wo 15 mei 2024 om 10:44 schreef Poor Yorick:
> I've done some extensive work on the Tcl documentation in the past.  One
> example is chan.n, where I reduced the word count by 40%:
>
>         https://core.tcl-lang.org/tcl/info/eb627bda27968937int
>
> Another example is SetResult.3, where I reduced the word count by 46%.
>
>         https://core.tcl-lang.org/tcl/info/8dba618fe6b6f8bb
>
> Both of these pages are significantly more readable as a result.

Today, in the TCT meeting, it was decided to back out those
changes from trunk, and move them aside to its own
branch in order to be reviewed properly later. So, your
rewrite is not going to be thrown away.

Harald already asked you, 2 weeks ago, to do this
backout, and put up those changes for review. But
it doesn't look like you have time to do that.

Regards,
          Jan Nijtmans

Re: [TCLCORE] CFV: TIP #696

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

On the Tcl level, many situations can be solved with both, with 
exceptions and with return codes. There are cases, where exceptions are 
more powerful. I am not happy by advertising a light-weight alternative 
path leading to foreseeable problems with interactions of packages. How 
can one safely use Tcl packages, where every Tcl package is free to 
register the same return-code, … or where someone refactors code 
introducing new Tcl return codes between releases? I see potential 
problems from the maintenance and debugging point of view. > 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.
All the best -g

Re: [TCLCORE] [chan postevent] must be asynchronous

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

Hi.

Kevin and Harald, thank you for speaking up.

> Andreas, thank you for the analysis.  In order to answer the question of
> whether [chan postevent] was intended to be asynchronous, you had to look
> decades back into the past and reconstruct your memories in light of the
> current debate,

> and you have persuaded yourself that [chan postevent] was intended to be
> synchronous.

I suspect that this is the sentence Kevin thought of as arrogant.

To myself it came more across as condescending. Note that I am not saying that
you intended it to be so [1], just that this was my reading of the phrase, with
my internal translations running along the lines of

    I know better than you (what you were thinking)
    I know better than you (what you are remembering)

> I'll now attempt to persuade you of the opposite.

And this follow-up I then translated as

   I know better than you (what reality should be)

Together these two sentences very much come across to me as an attempt at
gaslighting [2], unfortunately. Change the future by rewriting the past
(in my memory).

If that was not intended I would recommend that you sit back and think very 
hard
on how you communicate and phrase things. Maybe try to read mails from the
perspective of the prospective receiver and other audience. Yes, that is a hard
thing to do, we each have only our own mind to emulate/predict the thoughts of
others.

I had hoped that the technical arguments from my recollection would have been
answered by technical arguments.

Reading the rest of the mail now, having calmed down from my initial reaction 
to
the first parapgraph our your mail, I find that any technical arguments it may
contain are all couched in terms of manipulative language targeted at rewriting
my memory of the past.

I have decided that there is no point to respond to this.

I have decided that the topic of chan post event and its nature is closed on my
side. I will not dicuss it further.

~~~
[1] I cannot see into your mind.

[2] For those not versed in english idioms like this, see 
https://en.wikipedia.org/wiki/Gaslighting

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

Re: [TCLCORE] CFV: TIP #696

[Brian G. <bri...@ea...>]

TIP #696:  Yes
I’m voting for the defining of boundaries.  (fences make good neighbors)
The details can be explored and settled reasonably; just don’t bike shed too much.

-Brian
(from mobile device)

On Jun 4, 2024, at 14:44, Brian Griffin <bri...@ea...> wrote:



On Jun 4, 2024, at 10:02, apnmbx-public--- via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> wrote:

This is a Call for Votes for TIP #696 – Reserve range of return codes for Tcl's own use

TIP: https://core.tcl-lang.org/tips/doc/trunk/tip/696.md
Implementation: https://core.tcl-lang.org/tcl/timeline?r=tip-696

This is an almost zero-code TIP to formally partition the range of Tcl return codes in Tcl 9 between those reserved for Tcl itself and those available for use by extensions.

CFV ends June 19, 2024 at 8am UTC. Please send votes to the list or me before then.

TIP #696: Yes

/Ashok

TIP #696: Yes

-Brian

Re: [TCLCORE] CFV: TIP #696

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

Yes, Rolf also pointed out the wrong decimal value in TIP and docs. Fixed now. Thanks

 

0x3f..f is half of *positive* integer range. Not planning on changing this now in any case.

 

/Ashok

 

From: Dipl. Ing. Sergey G. Brester <se...@us...> 
Sent: Monday, June 10, 2024 4:23 AM
To: apn...@ya...
Cc: tcl...@li...
Subject: Re: [TCLCORE] CFV: TIP #696

 

Well, exception handling may be indeed relevant...
I also used it at some point, so I try to explain with a simple example:

1.    Tcl-API is used together with some C++ (or whatever) code that may throw an exception...

2.    It is not good to pass the exception over all levels of TCL-API (e. g. to avoid mem-leaks of C-code side, etc),
so one can catch the exception before going to TCL-API and "wrap" the exception to some ret-code.

3.    so for instance the code chain may look like this or something more complex depending on contex:
C++ awaiting exception <-> C++ checking retcode <-> TCL-API ... TCL-API <-> C++ with catch <-> C++ with exception

4.    finally an exception may be rethrowed (in wrapper C++ checking retcode) depending on interim return code;

5.    for the case the wrapper needs to handle many different exception codes, the reserved range (5 - 0x3FFFFFFF) may be still to large in my opinion (and I don't know why Tcl could need 1 billion return values, however may be for some flags?). 
But since TCL still not really use them, just reserve, I'm OK with that.

@Ashok
The TIP seems to have a small bug (in the range) and therefore may confuse people about the range size:

  #define TCL_CODE_USER_MIN 5
- #define TCL_CODE_USER_MAX 0x3FFFFFFF /*  268435455 */
+ #define TCL_CODE_USER_MAX 0x3FFFFFFF /* 1073741823 */

It is still one fourth of the whole int.

Or did you rather wanted to suggest 0x0FFFFFFF instead of 0x3FFFFFFF?

Regards,
Serg.

09.06.2024 19:38, apnmbx-public--- via Tcl-Core wrote:

I understand -errorcode usage. My point was return codes serve a very different purpose, are both more convenient and lighter weight, so I'm not sure consideration of exception handling is relevant here.

 

Re: [TCLCORE] CFV: TIP #696

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

 

Well, exception handling may be indeed relevant...
I also used it at some point, so I try to explain with a simple example:


 	* Tcl-API is used together with some C++ (or whatever) code that may
throw an exception...

	* It is not good to pass the exception over all levels of TCL-API (e.
g. to avoid mem-leaks of C-code side, etc),
so one can catch the exception before going to TCL-API and "wrap" the
exception to some ret-code. 
	* so for instance the code chain may look like this or something more
complex depending on contex:
C++ awaiting exception <-> C++ checking retcode <-> TCL-API ... TCL-API
<-> C++ with catch <-> C++ with exception 	* finally an exception may be
rethrowed (in wrapper C++ checking retcode) depending on interim return
code;

	* for the case the wrapper needs to handle many different exception
codes, the reserved range (5 - 0x3FFFFFFF) may be still to large in my
opinion (and I don't know why Tcl could need 1 billion return values,
however may be for some flags?). 
But since TCL still not really use them, just reserve, I'm OK with that.


@Ashok
The TIP seems to have a small bug (in the range) and therefore may
confuse people about the range size: 

 #define TCL_CODE_USER_MIN 5
- #define TCL_CODE_USER_MAX 0x3FFFFFFF /* 268435455 */
+ #define TCL_CODE_USER_MAX 0x3FFFFFFF /* 1073741823 */

It is still ONE FOURTH of the whole int. 

Or did you rather wanted to suggest 0X0FFFFFFF instead of 0X3FFFFFFF? 

Regards,
Serg. 

09.06.2024 19:38, apnmbx-public--- via Tcl-Core wrote: 

> I understand -errorcode usage. My point was return codes serve a very different purpose, are both more convenient and lighter weight, so I'm not sure consideration of exception handling is relevant here.
 

Re: [TCLCORE] [chan postevent] must be asynchronous

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

<div><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/rVnYYamP-8n39ITV5DvYA77aYDbqOcgc9yE69Zffxt_vKOIVeLeqyGdsU99B1kdbbpQ3UJlmUOTAGQlBSJZNBljbwIxE09dZCGiUkYn659iMwW6gTMPGkiowHSFGeDbjYHFtUJcCP239fcR9u2XVcFbdG2rw-1pfGF2j9OHp15w_ECg6DM0t-6Wyn5mPehnwDt99k6ewnVRmLPEnSSwS_37FQXUSb9Pw' /></div>Nathan,<br/><br/>On 6/9/24 3:41 PM, Harald Oehlmann wrote:<br/>> I invite you again and again to respect the members of the community. <br/><br/>I don't have a technical dog in this fight, as you have gone out of your <br/>way to point out, but I am concerned about your unwillingness or <br/>inability to accept that the consensus of the technical experts <br/>(including the author of the original TIP that you are arguing about) is <br/>so overwhelmingly against your position. And, as a TCT member, harmony <br/>in our small developer community IS a discussion where I have a stake.<br/><br/>So I'd like to add my request to those of others: Drop this argument.<br/><br/>Your behavior in this discussion is not just stubborn. You have <br/>repeatedly re-opened tickets that others have closed. You have attempted <br/>to explain to the author of the original TIP what he was thinking, as if <br/>you know his own mind better than he does. The arrogance of that takes <br/>my breath away.<br/><br/>The consensus of this community is that the technical topic you are <br/>attempting to engage is closed. You have persuaded no one. At some point <br/>the gracious thing to do is accept that the argument has not gone your <br/>way, and repeated efforts to change peoples' minds are not going to work.<br/><br/>Please: drop this argument.<br/><br/>Thank you,<br/><br/>Kevin<br/><br/><br/>