Re: [Gnu-arch-users] Nit

[Andrew Suffield]

On Tue, Oct 21, 2003 at 09:14:37PM -0700, Dustin Sallings wrote:
> 
> On Tuesday, Oct 21, 2003, at 20:37 US/Pacific, Andrew Suffield wrote:
> 
> >On Tue, Oct 21, 2003 at 08:13:29PM -0700, Dustin Sallings wrote:
> >>>>>I have never even encountered a program where this was not true, 
> >>>>>let
> >>>>>alone written one.
> >>>>
> >>>>  Are you familiar with signal 13?  That's what your application
> >>>>receives when its standard out goes to a pipe and the pipe closes.
> >>>>The
> >>>>default behavior is to have your program abort when it's unable to
> >>>>produce any more output.
> >>>
> >>>Behaviour which is fortunately easy to turn off. What I said remains
> >>>true, no matter how many historical features of unix you point out
> >>>that make it inconvinient.
> >>
> >>    Oh come on.  You either haven't seen it, or it's historical and in
> >>every application that hasn't specifically disabled it.
> >
> >I've seen it, and I've seen several applications that haven't disabled
> >it, and it's been undesireable in every case, which is what I
> >said. Where's your point?
> 
>       Well, at the top of this deeply quoted text, you hadn't seen it.  
>       Now you have.

That's simply wrong, and doesn't match anything I've said. Please
*stop* attributing things to me that I did not say.

> >>    I have seen very few applications, if any, that consider ENOSPC a
> >>temporary error.  I have a lot of programs that write to disk.  That's
> >>their job.  If there is no space, they cannot do their job.  What are
> >>they supposed to instead?
> >
> >Wait for more space, usually.
> 
>       Can you cite an application (other than something you've written, 
> apparently) where this actually happens?

Not off the top of my head, I'd have to go check a few things to find
one without this bug. It's distressingly common.

> >And yet you don't know how to acquire a list of all the perl
> >primatives? Or generate it on the fly? Oh dear. You are the sort of
> >person who gives perl a bad name. A skilled perl programmer would
> >produce things like that without having to think about them.
> 
>       Yay, more personal insults rather than accepting that there's a 
> problem.

The only problem is that you can't or won't write the fairly simple
code that would solve your problem. What else am I supposed to
conclude?

>  And no, the problem is not how to generate a list of all perl 
> primitives.  The problem is how to finish the Fatal implementation perl 
> comes with.

Generating a list of the primitives is how I would approach that. I
can't see any other approach that makes much sense.

> It's another example of a half-complete piece of code that 
> becomes increasingly difficult as you near completion due to 
> inconsistencies.

If this is your idea of "difficult"...

Really. It's trivial. Pathetically so. I'd place it around two dozen
lines.

>       You'd be part of the way there if you narrowed its reaction down to 
> only one of the two values perl considers false.

Once again you are showing your inexperience. There are three false
values in perl.

> The rest is dealing 
> with individual functions and their perception of failure.

Trivial.

> >No, that is not the only goal. Raising an exception on every error
> >might accomplish this, but it would have other disadvantages that are
> >unnecessary. Hence, perl does not do this - particularly since that
> >exact result can be generated fairly easily.
> 
>       You make it sound as if you sat through the meeting where they, um, 
> ``designed'' the error reporting for perl.

You make it sound as if there were not several large and heavy books
describing how and *why* perl works the way it does, or as if the
design decisions behind perl were not one of the *most common*
subjects of lectures by Larry Wall.

> Are you sure perl returns 
> undef rather than throws exceptions on error because of some defined 
> disadvantages?

Yes.

> >>If
> >>the most obvious and easiest way to solve a problem isn't the most
> >>reliable, it's not going to be the most common.  Experience is
> >>important here, of course, but saying stuff like, ``Ask a perl
> >>programmer to write it for you,'' when the only way they have to make
> >                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>functions safe is to know every function that is unsafe is certainly
> >  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>not helping.
> >
> >Straw man. You just don't know how to do it properly (and I have
> >better things to do than to write the code for you).
> 
>       That's fine, I don't want the code...even if you don't ``have to 
>       think about [it].''

Do you often spend this much time complaining about the lack of a
module which you don't even want?

> >>>>>>        To say that 0 should not ever be a valid result from a function
> >>>>>>        seems a little odd.
> >>>>>
> >>>>>Definitely not a perl programmer.
> >>
> >>    [yet another inconsistency in the perl core functions was here]
> >>
> >>>I didn't say there were no exceptions. I said they were very few in
> >>>number. I also said they were trivial to wrap.
> >>
> >>    Right, by writing more code.  If Fatal were implemented properly, I
> >>wouldn't have to know all of these exceptions to perl's consistency.
> >
> >Apples and oranges. You're complaining that Fatal, a module written to
> >perform task X, does not perform task Y.
> 
>       Fatal, a module that was written to ``replace functions with 
> equivalents which succeed or die,'' does not work for certain core 
> functions, to be specific.

And nor was it intended to. The reason for its existance is pretty
obvious to me, since I've spent more than 30 seconds (nearly five
minutes, I'd estimate) thinking about how to go about making all the
primitives throw exceptions on error.

> >That's not what you said. Here's what you said:
> >
> >>>>>>        To say that 0 should not ever be a valid result from a function
> >>>>>>        seems a little odd.
> >
> >I did not say that 0 should not ever be a valid result from a function.
> >
> >Please refrain from constructing more straw men.
> 
>       Well, the archives are there, but you accused me of not being a perl 
> programmer when I suggested 0 was a valid return value.

<sigh> Okay, I looked back at the history. I said that it was
considered abnormal to return 0, and you responded as above.

I then gave you the benefit of the doubt, and assumed you were
replying to me and being insufficiently careful with how you phrased
your comment, rather than attempting to twist my words. Am I to
conclude that I was wrong, and you were in fact deliberately
constructing a straw man?

> >>    It's part of the POSIX module.
> >
> >So it's not a perl function at all, it's a C function. Don't expect C
> >functions to behave like perl functions.
> >
> >The whole point of POSIX is to be the thinnest reasonale wrapper
> >possible around a bunch of C functions. It is very rarely necessary to
> >use it; an experienced perl programmer should always check twice
> >before calling a function from POSIX, because there's probably a perl
> >version that's preferable.
> 
>       Yes, as is clearly stated in the POSIX perldoc...somewhere between 
>       the parts where it says it gave them ``perl-ish interfaces'' and ``It's 
> a 
> great source of wisdom.''

No it isn't. What are you talking about?

> >>>Nobody who is remotely used to using java is going to expect
> >>>well-written java code, especially from third parties.
> >>
> >>    That answer is a bit rhetorical and probably just as true without
> >>specifying a language.
> >
> >Yes, that was my point, which you have "conviniently" deleted from the
> >quoted text.
> 
>       Ahhh, this must be why you keep accusing me of not reading what 
>       you're writing.  Clearly some pieces aren't making it across, as those 
> were 
> the only two lines anywhere near this part of the message that came 
> from you.

I cannot comprehend this paragraph. Are you attempting to suggest that
you didn't receive the following text?

> You have absolutely no cause for complaint about library modules which
> don't throw exceptions, because that happens in every language,
> especially java; it's up to the library author to decide whether to
> use exceptions or not.

It is the paragraph to which you were originally replying.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature