| Re: Epson printing problems? [message #392963 is a reply to message #392934] |
Fri, 10 April 2020 17:56   |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
<robin.vowels@gmail.com> wrote:
> On Friday, April 10, 2020 at 2:31:31 PM UTC+10, Dave Garland wrote:
>> On 4/9/2020 9:00 PM, r......@gmail.com wrote:
>>> On Thursday, April 9, 2020 at 9:02:10 PM UTC+10, Dan Espen wrote:
>>>> Gareth Evans <h......@yahoo.com> writes:
>>>>
>>>> > On 08/04/2020 23:21, Dan Espen wrote:
>>>> >>
>>>> >> Actually Linux is one of the few OSes that let you get near those
>>>> >> naked blinkenlights.
>>>> >
>>>> > AIUI the 64 bit processors no longer boot as 16 bitters,
>>>> > which counts out MSDOS as an option.
>>>> >
>>>> > How proud I was in 1986 to have the book,
>>>> > "Advanced MSDOS" by Ray Duncan, and how
>>>> > passe it is today!
>>>>
>>>> Hmm, MSDOS annoyed me from day 1.
>>>> What I wanted was a Unix flavor.
>>>> DOS fell short in so many ways.
>>>
>>> DR DOS was better.
>>
>> A bit.
>
> A lot better.
> For one, it was possible to edit a previous command,
> something that MS-DOS never did, and you could not do until
> in DOS under a much later Windows.
>
>> Or MSDOS with 4DOS enhancement. (Norton sold a "NDOS" that was
>> an OEM version of 4DOS.)
>
>>> Unix was crummy. It had documented bugs,
>>> that were never going to be fixed.
>
>> To be fair, all the micro OS had bugs
>
> No they didn't.
“All known bugs are fixed.”
--
Pete
|
|
|
|
| Re: Epson printing problems? [message #392964 is a reply to message #392935] |
Fri, 10 April 2020 17:56 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> On Fri, 2020-04-10, Dave Garland wrote:
> ...
>> IMHO, the LF/CR/CRLF thing is a bogus issue, and mostly always was. It
>> was an arbitrary standard. Yes, CRLF used one character per line more.
>> Maybe if you only had 8K RAM that was an issue. But it wasn't an issue
>> for CP/M-80 with 64K memory, and it's unlikely it ever unduly
>> constrained DOS. And today, who cares? A .docx file with a single line
>> of text is 4217 bytes, nobody will notice if it grows to 4218 bytes.
>
> Bogus in terms of file size, yes, but it still, in 2020, steals
> time for me and the rest of the team.
When you’re storing files on 360K floppies, a few hundred bytes per file
adds up quickly.
--
Pete
|
|
|
|
| Re: Epson printing problems? [message #392966 is a reply to message #392955] |
Fri, 10 April 2020 17:56 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2020-04-10, Scott Lurndal <scott@slp53.sl.home> wrote:
>
>> Gareth Evans <headstone255@yahoo.com> writes:
>>
>>> On 10/04/2020 19:42, Scott Lurndal wrote:
>>>
>>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>>
>>>> > On 10/04/2020 17:11, Scott Lurndal wrote:
>>>> >
>>>> >> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>
>>>> >>> On 09/04/2020 21:55, Dan Espen wrote:
>>>> >>>
>>>> >>> As to multicharacter markers in text files, do you
>>>> >>> object to the \n end of line convention in the C language
>>>> >>> because that takes two characters! :-)
>>>> >>
>>>> >> You do, of course, realize that '\n' translates into a single
>>>> >> byte, right?
>>>> >>
>>>> >> The fact that you need two characters to represent LF in source
>>>> >> is irrelevent. Note that you need four for CRLF (\r\n).
>>>> >
>>>> > Dan was discussing space taken up by text files, of which
>>>> > source files are an example.
>>>>
>>>> A C source file of 4000 lines might have one or two escaped characters
>>>> in it (or fewer, or more, but it's irrelevent to using CRLF as a
>>>> line delimiter). One or two extra backslash instead of 4000 useless
>>>> carriage returns.
>>>
>>> 4000 lines ???? That's 50 pages and a file of that size could
>>> only have been produced by a computing incompetentismo.
>>
>> Evasion noted.
>>
>> We have well over two millions lines of C/C++ code, and several files are
>> in the 2 to 4 thousand line range, even without counting header files that
>> are generated. And there is no "computing incompetentismo" involved.
>
> A couple of my source files have grown to over 10,000 lines.
> Not by design, but changing requirements, plus a compiler that
> can handle it. A single source file makes the makefile smaller.
>
> Small modules are a sign of a short attention span. :-)
>
I have a lot of multi-thousand line modules. I try to keep all related code
together. If the program is organized it’s not difficult to work with.
I recall the days when a program that was a tray of cards (2000 lines) was
pretty big, and anything over a tray was HUGE.
--
Pete
|
|
|
|
| Re: Epson printing problems? [message #392968 is a reply to message #392964] |
Fri, 10 April 2020 20:24 |
|
|
Originally posted by: J. Clarke
On Fri, 10 Apr 2020 14:56:32 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>> On Fri, 2020-04-10, Dave Garland wrote:
>> ...
>>> IMHO, the LF/CR/CRLF thing is a bogus issue, and mostly always was. It
>>> was an arbitrary standard. Yes, CRLF used one character per line more.
>>> Maybe if you only had 8K RAM that was an issue. But it wasn't an issue
>>> for CP/M-80 with 64K memory, and it's unlikely it ever unduly
>>> constrained DOS. And today, who cares? A .docx file with a single line
>>> of text is 4217 bytes, nobody will notice if it grows to 4218 bytes.
>>
>> Bogus in terms of file size, yes, but it still, in 2020, steals
>> time for me and the rest of the team.
>
> When you’re storing files on 360K floppies, a few hundred bytes per file
> adds up quickly.
A hundred nine year old diskettes go for 85 bucks on Amazon. A 2
terabyte USB hard drive goes for 65 bucks at Best Buy. Why does
anybody today store large amounts of data on 360 floppies?
|
|
|
|
| Re: Epson printing problems? [message #392969 is a reply to message #392961] |
Fri, 10 April 2020 20:26 |
|
|
Originally posted by: J. Clarke
On Fri, 10 Apr 2020 14:56:29 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:
> <robin.vowels@gmail.com> wrote:
>> On Friday, April 10, 2020 at 8:55:26 AM UTC+10, John Floren wrote:
>>> Dan Espen <d......@gmail.com> writes:
>>>
>>>> Gareth Evans <h......@yahoo.com> writes:
>>>>
>>>> > On 09/04/2020 15:35, Dan Espen wrote:
>>>> >>
>>>> >> So, DOS had 2 characters to end each line.
>>>> >> Completely ridiculous.
>>>> >
>>>> > If it was CR & LF, then they were control
>>>> > characters for the Teletypes that were extant
>>>> > for many years.
>>>>
>>>> And as I said, that's a completely ridiculous reason to use
>>>> CR/LF as a line ending in files.
>>>>
>>>> Some of those Teletypes you had to send nulls after the CR/LF
>>>> to give the printer time to restore the carriage before you could send
>>>> more data.
>>>
>>> How many DOS machines were ever connected to Teletypes, anyway?
>>
>> Probably most.
>>
>> Are you aware that the serial keyboard/printer attached to a DOS machine
>> could be used as a terminal? The keyboard of the DOS machine
>> could be reassigned to the keyboard/printer, thereby obtaining
>> not only what was typed at the keyboard, but the interleaved
>> responses from DOS.
>>
>>> It's
>>> before my time, but I'd assume that graphical terminals were pretty
>>> common by the time they wrote MS-DOS.
>>
>> Sure, but graphical terminals were fairly expensive, whereas
>> teleprinters could be obtained for a few dollars.
>
> Only a while after graphical terminals go cheap. A real Teletype was a
> pretty expensive piece of gear.
A real _new_ Teletype was. An old one could be had fairly cheap in
1974 or thereabouts. I remember my girlfriend at the time had just
dumped her husband because he spent the rent money on a teletype.
|
|
|
|
| Re: Epson printing problems? [message #392970 is a reply to message #392959] |
Fri, 10 April 2020 20:27 |
|
|
Originally posted by: J. Clarke
On Fri, 10 Apr 2020 17:13:25 -0400, Dan Espen <dan1espen@gmail.com>
wrote:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>
>> On 2020-04-10, Scott Lurndal <scott@slp53.sl.home> wrote:
>>
>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>
>>>> On 10/04/2020 19:42, Scott Lurndal wrote:
>>>>
>>>> > Gareth Evans <headstone255@yahoo.com> writes:
>>>> >
>>>> >> On 10/04/2020 17:11, Scott Lurndal wrote:
>>>> >>
>>>> >>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>>
>>>> >>>> On 09/04/2020 21:55, Dan Espen wrote:
>>>> >>>>
>>>> >>>> As to multicharacter markers in text files, do you
>>>> >>>> object to the \n end of line convention in the C language
>>>> >>>> because that takes two characters! :-)
>>>> >>>
>>>> >>> You do, of course, realize that '\n' translates into a single
>>>> >>> byte, right?
>>>> >>>
>>>> >>> The fact that you need two characters to represent LF in source
>>>> >>> is irrelevent. Note that you need four for CRLF (\r\n).
>>>> >>
>>>> >> Dan was discussing space taken up by text files, of which
>>>> >> source files are an example.
>>>> >
>>>> > A C source file of 4000 lines might have one or two escaped characters
>>>> > in it (or fewer, or more, but it's irrelevent to using CRLF as a
>>>> > line delimiter). One or two extra backslash instead of 4000 useless
>>>> > carriage returns.
>>>>
>>>> 4000 lines ???? That's 50 pages and a file of that size could
>>>> only have been produced by a computing incompetentismo.
>>>
>>> Evasion noted.
>>>
>>> We have well over two millions lines of C/C++ code, and several files are
>>> in the 2 to 4 thousand line range, even without counting header files that
>>> are generated. And there is no "computing incompetentismo" involved.
>>
>> A couple of my source files have grown to over 10,000 lines.
>> Not by design, but changing requirements, plus a compiler that
>> can handle it. A single source file makes the makefile smaller.
>>
>> Small modules are a sign of a short attention span. :-)
>
> 10K is way out there, I've seen that size with COBOL but it wasn't pleasant.
> If there is any pattern to that 10K of source code perhaps a code
> generator can condense some of it.
>
> I've taken good line counts out of Assembler and C buy writing macros.
The trouble is that you have to find the time to analyze it and make
the changes and test them.
|
|
|
|
| Re: Epson printing problems? [message #392971 is a reply to message #392958] |
Fri, 10 April 2020 20:30 |
|
|
Originally posted by: J. Clarke
On Fri, 10 Apr 2020 17:04:59 -0400, Dan Espen <dan1espen@gmail.com>
wrote:
> Gareth Evans <headstone255@yahoo.com> writes:
>
>> On 10/04/2020 19:42, Scott Lurndal wrote:
>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> On 10/04/2020 17:11, Scott Lurndal wrote:
>>>> > Gareth Evans <headstone255@yahoo.com> writes:
>>>> >> On 09/04/2020 21:55, Dan Espen wrote:
>>>> >
>>>> >> As to multicharacter markers in text files, do you
>>>> >> object to the \n end of line convention in the C language
>>>> >> because that takes two characters! :-)
>>>> >>
>>>> >
>>>> > You do, of course, realize that '\n' translates into a single
>>>> > byte, right?
>>>> >
>>>> > The fact that you need two characters to represent LF in source
>>>> > is irrelevent. Note that you need four for CRLF (\r\n).
>>>> >
>>>>
>>>> Dan was discussing space taken up by text files, of which
>>>> source files are an example.
>>>>
>>>
>>> A C source file of 4000 lines might have one or two escaped characters
>>> in it (or fewer, or more, but it's irrelevent to using CRLF as a
>>> line delimiter). One or two extra backslash instead of 4000 useless carriage returns.
>>>
>>
>> 4000 lines ???? That's 50 pages and a file of that size could
>> only have been produced by a computing incompetentismo.
>
> Well, I guess we are talking about C, but 4000 lines for COBOL
> is very common.
>
> With C, I've seen a few that size. Big complicated applications require
> that. I've seen attempts to break big applications into dozens of
> called modules. You end up with a nest where you can't find anything.
> (Even with the help of TAGS.)
>
> A few decades back I got temporary ownership of a huge C module.
> Even though the code was all in one module, it was still hard to find
> your way through the code.
>
> So, I looked for ways to use separate called modules and there was
> plenty of called modules, but so much shared stuff that the module
> resisted my efforts.
>
> So, I took a few hours and renamed all the called subroutines using
> COBOL rules. It looked pretty weird, C code like this:
>
> int b100_findstuff(int num, char* dta) {
> x100_getzip();
> }
>
> I then went through the prefixes (like b100,x100) and made them reflect
> the calling hierarchy.
> Then I moved all the code into alphanumeric order.
>
> Then I fixed the reason I was in the code in the first place.
>
> The other developers with years of C said they loved it.
That's a good idea. I have a ton of APL that is difficult to wade
through with which I might try that.
|
|
|
|
| Re: Epson printing problems? [message #392972 is a reply to message #392968] |
Fri, 10 April 2020 20:36 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> wrote:
> On Fri, 10 Apr 2020 14:56:32 -0700, Peter Flass
> <peter_flass@yahoo.com> wrote:
>
>> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>>> On Fri, 2020-04-10, Dave Garland wrote:
>>> ...
>>>> IMHO, the LF/CR/CRLF thing is a bogus issue, and mostly always was. It
>>>> was an arbitrary standard. Yes, CRLF used one character per line more.
>>>> Maybe if you only had 8K RAM that was an issue. But it wasn't an issue
>>>> for CP/M-80 with 64K memory, and it's unlikely it ever unduly
>>>> constrained DOS. And today, who cares? A .docx file with a single line
>>>> of text is 4217 bytes, nobody will notice if it grows to 4218 bytes.
>>>
>>> Bogus in terms of file size, yes, but it still, in 2020, steals
>>> time for me and the rest of the team.
>>
>> When you’re storing files on 360K floppies, a few hundred bytes per file
>> adds up quickly.
>
> A hundred nine year old diskettes go for 85 bucks on Amazon. A 2
> terabyte USB hard drive goes for 65 bucks at Best Buy. Why does
> anybody today store large amounts of data on 360 floppies?
>
We were talking about DOS. Many early systems only had floppies.
--
Pete
|
|
|
|
| Re: Epson printing problems? [message #392973 is a reply to message #392946] |
Fri, 10 April 2020 20:54 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, April 11, 2020 at 2:13:44 AM UTC+10, Scott Lurndal wrote:
> r......@gmail.com writes:
>> On Friday, April 10, 2020 at 4:21:29 AM UTC+10, Scott Lurndal wrote:
>
>>
>> And Teleprinters and Teletypes predated Unix by some 50 years
>> so there was a precedent for using CR LF.
>
> Not in file storage, Rod.
Rubbish.
> And the machines using those teleprinters and teletypes had
> device drivers that handled the device requirements.
Again, Rubbish. How is the "device driver" going to know
when to issue a CR and LF? (see also below)
>>> There is no need to store both characters on every line in a text file.
>>
>> There was, because of the need to copy a file to a teleprinter
>> or other serial devices.
>
> Nonsense, Rod.
How so? If there's a file on disc that is to be printed to
a serial printer (e.g., a Teletype), how do you suppose that
the relevant CR and LF can be given at the appropriate moment?
For that matter, how do you suppose that a page throw or tab,
or print on same line, or even a BELL can be issued?
|
|
|
|
| Re: Epson printing problems? [message #392974 is a reply to message #392786] |
Fri, 10 April 2020 20:55 |
|
|
Originally posted by: J. Clarke
On Thu, 9 Apr 2020 23:31:27 -0500, Dave Garland
<dave.garland@wizinfo.com> wrote:
> On 4/9/2020 9:00 PM, robin.vowels@gmail.com wrote:
>> On Thursday, April 9, 2020 at 9:02:10 PM UTC+10, Dan Espen wrote:
>>> Gareth Evans <h......@yahoo.com> writes:
>>>
>>>> On 08/04/2020 23:21, Dan Espen wrote:
>>>> >
>>>> > Actually Linux is one of the few OSes that let you get near those
>>>> > naked blinkenlights.
>>>>
>>>> AIUI the 64 bit processors no longer boot as 16 bitters,
>>>> which counts out MSDOS as an option.
>>>>
>>>> How proud I was in 1986 to have the book,
>>>> "Advanced MSDOS" by Ray Duncan, and how
>>>> passe it is today!
>>>
>>> Hmm, MSDOS annoyed me from day 1.
>>> What I wanted was a Unix flavor.
>>> DOS fell short in so many ways.
>>
>> DR DOS was better.
>
> A bit. Or MSDOS with 4DOS enhancement. (Norton sold a "NDOS" that was
> an OEM version of 4DOS.)
>
>>
>> Unix was crummy. It had documented bugs,
>> that were never going to be fixed.
>>
> To be fair, all the micro OS had bugs (as do all OS even today). Not
> all of them documented. I don't think the real UNIX ever ran on
> microcomputers.
Of course it did.
The porting base for System V Release 3 was the 3B2, which used a
Western Electric WE-3200 microprocessor.
The porting bases for SVR4 were the x86 and Sparc.
And SVR2 was available for the 80286--AT&T shipped an Olivetti-made
286 machine with SVR2 bundled.
And AT&T Unix was ported to many other architectures, a lot of them
micros.
> The problem with its clones (and the reason I didn't
> get an *IX) was cost. IIRC the options were all hundreds or thousands
> of dollars, where MSDOS was reasonable (or free, if you took
> liberties). BSD did exist, but they had legal problems with ATT and it
> wasn't clear they'd survive that. As a one man shop, I couldn't afford
> to gamble.
|
|
|
|
| Re: Epson printing problems? [message #392975 is a reply to message #392970] |
Fri, 10 April 2020 20:58 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> writes:
> On Fri, 10 Apr 2020 17:13:25 -0400, Dan Espen <dan1espen@gmail.com>
> wrote:
>
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>
>>> On 2020-04-10, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>
>>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>>
>>>> > On 10/04/2020 19:42, Scott Lurndal wrote:
>>>> >
>>>> >> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>
>>>> >>> On 10/04/2020 17:11, Scott Lurndal wrote:
>>>> >>>
>>>> >>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>>>
>>>> >>>>> On 09/04/2020 21:55, Dan Espen wrote:
>>>> >>>>>
>>>> >>>>> As to multicharacter markers in text files, do you
>>>> >>>>> object to the \n end of line convention in the C language
>>>> >>>>> because that takes two characters! :-)
>>>> >>>>
>>>> >>>> You do, of course, realize that '\n' translates into a single
>>>> >>>> byte, right?
>>>> >>>>
>>>> >>>> The fact that you need two characters to represent LF in source
>>>> >>>> is irrelevent. Note that you need four for CRLF (\r\n).
>>>> >>>
>>>> >>> Dan was discussing space taken up by text files, of which
>>>> >>> source files are an example.
>>>> >>
>>>> >> A C source file of 4000 lines might have one or two escaped characters
>>>> >> in it (or fewer, or more, but it's irrelevent to using CRLF as a
>>>> >> line delimiter). One or two extra backslash instead of 4000 useless
>>>> >> carriage returns.
>>>> >
>>>> > 4000 lines ???? That's 50 pages and a file of that size could
>>>> > only have been produced by a computing incompetentismo.
>>>>
>>>> Evasion noted.
>>>>
>>>> We have well over two millions lines of C/C++ code, and several files are
>>>> in the 2 to 4 thousand line range, even without counting header files that
>>>> are generated. And there is no "computing incompetentismo" involved.
>>>
>>> A couple of my source files have grown to over 10,000 lines.
>>> Not by design, but changing requirements, plus a compiler that
>>> can handle it. A single source file makes the makefile smaller.
>>>
>>> Small modules are a sign of a short attention span. :-)
>>
>> 10K is way out there, I've seen that size with COBOL but it wasn't pleasant.
>> If there is any pattern to that 10K of source code perhaps a code
>> generator can condense some of it.
>>
>> I've taken good line counts out of Assembler and C buy writing macros.
>
> The trouble is that you have to find the time to analyze it and make
> the changes and test them.
How is that trouble?
Isn't improving the code part of your job description?
Anyway, I'm pretty sure how you'll answer.
I know if you ask your boss, he'll always ask for quick and dirty.
But cleaning up code is it's own reward.
--
Dan Espen
|
|
|
|
| Re: Epson printing problems? [message #392976 is a reply to message #392972] |
Fri, 10 April 2020 20:59 |
|
|
Originally posted by: J. Clarke
On Fri, 10 Apr 2020 17:36:10 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:
> J. Clarke <jclarke.873638@gmail.com> wrote:
>> On Fri, 10 Apr 2020 14:56:32 -0700, Peter Flass
>> <peter_flass@yahoo.com> wrote:
>>
>>> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>>>> On Fri, 2020-04-10, Dave Garland wrote:
>>>> ...
>>>> > IMHO, the LF/CR/CRLF thing is a bogus issue, and mostly always was. It
>>>> > was an arbitrary standard. Yes, CRLF used one character per line more.
>>>> > Maybe if you only had 8K RAM that was an issue. But it wasn't an issue
>>>> > for CP/M-80 with 64K memory, and it's unlikely it ever unduly
>>>> > constrained DOS. And today, who cares? A .docx file with a single line
>>>> > of text is 4217 bytes, nobody will notice if it grows to 4218 bytes.
>>>>
>>>> Bogus in terms of file size, yes, but it still, in 2020, steals
>>>> time for me and the rest of the team.
>>>
>>> When you’re storing files on 360K floppies, a few hundred bytes per file
>>> adds up quickly.
>>
>> A hundred nine year old diskettes go for 85 bucks on Amazon. A 2
>> terabyte USB hard drive goes for 65 bucks at Best Buy. Why does
>> anybody today store large amounts of data on 360 floppies?
>>
>
> We were talking about DOS. Many early systems only had floppies.
You were responding to a statement "in 2020". In 2020 any diskettes
you have are ancient and huge hard drives are dirt cheap.
And the second generation of the IBM PC had a hard disk available. I
don't recall when it became a given that a machine would have one but
that was long before DOS disappeared from the market.
|
|
|
|
| Re: Epson printing problems? [message #392977 is a reply to message #392954] |
Fri, 10 April 2020 21:01 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, April 11, 2020 at 5:35:51 AM UTC+10, Charlie Gibbs wrote:
> On 2020-04-10, <r......@gmail.com> wrote:
>
>> On Friday, April 10, 2020 at 3:30:00 AM UTC+10, Scott Lurndal wrote:
>>
>>> Gareth Evans <h......@yahoo.com> writes:
>>>
>>>> On 09/04/2020 15:35, Dan Espen wrote:
>>>>
>>>> > So, DOS had 2 characters to end each line.
>>>> > Completely ridiculous.
>>>>
>>>> If it was CR & LF, then they were control
>>>> characters for the Teletypes that were extant
>>>> for many years.
>>>
>>> Indeed, but only one of the two characters are necessary
>>> to terminate a line;
>>
>> True, for keyboard input.
>>
>>> both just waste space.
>>
>> And how do you suppose a file sent to a printer such
>> as as a Teletype or one of the many different kinds of
>> serial printers will print unless it has CR and LF in it?
>
> A properly-written driver can take care of that,
You have side-stepped the question.
Exactly how is the "driver" going to take care of that?
It doesn't know where the ends of lines are? [without
CRLF)
> as well as
> inserting enough NULs to give the print head time to get back
> to the left. (Ever seen a Teletype scatter characters backwards
> across a line because it had no NUL padding?)
I've seen that when the LF is given before the CR in data
prepared for imput.
|
|
|
|
| Re: Epson printing problems? [message #392978 is a reply to message #392971] |
Fri, 10 April 2020 21:03 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> writes:
> On Fri, 10 Apr 2020 17:04:59 -0400, Dan Espen <dan1espen@gmail.com>
> wrote:
>
>> Gareth Evans <headstone255@yahoo.com> writes:
>>
>>> On 10/04/2020 19:42, Scott Lurndal wrote:
>>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> > On 10/04/2020 17:11, Scott Lurndal wrote:
>>>> >> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>> On 09/04/2020 21:55, Dan Espen wrote:
>>>> >>
>>>> >>> As to multicharacter markers in text files, do you
>>>> >>> object to the \n end of line convention in the C language
>>>> >>> because that takes two characters! :-)
>>>> >>>
>>>> >>
>>>> >> You do, of course, realize that '\n' translates into a single
>>>> >> byte, right?
>>>> >>
>>>> >> The fact that you need two characters to represent LF in source
>>>> >> is irrelevent. Note that you need four for CRLF (\r\n).
>>>> >>
>>>> >
>>>> > Dan was discussing space taken up by text files, of which
>>>> > source files are an example.
>>>> >
>>>>
>>>> A C source file of 4000 lines might have one or two escaped characters
>>>> in it (or fewer, or more, but it's irrelevent to using CRLF as a
>>>> line delimiter). One or two extra backslash instead of 4000 useless carriage returns.
>>>>
>>>
>>> 4000 lines ???? That's 50 pages and a file of that size could
>>> only have been produced by a computing incompetentismo.
>>
>> Well, I guess we are talking about C, but 4000 lines for COBOL
>> is very common.
>>
>> With C, I've seen a few that size. Big complicated applications require
>> that. I've seen attempts to break big applications into dozens of
>> called modules. You end up with a nest where you can't find anything.
>> (Even with the help of TAGS.)
>>
>> A few decades back I got temporary ownership of a huge C module.
>> Even though the code was all in one module, it was still hard to find
>> your way through the code.
>>
>> So, I looked for ways to use separate called modules and there was
>> plenty of called modules, but so much shared stuff that the module
>> resisted my efforts.
>>
>> So, I took a few hours and renamed all the called subroutines using
>> COBOL rules. It looked pretty weird, C code like this:
>>
>> int b100_findstuff(int num, char* dta) {
>> x100_getzip();
>> }
>>
>> I then went through the prefixes (like b100,x100) and made them reflect
>> the calling hierarchy.
>> Then I moved all the code into alphanumeric order.
>>
>> Then I fixed the reason I was in the code in the first place.
>>
>> The other developers with years of C said they loved it.
>
> That's a good idea. I have a ton of APL that is difficult to wade
> through with which I might try that.
I didn't know APL had subroutines, isn't APL supposed to be one line
long?
Joking aside, it really helped me and everyone that came after me
and it's a sort of mindless process. Sure you have to test but
renaming and rearranging shouldn't cause a lot of problems.
--
Dan Espen
|
|
|
|
| Re: Epson printing problems? [message #392979 is a reply to message #392961] |
Fri, 10 April 2020 21:09 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, April 11, 2020 at 7:56:30 AM UTC+10, Peter Flass wrote:
> <r......@gmail.com> wrote:
>> On Friday, April 10, 2020 at 8:55:26 AM UTC+10, John Floren wrote:
>>> Dan Espen <d......@gmail.com> writes:
>>>
>>>> Gareth Evans <h......@yahoo.com> writes:
>>>>
>>>> > On 09/04/2020 15:35, Dan Espen wrote:
>>>> >>
>>>> >> So, DOS had 2 characters to end each line.
>>>> >> Completely ridiculous.
>>>> >
>>>> > If it was CR & LF, then they were control
>>>> > characters for the Teletypes that were extant
>>>> > for many years.
>>>>
>>>> And as I said, that's a completely ridiculous reason to use
>>>> CR/LF as a line ending in files.
>>>>
>>>> Some of those Teletypes you had to send nulls after the CR/LF
>>>> to give the printer time to restore the carriage before you could send
>>>> more data.
>>>
>>> How many DOS machines were ever connected to Teletypes, anyway?
>>
>> Probably most.
>>
>> Are you aware that the serial keyboard/printer attached to a DOS machine
>> could be used as a terminal? The keyboard of the DOS machine
>> could be reassigned to the keyboard/printer, thereby obtaining
>> not only what was typed at the keyboard, but the interleaved
>> responses from DOS.
>>
>>> It's
>>> before my time, but I'd assume that graphical terminals were pretty
>>> common by the time they wrote MS-DOS.
>>
>> Sure, but graphical terminals were fairly expensive, whereas
>> teleprinters could be obtained for a few dollars.
>
> Only a while after graphical terminals go cheap. A real Teletype was a
> pretty expensive piece of gear.
Only the ASR 38. The more-common variety 33 could be picked up for
a few dollars.
|
|
|
|
| Re: Epson printing problems? [message #392980 is a reply to message #392968] |
Fri, 10 April 2020 21:13 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, April 11, 2020 at 10:24:26 AM UTC+10, J. Clarke wrote:
> On Fri, 10 Apr 2020 14:56:32 -0700, Peter Flass
> <p......@yahoo.com> wrote:
>
>> Jorgen Grahn <g......@snipabacken.se> wrote:
>>> On Fri, 2020-04-10, Dave Garland wrote:
>>> ...
>>>> IMHO, the LF/CR/CRLF thing is a bogus issue, and mostly always was. It
>>>> was an arbitrary standard. Yes, CRLF used one character per line more..
>>>> Maybe if you only had 8K RAM that was an issue. But it wasn't an issue
>>>> for CP/M-80 with 64K memory, and it's unlikely it ever unduly
>>>> constrained DOS. And today, who cares? A .docx file with a single line
>>>> of text is 4217 bytes, nobody will notice if it grows to 4218 bytes.
>>>
>>> Bogus in terms of file size, yes, but it still, in 2020, steals
>>> time for me and the rest of the team.
>>
>> When you’re storing files on 360K floppies, a few hundred bytes per file
>> adds up quickly.
>
> A hundred nine year old diskettes go for 85 bucks on Amazon. A 2
> terabyte USB hard drive goes for 65 bucks at Best Buy. Why does
> anybody today store large amounts of data on 360 floppies?
um, I think that the size of floppies has long been 1.44Mb.
|
|
|
|
| Re: Epson printing problems? [message #392981 is a reply to message #392969] |
Fri, 10 April 2020 21:15 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, April 11, 2020 at 10:26:23 AM UTC+10, J. Clarke wrote:
> On Fri, 10 Apr 2020 14:56:29 -0700, Peter Flass
> <p......@yahoo.com> wrote:
>
>> <r......@gmail.com> wrote:
>>> On Friday, April 10, 2020 at 8:55:26 AM UTC+10, John Floren wrote:
>>>> Dan Espen <d......@gmail.com> writes:
>>>>
>>>> > Gareth Evans <h......@yahoo.com> writes:
>>>> >
>>>> >> On 09/04/2020 15:35, Dan Espen wrote:
>>>> >>>
>>>> >>> So, DOS had 2 characters to end each line.
>>>> >>> Completely ridiculous.
>>>> >>
>>>> >> If it was CR & LF, then they were control
>>>> >> characters for the Teletypes that were extant
>>>> >> for many years.
>>>> >
>>>> > And as I said, that's a completely ridiculous reason to use
>>>> > CR/LF as a line ending in files.
>>>> >
>>>> > Some of those Teletypes you had to send nulls after the CR/LF
>>>> > to give the printer time to restore the carriage before you could send
>>>> > more data.
>>>>
>>>> How many DOS machines were ever connected to Teletypes, anyway?
>>>
>>> Probably most.
>>>
>>> Are you aware that the serial keyboard/printer attached to a DOS machine
>>> could be used as a terminal? The keyboard of the DOS machine
>>> could be reassigned to the keyboard/printer, thereby obtaining
>>> not only what was typed at the keyboard, but the interleaved
>>> responses from DOS.
>>>
>>>> It's
>>>> before my time, but I'd assume that graphical terminals were pretty
>>>> common by the time they wrote MS-DOS.
>>>
>>> Sure, but graphical terminals were fairly expensive, whereas
>>> teleprinters could be obtained for a few dollars.
>>
>> Only a while after graphical terminals go cheap. A real Teletype was a
>> pretty expensive piece of gear.
>
> A real _new_ Teletype was. An old one could be had fairly cheap in
> 1974 or thereabouts. I remember my girlfriend at the time had just
> dumped her husband because he spent the rent money on a teletype.
Glass teletypes were certainly around by 1969. and possibly by 1966.
|
|
|
|
| Re: Epson printing problems? [message #392982 is a reply to message #392977] |
Fri, 10 April 2020 21:34 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
<robin.vowels@gmail.com> wrote:
> On Saturday, April 11, 2020 at 5:35:51 AM UTC+10, Charlie Gibbs wrote:
>> On 2020-04-10, <r......@gmail.com> wrote:
>>
>>> On Friday, April 10, 2020 at 3:30:00 AM UTC+10, Scott Lurndal wrote:
>>>
>>>> Gareth Evans <h......@yahoo.com> writes:
>>>>
>>>> > On 09/04/2020 15:35, Dan Espen wrote:
>>>> >
>>>> >> So, DOS had 2 characters to end each line.
>>>> >> Completely ridiculous.
>>>> >
>>>> > If it was CR & LF, then they were control
>>>> > characters for the Teletypes that were extant
>>>> > for many years.
>>>>
>>>> Indeed, but only one of the two characters are necessary
>>>> to terminate a line;
>>>
>>> True, for keyboard input.
>>>
>>>> both just waste space.
>>>
>>> And how do you suppose a file sent to a printer such
>>> as as a Teletype or one of the many different kinds of
>>> serial printers will print unless it has CR and LF in it?
>>
>> A properly-written driver can take care of that,
>
> You have side-stepped the question.
> Exactly how is the "driver" going to take care of that?
> It doesn't know where the ends of lines are? [without
> CRLF)
I see this was answered above - only one character needed, two are
redundant. Also, there are other ways to define line length besides using a
terminating character.
--
Pete
|
|
|
|
| Re: Epson printing problems? [message #392983 is a reply to message #392978] |
Fri, 10 April 2020 21:34 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> J. Clarke <jclarke.873638@gmail.com> writes:
>
>> On Fri, 10 Apr 2020 17:04:59 -0400, Dan Espen <dan1espen@gmail.com>
>> wrote:
>>
>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>
>>>> On 10/04/2020 19:42, Scott Lurndal wrote:
>>>> > Gareth Evans <headstone255@yahoo.com> writes:
>>>> >> On 10/04/2020 17:11, Scott Lurndal wrote:
>>>> >>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>>> On 09/04/2020 21:55, Dan Espen wrote:
>>>> >>>
>>>> >>>> As to multicharacter markers in text files, do you
>>>> >>>> object to the \n end of line convention in the C language
>>>> >>>> because that takes two characters! :-)
>>>> >>>>
>>>> >>>
>>>> >>> You do, of course, realize that '\n' translates into a single
>>>> >>> byte, right?
>>>> >>>
>>>> >>> The fact that you need two characters to represent LF in source
>>>> >>> is irrelevent. Note that you need four for CRLF (\r\n).
>>>> >>>
>>>> >>
>>>> >> Dan was discussing space taken up by text files, of which
>>>> >> source files are an example.
>>>> >>
>>>> >
>>>> > A C source file of 4000 lines might have one or two escaped characters
>>>> > in it (or fewer, or more, but it's irrelevent to using CRLF as a
>>>> > line delimiter). One or two extra backslash instead of 4000 useless carriage returns.
>>>> >
>>>>
>>>> 4000 lines ???? That's 50 pages and a file of that size could
>>>> only have been produced by a computing incompetentismo.
>>>
>>> Well, I guess we are talking about C, but 4000 lines for COBOL
>>> is very common.
>>>
>>> With C, I've seen a few that size. Big complicated applications require
>>> that. I've seen attempts to break big applications into dozens of
>>> called modules. You end up with a nest where you can't find anything.
>>> (Even with the help of TAGS.)
>>>
>>> A few decades back I got temporary ownership of a huge C module.
>>> Even though the code was all in one module, it was still hard to find
>>> your way through the code.
>>>
>>> So, I looked for ways to use separate called modules and there was
>>> plenty of called modules, but so much shared stuff that the module
>>> resisted my efforts.
>>>
>>> So, I took a few hours and renamed all the called subroutines using
>>> COBOL rules. It looked pretty weird, C code like this:
>>>
>>> int b100_findstuff(int num, char* dta) {
>>> x100_getzip();
>>> }
>>>
>>> I then went through the prefixes (like b100,x100) and made them reflect
>>> the calling hierarchy.
>>> Then I moved all the code into alphanumeric order.
>>>
>>> Then I fixed the reason I was in the code in the first place.
>>>
>>> The other developers with years of C said they loved it.
>>
>> That's a good idea. I have a ton of APL that is difficult to wade
>> through with which I might try that.
>
> I didn't know APL had subroutines, isn't APL supposed to be one line
> long?
>
> Joking aside, it really helped me and everyone that came after me
> and it's a sort of mindless process. Sure you have to test but
> renaming and rearranging shouldn't cause a lot of problems.
>
It can with COBOL. Somewhere it says perform a thru c and somewhere else
it’s perform b thru d (assuming paragraphs are in alphabetical order in the
source. Moving them around will cause a mess. Sure it’s terrible code, but
I’ve seen worse.
--
Pete
|
|
|
|
| Re: Epson printing problems? [message #392984 is a reply to message #392981] |
Fri, 10 April 2020 21:34 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
<robin.vowels@gmail.com> wrote:
> On Saturday, April 11, 2020 at 10:26:23 AM UTC+10, J. Clarke wrote:
>> On Fri, 10 Apr 2020 14:56:29 -0700, Peter Flass
>> <p......@yahoo.com> wrote:
>>
>>> <r......@gmail.com> wrote:
>>>> On Friday, April 10, 2020 at 8:55:26 AM UTC+10, John Floren wrote:
>>>> > Dan Espen <d......@gmail.com> writes:
>>>> >
>>>> >> Gareth Evans <h......@yahoo.com> writes:
>>>> >>
>>>> >>> On 09/04/2020 15:35, Dan Espen wrote:
>>>> >>>>
>>>> >>>> So, DOS had 2 characters to end each line.
>>>> >>>> Completely ridiculous.
>>>> >>>
>>>> >>> If it was CR & LF, then they were control
>>>> >>> characters for the Teletypes that were extant
>>>> >>> for many years.
>>>> >>
>>>> >> And as I said, that's a completely ridiculous reason to use
>>>> >> CR/LF as a line ending in files.
>>>> >>
>>>> >> Some of those Teletypes you had to send nulls after the CR/LF
>>>> >> to give the printer time to restore the carriage before you could send
>>>> >> more data.
>>>> >
>>>> > How many DOS machines were ever connected to Teletypes, anyway?
>>>>
>>>> Probably most.
>>>>
>>>> Are you aware that the serial keyboard/printer attached to a DOS machine
>>>> could be used as a terminal? The keyboard of the DOS machine
>>>> could be reassigned to the keyboard/printer, thereby obtaining
>>>> not only what was typed at the keyboard, but the interleaved
>>>> responses from DOS.
>>>>
>>>> > It's
>>>> > before my time, but I'd assume that graphical terminals were pretty
>>>> > common by the time they wrote MS-DOS.
>>>>
>>>> Sure, but graphical terminals were fairly expensive, whereas
>>>> teleprinters could be obtained for a few dollars.
>>>
>>> Only a while after graphical terminals go cheap. A real Teletype was a
>>> pretty expensive piece of gear.
>>
>> A real _new_ Teletype was. An old one could be had fairly cheap in
>> 1974 or thereabouts. I remember my girlfriend at the time had just
>> dumped her husband because he spent the rent money on a teletype.
>
> Glass teletypes were certainly around by 1969. and possibly by 1966.
>
I think they were fairly expensive initially. Later, of course, prices
dropped.
--
Pete
|
|
|
|
| Re: Epson printing problems? [message #392985 is a reply to message #392975] |
Fri, 10 April 2020 21:50 |
|
|
Originally posted by: J. Clarke
On Fri, 10 Apr 2020 20:58:41 -0400, Dan Espen <dan1espen@gmail.com>
wrote:
> J. Clarke <jclarke.873638@gmail.com> writes:
>
>> On Fri, 10 Apr 2020 17:13:25 -0400, Dan Espen <dan1espen@gmail.com>
>> wrote:
>>
>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>>
>>>> On 2020-04-10, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>>
>>>> > Gareth Evans <headstone255@yahoo.com> writes:
>>>> >
>>>> >> On 10/04/2020 19:42, Scott Lurndal wrote:
>>>> >>
>>>> >>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>>
>>>> >>>> On 10/04/2020 17:11, Scott Lurndal wrote:
>>>> >>>>
>>>> >>>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>>>>
>>>> >>>>>> On 09/04/2020 21:55, Dan Espen wrote:
>>>> >>>>>>
>>>> >>>>>> As to multicharacter markers in text files, do you
>>>> >>>>>> object to the \n end of line convention in the C language
>>>> >>>>>> because that takes two characters! :-)
>>>> >>>>>
>>>> >>>>> You do, of course, realize that '\n' translates into a single
>>>> >>>>> byte, right?
>>>> >>>>>
>>>> >>>>> The fact that you need two characters to represent LF in source
>>>> >>>>> is irrelevent. Note that you need four for CRLF (\r\n).
>>>> >>>>
>>>> >>>> Dan was discussing space taken up by text files, of which
>>>> >>>> source files are an example.
>>>> >>>
>>>> >>> A C source file of 4000 lines might have one or two escaped characters
>>>> >>> in it (or fewer, or more, but it's irrelevent to using CRLF as a
>>>> >>> line delimiter). One or two extra backslash instead of 4000 useless
>>>> >>> carriage returns.
>>>> >>
>>>> >> 4000 lines ???? That's 50 pages and a file of that size could
>>>> >> only have been produced by a computing incompetentismo.
>>>> >
>>>> > Evasion noted.
>>>> >
>>>> > We have well over two millions lines of C/C++ code, and several files are
>>>> > in the 2 to 4 thousand line range, even without counting header files that
>>>> > are generated. And there is no "computing incompetentismo" involved.
>>>>
>>>> A couple of my source files have grown to over 10,000 lines.
>>>> Not by design, but changing requirements, plus a compiler that
>>>> can handle it. A single source file makes the makefile smaller.
>>>>
>>>> Small modules are a sign of a short attention span. :-)
>>>
>>> 10K is way out there, I've seen that size with COBOL but it wasn't pleasant.
>>> If there is any pattern to that 10K of source code perhaps a code
>>> generator can condense some of it.
>>>
>>> I've taken good line counts out of Assembler and C buy writing macros.
>>
>> The trouble is that you have to find the time to analyze it and make
>> the changes and test them.
>
> How is that trouble?
>
> Isn't improving the code part of your job description?
Nope.
> Anyway, I'm pretty sure how you'll answer.
> I know if you ask your boss, he'll always ask for quick and dirty.
> But cleaning up code is it's own reward.
She doesn't care how I do my job. But she does care that I get
everything that she's told me to do done soon enough that it doesn't
keep someone else from meeting their deadlines. And our deadlines are
hard deadlines--we have to have x results available for the board of
directors meeting this month, we have to have y results ready for the
one in June, we have to have z results for the one in September and
after they have made decisions in September we have to have the new
rates and business logic changes tested and ready for implementation
by the first weekend in November.
And trust me, you do _not_ want to explain to the Board of Directors
of a Fortune 100 financial services company why the information that
they need in order to make decisions is not available for the meeting
that has been on the calendar for over a year.
And there is plenty of "need to do stuff" that takes precedence over
"would be nice to do" stuff like analyzing wroking code in the hope of
making improvements.
|
|
|
|
| Re: Epson printing problems? [message #392986 is a reply to message #392983] |
Fri, 10 April 2020 21:56 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Dan Espen <dan1espen@gmail.com> wrote:
>> J. Clarke <jclarke.873638@gmail.com> writes:
>>
>>> On Fri, 10 Apr 2020 17:04:59 -0400, Dan Espen <dan1espen@gmail.com>
>>> wrote:
>>>
>>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>>
>>>> > On 10/04/2020 19:42, Scott Lurndal wrote:
>>>> >> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>> On 10/04/2020 17:11, Scott Lurndal wrote:
>>>> >>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>>>> On 09/04/2020 21:55, Dan Espen wrote:
>>>> >>>>
>>>> >>>>> As to multicharacter markers in text files, do you
>>>> >>>>> object to the \n end of line convention in the C language
>>>> >>>>> because that takes two characters! :-)
>>>> >>>>>
>>>> >>>>
>>>> >>>> You do, of course, realize that '\n' translates into a single
>>>> >>>> byte, right?
>>>> >>>>
>>>> >>>> The fact that you need two characters to represent LF in source
>>>> >>>> is irrelevent. Note that you need four for CRLF (\r\n).
>>>> >>>>
>>>> >>>
>>>> >>> Dan was discussing space taken up by text files, of which
>>>> >>> source files are an example.
>>>> >>>
>>>> >>
>>>> >> A C source file of 4000 lines might have one or two escaped characters
>>>> >> in it (or fewer, or more, but it's irrelevent to using CRLF as a
>>>> >> line delimiter). One or two extra backslash instead of 4000 useless carriage returns.
>>>> >>
>>>> >
>>>> > 4000 lines ???? That's 50 pages and a file of that size could
>>>> > only have been produced by a computing incompetentismo.
>>>>
>>>> Well, I guess we are talking about C, but 4000 lines for COBOL
>>>> is very common.
>>>>
>>>> With C, I've seen a few that size. Big complicated applications require
>>>> that. I've seen attempts to break big applications into dozens of
>>>> called modules. You end up with a nest where you can't find anything.
>>>> (Even with the help of TAGS.)
>>>>
>>>> A few decades back I got temporary ownership of a huge C module.
>>>> Even though the code was all in one module, it was still hard to find
>>>> your way through the code.
>>>>
>>>> So, I looked for ways to use separate called modules and there was
>>>> plenty of called modules, but so much shared stuff that the module
>>>> resisted my efforts.
>>>>
>>>> So, I took a few hours and renamed all the called subroutines using
>>>> COBOL rules. It looked pretty weird, C code like this:
>>>>
>>>> int b100_findstuff(int num, char* dta) {
>>>> x100_getzip();
>>>> }
>>>>
>>>> I then went through the prefixes (like b100,x100) and made them reflect
>>>> the calling hierarchy.
>>>> Then I moved all the code into alphanumeric order.
>>>>
>>>> Then I fixed the reason I was in the code in the first place.
>>>>
>>>> The other developers with years of C said they loved it.
>>>
>>> That's a good idea. I have a ton of APL that is difficult to wade
>>> through with which I might try that.
>>
>> I didn't know APL had subroutines, isn't APL supposed to be one line
>> long?
>>
>> Joking aside, it really helped me and everyone that came after me
>> and it's a sort of mindless process. Sure you have to test but
>> renaming and rearranging shouldn't cause a lot of problems.
>
> It can with COBOL. Somewhere it says perform a thru c and somewhere else
> it’s perform b thru d (assuming paragraphs are in alphabetical order in the
> source. Moving them around will cause a mess. Sure it’s terrible code, but
> I’ve seen worse.
Yeah, I was just thinking of PERFORM THRU but I didn't bring it up.
Of course, that should not occur.
The rule I adopted is that only SECTIONS should be PERFORMed.
The rare use of perform a thru b can usually become 2 performs.
--
Dan Espen
|
|
|
|
| Re: Epson printing problems? [message #392987 is a reply to message #392978] |
Fri, 10 April 2020 21:57 |
|
|
Originally posted by: J. Clarke
On Fri, 10 Apr 2020 21:03:02 -0400, Dan Espen <dan1espen@gmail.com>
wrote:
> J. Clarke <jclarke.873638@gmail.com> writes:
>
>> On Fri, 10 Apr 2020 17:04:59 -0400, Dan Espen <dan1espen@gmail.com>
>> wrote:
>>
>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>
>>>> On 10/04/2020 19:42, Scott Lurndal wrote:
>>>> > Gareth Evans <headstone255@yahoo.com> writes:
>>>> >> On 10/04/2020 17:11, Scott Lurndal wrote:
>>>> >>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>>> On 09/04/2020 21:55, Dan Espen wrote:
>>>> >>>
>>>> >>>> As to multicharacter markers in text files, do you
>>>> >>>> object to the \n end of line convention in the C language
>>>> >>>> because that takes two characters! :-)
>>>> >>>>
>>>> >>>
>>>> >>> You do, of course, realize that '\n' translates into a single
>>>> >>> byte, right?
>>>> >>>
>>>> >>> The fact that you need two characters to represent LF in source
>>>> >>> is irrelevent. Note that you need four for CRLF (\r\n).
>>>> >>>
>>>> >>
>>>> >> Dan was discussing space taken up by text files, of which
>>>> >> source files are an example.
>>>> >>
>>>> >
>>>> > A C source file of 4000 lines might have one or two escaped characters
>>>> > in it (or fewer, or more, but it's irrelevent to using CRLF as a
>>>> > line delimiter). One or two extra backslash instead of 4000 useless carriage returns.
>>>> >
>>>>
>>>> 4000 lines ???? That's 50 pages and a file of that size could
>>>> only have been produced by a computing incompetentismo.
>>>
>>> Well, I guess we are talking about C, but 4000 lines for COBOL
>>> is very common.
>>>
>>> With C, I've seen a few that size. Big complicated applications require
>>> that. I've seen attempts to break big applications into dozens of
>>> called modules. You end up with a nest where you can't find anything.
>>> (Even with the help of TAGS.)
>>>
>>> A few decades back I got temporary ownership of a huge C module.
>>> Even though the code was all in one module, it was still hard to find
>>> your way through the code.
>>>
>>> So, I looked for ways to use separate called modules and there was
>>> plenty of called modules, but so much shared stuff that the module
>>> resisted my efforts.
>>>
>>> So, I took a few hours and renamed all the called subroutines using
>>> COBOL rules. It looked pretty weird, C code like this:
>>>
>>> int b100_findstuff(int num, char* dta) {
>>> x100_getzip();
>>> }
>>>
>>> I then went through the prefixes (like b100,x100) and made them reflect
>>> the calling hierarchy.
>>> Then I moved all the code into alphanumeric order.
>>>
>>> Then I fixed the reason I was in the code in the first place.
>>>
>>> The other developers with years of C said they loved it.
>>
>> That's a good idea. I have a ton of APL that is difficult to wade
>> through with which I might try that.
>
> I didn't know APL had subroutines, isn't APL supposed to be one line
> long?
It has global variables (it doesn't have to, but the code was written
by actuaries whose programming was self taught)--I might try it with
those as well. It would be nice to know that x100_Z was changed in
x100_Foo, instead of wondering which of the numerous functions and
subroutines containing the variable "Z" is the one that changed it.
> Joking aside, it really helped me and everyone that came after me
> and it's a sort of mindless process. Sure you have to test but
> renaming and rearranging shouldn't cause a lot of problems.
|
|
|
|
| Re: Epson printing problems? [message #392988 is a reply to message #392982] |
Fri, 10 April 2020 22:07 |
|
|
Originally posted by: J. Clarke
On Fri, 10 Apr 2020 18:34:02 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:
> <robin.vowels@gmail.com> wrote:
>> On Saturday, April 11, 2020 at 5:35:51 AM UTC+10, Charlie Gibbs wrote:
>>> On 2020-04-10, <r......@gmail.com> wrote:
>>>
>>>> On Friday, April 10, 2020 at 3:30:00 AM UTC+10, Scott Lurndal wrote:
>>>>
>>>> > Gareth Evans <h......@yahoo.com> writes:
>>>> >
>>>> >> On 09/04/2020 15:35, Dan Espen wrote:
>>>> >>
>>>> >>> So, DOS had 2 characters to end each line.
>>>> >>> Completely ridiculous.
>>>> >>
>>>> >> If it was CR & LF, then they were control
>>>> >> characters for the Teletypes that were extant
>>>> >> for many years.
>>>> >
>>>> > Indeed, but only one of the two characters are necessary
>>>> > to terminate a line;
>>>>
>>>> True, for keyboard input.
>>>>
>>>> > both just waste space.
>>>>
>>>> And how do you suppose a file sent to a printer such
>>>> as as a Teletype or one of the many different kinds of
>>>> serial printers will print unless it has CR and LF in it?
>>>
>>> A properly-written driver can take care of that,
>>
>> You have side-stepped the question.
>> Exactly how is the "driver" going to take care of that?
>> It doesn't know where the ends of lines are? [without
>> CRLF)
>
> I see this was answered above - only one character needed, two are
> redundant. Also, there are other ways to define line length besides using a
> terminating character.
There are but those solutions aren't necessarily an improvement.
Fixed record length you end up with a bunch of wasted space if you are
dealing with variable length data. Any scheme that stores the line
length means that you have to store the line length, which takes up at
least as much space as the terminating character, and if you
anticipate lines longer than 256 characters then you have to have two
bytes for the line length, unless you go for some kind of packing and
indexing scheme and then you have pointers which add even more
overhead.
|
|
|
|
| Re: Epson printing problems? [message #393234 is a reply to message #392968] |
Sat, 11 April 2020 04:26 |
|
|
Originally posted by: maus
On 2020-04-11, J Clarke <jclarke.873638@gmail.com> wrote:
> On Fri, 10 Apr 2020 14:56:32 -0700, Peter Flass
> <peter_flass@yahoo.com> wrote:
>
>> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>>> On Fri, 2020-04-10, Dave Garland wrote:
>>> ...
>>>> IMHO, the LF/CR/CRLF thing is a bogus issue, and mostly always was. It
>>>> was an arbitrary standard. Yes, CRLF used one character per line more.
>>>> Maybe if you only had 8K RAM that was an issue. But it wasn't an issue
>>>> for CP/M-80 with 64K memory, and it's unlikely it ever unduly
>>>> constrained DOS. And today, who cares? A .docx file with a single line
>>>> of text is 4217 bytes, nobody will notice if it grows to 4218 bytes.
>>>
>>> Bogus in terms of file size, yes, but it still, in 2020, steals
>>> time for me and the rest of the team.
>>
>> When you’re storing files on 360K floppies, a few hundred bytes per file
>> adds up quickly.
>
> A hundred nine year old diskettes go for 85 bucks on Amazon. A 2
> terabyte USB hard drive goes for 65 bucks at Best Buy. Why does
> anybody today store large amounts of data on 360 floppies?
>
>
>
>
Not 360 floppies, but old ones, when you return from hospital, and
discover that your backup USB's were dumped by mistake.
|
|
|
|
| Re: Epson printing problems? [message #393238 is a reply to message #392982] |
Sat, 11 April 2020 06:21 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, April 11, 2020 at 11:34:04 AM UTC+10, Peter Flass wrote:
> <r......@gmail.com> wrote:
>> On Saturday, April 11, 2020 at 5:35:51 AM UTC+10, Charlie Gibbs wrote:
>>> On 2020-04-10, <r......@gmail.com> wrote:
>>>
>>>> On Friday, April 10, 2020 at 3:30:00 AM UTC+10, Scott Lurndal wrote:
>>>>
>>>> > Gareth Evans <h......@yahoo.com> writes:
>>>> >
>>>> >> On 09/04/2020 15:35, Dan Espen wrote:
>>>> >>
>>>> >>> So, DOS had 2 characters to end each line.
>>>> >>> Completely ridiculous.
>>>> >>
>>>> >> If it was CR & LF, then they were control
>>>> >> characters for the Teletypes that were extant
>>>> >> for many years.
>>>> >
>>>> > Indeed, but only one of the two characters are necessary
>>>> > to terminate a line;
>>>>
>>>> True, for keyboard input.
>>>>
>>>> > both just waste space.
>>>>
>>>> And how do you suppose a file sent to a printer such
>>>> as as a Teletype or one of the many different kinds of
>>>> serial printers will print unless it has CR and LF in it?
>>>
>>> A properly-written driver can take care of that,
>>
>> You have side-stepped the question.
>> Exactly how is the "driver" going to take care of that?
>> It doesn't know where the ends of lines are? [without
>> CRLF)
>
> I see this was answered above - only one character needed, two are
> redundant.
Two are needed as I explained before.
CR not followed immediately by LF permits the carriage to stay
on the same line so that characters can be underlined, or over-typed
for emphasis, etc.
> Also, there are other ways to define line length besides using a
> terminating character.
Line length is irrelevant, since multiple LFs can be given in the
one "line" to achieve certain formatting effects without the need
to return the carriage to the LH margin.
|
|
|
|
| Re: Epson printing problems? [message #393239 is a reply to message #392984] |
Sat, 11 April 2020 06:25 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, April 11, 2020 at 11:34:05 AM UTC+10, Peter Flass wrote:
> <r......@gmail.com> wrote:
>> On Saturday, April 11, 2020 at 10:26:23 AM UTC+10, J. Clarke wrote:
>>> On Fri, 10 Apr 2020 14:56:29 -0700, Peter Flass
>>> <p......@yahoo.com> wrote:
>>>
>>>> <r......@gmail.com> wrote:
>>>> > On Friday, April 10, 2020 at 8:55:26 AM UTC+10, John Floren wrote:
>>>> >> Dan Espen <d......@gmail.com> writes:
>>>> >>
>>>> >>> Gareth Evans <h......@yahoo.com> writes:
>>>> >>>
>>>> >>>> On 09/04/2020 15:35, Dan Espen wrote:
>>>> >>>>>
>>>> >>>>> So, DOS had 2 characters to end each line.
>>>> >>>>> Completely ridiculous.
>>>> >>>>
>>>> >>>> If it was CR & LF, then they were control
>>>> >>>> characters for the Teletypes that were extant
>>>> >>>> for many years.
>>>> >>>
>>>> >>> And as I said, that's a completely ridiculous reason to use
>>>> >>> CR/LF as a line ending in files.
>>>> >>>
>>>> >>> Some of those Teletypes you had to send nulls after the CR/LF
>>>> >>> to give the printer time to restore the carriage before you could send
>>>> >>> more data.
>>>> >>
>>>> >> How many DOS machines were ever connected to Teletypes, anyway?
>>>> >
>>>> > Probably most.
>>>> >
>>>> > Are you aware that the serial keyboard/printer attached to a DOS machine
>>>> > could be used as a terminal? The keyboard of the DOS machine
>>>> > could be reassigned to the keyboard/printer, thereby obtaining
>>>> > not only what was typed at the keyboard, but the interleaved
>>>> > responses from DOS.
>>>> >
>>>> >> It's
>>>> >> before my time, but I'd assume that graphical terminals were pretty
>>>> >> common by the time they wrote MS-DOS.
>>>> >
>>>> > Sure, but graphical terminals were fairly expensive, whereas
>>>> > teleprinters could be obtained for a few dollars.
>>>>
>>>> Only a while after graphical terminals go cheap. A real Teletype was a
>>>> pretty expensive piece of gear.
>>>
>>> A real _new_ Teletype was. An old one could be had fairly cheap in
>>> 1974 or thereabouts. I remember my girlfriend at the time had just
>>> dumped her husband because he spent the rent money on a teletype.
>>
>> Glass teletypes were certainly around by 1969. and possibly by 1966.
> I think they were fairly expensive initially. Later, of course, prices
> dropped.
No more expensive than a TV set, and much less noisy.
|
|
|
|
| Re: Epson printing problems? [message #393240 is a reply to message #392939] |
Sat, 11 April 2020 06:49 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Friday, April 10, 2020 at 8:56:14 PM UTC+10, Gareth Evans wrote:
> On 10/04/2020 05:51, r.......@gmail.com wrote:
>> For one, it was possible to edit a previous command,
>> something that MS-DOS never did, and you could not do until
>> in DOS under a much later Windows.
>
> I beg to differ. ISTR the use of F2 and F3 to repeat the
> previous command character by character.
You have forgotten that I still run DOS.
I just tried F2 and F3 on it, and they have no effect/
|
|
|
|
| Re: Epson printing problems? [message #393258 is a reply to message #392927] |
Fri, 10 April 2020 17:20 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 9 Apr 2020 19:00:28 -0700 (PDT)
robin.vowels@gmail.com wrote:
> On Thursday, April 9, 2020 at 9:02:10 PM UTC+10, Dan Espen wrote:
>> Hmm, MSDOS annoyed me from day 1.
>> What I wanted was a Unix flavor.
>> DOS fell short in so many ways.
>
> DR DOS was better.
Marginally, neither was more than a program loader and file
browser. The best MSDOS like thing from that era was DesqView.
> Unix was crummy. It had documented bugs,
> that were never going to be fixed.
Yet unix is still here today running most of the internet and
implementations of the unix kernel underpin the OS for almost every 'smart'
phone but pretty much nothing anywhere runs any variant of DOS.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: Epson printing problems? [message #393260 is a reply to message #393240] |
Sat, 11 April 2020 15:08 |
mjb
Messages: 32
Registered: April 2013
Karma: 0
|
Member |
|
|
In article <387976e4-2376-4106-b6dc-8ef491047b99@googlegroups.com>,
<robin.vowels@gmail.com> wrote:
> On Friday, April 10, 2020 at 8:56:14 PM UTC+10, Gareth Evans wrote:
>> On 10/04/2020 05:51, r.......@gmail.com wrote:
>>> For one, it was possible to edit a previous command,
>>> something that MS-DOS never did, and you could not do until
>>> in DOS under a much later Windows.
>>
>> I beg to differ. ISTR the use of F2 and F3 to repeat the
>> previous command character by character.
>
> You have forgotten that I still run DOS.
> I just tried F2 and F3 on it, and they have no effect/
I thought it was F1 and F3, but it's a long time ago. It was
a primitive way to recall the last command and (maybe) edit
in some new characters, to save retyping.
Google "MSDOS Command editing f1 f2 f3", plenty of references
to it. It was a thing!
--
--------------------------------------+--------------------- ---------------
Mike Brown: mjb[-at-]signal11.org.uk | http://www.signal11.org.uk
|
|
|
|
| Re: Epson printing problems? [message #393261 is a reply to message #392786] |
Sat, 11 April 2020 15:27 |
Jorgen Grahn
Messages: 606
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Sat, 2020-04-11, Dave Garland wrote:
> On 4/10/2020 12:35 AM, Jorgen Grahn wrote:
>> On Fri, 2020-04-10, Dave Garland wrote:
>> ...
>>> IMHO, the LF/CR/CRLF thing is a bogus issue, and mostly always was. It
>>> was an arbitrary standard. Yes, CRLF used one character per line more.
>>> Maybe if you only had 8K RAM that was an issue. But it wasn't an issue
>>> for CP/M-80 with 64K memory, and it's unlikely it ever unduly
>>> constrained DOS. And today, who cares? A .docx file with a single line
>>> of text is 4217 bytes, nobody will notice if it grows to 4218 bytes.
>>
>> Bogus in terms of file size, yes, but it still, in 2020, steals
>> time for me and the rest of the team.
>
> Do you and your team seriously spend a lot of time dealing with CR-LF?
Yes.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
|
|
|
|
| Re: Epson printing problems? [message #393262 is a reply to message #393261] |
Sat, 11 April 2020 16:09 |
Mike Spencer
Messages: 997
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Sat, 2020-04-11, Dave Garland wrote:
>> Do you and your team seriously spend a lot of time dealing with CR-LF?
>
> Yes.
Not recently. But back circa 1992, my wife had an account on a VMS
system. No WWW but there were places to get useful docs, compressed
archives & executables. I spent a lot of time unwinding/tweaking
files which, AFAICT, VMS broke by replacing LF with CRLF.
Some little time later, working at home with MS-DOS and learning Perl,
my first bit of cleverness (well, *I* thought it was clever for a Perl
novice :-) was to determine that Jeffrey Friedl's nice little script to
designate one color as transparent in a GIF image failed because,
under MS-DOS, stdin & stdout did automatic CRLF <-> LF translations.
Adding binmode commands in the right places fixed it.
--
Mike Spencer Nova Scotia, Canada
|
|
|
|
| Re: Epson printing problems? [message #393265 is a reply to message #392985] |
Sat, 11 April 2020 20:53 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> wrote:
> On Fri, 10 Apr 2020 20:58:41 -0400, Dan Espen <dan1espen@gmail.com>
> wrote:
>
>> J. Clarke <jclarke.873638@gmail.com> writes:
>>
>>> On Fri, 10 Apr 2020 17:13:25 -0400, Dan Espen <dan1espen@gmail.com>
>>> wrote:
>>>
>>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>>>
>>>> > On 2020-04-10, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>> >
>>>> >> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>
>>>> >>> On 10/04/2020 19:42, Scott Lurndal wrote:
>>>> >>>
>>>> >>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>>>
>>>> >>>>> On 10/04/2020 17:11, Scott Lurndal wrote:
>>>> >>>>>
>>>> >>>>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>>>>>
>>>> >>>>>>> On 09/04/2020 21:55, Dan Espen wrote:
>>>> >>>>>>>
>>>> >>>>>>> As to multicharacter markers in text files, do you
>>>> >>>>>>> object to the \n end of line convention in the C language
>>>> >>>>>>> because that takes two characters! :-)
>>>> >>>>>>
>>>> >>>>>> You do, of course, realize that '\n' translates into a single
>>>> >>>>>> byte, right?
>>>> >>>>>>
>>>> >>>>>> The fact that you need two characters to represent LF in source
>>>> >>>>>> is irrelevent. Note that you need four for CRLF (\r\n).
>>>> >>>>>
>>>> >>>>> Dan was discussing space taken up by text files, of which
>>>> >>>>> source files are an example.
>>>> >>>>
>>>> >>>> A C source file of 4000 lines might have one or two escaped characters
>>>> >>>> in it (or fewer, or more, but it's irrelevent to using CRLF as a
>>>> >>>> line delimiter). One or two extra backslash instead of 4000 useless
>>>> >>>> carriage returns.
>>>> >>>
>>>> >>> 4000 lines ???? That's 50 pages and a file of that size could
>>>> >>> only have been produced by a computing incompetentismo.
>>>> >>
>>>> >> Evasion noted.
>>>> >>
>>>> >> We have well over two millions lines of C/C++ code, and several files are
>>>> >> in the 2 to 4 thousand line range, even without counting header files that
>>>> >> are generated. And there is no "computing incompetentismo" involved.
>>>> >
>>>> > A couple of my source files have grown to over 10,000 lines.
>>>> > Not by design, but changing requirements, plus a compiler that
>>>> > can handle it. A single source file makes the makefile smaller.
>>>> >
>>>> > Small modules are a sign of a short attention span. :-)
>>>>
>>>> 10K is way out there, I've seen that size with COBOL but it wasn't pleasant.
>>>> If there is any pattern to that 10K of source code perhaps a code
>>>> generator can condense some of it.
>>>>
>>>> I've taken good line counts out of Assembler and C buy writing macros.
>>>
>>> The trouble is that you have to find the time to analyze it and make
>>> the changes and test them.
>>
>> How is that trouble?
>>
>> Isn't improving the code part of your job description?
>
> Nope.
>
>> Anyway, I'm pretty sure how you'll answer.
>> I know if you ask your boss, he'll always ask for quick and dirty.
>> But cleaning up code is it's own reward.
>
> She doesn't care how I do my job. But she does care that I get
> everything that she's told me to do done soon enough that it doesn't
> keep someone else from meeting their deadlines. And our deadlines are
> hard deadlines--we have to have x results available for the board of
> directors meeting this month, we have to have y results ready for the
> one in June, we have to have z results for the one in September and
> after they have made decisions in September we have to have the new
> rates and business logic changes tested and ready for implementation
> by the first weekend in November.
>
> And trust me, you do _not_ want to explain to the Board of Directors
> of a Fortune 100 financial services company why the information that
> they need in order to make decisions is not available for the meeting
> that has been on the calendar for over a year.
>
> And there is plenty of "need to do stuff" that takes precedence over
> "would be nice to do" stuff like analyzing wroking code in the hope of
> making improvements.
>
If there’s some code that you know you’re going have to modify often (more
than once) it’s probably better to grab some time to do some cleanup when
you’re in there. You don’t have to do it all at once, butbeach chane you
make means the next one will go more quickly.
--
Pete
|
|
|
|
| Re: Epson printing problems? [message #393266 is a reply to message #393234] |
Sat, 11 April 2020 20:53 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
maus <maus@dmaus.org> wrote:
> On 2020-04-11, J Clarke <jclarke.873638@gmail.com> wrote:
>> On Fri, 10 Apr 2020 14:56:32 -0700, Peter Flass
>> <peter_flass@yahoo.com> wrote:
>>
>>> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>>>> On Fri, 2020-04-10, Dave Garland wrote:
>>>> ...
>>>> > IMHO, the LF/CR/CRLF thing is a bogus issue, and mostly always was. It
>>>> > was an arbitrary standard. Yes, CRLF used one character per line more.
>>>> > Maybe if you only had 8K RAM that was an issue. But it wasn't an issue
>>>> > for CP/M-80 with 64K memory, and it's unlikely it ever unduly
>>>> > constrained DOS. And today, who cares? A .docx file with a single line
>>>> > of text is 4217 bytes, nobody will notice if it grows to 4218 bytes.
>>>>
>>>> Bogus in terms of file size, yes, but it still, in 2020, steals
>>>> time for me and the rest of the team.
>>>
>>> When you’re storing files on 360K floppies, a few hundred bytes per file
>>> adds up quickly.
>>
>> A hundred nine year old diskettes go for 85 bucks on Amazon. A 2
>> terabyte USB hard drive goes for 65 bucks at Best Buy. Why does
>> anybody today store large amounts of data on 360 floppies?
>>
>>
>>
>>
>
> Not 360 floppies, but old ones, when you return from hospital, and
> discover that your backup USB's were dumped by mistake.
>
Ouch!
--
Pete
|
|
|
|
| Re: Epson printing problems? [message #393267 is a reply to message #393265] |
Sat, 11 April 2020 21:07 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> J. Clarke <jclarke.873638@gmail.com> wrote:
>> On Fri, 10 Apr 2020 20:58:41 -0400, Dan Espen <dan1espen@gmail.com>
>> wrote:
>>
>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>
>>>> On Fri, 10 Apr 2020 17:13:25 -0400, Dan Espen <dan1espen@gmail.com>
>>>> wrote:
>>>>
>>>> > Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>>> >
>>>> >> On 2020-04-10, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>> >>
>>>> >>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>>
>>>> >>>> On 10/04/2020 19:42, Scott Lurndal wrote:
>>>> >>>>
>>>> >>>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>>>>
>>>> >>>>>> On 10/04/2020 17:11, Scott Lurndal wrote:
>>>> >>>>>>
>>>> >>>>>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>>>>>>
>>>> >>>>>>>> On 09/04/2020 21:55, Dan Espen wrote:
>>>> >>>>>>>>
>>>> >>>>>>>> As to multicharacter markers in text files, do you
>>>> >>>>>>>> object to the \n end of line convention in the C language
>>>> >>>>>>>> because that takes two characters! :-)
>>>> >>>>>>>
>>>> >>>>>>> You do, of course, realize that '\n' translates into a single
>>>> >>>>>>> byte, right?
>>>> >>>>>>>
>>>> >>>>>>> The fact that you need two characters to represent LF in source
>>>> >>>>>>> is irrelevent. Note that you need four for CRLF (\r\n).
>>>> >>>>>>
>>>> >>>>>> Dan was discussing space taken up by text files, of which
>>>> >>>>>> source files are an example.
>>>> >>>>>
>>>> >>>>> A C source file of 4000 lines might have one or two escaped characters
>>>> >>>>> in it (or fewer, or more, but it's irrelevent to using CRLF as a
>>>> >>>>> line delimiter). One or two extra backslash instead of 4000 useless
>>>> >>>>> carriage returns.
>>>> >>>>
>>>> >>>> 4000 lines ???? That's 50 pages and a file of that size could
>>>> >>>> only have been produced by a computing incompetentismo.
>>>> >>>
>>>> >>> Evasion noted.
>>>> >>>
>>>> >>> We have well over two millions lines of C/C++ code, and several files are
>>>> >>> in the 2 to 4 thousand line range, even without counting header files that
>>>> >>> are generated. And there is no "computing incompetentismo" involved.
>>>> >>
>>>> >> A couple of my source files have grown to over 10,000 lines.
>>>> >> Not by design, but changing requirements, plus a compiler that
>>>> >> can handle it. A single source file makes the makefile smaller.
>>>> >>
>>>> >> Small modules are a sign of a short attention span. :-)
>>>> >
>>>> > 10K is way out there, I've seen that size with COBOL but it wasn't pleasant.
>>>> > If there is any pattern to that 10K of source code perhaps a code
>>>> > generator can condense some of it.
>>>> >
>>>> > I've taken good line counts out of Assembler and C buy writing macros.
>>>>
>>>> The trouble is that you have to find the time to analyze it and make
>>>> the changes and test them.
>>>
>>> How is that trouble?
>>>
>>> Isn't improving the code part of your job description?
>>
>> Nope.
>>
>>> Anyway, I'm pretty sure how you'll answer.
>>> I know if you ask your boss, he'll always ask for quick and dirty.
>>> But cleaning up code is it's own reward.
>>
>> She doesn't care how I do my job. But she does care that I get
>> everything that she's told me to do done soon enough that it doesn't
>> keep someone else from meeting their deadlines. And our deadlines are
>> hard deadlines--we have to have x results available for the board of
>> directors meeting this month, we have to have y results ready for the
>> one in June, we have to have z results for the one in September and
>> after they have made decisions in September we have to have the new
>> rates and business logic changes tested and ready for implementation
>> by the first weekend in November.
>>
>> And trust me, you do _not_ want to explain to the Board of Directors
>> of a Fortune 100 financial services company why the information that
>> they need in order to make decisions is not available for the meeting
>> that has been on the calendar for over a year.
>>
>> And there is plenty of "need to do stuff" that takes precedence over
>> "would be nice to do" stuff like analyzing wroking code in the hope of
>> making improvements.
>
> If there’s some code that you know you’re going have to modify often (more
> than once) it’s probably better to grab some time to do some cleanup when
> you’re in there. You don’t have to do it all at once, butbeach chane you
> make means the next one will go more quickly.
That's the philosophy I always followed and it worked well.
Some of my bosses realized what was going on.
One remarked that invariably when I had to fix something, there were
less lines in the module after the fix.
(He would get line count reports.)
--
Dan Espen
|
|
|
|
| Re: Epson printing problems? [message #393268 is a reply to message #393265] |
Sat, 11 April 2020 21:17 |
|
|
Originally posted by: J. Clarke
On Sat, 11 Apr 2020 17:53:26 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:
> J. Clarke <jclarke.873638@gmail.com> wrote:
>> On Fri, 10 Apr 2020 20:58:41 -0400, Dan Espen <dan1espen@gmail.com>
>> wrote:
>>
>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>
>>>> On Fri, 10 Apr 2020 17:13:25 -0400, Dan Espen <dan1espen@gmail.com>
>>>> wrote:
>>>>
>>>> > Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>>> >
>>>> >> On 2020-04-10, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>> >>
>>>> >>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>>
>>>> >>>> On 10/04/2020 19:42, Scott Lurndal wrote:
>>>> >>>>
>>>> >>>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>>>>
>>>> >>>>>> On 10/04/2020 17:11, Scott Lurndal wrote:
>>>> >>>>>>
>>>> >>>>>>> Gareth Evans <headstone255@yahoo.com> writes:
>>>> >>>>>>>
>>>> >>>>>>>> On 09/04/2020 21:55, Dan Espen wrote:
>>>> >>>>>>>>
>>>> >>>>>>>> As to multicharacter markers in text files, do you
>>>> >>>>>>>> object to the \n end of line convention in the C language
>>>> >>>>>>>> because that takes two characters! :-)
>>>> >>>>>>>
>>>> >>>>>>> You do, of course, realize that '\n' translates into a single
>>>> >>>>>>> byte, right?
>>>> >>>>>>>
>>>> >>>>>>> The fact that you need two characters to represent LF in source
>>>> >>>>>>> is irrelevent. Note that you need four for CRLF (\r\n).
>>>> >>>>>>
>>>> >>>>>> Dan was discussing space taken up by text files, of which
>>>> >>>>>> source files are an example.
>>>> >>>>>
>>>> >>>>> A C source file of 4000 lines might have one or two escaped characters
>>>> >>>>> in it (or fewer, or more, but it's irrelevent to using CRLF as a
>>>> >>>>> line delimiter). One or two extra backslash instead of 4000 useless
>>>> >>>>> carriage returns.
>>>> >>>>
>>>> >>>> 4000 lines ???? That's 50 pages and a file of that size could
>>>> >>>> only have been produced by a computing incompetentismo.
>>>> >>>
>>>> >>> Evasion noted.
>>>> >>>
>>>> >>> We have well over two millions lines of C/C++ code, and several files are
>>>> >>> in the 2 to 4 thousand line range, even without counting header files that
>>>> >>> are generated. And there is no "computing incompetentismo" involved.
>>>> >>
>>>> >> A couple of my source files have grown to over 10,000 lines.
>>>> >> Not by design, but changing requirements, plus a compiler that
>>>> >> can handle it. A single source file makes the makefile smaller.
>>>> >>
>>>> >> Small modules are a sign of a short attention span. :-)
>>>> >
>>>> > 10K is way out there, I've seen that size with COBOL but it wasn't pleasant.
>>>> > If there is any pattern to that 10K of source code perhaps a code
>>>> > generator can condense some of it.
>>>> >
>>>> > I've taken good line counts out of Assembler and C buy writing macros.
>>>>
>>>> The trouble is that you have to find the time to analyze it and make
>>>> the changes and test them.
>>>
>>> How is that trouble?
>>>
>>> Isn't improving the code part of your job description?
>>
>> Nope.
>>
>>> Anyway, I'm pretty sure how you'll answer.
>>> I know if you ask your boss, he'll always ask for quick and dirty.
>>> But cleaning up code is it's own reward.
>>
>> She doesn't care how I do my job. But she does care that I get
>> everything that she's told me to do done soon enough that it doesn't
>> keep someone else from meeting their deadlines. And our deadlines are
>> hard deadlines--we have to have x results available for the board of
>> directors meeting this month, we have to have y results ready for the
>> one in June, we have to have z results for the one in September and
>> after they have made decisions in September we have to have the new
>> rates and business logic changes tested and ready for implementation
>> by the first weekend in November.
>>
>> And trust me, you do _not_ want to explain to the Board of Directors
>> of a Fortune 100 financial services company why the information that
>> they need in order to make decisions is not available for the meeting
>> that has been on the calendar for over a year.
>>
>> And there is plenty of "need to do stuff" that takes precedence over
>> "would be nice to do" stuff like analyzing wroking code in the hope of
>> making improvements.
>>
>
> If there’s some code that you know you’re going have to modify often (more
> than once) it’s probably better to grab some time to do some cleanup when
> you’re in there. You don’t have to do it all at once, butbeach chane you
> make means the next one will go more quickly.
The thing is we don't have any way of knowing in advance what we are
going to have to modify. If the politicians decide to change the tax
code it can involve changes in the code that nobody ever imagined
would be related to taxes. If they change the regulations the same.
There are some changes that we do make every year and we are working
on making them more efficient. In an ideal world they would be table
driven but we have no way of compelling the use of the right tables
without hard-coding them.
|
|
|
|
| Re: Epson printing problems? [message #393270 is a reply to message #392973] |
Sat, 11 April 2020 17:00 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Fri, 10 Apr 2020 17:54:39 -0700 (PDT)
robin.vowels@gmail.com wrote:
> How so? If there's a file on disc that is to be printed to
> a serial printer (e.g., a Teletype), how do you suppose that
> the relevant CR and LF can be given at the appropriate moment?
Works fine on unix systems - see man stty for details also of nul
insertion and other device driving gymnastics. Hint: somebody (sysadmin)
configures the driver on each port to suit the requirements of the device
connected to it.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
|
|
|
|
| Re: Epson printing problems? [message #393470 is a reply to message #393468] |
Tue, 14 April 2020 15:35 |
lawrence
Messages: 105
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
Thomas Koenig <tkoenig@netcologne.de> writes:
> J Clarke <jclarke.873638@gmail.com> schrieb:
>> I remember my girlfriend at the time had just
>> dumped her husband because he spent the rent money on a teletype.
>
> So she told me it was either her or the ham radio. Over.
One of the *first* things I did when I got into a "serious relationship"
was to Elmer my mate.
That trick I learned from my friend WB6NIL [SK] whose father pressured
his XYL (W6MBC) to get her ticket before he got his (W6MLW).
It's always easier to find room in the budget for a new radio when your
spouse wants it as much as you do.
--XE2/NK1G (formerly N1GAK)
|
|
|
|
Members
Search
Help
Register
Login
Home
