MIME-Version: 1.0
Return-Path: bluepeak.westend.com!popeye
Return-Path: <popeye@bluepeak.westend.com>
Received: from popeye.bluepeak.westend.com by bluepeak  with smtp
	(Smail3.2 #1) id m11UMzR-00027eC; Fri, 24 Sep 1999 06:29:45 +0200 (MEST)
Received: from genesis for a.kupries
 with Cubic Circle's cucipop (v1.10 1996/09/06) Fri Sep 24 06:24:26 1999
Received: from ficus.frogspace.net (root@[216.65.97.3] (may be forged))
	by genesis.westend.com (8.8.6/8.8.6) with ESMTP id FAA21406
	for <a.kupries@westend.com>; Fri, 24 Sep 1999 05:37:33 +0200 (MET DST)
Received: from [208.244.224.65] (helo=host65.novadigm.com)
	by ficus.frogspace.net with smtp (Exim 3.02 #1)
	id 11ULuq-0001hg-00; Thu, 23 Sep 1999 23:20:56 -0400
Received: from LAPCAT by host65.novadigm.com
          via smtpd (for [216.65.97.216]) with SMTP; 24 Sep 1999 03:46:17 UT
X-From_: matt@sensus.org  Fri Sep 24 05:37:35 1999
Message-ID: <003f01bf063e$150bff30$b3e6f4d0@lapcat>
From: "Matt Newman" <matt@sensus.org>
To: "Matt Newman" <matt@novadigm.com>,
        "Andreas Kupries" <a.kupries@westend.com>
Cc: "Jean-Claude Wippler" <jcw@equi4.com>
Subject: Re: [trf1.8] Support for Seek on FD
Date: Thu, 23 Sep 1999 23:36:59 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
              charset="iso-8859-1"

More on the flush-causes GPF issue.

Try this:

set data [info comm]
set fd [open foo w]
set fd [zip -attach $fd -mode compress]
puts -nonewline $fd $data
flush $fd
flush $fd
close $fd

The second flush causes an error followed by a GPF.

Matt Newman
-----Original Message-----
From: Matt Newman <matt@novadigm.com>
To: Matt Newman <matt@sensus.org>; Andreas Kupries <a.kupries@westend.com>
Cc: Jean-Claude Wippler <jcw@equi4.com>
Date: Thursday, September 23, 1999 10:25 PM
Subject: Re: [trf1.8] Support for Seek on FD


>I have attached some patches to registry.c - they return the running
>position in the stream and also have the side effect of disabling anything
>other than Tcl_Seek(ch, 0, SEEK_CUR)
>
>Let me know your thoughts on this.
>
>Matt Newman
>-----Original Message-----
>From: Matt Newman <matt@sensus.org>
>To: Andreas Kupries <a.kupries@westend.com>
>Cc: Jean-Claude Wippler <jcw@equi4.com>
>Date: Thursday, September 23, 1999 10:15 PM
>Subject: [trf1.8] Support for Seek on FD
>
>
>>I have been grapping with a problem using the zip compression method and
>>wanted to share my thoughts.
>>
>>A normal Tcl paradigm is to do
>>
>>set fd [open foo w]
>>puts $fd data
>>close $fd
>>set size [file size foo]
>>
>>But in the case of any form of transformation it is quite often nice to
>know
>>the pre-transformation size - i.e. in the case of zip the uncompressed
>size.
>>Now you can normally tell howmuch data has been written to a channel by
>>doing
>>
>>set fd [open foo w]
>>puts $fd data
>>flush $fd
>>set size [tell $fd]
>>close $fd
>>
>>(If the channel supports seeks)
>>
>>However when you do this with the Trf channels two problems raise their
>ugly
>>heads....
>>
>>1) Calling [tell] before the flush seems to brake the channel in some way
>>(try it out - reverse the flush & tell)
>>
>>2) The registry.c SeekProc calls the underlying channel's SeekProc.
>>
>>The later is not correct under almost all non 1-1 transformations, since
>>offsets (sizes) may be different on each side of the transformation.
>>
>>This also has the side effect that [tell] on a transformed FD returns the
>>underlying offset, not the pre-transform offset.
>>
>>It occured to me that the Seek support may need to be different for
>>different types of transform, instead of the single generic one in
>>registry.c
>>
>>One simple situtation I could propose would be that the registry.c code
>>maintain a byte-count and only support Tcl_Seek(ch, 0, SEEK_CUR) which is
>>what [tell] uses - and throws an error in all other cases - at least for
>>writing this would give me a very simple way of getting the pre-transform
>>byte-count.
>>
>>What do you think?
>>
>>Matt Newman
>>
>>PS. My "real" need is to know the pre and post compression sizes - but
this
>>need would hold true for all other transforms too.
>>
>
