Recent changes to feature-requests

http::geturl follow redirects

2013-05-02T11:35:53Z

IMHO it would be helpful, if http::geturl would follow redirects automatically (or with an option).

Thus
::http::geturl $url -followredirect 1
would do:
proc geturl_followRedirects {url args} {
while {1} {
set token [eval [list http::geturl $url] $args]
switch -glob [http::ncode $token] {
30[1237] { ### redirect - see below ### }
default { return $token }
}
upvar #0 $token state
array set meta [set ${token}(meta)]
if {![info exist meta(Location)]} {
return $token
}
set url $meta(Location)
unset meta
}
}

Thank you,
- Harald

Allow [clock format] and [clok scan] use higher resolution

2013-01-10T16:43:06Z

I would like to propose some options to [clock format] and [clock scan] to set the resolution type to work with, so that [clock milliseconds] etc could be used to format/scan higher resolution timestamps. The feature would also require new "cookie(s)" to be implemented. This feature will enable someone to work more easily with higher resolution timestamps, rather than them having to calculate a remainder to use with the timestamp they are formatting/scanning.

Allow tcltk-man2html to accept package directory

2013-01-07T12:52:26Z

tcltk-man2html.tcl is used to build HTML documentation on Windows and other platforms. It attempts to include documentation for extensions/packages, but is limited to find packages under $tcldir/pkgs/ .

When building from repository checkouts (rather than the official Tcl source distribution) or building non-TEA compliant packages it is (in this developer's opinion) convenient to locate extensions adjacent to rather than under $tcldir.

To support this I suggest a command line option "--pkgdir" that can specify the directory under which package sources can be found, as an absolute or relative (to pwd) path. The default if "--pkgdir" is omitted is $tcldir/pkgs, retaining backwards compatibility.

Implementation is in the Fossil repo in branch frq-(this frq).

new macro TclFreeIfRefCountZero

2012-12-29T18:21:20Z

In various places, objects with refCount zero are not
cleaned up in the error-case.

See branch "novem-freeifrefcountzero" for a start,
there are probably many more places where this
macro is useful. Meant for Tcl 9. Ongoing.

Inspired by the discussion regarding bug 3598580
with Alexandre Ferrieux.

Change PKG_DIR convention

2012-12-19T16:42:43Z

As noted in

https://sourceforge.net/mailarchive/message.php?msg_id=30251660

the established convention for PKG_DIR in Makefile.in

PKG_DIR= $(PACKAGE_NAME)$(PACKAGE_VERSION)

cannot work well for packages that make the unfortunate choice
to end their package name with a number.

An alternative convention

PKG_DIR= $(PACKAGE_NAME)-$(PACKAGE_VERSION)

would take care of them, and also align better with
other packaging standards out there, AIUI.

Ability to perform stricter encoding conversion checks

2012-12-18T11:50:34Z

Currently, Tcl never throws an error when:

1) Encountering an invalid byte sequence in the
source encoding when performing an "encoding
convertfrom" or while reading from a channel.

2) Encountering a Unicode character that cannot
be represented in the target encoding when
performing an "encoding convertto" or while
writing to a channel.

For example, these commands succeed
despite the data being incorrect:

$ tclsh
% encoding convertto iso8859-1 "\u4E24"
?
% encoding convertfrom utf-8 "\xC3\x28"
Ã(

This behaviour is often convenient if one wants
ones app to carry on "working" whatever happens,
but it's less desirable if one wants security or
correctness.

I feel Tcl would benefit from allowing a user to
request stricter encoding conversions.

Perhaps one way to do this would be to add a -strict
option to the encoding convert* commands:

encoding convertfrom ?-strict? ?encoding? data
encoding convertto ?-strict? ?encoding? string

And add a "-strictEncoding boolean" option to
fconfigure and chan configure.

I guess there might be other Tcl commands that
perform encoding conversions that might need to
be considered ("source" is one that comes to mind).

I'm not familiar enough with the C-level API to
propose changes there.

Alternatively, if this was targetted for Tcl 9 then
strictness could be made the default ...

[try] desired missing funciton

2012-11-30T23:52:57Z

The recipe

catch $script m o
return -options $o $m

lets me reproduce what evaluation of $script
alone would do. Other than the variables m and o
and some trivial unimportant things, they are
indistinguishable. Most importantly to me
they leave the same -errorinfo value in the
interp to be captured by another enclosing [catch].

I want some set of options to [try] to be able to
do the same thing. Right now, that appears
impossible because [try] seems to be pretty
insistent on leaving decorations on the errorInfo
value.

Since I have the [catch; return] combo that does what
I want, you might ask why that's not enough. Well
there are some places where only a single command
will do.

A [tailcall try $script] that didn't leave [try] droppings
on the stack trace would be nice.

new argument expansion {}$args like python args

2012-11-20T13:42:07Z

New argument expansion {**}$args like python **args, to call procedures with expanded named arguments...
%
proc test {{a "A"} {b "B"} {c "C"}} {
puts "- $a - $b - $c -"
}
% test
- A - B - C -
% test {**}{c Z a X}
- X - B - Z -

[tcl_findLibrary] armor against relative pathnames?

2012-11-09T13:41:55Z

When testing Tk 8.5.13 for release, we ran into troubles
when a realtive pathname value in TK_LIBRARY caused
a failure to find tk.tcl after a change of the working directory.
Using relative pathnames there is a bad idea, but in case it
happens, perhaps [tcl_findLibrary] ought to be normalizing
it's pathnames (or otherwise preventing relative pathnames)
as it puts them on the search path?

Allow user choice for RTLD_GLOBAL / RTLD_LOCAL

2012-10-22T00:51:23Z

This is similar to the feature request artifact id 3159088.
It would be very useful to allow users to control the flags passed to dlopen() when calling Tcl's load command.
One suggestion would be to add an optional -flags argument that accepts a list of values similar to the open command. Ex.

load myextension.so -flags { RTLD_GLOBAL RTLD_LAZY }