tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] CFV: My final round for 8.6...

[Jeff H. <je...@ac...>]

Donal K. Fellows wrote:
> Jan Nijtmans wrote:
>> Further on, I agree with Joe about the Tcl_NRAddCallback
>> signature: it is overkill to have 4 clientData arguments,
>> one would be sufficient. For use inside the core,
>> there still is an internal variant with 4 arguments, so this
>> change is easy: Just make Tcl NRAddCallback call
>> TclNRAddCallback, but with NULL as the last 3 arguments.
>> I considered giving Tcl_NRAddCallback a variable number of
>> arguments, but I think that would needlessly complicate things.
> 
> I've written a few of the actual uses of that API, and can supply a bit
> of grist to this mill. It is most certainly useful to be able to pass
> more than one machine-word to the callback, and 4 covers a vast majority
> of cases: keeping down the number of times you have to allocate memory
> on the critical path is also a good idea.
> 
> IIRC, the number 4 was chosen because that was what it was convenient to
> provide in the backing structure while retaining a fast allocator. Or
> something like that.

Then why doesn't it receive some objv/objc API?

Re: [TCLCORE] Delaying CVF#340 until dec 5 (Re: CFV TIP #340)

[Jan N. <nij...@us...>]

2008/12/8 Joe English <jen...@fl...>:
> For what it's worth, I would vote YES on the following:
>
>
> | SPECIFICATION
> |
> | Add a new convenience routine to the public API:
> |
> |       void Tcl_SetStringResult(Tcl_Interp *interp, const char *result);
> |
> | which shall be equivalent to
> |
> |       Tcl_SetObjResult(interp, Tcl_NewStringObj(result, -1));
> |
> | The existing routine Tcl_SetResult() shall be formally deprecated.
> |
> | END SPECIFICATION.

Yes, that's it, only that I specified Tcl_SetStringResult() to be
a macro, doing exactly that. The reason is that I expect
Tcl_SetStringResult to be a popular function, and someone
accidently using it might find that extensions using it,
compiled against Tcl 8.6, will no longer run against Tcl 8.5.
I know that 'forward compatibility' is not promised, but for
a function that is expected to be 'popular' it is more likely
to become a problem that for a hardly used function.

> I don't think that's exactly right -- Jan and I have identified
> a path towards eliminating interp->result internal manipulations,
> and I don't think it needs to wait a complete release cycle (all
> of the changes are internal and could be done at any time).
> Tcl_SetStringResult() would help smooth the path is all.

Agreed. But it would have helped if other TCT members
joined the discussion.

The exact specification can be found as 340b.patch in
[Patch 2315890].

So, what to do now? How do others feel about it? Should
I delay the vote again? Is Tcl_SetStringResult as a macro
OK, or should we make it a function (accepting the
'forward incompatibility'). Or both: define the function, but
let it be a macro in Tcl 8.6.

I called the vote in order to be able to reach the 9 dec deadline.
Would that still be possible now?

Regards,
         Jan Nijtmans

Re: [TCLCORE] TIP#343: A Binary Specifier for [format/scan]

[Donald G P. <dg...@ni...>]

Donald Arseneau wrote:
> And "0" is Tcl's prefix for indicating base-8 formatting.

Since Tcl 8.5.0, Tcl's preferred way to denote octal is
with the 0o prefix.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] TIP#343: A Binary Specifier for [format/scan]

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

On Mon, Dec 8, 2008 at 6:22 PM, Alexandre Ferrieux
<ale...@gm...> wrote:
>
> I would love to see you at peace with this instead of seeing it pass
> with the two-thirds part of TYANNOTT...

Patch updated, now exactly matching the TIP, no more, no less.

-Alex

Re: [TCLCORE] TIP#343: A Binary Specifier for [format/scan]

[Donald A. <as...@tr...>]

dg...@us... writes:

> ...introduces something completely new.  For
> this format specifier the %# means "use Tcl's
> prefix for indicating base-2 formatting" -- in
> this case the 0b.

That is not new, but the same as for %#x -> 0x.

> But then we look at:
> 
> % format %#o 14
> 016
> 
> (NOT 0o16 !)

And "0" is Tcl's prefix for indicating base-8 formatting.
Yes, that could (should) change as part of the program to 
eliminate the EVIL "0 prefix means octal". 

That doesn't mean %b should be held up.  I had it in my
head that %b was already accepted and was surprised when
it came up in the recent TIP!  Please don't wait longer.

> pointed out in Bug 2373594:
> 
> % scan 0b111 %i
> 0
> % scan 0o7 %i
> 0

Indeed bugs, but only conceptually related to this TIP,
unless they are the tip of an iceberg that sinks all the
radix internals.



-- 
Donald Arseneau                          as...@tr...

[TCLCORE] TIP#329 (try/catch) vote

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

My vote
	TIP#329	PRESENT

Read the TIP and it feels good. Tried to read the discussion and got lost. I
am not sure enough of my feelings of goodness to say yes, and have to trust
the people which actually took part in the discussion here, i.e. not stand
in their way.

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

[TCLCORE] TIP#322 (NRE API) vote

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

My vote
	TIP#322	YES

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

[TCLCORE] Updated: Status of votes in progress ...

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

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

Update using the latest votes.
 
> Voters = Who has voted what so far (+YES, -NO)
	/PRESENT
 
TIP             Deadl.  Voters
 
324 tk_font     9       +dkf	/ak +jnijtmans +kbk
332 1/2 close   9       +dkf +ak +jnijtmans /kbk
341 dict filter 9       +dkf +ak +jnijtmans +kbk
 
329 try/catch   10      +dkf +jenglish +jnijtmans /kbk
339 pkg names   10      +ak +tclguy -jenglish -jnijtmans +kbk
343 %b format   10      +dkf +ak +jnijtmans -dgp +kbk
322 nre api     10/12   +msofer +kbk +jenglish +jnijtmans

Voting ended for

340	const qual		rejected
234	zlib		accepted
244	png		accepted

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

Re: [TCLCORE] Yet more voting. (TIP 339 - Case-Insensitive Package Names)

[Jeff H. <je...@ac...>]

Jan Nijtmans wrote:
>  Andreas Kupries wrote:
>> Let us see who screams.
>> Calling the vote on
>>       TIP #339:       Case-Insensitive Package Names
> 
>  TIP#339: NO.
> 
> I hesitated much about this one, but finally  Jeff's remark
> about case insensitive OSes brought me to this. Most
> languages (e.g. java) have all lower-case package names.
> It just means that on a case-insensitive OS, a mismatch
> between file/directory-name and package name will not
> hurt, on other systems it will. Keeping the "be strict in what
> you generate and generous in what you accept" principle
> (in my interpretation) we should continue to accept
> Camel-case package names, but from now on only
> provide all-lower-case ones.
> 
> So, I suggest to make Tcl and Tk provide the "tcl" and "tk"
> packages as well as the "Tcl" and "Tk" packages, and
> - for Tk - make "package require tk" equivalent to
> "package require Tk". Just make all-lowercase package
> names the recommended way, but not enforce it. Then
> no current packages will break, still eventually every
> one can remember the concept. In time, the problem
> will fade away.

This seems like a flawed argument.  "I acknowledge the problem, but 
let's not force any fix, let's just recommend one, leaving the potential 
problems in the core and hope they fade away".  Eh?

Jeff

[TCLCORE] Ballot on pending TIPs

[Kenny, K. B (G. Research) <ke...@cr...>]

Thank you, Andreas for the summary.
 
TIP #324: YES.  
    We've needed a proper font selector for a long time.
    Now that the Windows-style (toplevel only) and the
    Mac-style (componentry) are both accounted for, this
    ought to go forward.
 
TIP #332: PRESENT
    I don't really feel comfortable evaluating this one.
    If Donal and Andreas are happy with it, I'll let others
    attack if they want.
 
TIP 341: YES
    Why not?
 
TIP 329: PRESENT
    I got lost in the discussion of this one long ago.
 
TIP 339: YES
    Tcl Modules in case-independent filesystems cause
    confusion. And I can never remember which package
    authors chose Titlecase or CamelCase for package
    names. If it causes some short-term breakage, so
    be it; the breakage is easy to fix.
 
TIP 343: YES
    Contrary to Don Porter's assertion, the TIP as stated
    makes %b work in a manner that is precisely analogous
    to %x. (It's not analogous to %o, but that inconsistency
    is something that we've inherited from our forbears.)
 
I've already registered YES votes on TIPs 234, 244 and 322.
 
-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] Delaying CVF#340 until dec 5 (Re: CFV TIP #340)

[Joe E. <jen...@fl...>]

Jan Nijtmans wrote:

> Here is the results of TIP #340 vote (Provided I
> interpreterd JE's correctly.
>
> JN: YES
> JE: NO
>
> This means the TIP is rejected.
>
> The best guess about the why question is Kevin's remark:

Erm...

For my part, this is the main reason:

| jenglish@eurydice$ folder
| inbox+ has 283 messages  (1-425); cur=377.

I saw the note mentioning that the TIP had been updated,
took a quick look, saw an ABSTRACT section and and a
RATIONALE section but no SPECIFICATION; thought "OK,
it'll take some effort to figure out *exactly* what's
being voted on, will get to it later", and have not
gotten around to doing so yet.

Sorry about that.  It's just that:

| jenglish@eurydice$ folder
| inbox+ has 283 messages  (1-425); cur=377.

For what it's worth, I would vote YES on the following:


| SPECIFICATION
|
| Add a new convenience routine to the public API:
|
|	void Tcl_SetStringResult(Tcl_Interp *interp, const char *result);
|
| which shall be equivalent to
|
|	Tcl_SetObjResult(interp, Tcl_NewStringObj(result, -1));
|
| The existing routine Tcl_SetResult() shall be formally deprecated.
|
| END SPECIFICATION.


> Kevin Kenny wrote:
> > I don't think there's any controversy that
> > we want to kill Tcl_SetResult -- eventually. It isn't const-
> > correct, and can't be made const-correct. But, aside from
> > spewing compiler warnings, it's Mostly Harmless. The chief
> > reason for wanting to kill it is that it's all tied up in
> > the manipulations of interp->result, and we have to wait at
> > least another release cycle before we can put paid to them.

I don't think that's exactly right -- Jan and I have identified
a path towards eliminating interp->result internal manipulations,
and I don't think it needs to wait a complete release cycle (all
of the changes are internal and could be done at any time).
Tcl_SetStringResult() would help smooth the path is all.



--Joe English

  jen...@fl...

Re: [TCLCORE] TIP#343: A Binary Specifier for [format/scan]

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

On Mon, Dec 8, 2008 at 6:06 PM, Donald G Porter <dg...@ni...> wrote:
>
> Or maybe I'm just making excuses because I can't keep up with the
> flood.

Not at all ! Your concern is perfectly valid, and now I understand
that my [scan %i] idea was a nastily incompatible one. Thanks for
clarifying this.
I will update the patch tonight.
In summary, what the TIP offers is:

  [format %#06b 5] ==> 0b0101 (NEW)
  [format %#o 9] ==> 011          (ALREADY)
  [scan %b 101] ==> 5               (NEW)
  [scan %i 0b101] ==> 0            (ALREADY)

In all cases, it preserves the invariant:

  [expr "[format %#BASE $x]==$x"]

regardless of how the base prefix is structured. Octal stands alone in
its ages-old mud, but Still Works ;-)

I would love to see you at peace with this instead of seeing it pass
with the two-thirds part of TYANNOTT...

-Alex

Re: [TCLCORE] TIP#343: A Binary Specifier for [format/scan]

[Donald G P. <dg...@ni...>]

Alexandre Ferrieux wrote:
> I was under the impression that TIPs were voted on based on their main
> text, not on the ref implementation (which in some cases is
> nonexistent at the time of voting). Am I wrong ?

When a TIP is not complete in every detail, I often fill in the
gaps from assumed context.  Best for this is reference implementation,
but related Tracker reports also come into play.

If I erred in understanding the proposal I apologize.  I've been
a bit rushed in my TIP review lately.

I don't want to play "what if" games now.  It's not appropriate
while voting is still in progress.  In all likelihood the TIP
will pass anyway, and you can just ignore my concerns.

The overall treatment of integers by Tcl is currently in a confused
state.  That should be fixed.  But for me, it's a better evolution
to at least attempt to go:

   confused -> sensible

in a single step, and avoid

   confused(in one way) -> confused (in a new way) -> ... -> sensible

Because the latter puts much bigger burdens on the effort to support
people having troubles.  "Oh!  You have variant X!  You need to
stand on your head *this* way!  Oh!  You need code that will work
with *all* the variations released?  hold your nose and copy..."

There's an element of "perfect enemy of good" there I recognize.
So be it.

Or maybe I'm just making excuses because I can't keep up with the
flood.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] TIP#343: A Binary Specifier for [format/scan]

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

On Mon, Dec 8, 2008 at 5:24 PM,  <dg...@us...> wrote:
> This one, alas, is not trouble free.  There
> are subtleties to this, which give me enough
> fear to not want to rush it.
>
> As an example, the addition of %#b as a format
> specifier for [format] as in the TIP example:
>
> format %#06b 5
>        => 0b0101
>
> ...introduces something completely new.  For
> this format specifier the %# means "use Tcl's
> prefix for indicating base-2 formatting" -- in
> this case the 0b.
>
> But then we look at:
>
> % format %#o 14
> 016
>
> (NOT 0o16 !)
>
> This is what the %#o format specifier has always
> done, and for consistency, ought to keep doing
> (consider the Tcl scripts using [format] to
> write C code), but is not following the same
> principles as %#b, generating the deprecated
> format instead of the preferred one.

OK, but please notice the TIP itself says nothing about what happens
or should happen with octal.
The %# notation in [format], when applied to hex, adds "0x" (except for 0).
Do you see any reason why the same could not apply to binary ?

> Similar troubles arise on the [scan] side, as
> pointed out in Bug 2373594:
> % scan 0b111 %i
> 0
> % scan 0o7 %i
> 0
>
> Perhaps surprising, but consistent with the
> non-error operations of [format] and [scan]
> since time began, and since I know not all
> the strange and wonderful uses these tools
> find, I fear changing them incompatibly.

OK. That voids my suggestion in the patch. But this was just an
ancillary proposal, and again *not* in the body of the TIP.

I was under the impression that TIPs were voted on based on their main
text, not on the ref implementation (which in some cases is
nonexistent at the time of voting). Am I wrong ?

In any case, what if I just remove the [scan %i] "fix" ?

-Alex

Re: [TCLCORE] TIP#343: A Binary Specifier for [format/scan]

[<dg...@us...>]

This one, alas, is not trouble free.  There
are subtleties to this, which give me enough
fear to not want to rush it.

As an example, the addition of %#b as a format
specifier for [format] as in the TIP example:

format %#06b 5
	=> 0b0101

...introduces something completely new.  For
this format specifier the %# means "use Tcl's
prefix for indicating base-2 formatting" -- in
this case the 0b.

But then we look at:

% format %#o 14
016

(NOT 0o16 !)

This is what the %#o format specifier has always
done, and for consistency, ought to keep doing
(consider the Tcl scripts using [format] to
write C code), but is not following the same
principles as %#b, generating the deprecated
format instead of the preferred one.

Similar troubles arise on the [scan] side, as
pointed out in Bug 2373594:

% scan 0b111 %i
0
% scan 0o7 %i
0

Perhaps surprising, but consistent with the
non-error operations of [format] and [scan]
since time began, and since I know not all
the strange and wonderful uses these tools
find, I fear changing them incompatibly.

For better or worse, [format] and [scan]
have always been just emulations of sprintf()
and sscanf() lifted to script level.  When
we venture to extend beyond that, I'd prefer
something done with more time to examine
the implications with care and completeness
(see TIP 297).

I vote: NO

but please understand that really means NOT NOW.
Raise it again for the next cycle.

DGP

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

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

David Gravereaux wrote:
> The list of available protocols for sockets is sizable actually.  Here
> goes the list of what the socket() command _might_ understand.  This is
> of course dependent on OS and what software drivers to support hardware
> are installed.  On win, they're called layered service providers.
[...]
> This isn't an exhaustive list either, but is all the easily available
> info I have.

If you're working on Unix, consider AF_UNIX as well.

Donal.

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

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

Alexandre Ferrieux wrote:

>    socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO)
> 
> Now whatever the semantics (possibly barely useful) or support
> (possibly patchy), exposing it in Dave's work should not be a problem
> (just map a string to an integer  constant).

On Win, just BTPROTO_RFCOMM and BTPROTO_L2CAP are defined.  Looks SOL
for BTPROTO_SCO and BTPROTO_HCI here.  The string mapping project is
going well.  Thanks for the above.  I'm up to a total of 45 different
socket types that might be possible in my dream list.  Whether I can
realize them is a different issue.

> On the other hand, being courageous might help for once. Compatibility
> with TclUDP is not a hard constraint since it is not in the core. And
> the "right way" might not be that complex. What about the following:
> 
>  # Example built with UDP in mind; please generalize.
> 
>  # sendto()
>  chan configure/fconfigure $channel -dest $host:$port
>  chan putpacket $channel $data
> 
>  # recvfrom()
>  set data [chan getpacket $channel]
>  set from [chan configure $channel -src]
> 
>  # connect()+recv() => filter
>  chan configure $channel -src $host:$port
>  set data [chan getpacket $channel]
> 
>  # ioctl() => immediate actions unfit for [fconfigure]
>  chan control $channel FOO bar


I like it.  I was thinking a more simple path just to get going, but
that certainly is my direction minus some details.  The
Tcl_Driver(Input|Output)Proc could both return EOPNOTSUPP for those
types when one accidentally uses [puts],[read] or Tcl_Gets, etc..

You're not kidding mentioning Pandora's box.  I'm getting dizzy seeing
all the possible network support we could have.

Re: [TCLCORE] CFV: Zlib and PNG

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

Donal K. Fellows wrote:
> As has been thoroughly threatened, here's the Call For Votes on getting
> zlib support for Tcl (yay compression!) and PNG support for Tk (yay
> modern icons!) Votes should be sent to tcl-core by midday GMT next
> Monday (i.e. [clock format 1228737600]).
> 
>    TIP#234: Add Support For Zlib Compression
>    TIP#244: PNG Photo Image Support for Tk

That's two accepted TIPs, both 6/0/0. In each case, the same people
voted for them, being:
   DKF, JN, AK, JH, MS, KBK

The subsidiary questions of prefixing and packaging for zlib also seem
to be settled: the C API prefix will be Tcl_Zlib, and the functionality
will not be formally part of a separate package.

Thanks to everyone who voted...

Donal.

Re: [TCLCORE] CFV: My final round for 8.6...

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

Jan Nijtmans wrote:
> Further on, I agree with Joe about the Tcl_NRAddCallback
> signature: it is overkill to have 4 clientData arguments,
> one would be sufficient. For use inside the core,
> there still is an internal variant with 4 arguments, so this
> change is easy: Just make Tcl NRAddCallback call
> TclNRAddCallback, but with NULL as the last 3 arguments.
> I considered giving Tcl_NRAddCallback a variable number of
> arguments, but I think that would needlessly complicate things.

I've written a few of the actual uses of that API, and can supply a bit
of grist to this mill. It is most certainly useful to be able to pass
more than one machine-word to the callback, and 4 covers a vast majority
of cases: keeping down the number of times you have to allocate memory
on the critical path is also a good idea.

IIRC, the number 4 was chosen because that was what it was convenient to
provide in the backing structure while retaining a fast allocator. Or
something like that.

Donal.

Re: [TCLCORE] CFV: My final round for 8.6...

[Jan N. <nij...@us...>]

2008/12/3 Donal K. Fellows <don...@ma...>:
> The final set of votes that I'm calling; we're about out of time and I'm
> definitely out of effort! :-)
>
>  TIP#329: Try/Catch/Finally syntax
>  TIP#343: A Binary Specifier for [format/scan]

My votes:

TIP#329: YES
TIP#343: YES

I wonder if support for "0o" (octal) is missing in some places in the
core as well. I think everywhere that "0b" is accepted, "0o" should
be accepted as well.

Some more:

TIP #322: YES (see additinal remark below)
TIP #324: YES
TIP #332: YES
TIP #341: YES

In TIP #322, I initially was mislead by the the signatures for
Tcl_NRCallObjProc and Tcl_NRCmdSwap but in tcl.decls
they are correct: "Tcl_Obj const *objv[]" should
have been "Tcl_Obj *const objv[]".

Further on, I agree with Joe about the Tcl_NRAddCallback
signature: it is overkill to have 4 clientData arguments,
one would be sufficient. For use inside the core,
there still is an internal variant with 4 arguments, so this
change is easy: Just make Tcl NRAddCallback call
TclNRAddCallback, but with NULL as the last 3 arguments.
I considered giving Tcl_NRAddCallback a variable number of
arguments, but I think that would needlessly complicate things.

Regards,
        Jan Nijtmans

Re: [TCLCORE] Yet more voting. (TIP 339 - Case-Insensitive Package Names)

[Jan N. <nij...@us...>]

 Andreas Kupries wrote:
> Let us see who screams.
> Calling the vote on
>       TIP #339:       Case-Insensitive Package Names

 TIP#339: NO.

I hesitated much about this one, but finally  Jeff's remark
about case insensitive OSes brought me to this. Most
languages (e.g. java) have all lower-case package names.
It just means that on a case-insensitive OS, a mismatch
between file/directory-name and package name will not
hurt, on other systems it will. Keeping the "be strict in what
you generate and generous in what you accept" principle
(in my interpretation) we should continue to accept
Camel-case package names, but from now on only
provide all-lower-case ones.

So, I suggest to make Tcl and Tk provide the "tcl" and "tk"
packages as well as the "Tcl" and "Tk" packages, and
- for Tk - make "package require tk" equivalent to
"package require Tk". Just make all-lowercase package
names the recommended way, but not enforce it. Then
no current packages will break, still eventually every
one can remember the concept. In time, the problem
will fade away.

Regards,
         Jan Nijtmans

Re: [TCLCORE] Delaying CVF#340 until dec 5 (Re: CFV TIP #340)

[Jan N. <nij...@us...>]

Here is the results of TIP #340 vote (Provided I
interpreterd JE's correctly.

JN: YES
JE: NO

This means the TIP is rejected.
The best guess about the why question is Kevin's remark:

Kevin Kenny wrote:
> I don't think there's any controversy that
> we want to kill Tcl_SetResult -- eventually. It isn't const-
> correct, and can't be made const-correct. But, aside from
> spewing compiler warnings, it's Mostly Harmless. The chief
> reason for wanting to kill it is that it's all tied up in
> the manipulations of interp->result, and we have to wait at
> least another release cycle before we can put paid to them.

The original TIP specification was too simple. The revised one
too complex. I didn't hear any arguments that this TIP was
fundamentally incorrect, so I propose to put back this TIP
and re-examine it again for Tcl 8.7.

Regards,
         Jan Nijtmans

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

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

On Mon, Dec 8, 2008 at 4:32 AM, Donal K. Fellows
<don...@ma...> wrote:
>
>> 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...
>
> That's the really big issue. With channels, it doesn't really matter if
> you break a message up into pieces: the other side will get them in
> order and can reassemble. With message-oriented connections such as
> UDP[*] that assumption doesn't hold, so TclUDP can break "interestingly"
> if used naïvely with large messages.

Of course. But programming naïvely (thanks for the non-ASCII
character) can lead to problems in many other circumstances ;-)
When you're doing UDP, on the write side you have to be aware of the
MTU anyway . On the receive side you can use TclUDP's guaranteed short
read semantics, so the only danger is if you pass a maximum length
that is too small...
So it seems the concern is more of an aesthetic than practical nature.
What I'm driving at is the following dichotomy. Should we:

 (a) stick to the TclUDP tradition for all the new packet-based socket
types in David's Pandora box.

 (b) first define a clean API extension before proceeding.

You seem to advocate (a)  because (b) is "a big project".
I can see another reason: (a) will probably have to be supported
anyway, eg  for backwards compatibility with TclUDP, or for the
uniformity of the channel API (no [read] nor [puts] sounds odd).
So, when (b) comes,  there will be two ways of sending/receiving
packets. I find this odd too :-(

On the other hand, being courageous might help for once. Compatibility
with TclUDP is not a hard constraint since it is not in the core. And
the "right way" might not be that complex. What about the following:

 # Example built with UDP in mind; please generalize.

 # sendto()
 chan configure/fconfigure $channel -dest $host:$port
 chan putpacket $channel $data

 # recvfrom()
 set data [chan getpacket $channel]
 set from [chan configure $channel -src]

 # connect()+recv() => filter
 chan configure $channel -src $host:$port
 set data [chan getpacket $channel]

 # ioctl() => immediate actions unfit for [fconfigure]
 chan control $channel FOO bar

Reactions ?

-Alex

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

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

On Mon, Dec 8, 2008 at 4:32 AM, Donal K. Fellows
<don...@ma...> wrote:
>
> [ ... And I don't understand SOCK_SEQPACKET. ]

That's reliable-ordered-datagrams (or stream-with-boundaries).
The only place I ever used it is on an emulated Bluetooth layer
exposing sound IO on a braindead home VOIP gateway made by my company
:-}

   socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO)

Now whatever the semantics (possibly barely useful) or support
(possibly patchy), exposing it in Dave's work should not be a problem
(just map a string to an integer  constant).

-Alex

Re: [TCLCORE] tcl/tk 8.6 schedule?

[Jan N. <nij...@us...>]

2008/12/6 Donal K. Fellows <don...@ma...>:
> 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);

Actually, in this case, it should be:
   Tcl_SetResult(interp, (char *)"some constant string", TCL_STATIC);
because of the signature problem of Tcl_SetResult (it depends
on the compiler version and compiler flags if you get a warning or not).
Therefore it is better to to use:
   Tcl_SetObjResult(interp, Tcl_NewStringObj("some constant string", -1));

Regards,
          Jan Nijtmans