long subject lines
laura fairhead
PLEASE PLEASE PLEASE
Can people stop using such ridiculously long subject lines
it's really spoiling my enjoyment of this group (don't
really know enough to contribute but like reading and have
been doing so for some months now).
My newsreader is splitting the threads all over the place
because the subject header lines are so long they are getting
line wrapped (somewhere) and justified, the number of spaces
introduced in between words is varying in every other post
(pressumably according to different NNTP servers/clients the
messages are going through) and my newsreader is unable to
recognise them as belonging to the same thread, nor does it
have filters so that I might just stop them altogether.
Aren't there some guidelines somewhere on how to compose
subject titles for USENET message posts? It seems to me
that one should keep a subject title BRIEF and CONCISE
rather than write an essay. Sorry to moan but it's really
ruined my enjoyment of this interesting newsgroup and it
seems to be such a simple and obvious thing.
regardsfrom
--
laura fairhead # la...@madonnaweb.com http://lf.8k.com
Why won't netscape access the URL http://mailserver.domain:25 ?
What are "security" reasons ?
It can easily be patched away with a debugger, for sure,
but it really makes you wonder ....
Hank Oredson
... Hank
"laura fairhead" <la...@madonnaweb.com> wrote in message
news:3c7457c4...@NEWS.CIS.DFN.DE...
del cecchi
"Hank Oredson" <hore...@att.net> wrote in message
news:Gs_c8.2713$Im1.1...@bgtnsc05-news.ops.worldnet.att.net...
commonly discussed and just use numerals for subjects.
1. Alpha, including its mismanagement and superior performance.
2. Memory Heirarchy
3. IA64 is a failure
4. Esoteric HPC programming
5. I have a question about....(Homework problems in drag)
6. Back when I was at DEC......... (Leakage from AFC)
7. You are an idiot. No, you are. (was 1:6)
Many integers left, any suggestions? :-)
Above not necessarily in order of importance.
del cecchi
Dennis O'Connor
[ ... objection to long subject lines ...]
The problem is probably in your configuration.
My configuration has no issues with current subject line lengths.
--
Dennis O'Connor dm...@primenet.com
We don't become a rabid dog to destroy a rabid dog.
Chris Quayle
> >
> In order to keep them short, we could just enumerate the 5 or 6 topics
> commonly discussed and just use numerals for subjects.
>
> 1. Alpha, including its mismanagement and superior performance.
> 2. Memory Heirarchy
> 3. IA64 is a failure
> 4. Esoteric HPC programming
> 5. I have a question about....(Homework problems in drag)
> 6. Back when I was at DEC......... (Leakage from AFC)
> 7. You are an idiot. No, you are. (was 1:6)
>
Full marks for that one - definately brought a smile to my face this
morning, especially 5 and 6 :-).
Chris
Tim Bradshaw
> 1. Alpha, including its mismanagement and superior performance.
> 2. Memory Heirarchy
> 3. IA64 is a failure
> 4. Esoteric HPC programming
> 5. I have a question about....(Homework problems in drag)
> 6. Back when I was at DEC......... (Leakage from AFC)
> 7. You are an idiot. No, you are. (was 1:6)
May I suggest that someone keep a central registry of subjects with
some mechanism for proposing new ones? There could have be registry
of common article bodies too. If we can assume 64bit words we then
could encode the body in the high 32 bits and the title in the low
one. Actually it's probably better to do it the other way around as
it's likely easier to filter based on subject. Given an octet (kind
of mutant doubled IPv4 address) notation, most threads would be in the
0.0.0.7.x.y.z.q subnet... Popular people could have their own numbers
thus enabling very efficient encoding of insults. Of course suitable
attention would need to be given to the decoding efficiency of this
system - we wouldn't want non-uniform-length for instance as it would
make life really hard for pipelined newsreaders.
--tim
Paul D Fox
> In order to keep them short, we could just enumerate the 5 or 6 topics
> commonly discussed and just use numerals for subjects.
>
> 1. Alpha, including its mismanagement and superior performance.
> 2. Memory Heirarchy
> 3. IA64 is a failure
> 4. Esoteric HPC programming
> 5. I have a question about....(Homework problems in drag)
> 6. Back when I was at DEC......... (Leakage from AFC)
> 7. You are an idiot. No, you are. (was 1:6)
>
> Many integers left, any suggestions? :-)
> Above not necessarily in order of importance.
>
> del cecchi
8. Why XXX replies in such an obnoxious way
9. Why the MAC is superior to the PC
10. Why the PC is superior to the MAC
11. Why Nick M. doesn't understand what everyone else is talking about
(no indictment of you Mr McLaren but everyone seems to lay into you).
12. Top posting
13. IA64 is a success
...
Chris Morgan
> 1. Alpha, including its mismanagement and superior performance.
> 2. Memory Heirarchy
> 3. IA64 is a failure
> 4. Esoteric HPC programming
> 5. I have a question about....(Homework problems in drag)
> 6. Back when I was at DEC......... (Leakage from AFC)
> 7. You are an idiot. No, you are. (was 1:6)
>
> Many integers left, any suggestions? :-)
8. incredible stunts of coding
9. brainiac vs. speed demon (megahertz myth)
10. servers should never trade cpu/memory slots for I/O
11. our great new servers trade cpu/memory slots for I/O
12. supercomputer bandwidth, latency, topology, power, cooling
13. interconnect theology
14. make money now fast $$$
(oops, sorry...)
> Above not necessarily in order of importance.
>
> del cecchi
>
>
--
Chris Morgan
Sid Ahmed Ali TOUATI
> Many integers left, any suggestions? :-)
you forgot architecture for buildings
Brig Campbell
> news:Gs_c8.2713$Im1.1...@bgtnsc05-news.ops.worldnet.att.net...
> > >
> > > --
> > > laura fairhead # la...@madonnaweb.com http://lf.8k.com
> > >
> > > Why won't netscape access the URL http://mailserver.domain:25 ?
> > > What are "security" reasons ?
> > > It can easily be patched away with a debugger, for sure,
> > > but it really makes you wonder ....
> >
> In order to keep them short, we could just enumerate the 5 or 6 topics
> commonly discussed and just use numerals for subjects.
>
> 1. Alpha, including its mismanagement and superior performance.
> 2. Memory Heirarchy
> 3. IA64 is a failure
> 4. Esoteric HPC programming
> 5. I have a question about....(Homework problems in drag)
> 6. Back when I was at DEC......... (Leakage from AFC)
> 7. You are an idiot. No, you are. (was 1:6)
>
> Many integers left, any suggestions? :-)
> Above not necessarily in order of importance.
>
> del cecchi
>
>
I'm in the process of finishing up a program that's a random subject
generator. It detects the decrease in comp.arch postings and then fires off
a new thread. The beta test posting was the subject "long subject lines",
it obviously has a "sighting".
BTW, what's the process for creating a new group:
comp.arch.enemies.nick.and.dennis
-brig
Jeffrey Dutky
> In order to keep them short, we could just enumerate the 5 or 6 topics
> commonly discussed and just use numerals for subjects.
>
> 1. Alpha, including its mismanagement and superior performance.
> 2. Memory Heirarchy
> 3. IA64 is a failure
> 4. Esoteric HPC programming
> 5. I have a question about....(Homework problems in drag)
> 6. Back when I was at DEC......... (Leakage from AFC)
> 7. You are an idiot. No, you are. (was 1:6)
>
> Many integers left, any suggestions? :-)
8. My New Idea(TM) for comp.arch stuff
9. A.I. crackpottery
10. misdirected architectural (e.g. buildings) stuff
11. misdirected "My PC is not working" stuff
- Jeff Dutky
Rupert Pigott
news:3C7513E0...@inria.fr...
> del cecchi wrote:
>
> > Many integers left, any suggestions? :-)
>
> you forgot architecture for buildings
>
>
That usually manifests itself as posts trying to sell CAD software. :)
Cheers,
Rupert
Rupert Pigott
news:f6013729.0202...@posting.google.com...
[SNIP]
> 9. A.I. crackpottery
That's actually quite easy, you don't need a subject
code for that one. Just look for "Arthur T Murray" or
"Mentifex" in the From line. I'm sure he uses another
couple of names too, but I'm damned if I can remember
em. :)
Credit to the guy/bot/whatever, it's been posting
solidly since 1993 at least !
Cheers,
Rupert
Peter Boyle
12. I'm bored with computing but can't deal with getting flamed
on rec.lingual.useless.comparisons
13. Management/sales/PR are waste of space. Discuss.
Peter Boyle
> - Jeff Dutky
>
Hank Oredson
Who would maintain the registry of topic numbers?
I'd vote for del ... heh heh ...
--
... Hank
"del cecchi" <dce...@msn.com> wrote in message
news:b%_c8.1859$ro1....@eagle.america.net...
>
Hank Oredson
"Dennis O'Connor" <dm...@primenet.com> wrote in message
news:a51uu2$heq$1...@node21.cwnet.roc.gblx.net...
A quick look at rfc-822 and rfc-850 suggests there is no limit
on the lenght of a Subject: header. Of course there is always
that "please limit text to 72 characters" suggestion from long
long ago. Um ... no ... I won't crosspost to a.f.c after all.
Terje Mathisen
No, no, no!
We should instead _require_ variable-length encoding in the search for
maximum network performance, with a corresponding 'trace cache' in the
decoding stage to expand these to the canonical (fixed 64-bit)
representation.
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Dennis O'Connor
> BTW, what's the process for creating a new group:
> comp.arch.enemies.nick.and.dennis
I have nothing against Nick Maclaren, he just happens
to post a lot of idiocy to this newsgroup. It's the idiocy,
not Nick, I have a problem with.
That, and the OE spell-check keeps wanting to change
his name to "Macarena". An-noying !!!
Dennis O'Connor
> Um ... no ... I won't crosspost to a.f.c after all.
THANK YOU ! Between the crossposting from
there and the VMS/Alpha groups, comp.arch is barely
a recognizable newsgroup.
laura fairhead
>"laura fairhead" <la...@madonnaweb.com> wrote:
>[ ... objection to long subject lines ...]
>
>The problem is probably in your configuration.
>My configuration has no issues with current subject line lengths.
It isn't so much the subject line length in itself, just that the
subject line length is causing different newsservers/clients to
format the 'Subject:' part of the header differently. I verified
this by using a reliable method to directly get 2 headers from
my news server of the same thread but the subject line in the
second one has been wrapped over 2 lines and the second line
has a different number of spaces...I replaced spaces with underscores
so this is clear;
(from head <a50n0c$c...@gap.cco.caltech.edu> )
Subject:_Re:_VAX,_M68K_complex_instructions_(was_Re:_Did_Intel_Bite_Off_MoreThan_It_Can_Chew?)
(from head <3C721094...@mediasec.de> )
Subject:_Re:_VAX,_M68K_complex_instructions_(was_Re:_Did_Intel_Bite_Off____
_More_______Than___It_Can_Chew?)
Some news readers, might be able to deal with this (every other post
gets a different type of formatting) but mine definently can't
(I've gone all through the configuration file and the UI options)
Eventually I'm going move over to a better newsreader, but I've got
to configure it properly for off-line reading and retrain myself
in its use and I don't have a lot of time at the moment (I was looking
at 'trn' but it's quite involved and doesn't want to do off-line
reading without a lot of things being configured).
Anyhow, thanx for listening....
>--
>Dennis O'Connor dm...@primenet.com
>We don't become a rabid dog to destroy a rabid dog.
>
>
bestwishesfrom
laura fairhead
>On Wed, 20 Feb 2002 22:01:12 -0700, "Dennis O'Connor" <dm...@primenet.com> wrote:
>
>>"laura fairhead" <la...@madonnaweb.com> wrote:
>>[ ... objection to long subject lines ...]
>>
>>The problem is probably in your configuration.
>>My configuration has no issues with current subject line lengths.
>
[snip]
Forget all that nonsense! You were right, there was a setting in
my configuration file 'NewSubjectStartsNewThread'. I had tried
setting it to 0 (before it was 1) and nothing happened, however
after I made my previous post everything has suddenly packed
itself neatly together and the problem is over :) Sorry about that,
I had lost the applications documentation and should have
tested things more thoroughly, oh well; I've learnt how to get USENET
posts using ftp and I'm back to enjoying this engaging group again.
Thanx for your help
byefrom
Hank Oredson
> On Wed, 20 Feb 2002 22:01:12 -0700, "Dennis O'Connor" <dm...@primenet.com>
wrote:
>
> >"laura fairhead" <la...@madonnaweb.com> wrote:
> >[ ... objection to long subject lines ...]
> >
> >The problem is probably in your configuration.
> >My configuration has no issues with current subject line lengths.
>
> It isn't so much the subject line length in itself, just that the
> subject line length is causing different newsservers/clients to
> format the 'Subject:' part of the header differently. I verified
> this by using a reliable method to directly get 2 headers from
> my news server of the same thread but the subject line in the
> second one has been wrapped over 2 lines and the second line
> has a different number of spaces...I replaced spaces with underscores
> so this is clear;
>
> (from head <a50n0c$c...@gap.cco.caltech.edu> )
>
>
Subject:_Re:_VAX,_M68K_complex_instructions_(was_Re:_Did_Intel_Bite_Off_MoreTha
n_It_Can_Chew?)
>
> (from head <3C721094...@mediasec.de> )
>
> Subject:_Re:_VAX,_M68K_complex_instructions_(was_Re:_Did_Intel_Bite_Off____
> _More_______Than___It_Can_Chew?)
Isn't there a tab or space in front of "_More"?
That would be normal rfc-822 line continuation.
Just two different ways of showing the same information.
> Some news readers, might be able to deal with this (every other post
> gets a different type of formatting) but mine definently can't
> (I've gone all through the configuration file and the UI options)
>
> Eventually I'm going move over to a better newsreader, but I've got
> to configure it properly for off-line reading and retrain myself
> in its use and I don't have a lot of time at the moment (I was looking
> at 'trn' but it's quite involved and doesn't want to do off-line
> reading without a lot of things being configured).
Erik Magnuson
Terje,
Looks like you've been spending w-a-y too much time re-reading the intel
8800, -er- iAPX432 documentation.
I, for one, would like to see the canonical representation as 20 octal
digits.
Erik Magnuson
Jeffrey S. Dutky
Gah! You spoke it's name! Now it will come and bore us
all to death with incomprehensible gibberish and ASCII
diagrams recapitulating the theory of Platonic forms
or Logical Positivism with a liberal sprinkling of
the computer/techno jargon-du-jour.
Actually, though I endeavor not to read ATM's postings,
I had noticed that he seems to have abandoned the ASCII
diagrams. All of the modern postings are pure text that
reads like the synthetic fiction from the early to mid
'80s.
- Jeff Dutky
Paul D Fox
Ok - my proposal. We have a header with a structure like this:
8 - octets;
octet[0] = 'S';
octet[1] = 'u';
octet[2] = 'b';
octet[3] = 'j';
octet[4] = 'e';
octet[5] = 'c';
octet[6] = 't';
octet [7] = ':';
Next follows the variable-length text field introducer:
octet[8] = ' ';
After this follows a random binary string of letters and numbers. In
order to avoid confusion, these will be in binary:
octet[9] = '1';
octet[10] = '0';
I think we only need 2 bits for the subject string as there only ever
seems to be 4 topics of conversation going on at any one time (one of
them inevitably involves Dennis in a
my-dongle-is-bigger-than-your-dangle).
In version two, we will compress the header and remove the octet[8].
Multilingual support will come in version 3, where we can use a lower
case
'S' in octet[0].
After that we will be working on the GNOME/KDE interface (header
expanded to 8 gigabytes - which should be enough room for the short
term; longer term we will need to move to 64-bit octets
[hexadecaquattroctets?]).
Rob Thorpe
Here is my scoring system for posts:
A -5 point starting credit.
1 point for mispelling "the".
1 point for every statement that is widely agreed on to be false.
2 points for every statement that is clearly vacuous.
3 points for every statement that is logically inconsistent.
5 points for each such statement that is adhered to despite careful
correction.
5 points for using a thought experiment that contradicts the results
of a widely accepted real experiment.
5 points for each word in all capital letters (except for those with
defective keyboards).
5 points for each mention of "Dirk Meyer", "Craig Barrett" and "Andy
Grove"
5 points each for mentioning the "memory wall", "Von Neumann
bottleneck" or saying "its the bandwidth stupid".
10 points for each claim that superpipelining is fundamentally
misguided (without good evidence).
10 point for claiming RISC Is fundementally misguided.
10 points for using the phrase superpipelining since it isn't properly
defined.
10 points for pointing out that you have gone to school, as if this
were evidence of sanity.
10 points for offering prize money to anyone who proves and/or finds
any flaws in what you claim.
10 points for each statement along the lines of "I'm not good at math,
but my theory is conceptually right, so all I need is for someone to
express it in terms of equations".
10 points for claiming that your favoured processor is on the cutting
edge of a "paradigm shift".
10 points for believing that X kB extra Level-Y cache or Z new bus
interface will have the same benefit for processor A as processor B.
10 points for believing that SOI, Copper, Low-K dielectric, High-K
dielectric, isotopically pure silicon, funny shaped gates or dynamic
logic will have the same benefit for processor A as processor B.
20 points for every use of science fiction works or myths as if they
were fact.
20 points for defending yourself by bringing up (real or imagined)
ridicule accorded to your past favoured processors.
20 points for each use of the phrase "hidebound reactionary".
20 points for each use of the phrase "self-appointed defender of the
orthodoxy".
30 point for believing that your favoured processor company will apply
technology X on there upcoming processor when it isn't mentioned on
their roadmaps.
30 points for suggesting that Cray, in his later years, was groping
his way towards the ideas you now advocate.
30 points for suggesting that the next processor to come out of your
favoured processor vendor will have some secret and very powerful new
optimization.
40 points for comparing those who argue against your ideas to Nazis,
stormtroopers, or brownshirts. (And thereby invoking Godwins law).
40 points for claiming that the "computing establishment" is engaged
in a "conspiracy" to prevent your favourite processor from gaining its
well-deserved fame, or market share.
Any resemblence to a similar scoring system used at sci.physics is
purely coincidental.
Rupert Pigott
news:3C75DFC4...@bellatlantic.net...
[SNIP]
> Actually, though I endeavor not to read ATM's postings,
> I had noticed that he seems to have abandoned the ASCII
> diagrams. All of the modern postings are pure text that
> reads like the synthetic fiction from the early to mid
> '80s.
I actually get a kick from reading them, for just that
reason. It's kinda fun. Reminds me of a few SF books I've
read. One day we'll look back on him as the Andy Warhol
of USENET. :)
Cheers,
Rupert
Terje Mathisen
> >No, no, no!
> >
> >We should instead _require_ variable-length encoding in the search for
> >maximum network performance, with a corresponding 'trace cache' in the
> >decoding stage to expand these to the canonical (fixed 64-bit)
> >representation.
>
> Looks like you've been spending w-a-y too much time re-reading the intel
> 8800, -er- iAPX432 documentation.
Sad to say, I've never had the chance to do that, it it isn't high
enough on my to-do list that I'm ever likely to get to it. :-(
What I have done is to suffer through a similar misfeature of a 'black
box' network backup protocol:
The designer spent half a year or so inventing exceedingly clever ways
to do bit-level compression of the header blocks for all the different
kinds of data items such a backup stream might need.
He then went on to setup the protocol in such a way that it _had_ to
know and care about the actual packetization/blocking of the data
stream.
Next he decided that all data items should be formatted in the same way,
with a header that contained a 32-bit length field, to make it easy to
unpack and possibly discard for a unit that didn't know/care about some
specific (or newly added) capability.
This made a slot of sense, so he then decided to introduce a very
crucial exception:
Any big data stream, i.e. actual file data, would _not_ have a header!
The only way to unpack the backup data stream is to know enough about
the system that generated it so that you can figure out from all the
other (with leading header) blocks exactly when a chunk of binary data
will turn up, and exactly how large it must be, taking pains to handle
the implicit end-of-block padding etc.
Finally, to make it really obvious that the 0.1% or so saved with header
compression didn't matter, he decided that there was no way to compress
the actual file data.
(Actually, this probably resulted from the decision to skip header
blocks for data streams, since it meant that there was no obvious place
to encode the compression method used. :-()
Alex Colvin
>>> > 1. Alpha, including its mismanagement and superior performance.
>>> > 2. Memory Heirarchy
>>> May I suggest that someone keep a central registry of subjects with
>>> some mechanism for proposing new ones? There could have be registry
>>No, no, no!
>>We should instead _require_ variable-length encoding in the search for
>>maximum network performance, with a corresponding 'trace cache' in the
>>decoding stage to expand these to the canonical (fixed 64-bit)
>>representation.
>I, for one, would like to see the canonical representation as 20 octal
>digits.
All good ideas, but too low-level and local solutions. Just what one would
expect from the RISC/CISC/EPIC obsessives. The subject should be an XML
document, allowing embedded URLS for entities.
XML solves all multilingual issues, allows attached video and sound, can
be parsed with only a few MB code, is fully backwards compatible with the
widely deployed SGML, and allows automated processing of subjects
(remmeber, that was the original problem for which compression was a
proposed solution).
Further, XML would ensure that subjects wouldn't be directly readable
without the aid of an Application. It would obviate the need for the rest
of the article.
And from XML we can embed active content and emerging technology, tying
news reading more closely to our operating system, and undercutting any
news archives.
And then we can announce news-enhanced processor designs...
--
mac the naïf
Sander Vesik
14. How (and what kind) of numbers for common subject scheme
comp.arch should adopt.
>
> Peter Boyle
>
--
Sander
+++ Out of cheese error +++
Eugene Miya
Chris Quayle <ligh...@aerosys.co.uk> wrote:
>del cecchi wrote:
>> In order to keep them short, we could just enumerate the 5 or 6 topics
>> commonly discussed and just use numerals for subjects.
Nice preliminary list!
>> 1. Alpha, including its mismanagement and superior performance.
>> 2. Memory Heirarchy
>> 3. IA64 is a failure
>> 4. Esoteric HPC programming
>> 5. I have a question about....(Homework problems in drag)
>> 6. Back when I was at DEC......... (Leakage from AFC)
>> 7. You are an idiot. No, you are. (was 1:6)
And numerous great suggestions in other posts.
Lazy bastards!
Start YOUR own FAQs.
>Full marks for that one - definately brought a smile to my face this
>morning, especially 5 and 6 :-).
;^)
Rob Rodgers
wrote:
>Erik Magnuson <er...@cts.com> wrote in message news:<Pine.SOL.4.43.0202212144240.25553-100000@erik>...
>> On Thu, 21 Feb 2002, Terje Mathisen wrote:
>>
>> Terje,
>>
>> Looks like you've been spending w-a-y too much time re-reading the intel
>> 8800, -er- iAPX432 documentation.
>>
>> I, for one, would like to see the canonical representation as 20 octal
>> digits.
>>
>> Erik Magnuson
>
>Ok - my proposal. We have a header with a structure like this:
>
> 8 - octets;
> octet[0] = 'S';
> octet[1] = 'u';
> octet[2] = 'b';
> octet[3] = 'j';
> octet[4] = 'e';
> octet[5] = 'c';
> octet[6] = 't';
> octet [7] = ':';
Sounds okay, but can we please use EBCDIC instead of ASCII?
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
Alex Colvin
>commonly discussed and just use numerals for subjects.
>1. Alpha, including its mismanagement and superior performance.
>2. Memory Heirarchy
>3. IA64 is a failure
>4. Esoteric HPC programming
You propose creating an Informal Comp.Arch News Numbering?
--
mac the naïf
Hank Oredson
"Rob Rodgers" <kn...@acm.org> wrote in message
news:3c768cee....@goliath.newsfeeds.com...
> On 22 Feb 2002 01:24:09 -0800, f...@crisp.demon.co.uk (Paul D Fox)
> wrote:
>
> >Erik Magnuson <er...@cts.com> wrote in message
news:<Pine.SOL.4.43.0202212144240.25553-100000@erik>...
> >> On Thu, 21 Feb 2002, Terje Mathisen wrote:
> >>
> >> Terje,
> >>
> >> Looks like you've been spending w-a-y too much time re-reading the intel
> >> 8800, -er- iAPX432 documentation.
> >>
> >> I, for one, would like to see the canonical representation as 20 octal
> >> digits.
> >>
> >> Erik Magnuson
> >
> >Ok - my proposal. We have a header with a structure like this:
> >
> > 8 - octets;
> > octet[0] = 'S';
> > octet[1] = 'u';
> > octet[2] = 'b';
> > octet[3] = 'j';
> > octet[4] = 'e';
> > octet[5] = 'c';
> > octet[6] = 't';
> > octet [7] = ':';
>
> Sounds okay, but can we please use EBCDIC instead of ASCII?
I suggest Fieldata, thus using only six bits per character.
The characters can be packed into octets in the obvious manner
(6 octets containing 8 characters). Doing it this way will make
long Subject: headers shorter.
I suspect someone from DEC might have another proposal ...
Hank Oredson
"Alex Colvin" <al...@world.std.com> wrote in message
news:GryE1...@world.std.com...
Now that should be worth at least ten points :-)
Ok, got up off floor, back onto chair now.
Paul Repacholi
> "del cecchi" <dce...@msn.com> writes:
>
> > 1. Alpha, including its mismanagement and superior performance.
> > 2. Memory Heirarchy
> > 3. IA64 is a failure
> > 4. Esoteric HPC programming
> > 5. I have a question about....(Homework problems in drag)
> > 6. Back when I was at DEC......... (Leakage from AFC)
> > 7. You are an idiot. No, you are. (was 1:6)
> >
> > Many integers left, any suggestions? :-)
>
> 8. incredible stunts of coding
> 9. brainiac vs. speed demon (megahertz myth)
> 10. servers should never trade cpu/memory slots for I/O
> 11. our great new servers trade cpu/memory slots for I/O
> 12. supercomputer bandwidth, latency, topology, power, cooling
> 13. interconnect theology
> 14. make money now fast $$$
15 All CPUs should have bitcount insns. (this is the Herman closure condition)
Any other subjuct is to be formed by packing the above into bundles of
subjects, and OT rambeling will be limited by extra prefixs that indicate
what is and is not allowed.
Article over 64KB are to replace the header with a 0x45504943 encoding.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Chris Quayle
>
> I suggest Fieldata, thus using only six bits per character.
> The characters can be packed into octets in the obvious manner
> (6 octets containing 8 characters). Doing it this way will make
> long Subject: headers shorter.
>
> I suspect someone from DEC might have another proposal ...
>
Radix50 anyone ?...
Chris
Terje Mathisen
> I suggest Fieldata, thus using only six bits per character.
> The characters can be packed into octets in the obvious manner
> (6 octets containing 8 characters). Doing it this way will make
> long Subject: headers shorter.
>
> I suspect someone from DEC might have another proposal ...
What's wrong with TTY (Baudot) code? The shift-In/Shift-Out codes could
be avoided by staying in letter mode all the time.
An even more advanced system has just recently (compared to the age of
the universe, at least) been revealed to me, named for it's inventor,
Samuel Morse.
The only problem is that it really requires a trinary encoding, for
dot/dash/space.
'subject' would then be encoded with 3+3+4+4+1+4+1+8 (spaces) = 28
symbols, which is roughly comparable to 44.4 binary bits.
Bill Todd
"Chris Quayle" <ligh...@aerosys.co.uk> wrote in message
news:3C77CF31...@aerosys.co.uk...
Fond as my memories of RAD50 are, I fear the term is now out of date. I
propose that it be changed to either RAD40 or RAD28.
- bill
Erik Magnuson
>Hank Oredson wrote:
>> I suggest Fieldata, thus using only six bits per character.
>> The characters can be packed into octets in the obvious manner
>> (6 octets containing 8 characters). Doing it this way will make
>> long Subject: headers shorter.
>>
>> I suspect someone from DEC might have another proposal ...
>
>What's wrong with TTY (Baudot) code? The shift-In/Shift-Out codes could
>be avoided by staying in letter mode all the time.
>
>An even more advanced system has just recently (compared to the age of
>the universe, at least) been revealed to me, named for it's inventor,
>Samuel Morse.
>
>The only problem is that it really requires a trinary encoding, for
>dot/dash/space.
>
>'subject' would then be encoded with 3+3+4+4+1+4+1+8 (spaces) = 28
>symbols, which is roughly comparable to 44.4 binary bits.
>
>Terje
>--
>
Are you talking about Americam Morse code or Continental Morse code? In
American Morse there are short and long spaces inside a symbol - the short
being one dot length and long being two dot lengths.
Erik Magnuson
Hank Oredson
"Terje Mathisen" <terje.m...@hda.hydro.com> wrote in message
news:3C77B394...@hda.hydro.com...
> Hank Oredson wrote:
> > I suggest Fieldata, thus using only six bits per character.
> > The characters can be packed into octets in the obvious manner
> > (6 octets containing 8 characters). Doing it this way will make
> > long Subject: headers shorter.
> >
> > I suspect someone from DEC might have another proposal ...
>
> What's wrong with TTY (Baudot) code? The shift-In/Shift-Out codes could
> be avoided by staying in letter mode all the time.
>
> An even more advanced system has just recently (compared to the age of
> the universe, at least) been revealed to me, named for it's inventor,
> Samuel Morse.
- . .-. .--- .
...- . .-. -.-- --. --- --- -.. .. -.. . .-
> The only problem is that it really requires a trinary encoding, for
> dot/dash/space.
>
> 'subject' would then be encoded with 3+3+4+4+1+4+1+8 (spaces) = 28
> symbols, which is roughly comparable to 44.4 binary bits.
>
> Terje
> --
> - <Terje.M...@hda.hydro.com>
> "almost all programming can be viewed as an exercise in caching"
laura fairhead
Sure. I have only briefly gone through the relevant sections of
that document so far but I'm assuming that any LWSP can just be
deleted from the <text> field (otherwise 'MoreThan' != 'More Than').
What is worrying me here is the trailing white-space on line-2
of that (the second) subject header. Trailing white-space in a
text stream being not guarenteed to be read using a standard
implementation of C/stdio.h. I just wondered if it is really
permissible here, but I'm not at all sure yet...
[]
>
>--
>
> ... Hank
>
>http://horedson.home.att.net
>
>
>
regards
Paul D Fox
> > Radix50 anyone ?...
>
> Fond as my memories of RAD50 are, I fear the term is now out of date. I
> propose that it be changed to either RAD40 or RAD28.
>
> - bill
RAD28 would be good except in a leap year when we would need to use RAD29. :-)
Terje Mathisen
> > the universe, at least) been revealed to me, named for it's inventor,
> > Samuel Morse.
>
> - . .-. .--- .
> ...- . .-. -.-- --. --- --- -.. .. -.. . .-
Thanks. :-)
Terje (LA8NW, since 1978)
Terje Mathisen
> Are you talking about Americam Morse code or Continental Morse code? In
> American Morse there are short and long spaces inside a symbol - the short
> being one dot length and long being two dot lengths.
Even though I've had my ham license since 1978, I've never heard about
long spaces inside symbols!
Why waste time/throughput this way?
The way I learned code, there's a short space, equal to a dot time)
between each dot or dash in a symbol, and then a long space, roughly
comparable to 3 short spaces, between two symbols.
Hank Oredson
Call sounds familiar, wonder if we ever had a QSO.
--
... Hank (W0RLI, since 1953)
Maynard Handley
Peter Boyle <pbo...@holyrood.ed.ac.uk> wrote:
> On 21 Feb 2002, Jeffrey Dutky wrote:
>
> > "del cecchi" <dce...@msn.com>
> > > In order to keep them short, we could just enumerate the 5 or 6 topics
> > > commonly discussed and just use numerals for subjects.
> > >
> > > 1. Alpha, including its mismanagement and superior performance.
> > > 2. Memory Heirarchy
> > > 3. IA64 is a failure
> > > 4. Esoteric HPC programming
> > > 5. I have a question about....(Homework problems in drag)
> > > 6. Back when I was at DEC......... (Leakage from AFC)
> > > 7. You are an idiot. No, you are. (was 1:6)
> > >
> > > Many integers left, any suggestions? :-)
> >
> > 8. My New Idea(TM) for comp.arch stuff
> > 9. A.I. crackpottery
> > 10. misdirected architectural (e.g. buildings) stuff
> > 11. misdirected "My PC is not working" stuff
>
> 12. I'm bored with computing but can't deal with getting flamed
> on rec.lingual.useless.comparisons
> 13. Management/sales/PR are waste of space. Discuss.
14. SMT (by my private never-to-be-explained definition) sucks/is the greatest.
Maynard
Erik Magnuson
>Erik Magnuson wrote:
>> Are you talking about Americam Morse code or Continental Morse code? In
>> American Morse there are short and long spaces inside a symbol - the short
>> being one dot length and long being two dot lengths.
>
>Even though I've had my ham license since 1978, I've never heard about
>long spaces inside symbols!
>
>Why waste time/throughput this way?
>
>The way I learned code, there's a short space, equal to a dot time)
>between each dot or dash in a symbol, and then a long space, roughly
>comparable to 3 short spaces, between two symbols.
>
>Terje
Because "dihdih dih" is distinct from "dihdihdih" and is shorter than
having a dah (dash) in place one of the dihs (dots). American Morse was
primarily used on landlines (e.g. Western Union, railroads) and I've heard
some references to it works better with the sounders than international
Morse. BTW, I've had my license since 1975.
There are a couple of tie-ins with comp.arch. One is that Morse's
telegraph was the first serial implementation - Wheatstone's had five (?)
wires. Another was that Philip Morse, who did a lot of math tables ine the
30's and 40's (also was on CDC's board for a while), is distantly related
to Samuel F B Morse.
Erik Magnuson
Arthur T. Murray
> On 21 Feb 2002, Jeffrey Dutky wrote:
>
>> "del cecchi" <dce...@msn.com>
>> > In order to keep them short, we could just enumerate the 5 or 6
>> > topics commonly discussed and just use numerals for subjects.
>> >
>> > 1. Alpha, including its mismanagement and superior performance.
>> > 2. Memory Heirarchy
>> > 3. IA64 is a failure
>> > 4. Esoteric HPC programming
>> > 5. I have a question about....(Homework problems in drag)
>> > 6. Back when I was at DEC......... (Leakage from AFC)
>> > 7. You are an idiot. No, you are. (was 1:6)
>> >
>> > Many integers left, any suggestions? :-)
>>
>> 8. My New Idea(TM) for comp.arch stuff
>> 9. A.I. crackpottery
No! A.I. is serious business; the crackpottery should be banned.
>> 10. misdirected architectural (e.g. buildings) stuff
>> 11. misdirected "My PC is not working" stuff
>
> 12. I'm bored with computing but can't deal with getting flamed
> on rec.lingual.useless.comparisons
> 13. Management/sales/PR are waste of space. Discuss.
>
> Peter Boyle
>>
>> - Jeff Dutky
Arthur T. Murray
--
http://mind.sourceforge.net/index.html -- the Mind in JavaScript;
http://slashdot.org/~Mentifex/ -- Slashdot User Info for Mentifex
http://www.nanomagazine.com/01_10_24 -- interview @ Nanomagazine;
http://www.scn.org/~mentifex/mind4th.html -- Mind.Forth Robot AI.
Brannon Batson
15. My precise definition for an ambiguous three-letter acronym is
better than yours.
16. These kids today don't know anything about computers because
they've never been inside one.
17. Oh that, that's not new--IBM did that xxx years ago in their
mainframe xxx.
Brannon
Terje Mathisen
>
> On Sun, 24 Feb 2002, Terje Mathisen wrote:
> >The way I learned code, there's a short space, equal to a dot time)
> >between each dot or dash in a symbol, and then a long space, roughly
> >comparable to 3 short spaces, between two symbols.
> >
> >Terje
>
> Because "dihdih dih" is distinct from "dihdihdih" and is shorter than
> having a dah (dash) in place one of the dihs (dots). American Morse was
Sorry for being obtuse, but I still don't get this:
'dihdih dih' is what I'd write as either '.. .' or /.././, in both cases
indicating 'IE', while 'dihdihdih' obviously is 'S'.
OK, here's another example:
Assuming a constant bit rate, TERJE (/-/./.-./.---/./) would be
transmitted as
'111 000 1 000 1011101 000 1011101110111 000 1' (space chars added for
clarity) with a longer pause after the word.
In what way would American Morse be different?
> primarily used on landlines (e.g. Western Union, railroads) and I've heard
> some references to it works better with the sounders than international
> Morse. BTW, I've had my license since 1975.
OK, you beat me by 2 or 3 years (early 1978).
> There are a couple of tie-ins with comp.arch. One is that Morse's
> telegraph was the first serial implementation - Wheatstone's had five (?)
> wires. Another was that Philip Morse, who did a lot of math tables ine the
> 30's and 40's (also was on CDC's board for a while), is distantly related
> to Samuel F B Morse.
The most relevant tie-in must be the original reason I introduced this:
It was the first ever (afaik) attempt at Huffmann style compression,
using shorter strings for common letters.
In fact, it was a pretty good implementation of a pretty good idea!
Hank Oredson
> Erik Magnuson wrote:
> >
> > On Sun, 24 Feb 2002, Terje Mathisen wrote:
> > >The way I learned code, there's a short space, equal to a dot time)
> > >between each dot or dash in a symbol, and then a long space, roughly
> > >comparable to 3 short spaces, between two symbols.
> > >
> > >Terje
> >
> > Because "dihdih dih" is distinct from "dihdihdih" and is shorter than
> > having a dah (dash) in place one of the dihs (dots). American Morse was
>
> Sorry for being obtuse, but I still don't get this:
>
> 'dihdih dih' is what I'd write as either '.. .' or /.././, in both cases
> indicating 'IE', while 'dihdihdih' obviously is 'S'.
>
> OK, here's another example:
>
> Assuming a constant bit rate, TERJE (/-/./.-./.---/./) would be
> transmitted as
> '111 000 1 000 1011101 000 1011101110111 000 1' (space chars added for
> clarity) with a longer pause after the word.
>
> In what way would American Morse be different?
To bring this back to comp.arch a bit:
Both codes attempt to map the most frequently used characters to the shortest
codes.
e is '.', i is '..', t is '-', z is '--..', q is '--.-', comma is '--..--'.
Instruction encodings in certain ISAs (e.g. x86) use the same idea.
One might even say "RISC is like BAUDOT or ASCII, all the
characters are the same length."
American Morse has three different "space" codes.
Inter word space.
Inter character space.
Intra character space. For exampe, .. . is a single character.
(.. . in Continental Morse would be "ie".)
Somewhere I have a book with the specifications for both codes.
In the early 1950s there was a small group of Hams who used
American Morse on 40 M. By 1960 I never heard it any more.
> > primarily used on landlines (e.g. Western Union, railroads) and I've heard
> > some references to it works better with the sounders than international
> > Morse. BTW, I've had my license since 1975.
>
> OK, you beat me by 2 or 3 years (early 1978).
>
> > There are a couple of tie-ins with comp.arch. One is that Morse's
> > telegraph was the first serial implementation - Wheatstone's had five (?)
> > wires. Another was that Philip Morse, who did a lot of math tables ine the
> > 30's and 40's (also was on CDC's board for a while), is distantly related
> > to Samuel F B Morse.
>
> The most relevant tie-in must be the original reason I introduced this:
> It was the first ever (afaik) attempt at Huffmann style compression,
> using shorter strings for common letters.
>
> In fact, it was a pretty good implementation of a pretty good idea!
>
> Terje
--
... Hank
Erik Magnuson
>Erik Magnuson wrote:
>>
>> On Sun, 24 Feb 2002, Terje Mathisen wrote:
>> >The way I learned code, there's a short space, equal to a dot time)
>> >between each dot or dash in a symbol, and then a long space, roughly
>> >comparable to 3 short spaces, between two symbols.
>> >
>> >Terje
>>
>> Because "dihdih dih" is distinct from "dihdihdih" and is shorter than
>> having a dah (dash) in place one of the dihs (dots). American Morse was
>
>Sorry for being obtuse, but I still don't get this:
>
>'dihdih dih' is what I'd write as either '.. .' or /.././, in both cases
>indicating 'IE', while 'dihdihdih' obviously is 'S'.
>
>
>Terje
The difference is that "dihdih dih" (IIRC Am. Morse "C") would be 101001
where "ie" would be 1010001. ISTR that American Morse had an extra long
dash as well.
The Frontierland station of the Disneyland RR (at Disneyland in Anaheim)
has a message in Americn Morse that throws off a lot of hams (me
included). And, FWIW, the FCC does allow use of American Morse (but used
mainly by RR telegraphers).
Erik Magnuson
Don Ames
in CW as opposed to the "Click down" vs "click up of a sounder. While I
have never used a telegraph sounder, I would expect that it is very
different from long an short tones that we think of when we listen to CW
"code".
/don
Terje Mathisen
> The difference is that "dihdih dih" (IIRC Am. Morse "C") would be 101001
> where "ie" would be 1010001. ISTR that American Morse had an extra long
> dash as well.
OK, so it is a totally different encoding scheme, not just a tweaked
implementation.
> The Frontierland station of the Disneyland RR (at Disneyland in Anaheim)
> has a message in Americn Morse that throws off a lot of hams (me
> included). And, FWIW, the FCC does allow use of American Morse (but used
> mainly by RR telegraphers).
Is _that_ why I couldn't make head or tail of that! :-)
Thanks, I learn something new every day.