tcl-core — Tcl Core Team discussions about Tcl development

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

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

Am 08.06.2024 um 22:05 schrieb Poor Yorick:
> 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'll now attempt to persuade
> you of the opposite.

Dear Nathan,
thank you for the message.
My work is to protect our Wizards from hard opinions. It was not easy to 
convince Andreas to comment and it append what is the worst for the 
community.
The Wizard Andreas got directly and attacked in a non respectful manner 
by you.
The result will be the same as in all other those actions: the Wizard 
will not answer and we risk to loose him.
I invite you again and again to respect the members of the community.

Thank you for your understanding,
Harald

Re: [TCLCORE] CFV: TIP #696

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

Am 09.06.2024 um 19:51 schrieb apnmbx-public--- via Tcl-Core:
> 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

Thank you,
Harald

Re: [TCLCORE] CFV: TIP #696

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

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.

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...> 
Sent: Friday, June 7, 2024 8:33 PM
To: tcl...@li...
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 <ne...@wu... <mailto:ne...@wu...> > 
Sent: Friday, June 7, 2024 11:59 AM
To: tcl...@li... <mailto:tcl...@li...> 
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 

Re: [TCLCORE] CFV: TIP #696

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

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.

 

/Ashok

 

From: Donald Porter <d.g...@co...> 
Sent: Friday, June 7, 2024 9:32 PM
To: apn...@ya...
Cc: tcl...@li...
Subject: Re: [TCLCORE] CFV: TIP #696

 

 

Not quite sure what you mean by exception handling. Return codes are a mechanism between C level calls as well.

 

Most (all?) of the use cases for a package defining its own return codes can be achieved just as well by defining its own

-errorcode’s to [throw] and handling by the trap blocks inside a [try].

 

Errorcodes are better suited for avoiding naming conflicts because they already follow the convention of being list valued with the first element of the list being the owning package name.

 

DGP

 

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

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

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>

It's meant for Tcl 9.0+ only. It basically makes the 'format'
and 'scan' commands platform-independent: if no
size specifier is given, the limitation/truncation will be
32-bit, and no longer depend on tcl_platform(wordSize).

If you think this is a bad idea, speak up now. If not,
I'll start the vote in a few days.

Regards,
         Jan Nijtmans

Re: [TCLCORE] tkprint-cups branch - please test

[Emiliano <emi...@gm...>]

Hi Schelte, thanks for testing !!

> Great work, thanks. I have tried this on SUSE 15.4 with the following 
> results:
> 
> ../unix/configure reports (among other things):
> checking whether to use libcups... yes
> checking for cups/cups.h... no
> 
> The make command then fails with:
> ../unix/tkUnixPrint.c:16:10: fatal error: cups/cups.h: No such file or 
> directory
>   #include <cups/cups.h>

There was a small typo in the check (cups -> libcups) that should be fixed
now. I've not regenerated the configure script, just changed configure.ac

> So it seems the configure check for cups availability is not foolproof 
> (me acting as the fool).
> 
> After installing cups-devel (zypper in cups-devel), everything builds 
> fine. The dialog looks great and correctly shows my printer. I missed 
> the option to print to a file, which is normally present in a print 
> dialog. But that option is also not available in the scripted version. 
> So this is not a deficiency of the compiled version.

Default GTK print dialog allows print to file, but others doesn't. This
is toolkit dependent. For a generic solution, there is a generic pdf
printer which outputs a pdf file in $env(HOME)/PDF directory by default.
This printer is also good for testing without wasting ink and paper.
 
> I haven't actually tried printing. My understanding is that the request 
> was only to check the dialog.

The dialog should be there, and print, even if you don't have CUPS
development files installed. There's an [exec] based implementation
as fallback in this case. Expect it to be *way* slower but fully
functional.

Thanks for testing.

-- 
Emiliano

Re: [TCLCORE] tkprint-cups branch - please test

[Schelte B. <tc...@tc...>]

Hello Kevin, Emiliano,

Great work, thanks. I have tried this on SUSE 15.4 with the following 
results:

../unix/configure reports (among other things):
checking whether to use libcups... yes
checking for cups/cups.h... no

The make command then fails with:
../unix/tkUnixPrint.c:16:10: fatal error: cups/cups.h: No such file or 
directory
  #include <cups/cups.h>

So it seems the configure check for cups availability is not foolproof 
(me acting as the fool).

After installing cups-devel (zypper in cups-devel), everything builds 
fine. The dialog looks great and correctly shows my printer. I missed 
the option to print to a file, which is normally present in a print 
dialog. But that option is also not available in the scripted version. 
So this is not a deficiency of the compiled version.

I haven't actually tried printing. My understanding is that the request 
was only to check the dialog.


Regards,
Schelte.


On 09/06/2024 03:38, Kevin Walzer wrote:
> Hi all,
> 
> Emiliano Gavilan has been working on a native Tk interface to the CUPS
> printing library on Unices, and has add this implementation to the "tk
> print" command that was added as part of TIP 604. Tk will now link to
> libcups if the library is installed at build time, and the result is a
> much faster implementation. Tk will fall back to the script-level
> implementation that was developed in TIP 604 if CUPS is not installed.
> 
> I've assisted Emiliano with the build-time bits (configure.ac and
> Makefile.in), and have been testing the branch on Debian. It now builds
> without errors and runs fine. We'd like to ask others in the community
> to give the "tkprint-cups" branch and provide feedback. Once we have a
> sense that the build works to others' satisfaction, Emiliano will merge
> the branch.
> 
> I don't believe a TIP is required - this branch adds an additional
> under-the-hood implementation and an optional build-time dependency, but
> introduces no public API changes. If others think adding a note to TIP
> 604 on the additional details is justified, I will do so.
> 
> Looking forward to your comments!
> 
> Thanks,
> 
> Kevin

[TCLCORE] How is the tclIndex file in the repository generated

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

The comments in the library/tclIndex file in the Tcl repository indicate
that it is auto generated but I cannot find any part of the build that does
this. Is it supposed to be manually generated (using auto_index) ? Or is it
now manually edited?

 

/Ashok

[TCLCORE] tkprint-cups branch - please test

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

<div><img width="1" height="1" src='https://fedbdhd.r.af.d.sendibt2.com/tr/op/KUhDMKtGuTJLcGdf9VI4oG7qQ9gC8HtQA0kvBAhyPPeWSzjC-D7Jp8RbUBhcmxEMVrK0tmHjoG9_fh2HMCtieNYpx5BNdkX_PwjzmCE8AZJt-5dHVRiZqLxy9AKcrjQsU0K1e128nHspVdjaMyIyt1K6SjW4TCUxRS8VuNGVCGHafvAzA_eL3CL1TatCDwoUL0ax_0TQQz0WUM-1fiBFx6E_gUrr_UCS' /></div>Hi all,<br/><br/>Emiliano Gavilan has been working on a native Tk interface to the CUPS <br/>printing library on Unices, and has add this implementation to the "tk <br/>print" command that was added as part of TIP 604. Tk will now link to <br/>libcups if the library is installed at build time, and the result is a <br/>much faster implementation. Tk will fall back to the script-level <br/>implementation that was developed in TIP 604 if CUPS is not installed.<br/><br/>I've assisted Emiliano with the build-time bits (configure.ac and <br/>Makefile.in), and have been testing the branch on Debian. It now builds <br/>without errors and runs fine. We'd like to ask others in the community <br/>to give the "tkprint-cups" branch and provide feedback. Once we have a <br/>sense that the build works to others' satisfaction, Emiliano will merge <br/>the branch.<br/><br/>I don't believe a TIP is required - this branch adds an additional <br/>under-the-hood implementation and an optional build-time dependency, but <br/>introduces no public API changes. If others think adding a note to TIP <br/>604 on the additional details is justified, I will do so.<br/><br/>Looking forward to your comments!<br/><br/>Thanks,<br/><br/>Kevin<br/><br/>

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

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

On 2024-06-05 00:53, Andreas Kupries wrote:
> [This response collects quotes from multiple mails received from 
> Nathan]
> 
>> Hi everyone,
> 
>> A number of people, including apparently several members of the Tcl
>> Core Team, have decided that [chan postevent] is part of Tcl's
>> synchronous API for channels rather part of Tcl's asynchronous API
>> for channels, and on that basis want to close the following issue
>> reports
> 
>> 	https://core.tcl-lang.org/tcl/tktview/67a5eabbd3d195915d3ccc13246bdecf10e20726
>> 	https://core.tcl-lang.org/tcl/tktview/de232b49f26da1c18e07513d4c7caa203cd27910
> 
>> The idea that [chan postevent] is part of Tcl's synchronous API is
>> one of the most wrong-headed ideas I've encountered among the
>> contributors to Tcl.
> 
> Strong claim. Emotional argument also, not technical.
> 
>> I'm sure that at least some people reading this have experienced
>> failure when trying to implement a refchan, and as a result have
>> simply turned their backs on refchans and found some other way to
>> get the job done.  When [chan postevent] is part of Tcl's
>> asynchronous API,
> 
>> as was always intended,
> 
> You seem to claim telepathy as well. Specifically that of my mind,
> given that I was the writer of [TIP #219][1] back in 2004.
> 
> [1] https://core.tcl-lang.org/tips/doc/trunk/tip/219.md
> 
> Despite the distance of 20 years I am pretty sure that I had not
> intended async operation.
> 
> And coming back into things after reading more mails I am now fully
> sure it was not intended to be async. See later where I talk about
> what a `refchan` truly is. A channel driver, just in Tcl. Operating
> under the same rules as a C-level driver. Whose equivalent to
> `postevent` is, yes, verily, synchronous.
> 
>> you wouldn't have experienced that "hanging" behaviour of refchans.
> 
>> For all those who have been bitten by refchans, now would be a good
>> time to voice your support for fixing bugs keep it from being
>> asynchronous as it should be.
> 
>> Here is a list of all wiki pages containing examples of postevent
>> that are broken until the issues referenced above are fixed:
> 
>> 	https://wiki.tcl-lang.org/page/fifo2+in+pure+Tcl
>> 	https://wiki.tcl-lang.org/page/reflected+channel+example
>> 	https://wiki.tcl-lang.org/page/reflected+channel
> 
>> Here is a list of wiki pages that contain ugly hacks to work around
>> the issues reference above:
> 
>> 	https://wiki.tcl-lang.org/page/A+template+reflected+channel
>> 	https://wiki.tcl-lang.org/page/topcua
> 
> The hack you refer too are the `after ...` constructions used to push
> `postevent` calls out of non-reentrant parts of the procs, right ?
> 
> I do not see such as hacks, but rather as the standard way to avoid
> reentrancy troubles anywhere.
> 
>> The general principle here is that event handlers should not
>> recursively enter event-handling, but should instead allow the event
>> loop to mediate.  This should be obvious, so I don't know why we now
>> have to debate it for [chan postevent].
> 
>> Was it ever documented to be synchronous?
> 
> No. Of course not. Because synchronous behaviour is the default for
> pretty much all Tcl commands, and it is the __exceptions__ from that
> default which are documented.
> 
>> Did any change I made require a change in the documentation?
> 
> Changing a command from sync to async is a strong change of the
> semantics. Yes, that requires a change of the docs. Because, see
> above, the async behaviour of a command is the exception from the
> default.
> 
>> If not, no TIP is required to fix bugs in the implementation.
> 
> Just declaring something as a bug does not give you a
> free-to-change-this card.
> 
>> Yes, really.  [chan postevent] is the mechanism provided for a refchan
>> to notifiy Tcl of events on the channel.  At the C level, the 
>> mechanism
>> provided to an event source for this purpose is Tcl_QueueEvent(), 
>> which
> 
> Actually the C level equivalent of `postevent` is `Tcl_NotifyChannel()`
> which is very much synchronous. Somehow the C-level channel drivers
> still manage to work.
> 
> https://www.tcl-lang.org/man/tcl8.6/TclLib/CrtChannel.htm
> 
> 	Tcl_NotifyChannel is called by a channel driver to indicate to
>         the generic layer that the events specified by mask have
>         occurred on the channel. Channel drivers are responsible for
>         invoking this function ___whenever the channel handlers need to
>         be called for the channel___ (or other pending tasks like a 
> write
>         flush should be performed). See WATCHPROC below for more
>         details.
> 
> (WATCHPROC) 
> https://www.tcl-lang.org/man/tcl8.6/TclLib/CrtChannel.htm#M16
> 
> 	... the channel driver is responsible for calling
> 	Tcl_NotifyChannel to inform the generic channel module. The
> 	driver should take care not to starve other channel drivers or
> 	sources of callbacks by invoking Tcl_NotifyChannel too
> 	frequently. Fairness can be insured by using the Tcl event
> 	queue to allow the channel event to be scheduled in sequence
> 	with other events
> 
> So, `Tcl_NC` is synchronous in C, and C-based channel driver are
> responsible for using the C-level equivalent of `after` to explicitly
> go through the event queue where/when needed, i.e. to avoid reentrancy
> issues, etc. And these drivers __do so__.
> 
> A `refchan` is a __direct__ mapping of a channel driver into Tcl, and
> therefore has the __same responsibilities__ as a C-level driver, up to
> and including to explicitly go through the event queue when needed,
> using `after` as the effective entrypoint to `Tcl_QueueEvent`.
> 
> A refchan directly talks to the low-level Tcl's IO system like C
> drivers to, and has to follow the same rules as they do.
> 
> 
>> My answer is that [chan postevent] was always sufficiently
>> documented as asynchronous,
> 
> I see no such documentation in the `chan` manpage, nor in the TIP 219.
> Please provide a reference to the docs you believe made the async
> claim.
> 

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'll now attempt to persuade
you of the opposite.

In the small, Tcl_NotifyChannel() appears to be synchronous, but when
one steps back and looks at the larger picture, it is part of an
asynchronous operation.  It's true that Tcl_NotifyChannel() does not
queue up an event, but that's because Tcl_NotifyChannel() is itself an
event handler.  In tclUnixChan.c, which is the implementation of the
*nix channel driver for files, FileWatchProc() passes
Tcl_NotifyChannel() to Tcl_CreateFileHandler(), and the notifier then
calls Tcl_NotifyChannel() later when it detects an event on the channel.
This effectively makes Tcl_NotifyChannel() asynchronous, as its only
caller is the event loop itself.  When this also true for refchans, i.e.
when the only caller of a handler for an event on the refchan is the
event loop itself, then the operation of refchan is consistent with the
operation of other channels.  Unfortunately, due to the reversions
listed below, this is no-longer the case.

You named it [chan postevent] instead of [chan notify] because you
intuited that it was not at the same level as Tcl_NotifyChannel(), even
if you didn't articulate then, or even now.  [chan postevent] is not
Tcl_NotifyChannel().  It operates at an even lower layer:  It is the
mechanism that informs the notifier that there is an event on the
channel.  File event detection is not part of the channel driver, but
rather is a part of the notifier:  select() is called in tclUnixNotfy.c,
not in tclUnixChan.c.  In contrast with other event sources that are
surfaced through select(), which interacts with external systems during
normal event loop operations, a refchan must have some way to make the
event known to Tcl.  [chan postevent] was provided for that purpose.  In
other words, [chan postevent] is the analogue of select(), not the
analogue of Tcl_NotifyChannel().  As such, it should return something to
the notifier, like select() does during normal event loop processing.
The way to have a refchan do that is for [chan postevent] to place an
event on the queue, just as its name implies.  So you got the name
right, even if you weren't sure exactly why.

Requiring every refchan to use [after] to call [chan postevent] is a
completely unnecessary wart.  It's nothing more than leakage of poor
implementation into the script level.  Inspection of the design proves
that it is unnecessary, and not one example has been brought forward
demonstrating any reason a refchan might need to call [chan postevent]
synchronously when a channel is nonblocking.  No one out there is doing
it either, because it would result in sporadic deadlocks.  This is
simply hand-wringing over a fictitious situation.  Since a refchan must
use [after] to call [chan postevent] if it wants to work properly,
taking care of that part at the implementation level is a much better
strategy.

For the last five years, the following bugs have been fixed on
core-8-branch and in trunk

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

	https://core.tcl-lang.org/tcl/tktview/67a5eabbd3d195915d3ccc13246bdecf10e20726

Throughout five years of development on those branches, the fix has
never been called into question, and has never lead to another valid bug
report (at least not one that wasn't quickly fixed).  Before coroutines,
calling [chan postevent] without a timer "only" lead to deadlocks.
Nowadays, when a refchan is implemented as a coroutine, it is an error
to call [chan postevent] synchronously.  I'll repeat that:

	It is an error to call [chan postevent] synchronously.

Coroutine implementations of refchans make it manifestly clear that
[chan postevent] must be asynchronous.  Therefore, there is no point in
trying to pretend that [chan postevent] is synchronous.  It must go
through the event queue, and the only way currently to do that is to use
[after].  Although it is coroutine implementations of refchans that make
this obvious, it is and always has been true for all other
implementations as well.  It's just that with other implementations, the
error can be more camouflaged, with deadlocks happening at unpredictable
times.

But now, via the following commits, the fix for the bugs mentioned
above has been undone.

	core-8-branch

		https://core.tcl-lang.org/tcl/info/8d4d978bd3ca580d

	trunk

		https://core.tcl-lang.org/tcl/info/1ec9927351b255fb

This work was tedious and painstaking, it solved the bugs referenced
above, and it made the operation of refchans more consistent with other
types of channels. Now Tcl has lost this contribution, and all for a
"bug" report that doesn't actually demonstrate any reproducible bug, and
only because someone has some ideas but no code to stand those ideas on.
It's a mistake to undo this work, and it's a mistake to rationalize
undoing it by documenting [chan postevent] as synchronous.  Let's bring
back consistency with the design of the IO subsystem, ditch this
brain-dead idea that [chan postevent] should do anything other than post
a notification for the notifier, and revert the reversions of the code
that fixed the bugs above.

-- 
Yorick

Re: [TCLCORE] CFV: TIP #696

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

 

+1 

I also find short (65536) as fully enough for Tcl (guess even that it'd
be never reached)
as well as in TIP suggested range of 2M totally surplus.

Regards,
Serg 

Am 06.06.2024 15:06, schrieb Jan Nijtmans: 

> TIP #696: YES
> 
> Op wo 5 jun 2024 om 05:23 schreef Ashok:
> 
>> Regarding tcllib, yes, some packages will have to be touched. Will it help if we reduce the range of Tcl reserved codes as @mjanssen suggested on the chat to say, -0xFFFF:0xFFFF ?
> 
> I think I would suggest using the -0x8000:0x7FFF range
> for Tcl, that's the complete 'short' range. Then
> "-return 0x8005" (for example) is not ridiculously long.
> 
> Regards,
> Jan NIjtmans
> 
> _______________________________________________
> 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

[Donald P. <d.g...@co...>]

> Not quite sure what you mean by exception handling. Return codes are a mechanism between C level calls as well.

Most (all?) of the use cases for a package defining its own return codes can be achieved just as well by defining its own
-errorcode’s to [throw] and handling by the trap blocks inside a [try].

Errorcodes are better suited for avoiding naming conflicts because they already follow the convention of being list valued with the first element of the list being the owning package name.

DGP

Re: [TCLCORE] CFV: TIP #696

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

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 <ne...@wu...> 
Sent: Friday, June 7, 2024 11:59 AM
To: tcl...@li...
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 

Re: [TCLCORE] CFV: TIP #696

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

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

Re: [TCLCORE] CFV: TIP #696

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

apnmbx-public--- via Tcl-Core writes:

> Packages/applications can use codes in the range 5 - 0x3FFFFFFF. New Tcl
> codes will have to be negative, 0-4 (as today) or above 0x40000000. This
> should help with compatibility with existing extensions as well as not
> burden new ones with remembering large values. Any new Tcl codes will likely
> come with a string equivalent like "break" etc. so it should not be
> inconvenient for Tcl core authors either.

LGTM. Thanks for listing to observations and comments.

rolf

Re: [TCLCORE] CFV: TIP #696

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

Andreas Kupries writes:
>> At the moment return -code raises error it the value isn't an int.
>
> It does ? I am pretty sure that I use constructs
>
> 	return -code return ...
>
> as a means for a proc to not only abort itself, but the caller.

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.

The context of my claim was extension specific return codes. If you want
to return something else then the named five symbols with the return
-code option than that value has to be an integer.

% return -code foo
bad completion code "foo": must be ok, error, return, break, continue, or an integer

rolf

Re: [TCLCORE] CFV: TIP #696

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

> At the moment return -code raises error it the value isn't an int.

It does ? I am pretty sure that I use constructs

	return -code return ...

as a means for a proc to not only abort itself, but the caller.
Good for DSL implementations, i.e. have code like

     proc foo {} {
     	  Check
	  ...
     }

and the `Check` proc can stop `foo` when something is wrong.

> Shouldn't it also raise error (after this TIP is accepted) if the value
> is an internal one (other then 0 - 4)?

See above, returning with an internal code is useful in scripts.

> This would make Tcl 8 code raise error with Tcl 9 which would otherways
> have worked unchangend for years and new return codes to come. But it
> would tell much earlier and clearer that here is a migration cost for
> Tcl 9. WDYT?

-- 
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

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

Ok then, one final proposal. 

Packages/applications can use codes in the range 5 - 0x3FFFFFFF. New Tcl
codes will have to be negative, 0-4 (as today) or above 0x40000000. This
should help with compatibility with existing extensions as well as not
burden new ones with remembering large values. Any new Tcl codes will likely
come with a string equivalent like "break" etc. so it should not be
inconvenient for Tcl core authors either.

If I don't hear any contrary opinions, I will make that change to the TIP.
If anyone does have concerns with this as well, please make a counter
proposal.

I'll also reset the vote as there has been discussion and changes since the
CFV.

/Ashok


-----Original Message-----
From: Rolf Ade <tcl...@po...> 
Sent: Thursday, June 6, 2024 4:22 AM
To: tcl...@li...
Subject: Re: [TCLCORE] CFV: TIP #696


apnmbx-public--- via Tcl-Core writes:
> Regarding tcllib, yes, some packages will have to be touched. Will it help
> if we reduce the range of Tcl reserved codes as @mjanssen suggested on the
> chat to say, -0xFFFF:0xFFFF ?

Well, I raised head only because it was so easy to find examples in
public available code as

https://core.tcl-lang.org/tcllib/file?udc=1&ln=2770&ci=trunk&name=modules%2F
mime%2Fmime.tcl

https://core.tcl-lang.org/tcllib/file?udc=1&ln=182&ci=trunk&name=modules%2Fs
truct%2Ftree_tcl.tcl

Reducing the range of Tcl reserved codes to -0xFFFF:0xFFFF would not
help for that cases.

A much smaller reserved range is appealing not because it would milden
migration needs but it would extension writers relieve from the need to
use ridiculously long own return codes.

rolf


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

Re: [TCLCORE] tcltls: unexpected 0-bytes [read], then nothing

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

While there is never any harm trying arbitrary commits if you have the time, the change @pooryorick refers to was made after 9.0b1 for sure and iirc after 9.0b2 as well. So if you have tested with 9.0b1, you probably already have tested the commit he references.

/Ashok

-----Original Message-----
From: Poor Yorick <org...@po...> 
Sent: Thursday, June 6, 2024 5:27 PM
To: tcl...@li...
Subject: Re: [TCLCORE] tcltls: unexpected 0-bytes [read], then nothing

On 2024-06-05 17:48, Colin Macleod via Tcl-Core wrote:
> On 05/06/2024 15:33, Harald Oehlmann wrote:
>> Am 05.06.2024 um 15:22 schrieb Pietro Cerutti via Tcl-Core:
>>> I and Colin have been investigating an issue when using the TLS 
>>> extension (https://core.tcl-lang.org/tcltls) to interact with a Redis 
>>> server using retcl (https://code.ptrcrt.ch/retcl/).
>> Pietro,
>> is this TCL 8.7a0 until 9.0b2 ?
>> If yes, please try the current main branch.
>> 
> I see the same issue with 8.6 and 9.0b1, I have not tried a newer 
> version so far.  Is there some recent change that would affect this?
> 
> Colin.

A significant change was made to the IO subsystem recently. You might 
try commit 9fa0318dcd9b2067, which was the last commit to trunk before 
the change.

-- 
Yorick



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

Re: [TCLCORE] CFV: TIP #696

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

TIP #696: YES

Op wo 5 jun 2024 om 05:23 schreef Ashok:
> Regarding tcllib, yes, some packages will have to be touched. Will it help
> if we reduce the range of Tcl reserved codes as @mjanssen suggested on the
> chat to say, -0xFFFF:0xFFFF ?

I think I would suggest using the -0x8000:0x7FFF range
for Tcl, that's the complete 'short' range. Then
"-return 0x8005" (for example) is not ridiculously long.

Regards,
      Jan NIjtmans

Re: [TCLCORE] tcltls: unexpected 0-bytes [read], then nothing

[Colin M. <col...@ya...>]

Thanks for this info, but the issue also occurs with Tcl 8.6 so it seems 
unlikely to be related to a recent change like this.

Colin.

On 06/06/2024 13:13, Jan Nijtmans wrote:
> Op do 6 jun 2024 om 13:57 schreef Poor Yorick:
>> A significant change was made to the IO subsystem recently. You might
>> try commit 9fa0318dcd9b2067, which was the last commit to trunk before
>> the change.
> The reason for this 'significant change' is explained in a technote:
>         <https://core.tcl-lang.org/tcl/wiki?name=Rationale+for+rollback+of+refchan+event+generation+in+core>
> After reading this, you most likely don't want to try
> commit 9fa0318dcd9b2067 or any other commit earlier
> than May 29 any more.
>
> Hope this helps,
>            Jan Nijtmans
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] tcltls: unexpected 0-bytes [read], then nothing

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

Op do 6 jun 2024 om 13:57 schreef Poor Yorick:
> A significant change was made to the IO subsystem recently. You might
> try commit 9fa0318dcd9b2067, which was the last commit to trunk before
> the change.

The reason for this 'significant change' is explained in a technote:
       <https://core.tcl-lang.org/tcl/wiki?name=Rationale+for+rollback+of+refchan+event+generation+in+core>
After reading this, you most likely don't want to try
commit 9fa0318dcd9b2067 or any other commit earlier
than May 29 any more.

Hope this helps,
          Jan Nijtmans

Re: [TCLCORE] tcltls: unexpected 0-bytes [read], then nothing

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

On 2024-06-05 17:48, Colin Macleod via Tcl-Core wrote:
> On 05/06/2024 15:33, Harald Oehlmann wrote:
>> Am 05.06.2024 um 15:22 schrieb Pietro Cerutti via Tcl-Core:
>>> I and Colin have been investigating an issue when using the TLS 
>>> extension (https://core.tcl-lang.org/tcltls) to interact with a Redis 
>>> server using retcl (https://code.ptrcrt.ch/retcl/).
>> Pietro,
>> is this TCL 8.7a0 until 9.0b2 ?
>> If yes, please try the current main branch.
>> 
> I see the same issue with 8.6 and 9.0b1, I have not tried a newer 
> version so far.  Is there some recent change that would affect this?
> 
> Colin.

A significant change was made to the IO subsystem recently. You might 
try commit 9fa0318dcd9b2067, which was the last commit to trunk before 
the change.

-- 
Yorick

Re: [TCLCORE] tcltls: unexpected 0-bytes [read], then nothing

[Pietro C. <ga...@ga...>]

On Jun 05 2024, 16:48 UTC, Gustaf Neumann <ne...@wu...> wrote:
[-- Type: text/plain; charset=UTF-8, Encoding: quoted-printable, Size: 2.6K --]
>You might also check the following ticket, dealing also with 0-byte reads
>
>https://core.tcl-lang.org/tcltls/tktview/88c0c84969
>
>Below is a diff against the current version of tcltls from the fossil 
>repository.
>
>Error handling is not very developed in tcltls.
>
>Hope this helps
>
>-g
>
>
>--- generic/tlsIO.c-orig	2024-06-05 18:38:51
>+++ generic/tlsIO.c	2024-06-05 18:40:44
>@@ -347,6 +347,18 @@
>     ERR_clear_error();
>     bytesRead = BIO_read(statePtr->bio, buf, bufSize);
>     dprintf("BIO_read -> %d", bytesRead);
>+
>+    if (bytesRead == 0 && Tcl_Eof(statePtr->self)) {
>+        /*
>+         * We know through BIO_CTRL_EOF that we are already at
>+         * EOF (determined during BIO_read()). There is no need to
>+         * try to handle this situation via error and reason codes
>+         * from OpenSSL.
>+         */
>+         dprintf("tried to read while channel is already at EOF");
>+         *errorCodePtr = 0;
>+         return(bytesRead);
>+    }
>     err = SSL_get_error(statePtr->ssl, bytesRead);
>     backingError = ERR_get_error();
>

Thanks, I have tried to add this block but it's not triggered.

-- 
Pietro Cerutti
I have pledged to give 10% of income to effective charities
and invite you to join me - https://givingwhatwecan.org

Re: [TCLCORE] tcltls: unexpected 0-bytes [read], then nothing

[Pietro C. <ga...@ga...>]

On Jun 06 2024, 04:15 UTC, Brian O'hagan <bri...@co...> wrote:
[-- Type: text/plain; charset=utf-8, Encoding: quoted-printable, Size: 1.6K --]
>Thanks. So make sure to use the tls-1.8 branch. It has all of my 
>changes including adding back the missed debug option. Jan is working 
>in the trunk and a few other branches, so he’ll need to chime in on his 
>changes there.

Thanks Brian and everyone else who helped out.

Please see here: https://people.freebsd.org/~gahr/tcltls-no-read/

1. test-upstash-manual.tcl
This is the test script I'm using. It optionally authenticates then 
sends two commands (SET the key foo to the value bar, GET the value of 
the key foo) to a Redis server.
The responses should be +OK\r\n for the authentication and the SET 
command, and $3\r\nbar\r\n for the GET command.

2. tls-debug-callback-local-ok.txt
The output of both stdout and stderr when running the script against my 
local Redis server, w/o authentication, like this:
$ tclsh8.6 test-upstash-manual.tcl localhost "" ""
As you can see, I get back both responses.

3. tls-debug-callback-upstash-nok.txt
The output of both stdout and stderr when running the script against my 
test instance on https://upstash.com/, like this:
$ tclsh8.6 test-upstash-manual.tcl blabla.upstash.io defalt my-pass
As you can see, I get back an empty response followed by the first 
response (to AUTH), but never the second (to SET) or third (to GET) 
ones.

In the outputs, you can see outbound data on lines starting with "->" 
and inbound data on lines starting with "<-".

I hope this helps...


-- 
Pietro Cerutti
I have pledged to give 10% of income to effective charities
and invite you to join me - https://givingwhatwecan.org