Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #141169 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2019-02-23 21:59 +0100 |
| Last post | 2019-03-01 19:30 +0100 |
| Articles | 20 on this page of 308 — 53 participants |
Back to article view | Back to comp.lang.c
C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-23 21:59 +0100
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-23 22:02 +0100
Re: C is not a low level language Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-02-23 16:05 -0500
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-24 08:37 +0100
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 12:12 +0800
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 12:11 +0800
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 12:40 +0800
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 05:16 +0000
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 13:20 +0800
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 13:24 +0800
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 19:45 +0800
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 13:09 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 14:38 +0000
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 15:18 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 17:21 +0100
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 17:43 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 20:17 +0100
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 18:19 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 20:02 +0100
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 19:26 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 21:36 +0100
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 20:47 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 21:10 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 08:25 +0100
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-25 12:24 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 17:04 +0100
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-25 16:52 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 17:59 -0800
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 09:19 +0100
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 09:41 +0100
Re: C is not a low level language Mateusz Viste <mateusz@wont.tell> - 2019-02-25 09:01 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 01:55 -0800
Re: C is not a low level language James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-25 10:24 -0800
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 08:46 +0100
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 09:36 +0100
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 10:13 +0100
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-26 09:56 +0100
Re: C is not a low level language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-25 14:12 +0000
Re: C is not a low level language James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-25 10:31 -0800
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 12:20 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 13:36 -0800
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 22:57 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 10:29 +0200
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 09:41 +0100
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 10:55 +0200
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 10:24 +0100
Re: C is not a low level language James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-25 10:46 -0800
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:34 +0200
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 21:03 +0000
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 08:58 +0100
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 09:40 +0100
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 10:01 +0100
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 12:55 -0800
Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 08:31 +0100
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 17:42 +0000
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 18:19 +0000
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-24 17:56 +0000
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 18:23 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 20:58 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 20:52 +0000
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-25 16:31 +0000
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-25 08:48 -0800
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 14:01 -0800
Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-25 23:04 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 15:53 -0800
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-26 00:29 -0800
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-26 01:33 -0800
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-28 16:07 +0000
Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-25 20:50 +0100
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-28 16:04 +0000
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-28 16:25 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-28 11:56 -0500
Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-28 19:45 +0000
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 17:55 +0000
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-28 16:03 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-28 11:25 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-28 19:30 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-02-28 13:18 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-28 21:48 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-02-28 17:54 -0800
Re: C is not a low level language Ian Collins <ian-news@hotmail.com> - 2019-03-01 20:19 +1300
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 03:05 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-03-01 11:29 +0000
The extent of Rick's experience (Was: C is not a low level language) gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-01 12:19 +0000
Re: The extent of Rick's experience (Was: C is not a low level language) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-01 04:28 -0800
Re: The extent of Rick's experience (Was: C is not a low level language) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 04:34 -0800
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 04:32 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-01 14:28 +0100
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-03-01 15:57 +0200
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 06:24 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-04 09:21 +0100
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-04 11:23 +0100
Re: C is not a low level language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-04 14:47 +0000
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-04 15:58 +0100
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-04 07:02 -0800
Re: C is not a low level language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-05 06:36 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-05 05:14 -0800
Re: C is not a low level language jadill33@gmail.com - 2019-03-05 05:44 -0800
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-05 16:47 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-03-01 14:02 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-03-01 15:50 +0200
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 06:11 -0800
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-03-01 16:50 +0200
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 07:22 -0800
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 07:24 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-03 19:55 +0100
Re: C is not a low level language Ian Collins <ian-news@hotmail.com> - 2019-03-02 08:39 +1300
Re: C is not a low level language Ian Collins <ian-news@hotmail.com> - 2019-03-02 08:37 +1300
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 11:43 -0800
Re: C is not a low level language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-02 07:20 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-02 04:18 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-03-02 12:28 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-02 05:19 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-03-02 23:47 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-02 18:24 -0800
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-03-02 16:02 +0100
Re: C is not a low level language Ian Collins <ian-news@hotmail.com> - 2019-03-03 06:53 +1300
Yep, I'm not surprised. (Was: C is not a low level language) gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-01 07:31 +0000
Re: C is not a low level language Wes Newell <w.newell@tx.rr.com> - 2019-03-01 06:13 +0000
Re: C is not a low level language Wes Newell <w.newell@tx.rr.com> - 2019-03-01 06:11 +0000
Re: C is not a low level language Jasen Betts <jasen@xnet.co.nz> - 2019-02-24 20:47 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 21:29 +0000
Re: C is not a low level language Jasen Betts <jasen@xnet.co.nz> - 2019-02-25 20:16 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 12:53 -0800
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 09:49 +0200
Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-25 21:07 +0100
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 22:59 +0000
Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-26 09:57 +0100
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-26 01:35 -0800
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 09:59 +0000
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-27 07:20 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-27 07:36 -0800
Re: C is not a low level language Eric Stevens <eric.stevens@sum.co.nz> - 2019-02-24 19:54 +1300
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-24 07:56 +0000
Re: C is not a low level language Eric Stevens <eric.stevens@sum.co.nz> - 2019-02-24 21:58 +1300
Re: C is not a low level language "A. Dumas" <alexandre@dumas.fr.invalid> - 2019-02-24 10:57 +0100
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-24 10:13 +0000
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 10:47 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-24 08:48 -0500
Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 14:42 +0000
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 07:15 +0000
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-25 02:43 -0800
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-25 09:25 -0500
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 15:03 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-25 12:10 -0500
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 17:58 +0000
Re: C is not a low level language Axel Berger <Spam@Berger-Odenthal.De> - 2019-02-25 17:44 +0100
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 19:18 +0200
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 10:35 +0200
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 10:44 +0000
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-25 12:29 +0000
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 14:26 +0000
Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 17:08 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 20:08 +0200
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 18:00 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-27 22:37 -0800
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-28 02:25 -0800
Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 12:27 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-25 09:36 -0500
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 15:05 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 19:20 +0200
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 23:02 +0000
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 06:52 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:41 +0200
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 12:20 +0000
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 14:01 +0100
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-26 08:48 -0500
Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-26 19:20 +0100
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 10:04 -0500
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 04:33 -0800
Re: C is not a low level language lonelydad <lonelydad58@gmail.com> - 2019-02-24 14:44 +0000
You were not meant to undersand this was: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-26 09:47 -0800
Re: You were not meant to undersand this was: C is not a low level language pjp <pjpoirier_is_located@hotmail.com> - 2019-02-26 16:05 -0400
Re: C is not a low level language luser droog <luser.droog@gmail.com> - 2019-02-26 20:16 -0800
Re: C is not a low level language "U-laptop\\Norah" <Norah@laptop.i-did-not-set--mail-host-address--so-tickle-me> - 2019-02-27 16:16 -0600
Re: C is not a low level language Eric Stevens <eric.stevens@sum.co.nz> - 2019-03-01 12:12 +1300
Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-03-01 00:19 +0000
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 04:57 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 05:15 -0800
Re: C is not a low level language Gene Wirchenko <genew@telus.net> - 2019-02-24 19:59 -0800
Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-25 16:10 +0000
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-25 09:00 -0800
Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-25 21:02 +0100
Re: C is not a low level language Lars Enderin <lars.enderin@telia.com> - 2019-02-26 00:37 +0100
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 19:09 -0500
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 06:52 +0000
Re: C is not a low level language T <T@invalid.invalid> - 2019-02-24 00:30 -0800
Re: C is not a low level language T <T@invalid.invalid> - 2019-02-24 00:31 -0800
Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-24 10:16 +0000
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-24 11:22 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-24 08:51 -0500
Re: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-24 07:20 -0800
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-24 15:35 +0000
Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-24 11:05 -0500
Re: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-24 14:39 -0800
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 19:11 -0800
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 09:41 -0500
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 14:53 +0000
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 10:19 -0500
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-25 16:38 +0100
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 11:20 -0500
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 17:49 +0000
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 09:18 +0100
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 20:25 +0200
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:40 -0500
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:45 +0200
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-26 08:02 -0500
Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-26 09:11 -0500
Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 09:23 +0100
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-26 08:02 -0500
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 17:57 +0200
Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 17:42 -0500
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 22:33 +0000
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 09:30 +0100
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-26 01:58 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 12:19 +0100
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 13:52 -0800
Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 15:20 +0000
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 18:47 +0000
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:50 -0500
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 18:59 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 20:15 +0200
Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-25 18:38 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:49 +0200
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:40 -0500
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:55 +0200
Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-26 16:29 +0000
Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-03-04 23:43 -0500
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-25 10:01 -0800
Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 18:16 +0000
Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 17:44 +0000
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:05 -0500
Re: C is not a low level language Robert Wessel <robertwessel2@yahoo.com> - 2019-02-26 00:51 -0600
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-26 10:58 +0100
Re: C is not a low level language Robert Wessel <robertwessel2@yahoo.com> - 2019-02-26 10:53 -0600
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-26 09:04 -0800
Re: C is not a low level language Robert Wessel <robertwessel2@yahoo.com> - 2019-02-26 13:25 -0600
Re: C is not a low level language Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-26 09:16 -0800
Re: C is not a low level language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-26 17:49 +0000
Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-26 18:11 +0000
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-26 18:24 +0000
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-26 10:29 -0800
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-26 19:24 +0100
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-26 19:44 +0100
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-27 03:29 -0800
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-26 10:26 -0800
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-26 12:41 -0800
Re: C is not a low level language nobody@example.org (Scott) - 2019-02-26 06:33 +0000
Re: C is not a low level language mark.bluemel@gmail.com - 2019-02-25 07:24 -0800
Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
Re: C is not a low level language Gene Wirchenko <genew@telus.net> - 2019-02-24 20:03 -0800
Re: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-24 14:56 -0800
Re: C is not a low level language Jasen Betts <jasen@xnet.co.nz> - 2019-02-24 20:43 +0000
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-25 14:14 +0800
Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 10:45 +0000
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-25 19:04 +0800
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 09:51 +0100
Re: C is not a low level language Melzzzzz <Melzzzzz@zzzzz.com> - 2019-02-24 09:37 +0000
Re: C is not a low level language Ian Collins <ian-news@hotmail.com> - 2019-02-24 22:52 +1300
Re: C is not a low level language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-24 11:13 +0000
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 16:30 +0100
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 07:50 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 08:14 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 08:29 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 09:00 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-24 17:16 +0100
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 08:42 -0800
Re: C is not a low level language bart4858@gmail.com - 2019-02-24 09:38 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 10:09 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 10:13 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 10:23 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 10:48 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-24 19:07 +0000
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 11:10 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-24 19:19 +0000
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-25 10:32 -0800
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 20:49 +0100
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 12:59 -0800
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 18:02 +0100
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-24 21:56 +0100
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 23:00 +0100
Re: C is not a low level language BGB <cr88192@hotmail.com> - 2019-02-28 17:07 -0600
Re: C is not a low level language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-24 20:34 +0000
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 23:04 +0100
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-24 14:29 -0800
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-25 07:12 +0100
Re: C is not a low level language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-24 10:41 +0000
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 06:47 -0800
Re: C is not a low level language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-24 17:30 +0000
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 16:32 +0100
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-02-24 03:19 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 04:29 -0800
Re: C is not a low level language Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-02-24 11:11 -0500
Re: C is not a low level language Rosario19 <Ros@invalid.invalid> - 2019-02-25 12:57 +0100
Re: C is not a low level language "l.s." <l.s@cryptolab.net> - 2019-02-28 19:17 +0100
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-28 21:09 +0100
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-02-28 13:20 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-01 10:27 +0100
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-03-01 14:18 +0100
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-01 15:10 +0100
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-03-01 19:30 +0100
Page 6 of 16 — ← Prev page 1 … 4 5 [6] 7 8 … 16 Next page →
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-03-01 15:50 +0200 |
| Message-ID | <4upnkf-0e4.ln1@gangtai.home.grep.be> |
| In reply to | #141531 |
On 1/03/2019 13:05, Rick C. Hodgin wrote:
> On Friday, March 1, 2019 at 2:19:33 AM UTC-5, Ian Collins wrote:
>> On 01/03/2019 14:54, Rick C. Hodgin wrote:
>>> On Thursday, February 28, 2019 at 4:48:41 PM UTC-5, Bart wrote:
>>>> On 28/02/2019 21:18, Rick C. Hodgin wrote:
>>>>> Do you have a "Bart Compiler Debugger" that you've created...
>>>> No I've never used a debugger nor created one.
>>> I could not get by without one.
>>
>> Using a debugger is an admission of defeat...
>
>
> If your debugger is gdb, then I agree. :-)
Nah.
> In the Windows developer environment we have the Visual Studio
> Debugger. It's one of the sole reasons I use Microsoft tools for
> development. Its debugger environment is unrivaled.
gdb is better, IMO. It also handles many of the things on your list:
> Remote debugging,
Check ("target remote <machine>:<port>", and then run "gdbserver
0.0.0.0:<port>" on the target).
> simultaneous multi-process,
Nope (but then, you can just start multiple instances in multiple
terminals, so I don't miss it)
> multi-thread debugging,
Breakpoints and watch points work across threads, so check for me (but
you might be meaning something else, in which case please elaborate).
> edit-and-continue,
That crashes more often than not, IME.
> exception handling,
Yes, I do miss that.
> memory and watch windows that handle ad hoc expressions,
You can use ad hoc expressions in gdb too, but sometimes the syntax is a
bit weird indeed.
> a Code Definition window which
> tracks the text under your cursor
Check ("gdb -tui")
> and contextually brings up class
> and struct definitions in other source files, variable definitions,
> function definitions, class and struct definitions, etc.
gdb is a stand-alone debugger, not an IDE; but many IDEs that use gdb
behind the curtains do provide this.
> It's a developer's greatest asset for non-trivial development.
>
> Visual Studio 2017 has integrated gcc+gdb support now, bringing a
> nice skin to gdb's abilities, though it's still lacking relative
> to Visual Studio's native debugger.
gdb also has:
- python integration (that is, you can script much of it with python)
- support for many more platforms than just "x86"
- the "ddd" frontent for a visual representation of the memory layout
(which is *far* more powerful than the table-based one that), and which
can also create graphs of how data in particular memory locations
changes over time (https://www.gnu.org/software/ddd/)
- support for other languages than just C++ and C (the home page
mentions Ada, Assembly, C, C++, D, Fortran, Go, Objective-C, OpenCL,
Modula-2, Pascal, and Rust, although I'll grant you that Assembly is
rather obvious)
- The ability to record and replay a debugging session (which I grant
isn't always useful, but can sometimes be very helpful):
https://sourceware.org/gdb/current/onlinedocs/gdb/Process-Record-and-Replay.html#Process-Record-and-Replay
- The ability to use detached debugging symbols (so you can ship
production code without the symbols installed, but still have the
debugging symbols available to figure out what went wrong in a core
dump, say)
- Reverse execution (although that requires support from the target):
https://sourceware.org/gdb/current/onlinedocs/gdb/Reverse-Execution.html#Reverse-Execution
... and a whole lot of other things.
All things considered, personally I prefer gdb over the MS debugger.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-03-01 06:11 -0800 |
| Message-ID | <a9c9f2a7-9d7b-4a80-8e8a-6dfc084f5a41@googlegroups.com> |
| In reply to | #141545 |
On Friday, March 1, 2019 at 8:59:13 AM UTC-5, Wouter Verhelst wrote:
> On 1/03/2019 13:05, Rick C. Hodgin wrote:
> > On Friday, March 1, 2019 at 2:19:33 AM UTC-5, Ian Collins wrote:
> >> On 01/03/2019 14:54, Rick C. Hodgin wrote:
> >>> On Thursday, February 28, 2019 at 4:48:41 PM UTC-5, Bart wrote:
> >>>> On 28/02/2019 21:18, Rick C. Hodgin wrote:
> >>>>> Do you have a "Bart Compiler Debugger" that you've created...
> >>>> No I've never used a debugger nor created one.
> >>> I could not get by without one.
> >>
> >> Using a debugger is an admission of defeat...
> >
> >
> > If your debugger is gdb, then I agree. :-)
>
> Nah.
>
> > In the Windows developer environment we have the Visual Studio
> > Debugger. It's one of the sole reasons I use Microsoft tools for
> > development. Its debugger environment is unrivaled.
>
> gdb is better, IMO. It also handles many of the things on your list:
Visual Studio 2017 (and possibly 2015) and later support GDB
natively. So, by definition, Visual Studio is better than GDB
because it not only includes all capabilities of GDB, but it
has more on top of it.
> > Remote debugging,
> Check ("target remote <machine>:<port>", and then run "gdbserver
> 0.0.0.0:<port>" on the target).
Good to know. I will make a note of it.
In Visual Studio you install a service on the remote machine,
which exposes the debugging services. You connect to the
machine by IP address or machine name, and then it lists out
the processes and you attach to as many as you need.
> > simultaneous multi-process,
> Nope (but then, you can just start multiple instances in multiple
> terminals, so I don't miss it)
It comes in handy when you're debugging a multi-process app.
You can, from one debugger instance, do something like SendMsg()
and have it leave the one process, arrive in the other, and you
can continue single-step debugging without missing a beat. When
it hits the return; you will seamlessly go back to the previous
process and keep going.
Very smooth and powerful.
> > multi-thread debugging,
>
> Breakpoints and watch points work across threads, so check for me (but
> you might be meaning something else, in which case please elaborate).
When you debug a thread you can choose to break all threads, or
let the other threads keep going.
> > edit-and-continue,
> That crashes more often than not, IME.
It depends on the nature of the change. Code fixes, the addition
of limited new local variables, these all work reliably.
Edit-and-continue doesn't work in 64-bit mode though, which for
some is a show stopper.
> > exception handling,
> Yes, I do miss that.
>
> > memory and watch windows that handle ad hoc expressions,
> You can use ad hoc expressions in gdb too, but sometimes the syntax is a
> bit weird indeed.
I'm not sure technically how MS does it, but I'm pretty sure they
use the same Visual C++ compiler because in the debugger the syntax
is pretty much identical to that of C++. You even use &var to get
its address in the watch window, for example.
> > a Code Definition window which
> > tracks the text under your cursor
> Check ("gdb -tui")
The Code Definition window works continuously in the IDE. It's
not just in the debugger, but it is a nice constant lookup source
for you. Visual Studio 2003 had one which would bring up the
contextual help file. I actually miss that, as it would show you
what you would find on MSDN pages for each of the functions, and
you could create your own help files to use likewise.
I wish they would bring that back.
> > and contextually brings up class
> > and struct definitions in other source files, variable definitions,
> > function definitions, class and struct definitions, etc.
>
> gdb is a stand-alone debugger, not an IDE; but many IDEs that use gdb
> behind the curtains do provide this.
I understand. Visual Studio is wholly integrated into the IDE. It
provides the full power of the tools available during source code
editing during your debugging session. It's a seamless environment
that, except for the change in screen layout to see the extra windows
used for debugging, you'd never know it wasn't running in the normal
editor.
> > It's a developer's greatest asset for non-trivial development.
> >
> > Visual Studio 2017 has integrated gcc+gdb support now, bringing a
> > nice skin to gdb's abilities, though it's still lacking relative
> > to Visual Studio's native debugger.
>
> gdb also has:
>
> - python integration (that is, you can script much of it with python)
> - support for many more platforms than just "x86"
> - the "ddd" frontent for a visual representation of the memory layout
> (which is *far* more powerful than the table-based one that), and which
> can also create graphs of how data in particular memory locations
> changes over time (https://www.gnu.org/software/ddd/)
I would like to see the ability to have add-on extensions to display
the memory in Visual Studio differently. That may exist, but it
would be nice to be able to see a graphics image you're constructing
as graphics, rather than byte-by-byte data.
> - support for other languages than just C++ and C (the home page
> mentions Ada, Assembly, C, C++, D, Fortran, Go, Objective-C, OpenCL,
> Modula-2, Pascal, and Rust, although I'll grant you that Assembly is
> rather obvious)
MS supports the languages it supports, including C/C++, C#, J#, F#,
and all of the other ones it does. .NET Javascript and XML tool.
> - The ability to record and replay a debugging session (which I grant
> isn't always useful, but can sometimes be very helpful):
> https://sourceware.org/gdb/current/onlinedocs/gdb/Process-Record-and-Replay.html#Process-Record-and-Replay
WinDbg has that, which is another separate Microsoft debugger tool
usually used for post mortem analyis. They call it Time Travel
Debugging.
> - The ability to use detached debugging symbols (so you can ship
> production code without the symbols installed, but still have the
> debugging symbols available to figure out what went wrong in a core
> dump, say)
Microsoft provides that via their PDB. You ship apps without any
debugging information, and the compiled PDB it generated at compile
+ link time associates the internal workings with everything.
This works in Visual Studio and WinDbg.
> - Reverse execution (although that requires support from the target):
> https://sourceware.org/gdb/current/onlinedocs/gdb/Reverse-Execution.html#Reverse-Execution
I've never seen the benefit of that, but I know some people do
love it.
> ... and a whole lot of other things.
>
> All things considered, personally I prefer gdb over the MS debugger.
I've never seen a more clunky debugger than gdb. It is all text-
based, and even with a GUI over the top it has limited functionality.
It also doesn't support edit-and-continue, which for me is a non-
starter.
To be honest, I can see why many people hate debuggers if all
they've ever used is GDB. It didn't even have Intel syntax when
I started using it. It was so awful compared to Visual Studio's
debugger, and even the CodeView DOS-based debugger, that I did
not code in GCC or any of the GNU toolchains because of it.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-03-01 16:50 +0200 |
| Message-ID | <tdtnkf-nii.ln1@gangtai.home.grep.be> |
| In reply to | #141549 |
On 1/03/2019 16:11, Rick C. Hodgin wrote:
> On Friday, March 1, 2019 at 8:59:13 AM UTC-5, Wouter Verhelst wrote:
>> On 1/03/2019 13:05, Rick C. Hodgin wrote:
>>> On Friday, March 1, 2019 at 2:19:33 AM UTC-5, Ian Collins wrote:
>>>> On 01/03/2019 14:54, Rick C. Hodgin wrote:
>>>>> On Thursday, February 28, 2019 at 4:48:41 PM UTC-5, Bart wrote:
>>>>>> On 28/02/2019 21:18, Rick C. Hodgin wrote:
>>>>>>> Do you have a "Bart Compiler Debugger" that you've created...
>>>>>> No I've never used a debugger nor created one.
>>>>> I could not get by without one.
>>>>
>>>> Using a debugger is an admission of defeat...
>>>
>>>
>>> If your debugger is gdb, then I agree. :-)
>>
>> Nah.
>>
>>> In the Windows developer environment we have the Visual Studio
>>> Debugger. It's one of the sole reasons I use Microsoft tools for
>>> development. Its debugger environment is unrivaled.
>>
>> gdb is better, IMO. It also handles many of the things on your list:
>
> Visual Studio 2017 (and possibly 2015) and later support GDB
> natively. So, by definition, Visual Studio is better than GDB
> because it not only includes all capabilities of GDB, but it
> has more on top of it.
Well, yeah, but then you're comparing apples and oranges.
gdb is a debugger, nothing more.
Visual Studio ships with a debugger and a whole lot of other things.
I'm comparing gdb against the Visual Studio debugger, not a debugger
against an IDE (which I hope you'll agree is not a fair comparison).
>>> Remote debugging,
>> Check ("target remote <machine>:<port>", and then run "gdbserver
>> 0.0.0.0:<port>" on the target).
>
> Good to know. I will make a note of it.
>
> In Visual Studio you install a service on the remote machine,
> which exposes the debugging services. You connect to the
> machine by IP address or machine name, and then it lists out
> the processes and you attach to as many as you need.
I hope there's some authentication involved there :-)
>>> simultaneous multi-process,
>> Nope (but then, you can just start multiple instances in multiple
>> terminals, so I don't miss it)
>
> It comes in handy when you're debugging a multi-process app.
> You can, from one debugger instance, do something like SendMsg()
> and have it leave the one process, arrive in the other, and you
> can continue single-step debugging without missing a beat. When
> it hits the return; you will seamlessly go back to the previous
> process and keep going.
>
> Very smooth and powerful.
It sounds pretty confusing to me.
When I've had to debug two applications that speak to eachother, I
prefer to just run them in separate windows. That makes it much more
obvious when I'm dealing with the client and when I'm dealing with the
server, too.
>>> multi-thread debugging,
>>
>> Breakpoints and watch points work across threads, so check for me (but
>> you might be meaning something else, in which case please elaborate).
>
> When you debug a thread you can choose to break all threads, or
> let the other threads keep going.
Breakpoints stop all threads under gdb. I don't know whether it allows
to keep other threads going, but I don't really see the benefit of that TBH.
[...]>>> exception handling,
>> Yes, I do miss that.
>>
>>> memory and watch windows that handle ad hoc expressions,
>> You can use ad hoc expressions in gdb too, but sometimes the syntax is a
>> bit weird indeed.
>
> I'm not sure technically how MS does it, but I'm pretty sure they
> use the same Visual C++ compiler because in the debugger the syntax
> is pretty much identical to that of C++. You even use &var to get
> its address in the watch window, for example.
Yeah, gdb has that too. You can also do pointer arithmetic or access the
members of a struct, etc.
Honestly, you don't need a compiler for that -- just something that
parses expressions is enough.
[...]
>>> It's a developer's greatest asset for non-trivial development.
>>>
>>> Visual Studio 2017 has integrated gcc+gdb support now, bringing a
>>> nice skin to gdb's abilities, though it's still lacking relative
>>> to Visual Studio's native debugger.
>>
>> gdb also has:
>>
>> - python integration (that is, you can script much of it with python)
>> - support for many more platforms than just "x86"
>> - the "ddd" frontent for a visual representation of the memory layout
>> (which is *far* more powerful than the table-based one that), and which
>> can also create graphs of how data in particular memory locations
>> changes over time (https://www.gnu.org/software/ddd/)
>
> I would like to see the ability to have add-on extensions to display
> the memory in Visual Studio differently. That may exist, but it
> would be nice to be able to see a graphics image you're constructing
> as graphics, rather than byte-by-byte data.
That sounds nice too, but is not what I meant.
ddd allows you to show 2D and 3D graphs of how variables change over
time. Please see https://www.gnu.org/software/ddd/plots.png for a
screenshot that shows you how that works.
[...]
>> All things considered, personally I prefer gdb over the MS debugger.
>
> I've never seen a more clunky debugger than gdb. It is all text-
> based,
The advantage of that is that I can SSH into a server, see that
something crashed, load the symbols file, and gdb the core file to
figure out what went wrong -- all while being on the crappy hotel wifi
while on holiday. This is much more complicated with graphical interfaces.
And you don't *have* to use the text interface; that's just the basic
fall-back UI that you use if nothing else is available. For regular
work, there are plenty of frontends that help you, and most IDEs support
gdb. Even visual studio does, by your own admission.
So let's not compare "the Visual Studio IDE" against "the basic
text-only interface of gdb", but let's compare "the features of the
Visual Studio debugger implementation" against "the features of gdb". If
you do that, in my opinion gdb is much more powerful.
> and even with a GUI over the top it has limited functionality.
>
> It also doesn't support edit-and-continue, which for me is a non-
> starter.
It does indeed not support that.
However, it does allow you to randomly modify memory values from the
debugger interface, and it also allows you to call random functions from
the debugger command line:
p foo()
is gdb-esque for "run the function called foo and print its output.
So if the kind of edit-and-continue that you wanted to implement does
not involve an extra branch, and you do not expect to run that function
again, you can:
- edit the source code to have the new function call or statements
- run the statements manually from the gdb command line
which is not the same as edit-and-continue, but would work for many
cases where edit-and-continue is useful, IMO (and works on all supported
platforms, not just 32-bit x86).
[...]
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-03-01 07:22 -0800 |
| Message-ID | <c29f7204-67e8-4c07-a378-60702e6edccc@googlegroups.com> |
| In reply to | #141553 |
On Friday, March 1, 2019 at 9:50:29 AM UTC-5, Wouter Verhelst wrote:
> On 1/03/2019 16:11, Rick C. Hodgin wrote:
> > On Friday, March 1, 2019 at 8:59:13 AM UTC-5, Wouter Verhelst wrote:
> >> gdb is better, IMO. It also handles many of the things on your list:
> >
> > Visual Studio 2017 (and possibly 2015) and later support GDB
> > natively. So, by definition, Visual Studio is better than GDB
> > because it not only includes all capabilities of GDB, but it
> > has more on top of it.
>
> Well, yeah, but then you're comparing apples and oranges.
>
> gdb is a debugger, nothing more.
> Visual Studio ships with a debugger and a whole lot of other things.
>
> I'm comparing gdb against the Visual Studio debugger, not a debugger
> against an IDE (which I hope you'll agree is not a fair comparison).
I was only referring to the debugger abilities. Visual Studio's
debugger has the ability to integrate with source code natively,
you can double-click on variables and have them appear in watch
windows. You can select text and drag it to a window an drop it
to inspect it.
These also work atop GDB, by the way, so that it will query the
same things you manipulate in that way in Visual Studio's IDE, but
it is the underlying GDB query / response system that handles the
return results.
> > In Visual Studio you install a service on the remote machine,
> > which exposes the debugging services. You connect to the
> > machine by IP address or machine name, and then it lists out
> > the processes and you attach to as many as you need.
>
> I hope there's some authentication involved there :-)
Yes. :-)
> >>> simultaneous multi-process,
> >> Nope (but then, you can just start multiple instances in multiple
> >> terminals, so I don't miss it)
> >
> > It comes in handy when you're debugging a multi-process app.
> > You can, from one debugger instance, do something like SendMsg()
> > and have it leave the one process, arrive in the other, and you
> > can continue single-step debugging without missing a beat. When
> > it hits the return; you will seamlessly go back to the previous
> > process and keep going.
> >
> > Very smooth and powerful.
>
> It sounds pretty confusing to me.
>
> When I've had to debug two applications that speak to eachother, I
> prefer to just run them in separate windows. That makes it much more
> obvious when I'm dealing with the client and when I'm dealing with the
> server, too.
You can do that in Visual Studio too. With the ability to have
multiple separate processes being debugged simultaneously, you
track with the IP address into different source files, which you
should also be coordinating with your thinking.
It can be confusing at times, but if you're "in the moment" it's
all intuitive.
> > When you debug a thread you can choose to break all threads, or
> > let the other threads keep going.
>
> Breakpoints stop all threads under gdb. I don't know whether it
> allows to keep other threads going, but I don't really see the
> benefit of that TBH.
I don't think I've ever used it, but I see it's an option. :-)
It would allow you to investigate a live running machine in pro-
duction. You could intercept your one test piece of data and
single-step through it, the one you know causes issues, while
the other ones which work properly continue processing through.
Pretty rare use case IMO, but Microsoft added it for a reason.
> > I'm not sure technically how MS does it, but I'm pretty sure they
> > use the same Visual C++ compiler because in the debugger the syntax
> > is pretty much identical to that of C++. You even use &var to get
> > its address in the watch window, for example.
>
> Yeah, gdb has that too. You can also do pointer arithmetic or access the
> members of a struct, etc.
>
> Honestly, you don't need a compiler for that -- just something that
> parses expressions is enough.
I figure it's just the front-end to the point of producing refer-
ences into the running ABI.
> [...]
> >>> It's a developer's greatest asset for non-trivial development.
> >>>
> >>> Visual Studio 2017 has integrated gcc+gdb support now, bringing a
> >>> nice skin to gdb's abilities, though it's still lacking relative
> >>> to Visual Studio's native debugger.
> >>
> >> gdb also has:
> >>
> >> - python integration (that is, you can script much of it with python)
> >> - support for many more platforms than just "x86"
> >> - the "ddd" frontent for a visual representation of the memory layout
> >> (which is *far* more powerful than the table-based one that), and which
> >> can also create graphs of how data in particular memory locations
> >> changes over time (https://www.gnu.org/software/ddd/)
> >
> > I would like to see the ability to have add-on extensions to display
> > the memory in Visual Studio differently. That may exist, but it
> > would be nice to be able to see a graphics image you're constructing
> > as graphics, rather than byte-by-byte data.
>
> That sounds nice too, but is not what I meant.
>
> ddd allows you to show 2D and 3D graphs of how variables change over
> time. Please see https://www.gnu.org/software/ddd/plots.png for a
> screenshot that shows you how that works.
Microsoft added that in VS2017. It's enabled by default, which is
really annoying. I didn't like it so I had shut it down. It also
provides timing information for functions as you single-step over
them ... also annoying because it injects text into the editor code
window which has tool tips popping up if you mouse over it.
Some features add too much clutter and should only be enabled when
needed, IMO. I think Microsoft wanted to advertise their shiny new
features though so they're auto-enabled.
> [...]
> >> All things considered, personally I prefer gdb over the MS debugger.
> >
> > I've never seen a more clunky debugger than gdb. It is all text-
> > based,
>
> The advantage of that is that I can SSH into a server, see that
> something crashed, load the symbols file, and gdb the core file to
> figure out what went wrong -- all while being on the crappy hotel wifi
> while on holiday. This is much more complicated with graphical interfaces.
>
> And you don't *have* to use the text interface; that's just the basic
> fall-back UI that you use if nothing else is available. For regular
> work, there are plenty of frontends that help you, and most IDEs support
> gdb. Even visual studio does, by your own admission.
>
> So let's not compare "the Visual Studio IDE" against "the basic
> text-only interface of gdb", but let's compare "the features of the
> Visual Studio debugger implementation" against "the features of gdb". If
> you do that, in my opinion gdb is much more powerful.
I prefer the GUI and the transport layer working with its own basic
requests, allowing the GUI to display them however it wants. The
debugger issues commands like "30 bytes beginning at 0xa000000" and
the transport layer sends it, and then the debugger makes sense of
it. Was it code to be disassembled? Was it a structure to display?
Was it ... whatever it was, it's all contextual through basic
abilities. I think that design is tidy. It's how CAlive's debugger
works.
> > and even with a GUI over the top it has limited functionality.
> >
> > It also doesn't support edit-and-continue, which for me is a non-
> > starter.
>
> It does indeed not support that.
>
> However, it does allow you to randomly modify memory values from the
> debugger interface, and it also allows you to call random functions from
> the debugger command line:
>
> p foo()
>
> is gdb-esque for "run the function called foo and print its output.
That is one thing I wish Visual Studio's debugger had, was the ability
to call a function ad hoc and display its results. I added that to my
own debugger. I also added something I call Codepoints, which are
like breakpoints, but they allow you to run arbitrary code at a par-
ticular point where you would set a breakpoint. You can code it there
in the debugger ad hoc.
> So if the kind of edit-and-continue that you wanted to implement does
> not involve an extra branch, and you do not expect to run that function
> again, you can:
>
> - edit the source code to have the new function call or statements
> - run the statements manually from the gdb command line
>
> which is not the same as edit-and-continue, but would work for many
> cases where edit-and-continue is useful, IMO (and works on all supported
> platforms, not just 32-bit x86).
Visual Studio is lacking in some areas where I think it could have
additions. I've added some of these to my debugger.
Here are some of the ideas I've had over time:
http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/ideas/debugger.txt
I added this one to address multi-process debugging more visually:
Jun.17.2018 -- Allow for colorized current line highlighting in
the debugger, or colorized source code, based on what module you
are in. If in the kernel code, blue coloring, if in a driver,
green coloring, if in your own app standard syntax highlighting
coloring, and if in a 3rd-party DLL or plugin, gray scaling, or
other such combinations.
I thought it would be nice to see the current source code line change
from whatever color it normally is to another one when you leave the
main debugged app (first process attached to for debugging).
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-03-01 07:24 -0800 |
| Message-ID | <6194a3f0-8e61-45c8-9361-3e4f9ced9bf5@googlegroups.com> |
| In reply to | #141553 |
On Friday, March 1, 2019 at 9:50:29 AM UTC-5, Wouter Verhelst wrote:
> On 1/03/2019 16:11, Rick C. Hodgin wrote:
> > On Friday, March 1, 2019 at 8:59:13 AM UTC-5, Wouter Verhelst wrote:
> >> On 1/03/2019 13:05, Rick C. Hodgin wrote:
> >>> simultaneous multi-process,
> >> Nope (but then, you can just start multiple instances in multiple
> >> terminals, so I don't miss it)
> >
> > It comes in handy when you're debugging a multi-process app.
> > You can, from one debugger instance, do something like SendMsg()
> > and have it leave the one process, arrive in the other, and you
> > can continue single-step debugging without missing a beat. When
> > it hits the return; you will seamlessly go back to the previous
> > process and keep going.
> >
> > Very smooth and powerful.
>
> It sounds pretty confusing to me.
Oops. It was this one I added for multi-processes. The other
color option was for debugging a single app which enters into
different modules, not so much processes:
Sep.12.2017 -- Allow an option for colorized instances, so
separate processes can be debugged in separate instances, and
it's immediately intuitive which one it is by the color. Green
for the main app, blue for another, red for another, etc.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-03 19:55 +0100 |
| Message-ID | <q5h7vh$thp$1@dont-email.me> |
| In reply to | #141553 |
On 01/03/2019 15:50, Wouter Verhelst wrote:
> On 1/03/2019 16:11, Rick C. Hodgin wrote:
>> On Friday, March 1, 2019 at 8:59:13 AM UTC-5, Wouter Verhelst wrote:
>>> On 1/03/2019 13:05, Rick C. Hodgin wrote:
>>>> On Friday, March 1, 2019 at 2:19:33 AM UTC-5, Ian Collins wrote:
>>>>> On 01/03/2019 14:54, Rick C. Hodgin wrote:
>>>>>> On Thursday, February 28, 2019 at 4:48:41 PM UTC-5, Bart wrote:
>>>>>>> On 28/02/2019 21:18, Rick C. Hodgin wrote:
>>>>>>>> Do you have a "Bart Compiler Debugger" that you've created...
>>>>>>> No I've never used a debugger nor created one.
>>>>>> I could not get by without one.
>>>>>
>>>>> Using a debugger is an admission of defeat...
>>>>
>>>>
>>>> If your debugger is gdb, then I agree. :-)
>>>
>>> Nah.
>>>
>>>> In the Windows developer environment we have the Visual Studio
>>>> Debugger. It's one of the sole reasons I use Microsoft tools for
>>>> development. Its debugger environment is unrivaled.
>>>
>>> gdb is better, IMO. It also handles many of the things on your list:
>>
>> Visual Studio 2017 (and possibly 2015) and later support GDB
>> natively. So, by definition, Visual Studio is better than GDB
>> because it not only includes all capabilities of GDB, but it
>> has more on top of it.
>
> Well, yeah, but then you're comparing apples and oranges.
>
> gdb is a debugger, nothing more.
> Visual Studio ships with a debugger and a whole lot of other things.
>
Yes. If you want to compare to VS, you should compare something like
Eclipse or Netbeans.
> I'm comparing gdb against the Visual Studio debugger, not a debugger
> against an IDE (which I hope you'll agree is not a fair comparison).
>
>>>> Remote debugging,
>>> Check ("target remote <machine>:<port>", and then run "gdbserver
>>> 0.0.0.0:<port>" on the target).
>>
>> Good to know. I will make a note of it.
>>
>> In Visual Studio you install a service on the remote machine,
>> which exposes the debugging services. You connect to the
>> machine by IP address or machine name, and then it lists out
>> the processes and you attach to as many as you need.
>
> I hope there's some authentication involved there :-)
gdb also supports several dozens of embedded targets in many different ways.
>
>>>> multi-thread debugging,
>>>
>>> Breakpoints and watch points work across threads, so check for me (but
>>> you might be meaning something else, in which case please elaborate).
>>
>> When you debug a thread you can choose to break all threads, or
>> let the other threads keep going.
>
> Breakpoints stop all threads under gdb. I don't know whether it allows
> to keep other threads going, but I don't really see the benefit of that TBH.
>
Rick needs here) thread-specific. You can pause everything, or just one
thread.
> [...]>>> exception handling,
>>> Yes, I do miss that.
gdb can set "catchpoints" to break on exceptions - throws, rethrows,
catches, etc.
>>>
>>>> memory and watch windows that handle ad hoc expressions,
>>> You can use ad hoc expressions in gdb too, but sometimes the syntax is a
>>> bit weird indeed.
>>
>> I'm not sure technically how MS does it, but I'm pretty sure they
>> use the same Visual C++ compiler because in the debugger the syntax
>> is pretty much identical to that of C++. You even use &var to get
>> its address in the watch window, for example.
>
> Yeah, gdb has that too. You can also do pointer arithmetic or access the
> members of a struct, etc.
>
> Honestly, you don't need a compiler for that -- just something that
> parses expressions is enough.
>
Exactly.
> [...]
>>>> It's a developer's greatest asset for non-trivial development.
>>>>
>>>> Visual Studio 2017 has integrated gcc+gdb support now, bringing a
>>>> nice skin to gdb's abilities, though it's still lacking relative
>>>> to Visual Studio's native debugger.
>>>
>>> gdb also has:
>>>
>>> - python integration (that is, you can script much of it with python)
>>> - support for many more platforms than just "x86"
>>> - the "ddd" frontent for a visual representation of the memory layout
>>> (which is *far* more powerful than the table-based one that), and which
>>> can also create graphs of how data in particular memory locations
>>> changes over time (https://www.gnu.org/software/ddd/)
>>
>> I would like to see the ability to have add-on extensions to display
>> the memory in Visual Studio differently. That may exist, but it
>> would be nice to be able to see a graphics image you're constructing
>> as graphics, rather than byte-by-byte data.
>
> That sounds nice too, but is not what I meant.
>
> ddd allows you to show 2D and 3D graphs of how variables change over
> time. Please see https://www.gnu.org/software/ddd/plots.png for a
> screenshot that shows you how that works.
>
> [...]
>>> All things considered, personally I prefer gdb over the MS debugger.
>>
>> I've never seen a more clunky debugger than gdb. It is all text-
>> based,
>
> The advantage of that is that I can SSH into a server, see that
> something crashed, load the symbols file, and gdb the core file to
> figure out what went wrong -- all while being on the crappy hotel wifi
> while on holiday. This is much more complicated with graphical interfaces.
gdb is also very scriptable using the text-based interface.
>
> And you don't *have* to use the text interface; that's just the basic
> fall-back UI that you use if nothing else is available. For regular
> work, there are plenty of frontends that help you, and most IDEs support
> gdb. Even visual studio does, by your own admission.
>
This also means there are different choices for your gdb front-end, and
it means that the same gdb front-end can use different gdb back-ends
(such as for different target processors).
> So let's not compare "the Visual Studio IDE" against "the basic
> text-only interface of gdb", but let's compare "the features of the
> Visual Studio debugger implementation" against "the features of gdb". If
> you do that, in my opinion gdb is much more powerful.
>
>> and even with a GUI over the top it has limited functionality.
>>
>> It also doesn't support edit-and-continue, which for me is a non-
>> starter.
>
> It does indeed not support that.
>
gdb /does/ support JIT compilation, which could probably be used for
something like edit-and-continue. I don't know
> However, it does allow you to randomly modify memory values from the
> debugger interface, and it also allows you to call random functions from
> the debugger command line:
>
> p foo()
>
> is gdb-esque for "run the function called foo and print its output.
>
> So if the kind of edit-and-continue that you wanted to implement does
> not involve an extra branch, and you do not expect to run that function
> again, you can:
>
> - edit the source code to have the new function call or statements
> - run the statements manually from the gdb command line
>
> which is not the same as edit-and-continue, but would work for many
> cases where edit-and-continue is useful, IMO (and works on all supported
> platforms, not just 32-bit x86).
>
> [...]
>
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-03-02 08:39 +1300 |
| Message-ID | <gdtg3tF7ehsU3@mid.individual.net> |
| In reply to | #141545 |
On 02/03/2019 02:50, Wouter Verhelst wrote: > - Reverse execution (although that requires support from the target): > https://sourceware.org/gdb/current/onlinedocs/gdb/Reverse-Execution.html#Reverse-Execution Some of our team have been playing with that, its a hoot :) -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-03-02 08:37 +1300 |
| Message-ID | <gdtfvkF7ehsU2@mid.individual.net> |
| In reply to | #141531 |
On 02/03/2019 00:05, Rick C. Hodgin wrote: > On Friday, March 1, 2019 at 2:19:33 AM UTC-5, Ian Collins wrote: >> On 01/03/2019 14:54, Rick C. Hodgin wrote: >>> On Thursday, February 28, 2019 at 4:48:41 PM UTC-5, Bart wrote: >>>> On 28/02/2019 21:18, Rick C. Hodgin wrote: >>>>> Do you have a "Bart Compiler Debugger" that you've created... >>>> No I've never used a debugger nor created one. >>> I could not get by without one. >> >> Using a debugger is an admission of defeat... > > > If your debugger is gdb, then I agree. :-) Irrelevant! It your code is well supported by tests, you don't need a debugger. If you find yourself wanting to use one, your tests aren't good enough! If you want to improve your coding process, work without a debugger. Better still code in a language without one (in my case, that was PHP back in the early 2000s...). > In the Windows developer environment we have the Visual Studio > Debugger. It's one of the sole reasons I use Microsoft tools for > development. Its debugger environment is unrivaled. Remote > debugging, simultaneous multi-process, multi-thread debugging, > edit-and-continue, exception handling, memory and watch windows > that handle ad hoc expressions, a Code Definition window which > tracks the text under your cursor and contextually brings up class > and struct definitions in other source files, variable definitions, > function definitions, class and struct definitions, etc. > > It's a developer's greatest asset for non-trivial development. Unit tests are a developer's greatest asset for non-trivial development. If you've ever tried to debug on a multi-threaded real time system, you'd get that! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-03-01 11:43 -0800 |
| Message-ID | <169f2756-d8ea-40a2-b020-03fb6ea5904d@googlegroups.com> |
| In reply to | #141572 |
On Friday, March 1, 2019 at 2:37:33 PM UTC-5, Ian Collins wrote: > On 02/03/2019 00:05, Rick C. Hodgin wrote: > > On Friday, March 1, 2019 at 2:19:33 AM UTC-5, Ian Collins wrote: > >> On 01/03/2019 14:54, Rick C. Hodgin wrote: > >>> I could not get by without one. > >> Using a debugger is an admission of defeat... > > If your debugger is gdb, then I agree. :-) > > Irrelevant! > > It your code is well supported by tests, you don't need a debugger. If > you find yourself wanting to use one, your tests aren't good enough! We've had this discussion before. We'll never come to agree- ment on this issue. > Unit tests are a developer's greatest asset for non-trivial development. > > If you've ever tried to debug on a multi-threaded real time system, > you'd get that! Of course, Ian. Debuggers are also still essential in my opinion, being used for new development, and maintenance. Unit tests are for validating the changes made do not break things. But when they do break things, the debugger aids you in tracking down the issue(s). Do you really need to use exclamation points? Perhaps you should relax a little. Have a cookie. :-) -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-03-02 07:20 +0000 |
| Message-ID | <slrnq7kbm1.4jo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #141575 |
On Fri, 2019-03-01, Rick C. Hodgin wrote: > On Friday, March 1, 2019 at 2:37:33 PM UTC-5, Ian Collins wrote: >> On 02/03/2019 00:05, Rick C. Hodgin wrote: >> > On Friday, March 1, 2019 at 2:19:33 AM UTC-5, Ian Collins wrote: >> >> On 01/03/2019 14:54, Rick C. Hodgin wrote: >> >>> I could not get by without one. >> >> Using a debugger is an admission of defeat... >> > If your debugger is gdb, then I agree. :-) >> >> Irrelevant! >> >> It your code is well supported by tests, you don't need a debugger. If >> you find yourself wanting to use one, your tests aren't good enough! > > We've had this discussion before. We'll never come to agree- > ment on this issue. Right. I'm with Ian, but good programmers at work think working without an IDE-integrated debugger is crazy. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-03-02 04:18 -0800 |
| Message-ID | <81f1fb1e-b0f1-43ce-8cee-f4bf2f7250c6@googlegroups.com> |
| In reply to | #141601 |
On Saturday, March 2, 2019 at 2:20:44 AM UTC-5, Jorgen Grahn wrote:
> On Fri, 2019-03-01, Rick C. Hodgin wrote:
> > On Friday, March 1, 2019 at 2:37:33 PM UTC-5, Ian Collins wrote:
> >> On 02/03/2019 00:05, Rick C. Hodgin wrote:
> >> > On Friday, March 1, 2019 at 2:19:33 AM UTC-5, Ian Collins wrote:
> >> >> On 01/03/2019 14:54, Rick C. Hodgin wrote:
> >> >>> I could not get by without one.
> >> >> Using a debugger is an admission of defeat...
> >> > If your debugger is gdb, then I agree. :-)
> >>
> >> Irrelevant!
> >>
> >> It your code is well supported by tests, you don't need a debugger. If
> >> you find yourself wanting to use one, your tests aren't good enough!
> >
> > We've had this discussion before. We'll never come to agree-
> > ment on this issue.
>
> Right. I'm with Ian, but good programmers at work think working
> without an IDE-integrated debugger is crazy.
My position against Ian's position is only that we do need debuggers
too. I agree unit testing is important, essential even, in long-
term software maintenance.
I think Ian is in a minority group saying you don't need a debugger.
I think he's also handicapping his performance (and possibly his
team's performance) by denying them use of a debugger.
We need both:
1) We need unit tests.
2) We need debuggers.
Both serve their function. Both complement one another.
When I was younger, I could keep more things in my active mind. As
I get older, it's more difficult to go that deep consistently, or
to stay there as long. As a result, I've had to shift my developer
practices slightly. I now view unit testing as essential, but I
see it as serving its own purpose, and certainly not one to replace
a debugger.
I'd be surprised to learn Ian's stated position (using a debugger
is akin to admitting defeat) is his true position.
I have known developers who do everything in their head and rarely
have any bugs in their code. I have a good track record of bug-free
code, and it's due to my "in-head analysis" coupled to testing and
also to an understanding of how to code to reduce bugs.
That being said, I have one bug that I haven't been able to track
down, but only workaround by wasting memory. It's a small component
of a large system so it's workable, but still frustrating.
I'm almost convinced I have UB somewhere due to me not understanding
that the way I've coded it is UB. I believe my own ignorance is
at work against me here, rather than a legitimate bug, and if I knew
more about C/C++ via the standard, I could see the bug in code.
Still not sure though. My most common bugs are due to dyslexia.
I think "if (x == 5)" but somehow type "if (x !=5)". Those bugs
are hard to track down because I'm not looking there. I have to
step through with a debugger to find it, and I am almost always
surprised because I draw from my memory rather than my eyes, not
even seeing the != sometimes. It's also why I view an edit-and-
continue debugger as essential, to make those kinds of changes without
requiring an app restart and full compilation cycle.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-02 12:28 +0000 |
| Message-ID | <OFueE.45932$OGY.32757@fx08.am4> |
| In reply to | #141603 |
On 02/03/2019 12:18, Rick C. Hodgin wrote: > It's also why I view an edit-and- > continue debugger as essential, to make those kinds of changes without > requiring an app restart and full compilation cycle. How long does one of your typical 'full compilation cycles' takes? How long does an app restart take? I've never worked with another programmer so I really don't know how anyone else does this stuff or how their tools stack up. I can tell you my current project takes 0.2 seconds for a full recompile, which I find mildly annoying as I can sense the delay. But it is not enough to warrant the effort needed to avoid the delay by introducing a massively complicated tool. Just the time need to press keys, move the mouse, or even think about you are doing would be longer than my rebuild time.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-03-02 05:19 -0800 |
| Message-ID | <8233da27-1d37-4c75-9b77-10fa285a0a92@googlegroups.com> |
| In reply to | #141604 |
On Saturday, March 2, 2019 at 7:28:40 AM UTC-5, Bart wrote: > On 02/03/2019 12:18, Rick C. Hodgin wrote: > > > It's also why I view an edit-and- > > continue debugger as essential, to make those kinds of changes without > > requiring an app restart and full compilation cycle. > > How long does one of your typical 'full compilation cycles' takes? > > How long does an app restart take? Two seconds, plus the 5+ seconds it takes to recompile. But it's the Nn seconds to get back in the app where the bug occurs that id the time consumer. With edit-and-continue it takes 3-10 seconds to recompile, and you are where you were able to continue. > I've never worked with another programmer so I really don't know how > anyone else does this stuff or how their tools stack up. > > I can tell you my current project takes 0.2 seconds for a full > recompile, which I find mildly annoying as I can sense the delay. But it > is not enough to warrant the effort needed to avoid the delay by > introducing a massively complicated tool. > > Just the time need to press keys, move the mouse, or even think about > you are doing would be longer than my rebuild time. We could work together on something. I could demonstrate how I do development over Teamviewer. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-02 23:47 +0000 |
| Message-ID | <XCEeE.69514$RBa.1148@fx15.am4> |
| In reply to | #141610 |
On 02/03/2019 13:19, Rick C. Hodgin wrote: > On Saturday, March 2, 2019 at 7:28:40 AM UTC-5, Bart wrote: >> On 02/03/2019 12:18, Rick C. Hodgin wrote: >> >>> It's also why I view an edit-and- >>> continue debugger as essential, to make those kinds of changes without >>> requiring an app restart and full compilation cycle. >> >> How long does one of your typical 'full compilation cycles' takes? >> >> How long does an app restart take? > > Two seconds, plus the 5+ seconds it takes to recompile. But it's > the Nn seconds to get back in the app where the bug occurs that id > the time consumer. > > With edit-and-continue it takes 3-10 seconds to recompile, and you > are where you were able to continue. So, it's still not instant. What is interesting is that it can recreate the exact same data structures as before, even though a recompilation means that the numbers, names, types and contents of those data structures could be entirely different. Even the meaning of the current program counter location could be rendered undefined. But I think this same scheme was discussed at length here a few years ago. No believed it could work then either. In my programs, recompiling then getting to the same failure point (with an aim to isolate the problem and reconstruct the bug in the simplest possible form) is part of the job of the person doing the development and testing. >> Just the time need to press keys, move the mouse, or even think about >> you are doing would be longer than my rebuild time. > > We could work together on something. What I do know is that my way of working is incompatible with anyone else, even if I was to use the same language, which I don't.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-03-02 18:24 -0800 |
| Message-ID | <e0cdbe0c-3499-45ee-bbf8-abd8c2b6fad0@googlegroups.com> |
| In reply to | #141619 |
On Saturday, March 2, 2019 at 6:48:17 PM UTC-5, Bart wrote: > On 02/03/2019 13:19, Rick C. Hodgin wrote: > > On Saturday, March 2, 2019 at 7:28:40 AM UTC-5, Bart wrote: > >> On 02/03/2019 12:18, Rick C. Hodgin wrote: > >> > >>> It's also why I view an edit-and- > >>> continue debugger as essential, to make those kinds of changes without > >>> requiring an app restart and full compilation cycle. > >> > >> How long does one of your typical 'full compilation cycles' takes? > >> > >> How long does an app restart take? > > > > Two seconds, plus the 5+ seconds it takes to recompile. But it's > > the Nn seconds to get back in the app where the bug occurs that id > > the time consumer. > > > > With edit-and-continue it takes 3-10 seconds to recompile, and you > > are where you were able to continue. > > So, it's still not instant. What is interesting is that it can recreate > the exact same data structures as before, even though a recompilation > means that the numbers, names, types and contents of those data > structures could be entirely different. Even the meaning of the current > program counter location could be rendered undefined. In those cases, edit-and-continue maintains stale code for the versions of those functions on the stack that have the old structures. Edit-and-continue is an incremental compile. Code can be changed, extended, but the ABI keeps getting bigger. New code blocks, new data blocks, maintaining both so stale code and new code work together. After the app terminates, an incremental link pass is run which culls the stale parts, resetting the ABI after editing, making it suitable for launch next time. When changes are too extensive, it forces a full recompile. > But I think this same scheme was discussed at length here a few years > ago. No believed it could work then either. > > In my programs, recompiling then getting to the same failure point (with > an aim to isolate the problem and reconstruct the bug in the simplest > possible form) is part of the job of the person doing the development > and testing. Edit-and-continue removes that step in many cases. It makes leaving a complicated environment in tact and allows ongoing editing and ex- amination of the runtime state. > >> Just the time need to press keys, move the mouse, or even think about > >> you are doing would be longer than my rebuild time. > > > > We could work together on something. > > What I do know is that my way of working is incompatible with anyone > else, even if I was to use the same language, which I don't. We learn (and grow) by doing. I'm not thinking collaboration, just an exchange of technique. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-03-02 16:02 +0100 |
| Message-ID | <m28sxx5nh3.fsf@despina.home> |
| In reply to | #141604 |
Bart <bc@freeuk.com> writes: > On 02/03/2019 12:18, Rick C. Hodgin wrote: > >> It's also why I view an edit-and- >> continue debugger as essential, to make those kinds of changes without >> requiring an app restart and full compilation cycle. > > How long does one of your typical 'full compilation cycles' takes? > > How long does an app restart take? > > I've never worked with another programmer so I really don't know how > anyone else does this stuff or how their tools stack up. > > I can tell you my current project takes 0.2 seconds for a full > recompile, which I find mildly annoying as I can sense the delay. But > it is not enough to warrant the effort needed to avoid the delay by > introducing a massively complicated tool. > > Just the time need to press keys, move the mouse, or even think about > you are doing would be longer than my rebuild time. There are builds that necessarily take more time. For example, I've worked on a sdk that took about 20 minutes to generate, process the sources (code obfuscation, etc), and compile for a single architecture on a single platform, (say, for debugging/development builds) but that needed to be compiled for 3 different platforms and 5 different architectures to run the tests on all of them, so it took one hour and a half to compile completely. Of course, using a better build system (eg. non-recursive makefiles) would have helped obtaining better compilation times, but since each platform required the use of its own build system, it was not really possible. -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-03-03 06:53 +1300 |
| Message-ID | <gdvu80F7ehsU4@mid.individual.net> |
| In reply to | #141603 |
On 03/03/2019 01:18, Rick C. Hodgin wrote: > On Saturday, March 2, 2019 at 2:20:44 AM UTC-5, Jorgen Grahn wrote: >> On Fri, 2019-03-01, Rick C. Hodgin wrote: >>> On Friday, March 1, 2019 at 2:37:33 PM UTC-5, Ian Collins wrote: >>>> On 02/03/2019 00:05, Rick C. Hodgin wrote: >>>>> On Friday, March 1, 2019 at 2:19:33 AM UTC-5, Ian Collins wrote: >>>>>> On 01/03/2019 14:54, Rick C. Hodgin wrote: >>>>>>> I could not get by without one. >>>>>> Using a debugger is an admission of defeat... >>>>> If your debugger is gdb, then I agree. :-) >>>> >>>> Irrelevant! >>>> >>>> It your code is well supported by tests, you don't need a debugger. If >>>> you find yourself wanting to use one, your tests aren't good enough! >>> >>> We've had this discussion before. We'll never come to agree- >>> ment on this issue. >> >> Right. I'm with Ian, but good programmers at work think working >> without an IDE-integrated debugger is crazy. > > My position against Ian's position is only that we do need debuggers > too. I agree unit testing is important, essential even, in long- > term software maintenance. > > I think Ian is in a minority group saying you don't need a debugger. A small minority that doesn't include me.... I was having a poke at using a debugger as a tool to develop code. Tests are no help if you get a crash dump from the field for example. But when it comes to developing new code, if you write it to pass tests and you commit little and often it is usually quicker to revert a breaking change and redo it that it is to attempt to debug the breakage. > I think he's also handicapping his performance (and possibly his > team's performance) by denying them use of a debugger. I'm not a debugger denier. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2019-03-01 07:31 +0000 |
| Subject | Yep, I'm not surprised. (Was: C is not a low level language) |
| Message-ID | <q5an4k$pg5$1@news.xmission.com> |
| In reply to | #141525 |
In article <2b698155-86eb-45f7-aaf8-caf204725ca1@googlegroups.com>, Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: ... >I place value on a debugger to such an extent that I basically >designed my entire language and compiler framework around the >basic concept of a true edit-and-continue environment, even for >runtime (optimized) code. I'm not surprised. -- Modern Conservative: Someone who can take time out from flashing her wedding ring around and bragging about her honeymoon to complain that a fellow secretary who keeps a picture of her girlfriend on her desk is "flauting her sexuality" and "forcing her lifestyle down our throats".
[toc] | [prev] | [next] | [standalone]
| From | Wes Newell <w.newell@tx.rr.com> |
|---|---|
| Date | 2019-03-01 06:13 +0000 |
| Message-ID | <q5aihq$j7q$2@dont-email.me> |
| In reply to | #141504 |
On Thu, 28 Feb 2019 11:25:50 -0800, Keith Thompson wrote: Please quit cross posting.
[toc] | [prev] | [next] | [standalone]
| From | Wes Newell <w.newell@tx.rr.com> |
|---|---|
| Date | 2019-03-01 06:11 +0000 |
| Message-ID | <q5aiea$j7q$1@dont-email.me> |
| In reply to | #141497 |
On Thu, 28 Feb 2019 16:03:39 +0000, Bill Findlay wrote: Please quit cross posting
[toc] | [prev] | [next] | [standalone]
Page 6 of 16 — ← Prev page 1 … 4 5 [6] 7 8 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web