Re: The ultimate luxury ?
From: Jesse F. Hughes (jesse_at_phiwumbda.org)
Date: 08/02/04
- Next message: Jesse F. Hughes: "Re: The ultimate luxury ?"
- Previous message: Andr? Michaud: "Re: "The map is not the Territory"..."
- Maybe in reply to: Kenneth Doyle: "Re: The ultimate luxury ?"
- Next in thread: Jesse F. Hughes: "Re: The ultimate luxury ?"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 02 Aug 2004 13:08:37 +0200
jmfbahciv@aol.com writes:
> In article <873c37yt2f.fsf@phiwumbda.org>,
> jesse@phiwumbda.org (Jesse F. Hughes) wrote:
>>jmfbahciv@aol.com writes:
>>
>>> In article <873c3817dm.fsf@phiwumbda.org>,
>>> jesse@phiwumbda.org (Jesse F. Hughes) wrote:
>>>>I glanced over the rest of your message and found this. I felt
>>>>compelled to respond.
>>>>
>>>>jmfbahciv@aol.com writes:
>>>>
>>>>>>Let's face it: Usenet conventions have changed since son-of-1036,
>>>>>>sometimes in good ways, sometimes in bad. We don't use the Summary
>>>>>>header much these days, but that seems acceptable in a time in which
>>>>>>the difference between downloading headers and downloading whole
>>>>>>messages is negligible.
>>>>>
>>>>> I never download the messages. I always download headers, then
>>>>> pick and choose which messages to retreive. Now I understand
>>>>> why you're confused.
>>>>
>>>>I am not confused. I didn't say a goddamn thing about what your
>>>>software does. I don't care what your software does. I told you what
>>>>my software does. You have been arrogant and stupid enough to tell me
>>>>that I'm wrong about what my software does without checking what, in
>>>>fact, it does.
>>>
>>> I told you that your software doesn't sort on the contents of
>>> the ref field. Everything you have described to me supports
>>> that statement. You have a misunderstanding of the term sort
>>> when used in the computer biz.
>>
>>Oh. You had a literal meaning of "sort on the references field".
>
> Of course I did. We were talking about specifics.
>
>>Well, *of course* it doesn't do that and I never meant it did. I
>>meant there was a mapping references -> some poset which yielded the
>>sorting.
>>
>>Duh.
>
> Duh back to you. If you're going to talk about specifications,
> you had better use the correct language. What you are doing
> is either a merge or a collation based on the contents of
> the data list given in the ref field. Not a sort.
Explain yourself.
Here is the situation as it occurs in my newsclient.
The headers for a number of articles have been fetched. A summary of
the set of fetched headers must be presented to the user. This is
done one record per line, so the issue to be solved is what order
these records should be presented. It is at this point that a *sort*
based on the References field takes place.
What merge are you talking about?
>>In any case, you certainly *can* sort on the references field. Given
>>two messages m1 and m2, if the references of m1 is a substring of the
>>references of m2, then m1 comes before m2 (with caveats concerning
>>whitespace omitted). Because in this case, m2 is either a reply to m1
>>or a reply to a reply to a reply to... m1.
>
> But that isn't sorting. That is collating. The ref field contains
> an ordered list of addresses or you can call them names. The code
> then takes the first name on the list, calls other code to retrieve
> the set of bits associated with that name and dumps the bit set
> into a file. The code then takes the next name on the list, retrieves
> the set of bits associated with that name, and appends the set
> to the end of the first set of bits. This is not sorting. It's
> actually not even a collation or a merge.
I don't want to quibble over terms here. I don't see what your
problem is with the term sort and I don't care much. The fact is that
the references header is used to determine the order in which to
present the records to the user. Call it what you want. It's a sort
where I come from.
>>So one *can* do something useful by sorting on the references field
>>(however, if software keeps no more than a fixed number of references,
>>then this is inadequate).
>>
>>Example: Your header:
>>References: <_Jeff_Relf_2004_Jul_28_q3qX@NCPlus.NET>
>> <4108dc1f$0$2847$61fed72c@news.rcn.com> <87n01jxcpb.fsf@phiwumbda.org>
>> <410a1f6d$0$2826$61fed72c@news.rcn.com> <87wu0lzsc9.fsf@phiwumbda.org>
>> <410a3419$0$2826$61fed72c@news.rcn.com> <87hdrp2xs3.fsf@phiwumbda.org>
>> <410bb162$0$2815$61fed72c@news.rcn.com> <873c3817dm.fsf@phiwumbda.org>
>>
>>The parent to your post:
>>References: <q9p9g0tdq7ua0hpfcu8skibuccj23urcdu@4ax.com>
> <7efpaixxs35p.1d9y0bhu3pegf.dlg@40tude.net>
>> <i0kdg0dnk4va61u8p8if366temsoq3134b@4ax.com>
>> <878yd4fnlb.fsf@phiwumbda.org> <41078863$0$2826$61fed72c@news.rcn.com>
>> <_Jeff_Relf_2004_Jul_28_q3qX@NCPlus.NET>
>> <4108dc1f$0$2847$61fed72c@news.rcn.com> <87n01jxcpb.fsf@phiwumbda.org>
>> <410a1f6d$0$2826$61fed72c@news.rcn.com> <87wu0lzsc9.fsf@phiwumbda.org>
>> <410a3419$0$2826$61fed72c@news.rcn.com> <87hdrp2xs3.fsf@phiwumbda.org>
>> <410bb162$0$2815$61fed72c@news.rcn.com>
>>
>>Your software dropped an initial segment, so the naive interpretation
>>of "sort on the references header" won't work.
>
> And you don't sort the ASCII collection of characters contained
> within <>. That ASCII gooblegook is a unique name assigned
> to a set of bits called a post. You are using the <data> as
> an indirection.
You're quibbling again. Your interpretation of what is happening is
one way of viewing things, but it isn't the one I use. Here's how I
view it.
For each post, we have a record of the headers fetched. One of the
entries in that record is the references header. True, the contents
of that header is a sequence of names for the individual records (not
every entry has been fetched, however), but I don't care about this at
present. I am only using the header to sort the records. I can use
the subject or date headers to sort the records, too.
The fact that the message-id's are names for the records isn't
consequential. Probably (almost certainly) my newsclient doesn't use
them for indirection internally at this point. It would be bad to do
so, since one cannot guarantee that message-ids are unique. They are
supposed to be unique, but they're created by the various posting
clients out there and one shouldn't depend on uniqueness more than he
has to. Instead, one uses the article number (which depends only on
the server and it would take a severely broken server to not guarantee
uniqueness.).
In any case, this has all come down to pointless quibbling over
terminology (that's not a sort, it's a collation, except it isn't that
either). You've determined you're going to win the claim that no one
sorts on references by interpreting the references header as a list of
pointers (which it really isn't anyway, near as I can figger).
>>>
>>> You are using terms incorrectly. I suspect that you do this because
>>> the first thing you do is dump all the data you may want to look
>>> at on your disk. Then indirection retrieval, sorting data, etc.
>>> looks like the same operation to you.
>>
>>Wrong. It doesn't dump data onto my disk. I admit using terms
>>loosely, but it was no confusion on my part.
>
> Good. Because that's what I'm fighting about.
>
>> .. If my loose use of the
>>term "sort on the references header" is the source of our
>>disagreement, then I apologize.
>
> YES!!!! Thank you. If you wrote a spec that said "sort", a
> mess would happen. That's all I'm trying to correct.
Really, I was being charitable when I wrote the above. For Christ's
sake, why would you think I meant an alphabetic sort?
>>But every sort involves imposing some sort of partial order on the
>>data to be sorted.
>
> No,no. Every sort imposes a well-specified complete order on
> the data to be sorted.
Yes, you're right. I should have said linear order, not partial.
>> .. Why assume that I meant, oh, dictionary order or
>>whatever you assumed? I didn't.
>
> Because that's how the term is used in computing.
Not in my experience, it's not.
I have reasonable experience in computer science. I cannot imagine
reading an article in which the author refused to use the term "sort"
outside of dictionary or numeric order. Your background is evidently
different than mine, but now that we've, er, sorted that all out,
let's just drop the tedious semantic quibbles.
> Other terms are collation, merge, sift. I'll have to check about
> the sift term. We certainly used it but I can't recall people using
> it in the last decade.
>>
>>Then your comment, "Now, the reason I'm harping on this
>>is because I think you're posting from that group that has "OS"
>>in its name. It is appalling to me that you don't this stuff
>>and you need to know the existence of all of this if you're
>>going to touch set any bit in a source set of an OS," is just stupid,
>>isn't it?
>
> Nope. Think of somebody who is writing the most important code
> in the computer biz (operating system code) who thinks that
> an address of the data is the data.
A message-id is not typically used as an address, though it is used as
an identifier. Now, I normally wouldn't quibble on this point, since
it's a matter of perspective, but you keep trying to claim that a
message-id is an address. It isn't. It *is* a name for a post, but
posts are not kept on the server by message-id and they're also not
manipulated by my client via message-id. The server-dependent article
number is instead used.
> Now think of a person who modifying file structure code and doesn't
> think that the physical address of the disk _contains_ the data.
>
> Now think of a person modifying OS code who is told to sort
> filenames in alphanumeric ascending order before moving the contents
> of those files in a copy command.
Who the *** cares? I'm not about to touch any OS code. And I am not
making the mistake you think I'm making.
--
Jesse F. Hughes
One is not superior merely because one sees the world as odious.
-- Chateaubriand (1768-1848)
- Next message: Jesse F. Hughes: "Re: The ultimate luxury ?"
- Previous message: Andr? Michaud: "Re: "The map is not the Territory"..."
- Maybe in reply to: Kenneth Doyle: "Re: The ultimate luxury ?"
- Next in thread: Jesse F. Hughes: "Re: The ultimate luxury ?"
- Messages sorted by: [ date ] [ thread ]