tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] CFV: TIP 701: C API for tilde substitution in paths

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

Op ma 21 okt 2024 om 08:32 schreef Ashok:

> This is a CFV for TIP 701: C API for tilde substitution in paths
>
>
>
> Please send me your votes by Oct 30 00:00 UTC.
>

 TIP #701:     YES

Regards,
      Jan Nijtmans

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

Op ma 21 okt 2024 om 08:13 schreef Ashok:

> Regarding the alternative of always installing into C:/Tcl/lib (even in an
> embedded ZIP build)…
>
>
>
> This precludes the ActiveState “basedll” or Roy’s “kitdll” style single
> file shared library configurations. Maybe that’s ok, maybe not. I do not
> use that config myself, not sure how many people do but separate DLL’s
> would make it not an option.
>

Please read this "C:/Tcl" as : same installation directory as Tcl 8.6.
"nmake -f makefile.vc install" already installs those dll's there.
My counter-proposal is only a very minimal one in makefile.vc:
    Tcl Source Code: Diff (tcl-lang.org)
<https://core.tcl-lang.org/tcl/fdiff?v1=7e901ffe3d7b512f&v2=8c3ccb5be8fb00eb>

We could talk about changing the default Tcl install dir, but
that's another topic.

Hope this helps,
        Jan Nijtmans

[TCLCORE] CFV: TIP 701: C API for tilde substitution in paths

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

This is a CFV for TIP 701: C API for tilde substitution in paths

 

Please send me your votes by Oct 30 00:00 UTC.

 

/Ashok

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

Jan,

 

Regarding registry and dde being dangerous…

 

As Kevin K. pointed out, if writing to the registry is dangerous, so is writing to the file system. For non-privileged applications, the OS should provide protection. For privileged applications, overwriting any number of files will tank the system as much as writing to sensitive registry keys. With respect to DDE, if an application wants to be a server (which is the case with security implications), whether the dde command is statically linked or not is immaterial. It will load it regardless. The same also applies to third party applications.

 

I am also somewhat skeptical of the rationale of keeping “dangerous” commands out of Tcl, whatever they might be. That’s what safe interpreters are for, aren’t they?

 

Regarding registry and dde not having the best API…

 

That’s a red herring and orthogonal to this TIP. Nothing precludes someone implementing a better API in the future.

 

Regarding the “package require” comment …

 

While I am ok with always having the commands available, the package require need is for backward compatibility reasons as mentioned in the TIP. Existing applications that do not load Tcl’s registry package but have their own “registry” command (which may not even have anything to do with the Windows registry) will not be affected. If folks think this is not a likely issue, I have no objections to always having the commands available.

 

Regarding whether modules should not be compiled into the core…

 

I am not sure I completely understood the point or why it is a bad idea. For example, modules that are expensive to initialize can very well benefit from having to be explicitly loaded. Even ICU, were it to make it into the core in some form at some future point, would be an example. In any case, the static shell has always had these compiled in so not really breaking new ground here.

 

Regarding the alternative of always installing into C:/Tcl/lib (even in an embedded ZIP build)…

 

This precludes the ActiveState “basedll” or Roy’s “kitdll” style single file shared library configurations. Maybe that’s ok, maybe not. I do not use that config myself, not sure how many people do but separate DLL’s would make it not an option.

 

Thanks for the comments. And no need for apologies; soliciting differing opinions is the primary point of a TIP!

 

/Ashok

 

From: Jan Nijtmans <jan...@gm...> 
Sent: Sunday, October 20, 2024 4:56 PM
To: Kevin Kenny <kev...@gm...>
Cc: tcl...@li...
Subject: Re: [TCLCORE] TIP 702 - static linking for registry and dde

 

Op zo 20 okt 2024 om 02:47 schreef Kevin Kenny:

For what it's worth, my understanding was that the original reason (which has fallen by the wayside) was that the Core proper didn't include anything that couldn't at least in concept be implemented on all three platforms.

 

Moreover, the extensions were thought to provide relatively simple worked examples of how to package an extension on Windows.

 

Sentiment used to favour unbundling: keeping features out of the Core but having the ones that were expected to be universal published as bundled extensions. That's one reason why I never proposed tdbc as bundled; a more important one was that I wasn't sure that the API was quite right and didn't want to freeze it for years or decades, as would happen if it came under TIP control and required a major Tcl release to introduce any incompatibilities. 

 

New leadership will of course have new directions, and if the pendulum is swinging back toward greater inclusion. I don't object.

 

I hope I will not the only one to be objecting, but here are my reasons:

1) dde and registry are 'dangerous' extensions. Dde has the same functionality as the "send" command,
    which was disabled due to security concerns. Registry makes it possible to read and write
    registry settings, which could also make the computer screw up completely. Separating
    them would make it possible to remove them, if some application doesn't need it.

2) dde and registry don't have the best API we can think of. dde would best be integrated in

   a new "send" command. The registry commands should feel more oo-like.

3) Every command should either be included, then no "package require" should be needed.

   Or it should be a module, activated by "package require". With TIP #702, "dde" and "registry"

   will be the only modules which are compiled into the Tcl library. Do we think it's a

   good example to other modules to do that? I don't think so. Either provide the "dde" and

   "registry" commands as being available always (which I wouldn't do due to 1) and 2),
  or make them a separate module loadable at wish (which they are now)

 

That said, I recognise the problem addressed in the TIP. Actually, there are 4 problems now.

1) Extracting ddl's from the zip-file takes time and is not 100% full-proof. That's something

which should be addressed (there already is a ticket for that)

2) Even if we can include dde.ddl and registry.ddl in the zip, the question is if we really
want to do that. We could just install those in C:\Tcl\lib\registry1.3 resp C:\Tcl\lib\dde1.4

(as is done now in Tcl 8.6), then all current problems are gone.

3) Currently, registry.dll is loaded at startup because the new "clock" command needs it.
It would be better to have a native clock subcommand, which reads the timezone
from the registry, in C, without the need to load registry.dll for doing that.

4) I think Tk also loads "registry.dll" at startup. I'm sure there's a way to prevent that too.

 

I'll create a new ticket, proposing to install registry and dde in C:\Tcl\lib, instead of packing

it into the zip-file. I think that's a better way going forward than TIP #702.

 

Sorry, Ashok,

 

Regards,

     Jan Nijtmans

Re: [TCLCORE] TIP 702 - static linking for registry and dde

[Christian G. <aur...@gm...>]

Am 20.10.24 um 22:56 schrieb Kevin Walzer:
>  > A final rant: what about ditching "dde" and "registry" once and for
>  > all and to add CFFI or FFIDL and reimplement those two
>  > guys in plain Tcl? And d(or whatever letter)bus using this
>  > infrastructure, too?
>
> Excellent idea  - Python has had "ctypes" for a long time and it allows
> full access to any kind of native API that you could ask for. All that
> needs to happen is for someone to do the work.
>

Well at least the hard part is already done by Ashok:

          https://github.com/apnadkarni/tcl-cffi

Now it would be great to add THIS to the core.

           Christian

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

<div><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/71ywrk27YImvZvlm_LSyQb_-Flhh8kng9TfcZSAlzxOdvE_cYxAizqZjnzOLmXCtMS4AHRnCEV8ipVOLRFEHSbZWSbba0lQUOthfqkrR0XDMckwYzI2Evxy2iOkh7cQ_AAwSzZF1E5ygKBJeYdtLj9TteWqgeGBJ8Ba0nlk6U1MzBC6-TW9Cpzn1Uc3joJZOnQR4HdLtcEWXSIle937fHawtnOd6ozwu' /></div>Hi Christian,<br/><br/>On 10/20/2024 02:20 PM, Kevin Walzer wrote:<br/><br/>><br/>>> ... Robust toolkits like Qt and wxWidgets support these out of the <br/>>> box. Tk should be able to serve data to other applications ...<br/>><br/>> Sorry Kevin, out of the poor fragility of our beloved toolkit I cannot <br/>> resist to ask about things like ICE, comm, Tcl-DP which<br/>> predate many of these other guys. And weren't there many attempts to <br/>> interface Tcl to something useful. Few days ago I had<br/>> a deeper look into tcluno (the bridge to the (Open|Libre)Office <br/>> world). Tons of code I managed not to do what was advertised.<br/>> My impression was not positive, that bridge is broken. I'm afraid, Tcl <br/>> is a hopeless case. Never be able to follow the cultural<br/>> en vogue trends in time. The all time flash in the pan.<br/><br/>I can't speak to any of the examples you cite. What little I know of <br/>them are that they are mostly various separate Tcl-only approaches to <br/>duplicate the "send" command - why that would need to be done is a <br/>mystery to me. Tcluno is a separate thing, obvioulsy, but I don't know <br/>much about it.<br/><br/>I'm referring to something different altogether. I'm referring to <br/>platform-native standard API's for IPC. I think that Tcl/Tk should <br/>support these in some form out of the box in order to be a better app <br/>citizen on each platform. DDE or COM, AppleEvents, and dbus are those <br/>interfaces.<br/><br/>><br/>> Now we discuss about the (in|ex)clusion of those ancient prehistoric <br/>> "dde" and "registry" things being part or not of the Tcl<br/>> binary while the real problem is Win32's unwillingness to <br/>> LoadLibrary() from memory streams. I bet that chrome, mozilla, and<br/>> even edge found ways to more or less safely load native code without <br/>> problems.<br/>><br/>> A final rant: what about ditching "dde" and "registry" once and for <br/>> all and to add CFFI or FFIDL and reimplement those two<br/>> guys in plain Tcl? And d(or whatever letter)bus using this <br/>> infrastructure, too?<br/><br/>Excellent idea  - Python has had "ctypes" for a long time and it allows <br/>full access to any kind of native API that you could ask for. All that <br/>needs to happen is for someone to do the work.<br/><br/>--Kevin<br/>

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

<div><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/xWvKr2ex9xZkADTfpqxRTBNXkZt21-qSR2rSVj8QWFY1AtNO4tKCQZhlTFXmcQBikDhnDbnjn_qDV4mc2T5aH8L-jsLtpkbyPgJVrT58teqq_Uqo_wBHGXcKgXUVulRCZraLkjyEHSCbaSar-It0AMAbLKutk3P-QrsiIdimUysvUmv1fCFXBo0vpWuxXvJP6SsgCVQjySd4x1DGwFkhxnQDDsHS-hGA' /></div>On 10/20/24 4:46 PM, Schelte Bron wrote:<br/><br/>> The "send" command is very useful for debugging Tcl/Tk programs. I use <br/>> it almost daily. I strongly disagree that it is obsolete. Removing it <br/>> would mean losing a very handy tool. <br/>Well, we missed an opportunity to remove it anyway with 9.0. So it will <br/>stay.<br/>

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

On 20/10/2024 14:20, Kevin Walzer wrote:
> I have never understood the value of “send”. It’s non-functional on 
> macOS and Windows, and only works with other Tk apps on X11, which is 
> far too limited to be useful. It’s obsolete and should be removed.
> 
The "send" command is very useful for debugging Tcl/Tk programs. I use 
it almost daily. I strongly disagree that it is obsolete. Removing it 
would mean losing a very handy tool.


Schelte.

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

This thread is becoming hard to follow,  because some participants are not
replying to the list.  Please try to copy the list on replies.

- Marc

On Sun, Oct 20, 2024 at 2:57 PM Harald Oehlmann <har...@el...>
wrote:

> Am 20.10.2024 um 13:26 schrieb Jan Nijtmans:
> > Op zo 20 okt 2024 om 02:47 schreef Kevin Kenny:
> >
> >     For what it's worth, my understanding was that the original reason
> >     (which has fallen by the wayside) was that the Core proper didn't
> >     include anything that couldn't at least in concept be implemented on
> >     all three platforms.
> >
> >     Moreover, the extensions were thought to provide relatively simple
> >     worked examples of how to package an extension on Windows.
> >
> >     Sentiment used to favour unbundling: keeping features out of the
> >     Core but having the ones that were expected to be universal
> >     published as bundled extensions. That's one reason why I never
> >     proposed tdbc as bundled; a more important one was that I wasn't
> >     sure that the API was quite right and didn't want to freeze it for
> >     years or decades, as would happen if it came under TIP control and
> >     required a major Tcl release to introduce any incompatibilities.
> >
> >     New leadership will of course have new directions, and if the
> >     pendulum is swinging back toward greater inclusion. I don't object.
> >
> >
> > I hope I will not the only one to be objecting, but here are my reasons:
> > 1) dde and registry are 'dangerous' extensions. Dde has the same
> > functionality as the "send" command,
> >      which was disabled due to security concerns. Registry makes it
> > possible to read and write
> >      registry settings, which could also make the computer screw up
> > completely. Separating
> >      them would make it possible to remove them, if some application
> > doesn't need it.
> > 2) dde and registry don't have the best API we can think of. dde would
> > best be integrated in
> >     a new "send" command. The registry commands should feel more oo-like.
> > 3) Every command should either be included, then no "package require"
> > should be needed.
> >     Or it should be a module, activated by "package require". With TIP
> > #702, "dde" and "registry"
> >     will be the only modules which are compiled into the Tcl library. Do
> > we think it's a
> >     good example to other modules to do that? I don't think so. Either
> > provide the "dde" and
> >     "registry" commands as being available always (which I wouldn't do
> > due to 1) and 2),
> >    or make them a separate module loadable at wish (which they are now)
> >
> > That said, I recognise the problem addressed in the TIP. Actually, there
> > are 4 problems now.
> > 1) Extracting ddl's from the zip-file takes time and is not 100% full-
> > proof. That's something
> > which should be addressed (there already is a ticket for that)
> > 2) Even if we can include dde.ddl and registry.ddl in the zip, the
> > question is if we really
> > want to do that. We could just install those in C:\Tcl\lib\registry1.3
> > resp C:\Tcl\lib\dde1.4
> > (as is done now in Tcl 8.6), then all current problems are gone.
> > 3) Currently, registry.dll is loaded at startup because the new "clock"
> > command needs it.
> > It would be better to have a native clock subcommand, which reads the
> > timezone
> > from the registry, in C, without the need to load registry.dll for doing
> > that.
> > 4) I think Tk also loads "registry.dll" at startup. I'm sure there's a
> > way to prevent that too.
> >
> > I'll create a new ticket, proposing to install registry and dde in C:
> > \Tcl\lib, instead of packing
> > it into the zip-file. I think that's a better way going forward than TIP
> > #702.
> >
> > Sorry, Ashok,
> >
> > Regards,
> >       Jan Nijtmans
> My 2 pence:
> - msgcat also loads the registry package.
> - I am not the opinion, that the registry package is dangerous. Critical
> changes may only be done by administrator priviledges.
> - So, I would advocate to move the registry stuff to the core. It is
> central on Windows.
> - The dde package is IMHO not so important and may IMHO even move to
> bundled packages
> - For me, the single executable facility is of central importance. I
> would love, that the any library may be included and that it does not
> produce a new copy on each start. I would love to have a constant
> temporary path for contained libraries. I would also like, that they
> keep their names (e.g.registry.dll) and not "tcl12345678.dll".
> If this is solved, the TIP is of less importance.
>
> Thanks for all,
> Harald
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

Am 20.10.2024 um 13:26 schrieb Jan Nijtmans:
> Op zo 20 okt 2024 om 02:47 schreef Kevin Kenny:
> 
>     For what it's worth, my understanding was that the original reason
>     (which has fallen by the wayside) was that the Core proper didn't
>     include anything that couldn't at least in concept be implemented on
>     all three platforms.
> 
>     Moreover, the extensions were thought to provide relatively simple
>     worked examples of how to package an extension on Windows.
> 
>     Sentiment used to favour unbundling: keeping features out of the
>     Core but having the ones that were expected to be universal
>     published as bundled extensions. That's one reason why I never
>     proposed tdbc as bundled; a more important one was that I wasn't
>     sure that the API was quite right and didn't want to freeze it for
>     years or decades, as would happen if it came under TIP control and
>     required a major Tcl release to introduce any incompatibilities.
> 
>     New leadership will of course have new directions, and if the
>     pendulum is swinging back toward greater inclusion. I don't object.
> 
> 
> I hope I will not the only one to be objecting, but here are my reasons:
> 1) dde and registry are 'dangerous' extensions. Dde has the same 
> functionality as the "send" command,
>      which was disabled due to security concerns. Registry makes it 
> possible to read and write
>      registry settings, which could also make the computer screw up 
> completely. Separating
>      them would make it possible to remove them, if some application 
> doesn't need it.
> 2) dde and registry don't have the best API we can think of. dde would 
> best be integrated in
>     a new "send" command. The registry commands should feel more oo-like.
> 3) Every command should either be included, then no "package require" 
> should be needed.
>     Or it should be a module, activated by "package require". With TIP 
> #702, "dde" and "registry"
>     will be the only modules which are compiled into the Tcl library. Do 
> we think it's a
>     good example to other modules to do that? I don't think so. Either 
> provide the "dde" and
>     "registry" commands as being available always (which I wouldn't do 
> due to 1) and 2),
>    or make them a separate module loadable at wish (which they are now)
> 
> That said, I recognise the problem addressed in the TIP. Actually, there 
> are 4 problems now.
> 1) Extracting ddl's from the zip-file takes time and is not 100% full- 
> proof. That's something
> which should be addressed (there already is a ticket for that)
> 2) Even if we can include dde.ddl and registry.ddl in the zip, the 
> question is if we really
> want to do that. We could just install those in C:\Tcl\lib\registry1.3 
> resp C:\Tcl\lib\dde1.4
> (as is done now in Tcl 8.6), then all current problems are gone.
> 3) Currently, registry.dll is loaded at startup because the new "clock" 
> command needs it.
> It would be better to have a native clock subcommand, which reads the 
> timezone
> from the registry, in C, without the need to load registry.dll for doing 
> that.
> 4) I think Tk also loads "registry.dll" at startup. I'm sure there's a 
> way to prevent that too.
> 
> I'll create a new ticket, proposing to install registry and dde in C: 
> \Tcl\lib, instead of packing
> it into the zip-file. I think that's a better way going forward than TIP 
> #702.
> 
> Sorry, Ashok,
> 
> Regards,
>       Jan Nijtmans
My 2 pence:
- msgcat also loads the registry package.
- I am not the opinion, that the registry package is dangerous. Critical 
changes may only be done by administrator priviledges.
- So, I would advocate to move the registry stuff to the core. It is 
central on Windows.
- The dde package is IMHO not so important and may IMHO even move to 
bundled packages
- For me, the single executable facility is of central importance. I 
would love, that the any library may be included and that it does not 
produce a new copy on each start. I would love to have a constant 
temporary path for contained libraries. I would also like, that they 
keep their names (e.g.registry.dll) and not "tcl12345678.dll".
If this is solved, the TIP is of less importance.

Thanks for all,
Harald

Re: [TCLCORE] TIP 702 - static linking for registry and dde

[Christian W. <Chr...@t-...>]

On 10/20/2024 02:20 PM, Kevin Walzer wrote:

> ... Robust toolkits like Qt and wxWidgets support these out of the box. Tk should be able to serve data to other applications ...

Sorry Kevin, out of the poor fragility of our beloved toolkit I cannot resist to ask about things like ICE, comm, Tcl-DP which
predate many of these other guys. And weren't there many attempts to interface Tcl to something useful. Few days ago I had
a deeper look into tcluno (the bridge to the (Open|Libre)Office world). Tons of code I managed not to do what was advertised.
My impression was not positive, that bridge is broken. I'm afraid, Tcl is a hopeless case. Never be able to follow the cultural
en vogue trends in time. The all time flash in the pan.

Now we discuss about the (in|ex)clusion of those ancient prehistoric "dde" and "registry" things being part or not of the Tcl
binary while the real problem is Win32's unwillingness to LoadLibrary() from memory streams. I bet that chrome, mozilla, and
even edge found ways to more or less safely load native code without problems.

A final rant: what about ditching "dde" and "registry" once and for all and to add CFFI or FFIDL and reimplement those two
guys in plain Tcl? And d(or whatever letter)bus using this infrastructure, too?

BR,
Christian

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

On Sun, Oct 20, 2024 at 7:26 AM Jan Nijtmans <jan...@gm...> wrote:

>
> I hope I will not the only one to be objecting, but here are my reasons:
> 1) dde and registry are 'dangerous' extensions. Dde has the same
> functionality as the "send" command,
>     which was disabled due to security concerns. Registry makes it
> possible to read and write
>     registry settings, which could also make the computer screw up
> completely. Separating
>     them would make it possible to remove them, if some application
> doesn't need it.
>

For what it's worth, I've never used 'dde' to have Tcl accept DDE
transactions. I've used it only to inject commands into foreign
applications. (I seldom need dde for that any more. Tcom and Twapi do what
I need, and do it better.)

'dde' and 'send' did have severe security implications because of the
danger of code injection from another application on the machine.  The same
argument doesn't apply to the use of 'dde' to command foreign applications
or of 'registry' to modify registry settings. Issuing a command to a
foreign app, or querying or adjusting the registry, is under the full
control of the programmer.  It doesn't hand the reins to an unrelated
application.

Registry actions are kind of required.  On Windows, for instance, as you
observe, [clock] needs to query the registry for time zone and locale
information. I don't see why it should be any different whether the query
originates in a Tcl script or a C wrapper function. We've generally
operated on the principle of having the language provide to users
everything that the library can do.

Tcl scripts have access to the filesystem and to [exec], both of which
already provide ample ways to screw up the computer.


-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

<div><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/w9RFJy8VY4uLSMR-YeDYGzlisv0asz3HIFlm2pt4DEGz_a-gJxROqJi6MKv_DDqpBpXfy5_cG280hVbS1Qng3fBmk0azaaSSQ5LZ2wIoAZMoH9Trs2qgzQNEcpve7ujD_FUQ0qplkmGTZBTMNEpmSOAfI9b4rg4Dl7mXPqUvFD0PaHyBwz55k6GKKMvoHOCgmnJvzCQjpOUN_1a751ARjZ9bBN0a_NrM' /></div>I have never understood the value of “send”. It’s non-functional on macOS and Windows, and only works with other Tk apps on X11, which is far too limited to be useful.  It’s obsolete and should be removed. <br/><br/>Each platform provides a native API for IPC - AppleEvents on macOS, dde or COM on Windows, and dbus on X11. Robust toolkits like Qt and wxWidgets support these out of the box. Tk should be able to serve data to other applications  over these connections, and also consume it. I make use of this in all my apps. <br/><br/>My thought is not to submerge these under a single new command. The API’s are too different. But bundling all in one form or another makes sense. <br/><br/>> On Oct 20, 2024, at 7:26 AM, Jan Nijtmans <jan...@gm...> wrote:<br/>> <br/>> 1) dde and registry are 'dangerous' extensions. Dde has the same functionality as the "send" command,<br/>>     which was disabled due to security concerns. Registry makes it possible to read and write<br/>>     registry settings, which could also make the computer screw up completely. Separating<br/>>     them would make it possible to remove them, if some application doesn't need it.<br/>> 2) dde and registry don't have the best API we can think of. dde would best be integrated in<br/>>    a new "send" command. The registry commands should feel more oo-like.<br/>

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

Op zo 20 okt 2024 om 02:47 schreef Kevin Kenny:

> For what it's worth, my understanding was that the original reason (which
> has fallen by the wayside) was that the Core proper didn't include anything
> that couldn't at least in concept be implemented on all three platforms.
>
> Moreover, the extensions were thought to provide relatively simple worked
> examples of how to package an extension on Windows.
>
> Sentiment used to favour unbundling: keeping features out of the Core but
> having the ones that were expected to be universal published as bundled
> extensions. That's one reason why I never proposed tdbc as bundled; a more
> important one was that I wasn't sure that the API was quite right and
> didn't want to freeze it for years or decades, as would happen if it came
> under TIP control and required a major Tcl release to introduce any
> incompatibilities.
>
> New leadership will of course have new directions, and if the pendulum is
> swinging back toward greater inclusion. I don't object.
>

I hope I will not the only one to be objecting, but here are my reasons:
1) dde and registry are 'dangerous' extensions. Dde has the same
functionality as the "send" command,
    which was disabled due to security concerns. Registry makes it possible
to read and write
    registry settings, which could also make the computer screw up
completely. Separating
    them would make it possible to remove them, if some application doesn't
need it.
2) dde and registry don't have the best API we can think of. dde would best
be integrated in
   a new "send" command. The registry commands should feel more oo-like.
3) Every command should either be included, then no "package require"
should be needed.
   Or it should be a module, activated by "package require". With TIP #702,
"dde" and "registry"
   will be the only modules which are compiled into the Tcl library. Do we
think it's a
   good example to other modules to do that? I don't think so. Either
provide the "dde" and
   "registry" commands as being available always (which I wouldn't do due
to 1) and 2),
  or make them a separate module loadable at wish (which they are now)

That said, I recognise the problem addressed in the TIP. Actually, there
are 4 problems now.
1) Extracting ddl's from the zip-file takes time and is not 100%
full-proof. That's something
which should be addressed (there already is a ticket for that)
2) Even if we can include dde.ddl and registry.ddl in the zip, the question
is if we really
want to do that. We could just install those in C:\Tcl\lib\registry1.3 resp
C:\Tcl\lib\dde1.4
(as is done now in Tcl 8.6), then all current problems are gone.
3) Currently, registry.dll is loaded at startup because the new "clock"
command needs it.
It would be better to have a native clock subcommand, which reads the
timezone
from the registry, in C, without the need to load registry.dll for doing
that.
4) I think Tk also loads "registry.dll" at startup. I'm sure there's a way
to prevent that too.

I'll create a new ticket, proposing to install registry and dde in
C:\Tcl\lib, instead of packing
it into the zip-file. I think that's a better way going forward than TIP
#702.

Sorry, Ashok,

Regards,
     Jan Nijtmans

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

On Oct 19 2024, 15:05 +0000, Kevin Walzer <kw...@co...> wrote:
>As a tangent, is there any interest in integrating Schelte Bron's dbus 
>and dbif libraries in the core as bundled packages? Schelte, what do 
>you think? Including these would give Tcl/Tk full platform-native IPC 
>support across all three platforms. I'd be glad to sponsor a TIP.

What would that mean, in practice? I can see different options:

1. dbus' repo moves within Tcl's fossil tree
2. dbus' packages are distributed with Tcl's (same as tdbc and Thread)
3. dbus is built as part of Tcl's build process

Speaking as a downstream packager, 1 and 2 have no impact on my work, 
and probably neither does it on final users.

As per 3, I see several issues.  I don't think dbus is special in any 
way, and - as much as I like it - I don't see it as being the future of 
IPC. Also, this would introduce a dependency on dbus to build Tcl, which 
I also don't favour. If this happened, in the FreeBSD ports, I'd 
probably disable it and provide it as a separate port anyway.

If we want to consider bundling 3rd party extensions, I think there are 
others that are more generally used than dbus and that would better fit 
a more "batteries" approach, e.g., tcllib, tDOM, tls, thread.

YMMV - which is why I'd rather keep the status quo.

Thanks,

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

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

On 19/10/2024 17:05, Kevin Walzer wrote:
> As a tangent, is there any interest in integrating Schelte Bron's dbus 
> and dbif libraries in the core as bundled packages? Schelte, what do you 
> think?

I have no objections.


Schelte.

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/AblX6MEdh0k3tBPVdNfSBsA72VOqL5JCPVZCsCRT38g1uY0Fe9J2ZuhbbCc2XCJMa8dXqZt_OXgsmVeYSncJorJCSx6FN15TphXSSvM3k1TpmxWqTAkT3OCuwONRnJISVY_aT1T17hck9EcvXRHHtS7BRJlQF-n_iRHbkAW4S0cL_c7N_-IR8TM8pPKSaevfHz8HryKZH97Oiu9bSrmjJr02tt-hPAz6' /><div dir="ltr"></div><div dir="ltr">For new API’s I agree. For established ones, layering an abstraction over them makes less sense.&nbsp;</div><div dir="ltr"><br><blockquote type="cite">On Oct 19, 2024, at 9:26 PM, Marc Culler &lt;cul...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>When faced with three different platform specific solutions to the same problem, I think one reasonable approach is to start by designing one abstraction that represents the important aspects of all three solutions and then to use the platform specific solutions to realize the abstraction.&nbsp; An example of this sort of thing, found in a number of languages, is having one database abstraction that serves as a "frontend" which can be used with many different database "backends".</div><div><br></div><div>The obvious advantage of doing this is that it enables writing platform independent code.</div><div><br></div><div>- Marc<br> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 19, 2024 at 10:06 AM Kevin Walzer &lt;<a href="mailto:kw...@co...">kw...@co...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div><img width="1" height="1" src="https://fedbdhd.r.bh.d.sendibt3.com/tr/op/xs-5-haiKBpl-s_C-aYodh_GwLpJ-OQRNSllSt5FyM8_QbMCTkY-VZHQmFv0z7BAAwCxCIIerMAbpWEUBO08joMjSiWW5FfjUjDOnmPBc_PZ4D5L_gSoquy31KsdRZ8GDF6s-lAq00e_8CIZxGzl6ArEmgScRHxjos6fhiF-5Eyj1rTat2fMEbrWxWR0SwXWjb1CfkWozjN4dsnQDOxU-ZUhdsh5pZtF" data-unique-identifier="">
    <p>Excellent idea. I've always considered these to be core commands
      anyway and I'm not quite clear why they are excluded, except for
      being platform-specific. We have AppleEvent support (Mac IPC
      mechanism that is similar to DDE) in the core. <br>
    </p>
    <p>As a tangent, is there any interest in integrating Schelte Bron's
      dbus and dbif libraries in the core as bundled packages? Schelte,
      what do you think? Including these would give Tcl/Tk full
      platform-native IPC support across all three platforms. I'd be
      glad to sponsor a TIP. <br>
    </p>
    <p>--Kevin <br>
    </p>
    <div>On 10/18/24 10:43 PM, apnmbx-public---
      via Tcl-Core wrote:<br>
    </div>
    <blockquote type="cite">
      
      
      
      <div>
        <p class="MsoNormal">TIP 702 - Statically link registry and dde
          extensions on Windows<u></u><u></u></p>
        <p class="MsoNormal"><u></u>&nbsp;<u></u></p>
        <p class="MsoNormal"><a href="https://fedbdhd.r.bh.d.sendibt3.com/tr/cl/dpvfbxiDwteuRkOCwwBEoFiYZiTMi3anLCHhAlKw_oOnNzECZgWFcEG0FrNw88GwseyEFjVyXcoDBCdUXmRGuo1EOi8cujkyV6rY4BJQLXZVJPdCCNDeGKROinEYKM3FG4E8rWa12ALRYlvKag6Akw_6tn4mv5Aw35_zPO8UjFJut3tNGBf-qxbg4pGqa6Kxgv0xykqBpcIzw5YiKS7iwNQJ5qOuFgUvYyVJnmLf7my21keR15Vd2fDjGki1CpStBIWrzXcFHlH5KZcxMCAg1yk6X-NyyT-7Zh6IuO4RSkyMApVq5_wev7z_iBbWevaNdM0m" target="_blank">https://core.tcl-lang.org/tips/doc/trunk/tip/702.md</a>
          <u></u><u></u></p>
        <p class="MsoNormal"><u></u>&nbsp;<u></u></p>
        <p class="MsoNormal">is up for review/comments.<u></u><u></u></p>
        <p class="MsoNormal"><u></u>&nbsp;<u></u></p>
        <p class="MsoNormal">I plan a CFV in two weeks.<u></u><u></u></p>
        <p class="MsoNormal"><u></u>&nbsp;<u></u></p>
        <p class="MsoNormal">/Ashok<u></u><u></u></p>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
Tcl-Core mailing list
<a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a>
<a href="https://fedbdhd.r.bh.d.sendibt3.com/tr/cl/MlB1gVVE1XsVmWESK_OwKVWaSF7WumaXA08YDpJRng5zcII-ljgKXzvnVaOui4SELj7pWA1qrzli4iEb1NkLfOUZCCSRvmWhEmmAjbBIWX5tRpWGOpfs0pATyS0qjEQdY_mBl-i7bGBfKM0DnklwLysxHXDFDbHwPsOBd5OcggkfpN8Z6kZKPjLaOEj8aZKdQZvt41_I8eiP1LgEgCQztBjzK_0JXKcDqjxiVL13K0X3Ac-vd8Q4SSl-txEQ6Pi2T5TsDdk4rwSKFWdo7QunREVWJVPZDrgd4TjSCupRvHEROg8uLoHkRAZGU6fZNzpiXw" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a>
</pre>
    </blockquote>
  </div>


_______________________________________________<br>
Tcl-Core mailing list<br>
<a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a><br>
<a href="https://fedbdhd.r.bh.d.sendibt3.com/tr/cl/NEyju_rOQTCEDlDotW1y6qkdH1b35Qycz1xz_6f13L2o3_memHYSWWzzuBTbfdHvFgnvXENl2s3OMHV7JZlYtw0bUi0lUKYCuPJ2KuneP2RnZnsD3amWdhqbKGTnaRRpJVYVZFr_8JrnZkp9lZ2v499v9MYY6kKHr3h__RW35h5y4NWR3moPf6E_MYDS7J4czQDlMYTq9clQxWgZGv8BliINm7prxe8zFrzXlA6LuWL9hsASlnAzQcLhYz2OF4zRrbQZq1wMkW4JFhLL7_I4y26TozAAIz-lsGQ1YMHHdYD8pcjD_B6JqKB53Ieiz73nfA" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><br>
</blockquote></div>
</div></blockquote></body></html>

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

On Sat, Oct 19, 2024 at 9:27 PM Marc Culler <cul...@gm...> wrote:

> When faced with three different platform specific solutions to the same
> problem, I think one reasonable approach is to start by designing one
> abstraction that represents the important aspects of all three solutions
> and then to use the platform specific solutions to realize the
> abstraction.  An example of this sort of thing, found in a number of
> languages, is having one database abstraction that serves as a "frontend"
> which can be used with many different database "backends".
>

Tcl is among those languages.  TDBC provides native-API interfaces to
MySQL/MariaDB, PostgreSQL, and SQLite3, and the TDBC-to-ODBC bridge covers
numerous other databases, including SQL Server and Jet/MS Access.  All of
these share a common front end.

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

I actually share Kevin’s sentiments about minimizing core bloat. However, registry and dde are for all practical purposes already in the core (they are part of the static shell unlike tdbc, thread etc.). One could move them out completely a la TDBC but that would be considerably more disruptive to users imo.

 

With regards to serving as sample extensions, I think there are many examples out there now so that is no longer a factor.

 

/Ashok

 

From: Kevin Kenny <kev...@gm...> 
Sent: Sunday, October 20, 2024 6:17 AM
To: Kevin Walzer <kw...@co...>
Cc: tcl...@li...
Subject: Re: [TCLCORE] TIP 702 - static linking for registry and dde

 

On Sat, Oct 19, 2024 at 11:06 AM Kevin Walzer <kw...@co... <mailto:kw...@co...> > wrote:



Excellent idea. I've always considered these to be core commands anyway and I'm not quite clear why they are excluded, except for being platform-specific. We have AppleEvent support (Mac IPC mechanism that is similar to DDE) in the core. 

As a tangent, is there any interest in integrating Schelte Bron's dbus and dbif libraries in the core as bundled packages? Schelte, what do you think? Including these would give Tcl/Tk full platform-native IPC support across all three platforms. I'd be glad to sponsor a TIP. 

--Kevin

 

For what it's worth, my understanding was that the original reason (which has fallen by the wayside) was that the Core proper didn't include anything that couldn't at least in concept be implemented on all three platforms.

 

Moreover, the extensions were thought to provide relatively simple worked examples of how to package an extension on Windows.

 

Sentiment used to favour unbundling: keeping features out of the Core but having the ones that were expected to be universal published as bundled extensions. That's one reason why I never proposed tdbc as bundled; a more important one was that I wasn't sure that the API was quite right and didn't want to freeze it for years or decades, as would happen if it came under TIP control and required a major Tcl release to introduce any incompatibilities. 

 

New leadership will of course have new directions, and if the pendulum is swinging back toward greater inclusion. I don't object.

 

-- 

73 de ke9tv/2, Kevin

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

When faced with three different platform specific solutions to the same
problem, I think one reasonable approach is to start by designing one
abstraction that represents the important aspects of all three solutions
and then to use the platform specific solutions to realize the
abstraction.  An example of this sort of thing, found in a number of
languages, is having one database abstraction that serves as a "frontend"
which can be used with many different database "backends".

The obvious advantage of doing this is that it enables writing platform
independent code.

- Marc

On Sat, Oct 19, 2024 at 10:06 AM Kevin Walzer <kw...@co...> wrote:

> Excellent idea. I've always considered these to be core commands anyway
> and I'm not quite clear why they are excluded, except for being
> platform-specific. We have AppleEvent support (Mac IPC mechanism that is
> similar to DDE) in the core.
>
> As a tangent, is there any interest in integrating Schelte Bron's dbus and
> dbif libraries in the core as bundled packages? Schelte, what do you think?
> Including these would give Tcl/Tk full platform-native IPC support across
> all three platforms. I'd be glad to sponsor a TIP.
>
> --Kevin
> On 10/18/24 10:43 PM, apnmbx-public--- via Tcl-Core wrote:
>
> TIP 702 - Statically link registry and dde extensions on Windows
>
>
>
> https://core.tcl-lang.org/tips/doc/trunk/tip/702.md
> <https://fedbdhd.r.bh.d.sendibt3.com/tr/cl/dpvfbxiDwteuRkOCwwBEoFiYZiTMi3anLCHhAlKw_oOnNzECZgWFcEG0FrNw88GwseyEFjVyXcoDBCdUXmRGuo1EOi8cujkyV6rY4BJQLXZVJPdCCNDeGKROinEYKM3FG4E8rWa12ALRYlvKag6Akw_6tn4mv5Aw35_zPO8UjFJut3tNGBf-qxbg4pGqa6Kxgv0xykqBpcIzw5YiKS7iwNQJ5qOuFgUvYyVJnmLf7my21keR15Vd2fDjGki1CpStBIWrzXcFHlH5KZcxMCAg1yk6X-NyyT-7Zh6IuO4RSkyMApVq5_wev7z_iBbWevaNdM0m>
>
>
>
> is up for review/comments.
>
>
>
> I plan a CFV in two weeks.
>
>
>
> /Ashok
>
>
> _______________________________________________
> Tcl-Core mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tcl-core <https://fedbdhd.r.bh.d.sendibt3.com/tr/cl/MlB1gVVE1XsVmWESK_OwKVWaSF7WumaXA08YDpJRng5zcII-ljgKXzvnVaOui4SELj7pWA1qrzli4iEb1NkLfOUZCCSRvmWhEmmAjbBIWX5tRpWGOpfs0pATyS0qjEQdY_mBl-i7bGBfKM0DnklwLysxHXDFDbHwPsOBd5OcggkfpN8Z6kZKPjLaOEj8aZKdQZvt41_I8eiP1LgEgCQztBjzK_0JXKcDqjxiVL13K0X3Ac-vd8Q4SSl-txEQ6Pi2T5TsDdk4rwSKFWdo7QunREVWJVPZDrgd4TjSCupRvHEROg8uLoHkRAZGU6fZNzpiXw>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

On Sat, Oct 19, 2024 at 11:06 AM Kevin Walzer <kw...@co...> wrote:

> Excellent idea. I've always considered these to be core commands anyway
> and I'm not quite clear why they are excluded, except for being
> platform-specific. We have AppleEvent support (Mac IPC mechanism that is
> similar to DDE) in the core.
>
> As a tangent, is there any interest in integrating Schelte Bron's dbus and
> dbif libraries in the core as bundled packages? Schelte, what do you think?
> Including these would give Tcl/Tk full platform-native IPC support across
> all three platforms. I'd be glad to sponsor a TIP.
>
> --Kevin
>

For what it's worth, my understanding was that the original reason (which
has fallen by the wayside) was that the Core proper didn't include anything
that couldn't at least in concept be implemented on all three platforms.

Moreover, the extensions were thought to provide relatively simple worked
examples of how to package an extension on Windows.

Sentiment used to favour unbundling: keeping features out of the Core but
having the ones that were expected to be universal published as bundled
extensions. That's one reason why I never proposed tdbc as bundled; a more
important one was that I wasn't sure that the API was quite right and
didn't want to freeze it for years or decades, as would happen if it came
under TIP control and required a major Tcl release to introduce any
incompatibilities.

New leadership will of course have new directions, and if the pendulum is
swinging back toward greater inclusion. I don't object.

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] TIP 702 - static linking for registry and dde

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

Excellent idea. I've always considered these to be core commands anyway 
and I'm not quite clear why they are excluded, except for being 
platform-specific. We have AppleEvent support (Mac IPC mechanism that is 
similar to DDE) in the core.

As a tangent, is there any interest in integrating Schelte Bron's dbus 
and dbif libraries in the core as bundled packages? Schelte, what do you 
think? Including these would give Tcl/Tk full platform-native IPC 
support across all three platforms. I'd be glad to sponsor a TIP.

--Kevin

On 10/18/24 10:43 PM, apnmbx-public--- via Tcl-Core wrote:
>
> TIP 702 - Statically link registry and dde extensions on Windows
>
> https://core.tcl-lang.org/tips/doc/trunk/tip/702.md
>
> is up for review/comments.
>
> I plan a CFV in two weeks.
>
> /Ashok
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] New unsupported ICU commands

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

I would like to add the following commands to the existing
tcl::unsupported::icu namespace for 9.0.1/9.1.

 

icu convertto ?-profile PROFILE? ICUENC STRING

icu convertfrom ?-profile PROFILE? ICUENC BYTES

 

These parallel Tcl's "encoding convertto,convertfrom". Their purpose is
further testing of Tcl encodings by comparing with ICU.

 

icu normalize ?-profile PROFILE? ?-mode NFC|NFD|NFKC|NFKD? STRING

 

This allows for experimenting with Unicode normalization forms as a basis
for introducing the functionality into some future Tcl release.

 

Since these are in unsupported namespace, no TIP is planned.

 

If there are no objections or concerns, I'll merge them in a couple of days.

 

/Ashok

[TCLCORE] TIP 702 - static linking for registry and dde

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

TIP 702 - Statically link registry and dde extensions on Windows

 

https://core.tcl-lang.org/tips/doc/trunk/tip/702.md 

 

is up for review/comments.

 

I plan a CFV in two weeks.

 

/Ashok

Re: [TCLCORE] Thanks for TCL/Tk 9.0.0 and next steps

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

On Thu, Oct 17, 2024 at 10:36 AM Marc Culler <cul...@gm...> wrote:

> I have no idea what the item "factor out the image command from Tk" is
> about, nor why one would want to do that. What is the issue? It seems like
> something that should be discussed here before it is discussed on zoom,
> which reaches many fewer people.
>
>
I have had a number of apps over the years that want to do 'headless' image
processing.  Either they are sending images to a destination other than a
graphical user interface (for example, printing), or they are accepting
images from an external source (such as a camera, X-ray, ultrasound, radar,
...) and performing analytics upon them.  But at the root, there's still an
'image' object - an array of pixels.  Much of what's in the [image] command
is dealing with file formats, memory management, and the like,
without reference to a GUI.  I think that refactoring that portion out and
making it available to non-GUI applications could be a significant step
forward.

Whether now is the time to discuss it (relative to the release schedule) is
a question that I'll leave to others.
-- 
73 de ke9tv/2, Kevin