tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] six lane highway just paved through the swamp. (tip162 - IPv6)

[Alexandre F. <ale...@gm...>]

On Sun, Dec 7, 2008 at 11:18 PM, David Gravereaux <dav...@po...> wrote:
> Alexandre Ferrieux wrote:
>
>> Now is there something intrinsically harder with USB ?
>
> There is no sockets interface for it, mainly.

Of course :-)

What I was dreaming of was taking whatever API exists for USB and
disguising it into a Tcl channel type.
(From what you wrote I believed you were about to do the same for
Bluetooth and IrDA; knowing nothing about them I assumed the three
were one the same level, exposing via specific APIs a point-to-point
packet transfer.)

Needless to say, such an USB channel would say nothing about the
actual bytes to send; that part would be the job of the "userland
driver" of each individual device.

Do you think this "transport-level-only" abstraction is doable ?

-Alex

Re: [TCLCORE] six lane highway just paved through the swamp. (tip162 - IPv6)

[Reinhard M. <ma...@tc...>]

Hi,

On Sun, 7 Dec 2008 at 23:18, David Gravereaux wrote:

> CreateFile() might have a way to get below the drivers and open the 
> port itself, but you are on your own for that.

I think libusb would be the way to go for talking directly to USB 
devices in a cross-platform way.

http://libusb.sf.net/

cu
 	Reinhard

Re: [TCLCORE] six lane highway just paved through the swamp. (tip162 - IPv6)

[David G. <dav...@po...>]

Alexandre Ferrieux wrote:

> Now is there something intrinsically harder with USB ?

There is no sockets interface for it, mainly.  So it extends to a
different interface.  Usermode is seen as the interface the USB end
device driver decides it wants to give you.  Some chose a comport,
others a C API.  What the stream details over the wire are not for
public consumption.  You could debug the wire and reverse engineer the
packet exchange.  CreateFile() might have a way to get below the drivers
and open the port itself, but you are on your own for that.

Re: [TCLCORE] six lane highway just paved through the swamp. (tip162 - IPv6)

[Alexandre F. <ale...@gm...>]

On Sun, Dec 7, 2008 at 9:25 PM, David Gravereaux <dav...@po...> wrote:
> Alexandre Ferrieux wrote:
>
>> But by the way, is USB dreamable of in this context ?
>
> Not for sockets.  Talking direct USB is like picking the lock on the
> backdoor instead of using the unlocked frontdoor.

Can you elaborate ?
Is there a fundamental difference between sending a data packet in
point-to-point mode over USB, Bluetooth, or IP(UDP) for that matter ?

By this I mean, I acknowledge the slight mismatch between the
stream-like Tcl channel model and packetized transmissions, but it is
doable anyway, as is shown by TclUDP: [puts -nonewline] (below the
MTU) and short-[read]s are just a peculiar packet interface, but a
working one...

Now is there something intrinsically harder with USB ?

-Alex

Re: [TCLCORE] six lane highway just paved through the swamp. (tip162 - IPv6)

[David G. <dav...@po...>]

Alexandre Ferrieux wrote:

> But by the way, is USB dreamable of in this context ?

Not for sockets.  Talking direct USB is like picking the lock on the
backdoor instead of using the unlocked frontdoor.

Even raw sockets is far off until a viable way to do message-based I/O
comes about.  I hope Pat Thoyts has some thoughts on merging his tcludp
into the core.

I'm excited about ipv6 multicast because it extends to internet routers.
 It's rather a moving target, which makes it even more exciting.

I've been away from core hacking for a while, and just found
Tcl_SetChannelError() yesterday.  An awesome addition to help bypass the
huge POSIX translation problem.  All thumbs up!

Re: [TCLCORE] TIP #342: Dict Get With Default

[Neil M. <ne...@Cs...>]

On 7 Dec 2008, at 14:41, Magentus wrote:
> On Tue, 02 Dec 2008 14:37:19 +0000,
> Lars Hellström <Lar...@re...> wrote:
>
>>  TIP #342: DICT GET WITH DEFAULT
>>
>>  A new subcommand of *dict* is proposed, which returns a dictionary
>>  value if it exists and returns a per-call default otherwise.
>
> Oh hell yes!  But a get-with-variable (returning a boolean) combo  
> would
> be even more useful (as I think was mentioned further down in your
> post).  This get-with-default command can be faked with [expr] without
> too much fuss, the other case however requires [catch], which I think
> should be reserved for error handling, not convenience. [...]

Were you thinking of something different than the following?

proc get-with-variable {dict key varName} {
     upvar 1 $varName var
     if {[dict exists $dict $key]} {
         set var [dict get $dict $key]
         return 1
     }
     return 0
}

-- Neil
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: [TCLCORE] TIP #342: Dict Get With Default

[Lars H. <Lar...@re...>]

Donal K. Fellows skrev:
> Lars Hellström wrote:
>>  The *dict* command will get a new subcommand        *dict 
>> getwithdefault* /dictionary/ /key/ ?/key/ ...? /value/ 
> 
> Now the questions:
> 1) Which is best: "getwithdefault" vs. "getdefault"?

I too agree with Twylite that a separate verb is better than a 
multiword phrase (although changing the subcommand name can be done at 
the script level, so it wouldn't be a catastrophe to have 
::tcl::dict::getwithdefault as the underlying command).

"lookup" to me signals some more advanced behaviour for missing keys 
than just returning a constant, so I suppose I would prefer "fetch", 
but for the rest of this mail I'm sticking with "getwithdefault".


> 2) Should the default value be before or after the keys?

My argument for putting it after has been analogy with [dict set]:

   dict set D key1 key2 value
   dict getwithdefault $D key1 key2 value

It also has the effect that key and value occur in the same order as in 
the string representation:

   dict getwithdefault {-foo bar} -foo baz

In addition, one could claim an analogy with [dict replace]:

   dict replace $D -foo bar
   dict getwithdefault $D -foo bar

Conversely, I don't think there is any [dict] subcommand which puts a 
key after its value.


> 3) Is a zero-length key list meaningful? (cf TIP#323)

The zero-length key list is not supported by [dict exists], and only 
supported by [dict get] as a special case (return corresponding 
key--value list).

It doesn't make sense when the number of keys is fixed --

   dict getwithdefault $D $default

would always return $D and never $default -- so what remains is the 
case of variable-length paths:

   dict getwithdefault $D {*}$path $default

The question is, what kind of $default would make sense in such a case? 
    If the same default is valid as an entry in a dictionary and for 
the dictionary as a whole, it follows that this entry is itself a 
dictionary of the same type as the whole, i.e., the dictionary is some 
kind of tree. The binary search tree

     0=A
     / \
    /   \
   /     \
-1=@   2=C
        /
       /
      1=B

/might/ indeed get encoded with nested dictionaries as

   key 0 value A left {key -1 value @}
   right {key 2 value C left {key 1 value B}}

so /maybe/ it could make sense, but I'm having trouble imagining an 
algorithm that would benefit from the combination of a possibly 
zero-length $path and a default for missing nodes.

In the case of a nested-dictionaries tree, I can however imagine it 
useful to retrieve an arbitrary node using a $path. Since that in the 
case of the root would cause [dict get] to return a list rather than a 
dictionary, shimmering might follow, so maybe that is a use-case for 
[dict getwithdefault $D {*}{} notused]. It's quite a stretch, though.

Lars Hellström

Re: [TCLCORE] TIP #342: Dict Get With Default

[Magentus <mag...@gm...>]

On Tue, 02 Dec 2008 14:37:19 +0000, 
Lars Hellström <Lar...@re...> wrote:

>  TIP #342: DICT GET WITH DEFAULT 
> 
>  A new subcommand of *dict* is proposed, which returns a dictionary 
>  value if it exists and returns a per-call default otherwise. 

Oh hell yes!  But a get-with-variable (returning a boolean) combo would
be even more useful (as I think was mentioned further down in your
post).  This get-with-default command can be faked with [expr] without
too much fuss, the other case however requires [catch], which I think
should be reserved for error handling, not convenience.  Also
get-with-default kind of brings back that NULL issue, where a boolean
result and a variable to stuff the value in very clearly avoids any
such nonsense.

One possibility; how about adding a keyword just before the last word
(presently /value/) to pick between them.  (Add hyphens to taste.)

Regardless, a vote for the name "fetch", here.


As a side note; in the [keyed] ensemble I've been using almost as long
as I've had a [dict] command to use, I've added [getv] (get with
variable), [getd] (get with default), and [getm] (get multiple, which I
think has been recently proposed somewhere, also, but I rarely actually
have a use for).  [getv] (get-with-variable) is what I personally use
most in regular code, while [getd] (your get-with-default) gets used
less often, and mostly only during setup and initialisation (in your
case, option parsing).


-- 
Fredderic

To the next generation: You ARE going to make mistakes, but could you
at least make them NEW mistakes?!?  We did.  And it was AWSOME!
		 -- fredderic, 2008

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 3 days, 17:36)

Re: [TCLCORE] six lane highway just paved through the swamp. (tip162 - IPv6)

[Reinhard M. <ma...@tc...>]

Hi,

On Sun, 7 Dec 2008 at 12:23, Alexandre Ferrieux wrote:

> I never understood why there wasn't a "UDP netcat".

the original netcat has a -u switch and socat supports UDP in various 
ways. What else would be needed to make them a "UDP netcat"?

cu
 	Reinhard

Re: [TCLCORE] six lane highway just paved through the swamp. (tip162 - IPv6)

[Alexandre F. <ale...@gm...>]

On Sun, Dec 7, 2008 at 12:23 PM, Alexandre Ferrieux
<ale...@gm...> wrote:
>
> Wow. UDP is a killer feature. Imagine, starting to be able to write
> userland drivers for various devices in pure Tcl !
> I never understood why there wasn't a "UDP netcat". This will bring it for free.
>
> What about portability ? Is there a Win-specific catch to UDP or can
> we hope to have it for unix with little work ?

Oops, I have written "UDP" where I meant "USB". Sorry.
The mistake was triggered by the analogy with Bluetooth.

But by the way, is USB dreamable of in this context ?

-Alex

Re: [TCLCORE] six lane highway just paved through the swamp. (tip162 - IPv6)

[Alexandre F. <ale...@gm...>]

On Sun, Dec 7, 2008 at 11:54 AM, David Gravereaux <dav...@po...> wrote:
> Just a happy announcement that tip-162-branch in CVS is building and
> working on windows:

Congrats Dave ! That's the kind of xmas gift I appreciate.

> I've started skeletal implementations of IrDA and Bluetooth additions
> mainly to force me to consider what the best API changes are needed so
> that we don't have to revisit API changes again.  Whether the new
> protocols make it to 8.6 or not is not my short term goal.
> I've also started a UDP section of the code in the hopes that one day we
> might fill it and turn it on.

Wow. UDP is a killer feature. Imagine, starting to be able to write
userland drivers for various devices in pure Tcl !
I never understood why there wasn't a "UDP netcat". This will bring it for free.

What about portability ? Is there a Win-specific catch to UDP or can
we hope to have it for unix with little work ?

> An asynchronous and protocol agnostic resolver is also in the works.
> That's about it for my dream networked Tcl..  Is it your's too?

You bet it is :)

-Alex

Re: [TCLCORE] TIP #329 [try] updated

[Andreas L. <av...@lo...>]

On Sun, Dec 07, 2008 at 04:24:37PM +1000, Magentus wrote:
> > Adding it now would unfortunately put the TIP at risk.
> Then put it at risk.
Your wish is heard, but not followed.

> From what I'm reading, there's still enough dissent;
This dissent has been resolved meanwhile.  There's only
remaining discussion about implementation details.

The current version is indeed KISS but has potential to 
be enhanced later (with new handler pseudo-keywords) if
that turned out to be desireable and worth it, later.

The current solution goes quite short, but at least
right-tracked (unlike globbing).  It is good.

[TCLCORE] six lane highway just paved through the swamp. (tip162 - IPv6)

[David G. <dav...@po...>]

Just a happy announcement that tip-162-branch in CVS is building and
working on windows:

E:\tcl_ws\tcl_tip162\win>release_vc8\tclsh86
% set s [socket -type tcp6 www.kame.net 80]
sock672
% fconfigure $s -sockname
2001:470:1f04:ed::2 davygrvy-pt.tunnel.tserv3.fmt2.ipv6.he.net 3182
% fconfigure $s -peername
2001:200:0:8002:203:47ff:fea5:3085 orange.kame.net 80

The old Win3.11 WSAAsyncSelect based I/O notification method is now
gone.  In it's place is a more modern and scalable use of overlapped
sockets using completion port notification.  The code base it came from
has a good history of being stable.

http://technet.microsoft.com/en-us/sysinternals/bb963891.aspx

A non-NT based implementation using WSAEventSelect has yet to be
invented.  In the meantime, I'm thinking of using the old code as a
runtime fallback if needed.

Hopefully by Christmas I'll have it all polished.

I've started skeletal implementations of IrDA and Bluetooth additions
mainly to force me to consider what the best API changes are needed so
that we don't have to revisit API changes again.  Whether the new
protocols make it to 8.6 or not is not my short term goal.

I've also started a UDP section of the code in the hopes that one day we
might fill it and turn it on.

An asynchronous and protocol agnostic resolver is also in the works.

That's about it for my dream networked Tcl..  Is it your's too?

Re: [TCLCORE] TIP #329 [try] updated

[Magentus <mag...@gm...>]

On Tue, 2 Dec 2008 08:56:40 +0100, 
Andreas Leitgeb <av...@lo...> wrote:

> I guess it will take a few years from now till Donal runs into such
> a practical usecase himself, and at that point we will perhaps add
> a new ltrap clause with just that type of matching.  Adding it now
> would unfortunately put the TIP at risk.

Then put it at risk.  From what I'm reading, there's still enough
dissent; one camp wants ultra-KISS, the other wants a useful flexible
tool (no prises for getting my preference ;) ).  Postpone the TIP,
implement both proposals as tcl::unsupported for people to try out, and
then it'll be a simple question a little further down the road of
"which one do we keep".

The chosen implementation gets moved to ::try, and other one gets
relegated to a script in tcllib for anyone who did actually use it in a
real project.

This isn't NEW functionality, it's a refactoring of OLD functionality.
High past time, I'll grant, but it's not a MUST HAVE for this release.
Having something to bang on for the next release, and a firm commitment
to make errorcodes useful (represented by the trial going on in
tcl::unsupported), will probably do more good then pushing through a
rushed TIP just so it'll make a deadline.


-- 
Fredderic

Junk is something you've kept for years and then
throw away three weeks before you need it.

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 3 days, 17:26)

Re: [TCLCORE] tcl/tk 8.6 schedule?

[Donal K. F. <don...@ma...>]

Adam Williamson wrote:
> Now you're getting slightly over my head (remember, no coder here!) but
> I get the basics. The API documentation could probably stand to be
> updated, in that case :). It still reads:
[...]
> ...unless, of course, that says the same as what you said in a way that
> I completely didn't get :)

I think the easiest way forward involves help with specific cases. But
one thing is that from 8.5 onwards, TCL_VOLATILE works identically to
TCL_STATIC so fixes for one are fixes for the other. :-)

If I go off into generalities, stop me or I'll lose you. ;-)

Donal.

Re: [TCLCORE] tcl/tk 8.6 schedule?

[Adam W. <awi...@ma...>]

On Sat, 2008-12-06 at 18:42 +0000, Donal K. Fellows wrote:
> Adam Williamson wrote:
> > Aren't TCL_DYNAMIC and TCL_VOLATILE options too, though? When would
> > those be used?
> 
> Originally (we're talking over 10 years ago now) TCL_STATIC meant that
> Tcl could just keep a reference to the string and never modify it,
> TCL_VOLATILE meant "copy immediately", and TCL_DYNAMIC meant "I give you
> this string, ckfree() it when you're done". But we've reorganized the
> way we manage the result since then; I think both TCL_STATIC and
> TCL_VOLATILE do the same thing now (copies), and TCL_DYNAMIC does the
> same except for freeing the argument too. I think. I don't feel like
> re-reading the source to find out! (If in doubt, use TCL_VOLATILE and
> then free the buffer yourself if it was allocated.)
> 
> Modern code uses Tcl_SetObjResult (which is actually more efficient than
> the old code could ever be) or Tcl_AppendResult (an old API that is just
> too convenient and which was redesigned inside).

Now you're getting slightly over my head (remember, no coder here!) but
I get the basics. The API documentation could probably stand to be
updated, in that case :). It still reads:

"If freeProc is TCL_STATIC it means that string refers to an area of
static storage that is guaranteed not to be modified until at least the
next call to Tcl_Eval. If freeProc is TCL_DYNAMIC it means that string
was allocated with a call to Tcl_Alloc and is now the property of the
Tcl system. Tcl_SetResult will arrange for the string's storage to be
released by calling Tcl_Free when it is no longer needed.If freeProc is
TCL_VOLATILE it means that string points to an area of memory that is
likely to be overwritten when Tcl_SetResult returns (e.g. it points to
something in a stack frame). In this case Tcl_SetResult will make a copy
of the string in dynamically allocated storage and arrange for the copy
to be the return string for the current Tcl command."

...unless, of course, that says the same as what you said in a way that
I completely didn't get :)
-- 
adamw

Re: [TCLCORE] tcl/tk 8.6 schedule?

[Donal K. F. <don...@ma...>]

Adam Williamson wrote:
> Aren't TCL_DYNAMIC and TCL_VOLATILE options too, though? When would
> those be used?

Originally (we're talking over 10 years ago now) TCL_STATIC meant that
Tcl could just keep a reference to the string and never modify it,
TCL_VOLATILE meant "copy immediately", and TCL_DYNAMIC meant "I give you
this string, ckfree() it when you're done". But we've reorganized the
way we manage the result since then; I think both TCL_STATIC and
TCL_VOLATILE do the same thing now (copies), and TCL_DYNAMIC does the
same except for freeing the argument too. I think. I don't feel like
re-reading the source to find out! (If in doubt, use TCL_VOLATILE and
then free the buffer yourself if it was allocated.)

Modern code uses Tcl_SetObjResult (which is actually more efficient than
the old code could ever be) or Tcl_AppendResult (an old API that is just
too convenient and which was redesigned inside).

Donal.

Re: [TCLCORE] tcl/tk 8.6 schedule?

[Adam W. <awi...@ma...>]

On Sat, 2008-12-06 at 10:11 +0000, Donal K. Fellows wrote:
> Adam Williamson wrote:
> > 99% of the issues I encountered were uses of interp->result, most of
> > which I fixed properly, some of which I kludged around with the
> > #define , because - not being a coder - I don't always know exactly how
> > to use Tcl_SetResult when tcl->result is being *set* rather than *read*
> > (I'm not sure whether to use TCL_STATIC, TCL_DYNAMIC or TCL_VOLATILE in
> > each case).
> 
> It depends which pattern they're using. So, if they're doing:
>    interp->result = "some constant string";
> then you use:
>    Tcl_SetResult(interp, "some constant string", TCL_STATIC);

Aren't TCL_DYNAMIC and TCL_VOLATILE options too, though? When would
those be used?

> If they're doing:
>    sprintf(interp->result, "some pattern %string", ...);
> then you use:
>    Tcl_SetObjResult(interp, Tcl_ObjPrintf("some pattern %string", ...));

Ah,  I see, that's useful. I'll see if I can turn any more kludges into
fixes with that. :)

> If they're doing something else, then the code is really in need of a
> load of TLC. :-)

Hehe :)
-- 
adamw

Re: [TCLCORE] tcl/tk 8.6 schedule?

[<lm...@bi...>]

> Heck, I even made ical work, I'm pretty sure we're
> the only distro in the world with a working ical package now. =) 

That's cool, I still use that.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

[TCLCORE] [OT] (TIP #329) some user mixup clarified.

[Andreas L. <av...@lo...>]

> From: Magentus <mag...@gm...>
> -- 
> Fredderic

Magentus signing as Fredderic got me confused in the past.
At some point I mixed up Twylite with Magentus, so in a recent
post I think I unappropriately thanked to "Fredderic". I really
meant to thank Twylight, who finally rewrote the TIP for sublist-
matching.
I'm terribly sorry for my misattributions.

ad Magentus/Fredderic: could you please change your real-name
part in the headers to "Fredderic", or clarify if you prefer
to be called Fredderic or Magentus?

Re: [TCLCORE] TIP #329 [try] updated

[Donal K. F. <don...@ma...>]

Magentus wrote:
> And all I'm reading is people complaining that the current proposal
> won't do this, and won't do that, that my proposal answers cleanly.
> Sounds like a case of "this is my party" to me.

We're in a vote now, on version 1.7 of the proposal. That covers exactly
one scheme for error matching: exact list prefixes. While there are use
cases which are not dealt with elegantly by it, they tend to rely on
badly constructed or badly designed errors. The first case is (probably)
a bug elsewhere (going by existing documentation) and the second is
really not our fault.

If you need something more complex, you can either use a smaller prefix
or handle all errors directly (through the exception code handler) and
use a Tcl script to do the rest. That is Good Enough.

Donal.

Re: [TCLCORE] tcl/tk 8.6 schedule?

[Donal K. F. <don...@ma...>]

Adam Williamson wrote:
> 99% of the issues I encountered were uses of interp->result, most of
> which I fixed properly, some of which I kludged around with the
> #define , because - not being a coder - I don't always know exactly how
> to use Tcl_SetResult when tcl->result is being *set* rather than *read*
> (I'm not sure whether to use TCL_STATIC, TCL_DYNAMIC or TCL_VOLATILE in
> each case).

It depends which pattern they're using. So, if they're doing:
   interp->result = "some constant string";
then you use:
   Tcl_SetResult(interp, "some constant string", TCL_STATIC);

If they're doing:
   sprintf(interp->result, "some pattern %string", ...);
then you use:
   Tcl_SetObjResult(interp, Tcl_ObjPrintf("some pattern %string", ...));

If they're doing something else, then the code is really in need of a
load of TLC. :-)

Donal.

Re: [TCLCORE] TIP #329 [try] updated

[Magentus <mag...@gm...>]

On Tue, 02 Dec 2008 01:05:45 +0200, 
Twylite <tw...@cr...> wrote:

> Thanks Joe,
>> Also also: re: "trap" clauses doing a glob match or
>> a list prefix match: either way sounds OK to me.
>> I have a slight preference for list prefix match,
>> but glob matching is also OK.
> So far the opinion seems to be that a list prefix is too limited, and
> a list pattern match (per element glob) is too difficult and has no
> existing reference.

That's been a short-coming with glob matching all alone, and something
I tried to address in a pluggable manner as a side-issue of my proposal.

Just because it has no existing reference is no reason to brush it
under the rug and pretend it doesn't exist.


> List prefixes are limited because they don't allow an errorcode to
> represent multiple dimensions. e.g. A media streaming error could be
> both an AudioException and an IOException, and different users of
> your media library may want to treat the error in different ways (a
> stream ripper is more concerned with IOExceptions, whereas a music
> player is probably more concerned with all types of AudioException
> (io, encoding, etc) ).  A list prefix matcher could cope with Java's
> single inheritance model, but not with the exception support
> available to (say) C++.

I dealt with that in my proposal, too.  You're not going to shoe-horn
C++ exceptions into any kind of string match.  That's why my proposal
split the handler into three keywords, two being common use cases, and
the third being a catch-all for everything else.  The idea also, was
that entirely new error paradigns could be added down the road, such as
OO exception handling.

Further, not all exceptions are errors.  A piece of information may or
may not be available yet.  If it is, then a result can be produced.  If
it isn't, then some information can be returned and presented to the
user.  That can readily be reflected by an exception, but is not an
error.  It is in that same line of reasoning that I pushed for matching
on OK return values also.


>> we don't ever want to see
>>     [try { ... } trap -match regexp "..." { ... }]
> No, no we don't ;)

Why the heck not?  (I believe the very next message also says basically
the same)


> The intended manner for extending [try] is by adding new handler
> keywords (if the existing ones are not handling the required use
> cases).

As I proposed very early on in the piece.  That doesn't mean you want
to swamp [try] with 1001 handler keywords for every possible error
source and string match combination.

[try] keywords should deal exclusively with the form that the error
takes, and a string match option should take care of matching against
the actual content of the error, if doing so even makes any sense for
that error form.


And all I'm reading is people complaining that the current proposal
won't do this, and won't do that, that my proposal answers cleanly.
Sounds like a case of "this is my party" to me.


-- 
Fredderic

You would if you could, but you can't so you won't.

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 2 days, 20:29)

Re: [TCLCORE] tcl/tk 8.6 schedule?

[Adam W. <awi...@ma...>]

On Wed, 2008-10-15 at 12:43 -0700, Adam Williamson wrote:

> I'd be able to manage on this front. Hopefully :) ATM I'm leaning
> towards kicking to 8.6 now, but I will do a quick survey of our major
> Tcl apps to make sure they have a port available already, or coming
> soon.

Well, the Mandriva Tcl 8.6 migration is now basically complete.

I left out a few packages that were Giant Balls Of Pain, but I ported
~100 packages to Tcl 8.6 and the new Fedora-based location policy (which
is very smart, kudos to whoever came up with it).

99% of the issues I encountered were uses of interp->result, most of
which I fixed properly, some of which I kludged around with the
#define , because - not being a coder - I don't always know exactly how
to use Tcl_SetResult when tcl->result is being *set* rather than *read*
(I'm not sure whether to use TCL_STATIC, TCL_DYNAMIC or TCL_VOLATILE in
each case).

But yep, it's all done, and just about everything works. Including the
big stuff like amsn. Heck, I even made ical work, I'm pretty sure we're
the only distro in the world with a working ical package now. =) So
migration to Tcl 8.6 is definitely possible for adventurous
distributions at this point. Wonder if whoever the Fedora maintainer is
wants to take the plunge. :)

I've mostly filed reports and contributed patches upstream, but of
course, upstream for many old Tcl apps is pretty much dead now. So
anyone interested can always pull the patches and quick fixes from
Mandriva SVN - http://svn.mandriva.com/ . The builds for Cooker can be
found at
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/(packagename) .
-- 
adamw

[TCLCORE] Status of votes in progress ...

[Andreas K. <and...@ac...>]

... as far as I was able to determine from the recent flood of mails ...


Deadl. = End of voting period, all in December.
TIP	 = Tip number, and short hand for the title.
Voters = Who has voted what so far (+YES, -NO)

TIP             Deadl.  Voters

340 const qual  ?       -jenglish? +jan?

234 zlib        8       +dkf +jan +ak +tclguy +msofer +kbk
244 png         8       +dkf +jan +ak +tclguy +msofer +kbk

324 tk_font     9       +dkf
332 1/2 close   9       +dkf +ak
341 dict filter 9       +dkf +ak

329 try/catch   10      +dkf +jenglish
339 pkg names   10      +ak +tclguy -jenglish
343 %b format   10      +dkf +ak
322 nre api     10/12   +msofer +kbk +jenglish

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122