Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.alt.folklore.computer > #51954 > unrolled thread

Pascal auf Nr. 10 ;-)

Started by"F. W." <me@home.invalid>
First post2025-09-04 10:26 +0200
Last post2025-09-12 11:47 +0200
Articles 20 on this page of 187 — 17 participants

Back to article view | Back to de.alt.folklore.computer

Contents

  Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-04 10:26 +0200
    Re: Pascal auf Nr. 10 ;-) Andreas Bockelmann <xotzil@gmx.de> - 2025-09-04 11:41 +0200
      Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-04 15:14 +0200
        Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-04 17:07 +0200
          Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-09-04 16:12 +0000
            Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-04 19:19 +0200
              Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 08:22 +0200
                Re: Pascal auf Nr. 10 ;-) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-09-05 06:41 +0000
                  Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 08:55 +0200
                    Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-05 11:41 +0200
                      Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 11:48 +0200
                    Re: Pascal auf Nr. 10 ;-) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-09-05 10:27 +0000
                      Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 09:54 +0200
                        Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-08 10:33 +0200
                          Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 11:14 +0200
                            Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-08 19:48 +0200
                              Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 07:38 +0200
                        Re: Pascal auf Nr. 10 ;-) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-09-09 08:52 +0000
                          Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 12:01 +0200
                            Re: Pascal auf Nr. 10 ;-) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-09-09 12:27 +0000
                              Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 15:04 +0200
                    Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-09-05 14:31 +0000
                      Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-05 17:24 +0200
                      Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-05 17:25 +0200
                        Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-11 17:15 +0000
                          Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-12 03:19 +0200
                      Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 09:56 +0200
                        Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-08 10:45 +0200
            Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-04 19:45 +0200
              Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 08:27 +0200
                Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-05 10:09 +0200
                Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-05 11:50 +0200
                  Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 07:08 +0200
                    Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-08 10:50 +0200
                      Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 11:16 +0200
                        Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-08 17:32 +0200
                        Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-08 18:27 +0200
                          Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 07:23 +0200
                            Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-09 18:48 +0200
                              Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-11 13:34 +0200
                                Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-11 19:09 +0200
                                  Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-12 08:59 +0200
                                    Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-12 09:41 +0200
                                    Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-12 16:20 +0200
                    Re: Pascal auf Nr. 10 ;-) Andreas Karrer <ak-5a@gmx.ch> - 2025-09-08 09:55 +0000
                      Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 16:57 +0200
                        Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-08 17:34 +0200
                          Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 07:24 +0200
                            Re: Pascal auf Nr. 10 ;-) Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-09 09:07 +0200
                              Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 10:16 +0200
                                Re: Pascal auf Nr. 10 ;-) Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-09 13:29 +0200
                                  Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 15:13 +0200
                    Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-08 19:06 +0200
                      Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-09 04:43 +0200
                        Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 07:29 +0200
                      Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 07:28 +0200
                        Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-09 19:26 +0200
                          Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-10 14:21 +0200
                            Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-10 18:11 +0200
                              Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-11 07:20 +0200
                                Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-11 08:15 +0200
                                Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-11 18:56 +0200
                                  Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-12 07:27 +0200
                                    Re: Pascal auf Nr. 10 ;-) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-09-12 07:21 +0000
                                      Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-12 11:38 +0200
                                        Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-12 15:51 +0200
                                    Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-12 15:47 +0200
                                      Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-15 07:16 +0200
                                      Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-15 09:02 +0200
                                        Re: Pascal auf Nr. 10 ;-) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-09-15 07:49 +0000
                                          Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-15 12:25 +0200
                                            Re: Pascal auf Nr. 10 ;-) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-09-15 12:28 +0000
                                              Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-15 19:17 +0200
                        Re: Pascal auf Nr. 10 ;-) Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-11 09:46 +0200
                          Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-11 10:38 +0200
              Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-05 11:45 +0200
                Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-05 17:14 +0200
                  Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 10:58 +0200
                    Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-06 12:23 +0200
                      Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 12:35 +0200
                        Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-06 14:40 +0200
                          Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 15:01 +0200
                      Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-09-06 11:41 +0000
                        Re: Pascal auf Nr. 10 ;-) Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-06 14:20 +0200
                          Re: Pascal auf Nr. 10 ;-) Alexander Schreiber <als@usenet.thangorodrim.de> - 2025-09-06 21:56 +0200
                        Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-06 15:58 +0200
                        Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-07 19:09 +0200
                      Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-06 14:12 +0200
                        Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 14:16 +0200
                      Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-12 09:04 +0200
                        Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-12 10:26 +0200
                    Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-09-06 11:26 +0000
                      Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 13:39 +0200
                    Re: Pascal auf Nr. 10 ;-) Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-06 14:19 +0200
                      Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 14:34 +0200
                  Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 11:40 +0200
                    Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-06 13:59 +0200
                      Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 14:02 +0200
                        Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-06 15:17 +0200
                          Re: Pascal auf Nr. 10 ;-) Eric Bruecklmeier <u@5i7.de> - 2025-09-06 15:36 +0200
            Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 08:18 +0200
              Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-05 08:41 +0200
                Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 08:56 +0200
                Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-12 05:51 +0000
                  Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-12 15:59 +0200
                    Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-12 15:12 +0000
            Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 08:19 +0200
          Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-04 18:55 +0200
            Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 08:33 +0200
              Re: Pascal auf Nr. 10 ;-) Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-05 09:12 +0200
                Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 11:52 +0200
                  Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-05 13:48 +0200
                    Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 07:17 +0200
                      Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-08 19:33 +0200
                  Re: Pascal auf Nr. 10 ;-) Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-05 14:52 +0200
                    Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 07:22 +0200
                      Re: Pascal auf Nr. 10 ;-) Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-08 08:55 +0200
                Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-12 06:06 +0000
                  Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-12 08:56 +0200
                  Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-12 16:17 +0200
                    Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-12 15:13 +0000
                    Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-12 18:13 +0200
                      Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-12 20:27 +0200
                        Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-12 21:58 +0000
                          Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-13 00:13 +0200
                            Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-13 09:07 +0000
                              Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-13 13:47 +0200
                                Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-14 12:14 +0200
                                  Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-15 20:22 +0200
                                    Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-16 06:51 +0200
                                      Re: Pascal auf Nr. 10 ;-) Andreas Eder <a_eder_muc@web.de> - 2025-10-03 11:08 +0200
                                        Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-10-03 13:17 +0200
                                          Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-10-03 13:48 +0000
                                            Re: Pascal auf Nr. 10 ;-) Andreas Eder <a_eder_muc@web.de> - 2025-10-04 12:57 +0200
                                          Re: Pascal auf Nr. 10 ;-) Andreas Eder <a_eder_muc@web.de> - 2025-10-04 12:44 +0200
                                            Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-10-04 17:34 +0200
                                        Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-10-03 16:30 +0200
                                          Re: Pascal auf Nr. 10 ;-) Christian Weisgerber <naddy@mips.inka.de> - 2025-10-05 21:35 +0000
                                            Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-10-06 08:29 +0200
                                            Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-10-06 19:07 +0200
                                              Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-10-06 19:18 +0000
                                                Re: Pascal auf Nr. 10 ;-) Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-10-07 08:15 +0000
                                                  Re: Pascal auf Nr. 10 ;-) Christian Corti <use@reply.to> - 2025-10-07 14:46 +0200
                                                    Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-10-07 17:32 +0200
                                                Re: Editor (was: Pascal auf Nr. 10 ;-) ) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-10-07 14:53 +0200
                                                Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-10-07 18:38 +0200
                                                  Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-10-08 14:17 +0000
                                                    Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-10-08 19:18 +0200
                                                      Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-10-08 17:57 +0000
                                                        Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-10-09 17:55 +0200
                                                          Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-10-09 19:47 +0000
                                    Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-16 18:34 +0200
                                      Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-16 16:58 +0000
                                      Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-16 21:12 +0200
                                        Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-17 17:52 +0200
                        Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-13 10:07 +0200
                        Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-13 10:34 +0200
                          Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-13 13:34 +0200
              Re: Pascal auf Nr. 10 ;-) Stefan Reuther <stefan.news@arcor.de> - 2025-09-05 18:46 +0200
          Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-04 19:33 +0200
            Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 08:53 +0200
              Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-05 10:45 +0200
                Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-05 12:01 +0200
                  Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-05 17:33 +0200
            Re: Pascal auf Nr. 10 ;-) "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2025-09-09 13:45 +0200
              Re: Pascal auf Nr. 10 ;-) Andreas Dau <dev.null@andreasdau.com> - 2025-09-09 16:33 +0200
                Re: Pascal auf Nr. 10 ;-) Andreas Dau <dev.null@andreasdau.com> - 2025-09-09 16:36 +0200
              Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-09-09 19:22 +0000
                Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-10 05:57 +0200
              Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-15 13:05 +0200
    Re: Pascal auf Nr. 10 ;-) Andreas Karrer <ak-5a@gmx.ch> - 2025-09-07 01:18 +0000
      Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-09-07 16:25 +0000
        Re: Pascal auf Nr. 10 ;-) Andreas Karrer <ak-5a@gmx.ch> - 2025-09-28 00:06 +0000
      Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-07 19:19 +0200
      Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-08 07:37 +0200
        Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-08 19:42 +0200
          Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-09 07:34 +0200
            Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-09 19:46 +0200
              Re: Pascal auf Nr. 10 ;-) Sebastian Barthel <naitsabes@freenet.de> - 2025-09-09 19:29 +0000
                Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-10 06:27 +0200
                Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-10 18:16 +0200
          Re: Pascal auf Nr. 10 ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-09-19 21:09 +0200
            Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-22 07:19 +0200
    Re: Pascal auf Nr. 10 ;-) Thomas Koenig <tkoenig@netcologne.de> - 2025-09-11 17:26 +0000
      Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-12 07:29 +0200
        Re: Pascal auf Nr. 10 ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-09-12 10:34 +0200
          Re: Pascal auf Nr. 10 ;-) "F. W." <me@home.invalid> - 2025-09-12 11:47 +0200

Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10  Next page →

#52117

FromThomas Koenig <tkoenig@netcologne.de>
Date2025-09-12 15:13 +0000
Message-ID<10a1db3$3jicf$2@dont-email.me>
In reply to#52114
Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
> On 2025-09-12 08:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>> An der Uni hatten wir damals Pascal SC (stand wohl für "Scientific
>> Compouting", wir hatten das damals als "Scheiss Compiler" gelesen).
>>
>> Schönstes Beispiel:
>>
>>    writeln("Gib einen Wert ein");
>>    readln(a);
>>
>> hat natürlich erst die Variable eingelesen und dann den String
>> ausgegeben.  Das entspricht der verqueren Sprachdefinition
>> und hat damals für nicht wenig Verwirrung gesorgt.
>
> Hatten wir das Beispiel nicht schon vor ein paar Tagen?
> Abgesehen von den falschen Anführungszeichen halte ich es für sehr
> wahrscheinlich, dass das »write« stand und nicht »writeln«.

Nein, da stand writeln.
-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#52118

FromStefan Reuther <stefan.news@arcor.de>
Date2025-09-12 18:13 +0200
Message-ID<10a1nsv.us.1@stefan.msgid.phost.de>
In reply to#52114
Am 12.09.2025 um 16:17 schrieb Peter J. Holzer:
> On 2025-09-12 08:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>    writeln("Gib einen Wert ein");
>>    readln(a);
>>
>> hat natürlich erst die Variable eingelesen und dann den String
>> ausgegeben.  Das entspricht der verqueren Sprachdefinition
>> und hat damals für nicht wenig Verwirrung gesorgt.
> 
> Hatten wir das Beispiel nicht schon vor ein paar Tagen?
> Abgesehen von den falschen Anführungszeichen halte ich es für sehr
> wahrscheinlich, dass das »write« stand und nicht »writeln«. Ich weiß
> zwar nicht auswendig, was in der Sprachdefinition steht (und bin zu
> faul, nachzulesen), aber ich weiß, wie Buffered I/O funktioniert, und da
> ist es sehr wahrscheinlich, dass bei einem nicht ausreichend
> durchdachten »write« genau das passiert, während das bei »writeln«
> eigentlich nicht passieren kann. (Bei C haben sich die Leute Gedanken
> gemacht, und genau dieser Fall ist daher im Standard geregelt).

Naja, die Leute bei C haben sich zwar Gedanken gemacht, aber so richtig
endgeil ist die Lösung auch nicht: man konfiguriert einen Modus
(unbuffered, line buffered, fully buffered) und im line buffered Modus
parsed die Standardbibliothek die Daten, um zu ermitteln, wo sie ein
flush einfügen muss. Ganz schön viel, was da passiert, bevor wir beim
write() ankommen.

C++ hat dann zum einen noch std::ios::tie() oben drauf gesetzt, um die
Tatsache "std::cin und std::cout gehören zusammen" abbilden zu können,
und außerdem std::endl erfunden, so dass man die C++-Programme
unerfahrener Programmierer an der schlechten Performance in Pipes
erkennen kann.

Ich hab hier eine ISO-10206-1990.pdf "Extended Pascal". Darin kann ich
auf die Schnelle weder eine Flush-Operation, noch irgendwelche
expliziten Verknüpfungen von Input und Output finden. Damit wäre das
oben Beschriebene wohl standardkonform (und identisch zu einem
C-Programm, dessen Ausgabe in eine Pipe geht).

Das einzige Vorkommen von 'interactive' in dem Dokument ist: "In order
to facilitate interactive terminal input and output, the procedure get
(and other input procedures) should be performed at the latest
opportunity, and the procedure put (and other output procedures) should
be performed at the first opportunity. This technique has been called
'lazy I/O'.". Irgendwer hat sich also Gedanken gemacht, ich steig nur
nicht dahinter.


  Stefan

[toc] | [prev] | [next] | [standalone]

#52120

From"Peter J. Holzer" <hjp-usenet4@hjp.at>
Date2025-09-12 20:27 +0200
Message-ID<slrn10c8pgk.290dl.hjp-usenet4@trintignant.hjp.at>
In reply to#52118
On 2025-09-12 18:13, Stefan Reuther <stefan.news@arcor.de> wrote:
> Am 12.09.2025 um 16:17 schrieb Peter J. Holzer:
>> On 2025-09-12 08:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>    writeln("Gib einen Wert ein");
>>>    readln(a);
>>>
>>> hat natürlich erst die Variable eingelesen und dann den String
>>> ausgegeben.  Das entspricht der verqueren Sprachdefinition

Ich merke da gerade ein mögliches Missverständnis. ist mit "entspricht
der verqueren Sprachdefinition" gemeint, dass die Sprachdefinition das
vorschreibt oder dass sie es erlaubt?

>>> und hat damals für nicht wenig Verwirrung gesorgt.
>> 
>> Hatten wir das Beispiel nicht schon vor ein paar Tagen?
>> Abgesehen von den falschen Anführungszeichen halte ich es für sehr
>> wahrscheinlich, dass das »write« stand und nicht »writeln«. Ich weiß
>> zwar nicht auswendig, was in der Sprachdefinition steht (und bin zu
>> faul, nachzulesen), aber ich weiß, wie Buffered I/O funktioniert, und da
>> ist es sehr wahrscheinlich, dass bei einem nicht ausreichend
>> durchdachten »write« genau das passiert, während das bei »writeln«
>> eigentlich nicht passieren kann. (Bei C haben sich die Leute Gedanken
>> gemacht, und genau dieser Fall ist daher im Standard geregelt).
>
> Naja, die Leute bei C haben sich zwar Gedanken gemacht, aber so richtig
> endgeil ist die Lösung auch nicht:

Das Wort "endgeil" würde ich auf C generell nicht und auf die
Standard-Library schon gar nicht anwenden.

> man konfiguriert einen Modus (unbuffered, line buffered, fully
> buffered) und im line buffered Modus parsed die Standardbibliothek die
> Daten, um zu ermitteln, wo sie ein flush einfügen muss. Ganz schön
> viel, was da passiert, bevor wir beim write() ankommen.

Damit ist schon eine PDP-11 zurechtgekommen. Konzeptionell läuft
jeglicher Output auf Aufrufe von fputc() hinaus. Da das genau ein
Zeichen ausgibt, muss da nichts "geparst" werden, die Funktion muss nur
schauen, ob das Zeichen '\n' ist. (In der Praxis ist das natürlich
meistens etwas optimierter)

Es passiert aber noch mehr, und das ist der Abschnitt, den ich meinte:

| Furthermore, characters are intended to be transmitted as a block to
| the host environment when a buffer is filled, when input is requested
| on an unbuffered stream, or when input is requested on a line buffered
| stream that requires the transmission of characters from the host
| environment.
    Zitiert aus ISO/IEC 9899:201x, aber unverändert seit C89.

Das betrifft genau den Fall mit dem Prompt. Der Prompt wird auf stdout
ausgegeben. stdout ist auf einem Terminal (normalerweise) line-buffered,
somit würde der Prompt nicht geflusht. Dann wird eine Input-Funktion
aufgerufen, die von stdin lesen soll. stdin ist normalerweise auch
line-buffered, aber zu dem Zeitpunkt ist der Buffer leer (der User hat
noch nichts eingegeben, weil er den Prompt ja noch gar nicht gesehen
hat). Bevor nun tatsächlich vom "host environment" Daten angefordert
werden, werden alle Output-Streams geflusht, somit auch stdout. Der User
sieht den Prompt und kann etwas eingeben.

Das ist zugegeben eine Holzhammer-Methode. Es würde reichen, nur stdout
zu flushen, aber offensichtlich wollten sie stdin und stdout da nicht
besonders behandeln und eine "Verknüpfung" von verschiedenen Streams
kennt die C-Library nicht. Einfach alles zu flushen löst das Problem auf
bequeme Art und Performance ist bei interaktiven Eingaben eher kein
Problem.

> C++ hat dann zum einen noch std::ios::tie() oben drauf gesetzt, um die
> Tatsache "std::cin und std::cout gehören zusammen" abbilden zu können,

Ja, das macht es etwas effizienter, aber dafür muss der Programmierer
drandenken, die richtigen Streams miteinander zu verknüpfen.

> und außerdem std::endl erfunden, so dass man die C++-Programme
> unerfahrener Programmierer an der schlechten Performance in Pipes
> erkennen kann.
>
> Ich hab hier eine ISO-10206-1990.pdf "Extended Pascal".

Ich auch (hat Deine Version auch kein Inhaltsverzeichnis?). Und
zwischenzeitlich habe ich mich auch aufgerafft, darin nachzuschlagen.

> Darin kann ich auf die Schnelle weder eine Flush-Operation, noch
> irgendwelche expliziten Verknüpfungen von Input und Output finden.

Yup. Es gibt ein bisschen was über "partial lines", aber ehrlich gesagt,
habe ich das nicht ganz verstanden. Für mich klingt es allerdings so,
als ob Output auf Text-Files immer in ganzen Zeilen erfolgen sollte
(also mindestens line-buffered ist).

Bei
    writeln('Gib einen Wert ein');
    readln(a);
wäre es demnach *erlaubt* (aber nicht vorgeschrieben), dass der Prompt
ausgebenen wird, bevor das Programm auf Eingabe wartet, bei
    write('Gib einen Wert ein');
    readln(a);
hingegen verboten.

> Das einzige Vorkommen von 'interactive' in dem Dokument ist: "In order
> to facilitate interactive terminal input and output, the procedure get
> (and other input procedures) should be performed at the latest
> opportunity, and the procedure put (and other output procedures) should
> be performed at the first opportunity. This technique has been called
> 'lazy I/O'.".

Ah, danke. Die Note hatte ich glatt überlesen, obwohl ich die Absätze
davor und danach gelesen habe. Offenbar haben die pre- und
post-assertions mein Kurzzeitgedächtnis resettet ;-).


> Irgendwer hat sich also Gedanken gemacht, ich steig nur nicht
> dahinter.

Ich würde das so interpretieren:

"Performed" verstehe ich als "hat einen Effekt außerhalb des Programms".
Denn dass eine Prozedur dann ausgeführt wird, wenn sie aufgerufen wird,
ist IMHO bei einer imperativen Programmiersprache wie Pascal
selbstverständlich.

write('Gib einen Wert ein') ist äquivalent zu
put('G'); put('i'); ... put('n');
Keines davon ist eine "opportunity", da da erst die "partial line"
"generated" wird. Es wird also nichts geflusht. Das folgende readln()
aber ist die "latest opportunity" für einen Input. Somit blockiert das
Programm an dieser Stelle, ohne dass der Prompt sichtbar wäre.

Das writeln hingegen ist äquivalent zu
put('G'); put('i'); ... put('n'); put(EOL);
Das EOL ist die "first opportunity", somit sollte an dieser Stelle die
gesamte Zeile ausgegeben werden.

Der Extremfall des umgekehrten Verhaltens wäre, dass das Programm gleich
beim Start input bis zum EOF in einen internen Buffer liest, und output
erst bei Programmende flusht. Das wäre vielleicht für Batch-Betrieb
effizient, aber für interaktiven Betrieb vollkommen ungeeignet.
Ich glaube aber, dass so eine Implementation standard-konform wäre
(erstens weil in der Note nur "should" steht und nicht "shall" und
zweitens, weil Notes in Standards meistens ohnehin nicht normativ sind
(allerdings steht das dann meistens auch im Standard, was hier nicht der
Fall ist)).

        hjp

[toc] | [prev] | [next] | [standalone]

#52121

FromThomas Koenig <tkoenig@netcologne.de>
Date2025-09-12 21:58 +0000
Message-ID<10a251d$3t4o0$1@dont-email.me>
In reply to#52120
Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
> On 2025-09-12 18:13, Stefan Reuther <stefan.news@arcor.de> wrote:
>> Am 12.09.2025 um 16:17 schrieb Peter J. Holzer:
>>> On 2025-09-12 08:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>>    writeln("Gib einen Wert ein");
>>>>    readln(a);
>>>>
>>>> hat natürlich erst die Variable eingelesen und dann den String
>>>> ausgegeben.  Das entspricht der verqueren Sprachdefinition
>
> Ich merke da gerade ein mögliches Missverständnis. ist mit "entspricht
> der verqueren Sprachdefinition" gemeint, dass die Sprachdefinition das
> vorschreibt oder dass sie es erlaubt?

Vorschreibt, IIRC.

Turbo-Pascal ist damals von der Norm abgewichten.
-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#52122

From"Peter J. Holzer" <hjp-usenet4@hjp.at>
Date2025-09-13 00:13 +0200
Message-ID<slrn10c96o4.2h1lb.hjp-usenet4@trintignant.hjp.at>
In reply to#52121
On 2025-09-12 23:58, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
>> On 2025-09-12 18:13, Stefan Reuther <stefan.news@arcor.de> wrote:
>>> Am 12.09.2025 um 16:17 schrieb Peter J. Holzer:
>>>> On 2025-09-12 08:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>>>    writeln("Gib einen Wert ein");
>>>>>    readln(a);
>>>>>
>>>>> hat natürlich erst die Variable eingelesen und dann den String
>>>>> ausgegeben.  Das entspricht der verqueren Sprachdefinition
>>
>> Ich merke da gerade ein mögliches Missverständnis. ist mit "entspricht
>> der verqueren Sprachdefinition" gemeint, dass die Sprachdefinition das
>> vorschreibt oder dass sie es erlaubt?
>
> Vorschreibt, IIRC.

Kann ich dem Standard nicht entnehmen (siehe Rest des Postings). War
allerdings für Extended Pascal und von 1990. (in den Standard Pascal
Standard aus dem gleichen Jahr habe ich kurz reingeschaut. Sieht auf den
ersten Blick recht ähnlich aus)

        hjp

[toc] | [prev] | [next] | [standalone]

#52126

FromThomas Koenig <tkoenig@netcologne.de>
Date2025-09-13 09:07 +0000
Message-ID<10a3c96$9ga4$1@dont-email.me>
In reply to#52122
Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
> On 2025-09-12 23:58, Thomas Koenig <tkoenig@netcologne.de> wrote:
>> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
>>> On 2025-09-12 18:13, Stefan Reuther <stefan.news@arcor.de> wrote:
>>>> Am 12.09.2025 um 16:17 schrieb Peter J. Holzer:
>>>>> On 2025-09-12 08:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>>>>    writeln("Gib einen Wert ein");
>>>>>>    readln(a);
>>>>>>
>>>>>> hat natürlich erst die Variable eingelesen und dann den String
>>>>>> ausgegeben.  Das entspricht der verqueren Sprachdefinition
>>>
>>> Ich merke da gerade ein mögliches Missverständnis. ist mit "entspricht
>>> der verqueren Sprachdefinition" gemeint, dass die Sprachdefinition das
>>> vorschreibt oder dass sie es erlaubt?
>>
>> Vorschreibt, IIRC.
>
> Kann ich dem Standard nicht entnehmen (siehe Rest des Postings).

In 
https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html
schreibt Kernighan

Pascal's built-in I/O has a deservedly bad reputation.  It believes
strongly in record-oriented input and output.  It also has a
look-ahead convention that is hard to implement properly in an
interactive environment.  Basically, the problem is that the I/O
system believes that it must read one record ahead of the record
that is being processed.  In an interactive system, this means
that when a program is started, its first operation is to try to
read the terminal for the first line of input, before any of the
program itself has been executed.  But in the program

     write('Please enter your name: ');
     read(name);
     ...

read-ahead causes the program to hang, waiting for input before
printing the prompt that asks for it.

Den Artikel sollte sich jeder Pascal-Fan mal ganz durchlesen :-)
-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

[toc] | [prev] | [next] | [standalone]

#52128

From"Peter J. Holzer" <hjp-usenet4@hjp.at>
Date2025-09-13 13:47 +0200
Message-ID<slrn10camdr.32pdi.hjp-usenet4@trintignant.hjp.at>
In reply to#52126
On 2025-09-13 11:07, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
>> On 2025-09-12 23:58, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
>>>> On 2025-09-12 18:13, Stefan Reuther <stefan.news@arcor.de> wrote:
>>>>> Am 12.09.2025 um 16:17 schrieb Peter J. Holzer:
>>>>>> On 2025-09-12 08:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>>>>>    writeln("Gib einen Wert ein");
>>>>>>>    readln(a);
>>>>>>>
>>>>>>> hat natürlich erst die Variable eingelesen und dann den String
>>>>>>> ausgegeben.  Das entspricht der verqueren Sprachdefinition
>>>>
>>>> Ich merke da gerade ein mögliches Missverständnis. ist mit "entspricht
>>>> der verqueren Sprachdefinition" gemeint, dass die Sprachdefinition das
>>>> vorschreibt oder dass sie es erlaubt?
>>>
>>> Vorschreibt, IIRC.
>>
>> Kann ich dem Standard nicht entnehmen (siehe Rest des Postings).
>
> In 
> https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html
> schreibt Kernighan
>
> Pascal's built-in I/O has a deservedly bad reputation.  It believes
> strongly in record-oriented input and output.

Ja.

> It also has a look-ahead convention that is hard to implement properly
> in an interactive environment.

Hard ist nicht unmöglich.

> Basically, the problem is that the I/O system believes that it must
> read one record ahead of the record that is being processed.  In an
> interactive system, this means that when a program is started, its
> first operation is to try to read the terminal for the first line of
> input, before any of the program itself has been executed.

Es ist unklar, ob er sich da auf eine bestimmte Implementation bezieht
oder auf eine Sprachdefinition (gab es 1981 schon einen Pascal-Standard?
Wenn nicht, wäre vermutlich das Buch von Wirth autoritativ). Es
widerspricht der Note, die Stefan im Standard entdeckt hat (allerdings
ist der 9 Jahre jünger).

Tatsächlich ein Problem ist allerdings das in Pascal übliche
(unvermeidliche?) Pattern:

    while not eof(f)
    begin
        prepare_something()
        readln(f, s);
        do_something_with(s)
    end;

Hier muss das eof() versuchen, zu lesen, um herauszufinden, ob das Ende
des Files erreicht ist. Das wird bei einem Terminal, einer Pipe, etc.
blockieren. prepare_something() wird also erst ausgeführt, nachdem
mindestens ein Zeichen (eher eine ganze Zeile) eingegeben wurde.

Das geht in C besser, weil hier die read-Operationen selbst
melden, dass sie EOF erreicht haben.


> Den Artikel sollte sich jeder Pascal-Fan mal ganz durchlesen :-)

Erstens: Ich bin kein Pascal-Fan (ich glaube, der einzige Pascal-Fan
hier ist F.W., aber der ist ja auch COBOL-Fan).
Zweitens: Ich habe den Artikel schon ca. 1990 ganz durchgelesen.

        hjp

[toc] | [prev] | [next] | [standalone]

#52129

FromStefan Reuther <stefan.news@arcor.de>
Date2025-09-14 12:14 +0200
Message-ID<10a6bi9.1qo.1@stefan.msgid.phost.de>
In reply to#52128
Am 13.09.2025 um 13:47 schrieb Peter J. Holzer:
> Tatsächlich ein Problem ist allerdings das in Pascal übliche
> (unvermeidliche?) Pattern:
> 
>     while not eof(f)
>     begin
>         prepare_something()
>         readln(f, s);
>         do_something_with(s)
>     end;
> 
> Hier muss das eof() versuchen, zu lesen, um herauszufinden, ob das Ende
> des Files erreicht ist. Das wird bei einem Terminal, einer Pipe, etc.
> blockieren. prepare_something() wird also erst ausgeführt, nachdem
> mindestens ein Zeichen (eher eine ganze Zeile) eingegeben wurde.

Wobei man da aber auch sagen muss: zu der Zeit, als Pascal am
populärsten war, waren auch Betriebssysteme populär, in denen das kein
Problem war. Unter DOS bzw. CP/M gibt es entweder Dateien, wo man die
EOF-Bedingung problemlos durch Vergleich von Dateiposition und -größe
feststellen kann bzw. wo Vorauslesen harmlos ist, oder es gibt Devices
(Konsole, COM, LPT), die niemals EOF melden.

Unix mit Pipes oder Devices, die EOF liefern können, waren da halt ein
Sonderfall.

> Erstens: Ich bin kein Pascal-Fan (ich glaube, der einzige Pascal-Fan
> hier ist F.W., aber der ist ja auch COBOL-Fan).

Eine verbreitete Sprache mit Pascal-Syntax und C++-Features wäre schon
knorke, aber die Geschichte hat sich halt anders entschieden.


  Stefan

[toc] | [prev] | [next] | [standalone]

#52137

From"Peter J. Holzer" <hjp-usenet4@hjp.at>
Date2025-09-15 20:22 +0200
Message-ID<slrn10cgmb5.1pu8e.hjp-usenet4@trintignant.hjp.at>
In reply to#52129
On 2025-09-14 12:14, Stefan Reuther <stefan.news@arcor.de> wrote:
> Am 13.09.2025 um 13:47 schrieb Peter J. Holzer:
>> Tatsächlich ein Problem ist allerdings das in Pascal übliche
>> (unvermeidliche?) Pattern:
>> 
>>     while not eof(f)
>>     begin
>>         prepare_something()
>>         readln(f, s);
>>         do_something_with(s)
>>     end;
>> 
>> Hier muss das eof() versuchen, zu lesen, um herauszufinden, ob das Ende
>> des Files erreicht ist. Das wird bei einem Terminal, einer Pipe, etc.
>> blockieren. prepare_something() wird also erst ausgeführt, nachdem
>> mindestens ein Zeichen (eher eine ganze Zeile) eingegeben wurde.
>
> Wobei man da aber auch sagen muss: zu der Zeit, als Pascal am
> populärsten war, waren auch Betriebssysteme populär, in denen das kein
> Problem war. Unter DOS bzw. CP/M gibt es entweder Dateien, wo man die
> EOF-Bedingung problemlos durch Vergleich von Dateiposition und -größe
> feststellen kann bzw. wo Vorauslesen harmlos ist, oder es gibt Devices
> (Konsole, COM, LPT), die niemals EOF melden.

Irgendwie muss man das Ende der Eingabe auch auf der Konsole signalieren
können. Unter CP/M und DOS gab es da die Konvention, Ctrl-Z zu tippen.
Ob das vom Device oder vom Runtime-System interpretiert wird, ist dabei
zweitrangig, in jedem Fall muss bei obigem Code bereits das eof() darauf
reagieren, obwohl es der User erst beim readln() tippt, was ohne
Fluxkompensator schwierig zu erreichen ist.


>> Erstens: Ich bin kein Pascal-Fan (ich glaube, der einzige Pascal-Fan
>> hier ist F.W., aber der ist ja auch COBOL-Fan).
>
> Eine verbreitete Sprache mit Pascal-Syntax und C++-Features wäre schon
> knorke, aber die Geschichte hat sich halt anders entschieden.

Ich glaube, das Problem bei C++ ist nicht die Syntax, sondern die
Features.

        hjp

[toc] | [prev] | [next] | [standalone]

#52138

FromHermann Riemann <nospam.ng@hermann-riemann.de>
Date2025-09-16 06:51 +0200
Message-ID<mis8mhF11sgU1@mid.individual.net>
In reply to#52137
Am 15.09.25 um 20:22 schrieb Peter J. Holzer:

> Ich glaube, das Problem bei C++ ist nicht die Syntax, sondern die
> Features.

Dann nimm Lisp, da ist es umgekehrt.

-- 
<http://www.hermann-riemann.de>

[toc] | [prev] | [next] | [standalone]

#52279

FromAndreas Eder <a_eder_muc@web.de>
Date2025-10-03 11:08 +0200
Message-ID<87tt0ge4ja.fsf@eder.anydns.info>
In reply to#52138
On Di 16 Sep 2025 at 06:51, Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:

> Am 15.09.25 um 20:22 schrieb Peter J. Holzer:
>
>> Ich glaube, das Problem bei C++ ist nicht die Syntax, sondern die
>> Features.
>
> Dann nimm Lisp, da ist es umgekehrt.

Lisp hat wohl die einfachste Syntax überhaupt.

'Andreas

-- 
ceterum censeo redmondinem esse delendam

[toc] | [prev] | [next] | [standalone]

#52280

FromHermann Riemann <nospam.ng@hermann-riemann.de>
Date2025-10-03 13:17 +0200
Message-ID<mk9pmqFml0tU1@mid.individual.net>
In reply to#52279
Am 03.10.25 um 11:08 schrieb Andreas Eder:
> On Di 16 Sep 2025 at 06:51, Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
> 
>> Am 15.09.25 um 20:22 schrieb Peter J. Holzer:
>>
>>> Ich glaube, das Problem bei C++ ist nicht die Syntax, sondern die
>>> Features.
>>
>> Dann nimm Lisp, da ist es umgekehrt.
> 
> Lisp hat wohl die einfachste Syntax überhaupt.

Vom logischen Konstrukt her, ja.
( Ähnlich wie FORTH )

Allerdings, da die Hälfte aller "Wörter"
  ( syntaktische Einheiten, token )
Klammern sind, gibt es Probleme.

Die meisten meiner ersten Lisp 1.5 Programme
liefern mir als Ergebnis nur "BAD BRACKET COUNT"

Ich erwäge,
wenn ich wieder LISP verwenden will,
einen eigenen Präprozessor zu verwenden,
der eine Python Schreibweise verwendet.
Insbesondere bei Einrückung passende Klammern setzt,
und auch Groß-Klein Schreibung irgendwie handhabt.

-- 
<http://www.hermann-riemann.de>

[toc] | [prev] | [next] | [standalone]

#52281

FromSebastian Barthel <naitsabes@freenet.de>
Date2025-10-03 13:48 +0000
Message-ID<10bok6m$f823$2@solani.org>
In reply to#52280
Am Fri, 03 Oct 2025 13:17:46 +0200 schrieb Hermann Riemann:

> Am 03.10.25 um 11:08 schrieb Andreas Eder:
>> On Di 16 Sep 2025 at 06:51, Hermann Riemann
>> <nospam.ng@hermann-riemann.de> wrote:
>> 
>>> Am 15.09.25 um 20:22 schrieb Peter J. Holzer:
>>>
>>>> Ich glaube, das Problem bei C++ ist nicht die Syntax, sondern die
>>>> Features.

>>> Dann nimm Lisp, da ist es umgekehrt.
>> 
>> Lisp hat wohl die einfachste Syntax überhaupt.
> 
> Vom logischen Konstrukt her, ja.
> ( Ähnlich wie FORTH )
> 
> Allerdings, da die Hälfte aller "Wörter"
>   ( syntaktische Einheiten, token )
> Klammern sind, gibt es Probleme.
> 
> Die meisten meiner ersten Lisp 1.5 Programme liefern mir als Ergebnis
> nur "BAD BRACKET COUNT"

Dafür gibt es passende Editoren, die das mitzählen und/oder farbig 
markieren.

[toc] | [prev] | [next] | [standalone]

#52288

FromAndreas Eder <a_eder_muc@web.de>
Date2025-10-04 12:57 +0200
Message-ID<87cy73c4sz.fsf@eder.anydns.info>
In reply to#52281
On Fr 03 Okt 2025 at 14:26, ram@zedat.fu-berlin.de (Stefan Ram) wrote:

> Sebastian Barthel <naitsabes@freenet.de> schrieb oder zitierte:
>>Dafür gibt es passende Editoren, die das mitzählen und/oder farbig 
>>markieren.
>
>   Es ist schon besser, wenn Quelltext auch ohne Hilfe des Editors
>   durch einen Menschen schnell erfaßt werden kann. Wenn man LISP-
>   Quelltext einheitlich einrückt, dann kann man ja die Klammern
>   fast ignorieren und sich auf die Einrückung verlassen.
>
> ( SETQ DIFF
>   ( LAMBDA( X )
>     ( COND 
>       ( ( ATOMP X )
>         ( COND 
>           ( ( EQ X 'X )
>             1 )
>           ( T
>             0 )))
>       ( T
>         ( COND 
>           ( ( EQ( CAR X )'SUM )
>             ( LIST 'SUM( DIFF( CADR X ))( DIFF( CADDR X )))))))))

So schreibt das doch kein Lisp/Programmierer!
So sieht das schon besser aus:

(defun diff (x)
       (if (atomp x)
           (if (eq x 'x ) 1 0)
           (when (eq (car x) 'sum )
                 (list 'sum (diff (cadr x)) (diff (caddr x))))))

'Andreas

-- 
ceterum censeo redmondinem esse delendam

[toc] | [prev] | [next] | [standalone]

#52287

FromAndreas Eder <a_eder_muc@web.de>
Date2025-10-04 12:44 +0200
Message-ID<87jz1bc5ej.fsf@eder.anydns.info>
In reply to#52280
On Fr 03 Okt 2025 at 13:17, Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:

> Am 03.10.25 um 11:08 schrieb Andreas Eder:
>> On Di 16 Sep 2025 at 06:51, Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
>> 
>>> Am 15.09.25 um 20:22 schrieb Peter J. Holzer:
>>>
>>>> Ich glaube, das Problem bei C++ ist nicht die Syntax, sondern die
>>>> Features.
>>>
>>> Dann nimm Lisp, da ist es umgekehrt.
>> Lisp hat wohl die einfachste Syntax überhaupt.
>
> Vom logischen Konstrukt her, ja.
> ( Ähnlich wie FORTH )
>
> Allerdings, da die Hälfte aller "Wörter"
>  ( syntaktische Einheiten, token )
> Klammern sind, gibt es Probleme.
>
> Die meisten meiner ersten Lisp 1.5 Programme
> liefern mir als Ergebnis nur "BAD BRACKET COUNT"

Da braucht man halt einen vernünftigen Editor, z.B. Emacs.

'Andreas

-- 
ceterum censeo redmondinem esse delendam

[toc] | [prev] | [next] | [standalone]

#52296

FromHermann Riemann <nospam.ng@hermann-riemann.de>
Date2025-10-04 17:34 +0200
Message-ID<mkct4oF88kfU1@mid.individual.net>
In reply to#52287
Am 04.10.25 um 12:44 schrieb Andreas Eder:
> On Fr 03 Okt 2025 at 13:17, Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
> 
>> Am 03.10.25 um 11:08 schrieb Andreas Eder:
>>> On Di 16 Sep 2025 at 06:51, Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
>>>
>>>> Am 15.09.25 um 20:22 schrieb Peter J. Holzer:
>>>>
>>>>> Ich glaube, das Problem bei C++ ist nicht die Syntax, sondern die
>>>>> Features.
>>>>
>>>> Dann nimm Lisp, da ist es umgekehrt.
>>> Lisp hat wohl die einfachste Syntax überhaupt.
>>
>> Vom logischen Konstrukt her, ja.
>> ( Ähnlich wie FORTH )
>>
>> Allerdings, da die Hälfte aller "Wörter"
>>   ( syntaktische Einheiten, token )
>> Klammern sind, gibt es Probleme.
>>
>> Die meisten meiner ersten Lisp 1.5 Programme
>> liefern mir als Ergebnis nur "BAD BRACKET COUNT"
> 
> Da braucht man halt einen vernünftigen Editor, z.B. Emacs.

Damals hatte ich nur Lochkarten.
Ich habe mir mit einem Fortan Programm beholfen,
welche Zeilen einfügte.
In den eingefügten Zeilen stand dann die Klammertiefe.
War die Tiefe >=10 wurde weitere Zeile eingefügt für
das Vielfache von 10, so das die Spalten übereinstimmten.

Bei >= 1 Editor blinkt eventuell die Gegenklammer.

-- 
<http://www.hermann-riemann.de>

[toc] | [prev] | [next] | [standalone]

#52283

From"Peter J. Holzer" <hjp-usenet4@hjp.at>
Date2025-10-03 16:30 +0200
Message-ID<slrn10dvngo.20s18.hjp-usenet4@trintignant.hjp.at>
In reply to#52279
On 2025-10-03 11:08, Andreas Eder <a_eder_muc@web.de> wrote:
> On Di 16 Sep 2025 at 06:51, Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
>> Am 15.09.25 um 20:22 schrieb Peter J. Holzer:
>>> Ich glaube, das Problem bei C++ ist nicht die Syntax, sondern die
>>> Features.
>>
>> Dann nimm Lisp, da ist es umgekehrt.
>
> Lisp hat wohl die einfachste Syntax überhaupt.

Das ist möglicherweise genau das Problem. Bei Lisp schaut alles
irgendwie gleich aus und man hat sehr wenig, woran man sich visuell
orientieren kann. Bei den meisten anderen Programmiersprachen sehen
hingegen verschiedene Dinge auch verschieden aus. Das kann man auch
wieder übertreiben (Perl z.B.), aber es gibt irgendwo einen Sweet Spot
(vermutlich von Person zu Person zu verschieden), wo der Source-Code
genug optische Variabilität hat, um dem Auge Halt zu bieten, aber nicht
soviel, dass man ernsthaft nachdenken muss, was ein bestimmtes Zeichen
oder Keyword bedeutet.

        hjp

PS: Ich habe mich vor 30+ Jahren ein bisschen mit Lisp gespielt, aber
    es hat nicht geklickt und als Nicht-Emacs-User hatte ich keine
    externe Motivation, mich weiter damit zu beschäftigen.

[toc] | [prev] | [next] | [standalone]

#52326

FromChristian Weisgerber <naddy@mips.inka.de>
Date2025-10-05 21:35 +0000
Message-ID<slrn10e5p49.10gj.naddy@lorvorc.mips.inka.de>
In reply to#52283
On 2025-10-03, Peter J. Holzer <hjp-usenet4@hjp.at> wrote:

> PS: Ich habe mich vor 30+ Jahren ein bisschen mit Lisp gespielt, aber
>     es hat nicht geklickt und als Nicht-Emacs-User hatte ich keine
>     externe Motivation, mich weiter damit zu beschäftigen.

Ich habe dreimal angefangen, mich in Lisp einzuarbeiten, einmal
sogar einen Uni-Schein für Programmieren in Common Lisp gemacht,
und jedes Mal ist das mangels Anwendung prompt wieder eingeschlafen
und in Vergessenheit geraten. :-(

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

[toc] | [prev] | [next] | [standalone]

#52330

FromHermann Riemann <nospam.ng@hermann-riemann.de>
Date2025-10-06 08:29 +0200
Message-ID<mkh5unFu1ukU1@mid.individual.net>
In reply to#52326
Am 05.10.25 um 23:35 schrieb Christian Weisgerber:
> On 2025-10-03, Peter J. Holzer <hjp-usenet4@hjp.at> wrote:
> 
>> PS: Ich habe mich vor 30+ Jahren ein bisschen mit Lisp gespielt, aber
>>      es hat nicht geklickt und als Nicht-Emacs-User hatte ich keine
>>      externe Motivation, mich weiter damit zu beschäftigen.
> 
> Ich habe dreimal angefangen, mich in Lisp einzuarbeiten, einmal
> sogar einen Uni-Schein für Programmieren in Common Lisp gemacht,
> und jedes Mal ist das mangels Anwendung prompt wieder eingeschlafen
> und in Vergessenheit geraten. :-(

Die einzige Anwendung, für die ich möglicherweise noch einmal
Lisp verwende werde, ist die quote eval Kombination.

Also zum automatischer Programm Entwicklung.

Ich habe z.B.
  ein Programmstück ( in Python Schreibweise ).

if a == b :

wenn ich jetzt a durch c ersetzen will
( z.B.für eine neue Variante )

müsste ich in anderen Sprachen
das im Text ( Quelltext ) ändern,
oder mir einen interpreter programmieren.

In Lisp steckt (quote) a in einem
array ( listen) Baum.

Die Ausführung geht dann mit eval.

In C müsste ich nach Programmänderung
übersetzen binden und interface ( shared memory ) basteln,
wenn ich keine internen Interpreter programmiert hätte.

Für alle anderen Anwendungen finde ich Lisp zu unhandlich.

Ein Anwendung davon wäre
dynamisch Lösungswege automatisch suchen.

-- 
<http://www.hermann-riemann.de> bzw.:
<https://www.hermann-riemann.eu/de>

[toc] | [prev] | [next] | [standalone]

#52343

FromStefan Reuther <stefan.news@arcor.de>
Date2025-10-06 19:07 +0200
Message-ID<10c140s.290.1@stefan.msgid.phost.de>
In reply to#52326
Am 05.10.2025 um 23:35 schrieb Christian Weisgerber:
> On 2025-10-03, Peter J. Holzer <hjp-usenet4@hjp.at> wrote:
>> PS: Ich habe mich vor 30+ Jahren ein bisschen mit Lisp gespielt, aber
>>     es hat nicht geklickt und als Nicht-Emacs-User hatte ich keine
>>     externe Motivation, mich weiter damit zu beschäftigen.
> 
> Ich habe dreimal angefangen, mich in Lisp einzuarbeiten, einmal
> sogar einen Uni-Schein für Programmieren in Common Lisp gemacht,
> und jedes Mal ist das mangels Anwendung prompt wieder eingeschlafen
> und in Vergessenheit geraten. :-(

Emacs benutzen ist eine gute Motivation.

Mein Grund, bei Emacs gelandet zu sein: als on-topic'ne Systeme der
heiße Scheiß waren, war (a) XEmacs die einzige Möglichkeit,
Syntax-Highlighting auf der Linux-Konsole zu bekommen, und (b) NTEmacs
die einzige Möglichkeit, unter Windows 95 einen
Kommandozeileninterpreter mit mehr als 80x25 Fenstergröße zu bekommen.
Und von da ist das dann eskaliert.


  Stefan

[toc] | [prev] | [next] | [standalone]

Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10  Next page →

Back to top | Article view | de.alt.folklore.computer

csiph-web