lremove in tcl 8.6

[pd]

I'm using tcl/tk 8.6 , reading documentation in https://www.tcl.tk/man/tcl8.6/TclCmd/contents.htm I see there's no lremove command, being a command in tcl 8.7 according to https://www.tcl.tk/man/tcl8.7/TclCmd/lremove.htm

But using tkcon 2.7 when I try to use lremove I got the following:

% lremove "a b c d" b
a c d

So it seems there's a lremove command in 8.6 after all but it works differently, in 8.6 you pass the item to remove as second parameter while in 8.7 you pass the index of the item to remove as second parameter

My question is how is it possible to have a lremove in 8.6 (being not documented) and with a different signature than the 8.7 documented?

[tedbr...@gmail.com]

On Tuesday, February 11, 2020 at 6:51:32 PM UTC-8, pd wrote:

> But using tkcon 2.7 when I try to use lremove I got the following:
>
> % lremove "a b c d" b
> a c d

I have a file that says tkcon 2.7 at the top and
if I run a 8.6.9 tclkit then AFTER I source tkcon.tcl, there's a
few new procs and commands, and lremove is one of them.

Looking at tkcon.tcl, sure enough there's a proc for lremove.

We must have got the same file from somewhere.

[pd]

>
> I have a file that says tkcon 2.7 at the top and
> if I run a 8.6.9 tclkit then AFTER I source tkcon.tcl, there's a
> few new procs and commands, and lremove is one of them.
>
> Looking at tkcon.tcl, sure enough there's a proc for lremove.
>
> We must have got the same file from somewhere.

Yes, I've checked it and I have a lremove proc, is there any way to know how it gets loaded? what file or package is loading it?

info loaded doesn't get so much info

greets

[Rich]

Look in the tkcon source files, somewhere in there is where it gets
defined.

Here is the tkcon docs listing all the extra procs tkcon provides:

http://tkcon.sourceforge.net/docs/procs.html

[heinrichmartin]

On Wednesday, February 12, 2020 at 9:59:26 PM UTC+1, pd wrote:
> Yes, I've checked it and I have a lremove proc, is there any way to know how it gets loaded? what file or package is loading it?

While this seems resolved for lremove (and because Tcl is cool), you can rewrite [proc]. For an even more general approach, note that lremove could also be an ensemble or an alias. But for now let's assume you are really looking at a proc, i.e. it is listed by [info procs].

Before loading any other code, inject this hack:

# untested
rename proc proc_native
proc_native proc {name arglist body} {
if {$name in {lremove}} {
return -code error "$name is defined as {[info level 0]}, see the stack trace."
# if the caller catches this, this is another option
puts stderr "some message"
exit 1
}
uplevel 1 [list proc_native $name $arglist $body]
}

[tedbr...@gmail.com]

On Thursday, February 13, 2020 at 1:01:41 AM UTC-8, heinrichmartin wrote:>

>While this seems resolved for lremove (and because Tcl is cool)

Here's another cool tcl feature (which I learned here) for all procs:

proc tracer {args} {
puts "proc def for: [lindex $args 0 1]"
for {set n 1} {$n < 6} {incr n} {
catch {
set dict [info frame $n]
puts " $n) line [format %5s [dict get $dict line]] in [dict get $dict file] "
}
}
}

trace add execution proc enter tracer

[pd]

El miércoles, 12 de febrero de 2020, 22:24:50 (UTC+1), Rich escribió:

> Look in the tkcon source files, somewhere in there is where it gets
> defined.
>
> Here is the tkcon docs listing all the extra procs tkcon provides:
>
> http://tkcon.sourceforge.net/docs/procs.html

Thanks for your info

For some reason I was expecting all these features were loaded through a package or similar, now I see it's just the source code in tkcon itself

[pd]

El jueves, 13 de febrero de 2020, 10:01:41 (UTC+1), heinrichmartin escribió:

> While this seems resolved for lremove (and because Tcl is cool), you can rewrite [proc]. For an even more general approach, note that lremove could also be an ensemble or an alias. But for now let's assume you are really looking at a proc, i.e. it is listed by [info procs].

it's a proc, I've already checked it with [info procs] ;-)

> Before loading any other code, inject this hack:
>
> # untested
> rename proc proc_native
> proc_native proc {name arglist body} {
> if {$name in {lremove}} {
> return -code error "$name is defined as {[info level 0]}, see the stack trace."
> # if the caller catches this, this is another option
> puts stderr "some message"
> exit 1
> }
> uplevel 1 [list proc_native $name $arglist $body]
> }

that's a nice trick but not applicable to this problem because tkcon already has all extension procs and aliases defined when it starts so there's no point in time to inject that proc redefinition code before loading any other code. Anyway I write down the trick for future use...

[pd]

I don't really understand how this works and how it is expected to be used, may you explain it?

[tedbr...@gmail.com]

On Sunday, February 16, 2020 at 2:08:24 PM UTC-8, pd wrote:

>
> I don't really understand how this works and how it is expected to be used, may you explain it?

It's another way to output something to trace each proc definition. It's just another way to do what heinrichmartin suggested in his post.

But if you can't use that code before you load tkcon or whatever else you might have that could define lremove, then it won't work. It sets a trace on the proc command, and then for each trace call, it outputs the name of the proc being defined plus looks at the stack frames to report line numbers and files so you can see where a proc definition got called from.

Typically, you'd place that code before any package require statements to see any proc's that were being defined.