Tcl/Tk 9.0b1 RELEASED

[Don Porter]

Tcl/Tk 9.0b1 Release Announcement
January 8, 2024

The Tcl Core Team is pleased to announce the 9.0b1 releases of the Tcl
dynamic language and the Tk graphical interface package. These are the
first beta releases of Tcl 9.0 and Tk 9.0. More details can be found below.

We would like to express our gratitude to all those who submit bug
reports and patches. This information is invaluable in enabling us
to identify and eliminate problems in the core. Such reports can be
submitted here.

https://core.tcl-lang.org/tcl/ticket
https://core.tcl-lang.org/tk/ticket

We ask that you log in (anonymous if you wish) to create tickets.
This deters abuse of the ticketing system:

https://core.tcl-lang.org/tcl/login
https://core.tcl-lang.org/tcl/login

Where to get the new releases:
------------------------------

Tcl/Tk 9.0b1 sources are freely available as open source from the Tcl
SourceForge project's file distribution area:

https://sourceforge.net/projects/tcl/files/

This distribution is source code only. We keep links to some third
parties offering pre-built binaries for various systems here:

https://www.tcl-lang.org/software/tcltk/bindist.html

General Summary
---------------

These are new major versions of both Tcl and Tk. There are new features
to be enjoyed. There are incompatibilities to be considered. The list
of both is long and detailed and not fully included here. We believe many
scripts written for Tcl 8 will run unchanged in Tcl 9. We believe many more
can be modified in small and simple ways to produce a new script that runs
in both Tcl 8 and Tcl 9. We expect that extensions and applications using
the public C APIs of Tcl and Tk will involve more effort, but that it is
still within reasonable reach to produce source code supporting both Tcl 8
and Tcl 9 while both releases remain in widespread use.

These are beta releases. The developers believe the new feature set is
complete enough and the code quality is high enough that it is time for
a larger audience of Tcl/Tk users to give them a try and report back
to the developers what difficulties need resolution before stable
releases of Tcl/Tk 9.0.0.

The experiences of Tcl/Tk 8 users adapting their code to the beta releases
of Tcl/Tk 9 will shape the final interfaces of Tcl/Tk 9.0.0, and will
determine the need for possible Tcl/Tk 8.7 releases that might supply
additional lifecycle and migration support.

It is not recommended to deploy these beta releases directly to mission
critical use without significant testing and review.

Some of the most noteworthy changes:

Tcl 9:

* 64-bit capacity: Data values larger than 2Gb

* Internationalization of text
- Full Unicode range of codepoints
- New encodings: utf-16(le|be), ucs-2(le|be), CESU-8, etc.
- [encoding] options -profile, -failindex manage encoding of I/O.
- [msgcat] supports custom locale search list
- [source] defaults to -encoding utf-8

* Zip filesystems and attached archives.

* Unix notifiers available using epoll() or kqueue()
- relieves limits on file descriptors imposed by legacy select()

* Notable incompatibilities
- Unqualified varnames resolved in current namespace, not global.
- No --disable-threads build option. Always thread-enabled.
- I/O malencoding default response: raise error (-profile strict)
- Windows platform needs Windows 7 or Windows Server 2008 R2 or later
- Ended interpretation of ~ as home directory in pathnames
- Removed the "identity" encoding
- $::tcl_precision no longer controls string generation of doubles
- Removed Tcl 7 legacies: [case], [puts] [read] variant syntaxes
- Removed subcommands [trace variable|vdelete|vinfo]

* Incompatibilities in C public interface
- Many arguments expanded type from int to Tcl_Size
- Ended support for Tcl_ChannelTypeVersion less than 5
- Introduced versioning of the Tcl_ObjType struct
- Removed macros CONST*: Tcl 9 support means dropping Tcl 8.3 support
- Removed routines:
Tcl_Backslash(), Tcl_*VA(), Tcl_*MathFunc*(), Tcl_MakeSafe(),
Tcl_(Save|Restore|Discard|Free)Result(), Tcl_EvalTokens(),
Tcl_(Get|Set)DefaultEncodingDir(),
Tcl_UniCharN(case)cmp(), Tcl_UniCharCaseMatch()

* New commands
- [array default], [array for]
- [coroinject], [coroprobe]
- [clock add weekdays]
- [const], [info const*]
- [dict getdefault]
- [file tempdir], [file home], [file tildeexpand]
- [info commandtype]
- [ledit]
- [lpop]
- [lremove]
- [lseq]
- [package files]
- [string insert], [string is dict]
- [tcl::process]

* New command options
- [regsub ... -command ...]
- [lsearch ... -stride ...]
- [socket ... -nodelay ... -keepalive ...]
- [vwait] controlled by several new options

* Numbers
- 0NNN format is no longer octal interpretation. Use 0oNNN.
- 0dNNNN format to compel decimal interpretation.
- NN_NNN_NNN, underscores in numbers for optional readability
- Functions: isinf() isnan() isnormal() issubnormal() isunordered()
- [fpclassify]
- Function int() no longer truncates to word size

* tcl::oo facilities
- private variable and methods
- [method -export], [method -unexport]

Tk 9:

* Many improvements to use of platform features and conventions.
- Built-in widgets and themes are scaling-aware.
- Improved support of two-finger gestures, where available
- The [tk windowingsystem] "aqua" needs macOS 10.10 or later

* New commands and options
- [tk sysnotify]: access to the OS notifications system
- [tk systray]: access to the OS tray facility
- [tk print]: access to the OS printing facility

* Widget options
- New ttk::progressbar option: -text
- [$frame ... -backgroundimage $img -tile $bool]
- [$menu id], [$menu add|insert ... ?$id? ...]
- [$image get ... -withalpha ...]

* Improved widget appearance
- ttk::notebook with nondefault tab positions

* Images
- Partial SVG support
- Read/write access to photo image metadata

Tcl Improvement Proposals (TIPs)
--------------------------------

Each new user-visible feature in Tcl or Tk should find its origins in
a Tcl Improvement Proposal (TIP). TIPs are published, edited, considered
and voted in public, and should contain valuable information about how
a feature came to be the way it is. See the full collection here:

https://tip.tcl-lang.org/

Additional support resources
----------------------------

See the following links for an accumulation of migration advice:

https://core.tcl-lang.org/tcl/wiki?name=Migrating+C+extensions+to+Tcl+9
https://core.tcl-lang.org/tcl/wiki?name=Migrating+scripts+to+Tcl+9

There has been much progress already porting many known applications,
extensions, and packages in the Tcl world to compatibility with Tcl/Tk 9:

https://wiki.tcl-lang.org/page/Apps+confirmed+to+work+with+Tcl+9
https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9

For additional information:
---------------------------

Please visit the Tcl Developer Xchange web site:

https://www.tcl-lang.org/

This site contains a variety of information about Tcl/Tk in general, the
core Tcl and Tk distributions, Tcl development tools, and much more.

--
Tcl Core Team and Maintainers
Don Porter, Tcl Core Release Manager

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

[Ian]

Don Porter wrote:

>
> Tcl/Tk 9.0b1 Release Announcement
> January 8, 2024

> ...

tkcon defines its own version of lremove, which has completely different
behaviour from the version defined by tcl9.0. This can produce
surprising results for tkcon users.

I have made a compatible version of tkcon by changing all instances of
lremove in its source code to Lremove, so the tcl9 version of lremove
does not get overwritten.

Is there someone who is actively maintaining tkcon?


*********** To reply by e-mail, make w single in address **************

[Harald Oehlmann]

Am 10.01.2024 um 02:54 schrieb Ian:
> Don Porter wrote:
>
>>
>> Tcl/Tk 9.0b1 Release Announcement
>> January 8, 2024
>> ...
>
> tkcon defines its own version of lremove, which has completely different
> behaviour from the version defined by tcl9.0. This can produce
> surprising results for tkcon users.
>
> I have made a compatible version of tkcon by changing all instances of
> lremove in its source code to Lremove, so the tcl9 version of lremove
> does not get overwritten.
>
> Is there someone who is actively maintaining tkcon?

Unfortunately not.

Jeff Hobbs did it and stepped away a decade from now.
We need a place for unmaintained extensions.
Steve Landers and others will care, but current release and holidays
have priority.

You are welcome to fill any gap !

Thank you for the action !
Harald

[tombert]

Pre-compiled binaries are available here: https://gitlab.com/teclabat/tcltk

[Luc]

On Mon, 15 Jan 2024 10:33:01 -0800 (PST), tombert wrote:

>Pre-compiled binaries are available here: https://gitlab.com/teclabat/tcltk

Is your process automated? Can I have a copy of the scripts you use
to make the builds?


--
Luc
>>

[tombert]

> Is your process automated? Can I have a copy of the scripts you use
> to make the builds?

Yes, this process is fully automated including downloading newest sources, compiling Tcl/Tk and its libraries and the CI scripts for gitlab uploading the binaries.
There is some proprietary code in the scripts, so I cannot share them 1:1, but I can give you snapshots if you tell me what you need.

[Harald Oehlmann]

Am 15.01.2024 um 19:33 schrieb tombert:
> Pre-compiled binaries are available here: https://gitlab.com/teclabat/tcltk

Hi Thomas,
great !

Would it be ok to link your binary download
https://gitlab.com/teclabat/tcltk/-/packages
on www.tcl-lang.org ?

I think, those are currently the only ones.

Thank you,
Harald

[Luc]

**************************

Well, I love how you made neat Debian packages that install completely
inside /opt. That is very clean.

But I can't use your packages because I use an old Debian version that
I can't upgrade for a number of personal reasons.

./wish: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found
(required by /opt/tcltk87/lib/libtk8.7.so)

So I would like to have TclTk 8.7 and 8.6.13 and update them often, but
for that I would have to build them myself in my old Debian. I am very
insecure about building though. About 99% of everything I ever tried to
build in my lifetime failed and when that happens I have no clue about
how to fix it. I am C-illiterate.

I'm also very afraid of breaking my current 8.6.6 installation. It's
what I use every day.

Another reason why I don't want to lose that 8.6.6 installation is that
I am developing something for general public consumption and I want my
application to be legacy-aware to some extent, i.e. able to circumvent
problems in old Tcl/Tk (I've actually found a big and important one).
I guess 8.6.6 is a good minimum standard for that.

--
Luc
>>

[Rich]

Building Tcl and Tk is almost trivial. Provided you have installed the
C development packages. Debian is one of the distros that separates
out the files needed to compile against from the files needed to use a
library into different packages, and then does not install the
development side by default. This made sense 25 years ago when one was
shoehorning Linux into a 1-4GB partition on an 8GB total disk, but in
today's world of massive disk sizes it makes no sense, but the practice
continues.

You unpack the tar file, cd into the "unix" directory, run configure
(setting the options for 'where' you want it to install) and then run
make (and wait).

Given that you cause no changes by compiling (only installing causes
changes, and the install can be done as a normal user if the
destination is writable by that normal user) why not try compiling and
see if it works or not for you. If it does, then you can compile, and
install in different directories, as many different Tcl versions as you
wish.

[Luc]

On Tue, 16 Jan 2024 19:10:26 -0000 (UTC), Rich wrote:

>Building Tcl and Tk is almost trivial.

Let me guess. You know C and have successfully compiled a lot of
source code before. The complete opposite of me.

> Provided you have installed the C development packages.

I have the packages. I have successfully been through ./configure
and make with Tcl. I didn't try Tk yet.

>Given that you cause no changes by compiling (only installing causes
>changes

That's when I get stage fright. I'm afraid of running 'make install'.
There are two location parameters. There is --prefix and there is
--exec-prefix. That makes me nervous and upset. Why the hell do both
have to exist? What is the difference? Is --exec-prefix the location
of the executable? But then what is --prefix? Can they be different?
How? Why? Who ever thought this was a good idea? That makes me nervous
for the simple reason that I don't know what I'm doing and I'm aware
of it. I don't know what the consequences of a mistake will be. I don't
know what kind of mess I could make and I obviously wouldn't know how
to clean it up. So I stall. Compiling is cruel. It just assumes that
everybody knows how to do it. So much for "free" software. Unless it
is a binary distribution, there is a virtual moat around it that does
a pretty good job of keeping most people outside. It's like telling
someone, "Hey, swimming is simple. Just jump in the water and move
your arms around" (not even mentioning the legs). To make things worse,
99% of everything I ever tried to build failed with some message that
made as much sense to me as Egyptian hieroglyphs. I have a lot of Post
Failed Compilation Trauma. I just no longer have any faith that the
damn thing will work after so many failures. Tcl seems to compile fine.
I was absolutely awestruck when I saw it compile cleanly. Wow. Tcl
really is a remarkable thing. It even compiles cleanly in my extremely
incompetent hands. That is fantastic. But I'm still too insecure to go
forward.

Have you seen tombert's packages? They are pure Debian packages that
install in their own directory each under /opt. Really nice.

This is why I program in Tcl. My users will have access to the source
script if they want it, but also to a neat single Freewrap executable
that will Just Work™. No building. No stress. Just turn the key and
drive. I don't blame Tcl. I blame the Unix culture.

/me gets down from the soap box down

--
Luc
>>

[Rich]

Luc <l...@sep.invalid> wrote:
> On Tue, 16 Jan 2024 19:10:26 -0000 (UTC), Rich wrote:
>
>>Building Tcl and Tk is almost trivial.
>
> Let me guess. You know C and have successfully compiled a lot of
> source code before. The complete opposite of me.

Know C? Barely. I can write some C, but am by no means an expert.

Compiled a lot? On that yes, I started with Linux circa Kernel 0.88 or
so around 1993-1994, and back then if one didn't compile it, one often
didn't have it, so I learned by doing.

>> Provided you have installed the C development packages.
>
> I have the packages. I have successfully been through ./configure
> and make with Tcl. I didn't try Tk yet.

If Tcl compiles cleanly, then it is very likely Tk will as well.

>>Given that you cause no changes by compiling (only installing causes
>>changes
>
> That's when I get stage fright. I'm afraid of running 'make install'.

Then don't compile as root. Compile as yourself, or given you
'stagefright', setup a completely separate user to compile (and
install) as. If you setup a new user (lets name it 'compile') then you
can't break anything system wide (assuming you've not changed
permissions everywhere to let any user mess with the system) nor can
you break anything as yourself. At most, you break something for that
one user only, and if need be you can delete the user and make a new
one.

> There are two location parameters. There is --prefix and there is
> --exec-prefix. That makes me nervous and upset. Why the hell do both
> have to exist?

Did you look at ./configure --help?

--prefix is where "architecture-independent files" (i.e., those not
tied to a specific CPU) get installed.

--exec-prefix is where "architecture-dependent files" (i.e., those
specific to a particular CPU) get installed

> What is the difference?

Nothing at all, unless you want to put your CPU specific binaries in a
different location from the files that have no dependency on the CPU,
because --exec-prefix defaults to using --prefix unless you provide
another option.

In bygone days, there were more CPU architectures in the world than
just 64-bit Intel CPU's. Someone setting up a shared instal for a
cluster of machines of different architectures might want to put all
the files that are not specific to a particular CPU in one location,
then put the CPU specific files (i.e. MIPS binaries in a mips/ tree,
Sparc binaries in a sparc/ tree, Alpha binaries in an alpha/ tree) and
then NFS mount that to all the machines. They all share the "arch
independent" files (and so only one copy is using up disk space) and a
given machine (say a MIPS workstation) sets up its PATH= to launch the
MIPS binaries and libraries from the mips/ tree.

But, since you won't likely be doing that, you can ignore the
--exec-prefix.

> Is --exec-prefix the location of the executable?

Yes, if you give a value, otherwise it defaults to where --prefix is
set.

> But then what is --prefix?

Non CPU binaries -- i.e., config files, Tcl script files, Tk script
files, Perl files, etc. Anything not tied to a specific CPU
architecture.

> Can they be different?

Yes

> How?

By lauching configure with --prefix and --exec-prefix set to something.
I.e.:

./configure --prefix /home/compile/Tcl --exec-prefix /home/compile/Tcl-MIPS

> Why?

See long paragraphs several lines above.

> Who ever thought this was a good idea?

Those who wanted their installation to allow them to separate the CPU
binaries apart from the non-binaries for space savings or for
supporting plural CPU architectures in a small networked cluster.

> That makes me nervous for the simple reason that I don't know what
> I'm doing and I'm aware of it. I don't know what the consequences of
> a mistake will be.

Then create a brand new user, and "do it" as the new user. Worst case,
things dont work and you can delete the new user and its home directory
to cleanup and remake the user to try again in a different way.

> I don't know what kind of mess I could make and I obviously wouldn't
> know how to clean it up.

If you experiment as an independent user on the system, the most you
can mess up is that new independent user. That's rather the point of
having a "multi-user operating system". Each user is isolated from the
others (unless they decide to 'share') and is isolated from harming
"the system" as well.

> So I stall. Compiling is cruel. It just assumes that everybody
> knows how to do it. So much for "free" software. Unless it is a
> binary distribution, there is a virtual moat around it that does a
> pretty good job of keeping most people outside. It's like telling
> someone, "Hey, swimming is simple. Just jump in the water and move
> your arms around" (not even mentioning the legs). To make things
> worse, 99% of everything I ever tried to build failed with some
> message that made as much sense to me as Egyptian hieroglyphs.

At the same time, if you never try, esp. in a safe environment, you
won't ever learn to interpret what looks like hieroglyphs to you at the
moment.

> Tcl seems to compile fine. I was absolutely awestruck when I saw it
> compile cleanly. Wow. Tcl really is a remarkable thing. It even
> compiles cleanly in my extremely incompetent hands. That is
> fantastic. But I'm still too insecure to go forward.

Setup a brand new user, and try both compiling, and installing, as that
new user (hint, make --prefix point to a place in that new user's home
dir).

> Have you seen tombert's packages? They are pure Debian packages that
> install in their own directory each under /opt. Really nice.

And most likely created by automating something that resembles this:

./configure --prefix=/opt/tcl-8.6.13/
make
make install
./configure --prefix=/opt/tcl-8.7.02/
make
make install

And so on.

[Luc]

OK, here we go. Tcl compiled, but Tk didn't.


$ make
gcc -c -I/home/tcl/source/tk8613-src/tk8.6.13/unix/../unix -I/home/tcl/source/tk8613-src/tk8.6.13/unix/../generic -I/home/tcl/source/tk8613-src/tk8.6.13/unix/../bitmaps -O2
-pipe -m64 -Wall -Wpointer-arith -fPIC -DBUILD_tk
-I/home/tcl/source/tcl8613-src/tcl8.6.13/generic
-I/home/tcl/source/tcl8613-src/tcl8.6.13/unix -DPACKAGE_NAME=\"tk\"
-DPACKAGE_TARNAME=\"tk\" -DPACKAGE_VERSION=\"8.6\" -DPACKAGE_STRING=\"tk\
8.6\" -DPACKAGE_BUGREPORT=\"\" -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
-DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1
-DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_PTHREAD_ATFORK=1 -DTCL_THREADS=1
-DSTATIC_BUILD=1 -DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DHAVE_HIDDEN=1
-DTCL_CFG_DO64BIT=1 -DHAVE_CAST_TO_UNION=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 -DTIME_WITH_SYS_TIME=1
-DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DHAVE_PW_GECOS=1
-DXKEYCODETOKEYSYM_IS_DEPRECATED=1
-fno-lto /home/tcl/source/tk8613-src/tk8.6.13/unix/../generic/tkStubLib.c
In file included
from /home/tcl/source/tk8613-src/tk8.6.13/unix/../generic/tkPort.h:21:0,
from /home/tcl/source/tk8613-src/tk8.6.13/unix/../generic/tkInt.h:19,
from /home/tcl/source/tk8613-src/tk8.6.13/unix/../generic/tkStubLib.c:14: /home/tcl/source/tk8613-src/tk8.6.13/unix/../generic/tk.h:99:25:
fatal error: X11/Xlib.h: No such file or directory # include <X11/Xlib.h>
^ compilation terminated. Makefile:1168: recipe for target 'tkStubLib.o'
failed make: *** [tkStubLib.o] Error 1


$ cd /home/tcl/source
$ find . -type f -iname 'Xlib.h' -print
./tk8613-src/tk8.6.13/xlib/X11/Xlib.h

--
Luc
>>

[Rich]

When you compiled Tcl, did you install it into a custom directory?

When you "configured" Tk, did you use the --with-tcl= option to point
it at the newly compiled Tcl?

Also, "#include <X11/Xlib.h>" is referring to your system X11/Xlib.h,
so the error implies you do not yet have all of the X development
packages installed.

[tombert]

Which OS would you need to compile on?

[Luc]

On Wed, 17 Jan 2024 05:03:19 -0000 (UTC), Rich wrote:

>When you "configured" Tk, did you use the --with-tcl= option to point
>it at the newly compiled Tcl?

I used --with-tcl= pointing to where Tcl was compiled. I followed this:

> then for tk, you need to add the option --with-tcl so it can find the one you just built
> ./configure --prefix=/path/to/place/build --with-tcl=/path/to.../unix
> pointing to where the unix directory is that you did the tcl build from

It was sent by et99 in December.

>Also, "#include <X11/Xlib.h>" is referring to your system X11/Xlib.h,
>so the error implies you do not yet have all of the X development
>packages installed.

That is libx11-dev in Debian. But I can't install it. GDebi says:

Error: Dependency is not satisfiable: libx11-6 (=2:1.6.4-3+deb9u1)

I already have 2:1.6.4-3+deb9u4, it's newer, but not acceptable.

I have managed to find libx11-6-udeb_1.6.4-3+deb9u1_amd64.udeb.
But GDebi tells me I can't install it either:

Error: Dependency is not satisfiable: libc6-udeb (>=2.24)

I found that too. But that's not enough. Now I need libx11-6-udeb.

I found it. Not enough. Now it wants libxcb1-udeb. Which of course
cannot be installed because it needs libxau6-udeb.

I found that too, but you know the drill. Now it wants libxdmcp6-udeb.
A 7.7kb file! I cannot proceed because of a 7.7kb file.

But I found it! But nooooo! It's not enough nooooo! It can't exist
without libbsd0-udeb!

And I found that too, but this whole thing is extremely carefully
designed to break:

dpkg: error processing archive libbsd0-udeb_0.8.3-1_amd64.udeb (--install):
trying to overwrite '/lib/x86_64-linux-gnu/libbsd.so.0.8.3', which is also in package libbsd0:amd64 0.8.3-1+deb9u1
Errors were encountered while processing:
libbsd0-udeb_0.8.3-1_amd64.udeb

So I already have it?

So I already have it.

But I can't install some package that requires it and without that
package I can't install the other package that is required by the
other package that is required by the other package that is required
by the compilation source.

I can't find words to describe how utterly stupid I think this is.
This is why I hate building from source.


--
Luc
>>

[Rich]

Luc <l...@sep.invalid> wrote:
> On Wed, 17 Jan 2024 05:03:19 -0000 (UTC), Rich wrote:
>
>>When you "configured" Tk, did you use the --with-tcl= option to point
>>it at the newly compiled Tcl?
>
> I used --with-tcl= pointing to where Tcl was compiled. I followed this:
>
>> then for tk, you need to add the option --with-tcl so it can find the one you just built
>> ./configure --prefix=/path/to/place/build --with-tcl=/path/to.../unix
>> pointing to where the unix directory is that you did the tcl build from
>
> It was sent by et99 in December.
>
>
>>Also, "#include <X11/Xlib.h>" is referring to your system X11/Xlib.h,
>>so the error implies you do not yet have all of the X development
>>packages installed.
>
>
> That is libx11-dev in Debian. But I can't install it. GDebi says:
>
> Error: Dependency is not satisfiable: libx11-6 (=2:1.6.4-3+deb9u1)
>

> [long chain of serial dependencies snipped]

>
> But I found it! But nooooo! It's not enough nooooo! It can't exist
> without libbsd0-udeb!
>
> And I found that too, but this whole thing is extremely carefully
> designed to break:

IIRC, one of the whole "value adds" to debian and their package system
was automatic handling of these kinds of dependencies (both this serial
one, and the just as bad "fan out" one where package X needs Y and Z
and Y and Z each need A B C and D E F). So it does not make any sense
that you have to go and chase the dependencies yourself when the deb
package manager is supposed to handle that for you.

As I don't use debian (Slackware here) I can't offer any advice on what
might be wrong of how you might fix it (other than the usual 'obvious'
one, of maybe doing a clean re-install).

> I can't find words to describe how utterly stupid I think this is.
> This is why I hate building from source.

Well, the dependencies are real. The fact that the packagers like to
"finely dice" everything up, creating even greater webs of
interdependent stuff is what makes this a terrible experience when
something goes wrong. But if your package manager had done what it was
supposed to have done, simply upgrading/installing the one missing item
should have caused it to find, and ask "you also need this: XXXXX",
you'd answer yes, and it would go on about updating/installing all the
web of dependencies necessary.

[Luc]

On Wed, 17 Jan 2024 16:00:39 -0000 (UTC), Rich wrote:

>IIRC, one of the whole "value adds" to debian and their package system
>was automatic handling of these kinds of dependencies (both this serial
>one, and the just as bad "fan out" one where package X needs Y and Z
>and Y and Z each need A B C and D E F). So it does not make any sense
>that you have to go and chase the dependencies yourself when the deb
>package manager is supposed to handle that for you.
>
>As I don't use debian (Slackware here) I can't offer any advice on what
>might be wrong of how you might fix it (other than the usual 'obvious'
>one, of maybe doing a clean re-install).
>
>> I can't find words to describe how utterly stupid I think this is.
>> This is why I hate building from source.
>
>Well, the dependencies are real. The fact that the packagers like to
>"finely dice" everything up, creating even greater webs of
>interdependent stuff is what makes this a terrible experience when
>something goes wrong. But if your package manager had done what it was
>supposed to have done, simply upgrading/installing the one missing item
>should have caused it to find, and ask "you also need this: XXXXX",
>you'd answer yes, and it would go on about updating/installing all the
>web of dependencies necessary.

**************************

I use an old version. The package manager won't handle it anymore in
many cases. Sometimes it still does, it doesn't in this case.

No, I will not upgrade. They "deprecate" or no longer package stuff I
still want, they don't care about the users, so I will not upgrade in
the forseeable future.

I also need a separate hard disk for a migration so I can carefully copy
all my customizations over. Linux is almost useless to me without my
customizations. I can't afford a new hard disk. I can barely afford food
right now.


--
Luc
>>

[tombert]

> I use an old version. The package manager won't handle it anymore in
> many cases. Sometimes it still does, it doesn't in this case.

I am asking again: What OS are you using?

[Luc]

I've made a little progress. Just not quite there yet.

I ran sed recursively across the entire source directory and replaced
all references to X11/* with references to the source's own xlib/X11
directory.

It was tricky because I had to tackle three different formats:
#include <X11/*
#include "<X11/*
#include "X11/*

But I think it worked. The first errors disappeared.

But it complained about the lack of Xproto.h. I brought it in from my
own /usr/include/X11 directory and it worked.

Then it complained about the lack of Xresources.h. I had to download
that one from Ubuntu. It was the one I could find.

Then it seemed to work, printing out a lot of output, then it halted
here:

-Lhome/tcl/source/tk8613-src/tk8.6.13/unix -ltcl8.6 -lpthread -lX11 -ldl -lz -lpthread -lm "-Wl,-rpath,/opt/tcltk8613/lib" -o wish
/usr/bin/ld: cannot find -lX11
collect2: error: ld returned 1 exit status
Makefile:624: recipe for target 'wish' failed
make: *** [wish] Error 1


Questions:

1. Is there any trick I can try to overcome this specific hurdle?

2. Is it reasonable to file a "feature request" (I guess it doesn't
qualify as a bug) to include Xproto.h and Xresources.h in the source
distribution AND have the build scripts point to itself instead of the
system-wide corresponding files, at least with some --parameter?


--
Luc
>>

[Luc]

**************************

I'm sorry. I forgot to get back to you.

I have Debian 9, aka Stretch.

--
Luc
>>

[Rich]

Luc <l...@sep.invalid> wrote:
> On Wed, 17 Jan 2024 16:00:39 -0000 (UTC), Rich wrote:
>
>>IIRC, one of the whole "value adds" to debian and their package system
>>was automatic handling of these kinds of dependencies (both this serial
>>one, and the just as bad "fan out" one where package X needs Y and Z
>>and Y and Z each need A B C and D E F). So it does not make any sense
>>that you have to go and chase the dependencies yourself when the deb
>>package manager is supposed to handle that for you.
>>
>>As I don't use debian (Slackware here) I can't offer any advice on what
>>might be wrong of how you might fix it (other than the usual 'obvious'
>>one, of maybe doing a clean re-install).
>>
>>> I can't find words to describe how utterly stupid I think this is.
>>> This is why I hate building from source.
>>
>>Well, the dependencies are real. The fact that the packagers like to
>>"finely dice" everything up, creating even greater webs of
>>interdependent stuff is what makes this a terrible experience when
>>something goes wrong. But if your package manager had done what it was
>>supposed to have done, simply upgrading/installing the one missing item
>>should have caused it to find, and ask "you also need this: XXXXX",
>>you'd answer yes, and it would go on about updating/installing all the
>>web of dependencies necessary.
> **************************
>
> I use an old version. The package manager won't handle it anymore in
> many cases. Sometimes it still does, it doesn't in this case.

Ah, that explains why it didn't just "auto-find" the necessary items.

> No, I will not upgrade. They "deprecate" or no longer package stuff I
> still want, they don't care about the users, so I will not upgrade in
> the forseeable future.

Understood. I've got two older installs myself, although in my case
the lack of 'uping' them is more to do with lack of time to go through
the upgrade process.

But also keep in mind that by keeping the old version around, that some
(if not a majority) of your issues are also "self imposed".

> I also need a separate hard disk for a migration so I can carefully
> copy all my customizations over. Linux is almost useless to me
> without my customizations. I can't afford a new hard disk. I can
> barely afford food right now.

Also a fair assessment. Food obviously ranks higher in the priority
speectrum than "new disk for upgrading installation".

Note that if you at some point do get a new disk and go through an
upgrade, that you can also keep "old distributions" running inside of a
virtual machine (i.e., VirtualBox) and can keep your host (the system
running the VM's) updated while also still having the "old things that
have been abandoned" still running in an environment they work within.

[Rich]

Luc <l...@sep.invalid> wrote:
> I've made a little progress. Just not quite there yet.
>
> I ran sed recursively across the entire source directory and replaced
> all references to X11/* with references to the source's own xlib/X11
> directory.
>
> It was tricky because I had to tackle three different formats:
> #include <X11/*

> #include "<X11/*

Did you really find this one? That ought to be a syntax error.

> #include "X11/*
>
> But I think it worked. The first errors disappeared.
>
> But it complained about the lack of Xproto.h. I brought it in from my
> own /usr/include/X11 directory and it worked.
>
> Then it complained about the lack of Xresources.h. I had to download
> that one from Ubuntu. It was the one I could find.
>
> Then it seemed to work, printing out a lot of output, then it halted
> here:
>
> -Lhome/tcl/source/tk8613-src/tk8.6.13/unix -ltcl8.6 -lpthread -lX11 -ldl -lz -lpthread -lm "-Wl,-rpath,/opt/tcltk8613/lib" -o wish
> /usr/bin/ld: cannot find -lX11
> collect2: error: ld returned 1 exit status
> Makefile:624: recipe for target 'wish' failed
> make: *** [wish] Error 1
>
>
> Questions:
>
> 1. Is there any trick I can try to overcome this specific hurdle?

It can't find libX11* to link against. So either your X11 library
files are in an unexpected location (possible given the old distro) or
you don't have a libX11 (unlikely, as without it you would not be
running X programs). So most likely you need to add another -L to the
link command line above pointing at the location of your libX11 files.

Mine here (Slackware 15) are at:

0 lrwxrwxrwx 1 root 15 Oct 9 11:26 /usr/lib64/libX11.so -> libX11.so.6.4.0*
0 lrwxrwxrwx 1 root 15 Oct 9 11:26 /usr/lib64/libX11.so.6 -> libX11.so.6.4.0*
1280 -rwxr-xr-x 1 root 1310240 Oct 3 15:39 /usr/lib64/libX11.so.6.4.0*

When you do find it, edit the makefile and look for the line that
includes those -lpthread -lX11 -ldl -lz options, and add a
"-L/path/to/X11" before (prior to) the -lX11 option. Note that
"/path/to/X11" will be the path to where the libX11 files sit on your
machine.

> 2. Is it reasonable to file a "feature request" (I guess it doesn't
> qualify as a bug) to include Xproto.h and Xresources.h in the source
> distribution AND have the build scripts point to itself instead of the
> system-wide corresponding files, at least with some --parameter?

I'd say no, because given a proper build environment, they will be
available in the expected system locations (and be the proper ones for
the local system). Your Deb-9 system has diverged enough from "proper
build environment" that I'd say such a change is unlikely to be
included.

[Luc]

On Wed, 17 Jan 2024 19:55:57 -0000 (UTC), Rich wrote:

>> It was tricky because I had to tackle three different formats:
>> #include <X11/*
>
>> #include "<X11/*
>
>Did you really find this one? That ought to be a syntax error.

I just searched a clean copy of the source and didn't find it so it has
to be my mistake. I just remember I had to do it three times. I forget
what the third one was. Sorry.

--
Luc
>>

[Alexandru]

I'm using "image create photo $imgname -file $imgfile" to create images from SVG files.
Currently the "text" element is not supported.
Will this be supported in Tcl/Tk 9.0b?

Thanks
Alexandru

[rene]

No, but you can convert the text in the svg to lines p.e. with inkcsape.

HTH
rene

[Alexandru]

Thanks, but I writting an app in Tcl/Tk, that creates an SVG file and then displays that in a label.
The img parser fails currently also at oher SVG elements (path is also not supported).