Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #126692 > unrolled thread
| Started by | G B <gb@gb.com> |
|---|---|
| First post | 2018-02-14 11:47 -0400 |
| Last post | 2018-02-25 20:12 +0000 |
| Articles | 20 on this page of 168 — 30 participants |
Back to article view | Back to comp.lang.c
Text Files G B <gb@gb.com> - 2018-02-14 11:47 -0400
Re: Text Files Ed Prochak <edprochak@gmail.com> - 2018-02-14 08:45 -0800
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-14 08:47 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-15 01:17 -0800
Re: Text Files gordonb.ea2mq@burditt.org (Gordon Burditt) - 2018-02-14 11:10 -0600
Re: Text Files "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-14 12:28 -0500
Re: Text Files jt@toerring.de (Jens Thoms Toerring) - 2018-02-14 21:07 +0000
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-14 15:31 -0700
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-15 06:59 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 10:20 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-14 22:51 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 11:04 +0100
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-15 06:16 -0800
Re: Text Files "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-15 22:22 +0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 15:58 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 16:31 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 21:31 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 21:21 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 22:17 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 23:36 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 23:48 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 10:09 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 12:57 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 15:50 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 15:50 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 17:07 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 20:44 +0000
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-17 11:22 +1300
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 17:48 +0000
Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-16 17:06 +0100
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-17 11:10 +1300
Re: Text Files supercat@casperkitty.com - 2018-02-16 14:48 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-16 15:14 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 23:25 +0000
Re: Text Files supercat@casperkitty.com - 2018-02-16 15:50 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-16 07:19 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 17:13 +0100
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-19 17:55 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-19 19:14 +0100
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-19 11:48 -0800
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 08:14 -0800
Re: Text Files Robert Wessel <robertwessel2@yahoo.com> - 2018-02-17 18:32 -0600
Re: Text Files jacobnavia <jacob@jacob.remcomp.fr> - 2018-02-15 22:57 +0100
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 22:58 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 00:19 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 02:26 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 02:57 +0000
Re: Text Files asetofsymbols@gmail.com - 2018-02-16 00:21 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 11:30 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 10:36 +0100
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 11:36 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 13:10 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 12:25 +0000
Re: Text Files Ike Naar <ike@iceland.freeshell.org> - 2018-03-06 19:33 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-03-06 20:55 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 04:42 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 16:58 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 20:02 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 21:43 +0100
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 04:01 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-17 13:10 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 05:27 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-17 14:20 +0000
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-16 09:04 -0700
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 14:31 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 06:42 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 14:58 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 07:23 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 15:24 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 04:13 -0800
Re: Text Files Siri Cruise <chine.bleu@yahoo.com> - 2018-02-16 04:29 -0800
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-20 16:41 +0000
Re: Text Files Siri Cruise <chine.bleu@yahoo.com> - 2018-02-20 09:39 -0800
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-20 19:16 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 12:46 +0000
Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-15 14:52 +0100
Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-15 17:07 +0300
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 14:23 +0000
Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-15 18:52 +0300
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 14:39 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 15:43 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 20:32 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 22:06 +0000
Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-15 23:12 +0100
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-15 15:12 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 23:43 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 23:54 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 23:35 +0000
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-16 17:07 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-17 02:38 +0000
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-17 17:26 +1300
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-17 11:22 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-17 12:07 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 04:17 -0800
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-17 16:25 +0300
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 07:35 -0800
Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-17 15:24 +0100
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-18 11:10 +1300
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-19 12:05 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-19 15:32 -0800
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 10:34 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-21 15:35 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-22 00:11 +0000
Re: Text Files Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 18:26 -0600
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 21:39 -0800
Re: Text Files Robert Wessel <robertwessel2@yahoo.com> - 2018-02-23 03:08 -0600
Re: Text Files supercat@casperkitty.com - 2018-02-23 16:16 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-23 16:46 -0800
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-24 02:49 -0800
Re: Text Files asetofsymbols@gmail.com - 2018-02-24 05:16 -0800
Re: Text Files "F. Russell" <fr@random.info> - 2018-02-24 14:35 +0000
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-24 08:48 -0700
Re: Text Files supercat@casperkitty.com - 2018-02-25 15:09 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-25 15:54 -0800
Re: Text Files supercat@casperkitty.com - 2018-02-26 11:04 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 11:52 -0800
Re: Text Files supercat@casperkitty.com - 2018-02-26 14:12 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 14:40 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-22 04:58 -0800
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-22 05:33 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-22 13:59 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-22 07:24 -0800
Re: Text Files supercat@casperkitty.com - 2018-02-20 12:14 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 21:37 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 21:34 +0000
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-15 14:15 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 10:47 +0100
Re: Text Files "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-15 22:20 +0800
Re: Text Files "F. Russell" <fr@random.info> - 2018-02-15 15:24 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 16:05 +0000
Re: Text Files "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-16 00:22 +0800
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-15 13:35 -0700
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 00:13 +0300
Re: Text Files bartc <bc@freeuk.com> - 2018-02-24 21:24 +0000
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 14:55 +0300
Re: Text Files bartc <bc@freeuk.com> - 2018-02-25 13:00 +0000
Re: Text Files Real Troll <Real.Troll@Trolls.com> - 2018-02-24 17:35 -0400
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-24 21:36 +0000
Re: Text Files Real Troll <Real.Troll@Trolls.com> - 2018-02-24 17:45 -0400
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-24 22:51 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-24 23:56 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-25 00:14 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-25 00:22 +0000
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 15:16 +0300
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-25 15:20 -0800
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-25 20:27 -0700
Re: Text Files gazelle@shell.xmission.com (Kenny McCormack) - 2018-02-26 06:19 +0000
Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-26 15:35 +0300
Re: Text Files Reinhardt Behm <rbehm@hushmail.com> - 2018-02-26 20:53 +0800
Grammar Patrol (Was: Text Files) gazelle@shell.xmission.com (Kenny McCormack) - 2018-02-26 17:54 +0000
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-26 15:27 +0000
Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-26 18:50 +0300
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 09:26 -0800
Re: Text Files scott@slp53.sl.home (Scott Lurndal) - 2018-02-26 19:46 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-27 09:04 +0100
Re: Text Files already5chosen@yahoo.com - 2018-02-27 00:56 -0800
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-27 22:07 +1300
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-27 14:37 +0100
Re: Text Files already5chosen@yahoo.com - 2018-02-27 07:38 -0800
Re: Text Files supercat@casperkitty.com - 2018-02-27 09:18 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-27 10:15 +0100
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-27 08:53 -0800
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-26 23:14 -0800
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-26 08:32 -0700
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 09:17 -0800
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-26 22:55 -0800
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 15:02 +0300
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-25 20:12 +0000
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-24 23:56 +0000 |
| Message-ID | <87y3jiuel4.fsf@bsb.me.uk> |
| In reply to | #127024 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Sat, 2018-02-24, Ben Bacarisse wrote:
>> Anton Shepelev <anton.txt@gmail.com> writes:
<snip>
>>> #include <stdio.h>
>>>
>>> typedef struct reader_t
>>> { int n;
>>> int sp;
>>> FILE* file;
>>> char* sbuf;
>>> unsigned char* nbuf;
>>> int size;
>>> } reader_t;
>>>
>>> const int DIGIT_N = 2;
>>>
>>> void initreader( reader_t * readerP, int n, int sp, char* path )
>>> { readerP->n = n;
>>> readerP->sp = sp;
>>> readerP->file = fopen( path, "r" );
>>> readerP->size = n * DIGIT_N + (n - 1) * sp + 2;
>>> readerP->sbuf = ( char* )malloc( readerP->size );
>>> readerP->nbuf = ( unsigned char* )malloc( readerP->n );
>>> }
>>>
>>> int readrow( reader_t * readerP )
>>> { int res, i;
>>> char* pos;
>>> if( fgets( readerP->sbuf, readerP->size, readerP->file ) == NULL )
>>> { res = 0; }
>>> else
>>> { pos = readerP->sbuf;
>>> for( i = 0; i < readerP->n; i++ )
>>> { readerP->nbuf[i] = atoi( pos );
>>> pos = pos + readerP->sp + DIGIT_N;
>>> }
>>> res = 1;
>>> }
>>> return res;
>>> }
>>>
>>> void deinitreader( reader_t * readerP )
>>> { free ( readerP->sbuf );
>>> free ( readerP->nbuf );
>>> fclose( readerP->file );
>>> }
>>>
>>> int main( int argc, char** argv )
>>> { const int NUMCOUNT = 6;
>>> int i;
>>> reader_t r;
>>>
>>> initreader( &r, NUMCOUNT, 4, "test.txt" );
>>> while( readrow( &r ) )
>>> { for( i = 0; i < NUMCOUNT; i++ )
>>> { printf("%3i ", r.nbuf[i] ); }
>>> printf("\n");
>>> }
>>> deinitreader( &r );
>>>
>>> return 0;
>>> }
>>
>> I've left the whole thing because I don't know what you cut. Are you
>> assuming that the OP is posting coursework and you are deliberately not
>> helping?
>
> Are you responding to the posting you think? He didn't cut anything,
Yes, that was the post I intended to reply to. Unfortunately I typed
"you" instead of "to" so the sentence made no sense (well, not true, it
did -- it made the wrong sense).
> as far as I can tell: he just responded to the original query, with an
> implementation which looks plausible.
I couldn't see the point of posting a complex implementation that
accepts such a narrowly defined format with almost no error checking.
The code has the undefined behaviour that can come from using atoi but
none of the simplicity of the other suggestions that have been made. It
will read incorrect data with the slightest perturbation in the input
without ever reporting any errors. It did not look serious to me.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-25 00:14 +0000 |
| Message-ID | <MdnkC.301854$sF7.124348@fx15.am4> |
| In reply to | #127026 |
On 24/02/2018 23:56, Ben Bacarisse wrote: > Jorgen Grahn <grahn+nntp@snipabacken.se> writes: >> as far as I can tell: he just responded to the original query, with an >> implementation which looks plausible. > > I couldn't see the point of posting a complex implementation that > accepts such a narrowly defined format with almost no error checking. > The code has the undefined behaviour that can come from using atoi but > none of the simplicity of the other suggestions that have been made. It > will read incorrect data with the slightest perturbation in the input > without ever reporting any errors. It did not look serious to me. You're right; while it will read the example data as given, it won't read the same data as output by the program and then read in again. That might have obviated the need for extensive error checking, if data was machine generated like this but including some degree of flexibility in format. But as it is, it's not so useful. (The version I posted [15.2.18] will read its output, with a 99999 upper limit due to output format but which is easily fixed.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-25 00:22 +0000 |
| Message-ID | <SknkC.175655$C73.174759@fx32.am4> |
| In reply to | #127027 |
On 25/02/2018 00:14, bartc wrote: > On 24/02/2018 23:56, Ben Bacarisse wrote: >> Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > >>> as far as I can tell: he just responded to the original query, with an >>> implementation which looks plausible. >> >> I couldn't see the point of posting a complex implementation that >> accepts such a narrowly defined format with almost no error checking. >> The code has the undefined behaviour that can come from using atoi but >> none of the simplicity of the other suggestions that have been made. It >> will read incorrect data with the slightest perturbation in the input >> without ever reporting any errors. It did not look serious to me. > > You're right; while it will read the example data as given, it won't > read the same data as output by the program and then read in again. > > That might have obviated the need for extensive error checking, if data > was machine generated like this but including some degree of flexibility > in format. But as it is, it's not so useful. > > (The version I posted [15.2.18] will read its output, with a 99999 upper > limit due to output format but which is easily fixed.) Actually that doesn't matter; a value of 123456 printed with %5d will show 123456 (not ***** like some other languages). The real limitation is the int32 range, but that is also easily changed to int64. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2018-02-25 15:16 +0300 |
| Message-ID | <20180225151636.c977d8207b1c3e9fe372c067@gmail.com> |
| In reply to | #127027 |
bartc to Ben Bacarisse: > > The code has the undefined behaviour that can > > come from using atoi but none of the simplicity > > of the other suggestions that have been made. > > It will read incorrect data with the slightest > > perturbation in the input without ever reporting > > any errors. It did not look serious to me. > > You're right; while it will read the example data > as given, it won't read the same data as output by > the program and then read in again. The flexibility that I wanted was the reading of tu- ples of user-supplied cardinality into arrays. I did assume the data was machine-generated and opti- mised for reading speed by means of fixed-width num- bers. This allowed me to jump from one number to the next instead of scanning through the intervening whitespace. My program prints what it reads merely as a demon- stration. I did not want to invoke some abstract processrow() function. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-02-25 15:20 -0800 |
| Message-ID | <ln8tbgk66s.fsf@kst-u.example.com> |
| In reply to | #127034 |
Anton Shepelev <anton.txt@gmail.com> writes:
[...]
> The flexibility that I wanted was the reading of tu-
> ples of user-supplied cardinality into arrays. I
> did assume the data was machine-generated and opti-
> mised for reading speed by means of fixed-width num-
> bers. This allowed me to jump from one number to
> the next instead of scanning through the intervening
> whitespace.
[...]
You seem to go to some effort to make all lines in your articles
have the same length. In my opinion, this hurts readability.
Words are split across lines unnecessarily, and double spaces are
arbitrarily inserted between some words. I suggest you don't bother.
I find this:
> The flexibility that I wanted was the reading of tuples of
> user-supplied cardinality into arrays. I did assume the data
> was machine-generated and optimised for reading speed by means
> of fixed-width numbers. This allowed me to jump from one number
> to the next instead of scanning through the intervening whitespace.
more readable.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2018-02-25 20:27 -0700 |
| Message-ID | <1bzi3wqvkm.fsf@pfeifferfamily.net> |
| In reply to | #127054 |
Keith Thompson <kst-u@mib.org> writes: > Anton Shepelev <anton.txt@gmail.com> writes: > [...] >> The flexibility that I wanted was the reading of tu- >> ples of user-supplied cardinality into arrays. I >> did assume the data was machine-generated and opti- >> mised for reading speed by means of fixed-width num- >> bers. This allowed me to jump from one number to >> the next instead of scanning through the intervening >> whitespace. > [...] > > You seem to go to some effort to make all lines in your articles > have the same length. In my opinion, this hurts readability. > Words are split across lines unnecessarily, and double spaces are > arbitrarily inserted between some words. I suggest you don't bother. > > I find this: > >> The flexibility that I wanted was the reading of tuples of >> user-supplied cardinality into arrays. I did assume the data >> was machine-generated and optimised for reading speed by means >> of fixed-width numbers. This allowed me to jump from one number >> to the next instead of scanning through the intervening whitespace. > > more readable. To me, it looks like his news client is doing it to him...
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2018-02-26 06:19 +0000 |
| Message-ID | <p708tq$tvc$1@news.xmission.com> |
| In reply to | #127054 |
In article <ln8tbgk66s.fsf@kst-u.example.com>, Keith Thompson <kst-u@mib.org> wrote: ... >You seem to go to some effort to make all lines in your articles have >the same length. In my opinion, this hurts readability. Words are split >across lines unnecessarily, and double spaces are arbitrarily inserted >between some words. I suggest you don't bother. > >I find this: > >> The flexibility that I wanted was the reading of tuples of >> user-supplied cardinality into arrays. I did assume the data was >> machine-generated and optimised for reading speed by means of >> fixed-width numbers. This allowed me to jump from one number to the >> next instead of scanning through the intervening whitespace. > >more readable. How nice for you. -- It's possible that leasing office space to a Starbucks is a greater liability in today's GOP than is hitting your mother on the head with a hammer.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2018-02-26 15:35 +0300 |
| Message-ID | <20180226153511.db5ba4b13c15438593cf8b6a@g{oogle}mail.com> |
| In reply to | #127054 |
Keith Thompson to Anton Shepelev: >>The flexibility that I wanted was the reading of >>tuples of user-supplied cardinality into arrays. >>I did assume the data was machine-generated and >>optimised for reading speed by means of fixed- >>width numbers. This allowed me to jump from one >>number to the next instead of scanning through the >>intervening whitespace. > >You seem to go to some effort to make all lines in >your articles have the same length. In my opinion, >this hurts readability. Words are split across >lines unnecessarily, and double spaces are arbi- >trarily inserted between some words. I suggest you >don't bother. I format my posts with GNU Troff. >I find this: > >>The flexibility that I wanted was the reading of tuples of >>user-supplied cardinality into arrays. I did assume the >>data was machine-generated and optimised for reading speed >>by means of fixed-width numbers. This allowed me to jump >>from one number to the next instead of scanning through the >>intervening whitespace. > >more readable. Even in monospaced font? -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2018-02-26 20:53 +0800 |
| Message-ID | <p7100i$prt$1@dont-email.me> |
| In reply to | #127072 |
AT Monday 26 February 2018 20:35, Anton Shepelev wrote: > Keith Thompson to Anton Shepelev: > >>>The flexibility that I wanted was the reading of >>>tuples of user-supplied cardinality into arrays. >>>I did assume the data was machine-generated and >>>optimised for reading speed by means of fixed- >>>width numbers. This allowed me to jump from one >>>number to the next instead of scanning through the >>>intervening whitespace. >> >>You seem to go to some effort to make all lines in >>your articles have the same length. In my opinion, >>this hurts readability. Words are split across >>lines unnecessarily, and double spaces are arbi- >>trarily inserted between some words. I suggest you >>don't bother. > > I format my posts with GNU Troff. > >>I find this: >> >>>The flexibility that I wanted was the reading of tuples of >>>user-supplied cardinality into arrays. I did assume the >>>data was machine-generated and optimised for reading speed >>>by means of fixed-width numbers. This allowed me to jump >>>from one number to the next instead of scanning through the >>>intervening whitespace. >> >>more readable. > > Even in monospaced font? Yes, text without unnecessary spacing is much better readable. -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2018-02-26 17:54 +0000 |
| Subject | Grammar Patrol (Was: Text Files) |
| Message-ID | <p71hjq$k1l$1@news.xmission.com> |
| In reply to | #127073 |
In article <p7100i$prt$1@dont-email.me>, Reinhardt Behm <rbehm@hushmail.com> wrote: ... >Yes, text without unnecessary spacing is much better readable. Text grammar right readable better, two. -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/LadyChatterley
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-02-26 15:27 +0000 |
| Message-ID | <slrnp989q5.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #127072 |
On Mon, 2018-02-26, Anton Shepelev wrote: > Keith Thompson to Anton Shepelev: > >>>The flexibility that I wanted was the reading of >>>tuples of user-supplied cardinality into arrays. >>>I did assume the data was machine-generated and >>>optimised for reading speed by means of fixed- >>>width numbers. This allowed me to jump from one >>>number to the next instead of scanning through the >>>intervening whitespace. >> >>You seem to go to some effort to make all lines in >>your articles have the same length. In my opinion, >>this hurts readability. Words are split across >>lines unnecessarily, and double spaces are arbi- >>trarily inserted between some words. I suggest you >>don't bother. > > I format my posts with GNU Troff. Then at least your line layout and hyphenation engine is the best. >>I find this: >> >>>The flexibility that I wanted was the reading of tuples of >>>user-supplied cardinality into arrays. I did assume the >>>data was machine-generated and optimised for reading speed >>>by means of fixed-width numbers. This allowed me to jump >>>from one number to the next instead of scanning through the >>>intervening whitespace. >> >>more readable. > > Even in monospaced font? I agree with Keith, although I don't think it's a big deal, given the awful formatting you see on USENET. There are three parts to my problem: - I'm not used to seeing hyphenated and aligned text on USENET. - Your lines appear to be 50 characters wide; that's a bit low for the layout algorithm to give a pleasant result. - I sometimes rewrap quoted text when replying (Emacs Mail-mode) and the hyphenation prevents that. (I see you do it too.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2018-02-26 18:50 +0300 |
| Message-ID | <20180226185010.7b3f9c88e54612cee7da3cc7@g{oogle}mail.com> |
| In reply to | #127077 |
Jorgen Grahn to Anton Shepelev: >>I format my posts with GNU Troff. > >Then at least your line layout and hyphenation en- >gine is the best. groff's line layout is very simple for both charac- ter-cell devices and more advanced vector-based ones (e.g. PostScript). Its hyphenation engine is, as far as I know, identical with that of (La)TeX, and it gives me trouble from time to time, especially with Cyrillic. >I agree with Keith, although I don't think it's a >big deal, given the awful formatting you see on >USENET. The brunt of poor formatting comes from Google groups, then some from incompetent newsreaders not using a monospace font and hard wrapping. >There are three parts to my problem: > >-- I'm not used to seeing hyphenated and aligned > text on USENET. > >-- Your lines appear to be 50 characters wide; > that's a bit low for the layout algorithm to > give a pleasant result. > >-- I sometimes rewrap quoted text when replying > (Emacs Mail-mode) and the hyphenation prevents > that. (I see you do it too.) My lines are 52 characters wide, which is all right for justification with the rare exceptions of long nonbreakable words. It is the with that seems most comfortable to me, although I believe can tolerate 60. Instead of reflowing, I will often reuse the source of the previous post, add my answer and typeset it. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-02-26 09:26 -0800 |
| Message-ID | <lnr2p7irwj.fsf@kst-u.example.com> |
| In reply to | #127080 |
Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
[...]
> My lines are 52 characters wide, which is all right
> for justification with the rare exceptions of long
> nonbreakable words. It is the with that seems most
> comfortable to me, although I believe can tolerate
> 60.
>
> Instead of reflowing, I will often reuse the source
> of the previous post, add my answer and typeset it.
I'm not going to spend much more time trying to persuade you, but
I really do find your articles more difficult to read because of
the way you format them. There haven't been a lot of responses,
but several other people agree with me, and nobody so far has said
your formatting is helpful. If nothing else, the contrast with
all the other articles here is jarring.
I often use "fmt -70", or just "fmt", or the built-in formatter of
the editor I'm using. I find 52 columns annoyingly narrow.
Google Groups is to blame for a lot of the bad formatting we
see here. If I had to use it, I'd copy-and-paste into an editor,
reformat, and copy-and-paste back into Google Groups.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-02-26 19:46 +0000 |
| Message-ID | <uuZkC.43860$hb4.11420@fx11.iad> |
| In reply to | #127083 |
Keith Thompson <kst-u@mib.org> writes:
>Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>[...]
>> My lines are 52 characters wide, which is all right
>> for justification with the rare exceptions of long
>> nonbreakable words. It is the with that seems most
>> comfortable to me, although I believe can tolerate
>> 60.
>>
>> Instead of reflowing, I will often reuse the source
>> of the previous post, add my answer and typeset it.
>
>I'm not going to spend much more time trying to persuade you, but
>I really do find your articles more difficult to read because of
>the way you format them. There haven't been a lot of responses,
On the spectrum of poorly formated USENET posts, Anton's don't
even register. I'd much rather see 52 columns well formated
over anything produced by google groups. Nothing wrong with a
ragged right edge, which troff can be told to do.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-27 09:04 +0100 |
| Message-ID | <p733ei$bi1$1@dont-email.me> |
| In reply to | #127083 |
On 26/02/18 18:26, Keith Thompson wrote:
> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> [...]
>> My lines are 52 characters wide, which is all right
>> for justification with the rare exceptions of long
>> nonbreakable words. It is the with that seems most
>> comfortable to me, although I believe can tolerate
>> 60.
>>
>> Instead of reflowing, I will often reuse the source
>> of the previous post, add my answer and typeset it.
>
> I'm not going to spend much more time trying to persuade you, but
> I really do find your articles more difficult to read because of
> the way you format them. There haven't been a lot of responses,
> but several other people agree with me, and nobody so far has said
> your formatting is helpful. If nothing else, the contrast with
> all the other articles here is jarring.
>
> I often use "fmt -70", or just "fmt", or the built-in formatter of
> the editor I'm using. I find 52 columns annoyingly narrow.
>
> Google Groups is to blame for a lot of the bad formatting we
> see here. If I had to use it, I'd copy-and-paste into an editor,
> reformat, and copy-and-paste back into Google Groups.
>
I agree with Keith here. The 52 character width is too short, and makes
the posts stand out from the norm of Usenet. The justification looks
artificial, and the occasional hyphenation is distracting to the reader.
It is a format well suited to tabloid newspapers where the main stories
are about which semi-famous film star got caught with drugs or threw
their phone at the nanny. And I keep expected to see a "Sent from my
iPhone XIX :-) " signature at the bottom.
There are plenty of other ways to make posts difficult to read in
Usenet. Google groups posts with no line breaks are a pain, especially
if there is code in the same posts (meaning you can't easily reflow it
with a newsreader program). So are posts without attributions, or
without context, or with far too much context. These 52 character posts
are far from the worst - but they are also posts that could easily have
been made a lot nicer just by using standard 72 character widths and
ragged right margins.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2018-02-27 00:56 -0800 |
| Message-ID | <0356003a-1859-49e0-8f19-64688f62016c@googlegroups.com> |
| In reply to | #127118 |
On Tuesday, February 27, 2018 at 10:04:49 AM UTC+2, David Brown wrote:
> On 26/02/18 18:26, Keith Thompson wrote:
> > Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> > [...]
> >> My lines are 52 characters wide, which is all right
> >> for justification with the rare exceptions of long
> >> nonbreakable words. It is the with that seems most
> >> comfortable to me, although I believe can tolerate
> >> 60.
> >>
> >> Instead of reflowing, I will often reuse the source
> >> of the previous post, add my answer and typeset it.
> >
> > I'm not going to spend much more time trying to persuade you, but
> > I really do find your articles more difficult to read because of
> > the way you format them. There haven't been a lot of responses,
> > but several other people agree with me, and nobody so far has said
> > your formatting is helpful. If nothing else, the contrast with
> > all the other articles here is jarring.
> >
> > I often use "fmt -70", or just "fmt", or the built-in formatter of
> > the editor I'm using. I find 52 columns annoyingly narrow.
> >
> > Google Groups is to blame for a lot of the bad formatting we
> > see here. If I had to use it, I'd copy-and-paste into an editor,
> > reformat, and copy-and-paste back into Google Groups.
> >
>
> I agree with Keith here. The 52 character width is too short, and makes
> the posts stand out from the norm of Usenet. The justification looks
> artificial, and the occasional hyphenation is distracting to the reader.
> It is a format well suited to tabloid newspapers where the main stories
> are about which semi-famous film star got caught with drugs or threw
> their phone at the nanny. And I keep expected to see a "Sent from my
> iPhone XIX :-) " signature at the bottom.
>
> There are plenty of other ways to make posts difficult to read in
> Usenet. Google groups posts with no line breaks are a pain, especially
> if there is code in the same posts (meaning you can't easily reflow it
> with a newsreader program). So are posts without attributions, or
> without context, or with far too much context. These 52 character posts
> are far from the worst - but they are also posts that could easily have
> been made a lot nicer just by using standard 72 character widths and
> ragged right margins.
Google groups web client follows the spirit of the Web formatting:
producer is responsible for paragraph marks, consumer is responsible for line breaks.
Yes, there exist an argument that nesgroups pre-date web. I don't give a damn
to that argument. By now newsreaders had more than enough of time to adapt
to new (and better) reality.
A code, embedded within a message is indeed a small problem. Things could
have been better with some form of code tag. But it's not close to be a big
problem as long as neswreader uses rather simple heuristics with regard to
what to consider hard line break vs soft line break.
IMHO, nearly all problem of newsgroup formatting are cultural (snobbery) rather than technical.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-02-27 22:07 +1300 |
| Message-ID | <ffkldtFginrU1@mid.individual.net> |
| In reply to | #127122 |
On 02/27/2018 09:56 PM, already5chosen@yahoo.com wrote: > > IMHO, nearly all problem of newsgroup formatting are cultural (snobbery) rather than technical. Most of the guidelines (50-75 characters) probably go way back to print media. These in turn stem from research findings that people have more difficulty tracking back the the beginning of the next line when the line length exceeds 75 characters. Having had a child with eye tacking issues, I can certainly believe that! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-27 14:37 +0100 |
| Message-ID | <p73mv8$n7b$1@dont-email.me> |
| In reply to | #127123 |
On 27/02/18 10:07, Ian Collins wrote: > On 02/27/2018 09:56 PM, already5chosen@yahoo.com wrote: >> >> IMHO, nearly all problem of newsgroup formatting are cultural >> (snobbery) rather than technical. > > Most of the guidelines (50-75 characters) probably go way back to print > media. These in turn stem from research findings that people have more > difficulty tracking back the the beginning of the next line when the > line length exceeds 75 characters. Having had a child with eye tacking > issues, I can certainly believe that! > These guidelines apply to non-printed media as well - for exactly the same reasons. Another key data point is that 80 character wide terminals and screens used to be very common. I expect it is no coincidence that the common terminal width was slightly wider than popular guidelines for printed text widths.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2018-02-27 07:38 -0800 |
| Message-ID | <38fbb5c6-31f8-41cc-b47f-18ab2a8a9000@googlegroups.com> |
| In reply to | #127129 |
On Tuesday, February 27, 2018 at 3:38:01 PM UTC+2, David Brown wrote: > On 27/02/18 10:07, Ian Collins wrote: > > On 02/27/2018 09:56 PM, already5chosen@yahoo.com wrote: > >> > >> IMHO, nearly all problem of newsgroup formatting are cultural > >> (snobbery) rather than technical. > > > > Most of the guidelines (50-75 characters) probably go way back to print > > media. These in turn stem from research findings that people have more > > difficulty tracking back the the beginning of the next line when the > > line length exceeds 75 characters. Having had a child with eye tacking > > issues, I can certainly believe that! > > > > These guidelines apply to non-printed media as well - for exactly the > same reasons. > > Another key data point is that 80 character wide terminals and screens > used to be very common. I expect it is no coincidence that the common > terminal width was slightly wider than popular guidelines for printed > text widths. The point is not what text width is most convenient, but who should be responsible for text width, producer or consumer. IMHO it's bloody obvious that at least by default, i.e. in case of normal text, rather than python code or poetry, the correct answer is "consumer". That was a correct answer 30 years ago and is only even more correct today, when display devices differ so widely.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-02-27 09:18 -0800 |
| Message-ID | <b3dabde6-07f0-429e-8399-5def1e729e03@googlegroups.com> |
| In reply to | #127131 |
On Tuesday, February 27, 2018 at 9:38:23 AM UTC-6, already...@yahoo.com wrote: > The point is not what text width is most convenient, but who should be > responsible for text width, producer or consumer. IMHO it's bloody > obvious that at least by default, i.e. in case of normal text, rather > than python code or poetry, the correct answer is "consumer". > That was a correct answer 30 years ago and is only even more correct > today, when display devices differ so widely. For text which is marked with forced line breaks only where semantically required, leaving the consumer responsible for non-semantic line breaks is useful and appropriate. For text which includes non-semantic line breaks which cannot be reliably distinguished from semantically-significant ones, but does not have an excessive number of characters between line breaks, it is more useful to have the user agent show line breaks as they appear. Effectively working with a mixture of text in both formats would require a means of indicating which parts of a text are in which format, and as far as I know there is no standard for doing that on Usenet.
[toc] | [prev] | [next] | [standalone]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web