gmane.comp.lang.tcl.core

Andreas Leitgeb | 24 Sep 10:24

TIP 301 obsolescence (Was: TIPs I'd like to see done)

"Alexandre Ferrieux" <alexandre.ferrieux@...> wrote:
> With 304, it is now trivially done:
>       lassign [chan pipe] pr pw
>       set ch [open "|cmd <@ $pr" r]
>       close $pr
>       ...
>       close $pw
>       set final_word [read $ch]

IMHO, splitting channels just for solving this problem
was an entirely wrong approach.   I'm not opposing the
idea of "chan pipe", but I just think it's a bad solution 
for the original problem.

Just compare the above-quoted kludge with how a concise
solution could have worked out:
   set ch [open "|cmd" r+]; # puts $ch ...
   close -w $ch  ;#  or whatever other color for the bikeshed
   set final_words [read $ch]
   close $ch
Between the two "close"s, the channel would behave as
if it had originally been opened with "r"

Btw., has there ever been any reasonable usecase for
closing just the read-side but still allowing to write?

> I said "almost" because there is also the important case of sockets
> and the shutdown() syscall, allowing to close independently halves of
> its duplex channel.

(Continue reading)

Donal K. Fellows | 24 Sep 11:20

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

Andreas Leitgeb wrote:
>> If those far-fetched alternative justifications are invalid, I propose
>> to withdraw #301 and write another TIP to encapsulate
>> shutdown(socket,direction)?
> 
> Or just the general "halfway" close, that was originally proposed.

That would be useful for dealing with the current bidirectional
"pipeline" case as well; a number of applications that we might
otherwise want to wrap up need to have their input closed before they
produce output. Right now we can do awkward workarounds, but just being
able to drop from read-write to read-only (or write-only I suppose) will
be simpler for many cases. This doesn't make [chan pipe] obsolete
though; more complex situations will need the additional power.

Donal.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Alexandre Ferrieux | 24 Sep 14:11

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

On Wed, Sep 24, 2008 at 11:20 AM, Donal K. Fellows
<donal.k.fellows@...> wrote:
> Andreas Leitgeb wrote:
>>> If those far-fetched alternative justifications are invalid, I propose
>>> to withdraw #301 and write another TIP to encapsulate
>>> shutdown(socket,direction)?
>>
>> Or just the general "halfway" close, that was originally proposed.
>
> That would be useful for dealing with the current bidirectional
> "pipeline" case as well;

OK. Then, do I modify the TIP in-place or do we withdraw it and
allocate a fresh number ?

Also, regarding the implementation: sinc this would require a generic
evolution, do you have guidelines to minimize the ABI compatibility
breakage of changing the Channel vector-of-funcs ?

-Alex

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Donal K. Fellows | 24 Sep 15:41

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

Alexandre Ferrieux wrote:
> OK. Then, do I modify the TIP in-place or do we withdraw it and
> allocate a fresh number ?

I think it's probably easier to do a new TIP. I'm happy to set it to
obsolete #301.

> Also, regarding the implementation: sinc this would require a generic
> evolution, do you have guidelines to minimize the ABI compatibility
> breakage of changing the Channel vector-of-funcs ?

No. I have no guidelines; it's not a part of the core I focus on. 

Donal.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Alexandre Ferrieux | 24 Sep 22:41

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

On Wed, Sep 24, 2008 at 3:41 PM, Donal K. Fellows
<donal.k.fellows@...> wrote:
>
> I think it's probably easier to do a new TIP. I'm happy to set it to
> obsolete #301.
>

OK. A few last things to settle before the new TIP:

 - proposed script API:

      (a)  [close -r|-w $ch] and [chan close -r|-w $ch]
      (b)  [chan halfclose $ch r|w]

 - semantics of full close

      (c) make the channel vanish after [close -r] and close [-w]
      (d) consider half closes as mere signals, so a true [close $ch]
is still needed

Notice that (a) is more natural with (c), and ipso facto (b) with (d)
because distinct verbs remind of orthogonal semantics.
I have a preference for (d) because it preserves robust cleanup
procedures doing [close $ch] regardless of the completion of the task
at hand.
So my initial bet would be (b),(d). But I'm open to arguments.

-Alex

-------------------------------------------------------------------------

(Continue reading)

Jeff Hobbs | 24 Sep 23:10

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

Alexandre Ferrieux wrote:
> OK. A few last things to settle before the new TIP:
> 
>  - proposed script API:
> 
>       (a)  [close -r|-w $ch] and [chan close -r|-w $ch]
>       (b)  [chan halfclose $ch r|w]
> 
>  - semantics of full close
> 
>       (c) make the channel vanish after [close -r] and close [-w]
>       (d) consider half closes as mere signals, so a true [close $ch]
> is still needed
> 
> Notice that (a) is more natural with (c), and ipso facto (b) with (d)
> because distinct verbs remind of orthogonal semantics.
> I have a preference for (d) because it preserves robust cleanup
> procedures doing [close $ch] regardless of the completion of the task
> at hand.
> So my initial bet would be (b),(d). But I'm open to arguments.

I think the best partial close api is:

	[chan close $ch ?r|w?]

with semantics being that any partial close leaving an open r|w can be 
closed by either another partial close request of the remaining pipe, or 
with a simple [chan close $ch], which closes whatever is open.

Jeff

(Continue reading)

Alexandre Ferrieux | 24 Sep 23:19

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

On Wed, Sep 24, 2008 at 11:10 PM, Jeff Hobbs <jeffh@...> wrote:
>
> I think the best partial close api is:
>
>        [chan close $ch ?r|w?]
>
> with semantics being that any partial close leaving an open r|w can be
> closed by either another partial close request of the remaining pipe, or
> with a simple [chan close $ch], which closes whatever is open.

OK that's (a.3)+(c), then. We seem to have unanimity among the
(expressed) ballots in the TCT 

Now a few minor points:

   - Do we also allow [close $ch r|w] without the [chan] prefix ?
   - Does a half-close of (the proper side of) a mono-directional
channel just close, or raise an error ?

-Alex

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Jeff Hobbs | 24 Sep 23:22

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

Alexandre Ferrieux wrote:
> On Wed, Sep 24, 2008 at 11:10 PM, Jeff Hobbs <jeffh@...> wrote:
>> I think the best partial close api is:
>>
>>        [chan close $ch ?r|w?]
>>
>> with semantics being that any partial close leaving an open r|w can be
>> closed by either another partial close request of the remaining pipe, or
>> with a simple [chan close $ch], which closes whatever is open.
> 
> OK that's (a.3)+(c), then. We seem to have unanimity among the
> (expressed) ballots in the TCT 
> 
> Now a few minor points:
> 
>    - Do we also allow [close $ch r|w] without the [chan] prefix ?

I believe this is a moot point as they are one and the same 
implementation (one points to the other).

>    - Does a half-close of (the proper side of) a mono-directional
> channel just close, or raise an error ?

Good question ... closing something that isn't open is an error 
currently.  I think it should remain so for half-closes of non-open halves.

Jeff

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge

(Continue reading)

Alexandre Ferrieux | 24 Sep 23:29

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

On Wed, Sep 24, 2008 at 11:22 PM, Jeff Hobbs <jeffh@...> wrote:
>>
>>   - Do we also allow [close $ch r|w] without the [chan] prefix ?
>
> I believe this is a moot point as they are one and the same implementation
> (one points to the other).

Well, it should still be settled as the TIP gives the script API. I
propose to offer both.

>>   - Does a half-close of (the proper side of) a mono-directional
>> channel just close, or raise an error ?
>
> Good question ... closing something that isn't open is an error currently.
>  I think it should remain so for half-closes of non-open halves.

Of course; my question was rather about the other side: the one that
is actually open.
I propose to still raise an error because a half-close on a
monodirectional channel indicates a false assumption on the channel's
nature.

-Alex

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

(Continue reading)

dgp | 25 Sep 04:51

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

Quoting "Alexandre Ferrieux" <alexandre.ferrieux@...>:
> ... We seem to have unanimity among the
> (expressed) ballots in the TCT 

If you require a nose count as well as just feedback,
put me down for "Jeff is correct".

DGP

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Joe English | 24 Sep 23:49

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

Alexandre Ferrieux wrote:
> > I think the best partial close api is:
> >
> >        [chan close $ch ?r|w?]
> >
> > with semantics being that any partial close leaving an open r|w can be
> > closed by either another partial close request of the remaining pipe, or
> > with a simple [chan close $ch], which closes whatever is open.
>
> OK that's (a.3)+(c), then. We seem to have unanimity among the
> (expressed) ballots in the TCT 
>
> Now a few minor points:
>
>    - Do we also allow [close $ch r|w] without the [chan] prefix ?

I'd say no, don't bother.

>    - Does a half-close of (the proper side of) a mono-directional
> channel just close, or raise an error ?

Another question: what should [chan close $f r] do
if $f is not a socket?

Ordinary Unix file descriptors don't have a notion of "half-closedness",
and the shutdown(2) system call only works on sockets.
Don't know how Windows handles this, but I'd expect something
similar.

(Continue reading)

Alexandre Ferrieux | 25 Sep 00:47

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

On Wed, Sep 24, 2008 at 11:49 PM, Joe English <jenglish@...> wrote:
>
>>    - Do we also allow [close $ch r|w] without the [chan] prefix ?
>
> I'd say no, don't bother.

Well, Jeff pointed out that currently [chan close] is just an alias of
[close], so breaking the symmetry would cost more than keeping it. He
certainly has a point.

> Another question: what should [chan close $f r] do
> if $f is not a socket?
> Ordinary Unix file descriptors don't have a notion of "half-closedness",
> and the shutdown(2) system call only works on sockets.
> Don't know how Windows handles this, but I'd expect something
> similar.

You're right that the shutdown() syscall (and its equivalent on
Windows) works only on sockets, but since we are providing an
abstraction layer we can generalize.
The "bidirectional" channel of a command pipeline is indeed purely in
Tcl's mind, so we do the right thing in this case (use close() on
individual fds).
Another interesting case could be serial devices, but I don't know (a)
if it is possible to open the same port separately in read and write
mode and (b) if it makes any difference on the other side if one half
is close.

Now for purely monodirectional things like regular files, or a single
end of a [chan pipe], we've just discussed that with Jeff. He seems to

(Continue reading)

Jeff Hobbs | 24 Sep 22:57

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

Alexandre Ferrieux wrote:
> On Wed, Sep 24, 2008 at 3:41 PM, Donal K. Fellows
> <donal.k.fellows@...> wrote:
>> I think it's probably easier to do a new TIP. I'm happy to set it to
>> obsolete #301.
>>
> 
> OK. A few last things to settle before the new TIP:
> 
>  - proposed script API:
> 
>       (a)  [close -r|-w $ch] and [chan close -r|-w $ch]
>       (b)  [chan halfclose $ch r|w]

       (b.2)  [chan close $ch ?read|write?]

>  - semantics of full close
> 
>       (c) make the channel vanish after [close -r] and close [-w]
>       (d) consider half closes as mere signals, so a true [close $ch]
> is still needed
> 
> Notice that (a) is more natural with (c), and ipso facto (b) with (d)
> because distinct verbs remind of orthogonal semantics.
> I have a preference for (d) because it preserves robust cleanup
> procedures doing [close $ch] regardless of the completion of the task
> at hand.
> So my initial bet would be (b),(d). But I'm open to arguments.

Jeff

(Continue reading)

Alexandre Ferrieux | 24 Sep 22:59

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

On Wed, Sep 24, 2008 at 10:57 PM, Jeff Hobbs <jeffh@...> wrote:
> Alexandre Ferrieux wrote:
>>
>> On Wed, Sep 24, 2008 at 3:41 PM, Donal K. Fellows
>> <donal.k.fellows@...> wrote:
>>>
>>> I think it's probably easier to do a new TIP. I'm happy to set it to
>>> obsolete #301.
>>>
>>
>> OK. A few last things to settle before the new TIP:
>>
>>  - proposed script API:
>>
>>      (a)  [close -r|-w $ch] and [chan close -r|-w $ch]
>>      (b)  [chan halfclose $ch r|w]
>
>      (b.2)  [chan close $ch ?read|write?]

It would be (a.2) then: (b) is distinguished by a different verb (halfclose).
May I suggest also

        (a.3)  [chan close $ch ?r|w?] (by symmetry with [open])

-Alex

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world

(Continue reading)

Jeff Hobbs | 24 Sep 23:02

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

Alexandre Ferrieux wrote:
> On Wed, Sep 24, 2008 at 10:57 PM, Jeff Hobbs <jeffh@...> wrote:
>> Alexandre Ferrieux wrote:
>>> On Wed, Sep 24, 2008 at 3:41 PM, Donal K. Fellows
>>> <donal.k.fellows@...> wrote:
>>>> I think it's probably easier to do a new TIP. I'm happy to set it to
>>>> obsolete #301.
>>>>
>>> OK. A few last things to settle before the new TIP:
>>>
>>>  - proposed script API:
>>>
>>>      (a)  [close -r|-w $ch] and [chan close -r|-w $ch]
>>>      (b)  [chan halfclose $ch r|w]
>>      (b.2)  [chan close $ch ?read|write?]
> 
> It would be (a.2) then: (b) is distinguished by a different verb (halfclose).
> May I suggest also
> 
>         (a.3)  [chan close $ch ?r|w?] (by symmetry with [open])

I was invalidating (b) completely because it was unnecessary to create 
another verb.  Calling it a.3 is fine as well, but it's the one that 
makes sense for symmetry reasons.

Jeff

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes

(Continue reading)

Alexandre Ferrieux | 24 Sep 23:05

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

On Wed, Sep 24, 2008 at 11:02 PM, Jeff Hobbs <jeffh@...> wrote:
>>
>>        (a.3)  [chan close $ch ?r|w?] (by symmetry with [open])
>
> I was invalidating (b) completely because it was unnecessary to create
> another verb.  Calling it a.3 is fine as well, but it's the one that makes
> sense for symmetry reasons.

The reason why I proposed a new verb (which is really not my teacup
usually  was to remind the programmer of the necessity of a [close]
anyway, under assumption (d). Can you then give your opinion on (c)
vs. (d) ?

-Alex

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Donal K. Fellows | 25 Sep 10:39

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

Alexandre Ferrieux wrote:
> Jeff Hobbs wrote:
>> Alexandre Ferrieux wrote:
>>>      (a)  [close -r|-w $ch] and [chan close -r|-w $ch]
>>>      (b)  [chan halfclose $ch r|w]
>>      (b.2)  [chan close $ch ?read|write?]
> 
> It would be (a.2) then: (b) is distinguished by a different verb (halfclose).
> May I suggest also
> 
>         (a.3)  [chan close $ch ?r|w?] (by symmetry with [open])

Write them out in full, but allow abbreviation. Just because [open] does
something else doesn't mean that we need to propagate that. Allowing
abbreviation of literals is quite a common Tcl idiom.

Which means I support b.2, and note that a.3 would be a way you could
write it in a script. 

Donal.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Jeff Hobbs | 25 Sep 20:39

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

Donal K. Fellows wrote:
> Alexandre Ferrieux wrote:
>> Jeff Hobbs wrote:
>>> Alexandre Ferrieux wrote:
>>>>      (a)  [close -r|-w $ch] and [chan close -r|-w $ch]
>>>>      (b)  [chan halfclose $ch r|w]
>>>      (b.2)  [chan close $ch ?read|write?]
>> It would be (a.2) then: (b) is distinguished by a different verb (halfclose).
>> May I suggest also
>>
>>         (a.3)  [chan close $ch ?r|w?] (by symmetry with [open])
> 
> Write them out in full, but allow abbreviation. Just because [open] does
> something else doesn't mean that we need to propagate that. Allowing
> abbreviation of literals is quite a common Tcl idiom.
> 
> Which means I support b.2, and note that a.3 would be a way you could
> write it in a script. 

In looking at this, I wanted the expanded, but symmetry with open can be 
taken to the literal extreme:

	set fid [open $file rw]
	chan close $fid rw  ; # equiv to having no rw

In this case, I do with perfect symmetry over idiosyncrasies.

Jeff

-------------------------------------------------------------------------

(Continue reading)

Alexandre Ferrieux | 25 Sep 23:18

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

On Thu, Sep 25, 2008 at 8:39 PM, Jeff Hobbs <jeffh@...> wrote:
>
> In looking at this, I wanted the expanded, but symmetry with open can be
> taken to the literal extreme:
>
>        set fid [open $file rw]
>        chan close $fid rw  ; # equiv to having no rw
>
> In this case, I do with perfect symmetry over idiosyncrasies.

I do like symmetry too, but I'm not too happy about giving yet another
syntax to an already covered semantics :-}
So, count me as agnostic on this one. I'll comply with the majority.
Nose count ?

-Alex

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Reinhard Max | 25 Sep 23:30

Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)


On Thu, 25 Sep 2008 at 20:39, Jeff Hobbs wrote:

> In looking at this, I wanted the expanded, but symmetry with open 
> can be taken to the literal extreme:
>
> 	set fid [open $file rw]
> 	chan close $fid rw  ; # equiv to having no rw

What symmetry?

% open /tmp/foo rw
illegal access mode "rw"
% info patch
8.6a3

cu
 	Reinhard

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Return

Return to gmane.comp.lang.tcl.core.

Advertisement

Project Web Page

Tcl Core Team discussions about Tcl development

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane