<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to feature-requests</title><link>https://sourceforge.net/p/tcl/feature-requests/</link><description>Recent changes to feature-requests</description><atom:link href="https://sourceforge.net/p/tcl/feature-requests/feed.rss" rel="self"/><language>en</language><lastBuildDate>Thu, 02 May 2013 11:35:53 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/tcl/feature-requests/feed.rss" rel="self" type="application/rss+xml"/><item><title>http::geturl follow redirects</title><link>https://sourceforge.net/p/tcl/feature-requests/646/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;IMHO it would be helpful, if http::geturl would follow redirects automatically (or with an option).&lt;/p&gt;
&lt;p&gt;Following &lt;a href="http://wiki.tcl.tk/1475" rel="nofollow"&gt;http://wiki.tcl.tk/1475&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Thus &lt;br /&gt;
::http::geturl $url -followredirect 1&lt;br /&gt;
would do:&lt;br /&gt;
proc geturl_followRedirects {url args} {&lt;br /&gt;
while {1} {&lt;br /&gt;
set token [eval [list http::geturl $url] $args]&lt;br /&gt;
switch -glob [http::ncode $token] {&lt;br /&gt;
30[1237] { ### redirect - see below ### }&lt;br /&gt;
default  { return $token }&lt;br /&gt;
}&lt;br /&gt;
upvar #0 $token state&lt;br /&gt;
array set meta [set ${token}(meta)]&lt;br /&gt;
if {![info exist meta(Location)]} {&lt;br /&gt;
return $token&lt;br /&gt;
}&lt;br /&gt;
set url $meta(Location)&lt;br /&gt;
unset meta&lt;br /&gt;
}&lt;br /&gt;
}&lt;/p&gt;
&lt;p&gt;Thank you,&lt;br /&gt;
- Harald&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Harald Oehlmann</dc:creator><pubDate>Thu, 02 May 2013 11:35:53 -0000</pubDate><guid>https://sourceforge.neta93e4adc0b4a62f4d62641a276467891b1bb4be9</guid></item><item><title>Allow [clock format] and [clok scan] use higher resolution</title><link>https://sourceforge.net/p/tcl/feature-requests/645/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;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.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Meliorator</dc:creator><pubDate>Thu, 10 Jan 2013 16:43:06 -0000</pubDate><guid>https://sourceforge.neteed97da08174efdd8f3f7d507648ad6348287981</guid></item><item><title>Allow tcltk-man2html to accept package directory</title><link>https://sourceforge.net/p/tcl/feature-requests/644/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;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/ .&lt;br /&gt;
&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Implementation is in the Fossil repo in branch frq-(this frq).&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Twylite</dc:creator><pubDate>Mon, 07 Jan 2013 12:52:26 -0000</pubDate><guid>https://sourceforge.net3173c60d07b6416d95b303c93f00d7234616f8c5</guid></item><item><title>new macro TclFreeIfRefCountZero</title><link>https://sourceforge.net/p/tcl/feature-requests/643/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;In various places, objects with refCount zero are not&lt;br /&gt;
cleaned up in the error-case.&lt;/p&gt;
&lt;p&gt;See branch "novem-freeifrefcountzero" for a start,&lt;br /&gt;
there are probably many more places where this&lt;br /&gt;
macro is useful. Meant for Tcl 9. Ongoing.&lt;/p&gt;
&lt;p&gt;Inspired by the discussion regarding bug 3598580&lt;br /&gt;
with Alexandre Ferrieux.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Jan Nijtmans</dc:creator><pubDate>Sat, 29 Dec 2012 18:21:20 -0000</pubDate><guid>https://sourceforge.net0db0a7fc52996589e936d70736926a419d1a36f3</guid></item><item><title>Change PKG_DIR convention</title><link>https://sourceforge.net/p/tcl/feature-requests/642/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;As noted in&lt;/p&gt;
&lt;p&gt;&lt;a href="https://sourceforge.net/mailarchive/message.php?msg_id=30251660"&gt;https://sourceforge.net/mailarchive/message.php?msg_id=30251660&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;the established convention for PKG_DIR in Makefile.in&lt;/p&gt;
&lt;p&gt;PKG_DIR=    $(PACKAGE_NAME)$(PACKAGE_VERSION)&lt;/p&gt;
&lt;p&gt;cannot work well for packages that make the unfortunate choice&lt;br /&gt;
to end their package name with a number.&lt;/p&gt;
&lt;p&gt;An alternative convention&lt;/p&gt;
&lt;p&gt;PKG_DIR=    $(PACKAGE_NAME)-$(PACKAGE_VERSION)&lt;/p&gt;
&lt;p&gt;would take care of them, and also align better with&lt;br /&gt;
other packaging standards out there, AIUI.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Don Porter</dc:creator><pubDate>Wed, 19 Dec 2012 16:42:43 -0000</pubDate><guid>https://sourceforge.net608e823d2fc87c9121c027e9bc6982bc622eeb3b</guid></item><item><title>Ability to perform stricter encoding conversion checks</title><link>https://sourceforge.net/p/tcl/feature-requests/641/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;Currently, Tcl never throws an error when:&lt;/p&gt;
&lt;p&gt;1) Encountering an invalid byte sequence in the&lt;br /&gt;
source encoding when performing an "encoding&lt;br /&gt;
convertfrom" or while reading from a channel.&lt;/p&gt;
&lt;p&gt;2) Encountering a Unicode character that cannot&lt;br /&gt;
be represented in the target encoding when&lt;br /&gt;
performing an "encoding convertto" or while&lt;br /&gt;
writing to a channel.&lt;/p&gt;
&lt;p&gt;For example, these commands succeed&lt;br /&gt;
despite the data being incorrect:&lt;/p&gt;
&lt;p&gt;$ tclsh&lt;br /&gt;
% encoding convertto iso8859-1 "\u4E24"&lt;br /&gt;
?&lt;br /&gt;
% encoding convertfrom utf-8 "\xC3\x28"&lt;br /&gt;
Ã(&lt;/p&gt;
&lt;p&gt;This behaviour is often convenient if one wants&lt;br /&gt;
ones app to carry on "working" whatever happens,&lt;br /&gt;
but it's less desirable if one wants security or&lt;br /&gt;
correctness.&lt;/p&gt;
&lt;p&gt;I feel Tcl would benefit from allowing a user to&lt;br /&gt;
request stricter encoding conversions.&lt;/p&gt;
&lt;p&gt;Perhaps one way to do this would be to add a -strict&lt;br /&gt;
option to the encoding convert* commands:&lt;/p&gt;
&lt;p&gt;encoding convertfrom ?-strict? ?encoding? data&lt;br /&gt;
encoding convertto ?-strict? ?encoding? string&lt;/p&gt;
&lt;p&gt;And add a "-strictEncoding boolean" option to&lt;br /&gt;
fconfigure and chan configure.&lt;/p&gt;
&lt;p&gt;I guess there might be other Tcl commands that&lt;br /&gt;
perform encoding conversions that might need to&lt;br /&gt;
be considered ("source" is one that comes to mind).&lt;/p&gt;
&lt;p&gt;I'm not familiar enough with the C-level API to&lt;br /&gt;
propose changes there.&lt;/p&gt;
&lt;p&gt;Alternatively, if this was targetted for Tcl 9 then&lt;br /&gt;
strictness could be made the default ...&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Kieran</dc:creator><pubDate>Tue, 18 Dec 2012 11:50:34 -0000</pubDate><guid>https://sourceforge.net927f8a052d5bc9ebbdd67bf9687f1e5d630ba1e1</guid></item><item><title>[try] desired missing funciton</title><link>https://sourceforge.net/p/tcl/feature-requests/640/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;The recipe&lt;/p&gt;
&lt;p&gt;catch $script m o&lt;br /&gt;
return -options $o $m&lt;/p&gt;
&lt;p&gt;lets me reproduce what evaluation of $script&lt;br /&gt;
alone would do.  Other than the variables m and o&lt;br /&gt;
and some trivial unimportant things, they are&lt;br /&gt;
indistinguishable.  Most importantly to me&lt;br /&gt;
they leave the same -errorinfo value in the&lt;br /&gt;
interp to be captured by another enclosing [catch].&lt;/p&gt;
&lt;p&gt;I want some set of options to [try] to be able to&lt;br /&gt;
do the same thing.  Right now, that appears&lt;br /&gt;
impossible because [try] seems to be pretty&lt;br /&gt;
insistent on leaving decorations on the errorInfo&lt;br /&gt;
value.&lt;/p&gt;
&lt;p&gt;Since I have the [catch; return] combo that does what&lt;br /&gt;
I want, you might ask why that's not enough.   Well&lt;br /&gt;
there are some places where only a single command&lt;br /&gt;
will do.&lt;/p&gt;
&lt;p&gt;A [tailcall try $script] that didn't leave [try] droppings&lt;br /&gt;
on the stack trace would be nice.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Don Porter</dc:creator><pubDate>Fri, 30 Nov 2012 23:52:57 -0000</pubDate><guid>https://sourceforge.netd5f48866b511aa435fc8a8b92d3b2f530a939235</guid></item><item><title>new argument expansion {**}$args like python **args</title><link>https://sourceforge.net/p/tcl/feature-requests/639/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;New argument expansion {**}$args like python **args, to call procedures with expanded named arguments...&lt;br /&gt;
%&lt;br /&gt;
proc test {{a "A"} {b "B"} {c "C"}} {&lt;br /&gt;
puts "- $a - $b - $c -"&lt;br /&gt;
}&lt;br /&gt;
% test&lt;br /&gt;
- A - B - C -&lt;br /&gt;
% test {**}{c Z a X}&lt;br /&gt;
- X - B - Z -&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Serg G. Brester</dc:creator><pubDate>Tue, 20 Nov 2012 13:42:07 -0000</pubDate><guid>https://sourceforge.nete31851cb971fbd25457961e38572c95b8227a695</guid></item><item><title>[tcl_findLibrary] armor against relative pathnames?</title><link>https://sourceforge.net/p/tcl/feature-requests/638/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;When testing Tk 8.5.13 for release, we ran into troubles&lt;br /&gt;
when a realtive pathname value in TK_LIBRARY caused&lt;br /&gt;
a failure to find tk.tcl after a change of the working directory.&lt;br /&gt;
Using relative pathnames there is a bad idea, but in case it&lt;br /&gt;
happens, perhaps [tcl_findLibrary] ought to be normalizing&lt;br /&gt;
it's pathnames (or otherwise preventing relative pathnames)&lt;br /&gt;
as it puts them on the search path?&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Don Porter</dc:creator><pubDate>Fri, 09 Nov 2012 13:41:55 -0000</pubDate><guid>https://sourceforge.net7c7c47ee0b5ca6aff1518d2242a04cd57454dca1</guid></item><item><title>Allow user choice for RTLD_GLOBAL / RTLD_LOCAL</title><link>https://sourceforge.net/p/tcl/feature-requests/637/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;This is similar to the feature request artifact id 3159088.&lt;br /&gt;
It would be very useful to allow users to control the flags passed to dlopen() when calling Tcl's load command.&lt;br /&gt;
One suggestion would be to add an optional -flags argument that accepts a list of values similar to the open command.  Ex.&lt;/p&gt;
&lt;p&gt;load myextension.so -flags { RTLD_GLOBAL RTLD_LAZY }&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Anonymous</dc:creator><pubDate>Mon, 22 Oct 2012 00:51:23 -0000</pubDate><guid>https://sourceforge.net3299733370c4436c55099e479e4b826b2ca04abd</guid></item></channel></rss>