tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] New Logo ?

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

The blue feather was designed by David Zolli.  I like it and prefer it to the earlier feather designed by Clif Flynt (IIRC).

The logo mentioned by Brian might be the one designed by Tim Hartford of Hartford Design (https://hartfordesign.com/). Tim did this some years ago as a favour for the Tcl community, including the logo and color palette.   I dusted it off for Torsten, Max and Shaun to use in the documentation project.


-- Steve
On 23 Jul 2024 at 5:36 AM +0800, Torsten Berg <be...@ty...>, wrote:
> No, that wasn't me.
>
> I really like the nice blue feather and would miss it. I also think people are probably now used to the logo and a new one should be not too different so it can be recognized. This is probably true for any brand: change your logo gradually, not dramatically.
>
> Torsten
>
>
> > Am 22.07.2024 um 18:58 schrieb Brian Griffin <bri...@ea...>:
> >
> > Very creative!
> > I also like the logo Torsten(?) came up with: T<L
> > It’s a stylized combination of Tcl and Tk
> >
> > -Brian
> >
> > > On Jul 22, 2024, at 08:40, Colin Macleod via Tcl-Core <tcl...@li...> wrote:
> > >
> > > Dear All,
> > > I'm wondering if it might be worth updating the Tcl logo for version 9.  The current feather logo is rather obscure, being based on Tcl sounding like "tickle", and may give the impression that it's not suitable for serious work.  Also it's very similar to the feather logo used by Apache.
> > > I've put together a couple of suggestion, trying to emphasise the Tools aspect of the Tool Command Language:
> > >
> > > 1. Spelling out Tcl9 with svg images of tools (all public domain)
> > > <logo.svg>
> > > 2. Tcl9 as a geometrical animated GIF
> > > <tcl9.gif>
> > >
> > > This was generated by a TclMagick script, I've put the code at https://cmacleod.me.uk/tcl/logo/
> > >
> > > Colin.
> > > _______________________________________________
> > > Tcl-Core mailing list
> > > Tcl...@li...
> > > https://lists.sourceforge.net/lists/listinfo/tcl-core
> > <tcl9.gif><logo.svg>_______________________________________________
> > 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] New Logo ?

[Torsten B. <be...@ty...>]

No, that wasn't me.

I really like the nice blue feather and would miss it. I also think people are probably now used to the logo and a new one should be not too different so it can be recognized. This is probably true for any brand: change your logo gradually, not dramatically.

Torsten


> Am 22.07.2024 um 18:58 schrieb Brian Griffin <bri...@ea...>:
> 
> Very creative!
> I also like the logo Torsten(?) came up with: T<L
> It’s a stylized combination of Tcl and Tk
> 
> -Brian
> 
>> On Jul 22, 2024, at 08:40, Colin Macleod via Tcl-Core <tcl...@li...> wrote:
>> 
>> 
>> Dear All,
>> 
>> I'm wondering if it might be worth updating the Tcl logo for version 9.  The current feather logo is rather obscure, being based on Tcl sounding like "tickle", and may give the impression that it's not suitable for serious work.  Also it's very similar to the feather logo used by Apache.
>> 
>> I've put together a couple of suggestion, trying to emphasise the Tools aspect of the Tool Command Language:
>> 
>> Spelling out Tcl9 with svg images of tools (all public domain)
>> <logo.svg>
>> Tcl9 as a geometrical animated GIF
>> <tcl9.gif>
>> 
>> This was generated by a TclMagick script, I've put the code at https://cmacleod.me.uk/tcl/logo/
>> Colin.
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
> <tcl9.gif><logo.svg>_______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] The tip of an iceberg

[Francois V. <fvo...@fr...>]

Following your latest commit, note there is a second place where this 
should be corrected: see same file, line 201.

F.

Le 22/07/2024 à 21:50, Marc Culler a écrit :
> Oh, never mind.  I just figured out that I put the decimal point in 
> the wrong place on my last commit when I replaced the literal 
> expression by a litteral value.  So it really was off by a factor otf 
> 10.  Exactly.
>
> - Marc
>
> On Mon, Jul 22, 2024 at 2:26 PM Marc Culler <mar...@gm...> wrote:
>
>     The seemingly innocuous change that I made, where the floating
>     point number 0.35278 was replaced by its correct value, namely 
>     0.352777777777777777 is the tip of an iceberg on which the ship of
>     TclTk is going to crash and then possibly sink to the bottom.
>
>     The effect of that change was that many computations of sizes of
>     widgets are now producing crazy answers.  The answers are not just
>     off by .00001.  They are hugely wrong.
>
>     The second example I have seen of this is the test spinbox-3.0 in
>     ttk/spinbox.test.  (The first was in my mathematical software
>     project, SnapPy, where windows suddenly had crazy sizes.)
>
>     The spinbox-3.0 test is now failing, not just on CI but also on
>     real computers and on all platforms.  The test is checking that a
>     ttk spinbox expands horizontally when gridded with sticky=ew in a
>     column with weight 1.  The test only fails when the entire test
>     suite is run, not when you just run the one file.  I added a long
>     wait in that test so I could take a screenshot of the window
>     containing the spinbox during the test.  It looks like this:
>     Screenshot 2024-07-22 at 12.54.22 PM.png
>
>     If you create the same window in wish it looks like what you would
>     expect, like this:
>
>     Screenshot 2024-07-22 at 12.58.47 PM.png
>
>     What is causing this is that the height of the spinbox widget is
>     being computed before it is displayed, and the answer is turning
>     out to be many times bigger than it should be -- I'd say about an
>     order of magnitude larger.
>
>     Here is what I think is going on.  The number 0.35278 has a string
>     representation with only 7 characters.  The string representation
>     of 0.352777777777777777 is much larger.  I believe that there are
>     moments when Tcl assumes that a Tcl Object representing a double
>     has a string representation with at most 8 characters (which would
>     fit in a long long, and make sense for a single precision
>     number).  This assumption is not being made all of the time, just
>     in situations where there is not much time available for
>     initializing Tcl Objects with their correct floating point
>     values.  (Is this is an example of "shimmering"?)  Running the
>     test suite is such a time when things are happening very rapidly. 
>     And that is why the spinbox is being given a height that is 10
>     times too large when the full test suite is run, but not when
>     running only the one test file or when creating the equivalent
>     widget interactively in wish.
>
>     Can any of our Tcl experts provide an explanation for how this
>     could happen (and, more importantly, how to fix it)? I would not
>     be surprised to hear that it is impossible.  But you can see the
>     evidence in the two screenshots above and the sudden appearance of
>     failed tests after that extremely minor change.
>
>     - Marc
>     _______________________________________________
>     Tcl-Core mailing list
>     Tcl...@li...
>     https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] The tip of an iceberg

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

Oh, never mind.  I just figured out that I put the decimal point in the
wrong place on my last commit when I replaced the literal expression by a
litteral value.  So it really was off by a factor otf 10.  Exactly.

- Marc

On Mon, Jul 22, 2024 at 2:26 PM Marc Culler <mar...@gm...> wrote:

> The seemingly innocuous change that I made, where the floating point
> number 0.35278 was replaced by its correct value, namely
> 0.352777777777777777 is the tip of an iceberg on which the ship of TclTk is
> going to crash and then possibly sink to the bottom.
>
> The effect of that change was that many computations of sizes of widgets
> are now producing crazy answers.  The answers are not just off by .00001.
> They are hugely wrong.
>
> The second example I have seen of this is the test spinbox-3.0 in
> ttk/spinbox.test.  (The first was in my mathematical software project,
> SnapPy, where windows suddenly had crazy sizes.)
>
> The spinbox-3.0 test is now failing, not just on CI but also on real
> computers and on all platforms.  The test is checking that a ttk spinbox
> expands horizontally when gridded with sticky=ew in a column with weight
> 1.  The test only fails when the entire test suite is run, not when you
> just run the one file.  I added a long wait in that test so I could take a
> screenshot of the window containing the spinbox during the test.  It looks
> like this:
> [image: Screenshot 2024-07-22 at 12.54.22 PM.png]
>
> If you create the same window in wish it looks like what you would expect,
> like this:
>
> [image: Screenshot 2024-07-22 at 12.58.47 PM.png]
>
> What is causing this is that the height of the spinbox widget is being
> computed before it is displayed, and the answer is turning out to be many
> times bigger than it should be -- I'd say about an order of magnitude
> larger.
>
> Here is what I think is going on.  The number 0.35278 has a string
> representation with only 7 characters.  The string representation of
> 0.352777777777777777 is much larger.  I believe that there are moments when
> Tcl assumes that a Tcl Object representing a double has a string
> representation with at most 8 characters (which would fit in a long long,
> and make sense for a single precision number).  This assumption is not
> being made all of the time, just in situations where there is not much time
> available for initializing Tcl Objects with their correct floating point
> values.  (Is this is an example of "shimmering"?)  Running the test suite
> is such a time when things are happening very rapidly.  And that is why the
> spinbox is being given a height that is 10 times too large when the full
> test suite is run, but not when running only the one test file or when
> creating the equivalent widget interactively in wish.
>
> Can any of our Tcl experts provide an explanation for how this could
> happen (and, more importantly, how to fix it)? I would not be surprised to
> hear that it is impossible.  But you can see the evidence in the two
> screenshots above and the sudden appearance of failed tests after that
> extremely minor change.
>
> - Marc
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

[TCLCORE] The tip of an iceberg

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

The seemingly innocuous change that I made, where the floating point number
0.35278 was replaced by its correct value, namely  0.352777777777777777 is
the tip of an iceberg on which the ship of TclTk is going to crash and then
possibly sink to the bottom.

The effect of that change was that many computations of sizes of widgets
are now producing crazy answers.  The answers are not just off by .00001.
They are hugely wrong.

The second example I have seen of this is the test spinbox-3.0 in
ttk/spinbox.test.  (The first was in my mathematical software project,
SnapPy, where windows suddenly had crazy sizes.)

The spinbox-3.0 test is now failing, not just on CI but also on real
computers and on all platforms.  The test is checking that a ttk spinbox
expands horizontally when gridded with sticky=ew in a column with weight
1.  The test only fails when the entire test suite is run, not when you
just run the one file.  I added a long wait in that test so I could take a
screenshot of the window containing the spinbox during the test.  It looks
like this:
[image: Screenshot 2024-07-22 at 12.54.22 PM.png]

If you create the same window in wish it looks like what you would expect,
like this:

[image: Screenshot 2024-07-22 at 12.58.47 PM.png]

What is causing this is that the height of the spinbox widget is being
computed before it is displayed, and the answer is turning out to be many
times bigger than it should be -- I'd say about an order of magnitude
larger.

Here is what I think is going on.  The number 0.35278 has a string
representation with only 7 characters.  The string representation of
0.352777777777777777 is much larger.  I believe that there are moments when
Tcl assumes that a Tcl Object representing a double has a string
representation with at most 8 characters (which would fit in a long long,
and make sense for a single precision number).  This assumption is not
being made all of the time, just in situations where there is not much time
available for initializing Tcl Objects with their correct floating point
values.  (Is this is an example of "shimmering"?)  Running the test suite
is such a time when things are happening very rapidly.  And that is why the
spinbox is being given a height that is 10 times too large when the full
test suite is run, but not when running only the one test file or when
creating the equivalent widget interactively in wish.

Can any of our Tcl experts provide an explanation for how this could happen
(and, more importantly, how to fix it)? I would not be surprised to hear
that it is impossible.  But you can see the evidence in the two screenshots
above and the sudden appearance of failed tests after that extremely minor
change.

- Marc

Re: [TCLCORE] New Logo ?

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

Very creative!
I also like the logo Torsten(?) came up with: T<L
It’s a stylized combination of Tcl and Tk

-Brian

On Jul 22, 2024, at 08:40, Colin Macleod via Tcl-Core <tcl...@li...> wrote:



Dear All,

I'm wondering if it might be worth updating the Tcl logo for version 9.  The current feather logo is rather obscure, being based on Tcl sounding like "tickle", and may give the impression that it's not suitable for serious work.  Also it's very similar to the feather logo used by Apache.

I've put together a couple of suggestion, trying to emphasise the Tools aspect of the Tool Command Language:

  1.  Spelling out Tcl9 with svg images of tools (all public domain)
<logo.svg>
  2.  Tcl9 as a geometrical animated GIF
<tcl9.gif>

This was generated by a TclMagick script, I've put the code at https://cmacleod.me.uk/tcl/logo/

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

[TCLCORE] New Logo ?

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

Dear All,

I'm wondering if it might be worth updating the Tcl logo for version 9.  
The current feather logo is rather obscure, being based on Tcl sounding 
like "tickle", and may give the impression that it's not suitable for 
serious work.  Also it's very similar to the feather logo used by Apache.

I've put together a couple of suggestion, trying to emphasise the Tools 
aspect of the Tool Command Language:

 1. Spelling out Tcl9 with svg images of tools (all public domain)
 2. Tcl9 as a geometrical animated GIF

    This was generated by a TclMagick script, I've put the code at
    https://cmacleod.me.uk/tcl/logo/

Colin.

[TCLCORE] Delighted by TIP 700: TCL documentation reform

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

Dear Torsten, dear Team,
I am delighted by recent developments of TIP700:

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

- There is a semantic markup defined, which clearly tags part of the 
documentation with very readable tags like ".cmd".
- Code samples are unified and have command/answer markup and copy/try 
functionality

I would also invite to merge documentation correction already to the 
main branch. I think, it is getting better by those changes.

Thank you all, great work!
Harald

Re: [TCLCORE] Go port

[Jan M. <0x...@gm...>]

On Sat, Jul 20, 2024 at 1:30 PM Donal Fellows
<don...@ma...> wrote:

> High level:

Thanks to all of the much appreciated help from this thread it was
possible to resolve the issue[0].

Many thanks for all inputs!

Regards,

-j

  [0]: https://gitlab.com/cznic/tk8.6/-/issues/1#note_2009294070

[TCLCORE] TCL at HackerNews

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

Hi all,

Just a heads up that this is the second day TCL is featured at HackerNews,
which is very popular among the tech community.

Yesterday, they had an interview of John Ousterhout from 2023:
https://news.ycombinator.com/item?id=41017367 - A brief interview with Tcl
creator John Ousterhout (2023)

Today, they have this: https://news.ycombinator.com/item?id=41022400 - Why
You Should Not Use Tcl (1994).

I am sorry if it is offtopic in any way but I think it would help if people
contributed to the discussion there.

All the best,
Neophytos

Re: [TCLCORE] Go port

[Donal F. <don...@ma...>]

High level:

Key presses enter Tk as KeyEvents (or the equivalent on other platforms). Those events are routed to the widget that has the focus (unlike many other events which go to the widget that has the mouse over it or which are just delivered to the target window). Upon delivery to a widget, events are mostly processed by a binding table (the thing that [bind] and [bindtags] manipulate) to work out what script to dispatch to; this is *always* the case for key events (some other events are handled separately). The table resolves things to a sequence of scripts, one for each relevant binding tag; the relevant ones for a key event on a ttk::entry are typically the <Key> event on the TEntry class, but there are other bindings for some keys.

The class binding calls a procedure that decides what to do (a common Tk pattern) and that’s usually call the insert method with the correct insertion location for entries. That updates the underlying model of the widget, and schedules a redisplay of the widget when the event loop goes idle; that delayed redisplay mechanism is critical to how Tk works and is why Tk has had good performance for decades. (Idle means “no events pending from the event sources, would otherwise ask the OS to let us sleep to wait efficiently”.)

The actual redisplay code does the obvious thing, using double buffering, repainting using standard drawing functions. Comparatively obvious stuff if you’ve ever done any GUI programming at all.

Summary: high level Controllers are in Tcl scripts, Model is simple (typically just a string in a variable for entries) with some manipulator methods, and the View is done on a delayed basis.

Donal.

From: Jan Mercl <0x...@gm...>
Sent: Friday, July 19, 2024 12:14 PM
To: tcl...@li...
Subject: [TCLCORE] Go port

Hi list. I'm looking for help. I started a Tcl/Tk port for the Go programming language. (The C code is transpilled to Go, making cross compilation of Go programs using the package easier. ) Some things already work, many other do not yet. Additionally
ZjQcmQRYFpfptBannerStart
This Message Is From a New External Sender
You have not previously corresponded with this sender. Please exercise caution when opening links or attachments included in this message.
ZjQcmQRYFpfptBannerEnd

Hi list.



I'm looking for help. I started a Tcl/Tk port for the Go programming

language. (The C code is transpilled to Go, making cross compilation

of Go programs using the package easier.) Some things already work,

many other do not yet. Additionally I'm making

https://urldefense.com/v3/__https://pkg.go.dev/modernc.org/tk8.6__;!!PDiH4ENfjr2_Jw!BJn92uxN3omZowdJJBDQBI63EVsnJASDgsFBsyAtOWxLxH5bqxIm83o2VslMWwhtnnmnGNtWZAeMhvzwTtWH3vS8G0w$<https://urldefense.com/v3/__https:/pkg.go.dev/modernc.org/tk8.6__;!!PDiH4ENfjr2_Jw!BJn92uxN3omZowdJJBDQBI63EVsnJASDgsFBsyAtOWxLxH5bqxIm83o2VslMWwhtnnmnGNtWZAeMhvzwTtWH3vS8G0w$>[pkg[.]go[.]dev], which is something like tkinter

for Go. It is a work in progress, not even alfa stage yet. I ran into

https://urldefense.com/v3/__https://gitlab.com/cznic/tk8.6/-/issues/1__;!!PDiH4ENfjr2_Jw!BJn92uxN3omZowdJJBDQBI63EVsnJASDgsFBsyAtOWxLxH5bqxIm83o2VslMWwhtnnmnGNtWZAeMhvzwTtWHMgG7Bq4$<https://urldefense.com/v3/__https:/gitlab.com/cznic/tk8.6/-/issues/1__;!!PDiH4ENfjr2_Jw!BJn92uxN3omZowdJJBDQBI63EVsnJASDgsFBsyAtOWxLxH5bqxIm83o2VslMWwhtnnmnGNtWZAeMhvzwTtWHMgG7Bq4$>[gitlab[.]com]. Unfortunately, my practical

experiences using Tcl/Tk are almost non existing.



What I'm looking for is a high-level overview of how the machinery on

the path from a keyboard keypress to the character getting displayed

in the entry/ttk::entry widget works in Tcl/Tk. In other words, where

do I need to look in debugging the issue for checkpoints. So far I was

able to find the window  manager events handling, I think. Where are

the [other] X events processed missed me on the initial attempts. I

can perhaps figure it out by myself, but I guess some guidance can

save me a lot of time learning what someone else can teach me quickly.

Or please point me to some existing design document I failed to find.



I was advised on the Tcl Slack #general channel to ask here.



Thanks in advance for any hints/tips.



-j





_______________________________________________

Tcl-Core mailing list

Tcl...@li...<mailto:Tcl...@li...>

https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!BJn92uxN3omZowdJJBDQBI63EVsnJASDgsFBsyAtOWxLxH5bqxIm83o2VslMWwhtnnmnGNtWZAeMhvzwTtWHgaFE_Ug$<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!BJn92uxN3omZowdJJBDQBI63EVsnJASDgsFBsyAtOWxLxH5bqxIm83o2VslMWwhtnnmnGNtWZAeMhvzwTtWHgaFE_Ug$>[lists[.]sourceforge[.]net]

Re: [TCLCORE] support documents update

[Benjamin R. <b.r...@tu...>]

Hi Donal, all.

Donal Fellows writes:
> things other than *roff natively so pictures could be used)

Just to clarify, not as a general defence of troff: Troff can include
pictures fine (traditionally as PS), it was intended as complete
solution for papers after all IIUC.  Pictures do not work in the
terminal, of course, so for the use as offline documentation on the
command-line (man XXX) you need fallbacks in ASCII art or references to
external resources.

regards, benny

Re: [TCLCORE] Go port

[Jan M. <0x...@gm...>]

On Fri, Jul 19, 2024 at 2:05 PM Harald Oehlmann
<har...@el...> wrote:

> great that you do this work. I think, looking at TkInter would be the
> best. We have active people here caring about it. Also, we have Go
> people here, who may comment.
>
> Currently, we are in the redesign process of all extensions to Tcl/Tk 9.
> It might be more effective to directly look to TCL/Tk 9.

I actually started with POC based on Tck/Tk 9 beta first[0]  ;-)

> About your Tk question. You are interested in Linux, right?

Correct at the moment, but other platforms are intended to come later.
The wish is to cover Linux/macOS/Windows on all of the most used CPU
architectures. Let's see how it goes.

> The outer event system is translated to Tk events by a compatibility
> layer. Widgets like ttk::entry typically only get tk events.
> See the bind manual page for a description.
>
> You may first bump any event on the TCL console:
> https://wiki.tcl-lang.org/page/Key%2Dpress+names

That was really helpful, thanks! Based on your advice I found the
right place in tkBind.c and with some debug prints it turns out both
%K and %N substitutions work as intended but the %A does not. Long
story short, the failure seems to be rooted in some layers below in
libX11 that does not assign any ucs-to-string converter because it
looks there's some misconfiguration of locale/encoding. I don't know
if it is a runtime problem or a ./configure and build time issue. Or
it could be a bug in the transpiler.

For Go in particular, I think it is enough to support Unicode as the
only encoding, which luckily allows me to cheat and possibly hard-code
the locale or the ucs converter somewhere.

Thanks again.

Best regards,

-j

  [0]: https://opu.peklo.biz/p/24/07/20/1721466621-ee773.jpg

Re: [TCLCORE] support documents update

[Donal F. <don...@ma...>]

There’s lots of different types of documentation possible. The basic Tcl docs are reference material, and we need that (as it states the definitions of what people can assume), but there’s a lot of space for other, more discursive documents such as tutorials, howtos, general maps of how things fit together, etc. We have some examples in most Tcl manual pages (and many Tk ones; those would benefit from being in things other than *roff natively so pictures could be used) but there’s always more possible, especially ones that illustrate how different parts can be used together. Since at a base level, we try to make everything work reasonably with everything else, the ways in which stuff can be used creatively are always a bit mysterious.

My point? We welcome more! Yes, we’re careful with the reference docs as they’re normative (or near to), but anything else is a truly welcome contribution. (Don’t know where to put such things right now, but we’ll cross that bridge when we get there.) It’s hard for those of us working on the core of Tcl and Tk themselves to see exactly what needs doing; we’re already aware of many of the details and so can’t see much of what is confusing to others.

Donal.

From: nb...@to... <nb...@to...>
Sent: Sunday, July 14, 2024 2:59 AM
To: tcl...@li...
Subject: [TCLCORE] support documents update

after read this， I really support this work to became true. as a newbie， we need tcl/tk doc more readable，more update，more access able. support offline read. thank your all ! Enhancing Tcl/Tk Documentation: From
ZjQcmQRYFpfptBannerStart
This Message Is From a New External Sender
You have not previously corresponded with this sender. Please exercise caution when opening links or attachments included in this message.
ZjQcmQRYFpfptBannerEnd
after read this，
I really support this work to became true. as a newbie， we need tcl/tk doc  more readable，more update，more access able. support offline read. thank your all !

Enhancing Tcl/Tk Documentation: From nroff to Markdown and further [openacs.org]<https://urldefense.com/v3/__https:/openacs.org/conf2024/info/download/file/openacs-tcltk-2024-manual-pages.pdf__;!!PDiH4ENfjr2_Jw!AEKwRRVIWSERuXj2pKc3VhhZKVdXNgWkVKfByzqJTjYCoGDWoQVeVjyRPCD5VVEPA5h-1jEC-rMTQb3AJOtiar4c$>
Torsten Berg


发自我的手机

Re: [TCLCORE] Tcl/Tk 9.0b2 RELEASED

[elns <el...@xs...>]

Ticket created for the build issue:

https://core.tcl-lang.org/tk/tktview/59518a2d7a97a44692fd6f5639f7e2a8a31be4a3

Erik Leunissen
--


On 7/19/24 17:16, Jan Nijtmans wrote:
> 
> 
> Op do 18 jul 2024 14:34 schreef elns <el...@xs... <mailto:el...@xs...>>:
> 
>     Two remarks:
> 
>     A. Build problem
>     ================
>     I use to building for a x86_64-mingw32 target from a linux host, using a gcc cross compiler. This
>     went well for Tcl. For Tk, the build aborted with:
> 
>       > /opt/toolchains/x86_64-w64-mingw32/bin/x86_64-w64-mingw32-gcc -std=gnu11 -c -O2
>     -fomit-frame-pointer -D_ATL_XP_TARGETING=1 -D__USE_MINGW_ANSI_STDIO=0 -Wall -Wextra -Wshadow -Wundef
> 
> 
> 
> Where does  -D_ATL_XP_TARGETING=1 come from?
> 
> My guess is that this is the problem. It disables Windows 7+ API's
> 
> Hope this helps
> 
>         Jan Nijtmans

Re: [TCLCORE] Tcl/Tk 9.0b2 RELEASED

[elns <el...@xs...>]

On 7/19/24 17:16, Jan Nijtmans wrote:
> 
> Where does  -D_ATL_XP_TARGETING=1 come from?
> 

Well, it appears to originate from the Tcl source distribution at:

win/Makefile.in:177:

CFLAGS              = @CFLAGS@ @CFLAGS_DEFAULT@ -D_ATL_XP_TARGETING=1 -D__USE_MINGW_ANSI_STDIO=0

> My guess is that this is the problem. It disables Windows 7+ API's

I recompiled with:

a. this directive removed from that line:

CFLAGS              = @CFLAGS@ @CFLAGS_DEFAULT@ -D__USE_MINGW_ANSI_STDIO=0

b. setting its value to zero:

CFLAGS              = @CFLAGS@ @CFLAGS_DEFAULT@ -D_ATL_XP_TARGETING=0 -D__USE_MINGW_ANSI_STDIO=0


In both variants, I get the exact same error as reported previously.

So, alas no luck.
Erik.
--

> 
> Hope this helps
> 
>         Jan Nijtmans

Re: [TCLCORE] Tcl/Tk 9.0b2 RELEASED

[elns <el...@xs...>]

On 7/19/24 17:16, Jan Nijtmans wrote:
> 
> Where does  -D_ATL_XP_TARGETING=1 come from?
> 

No idea. I never knew about this (or many other) directives.
But I'm going to find this out, and see whether I can experiment with it.


> My guess is that this is the problem. It disables Windows 7+ API's
> 

I'll report back my when I have a result.

Thanks for the hint.
Erik.
--


> Hope this helps
> 
>         Jan Nijtmans

Re: [TCLCORE] Tcl/Tk 9.0b2 RELEASED

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

Op do 18 jul 2024 14:34 schreef elns <el...@xs...>:

> Two remarks:
>
> A. Build problem
> ================
> I use to building for a x86_64-mingw32 target from a linux host, using a
> gcc cross compiler. This
> went well for Tcl. For Tk, the build aborted with:
>
>  > /opt/toolchains/x86_64-w64-mingw32/bin/x86_64-w64-mingw32-gcc
> -std=gnu11 -c -O2
> -fomit-frame-pointer -D_ATL_XP_TARGETING=1 -D__USE_MINGW_ANSI_STDIO=0
> -Wall -Wextra -Wshadow -Wundef



Where does  -D_ATL_XP_TARGETING=1 come from?

My guess is that this is the problem. It disables Windows 7+ API's

Hope this helps

       Jan Nijtmans

Re: [TCLCORE] Go port

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

Am 19.07.2024 um 13:14 schrieb Jan Mercl:
> Hi list.
> 
> I'm looking for help. I started a Tcl/Tk port for the Go programming
> language. (The C code is transpilled to Go, making cross compilation
> of Go programs using the package easier.) Some things already work,
> many other do not yet. Additionally I'm making
> https://pkg.go.dev/modernc.org/tk8.6, which is something like tkinter
> for Go. It is a work in progress, not even alfa stage yet. I ran into
> https://gitlab.com/cznic/tk8.6/-/issues/1. Unfortunately, my practical
> experiences using Tcl/Tk are almost non existing.
> 
> What I'm looking for is a high-level overview of how the machinery on
> the path from a keyboard keypress to the character getting displayed
> in the entry/ttk::entry widget works in Tcl/Tk. In other words, where
> do I need to look in debugging the issue for checkpoints. So far I was
> able to find the window  manager events handling, I think. Where are
> the [other] X events processed missed me on the initial attempts. I
> can perhaps figure it out by myself, but I guess some guidance can
> save me a lot of time learning what someone else can teach me quickly.
> Or please point me to some existing design document I failed to find.
> 
> I was advised on the Tcl Slack #general channel to ask here.
> 
> Thanks in advance for any hints/tips.

Dear Jan,

great that you do this work. I think, looking at TkInter would be the 
best. We have active people here caring about it. Also, we have Go 
people here, who may comment.

Currently, we are in the redesign process of all extensions to Tcl/Tk 9.
It might be more effective to directly look to TCL/Tk 9.
The interface is different, as sizes changed from int to pntrdiff_t and 
some formerly direct accessible structures now have access functions.

TCL internals is quite tricky, as double ported variables are used, 
which may have two type representations at the same time.

About your Tk question. You are interested in Linux, right?
The outer event system is translated to Tk events by a compatibility 
layer. Widgets like ttk::entry typically only get tk events.
See the bind manual page for a description.

You may first bump any event on the TCL console:
https://wiki.tcl-lang.org/page/Key%2Dpress+names

You may consider to ask on the tcl chat.
https://wiki.tcl-lang.org/page/TkChat

Take care,
Harald

[TCLCORE] Go port

[Jan M. <0x...@gm...>]

Hi list.

I'm looking for help. I started a Tcl/Tk port for the Go programming
language. (The C code is transpilled to Go, making cross compilation
of Go programs using the package easier.) Some things already work,
many other do not yet. Additionally I'm making
https://pkg.go.dev/modernc.org/tk8.6, which is something like tkinter
for Go. It is a work in progress, not even alfa stage yet. I ran into
https://gitlab.com/cznic/tk8.6/-/issues/1. Unfortunately, my practical
experiences using Tcl/Tk are almost non existing.

What I'm looking for is a high-level overview of how the machinery on
the path from a keyboard keypress to the character getting displayed
in the entry/ttk::entry widget works in Tcl/Tk. In other words, where
do I need to look in debugging the issue for checkpoints. So far I was
able to find the window  manager events handling, I think. Where are
the [other] X events processed missed me on the initial attempts. I
can perhaps figure it out by myself, but I guess some guidance can
save me a lot of time learning what someone else can teach me quickly.
Or please point me to some existing design document I failed to find.

I was advised on the Tcl Slack #general channel to ask here.

Thanks in advance for any hints/tips.

-j

Re: [TCLCORE] www.tcl.tk is down

[Arjen M. <Arj...@de...>]

I just tried - it is up again.

Regards,

Arjen

-----Original Message-----
From: Andreas Kupries <and...@gm...>
Sent: Friday, July 19, 2024 9:08 AM
To: Massimo Manghi <mas...@ri...>
Cc: tcl...@li...
Subject: Re: [TCLCORE] http://www.tcl.tk/ is down

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment.


> still not working here, same error

Please try again.

Logging into the machine I found that the web server was not running.
I restarted it now.

>   -- M

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






_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [TCLCORE] www.tcl.tk is down

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

> still not working here, same error

Please try again.

Logging into the machine I found that the web server was not running.
I restarted it now.

>   -- M

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

Re: [TCLCORE] Tcl/Tk 9.0b2 RELEASED

[elns <el...@xs...>]

And here are a few warnings when natively compiling Tk9.0b2 for x86_64-linux:

<snip>

gcc -c -I/usr/local/src/SOURCES/tk9.0b2/unix/../unix 
-I/usr/local/src/SOURCES/tk9.0b2/unix/../generic -I/usr/local/src/SOURCES/tk9.0b2/unix/../bitmaps 
-O3  -pipe -m64 -finput-charset=UTF-8  -Wall -Wextra -Wshadow -Wundef -Wwrite-strings 
-Wpointer-arith -Wc++-compat -fextended-identifiers -fPIC -fno-common -DBUILD_tk 
-I/usr/local/src/SOURCES/tcl9.0b2/generic -I/usr/local/src/SOURCES/tcl9.0b2/unix 
-DPACKAGE_NAME=\"tk\" -DPACKAGE_TARNAME=\"tk\" -DPACKAGE_VERSION=\"9.0\" -DPACKAGE_STRING=\"tk\ 
9.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DTCL_CFGVAL_ENCODING=\"utf-8\" -DSTDC_HEADERS=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DMODULE_SCOPE=extern\ 
__attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DHAVE_HIDDEN=1 -DTCL_CFG_DO64BIT=1 
-DHAVE_CAST_TO_UNION=1 -DHAVE_STDBOOL_H=1 -DHAVE_VFORK=1 -DHAVE_POSIX_SPAWNP=1 
-DHAVE_POSIX_SPAWN_FILE_ACTIONS_ADDDUP2=1 -DHAVE_POSIX_SPAWNATTR_SETFLAGS=1 -DTCL_SHLIB_EXT=\".so\" 
-DNDEBUG=1 -DTCL_CFG_OPTIMIZED=1 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_IS_LONG=1 
-DHAVE_SYS_TIME_H=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DHAVE_PW_GECOS=1 -DHAVE_LIBXFT=1 
-DHAVE_XFT=1 -DZIPFS_BUILD=1      -DTCL_UTF_MAX=4  -DUSE_TCL_STUBS 
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c: In function ‘TkPostscriptImage’:
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1196:37: warning: ‘cdata.blue_mask’ may be 
used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetBValue(rgb) ((rgb & cdata->blue_mask) >> cdata->blue_shift)
                                      ^~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1276:20: note: ‘cdata.blue_mask’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1195:37: warning: ‘cdata.green_mask’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetGValue(rgb) ((rgb & cdata->green_mask) >> cdata->green_shift)
                                      ^~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1276:20: note: ‘cdata.green_mask’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1194:37: warning: ‘cdata.red_mask’ may be 
used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetRValue(rgb) ((rgb & cdata->red_mask) >> cdata->red_shift)
                                      ^~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1276:20: note: ‘cdata.red_mask’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1196:50: warning: ‘cdata.blue_shift’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetBValue(rgb) ((rgb & cdata->blue_mask) >> cdata->blue_shift)
                                                   ^~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1276:20: note: ‘cdata.blue_shift’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1194:49: warning: ‘cdata.red_shift’ may be 
used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetRValue(rgb) ((rgb & cdata->red_mask) >> cdata->red_shift)
                                                  ^~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1276:20: note: ‘cdata.red_shift’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1195:51: warning: ‘cdata.green_shift’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetGValue(rgb) ((rgb & cdata->green_mask) >> cdata->green_shift)
                                                    ^~
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkCanvPs.c:1276:20: note: ‘cdata.green_shift’ was 
declared here
      TkColormapData cdata;
                     ^~~~~

<snip>

gcc -c -I/usr/local/src/SOURCES/tk9.0b2/unix/../unix 
-I/usr/local/src/SOURCES/tk9.0b2/unix/../generic -I/usr/local/src/SOURCES/tk9.0b2/unix/../bitmaps 
-O3  -pipe -m64 -finput-charset=UTF-8  -Wall -Wextra -Wshadow -Wundef -Wwrite-strings 
-Wpointer-arith -Wc++-compat -fextended-identifiers -fPIC -fno-common -DBUILD_tk 
-I/usr/local/src/SOURCES/tcl9.0b2/generic -I/usr/local/src/SOURCES/tcl9.0b2/unix 
-DPACKAGE_NAME=\"tk\" -DPACKAGE_TARNAME=\"tk\" -DPACKAGE_VERSION=\"9.0\" -DPACKAGE_STRING=\"tk\ 
9.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DTCL_CFGVAL_ENCODING=\"utf-8\" -DSTDC_HEADERS=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DMODULE_SCOPE=extern\ 
__attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DHAVE_HIDDEN=1 -DTCL_CFG_DO64BIT=1 
-DHAVE_CAST_TO_UNION=1 -DHAVE_STDBOOL_H=1 -DHAVE_VFORK=1 -DHAVE_POSIX_SPAWNP=1 
-DHAVE_POSIX_SPAWN_FILE_ACTIONS_ADDDUP2=1 -DHAVE_POSIX_SPAWNATTR_SETFLAGS=1 -DTCL_SHLIB_EXT=\".so\" 
-DNDEBUG=1 -DTCL_CFG_OPTIMIZED=1 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_IS_LONG=1 
-DHAVE_SYS_TIME_H=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DHAVE_PW_GECOS=1 -DHAVE_LIBXFT=1 
-DHAVE_XFT=1 -DZIPFS_BUILD=1      -DTCL_UTF_MAX=4  -DUSE_TCL_STUBS 
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkTextImage.c
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkTextImage.c: In function ‘EmbImageDisplayProc’:
/usr/local/src/SOURCES/tk9.0b2/unix/../generic/tkTextImage.c:670:5: warning: ‘imageY’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
      Tk_RedrawImage(image, 0, 0, width, height, dst, imageX, imageY);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Regards,
Erik Leunissen.
--

Re: [TCLCORE] www.tcl.tk is down

[Massimo M. <mas...@ri...>]

still not working here, same error

  -- M

On 7/19/24 05:59, Marc Culler wrote:
> If you go to www.tcl.tk <http://www.tcl.tk>, say to read the Tk 
> documentation, you get a message from
> cloudflare.com <http://cloudflare.com> saying that the web server is down:
> 
>     What happened?
> 
>     The web server is not returning a connection. As a result, the web
>     page is not displaying.
> 
> 
> I don't know who is in charge of that server.  Hopefully they subscribe 
> to this list.
> 
> - Marc
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Tcl/Tk 9.0b2 RELEASED

[elns <el...@xs...>]

When invoking a freshly built Tcl9.0b2 on Linux, I get:

 > tclsh9.0
application-specific initialization failed: Can't find a usable init.tcl in the following directories:
      {} /usr/local/lib/tcl9.0 /usr/local/lib/tcl9.0 /usr/lib/tcl9.0 /usr/local/library /usr/library 
/usr/tcl9.0/library /usr/tcl9.0b1/library /tcl9.0b1/library


Indeed, /usr/local/lib/tcl9.0 was not created in the installation process. Surficial inspection 
revealed one  line in Makefile.in, which is different from previous Tcl releases (and somewhat 
suspicious to me). I changed this line to make it equal to the line in the Makefile.in for tcl8.6.14:

--- Makefile.in.orig	2024-04-24 19:48:01.000000000 +0200
+++ Makefile.in	2024-07-19 08:15:40.000000000 +0200
@@ -999,7 +999,7 @@
  # Installation rules
  #--------------------------------------------------------------------------

-INSTALL_BASE_TARGETS = install-binaries $(INSTALL_LIBRARIES) $(INSTALL_MSGS) $(INSTALL_TZDATA)
+INSTALL_BASE_TARGETS = install-binaries install-libraries install-msgs $(INSTALL_TZDATA)
  INSTALL_DOC_TARGETS = install-doc
  INSTALL_PACKAGE_TARGETS = install-packages
  INSTALL_DEV_TARGETS = install-headers

and all went well after another "configure; make; sudo make install".

Note that I'm not saying that my change is the right fix for the issue; maybe it needs to be fixed 
differently. I'm just indicating what I found remarkable at first glance.

Best regards,
Erik Leunissen.
--