gmane.comp.lang.tcl.core

TIP 304 CFV

Hello,

Apologies if I'm not entitled to a CFV as a non-TCT-member. You can
bite me in that case.
Still, I believe it is roughly the proper time for a vote on TIP 304,
aiming for 8.6a2 if accepted.
Brief summary/history:

TIP #304:
A Standalone [pipe] Primitive for Advanced Child IPC
http://www.tcl.tk/cgi-bin/tct/tip/304.html

It is basically stealing TclX's [pipe], bringing it to stock Tcl as [chan pipe].
This allows, among other things, to redirect separately stdout and
stderr from a child and use both programmatically, like [bgexec] does.
It also silences most of the need behind "TIP #301: Split
Bidirectional Channels For Half-Close", since it allows to close the
stdin of a child and still listen to its last words.

Reference implementation as [Patch 1978495]:
https://sourceforge.net/tracker/index.php?func=detail&aid=1978495&group_id=10894&atid=310894

The implementation is no rocket science. It is a minimal stylistic/API
readjustment of TclX's, which has withstood fire for years.
Notably, it leverages existing pipe machinery with its
obsolete-but-working worker threads and events under Windows. We have
a plan to iron this out eventually, but it is strictly orthogonal to
304 (as it will ease plain [open |] too and fix the awful
TerminateThread issues like in [Bug 1958930]).

(Continue reading)

headers

Donal K. Fellows | 30 Jun 14:28

Re: TIP 304 CFV

Alexandre Ferrieux wrote:
> TIP #304:
> A Standalone [pipe] Primitive for Advanced Child IPC
> http://www.tcl.tk/cgi-bin/tct/tip/304.html
> 
> It is basically stealing TclX's [pipe], bringing it to stock Tcl as [chan pipe].
> This allows, among other things, to redirect separately stdout and
> stderr from a child and use both programmatically, like [bgexec] does.
> It also silences most of the need behind "TIP #301: Split
> Bidirectional Channels For Half-Close", since it allows to close the
> stdin of a child and still listen to its last words.

Before I run the CFV, I note that there's an inconsistency between the
change documented in the TIP and what you seem to be proposing. Can you
update the TIP to reflect what you actually think should happen? Thanks.
(I'm happy to update the title for you if you tell me what to change it
to.) With the updates done, I'm sure that we can go ahead with the CFV.

Donal.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

headers

Alexandre Ferrieux | 30 Jun 14:54

Re: TIP 304 CFV

On Mon, Jun 30, 2008 at 2:28 PM, Donal K. Fellows
<donal.k.fellows@...> wrote:
> Alexandre Ferrieux wrote:
>>
>> TIP #304:
>> A Standalone [pipe] Primitive for Advanced Child IPC
>> http://www.tcl.tk/cgi-bin/tct/tip/304.html
>>
>> It is basically stealing TclX's [pipe], bringing it to stock Tcl as [chan
>> pipe].
>> This allows, among other things, to redirect separately stdout and
>> stderr from a child and use both programmatically, like [bgexec] does.
>> It also silences most of the need behind "TIP #301: Split
>> Bidirectional Channels For Half-Close", since it allows to close the
>> stdin of a child and still listen to its last words.
>
> Before I run the CFV, I note that there's an inconsistency between the
> change documented in the TIP and what you seem to be proposing. Can you
> update the TIP to reflect what you actually think should happen? Thanks.

Oops sorry - done in the TIP: [pipe]->[chan pipe]

> (I'm happy to update the title for you if you tell me what to change it
> to.) With the updates done, I'm sure that we can go ahead with the CFV.

Yes, please change the title, it looks like the editor does not permit
a title change.

Thanks,

(Continue reading)

headers

Donal K. Fellows | 30 Jun 15:29

Re: TIP 304 CFV

Alexandre Ferrieux wrote:
> Donal K. Fellows wrote:
>> (I'm happy to update the title for you if you tell me what to change it
>> to.) With the updates done, I'm sure that we can go ahead with the CFV.
> 
> Yes, please change the title, it looks like the editor does not permit
> a title change.

Updated. I've also made it a bit neater formatted, and I've documented
the C API. Double-check my changes, and if they're good, we're good to
go with a CFV.

Donal.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

headers

Alexandre Ferrieux | 30 Jun 16:47

Re: TIP 304 CFV

On Mon, Jun 30, 2008 at 3:29 PM, Donal K. Fellows
<donal.k.fellows@...> wrote:
>
> Updated. I've also made it a bit neater formatted, and I've documented
> the C API. Double-check my changes, and if they're good, we're good to
> go with a CFV.

Thank you very much Donal for that last touch !
It's perfect for me.

-Alex

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

headers

Daniel A. Steffen | 30 Jun 17:36

Re: TIP 304 CFV

Hi Alexandre,

On 30/06/2008, at 14:16, Alexandre Ferrieux wrote:

> TIP #304:

> chan pipe ?pr pw?
>
> Create a pipe. If pr and pw are specified, then chan pipe will set  
> the variable named pr to contain the channel wrapping the side of  
> the pipe that was opened for reading, andpw the same for writing.  
> Subsequently, anything written to $pw will be readable on $pr. If  
> the variables are not specified, then a list containing the read and  
> write channels is returned as the result of the command.
>
very minor question: why not return the list of channelIds in both  
cases (i.e. even when the variable names are passed in) ?
the return value may go used in that case but that does not hurt  
anything, and it would be more consistent with the other channel  
creating commands that always return a channelId...

Cheers,

Daniel

--

-- 
** Daniel A. Steffen                   **
** <mailto:das@...>  **

(Continue reading)

headers

Alexandre Ferrieux | 30 Jun 17:58

Re: TIP 304 CFV

On Mon, Jun 30, 2008 at 5:36 PM, Daniel A. Steffen
<das@...> wrote:
> Hi Alexandre,
>
> On 30/06/2008, at 14:16, Alexandre Ferrieux wrote:
>
>> TIP #304:
>
>> chan pipe ?pr pw?
>>
>> Create a pipe. If pr and pw are specified, then chan pipe will set the
>> variable named pr to contain the channel wrapping the side of the pipe that
>> was opened for reading, andpw the same for writing. Subsequently, anything
>> written to $pw will be readable on $pr. If the variables are not specified,
>> then a list containing the read and write channels is returned as the result
>> of the command.
>>
> very minor question: why not return the list of channelIds in both cases
> (i.e. even when the variable names are passed in) ?
> the return value may go used in that case but that does not hurt anything,
> and it would be more consistent with the other channel creating commands
> that always return a channelId...

The initial idea is to go hand-in-glove with existing usage with TclX.
But a much stronger argument is that I fundamentally dislike an API
yielding the same information in two places in a single call...
(personally I never [set x [incr y]] nor [set l [lappend m $x]])

-Alex

(Continue reading)

headers

Daniel A. Steffen | 30 Jun 18:08

Re: TIP 304 CFV

On 30/06/2008, at 17:58, Alexandre Ferrieux wrote:

> The initial idea is to go hand-in-glove with existing usage with TclX.

sure, but existing TclX usage will continue to work unchanged if the  
first form were to also return a result.

> But a much stronger argument is that I fundamentally dislike an API
> yielding the same information in two places in a single call...
> (personally I never [set x [incr y]] nor [set l [lappend m $x]])

you may not like it, but others certainly do, that style is  
widespread...
there is also plenty of precedent in Tcl for returning info in  
multiple places.

anyway, minor point like I said...

Cheers,

Daniel

--

-- 
** Daniel A. Steffen                   **
** <mailto:das@...>  **

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.

(Continue reading)

headers

Jeff Hobbs | 30 Jun 22:51

Re: TIP 304 CFV

Daniel A. Steffen wrote:
> On 30/06/2008, at 17:58, Alexandre Ferrieux wrote:
> 
>> The initial idea is to go hand-in-glove with existing usage with TclX.
> 
> sure, but existing TclX usage will continue to work unchanged if the  
> first form were to also return a result.
> 
>> But a much stronger argument is that I fundamentally dislike an API
>> yielding the same information in two places in a single call...
>> (personally I never [set x [incr y]] nor [set l [lappend m $x]])
> 
> 
> you may not like it, but others certainly do, that style is  
> widespread...
> there is also plenty of precedent in Tcl for returning info in  
> multiple places.

+1 agreed.  I have done [set x [incr y]] on the odd occasion as well.

Jeff

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

headers

Alexandre Ferrieux | 30 Jun 23:08

Re: TIP 304 CFV

On 6/30/08, Jeff Hobbs <jeffh@...> wrote:
> Daniel A. Steffen wrote:
> > On 30/06/2008, at 17:58, Alexandre Ferrieux wrote:
> >
> >
> > > The initial idea is to go hand-in-glove with existing usage with TclX.
> > >
> >
> > sure, but existing TclX usage will continue to work unchanged if the
> first form were to also return a result.
> >
> >
> > > But a much stronger argument is that I fundamentally dislike an API
> > > yielding the same information in two places in a single call...
> > > (personally I never [set x [incr y]] nor [set l [lappend m $x]])
> > >
> >
> >
> > you may not like it, but others certainly do, that style is  widespread...
> > there is also plenty of precedent in Tcl for returning info in  multiple
> places.
> >
>
> +1 agreed.  I have done [set x [incr y]] on the odd occasion as well.

But would you really write code like

           lassign [chan pipe pr pw] qr qw

with the dubious intent that $pr==$qr and $pw==$qw ?

(Continue reading)

headers

Fredderic Unpenstein | 1 Jul 06:49

Re: TIP 304 CFV

On 01/07/2008, Alexandre Ferrieux wrote:
> On 6/30/08, Jeff Hobbs wrote:
>> Daniel A. Steffen wrote:
>>> On 30/06/2008, at 17:58, Alexandre Ferrieux wrote:
>>>> But a much stronger argument is that I fundamentally dislike an API
>>>> yielding the same information in two places in a single call...
>>>> (personally I never [set x [incr y]] nor [set l [lappend m $x]])
>>> you may not like it, but others certainly do, that style is
>>> widespread...
>>> there is also plenty of precedent in Tcl for returning info in  multiple
>>> places.
>> +1 agreed.  I have done [set x [incr y]] on the odd occasion as well.
> But would you really write code like
>            lassign [chan pipe pr pw] qr qw
> with the dubious intent that $pr==$qr and $pw==$qw ?
> What purpose does that idiom serve ?

It's called consistency.  Imagine this:

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

headers

Fredderic Unpenstein | 1 Jul 09:21

Re: TIP 304 CFV

On 01/07/2008, Alexandre Ferrieux wrote:
> On 6/30/08, Jeff Hobbs wrote:
>> Daniel A. Steffen wrote:
>>> On 30/06/2008, at 17:58, Alexandre Ferrieux wrote:
>>>> But a much stronger argument is that I fundamentally dislike an API
>>>> yielding the same information in two places in a single call...
>>>> (personally I never [set x [incr y]] nor [set l [lappend m $x]])
>>> you may not like it, but others certainly do, that style is
>>> widespread... there is also plenty of precedent in Tcl for returning info
>>> in multiple places.
>> +1 agreed.  I have done [set x [incr y]] on the odd occasion as well.
> But would you really write code like
>            lassign [chan pipe pr pw] qr qw

On first glance, I agree.  It does seem kind of odd.

On one hand, it's called consistency, which is worth while as long as
it doesn't complicate the implementation.

On the other, there are plenty of times when it makes sense to keep a
value in two places, because one of them may get changed, or simply
because you need the information in two different forms.

I can envision people sticking the returned list into a list or
variable to be returned, and doing something similar to what people do
with the first return var of [regexp], that is, shoving it in a
variable that looks more like a syntactic token, and not taking any
further notice of it.

It's a good thing, and I can't envision a single reason not to, other

(Continue reading)

headers

Donal K. Fellows | 1 Jul 10:03

Re: TIP 304 CFV

Jeff Hobbs wrote:
> Daniel A. Steffen wrote:
>> you may not like it, but others certainly do, that style is  
>> widespread...
>> there is also plenty of precedent in Tcl for returning info in  
>> multiple places.
> 
> +1 agreed.  I have done [set x [incr y]] on the odd occasion as well.

It seems that this TIP needs a little longer before everyone decides
whether it is fully baked. BTW, one argument in favour of only returning
the channels is that all the other commands that create channels (i.e.
[open], [socket]) only return them.

Donal.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

headers

Alexandre Ferrieux | 1 Jul 10:47

Re: TIP 304 CFV

On Tue, Jul 1, 2008 at 10:03 AM, Donal K. Fellows
<donal.k.fellows@...> wrote:
> Jeff Hobbs wrote:
>> Daniel A. Steffen wrote:
>>> you may not like it, but others certainly do, that style is
>>> widespread...
>>> there is also plenty of precedent in Tcl for returning info in
>>> multiple places.
>>
>> +1 agreed.  I have done [set x [incr y]] on the odd occasion as well.
>
> It seems that this TIP needs a little longer before everyone decides
> whether it is fully baked.

Ouch. Delay again, for something like this, after so many weeks of
silence ? Daniel himself mentions a "minor point", and it ends up as a
veto...  I really don't understand.

I'm happy to yield instantly to whatever funky syntax anyone wants to
put forward now: the only important part of the TIP is to plug a basic
OS-related need.

-Alex

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

(Continue reading)

headers

Kevin Kenny | 2 Jul 02:41

Re: TIP 304 CFV

> Ouch. Delay again, for something like this, after so many weeks of
> silence ? Daniel himself mentions a "minor point", and it ends up as a
> veto...  I really don't understand.

Don't think of it as a veto.  It sounded as if you needed to
edit the TIP either to clarify what the return value is, or
to change it to return the two channels at the ends of the pipe.
You can do it quickly, announce that you've done it, and wait
a couple of days for comments.

The reason for this is that we really, really want to know
what we're voting on; hence, we allow *no* changes to a TIP
when the vote is in progress.  Even minor projected changes
are enough to delay the vote. (But they can be done quickly,
so they don't need to delay it *much*.)

--

-- 
73 de ke9tv/2, Kevin

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

headers

Alexandre Ferrieux | 2 Jul 12:29

Re: TIP 304 CFV

On Wed, Jul 2, 2008 at 2:41 AM, Kevin Kenny <kennykb@...> wrote:
>> Ouch. Delay again, for something like this, after so many weeks of
>> silence ? Daniel himself mentions a "minor point", and it ends up as a
>> veto...  I really don't understand.
>
> Don't think of it as a veto.  It sounded as if you needed to
> edit the TIP either to clarify what the return value is, or
> to change it to return the two channels at the ends of the pipe.
> You can do it quickly, announce that you've done it, and wait
> a couple of days for comments.
>
> The reason for this is that we really, really want to know
> what we're voting on; hence, we allow *no* changes to a TIP
> when the vote is in progress.  Even minor projected changes
> are enough to delay the vote. (But they can be done quickly,
> so they don't need to delay it *much*.)

OK. Then let's run a poll to decide in what direction the TIP should evolve:
Please, all, give your choice 1-3 between:

  1) [chan pipe pr pw] returns {} and [chan pipe] returns [list $pr
$pw] (TclX, current TIP)

  2) both return [list $pr $pw] (Daniel's suggestion)

  3) [chan pipe pr pw] is removed, hence only allowed single idiom
[lassign [chan pipe] pr pw] (Freddie's suggestion)

I'd advocate (1) of course, with  a second choice of (3). The reason
is that (1) is motivated by legacy (TclX) and a slightly higher

(Continue reading)

headers

Neil Madden | 2 Jul 13:09

Re: TIP 304 CFV

On 2 Jul 2008, at 11:29, Alexandre Ferrieux wrote:
> On Wed, Jul 2, 2008 at 2:41 AM, Kevin Kenny  
> <kennykb@...> wrote:
>>> Ouch. Delay again, for something like this, after so many weeks of
>>> silence ? Daniel himself mentions a "minor point", and it ends up  
>>> as a
>>> veto...  I really don't understand.
>>
>> Don't think of it as a veto.  It sounded as if you needed to
>> edit the TIP either to clarify what the return value is, or
>> to change it to return the two channels at the ends of the pipe.
>> You can do it quickly, announce that you've done it, and wait
>> a couple of days for comments.
>>
>> The reason for this is that we really, really want to know
>> what we're voting on; hence, we allow *no* changes to a TIP
>> when the vote is in progress.  Even minor projected changes
>> are enough to delay the vote. (But they can be done quickly,
>> so they don't need to delay it *much*.)
>
> OK. Then let's run a poll to decide in what direction the TIP  
> should evolve:
> Please, all, give your choice 1-3 between:
>
>   1) [chan pipe pr pw] returns {} and [chan pipe] returns [list $pr
> $pw] (TclX, current TIP)

Is there some more useful bit of info than just "" that could be  
returned here? E.g. like [gets], which returns the num bytes read  
when a varName is supplied.

(Continue reading)

headers

Kevin Kenny | 2 Jul 13:21

Re: TIP 304 CFV

Alexandre Ferrieux:
>> OK. Then let's run a poll to decide in what direction the TIP should 
>> evolve:
>> Please, all, give your choice 1-3 between:
>>
>>   1) [chan pipe pr pw] returns {} and [chan pipe] returns [list $pr
>> $pw] (TclX, current TIP)
> 
> Is there some more useful bit of info than just "" that could be 
> returned here? E.g. like [gets], which returns the num bytes read when a 
> varName is supplied.
> 
>>   2) both return [list $pr $pw] (Daniel's suggestion)
>>
>>   3) [chan pipe pr pw] is removed, hence only allowed single idiom
>> [lassign [chan pipe] pr pw] (Freddie's suggestion)

Neil Madden:
> I don't think there's a significant difference between these proposals 
> -- just minor syntax variations. It seems that each is capable of 
> trivially implementing the others. So I'd say just pick whichever you 
> prefer and go with it.

My preference is (3), second choice (2) - but this is indeed a
bikeshed argument. None of the choices is bad enough to make me
vote against the TIP on that ground.

--

-- 
73 de ke9tv/2, Kevin

(Continue reading)

headers

Donal K. Fellows | 2 Jul 14:29

Re: TIP 304 CFV

Kevin Kenny wrote:
> My preference is (3), second choice (2) - but this is indeed a
> bikeshed argument. None of the choices is bad enough to make me
> vote against the TIP on that ground.

Agreed. On all points.

Donal.

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

headers

miguel sofer | 2 Jul 14:32

Re: TIP 304 CFV

Donal K. Fellows wrote:
> Kevin Kenny wrote:
>> My preference is (3), second choice (2) - but this is indeed a
>> bikeshed argument. None of the choices is bad enough to make me
>> vote against the TIP on that ground.
> 
> Agreed. On all points.
> 
> Donal.

Yeah ... where do I sign?

Miguel (who prefers commands returning values instead of setting variables)

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

headers

Alexandre Ferrieux | 2 Jul 15:10

Re: TIP 304 CFV

On Wed, Jul 2, 2008 at 2:32 PM, miguel sofer <miguel.sofer@...> wrote:
> Donal K. Fellows wrote:
>> Kevin Kenny wrote:
>>> My preference is (3), second choice (2) - but this is indeed a
>>> bikeshed argument. None of the choices is bad enough to make me
>>> vote against the TIP on that ground.
>>
>> Agreed. On all points.
>>
>> Donal.
>
> Yeah ... where do I sign?
>
> Miguel (who prefers commands returning values instead of setting variables)

Thanks to you all for this quick convergence 
Therefore I will go for (3): clean, simple, consensual.
Will tell you as soon as TIP and patch are up to date.

-Alex

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

headers

Alexandre Ferrieux | 2 Jul 16:19

Re: TIP 304 CFV

Hello again,

On Wed, Jul 2, 2008 at 3:10 PM, Alexandre Ferrieux
<alexandre.ferrieux@...> wrote:
> Thanks to you all for this quick convergence 
> Therefore I will go for (3): clean, simple, consensual.
> Will tell you as soon as TIP and patch are up to date.

Now TIP 304 and reference implementation are in sync with the consensus.
Would respectfully appreciate a CFV now, because I'll be offline from
next Tuesday to July 21st 

TIA,

-Alex

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

headers

Jeff Hobbs | 2 Jul 20:53

TIP 304 repeat CFV "A Standalone [chan pipe] Primitive"

Updated by Alex (thanks!) and ready for voting:

   TIP #304: A Standalone [chan pipe] Primitive for Advanced Child IPC
   http://tip.tcl.tk/304

I know most people have stated positive preference already, but please 
just repeat here for the official tally.

   Close time: Wed, July 9th, 12:00pm PDT

TIP#304: YES

Jeff

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

headers

Jan Nijtmans | 2 Jul 21:43

Re: TIP 304 repeat CFV "A Standalone [chan pipe] Primitive"

2008/7/2, Jeff Hobbs <jeffh@...>:
>   TIP #304: A Standalone [chan pipe] Primitive for Advanced Child IPC
>   http://tip.tcl.tk/304

TIP#304: YES

Regards,
         Jan Nijtmans

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

headers

Donald G Porter | 2 Jul 22:33

Re: TIP 304 repeat CFV "A Standalone [chan pipe] Primitive"


Jeff Hobbs wrote:
>    TIP #304: A Standalone [chan pipe] Primitive for Advanced Child IPC
>    http://tip.tcl.tk/304

If this is already answered in the TIP, just point me back there.

Hoping someone can summarize which items on the long list of
defects in [exec] get addressed by this, and which do not.

Thanks!

--

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

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

headers

Jeff Hobbs | 2 Jul 22:45

Re: TIP 304 repeat CFV "A Standalone [chan pipe] Primitive"

Donald G Porter wrote:
> Jeff Hobbs wrote:
>>    TIP #304: A Standalone [chan pipe] Primitive for Advanced Child IPC
>>    http://tip.tcl.tk/304
> 
> If this is already answered in the TIP, just point me back there.
> 
> Hoping someone can summarize which items on the long list of
> defects in [exec] get addressed by this, and which do not.

I don't think it hits all the issues, but the "Additional Benefits" 
section does discuss some ramifications for [exec], as well as future 
work possibilities.  I don't think the TIP author should be accountable 
for covering things not dealt with (that would be a very, very long 
list).  ;)

Jeff

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

headers

Donal K. Fellows | 3 Jul 01:32

Re: TIP 304 repeat CFV "A Standalone [chan pipe] Primitive"

Jeff Hobbs wrote:
>    TIP #304: A Standalone [chan pipe] Primitive for Advanced Child IPC
>    http://tip.tcl.tk/304

TIP #304: YES

(It took a few iterations, but it's a good 'un now.)

Donal.

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

headers

Jeff Hobbs | 10 Jul 01:06

TIP 304 Passed

TIP #304 has passed.

YES:     JH, MS, JN, JE, DKF, KK
NO:      None
ABSTAIN: None

Apologies if I missed a vote, but the result would be unchanged.  Alex - 
please feel free to commit this to the HEAD at your convenience.

Thanks,

Jeff

Jeff Hobbs wrote:
> Updated by Alex (thanks!) and ready for voting:
> 
>    TIP #304: A Standalone [chan pipe] Primitive for Advanced Child IPC
>    http://tip.tcl.tk/304
> 
> I know most people have stated positive preference already, but please 
> just repeat here for the official tally.
> 
>    Close time: Wed, July 9th, 12:00pm PDT

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

(Continue reading)

headers

Joe English | 2 Jul 22:51

Re: TIP 304 repeat CFV "A Standalone [chan pipe] Primitive"


TIP #304 (Revision 1.12): YES.

--Joe English

  jenglish@...

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

headers

Kevin Kenny | 3 Jul 05:11

Re: TIP 304 CFV

TIP#304: YES

I like green for the bikeshed, too, let's go with it.

--

-- 
73 de ke9tv/2, Kevin

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

headers

Joe English | 2 Jul 18:06

Re: TIP 304 CFV


Kevin Kenny wrote:
>
> >>   1) [chan pipe pr pw] returns {} and [chan pipe] returns [list $pr
> >> $pw] (TclX, current TIP)
> >>   2) both return [list $pr $pw] (Daniel's suggestion)
> >>   3) [chan pipe pr pw] is removed, hence only allowed single idiom
> >> [lassign [chan pipe] pr pw] (Freddie's suggestion)
>
> My preference is (3), second choice (2) - but this is indeed a
> bikeshed argument. None of the choices is bad enough to make me
> vote against the TIP on that ground.

Ditto.  #3, followed by #2, followed by #1; all are
acceptable; and this is a bikeshed.

--JE

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

headers

Jeff Hobbs | 2 Jul 20:49

Re: TIP 304 CFV

Joe English wrote:
> Kevin Kenny wrote:
>>>>   1) [chan pipe pr pw] returns {} and [chan pipe] returns [list $pr
>>>> $pw] (TclX, current TIP)
>>>>   2) both return [list $pr $pw] (Daniel's suggestion)
>>>>   3) [chan pipe pr pw] is removed, hence only allowed single idiom
>>>> [lassign [chan pipe] pr pw] (Freddie's suggestion)
>> My preference is (3), second choice (2) - but this is indeed a
>> bikeshed argument. None of the choices is bad enough to make me
>> vote against the TIP on that ground.
> 
> Ditto.  #3, followed by #2, followed by #1; all are
> acceptable; and this is a bikeshed.

Ditto above.  I like green.

While TclX compatibility is "nice", fitting in with the core is best. 
It is already being called [chan pipe], and it is only a one liner to 
make the compat function.

Jeff

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

headers

Fredderic Unpenstein | 2 Jul 10:25

Re: TIP 304 CFV

On 01/07/2008, Alexandre Ferrieux wrote:
> On Tue, Jul 1, 2008 at 10:03 AM, Donal K. Fellows wrote:
>> Jeff Hobbs wrote:
>>> Daniel A. Steffen wrote:
>>>> there is also plenty of precedent in Tcl for returning info in multiple
>>>> places.
>>> +1 agreed.  I have done [set x [incr y]] on the odd occasion as well.
>> It seems that this TIP needs a little longer before everyone decides
>> whether it is fully baked.
> Ouch. Delay again, for something like this, after so many weeks of
> silence ? Daniel himself mentions a "minor point", and it ends up as a
> veto...  I really don't understand.

Life's so cruel sometimes...  ;)

But seriously, right now as the CFV is being pushed, the issue is
stable and people can see it in its entirety.

> I'm happy to yield instantly to whatever funky syntax anyone wants to
> put forward now: the only important part of the TIP is to plug a basic
> OS-related need.

Returning the list of handles is simply more useful.  You can stash it
away for later, [lassign] it out immediately, pluck out just one half
and [fconfigure] before handing the whole response back, whatever.
Plus, it leaves room for arguments to be added later.  What's "yucky"
about that?

Would it be so bizarre to call an open multiple-choice vote?

(Continue reading)