tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Tcl_Obj types and tkinter

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

Marc,
thank you for this opinion. I think, if people have seen the new 
scalable look and feel, they will not think for a long time.

Take care,
Harald

Am 09.07.2024 um 22:09 schrieb Marc Culler:
> I don't think it is a blocker for releasing Tcl 9.  Python is pretty 
> conservative about the external packages that they embed.  Even if Tcl 9 
> had already been released I would expect Python to continue using 8.6 
> for quite a while.  But if you want more people to be using Tk 9 then 
> convincing Python to switch to it would be a big boost.
> 
> - Marc

Re: [TCLCORE] Tcl_Obj types and tkinter

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

I don't think it is a blocker for releasing Tcl 9.  Python is pretty
conservative about the external packages that they embed.  Even if Tcl 9
had already been released I would expect Python to continue using 8.6 for
quite a while.  But if you want more people to be using Tk 9 then
convincing Python to switch to it would be a big boost.

- Marc


On Tue, Jul 9, 2024 at 2:57 PM Harald Oehlmann <har...@el...>
wrote:

> Marc,
> I am sorry for the inconveniences. So, TkInter is not a blocker any more
> to release TCL/Tk 9.0.
> We would love to correct all the issues.
> Unfortunately, 7 years passed in TCL/Tk 9 development and it is time for
> a release.
> Thank you for this great news and your understanding,
> Harald
>
> Am 09.07.2024 um 21:11 schrieb Marc Culler:
> > I am still working on making the Python tkinter module work with Tk
> > 9.0.  I am now down to 38 failures in the tkinter unit tests.  The
> > Tcl_GetNumberFromObject function worked well for the job of converting
> > Tcl objects to Python objects.
> >
> > Inconsistent behavior with respect to how options are handled is the
> > main source of problems now.  The behavior is different in 8.6 and 9.0
> > and it is also different for different widgets and for different options
> > of the same widget in Tk 9.0.  For example, a button allows setting the
> > borderwidth to a negative value, but silently records the value as 0.
> > It also allows the width and height to be set to negative values but
> > does not change them to 0.  Other widgets allow any screen distance
> > option to be set to a negative value even though it is invalid.  The
> > unit tests try to test each option for each widget using both valid and
> > invalid values, so they need to know each widget's policy for each
> > option for each version of Tk.
> >
> > - Marc
> >
> > On Tue, Jul 9, 2024 at 7:30 AM Steve Landers <st...@di...
> > <mailto:st...@di...>> wrote:
> >
> >     HI Marc,
> >
> >     Can you confirm if your concerns about Tcl/Tk 9.0 and tkinter have
> >     been addressed?
> >
> >     -- Steve
> >     On 3 Jul 2024 at 9:48 AM +0800, Marc Culler <cul...@gm...
> >     <mailto:cul...@gm...>>, wrote:
> >>     Hi Jan,
> >>
> >>     The Python _tkinter extension module definitely needs to be able
> >>     to convert any Tcl_Obj to some sort of Python object.  The reason
> >>     is that tkinter allows running any Tcl command in an embedded Tcl
> >>     interpreter.  The Python class tkinter.Tk encapsulates a Tcl
> >>     interpreter which has loaded the Tk package.  The interpreter has
> >>     a call method which can be passed a sequence of strings to be run
> >>     as a Tcl command.
> >>
> >>     Here is an example of how you can generate a Tcl bignum using
> >>     Python's  tkinter package, which then converts it to a Python
> integer:
> >>
> >>     $ python3
> >>     Python 3.11.8 (v3.11.8:db85d51d3e, Feb  6 2024, 18:02:37) [Clang
> >>     13.0.0 (clang-1300.0.29.30)] on darwin
> >>     Type "help", "copyright", "credits" or "license" for more
> information.
> >>     >>> import tkinter
> >>     >>> interp = tkinter.Tk()
> >>     >>> x = interp.call('expr', '11111111111111111111', '*',
> >>     '22222222222222222222')
> >>     >>> print(x)
> >>     246913580246913580241975308641975308642
> >>     >>> type(x)
> >>     <class 'int'>
> >>
> >>     - Marc
> >>
> >>     On Tue, Jul 2, 2024 at 7:26 PM Marc Culler <cul...@gm...
> >>     <mailto:cul...@gm...>> wrote:
> >>
> >>         On Tue, Jul 2, 2024 at 3:13 AM Jan Nijtmans
> >>         <jan...@gm... <mailto:jan...@gm...>> wrote:
> >>
> >>             Let me explain the reason for the removal of "boolean" and
> >>             "int".
> >>
> >>
> >>         Thank you!
> >>
> >>             This means that code which uses the "int" or "boolean"
> >>             types need to be inspected: code which worked for 8.x
> >>             won't necessarily behave the same in 9.0.
> >>
> >>
> >>         That is understandable, although I don't see what it has to do
> >>         with whether registration was a good idea or not.
> >>
> >>         As far as _tkinter is concerned (based on what I can see  from
> >>         reading the code - I had no hand in writing it) here is the
> >>         issue.  The _tkinter module allows running Tk commands in an
> >>         embedded interpreter.  The result is a pointer to a Tcl_Obj of
> >>         some type.  Several of the possible types can be converted
> >>         into comparable Python objects: this is true for int, string,
> >>         list, dict, bignum, and boolean at least.  For each such type
> >>         there is a function in _tkinter.c which converts that Tcl_Obj
> >>         type to the corresponding Python type.  (You are saying that
> >>         those functions will need to be rewritten.  That is extremely
> >>         useful to know, but unrelated to how the registration is used
> >>         in _tkinter.c.)  There are also types which do not convert
> >>         naturally.  There is a function in _tkinter.c to convert such
> >>         a Tcl_Obj to a Python object which basically just records the
> >>         type name and is of no particular use in Python, although it
> >>         can be converted to a string.  In addition to these utility
> >>         functions there is a function FromObj which converts the
> >>         result of any Tcl command to a Python object by calling the
> >>         appropriate converter.  The FromObj just needs to know what
> >>         the type of the TclObj is so it can call the right converter.
> >>         The converter is responsible for knowing enough about the
> >>         internal structure of the Tcl_Obj to construct  its python
> object.
> >>
> >>         Here is how the current _tkinter code makes that decision.  It
> >>         caches a pointer to each of the Tcl_ObjType structs used by a
> >>         type for which it has a converter.  When it receives a Tcl_Obj
> >>         it checks the typePtr to the cached values and if it gets a
> >>         match it calls the corresponding converter.  You have pointed
> >>         out that a Tcl_Obj of a given type (as determined by its type
> >>         name) might have a NULL typePtr, meaning it is uninitialized.
> >>         But Python has no concept of an uninitialized objects.  So if
> >>         _tkinter receives a Tcl_Obj with a NULL typePtr it has to
> >>         treat it as an unknown type, even though it has a well-defined
> >>         type name.  It cannot be converted to anything.
> >>
> >>         The way that the authors of _tkinter were using Tcl_GetObjType
> >>         was simply to initialize the list of cached pointers to
> >>         Tcl_ObjType structs.  The code had already been patched to
> >>         deal with unregistered types by parsing the type name and
> >>         updating the cache the first time that it sees a Tcl_Obj of a
> >>         recognized name with a non-NULL typePtr.  Of course they could
> >>         have chosen to parse the type name for every Tcl_Obj
> >>         received.  But I am pretty sure they thought (correctly) that
> >>         doing that was going to be unnecessarily slow.
> >>
> >>         Here is a fourth workaround option which could be added to my
> >>         list.  How about if each Tcl_Obj had a 32-bit (or even 8-bit)
> >>         integer field which is an identifier for the the type of the
> >>         Tcl_Obj.  There would be a unique value for each type defined
> >>         by the core and one other value meaning that the type is
> >>         registered by an extension.  Then it would be possible to very
> >>         quickly decide what the type of a Tcl_Obj is.  Those
> >>         identifiers could be conveniently used in a switch statement.
> >>         One could check whether an object has been initialized by
> >>         checking if its typePtr is NULL.  It would be quick to
> >>         determine when a call to Tcl_GetObjType is needed.
> >>
> >>             Let's see. I doubt the usefulness of "boolean", "bignum",
> >>             "exprcode" and "ensembleCommand" for tkInter. Tk never
> >>             returns a Tcl_Obj of the "boolean" and the "bignum" type, it
> >>             uses the "int" type for that (since pixels never exceed the
> >>             wideint range). "exprcode" and "ensembleCommand"
> >>             were not exported in Tcl 8.6, why do you want them now?
> >>
> >>
> >>         I don't want types that could never appear.  It is just that I
> >>         saw no reason why some core types should be registered and
> >>         others not.  The tkinter module is not the only consumer.  It
> >>         is simpler, conceptually and programmatically, to simply
> >>         register all of the core types.  Also, I am pretty surprised
> >>         to hear that boolean and bignum types could never appear as
> >>         the result of a Tcl command processed by tkinter, given that
> >>         _tkinter.c includes code for converting those types to Python
> >>         types.  Are you sure about that?
> >>
> >>         - Marc
> >>
> >>
> >>             The "bignum" implementation changed between 8.6
> >>             and 8.7/9.0 too: the libtommath library in 8.6 was
> >>             always compiled for 32-bit. In 8.7 it's compiled for
> >>             64-bit on 64-bit platforms. So, accessing the internal
> >>             fields won't be the same as in Tcl 8.6!
> >>
> >>             That leaves "int" and "index". I can imagine those are
> >>             useful for optimization purposes in tkInter. If
> >>             Tcl_GetNumberFromObj (which doesn't handle "index")
> >>             is not a useful function for what tkInter needs it for,
> >>             I'm OK with adding those two back in Tcl 9.0.
> >>
> >>             So:
> >>             1) Marc, can you live with the compromise of adding
> >>             "int" and "index" only? IMHO "boolean" and
> >>             "bignum" are not useful for special-casing in tkInter.
> >>             For "exprcode" and "ensembleCommand" I don't
> >>             see a use-case at all.
> >>             2) What would be needed for Tcl_GetNumberFromObj()
> >>             to make it a useful alternative for use in tkInter? Would
> >>             adding "index" and "boolean" (two additional enum
> >>             values) help there?
> >>
> >>             I won't create a quick TIP for adding "index" and
> >>             "boolean" to Tcl_GetNumberFromObj(). Maybe for 9.1.
> >>
> >>             Hope this helps,
> >>                    Jan Nijtmans
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Tcl_Obj types and tkinter

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

Op di 9 jul 2024 om 21:12 schreef Marc Culler:
>
> I am still working on making the Python tkinter module work with Tk 9.0.  I am now down to 38 failures in the tkinter unit tests.  The Tcl_GetNumberFromObject function worked well for the job of converting Tcl objects to Python objects.
>
> Inconsistent behavior with respect to how options are handled is the main source of problems now.  The behavior is different in 8.6 and 9.0 and it is also different for different widgets and for different options of the same widget in Tk 9.0.  For example, a button allows setting the borderwidth to a negative value, but silently records the value as 0.  It also allows the width and height to be set to negative values but does not change them to 0.  Other widgets allow any screen distance option to be set to a negative value even though it is invalid.  The unit tests try to test each option for each widget using both valid and invalid values, so they need to know each widget's policy for each option for each version of Tk.

I am well aware of this inconsistency. It's the reason
for writing this TIP:
    <https://core.tcl-lang.org/tips/doc/trunk/tip/698.md>

Any widget which disallows negative pixel values will then
simply throw an error, just as other invalid option values do,
without magically change them to 0 or simply threat them
as being 0.

Hope this helps,
     Jan Nijtmans

Re: [TCLCORE] Tcl_Obj types and tkinter

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

Marc,
I am sorry for the inconveniences. So, TkInter is not a blocker any more 
to release TCL/Tk 9.0.
We would love to correct all the issues.
Unfortunately, 7 years passed in TCL/Tk 9 development and it is time for 
a release.
Thank you for this great news and your understanding,
Harald

Am 09.07.2024 um 21:11 schrieb Marc Culler:
> I am still working on making the Python tkinter module work with Tk 
> 9.0.  I am now down to 38 failures in the tkinter unit tests.  The 
> Tcl_GetNumberFromObject function worked well for the job of converting 
> Tcl objects to Python objects.
> 
> Inconsistent behavior with respect to how options are handled is the 
> main source of problems now.  The behavior is different in 8.6 and 9.0 
> and it is also different for different widgets and for different options 
> of the same widget in Tk 9.0.  For example, a button allows setting the 
> borderwidth to a negative value, but silently records the value as 0.  
> It also allows the width and height to be set to negative values but 
> does not change them to 0.  Other widgets allow any screen distance 
> option to be set to a negative value even though it is invalid.  The 
> unit tests try to test each option for each widget using both valid and 
> invalid values, so they need to know each widget's policy for each 
> option for each version of Tk.
> 
> - Marc
> 
> On Tue, Jul 9, 2024 at 7:30 AM Steve Landers <st...@di... 
> <mailto:st...@di...>> wrote:
> 
>     HI Marc,
> 
>     Can you confirm if your concerns about Tcl/Tk 9.0 and tkinter have
>     been addressed?
> 
>     -- Steve
>     On 3 Jul 2024 at 9:48 AM +0800, Marc Culler <cul...@gm...
>     <mailto:cul...@gm...>>, wrote:
>>     Hi Jan,
>>
>>     The Python _tkinter extension module definitely needs to be able
>>     to convert any Tcl_Obj to some sort of Python object.  The reason
>>     is that tkinter allows running any Tcl command in an embedded Tcl
>>     interpreter.  The Python class tkinter.Tk encapsulates a Tcl
>>     interpreter which has loaded the Tk package.  The interpreter has
>>     a call method which can be passed a sequence of strings to be run
>>     as a Tcl command.
>>
>>     Here is an example of how you can generate a Tcl bignum using
>>     Python's  tkinter package, which then converts it to a Python integer:
>>
>>     $ python3
>>     Python 3.11.8 (v3.11.8:db85d51d3e, Feb  6 2024, 18:02:37) [Clang
>>     13.0.0 (clang-1300.0.29.30)] on darwin
>>     Type "help", "copyright", "credits" or "license" for more information.
>>     >>> import tkinter
>>     >>> interp = tkinter.Tk()
>>     >>> x = interp.call('expr', '11111111111111111111', '*',
>>     '22222222222222222222')
>>     >>> print(x)
>>     246913580246913580241975308641975308642
>>     >>> type(x)
>>     <class 'int'>
>>
>>     - Marc
>>
>>     On Tue, Jul 2, 2024 at 7:26 PM Marc Culler <cul...@gm...
>>     <mailto:cul...@gm...>> wrote:
>>
>>         On Tue, Jul 2, 2024 at 3:13 AM Jan Nijtmans
>>         <jan...@gm... <mailto:jan...@gm...>> wrote:
>>
>>             Let me explain the reason for the removal of "boolean" and
>>             "int".
>>
>>
>>         Thank you!
>>
>>             This means that code which uses the "int" or "boolean"
>>             types need to be inspected: code which worked for 8.x
>>             won't necessarily behave the same in 9.0.
>>
>>
>>         That is understandable, although I don't see what it has to do
>>         with whether registration was a good idea or not.
>>
>>         As far as _tkinter is concerned (based on what I can see  from
>>         reading the code - I had no hand in writing it) here is the
>>         issue.  The _tkinter module allows running Tk commands in an
>>         embedded interpreter.  The result is a pointer to a Tcl_Obj of
>>         some type.  Several of the possible types can be converted
>>         into comparable Python objects: this is true for int, string,
>>         list, dict, bignum, and boolean at least.  For each such type
>>         there is a function in _tkinter.c which converts that Tcl_Obj
>>         type to the corresponding Python type.  (You are saying that
>>         those functions will need to be rewritten.  That is extremely
>>         useful to know, but unrelated to how the registration is used
>>         in _tkinter.c.)  There are also types which do not convert
>>         naturally.  There is a function in _tkinter.c to convert such
>>         a Tcl_Obj to a Python object which basically just records the
>>         type name and is of no particular use in Python, although it
>>         can be converted to a string.  In addition to these utility
>>         functions there is a function FromObj which converts the
>>         result of any Tcl command to a Python object by calling the
>>         appropriate converter.  The FromObj just needs to know what
>>         the type of the TclObj is so it can call the right converter. 
>>         The converter is responsible for knowing enough about the
>>         internal structure of the Tcl_Obj to construct  its python object.
>>
>>         Here is how the current _tkinter code makes that decision.  It
>>         caches a pointer to each of the Tcl_ObjType structs used by a
>>         type for which it has a converter.  When it receives a Tcl_Obj
>>         it checks the typePtr to the cached values and if it gets a
>>         match it calls the corresponding converter.  You have pointed
>>         out that a Tcl_Obj of a given type (as determined by its type
>>         name) might have a NULL typePtr, meaning it is uninitialized. 
>>         But Python has no concept of an uninitialized objects.  So if
>>         _tkinter receives a Tcl_Obj with a NULL typePtr it has to
>>         treat it as an unknown type, even though it has a well-defined
>>         type name.  It cannot be converted to anything.
>>
>>         The way that the authors of _tkinter were using Tcl_GetObjType
>>         was simply to initialize the list of cached pointers to
>>         Tcl_ObjType structs.  The code had already been patched to
>>         deal with unregistered types by parsing the type name and
>>         updating the cache the first time that it sees a Tcl_Obj of a
>>         recognized name with a non-NULL typePtr.  Of course they could
>>         have chosen to parse the type name for every Tcl_Obj
>>         received.  But I am pretty sure they thought (correctly) that
>>         doing that was going to be unnecessarily slow.
>>
>>         Here is a fourth workaround option which could be added to my
>>         list.  How about if each Tcl_Obj had a 32-bit (or even 8-bit)
>>         integer field which is an identifier for the the type of the
>>         Tcl_Obj.  There would be a unique value for each type defined
>>         by the core and one other value meaning that the type is
>>         registered by an extension.  Then it would be possible to very
>>         quickly decide what the type of a Tcl_Obj is.  Those
>>         identifiers could be conveniently used in a switch statement. 
>>         One could check whether an object has been initialized by
>>         checking if its typePtr is NULL.  It would be quick to
>>         determine when a call to Tcl_GetObjType is needed.
>>
>>             Let's see. I doubt the usefulness of "boolean", "bignum",
>>             "exprcode" and "ensembleCommand" for tkInter. Tk never
>>             returns a Tcl_Obj of the "boolean" and the "bignum" type, it
>>             uses the "int" type for that (since pixels never exceed the
>>             wideint range). "exprcode" and "ensembleCommand"
>>             were not exported in Tcl 8.6, why do you want them now?
>>
>>
>>         I don't want types that could never appear.  It is just that I
>>         saw no reason why some core types should be registered and
>>         others not.  The tkinter module is not the only consumer.  It
>>         is simpler, conceptually and programmatically, to simply
>>         register all of the core types.  Also, I am pretty surprised
>>         to hear that boolean and bignum types could never appear as
>>         the result of a Tcl command processed by tkinter, given that
>>         _tkinter.c includes code for converting those types to Python
>>         types.  Are you sure about that?
>>
>>         - Marc
>>
>>
>>             The "bignum" implementation changed between 8.6
>>             and 8.7/9.0 too: the libtommath library in 8.6 was
>>             always compiled for 32-bit. In 8.7 it's compiled for
>>             64-bit on 64-bit platforms. So, accessing the internal
>>             fields won't be the same as in Tcl 8.6!
>>
>>             That leaves "int" and "index". I can imagine those are
>>             useful for optimization purposes in tkInter. If
>>             Tcl_GetNumberFromObj (which doesn't handle "index")
>>             is not a useful function for what tkInter needs it for,
>>             I'm OK with adding those two back in Tcl 9.0.
>>
>>             So:
>>             1) Marc, can you live with the compromise of adding
>>             "int" and "index" only? IMHO "boolean" and
>>             "bignum" are not useful for special-casing in tkInter.
>>             For "exprcode" and "ensembleCommand" I don't
>>             see a use-case at all.
>>             2) What would be needed for Tcl_GetNumberFromObj()
>>             to make it a useful alternative for use in tkInter? Would
>>             adding "index" and "boolean" (two additional enum
>>             values) help there?
>>
>>             I won't create a quick TIP for adding "index" and
>>             "boolean" to Tcl_GetNumberFromObj(). Maybe for 9.1.
>>
>>             Hope this helps,
>>                    Jan Nijtmans

Re: [TCLCORE] Tcl_Obj types and tkinter

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

I am still working on making the Python tkinter module work with Tk 9.0.  I
am now down to 38 failures in the tkinter unit tests.  The
Tcl_GetNumberFromObject function worked well for the job of converting Tcl
objects to Python objects.

Inconsistent behavior with respect to how options are handled is the main
source of problems now.  The behavior is different in 8.6 and 9.0 and it is
also different for different widgets and for different options of the same
widget in Tk 9.0.  For example, a button allows setting the borderwidth to
a negative value, but silently records the value as 0.  It also allows the
width and height to be set to negative values but does not change them to
0.  Other widgets allow any screen distance option to be set to a negative
value even though it is invalid.  The unit tests try to test each option
for each widget using both valid and invalid values, so they need to know
each widget's policy for each option for each version of Tk.

- Marc

On Tue, Jul 9, 2024 at 7:30 AM Steve Landers <st...@di...>
wrote:

> HI Marc,
>
> Can you confirm if your concerns about Tcl/Tk 9.0 and tkinter have been
> addressed?
>
> -- Steve
> On 3 Jul 2024 at 9:48 AM +0800, Marc Culler <cul...@gm...>, wrote:
>
> Hi Jan,
>
> The Python _tkinter extension module definitely needs to be able to
> convert any Tcl_Obj to some sort of Python object.  The reason is that
> tkinter allows running any Tcl command in an embedded Tcl interpreter.  The
> Python class tkinter.Tk encapsulates a Tcl interpreter which has loaded the
> Tk package.  The interpreter has a call method which can be passed a
> sequence of strings to be run as a Tcl command.
>
> Here is an example of how you can generate a Tcl bignum using Python's
> tkinter package, which then converts it to a Python integer:
>
> $ python3
> Python 3.11.8 (v3.11.8:db85d51d3e, Feb  6 2024, 18:02:37) [Clang 13.0.0
> (clang-1300.0.29.30)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import tkinter
> >>> interp = tkinter.Tk()
> >>> x = interp.call('expr', '11111111111111111111', '*',
> '22222222222222222222')
> >>> print(x)
> 246913580246913580241975308641975308642
> >>> type(x)
> <class 'int'>
>
> - Marc
>
> On Tue, Jul 2, 2024 at 7:26 PM Marc Culler <cul...@gm...> wrote:
>
>> On Tue, Jul 2, 2024 at 3:13 AM Jan Nijtmans <jan...@gm...>
>> wrote:
>>
>>> Let me explain the reason for the removal of "boolean" and "int".
>>
>>
>> Thank you!
>>
>>
>>> This means that code which uses the "int" or "boolean"
>>> types need to be inspected: code which worked for 8.x
>>> won't necessarily behave the same in 9.0.
>>>
>>
>> That is understandable, although I don't see what it has to do with
>> whether registration was a good idea or not.
>>
>> As far as _tkinter is concerned (based on what I can see  from reading
>> the code - I had no hand in writing it) here is the issue.  The _tkinter
>> module allows running Tk commands in an embedded interpreter.  The result
>> is a pointer to a Tcl_Obj of some type.  Several of the possible types can
>> be converted into comparable Python objects: this is true for int, string,
>> list, dict, bignum, and boolean at least.  For each such type there is a
>> function in _tkinter.c which converts that Tcl_Obj type to the
>> corresponding Python type.  (You are saying that those functions will need
>> to be rewritten.  That is extremely useful to know, but unrelated to how
>> the registration is used in _tkinter.c.)  There are also types which do not
>> convert naturally.  There is a function in _tkinter.c to convert such a
>> Tcl_Obj to a Python object which basically just records the type name and
>> is of no particular use in Python, although it can be converted to a
>> string.  In addition to these utility functions there is a function FromObj
>> which converts the result of any Tcl command to a Python object by calling
>> the appropriate converter.  The FromObj just needs to know what the type of
>> the TclObj is so it can call the right converter.  The converter is
>> responsible for knowing enough about the internal structure of the Tcl_Obj
>> to construct  its python object.
>>
>> Here is how the current _tkinter code makes that decision.  It caches a
>> pointer to each of the Tcl_ObjType structs used by a type for which it has
>> a converter.  When it receives a Tcl_Obj it checks the typePtr to the
>> cached values and if it gets a match it calls the corresponding converter.
>> You have pointed out that a Tcl_Obj of a given type (as determined by its
>> type name) might have a NULL typePtr, meaning it is uninitialized.  But
>> Python has no concept of an uninitialized objects.  So if _tkinter receives
>> a Tcl_Obj with a NULL typePtr it has to treat it as an unknown type, even
>> though it has a well-defined type name.  It cannot be converted to anything.
>>
>> The way that the authors of _tkinter were using Tcl_GetObjType was simply
>> to initialize the list of cached pointers to Tcl_ObjType structs.  The code
>> had already been patched to deal with unregistered types by parsing the
>> type name and updating the cache the first time that it sees a Tcl_Obj of a
>> recognized name with a non-NULL typePtr.  Of course they could have chosen
>> to parse the type name for every Tcl_Obj received.  But I am pretty sure
>> they thought (correctly) that doing that was going to be unnecessarily slow.
>>
>> Here is a fourth workaround option which could be added to my list.  How
>> about if each Tcl_Obj had a 32-bit (or even 8-bit) integer field which is
>> an identifier for the the type of the Tcl_Obj.  There would be a unique
>> value for each type defined by the core and one other value meaning that
>> the type is registered by an extension.  Then it would be possible to very
>> quickly decide what the type of a Tcl_Obj is.  Those identifiers could be
>> conveniently used in a switch statement.  One could check whether an object
>> has been initialized by checking if its typePtr is NULL.  It would be quick
>> to determine when a call to Tcl_GetObjType is needed.
>>
>>
>>> Let's see. I doubt the usefulness of "boolean", "bignum",
>>> "exprcode" and "ensembleCommand" for tkInter. Tk never
>>> returns a Tcl_Obj of the "boolean" and the "bignum" type, it
>>> uses the "int" type for that (since pixels never exceed the
>>> wideint range). "exprcode" and "ensembleCommand"
>>> were not exported in Tcl 8.6, why do you want them now?
>>>
>>
>> I don't want types that could never appear.  It is just that I saw no
>> reason why some core types should be registered and others not.  The
>> tkinter module is not the only consumer.  It is simpler, conceptually and
>> programmatically, to simply register all of the core types.  Also, I am
>> pretty surprised to hear that boolean and bignum types could never appear
>> as the result of a Tcl command processed by tkinter, given that _tkinter.c
>> includes code for converting those types to Python types.  Are you sure
>> about that?
>>
>> - Marc
>>
>>
>>>
>>> The "bignum" implementation changed between 8.6
>>> and 8.7/9.0 too: the libtommath library in 8.6 was
>>> always compiled for 32-bit. In 8.7 it's compiled for
>>> 64-bit on 64-bit platforms. So, accessing the internal
>>> fields won't be the same as in Tcl 8.6!
>>>
>>> That leaves "int" and "index". I can imagine those are
>>> useful for optimization purposes in tkInter. If
>>> Tcl_GetNumberFromObj (which doesn't handle "index")
>>> is not a useful function for what tkInter needs it for,
>>> I'm OK with adding those two back in Tcl 9.0.
>>>
>>> So:
>>> 1) Marc, can you live with the compromise of adding
>>> "int" and "index" only? IMHO "boolean" and
>>> "bignum" are not useful for special-casing in tkInter.
>>> For "exprcode" and "ensembleCommand" I don't
>>> see a use-case at all.
>>> 2) What would be needed for Tcl_GetNumberFromObj()
>>> to make it a useful alternative for use in tkInter? Would
>>> adding "index" and "boolean" (two additional enum
>>> values) help there?
>>>
>>> I won't create a quick TIP for adding "index" and
>>> "boolean" to Tcl_GetNumberFromObj(). Maybe for 9.1.
>>>
>>> Hope this helps,
>>>        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] Tcl_Obj types and tkinter

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

HI Marc,

Can you confirm if your concerns about Tcl/Tk 9.0 and tkinter have been addressed?

-- Steve
On 3 Jul 2024 at 9:48 AM +0800, Marc Culler <cul...@gm...>, wrote:
> Hi Jan,
>
> The Python _tkinter extension module definitely needs to be able to convert any Tcl_Obj to some sort of Python object.  The reason is that tkinter allows running any Tcl command in an embedded Tcl interpreter.  The Python class tkinter.Tk encapsulates a Tcl interpreter which has loaded the Tk package.  The interpreter has a call method which can be passed a sequence of strings to be run as a Tcl command.
>
> Here is an example of how you can generate a Tcl bignum using Python's  tkinter package, which then converts it to a Python integer:
>
> $ python3
> Python 3.11.8 (v3.11.8:db85d51d3e, Feb  6 2024, 18:02:37) [Clang 13.0.0 (clang-1300.0.29.30)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import tkinter
> >>> interp = tkinter.Tk()
> >>> x = interp.call('expr', '11111111111111111111', '*', '22222222222222222222')
> >>> print(x)
> 246913580246913580241975308641975308642
> >>> type(x)
> <class 'int'>
>
> - Marc
>
> > On Tue, Jul 2, 2024 at 7:26 PM Marc Culler <cul...@gm...> wrote:
> > > > On Tue, Jul 2, 2024 at 3:13 AM Jan Nijtmans <jan...@gm...> wrote:
> > > > > > Let me explain the reason for the removal of "boolean" and "int".
> > > > >
> > > > > Thank you!
> > > > >
> > > > > > This means that code which uses the "int" or "boolean"
> > > > > > types need to be inspected: code which worked for 8.x
> > > > > > won't necessarily behave the same in 9.0.
> > > > >
> > > > > That is understandable, although I don't see what it has to do with whether registration was a good idea or not.
> > > > >
> > > > > As far as _tkinter is concerned (based on what I can see  from reading the code - I had no hand in writing it) here is the issue.  The _tkinter module allows running Tk commands in an embedded interpreter.  The result is a pointer to a Tcl_Obj of some type.  Several of the possible types can be converted into comparable Python objects: this is true for int, string, list, dict, bignum, and boolean at least.  For each such type there is a function in _tkinter.c which converts that Tcl_Obj type to the corresponding Python type.  (You are saying that those functions will need to be rewritten.  That is extremely useful to know, but unrelated to how the registration is used in _tkinter.c.)  There are also types which do not convert naturally.  There is a function in _tkinter.c to convert such a Tcl_Obj to a Python object which basically just records the type name and is of no particular use in Python, although it can be converted to a string.  In addition to these utility functions there is a function FromObj which converts the result of any Tcl command to a Python object by calling the appropriate converter.  The FromObj just needs to know what the type of the TclObj is so it can call the right converter.  The converter is responsible for knowing enough about the internal structure of the Tcl_Obj to construct  its python object.
> > > > >
> > > > > Here is how the current _tkinter code makes that decision.  It caches a pointer to each of the Tcl_ObjType structs used by a type for which it has a converter.  When it receives a Tcl_Obj it checks the typePtr to the cached values and if it gets a match it calls the corresponding converter.  You have pointed out that a Tcl_Obj of a given type (as determined by its type name) might have a NULL typePtr, meaning it is uninitialized.  But Python has no concept of an uninitialized objects.  So if _tkinter receives a Tcl_Obj with a NULL typePtr it has to treat it as an unknown type, even though it has a well-defined type name.  It cannot be converted to anything.
> > > > >
> > > > > The way that the authors of _tkinter were using Tcl_GetObjType was simply to initialize the list of cached pointers to Tcl_ObjType structs.  The code had already been patched to deal with unregistered types by parsing the type name and updating the cache the first time that it sees a Tcl_Obj of a recognized name with a non-NULL typePtr.  Of course they could have chosen to parse the type name for every Tcl_Obj received.  But I am pretty sure they thought (correctly) that doing that was going to be unnecessarily slow.
> > > > >
> > > > > Here is a fourth workaround option which could be added to my list.  How about if each Tcl_Obj had a 32-bit (or even 8-bit) integer field which is an identifier for the the type of the Tcl_Obj.  There would be a unique value for each type defined by the core and one other value meaning that the type is registered by an extension.  Then it would be possible to very quickly decide what the type of a Tcl_Obj is.  Those identifiers could be conveniently used in a switch statement.  One could check whether an object has been initialized by checking if its typePtr is NULL.  It would be quick to determine when a call to Tcl_GetObjType is needed.
> > > > >
> > > > > > Let's see. I doubt the usefulness of "boolean", "bignum",
> > > > > > "exprcode" and "ensembleCommand" for tkInter. Tk never
> > > > > > returns a Tcl_Obj of the "boolean" and the "bignum" type, it
> > > > > > uses the "int" type for that (since pixels never exceed the
> > > > > > wideint range). "exprcode" and "ensembleCommand"
> > > > > > were not exported in Tcl 8.6, why do you want them now?
> > > > >
> > > > > I don't want types that could never appear.  It is just that I saw no reason why some core types should be registered and others not.  The tkinter module is not the only consumer.  It is simpler, conceptually and programmatically, to simply register all of the core types.  Also, I am pretty surprised to hear that boolean and bignum types could never appear as the result of a Tcl command processed by tkinter, given that _tkinter.c includes code for converting those types to Python types.  Are you sure about that?
> > > > >
> > > > > - Marc
> > > > >
> > > > > >
> > > > > > The "bignum" implementation changed between 8.6
> > > > > > and 8.7/9.0 too: the libtommath library in 8.6 was
> > > > > > always compiled for 32-bit. In 8.7 it's compiled for
> > > > > > 64-bit on 64-bit platforms. So, accessing the internal
> > > > > > fields won't be the same as in Tcl 8.6!
> > > > > >
> > > > > > That leaves "int" and "index". I can imagine those are
> > > > > > useful for optimization purposes in tkInter. If
> > > > > > Tcl_GetNumberFromObj (which doesn't handle "index")
> > > > > > is not a useful function for what tkInter needs it for,
> > > > > > I'm OK with adding those two back in Tcl 9.0.
> > > > > >
> > > > > > So:
> > > > > > 1) Marc, can you live with the compromise of adding
> > > > > > "int" and "index" only? IMHO "boolean" and
> > > > > > "bignum" are not useful for special-casing in tkInter.
> > > > > > For "exprcode" and "ensembleCommand" I don't
> > > > > > see a use-case at all.
> > > > > > 2) What would be needed for Tcl_GetNumberFromObj()
> > > > > > to make it a useful alternative for use in tkInter? Would
> > > > > > adding "index" and "boolean" (two additional enum
> > > > > > values) help there?
> > > > > >
> > > > > > I won't create a quick TIP for adding "index" and
> > > > > > "boolean" to Tcl_GetNumberFromObj(). Maybe for 9.1.
> > > > > >
> > > > > > Hope this helps,
> > > > > >        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] Review request: [0439e1e1a3]

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

Op di 9 jul 2024 om 11:13 schreef Pietro Cerutti:
>
> On Jul 08 2024, 11:04 UTC, Jan Nijtmans <jan...@gm...> wrote:
> >Op ma 8 jul 2024 om 11:57 schreef Reinhard Max:
> >> If possible without a considerable performance hit, I'd suggest to add
> >> information about which operand it was to the error message:
> >>
> >>      % expr {$x+$y}
> >>      can't use a list as the left operand of "+"
> >
> >That's not difficult at all:
> >     <https://core.tcl-lang.org/tcl/info/e2bcafbe4a0e0d47>
>
> Would it be cleaner to use an enumeration instead of a string for the
> ord argument, so callers don't need to remember that they need to add a
> space in "first " and "second " because of how you use them in the
> format string?

I thought of that, but IllegalExprOperandType() is only a private
function inside tclExecute.c. There are only a few callers now,
I don't think there will be more in the future.

Hope this helps,
      Jan Nijtmans

Re: [TCLCORE] Review request: [0439e1e1a3]

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

On Jul 08 2024, 11:04 UTC, Jan Nijtmans <jan...@gm...> wrote:
>Op ma 8 jul 2024 om 11:57 schreef Reinhard Max:
>> If possible without a considerable performance hit, I'd suggest to add
>> information about which operand it was to the error message:
>>
>>      % expr {$x+$y}
>>      can't use a list as the left operand of "+"
>
>That's not difficult at all:
>     <https://core.tcl-lang.org/tcl/info/e2bcafbe4a0e0d47>

Would it be cleaner to use an enumeration instead of a string for the 
ord argument, so callers don't need to remember that they need to add a 
space in "first " and "second " because of how you use them in the 
format string?

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

Re: [TCLCORE] Review request: [0439e1e1a3]

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

Op di 9 jul 2024 om 10:40 schreef apnmbx-public:
> While I do not have strong opinions in this matter, if error messages cannot
> be edited for clarity, consistency, detail etc. in a major release which has
> far more significant incompatibilities like tilde, strict encodings and
> more, then when can they be changed?

They always can be changed: Tcl doesn't guarantee keeping
the same error-messages. That said, we know that external
package maintainers have testcases which depend on the
exact text of an error-message. That's not right, but what
can we do about it....
Therefore, _big_  changes like "can't" -> "cannot" should
only be done in a minor release.

For now, it surely doesn't have enough priority for me,
we might look at it again in 9.1. It would be worth not
only looking at things like apostrophes., but also at
making it more concise.

Regards,
       Jan Nijtmans

Re: [TCLCORE] Review request: [0439e1e1a3]

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

While I do not have strong opinions in this matter, if error messages cannot
be edited for clarity, consistency, detail etc. in a major release which has
far more significant incompatibilities like tilde, strict encodings and
more, then when can they be changed?

/Ashok


-----Original Message-----
From: Christian Werner <Chr...@t-...> 
Sent: Tuesday, July 9, 2024 9:14 AM
To: Brian Griffin <bri...@ea...>; Jan Nijtmans
<jan...@gm...>
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] Review request: [0439e1e1a3]

On 07/09/2024 02:30 AM, Brian Griffin wrote:

Jan,

> I certainly do not prescribe correcting any pre-existing message, it's not
that important. (if it ain't broke, don't fix it.)  I do think, in general,
messages should be formal, to express serious professionalism.  That's all.
>
> -Brian
>
>> On Jul 8, 2024, at 15:51, Jan Nijtmans <jan...@gm...
<mailto:jan...@gm...>> wrote:
>>
>> Op di 9 jul 2024 om 00:02 schreef Christian Werner:
>>> No, I certainly don't hate apostrophes. I'm quite sure, there's
>>> a place for 'em in 'tis world. Why kill'em then now, suddenly?
>>
>> Are you generally against large commits? Did Brian
>> open a can-of-worms with his remark? Or is it simply
>> a matter of consistency? Fact is that some error-
>> messages use "cannot", others "can't". Brian seems to
>> prefer "cannot", I actually agree with him. Do you
>> disagree? Should it be "can't" everywhere?
>>
>> So, while on it, why not fix it?

These are the important points to underline:

  * "pre-existing message" (could be that existing third (n-th) party code
relies on it)
  * "if it ain't broke, don't fix it" ('cus that's how it's written)

The volume of a commit is not relevant at all. But it's impact is.
Take for example the last parameter to Tcl_SetErrorCode() which went
from plain NULL to (char *) NULL. Not visible from outside. Could be
a single huge commit (a reform) instead of many small ones (a process).
But changing exposed error messages simply could break decade old code
(unintended consequences, curse of the evil deed).

BR,
Christian



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

Re: [TCLCORE] Review request: [0439e1e1a3]

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

Op di 9 jul 2024 om 05:56 schreef Steve Landers:
>
> I would be happy with a statement that all new messages should not be contractions but existing messages should stay as they are to avoid unintended breakage. That gives both forward and backward clarity.

This makes sense.

Thanks!
          Jan Nijtmans

Re: [TCLCORE] Review request: [0439e1e1a3]

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

I would be happy with a statement that all new messages should not be contractions but existing messages should stay as they are to avoid unintended breakage. That gives both forward and backward clarity.

-- Steve
On 9 Jul 2024 at 11:47 AM +0800, Christian Werner <Chr...@t-...>, wrote:
> On 07/09/2024 02:30 AM, Brian Griffin wrote:
>
> Jan,
>
> > I certainly do not prescribe correcting any pre-existing message, it's not that important. (if it ain't broke, don't fix it.) I do think, in general, messages should be formal, to express serious professionalism. That's all.
> >
> > -Brian
> >
> > > On Jul 8, 2024, at 15:51, Jan Nijtmans <jan...@gm... <mailto:jan...@gm...>> wrote:
> > >
> > > Op di 9 jul 2024 om 00:02 schreef Christian Werner:
> > > > No, I certainly don't hate apostrophes. I'm quite sure, there's
> > > > a place for 'em in 'tis world. Why kill'em then now, suddenly?
> > >
> > > Are you generally against large commits? Did Brian
> > > open a can-of-worms with his remark? Or is it simply
> > > a matter of consistency? Fact is that some error-
> > > messages use "cannot", others "can't". Brian seems to
> > > prefer "cannot", I actually agree with him. Do you
> > > disagree? Should it be "can't" everywhere?
> > >
> > > So, while on it, why not fix it?
>
> These are the important points to underline:
>
> * "pre-existing message" (could be that existing third (n-th) party code relies on it)
> * "if it ain't broke, don't fix it" ('cus that's how it's written)
>
> The volume of a commit is not relevant at all. But it's impact is.
> Take for example the last parameter to Tcl_SetErrorCode() which went
> from plain NULL to (char *) NULL. Not visible from outside. Could be
> a single huge commit (a reform) instead of many small ones (a process).
> But changing exposed error messages simply could break decade old code
> (unintended consequences, curse of the evil deed).
>
> BR,
> Christian
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Review request: [0439e1e1a3]

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

On 07/09/2024 02:30 AM, Brian Griffin wrote:

Jan,

> I certainly do not prescribe correcting any pre-existing message, it's not that important. (if it ain't broke, don't fix it.)  I do think, in general, messages should be formal, to express serious professionalism.  That's all.
>
> -Brian
>
>> On Jul 8, 2024, at 15:51, Jan Nijtmans <jan...@gm... <mailto:jan...@gm...>> wrote:
>>
>> Op di 9 jul 2024 om 00:02 schreef Christian Werner:
>>> No, I certainly don't hate apostrophes. I'm quite sure, there's
>>> a place for 'em in 'tis world. Why kill'em then now, suddenly?
>>
>> Are you generally against large commits? Did Brian
>> open a can-of-worms with his remark? Or is it simply
>> a matter of consistency? Fact is that some error-
>> messages use "cannot", others "can't". Brian seems to
>> prefer "cannot", I actually agree with him. Do you
>> disagree? Should it be "can't" everywhere?
>>
>> So, while on it, why not fix it?

These are the important points to underline:

  * "pre-existing message" (could be that existing third (n-th) party code relies on it)
  * "if it ain't broke, don't fix it" ('cus that's how it's written)

The volume of a commit is not relevant at all. But it's impact is.
Take for example the last parameter to Tcl_SetErrorCode() which went
from plain NULL to (char *) NULL. Not visible from outside. Could be
a single huge commit (a reform) instead of many small ones (a process).
But changing exposed error messages simply could break decade old code
(unintended consequences, curse of the evil deed).

BR,
Christian

Re: [TCLCORE] Review request: [0439e1e1a3]

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

I certainly do not prescribe correcting any pre-existing message, it's not that important. (if it ain't broke, don't fix it.)  I do think, in general, messages should be formal, to express serious professionalism.  That's all.

-Brian

On Jul 8, 2024, at 15:51, Jan Nijtmans <jan...@gm...<mailto:jan...@gm...>> wrote:

Op di 9 jul 2024 om 00:02 schreef Christian Werner:
No, I certainly don't hate apostrophes. I'm quite sure, there's
a place for 'em in 'tis world. Why kill'em then now, suddenly?

Are you generally against large commits? Did Brian
open a can-of-worms with his remark? Or is it simply
a matter of consistency? Fact is that some error-
messages use "cannot", others "can't". Brian seems to
prefer "cannot", I actually agree with him. Do you
disagree? Should it be "can't" everywhere?

So, while on it, why not fix it?

Hope this helps,
   Jan Nijtmans


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

Re: [TCLCORE] Review request: [0439e1e1a3]

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

Op di 9 jul 2024 om 00:02 schreef Christian Werner:
> No, I certainly don't hate apostrophes. I'm quite sure, there's
> a place for 'em in 'tis world. Why kill'em then now, suddenly?

Are you generally against large commits? Did Brian
open a can-of-worms with his remark? Or is it simply
a matter of consistency? Fact is that some error-
messages use "cannot", others "can't". Brian seems to
prefer "cannot", I actually agree with him. Do you
disagree? Should it be "can't" everywhere?

So, while on it, why not fix it?

Hope this helps,
    Jan Nijtmans

Re: [TCLCORE] Review request: [0439e1e1a3]

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

On 07/08/2024 09:04 PM, Christian Werner wrote:

> While I fully support elimination of single single quotes in error ...
> Alternatively, we could conserve these eggs for later.

As time goes shortly by, things condense very soon into Tk
according to this commit

   https://core.tcl-lang.org/tk/info/90e6962b3d06f283

No, I certainly don't hate apostrophes. I'm quite sure, there's
a place for 'em in 'tis world. Why kill'em then now, suddenly?

Resembles somewhat to the Grand Master Slave rename. In hindsight
irrelevant but still disturbing. Due to 20+ years history without
any doubt.

Unconvinced, grumbling,
Christian

--

"But Kataklysmik Kat'astrophe shalt overcome unto you, mortals,
for all your toxic deeds on The Code."

Re: [TCLCORE] Review request: [0439e1e1a3]

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

On 07/08/2024 03:02 PM, Brian Griffin wrote:

> The only change I would recommend is to not use a contraction in the error message. In other words, use “cannot” instead of “can’t”. IMO, messages should be formal, not conversational.

While I fully support elimination of single single quotes in error
messages regardless of formalism or conversation I wonder how many
omelettes we'll be able to make from the potentially many broken eggs.
Alternatively, we could conserve these eggs for later.

Best,
Christian

Re: [TCLCORE] Review request: [0439e1e1a3]

[Patrick M. <dus...@gm...>]

Contractions are used in other places too, for instance, the Tk error
message "image doesn't exist".

Regards,
PM

On Mon, 8 Jul 2024 at 14:44, Jan Nijtmans <jan...@gm...> wrote:

> Op ma 8 jul 2024 om 15:02 schreef Brian Griffin:
> > The only change I would recommend is to not use a contraction in the
> error message. In other words, use “cannot” instead of “can’t”. IMO,
> messages should be formal, not conversational.
>
> Thanks!  I'll change that for these error-messages.
>
> Also noting that the use of "can't" vs "cannot" is not
> consistent at all: both are used in Tcl error-messages.
> It would be good to use "cannot" everywhere, but
> it's a little too much to do that for this ticket ....
>
> Regards,
>        Jan Nijtmans
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Review request: [0439e1e1a3]

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

Op ma 8 jul 2024 om 15:02 schreef Brian Griffin:
> The only change I would recommend is to not use a contraction in the error message. In other words, use “cannot” instead of “can’t”. IMO, messages should be formal, not conversational.

Thanks!  I'll change that for these error-messages.

Also noting that the use of "can't" vs "cannot" is not
consistent at all: both are used in Tcl error-messages.
It would be good to use "cannot" everywhere, but
it's a little too much to do that for this ticket ....

Regards,
       Jan Nijtmans

Re: [TCLCORE] Review request: [0439e1e1a3]

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

Hi Jan,

Thanks for doing this! 
The only change I would recommend is to not use a contraction in the error message. In other words, use “cannot” instead of “can’t”. IMO, messages should be formal, not conversational. 

-Brian

> On Jul 8, 2024, at 02:40, Jan Nijtmans <jan...@gm...> wrote:
> 
> Hi all,
> 
> This ticket is meant for functions which require a
> single numerical argument. If they are provided
> a (potentially very long) list, it might take a long
> time to generate the string representation of the
> list, only discovering afterwards it won't work.
> 
> Example:
>    $ tclsh9.0
>    % set x [lseq 1 11111111111111];set y 5
>    5
>    % expr {$x+$y}
> (this simply hangs for a long time)
> 
> My proposal:
>    % set x [lseq 1 11111111111111];set y 5
>    5
>    % expr {$x+$y}
>    can't use a list as operand of "+"
> 
> That means, if the argument can be represented
> as a list (with >1 elements), it won't be printed as
> part of the error-message any more.
> 
> Please have a look:
>    <https://core.tcl-lang.org/tcl/tktview/0439e1e1a3>
> 
> If there are no objections, I'll commit this in
> a few days.
> 
> Thanks!
>        Jan NIjtmans
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 

Re: [TCLCORE] Review request: [0439e1e1a3]

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

Op ma 8 jul 2024 om 11:57 schreef Reinhard Max:
> If possible without a considerable performance hit, I'd suggest to add
> information about which operand it was to the error message:
>
>      % expr {$x+$y}
>      can't use a list as the left operand of "+"

That's not difficult at all:
     <https://core.tcl-lang.org/tcl/info/e2bcafbe4a0e0d47>

Thanks for the idea!
      Jan Nijtmans

Re: [TCLCORE] Review request: [0439e1e1a3]

[Reinhard M. <rei...@m4...>]

Am 08.07.2024 11:39, schrieb Jan Nijtmans:

> My proposal:
>     % set x [lseq 1 11111111111111];set y 5
>     5
>     % expr {$x+$y}
>     can't use a list as operand of "+"

If possible without a considerable performance hit, I'd suggest to add 
information about which operand it was to the error message:

     % expr {$x+$y}
     can't use a list as the left operand of "+"
     % expr {$y+$x}
     can't use a list as the right operand of "+"

cu
Reinhard

[TCLCORE] Review request: [0439e1e1a3]

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

Hi all,

This ticket is meant for functions which require a
single numerical argument. If they are provided
a (potentially very long) list, it might take a long
time to generate the string representation of the
list, only discovering afterwards it won't work.

Example:
    $ tclsh9.0
    % set x [lseq 1 11111111111111];set y 5
    5
    % expr {$x+$y}
(this simply hangs for a long time)

My proposal:
    % set x [lseq 1 11111111111111];set y 5
    5
    % expr {$x+$y}
    can't use a list as operand of "+"

That means, if the argument can be represented
as a list (with >1 elements), it won't be printed as
part of the error-message any more.

Please have a look:
    <https://core.tcl-lang.org/tcl/tktview/0439e1e1a3>

If there are no objections, I'll commit this in
a few days.

Thanks!
        Jan NIjtmans

[TCLCORE] July 9 2024 Tcl monthly virtual meetup notice

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

A reminder that the July Tcl virtual meetup will be  held Tuesday July 9th 2024 at [clock format 1720573200] - Tuesday 6pm US West, 8pm US Central, 9pm US East, Wednesday 1am UTC, 2am UK, 3am Western Europe, 6:30am India, 9am Australia West / Singapore / China, 10am Japan, 11am Australia East, 1pm New Zealand

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

-- Steve

Re: [TCLCORE] Migration tool for Tcl 9

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

V0.2 of the migration tool has been released following feedback from Paul and Andreas (thanks both).

 

https://github.com/apnadkarni/tcl9-migrate/releases

 

Docs: https://github.com/apnadkarni/tcl9-migrate/blob/main/README.md

 

Additional feedback on false positive/negatives appreciated.

 

/Ashok

 

From: apn...@ya... <apn...@ya...> On Behalf Of apn...@ya...
Sent: Tuesday, July 2, 2024 10:44 AM
To: apn...@ya...; 'Paul Obermeier' <pa...@po...>; tcl...@li...
Subject: RE: [TCLCORE] Migration tool for Tcl 9

 

Oops, I mean false positive, not false negative 😊 It should not flag a warning.

 

From: apnmbx-public--- via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > 
Sent: Tuesday, July 2, 2024 8:01 AM
To: 'Paul Obermeier' <pa...@po... <mailto:pa...@po...> >; tcl...@li... <mailto:tcl...@li...> 
Subject: Re: [TCLCORE] Migration tool for Tcl 9

 

Yes, that would seem to be a false negative. Does not seem to account for reference to array elements when the array variable is declared. Should be fixable..I think.

 

Thanks for the feedback

 

From: Paul Obermeier <pa...@po... <mailto:pa...@po...> > 
Sent: Tuesday, July 2, 2024 3:14 AM
To: tcl...@li... <mailto:tcl...@li...> 
Subject: Re: [TCLCORE] Migration tool for Tcl 9

 

For the following simple test script:
namespace eval poImg {
    variable DrawPos

    set DrawPos(x) 0
    set DrawPos(y) 0
}

I get the following warnings from tcl9-migrate:
Line   4: W Variable "DrawPos(x)" possibly set without a variable or global declaration within namespace ::poImg. [UNDECLARED]
Line   5: W Variable "DrawPos(y)" possibly set without a variable or global declaration within namespace ::poImg. [UNDECLARED]

Is this a false negative?

Paul

Am 01.07.2024 um 22:42 schrieb Paul Obermeier:

Hi Ashok,

thanks for this great tool.

I found several Tcl9 related issues (esp. [RELATIVENS] and [UNDECLARED]) in my Tcl sources,
which are otherwise difficult to find.
The runtime checker works, too. 

Best regards,
Paul

Am 01.07.2024 um 09:44 schrieb apnmbx-public--- via Tcl-Core:

All,

 

I've been working on a tool to help with migration of Tcl 8 scripts to Tcl 9. It includes a static checker based on Nagelfar as well as a runtime shim that fixes up incompatibilities like i/o encoding errors, tilde expansion, package requirements etc., allowing the scripts to be loaded while emitting warnings.

 

Repository: https://github.com/apnadkarni/tcl9-migrate

Docs: https://github.com/apnadkarni/tcl9-migrate/blob/main/README.md

Download: https://github.com/apnadkarni/tcl9-migrate/releases/tag/v0.1

 

I'm looking for testers and feedback on both the tool as well as documentation (explanation of the warnings). I'd appreciate testing with your Tcl 8 (or ported to Tcl 9) code bases. Please log tickets in above repository.

 

Be warned it has (and always will have) false positives and false negatives but the hope is it will nevertheless be useful in saving time.

 

Thanks

 

/Ashok

 

_______________________________________________
Tcl-Core mailing list
Tcl...@li... <mailto:Tcl...@li...> 
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