Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #123317 > unrolled thread
| Started by | luser droog <luser.droog@gmail.com> |
|---|---|
| First post | 2017-11-22 09:39 -0800 |
| Last post | 2017-11-30 23:56 -0600 |
| Articles | 20 on this page of 276 — 37 participants |
Back to article view | Back to comp.lang.c
[computerphile] Why can't floating point do money? luser droog <luser.droog@gmail.com> - 2017-11-22 09:39 -0800
Re: [computerphile] Why can't floating point do money? "F. Russell" <fr@random.info> - 2017-11-23 13:11 +0000
Re: [computerphile] Why can't floating point do money? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-23 05:35 -0800
Re: [computerphile] Why can't floating point do money? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-11-23 13:47 +0000
Re: [computerphile] Why can't floating point do money? "F. Russell" <fr@random.info> - 2017-11-23 15:20 +0000
Re: [computerphile] Why can't floating point do money? Robert Wessel <robertwessel2@yahoo.com> - 2017-11-24 00:53 -0600
Re: [computerphile] Why can't floating point do money? supercat@casperkitty.com - 2017-11-24 14:16 -0800
Re: [computerphile] Why can't floating point do money? Robert Wessel <robertwessel2@yahoo.com> - 2017-11-24 23:50 -0600
Re: [computerphile] Why can't floating point do money? Noob <root@127.0.0.1> - 2017-11-24 09:44 +0100
Re: [computerphile] Why can't floating point do money? Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-24 09:18 -0500
Re: [computerphile] Why can't floating point do money? Noob <root@127.0.0.1> - 2017-11-29 11:50 +0100
Re: Toy code for currency handling Noob <root@127.0.0.1> - 2017-11-29 16:13 +0100
Re: Toy code for currency handling Noob <root@127.0.0.1> - 2017-11-29 16:53 +0100
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2017-11-29 10:42 -0600
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-11-29 09:25 -0800
Re: Toy code for currency handling Noob <root@127.0.0.1> - 2017-11-29 19:38 +0100
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-11-29 11:03 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-11-29 19:14 +0000
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-11-29 11:31 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2017-12-01 00:04 -0600
Re: Toy code for currency handling fr314159@gmail.com - 2017-12-01 12:41 -0800
Re: Toy code for currency handling supercat@casperkitty.com - 2017-12-01 15:24 -0800
Re: Toy code for currency handling Noob <root@127.0.0.1> - 2017-12-03 18:08 +0100
Re: Toy code for currency handling fr314159@gmail.com - 2017-12-04 10:06 -0800
Re: Toy code for currency handling jameskuyper@verizon.net - 2017-12-04 10:19 -0800
Re: Toy code for currency handling fr314159@gmail.com - 2017-12-04 11:35 -0800
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-12-04 11:56 -0800
Re: Toy code for currency handling Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-04 15:01 -0500
Re: Toy code for currency handling "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-12-05 07:14 +0100
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-05 09:18 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-05 11:31 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-05 14:13 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-05 14:39 +0000
Re: Toy code for currency handling Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-05 15:00 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-05 15:19 +0000
Re: Toy code for currency handling Melzzzzz <mel@zzzzz.com> - 2017-12-05 16:31 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-05 16:07 +0000
Re: Toy code for currency handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-06 01:25 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 02:00 +0000
Re: Toy code for currency handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-06 03:04 +0000
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2017-12-05 16:14 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-05 17:28 +0100
Re: Toy code for currency handling supercat@casperkitty.com - 2017-12-05 11:25 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-05 21:47 +0000
Re: Toy code for currency handling supercat@casperkitty.com - 2017-12-05 14:13 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-05 22:40 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-06 00:38 +0100
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-06 00:21 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 02:22 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-06 10:04 +0100
Re: Toy code for currency handling gordonb.g8o8d@burditt.org (Gordon Burditt) - 2017-12-10 21:45 -0600
Re: Toy code for currency handling supercat@casperkitty.com - 2017-12-06 08:31 -0800
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-05 16:25 +0100
Re: Toy code for currency handling already5chosen@yahoo.com - 2017-12-05 08:33 -0800
Re: Toy code for currency handling Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-05 19:09 +0000
Re: Toy code for currency handling already5chosen@yahoo.com - 2017-12-05 12:27 -0800
Re: Toy code for currency handling Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-05 20:40 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-05 16:42 +0000
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-12-05 09:39 -0800
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2017-12-05 17:52 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2017-12-06 07:59 +1300
Re: Toy code for currency handling Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-05 19:12 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-05 21:59 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-06 00:44 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 01:52 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2017-12-06 19:40 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 12:03 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-06 10:30 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 11:40 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-06 14:03 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 14:32 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-06 16:25 +0100
Re: Toy code for currency handling already5chosen@yahoo.com - 2017-12-06 07:47 -0800
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2017-12-06 16:06 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 18:08 +0000
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-12-06 11:22 -0800
Re: Toy code for currency handling supercat@casperkitty.com - 2017-12-06 09:24 -0800
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-12-06 11:23 -0800
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-12-06 11:18 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 19:59 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 20:02 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2017-12-07 09:39 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 21:36 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2017-12-07 11:15 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 23:36 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2017-12-07 12:49 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-06 23:58 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2017-12-07 13:08 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-07 01:51 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2017-12-07 14:54 +1300
Re: Toy code for currency handling Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-12-07 11:27 -0500
Re: Toy code for currency handling Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2017-12-07 03:38 +0100
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-12-06 20:39 -0800
Re: Toy code for currency handling "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-12-07 12:45 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-07 12:21 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-07 14:53 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-07 14:31 +0000
Re: Toy code for currency handling "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-12-07 15:33 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-07 14:53 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-07 14:46 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-07 20:28 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-07 20:03 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-07 22:27 +0100
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2017-12-07 22:45 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-08 00:39 +0100
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-24 03:41 -0800
Re: Toy code for currency handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-07 21:38 +0000
Re: Toy code for currency handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-07 15:24 +0000
Re: Toy code for currency handling herrmannsfeldt@gmail.com - 2017-12-11 02:17 -0800
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-12-11 08:50 -0800
Re: Toy code for currency handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-11 17:42 +0000
Re: Toy code for currency handling supercat@casperkitty.com - 2017-12-12 11:33 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2017-12-11 12:23 -0600
Re: Toy code for currency handling David Thompson <dave.thompson2@verizon.net> - 2018-01-21 11:53 -0500
Re: Toy code for currency handling supercat@casperkitty.com - 2018-01-21 11:44 -0800
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2018-01-21 12:24 -0800
Re: Toy code for currency handling herrmannsfeldt@gmail.com - 2018-01-23 21:03 -0800
Re: Toy code for currency handling Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-01-24 15:02 +0000
Re: Toy code for currency handling supercat@casperkitty.com - 2018-01-24 08:45 -0800
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2018-01-24 11:40 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-24 14:52 -0600
Re: Toy code for currency handling supercat@casperkitty.com - 2018-01-24 13:05 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-24 13:12 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-25 01:04 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-24 19:17 -0600
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-24 17:33 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-25 12:14 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 04:31 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-25 13:03 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 05:28 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 05:37 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 05:43 -0800
Re: Toy code for currency handling mark.bluemel@gmail.com - 2018-01-25 05:57 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-25 15:48 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 08:32 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 10:56 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-25 21:28 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 15:10 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 06:14 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 06:38 -0800
Re: Toy code for currency handling gordonb.ma9h0@burditt.org (Gordon Burditt) - 2018-01-24 21:53 -0600
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2018-01-25 18:05 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-25 18:16 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-26 07:30 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-25 22:08 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-26 20:00 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-26 11:31 +0000
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2018-01-26 15:51 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-26 10:32 -0600
Re: Toy code for currency handling supercat@casperkitty.com - 2018-01-26 08:50 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-26 13:11 -0600
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-26 18:32 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-26 13:07 -0600
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-27 09:43 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-26 21:44 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-27 11:02 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-27 00:46 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-28 09:19 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-27 21:19 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-27 14:14 -0800
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-28 11:21 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-27 22:32 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-28 12:16 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-28 00:44 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 04:13 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-28 13:56 +0000
Re: Toy code for currency handling Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-01-28 06:12 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 06:43 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-28 15:40 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 07:56 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-28 16:12 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 08:34 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-28 16:53 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 09:30 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 09:48 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-28 23:23 -0600
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-29 18:29 +1300
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-28 23:45 -0600
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-29 19:54 +1300
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-29 01:38 -0600
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-29 20:56 +1300
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-29 20:34 -0600
Re: Toy code for currency handling "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-01-29 21:46 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-28 23:34 -0600
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-29 12:02 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-29 12:33 +0000
Re: Toy code for currency handling Richard Damon <Richard@Damon-Family.org> - 2018-01-29 08:30 -0500
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-29 14:08 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-29 19:36 -0600
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-30 11:49 +0000
Re: Toy code for currency handling already5chosen@yahoo.com - 2018-01-30 04:45 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-30 13:04 +0000
Re: Toy code for currency handling already5chosen@yahoo.com - 2018-01-30 05:17 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-30 14:23 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-30 11:39 -0600
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-30 18:23 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-30 18:25 -0600
Re: Toy code for currency handling supercat@casperkitty.com - 2018-01-31 07:56 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-31 12:56 -0600
Re: Toy code for currency handling supercat@casperkitty.com - 2018-01-31 13:09 -0800
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2018-01-31 21:35 +0000
Re: Toy code for currency handling supercat@casperkitty.com - 2018-01-31 16:45 -0800
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2018-02-01 08:59 +0100
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-02-01 02:40 -0600
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2018-02-01 10:13 +0100
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2018-02-01 14:49 +0000
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2018-02-01 16:13 +0100
Re: Toy code for currency handling supercat@casperkitty.com - 2018-02-01 09:05 -0800
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2018-02-01 22:07 +0100
Re: Toy code for currency handling supercat@casperkitty.com - 2018-02-01 15:49 -0800
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2018-02-02 13:13 +0100
Re: Toy code for currency handling already5chosen@yahoo.com - 2018-01-30 05:30 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-30 10:48 -0600
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-29 12:59 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-29 20:26 -0600
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-29 20:36 -0600
Re: Toy code for currency handling mark.bluemel@gmail.com - 2018-01-30 00:34 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-30 11:33 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-30 11:49 -0600
Re: Toy code for currency handling jameskuyper@verizon.net - 2018-01-30 12:03 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-30 17:40 -0600
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-30 12:56 +0000
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-30 11:28 -0600
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-31 19:19 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 04:16 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-28 13:40 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 06:35 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 07:24 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-28 15:24 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-28 07:44 -0800
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-29 18:34 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-29 12:21 +0000
Re: Toy code for currency handling Ian Collins <ian-news@hotmail.com> - 2018-01-30 07:59 +1300
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-29 19:56 +0000
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2018-01-29 20:53 +0000
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-29 21:52 +0000
Re: Toy code for currency handling Richard Damon <Richard@Damon-Family.org> - 2018-01-27 18:32 -0500
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-27 13:22 -0600
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-26 13:23 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-26 13:41 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-26 14:12 -0800
Re: Toy code for currency handling bartc <bc@freeuk.com> - 2018-01-26 22:23 +0000
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-26 14:44 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-26 15:28 -0800
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-26 16:22 -0800
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2018-01-25 09:11 +0100
Re: Toy code for currency handling fir <profesor.fir@gmail.com> - 2018-01-25 02:27 -0800
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2018-01-24 15:23 -0600
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2018-01-24 14:29 -0800
Re: Toy code for currency handling supercat@casperkitty.com - 2018-01-24 14:49 -0800
Re: Toy code for currency handling supercat@casperkitty.com - 2017-12-07 07:42 -0800
Re: Toy code for currency handling herrmannsfeldt@gmail.com - 2017-12-11 02:20 -0800
Re: Toy code for currency handling gordonb.s654i@burditt.org (Gordon Burditt) - 2017-12-11 03:06 -0600
Re: Toy code for currency handling gordonb.pit4p@burditt.org (Gordon Burditt) - 2017-12-11 03:55 -0600
Re: Toy code for currency handling scott@slp53.sl.home (Scott Lurndal) - 2017-12-07 14:58 +0000
Re: Toy code for currency handling already5chosen@yahoo.com - 2017-12-06 01:45 -0800
Re: Toy code for currency handling Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-05 08:38 -0500
Re: Toy code for currency handling "James R. Kuyper" <jameskuyper@verizon.net> - 2017-12-04 15:16 -0500
Re: Toy code for currency handling asetofsymbols@gmail.com - 2017-12-05 02:56 -0800
Re: Toy code for currency handling Keith Thompson <kst-u@mib.org> - 2017-12-04 11:04 -0800
Re: Toy code for currency handling David Brown <david.brown@hesbynett.no> - 2017-12-05 09:33 +0100
Re: Toy code for currency handling Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-04 14:56 -0500
Re: Toy code for currency handling Robert Wessel <robertwessel2@yahoo.com> - 2017-12-04 20:44 -0600
Re: Toy code for currency handling herrmannsfeldt@gmail.com - 2017-12-06 21:59 -0800
Re: [computerphile] Why can't floating point do money? Robert Wessel <robertwessel2@yahoo.com> - 2017-11-29 10:51 -0600
Re: [computerphile] Why can't floating point do money? Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-30 16:18 -0500
Re: [computerphile] Why can't floating point do money? scott@slp53.sl.home (Scott Lurndal) - 2017-11-30 22:13 +0000
Re: [computerphile] Why can't floating point do money? Robert Wessel <robertwessel2@yahoo.com> - 2017-11-24 10:19 -0600
Re: [computerphile] Why can't floating point do money? Spiros Bousbouras <spibou@gmail.com> - 2017-11-24 16:43 +0000
Re: [computerphile] Why can't floating point do money? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-24 08:53 -0800
Re: [computerphile] Why can't floating point do money? bert <bert.hutchings@btinternet.com> - 2017-11-24 08:57 -0800
Re: [computerphile] Why can't floating point do money? bartc <bc@freeuk.com> - 2017-11-24 16:57 +0000
Re: [computerphile] Why can't floating point do money? Robert Wessel <robertwessel2@yahoo.com> - 2017-11-24 23:35 -0600
Re: [computerphile] Why can't floating point do money? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-11-25 05:59 +0000
Re: [computerphile] Why can't floating point do money? supercat@casperkitty.com - 2017-11-27 10:14 -0800
Re: [computerphile] Why can't floating point do money? Robert Wessel <robertwessel2@yahoo.com> - 2017-11-30 23:56 -0600
Page 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-12-05 16:14 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <cBzVB.42658$_e3.210@fx43.iad> |
| In reply to | #123854 |
bartc <bc@freeuk.com> writes: >On 05/12/2017 15:00, Melzzzzz wrote: >> On 2017-12-05, bartc <bc@freeuk.com> wrote: > >The fact is that in Linux, abc.c, abc.C, abC.c, abC.C, aBc.c, aBc.C, >aBC.c, aBC.C, Abc.c, Abc.C, AbC.c, AbC.C, ABc.c, ABc.C, ABC.c and ABC.C >are all different files, even in the same directory. /That/ is crazy. > They are all different names, why shouldn't they be all different files? Windows making filenames case insensitive is SNAFU for Windows.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-05 17:28 +0100 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <p06hg3$3nt$1@dont-email.me> |
| In reply to | #123854 |
On 05/12/17 16:19, bartc wrote: > On 05/12/2017 15:00, Melzzzzz wrote: >> On 2017-12-05, bartc <bc@freeuk.com> wrote: > >>> However, /my/ complaints about Linux are more fundamental. Like its case >>> sensitivity. >> >> Your problem with Linux is that you used to Windows naming convention. > > Which is what? > >> Put all files in lower case and no problem to move between Windows and >> Linux ;) > > If all Linux files are always lower case, they why should it matter if > the names are typed in upper case? ABC.C should be assumed to mean abc.c. > > The fact is that in Linux, abc.c, abc.C, abC.c, abC.C, aBc.c, aBc.C, > aBC.c, aBC.C, Abc.c, Abc.C, AbC.c, AbC.C, ABc.c, ABc.C, ABC.c and ABC.C > are all different files, even in the same directory. /That/ is crazy. > Windows lets you have files "file.txt", "fıle.txt", "fíle.txt", "fïle.txt", "fìle.txt", "fįle.txt", "fīle.txt", "fĩle.txt" and "fîle.txt" in the same directory. Most Windows users - at least English-speaking ones - will have no idea how to type these file names. They are certainly going to have a hard job distinguishing between them. Don't you think /that/ is crazy? Just for a laugh, you can call your malware program "file.txt.exe" with an icon to match notepad's, and at least 95% of Windows users will think it is an innocent text file. Don't you think /that/ is crazy? With a bit of effort, you can put both "file.txt" and "File.txt" in the same directory on Windows (enabling Posix on the Windows system, or using a different system to write to the NTFS disk (say, a Linux live CD). Then you end up with two files that you can see, but you can only open one of them with normal Windows programs. Don't you think /that/ is crazy? In Turkish, the capital of i is İ, and the small letter for I is ı. That means you cannot have two files "FILE.TXT" and "file.txt", even though they are different names in Turkish - but you /can/ have "FİLE.TXT" and "file.txt", and "FILE.TXT" and "fıle.txt" even though these are the same names. And how well do you think Windows handles case insensitivity of Greek or Cyrillic letters? The answer depends highly on the version of Windows and the languages it supports. Don't you think /that/ is crazy? IMHO, "crazy" is /people/ doing stupid things - not the system. Any attempt at restricting "crazy" behaviour can only limit some cases - and may also limit perfectly good behaviour. The only /consistent/ behaviour for filename characters is for the OS and the filesystem to have an absolute minimum of special characters, and to treat everything else "as is". (Having said that, I think it was a silly idea in the *nix world to make the extension .C be considered a C++ file by default. It is not the fault of the OS, of course - *nix OS's don't use file extensions. It is a case of "crazy people", not "crazy systems".) > (It's a good thing I chose an example with only four letters otherwise > this could have been a very long post.) > > The world is fortunate that Google searches are case-insensitive... > Some things are definitely best being case-insensitive. It is simply that filenames are not, IMHO, one of these things. Certainly having case sensitive file names is not a big deal.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-05 11:25 -0800 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <757c793b-e4d6-49ce-95f2-22443daae495@googlegroups.com> |
| In reply to | #123860 |
On Tuesday, December 5, 2017 at 10:29:06 AM UTC-6, David Brown wrote:
> Windows lets you have files "file.txt", "fıle.txt", "fíle.txt",
> "fïle.txt", "fìle.txt", "fįle.txt", "fīle.txt", "fĩle.txt" and
> "fîle.txt" in the same directory. Most Windows users - at least
> English-speaking ones - will have no idea how to type these file names.
> They are certainly going to have a hard job distinguishing between them.
>
> Don't you think /that/ is crazy?
Trying to use the same string both for purposes of conveying identity and
human-readable semantic content requires compromises. Strings used as
identifiers should be unambiguously readable and writable by both humans
and machines, but extended-character-set support can severely undermine
that. For programming languages that process source code (as opposed to
ones that receive code interactively from a stream), the approach I would
favor for case sensitivity would be to say that every identifier would
have a canonical form [which would, among other things, flatten both A-Z
and a-z to a-z], and defining an identifier in a particular scope would
shadow all outer-scope identifiers whose canonical form matched, *but*
code which uses identifiers would have to match the spelling precisely.
Given [in pseudo-code]
outer scope:
define X as integer
inner scope:
define x as integer
X = 23
I would suggest that there's no particular reason to believe that a
programmer definitely meant to write to the inner "x", nor that the
intention was definitely to write to the outer "X". Instead, I think
it would be better to say that a programmer wanting to access the outer
"X" must either refrain from using the inner one or indicate via some
means an intention to use the outer, while a programmer wanting to use
the inner "x" should capitalize it properly. If a language processes
code from source files, it would be fairly simple to have a tool which
could prompt the user about the intention of every place where an error
like the above occurs, thus making it easy to correct the code so as to
make the programmer's intention unambiguous.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-05 21:47 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <1uEVB.102283$9N.56488@fx30.am4> |
| In reply to | #123860 |
On 05/12/2017 16:28, David Brown wrote: > On 05/12/17 16:19, bartc wrote: >> On 05/12/2017 15:00, Melzzzzz wrote: >>> On 2017-12-05, bartc <bc@freeuk.com> wrote: >> >>>> However, /my/ complaints about Linux are more fundamental. Like its case >>>> sensitivity. >>> >>> Your problem with Linux is that you used to Windows naming convention. >> >> Which is what? >> >>> Put all files in lower case and no problem to move between Windows and >>> Linux ;) >> >> If all Linux files are always lower case, they why should it matter if >> the names are typed in upper case? ABC.C should be assumed to mean abc.c. >> >> The fact is that in Linux, abc.c, abc.C, abC.c, abC.C, aBc.c, aBc.C, >> aBC.c, aBC.C, Abc.c, Abc.C, AbC.c, AbC.C, ABc.c, ABc.C, ABC.c and ABC.C >> are all different files, even in the same directory. /That/ is crazy. >> > > Windows lets you have files "file.txt", "fıle.txt", "fíle.txt", > "fïle.txt", "fìle.txt", "fįle.txt", "fīle.txt", "fĩle.txt" and > "fîle.txt" in the same directory. Most Windows users - at least > English-speaking ones - will have no idea how to type these file names. Why would they want to? I wouldn't have any idea how to type them on /any/ system. But the people to whom they make sense, probably would. And to me, they are all visually distinct. You could have chosen better examples from Unicode where different characters have identical glyphs. But that would be a problem - for file names and identifiers in general - on /any/ system. > They are certainly going to have a hard job distinguishing between them. > > Don't you think /that/ is crazy? As crazy as mixing 1, l and I, or 0 and O, in an unsuitable font. That is not a peculiarity of Windows. > Just for a laugh, you can call your malware program "file.txt.exe" with > an icon to match notepad's, and at least 95% of Windows users will think > it is an innocent text file. > > Don't you think /that/ is crazy? What's more crazy is that on Linux, the same file "file" can be a text file or executable or pretty much anything else, because it doesn't believe in file extensions. What extensions /are/ used have been grudgingly made available because humans, for some inexplicable reason, find them useful. > With a bit of effort, you can put both "file.txt" and "File.txt" in the > same directory on Windows (enabling Posix on the Windows system, or > using a different system to write to the NTFS disk (say, a Linux live > CD). Then you end up with two files that you can see, but you can only > open one of them with normal Windows programs. > > Don't you think /that/ is crazy? I don't know how to do that. If you circumvent the OS - by using Linux - to write such files, then that's the problem of whoever tries to do that. At one time I could directly write to disk sectors to write whatever filenames I liked, and in the same way I could end up with identically named files, or filenames I could not key in. That would be /my/ fault. > In Turkish, the capital of i is İ, and the small letter for I is ı. > That means you cannot have two files "FILE.TXT" and "file.txt", even > though they are different names in Turkish - but you /can/ have > "FİLE.TXT" and "file.txt", and "FILE.TXT" and "fıle.txt" even though > these are the same names. I've heard this argument before, that we need to do away with the concept of upper and lower case versions of letters in the English simply because there exist languages or alphabets where lower and upper case don't make sense. Or ones like Turkish there are some odd exceptions. And how well do you think Windows handles > case insensitivity of Greek or Cyrillic letters? The answer depends > highly on the version of Windows and the languages it supports. > > Don't you think /that/ is crazy? I'd be quite happy for upper/lower case equivalence of letters to be limited to the A-Z and a-z of ASCII; everyone else can keep their distinctions if that's what they want. The fact is that I can write my name as bart or Bart or BART, and people will know who it was. Are you telling me that I can't do that - using English and and even without involving any sort of computer system - because in China or wherever such an upper/lower case equivalance is meaningless? I'll remember that next time I rob a bank - I can spray my full name on the wall provided I use capital letters, because the police will have no idea how to trace me! "Who's this 'BART' chap?" "Well, there's a 'Bart' listed that lives in so-and-so street." "No, it can't be him because he's 'Bart' and we want a 'BART' - quite different"! > IMHO, "crazy" is /people/ doing stupid things - not the system. Any > attempt at restricting "crazy" behaviour can only limit some cases - and > may also limit perfectly good behaviour. The only /consistent/ > behaviour for filename characters is for the OS and the filesystem to > have an absolute minimum of special characters, and to treat everything > else "as is". What drives /me/ up the wall is needing to continually think up passwords that require some mix of upper AND lower characters. What on earth does it matter? Just have a password 2 letters longer and you have one just as secure. It's bad enough trying to remember which letters are in the right case, and getting shift and caps lock right, when you can SEE what you're typing! Let me guess - case sensitive passwords were the idea of some guy used to Unix and wanted to inflict them on the entire world. > Some things are definitely best being case-insensitive. It is simply > that filenames are not, IMHO, one of these things. Certainly having > case sensitive file names is not a big deal. I can type the main part of a URL in any case. Until I get to the the "/", then everything after that is case sensitive. For God's sake, why?? The main part was already sufficient to identify this machine amongst billions, but now you need upper/lower case variations to identify one file among a few thousand? And just so any 8-letter filename can have 256 variations of /exactly the same name/? God help us. BTW, is to possible for the main URL to include "file", "fıle", "fíle", "fïle", "fìle", "fįle", "fīle", "fĩle" and "fîle" as distinct sub-sequences? If so, that is equally crazy. If not, then finally someone with some sense. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-05 14:13 -0800 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <b0e5edb2-43ff-4d95-a0d4-732fd3217a26@googlegroups.com> |
| In reply to | #123893 |
On Tuesday, December 5, 2017 at 3:47:57 PM UTC-6, Bart wrote: > On 05/12/2017 16:28, David Brown wrote: > > Windows lets you have files "file.txt", "fıle.txt", "fíle.txt", > > "fïle.txt", "fìle.txt", "fįle.txt", "fīle.txt", "fĩle.txt" and > > "fîle.txt" in the same directory. Most Windows users - at least > > English-speaking ones - will have no idea how to type these file names. > > Why would they want to? I wouldn't have any idea how to type them on > /any/ system. But the people to whom they make sense, probably would. How about when one is trying to figure out why the system can't seem to find a file with a certain name, when it seems to be right where it should be? > And to me, they are all visually distinct. You could have chosen better > examples from Unicode where different characters have identical glyphs. > But that would be a problem - for file names and identifiers in general > - on /any/ system. Only those which allow nearly-indistinguishable characters to be used within identifiers. Something like a DNS name can always be distinguished readily via observation, since the character set is quite limited. From what I understand, user agents may transliterate certain character sequences to/from non-Latin character sets, but DNS searches are actually performed using names that are entirely encoded within a small fraction of the ASCII set. > What's more crazy is that on Linux, the same file "file" can be a text > file or executable or pretty much anything else, because it doesn't > believe in file extensions. What extensions /are/ used have been > grudgingly made available because humans, for some inexplicable reason, > find them useful. Classic Macintosh users would regard both as crazy, compared with having the system store for each file a 32-bit creator-ID and a 32-bit file type. A program that needs to read text files can offer to open any file whose type is TEXT, but the system would still be able to distinguish text files created by TeachText from one created by MS-Word, or Think C, or anything else. > I can type the main part of a URL in any case. Until I get to the the > "/", then everything after that is case sensitive. For God's sake, why?? > The main part was already sufficient to identify this machine amongst > billions, but now you need upper/lower case variations to identify one > file among a few thousand? And just so any 8-letter filename can have > 256 variations of /exactly the same name/? God help us. The Standards specify that the portion to the right of the hostname will be given to the host verbatim to process as it sees fit. If a page is designed to take some supplied text and produce a graphic rendering of that text, it wouldn't make much sense to require that myFontGenerator.example.com/renderFont?text=Hello+there and myFontGenerator.example.com/renderFont?text=HELLO+THERE both return the same result (rather than having one return a picture of lowercase lettering and having the other render a picture of uppercase). The fact that the Standard allows web servers to process things in case-sensitive fashion means that upper and lower case must be passed through to those servers verbatum, but does not imply any judgment about when servers should or should not process upper- and lower-case letters differently.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-05 22:40 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <afFVB.151716$3X1.117541@fx28.am4> |
| In reply to | #123895 |
On 05/12/2017 22:13, supercat@casperkitty.com wrote: > On Tuesday, December 5, 2017 at 3:47:57 PM UTC-6, Bart wrote: >> I can type the main part of a URL in any case. Until I get to the the >> "/", then everything after that is case sensitive. For God's sake, why?? >> The main part was already sufficient to identify this machine amongst >> billions, but now you need upper/lower case variations to identify one >> file among a few thousand? And just so any 8-letter filename can have >> 256 variations of /exactly the same name/? God help us. > > The Standards specify that the portion to the right of the hostname will > be given to the host verbatim to process as it sees fit. If a page is > designed to take some supplied text and produce a graphic rendering of > that text, it wouldn't make much sense to require that > > myFontGenerator.example.com/renderFont?text=Hello+there > > and > > myFontGenerator.example.com/renderFont?text=HELLO+THERE The part after 'text=' I would classify as literal text, not a path within the local file system. For the earlier part, I don't want to have to remember whether it's RenderFont or renderfont or Renderfont or renderFont. > > both return the same result (rather than having one return a picture of > lowercase lettering and having the other render a picture of uppercase). > > The fact that the Standard allows web servers to process things in > case-sensitive fashion means that upper and lower case must be passed > through to those servers verbatum, but does not imply any judgment about > when servers should or should not process upper- and lower-case letters > differently. Fine, then it's up to the server to deal with it in a helpful fashion. BTW why IS the hostname allowed to be case-insensitive? What problem does that solve? Because many here are so brainwashed by having to use Unix for so long that they are refusing to see it as a problem. In fact, that it is somehow an advantage. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-06 00:38 +0100 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <p07alk$24h$1@dont-email.me> |
| In reply to | #123897 |
On 05/12/17 23:40, bartc wrote: > On 05/12/2017 22:13, supercat@casperkitty.com wrote: >> On Tuesday, December 5, 2017 at 3:47:57 PM UTC-6, Bart wrote: > >>> I can type the main part of a URL in any case. Until I get to the the >>> "/", then everything after that is case sensitive. For God's sake, why?? >>> The main part was already sufficient to identify this machine amongst >>> billions, but now you need upper/lower case variations to identify one >>> file among a few thousand? And just so any 8-letter filename can have >>> 256 variations of /exactly the same name/? God help us. >> >> The Standards specify that the portion to the right of the hostname will >> be given to the host verbatim to process as it sees fit. If a page is >> designed to take some supplied text and produce a graphic rendering of >> that text, it wouldn't make much sense to require that >> >> myFontGenerator.example.com/renderFont?text=Hello+there >> >> and >> >> myFontGenerator.example.com/renderFont?text=HELLO+THERE > > > The part after 'text=' I would classify as literal text, not a path > within the local file system. > Classify it that way if you want - but don't expect web servers, web browsers, or websites to follow. It is quite common to use all or part of the URL path as part of the filename path (and therefore it is logical that it be case sensitive, since almost all websites are server from *nix systems with case sensitive filesystems). But it is certainly not a requirement, and many sites handle things differently. > For the earlier part, I don't want to have to remember whether it's > RenderFont or renderfont or Renderfont or renderFont. > It does not matter what you want. It is up to the website developer - who can pick whatever case he thinks is sensible, or even allow it to be case insensitive. Of course, if the website developer does not make life easy for the users (such as by providing a link), the site will not be popular. >> > >> both return the same result (rather than having one return a picture of >> lowercase lettering and having the other render a picture of uppercase). >> >> The fact that the Standard allows web servers to process things in >> case-sensitive fashion means that upper and lower case must be passed >> through to those servers verbatum, but does not imply any judgment about >> when servers should or should not process upper- and lower-case letters >> differently. > > Fine, then it's up to the server to deal with it in a helpful fashion. > For almost all cases, all lower case works fine. No more "help" is needed. > BTW why IS the hostname allowed to be case-insensitive? What problem > does that solve? Because many here are so brainwashed by having to use > Unix for so long that they are refusing to see it as a problem. In fact, > that it is somehow an advantage. > As I said, I don't know why the hostname is case insensitive. Domain names are always ASCII (with a limited character set), so case insensitivity is easy to implement. I can't see how it is an advantage or a disadvantage - people just use lowercase letters. I suppose it is a security benefit - if you type "www.Google.com" you get to Google, without them having to register an even bigger range of domain names to avoid spoofs.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-06 00:21 +0100 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <p079ln$rt8$1@dont-email.me> |
| In reply to | #123893 |
On 05/12/17 22:47, bartc wrote: > On 05/12/2017 16:28, David Brown wrote: >> On 05/12/17 16:19, bartc wrote: >>> On 05/12/2017 15:00, Melzzzzz wrote: >>>> On 2017-12-05, bartc <bc@freeuk.com> wrote: >>> >>>>> However, /my/ complaints about Linux are more fundamental. Like its >>>>> case >>>>> sensitivity. >>>> >>>> Your problem with Linux is that you used to Windows naming convention. >>> >>> Which is what? >>> >>>> Put all files in lower case and no problem to move between Windows and >>>> Linux ;) >>> >>> If all Linux files are always lower case, they why should it matter if >>> the names are typed in upper case? ABC.C should be assumed to mean >>> abc.c. >>> >>> The fact is that in Linux, abc.c, abc.C, abC.c, abC.C, aBc.c, aBc.C, >>> aBC.c, aBC.C, Abc.c, Abc.C, AbC.c, AbC.C, ABc.c, ABc.C, ABC.c and ABC.C >>> are all different files, even in the same directory. /That/ is crazy. >>> >> >> Windows lets you have files "file.txt", "fıle.txt", "fíle.txt", >> "fïle.txt", "fìle.txt", "fįle.txt", "fīle.txt", "fĩle.txt" and >> "fîle.txt" in the same directory. Most Windows users - at least >> English-speaking ones - will have no idea how to type these file names. > > Why would they want to? Bingo! We have a winner! Now, tell us /why/ we would want to have abc.c, abc.C, abC.c, and so on. One would have to have a /very/ good reason to want to have confusingly named files in the same directory - whether that confusion is due to non-ASCII letters, differences in file case only, spelling mistakes, very long file names, or anything else that can make mistakes more likely. But it is a lot simpler to have fewer rules and assume the user is sensible, than to impose extra rules that can be inconsistent and hinder the occasional good use. > I wouldn't have any idea how to type them on > /any/ system. But the people to whom they make sense, probably would. One of the nice things about Linux is that it is easy to use accents and different letters. Obviously for the ones I use often - such as ÅØÆ in Norwegian - you type them on the keyboard in the same way as any other letter, using a Norwegian keyboard and Norwegian keyboard layout. And that works on Windows too. But sometimes you want some extra symbols or letters, even when you normally use English - naïve, touché, πr², 2×4", 37°C, ¡Español! Of course you can use the character map applet in Windows - you have those in Linux too. But it's just that little bit simpler in Linux. (Or other *nix's.) > > And to me, they are all visually distinct. You could have chosen better > examples from Unicode where different characters have identical glyphs. I could, yes - but I was picking letters that are similar. I think most people will find the names abC.C and abC.c to be of a similar distinction to file.txt and fıle.txt. > But that would be a problem - for file names and identifiers in general > - on /any/ system. It would be a problem for users. On Linux, at least, visually identical Unicode codepoints are as different as "A" and "B" to the file system - it's the codepoint that makes the difference. Windows may, perhaps, treat "A" and "Α" as being the same letter (one is the Latin letter A, the other is a Greek capital Alpha). I don't know - I haven't tried making such filenames. > >> They are certainly going to have a hard job distinguishing between >> them. >> >> Don't you think /that/ is crazy? > > As crazy as mixing 1, l and I, or 0 and O, in an unsuitable font. That > is not a peculiarity of Windows. Exactly. I agree entirely. So why single out the ability to have files with different capitalisation as "crazy", when virtually all systems allow lots of other "crazy" file names? > >> Just for a laugh, you can call your malware program "file.txt.exe" with >> an icon to match notepad's, and at least 95% of Windows users will think >> it is an innocent text file. >> >> Don't you think /that/ is crazy? > > What's more crazy is that on Linux, the same file "file" can be a text > file or executable or pretty much anything else, because it doesn't > believe in file extensions. The same file can't be a a text file or an executable or anything else - the file is what it is, regardless of what it is called. And therein lies the difference. A file is a jpeg image because it is a jpeg image file - not because of what you choose to call it. (On Windows, there are all sorts of files that are executable. Did you know that a font file is also executable?) > What extensions /are/ used have been > grudgingly made available because humans, for some inexplicable reason, > find them useful. Hey, what a novel idea! If a feature is useful for human users, let the human users use them! And if the OS doesn't need the feature, why force the /OS/ to use it? Actually, lots of programs also find file extensions to be a convenient method for identifying file types. Trying desperately to get back on topic, compilers (or compiler drivers, like gcc and clang) typically use them to identify files as C, C++, Fortran, Ada, Assembly, or whatever other languages they support - though you can always override the behaviour. > >> With a bit of effort, you can put both "file.txt" and "File.txt" in the >> same directory on Windows (enabling Posix on the Windows system, or >> using a different system to write to the NTFS disk (say, a Linux live >> CD). Then you end up with two files that you can see, but you can only >> open one of them with normal Windows programs. >> >> Don't you think /that/ is crazy? > > I don't know how to do that. If you circumvent the OS - by using Linux - > to write such files, then that's the problem of whoever tries to do > that. Windows supports Posix - it /allows/ this. But you have to enable the Posix subsystem, and you have to have appropriate tools for it (like the MS Posix utilities). > At one time I could directly write to disk sectors to write > whatever filenames I liked, and in the same way I could end up with > identically named files, or filenames I could not key in. That would be > /my/ fault. Well, indeed. (I have done that sort of thing in the past - it was fun!) > >> In Turkish, the capital of i is İ, and the small letter for I is ı. >> That means you cannot have two files "FILE.TXT" and "file.txt", even >> though they are different names in Turkish - but you /can/ have >> "FİLE.TXT" and "file.txt", and "FILE.TXT" and "fıle.txt" even though >> these are the same names. > > I've heard this argument before, that we need to do away with the > concept of upper and lower case versions of letters in the English > simply because there exist languages or alphabets where lower and upper > case don't make sense. Or ones like Turkish there are some odd exceptions. > It is not an argument for getting rid of cases (or sorting, or whatever else depends on the language). It is an argument for not having it as part of the lower levels of an OS or in a filesystem. At the user level - in programs that can handle multiple languages - you can have capitalisation, sort orders, and the like. But it does not belong in the language-neutral depths of the system. > > And how well do you think Windows handles >> case insensitivity of Greek or Cyrillic letters? The answer depends >> highly on the version of Windows and the languages it supports. >> >> Don't you think /that/ is crazy? > > I'd be quite happy for upper/lower case equivalence of letters to be > limited to the A-Z and a-z of ASCII; everyone else can keep their > distinctions if that's what they want. > As long as no one disturbs your little Anglo-centric world, you don't care about the rest of the world? > The fact is that I can write my name as bart or Bart or BART, and people > will know who it was. Are you telling me that I can't do that - using > English and and even without involving any sort of computer system - > because in China or wherever such an upper/lower case equivalance is > meaningless? All I am saying is that an OS and a filesystem should accept what you tell it. If you want a file called Bart (being your name) and a file called BART (being an abbreviation for "Bay Area Rapid Transit"), that should be /your/ choice. (I've no idea what the "Bay Area Rapid Transit" is - according to google, BART is an abbreviation for it.) > > I'll remember that next time I rob a bank - I can spray my full name on > the wall provided I use capital letters, because the police will have no > idea how to trace me! > > "Who's this 'BART' chap?" "Well, there's a 'Bart' listed that lives in > so-and-so street." "No, it can't be him because he's 'Bart' and we want > a 'BART' - quite different"! > >> IMHO, "crazy" is /people/ doing stupid things - not the system. Any >> attempt at restricting "crazy" behaviour can only limit some cases - and >> may also limit perfectly good behaviour. The only /consistent/ >> behaviour for filename characters is for the OS and the filesystem to >> have an absolute minimum of special characters, and to treat everything >> else "as is". > > What drives /me/ up the wall is needing to continually think up > passwords that require some mix of upper AND lower characters. What on > earth does it matter? Just have a password 2 letters longer and you have > one just as secure. That is a totally different concept - bearing no relation whatsoever to the topic at hand. Case sensitive passwords are more secure, /and/ easier to implement. What is not to like? A system that /requires/ letters of more than one case, and in particular, one that requires numbers and symbols, is less convenient and less secure (since it restricts your choices). But there is nothing wrong with /letting/ you have different cases in your letters. > > It's bad enough trying to remember which letters are in the right case, > and getting shift and caps lock right, when you can SEE what you're typing! > > Let me guess - case sensitive passwords were the idea of some guy used > to Unix and wanted to inflict them on the entire world. > I have no idea who thought of using case sensitive passwords. (My own guess would be that for computer passwords, case sensitive passwords were used before case insensitive ones. But that is merely a wild guess.) >> Some things are definitely best being case-insensitive. It is simply >> that filenames are not, IMHO, one of these things. Certainly having >> case sensitive file names is not a big deal. > > > I can type the main part of a URL in any case. Until I get to the the > "/", then everything after that is case sensitive. For God's sake, why?? The domain name is case insensitive (I don't know why - it makes little sense). The rest of the URL is interpreted by the web server, and it is up to the server to be case sensitive or not. You can always pretend that the domain name has to be in lower case, and then everything is nice and consistent. That's what everyone else does - most people don't even know it is possible to use capitals in URLs. > The main part was already sufficient to identify this machine amongst > billions, but now you need upper/lower case variations to identify one > file among a few thousand? And just so any 8-letter filename can have > 256 variations of /exactly the same name/? God help us. > > BTW, is to possible for the main URL to include "file", "fıle", "fíle", > "fïle", "fìle", "fįle", "fīle", "fĩle" and "fîle" as distinct > sub-sequences? If so, that is equally crazy. If not, then finally > someone with some sense. > Of course it is possible. Of course no one does it. It is a side-effect of allowing Unicode in URLs - so that non-English speakers can use URLs that suit /them/, rather than being restricted to ASCII.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-06 02:22 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <RvIVB.113156$9N.41748@fx30.am4> |
| In reply to | #123899 |
On 05/12/2017 23:21, David Brown wrote: > On 05/12/17 22:47, bartc wrote: >> Why would they want to? > > Bingo! We have a winner! > > Now, tell us /why/ we would want to have abc.c, abc.C, abC.c, and so on. I don't get you. 'ABC' and 'abc' are generally considered equivalent when used as names. They can be trivially compared to be equal if both are converted to lower or upper case before comparison. But that isn't so simple to do when you have ï and so on. (I don't know if a language that uses such a letter normally treats it like a normal 'i'. In Italian, something like à (or is it the other way) where the accent modifies the pronunciation, I would imagine it is otherwise treated like 'a', but would need normalising before compare operations.) On Windows, if I'm creating a new directory and caps lock happens to be on, I will end up typing MD ABC instead of md abc. But it doesn't matter; I can rename it later if I like to keep these things consistent. But in the meantime, I can use \abc in programs and scripts; it will still work. Or I can use \ABC; it will still work, even after I rename directory 'ABC' to 'abc'. It's just something you don't need to worry about. Unlike Linux where files can be hiding in plain sight. Suppose you had a file in a subdirectory called Renderfile, or was it renderFile? Anyway you can't remember the exact capitalisation; how are you going to find it? Don't tell me that there is a search facility that will ignore case! Why on earth would they need that? > One of the nice things about Linux is that it is easy to use accents and > different letters. Why would it be any different for Windows? The keyboards in a country usually have the same layout. And with on-screen keyboards, they can do what they like. (I've implemented keyboards on digitising tablets that had extra help for all those accents. And that worked on Windows, and also pre-Windows. Linux doesn't have a monopoly on this stuff.) > I could, yes - but I was picking letters that are similar. I think most > people will find the names abC.C and abC.c to be of a similar > distinction to file.txt and fıle.txt. No, that ı is clearly not i or I. >> What's more crazy is that on Linux, the same file "file" can be a text >> file or executable or pretty much anything else, because it doesn't >> believe in file extensions. > > The same file can't be a a text file or an executable or anything else - Obviously I mean the same file name. >>> In Turkish, the capital of i is İ, and the small letter for I is ı. >>> That means you cannot have two files "FILE.TXT" and "file.txt", even The Turkish alphabet has already been through one revolution. Perhaps it's time for another tweak, before it destroys our concept of upper and lower case. (Life would be much easier with only one case, but unfortunately upper and lower case are here to stay. In which case, it's much easier if they are interchangeable.) >> I'd be quite happy for upper/lower case equivalence of letters to be >> limited to the A-Z and a-z of ASCII; everyone else can keep their >> distinctions if that's what they want. >> > > As long as no one disturbs your little Anglo-centric world, you don't > care about the rest of the world? ASCII is special. Isn't that what is used for URL hostnames? What about email addresses? And I understand that hostnames and emails are case insensitive. Are you going to accuse whoever devised those schemes of being Anglo-centric? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-06 10:04 +0100 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <p08bqn$c5d$1@dont-email.me> |
| In reply to | #123911 |
On 06/12/17 03:22, bartc wrote: > On 05/12/2017 23:21, David Brown wrote: >> On 05/12/17 22:47, bartc wrote: > >>> Why would they want to? >> >> Bingo! We have a winner! >> >> Now, tell us /why/ we would want to have abc.c, abc.C, abC.c, and so on. > > I don't get you. You said it is fine that Windows (and Linux, for that matter) support confusingly similar filenames like "file.txt" and "fıle.txt" in the same directory - because people would not want to use them together in a confusing manner. But you think it is "crazy" that Linux allows you to have "abc.c" and "abC.c" in the same directory. The only rationale for that distinction is that you think people /would/ want to use them together in the same directory, despite confusion. So I am asking you why you think people would want to use more than one filename, differing only in case, in the same directory. If your answer is "I can't think of any reason", then there is no harm in having this feature - it can't be confusing or "crazy" if it is not used. If your answer is "People might want to...", then you can see there is a /benefit/ in having the feature. > > 'ABC' and 'abc' are generally considered equivalent when used as names. In some contexts, they can be considered the same. In other contexts, they have different meanings or at least different implementations. My name is "David". If I see "david", I assume it is a computer username, part of an email address, etc. If I see "DAVID", I assume it is some sort of official form (where everything is to be written in block capitals). "ABC" and "abc" are different to me in most situations. That does not mean I think it is a good idea to use both versions at once, except perhaps in a few unusual circumstances. It just means that - at least in the computing world - I see no problems in getting the cases consistent and knowing exactly which one I want. > They can be trivially compared to be equal if both are converted to > lower or upper case before comparison. They can - for ASCII characters and English language comparisons. > > But that isn't so simple to do when you have ï and so on. (I don't know > if a language that uses such a letter normally treats it like a normal > 'i'. In Italian, something like à (or is it the other way) where the > accent modifies the pronunciation, I would imagine it is otherwise > treated like 'a', but would need normalising before compare operations.) Different languages handle this sort of thing in different ways. They can also handle it in different ways in different contexts. In German, "ü" is sorted along with "u" in dictionaries, because it makes related words stick together. In a phone directory, "ü" is sorted with "ue", because that is an alternative transliteration for the same letter. In Norwegian, "Aaron" would come at the start of a list of names - "Aase" would come at the end, because it is a form of "Åse" and the letter "Å" is last in the Norwegian alphabet. The rules for these things are immensely complicated. The only sane way to handle them is for the low levels (like the OS kernel and filesystem) to stay completely out of the way, and for user level systems to use tools like ICU or i18n libraries. This can be part of the complete OS distribution (in Linux, these would be standard distro libraries - in Windows, you could have them as standard system libraries) to provide a consistent service to user programs. But you do /not/ want this kind of thing forming part of your filesystem! Windows moved from language-specific code pages to Unicode (or at least, UCS2) precisely to separate the filesystem from language details. I am sure MS would have preferred to avoid all the mess of cases there too, but history and compatibility are strong drivers. > > On Windows, if I'm creating a new directory and caps lock happens to be > on, I will end up typing MD ABC instead of md abc. But it doesn't > matter; I can rename it later if I like to keep these things consistent. > On Linux, if I type "MD ABC", I am told that there is no such command as "MD" and thus I am prevented from making such a mistake in the first place. > But in the meantime, I can use \abc in programs and scripts; it will > still work. Or I can use \ABC; it will still work, even after I rename > directory 'ABC' to 'abc'. > > It's just something you don't need to worry about. The "worry" is in your imagination only. I cannot recall ever hearing someone worry, fret, or otherwise complain about the case-sensitive nature of *nix filesystems. In my experience, users fall mostly into two categories regarding finding files. There are those who always use gui tools - the case is irrelevant there, because they are picking the file from a list on the screen. And there are those who at least sometimes type the names - they generally know what they are doing, and don't worry about cases either. From most Linux shells, you have "tab completion", which is a great shortcut for longer file names. It works a bit differently from the Windows method (unless you change your settings to make it Windows-like). > Unlike Linux where > files can be hiding in plain sight. Suppose you had a file in a > subdirectory called Renderfile, or was it renderFile? Anyway you can't > remember the exact capitalisation; how are you going to find it? > Um, by looking? It is the same thing if I can't remember if the directory is called "renderfile" or "renderfiles". > Don't tell me that there is a search facility that will ignore case! Why > on earth would they need that? Of course there are search facilities that ignore case - and search facilities that are case sensitive. Searching is a situation where you want both options available. > > >> One of the nice things about Linux is that it is easy to use accents >> and different letters. > > Why would it be any different for Windows? The keyboards in a country > usually have the same layout. > Ask MS. The basic keys are the same in Windows and Linux with my Norwegian keyboard and Norwegian keyboard layout. (Linux offers me 7 basic choices for the Norwegian layout, and then a range of customisations - Windows offers me 1 layout and no customisation. But the standard setup is the same.) *nix, and in particular X, have offered more flexible keyboard entry since the earliest days. So while Windows offers me a few extra symbols and accents via the Alt-Gr key, Linux offers me many more. And the *nix "compose key" must be at least 3 decades old, giving a fairly intuitive way of entering many symbols. If you want to type ½, you press compose, then 1, then 2. If you want ©, you press compose, then O, then C. If you want to write a Polish Ł you press compose, then /, then L. Obviously these sorts of letters and symbols are not something you use a lot - the common ones for your language are part of the main language-dependent keyboard layout. But they are occasionally useful, such as when telling people how naïve they are to think Windows is more user-friendly than Linux. > And with on-screen keyboards, they can do what they like. (I've > implemented keyboards on digitising tablets that had extra help for all > those accents. And that worked on Windows, and also pre-Windows. Linux > doesn't have a monopoly on this stuff.) There are many ways to handle these things. And you are right that Linux does not have a monopoly here - it merely makes it a little easier and more flexible out of the box. > >> I could, yes - but I was picking letters that are similar. I think >> most people will find the names abC.C and abC.c to be of a similar >> distinction to file.txt and fıle.txt. > > No, that ı is clearly not i or I. Well, clarity here is in the eye of the beholder. > >>> What's more crazy is that on Linux, the same file "file" can be a >>> text file or executable or pretty much anything else, because it >>> doesn't believe in file extensions. >> >> The same file can't be a a text file or an executable or anything else - > > Obviously I mean the same file name. If the file has the same name (in the same directory), it refers to the same file. > >>>> In Turkish, the capital of i is İ, and the small letter for I is ı. >>>> That means you cannot have two files "FILE.TXT" and "file.txt", even > > The Turkish alphabet has already been through one revolution. Perhaps > it's time for another tweak, before it destroys our concept of upper and > lower case. Ah, that makes sense - the Turks need another language revolution to suit the British and Americans who can't imagine anything other than English. If the Turks want to change their written language to make life easier for /them/, then fine - but I don't see why they should change to make life easier for /you/. > (Life would be much easier with only one case, but > unfortunately upper and lower case are here to stay. In which case, it's > much easier if they are interchangeable.) Perhaps we should change to using the Georgian scripts - they are all Unicase. (And the Mkhedruli script can be lovely in calligraphy.) And how do you like languages where there are different forms for the same letters, depending on things like the position in a word? Arabic has, AFAIUI, 5 different forms for its letters - even though there is only one case. > >>> I'd be quite happy for upper/lower case equivalence of letters to be >>> limited to the A-Z and a-z of ASCII; everyone else can keep their >>> distinctions if that's what they want. >>> >> >> As long as no one disturbs your little Anglo-centric world, you don't >> care about the rest of the world? > > ASCII is special. Isn't that what is used for URL hostnames? What about > email addresses? > > And I understand that hostnames and emails are case insensitive. > > Are you going to accuse whoever devised those schemes of being > Anglo-centric? > Of course they were Anglo-centric. ASCII certainly makes things easier - there is no doubt about that. It is ideal for things that are strictly computer-oriented - but not so for user-oriented text. Thus domain names and the DNS system are ASCII (with restricted choice of characters). The international domain name system lets users type and read domain names in Unicode, which is then transliterated into ASCII for DNS lookup.
[toc] | [prev] | [next] | [standalone]
| From | gordonb.g8o8d@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2017-12-10 21:45 -0600 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <mf2dnQ8A877aYrDHnZ2dnUU7-d3NnZ2d@posted.internetamerica> |
| In reply to | #123911 |
> 'ABC' and 'abc' are generally considered equivalent when used as names. > They can be trivially compared to be equal if both are converted to > lower or upper case before comparison. Converting to upper or lower case is locale-dependent. Now, what happens if you create two files that are considered unequal when compared in locale X, but a user in locale Y looking at the same drive sees two files that differ only in case. The user in locale Y has no way to access more than one of them. What determines which file that user sees when he tries to edit it? If he deletes one of the files, do both of them vanish?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-06 08:31 -0800 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <173b203a-7e02-4fd9-9dd1-9fcd79e25c94@googlegroups.com> |
| In reply to | #123899 |
On Tuesday, December 5, 2017 at 5:21:46 PM UTC-6, David Brown wrote: > The domain name is case insensitive (I don't know why - it makes little > sense). The rest of the URL is interpreted by the web server, and it is > up to the server to be case sensitive or not. You can always pretend > that the domain name has to be in lower case, and then everything is > nice and consistent. That's what everyone else does - most people don't > even know it is possible to use capitals in URLs. The domain name is required to consist entirely of characters chosen from the set "abcdefghijklmnopqrstuvwxyz-0123456789". While there would be no particular difficulty making them case-sensitive [in which case uppercase characters would simply be invalid] I think it's more useful to be able to allow camelCase to be used to make names more readable even if the actual casing is ignored. >As long as no one disturbs your little Anglo-centric world, you don't >care about the rest of the world? For *identifiers*, using a small character set is often better *for both computers and humans* than using a larger one. If the set of characters usable in identifiers is limited to those allowable in hostnames, then anyone wanting to read and write identifiers as identifiers [i.e. determine whether two of them match, or create an identifier that matches an existing one, etc.] will need to learn 37 characters, some of which may have a few significantly different representations in different fonts. While some variations would have to be simply learned (e.g. the "g" in Times-Roman is very different from the one in Helvetica), someone who sees a letter that is close to one they're familiar with could generally assume it is the same without having to worry about whether the precise shape of a particular stroke is significant. The ability to encode human readable semantic content within identifiers, e.g. being able to name variables "velocity" and "position" rather than "variable 37" and "variable 43") is useful, but even numbered variables would retain the most important part of their names' meaning: their identity. Expanding the character set may enhance the amount of semantic content that could be embedded within identifiers, but would undermine their usefulness for *identifying* things.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-05 16:25 +0100 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <p06dpv$84p$1@dont-email.me> |
| In reply to | #123852 |
On 05/12/17 15:39, bartc wrote: > On 05/12/2017 13:13, David Brown wrote: >> On 05/12/17 12:31, bartc wrote: > >>> Say you're using C. The development process might involve running a text >>> editor, C compiler, and a linker. >>> >> >> My development process usually involves an IDE (not just a text editor), >> a compiler, an assembler (usually called by the compiler driver), a >> linker, libraries, and headers. >> >> Builds are driven by make - with the process also using a range of >> utilities like sed, cp, touch, etc. (Why? Because it makes my builds >> faster, smoother, easier to maintain and better organised. My programs >> don't consist of a couple of C files - they usually consist of many >> dozens of files over several directories.) >> >> Sometimes there are additional tools or scripts involved, usually in >> Python. There is always a revision control system (like subversion or >> git). There are all sorts of tests, perhaps also simulations. There >> are debuggers, and programmers for my embedded systems. There are >> usually terminal emulators, and might be network test code or loggers. >> There is documentation - LibreOffice or LaTeX. >> >> /Real/ development processes involve vastly more than hacking out a C >> file or two with Notepad and running "gcc file1.c file2.c -o >> coolprogram.exe". > > Why makes you think /I/ have never done real development? I did not say that - I simply gave some of the things needed for serious development work, rather than just a simple one or two file C project. > My apps also > involved many dozens of files, and in pre-Windows days they included > printer drivers, plotter drivers, video drivers, mice/tablet drivers, > bitmap fonts, vector fonts, image file handlers, and message files (for > internationalisation). Plus application-specific data files (GUI icons > for example). And when you did that sort of thing, you'd need more than a text editor and a C compiler. > > Plus of course I created all my own tools, some of which were part of > the apps, so files for editors, interpreters and compilers. > Showing that you need more than a text editor and a C compiler for serious development work... > Source code included compiled programs, interpreted programs, and > command scripts. > > Did any of this demand any special features of the OS? No it didn't. It > just needed a file system. To compile everything from source was just a > matter of compiling one file after another. If the IDE didn't handle it, > then it was the simplest kind of batch file. > Some people have more advanced tools at hand - and make good use of them. I have plenty of "make.bat" or "build.bat" files in very old projects from my DOS and 16-bit Windows days. I've moved on. You /can/ build a house using tools like a hammer, a saw, a manual drill and screwdrivers. But people building something more than a playhouse or a dog kennel usually prefer nailguns, electric saws, battery-powered drills, and so on. Better tools and features may not be necessary (and sometimes they get in the way) - but usually they are a good idea if you have them. > I think what happens is that people just make use of the miscellaneous, > arcane features of an OS like Linux, so that they develop a dependency > on it. Then they have problems in working with a comparatively bare OS > like Windows, without having to import half of Linux, and that's when > they complain that Windows is so terrible to work with. > No, I think you are wrong. >> I can usually do most of this with Windows. In fact, I make a point of >> being able to replicate my builds on Windows as well as Linux. But on >> Linux, the whole process is more efficient and smoother to use - at >> least for me, as someone familiar with both systems. The big picture is >> mostly the same - I can use the same Eclipse on both systems, the same >> gcc, and I have the same *nix utilities for makefiles (via msys2 on >> Windows). > > Yeah, importing half of Linux... > You mean a selection of the GNU utilities that comes with any Linux distribution? Yes. (You can, if you prefer, get these from Microsoft.) It has always taken a bit of effort to make Windows look like a sensible OS and have the basic tools. It has always been /possible/ (at least, since NT and cygwin), and the effort involved has dropped (msys2 and mingw-64 are not hard to install). But Windows out-of-the-box simply lacks the tools needed for development work. It does not have a compiler, a usable editor, a shell, build utilities, script languages, debuggers, word processors, etc. You have to find and install all this stuff. Of course, such installation is a one-off job, and when it's there you can use it as needed. You don't get everything, but you can get most stuff. >> It is all the little things that add up, and make life >> simpler for a developer when using Linux. > > If you're used to Linux then just use that. But don't say that Windows > is so terrible because it doesn't include your favourite toys. > I say that Windows is less suited for development work for a range of reasons - including that it does not have the range of utilities that /I/ think are useful during development. > However, /my/ complaints about Linux are more fundamental. Like its case > sensitivity. > Seriously? The only time I find case sensitivity an inconvenience in Linux is when working with source code written by Windows users with inconsistent capitalisation (like having #include "Foo.h" when the file is called foo.h). And I hate such inconsistencies - even for Windows only stuff, or for languages such as Pascal that are case insensitive. I've heard a lot of complains about Linux - some reasonable and rationally justified - others less so. But I don't remember seeing case sensitivity as the number one complaint from anyone. (You might like to know that Linux is not, in itself, case sensitive - it does not care. It is filesystems that are case sensitive - and pretty much every filesystem since FAT is case sensitive. Even NTFS can be, if you access it from something other than the standard Windows tools.)
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2017-12-05 08:33 -0800 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <e9523f2e-da78-483e-8fc9-a7e2bbd03500@googlegroups.com> |
| In reply to | #123855 |
On Tuesday, December 5, 2017 at 5:25:59 PM UTC+2, David Brown wrote: > On 05/12/17 15:39, bartc wrote: > > On 05/12/2017 13:13, David Brown wrote: > >> On 05/12/17 12:31, bartc wrote: > > > >>> Say you're using C. The development process might involve running a text > >>> editor, C compiler, and a linker. > >>> > >> > >> My development process usually involves an IDE (not just a text editor), > >> a compiler, an assembler (usually called by the compiler driver), a > >> linker, libraries, and headers. > >> > >> Builds are driven by make - with the process also using a range of > >> utilities like sed, cp, touch, etc. (Why? Because it makes my builds > >> faster, smoother, easier to maintain and better organised. My programs > >> don't consist of a couple of C files - they usually consist of many > >> dozens of files over several directories.) > >> > >> Sometimes there are additional tools or scripts involved, usually in > >> Python. There is always a revision control system (like subversion or > >> git). There are all sorts of tests, perhaps also simulations. There > >> are debuggers, and programmers for my embedded systems. There are > >> usually terminal emulators, and might be network test code or loggers. > >> There is documentation - LibreOffice or LaTeX. > >> > >> /Real/ development processes involve vastly more than hacking out a C > >> file or two with Notepad and running "gcc file1.c file2.c -o > >> coolprogram.exe". > > > > Why makes you think /I/ have never done real development? > > I did not say that - I simply gave some of the things needed for serious > development work, rather than just a simple one or two file C project. > > > My apps also > > involved many dozens of files, and in pre-Windows days they included > > printer drivers, plotter drivers, video drivers, mice/tablet drivers, > > bitmap fonts, vector fonts, image file handlers, and message files (for > > internationalisation). Plus application-specific data files (GUI icons > > for example). > > And when you did that sort of thing, you'd need more than a text editor > and a C compiler. > > > > > Plus of course I created all my own tools, some of which were part of > > the apps, so files for editors, interpreters and compilers. > > > > Showing that you need more than a text editor and a C compiler for > serious development work... > > > Source code included compiled programs, interpreted programs, and > > command scripts. > > > > Did any of this demand any special features of the OS? No it didn't. It > > just needed a file system. To compile everything from source was just a > > matter of compiling one file after another. If the IDE didn't handle it, > > then it was the simplest kind of batch file. > > > > Some people have more advanced tools at hand - and make good use of them. > > I have plenty of "make.bat" or "build.bat" files in very old projects > from my DOS and 16-bit Windows days. I've moved on. > > You /can/ build a house using tools like a hammer, a saw, a manual drill > and screwdrivers. But people building something more than a playhouse > or a dog kennel usually prefer nailguns, electric saws, battery-powered > drills, and so on. Better tools and features may not be necessary (and > sometimes they get in the way) - but usually they are a good idea if you > have them. > > > I think what happens is that people just make use of the miscellaneous, > > arcane features of an OS like Linux, so that they develop a dependency > > on it. Then they have problems in working with a comparatively bare OS > > like Windows, without having to import half of Linux, and that's when > > they complain that Windows is so terrible to work with. > > > > No, I think you are wrong. > > >> I can usually do most of this with Windows. In fact, I make a point of > >> being able to replicate my builds on Windows as well as Linux. But on > >> Linux, the whole process is more efficient and smoother to use - at > >> least for me, as someone familiar with both systems. The big picture is > >> mostly the same - I can use the same Eclipse on both systems, the same > >> gcc, and I have the same *nix utilities for makefiles (via msys2 on > >> Windows). > > > > Yeah, importing half of Linux... > > > > You mean a selection of the GNU utilities that comes with any Linux > distribution? Yes. (You can, if you prefer, get these from Microsoft.) > > It has always taken a bit of effort to make Windows look like a sensible > OS and have the basic tools. It has always been /possible/ (at least, > since NT and cygwin), and the effort involved has dropped (msys2 and > mingw-64 are not hard to install). But Windows out-of-the-box simply > lacks the tools needed for development work. It does not have a > compiler, a usable editor, I personally wouldn't consider notepad "a usable editor", but some people would. Then again, there are (were) tens of thousands of people that considered vi a usable editor. And 6 or 7 that considered ed usable. > a shell, It has *two* shells out of the box. > build utilities, script languages, It has a couple - JScript and VBScript. Plus powershell language is really closer to "real" script language than to your typical shell script language. Unfortunately, a learning curve is also closer to "real" script language. > debuggers, That sounds closely related to not having built-in compiler. BTW, as far as I remember, DOS did have built-in debugger. I wonder why they decided to not provide debigger with Nt. > word processors, etc. WordPad can be considered very basic word processor. > You have to find and install all this > stuff. Of course, such installation is a one-off job, and when it's > there you can use it as needed. You don't get everything, but you can > get most stuff. > > >> It is all the little things that add up, and make life > >> simpler for a developer when using Linux. > > > > If you're used to Linux then just use that. But don't say that Windows > > is so terrible because it doesn't include your favourite toys. > > > > I say that Windows is less suited for development work for a range of > reasons - including that it does not have the range of utilities that > /I/ think are useful during development. > > > However, /my/ complaints about Linux are more fundamental. Like its case > > sensitivity. > > > > Seriously? > > The only time I find case sensitivity an inconvenience in Linux is when > working with source code written by Windows users with inconsistent > capitalisation (like having #include "Foo.h" when the file is called > foo.h). And I hate such inconsistencies - even for Windows only stuff, > or for languages such as Pascal that are case insensitive. > > > I've heard a lot of complains about Linux - some reasonable and > rationally justified - others less so. But I don't remember seeing case > sensitivity as the number one complaint from anyone. > > (You might like to know that Linux is not, in itself, case sensitive - > it does not care. It is filesystems that are case sensitive - and > pretty much every filesystem since FAT is case sensitive. Even NTFS can > be, if you access it from something other than the standard Windows tools.)
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2017-12-05 19:09 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <p06qtv$ro1$1@news.albasani.net> |
| In reply to | #123862 |
On 2017-12-05, already5chosen@yahoo.com <already5chosen@yahoo.com> wrote: > On Tuesday, December 5, 2017 at 5:25:59 PM UTC+2, David Brown wrote: >> >> It has always taken a bit of effort to make Windows look like a sensible >> OS and have the basic tools. It has always been /possible/ (at least, >> since NT and cygwin), and the effort involved has dropped (msys2 and >> mingw-64 are not hard to install). But Windows out-of-the-box simply >> lacks the tools needed for development work. It does not have a >> compiler, a usable editor, > > I personally wouldn't consider notepad "a usable editor", but some > people would. Then again, there are (were) tens of thousands of > people that considered vi a usable editor. And 6 or 7 that considered > ed usable. I hated vi back in 92 when I started to work, but now I am using vim, which is same thing after all ;) to type this message and do almost everything else ;) -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2017-12-05 12:27 -0800 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <5a9598d3-b64a-4911-946a-cc3791c4a632@googlegroups.com> |
| In reply to | #123873 |
On Tuesday, December 5, 2017 at 9:10:07 PM UTC+2, Melzzzzz wrote: > On 2017-12-05, already5chosen@yahoo.com <already5chosen@yahoo.com> wrote: > > On Tuesday, December 5, 2017 at 5:25:59 PM UTC+2, David Brown wrote: > >> > >> It has always taken a bit of effort to make Windows look like a sensible > >> OS and have the basic tools. It has always been /possible/ (at least, > >> since NT and cygwin), and the effort involved has dropped (msys2 and > >> mingw-64 are not hard to install). But Windows out-of-the-box simply > >> lacks the tools needed for development work. It does not have a > >> compiler, a usable editor, > > > > I personally wouldn't consider notepad "a usable editor", but some > > people would. Then again, there are (were) tens of thousands of > > people that considered vi a usable editor. And 6 or 7 that considered > > ed usable. > > I hated vi back in 92 when I started to work, but now I am using vim, > which is same thing after all ;) to type this message and do almost > everything else ;) > > -- > press any key to continue or any other to quit... Nah, vim is WAY saner than vi. Still, I wouldn't use vim (or Emacs) for programming unless I absolutely have to. My biggest problem with both is that using them consumes part of the same mental capacity that can be usable for programming itself.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2017-12-05 20:40 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <p0708q$flj$1@news.albasani.net> |
| In reply to | #123878 |
On 2017-12-05, already5chosen@yahoo.com <already5chosen@yahoo.com> wrote: > On Tuesday, December 5, 2017 at 9:10:07 PM UTC+2, Melzzzzz wrote: >> On 2017-12-05, already5chosen@yahoo.com <already5chosen@yahoo.com> wrote: >> > On Tuesday, December 5, 2017 at 5:25:59 PM UTC+2, David Brown wrote: >> >> >> >> It has always taken a bit of effort to make Windows look like a sensible >> >> OS and have the basic tools. It has always been /possible/ (at least, >> >> since NT and cygwin), and the effort involved has dropped (msys2 and >> >> mingw-64 are not hard to install). But Windows out-of-the-box simply >> >> lacks the tools needed for development work. It does not have a >> >> compiler, a usable editor, >> > >> > I personally wouldn't consider notepad "a usable editor", but some >> > people would. Then again, there are (were) tens of thousands of >> > people that considered vi a usable editor. And 6 or 7 that considered >> > ed usable. >> >> I hated vi back in 92 when I started to work, but now I am using vim, >> which is same thing after all ;) to type this message and do almost >> everything else ;) >> > > Nah, vim is WAY saner than vi. Still, I wouldn't use vim (or Emacs) > for programming unless I absolutely have to. My biggest problem with > both is that using them consumes part of the same mental capacity that > can be usable for programming itself. It's not problem to me ;) Once you are fine with hitting ESC constantly, that is ;) Emacs I haven't used but in 90es on VOS terminals. I don't know if this is that Emacs, or something else ;) All in all, I used joe editor before vim, and now vim and have no problems with it, so far. -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-05 16:42 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <T%zVB.97809$bN1.16118@fx14.am4> |
| In reply to | #123855 |
On 05/12/2017 15:25, David Brown wrote: > On 05/12/17 15:39, bartc wrote: >> Why makes you think /I/ have never done real development? > > I did not say that - I simply gave some of the things needed for serious > development work, rather than just a simple one or two file C project. > >> My apps also >> involved many dozens of files, and in pre-Windows days they included >> printer drivers, plotter drivers, video drivers, mice/tablet drivers, >> bitmap fonts, vector fonts, image file handlers, and message files (for >> internationalisation). Plus application-specific data files (GUI icons >> for example). > > And when you did that sort of thing, you'd need more than a text editor > and a C compiler. Well, it wasn't a C compiler, but it wouldn't have been much more than that. Most of that lot is source code or text files. Yes there might be some other utilities of the kind you just write without thinking about it. >> >> Plus of course I created all my own tools, some of which were part of >> the apps, so files for editors, interpreters and compilers. >> > > Showing that you need more than a text editor and a C compiler for > serious development work... It doesn't show that at all. > You /can/ build a house using tools like a hammer, a saw, a manual drill > and screwdrivers. But people building something more than a playhouse > or a dog kennel usually prefer nailguns, electric saws, battery-powered > drills, and so on. Better tools and features may not be necessary (and > sometimes they get in the way) - but usually they are a good idea if you > have them. When I was developing apps, the lack of tools was never the problem. Nor was waiting for a 'build'. Nor was it ever 'battling the language'. It was designing the programs, doing coding, creating and testing algorithms, dealing with user feedback, dealing with bugs, testing different bits of software. > But Windows out-of-the-box simply > lacks the tools needed for development work. It does not have a > compiler, a usable editor, a shell, build utilities, script languages, > debuggers, word processors, etc. You have to find and install all this > stuff. Perhaps I have a different view on that because the machines I first used (when I finally had a proper job) had /nothing/. And even we had that lot, they either wouldn't fit on the machine, or they would run far too slowly. I was incredibly productive time at that perhaps /because/ I didn't have those fancy tools! > (You might like to know that Linux is not, in itself, case sensitive - > it does not care. It is filesystems that are case sensitive - and > pretty much every filesystem since FAT is case sensitive. In Linux there are filenames, command options, and identifiers in C programs - what else is there? And all those are case sensitive. Probably, names in configuration files too. Which part of Linux /isn't/ case sensitive? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-05 09:39 -0800 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <ln4lp5ul9u.fsf@kst-u.example.com> |
| In reply to | #123864 |
bartc <bc@freeuk.com> writes:
[...]
> Which part of Linux /isn't/ case sensitive?
If I mount a FAT32-formatted thumb drive, it's case insensitive.
I can create a file "foo.txt" and refer to it as "FOO.TXT".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-12-05 17:52 +0000 |
| Subject | Re: Toy code for currency handling |
| Message-ID | <B1BVB.18131$7X1.903@fx08.iad> |
| In reply to | #123864 |
bartc <bc@freeuk.com> writes: >On 05/12/2017 15:25, David Brown wrote: ols! > >> (You might like to know that Linux is not, in itself, case sensitive - >> it does not care. It is filesystems that are case sensitive - and >> pretty much every filesystem since FAT is case sensitive. > >In Linux there are filenames, command options, and identifiers in C >programs - what else is there? And all those are case sensitive. Don't confuse the operating system with the distribution. The kernel itself doesn't care about case, except with respect to kernel options presented on the kernel command line by the boot agent.
[toc] | [prev] | [next] | [standalone]
Page 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web