Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #127943 > unrolled thread
| Started by | bartc <bc@freeuk.com> |
|---|---|
| First post | 2018-03-17 16:07 +0000 |
| Last post | 2018-03-21 12:19 +0000 |
| Articles | 20 on this page of 125 — 24 participants |
Back to article view | Back to comp.lang.c
Dropping C bartc <bc@freeuk.com> - 2018-03-17 16:07 +0000
Re: Dropping C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-18 00:41 +0800
Re: Dropping C Richard Damon <Richard@Damon-Family.org> - 2018-03-17 19:54 -0400
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-18 13:19 +1300
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 02:42 -0700
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-18 01:28 +0000
Re: Dropping C Richard Damon <Richard@Damon-Family.org> - 2018-03-17 21:41 -0400
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-18 11:25 +0000
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 04:33 -0700
Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-19 00:05 +0100
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 00:24 +0000
Re: Dropping C Richard Damon <Richard@Damon-Family.org> - 2018-03-18 21:15 -0400
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 19:00 -0700
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-19 14:04 +0100
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-19 06:08 -0700
Re: Dropping C supercat@casperkitty.com - 2018-03-19 14:29 -0700
Re: Dropping C Noob <root@127.0.0.1> - 2018-03-19 14:34 +0100
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-19 06:39 -0700
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-19 15:17 +0100
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 15:03 +0000
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-19 15:36 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 17:01 +0000
Re: Dropping C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-03-19 12:14 -0600
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 19:15 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-20 08:20 +1300
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 20:47 +0000
Re: Dropping C Lowell Gilbert <lgusenet@be-well.ilk.org> - 2018-03-19 18:00 -0400
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 22:17 +0000
Re: Dropping C Reinhardt Behm <rbehm@hushmail.com> - 2018-03-20 09:34 +0800
Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-21 07:54 +0100
Re: Dropping C Robert Wessel <robertwessel2@yahoo.com> - 2018-03-21 04:10 -0500
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-21 11:08 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-21 11:18 +0000
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-21 05:28 -0700
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-21 12:13 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-21 12:26 +0000
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-21 15:55 +0000
Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-21 20:15 +0100
Re: Dropping C Keith Thompson <kst-u@mib.org> - 2018-03-21 12:45 -0700
Re: Dropping C supercat@casperkitty.com - 2018-03-21 13:46 -0700
Killfiles (Was: Dropping C) gazelle@shell.xmission.com (Kenny McCormack) - 2018-03-21 21:42 +0000
Re: Killfiles (Was: Dropping C) Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-22 04:22 -0700
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-21 20:21 +0000
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-21 22:21 -0700
Re: Dropping C Reinhardt Behm <rbehm@hushmail.com> - 2018-03-20 09:32 +0800
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 10:01 +1300
Re: Dropping C luser droog <luser.droog@gmail.com> - 2018-03-20 16:01 -0700
Re: Dropping C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-03-19 13:41 -0600
Re: Dropping C luser droog <luser.droog@gmail.com> - 2018-03-19 12:52 -0700
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-19 20:15 +0000
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-19 20:38 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-19 22:00 +0100
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 01:45 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-20 03:05 +0100
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 21:09 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-20 18:26 +1300
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 10:58 +0000
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-20 14:22 +0100
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-20 13:58 +0000
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-20 17:14 +0100
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 16:31 +0000
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-20 17:14 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 07:31 +1300
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 18:51 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 08:01 +1300
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-20 19:03 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 19:22 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 08:25 +1300
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 19:33 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 09:34 +1300
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-20 19:49 +0000
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-21 11:27 +0100
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 01:27 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-19 17:03 +0100
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-19 23:13 +0100
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-20 00:23 +0100
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 00:55 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-20 02:29 +0100
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 02:04 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-20 03:31 +0100
Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-21 20:18 +0100
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-21 21:32 +0100
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-21 20:52 +0000
Re: Dropping C supercat@casperkitty.com - 2018-03-21 14:38 -0700
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-21 23:08 +0100
Re: Dropping C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-22 13:37 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 15:41 +0100
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-22 14:58 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 17:37 +0100
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-22 17:09 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 18:27 +0100
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-22 17:35 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 18:46 +0100
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-22 18:22 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 19:38 +0100
Re: Dropping C jameskuyper@verizon.net - 2018-03-22 12:19 -0700
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-22 20:23 +0000
Re: Dropping C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-03-23 06:10 -0700
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-23 14:54 +0100
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-23 16:55 +0100
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-23 17:46 +0100
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-24 02:50 +0100
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-24 02:54 +0100
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-22 16:43 +0000
Re: Dropping C Keith Thompson <kst-u@mib.org> - 2018-03-22 10:39 -0700
Re: Dropping C Robert Wessel <robertwessel2@yahoo.com> - 2018-03-22 11:47 -0500
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-24 00:59 -0700
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 15:07 +0000
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-19 15:37 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 17:16 +0000
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-19 20:30 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 21:24 +0000
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-19 23:06 +0000
Re: Dropping C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-20 14:04 +0000
Re: Dropping C supercat@casperkitty.com - 2018-03-19 15:32 -0700
Re: Dropping C Robert Wessel <robertwessel2@yahoo.com> - 2018-03-19 19:03 -0500
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 02:13 +0000
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-20 14:25 +0100
Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-21 18:36 +0100
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-19 23:33 +0100
Re: Dropping C supercat@casperkitty.com - 2018-03-19 16:34 -0700
Re: Dropping C asetofsymbols@gmail.com - 2018-03-20 00:58 -0700
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-20 01:10 -0700
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-19 14:25 +1300
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-21 12:19 +0000
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-20 16:31 +0000 |
| Message-ID | <MHasC.175481$rA1.37375@fx34.am4> |
| In reply to | #128096 |
On 20/03/2018 13:58, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 20/03/18 11:58, bartc wrote: > >>>> Can you use notepad over a serial connection? >>> >>> In what manner? What is at either end of the serial connection? And why >>> is it relevant to editing programming source code? >> >> It would be strange (in this century) to do a lot of code editing over a >> serial connection or low-bandwidth network connection. > > That's my primary mode of work. SSH (6mbps/700kbps DSL) to a server > in the office, tunnelling X back. The low bandwidth uplink makes > anything other than Athena Widgets GUI applications terminally slow. But > vim works great over SSH. (gvim is a bit slower, due to the GTK overhead). From some of your posts I think you will remember 110baud terminals. /That's/ what I would call low-bandwidth. I assume you refer to the 700kbps as low bandwidth, but I can't see that as an impediment to even a graphic mode text editor if implemented properly. What is it that is being transferred at every keystroke or mouse movement? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-03-20 17:14 +0000 |
| Message-ID | <jkbsC.85932$Rp1.72519@fx37.iad> |
| In reply to | #128110 |
bartc <bc@freeuk.com> writes: >On 20/03/2018 13:58, Scott Lurndal wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 20/03/18 11:58, bartc wrote: >> >>>>> Can you use notepad over a serial connection? >>>> >>>> In what manner? What is at either end of the serial connection? And why >>>> is it relevant to editing programming source code? >>> >>> It would be strange (in this century) to do a lot of code editing over a >>> serial connection or low-bandwidth network connection. >> >> That's my primary mode of work. SSH (6mbps/700kbps DSL) to a server >> in the office, tunnelling X back. The low bandwidth uplink makes >> anything other than Athena Widgets GUI applications terminally slow. But >> vim works great over SSH. (gvim is a bit slower, due to the GTK overhead). > > From some of your posts I think you will remember 110baud terminals. > >/That's/ what I would call low-bandwidth. > >I assume you refer to the 700kbps as low bandwidth, but I can't see that >as an impediment to even a graphic mode text editor if implemented >properly. What is it that is being transferred at every keystroke or >mouse movement? > https://www.x.org/releases/X11R7.5/doc/x11proto/proto.pdf
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-03-21 07:31 +1300 |
| Message-ID | <fhd2c4Fa3iaU1@mid.individual.net> |
| In reply to | #128082 |
On 03/20/2018 11:58 PM, bartc wrote: > On 20/03/2018 05:26, Ian Collins wrote: >> On 03/20/2018 10:09 AM, bartc wrote: >>> On 19/03/2018 20:38, Scott Lurndal wrote: >>> >>>>> I obviously mean any editor that just edits text and knows nothing >>>>> about >>>>> ctags or cscopes or databases or identifiers. >>>> >>>> Well, leaving aside how dumb that is.... >>> >>> I understand. You guys are obviously using a language so fantastically >>> advanced that a mere 'editor' just won't do! >> >> vi is a "mere editor". > > One that understands ctags and cscopes? Then it's not a mere editor. And > if it doesn't, then it would be a dumb way of editing C source, > according to Scott. > >> Can you use notepad over a serial connection? > > In what manner? What is at either end of the serial connection? And why > is it relevant to editing programming source code? Two recent real examples: updating code on client systems that are accessed through a tty port over a serial to Ethernet converter. Fixing code that prevented a system starting its networking services on startup. > When I run my own editor I can use it on anything that is accessible via > my file system, or that has been made accessible (eg. run ftp first). I > don't know what point you're trying to make other than some apparent > superiority of vi over Notepad. Simple editors don't need a GUI. > (I don't use Notepad, it's just a good example of a simple editor.) ed is a good example of a simple editor! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-20 18:51 +0000 |
| Message-ID | <_KcsC.148367$Mv4.4553@fx37.am4> |
| In reply to | #128113 |
On 20/03/2018 18:31, Ian Collins wrote: > On 03/20/2018 11:58 PM, bartc wrote: >> On 20/03/2018 05:26, Ian Collins wrote: >>> On 03/20/2018 10:09 AM, bartc wrote: >>>> On 19/03/2018 20:38, Scott Lurndal wrote: >>>> >>>>>> I obviously mean any editor that just edits text and knows nothing >>>>>> about >>>>>> ctags or cscopes or databases or identifiers. >>>>> >>>>> Well, leaving aside how dumb that is.... >>>> >>>> I understand. You guys are obviously using a language so fantastically >>>> advanced that a mere 'editor' just won't do! >>> >>> vi is a "mere editor". >> >> One that understands ctags and cscopes? Then it's not a mere editor. And >> if it doesn't, then it would be a dumb way of editing C source, >> according to Scott. >> >>> Can you use notepad over a serial connection? >> >> In what manner? What is at either end of the serial connection? And why >> is it relevant to editing programming source code? > > Two recent real examples: updating code on client systems that are > accessed through a tty port over a serial to Ethernet converter. Fixing > code that prevented a system starting its networking services on startup. I'm not sure why that needs to be a concern of an editor; why can't you use other services to transfer the file to your machine than transfer it back again? Then you can use ANY editor of any capabilities. >> When I run my own editor I can use it on anything that is accessible via >> my file system, or that has been made accessible (eg. run ftp first). I >> don't know what point you're trying to make other than some apparent >> superiority of vi over Notepad. > > Simple editors don't need a GUI. You don't need an advanced GUI but you do need a visual representation of the file you're working on. That can be with a console display (ie. char-based not pixel-based). (The smallest such editor I created I think was on a machine with just 1KB memory, including the video frame buffer [1K x 6-bit char display and 256 bytes code]. So on anything else there isn't any excuse to use those appalling line buffer editors if that's what you meant.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-03-21 08:01 +1300 |
| Message-ID | <fhd448Fa3iaU2@mid.individual.net> |
| In reply to | #128114 |
On 03/21/2018 07:51 AM, bartc wrote: > On 20/03/2018 18:31, Ian Collins wrote: >> On 03/20/2018 11:58 PM, bartc wrote: >>> On 20/03/2018 05:26, Ian Collins wrote: >>>> On 03/20/2018 10:09 AM, bartc wrote: >>>>> On 19/03/2018 20:38, Scott Lurndal wrote: >>>>> >>>>>>> I obviously mean any editor that just edits text and knows nothing >>>>>>> about >>>>>>> ctags or cscopes or databases or identifiers. >>>>>> >>>>>> Well, leaving aside how dumb that is.... >>>>> >>>>> I understand. You guys are obviously using a language so fantastically >>>>> advanced that a mere 'editor' just won't do! >>>> >>>> vi is a "mere editor". >>> >>> One that understands ctags and cscopes? Then it's not a mere editor. And >>> if it doesn't, then it would be a dumb way of editing C source, >>> according to Scott. >>> >>>> Can you use notepad over a serial connection? >>> >>> In what manner? What is at either end of the serial connection? And why >>> is it relevant to editing programming source code? >> >> Two recent real examples: updating code on client systems that are >> accessed through a tty port over a serial to Ethernet converter. Fixing >> code that prevented a system starting its networking services on startup. > > I'm not sure why that needs to be a concern of an editor; why can't you > use other services to transfer the file to your machine than transfer it > back again? Then you can use ANY editor of any capabilities. It isn't a concern of an editor, it's a use for an editor. Copying files back and forth over a serial connection is a very inefficient way of working compared to using a simple editor locally. >>> When I run my own editor I can use it on anything that is accessible via >>> my file system, or that has been made accessible (eg. run ftp first). I >>> don't know what point you're trying to make other than some apparent >>> superiority of vi over Notepad. >> >> Simple editors don't need a GUI. > > You don't need an advanced GUI but you do need a visual representation > of the file you're working on. That can be with a console display (ie. > char-based not pixel-based). A console display is exactly what a simple editor such as vi uses. A GUI layer is a whole extra level of complexity many systems neither have nor need. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-03-20 19:03 +0000 |
| Message-ID | <hWcsC.44397$hO5.10698@fx05.iad> |
| In reply to | #128114 |
bartc <bc@freeuk.com> writes: >On 20/03/2018 18:31, Ian Collins wrote: >> >> Two recent real examples: updating code on client systems that are >> accessed through a tty port over a serial to Ethernet converter. Fixing >> code that prevented a system starting its networking services on startup. > >I'm not sure why that needs to be a concern of an editor; why can't you >use other services to transfer the file to your machine than transfer it >back again? Then you can use ANY editor of any capabilities. I, and I expect Ian as well, have no desire to ever learn another editor. Logging in to a server with ssh through a terminal concentrator hosting the serial consoles for a row of racks to fix a simple config file is much more convenient then copying files around or rolling a cart with a monitor/keyboard/mouse to the right row in the datacenter. Calling notepad an editor is generous at best. >> Simple editors don't need a GUI. > >You don't need an advanced GUI but you do need a visual representation >of the file you're working on. That can be with a console display (ie. >char-based not pixel-based). A console (character based) display is the very antithesis of a GUI.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-20 19:22 +0000 |
| Message-ID | <VbdsC.243680$Ly1.145955@fx13.am4> |
| In reply to | #128116 |
On 20/03/2018 19:03, Scott Lurndal wrote: > bartc <bc@freeuk.com> writes: >> On 20/03/2018 18:31, Ian Collins wrote: > >>> >>> Two recent real examples: updating code on client systems that are >>> accessed through a tty port over a serial to Ethernet converter. Fixing >>> code that prevented a system starting its networking services on startup. >> >> I'm not sure why that needs to be a concern of an editor; why can't you >> use other services to transfer the file to your machine than transfer it >> back again? Then you can use ANY editor of any capabilities. > > I, and I expect Ian as well, have no desire to ever learn another editor. > > Logging in to a server with ssh through a terminal concentrator > hosting the serial consoles for a row of racks to fix a simple config file is much more > convenient then copying files around or rolling a cart with a monitor/keyboard/mouse > to the right row in the datacenter. I'm mildly surprised this can't be done with a script. For example, this script I just created lets me edit the index.html file associated with my web page (www.bcas.freeuk.com): ftp -s:downloadindex call ed index.html ftp -s:uploadindex My editor (invoked with 'ed') needs to know nothing about ftp file transfers. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-03-21 08:25 +1300 |
| Message-ID | <fhd5hiFa3iaU3@mid.individual.net> |
| In reply to | #128118 |
On 03/21/2018 08:22 AM, bartc wrote: > On 20/03/2018 19:03, Scott Lurndal wrote: >> bartc <bc@freeuk.com> writes: >>> On 20/03/2018 18:31, Ian Collins wrote: >> >>>> >>>> Two recent real examples: updating code on client systems that are >>>> accessed through a tty port over a serial to Ethernet converter. Fixing >>>> code that prevented a system starting its networking services on startup. >>> >>> I'm not sure why that needs to be a concern of an editor; why can't you >>> use other services to transfer the file to your machine than transfer it >>> back again? Then you can use ANY editor of any capabilities. >> >> I, and I expect Ian as well, have no desire to ever learn another editor. >> >> Logging in to a server with ssh through a terminal concentrator >> hosting the serial consoles for a row of racks to fix a simple config file is much more >> convenient then copying files around or rolling a cart with a monitor/keyboard/mouse >> to the right row in the datacenter. > > > I'm mildly surprised this can't be done with a script. > > For example, this script I just created lets me edit the index.html file > associated with my web page (www.bcas.freeuk.com): > > ftp -s:downloadindex > call ed index.html > ftp -s:uploadindex Does it work over a serial tty? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-20 19:33 +0000 |
| Message-ID | <rmdsC.65541$PX4.64534@fx35.am4> |
| In reply to | #128119 |
On 20/03/2018 19:25, Ian Collins wrote: > On 03/21/2018 08:22 AM, bartc wrote: >> On 20/03/2018 19:03, Scott Lurndal wrote: >>> bartc <bc@freeuk.com> writes: >>>> On 20/03/2018 18:31, Ian Collins wrote: >>> >>>>> >>>>> Two recent real examples: updating code on client systems that are >>>>> accessed through a tty port over a serial to Ethernet converter. >>>>> Fixing >>>>> code that prevented a system starting its networking services on >>>>> startup. >>>> >>>> I'm not sure why that needs to be a concern of an editor; why can't you >>>> use other services to transfer the file to your machine than >>>> transfer it >>>> back again? Then you can use ANY editor of any capabilities. >>> >>> I, and I expect Ian as well, have no desire to ever learn another >>> editor. >>> >>> Logging in to a server with ssh through a terminal concentrator >>> hosting the serial consoles for a row of racks to fix a simple >>> config file is much more >>> convenient then copying files around or rolling a cart with a >>> monitor/keyboard/mouse >>> to the right row in the datacenter. >> >> >> I'm mildly surprised this can't be done with a script. >> >> For example, this script I just created lets me edit the index.html file >> associated with my web page (www.bcas.freeuk.com): >> >> ftp -s:downloadindex >> call ed index.html >> ftp -s:uploadindex > > Does it work over a serial tty? I doubt FTP will. But I've no idea of my machine's capabilities in that respect. The point however is splitting the acquisition of the data to be edited, from the editor itself. For example, I could invent a new type of interface tomorrow, BARTSYNC, and a way to upload and download files. But your editor would probably have no built-in means of doing so. I'm not sure about the purpose of your remarks, is it just to reinforce the idea that your editor with builtin serial tty ssh [insert loads more tlas just as meaningless to me] is better than Notepad, then I get that. I would still rather use mine. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-03-21 09:34 +1300 |
| Message-ID | <fhd9hrFa3iaU4@mid.individual.net> |
| In reply to | #128120 |
On 03/21/2018 08:33 AM, bartc wrote: > On 20/03/2018 19:25, Ian Collins wrote: >> On 03/21/2018 08:22 AM, bartc wrote: >>> On 20/03/2018 19:03, Scott Lurndal wrote: >>>> bartc <bc@freeuk.com> writes: >>>>> On 20/03/2018 18:31, Ian Collins wrote: >>>> >>>>>> >>>>>> Two recent real examples: updating code on client systems that are >>>>>> accessed through a tty port over a serial to Ethernet converter. >>>>>> Fixing >>>>>> code that prevented a system starting its networking services on >>>>>> startup. >>>>> >>>>> I'm not sure why that needs to be a concern of an editor; why can't you >>>>> use other services to transfer the file to your machine than >>>>> transfer it >>>>> back again? Then you can use ANY editor of any capabilities. >>>> >>>> I, and I expect Ian as well, have no desire to ever learn another >>>> editor. >>>> >>>> Logging in to a server with ssh through a terminal concentrator >>>> hosting the serial consoles for a row of racks to fix a simple >>>> config file is much more >>>> convenient then copying files around or rolling a cart with a >>>> monitor/keyboard/mouse >>>> to the right row in the datacenter. >>> >>> >>> I'm mildly surprised this can't be done with a script. >>> >>> For example, this script I just created lets me edit the index.html file >>> associated with my web page (www.bcas.freeuk.com): >>> >>> ftp -s:downloadindex >>> call ed index.html >>> ftp -s:uploadindex >> >> Does it work over a serial tty? > > I doubt FTP will. But I've no idea of my machine's capabilities in that > respect. > > The point however is splitting the acquisition of the data to be edited, > from the editor itself. Which works fine with many small files but not so well with one of your monstrous all-in-ones! > I'm not sure about the purpose of your remarks, is it just to reinforce > the idea that your editor with builtin serial tty ssh [insert loads more > tlas just as meaningless to me] is better than Notepad, then I get that. The editor doesn't have any "builtin serial tty ssh" it is just a simple editor that works on a dumb terminal. The epitome of a "mere editor" rather than a GUI based monstrosity... -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-03-20 19:49 +0000 |
| Message-ID | <UAdsC.8957$0v5.3706@fx31.iad> |
| In reply to | #128118 |
bartc <bc@freeuk.com> writes: >On 20/03/2018 19:03, Scott Lurndal wrote: >> bartc <bc@freeuk.com> writes: >>> On 20/03/2018 18:31, Ian Collins wrote: >> >>>> >>>> Two recent real examples: updating code on client systems that are >>>> accessed through a tty port over a serial to Ethernet converter. Fixing >>>> code that prevented a system starting its networking services on startup. >>> >>> I'm not sure why that needs to be a concern of an editor; why can't you >>> use other services to transfer the file to your machine than transfer it >>> back again? Then you can use ANY editor of any capabilities. >> >> I, and I expect Ian as well, have no desire to ever learn another editor. >> >> Logging in to a server with ssh through a terminal concentrator >> hosting the serial consoles for a row of racks to fix a simple config file is much more >> convenient then copying files around or rolling a cart with a monitor/keyboard/mouse >> to the right row in the datacenter. > > >I'm mildly surprised this can't be done with a script. > >For example, this script I just created lets me edit the index.html file >associated with my web page (www.bcas.freeuk.com): > > ftp -s:downloadindex FTP is disabled on all modern servers for very good reasons. > call ed index.html > ftp -s:uploadindex > >My editor (invoked with 'ed') needs to know nothing about ftp file >transfers. So, ssh host cd /var/www/html vim index.html ^D is hardly worse.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-21 11:27 +0100 |
| Message-ID | <p8tc1l$q5f$1@dont-email.me> |
| In reply to | #128116 |
On 20/03/18 20:03, Scott Lurndal wrote: > bartc <bc@freeuk.com> writes: >> On 20/03/2018 18:31, Ian Collins wrote: > >>> >>> Two recent real examples: updating code on client systems that are >>> accessed through a tty port over a serial to Ethernet converter. Fixing >>> code that prevented a system starting its networking services on startup. >> >> I'm not sure why that needs to be a concern of an editor; why can't you >> use other services to transfer the file to your machine than transfer it >> back again? Then you can use ANY editor of any capabilities. > > I, and I expect Ian as well, have no desire to ever learn another editor. > I find it useful to make a distinction between mainstream development, small changes outside of my focus, and emergency fixes. For normal development, I use Eclipse - others have different preferences, but the typical situation is to have a big, powerful IDE with lots of features to make your main development work as smooth as possible. Sometimes I also need to do a little short-term work on other projects. Depending on the size of the effort, I might bring up a second copy of Eclipse with a different workspace, or I might just use a lightweight editor such as gedit. And when I want to make changes directly on a remote system, I use a small console editor - nano. These give different balances of features and convenience, so I use them all at different times. Some editors - vim and emacs stand out - can be used in a much broader range of circumstances as they have powerful programmers' tools (like ctags) /and/ can run as pure console mode. But I am sure that even there, you could well have different setups and selections of add-ons for different purposes. > Logging in to a server with ssh through a terminal concentrator > hosting the serial consoles for a row of racks to fix a simple config file is much more > convenient then copying files around or rolling a cart with a monitor/keyboard/mouse > to the right row in the datacenter. > > > Calling notepad an editor is generous at best. > > >>> Simple editors don't need a GUI. >> >> You don't need an advanced GUI but you do need a visual representation >> of the file you're working on. That can be with a console display (ie. >> char-based not pixel-based). > > A console (character based) display is the very antithesis of a GUI. >
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2018-03-20 01:27 +0000 |
| Message-ID | <weq1cZKhskkYpvW9x3VTy8bF6qO4k@bongo-ra.co> |
| In reply to | #128030 |
On Mon, 19 Mar 2018 20:38:53 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
> Bell Labs and USL software written in C followed certain
> conventions to make it easier to use the "editor" (vi, not vim).
>
> A typical function would be coded as:
>
> return-type
> function-name(parameters...)
> {
> body
> }
>
> This allowed certain keystroke sequences to find certain things.
>
> For example, to find the function definition, one would simply
> search for the function name at the beginning of the line. (/^function-name
> in vi).
>
> To move the cursor to the start of the function, hit [[ twice and
> it will move the cursor to a prior line that had the '{' as the
> first character on the line, while ]] will move the cursor to the
> first line (opening brace) of the next function.
>
> Unix, SVR4 and Unixware all followed this convention.
I have seen the convention and I dislike it. It looks ugly , it makes the
code harder to read and it wastes 2 lines thereby reducing the context one
sees on the screen.
> It really pissed me off that Linus wasn't aware of this simple
> convention and consequently the opensource world prefers 'return-type function(...) {'
Linus only sets coding standards for the Linux kernel and possibly also for
git .The rest of the open source world do their own thing. Note for example
that GNU coding standards specify what you want :
www.gnu.org/prep/standards/standards.html#Formatting .Personally I do prefer
return-type function(...) {
....
}
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2018-03-19 17:03 +0100 |
| Message-ID | <20180319170345.de479c7d9d02f2e0570a7b28@gmail.com> |
| In reply to | #128001 |
On Mon, 19 Mar 2018 15:03:54 +0000
bartc <bc@freeuk.com> wrote:
> BTW I've been meaning to ask this for a while: given an ordinary text
> editor, and given the name of a function, how do you find that
> function definition in a source file? I mean, going straight there
> rather then scanning a hundred other occurrences of the name before
> you get to the definition.
Just open the right source file in your text editor. ;-)
Usually looking for "funcname(" is enough. Bad code management put
everything in the same file, whereas good code management split each
function definition in its own file. It could be very annoying to lose
a lot of code consequently to a bad IDE crash.
I would recommend you to read "The Standard C Library" by Phillip James
PLAUGER which provides some good advices in implementing a robust C
code.
--
GOTHIER Nathan
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-19 23:13 +0100 |
| Message-ID | <p8pcm7$ier$1@dont-email.me> |
| In reply to | #128006 |
On 19/03/18 17:03, GOTHIER Nathan wrote:
> On Mon, 19 Mar 2018 15:03:54 +0000
> bartc <bc@freeuk.com> wrote:
>
>> BTW I've been meaning to ask this for a while: given an ordinary text
>> editor, and given the name of a function, how do you find that
>> function definition in a source file? I mean, going straight there
>> rather then scanning a hundred other occurrences of the name before
>> you get to the definition.
>
> Just open the right source file in your text editor. ;-)
>
> Usually looking for "funcname(" is enough. Bad code management put
> everything in the same file, whereas good code management split each
> function definition in its own file. It could be very annoying to lose
> a lot of code consequently to a bad IDE crash.
No, good code management puts related content in the same file, keeping
files of convenient size. Too big a source file and it is hard to find
what you are looking for. Too small source files, and you lose
modularity, pollute your global name space, and /also/ have trouble
finding what you are looking for.
With the right size of your files (where "right size" depends on many
factors), well-chosen function names, logical layout, and sensible file
names, it is usually fairly obvious if the function you want is in the
file you have open, or which file it is likely to be found in.
Obviously an IDE or a half-decent programmers' editor will find it for
you in a fraction of a second, but for small projects you should be able
to find your function definitions manually without too much trouble.
And using decent file management, source code versioning systems,
backups, etc., is what protects your code from bad crashes.
>
> I would recommend you to read "The Standard C Library" by Phillip James
> PLAUGER which provides some good advices in implementing a robust C
> code.
>
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2018-03-20 00:23 +0100 |
| Message-ID | <20180320002317.76847e5e055cf6e02c901994@gmail.com> |
| In reply to | #128042 |
On Mon, 19 Mar 2018 23:13:27 +0100 David Brown <david.brown@hesbynett.no> wrote: > No, good code management puts related content in the same file, > keeping files of convenient size. Too big a source file and it is > hard to find what you are looking for. Too small source files, and > you lose modularity, pollute your global name space, and /also/ have > trouble finding what you are looking for. I disagree. Related contents should be stored in the same directory. It is not a coincidence if the C programming language provides the source file inclusion in addition to the header inclusion (which may but not mandatory include a file). > With the right size of your files (where "right size" depends on many > factors), well-chosen function names, logical layout, and sensible > file names, it is usually fairly obvious if the function you want is > in the file you have open, or which file it is likely to be found in. > Obviously an IDE or a half-decent programmers' editor will find it > for you in a fraction of a second, but for small projects you should > be able to find your function definitions manually without too much > trouble. There is no right size for a source file but only a good code design for the project. > And using decent file management, source code versioning systems, > backups, etc., is what protects your code from bad crashes. Wrong. Only reliable tools protect your code from defects. However, splitting each function definition into one file enables to limit the recovery cost. -- GOTHIER Nathan
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2018-03-20 00:55 +0000 |
| Message-ID | <weq1cZKhskkYpsW9x3VTy8bF6qO4k@bongo-ra.co> |
| In reply to | #128006 |
On Mon, 19 Mar 2018 17:03:45 +0100
GOTHIER Nathan <nathan.gothier@gmail.com> wrote:
> Usually looking for "funcname(" is enough. Bad code management put
> everything in the same file, whereas good code management split each
> function definition in its own file.
No , putting each function definition in its own file would make the code
very hard to read. Related functions should go in the same file.
> It could be very annoying to lose
> a lot of code consequently to a bad IDE crash.
I haven't had vim crash on me in many years. In any case , it saves
regularly in the so called "swapfiles" and you can even control how
often saving happens through the options updatecount and
updatetime .If an IDE or editor does not provide analogous facilities
then they're not fit for serious work.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2018-03-20 02:29 +0100 |
| Message-ID | <20180320022902.6d9a903062a2fca49d7801b9@gmail.com> |
| In reply to | #128060 |
On Tue, 20 Mar 2018 00:55:48 GMT Spiros Bousbouras <spibou@gmail.com> wrote: > No , putting each function definition in its own file would make the > code very hard to read. Related functions should go in the same file. Could you explain why inflating the source file with zillions function definitions makes it more convenient to read by the programmer than reading a small file containing only one function definition? > I haven't had vim crash on me in many years. In any case , it saves > regularly in the so called "swapfiles" and you can even control how > often saving happens through the options updatecount and > updatetime .If an IDE or editor does not provide analogous facilities > then they're not fit for serious work. Serious work should be saved but not autocrappy. If you don't trust the programmer then why programming? Specially in C. -- GOTHIER Nathan
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2018-03-20 02:04 +0000 |
| Message-ID | <0%ZrC.159455$_91.56000@fx02.am4> |
| In reply to | #128063 |
On Tue, 20 Mar 2018 02:29:02 +0100
GOTHIER Nathan <nathan.gothier@gmail.com> wrote:
> On Tue, 20 Mar 2018 00:55:48 GMT
> Spiros Bousbouras <spibou@gmail.com> wrote:
>
> > No , putting each function definition in its own file would make the
> > code very hard to read. Related functions should go in the same file.
>
> Could you explain why inflating the source file with zillions function
> definitions makes it more convenient to read by the programmer than
> reading a small file containing only one function definition?
It wouldn't be zillions it would be a number so that the total file size is
not "too big" where "too big" is up to individual taste or judgement. It
makes it easier to read because if the functions are related , which means
they call each other and possibly use some file scope variables , it's easier
to follow the flow of code and also the relation between the functions and
any file scope variables. Whereas if they were separated between different
files , you would have to switch between files to do the same. Say for example
you have
static size_t buffer_pos , buffer_size , line_num ;
static char *line ;
static void report_error(...) {
... Uses line_num in its error reports ...
}
static void put_char_in_buffer(char ch) {
... Uses buffer_pos , buffer_size and line ...
}
void get_line(FILE * input_file) {
... Increases line_num and uses line .It also uses buffer_pos
to get the final line length ...
}
void parse_line(...) {
... If parsing is simple then you can put this function in the same file
as the others ...
}
How would you break this so that each function is in its own file ?
> > I haven't had vim crash on me in many years. In any case , it saves
> > regularly in the so called "swapfiles" and you can even control how
> > often saving happens through the options updatecount and
> > updatetime .If an IDE or editor does not provide analogous facilities
> > then they're not fit for serious work.
>
> Serious work should be saved but not autocrappy. If you don't trust the
> programmer then why programming? Specially in C.
What's crappy about it ? As for saving regularly , it's not about trust ,
it's about tedium. I wouldn't have trouble remembering to save regularly ,
I would just find it boring and prefer it if the editor does it automatically.
I don't always do it like this but sometimes it's convenient.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2018-03-20 03:31 +0100 |
| Message-ID | <20180320033154.27f2660cdd5f6676712b9722@gmail.com> |
| In reply to | #128067 |
On Tue, 20 Mar 2018 02:04:44 GMT
Spiros Bousbouras <spibou@gmail.com> wrote:
> It wouldn't be zillions it would be a number so that the total file
> size is not "too big" where "too big" is up to individual taste or
> judgement. It makes it easier to read because if the functions are
> related , which means they call each other and possibly use some file
> scope variables , it's easier to follow the flow of code and also the
> relation between the functions and any file scope variables. Whereas
> if they were separated between different files , you would have to
> switch between files to do the same. Say for example you have
>
> static size_t buffer_pos , buffer_size , line_num ;
> static char *line ;
>
> static void report_error(...) {
> ... Uses line_num in its error reports ...
> }
>
> static void put_char_in_buffer(char ch) {
> ... Uses buffer_pos , buffer_size and line ...
> }
>
> void get_line(FILE * input_file) {
> ... Increases line_num and uses line .It also uses buffer_pos
> to get the final line length ...
> }
>
> void parse_line(...) {
> ... If parsing is simple then you can put this function in the
> same file as the others ...
> }
>
> How would you break this so that each function is in its own file ?
/* common.c */
#if (defined(COMMON) == 0)
#define COMMON 1
size_t buffer_size = 0U;
size_t buffer_pos = 0U;
size_t line_num = 0U;
#endif
/* reperr.c */
#if (defined(REPERR) == 0)
#define REPERR 1
extern size_t line_num;
void report_error(/* some parameters */)
{
/* use line_num in its error reports */
}
#endif
/* etc */
> What's crappy about it ? As for saving regularly , it's not about
> trust , it's about tedium. I wouldn't have trouble remembering to
> save regularly , I would just find it boring and prefer it if the
> editor does it automatically. I don't always do it like this but
> sometimes it's convenient.
Thus you don't trust the programmer to realize relevant backups.
Actually autosaving corrupted files is not a good bargain.
--
GOTHIER Nathan
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web