Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.mac.system > #56833 > unrolled thread
| Started by | Ted Lee <tmplee@gmail.com> |
|---|---|
| First post | 2014-02-22 12:56 -0600 |
| Last post | 2014-03-01 21:53 +0000 |
| Articles | 20 on this page of 197 — 21 participants |
Back to article view | Back to comp.sys.mac.system
Latest IOS/OS X SSL security flaw Ted Lee <tmplee@gmail.com> - 2014-02-22 12:56 -0600
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 14:15 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 14:47 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-22 21:30 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 19:04 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 00:36 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 09:48 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 16:41 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 12:05 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 17:22 +0000
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-24 02:15 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 03:57 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 18:25 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-25 08:16 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:50 -0500
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-23 07:51 -0800
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 11:23 -0500
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-23 15:05 -0800
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 20:01 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 04:21 +0000
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-24 04:35 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 06:00 +0000
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-24 16:52 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-24 21:54 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:44 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:19 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 19:26 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:40 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 19:46 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:57 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:43 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:19 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 19:29 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:40 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 19:45 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:57 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 05:04 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 06:00 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 16:10 +0000
Re: Latest IOS/OS X SSL security flaw Kurt Ullman <kurtullman@yahoo.com> - 2014-02-24 12:15 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 22:33 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:47 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-25 13:41 +0000
Re: Latest IOS/OS X SSL security flaw Kurt Ullman <kurtullman@yahoo.com> - 2014-02-25 09:06 -0500
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-25 17:34 +0000
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-25 19:14 +0000
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-25 20:42 +0100
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-25 21:32 +0000
Re: Latest IOS/OS X SSL security flaw Ted Lee <tmplee@gmail.com> - 2014-02-25 17:12 -0600
Re: Latest IOS/OS X SSL security flaw Ted Lee <tmplee@gmail.com> - 2014-02-25 17:24 -0600
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-26 02:38 +0000
Re: Latest IOS/OS X SSL security flaw Ted Lee <tmplee@gmail.com> - 2014-02-25 21:03 -0600
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-26 04:19 +0000
Re: Latest IOS/OS X SSL security flaw "M. John Matlaw" <nouser@invalid.com> - 2014-02-28 11:29 -0500
Re: Latest IOS/OS X SSL security flaw Ted Lee <tmplee@gmail.com> - 2014-02-28 12:48 -0600
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-26 01:44 +0000
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-25 21:59 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 22:33 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 23:13 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:45 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 23:17 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 18:28 -0500
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-24 23:16 -0500
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-24 21:17 -0800
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-25 21:03 +0100
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-25 21:00 +0100
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-25 22:02 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-25 08:11 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-25 16:47 +0000
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-25 17:03 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:45 -0500
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-26 00:05 -0500
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-25 20:57 +0100
Re: Latest IOS/OS X SSL security flaw "M. John Matlaw" <nouser@invalid.com> - 2014-02-26 09:52 -0500
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-04-06 02:36 +0200
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-24 21:24 +0100
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 20:43 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:40 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 16:47 +0000
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-23 15:37 -0800
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 20:08 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 01:15 +0000
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-23 18:45 -0800
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 02:52 +0000
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-23 19:01 -0800
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 04:23 +0000
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-24 22:10 +0100
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 22:21 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:27 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:27 -0500
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-24 21:05 -0800
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:34 -0500
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-24 21:58 +0100
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 18:04 -0500
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-25 02:44 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 01:14 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 04:11 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 18:36 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-25 08:20 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-25 17:00 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-25 20:05 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-25 21:31 +0000
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-25 19:13 -0800
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-26 04:35 +0000
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-26 06:42 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-03-01 21:57 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-26 23:29 +0000
Re: Latest IOS/OS X SSL security flaw Walter Bushell <proto@panix.com> - 2014-04-13 15:06 -0400
Re: Latest IOS/OS X SSL security flaw Tom Stiller <clusterfux.upmon@gmail.com> - 2014-04-13 21:11 +0000
Re: Latest IOS/OS X SSL security flaw Walter Bushell <proto@panix.com> - 2014-04-15 17:03 -0400
Re: Latest IOS/OS X SSL security flaw Your Name <YourName@YourISP.com> - 2014-04-16 09:29 +1200
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:29 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-26 00:49 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:59 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-26 02:03 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 22:13 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-26 14:03 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-26 23:42 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-27 17:03 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-26 02:47 +0000
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-26 00:10 -0500
Re: Latest IOS/OS X SSL security flaw Walter Bushell <proto@panix.com> - 2014-04-13 15:11 -0400
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-13 15:43 -0400
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-26 02:42 +0000
Re: Latest IOS/OS X SSL security flaw Walter Bushell <proto@panix.com> - 2014-04-13 15:08 -0400
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-13 15:41 -0400
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:18 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-26 23:39 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-27 17:09 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 13:03 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-23 01:32 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 10:07 -0500
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-04-06 02:44 +0200
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-22 17:49 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 19:07 -0500
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-22 22:23 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 03:49 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 10:12 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 16:42 +0000
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 14:38 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 10:11 -0500
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 14:38 -0500
Re: Latest IOS/OS X SSL security flaw Jim Gibson <jimsgibson@gmail.com> - 2014-02-24 10:42 -0800
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-24 17:07 -0500
Re: Latest IOS/OS X SSL security flaw Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2014-02-22 23:01 -0800
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 14:38 -0500
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-24 01:46 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-03-01 21:52 +0000
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-03-02 00:05 -0500
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-24 22:24 +0100
Re: Latest IOS/OS X SSL security flaw mcarels@xs4all.nl (Maarten Carels) - 2014-02-24 10:43 +0100
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 18:39 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 19:16 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 14:18 -0500
Re: Latest IOS/OS X SSL security flaw Tim McNamara <timmcn@bitstream.net> - 2014-02-22 13:43 -0600
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 14:52 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-22 20:05 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 15:16 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-22 21:10 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 16:25 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-22 22:13 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-22 22:19 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 18:55 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-23 09:38 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 10:17 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-23 15:42 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 10:45 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-23 17:09 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 13:51 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-23 20:07 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 15:14 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 15:20 -0500
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-24 02:18 +0000
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-22 17:51 -0500
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 17:55 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-22 21:50 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 19:09 -0500
Re: Latest IOS/OS X SSL security flaw Alan Baker <alangbaker@telus.net> - 2014-02-22 12:35 -0800
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 16:59 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-22 22:14 +0000
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 17:53 -0500
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-22 18:01 -0500
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 18:22 -0500
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 18:29 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-22 23:33 +0000
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 18:23 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 01:08 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-22 21:49 +0000
Re: Latest IOS/OS X SSL security flaw Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2014-02-22 22:57 -0800
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 16:36 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 11:58 -0500
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 14:35 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 21:03 +0000
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 18:23 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 01:07 +0000
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-24 01:53 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-03-01 21:53 +0000
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-02-24 23:17 +0000 |
| Message-ID | <bn228nFrogrU2@mid.individual.net> |
| In reply to | #57013 |
On 2014-02-24, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> On 2014.02.24, 00:04 , Jolly Roger wrote:
>> On 2014-02-24, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
>>> In message <ItGdnd5-bfmfB5fOnZ2dnUVZ_qmdnZ2d@giganews.com>
>>> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>>> if bar(foo) then
>>>> begin
>>>> brat (tat);
>>>> stat (a,v)
>>>> end
>>>> else
>>>> faggetaboutit("I object!");
>>>
>>> Is how I would space that. However, that else is something I
>>> particularly dislike. That, to me, is terrible obtuse code.
>>>
>>> if bar(foo) {
>>> brat(tat);
>>> stat(a,v);
>>> } else {
>>> faggetaboutit("I object!");
>>> }
>>>
>>> That is much clearer and more concise that the code above.
>>>
>>> I don't like putting {'s on empty lines for no reason, but the last
>>> close bracket matches up the else and if showing the block has ended.
>>>
>>> That said, I can't stand writing in python because of its reliance of
>>> using white space for block control. That seems like the stupidest idea
>>> any language designer ever had.
>>
>> White space isn't the enemy. Far from it.
>
> As structure guidance for the compiler it sure is ...
Most compilers are designed to ignore white space. Hardly an enemy!
--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.
JR
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-24 18:28 -0500 |
| Message-ID | <FbWdndp-x-csSJbOnZ2dnUVZ_rednZ2d@giganews.com> |
| In reply to | #57020 |
On 2014.02.24, 18:17 , Jolly Roger wrote:
> On 2014-02-24, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> On 2014.02.24, 00:04 , Jolly Roger wrote:
>>> On 2014-02-24, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
>>>> In message <ItGdnd5-bfmfB5fOnZ2dnUVZ_qmdnZ2d@giganews.com>
>>>> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>>>> if bar(foo) then
>>>>> begin
>>>>> brat (tat);
>>>>> stat (a,v)
>>>>> end
>>>>> else
>>>>> faggetaboutit("I object!");
>>>>
>>>> Is how I would space that. However, that else is something I
>>>> particularly dislike. That, to me, is terrible obtuse code.
>>>>
>>>> if bar(foo) {
>>>> brat(tat);
>>>> stat(a,v);
>>>> } else {
>>>> faggetaboutit("I object!");
>>>> }
>>>>
>>>> That is much clearer and more concise that the code above.
>>>>
>>>> I don't like putting {'s on empty lines for no reason, but the last
>>>> close bracket matches up the else and if showing the block has ended.
>>>>
>>>> That said, I can't stand writing in python because of its reliance of
>>>> using white space for block control. That seems like the stupidest idea
>>>> any language designer ever had.
>>>
>>> White space isn't the enemy. Far from it.
>>
>> As structure guidance for the compiler it sure is ...
>
> Most compilers are designed to ignore white space. Hardly an enemy!
Exactly. What Lewis is complaining about is that the white space
influences the block control in python.
And it has its defenders ...
http://www.secnetix.de/olli/Python/block_indentation.hawk
--
Those who have reduced our privacy, whether they are state
or commercial actors, prefer that we do not reduce theirs.
- Jaron Lanier, Scientific American, 2013.11.
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2014-02-24 23:16 -0500 |
| Message-ID | <530c1925$0$61210$c3e8da3$5e5e430d@news.astraweb.com> |
| In reply to | #57024 |
On 14-02-24 18:28, Alan Browne wrote: > Exactly. What Lewis is complaining about is that the white space > influences the block control in python. Gets worse when you work on a good old terminal with white text on black background since there is no white space, only black space :-)
[toc] | [prev] | [next] | [standalone]
| From | Don Bruder <dakidd@sonic.net> |
|---|---|
| Date | 2014-02-24 21:17 -0800 |
| Message-ID | <leh91i$sa$2@dont-email.me> |
| In reply to | #57046 |
In article <530c1925$0$61210$c3e8da3$5e5e430d@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > On 14-02-24 18:28, Alan Browne wrote: > > > Exactly. What Lewis is complaining about is that the white space > > influences the block control in python. > > > Gets worse when you work on a good old terminal with white text on black > background since there is no white space, only black space :-) Quick! Somebody swat his nose with a rolled up newspaper! I'd do it myself, but my arm isn't long enough. (Next, he'll be bringing up amber monitors... :-P ) -- Security provided by Mssrs Smith and/or Wesson. Brought to you by the letter Q
[toc] | [prev] | [next] | [standalone]
| From | Paul Sture <nospam@sture.ch> |
|---|---|
| Date | 2014-02-25 21:03 +0100 |
| Message-ID | <5i9vta-au71.ln1@news.chingola.ch> |
| In reply to | #57049 |
On 2014-02-25, Don Bruder <dakidd@sonic.net> wrote: > In article <530c1925$0$61210$c3e8da3$5e5e430d@news.astraweb.com>, > JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > >> On 14-02-24 18:28, Alan Browne wrote: >> >> > Exactly. What Lewis is complaining about is that the white space >> > influences the block control in python. >> >> >> Gets worse when you work on a good old terminal with white text on black >> background since there is no white space, only black space :-) > > Quick! Somebody swat his nose with a rolled up newspaper! I'd do it > myself, but my arm isn't long enough. > > (Next, he'll be bringing up amber monitors... :-P ) Some of those were awful, but the worst combination I came across was best described as "puke on bile", and that name stuck. Fortunately we only had one of those and when the one guy who liked it left, it got "forgotten" in an office move. -- Paul Sture How many Linux users does it take to change a lightbulb? 20. 1 to change it and 19 others to install new sockets do it their own way.
[toc] | [prev] | [next] | [standalone]
| From | Paul Sture <nospam@sture.ch> |
|---|---|
| Date | 2014-02-25 21:00 +0100 |
| Message-ID | <gc9vta-au71.ln1@news.chingola.ch> |
| In reply to | #57046 |
On 2014-02-25, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > On 14-02-24 18:28, Alan Browne wrote: > >> Exactly. What Lewis is complaining about is that the white space >> influences the block control in python. > > > Gets worse when you work on a good old terminal with white text on black > background since there is no white space, only black space :-) This is where a bit of creative thinking helps. I run Terminal as black on white and iTerm as white on black, so I can choose the one appropriate for the job :-) -- Paul Sture How many Linux users does it take to change a lightbulb? 20. 1 to change it and 19 others to install new sockets do it their own way.
[toc] | [prev] | [next] | [standalone]
| From | billy@MIX.COM |
|---|---|
| Date | 2014-02-25 22:02 +0000 |
| Message-ID | <lej3tn$re7$2@reader2.panix.com> |
| In reply to | #57082 |
Paul Sture <nospam@sture.ch> writes:
> I run Terminal as black on white and iTerm as white on black, so I can
> choose the one appropriate for the job :-)
I flip back and forth - when I get tired of one, I goto (heh) the other.
Back in the good old days (of CRTs) I ran a script that'd flip everyone's
terminals to the other mode over the weekends, to combat burn-in. Worked
fairly well...
Billy Y..
--
sub #'9+1 ,r0 ; convert ascii byte
add #9.+1 ,r0 ; to an integer
bcc 20$ ; not a number
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2014-02-25 08:11 +0000 |
| Message-ID | <slrnlgok1d.1jei.g.kreme@oswin.local> |
| In reply to | #57024 |
In message <FbWdndp-x-csSJbOnZ2dnUVZ_rednZ2d@giganews.com>
Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> On 2014.02.24, 18:17 , Jolly Roger wrote:
>> On 2014-02-24, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>> On 2014.02.24, 00:04 , Jolly Roger wrote:
>>>> On 2014-02-24, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
>>>>> In message <ItGdnd5-bfmfB5fOnZ2dnUVZ_qmdnZ2d@giganews.com>
>>>>> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>>>>> if bar(foo) then
>>>>>> begin
>>>>>> brat (tat);
>>>>>> stat (a,v)
>>>>>> end
>>>>>> else
>>>>>> faggetaboutit("I object!");
>>>>>
>>>>> Is how I would space that. However, that else is something I
>>>>> particularly dislike. That, to me, is terrible obtuse code.
>>>>>
>>>>> if bar(foo) {
>>>>> brat(tat);
>>>>> stat(a,v);
>>>>> } else {
>>>>> faggetaboutit("I object!");
>>>>> }
>>>>>
>>>>> That is much clearer and more concise that the code above.
>>>>>
>>>>> I don't like putting {'s on empty lines for no reason, but the last
>>>>> close bracket matches up the else and if showing the block has ended.
>>>>>
>>>>> That said, I can't stand writing in python because of its reliance of
>>>>> using white space for block control. That seems like the stupidest idea
>>>>> any language designer ever had.
>>>>
>>>> White space isn't the enemy. Far from it.
>>>
>>> As structure guidance for the compiler it sure is ...
>>
>> Most compilers are designed to ignore white space. Hardly an enemy!
> Exactly. What Lewis is complaining about is that the white space
> influences the block control in python.
> And it has its defenders ...
> http://www.secnetix.de/olli/Python/block_indentation.hawk
Someone got a bug up their ass about having a character pair that
clearly and explicitly delimits a logical block and decided to write a
language with the sole intent of not using that character pair.
"Of course, you could resort to always use braces, no matter what, but
that's tiresome and bloats the source code, and it doesn't prevent you
from accidentally obfuscating the code by still having the wrong
indentation."
"Tiresome" and "bloats the source code" are meaningless value
statements. A single { characer is much less 'bloat' than having to
indent 16 spaces to get 4 levels deep.
To me, having explicit delimiters for a block is clear, much more clear
than simply relying on white space indentation. It's trivial to compose
a perfectly valid bit of python code where it's very difficult to see
where the logic is unless you use something >=4 spaces, and then the
code marches off the right side of the editor quite quickly (especially
if you accept the python default of *eight* spaces per tab.
On mixing tabs and spaces:
"If you move a piece of C source to an editor with different tabstops,
it will all look wrong (and possibly behave differently than it looks at
first sight)."
This last part is pure FUD. The code will NOT magically change, but if
you mix tabs and spaces in Python, the code *will* break. This is
considered a "feature". Asshats. Paste in some code from a different
file and break your program for no apparent reason. Good plan, you
numpty morons.
Don't get me started on Python, I can go on for hours on how utterly
stupid the syntax requirements are, though really, the URL you pasted is
all the evidence anyone needs.
--
There's nothing to do, so you just stay in bed [ah, poor thing] Why live
in the world when you can live in your head?
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-02-25 16:47 +0000 |
| Message-ID | <bn3vobF96u7U2@mid.individual.net> |
| In reply to | #57056 |
On 2014-02-25, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
> In message <FbWdndp-x-csSJbOnZ2dnUVZ_rednZ2d@giganews.com>
> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> On 2014.02.24, 18:17 , Jolly Roger wrote:
>>> On 2014-02-24, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>
>> Exactly. What Lewis is complaining about is that the white space
>> influences the block control in python.
>
>> And it has its defenders ...
>
>> http://www.secnetix.de/olli/Python/block_indentation.hawk
>
> Someone got a bug up their ass about having a character pair that
> clearly and explicitly delimits a logical block and decided to write a
> language with the sole intent of not using that character pair.
>
> "Of course, you could resort to always use braces, no matter what, but
> that's tiresome and bloats the source code, and it doesn't prevent you
> from accidentally obfuscating the code by still having the wrong
> indentation."
>
> "Tiresome" and "bloats the source code" are meaningless value
> statements. A single { characer is much less 'bloat' than having to
> indent 16 spaces to get 4 levels deep.
That's my take on it as well. Python seems to enjoy making a point of
being a total bitch to developers just to prove a very silly point.
> To me, having explicit delimiters for a block is clear, much more clear
> than simply relying on white space indentation. It's trivial to compose
> a perfectly valid bit of python code where it's very difficult to see
> where the logic is unless you use something >=4 spaces, and then the
> code marches off the right side of the editor quite quickly (especially
> if you accept the python default of *eight* spaces per tab.
It ain't just to you... : ) There's no getting around the fact that
Python is just plain fucking ugly and problematic in this respect.
"Oops, I forgot to indent that %$*@ section" is one of the most common
complaints during debugging sessions because of it. It's always been a
complete turn-off for me. No thanks!
> On mixing tabs and spaces:
>
> "If you move a piece of C source to an editor with different tabstops,
> it will all look wrong (and possibly behave differently than it looks at
> first sight)."
>
> This last part is pure FUD. The code will NOT magically change, but if
> you mix tabs and spaces in Python, the code *will* break. This is
> considered a "feature". Asshats. Paste in some code from a different
> file and break your program for no apparent reason. Good plan, you
> numpty morons.
I and the developers with whom I work use a variety of editors with
tabbed C, XSL, Java, and so on all the time without such manufactured
"issues". FUD indeed.
> Don't get me started on Python, I can go on for hours on how utterly
> stupid the syntax requirements are, though really, the URL you pasted is
> all the evidence anyone needs.
I generally refuse to touch Python code. I have better things to do with
my life.
--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.
JR
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2014-02-25 17:03 -0500 |
| Message-ID | <530d133a$0$47876$c3e8da3$5d8fb80f@news.astraweb.com> |
| In reply to | #57056 |
On 14-02-25 03:11, Lewis wrote:
> Someone got a bug up their ass about having a character pair that
> clearly and explicitly delimits a logical block and decided to write a
> language with the sole intent of not using that character pair.
Remember that the ASCII set has limited number of such characters on a
keyboard. You don't want to force programmers to use convoluted keyboard
manoeuvers to generate such a character.
() used to enclose arguments to a subroutine call.
[] used to enclose index to an array
so that leaves {} to enclose blocks of code as a single unit.
And they ran out for comments, so they have double characters /* and */
to open and close comments.
Heck, PASCAL on a 3270 terminal (EBCDIC) lacked [] or {}, can't remember
which and they had convoluted double character to replace it.
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-25 19:45 -0500 |
| Message-ID | <W8idnSWpdtCQpJDOnZ2dnUVZ_jSdnZ2d@giganews.com> |
| In reply to | #57088 |
On 2014.02.25, 17:03 , JF Mezei wrote:
> On 14-02-25 03:11, Lewis wrote:
>
>> Someone got a bug up their ass about having a character pair that
>> clearly and explicitly delimits a logical block and decided to write a
>> language with the sole intent of not using that character pair.
>
> Remember that the ASCII set has limited number of such characters on a
> keyboard. You don't want to force programmers to use convoluted keyboard
> manoeuvers to generate such a character.
>
> () used to enclose arguments to a subroutine call.
> [] used to enclose index to an array
>
> so that leaves {} to enclose blocks of code as a single unit.
>
> And they ran out for comments, so they have double characters /* and */
> to open and close comments.
>
>
> Heck, PASCAL on a 3270 terminal (EBCDIC) lacked [] or {}, can't remember
> which and they had convoluted double character to replace it.
In standard Pascal you enclose comments in { } or between (* *).
The later perhaps for keyboards w/o {}
In newer Pascal, such as fpc, you can use //
a := a + 1; // this is not algebra.
a := a - a; {Back where we were}
In assembler there were many variations from blank lines, to the letter
C in the first column to ; ...
FORTRAN I seem to recall ! as the beginning of a comment.
--
Those who have reduced our privacy, whether they are state
or commercial actors, prefer that we do not reduce theirs.
- Jaron Lanier, Scientific American, 2013.11.
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2014-02-26 00:05 -0500 |
| Message-ID | <530d7624$0$59826$c3e8da3$e074e489@news.astraweb.com> |
| In reply to | #57099 |
On 14-02-25 19:45, Alan Browne wrote:
> In standard Pascal you enclose comments in { } or between (* *).
> The later perhaps for keyboards w/o {}
That was it. But for IBM systems, it wasn't the lack of {} on a
keyboard, it was the lack of {} in the EBCDIC character set.
[toc] | [prev] | [next] | [standalone]
| From | Paul Sture <nospam@sture.ch> |
|---|---|
| Date | 2014-02-25 20:57 +0100 |
| Message-ID | <279vta-au71.ln1@news.chingola.ch> |
| In reply to | #57020 |
On 2014-02-24, Jolly Roger <jollyroger@pobox.com> wrote:
> On 2014-02-24, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> On 2014.02.24, 00:04 , Jolly Roger wrote:
>>>
>>> White space isn't the enemy. Far from it.
>>
>> As structure guidance for the compiler it sure is ...
>
> Most compilers are designed to ignore white space. Hardly an enemy!
Dunno about modern FORTRAN, but the compilers I used stripped all the
non-quoted spaces from source lines before parsing them.
unlike the syntax of various other languages the delimiters and numeric
labels mean this can be done e.g.
if (a .eq. b) x = y
if (i .gt. j) goto 9999
--
Paul Sture
How many Linux users does it take to change a lightbulb? 20. 1 to change it
and 19 others to install new sockets do it their own way.
[toc] | [prev] | [next] | [standalone]
| From | "M. John Matlaw" <nouser@invalid.com> |
|---|---|
| Date | 2014-02-26 09:52 -0500 |
| Message-ID | <lekv2m$rgc$1@dont-email.me> |
| In reply to | #57081 |
On 2/25/14, 2:57 PM, Paul Sture wrote: > Paul Sture > > How many Linux users does it take to change a lightbulb? 20. 1 to change it > and 19 others to install new sockets do it their own way. A funny sig but I think it's missing a "to" and 19 others to install new sockets "to" do it their own way.
[toc] | [prev] | [next] | [standalone]
| From | Paul Sture <nospam@sture.ch> |
|---|---|
| Date | 2014-04-06 02:36 +0200 |
| Message-ID | <h5k61b-agd.ln1@news.chingola.ch> |
| In reply to | #57133 |
On 2014-02-26, M. John Matlaw <nouser@invalid.com> wrote: > On 2/25/14, 2:57 PM, Paul Sture wrote: >> Paul Sture >> >> How many Linux users does it take to change a lightbulb? 20. 1 to change it >> and 19 others to install new sockets do it their own way. > A funny sig but I think it's missing a "to" > > and 19 others to install new sockets "to" do it their own way. Thanks for the correction. -- Paul Sture "In that case," said Napoleon, "let us wait twenty minutes; when the enemy is making a false movement we must take good care not to interrupt him."
[toc] | [prev] | [next] | [standalone]
| From | Paul Sture <nospam@sture.ch> |
|---|---|
| Date | 2014-02-24 21:24 +0100 |
| Message-ID | <ucmsta-3361.ln1@news.chingola.ch> |
| In reply to | #56947 |
On 2014-02-24, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
> In message <ItGdnd5-bfmfB5fOnZ2dnUVZ_qmdnZ2d@giganews.com>
> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> if bar(foo) then
>> begin
>> brat (tat);
>> stat (a,v)
>> end
>> else
>> faggetaboutit("I object!");
>
> Is how I would space that. However, that else is something I
> particularly dislike. That, to me, is terrible obtuse code.
>
> if bar(foo) {
> brat(tat);
> stat(a,v);
> } else {
> faggetaboutit("I object!");
> }
>
> That is much clearer and more concise that the code above.
but to me that } else { looks "too busy", by which I mean I have to stop
and think what belongs where. I prefer indenting by more than 2 spaces
at a time as well. but I come from a COBOL/FORTRAN environment where we
used the "tab source format" available in the DEC compilers, where tab
stops were at columns 9, 17, 25... I would typically only drop to 4
spaces when dealing with enough levels of indentation to make fitting
it all into <80 characters on a dumb terminal, and that habit stuck for
many years after I started using X11.
> I don't like putting {'s on empty lines for no reason, but the last
> close bracket matches up the else and if showing the block has ended.
>
> That said, I can't stand writing in python because of its reliance of
> using white space for block control. That seems like the stupidest idea
> any language designer ever had.
If I'm using BBEdit for python I set tabs to be 4 spaces and switch on
the vertical tab stops. Getting things aligned is dead easy with that.
--
Paul Sture
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-02-24 20:43 +0000 |
| Message-ID | <bn1p7oFpphcU1@mid.individual.net> |
| In reply to | #56979 |
On 2014-02-24, Paul Sture <nospam@sture.ch> wrote:
> On 2014-02-24, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
>> In message <ItGdnd5-bfmfB5fOnZ2dnUVZ_qmdnZ2d@giganews.com>
>> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>> if bar(foo) then
>>> begin
>>> brat (tat);
>>> stat (a,v)
>>> end
>>> else
>>> faggetaboutit("I object!");
>>
>> Is how I would space that. However, that else is something I
>> particularly dislike. That, to me, is terrible obtuse code.
>>
>> if bar(foo) {
>> brat(tat);
>> stat(a,v);
>> } else {
>> faggetaboutit("I object!");
>> }
>>
>> That is much clearer and more concise that the code above.
>
> but to me that } else { looks "too busy", by which I mean I have to stop
> and think what belongs where.
if
{
foo = bar;
}
else
{
bar = foo;
}
Is just easier to scan, which is why I prefer it, personally. White
space isn't the enemy. Code that is easier to scan and read is code that
is easier to maintain.
> I prefer indenting by more than 2 spaces at a time as well. but I come
> from a COBOL/FORTRAN environment where we used the "tab source format"
> available in the DEC compilers, where tab stops were at columns 9, 17,
> 25... I would typically only drop to 4 spaces when dealing with
> enough levels of indentation to make fitting it all into <80
> characters on a dumb terminal, and that habit stuck for many years
> after I started using X11.
I *always* use tab characters for indents, because tab spacing can be
adjusted to your own individual preferences.
--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.
JR
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-24 17:40 -0500 |
| Message-ID | <Ls-dnXM1lJPtV5bOnZ2dnUVZ_oOdnZ2d@giganews.com> |
| In reply to | #56947 |
On 2014.02.23, 23:21 , Lewis wrote:
> In message <ItGdnd5-bfmfB5fOnZ2dnUVZ_qmdnZ2d@giganews.com>
> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> if bar(foo) then
>> begin
>> brat (tat);
>> stat (a,v)
>> end
>> else
>> faggetaboutit("I object!");
>
> Is how I would space that. However, that else is something I
> particularly dislike. That, to me, is terrible obtuse code.
>
> if bar(foo) {
> brat(tat);
> stat(a,v);
> } else {
> faggetaboutit("I object!");
> }
>
> That is much clearer and more concise that the code above.
To you, perhaps. To me the curlies are just an awful, ugly way to mark
code blocks. Of course in Pascal (etc) you can also use
BEGIN
Begin
End;
END;
>
> I don't like putting {'s on empty lines for no reason, but the last
> close bracket matches up the else and if showing the block has ended.
My note above refers. Though on re-look I would have moved everything
below the if line (in my block) in a couple more spaces.
> That said, I can't stand writing in python because of its reliance of
> using white space for block control. That seems like the stupidest idea
> any language designer ever had.
Does it really? Ouch.
--
... it may be that "in the cloud" really isn't the best term
for the services these companies offer. What they really
want is to have us "on the leash."
-David Pogue, Scientific American, 2014.02
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-02-23 16:47 +0000 |
| Message-ID | <bmun0vF59p1U4@mid.individual.net> |
| In reply to | #56895 |
On 2014-02-23, Don Bruder <dakidd@sonic.net> wrote:
> In article <bmsu50Fnr6sU2@mid.individual.net>,
> Jolly Roger <jollyroger@pobox.com> wrote:
>
>> On 2014-02-23, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> > On 2014.02.22, 16:30 , Jolly Roger wrote:
>> >> On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> >>> On 2014.02.22, 14:15 , nospam wrote:
>> >>>> In article <lears8$l8d$1@dont-email.me>, Ted Lee
>> >>>> <tmplee@gmail.com> wrote:
>> >>>>
>> >>>>> The press and gossip rag reports say the recently discovered
>> >>>>> security flaw with SSL is present in both IOS and OS X. The
>> >>>>> patch for IOS showed up last night. The reports say the OS X
>> >>>>> one will be out soon. Has anyone run across a technically
>> >>>>> competent (as opposed to sensationalized fear-mongering amateur
>> >>>>> drivel) discussion of the flaw *and* a conclusive statement
>> >>>>> that it is indeed present in OS X?
>> >>>>
>> >>>> it is in os x, and it's nothing more than an extra goto.
>> >>>>
>> >>>> <https://www.imperialviolet.org/2014/02/22/applebug.html>
>> >>>
>> >>> ROFL.
>> >>>
>> >>> goto has always been a source of low software quality - and it
>> >>> rears its head again here - although it looks more like sloppy
>> >>> editing than anything else - like another line of condition code
>> >>> had been deleted or moved.
>> >>
>> >> Indeed. And as John Gruber (Daring Fireball) asserted, the
>> >> practice of using curly braces for if blocks would have made the
>> >> slip-up much more obvious. I tend to prefer using braces in if
>> >> blocks myself.
>
> I tend toward "overkill unto the verge of paranoia" when bracing
> conditionals, for exactly that reason. Even though I'm quite aware
> that "if (foo) bar(foo);" is perfectly valid code that'll compile
> without so much as a hiccup, if I'm coding something that needs that
> sort of construct, I'm most likely going to write it as
> if (foo)
> {
> bar(foo);
> }
> else
> {
> // It's a bad idea to bar() a nil foo
> }
> specifically to negate even the possibility of getting bit by that
> type of bug. Vertical space is cheap insurance :)
Indeed! Like minds, there! (Only difference I tend not to indent th
braces themselves.) Not everyone has the discipline or interest to do
this. I am often praised for my code cleanliness and readability by
others. So there are obviously other benefits to adhering to strict best
practices like this.
>> > I tend to think curly braces suck as code block begin/ends. ;-)
>> >
>> > {This was esp. so with dot matrix printers. We didn't have no
>> > fancy colour editors either}
>> >
>> > What the hell is the matter with nice fat, 0 code producing BEGIN
>> > END statements, anyway?
>> >
>> > Ada. Ah, Ada, why have you forsaken us and let C rule?
>>
>> Right there with you. : ) I can appreciate shortened forms; but not
>> so much when they increase the likelihood of mistakes like this.
>> Pascal had BEGIN/END too.
>
> What? Never heard of
> #define BEGIN {
> #define END }
> ?
> :)
>
> Years ago, those, and other similar "translation" macros, were exactly
> how I transitioned from Pascal to C. Then one day I noticed that the C
> must have "kicked in" - I'd been using "naked" C and forgetting to
> bother setting up or #include-ing the #defines for a while without
> even realizing it.
Haha! I did similar things during my transition! : D I'm glad I cut my
teeth on Pascal before moving to C/C++. I think it gave me an
appreciation for structure that I otherwise might not have attained.
--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.
JR
[toc] | [prev] | [next] | [standalone]
| From | Don Bruder <dakidd@sonic.net> |
|---|---|
| Date | 2014-02-23 15:37 -0800 |
| Message-ID | <lee0o1$p6s$2@dont-email.me> |
| In reply to | #56901 |
In article <bmun0vF59p1U4@mid.individual.net>,
Jolly Roger <jollyroger@pobox.com> wrote:
> On 2014-02-23, Don Bruder <dakidd@sonic.net> wrote:
> > In article <bmsu50Fnr6sU2@mid.individual.net>,
> > Jolly Roger <jollyroger@pobox.com> wrote:
> >
> >> On 2014-02-23, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> >> > On 2014.02.22, 16:30 , Jolly Roger wrote:
> >> >> On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> >> >>> On 2014.02.22, 14:15 , nospam wrote:
> >> >>>> In article <lears8$l8d$1@dont-email.me>, Ted Lee
> >> >>>> <tmplee@gmail.com> wrote:
> >> >>>>
> >> >>>>> The press and gossip rag reports say the recently discovered
> >> >>>>> security flaw with SSL is present in both IOS and OS X. The
> >> >>>>> patch for IOS showed up last night. The reports say the OS X
> >> >>>>> one will be out soon. Has anyone run across a technically
> >> >>>>> competent (as opposed to sensationalized fear-mongering amateur
> >> >>>>> drivel) discussion of the flaw *and* a conclusive statement
> >> >>>>> that it is indeed present in OS X?
> >> >>>>
> >> >>>> it is in os x, and it's nothing more than an extra goto.
> >> >>>>
> >> >>>> <https://www.imperialviolet.org/2014/02/22/applebug.html>
> >> >>>
> >> >>> ROFL.
> >> >>>
> >> >>> goto has always been a source of low software quality - and it
> >> >>> rears its head again here - although it looks more like sloppy
> >> >>> editing than anything else - like another line of condition code
> >> >>> had been deleted or moved.
> >> >>
> >> >> Indeed. And as John Gruber (Daring Fireball) asserted, the
> >> >> practice of using curly braces for if blocks would have made the
> >> >> slip-up much more obvious. I tend to prefer using braces in if
> >> >> blocks myself.
> >
> > I tend toward "overkill unto the verge of paranoia" when bracing
> > conditionals, for exactly that reason. Even though I'm quite aware
> > that "if (foo) bar(foo);" is perfectly valid code that'll compile
> > without so much as a hiccup, if I'm coding something that needs that
> > sort of construct, I'm most likely going to write it as
> > if (foo)
> > {
> > bar(foo);
> > }
> > else
> > {
> > // It's a bad idea to bar() a nil foo
> > }
> > specifically to negate even the possibility of getting bit by that
> > type of bug. Vertical space is cheap insurance :)
>
> Indeed! Like minds, there! (Only difference I tend not to indent th
> braces themselves.)
That's at least partly the product of the ridicule I took from the
instructor when I turned in my first project in my first formal Pascal
class - I didn't believe in indenting - PERIOD! So imagine 100 lines or
so of Pascal without so much as a single indent to be seen *ANYWHERE*.
After that, I started indenting every damned thing under the sun. Over
time, I fell back to an indenting policy that's at least A LITTLE saner.
:)
I couldn't help it - I was a roughly 16 year old self-taught "computer
expert" who cut his programming teeth on a mix of TRS-80 Level I BASIC,
Integer (and later Applesoft) BASIC, Z80 *MACHINE LANGUAGE* (not
"assembler" - We're talking pure hex bytes arrived at through laborious
lookups in the back of the book), 8080 assembler created by
hand-translating pencil-and-paper source into hex and then punching it
into the old MS-DOS DEBUG.COM program a byte at a time) and 6502
assembler (using, at first, nothing but the built-in "mini-assembler" on
the Apple II, eventually moving to the "LISA" assembler, and finally
Merlin-Pro)
--
Security provided by Mssrs Smith and/or Wesson. Brought to you by the letter Q
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.sys.mac.system
csiph-web