From Newsgroup: comp.lang.tcl

Following my recent query about reference counting (thanks again for the responses), I feel that I should have access to the 'memory' command,
which I see means that I need to define TCL_MEM_DEBUG at compile time.
That immediately raises two questions:

i) Exactly how do I do that?

I expect that I need to specify something when I run configure.
Maybe something like

configure --define=TCL_MEM_DEBUG --prefix=<wherever>

but I can't find what exactly.

ii) Will I need to recompile all the binary extensions I use?

If not, I plan to build and install Tcl with the symbol defined,
rename tclsh9.1 to tclsh-mem9.1 with a tclsh-mem softlink pointing
to it, then re-install a "standard" Tcl in the same directory with a
tclsh softlink. This would let me do tclsh to run a "standard" shell
and tclsh-mem to run a shell that supports 'memory'.

If I would need to recompile the binary extensions, then I guess I
need two parallel directories. I suppose I can get away with putting
the tclsh-mem softlink in the "standard" directory and only have a
single entry in PATH.


Many thanks


Alan
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 15.10.2026 um 20:30 schrieb Alan Grunwald:

Following my recent query about reference counting (thanks again for the responses), I feel that I should have access to the 'memory' command,
which I see means that I need to define TCL_MEM_DEBUG at compile time.
That immediately raises two questions:

i) Exactly how do I do that?

    I expect that I need to specify something when I run configure.
    Maybe something like

          configure --define=TCL_MEM_DEBUG --prefix=<wherever>

    but I can't find what exactly.

ii) Will I need to recompile all the binary extensions I use?

    If not, I plan to build and install Tcl with the symbol defined,
    rename tclsh9.1 to tclsh-mem9.1 with a tclsh-mem softlink pointing
    to it, then re-install a "standard" Tcl in the same directory with a
    tclsh softlink. This would let me do tclsh to run a "standard" shell
    and tclsh-mem to run a shell that supports 'memory'.

    If I would need to recompile the binary extensions, then I guess I
    need two parallel directories. I suppose I can get away with putting
    the tclsh-mem softlink in the "standard" directory and only have a
    single entry in PATH.

Many thanks

Alan

Yes, aparently, it is an official feature:

https://www.tcl-lang.org/man/tcl9.1/TclLib/TCL_MEM_DEBUG.html

On MS-Win, the head of the make file has comment how to use it (opts=MEM_DEBUG).

But the file unix\README contains the information:
How I understand it:
--enable-symbols=mem

But the instructions are unclear to me.
Room for improvement on the man page and help files...

Sorry,
Harald
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On Unix/MinGW

configure --enable-symbols=mem ....

With nmake,

nmake /f makefile.vc STATS=memdbg ....



On 10/16/2026 12:00 AM, Alan Grunwald wrote:

Following my recent query about reference counting (thanks again for the responses), I feel that I should have access to the 'memory' command,
which I see means that I need to define TCL_MEM_DEBUG at compile time.
That immediately raises two questions:

i) Exactly how do I do that?

    I expect that I need to specify something when I run configure.
    Maybe something like

          configure --define=TCL_MEM_DEBUG --prefix=<wherever>

    but I can't find what exactly.

ii) Will I need to recompile all the binary extensions I use?

    If not, I plan to build and install Tcl with the symbol defined,
    rename tclsh9.1 to tclsh-mem9.1 with a tclsh-mem softlink pointing
    to it, then re-install a "standard" Tcl in the same directory with a
    tclsh softlink. This would let me do tclsh to run a "standard" shell
    and tclsh-mem to run a shell that supports 'memory'.

    If I would need to recompile the binary extensions, then I guess I
    need two parallel directories. I suppose I can get away with putting
    the tclsh-mem softlink in the "standard" directory and only have a
    single entry in PATH.

Many thanks

Alan

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

BTW, I am not sure whether compiling Tcl with memory debugging enabled requires any loaded extensions to also have been compiled the same way. Probably safer to do so.

On 10/16/2026 12:00 AM, Alan Grunwald wrote:

Following my recent query about reference counting (thanks again for the responses), I feel that I should have access to the 'memory' command,
which I see means that I need to define TCL_MEM_DEBUG at compile time.
That immediately raises two questions:

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 16/10/2026 08:47, Harald Oehlmann wrote:

Am 15.10.2026 um 20:30 schrieb Alan Grunwald:

Following my recent query about reference counting (thanks again for
the responses), I feel that I should have access to the 'memory'
command, which I see means that I need to define TCL_MEM_DEBUG at
compile time. That immediately raises two questions:

i) Exactly how do I do that?

     I expect that I need to specify something when I run configure.
     Maybe something like

           configure --define=TCL_MEM_DEBUG --prefix=<wherever>

     but I can't find what exactly.

ii) Will I need to recompile all the binary extensions I use?

     If not, I plan to build and install Tcl with the symbol defined,
     rename tclsh9.1 to tclsh-mem9.1 with a tclsh-mem softlink pointing >>      to it, then re-install a "standard" Tcl in the same directory with a
     tclsh softlink. This would let me do tclsh to run a "standard" shell
     and tclsh-mem to run a shell that supports 'memory'.

     If I would need to recompile the binary extensions, then I guess I >>      need two parallel directories. I suppose I can get away with putting
     the tclsh-mem softlink in the "standard" directory and only have a >>      single entry in PATH.


Many thanks


Alan

Yes, aparently, it is an official feature:

https://www.tcl-lang.org/man/tcl9.1/TclLib/TCL_MEM_DEBUG.html

On MS-Win, the head of the make file has comment how to use it (opts=MEM_DEBUG).

But the file unix\README contains the information:
How I understand it:
--enable-symbols=mem

But the instructions are unclear to me.
Room for improvement on the man page and help files...

Sorry,
Harald

Thanks Harald, I'll give it a go.

The README file is fairly good actually; like everything it could be
improved but it's actually quite serviceable. (My problem was simply
that as I was expecting a "--with" flag, I didn't look properly at the "--enable" flags.)


Alan
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 16/10/2026 13:04, Ashok wrote:

On Unix/MinGW

configure --enable-symbols=mem ....

With nmake,

nmake /f makefile.vc STATS=memdbg ....

On 10/16/2026 12:00 AM, Alan Grunwald wrote:

Following my recent query about reference counting (thanks again for
the responses), I feel that I should have access to the 'memory'
command, which I see means that I need to define TCL_MEM_DEBUG at
compile time. That immediately raises two questions:

i) Exactly how do I do that?

     I expect that I need to specify something when I run configure.
     Maybe something like

           configure --define=TCL_MEM_DEBUG --prefix=<wherever>

     but I can't find what exactly.

ii) Will I need to recompile all the binary extensions I use?

     If not, I plan to build and install Tcl with the symbol defined,
     rename tclsh9.1 to tclsh-mem9.1 with a tclsh-mem softlink pointing >>      to it, then re-install a "standard" Tcl in the same directory with a
     tclsh softlink. This would let me do tclsh to run a "standard" shell
     and tclsh-mem to run a shell that supports 'memory'.

     If I would need to recompile the binary extensions, then I guess I >>      need two parallel directories. I suppose I can get away with putting
     the tclsh-mem softlink in the "standard" directory and only have a >>      single entry in PATH.


Many thanks


Alan

Thanks Ashok.

tl;dr

For your info, after MANY years of asking how to compile Tcl on windows
- I managed the feat once a few years ago but never managed to repeat it
again without help - the hard disk on may desktop packed up a few months
back.

Dell weren't that interested in supplying a replacement 1TB disk - the smallest that appears on their site is 16TB and cost more than the
entire machine. I went out and bought something online for a very
reasonable price, but something went wrong when I was trying to
re-install Windows and after a week of to-and-fro, Dell decided that my
best bet was to let them have the machine for a month or so. at that
point I decided to put Linux on the desktop as well as the laptop and,
to be honest, I haven't looked back since.

Thanks anyway for the nmake instructions, particularly on behalf of any Windows users who stumble upon this question in the future.


Alan
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 16/10/2026 13:06, Ashok wrote:

BTW, I am not sure whether compiling Tcl with memory debugging enabled requires any loaded extensions to also have been compiled the same way. Probably safer to do so.

I agree it would be safer.


FWIW, I'm intending only to use the memory-enabled shell to
exercise/debug my homebrew extension and I'm fairly sure that none of
the scripts that I'm using it with rely on any other binary extensions.
I'm planning to see what happens when I run my extension without
rebuilding it[*]. If I don't come back here to report otherwise, you can assume that I had no problems.


Alan

[*] Come to think of it, I rather think I _will_ have to recompile my extension to be sure that my own calls to the framework use the
TCL_MEM_DEBUG versions of things. Watch this space!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Alan,

There are much better ways to do this today.

I just built an extension for Tcl 9.1 with Claude, and the testing it did was incredible: 500+ tests, 220 mutations, and checks with valgrind, gcov and more. Claude works in a Linux sandbox that has Tcl 8.6 installed, and it can download the latest 9.1 trunk and build it, so it doesn't matter that my extension only runs on 9.1 that has the abstract list feature.

To try the same on your extension:

1. Download the zip from https://github.com/rocketship88/tcl-bit-array-extension
2. Drag the whole zip into a new Claude chat. It contains a claude.md file written for a fresh Claude with no memory of my sessions, so it explains what was built and how the testing was done.
3. Then say: "Claude, look at this and do the same kinds of tests for my extension."
4. Paste in your extension source, or drag the files into the window.

Since you're debugging with TCL_MEM_DEBUG, you could also ask it to build Tcl with memory debugging enabled and recompile your extension against that build.

A few notes:
- Claude needs code execution and file creation turned on in Settings to use the sandbox.
- If Claude doesn't pick up claude.md on its own, add "start by reading claude.md" to the prompt in step 3.
- I pay $20/month so I never get cut off mid-session, but I don't think you need a paid tier to try this.
- The zip also contains dozens of the test scripts it wrote. If you want to see what it can do, ask it to run the stepper in a side panel.

Regards,

Eric


On 10/16/2026 9:54 AM, Alan Grunwald wrote:

On 16/10/2026 13:06, Ashok wrote:

BTW, I am not sure whether compiling Tcl with memory debugging enabled requires any loaded extensions to also have been compiled the same way. Probably safer to do so.

I agree it would be safer.

FWIW, I'm intending only to use the memory-enabled shell to exercise/debug my homebrew extension and I'm fairly sure that none of the scripts that I'm using it with rely on any other binary extensions. I'm planning to see what happens when I run my extension without rebuilding it[*]. If I don't come back here to report otherwise, you can assume that I had no problems.

Alan

[*] Come to think of it, I rather think I _will_ have to recompile my extension to be sure that my own calls to the framework use the TCL_MEM_DEBUG versions of things. Watch this space!

--- Synchronet 3.22a-Linux NewsLink 1.2