>> Well, the problem is how do you handle partial writes? Is there a
>> case in which an error occurs but the caller would want to know how much
>> data was successfully written? If not, you could just change the
>> interface to return a boolean 1 (all data successfully written) or 0
>> (err
On 12/5/06, Andrew Church <[EMAIL PROTECTED]> wrote:
>Looks that the right thing to do is to make tc_pwrite (and family) to
>return -1 if errno != EINTR happens.
>(Andrew, any objections?)
Well, the problem is how do you handle partial writes? Is there a
case in which an error occurs but t
>Looks that the right thing to do is to make tc_pwrite (and family) to
>return -1 if errno != EINTR happens.
>(Andrew, any objections?)
Well, the problem is how do you handle partial writes? Is there a
case in which an error occurs but the caller would want to know how much
data was successf
>Looks quite nice but this require much heavier changes that I've planned.
>I'm still wondering if having I/O code as plugin make fully sense given
>current and foreseable architecture (I'm afraid of plugin method explosion;
>reorganizing plugin in classes -in case- will surely NOT happen for 1.1.0
>Yes, transcode should definitely handle globbing.
>I think this is the way most commandline programs works and the users are used
>to it.
Technically speaking, it's the shell that handles globbing; when you
do something like "cat *", the shell expands "*" to all of the filesnames
in the dire
On Tue, 5 Dec 2006 08:29:04 -0800
"Scott Smith" <[EMAIL PROTECTED]> wrote:
[...]
> Ok, but there's a bug in tc_pwrite, or in the way it's being used.
> The return value of tc_pwrite is the number of bytes written. It is
> never less than that; there is no special case to return a negative
> numbe
On Tue, 5 Dec 2006 22:08:59 +0100 (MET)
Thomas Wehrspann <[EMAIL PROTECTED]> wrote:
> > Sounds interesting, could you please expand a bit please?
> > Do you mean that transcode should handle globbing?
> Yes, transcode should definitely handle globbing.
> I think this is the way most commandline pr
On Tuesday 05 December 2006 11:29, Francesco Romani wrote:
> On 12/5/06, Thomas Wehrspann <[EMAIL PROTECTED]> wrote:
> >
> > 4. Implementation issues.
> > -
> > I think a directory mode is only a special case of 'dir/*', which is a
> > more
> > flexible way of selecting file
On 12/5/06, Francesco Romani <[EMAIL PROTECTED]> wrote:
That makes think that we're talking about 1.0.x branch, am I right?
oh, right. I noticed that some CVS modules used fwrite, but not that
you switched to tc_pwrite.
Ok, but there's a bug in tc_pwrite, or in the way it's being used.
The re
On 12/5/06, Thomas Wehrspann <[EMAIL PROTECTED]> wrote:
4. Implementation issues.
-
I think a directory mode is only a special case of 'dir/*', which is a
more
flexible way of selecting files (e.g. dir/*.mpg).
So we should focus on the '*.*' mode, as it includes the direc
On Sunday 03 December 2006 10:57, Francesco Romani wrote:
>
> Hi,
>
> The directory mode has some long-standing bugs (just take a peek at
> transcode-users and/or at dvdrip-users archives).
> I consider this issue a blocker for 1.1.0 release and I think there is room
> and chance for a serious re
On 12/5/06, Scott Smith <[EMAIL PROTECTED]> wrote:
On 12/4/06, Andrew Church <[EMAIL PROTECTED]> wrote:
> Personally, I've had my eye on getting rid of import_exit()
> entirely,
I fully agree with this.
well a little more digging shows that apparently fwrite is not the
preferred metho
12 matches
Mail list logo
