tcl-core — Tcl Core Team discussions about Tcl development

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

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

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


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

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

[TCLCORE] CFV: TIP #696

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

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

Re: [TCLCORE] New Edition of Developer's Guide & Questions

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

Am 04.06.2024 um 16:06 schrieb Clif Flynt via Tcl-Core:
> Hi,
>    I'm updating Tcl/Tk: A Developer's Guide for 9.0 and other
> changes since 2011 (so long ago!).

Great action !!!!!

>    The sources for binary distributions I referenced back then
> have largely vanished, or don't seem to be up to date.
> 
>    Is there an accepted site for binaries nowadays? Any single site that
> provides binaries for Linux/Unix, Windows and Mac? Or preferred site
> for a given platform.

With clear 9.0, there is:
BAWT
Windows: Magicsplat

I can imagine, that AndroWish/Undroidwish will follow.

Take care,
Harald

>    Also, if anyone wants to volunteer as a beta-reader, let me know.
>    
>    Happy Tcl'ing,
>    Clif
> 

[TCLCORE] New Edition of Developer's Guide & Questions

[Clif F. <CL...@CF...>]

Hi,
  I'm updating Tcl/Tk: A Developer's Guide for 9.0 and other
changes since 2011 (so long ago!).

  The sources for binary distributions I referenced back then
have largely vanished, or don't seem to be up to date.

  Is there an accepted site for binaries nowadays? Any single site that
provides binaries for Linux/Unix, Windows and Mac? Or preferred site
for a given platform.
  
  Also, if anyone wants to volunteer as a beta-reader, let me know.
  
  Happy Tcl'ing,
  Clif

-- 
... Clif Flynt ... http://www.cflynt.com ... cl...@cf... ....
.. Tcl/Tk: A Developer's Guide (3'd edition) - Morgan Kauffman ..
.............. Promised Rewards - Dark Myth Press ...............
.......... 5 Minutes in Hotel Stormcove - Atthis Arts ...........
...........  Unidentified Funny Objects, #7, #8, #9  ............

[TCLCORE] tdbc error?

[Zaumseil R. <RZa...@kk...>]

Hello

Running the following script results in a message "database locked".
If I change "attach ..." to "-- attach ..." the script run without error.
I use sqlite version 3.43.1 and tdbc 1.1.1

===
    package require tdbc::sqlite3
    set myFile D:/testdb
    set myDb ::DB
    catch "$myDb close"
    ::tdbc::sqlite3::connection create $myDb $myFile -readonly 0 -timeout 1000
    set myS [$myDb prepare {
attach $myFile as cms;
    }]
    $myS execute
    $myS close
    $myDb transaction {
        set myS [$myDb prepare {
drop table if exists t1;
create table if not exists t1 (x,y);
                }]
        set myR [$myS execute]
        $myS close
        set myS [$myDb prepare {
select name from pragma_table_info('t1')
                }]
        $myS close
    }
    $myDb close
===

Running the equivalent sqlite script is ok:

===
    catch {::DB close}
    sqlite3 ::DB D:/test1 -readonly 0
    ::DB timeout 1000
    ::DB eval {
attach $myFile as cms;
    }
    ::DB transaction {
                ::DB eval {
drop table if exists t1;
create table if not exists t1 (x,y);
        }
                ::DB eval {
select name from pragma_table_info('t1')
                }
    }
===

Thank you for any hints

rene

Re: [TCLCORE] Documentation of integer truncation in [expr]essions

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

Op vr 31 mei 2024 om 21:11 schreef Dipl. Ing. Sergey G. Brester:
> For Tcl (8.7+) the solely possibility to get it would be something like that:
>
> if {$::tcl_platform(wordSize) == 4} {
>   proc ::tcl::mathfunc::c_long i {
>     set i [expr {$i & 0xffffffff}]
>     expr { ($i ^ 0x80000000) - 0x80000000 }
>   }
> } else {
>   proc ::tcl::mathfunc::c_long i {
>     set i [expr {$i & 0xffffffffffffffff}]
>     expr { ($i ^ 0x8000000000000000) - 0x8000000000000000 }
>   }
> }

Of course, we can add additional functions. But we
could also recommend to use the wide() function
as building block to implement those. e.g.:

    proc ::tcl::mathfunc::int32 i {
        return [expr {wide($i<<32)>>32}]
    }
    proc ::tcl::mathfunc::int16 i {
        return [expr {wide($i<<48)>>48}]
    }
or
    if {$::tcl_platform(wordSize) == 4} {
        proc ::tcl::mathfunc::c_long i {
            return [expr {wide($i<<32)>>32}]
        }
    } else {
        proc ::tcl::mathfunc::c_long i {
            return [::tcl::mathfunc::wide $i]
        }
    }

I don't know why someone would want a different
behavior depending on $::tcl_platform(wordSize),
that's why I didn't bother to implement that.

Donald G Porter wrote:
> My preferred solution is to take the position that Tcl 9 documentation
> has no duty to instruct on how to migrate expressions from Tcl 8.4.  That
> transition happened long ago.  Strike the sentences.

Agreed!

Hope this helps,
         Jan Nijtmans

Re: [TCLCORE] TclLang twitter feed

[Neophytos D. <neo...@gm...>]

Dear Ashok,

Thank you for your kind and considerate email. I am genuinely appreciative
of the efforts you put into managing the feed, which plays a pivotal role
in our community's engagement and outreach.

Please let me know how I can contribute and any specific areas where you
might need an extra pair of hands. I am ready and willing to help in any
capacity that serves our community best.

Warmest regards,
Neophytos

On Mon, Jun 3, 2024 at 9:47 AM <apn...@ya...> wrote:

> Mea culpa.
>
>
>
> It’s an unofficial feed I maintain. I used to be more scrupulous in
> tracking release announcements on comp.lang.tcl and the wiki but over the
> past year have been negligent, only updating when I happen to come across a
> release announcement by chance.
>
>
>
> Need to get better with that.
>
>
>
> I’ll post those two. Let me know if there are others.
>
>
>
> /Ashok
>
>
>
> *From:* Neophytos Demetriou <neo...@gm...>
> *Sent:* Monday, June 3, 2024 5:20 PM
> *To:* tcl...@li...
> *Subject:* [TCLCORE] TclLang twitter feed
>
>
>
> Dear Tcl Core Team,
>
> I hope this message finds you well. I am reaching out to kindly inquire
> about the curation process of the TclLang Twitter feed. As it is
> prominently featured on the TCL wiki, I am interested in understanding
> whether it is officially maintained by the Tcl Core Team. Additionally, I
> would be grateful if you could share any guidelines that determine the
> content shared on the feed.
>
> I have noticed that certain projects, such as tink-tcl (
> https://github.com/jerily/tink-tcl ), which has been available since
> October 2023 and then again in April 2024, have not been featured on the
> feed and I cannot understand why. Similarly, aws-sdk-tcl (
> https://github.com/jerily/aws-sdk-tcl ) was not included until a recent
> release with a missing commit broke the build. As a member of the TCL
> community, I am curious about these selections and would appreciate any
> clarity you can provide.
>
> Thank you for your time and attention to this matter. I look forward to
> your response.
>
> Warm regards,
>
> Neophytos
>

Re: [TCLCORE] TclLang twitter feed

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

Mea culpa.

 

It’s an unofficial feed I maintain. I used to be more scrupulous in tracking release announcements on comp.lang.tcl and the wiki but over the past year have been negligent, only updating when I happen to come across a release announcement by chance.

 

Need to get better with that.

 

I’ll post those two. Let me know if there are others.

 

/Ashok

 

From: Neophytos Demetriou <neo...@gm...> 
Sent: Monday, June 3, 2024 5:20 PM
To: tcl...@li...
Subject: [TCLCORE] TclLang twitter feed

 

Dear Tcl Core Team,

I hope this message finds you well. I am reaching out to kindly inquire about the curation process of the TclLang Twitter feed. As it is prominently featured on the TCL wiki, I am interested in understanding whether it is officially maintained by the Tcl Core Team. Additionally, I would be grateful if you could share any guidelines that determine the content shared on the feed.

I have noticed that certain projects, such as tink-tcl ( https://github.com/jerily/tink-tcl ), which has been available since October 2023 and then again in April 2024, have not been featured on the feed and I cannot understand why. Similarly, aws-sdk-tcl ( https://github.com/jerily/aws-sdk-tcl ) was not included until a recent release with a missing commit broke the build. As a member of the TCL community, I am curious about these selections and would appreciate any clarity you can provide.

Thank you for your time and attention to this matter. I look forward to your response.

Warm regards,

Neophytos

[TCLCORE] TclLang twitter feed

[Neophytos D. <neo...@gm...>]

Dear Tcl Core Team,

I hope this message finds you well. I am reaching out to kindly inquire
about the curation process of the TclLang Twitter feed. As it is
prominently featured on the TCL wiki, I am interested in understanding
whether it is officially maintained by the Tcl Core Team. Additionally, I
would be grateful if you could share any guidelines that determine the
content shared on the feed.

I have noticed that certain projects, such as tink-tcl (
https://github.com/jerily/tink-tcl ), which has been available since
October 2023 and then again in April 2024, have not been featured on the
feed and I cannot understand why. Similarly, aws-sdk-tcl (
https://github.com/jerily/aws-sdk-tcl ) was not included until a recent
release with a missing commit broke the build. As a member of the TCL
community, I am curious about these selections and would appreciate any
clarity you can provide.

Thank you for your time and attention to this matter. I look forward to
your response.

Warm regards,
Neophytos

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

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

Am 03.06.2024 um 10:44 schrieb Poor Yorick:
> On 2024-06-03 11:23, apn...@ya... wrote:
>> My "Really!" comment was directed at your insinuation that every command
>> that executes synchronously should have explicit documentation that it
>> executes synchronously and it is is fair game to change it to 
>> asynchronous
>> in the absence of such. Not at the following sentence.
>>
>> Since I was apparently not clear before, I will therefore explicitly ask
>> again - do you think any command that is not specifically documented as
>> synchronous can be changed to asynchronous behavior without a TIP ?
>>
>> If your answer is Yes, as you seem to think, there is nothing more 
>> discuss
>> as you have a difference of opinion with respect to TIP's.
>>
>> If your answer is No, there is nothing more to discuss, as we then 
>> agree you
>> need to write a TIP.
>>
> 
> My answer is that [chan postevent] was always sufficiently documented as
> asynchronous, that no one has ever relied on it to be synchronous, that
> no one has ever shown a need for it to be synchronous, that it was
> always intended to be asynchronous, and that the campaign to suddenly
> label it as synchronous based on buggy behaviour, and without any
> evidenced need, is ridiculous.  Ridiculous and harmful, particularly as
> it propagates broken refchans into the Tcl 9 release.
> 
> You all should submit a TIP to make [chan postevent] synchronous if you
> really believe that nonsense.

Sorry, it is synchroneous.

Please author a TIP if it should be changed to asynchoneous.

Thank you for your comprehension,
Harald

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

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

On 2024-06-03 11:23, apn...@ya... wrote:
> My "Really!" comment was directed at your insinuation that every 
> command
> that executes synchronously should have explicit documentation that it
> executes synchronously and it is is fair game to change it to 
> asynchronous
> in the absence of such. Not at the following sentence.
> 
> Since I was apparently not clear before, I will therefore explicitly 
> ask
> again - do you think any command that is not specifically documented as
> synchronous can be changed to asynchronous behavior without a TIP ?
> 
> If your answer is Yes, as you seem to think, there is nothing more 
> discuss
> as you have a difference of opinion with respect to TIP's.
> 
> If your answer is No, there is nothing more to discuss, as we then 
> agree you
> need to write a TIP.
> 

My answer is that [chan postevent] was always sufficiently documented as
asynchronous, that no one has ever relied on it to be synchronous, that
no one has ever shown a need for it to be synchronous, that it was
always intended to be asynchronous, and that the campaign to suddenly
label it as synchronous based on buggy behaviour, and without any
evidenced need, is ridiculous.  Ridiculous and harmful, particularly as
it propagates broken refchans into the Tcl 9 release.

You all should submit a TIP to make [chan postevent] synchronous if you
really believe that nonsense.


-- 
yorick

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

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

My "Really!" comment was directed at your insinuation that every command
that executes synchronously should have explicit documentation that it
executes synchronously and it is is fair game to change it to asynchronous
in the absence of such. Not at the following sentence.

Since I was apparently not clear before, I will therefore explicitly ask
again - do you think any command that is not specifically documented as
synchronous can be changed to asynchronous behavior without a TIP ?

If your answer is Yes, as you seem to think, there is nothing more discuss
as you have a difference of opinion with respect to TIP's.

If your answer is No, there is nothing more to discuss, as we then agree you
need to write a TIP.

/Ashok

-----Original Message-----
From: Poor Yorick <org...@po...> 
Sent: Monday, June 3, 2024 1:38 PM
To: tcl...@li...
Subject: Re: [TCLCORE] [chan postevent] must be asynchronous

On 2024-06-03 05:07, apn...@ya... wrote:
> Nathan wrote: "Was it ever documented to be synchronous?"
> 
> The vast majority of commands are synchronous. Afaict, none of them are
> documented to be so. The expectation is always that a command is 
> synchronous
> unless stated otherwise. This is the norm not just in Tcl but all 
> languages.
> I cannot suddenly decide on my own that a command would work better if 
> it
> traversed the event loop first before execution and then claim the docs
> never said it had to be synchronous! Really?
> 

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
places an event notification on the event queue.  In other words,
Tcl_QueueEvent operates asynchronously by letting the event queue
mediate notification.  Since Tcl_QueueEvent is asynchronous,  [chan
postevent] is clearly also intended to be asynchronous.  Event the name
"postevent" implies that.  The command posts an event.  And where does
it post the event to?  To the event queue of course.

-- 
Yorick


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

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

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

Am 03.06.2024 um 10:17 schrieb Poor Yorick:
> On 2024-06-03 11:10, Harald Oehlmann wrote:
> 
>>
>>
>> Thanks for this valuable contribution.
>> As already stated, please put it into a TIP.
> 
> No, this is not TIP territory.  This is bug territory.
> 
> The fix for this bug has been in place for 5 years, and suddenly people 
> want to TIP it?  No.
> 

Dear Nathan,

Sorry,
yes to TIP it.
A TIP is required.

Thank you for your comprehension,
Harald

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

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

On 2024-06-03 11:10, Harald Oehlmann wrote:

> 
> 
> Thanks for this valuable contribution.
> As already stated, please put it into a TIP.

No, this is not TIP territory.  This is bug territory.

The fix for this bug has been in place for 5 years, and suddenly people 
want to TIP it?  No.

-- 
Nathan

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

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

Am 03.06.2024 um 10:07 schrieb Poor Yorick:
> On 2024-06-03 05:07, apn...@ya... wrote:
>> Nathan wrote: "Was it ever documented to be synchronous?"
>>
>> The vast majority of commands are synchronous. Afaict, none of them are
>> documented to be so. The expectation is always that a command is 
>> synchronous
>> unless stated otherwise. This is the norm not just in Tcl but all 
>> languages.
>> I cannot suddenly decide on my own that a command would work better if it
>> traversed the event loop first before execution and then claim the docs
>> never said it had to be synchronous! Really?
>>
> 
> 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
> places an event notification on the event queue.  In other words,
> Tcl_QueueEvent operates asynchronously by letting the event queue
> mediate notification.  Since Tcl_QueueEvent is asynchronous,  [chan
> postevent] is clearly also intended to be asynchronous.  Event the name
> "postevent" implies that.  The command posts an event.  And where does
> it post the event to?  To the event queue of course.
> 


Thanks for this valuable contribution.
As already stated, please put it into a TIP.

Thank you and take care,
Harald

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

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

On 2024-06-03 05:07, apn...@ya... wrote:
> Nathan wrote: "Was it ever documented to be synchronous?"
> 
> The vast majority of commands are synchronous. Afaict, none of them are
> documented to be so. The expectation is always that a command is 
> synchronous
> unless stated otherwise. This is the norm not just in Tcl but all 
> languages.
> I cannot suddenly decide on my own that a command would work better if 
> it
> traversed the event loop first before execution and then claim the docs
> never said it had to be synchronous! Really?
> 

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
places an event notification on the event queue.  In other words,
Tcl_QueueEvent operates asynchronously by letting the event queue
mediate notification.  Since Tcl_QueueEvent is asynchronous,  [chan
postevent] is clearly also intended to be asynchronous.  Event the name
"postevent" implies that.  The command posts an event.  And where does
it post the event to?  To the event queue of course.

-- 
Yorick

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

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

Hi Nathan,

thank you for pointing out, that the documentation of "chan readable 
synchroneous" is missing.

Please fullfill the 3 given tasks.

Thank you for your comprehension,
Harald

Am 02.06.2024 um 22:56 schrieb Poor Yorick:
> On 2024-06-02 20:01, Harald Oehlmann wrote:
>> Hi Nathan,
>>
>> thank you for the message.
>>
>> May I invite you to the following actions:
>> 1) "chan postevent" is synchoneous. If you want to change this, please 
>> follow the steps indicated by Ashok:
>> - write a TIP
> 
> Was it ever documented to be synchronous?  Did any change I made require
> a change in the documentation?  If not, no TIP is required to fix bugs
> in the implementation.
> 
> More importantly, why would anyone expect [chan postevent] to be
> anything other than asynchronous in its behaviour?
> 
> 
>> - put an implementation into a branch
>> - start a discussion on the core list
>> 2) The two issue report [67a5eabb] and [de232b49] will not fix with 
>> the current solution. The formulated RFE are not fixable without 
>> action 1). They are correctly closed and should stay closed forever. A 
>> change is only possible by action 1 above.
> 
> There is no documentation indicating that the behaviour illustrated in
> these reports is expected.  They are valid issues and should remain
> open.
> 
>> 3) In the message 2024-05-15, you announced a change in the 
>> documentation of chan.n and SetResult.3. You were invited to back them 
>> out and present them in a branch for discussion. You were already 
>> reminded to do this action, but it did not happen jet. Please do this 
>> action.
> 
> I'm planning to do this when I find time.

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

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

Nathan wrote: "Was it ever documented to be synchronous?"

The vast majority of commands are synchronous. Afaict, none of them are
documented to be so. The expectation is always that a command is synchronous
unless stated otherwise. This is the norm not just in Tcl but all languages.
I cannot suddenly decide on my own that a command would work better if it
traversed the event loop first before execution and then claim the docs
never said it had to be synchronous! Really?

It's a separate matter that your change caused events generated by working
refchans in both tcllib and twapi to needlessly traverse the event loop an
additional time.

" More importantly, why would anyone expect [chan postevent] to be
anything other than asynchronous in its behaviour?"

TIP the change along with a *technical* rationale, not opinions like
"refchans are hard to use", and we may get some answers. So far I have not
heard a single reason. Your tickets do not serve as rationale simply because
the refchan implementations in them were faulty.

/Ashok

-----Original Message-----
From: Poor Yorick <org...@po...> 
Sent: Monday, June 3, 2024 2:27 AM
To: tcl...@li...
Subject: Re: [TCLCORE] [chan postevent] must be asynchronous

On 2024-06-02 20:01, Harald Oehlmann wrote:
> Hi Nathan,
> 
> thank you for the message.
> 
> May I invite you to the following actions:
> 1) "chan postevent" is synchoneous. If you want to change this, please 
> follow the steps indicated by Ashok:
> - write a TIP

Was it ever documented to be synchronous?  Did any change I made require
a change in the documentation?  If not, no TIP is required to fix bugs
in the implementation.

More importantly, why would anyone expect [chan postevent] to be
anything other than asynchronous in its behaviour?


> - put an implementation into a branch
> - start a discussion on the core list
> 2) The two issue report [67a5eabb] and [de232b49] will not fix with the 
> current solution. The formulated RFE are not fixable without action 1). 
> They are correctly closed and should stay closed forever. A change is 
> only possible by action 1 above.

There is no documentation indicating that the behaviour illustrated in
these reports is expected.  They are valid issues and should remain
open.

> 3) In the message 2024-05-15, you announced a change in the 
> documentation of chan.n and SetResult.3. You were invited to back them 
> out and present them in a branch for discussion. You were already 
> reminded to do this action, but it did not happen jet. Please do this 
> action.

I'm planning to do this when I find time.


-- 
Yorick


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

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

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

On 2024-06-02 20:01, Harald Oehlmann wrote:
> Hi Nathan,
> 
> thank you for the message.
> 
> May I invite you to the following actions:
> 1) "chan postevent" is synchoneous. If you want to change this, please 
> follow the steps indicated by Ashok:
> - write a TIP

Was it ever documented to be synchronous?  Did any change I made require
a change in the documentation?  If not, no TIP is required to fix bugs
in the implementation.

More importantly, why would anyone expect [chan postevent] to be
anything other than asynchronous in its behaviour?


> - put an implementation into a branch
> - start a discussion on the core list
> 2) The two issue report [67a5eabb] and [de232b49] will not fix with the 
> current solution. The formulated RFE are not fixable without action 1). 
> They are correctly closed and should stay closed forever. A change is 
> only possible by action 1 above.

There is no documentation indicating that the behaviour illustrated in
these reports is expected.  They are valid issues and should remain
open.

> 3) In the message 2024-05-15, you announced a change in the 
> documentation of chan.n and SetResult.3. You were invited to back them 
> out and present them in a branch for discussion. You were already 
> reminded to do this action, but it did not happen jet. Please do this 
> action.

I'm planning to do this when I find time.


-- 
Yorick

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

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

Hi Nathan,

thank you for the message.

May I invite you to the following actions:
1) "chan postevent" is synchoneous. If you want to change this, please 
follow the steps indicated by Ashok:
- write a TIP
- put an implementation into a branch
- start a discussion on the core list
2) The two issue report [67a5eabb] and [de232b49] will not fix with the 
current solution. The formulated RFE are not fixable without action 1). 
They are correctly closed and should stay closed forever. A change is 
only possible by action 1 above.
3) In the message 2024-05-15, you announced a change in the 
documentation of chan.n and SetResult.3. You were invited to back them 
out and present them in a branch for discussion. You were already 
reminded to do this action, but it did not happen jet. Please do this 
action.

Your cooperation is highly appreciated.

Thank you and take care,
Harald



Am 01.06.2024 um 00:53 schrieb Poor Yorick:
> 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.  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 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 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].

[TCLCORE] [chan postevent] must be asynchronous

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

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


-- 
yorick

Re: [TCLCORE] Documentation of integer truncation in [expr]essions

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

 

The issue with that is: you don't really have the simple possibility 
to get SIGNED platform integer (e. g. native C-long) if needed.

For unsigned there is indeed & 0xFF..FF, but even then one'd need
to make it depending on tcl_platform(wordSize), if C-long is expected.
For the signed, it's even more complex, see example below.

Command [scan] is ugly, because it'd scan the string representation,
but if you need it for pure math (arithmetic operations only), it
implies
that integer firstly converting to string and then scanned as a native
integer.

Many languages have stock functions (or modules) that allow such 
conversions (or casts) to the c-type, Tcl would not have them anymore.
For instance python: 

>>> import ctypes
>>> ctypes.c_long(0x8888888888888888).value
-8608480567731124088 (or -2004318072 for 32-bit long) 

For Tcl (8.7+) the solely possibility to get it would be something like
that: 

if {$::tcl_platform(wordSize) == 4} {
 proc ::tcl::mathfunc::c_long i {
 set i [expr {$i & 0xffffffff}]
 expr { ($i ^ 0x80000000) - 0x80000000 }
 }
} else {
 proc ::tcl::mathfunc::c_long i {
 set i [expr {$i & 0xffffffffffffffff}]
 expr { ($i ^ 0x8000000000000000) - 0x8000000000000000 }
 }
} 

Or to write a C-tcl-binding implementing such "casts" natively.
Or use ffidl or similar packages that can convert to native C types. 

So perhaps besides the documentation we'd provide some math-functions 
doing such "casting", e. g. int32, int64, longc, llongc, etc. 

Regards,
Serg 

31.05.2024 19:40, Donald G Porter via Tcl-Core wrote: 

> The documentation page for [expr] includes migration instructions for
> any [expr]essions written for Tcl releases 8.4 or earlier that relied
> on the implicit range truncation of integer values on overflow that was
> in place before Tcl 8.5. The instructions relied on the truncation
> effects provided by the functions int(.) and wide(.).
> 
> In Tcl 9 (8.7+), int(.) no longer truncates. (TIP 514) The docs have
> just been updated to stop advising use of int(.) to restore truncation.
> That's a positive step, but doesn't leave the docs in an accurate state.
> 
> The wide(.) function does continue to truncate, but it is not enough
> alone as a tool to craft 8.4-equivalent expressions regarding truncation.
> If some long legacy expression needs calculations to be done modulo the
> machine word size, the Tcl 9 tool would have to be some application of
> [scan] or some application of masking (& 0xFF...FF) at the right places.
> 
> My preferred solution is to take the position that Tcl 9 documentation
> has no duty to instruct on how to migrate expressions from Tcl 8.4. That
> transition happened long ago. Strike the sentences.
> 
> Posting to TCLCORE just in case there are other viewpoints needing to
> be heard.
 

[TCLCORE] Documentation of integer truncation in [expr]essions

[Donald G P. <don...@ni...>]

The documentation page for [expr] includes migration instructions for
any [expr]essions written for Tcl releases 8.4 or earlier that relied
on the implicit range truncation of integer values on overflow that was
in place before Tcl 8.5.  The instructions relied on the truncation
effects provided by the functions int(.) and wide(.).

In Tcl 9 (8.7+), int(.) no longer truncates. (TIP 514)  The docs have
just been updated to stop advising use of int(.) to restore truncation.
That's a positive step, but doesn't leave the docs in an accurate state.

The wide(.) function does continue to truncate, but it is not enough
alone as a tool to craft 8.4-equivalent expressions regarding truncation.
If some long legacy expression needs calculations to be done modulo the
machine word size, the Tcl 9 tool would have to be some application of
[scan] or some application of masking (& 0xFF...FF) at the right places.

My preferred solution is to take the position that Tcl 9 documentation
has no duty to instruct on how to migrate expressions from Tcl 8.4.  That
transition happened long ago.  Strike the sentences.

Posting to TCLCORE just in case there are other viewpoints needing to
be heard.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] github mirrors not syncing

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

> Op wo 29 mei 2024 om 18:20 schreef Andreas Kupries:
> > With the Technote at that location mirroring synched it and now believes that
> > it has nothing to synch anymore, despite more commits appearing __underneath__
> > the TN.
> 
> So, the lesson is: no technotes in the future any more. Check!

Yes.

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