tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule

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

On Jan 11, 2025, at 08:09, Marc Culler <cul...@gm...> wrote:


I think that the licensing issue is a red herring, in spite of being named as the main point of the TIP.

I think the core issue is whether to rely on undocumented operating system features.  The TIP addresses this by saying "In Tcl 8.6 and 9.0 it is only enabled when the build is configured with --enable-memorymodule".  So, even though this feature may be dangerous, you have to explicitly request it in order to be exposed to the dangers.  Perhaps that is adequate protection - I am not sure.

I do not understand the problem which this optional feature is solving.  The TIP says that the problem (which involves failing to delete temporary files) only arises when Tcl loads a DLL with the "Windows VFS loader".  I don't really know what "Windows VFS" means and the internet was not much help when I tried to read about "Windows VFS".

VFS: Virtual File System

Does "Windows VFS" have another name that might be more familiar? Does "Windows VFS" mean SAMBA?  What are the common, problematic, use cases in which people need Tcl to load a DLL from "Windows VFS"?

Tcl includes support for a zip based VFS. It is used internally when tcl is built with -disable-shared. The result is a single file tclsh.exe that contains the executable and an attached zip file containing the tcl library of scripts and packages, which may include dll files.

At runtime, the dll files are copied out to a temporary location so that the os can load them.
It’s these copies that need to be cleaned up.

-Brian

How common are they?  Where do the orphaned temporary files which get created in the problematic situation end up?  The fact that they do not get cleaned up is being attributed to "a longstanding bug in the implementation of the VFS loader for Windows".  But I don't really know what that means.

I can't really tell how serious this problem is, how prevalent it is, or where it comes from.

- Marc



On Fri, Jan 10, 2025 at 6:04 PM Rolf Ade <tcl...@po...<mailto:tcl...@po...>> wrote:

apnmbx-public--- via Tcl-Core writes:
> FWIW I would not say understanding Windows API’s is the crux of the
> issue. It really has to do with whether Tcl should rely on
> undocumented behaviour and implementation (not just API’s) that might
> change between OS versions.

Not sure if this frames the decision problem at hand right. Without
other context relying "on undocumented behaviour and implementation (not
just API’s) that might change between OS versions" sounds at best
peculiar.

From what I read the proposal fixes real, reported problems of some
people.

I do not know how likely it is, that the "fix" stops to work with some
random windows update. I also don't know how likely other problems are
(beside the most tested registry and dde).

This points back to the knowledge and experience of the windows experts.

rolf

>
>
> From: Marc Culler <cul...@pu...<mailto:cul...@pu...>>
> Sent: Friday, January 10, 2025 7:43 AM
> To: apnmbx-public-/E15...@pu...<mailto:E15...@pu...>
> Cc: Tcl Core List <tcl...@pu...<mailto:tcl-core-5NWGOfrQmneRv%2BL...@pu...>>
> Subject: Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule
>
>
>
> I am getting the impression that  deciding on this TIP will require more experience with Windows APIs than I possess.  I will probably have to leave this decision to the Windows experts.
>
>
>
> - Marc
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jan 9, 2025 at 7:30 PM apnmbx-public--- via Tcl-Core <tcl...@pu...<mailto:tcl-core-5NWGOfrQmneRv%2BL...@pu...> <mailto:tcl...@pu...<mailto:tcl-core-5NWGOfrQmneRv%2BL...@pu...>> > wrote:
>
> I am torn about this TIP.
>
>
>
> On the one hand, it is a very nice feature. On the other hand, it uses undocumented Windows behaviour / API’s which has already changed once (though it was a while ago for Vista). Jan has spent considerable effort on merging patches for MemoryModule and making it robust. Nevertheless, the fact remains it is susceptible to internal design changes in Windows which would cause applications making use this in-memory loading to fail (not fail to load, which would result in an external copy of the DLL to be made but fail at some later point in mysterious ways). If I understood Christian correctly, this does not work in Wine either which points to the dependency on the exact loader implementation.
>
>
>
> But I appreciate the usefulness and the fact that it is not the default build behaviour mitigates my concerns to some extent. Thus my ambivalence.
>
>
>
> For anyone who has not followed earlier discussion, please see ticket https://core.tcl-lang.org/tcl/tktview/a8e4f76ce4.
>
>
>
> /Ashok
>
>
>
>
>
> From: Jan Nijtmans <jan...@pu...<mailto:jan...@pu...> <mailto:jan...@pu...<mailto:jan...@pu...>> >
> Sent: Wednesday, January 8, 2025 9:24 PM
> To: Tcl Core List <tcl...@pu...<mailto:tcl-core-5NWGOfrQmneRv%2BL...@pu...> <mailto:tcl...@pu...<mailto:tcl-core-5NWGOfrQmneRv%2BL...@pu...>> >; Nathan Coulter <com...@pu...<mailto:com...@pu...> <mailto:com...@pu...<mailto:com...@pu...>> >
> Subject: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule
>
>
>
> This is a CFV warning for TIP #699:
>     MPL Licence for MemoryModule
>     <https://core.tcl-lang.org/tips/doc/trunk/tip/709.md>
>
> This is - most likely - the last TIP targeting 8.6 as well.
>
> MemoryModule is already used in androwish (more precisely,
>
> in the LUCK <https://wiki.tcl-lang.org/page/LUCK)>  framework), which is still based on 8.6.
>
> The TIP implementation is based on 9.0, but
>
> backporting to 8.7 and 8.6 is trivial. Since this is an
>
> opt-in feature, default Tcl builds are not affected.
>
>
> The vote process for TIP #705: "Affirm Tcl License" will
>
> (most likely) start soon as well. This TIP can be
>
> seen as an example how to request inclusion
>
> of differently-licensed code in a repository supplied
>
> by the Tcl consortium (anything ending with tcl-lang.org<http://tcl-lang.org> <http://tcl-lang.org> ).
>
> @Nathan Coulter <mailto:com...@pu...<mailto:com...@pu...>>  If you have any spelling/wording
>
> suggestions, please supply them now, not after
>
> the voting finishes!
>
>
> 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
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@pu...<mailto:Tcl-Core-5NWGOfrQmneRv%2BL...@pu...> <mailto:Tcl...@pu...<mailto:Tcl-Core-5NWGOfrQmneRv%2BL...@pu...>>
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@pu...<mailto:Tcl-Core-5NWGOfrQmneRv%2BL...@pu...>
> https://lists.sourceforge.net/lists/listinfo/tcl-core


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

Re: [TCLCORE] On editing of passed TIP's

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

On 2025-01-11 17:43, Gerald Lester wrote:
> On 1/11/25 09:30, Poor Yorick wrote:
>> On 2025-01-11 16:49, Kevin Walzer wrote:
>>> Nathan,
>>> 
>>>> On Jan 11, 2025, at 8:48 AM, Poor Yorick wrote:
>>>> 
>>>> My point is that my commit was reverted without citing any
>>> deficiency in
>>>> the commit. To date, no one has cited any deficiency in the commit.
>>> 
>>> That doesn’t matter. The edits themselves are simply inappropriate.
>>> You don’t have license to make these changes on completed TIPs.
>>> Post-TIP edits should be limited to narrowly targeted clarifications
>>> of unclear technical details, should be discussed by the TCT, voted
>>> on, and documented. Who appointed YOU the copy editor of TIPs? You
>>> don’t seem to understand that you are making a CATEGORICAL
>>> misjudgment here - that your editorial services, buttressed by your
>>> sole editorial discretion and judgment and without input from anyone
>>> else in the community, are required.
>> 
>> This comment was not about edits to a TIP, but about this commit to
>> tcl.n:
>> 
>>     https://core.tcl-lang.org/tcl/file?name=doc/Tcl.n&ci=1117e4b1f0c36d54:
> 
> That is even worse!!!!!!
> 
> That page was generated as part of a TIP.
> 
> The correct procedure would have been to submit a bug report with a 
> suggested fix or a new TIP to address the wording, not just make random 
> changes.
> 
> Sorry, no soup for you.

What TIP are you referring to?  I'm not aware of any TIP that codifies
the documentation for the basic rules of Tcl.  TIPs are generally
understood to be only necessary in order to effect a change to the
public interface of Tcl.  Modification of the documentation to
accurately describe the current implementation does not constitute a
change to the public interface of Tcl.


> 
>> 
>> Regarding edits to TIPs:  If you think an edit is deficient, just 
>> revert it, but make sure you point out the deficiency.
> 
> NO, if YOU think the TIP is incorrect in any way, including grammar, 
> spelling, or anything else then SUBMIT A COMMENT TO THE TCT.
> 
> As to not pointing out why, they were likely trying to be nice to you 
> and not cause you embarrassment. By putting in a comment to the effect: 
> "Nathan is not playing by the rules, again!".
> 
> No soup for you.

I disagree.  Only changes to the normative parts of a TIP require a new
vote.

> 
> 
>> You seem to have a
>> fundamental misunderstanding of the way collaborative development is
>> done in all the repositories:  No one appointed anyone to make any
>> particular changes.  People just make contributions where they have 
>> the
>> skill and the resolve.  If the contributions are good, they are
>> accepted.  If not, they are rejected.
> 
> NO!  You have a refusal to play by the rules as laid down in TIPs 0 
> through 5.
> 
> In other words: You seem to have a fundamental misunderstanding of how 
> Tcl development is to be done.
> 
> No soup for you.

Which particular rule laid out in TIP 0 through 5 do you allege that I'm
violating?  I believe I'm adhering to all the rules.

-- 
Yorick

Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule

[Marc C. <cul...@gm...>]

I think that the licensing issue is a red herring, in spite of being named
as the main point of the TIP.

I think the core issue is whether to rely on undocumented operating system
features.  The TIP addresses this by saying "In Tcl 8.6 and 9.0 it is only
enabled when the build is configured with --enable-memorymodule".  So, even
though this feature may be dangerous, you have to explicitly request it in
order to be exposed to the dangers.  Perhaps that is adequate protection -
I am not sure.

I do not understand the problem which this optional feature is solving.
The TIP says that the problem (which involves failing to delete temporary
files) only arises when Tcl loads a DLL with the "Windows VFS loader".  I
don't really know what "Windows VFS" means and the internet was not much
help when I tried to read about "Windows VFS".  Does "Windows VFS" have
another name that might be more familiar? Does "Windows VFS" mean SAMBA?
What are the common, problematic, use cases in which people need Tcl to
load a DLL from "Windows VFS"?  How common are they?  Where do the orphaned
temporary files which get created in the problematic situation end up?  The
fact that they do not get cleaned up is being attributed to "a longstanding
bug in the implementation of the VFS loader for Windows".  But I don't
really know what that means.

I can't really tell how serious this problem is, how prevalent it is, or
where it comes from.

- Marc



On Fri, Jan 10, 2025 at 6:04 PM Rolf Ade <tcl...@po...> wrote:

>
> apnmbx-public--- via Tcl-Core writes:
> > FWIW I would not say understanding Windows API’s is the crux of the
> > issue. It really has to do with whether Tcl should rely on
> > undocumented behaviour and implementation (not just API’s) that might
> > change between OS versions.
>
> Not sure if this frames the decision problem at hand right. Without
> other context relying "on undocumented behaviour and implementation (not
> just API’s) that might change between OS versions" sounds at best
> peculiar.
>
> From what I read the proposal fixes real, reported problems of some
> people.
>
> I do not know how likely it is, that the "fix" stops to work with some
> random windows update. I also don't know how likely other problems are
> (beside the most tested registry and dde).
>
> This points back to the knowledge and experience of the windows experts.
>
> rolf
>
> >
> >
> > From: Marc Culler <cul...@pu...>
> > Sent: Friday, January 10, 2025 7:43 AM
> > To: apnmbx-public-/E15...@pu...
> > Cc: Tcl Core List <
> tcl...@pu...>
> > Subject: Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for
> MemoryModule
> >
> >
> >
> > I am getting the impression that  deciding on this TIP will require more
> experience with Windows APIs than I possess.  I will probably have to leave
> this decision to the Windows experts.
> >
> >
> >
> > - Marc
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Jan 9, 2025 at 7:30 PM apnmbx-public--- via Tcl-Core <
> tcl...@pu... <mailto:
> tcl...@pu...> > wrote:
> >
> > I am torn about this TIP.
> >
> >
> >
> > On the one hand, it is a very nice feature. On the other hand, it uses
> undocumented Windows behaviour / API’s which has already changed once
> (though it was a while ago for Vista). Jan has spent considerable effort on
> merging patches for MemoryModule and making it robust. Nevertheless, the
> fact remains it is susceptible to internal design changes in Windows which
> would cause applications making use this in-memory loading to fail (not
> fail to load, which would result in an external copy of the DLL to be made
> but fail at some later point in mysterious ways). If I understood Christian
> correctly, this does not work in Wine either which points to the dependency
> on the exact loader implementation.
> >
> >
> >
> > But I appreciate the usefulness and the fact that it is not the default
> build behaviour mitigates my concerns to some extent. Thus my ambivalence.
> >
> >
> >
> > For anyone who has not followed earlier discussion, please see ticket
> https://core.tcl-lang.org/tcl/tktview/a8e4f76ce4.
> >
> >
> >
> > /Ashok
> >
> >
> >
> >
> >
> > From: Jan Nijtmans <jan...@pu...
> <mailto:jan...@pu...> >
> > Sent: Wednesday, January 8, 2025 9:24 PM
> > To: Tcl Core List <
> tcl...@pu... <mailto:
> tcl...@pu...> >; Nathan
> Coulter <com...@pu...
> <mailto:com...@pu...>
> >
> > Subject: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule
> >
> >
> >
> > This is a CFV warning for TIP #699:
> >     MPL Licence for MemoryModule
> >     <https://core.tcl-lang.org/tips/doc/trunk/tip/709.md>
> >
> > This is - most likely - the last TIP targeting 8.6 as well.
> >
> > MemoryModule is already used in androwish (more precisely,
> >
> > in the LUCK <https://wiki.tcl-lang.org/page/LUCK)>  framework), which
> is still based on 8.6.
> >
> > The TIP implementation is based on 9.0, but
> >
> > backporting to 8.7 and 8.6 is trivial. Since this is an
> >
> > opt-in feature, default Tcl builds are not affected.
> >
> >
> > The vote process for TIP #705: "Affirm Tcl License" will
> >
> > (most likely) start soon as well. This TIP can be
> >
> > seen as an example how to request inclusion
> >
> > of differently-licensed code in a repository supplied
> >
> > by the Tcl consortium (anything ending with tcl-lang.org <
> http://tcl-lang.org> ).
> >
> > @Nathan Coulter <mailto:
> com...@pu...>  If
> you have any spelling/wording
> >
> > suggestions, please supply them now, not after
> >
> > the voting finishes!
> >
> >
> > 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
> >
> >
> >
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@pu... <mailto:
> Tcl...@pu...>
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
> >
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@pu...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] On editing of passed TIP's

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

Poor Yorick writes:
> My point is that my commit was reverted without citing any deficiency in
> the commit.  To date, no one has cited any deficiency in the commit.

Well, you commit your changes in the first place without citing and
discussing the deficiency in the original text, no?

And your changes were not only fixing a misspelled word here and
changing a sentence there to streamline grammar. You substantially
changed the text, reduced the number of rules and changed the order how
information was provided.

Incremental improvements of source files happens all the day without
prior discussion and are OK, especially if a clean test suite run
indicates that the changes are OK.

But you changed the central summary text of the Tcl language syntax. And
surely not just or only in an incremental way.

You seem to think that anyone with commit rights is allowed to change
such a central text on _trunk_ without prior communication with the
developer community. I understand that this raises questions about your
judgement skills which are a requisite for giving the power of commit
rights.

Instead of moaning about the revert (which was justified) you would
spend your (and our) time better if you would start to argue for your
proposal so that we, in the best case, end with an improved and
consented text.

rolf

Re: [TCLCORE] On editing of passed TIP's

[Gerald L. <ger...@gm...>]

On 1/11/25 09:30, Poor Yorick wrote:
> On 2025-01-11 16:49, Kevin Walzer wrote:
>> Nathan,
>>
>>> On Jan 11, 2025, at 8:48 AM, Poor Yorick wrote:
>>>
>>> My point is that my commit was reverted without citing any
>> deficiency in
>>> the commit. To date, no one has cited any deficiency in the commit.
>>
>> That doesn’t matter. The edits themselves are simply inappropriate.
>> You don’t have license to make these changes on completed TIPs.
>> Post-TIP edits should be limited to narrowly targeted clarifications
>> of unclear technical details, should be discussed by the TCT, voted
>> on, and documented. Who appointed YOU the copy editor of TIPs? You
>> don’t seem to understand that you are making a CATEGORICAL
>> misjudgment here - that your editorial services, buttressed by your
>> sole editorial discretion and judgment and without input from anyone
>> else in the community, are required.
>
> This comment was not about edits to a TIP, but about this commit to
> tcl.n:
>
>     https://core.tcl-lang.org/tcl/file?name=doc/Tcl.n&ci=1117e4b1f0c36d54: 
>

That is even worse!!!!!!

That page was generated as part of a TIP.

The correct procedure would have been to submit a bug report with a 
suggested fix or a new TIP to address the wording, not just make random 
changes.

Sorry, no soup for you.

>
> Regarding edits to TIPs:  If you think an edit is deficient, just 
> revert it, but make sure you point out the deficiency. 

NO, if YOU think the TIP is incorrect in any way, including grammar, 
spelling, or anything else then SUBMIT A COMMENT TO THE TCT.

As to not pointing out why, they were likely trying to be nice to you 
and not cause you embarrassment. By putting in a comment to the effect: 
"Nathan is not playing by the rules, again!".

No soup for you.


> You seem to have a
> fundamental misunderstanding of the way collaborative development is
> done in all the repositories:  No one appointed anyone to make any
> particular changes.  People just make contributions where they have the
> skill and the resolve.  If the contributions are good, they are
> accepted.  If not, they are rejected. 

NO!  You have a refusal to play by the rules as laid down in TIPs 0 
through 5.

In other words: You seem to have a fundamental misunderstanding of how 
Tcl development is to be done.

No soup for you.


> The vast majority of my hundreds of contributions, representing a 
> significant amount of invested time, have been accepted without any 
> trouble.


When you play by the rules they may.  When you try to break the rules 
they will not be.

-- 
+------------------------------------------------------------------------+
| Gerald W. Lester                                                       |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

Re: [TCLCORE] On editing of passed TIP's

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

On 2025-01-11 16:49, Kevin Walzer wrote:
> Nathan,
> 
>> On Jan 11, 2025, at 8:48 AM, Poor Yorick wrote:
>> 
>> My point is that my commit was reverted without citing any
> deficiency in
>> the commit. To date, no one has cited any deficiency in the commit.
> 
> That doesn’t matter. The edits themselves are simply inappropriate.
> You don’t have license to make these changes on completed TIPs.
> Post-TIP edits should be limited to narrowly targeted clarifications
> of unclear technical details, should be discussed by the TCT, voted
> on, and documented. Who appointed YOU the copy editor of TIPs? You
> don’t seem to understand that you are making a CATEGORICAL
> misjudgment here - that your editorial services, buttressed by your
> sole editorial discretion and judgment and without input from anyone
> else in the community, are required.

This comment was not about edits to a TIP, but about this commit to
tcl.n:

	https://core.tcl-lang.org/tcl/file?name=doc/Tcl.n&ci=1117e4b1f0c36d54:

Regarding edits to TIPs:  If you think an edit is deficient, just revert
it, but make sure you point out the deficiency.  You seem to have a
fundamental misunderstanding of the way collaborative development is
done in all the repositories:  No one appointed anyone to make any
particular changes.  People just make contributions where they have the
skill and the resolve.  If the contributions are good, they are
accepted.  If not, they are rejected.  The vast majority of my hundreds
of contributions, representing a significant amount of invested time,
have been accepted without any trouble.

-- 
Yorick

Re: [TCLCORE] On editing of passed TIP's

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

<div><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/_uVzvH00ytdJj2fw-sP2Z-DqYXC1YUBfTeYxila_zVseVCXfblVTTQFAy8X5bhBKaWbVZb2REiydz1N7kaCpkf490onjJXvUrIkYvDg47LqFudOxQ5QSIoHZyxWCAvOCEHDF5SwWZ5jLK7HrEQTWPSegcK-3NukTtDw1SSUvXjY9VBfgCLnzSLrdZQRw4d6dKbgNIUo2o6AH3zwIVd7RjINBOSrJT5MG' /></div>Nathan,<br/><br/>> On Jan 11, 2025, at 8:48 AM, Poor Yorick <org...@po...> wrote:<br/>> <br/>> My point is that my commit was reverted without citing any deficiency in<br/>> the commit.  To date, no one has cited any deficiency in the commit.<br/><br/>That doesn’t matter. The edits themselves are simply inappropriate. You don’t have license to make these changes on completed TIPs. Post-TIP edits should be limited to narrowly targeted clarifications of unclear technical details, should be discussed by the TCT, voted on, and documented. Who appointed YOU the copy editor of TIPs?  You don’t seem to understand that you are making a CATEGORICAL misjudgment here - that your editorial services, buttressed by your sole editorial discretion and judgment and without input from anyone else in the community, are required. <br/><br/>—Kevin

Re: [TCLCORE] On editing of passed TIP's

[Gerald L. <ger...@gm...>]

On 1/11/25 08:49, Kevin Walzer wrote:
> Nathan,
>
> > On Jan 11, 2025, at 8:48 AM, Poor Yorick wrote:
> >
> > My point is that my commit was reverted without citing any deficiency in
> > the commit. To date, no one has cited any deficiency in the commit.
>
> That doesn’t matter. The edits themselves are simply inappropriate. 
> You don’t have license to make these changes on completed TIPs. 
> Post-TIP edits should be limited to narrowly targeted clarifications 
> of unclear technical details, should be discussed by the TCT, voted 
> on, and documented. Who appointed YOU the copy editor of TIPs? You 
> don’t seem to understand that you are making a CATEGORICAL misjudgment 
> here - that your editorial services, buttressed by your sole editorial 
> discretion and judgment and without input from anyone else in the 
> community, are required.
>
> —Kevin 

Kevin,

As usual, you word things much better than I!

-- 
+------------------------------------------------------------------------+
| Gerald W. Lester                                                       |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

Re: [TCLCORE] On editing of passed TIP's

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

On 2025-01-11 06:40, Gerald Lester wrote:
> On 1/10/25 18:47, tcl...@li... wrote:
>> On 2024-12-31 05:51,apn...@ya...  wrote:
>> 
>>> Nathan, While thanking you for your efforts, I would request you to 
>>> not rewrite substantial portions of a passed TIP for purposes of 
>>> "correcting grammar and wording". Reasons are similar to those that 
>>> led to reversal of your dodekalogue and other manpage edits.
>> 
>> You reverted my changes to the Tcl man page (dodekalogue) without
>> reviewing them, and after they had been committed for YEARS.  
>> Reverting them
>> because of some defect would have been one thing, but you reverted 
>> them just
>> because you couldn't be bothered to take the time to read them.
> 
> Nathan, unless you were with him all day and all night, you have no 
> idea if he did or did not read them.  Basically you are making 
> unsubstantiated allegations that are both uncalled for and unseemly.  
> Making such puts any other statements you make in a questionable light.

My point is that my commit was reverted without citing any deficiency in
the commit.  To date, no one has cited any deficiency in the commit.

> 
> No, TIPS should not be changed unless debated on and should never be 
> changed after passing -- at least not without another TIP correcting 
> it.
> 
> This is like needing an amendment to change the U.S. Constitution, 
> including a previously passed amendment.  We don't do it -- even if 
> some people would love to "clarify" certain portions of the original 
> document or amendments to "more clearly express what they should", well 
> "should" at least in their opinion.

This is true regarding changing the meaning of the formal parts that
were voted on.  It's not true of spelling errors like "it's" vs "its"
and other corrections to grammar, or of historical or explanatory text
that is merely informative and ancillary to what is being voted on.  A
significant portion of most TIPs is merely background information.

-- 
Yorick

Re: [TCLCORE] On editing of passed TIP's

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

On 2025-01-11 07:27, apn...@ya... wrote:
> Nathan,

> Firstly, before you accuse me, please go back to fossil finfo and 
> verify
> Tcl.n commits. Point me to the commit where I reverted your Tcl.n 
> changes. I
> do not recall ever reverting that file.

Nevertheless, you instigated the change.  It had been there for years 
before
you raised the issue.

> 
> As far as approvals go, I do advertise in a branch all changes I make. 
> I see
> a second pair of eyes before merging as a benefit. You see it as a
> hindrance.

You just admonished me about making baseless accusations, and now here 
you are
making them. It is not the first time you have thrown such phrases out.  
I do
not see it as a hindrance.  Some work is better done in a branch before
merging, and some work is not worth a branch.  It's a judgement call.  
Either
way, the change management system makes it easy to review and revert 
work as
needed.


> As far as approvals go, I do advertise in a branch all changes I make. 
> I see
> a second pair of eyes before merging as a benefit. You see it as a
> hindrance.

Working in a branch (which I usually do as well) and then merging it 
does not
automatically mean that anyone has reviewed it.  You yourself know that 
most of
the time no one reads your code before you merge it to trunk.  I don't 
have any
objection to requiring the every commit to trunk to be a merge if people 
decide
that it's worth having such a rule.


> 
> The community does work in democratic fashion. What you seem to want is
> anarchy.

Also baseless opining.  Yes, mudslinging works. Observe the results
presidential election in the United States. What I want is to not have
unnecessary obstacles to people getting work done.  The system makes it 
easy to
review work and revert it or move it to a branch if necessary.  There is 
the
test suite, valgrind, and nightly testing to catch things on the main 
branches
that are problematic.  I worked for several weeks a few years ago making 
sure
that "make valgrind" would return a clean result so that developers 
could use
it to check that they haven't introduced any memory errors.  A couple 
years
later I did the same thing because in the meantime people hadn't 
bothered to
update the valgrind exception list.  Work like that represents real gain 
in
efficiency and correctness without adding any extra burden of process.

The real problem that we have is lack of resources to review
things, and extra rules, procedure, and process take further resources.  
Some
rules are necessary, some are just a drag.  Like it or not, a lot of 
stuff gets
committed to trunk without peer review.

But we were talking about TIPs.  Yes, they're used for voting, but after 
the
vote by far the biggest use of a TIP is for others to read it in order 
to
understand how Tcl now works, and the biggest benefit is for TIPs to be 
easily
readable.  Without extra editing, some of them are impossible to divine 
the
meaning of.  When I start editing a TIP, it's because of something that 
really
does need fixing, but once I'm there I look over other things as well.  
For
example, let's take TIP 538, which I chose at random.  The first issue 
is that
"it's" should be "its".  Not a big change, but worth making.  Since we 
already
have to make a commit in order to make a change, and every commit adds a
little overhead that exists in the repository forever, it's worth 
looking at
what else is worth including in this commit.  There is the phrase "used 
to be
built".  It's passable but a little colloquial, and could be changed to 
"was
previously built".  It economizes one word, reads a little faster, and 
avoids
the ambiguity of the word "used". This is not an improvement that would 
be
worth a new commit, but it might be worth fitting into this commit.  
Further,
there is "will need to be" which could be replaced with "must be", which
economizes two words and eliminates the use of future tense.  Also not 
worth an
individual commit, but also maybe worth changing since a commit is 
already
going to be made.  There are various other changes that would improve 
this TIP,
but that's enough for this example.

Many changes that result in a good document are minor by themselves, but 
they
accumulate, and a well-written document is much easier to read.  There 
is a
difference between "which" and "that", and those paying attention to the
grammar pause a little mentally every time they observe in incorrect 
construct.
Correct grammar makes a real difference in the end.  In short, it's the 
blatant
spelling errors that trigger the need to make a commit, but once a 
commit is
going to be made, it's an opportunity to apply other principles of 
correct
grammar.

You want me to stop fixing errors in TIPs because you don't want to be 
bothered
with reviewing the changes.  I don't think that's reasonable.

-- 
Yorick

Re: [TCLCORE] On editing of passed TIP's

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

Nathan,

Firstly, before you accuse me, please go back to fossil finfo and verify
Tcl.n commits. Point me to the commit where I reverted your Tcl.n changes. I
do not recall ever reverting that file. 

I very rarely, if ever, revert someone else's commits. I did not even revert
the commits you made to 647 that triggered my email because after reviewing
them I did not think they changed semantics. (And whether stuff like
changing "allow" to "make it possible" and "we can correct" to "can be
corrected", "too" to "as well" are worth the edits and add clarity is
doubtful! The original TIP was clear enough.)

Secondly, I do remember the changes you made to the dodekalogue. I also
remember them being reverted *after* discussion by several TCT members, not
a decision by any single individual. Who did the revert is immaterial
because it was carrying out the action that was collectively determined.
Whether Rolf preferred your changes is also immaterial, because the issue
was not which was better or worse, it was about extensive rewrite of what is
the primary documentation of Tcl syntax with zero review from anyone else to
ensure preservation of semantics, not just readability.

You are also making completely baseless claims about whether I reviewed your
changes or not. It so happens I did but what I thought of them had no
bearing on my support for reverting which was entirely based on major
commits being made without review.

You may or may not have changed semantics in TIP's but my prior email
already gave an example where you did change it in the fileevent manpage.
Forgive me for not trusting you on this.

As far as approvals go, I do advertise in a branch all changes I make. I see
a second pair of eyes before merging as a benefit. You see it as a
hindrance.

The community does work in democratic fashion. What you seem to want is
anarchy.

/Ashok

-----Original Message-----
From: Poor Yorick <org...@po...> 
Sent: Saturday, January 11, 2025 6:18 AM
To: apn...@ya...
Cc: tcl...@li...
Subject: Re: On editing of passed TIP's

On 2024-12-31 05:51, apn...@ya... wrote:
> Nathan,
> 
> 
> 
> While thanking you for your efforts, I would request you to not rewrite
> substantial portions of a passed TIP for purposes of "correcting 
> grammar and
> wording". Reasons are similar to those that led to reversal of your
> dodekalogue and other manpage edits.

You reverted my changes to the Tcl man page (dodekalogue) without 
reviewing
them, and after they had been committed for YEARS.  Reverting them 
because of
some defect would have been one thing, but you reverted them just 
because you
couldn't be bothered to take the time to read them.  Rolf on the other 
hand did
review my changes and expressed his preference for them.  Nevertheless, 
they
remain reverted to this day.  I get the impression that all commits have 
to
wait now until you find time to decide whether you like them or not.

The way it should work is that commits that aren't up-to-snuff get 
reverted,
and other commits remain.

> 
> 
> 
> Minor typos are one thing (though even then it's debatable whether they 
> need
> fixing in passed TIPs), but substantial rewrites risk altering the 
> semantics
> of the TIP or manpage, whether intentionally or unintentionally, and 
> must be
> reviewed and agreed to. The dodekalogue edits were reverted because it 
> was
> unclear whether the semantics were preserved or if the rewrite was 
> actually
> clearer than the original. And edits to the fileevent manpage, which 
> removed
> the stated conditions for generating writable events, actually altered
> semantics.
> 
> 
> 
> In the case of voted TIP's in particular, as opposed to manpages, there 
> is
> also the whole other issue of whether the original was really unclear 
> enough
> to need changing (clarifications would have been sought before the 
> vote) and
> justifies expenditure of time to review again.

A lot of TIPs were clearly written in haste and are poorly written.  It 
is
clear that no one bothered to read them, or at least no one bothered to 
correct
them before voting.  I suggest that the core team take more care to 
ensure the
quality of a TIP before voting on it.  Then we won't have these problems
related to fixing them after the fact.

To my knowledge I have not changed the meaning of any text in a TIP such 
that
it substantially impacted what was being voted on.  Also, it's not like
changing the wording of the TIP changes the implementation.  Many TIPs 
are
painted in broad strokes.  You are exaggerating the importance of TIP 
wording.
If there's ever a debate about it, people can always look through the 
commit
history for the TIP.

My opinion is that spelling and grammatical errors, and text that is 
obviously
not written by a native English speaker should be fixed even after 
voting.

--
Yorick

Re: [TCLCORE] On editing of passed TIP's

[Gerald L. <ger...@gm...>]

On 1/10/25 18:47, tcl...@li... wrote:
> On 2024-12-31 05:51,apn...@ya...  wrote:
>
>> Nathan, While thanking you for your efforts, I would request you to 
>> not rewrite substantial portions of a passed TIP for purposes of 
>> "correcting grammar and wording". Reasons are similar to those that 
>> led to reversal of your dodekalogue and other manpage edits. 
>
> You reverted my changes to the Tcl man page (dodekalogue) without
> reviewing them, and after they had been committed for YEARS.  Reverting them
> because of some defect would have been one thing, but you reverted them just
> because you couldn't be bothered to take the time to read them.

Nathan, unless you were with him all day and all night, you have no idea 
if he did or did not read them.  Basically you are making 
unsubstantiated allegations that are both uncalled for and unseemly.  
Making such puts any other statements you make in a questionable light.

> Rolf on the other
> hand did review my changes and expressed his preference for them.
That is nice, but not really relevant.  Because I like something, say 
raw oysters with horseradish, better than something else, say fried 
oysters, and someone else also likes them does not mean that is what is 
best for everyone.
> Nevertheless,they remain reverted to this day.  I get the impression that all commits have
> to wait now until you find time to decide whether you like them or not.
>
>
> The way it should work is that commits that aren't up-to-snuff get
> reverted, and other commits remain.
Up to snuff in whose opinion yours or his?
>> Minor typos are one thing (though even then it's debatable whether 
>> they need fixing in passed TIPs), but substantial rewrites risk 
>> altering the semantics of the TIP or manpage, whether intentionally 
>> or unintentionally, and must be reviewed and agreed to. The 
>> dodekalogue edits were reverted because it was unclear whether the 
>> semantics were preserved or if the rewrite was actually clearer than 
>> the original. And edits to the fileevent manpage, which removed the 
>> stated conditions for generating writable events, actually altered 
>> semantics. In the case of voted TIP's in particular, as opposed to 
>> manpages, there is also the whole other issue of whether the original 
>> was really unclear enough to need changing (clarifications would have 
>> been sought before the vote) and justifies expenditure of time to 
>> review again. 
>
> A lot of TIPs were clearly written in haste and are poorly written.  It
> is clear that no one bothered to read them, or at least no one bothered to
> correct them before voting.  I suggest that the core team take more care to
> ensure the quality of a TIP before voting on it.  Then we won't have these problems
> related to fixing them after the fact.
>
> To my knowledge I have not changed the meaning of any text in a TIP such
> that it substantially impacted what was being voted on.  Also, it's not like
> changing the wording of the TIP changes the implementation.  Many TIPs
> are painted in broad strokes.  You are exaggerating the importance of TIP
> wording.
>
> If there's ever a debate about it, people can always look through the
> commit history for the TIP.
>
> My opinion is that spelling and grammatical errors, and text that is
> obviously not written by a native English speaker should be fixed even after
> voting.

No, TIPS should not be changed unless debated on and should never be 
changed after passing -- at least not without another TIP correcting it.

This is like needing an amendment to change the U.S. Constitution, 
including a previously passed amendment.  We don't do it -- even if some 
people would love to "clarify" certain portions of the original document 
or amendments to "more clearly express what they should", well "should" 
at least in their opinion.

> --
>
> Yorick

-- 
+------------------------------------------------------------------------+
| Gerald W. Lester                                                       |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

Re: [TCLCORE] On editing of passed TIP's

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

On 2024-12-31 05:51, apn...@ya... wrote:
> Nathan,
> 
> 
> 
> While thanking you for your efforts, I would request you to not rewrite
> substantial portions of a passed TIP for purposes of "correcting 
> grammar and
> wording". Reasons are similar to those that led to reversal of your
> dodekalogue and other manpage edits.

You reverted my changes to the Tcl man page (dodekalogue) without 
reviewing
them, and after they had been committed for YEARS.  Reverting them 
because of
some defect would have been one thing, but you reverted them just 
because you
couldn't be bothered to take the time to read them.  Rolf on the other 
hand did
review my changes and expressed his preference for them.  Nevertheless, 
they
remain reverted to this day.  I get the impression that all commits have 
to
wait now until you find time to decide whether you like them or not.

The way it should work is that commits that aren't up-to-snuff get 
reverted,
and other commits remain.

> 
> 
> 
> Minor typos are one thing (though even then it's debatable whether they 
> need
> fixing in passed TIPs), but substantial rewrites risk altering the 
> semantics
> of the TIP or manpage, whether intentionally or unintentionally, and 
> must be
> reviewed and agreed to. The dodekalogue edits were reverted because it 
> was
> unclear whether the semantics were preserved or if the rewrite was 
> actually
> clearer than the original. And edits to the fileevent manpage, which 
> removed
> the stated conditions for generating writable events, actually altered
> semantics.
> 
> 
> 
> In the case of voted TIP's in particular, as opposed to manpages, there 
> is
> also the whole other issue of whether the original was really unclear 
> enough
> to need changing (clarifications would have been sought before the 
> vote) and
> justifies expenditure of time to review again.

A lot of TIPs were clearly written in haste and are poorly written.  It 
is
clear that no one bothered to read them, or at least no one bothered to 
correct
them before voting.  I suggest that the core team take more care to 
ensure the
quality of a TIP before voting on it.  Then we won't have these problems
related to fixing them after the fact.

To my knowledge I have not changed the meaning of any text in a TIP such 
that
it substantially impacted what was being voted on.  Also, it's not like
changing the wording of the TIP changes the implementation.  Many TIPs 
are
painted in broad strokes.  You are exaggerating the importance of TIP 
wording.
If there's ever a debate about it, people can always look through the 
commit
history for the TIP.

My opinion is that spelling and grammatical errors, and text that is 
obviously
not written by a native English speaker should be fixed even after 
voting.

--
Yorick

Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule

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

apnmbx-public--- via Tcl-Core writes:
> FWIW I would not say understanding Windows API’s is the crux of the
> issue. It really has to do with whether Tcl should rely on
> undocumented behaviour and implementation (not just API’s) that might
> change between OS versions.

Not sure if this frames the decision problem at hand right. Without
other context relying "on undocumented behaviour and implementation (not
just API’s) that might change between OS versions" sounds at best
peculiar.

>From what I read the proposal fixes real, reported problems of some
people.

I do not know how likely it is, that the "fix" stops to work with some
random windows update. I also don't know how likely other problems are
(beside the most tested registry and dde).

This points back to the knowledge and experience of the windows experts.

rolf

>  
>
> From: Marc Culler <cul...@pu...> 
> Sent: Friday, January 10, 2025 7:43 AM
> To: apnmbx-public-/E15...@pu...
> Cc: Tcl Core List <tcl...@pu...>
> Subject: Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule
>
>  
>
> I am getting the impression that  deciding on this TIP will require more experience with Windows APIs than I possess.  I will probably have to leave this decision to the Windows experts.
>
>  
>
> - Marc
>
>  
>
>  
>
>  
>
>  
>
>  
>
> On Thu, Jan 9, 2025 at 7:30 PM apnmbx-public--- via Tcl-Core <tcl...@pu... <mailto:tcl...@pu...> > wrote:
>
> I am torn about this TIP.
>
>  
>
> On the one hand, it is a very nice feature. On the other hand, it uses undocumented Windows behaviour / API’s which has already changed once (though it was a while ago for Vista). Jan has spent considerable effort on merging patches for MemoryModule and making it robust. Nevertheless, the fact remains it is susceptible to internal design changes in Windows which would cause applications making use this in-memory loading to fail (not fail to load, which would result in an external copy of the DLL to be made but fail at some later point in mysterious ways). If I understood Christian correctly, this does not work in Wine either which points to the dependency on the exact loader implementation.
>
>  
>
> But I appreciate the usefulness and the fact that it is not the default build behaviour mitigates my concerns to some extent. Thus my ambivalence.
>
>  
>
> For anyone who has not followed earlier discussion, please see ticket https://core.tcl-lang.org/tcl/tktview/a8e4f76ce4. 
>
>  
>
> /Ashok
>
>  
>
>  
>
> From: Jan Nijtmans <jan...@pu... <mailto:jan...@pu...> > 
> Sent: Wednesday, January 8, 2025 9:24 PM
> To: Tcl Core List <tcl...@pu... <mailto:tcl...@pu...> >; Nathan Coulter <com...@pu... <mailto:com...@pu...> >
> Subject: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule
>
>  
>
> This is a CFV warning for TIP #699:
>     MPL Licence for MemoryModule
>     <https://core.tcl-lang.org/tips/doc/trunk/tip/709.md>
>
> This is - most likely - the last TIP targeting 8.6 as well.
>
> MemoryModule is already used in androwish (more precisely,
>
> in the LUCK <https://wiki.tcl-lang.org/page/LUCK)>  framework), which is still based on 8.6.
>
> The TIP implementation is based on 9.0, but
>
> backporting to 8.7 and 8.6 is trivial. Since this is an
>
> opt-in feature, default Tcl builds are not affected.
>
>
> The vote process for TIP #705: "Affirm Tcl License" will
>
> (most likely) start soon as well. This TIP can be
>
> seen as an example how to request inclusion
>
> of differently-licensed code in a repository supplied
>
> by the Tcl consortium (anything ending with tcl-lang.org <http://tcl-lang.org> ).
>
> @Nathan Coulter <mailto:com...@pu...>  If you have any spelling/wording
>
> suggestions, please supply them now, not after
>
> the voting finishes!
>
>
> 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
>
>  
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@pu... <mailto:Tcl...@pu...> 
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@pu...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule

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

On 2025-01-10 21:48, Jan Nijtmans wrote:
[SNIP]
> 
> Part of the question is also non-technical. Should the quality
> of code be a reason to accept or decline it in one of our
> repositories? If TIP #705 "Affirm Tcl License" wouldn't be
> there, TIP #709 wouldn't have been written at all. It also
> means that - if TIP #709 is declined, I have to close the
> branch and cannot even work on it any more, trying to
> make it even more GREAT than it already is ;-)
> 

Right.  TIP 705 just makes development of Tcl more difficult for no real
benefit to anyone.  The whole point of branches is to allow people to 
work in
their own corner where they don't affect any other branch until a 
decision to
merge is made.

-- 
Yorick

Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule

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

Op vr 10 jan 2025 om 19:58 schreef Kevin Walzer:
> I'd caution against relying on undocumented/private API's unless there is a GREAT reason to do so. Windows has been remarkably stable for Tcl/Tk, and it would be shame for API churn (typical of Apple) to make its way into that source tree.

That's part of the point here. I think, being able to load dll's in memory is
such a GREAT reason. Ashok is IMHO exaggerating on how bad
MemoryModule is, looking at the code it is - actually - programmed
quite well. Well enough that it is picked up by other projects, and
other people were contributing back their fixes. I wrote testcases
for various situations Ashok pointed out to be problematic: All of
those worked fine! A "great" reason would be enough for me,
it doesn't even need to be GREAT.

Since I was not able to convince Ashok, it's now on our plate to
decide.

Part of the question is also non-technical. Should the quality
of code be a reason to accept or decline it in one of our
repositories? If TIP #705 "Affirm Tcl License" wouldn't be
there, TIP #709 wouldn't have been written at all. It also
means that - if TIP #709 is declined, I have to close the
branch and cannot even work on it any more, trying to
make it even more GREAT than it already is ;-)

Hope this helps,
    Jan Nijtmans

Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule

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

I'd caution against relying on undocumented/private API's unless there 
is a GREAT reason to do so. Windows has been remarkably stable for 
Tcl/Tk, and it would be shame for API churn (typical of Apple) to make 
its way into that source tree.

On 1/10/25 11:29 AM, apnmbx-public--- via Tcl-Core wrote:
>
> FWIW I would not say understanding Windows API’s  is the crux of the 
> issue. It really has to do with whether Tcl should rely on 
> undocumented behaviour and implementation (not just API’s) that might 
> change between OS versions.
>
> *From:*Marc Culler <cul...@gm...>
> *Sent:* Friday, January 10, 2025 7:43 AM
> *To:* apn...@ya...
> *Cc:* Tcl Core List <tcl...@li...>
> *Subject:* Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for 
> MemoryModule
>
> I am getting the impression that  deciding on this TIP will require 
> more experience with Windows APIs than I possess.  I will probably 
> have to leave this decision to the Windows experts.
>
> - Marc
>
> On Thu, Jan 9, 2025 at 7:30 PM apnmbx-public--- via Tcl-Core 
> <tcl...@li...> wrote:
>
>     I am torn about this TIP.
>
>     On the one hand, it is a very nice feature. On the other hand, it
>     uses undocumented Windows behaviour / API’s which has already
>     changed once (though it was a while ago for Vista). Jan has spent
>     considerable effort on merging patches for MemoryModule and making
>     it robust. Nevertheless, the fact remains it is susceptible to
>     internal design changes in Windows which would cause applications
>     making use this in-memory loading to fail (not fail to load, which
>     would result in an external copy of the DLL to be made but fail at
>     some later point in mysterious ways). If I understood Christian
>     correctly, this does not work in Wine either which points to the
>     dependency on the exact loader implementation.
>
>     But I appreciate the usefulness and the fact that it is not the
>     default build behaviour mitigates my concerns to some extent. Thus
>     my ambivalence.
>
>     For anyone who has not followed earlier discussion, please see
>     ticket https://core.tcl-lang.org/tcl/tktview/a8e4f76ce4.
>
>     /Ashok
>
>     *From:*Jan Nijtmans <jan...@gm...>
>     *Sent:* Wednesday, January 8, 2025 9:24 PM
>     *To:* Tcl Core List <tcl...@li...>; Nathan
>     Coulter <com...@po...>
>     *Subject:* [TCLCORE] CFV warning: TIP #709: MPL Licence for
>     MemoryModule
>
>     This is a CFV warning for TIP #699:
>         MPL Licence for MemoryModule
>         <https://core.tcl-lang.org/tips/doc/trunk/tip/709.md>
>
>     This is - most likely - the last TIP targeting 8.6 as well.
>
>     MemoryModule is already used in androwish (more precisely,
>
>     in the LUCK <https://wiki.tcl-lang.org/page/LUCK)> framework),
>     which is still based on 8.6.
>
>     The TIP implementation is based on 9.0, but
>
>     backporting to 8.7 and 8.6 is trivial. Since this is an
>
>     opt-in feature, default Tcl builds are not affected.
>
>
>     The vote process for TIP #705: "Affirm Tcl License" will
>
>     (most likely) start soon as well. This TIP can be
>
>     seen as an example how to request inclusion
>
>     of differently-licensed code in a repository supplied
>
>     by the Tcl consortium (anything ending with tcl-lang.org
>     <http://tcl-lang.org>).
>
>     @Nathan Coulter
>     <mailto:com...@po...> If you have any
>     spelling/wording
>
>     suggestions, please supply them now, not after
>
>     the voting finishes!
>
>
>     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
>
>     _______________________________________________
>     Tcl-Core mailing list
>     Tcl...@li...
>     https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule

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

FWIW I would not say understanding Windows API’s  is the crux of the issue. It really has to do with whether Tcl should rely on undocumented behaviour and implementation (not just API’s) that might change between OS versions.

 

From: Marc Culler <cul...@gm...> 
Sent: Friday, January 10, 2025 7:43 AM
To: apn...@ya...
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule

 

I am getting the impression that  deciding on this TIP will require more experience with Windows APIs than I possess.  I will probably have to leave this decision to the Windows experts.

 

- Marc

 

 

 

 

 

On Thu, Jan 9, 2025 at 7:30 PM apnmbx-public--- via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > wrote:

I am torn about this TIP.

 

On the one hand, it is a very nice feature. On the other hand, it uses undocumented Windows behaviour / API’s which has already changed once (though it was a while ago for Vista). Jan has spent considerable effort on merging patches for MemoryModule and making it robust. Nevertheless, the fact remains it is susceptible to internal design changes in Windows which would cause applications making use this in-memory loading to fail (not fail to load, which would result in an external copy of the DLL to be made but fail at some later point in mysterious ways). If I understood Christian correctly, this does not work in Wine either which points to the dependency on the exact loader implementation.

 

But I appreciate the usefulness and the fact that it is not the default build behaviour mitigates my concerns to some extent. Thus my ambivalence.

 

For anyone who has not followed earlier discussion, please see ticket https://core.tcl-lang.org/tcl/tktview/a8e4f76ce4. 

 

/Ashok

 

 

From: Jan Nijtmans <jan...@gm... <mailto:jan...@gm...> > 
Sent: Wednesday, January 8, 2025 9:24 PM
To: Tcl Core List <tcl...@li... <mailto:tcl...@li...> >; Nathan Coulter <com...@po... <mailto:com...@po...> >
Subject: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule

 

This is a CFV warning for TIP #699:
    MPL Licence for MemoryModule
    <https://core.tcl-lang.org/tips/doc/trunk/tip/709.md>

This is - most likely - the last TIP targeting 8.6 as well.

MemoryModule is already used in androwish (more precisely,

in the LUCK <https://wiki.tcl-lang.org/page/LUCK)>  framework), which is still based on 8.6.

The TIP implementation is based on 9.0, but

backporting to 8.7 and 8.6 is trivial. Since this is an

opt-in feature, default Tcl builds are not affected.


The vote process for TIP #705: "Affirm Tcl License" will

(most likely) start soon as well. This TIP can be

seen as an example how to request inclusion

of differently-licensed code in a repository supplied

by the Tcl consortium (anything ending with tcl-lang.org <http://tcl-lang.org> ).

@Nathan Coulter <mailto:com...@po...>  If you have any spelling/wording

suggestions, please supply them now, not after

the voting finishes!


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

 

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

[TCLCORE] January 14 2025 Tcl monthly virtual meetup notice

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

A reminder that the next meetup will be held Tuesday January 14 2025 at [clock format 1736906400] Tuesday 6pm US West, 8pm US Central, 9pm US East, Wednesday 2am UTC, 2am UK, 3am Western Europe, 7:30am India, 10am Australia West / Singapore / China, 11am Japan, 1pm Australia East, 3pm New Zealand

Details (including how to connect) are available via https://wiki.tcl-lang.org/page/Monthly+Virtual+Meetup

-- Steve

Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule

[Marc C. <cul...@gm...>]

I am getting the impression that  deciding on this TIP will require more
experience with Windows APIs than I possess.  I will probably have to leave
this decision to the Windows experts.

- Marc





On Thu, Jan 9, 2025 at 7:30 PM apnmbx-public--- via Tcl-Core <
tcl...@li...> wrote:

> I am torn about this TIP.
>
>
>
> On the one hand, it is a very nice feature. On the other hand, it uses
> undocumented Windows behaviour / API’s which has already changed once
> (though it was a while ago for Vista). Jan has spent considerable effort on
> merging patches for MemoryModule and making it robust. Nevertheless, the
> fact remains it is susceptible to internal design changes in Windows which
> would cause applications making use this in-memory loading to fail (not
> fail to load, which would result in an external copy of the DLL to be made
> but fail at some later point in mysterious ways). If I understood Christian
> correctly, this does not work in Wine either which points to the dependency
> on the exact loader implementation.
>
>
>
> But I appreciate the usefulness and the fact that it is not the default
> build behaviour mitigates my concerns to some extent. Thus my ambivalence.
>
>
>
> For anyone who has not followed earlier discussion, please see ticket
> https://core.tcl-lang.org/tcl/tktview/a8e4f76ce4.
>
>
>
> /Ashok
>
>
>
>
>
> *From:* Jan Nijtmans <jan...@gm...>
> *Sent:* Wednesday, January 8, 2025 9:24 PM
> *To:* Tcl Core List <tcl...@li...>; Nathan Coulter <
> com...@po...>
> *Subject:* [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule
>
>
>
> This is a CFV warning for TIP #699:
>     MPL Licence for MemoryModule
>     <https://core.tcl-lang.org/tips/doc/trunk/tip/709.md>
>
> This is - most likely - the last TIP targeting 8.6 as well.
>
> MemoryModule is already used in androwish (more precisely,
>
> in the LUCK <https://wiki.tcl-lang.org/page/LUCK)> framework), which is
> still based on 8.6.
>
> The TIP implementation is based on 9.0, but
>
> backporting to 8.7 and 8.6 is trivial. Since this is an
>
> opt-in feature, default Tcl builds are not affected.
>
>
> The vote process for TIP #705: "Affirm Tcl License" will
>
> (most likely) start soon as well. This TIP can be
>
> seen as an example how to request inclusion
>
> of differently-licensed code in a repository supplied
>
> by the Tcl consortium (anything ending with tcl-lang.org).
>
> @Nathan Coulter <com...@po...> If you have
> any spelling/wording
>
> suggestions, please supply them now, not after
>
> the voting finishes!
>
>
> 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
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule

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

I am torn about this TIP.

 

On the one hand, it is a very nice feature. On the other hand, it uses undocumented Windows behaviour / API’s which has already changed once (though it was a while ago for Vista). Jan has spent considerable effort on merging patches for MemoryModule and making it robust. Nevertheless, the fact remains it is susceptible to internal design changes in Windows which would cause applications making use this in-memory loading to fail (not fail to load, which would result in an external copy of the DLL to be made but fail at some later point in mysterious ways). If I understood Christian correctly, this does not work in Wine either which points to the dependency on the exact loader implementation.

 

But I appreciate the usefulness and the fact that it is not the default build behaviour mitigates my concerns to some extent. Thus my ambivalence.

 

For anyone who has not followed earlier discussion, please see ticket https://core.tcl-lang.org/tcl/tktview/a8e4f76ce4. 

 

/Ashok

 

 

From: Jan Nijtmans <jan...@gm...> 
Sent: Wednesday, January 8, 2025 9:24 PM
To: Tcl Core List <tcl...@li...>; Nathan Coulter <com...@po...>
Subject: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule

 

This is a CFV warning for TIP #699:
    MPL Licence for MemoryModule
    <https://core.tcl-lang.org/tips/doc/trunk/tip/709.md>

This is - most likely - the last TIP targeting 8.6 as well.

MemoryModule is already used in androwish (more precisely,

in the LUCK <https://wiki.tcl-lang.org/page/LUCK)>  framework), which is still based on 8.6.

The TIP implementation is based on 9.0, but

backporting to 8.7 and 8.6 is trivial. Since this is an

opt-in feature, default Tcl builds are not affected.


The vote process for TIP #705: "Affirm Tcl License" will

(most likely) start soon as well. This TIP can be

seen as an example how to request inclusion

of differently-licensed code in a repository supplied

by the Tcl consortium (anything ending with tcl-lang.org <http://tcl-lang.org> ).

@Nathan Coulter <mailto:com...@po...>  If you have any spelling/wording

suggestions, please supply them now, not after

the voting finishes!


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] CFV - TIP 705: Affirm Tcl License

[Jos D. <jos...@gm...>]

TIP 705: YES

Jos.

On Thu, Jan 9, 2025 at 8:12 AM Harald Oehlmann <har...@el...>
wrote:

> Am 09.01.2025 um 01:55 schrieb Kevin Walzer:
> > Hi all,
> >
> > Sorry this got away from me - the holidays and some other projects took
> > priority.
> >
> > This is a CFV for TIP 705. Let's have the vote in by 01/13/2025.
> >
> > My vote: YES.
> My vote: Yes.
>
> Thanks for all,
> Harald
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] CFV - TIP 705: Affirm Tcl License

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

TIP 705: Yes

rolf

"Kevin Walzer" <kw-...@pu...> writes:
> Hi all,
>
> Sorry this got away from me - the holidays and some other projects took 
> priority.
>
> This is a CFV for TIP 705. Let's have the vote in by 01/13/2025.
>
> My vote: YES.
>
> Thanks,
>
> Kevin
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@pu...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV - TIP 705: Affirm Tcl License

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

> TIP 705

VOTE:	YES

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

Re: [TCLCORE] CFV - TIP 705: Affirm Tcl License

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

Op do 9 jan 2025 om 01:55 schreef Kevin Walzer <kw...@co...>:

> This is a CFV for TIP 705. Let's have the vote in by 01/13/2025.
>

My vote: YES

Regards,
     Jan Nijtmans