From gpc-doc Thu Jan 01 00:00:00 2002 Delivered-To: gpc-doc@gerwinski.de Received: (qmail 22765 invoked from network); 17 Mar 2000 01:34:27 -0000 Received: from esmeralda.gerwinski.de (root@194.221.119.18) by tim.gerwinski.de with SMTP; 17 Mar 2000 01:34:27 -0000 Received: (from peter@localhost) by esmeralda.gerwinski.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id CAA02139 for gpc-doc@gnu.de; Fri, 17 Mar 2000 02:33:31 +0100 Received: (qmail 22660 invoked from network); 17 Mar 2000 01:32:08 -0000 Received: from 44615166.theo-phys.uni-essen.de (132.252.73.246) by tim.gerwinski.de with SMTP; 17 Mar 2000 01:32:08 -0000 Received: (from anja@localhost) by 44615166.theo-phys.uni-essen.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id CAA07949 for gpc-doc@gnu.de; Fri, 17 Mar 2000 02:32:37 +0100 Date: Fri, 17 Mar 2000 02:32:37 +0100 From: Anja Drewitz To: gpc-doc@gnu.de Subject: Test Message-ID: <20000317023237.A7946@44615166.theo-phys.uni-essen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Sender: owner-gpc-doc@gnu.de Precedence: bulk Hallo, dies ist ein Test. Anja From gpc-doc Thu Jan 01 00:00:00 2002 Delivered-To: gpc-doc@gerwinski.de Received: (qmail 22940 invoked from network); 17 Mar 2000 01:40:54 -0000 Received: from esmeralda.gerwinski.de (root@194.221.119.18) by tim.gerwinski.de with SMTP; 17 Mar 2000 01:40:54 -0000 Received: (from peter@localhost) by esmeralda.gerwinski.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id CAA02160 for gpc-doc@gnu.de; Fri, 17 Mar 2000 02:39:58 +0100 Received: (qmail 22825 invoked from network); 17 Mar 2000 01:36:35 -0000 Received: from 44615166.theo-phys.uni-essen.de (132.252.73.246) by tim.gerwinski.de with SMTP; 17 Mar 2000 01:36:34 -0000 Received: (from anja@localhost) by 44615166.theo-phys.uni-essen.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id CAA07987 for gpc-doc@gnu.de; Fri, 17 Mar 2000 02:37:03 +0100 Date: Fri, 17 Mar 2000 02:37:03 +0100 From: Anja Drewitz To: gpc-doc@gnu.de Subject: Test 2 Message-ID: <20000317023703.A7980@44615166.theo-phys.uni-essen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Sender: owner-gpc-doc@gnu.de Precedence: bulk Hallo, hier kommt noch ein Test. Anja From gpc-doc Thu Jan 01 00:00:00 2002 Delivered-To: gpc-doc@gerwinski.de Received: (qmail 24427 invoked from network); 17 Mar 2000 01:57:43 -0000 Received: from esmeralda.gerwinski.de (root@194.221.119.18) by tim.gerwinski.de with SMTP; 17 Mar 2000 01:57:43 -0000 Received: (from peter@localhost) by esmeralda.gerwinski.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id CAA02270 for gpc-doc@gnu.de; Fri, 17 Mar 2000 02:56:47 +0100 Received: (qmail 24277 invoked from network); 17 Mar 2000 01:56:19 -0000 Received: from esmeralda.gerwinski.de (root@194.221.119.18) by tim.gerwinski.de with SMTP; 17 Mar 2000 01:56:19 -0000 Received: (from peter@localhost) by esmeralda.gerwinski.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id CAA02258 for gpc-doc@gnu.de; Fri, 17 Mar 2000 02:55:23 +0100 Date: Fri, 17 Mar 2000 02:55:18 +0100 From: Peter Gerwinski To: gpc-doc@gnu.de Subject: Test Message-ID: <20000317025518.I655@esmeralda.gerwinski.de> Mail-Followup-To: gpc-doc@gnu.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Sender: owner-gpc-doc@gnu.de Precedence: bulk Testing (16.3.2000, 26:55) From gpc-doc Thu Jan 01 00:00:00 2002 Delivered-To: gpc-doc@gerwinski.de Received: (qmail 26059 invoked from network); 17 Mar 2000 02:12:11 -0000 Received: from esmeralda.gerwinski.de (root@194.221.119.18) by tim.gerwinski.de with SMTP; 17 Mar 2000 02:12:10 -0000 Received: (from peter@localhost) by esmeralda.gerwinski.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id DAA02362 for gpc-doc@gnu.de; Fri, 17 Mar 2000 03:11:13 +0100 Date: Fri, 17 Mar 2000 03:10:29 +0100 From: Peter Gerwinski To: gpc-doc@gnu.de Subject: Test Message-ID: <20000317031029.L655@esmeralda.gerwinski.de> Mail-Followup-To: gpc-doc@gnu.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Sender: owner-gpc-doc@gnu.de Precedence: bulk Testing (16.3.2000, 27:10) From gpc-doc Thu Jan 01 00:00:00 2002 Delivered-To: gpc-doc@gerwinski.de Received: (qmail 15222 invoked from network); 7 Nov 2000 09:42:05 -0000 Received: from mond.dida.physik.uni-essen.de (132.252.78.233) by tim.gerwinski.de with SMTP; 7 Nov 2000 09:42:05 -0000 Received: from lange by mond.dida.physik.uni-essen.de with local (Exim 3.12 #1 (Debian)) id 13t5Gk-0004L7-00; Tue, 07 Nov 2000 10:42:18 +0100 Date: Tue, 7 Nov 2000 10:42:18 +0100 From: Eike Lange To: gpc-doc@gnu.de Cc: gpc@gnu.de Subject: help writing documentation Message-ID: <20001107104218.B16403@mond.dida.physik.uni-essen.de> Mail-Followup-To: gpc-doc@gnu.de, gpc@gnu.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Sender: owner-gpc-doc@gnu.de Precedence: bulk Hi! I would like to help writing documentation for gpc. My project, writing german documentation for gpc died because nobody was interested helping me and its too much for just one man. I would prefer to discuss documentation-related topics on the gpc-doc-mailinglist (gpc-doc@gnu.de) . There are still some questions left: - Is Texinfo 4.0 ok? - Which options do you use to create the diffs - Are there any documentation-standards, I have to recognize? Eike From gpc-doc Thu Jan 01 00:00:00 2002 Delivered-To: gpc-doc@gerwinski.de Received: (qmail 1455 invoked by uid 10); 7 Nov 2000 15:17:41 -0000 Received: from goedel.fjf.gnu.de (goedel.fjf.gnu.de [10.1.6.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id QAA08888; Tue, 7 Nov 2000 16:09:46 +0100 Date: Tue, 7 Nov 2000 16:09:46 +0100 From: Frank Heckenbach Message-Id: <1315CF98.20001107160946.FOO-22B6.frank@g-n-u.de> X-Mailer: smtphack 0.3.5 by Jan Andres To: gpc@gnu.de, gpc-doc@gnu.de Subject: Re: help writing documentation References: <20001107104218.B16403@mond.dida.physik.uni-essen.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Sender: owner-gpc-doc@gnu.de Precedence: bulk Eike Lange wrote: > Hi! > > I would like to help writing documentation for gpc. > > My project, writing german documentation for gpc > died because nobody was interested helping me and its too > much for just one man. > > I would prefer to discuss documentation-related topics > on the gpc-doc-mailinglist (gpc-doc@gnu.de) . > > There are still some questions left: > > - Is Texinfo 4.0 ok? I think so. The current documentation works with 4.0 (might also work with older versions, but I didn't test it). I plan to use a new Texinfo version when it supports HTML better (i.e., supports splitting it into multiple files -- until then I use texi2html to generate the HTML). > - Which options do you use to create the diffs Those in the script/mkdiff script. Those who are going to work on the documentation regularly might want to ask Peter for write access to the doc directory in the CVS. > - Are there any documentation-standards, I have to recognize? I use the following rules (probably forgot some). GPC comes with a script check-doc that checks some of them. - General: - Should work with makeinfo, texi2html and texi2dvi, of course. -- Usually, it's enough to run makeinfo regularly and check the others only once in a while. TeX (run by texi2dvi) will sometimes warn about overfull hboxes -- but this is mostly a problem when mentioning long URLs. If there are errors, makeinfo seems to give the best error messages. - Use available Texinfo formatting as well as possible ;-), e.g. @samp for identifiers etc., @example for longer code examples (don't indent the complete examples -- i.e., of course, indent blocks within the code as usual, but start the main block at the first column). - Use logical formatting rather than physical formatting when possible (e.g. @samp etc., lists, tables rather than @tt, @sp or "space formatting"). - Write many index entries (with @cindex)... - Indicate omissions or questionable parts in the documentation with something like `@c @@@@ blah blah...', so future documentation writers will see the problems. (Or ask about them in the list...) - The GNU Coding Standards (chapter `Documentation' in standards.texi) also contain some hints. - Reference: - Sorted alphabetically (of course) - Complete entries (by comparing it with the compiler source where the keywords and built-in identifiers are "declared") -- sure, currently many entries are just skeletons, the scripts just checks that they're there... - Complete subscetions (Synopsis, Description, Conforming to, Example, See also) and cindex entry - Example programs: - Between `@example' ... `@end example' - They are extracted to files under docdemos in binary distributions automatically by the extract-doc-demos script. - Should compile without problems. (check-doc calls extract-doc-demos to extract them to a temporary directory and then tries to compile each of them, that's why running check-doc takes a while.) - Do not have to do any useful task when run (that's what the programs in the demos directory are for), just demonstrate how to do something for someone who reads them... - The first line after @example must contain `program', `module' or `unit' in the first column. The file (under docdemos) name will be the program/unit/module's name (converted to lower case, and with `.pas' appended). For non-Pascal files, the first line after @example must contain "File `filename.foo':". -- Currently, there's a lot of code fragments without such a heading line. For now, these fragments are ignored by extract-doc-demos. Whenever possible, they should be extended to a complete program. - A demo program for a identifier `Foo' (in the reference) should be called `FooDemo', and other demos (in other chapters) should usually also have names ending in `Demo'. - To cater for Dos systems, the names should be unique in the first 8 characters (they may be longer and will be truncated by Dos utilities). So, e.g., when you have several demos for `FooBar', call them `FooBar1Demo', `FooBar2Demo', etc., not `FooBarDemo1' etc. ... About the structure of the documentation: I think currently (apart from internals which is meant for GPC developers rather than users and not so important for now), all chapters except programming and reference are up to date and don't need much work. This is not as good as it sound since these are the two largest chapters... The structure of reference is clear (alphabetical list of all keyowrds and built-in identifeiers, see above). The structure of programming certainly needs improvement (several sections have been collected there from various places). Dominik (who should be on this list) told me he has some ideas and you probably have some, too, so perhaps we can discuss them here... Let me start: I think the last two sections (RTS and units) should be moved to a separate chapter (they're more like the reference, anyway). (The bpqstart chapter is IMHO quite ok currently, but if someone wants to add more about differences and common things between BP and GPC, this is welcome, too.) Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html From gpc-doc Thu Jan 01 00:00:00 2002 Delivered-To: gpc-doc@gerwinski.de Received: (qmail 3827 invoked from network); 7 Nov 2000 17:16:10 -0000 Received: from esmeralda.gerwinski.de (root@194.221.119.18) by tim.gerwinski.de with SMTP; 7 Nov 2000 17:16:10 -0000 Received: (from peter@localhost) by esmeralda.gerwinski.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id SAA25178 for gpc-doc@gnu.de; Tue, 7 Nov 2000 18:17:16 +0100 Received: (qmail 2598 invoked from network); 7 Nov 2000 16:09:42 -0000 Received: from mailout00.sul.t-online.com (194.25.134.16) by tim.gerwinski.de with SMTP; 7 Nov 2000 16:09:42 -0000 Received: from fwd07.sul.t-online.com by mailout00.sul.t-online.com with smtp id 13tBKj-0004ws-01; Tue, 07 Nov 2000 17:10:49 +0100 Received: from seibertz.de (0332378470-0001@[62.158.186.102]) by fwd07.sul.t-online.com with esmtp id 13tBKZ-0na1jcC; Tue, 7 Nov 2000 17:10:39 +0100 Received: (from egbert@localhost) Message-ID: <20001107171121.A922@sz> Date: Tue, 7 Nov 2000 17:11:21 +0100 From: Egbert Seibertz To: gpc@gnu.de, gpc-doc@gnu.de Subject: [egbert: Re: help writing documentation] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jI8keyz6grp/JLjh" X-Mailer: Mutt 0.93.2i X-Sender: 0332378470-0001@t-dialin.net Sender: owner-gpc-doc@gnu.de Precedence: bulk --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Cc forgotten ... Egbert --jI8keyz6grp/JLjh Content-Type: message/rfc822 Content-Description: Forwarded message from Egbert Seibertz Message-ID: <20001107170433.B811@sz> Date: Tue, 7 Nov 2000 17:04:33 +0100 From: Egbert Seibertz To: Eike Lange Subject: Re: help writing documentation References: <20001107104218.B16403@mond.dida.physik.uni-essen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <20001107104218.B16403@mond.dida.physik.uni-essen.de>; from Eike Lange on Tue, Nov 07, 2000 at 10:42:18AM +0100 On Tue, Nov 07, 2000 at 10:42:18AM +0100, Eike Lange wrote: > Hi! > > I would like to help writing documentation for gpc. > > My project, writing german documentation for gpc > died because nobody was interested helping me and its too > much for just one man. Sorry, I should do it, if you still interested, too. Egbert > > I would prefer to discuss documentation-related topics > on the gpc-doc-mailinglist (gpc-doc@gnu.de) . > > There are still some questions left: > > - Is Texinfo 4.0 ok? > - Which options do you use to create the diffs > - Are there any documentation-standards, I have to recognize? > > Eike --jI8keyz6grp/JLjh-- From gpc-doc Thu Jan 01 00:00:00 2002 Delivered-To: gpc-doc@gerwinski.de Received: (qmail 5568 invoked by uid 10); 15 Nov 2000 03:12:41 -0000 Received: from goedel.fjf.gnu.de (goedel.fjf.gnu.de [10.1.6.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id DAA30520; Wed, 15 Nov 2000 03:14:41 +0100 Date: Wed, 15 Nov 2000 03:14:41 +0100 From: Frank Heckenbach Message-Id: <24E8A81D.20001115031441.FOO-7736.frank@g-n-u.de> X-Mailer: smtphack 0.3.5 by Jan Andres To: gpc@gnu.de, gpc-doc@gnu.de Subject: Val MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Sender: owner-gpc-doc@gnu.de Precedence: bulk The GPC reference claims that the 3rd parameter of Val is optional: : procedure Val (const Source: String; var x: INTEGER OR REAL); : or : procedure Val (const Source: String; var x: INTEGER OR REAL; : var ErrorCode: Integer); However, that's not the case in GPC (neither in BP from which the Val procedure comes). Thanks to Nicola Girardi for pointing out this discrepancy. Though there are cases where one might want to ignore the 3rd parameter (such as if it was checked before calling Val that the string consists only of digits, or at least has a starting digit and one is willing to ignore trailing "garbage"), but IMHO they're rare enough that they don't justify another syntax extension. So I suggest to "fix" the documentation by removing the first part. -- Of course, I could've just done that, but perhaps someone disagrees... Also, maybe someone interested in writing/maintaining documentation might want to take this as a start (and perhaps write some words about Val in the reference while they're at it :-)... Minor note: The name of the parameter should by `ErrorPosition' rather than `ErrorCode' (the BP documentation also calls it `Code', but we shouldn't copy their mistakes, it's not a code, just a position)... Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html From gpc-doc Thu Jan 01 00:00:00 2002 Delivered-To: gpc-doc@gerwinski.de Received: (qmail 23040 invoked by uid 10); 14 Dec 2000 13:54:26 -0000 Received: from goedel.fjf.gnu.de (goedel.fjf.gnu.de [10.1.6.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id OAA05361; Thu, 14 Dec 2000 14:57:09 +0100 Date: Thu, 14 Dec 2000 14:57:09 +0100 From: Frank Heckenbach Message-Id: <336E03C7.20001214145709.FOO-14EF.frank@g-n-u.de> X-Mailer: smtphack 0.3.5 by Jan Andres To: gpc@gnu.de, gpc-doc@gnu.de Subject: Re: A very minor documentation error References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Sender: owner-gpc-doc@gnu.de Precedence: bulk Bernard Leak wrote: > Dear Sirs, Mesdames, Unspecified Neuters, and others: > > The heading to the page > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/gpc_4.html#SEC4 > 3.1 General Changes And Possible Incompatibilies To Previous Versions > > and the link to it on the page > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/news.html > > (there may be other links - I haven't searched) > is not in English (not even International English). > > It should read > > "Incompatibilies To" <- "Incompatibilities With" > > Normally, the preposition "With", articles and conjunctions > shouldn't be capitalised either, except at the start of a sentence. > The site is notably inconsistent in its capitalisation style, so > I feel free to suggest a merely local change. > > I propose a squeakily-clean replacement with > > 3.1 General Changes and Possible Incompatibilities with Previous Versions Thanks. These kinds of errors are due to the fact that most of the writers and editors of the documentation are non-native speakers, and I (who wrote this section, AFAIR) have never learnt the rules for capitalizing headlines and such... If you'd like to offer more help in these matters, this would be very welcome. The preferred form for making such changes is to start with the Texinfo files (part of GPC source distributions and available through CVS) and send diffs to the gpc-doc mailing list (to which I'm sending a CC of this mail). Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html From gpc-doc Thu Jan 01 00:00:00 2002 Delivered-To: gpc-doc@gerwinski.de Received: (qmail 642 invoked from network); 9 Mar 2001 08:57:17 -0000 Received: from mond.dida.physik.uni-essen.de (132.252.78.233) by tim.gerwinski.de with SMTP; 9 Mar 2001 08:57:17 -0000 Received: from lange by mond.dida.physik.uni-essen.de with local (Exim 3.12 #1 (Debian)) id 14bIkK-0002YX-00 for ; Fri, 09 Mar 2001 09:59:36 +0100 Date: Fri, 9 Mar 2001 09:59:36 +0100 From: Eike Lange To: gpc-doc@gnu.de Subject: Re: help writing documentation Message-ID: <20010309095936.B9647@mond.dida.physik.uni-essen.de> References: <20001107104218.B16403@mond.dida.physik.uni-essen.de> <1315CF98.20001107160946.FOO-22B6.frank@g-n-u.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1315CF98.20001107160946.FOO-22B6.frank@g-n-u.de>; from frank@g-n-u.de on Tue, Nov 07, 2000 at 04:09:46PM +0100 Sender: owner-gpc-doc@gnu.de Precedence: bulk Hi! Now I done with some work and like to write some documentation. I'd like to care about programming->data types. How did you organize the work, when more than one is working on a file? To whom do I have to send the diffs? Eike From gpc-doc Thu Jan 01 00:00:00 2002 Delivered-To: gpc-doc@gerwinski.de Received: (qmail 2233 invoked by uid 10); 9 Mar 2001 12:29:56 -0000 Received: from goedel.fjf.gnu.de (goedel.fjf.gnu.de [10.1.6.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id KAA27254 for ; Fri, 9 Mar 2001 10:49:20 +0100 Date: Fri, 9 Mar 2001 10:49:20 +0100 From: Frank Heckenbach Message-Id: <258B3E0F.20010309104920.FOO-6A74.frank@g-n-u.de> X-Mailer: smtphack 0.3.5 by Jan Andres To: gpc-doc@gnu.de Subject: Re: help writing documentation References: <20001107104218.B16403@mond.dida.physik.uni-essen.de> <1315CF98.20001107160946.FOO-22B6.frank@g-n-u.de> <20010309095936.B9647@mond.dida.physik.uni-essen.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Sender: owner-gpc-doc@gnu.de Precedence: bulk Eike Lange wrote: > Now I done with some work and like to write some documentation. > I'd like to care about programming->data types. Fine. :-) > How did you organize the work, when more than one is working > on a file? Quite frankly, this situation hasn't occurred very often yet. Since we have the gpc-doc list, I suggest you post a short note saying what you're going to modify and if anyone else is working on the same things, they will tell you. (Simultaneous changes to different parts of a file are usually no problem, the patches will apply with some offset, so the danger is not too big, I think...) > To whom do I have to send the diffs? I suppose Peter or me. Well, since Peter is always so busy, probably me... Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html From gpc-doc Thu Jan 01 00:00:00 2002 Delivered-To: gpc-doc@gerwinski.de Received: (qmail 21034 invoked by uid 10); 29 Jun 2001 22:09:33 -0000 Received: (from peter@localhost) by miez.drewitz.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id AAA19313 for gpc-doc@gnu.de; Sat, 30 Jun 2001 00:11:19 +0200 Received: (qmail 706 invoked from network); 29 Jun 2001 00:49:26 -0000 Received: from 44615166.theo-phys.uni-essen.de (HELO 44615166) (132.252.73.246) by tim.gerwinski.de with SMTP; 29 Jun 2001 00:49:26 -0000 Received: (from anja@localhost) by 44615166 (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) id f5T03jd21858; Fri, 29 Jun 2001 02:03:45 +0200 Date: Fri, 29 Jun 2001 02:03:45 +0200 From: Anja Gerwinski To: CandiChat , GNU Pascal Mailingliste , gpc-doc@gnu.de Subject: server moving this Friday (June 29) Message-ID: <20010629020345.B21813@44615166.theo-phys.uni-essen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-gpc-doc@gnu.de Precedence: bulk Hello, folks, tomorrow (Friday) our mailing lists and web pages are moving to our new server adele (.gerwinski.de). Maybe the mailing lists will not be available for a brief time; they should be running again in the evening. I'll let you know via the list when we are finished. If afterwards mail is not delivered via the list as it should please let me know . Best wishes, Anja From gpc-doc-owner@gnu.de Wed Jul 11 08:13:31 2001 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.12 #1 (Debian)) id 15KDFQ-0000FR-00; Wed, 11 Jul 2001 08:13:20 +0200 Received: (from peter@localhost) by miez.drewitz.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id IAA01649; Wed, 11 Jul 2001 08:13:50 +0200 Date: Wed, 11 Jul 2001 08:13:50 +0200 From: Peter Gerwinski To: gpc@gnu.de, gpc-doc@gnu.de, grx@gnu.de, gpc-de@gnu.de Subject: email problems Message-ID: <20010711081350.B1374@miez.drewitz.de> Mail-Followup-To: gpc@gnu.de, gpc-doc@gnu.de, grx@gnu.de, gpc-de@gnu.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Archive-Number: 200107/1 X-Sequence-Number: 1 Hello, during the last 36 hours emails to this list were not delivered. The problem is fixed now. In case you have unsuccessfully tried to post to the list, please retry now. In den letzten 36 Stunden wurde E-Mails an diese Liste nicht zugestellt. Das Problem ist jetzt behoben. Wer in diesem Zeitraum vergeblich versucht hat, E-Mail an die Liste zu schicken, kann es jetzt noch einmal probieren. Peter -- http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-20010623 GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422 keys: http://www.gerwinski.de/pubkeys/ - AntiSpam: http://spam.abuse.net From gpc-doc-owner@gnu.de Fri Jul 13 14:51:24 2001 Received: from mail.keycomm.it ([::ffff:62.152.33.7]) by adele.gerwinski.de with esmtp (Exim 3.12 #1 (Debian)) id 15L2Pe-0004mu-00 for ; Fri, 13 Jul 2001 14:51:18 +0200 Received: from ip-a1-35086.keycomm.it (mail@ip-a1-35086.keycomm.it [62.152.35.86]) by mail.keycomm.it (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id OAA10272 for ; Fri, 13 Jul 2001 14:43:43 +0200 Received: from 127.0.0.1 by darkstar.linux.bogus with esmtp (MasqMail 0.1.14) id 15L2Oi-4F9-00 for gpc-doc@gnu.de; Fri, 13 Jul 2001 14:50:21 +0200 Subject: GNU Pascal Coding Standards MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii From: Nicola Girardi To: gpc-doc@gnu.de X-Mailer: semail 0.06 Date: Fri, 13 Jul 2001 14:50:21 +0200 Message-ID: <15L2Oi-4F9-00@darkstar.linux.bogus> X-Archive-Number: 200107/2 X-Sequence-Number: 2 Hi GPC'ers! This is to announce the first public release of the GNU Pascal Coding Standards. The aim of this document is extending the GNU Coding Standards with specific information relating Pascal programming. Of course there are topics that can be shared between the two manuals, and we have taken this into account. You are encouraged to read the manual and follow the suggestions you find, fix the bugs (yes, there can be bugs in documentation, most times disguised as typos ;-)) and discuss the several issues raised. You can find the standards online at: http://adele.gerwinski.de/~nicola/pascal-standards/ NB: We're sorry for the long HTML file, but if we use texi2html to split the files we get many links pointing to the same document instead of pointing to the GNU Coding Standards, to which we refer often. Greetings, Frank Heckenbach Peter Gerwinski Nicola Girardi From gpc-doc-owner@gnu.de Fri Jul 13 15:34:30 2001 Received: from vaak.stack.nl ([::ffff:131.155.140.140] helo=mailhost.stack.nl) by adele.gerwinski.de with esmtp (Exim 3.12 #1 (Debian)) id 15L35Q-0004uP-00 for ; Fri, 13 Jul 2001 15:34:28 +0200 Received: from toad.stack.nl (toad.stack.nl [2001:610:1108:5010:200:e8ff:fe55:346d]) by mailhost.stack.nl (Postfix) with ESMTP id 001143D81F for ; Fri, 13 Jul 2001 15:34:23 +0200 (CEST) Received: by toad.stack.nl (Postfix, from userid 816) id BCC1F96A2; Fri, 13 Jul 2001 15:34:23 +0200 (CEST) Subject: GNU Pascal Coding stuff To: gpc-doc@gnu.de Date: Fri, 13 Jul 2001 15:34:23 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20010713133423.BCC1F96A2@toad.stack.nl> From: marcov@stack.nl (Marco van de Voort) X-Archive-Number: 200107/3 X-Sequence-Number: 3 Quick read it, will further comment later, some quick stuff: - You discourage the use of (*, because displaying "(" would be difficult on some terminals, but afaik { is also? - The document itself has no copyright statement. From gpc-doc-owner@gnu.de Fri Jul 13 22:56:14 2001 Received: from 063-151-108-039.pc.ashlandfiber.net ([::ffff:63.151.108.39] helo=rusty.russwhit.com) by adele.gerwinski.de with esmtp (Exim 3.12 #1 (Debian)) id 15L9ys-00068A-00 for ; Fri, 13 Jul 2001 22:56:10 +0200 Received: from localhost (russ@localhost) by rusty.russwhit.com (8.10.2/8.10.2) with ESMTP id f6DL5j600389 for ; Fri, 13 Jul 2001 14:05:45 -0700 X-Authentication-Warning: rusty.russwhit.com: russ owned process doing -bs Date: Fri, 13 Jul 2001 14:05:44 -0700 (PDT) From: Russ Whitaker X-Sender: russ@rusty.russwhit.com To: gpc-doc@gnu.de Subject: Standards.text Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200107/4 X-Sequence-Number: 4 Hi Printed out a copy of the pascal-standards.text: 1. Table of Contents is at wrong end. 2. Suggest changing " aString: String " to " S: String " You have 2 lines that are 100 cols in length. While most printing defaults to 80 cols for 8.5 inch paper you can set printer to elite which gives you 96 cols without line wrap. (I prefer 90 cols max so I can have an extra margin for 3 hole punch.) Yes I know you can't always keep the line length to 96 or less and have the results look neat, but at least this change will help at times. Russ From gpc-doc-owner@gnu.de Fri Jul 13 23:02:30 2001 Received: from mail.keycomm.it ([::ffff:62.152.33.7]) by adele.gerwinski.de with esmtp (Exim 3.12 #1 (Debian)) id 15LA4x-00068w-00 for ; Fri, 13 Jul 2001 23:02:27 +0200 Received: from ip-a1-35082.keycomm.it (mail@ip-a1-35082.keycomm.it [62.152.35.82]) by mail.keycomm.it (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id WAA17618 for ; Fri, 13 Jul 2001 22:54:50 +0200 Received: from 127.0.0.1 by darkstar.linux.bogus with esmtp (MasqMail 0.1.14) id 15L7Hm-041-00 for gpc-doc@gnu.de; Fri, 13 Jul 2001 20:03:30 +0200 Subject: Re: GNU Pascal Coding stuff MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii From: Nicola Girardi To: gpc-doc@gnu.de References: <20010713133423.BCC1F96A2@toad.stack.nl> X-Mailer: semail 0.06 Date: Fri, 13 Jul 2001 20:03:30 +0200 Message-ID: <15L7Hm-041-00@darkstar.linux.bogus> X-Archive-Number: 200107/5 X-Sequence-Number: 5 > - You discourage the use of (*, because displaying "(" would be > difficult on some terminals, but afaik { is also? We discourage old style comments like (* this *) because in fact `{' and `}' are available everywhere these days. I tried to grep the document but don't see where you got this from... > - The document itself has no copyright statement. If you're reading the HTML version this is true. There are copyright statements in the Texinfo source, though, but this might not be enough. However, I see that also the HTML online version of the GNU Coding Standards doesn't hold a copyright notice, either. Maybe we can add it to our HTML version, though. Frank or Peter, what do you think? Thanks for the feedback! Best regards, Nick From gpc-doc-owner@gnu.de Fri Jul 13 23:05:24 2001 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.12 #1 (Debian)) id 15LA7b-0006Ax-00 for ; Fri, 13 Jul 2001 23:05:11 +0200 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id WAA00969 for ; Fri, 13 Jul 2001 22:40:36 +0200 Date: Fri, 13 Jul 2001 22:40:36 +0200 Message-Id: <200107132040.WAA00969@goedel.fjf.gnu.de> Subject: Re: GNU Pascal Coding stuff MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii From: Frank Heckenbach To: gpc-doc@gnu.de References: <20010713133423.BCC1F96A2@toad.stack.nl> X-Mailer: semail 0.06 X-Archive-Number: 200107/6 X-Sequence-Number: 6 Marco van de Voort wrote: > - You discourage the use of (*, because displaying "(" would be difficult on > some terminals, but afaik { is also? Nope. What we mean is: The (* *) comments (just like (. .) for array indexing etc.) were introduced in the language because at that time { }, [ ] etc. were difficult on some terminals. Today, this isn't an issue anymore, therefore we use the "original" (and shorter) forms { } and [ ]. If that wasn't clear, it should be written more extensive in the text. > - The document itself has no copyright statement. It does, once in @ifinfo, and once in @titlepage (which appears only in the TeXed versions), so it's indeed missing in the HTML version. Nick, you might want to try s/@ifinfo/@ifnottex/ or something. (Though my texinfo manual suggests what you did, but it might be from a time where HTML output was not supported.) Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html From gpc-doc-owner@gnu.de Fri Jul 13 23:19:22 2001 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.12 #1 (Debian)) id 15LALH-0006KJ-00 for ; Fri, 13 Jul 2001 23:19:19 +0200 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id XAA03592 for ; Fri, 13 Jul 2001 23:12:34 +0200 Date: Fri, 13 Jul 2001 23:12:34 +0200 Message-Id: <200107132112.XAA03592@goedel.fjf.gnu.de> Subject: Re: Standards.text MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii From: Frank Heckenbach To: gpc-doc@gnu.de References: X-Mailer: semail 0.06 X-Archive-Number: 200107/7 X-Sequence-Number: 7 Russ Whitaker wrote: > Printed out a copy of the pascal-standards.text: > > 1. Table of Contents is at wrong end. That's a general problem of Texinfo in TeX mode (don't know really why, since LaTeX manages to put it at the right end). Anyway, I wrote a script to reorder the DVI file. It's called dvi-reorder, and it's in p/script in GPC sources. It requires dviutils (dviselect and dviconcat). > 2. Suggest changing " aString: String " to " S: String " Indeed. I copied these lines (as an example) from older code which does not conform to our rules about identifier names. > You have 2 lines that are 100 cols in length. While most printing > defaults to 80 cols for 8.5 inch paper you can set printer to elite > which gives you 96 cols without line wrap. (I prefer 90 cols max so > I can have an extra margin for 3 hole punch.) > > Yes I know you can't always keep the line length to 96 or less and > have the results look neat, but at least this change will help at > times. Yes, line width is a difficult issue which is why we don't give fixed rules there. In this particular example, it's probably better to avoid the problem (just delete the last two lines, I think the other ones already make the point clear). Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html From gpc-doc-owner@gnu.de Fri Jul 13 23:23:57 2001 Received: from 063-151-108-039.pc.ashlandfiber.net ([::ffff:63.151.108.39] helo=rusty.russwhit.com) by adele.gerwinski.de with esmtp (Exim 3.12 #1 (Debian)) id 15LAPi-0006LV-00 for ; Fri, 13 Jul 2001 23:23:54 +0200 Received: from localhost (russ@localhost) by rusty.russwhit.com (8.10.2/8.10.2) with ESMTP id f6DLXYr00423 for ; Fri, 13 Jul 2001 14:33:34 -0700 X-Authentication-Warning: rusty.russwhit.com: russ owned process doing -bs Date: Fri, 13 Jul 2001 14:33:34 -0700 (PDT) From: Russ Whitaker X-Sender: russ@rusty.russwhit.com To: gpc-doc@gnu.de Subject: Re: GNU Pascal Coding stuff In-Reply-To: <200107132040.WAA00969@goedel.fjf.gnu.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200107/8 X-Sequence-Number: 8 On Fri, 13 Jul 2001, Frank Heckenbach wrote: > Marco van de Voort wrote: > > > - You discourage the use of (*, because displaying "(" would be difficult on > > some terminals, but afaik { is also? > > Nope. What we mean is: The (* *) comments (just like (. .) for array > indexing etc.) were introduced in the language because at that time > { }, [ ] etc. were difficult on some terminals. > > Today, this isn't an issue anymore, therefore we use the "original" > (and shorter) forms { } and [ ]. Good idea. However, hope you don't remove support for (* *) because during developement it's a handy way to comment out a block of code - especially if the block contains { } Russ From gpc-doc-owner@gnu.de Fri Jul 13 23:39:43 2001 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.12 #1 (Debian)) id 15LAey-0006OD-00 for ; Fri, 13 Jul 2001 23:39:40 +0200 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id XAA09426 for ; Fri, 13 Jul 2001 23:38:37 +0200 Date: Fri, 13 Jul 2001 23:38:37 +0200 Message-Id: <200107132138.XAA09426@goedel.fjf.gnu.de> Subject: Re: GNU Pascal Coding stuff MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii From: Frank Heckenbach To: gpc-doc@gnu.de References: X-Mailer: semail 0.06 X-Archive-Number: 200107/9 X-Sequence-Number: 9 Russ Whitaker wrote: > On Fri, 13 Jul 2001, Frank Heckenbach wrote: > > > Marco van de Voort wrote: > > > > > - You discourage the use of (*, because displaying "(" would be difficult on > > > some terminals, but afaik { is also? > > > > Nope. What we mean is: The (* *) comments (just like (. .) for array > > indexing etc.) were introduced in the language because at that time > > { }, [ ] etc. were difficult on some terminals. > > > > Today, this isn't an issue anymore, therefore we use the "original" > > (and shorter) forms { } and [ ]. > > Good idea. However, hope you don't remove support for (* *) Of course not! That would be quite a break of all existing Pascal standards and non-standards. These are merely guidelines, not plans for modifications of the compiler. > because > during developement it's a handy way to comment out a block of code > - especially if the block contains { } Yes -- though there's also {$if False} ... {$endif} (which we actually recommend since it also can be nested etc.). Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html From gpc-doc-owner@gnu.de Fri Jul 13 23:47:54 2001 Received: from mail.keycomm.it ([::ffff:62.152.33.7]) by adele.gerwinski.de with esmtp (Exim 3.12 #1 (Debian)) id 15LAmt-0006Pz-00 for ; Fri, 13 Jul 2001 23:47:51 +0200 Received: from ip-a1-35080.keycomm.it (mail@ip-a1-35080.keycomm.it [62.152.35.80]) by mail.keycomm.it (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id XAA17939 for ; Fri, 13 Jul 2001 23:40:15 +0200 Received: from 127.0.0.1 by darkstar.linux.bogus with esmtp (MasqMail 0.1.14) id 15LAmR-37e-00 for gpc-doc@gnu.de; Fri, 13 Jul 2001 23:47:23 +0200 Subject: Re: Standards.text MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii From: Nicola Girardi To: gpc-doc@gnu.de References: X-Mailer: semail 0.06 Date: Fri, 13 Jul 2001 23:47:23 +0200 Message-ID: <15LAmR-37e-00@darkstar.linux.bogus> X-Archive-Number: 200107/10 X-Sequence-Number: 10 Hi Russ, > 1. Table of Contents is at wrong end. I don't have clues how to tell `makeinfo' to put it where it belongs. I noticed now that there's the same problem in the HTML version, caused again by `makeinfo'. Any suggestion? > 2. Suggest changing " aString: String " to " S: String " Not really. First of all, according the the GPCS (short for GNU Pascal Coding Standards) "S: String" should be "s: String". (Of course nobody can force anyone to apply the GPCS, they are just advice.) Secondly, "aString" is the result of a rule we haven't yet defined. It's the only one which hasn't been defined yet. If you grep for "FIXME" you'll find just one instance of it and you can read what it's about. I'll save you the grep which is hard for a printed copy. :-)) : In object oriented code (especially often in constructors), there is : often the need to have a parameter correspond to an object field : (e.g., to pass a value with which to initialize the field). Since : both can't be called the same, the field should have the ``natural'' : name since it's usually used in more routines, and the parameter : name should be ``mangled''. FIXME: We haven't found a really : satisfactory rule for mangling yet (some use ``a'' as a prefix), and : if you have any good idea, let us know. > You have 2 lines that are 100 cols in length. I fixed those lines. I also tried to solve the problem for the lines of code by choosing another appropriate example from the GPC sources which doesn't need such long lines. Thanks, Nick From gpc-doc-owner@gnu.de Sat Jul 14 00:08:27 2001 Received: from mail.keycomm.it ([::ffff:62.152.33.7]) by adele.gerwinski.de with esmtp (Exim 3.12 #1 (Debian)) id 15LB6j-0006UB-00 for ; Sat, 14 Jul 2001 00:08:21 +0200 Received: from ip-a1-35080.keycomm.it (mail@ip-a1-35080.keycomm.it [62.152.35.80]) by mail.keycomm.it (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id AAA18230 for ; Sat, 14 Jul 2001 00:00:46 +0200 Received: from 127.0.0.1 by darkstar.linux.bogus with esmtp (MasqMail 0.1.14) id 15LB5y-3Aq-00 for gpc-doc@gnu.de; Sat, 14 Jul 2001 00:07:34 +0200 Subject: Re: GNU Pascal Coding stuff References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii From: Nicola Girardi To: gpc-doc@gnu.de X-Mailer: semail 0.06 Date: Sat, 14 Jul 2001 00:07:34 +0200 Message-ID: <15LB5y-3Aq-00@darkstar.linux.bogus> X-Archive-Number: 200107/11 X-Sequence-Number: 11 > Nick, you might want to try s/@ifinfo/@ifnottex/ or something. I'm trying to fix this problem. Well, there's a problem with a "

" being inserted after the `G' of "GNU" for no good reason... > > 2. Suggest changing " aString: String " to " S: String " > > Indeed. I copied these lines (as an example) from older code which > does not conform to our rules about identifier names. Is this OK? : @example : @{ Port access functions @} : function InPortB (PortNumber: ShortWord): Byte; : function InPortW (PortNumber: ShortWord): ShortWord; : procedure OutPortB (PortNumber: ShortWord; aValue : Byte); : procedure OutPortW (PortNumber, aValue: ShortWord); : @end example Best regards, Nick From gpc-doc-owner@gnu.de Sat Jul 14 12:58:42 2001 Received: from mail.keycomm.it ([::ffff:62.152.33.7]) by adele.gerwinski.de with esmtp (Exim 3.12 #1 (Debian)) id 15LB6k-0006UH-00 for ; Sat, 14 Jul 2001 00:08:22 +0200 Received: from ip-a1-35080.keycomm.it (mail@ip-a1-35080.keycomm.it [62.152.35.80]) by mail.keycomm.it (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id AAA18233 for ; Sat, 14 Jul 2001 00:00:46 +0200 Received: from 127.0.0.1 by darkstar.linux.bogus with esmtp (MasqMail 0.1.14) id 15LB6C-3BA-00 for gpc-doc@gnu.de; Sat, 14 Jul 2001 00:07:48 +0200 Subject: Re: GNU Pascal Coding stuff MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii From: Nicola Girardi To: gpc-doc@gnu.de References: <20010713133423.BCC1F96A2@toad.stack.nl> <200107132040.WAA00969@goedel.fjf.gnu.de> X-Mailer: semail 0.06 Date: Sat, 14 Jul 2001 00:07:48 +0200 Message-ID: <15LB6C-3BA-00@darkstar.linux.bogus> X-Archive-Number: 200107/12 X-Sequence-Number: 12 > Nick, you might want to try s/@ifinfo/@ifnottex/ or something. I'm trying to fix this problem. Well, there's a problem with a "

" being inserted after the `G' of "GNU" for no good reason... > > 2. Suggest changing " aString: String " to " S: String " > > Indeed. I copied these lines (as an example) from older code which > does not conform to our rules about identifier names. Is this OK? : @example : @{ Port access functions @} : function InPortB (PortNumber: ShortWord): Byte; : function InPortW (PortNumber: ShortWord): ShortWord; : procedure OutPortB (PortNumber: ShortWord; aValue : Byte); : procedure OutPortW (PortNumber, aValue: ShortWord); : @end example Best regards, Nick From gpc-doc-owner@gnu.de Sat Jul 14 13:36:20 2001 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.12 #1 (Debian)) id 15LNia-0008AZ-00 for ; Sat, 14 Jul 2001 13:36:16 +0200 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id NAA09398 for ; Sat, 14 Jul 2001 13:32:36 +0200 Date: Sat, 14 Jul 2001 13:32:36 +0200 Message-Id: <200107141132.NAA09398@goedel.fjf.gnu.de> Subject: Re: Standards.text MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii From: Frank Heckenbach To: gpc-doc@gnu.de References: <15LAmR-37e-00@darkstar.linux.bogus> <20010713133423.BCC1F96A2@toad.stack.nl> <200107132040.WAA00969@goedel.fjf.gnu.de> <15LB6C-3BA-00@darkstar.linux.bogus> X-Mailer: semail 0.06 X-Archive-Number: 200107/13 X-Sequence-Number: 13 Nicola Girardi wrote: > Not really. First of all, according the the GPCS (short for GNU > Pascal Coding Standards) "S: String" should be "s: String". (Of > course nobody can force anyone to apply the GPCS, they are just > advice.) Secondly, "aString" is the result of a rule we haven't yet > defined. It's the only one which hasn't been defined yet. If you > grep for "FIXME" you'll find just one instance of it and you can > read what it's about. I'll save you the grep which is hard for a > printed copy. :-)) > > : In object oriented code (especially often in constructors), there is > : often the need to have a parameter correspond to an object field > : (e.g., to pass a value with which to initialize the field). Since > : both can't be called the same, the field should have the ``natural'' > : name since it's usually used in more routines, and the parameter > : name should be ``mangled''. FIXME: We haven't found a really > : satisfactory rule for mangling yet (some use ``a'' as a prefix), and > : if you have any good idea, let us know. But this (yet to be resolved) rule is only for OOP. Using `aString' in these routines here is really not good (I wrote this a long time ago), so I'm changing it to `s'. > > > 2. Suggest changing " aString: String " to " S: String " > > > > Indeed. I copied these lines (as an example) from older code which > > does not conform to our rules about identifier names. > > Is this OK? > > : @example > : @{ Port access functions @} > : function InPortB (PortNumber: ShortWord): Byte; > : function InPortW (PortNumber: ShortWord): ShortWord; > : procedure OutPortB (PortNumber: ShortWord; aValue : Byte); > : procedure OutPortW (PortNumber, aValue: ShortWord); > : @end example I wouldn't recommend it. The port functions are the (only) nonportable unit that comes with GPC, so it's not a good example. I suggest: function Pos (const SubString, s: String): Integer; function LastPos (const SubString, s: String): Integer; function PosCase (const SubString, s: String): Integer; function LastPosCase (const SubString, s: String): Integer; function CharPos (const Chars: CharSet; const s: String): Integer; function LastCharPos (const Chars: CharSet; const s: String): Integer; function PosFrom (const SubString, s: String; From: Integer): Integer; function LastPosTill (const SubString, s: String; Till: Integer): Integer; function PosFromCase (const SubString, s: String; From: Integer): Integer; function LastPosTillCase (const SubString, s: String; Till: Integer): Integer; Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html From gpc-doc-owner@gnu.de Sat Jul 14 15:13:08 2001 Received: from mail.keycomm.it ([::ffff:62.152.33.7]) by adele.gerwinski.de with esmtp (Exim 3.12 #1 (Debian)) id 15LPEG-0008Q6-00 for ; Sat, 14 Jul 2001 15:13:04 +0200 Received: from ip-a1-35087.keycomm.it (mail@ip-a1-35087.keycomm.it [62.152.35.87]) by mail.keycomm.it (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id PAA22721 for ; Sat, 14 Jul 2001 15:05:26 +0200 Received: from 127.0.0.1 by darkstar.linux.bogus with esmtp (MasqMail 0.1.14) id 15LP9U-0BV-00 for gpc-doc@gnu.de; Sat, 14 Jul 2001 15:08:08 +0200 Subject: Re: Standards.text MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii From: Nicola Girardi To: gpc-doc@gnu.de References: <15LAmR-37e-00@darkstar.linux.bogus> <20010713133423.BCC1F96A2@toad.stack.nl> <200107132040.WAA00969@goedel.fjf.gnu.de> <15LB6C-3BA-00@darkstar.linux.bogus> <200107141132.NAA09398@goedel.fjf.gnu.de> X-Mailer: semail 0.06 Date: Sat, 14 Jul 2001 15:08:08 +0200 Message-ID: <15LP9U-0BV-00@darkstar.linux.bogus> X-Archive-Number: 200107/14 X-Sequence-Number: 14 Frank Heckenbach wrote: > > : @example > > : @{ Port access functions @} > > : function InPortB (PortNumber: ShortWord): Byte; > > : function InPortW (PortNumber: ShortWord): ShortWord; > > : procedure OutPortB (PortNumber: ShortWord; aValue : Byte); > > : procedure OutPortW (PortNumber, aValue: ShortWord); > > : @end example > > I wouldn't recommend it. The port functions are the (only) ^^^^ Whoa this demonstrates what a lucky guy I am. > nonportable unit that comes with GPC, so it's not a good example. I > suggest: [...] Inserted. > function LastPosTillCase (const SubString, s: String; Till: Integer): Integer; You might also want to put only a space between "function" and the function name. (I know you won't do this in the actual source because there probably is some "procedure" but I'll do it in the manual.) Best wishes, Nick From gpc-doc-owner@gnu.de Sat Jul 14 20:11:22 2001 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.12 #1 (Debian)) id 15LTst-0000rm-00 for ; Sat, 14 Jul 2001 20:11:19 +0200 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id SAA10082 for ; Sat, 14 Jul 2001 18:36:29 +0200 Date: Sat, 14 Jul 2001 18:36:29 +0200 Message-Id: <200107141636.SAA10082@goedel.fjf.gnu.de> Subject: Re: Standards.text MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii From: Frank Heckenbach To: gpc-doc@gnu.de References: <20010713133423.BCC1F96A2@toad.stack.nl> <200107132040.WAA00969@goedel.fjf.gnu.de> <15LB6C-3BA-00@darkstar.linux.bogus> <200107141132.NAA09398@goedel.fjf.gnu.de> <15LP9U-0BV-00@darkstar.linux.bogus> X-Mailer: semail 0.06 X-Archive-Number: 200107/15 X-Sequence-Number: 15 Nicola Girardi wrote: > You might also want to put only a space between "function" and the > function name. (I know you won't do this in the actual source because > there probably is some "procedure" Exactly. > but I'll do it in the manual.) OK. Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html From gpc-doc-owner@gnu.de Tue Jan 28 07:17:09 2003 Received: from smtp1.clear.net.nz ([203.97.33.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18dP1m-0007Sb-00 for ; Tue, 28 Jan 2003 07:15:23 +0100 Received: from [203.167.181.140] (203-167-181-140.dialup.clear.net.nz [203.167.181.140]) by smtp1.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0H9E00DFAUN6YQ@smtp1.clear.net.nz> for gpc-doc@gnu.de; Tue, 28 Jan 2003 19:13:56 +1300 (NZDT) Date: Tue, 28 Jan 2003 19:15:41 +1300 From: Grant Jacobs Subject: subscribe X-Sender: grant.jacobs@pop.clear.net.nz To: gpc-doc@gnu.de Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii X-Archive-Number: 200301/1 X-Sequence-Number: 16 subscribe -- -------------------------------------------------------- Grant Jacobs grant.jacobs@clear.net.nz McAndrew Bay, Dunedin, ph. +64 3 476 1820 NEW ZEALAND. fax. +64 3 476 1825 From gpc-doc-owner@gnu.de Wed Jan 29 05:53:41 2003 Received: from smtp2.clear.net.nz ([203.97.37.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18dkC7-0001nk-00 for ; Wed, 29 Jan 2003 05:51:28 +0100 Received: from [203.167.170.18] (203-167-170-18.dialup.clear.net.nz [203.167.170.18]) by smtp2.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0H9G0034GLHNT6@smtp2.clear.net.nz> for gpc-doc@gnu.de; Wed, 29 Jan 2003 17:51:24 +1300 (NZDT) Date: Wed, 29 Jan 2003 17:53:12 +1300 From: Grant Jacobs Subject: subscribe X-Sender: biot/grant.jacobs@pop.clear.net.nz To: gpc-doc@gnu.de Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii X-Archive-Number: 200301/2 X-Sequence-Number: 17 subscribe -- -------------------------------------------------------- Grant Jacobs grant.jacobs@clear.net.nz McAndrew Bay, Dunedin, ph. +64 3 476 1820 NEW ZEALAND. fax. +64 3 476 1825 From gpc-doc-owner@gnu.de Wed Jan 29 13:16:07 2003 Received: from smtp1.clear.net.nz ([203.97.33.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18dPVP-0007bF-00 for ; Tue, 28 Jan 2003 07:46:00 +0100 Received: from [203.167.181.140] (203-167-181-140.dialup.clear.net.nz [203.167.181.140]) by smtp1.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0H9E00GKFW2277@smtp1.clear.net.nz> for gpc-doc@gnu.de; Tue, 28 Jan 2003 19:44:32 +1300 (NZDT) Date: Tue, 28 Jan 2003 19:46:12 +1300 From: Grant Jacobs Subject: Some observations [GHJ] X-Sender: grant.jacobs@pop.clear.net.nz To: gpc-doc@gnu.de Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii X-Archive-Number: 200301/3 X-Sequence-Number: 18 Shifting this thread over from gpc@gnu.de... (excuse the length of this) At 3:04 AM +0100 28/1/03, Frank Heckenbach wrote: >Grant Jacobs wrote: > >> A few observations from trying out gpc (Linux). >> >> 1. --interface-only -c doesn't (always) produce a .o as the docs >> say, > >Where does it say so? Oh, you mean in the `-c' description. OK, the >`--interface-only' description should make it clearer that it >overrides `-c' in this regard. (To me, "compiling the interface" is >clear enough to mean producing only a gpi file, but probably not to >everyone ... ;-) If you try use --interface-only on its own, the compiler stops and says you must use either -c or -S with it. So I presumed (always a bad thing to do!) after reading the -c description that your interface modules are stored as object files. (see below, also) > > but rather only a .gpi (and a .gpm in the case of modules), at >> least in my case. > >I think that's reasonable behaviour, and the docs should be >adjusted. Yes, I agree the behaviour is OK; Its the docs that need attending to! I wasn't actually meaning to complain about the behaviour. > > Either that, or its placing the object files >> somewhere else on my system! In turn, this seems to block me from >> compiling with units or modules unless I use --autobuild on the main >> program to force the issue, so to speak. > >Maybe you misunderstand the purpose of the option. It means to >process only the interface part of a unit/module. Of course, you >generally don't get a complete program without the implementation. I sort-of got this right the first time around ;-) The reason I went astray, was that I expected that compiling a unit would produce an object file, which would later be linked in when the main was compiled. In practice, none of the units I've tried compile fully on their own. You get complaints about undefined main, etc., which lead me to thinking that there much be some sort of compiler switch that'd tell it to not look for / create a main function, just create an object file 9library if that suits you better) to later be linked to a main program. That, in turn, lead me to fiddling around with different options. Which... you get the drift, anyway. This is why a description of how to compile units/modules would have helped... I suppose there is something down in the description of generation of .gpi/.gpm files that might have caused the penny to drop. But currently there appears to be nothing explicit says how its supposed to work. >`--interface-only' is only useful (necessary) in situations with >circular unit/module dependencies, e.g., A's interface uses B, and >B's implementation uses A. The only way to compile this is to first >compile B with `--interface-only', then A and B again without the >option. This paragraph ought to be inserted into the docs in the --interface-only description! (Nicely, worded - thanks.) > > 2. The blocksize parameter to reset() appears not to be optional (as >> the doc says it is) > >: Reset >: >: Like @samp{Rewrite}, @samp{Append} and @samp{Extend} do, >: @samp{Reset} accepts an optional second and third parameter for the >: name of the file in the filesystem and, for untyped files, the block >: size of the file. (For details, see @ref{Rewrite}.) > >: Rewrite >: >: The last optional parameter determines the block size of the file. >: It is valid only for untyped files. Almost always, 1 is the most >: reasonable value here. However, the existence of this parameter is a >: BP compatibility feature, and in BP it defaults to 128 because of >: historic misdesign. Therefore, GPC requires this parameter to be >: present. In @samp{--borland-pascal} mode, it makes it optional (like >: BP does), but warns about the strange default if omitted. > >I admit, it could have been made a little clearer ;-), and if you or >someone wants to help on the documentation, that's always welcome. I read the reset docs, not rewrite. I might tweak the docs at some stage. > > if the file is untyped. It'd be nice if there was > > a 'silent default' so that existing programs work 'as is'. For example >> reset( infile, infname ) ; >> gives a syntax error and demands that a buffer size be added. > >Yes, it's be nice, but BP stands in the way, as noted above. (AFAIK, >the misdesign goes back to UCSD Pascal and the CPM file system ...) >I think it would be too confusing to have two different silent >defaults, depending on the dialect option. But how about an explicit default by the user from the command-line? Easier than fiddling with their code (not that that's a terribly to do in this case)... low priority... its solvable if faintly irritating. if it was C, I'd use a macro to solve this, FWIW. >The only thing I could possibly imagine would be to make the >difference clear in some other way, e.g. to have the file declared >as `file of Void' or so (with a default of 1), whereas a simple >`file' (as in BP) behaves as it does now. Or redefine type File, doing which, err, must raise its own issues... type file = file of void ; {or} file = file[1] ; { ie file[ > 3. One of my enumerated types contains 'property' and 'operator' >> which prove to be GPC reserved words of some sort as the compiler >> throws up a syntax error. I don't really want to have to alter >> these... are these keywords part of some new standard? > >`property' is from Delphi, `operator' from PXSC. > >Generally, if you don't want any extensions (which include a few new >keywords, of course), try `--extended-pascal'. > >The next GPC will also support `--disable-keyword=property,operator' >(or `{$disable-keyword=property operator}' in the source). Grr. Any ideas on how long its going to take for this to appear? I got the vague idea that part of the strategy of GPC was to allow keywords to be redefined so that older code won't bump into keywords from newer/different implementations of Pascal. So this isn't really in place yet? > > 4. It'd be nice to sort the command-line options. They are hard to >> locate as they are without trawling through the whole list. > >OTOH, they are (somewhat) sorted by topic now. But no topic headings... yet ;-) >Well, we could have one list as it is now, and another one in >alphabetic order with the same information. > >Since the list is generated automatically, this should be rather >easy to do. But would it help, or be more confusing? Hmm. Both, but in my ideal world (!) I'd lay out the docs. in a different way. To me the best indexing/reference scheme I have seen is in 'Web Design in a Nutshell' (O'Reilly). I wish O'Reilly would use it in their other books. The index (or appendix) has the keywords in alphabetical order, referring you to an appendix with brief synopses of the keywords in alphabetical order. These, in turn, refer you to a complete synopsis at the head of a chapter. If you still can't remember how to use the thing, you're conveniently at the start of the chapter that covers that subject area needed to (re)learn it. The beauty of this is that it can be read either front-to-back or as a reference via the index/appendices without either disrupting the use of the other. For example, in the index, points to p473, which contains Chapter 11, page 207 ------------------------------------------------- Description: Frameset Attributes: border bordercolour cols frameborder framespacing ... Page 207 has the full synopsis, with standards support and short descriptions of the keyword's functions, eg: NN: 2,3,4 - MSIE: 3,4,5 - HTML 4 - WebTV - Opera3 ------------------------------------------------------------------------ ... Defines a collection of frames or other framesets Attributes border=number Sets frame border thickness (in pixels) ... ... If you're _still_ stuck, you read the chapter that follows. There is a nice hierarchy that you traverse, stopping when you've reached the level you need. If you're learning, you read from the front. This looks like a lot of work, but if done from HeaderDoc or the like, it might be possible to automate much of this straight from descriptions in the source code. Besides, we could aim to write our own O'Reilly Nutshell book :-) JK! And I really mean JK! [snip] > > 6. While I appreciate the effort that has been made, personally, I >> don't consider projects complete until the docs have been written... > >I don't think anyone would consider GPC complete in any way. ;-) I know, but... :-) [snip] > > > Can I suggest that a scheme allowing user's to add >> > comments/observations to the docs be made so that at least some >> > information gets into the docs. while the implementors have their >> > minds elsewhere? Perhaps add some keyword to indicate that this >> > item/section has been written by a user rather than implementor? For >> > example perhaps bracketing the text in the spirit of the way that XML >> > does, so that the reader can easily identify which bits have been >> > contributed by users and thus while probably true need to be taken >> > with a little salt :-) >> > >> > Alternatively add another section "user's observations" or some such >> > to the description of each element. >> > >> > It might also prove a useful reference of when user's experiences are >> > at odds with the implementors intentions while a bug fix is pending. >> > >> A gpc wiki would fit the bill for such a setup. > >I'm somewhat skeptical. There have been a number of other >suggestions over the years to address the "formal issues", but in >many cases, the potential contributors lost interest or had no time >to spend shortly after (or even before) the formalities had been >settled. What I'm suggesting is a little different. Provide a framework within the docs that users can add their own observations to, but one that such that readers can see that its a user contribution. Then users can add as little or much as they like. You'd occasionally want an editor to run over the whole thing and make it more consistent. (Or have two versions of the docs - last edited version and the free-for-all version) >In the end, it really comes down to the fact that someone has to >write the stuff ... > >Actually, it's not a big issue for me to apply documentation changes >I get (and to review them for serious mistakes) -- a simple patch >sent to me or the gpc-doc list will do. I've been getting some up to >now -- but unfortunately too sporadic and by far not enough to >really cover the holes ... If you can get the automatic docs out in some format, have a field 'user notes' or whatever present. Let the users add to that. You can then receive contrib.s as diffs or simply merge the new and old docs. >So I suggest to focus on the content first, not on the formalities. I agree. Fits with what I see as the pragmatic nature of GPC. The user notes can help in this respect. >Of course, if there are several contributors you might want to agree >on the areas you work on to avoid overlaps (though the chances are >small, given the number of holes) ... :-) I'd just have people submit their bits "without delay" so we'd discover that soon enough before they built up too much of a head of steam... :-) Lazier than some formal coordination scheme! > > > Really the implementors ought to be using something like HeaderDoc or >> > whatever and write these descriptions as they code... just a > > > thought... > > >> Again I agree with you. I have only been able to find pasdoc but it was >> wrote for delphi/kylix/fpc which means the code may not be portable to >> gpc. It also has not been touched in a couple of years. I grabed a copy > > of the source and am going to take a look at getting it ported to gpc >> and add some things to it. For instance right now it will output HTML >> and Texi. The HTML part is OK but I will need to work on the Texi part > > and change it to texinfo as that is what is being used for gpc. > >I've made some plans for such a utility, in particular some features >required, and some ideas for the syntax. I've been working on something along these lines myself. (I'm very slowly working towards writing my very own little language, which will probably have an audience of one, ie. me!) >My main goal would be (unlike some -- I don't know if all -- of the >other utilities), to have the syntax as simple and readable as >possible, e.g. to use paired quotes (like `foo') for markup (which >would be @samp{foo} in texi). The purpose would explicitely *not* be >to have a complete layout system (such as TeX; I think already texi >is not), but to focus on the common things. (There can always be an >escape mode for the occasional exception.) I agree: the learning curve needs to be small. >In the end, the existing comments in the unit interfaces, where they >exists, should be accepted with few modifications, and the output >should replace the interface copies in p/doc/generated. > If there is some real interest, I could write my ideas (which now >are just some random notes). I'd be interested to see how our ideas compare. I'm working in C, but trying to make it language-independent in a simplistic way. > > I may >> actualy just end up rewriting it from scratch as it is using quite a few >> custom class that duplicate units gpc already has and I would prefer to >> use the ones gpc provides verses costom ones. I know what you mean :-) >BTW, I don't quite see where such a utility would need classes and >collections and all that stuff at all, but then, I'm only a moderate >OOP follower ... > >Frank > >-- >Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E >GPC To-Do list, latest features, fixed bugs: >http://www.gnu-pascal.de/todo.html >GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 -- -------------------------------------------------------- Grant Jacobs grant.jacobs@clear.net.nz McAndrew Bay, Dunedin, ph. +64 3 476 1820 NEW ZEALAND. fax. +64 3 476 1825 From gpc-doc-owner@gnu.de Thu Jan 30 08:48:05 2003 Received: from smtp2.clear.net.nz ([203.97.37.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18e9Qa-00063T-00 for ; Thu, 30 Jan 2003 08:48:04 +0100 Received: from [203.167.130.129] (203-167-130-129.dialup.clear.net.nz [203.167.130.129]) by smtp2.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0H9I004B6OBJEO@smtp2.clear.net.nz> for gpc-doc@gnu.de; Thu, 30 Jan 2003 20:47:45 +1300 (NZDT) Date: Thu, 30 Jan 2003 20:49:35 +1300 From: Grant Jacobs Subject: Digest available for last few days? X-Sender: biot/grant.jacobs@pop.clear.net.nz To: gpc-doc@gnu.de Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii X-Archive-Number: 200301/4 X-Sequence-Number: 19 I was following the documentation issues on gpc@gnu.de, but screwed up a bit on swopping over to gpc-doc -- would anyone be kind enough to post me a digest of the last couple of days of posts? Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs@bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. From gpc-doc-owner@gnu.de Thu Jan 30 09:54:05 2003 Received: from mond.dida.physik.uni-essen.de ([132.252.79.233]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18eASS-0006Kb-00 for ; Thu, 30 Jan 2003 09:54:04 +0100 Received: (from lange@localhost) by mond.dida.physik.uni-essen.de (8.11.6/8.11.6/SuSE Linux 0.5) id h0U8qA701329 for gpc-doc@gnu.de; Thu, 30 Jan 2003 09:52:10 +0100 Date: Thu, 30 Jan 2003 09:52:10 +0100 From: Eike Lange To: gpc-doc@gnu.de Subject: Re: Digest available for last few days? Message-ID: <20030130095210.C1124@mond.dida.physik.uni-essen.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-Eike-Conspiracy: There is no conspiracy X-Archive-Number: 200301/5 X-Sequence-Number: 20 On Thu, Jan 30, 2003 at 08:49:35PM +1300, Grant Jacobs wrote: > I was following the documentation issues on gpc@gnu.de, but screwed > up a bit on swopping over to gpc-doc -- would anyone be kind enough > to post me a digest of the last couple of days of posts? There aren't any. Eike From gpc-doc-owner@gnu.de Thu Jan 30 18:38:54 2003 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian)) id 18eIeH-0002L8-00 for ; Thu, 30 Jan 2003 18:38:49 +0100 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id SAA31734 for ; Thu, 30 Jan 2003 18:36:47 +0100 Date: Thu, 30 Jan 2003 18:36:47 +0100 Message-Id: <200301301736.SAA31734@goedel.fjf.gnu.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii Subject: Re: Digest available for last few days? To: gpc-doc@gnu.de References: In-Reply-To: From: Frank Heckenbach X-Mailer: semail 20030101 X-Archive-Number: 200301/6 X-Sequence-Number: 21 Grant Jacobs wrote: > I was following the documentation issues on gpc@gnu.de, but screwed > up a bit on swopping over to gpc-doc -- would anyone be kind enough > to post me a digest of the last couple of days of posts? You can see the archives at http://www.gnu.de/archive/ Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 From gpc-doc-owner@gnu.de Thu Jan 30 18:38:54 2003 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian)) id 18eIeH-0002L0-00 for ; Thu, 30 Jan 2003 18:38:49 +0100 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id SAA31487 for ; Thu, 30 Jan 2003 18:30:01 +0100 Date: Thu, 30 Jan 2003 18:30:01 +0100 Message-Id: <200301301730.SAA31487@goedel.fjf.gnu.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii Subject: Re: Some observations [GHJ] To: gpc-doc@gnu.de References: <200301280204.DAA12034@goedel.fjf.gnu.de> <1043732400.4799.36.camel@gigaflop.1gig.net> <200301290441.FAA30843@goedel.fjf.gnu.de> <1043911804.30673.50.camel@gigaflop.1gig.net> In-Reply-To: <1043911804.30673.50.camel@gigaflop.1gig.net> From: Frank Heckenbach X-Mailer: semail 20030101 X-Archive-Number: 200301/7 X-Sequence-Number: 22 Richard D. Jackson wrote: > What I envioson is more of a tag syntax verses a complete layout system. > By tag I mean something that indicates that something is: > Author name > Module version > copyright notice > description These are usually global (per module), currently contained in a comment at the top. Ideally, the tool would get them from there using the existing information. E.g.: : { Some utility routines for compatibility to some units available : for BP, like some `Turbo Power' units. Title : Copyright (C) 1998-2003 Free Software Foundation, Inc. Copyright notice (keyword "Copyright" :-). : Authors: Prof. Abimbola A. Olowofoyeku : Frank Heckenbach Author name(s) (keyword "Author(s)"). [Further description (could be put right after the title if it makes things easier)] : This file is part of GNU Pascal. : : GNU Pascal is free software; you can redistribute it and/or modify License (could be put together with the copyright notice if it makes things easier). > return type/description ( may or may not need this ) > paramiter As for the syntax, these are clear from the declaration, therefore should not require further commenting. I think it should be enough to write the declaration in the "Synopsis" part. A Pascal programmer ought to know what the declaration means and how to use it. The semantics of each parameter and the return value (if any), of course, should be described in the text, but I'm not sure we need any formalities for that. > code example Yep. > header ( by this I mean module header or description ) These are the things mentioned above, aren't they? > referance Yes, quite important. As I wrote in my program's comments, I'd prefer to make them as easily as possible, e.g., will write the identifier foo in the text, but also put it in the references section. It might seem a small issue, but not having to write the thing twice (in the text and the references) is more comfortable and will probably encourage people to use many references. :-) Of course, adding more references explicitly (`@seealso' in my example) should also be possible. > But not a whole lot of stuff. Leave formating and structure up to the > output code. This is how POD, JavaDoc ( core stuff that is ) and a few > others do. That way if you don't like the output you can write your own > output generator that will format it the way you want. Core Doxygen does > this as well but becasue the backend dictates the output form/layout it > has had many output generaters created for it. But I think its down fall > is that it does allow the programmer to use or embed form/layout stuff > for specific output generaters which means the programmer spends can > spend too much time trying to do some special form/layout verses just > writing the doc. I basically agree. Though I think there is some amount of markup we need. E.g., to mark identifiers (see above, with references for identifiers mentioned besides the current ones), and to mark sections of code etc. E.g., the description of gpc.pas:CanRead currently says: [...] This is similar to `not EOF (aFile)', but [...] So the `not EOF (aFile)' part should be marked in some way to avoid confusion -- preferably (to me) `...' in the input and @samp{...} in the texi output. Also, it *might* be useful to write emphasis sometimes. In plain text formats which don't provide for this, people will often use *...* for it, so a tool could just as well convert it to proper emphasis in the output. > First the question I would have is what is the target application of the > documenter? If for only documenting single monolithic units then a > single pass ( single file ) tool would do the job. But on the other hand > if you want to handle multi-module/unit applications that need to beable > to cross link the documention and or have a unified cross-referance > amogst all the code modules then what you really want to do is process > all of the files in a single pass. Not necessarily. If you're worried about cross-references, Texinfo handles them already (see below). > One other thing I would like for it to do besides output the > documentation is to output a cross referance list so that other modules > can referance the doc if needed. > For instance lets say I'm writing a string utility unit wouldn't it be > nice if I could referance the RTS with in my doc's and actualy have a > working link to the RTS doc for a paricular function/procedure verses > something like this " see these functions in the RTS documentation > ....." As you might know, texi has references that refer to "nodes" by name. If we generally make each node's name the same as the identifier being described, we can refer to every identifier in the current or another module the same way. (The scheme would break if there are several identifiers of the same name in different modules. This is allowed, but honestly, who would do so -- within one project! I think we can ignore this. ;-) So the translation would run like this (which is basically what is done now for the GPC manual, where the part of the new tool is taken by a simple copying of the interface): foo.pas -> foo.texi bar.pas -> bar.texi baz.pas -> baz.texi myproj.texi (contains the main menu and possibly other documentation) {myproj,foo,bar,baz}.texi -> myproj.{info,html,dvi,ps,pdf,...} It's different when you want to refer to things from other projects (e.g., you write documentation for your own code and want to refer to the GPC manual directly). BTW, that's no different whether the tool will translate single or multiple files, since different projects are translated separately, anyway. Actually, all that's required then is to get the name of the other documentation file -- the texi reference would then look like `@ref{WriteLn,,,gpc}' instead of `@ref{WriteLn}'. To do this automatically, the cross reference list you suggested might be useful. I.e., while translating the GPC documentation, this list is produced and stored somewhere, and when translating the documentation of another project, it could use this list to find out which identifiers should have their references pointing to the GPC documentation. Grant Jacobs wrote: > Don't include format per se, but include some style class information > like 'header' 'text' etc so that it can be appropriately formatted > later. I'd prefer sections to headers. The difference may be small, but rather than inserting headers here and there, this will structure the documentation. I suppose that smaller units will not need sections at all, but for larger ones they could be useful. One hierarchy level should be enough, though. > Its a good point, but I think processing all the files in a single > pass has exactly the same flaw as compiling code in the same fashion. > The interface/implementation approach was developed for that reason. I don't know if speed is a real concern here, but still I'd prefer the separate translation approach, too. Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 From gpc-doc-owner@gnu.de Thu Jan 30 23:04:24 2003 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian)) id 18eMnH-0006LA-00 for ; Thu, 30 Jan 2003 23:04:23 +0100 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id XAA04807 for ; Thu, 30 Jan 2003 23:03:16 +0100 Date: Thu, 30 Jan 2003 23:03:16 +0100 Message-Id: <200301302203.XAA04807@goedel.fjf.gnu.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii Subject: Re: Some observations [GHJ] To: gpc-doc@gnu.de References: In-Reply-To: From: Frank Heckenbach X-Mailer: semail 20030101 X-Archive-Number: 200301/8 X-Sequence-Number: 23 Grant Jacobs wrote: > What I'm suggesting is a little different. Provide a framework within > the docs that users can add their own observations to, but one that > such that readers can see that its a user contribution. Then users > can add as little or much as they like. > > You'd occasionally want an editor to run over the whole thing and > make it more consistent. (Or have two versions of the docs - last > edited version and the free-for-all version) > > >In the end, it really comes down to the fact that someone has to > >write the stuff ... > > > >Actually, it's not a big issue for me to apply documentation changes > >I get (and to review them for serious mistakes) -- a simple patch > >sent to me or the gpc-doc list will do. I've been getting some up to > >now -- but unfortunately too sporadic and by far not enough to > >really cover the holes ... > > If you can get the automatic docs out in some format, have a field > 'user notes' or whatever present. Let the users add to that. You can > then receive contrib.s as diffs or simply merge the new and old docs. OK, I think I can do that -- to add an input form at the bottom of each page, so anything entered there will appear on the page (just above the input form I guess) marked as user notes, and is sent to me so I can put it into the main documentation if it's alright. Is that what you mean? I'm still skeptical how much it will gain us in the end, but since there's not much to lose, I'll try it (with the next update) ... Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 From gpc-doc-owner@gnu.de Fri Jan 31 05:36:04 2003 Received: from adsl-64-217-81-216.dsl.austtx.swbell.net ([64.217.81.216] helo=gigabyte.1gig.net ident=nobody) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18eSuD-0001j6-00; Fri, 31 Jan 2003 05:35:57 +0100 Received: from [192.168.1.2] (gigaflop.1gig.net [192.168.1.2]) by gigabyte.1gig.net (Postfix) with ESMTP id 966715DA8; Thu, 30 Jan 2003 22:35:26 -0600 (CST) Subject: Re: Some observations [GHJ] From: "Richard D. Jackson" To: gpc@gnu.de, gpc-doc@gnu.de In-Reply-To: References: <1043681772.3862.32.camel@gigaflop.1gig.net> <200301280204.DAA12034@goedel.fjf.gnu.de> <1043732400.4799.36.camel@gigaflop.1gig.net> <200301290441.FAA30843@goedel.fjf.gnu.de> <1043911804.30673.50.camel@gigaflop.1gig.net> Content-Type: text/plain Organization: Message-Id: <1043988326.31971.1.camel@gigaflop.1gig.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1- Date: 30 Jan 2003 22:45:26 -0600 Content-Transfer-Encoding: 7bit X-Archive-Number: 200301/9 X-Sequence-Number: 24 On Thu, 2003-01-30 at 02:27, Grant Jacobs wrote: > I thought this was moving over to gpc-doc? Should I send my postings > which I've held back until sorting a hiccup registering for gpc-doc > here instead? > (more below) > > At 1:30 AM -0600 30/1/03, Richard D. Jackson wrote: > >On Tue, 2003-01-28 at 22:41, Frank Heckenbach wrote: > > > Richard D. Jackson wrote: This is the last post on this subject going to gpc. On this one I just did a reply and forgot to move it to gpc-doc. Richard From gpc-doc-owner@gnu.de Fri Jan 31 06:37:23 2003 Received: from adsl-64-217-81-216.dsl.austtx.swbell.net ([64.217.81.216] helo=gigabyte.1gig.net ident=nobody) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18eTrc-0002FN-00 for ; Fri, 31 Jan 2003 06:37:21 +0100 Received: from [192.168.1.2] (gigaflop.1gig.net [192.168.1.2]) by gigabyte.1gig.net (Postfix) with ESMTP id 287B01BC for ; Thu, 30 Jan 2003 23:36:50 -0600 (CST) Subject: Re: Some observations [GHJ] From: "Richard D. Jackson" To: gpc-doc@gnu.de In-Reply-To: <200301301730.SAA31487@goedel.fjf.gnu.de> References: <200301280204.DAA12034@goedel.fjf.gnu.de> <1043732400.4799.36.camel@gigaflop.1gig.net> <200301290441.FAA30843@goedel.fjf.gnu.de> <1043911804.30673.50.camel@gigaflop.1gig.net> <200301301730.SAA31487@goedel.fjf.gnu.de> Content-Type: text/plain Organization: Message-Id: <1043992009.31980.52.camel@gigaflop.1gig.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1- Date: 30 Jan 2003 23:46:50 -0600 Content-Transfer-Encoding: 7bit X-Archive-Number: 200301/10 X-Sequence-Number: 25 On Thu, 2003-01-30 at 11:30, Frank Heckenbach wrote: > Richard D. Jackson wrote: > > > What I envioson is more of a tag syntax verses a complete layout system. > > By tag I mean something that indicates that something is: > > Author name > > Module version > > copyright notice > > description > > These are usually global (per module), currently contained in a > comment at the top. Ideally, the tool would get them from there > using the existing information. E.g.: > Yes I agree and it is the way it should be. I'm going to snip the example you gave below this statment for now just because it is further down the process than I want to be at this point. > > return type/description ( may or may not need this ) > > paramiter > > As for the syntax, these are clear from the declaration, therefore > should not require further commenting. > > I think it should be enough to write the declaration in the > "Synopsis" part. A Pascal programmer ought to know what the > declaration means and how to use it. > > The semantics of each parameter and the return value (if any), of > course, should be described in the text, but I'm not sure we need > any formalities for that. > Take a look at this http://java.sun.com/j2se/1.4.1/docs/api/index.html ignore the stuf at the top and scroll down to the section containing the method documentation. This is the type of format/output I would like to see the html ouput engine produce for a function/procedure. I wouldn't mind seeing that type of output on the texinfo side either but I definatly want it on the html side. Now to do that type of formating will require that the documenter mark what is what. > > code example > > Yep. > > > header ( by this I mean module header or description ) > > These are the things mentioned above, aren't they? True. I was kinda of asleep when I wrote this :) > > > referance > > Yes, quite important. As I wrote in my program's comments, I'd > prefer to make them as easily as possible, e.g., will write > the identifier foo in the text, but also put it in the references > section. It might seem a small issue, but not having to write the > thing twice (in the text and the references) is more comfortable and > will probably encourage people to use many references. :-) The problem with using would be that now to include a <> in your documentaion would mean you have to escape it so that a ref is not created. So I think the first thing to deside is what do you use to denote a command. example @ % * ~ whatever it is I would prefer something that will mostlikly not be needed in the docmentation so we don't have to worry about escapes. > > > But not a whole lot of stuff. Leave formating and structure up to the > > output code. This is how POD, JavaDoc ( core stuff that is ) and a few > > others do. That way if you don't like the output you can write your own > > output generator that will format it the way you want. Core Doxygen does > > this as well but becasue the backend dictates the output form/layout it > > has had many output generaters created for it. But I think its down fall > > is that it does allow the programmer to use or embed form/layout stuff > > for specific output generaters which means the programmer spends can > > spend too much time trying to do some special form/layout verses just > > writing the doc. > > I basically agree. Though I think there is some amount of markup we > need. E.g., to mark identifiers (see above, with references for > identifiers mentioned besides the current ones), and to mark > sections of code etc. E.g., the description of gpc.pas:CanRead > currently says: > [...] This is similar to `not EOF (aFile)', but [...] > > So the `not EOF (aFile)' part should be marked in some way to avoid > confusion -- preferably (to me) `...' in the input and @samp{...} in > the texi output. > Yes I do agree with you in that we should have things like bold and italics > Also, it *might* be useful to write emphasis sometimes. In plain > text formats which don't provide for this, people will often use > *...* for it, so a tool could just as well convert it to proper > emphasis in the output. Yes the documenter can indicate that he/she wants emphasis and leave it up to the backend to decide how to do it. > > > First the question I would have is what is the target application of the > > documenter? If for only documenting single monolithic units then a > > single pass ( single file ) tool would do the job. But on the other hand > > if you want to handle multi-module/unit applications that need to beable > > to cross link the documention and or have a unified cross-referance > > amogst all the code modules then what you really want to do is process > > all of the files in a single pass. > > Not necessarily. If you're worried about cross-references, Texinfo > handles them already (see below). > Yes Texinfo does but HTML does not. True you can just output Texinfo and then convert that to HTML but doing it that way you loose some of the things you can do in HTML that Texinfo was not designed for. > As you might know, texi has references that refer to "nodes" by > name. If we generally make each node's name the same as the > identifier being described, we can refer to every identifier in the > current or another module the same way. (The scheme would break if > there are several identifiers of the same name in different modules. > This is allowed, but honestly, who would do so -- within one > project! I think we can ignore this. ;-) > > So the translation would run like this (which is basically what is > done now for the GPC manual, where the part of the new tool is taken > by a simple copying of the interface): > > foo.pas -> foo.texi > bar.pas -> bar.texi > baz.pas -> baz.texi > myproj.texi (contains the main menu and possibly other documentation) > {myproj,foo,bar,baz}.texi -> myproj.{info,html,dvi,ps,pdf,...} > Yes but how do I go directly to a particular section in the info file? > It's different when you want to refer to things from other projects > (e.g., you write documentation for your own code and want to refer > to the GPC manual directly). BTW, that's no different whether the > tool will translate single or multiple files, since different > projects are translated separately, anyway. Actually, all that's > required then is to get the name of the other documentation file -- > the texi reference would then look like `@ref{WriteLn,,,gpc}' > instead of `@ref{WriteLn}'. > Again how would you go directly to WriteLn in the texi file. Yes going to the main menu of the texi file would be easy but I want to link directly into it. > To do this automatically, the cross reference list you suggested > might be useful. I.e., while translating the GPC documentation, this > list is produced and stored somewhere, and when translating the > documentation of another project, it could use this list to find out > which identifiers should have their references pointing to the GPC > documentation. > Exactly! And with the list would be the exact link to it so you can go directly to it. The problem is that Texinfo will split it up and I don't know enough texinfo yet to look into how to do that for texinfo. HTML would be easy as you are going direct to finished output where as texinfo files will still need to be processed by maketexi? > Grant Jacobs wrote: > > > Don't include format per se, but include some style class information > > like 'header' 'text' etc so that it can be appropriately formatted > > later. > > I'd prefer sections to headers. The difference may be small, but > rather than inserting headers here and there, this will structure > the documentation. I suppose that smaller units will not need > sections at all, but for larger ones they could be useful. One > hierarchy level should be enough, though. > Yes and even better do the section at the top and down in the function/procedure documenation have a tag that indicates what section this belongs to. That way you have the formater do the work of filling out the section documentation. > > Its a good point, but I think processing all the files in a single > > pass has exactly the same flaw as compiling code in the same fashion. > > The interface/implementation approach was developed for that reason. > > I don't know if speed is a real concern here, but still I'd prefer > the separate translation approach, too. > I need to think about this some more :) But I do think the first things we need to decide is what do we use to indicate a command/tag and what tags/commands do we need. And what the tag/command should do. Lets keep it to that for now and leave how it should work or how you should use them for later. For example: ~ = this indicates a command ( I'm not advicating ~ it is just a good starting point as it is not reserved, it is not a compiler commad like {@ is and will most likly not be used in documentation. ) ~bold = this will mark the following text in bold. ~end = This ends a format command. After that is done I will write up something for the tags. The next stage would be how do you use the tags/commands we have decided on. I'll leave it at that for now. Richard From gpc-doc-owner@gnu.de Fri Jan 31 09:57:19 2003 Received: from smtp2.clear.net.nz ([203.97.37.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18eWz7-00042T-00 for ; Fri, 31 Jan 2003 09:57:18 +0100 Received: from [203.167.130.123] (203-167-130-123.dialup.clear.net.nz [203.167.130.123]) by smtp2.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0H9K002XBM6G61@smtp2.clear.net.nz> for gpc-doc@gnu.de; Fri, 31 Jan 2003 21:56:44 +1300 (NZDT) Date: Fri, 31 Jan 2003 21:47:47 +1300 From: Grant Jacobs Subject: Re: Some observations [GHJ] X-Sender: biot/grant.jacobs@pop.clear.net.nz To: gpc-doc@gnu.de Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii X-Archive-Number: 200301/11 X-Sequence-Number: 26 Just catching up with the state of affairs... > > Really the implementors ought to be using something like HeaderDoc or >> whatever and write these descriptions as they code... just a > > thought... > >Again I agree with you. I have only been able to find pasdoc but it was >wrote for delphi/kylix/fpc which means the code may not be portable to >gpc. It also has not been touched in a couple of years. I grabed a copy >of the source and am going to take a look at getting it ported to gpc >and add some things to it. For instance right now it will output HTML >and Texi. The HTML part is OK but I will need to work on the Texi part >and change it to texinfo as that is what is being used for gpc. I may >actualy just end up rewriting it from scratch as it is using quite a few >custom class that duplicate units gpc already has and I would prefer to >use the ones gpc provides verses costom ones. I'm trying to implement my own little scheme, but written in C (don't look at me!). I get the feeling mine wind up a little more basic, but it'll be mine, all mine! :-) Grant -- -------------------------------------------------------- Grant Jacobs grant.jacobs@clear.net.nz McAndrew Bay, Dunedin, ph. +64 3 476 1820 NEW ZEALAND. fax. +64 3 476 1825 From gpc-doc-owner@gnu.de Sat Feb 1 06:07:32 2003 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian)) id 18epsG-0007Jj-00 for ; Sat, 01 Feb 2003 06:07:28 +0100 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id GAA26018 for ; Sat, 1 Feb 2003 06:06:54 +0100 Date: Sat, 1 Feb 2003 06:06:54 +0100 Message-Id: <200302010506.GAA26018@goedel.fjf.gnu.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii Subject: Re: Some observations [GHJ] To: gpc-doc@gnu.de References: <1043911804.30673.50.camel@gigaflop.1gig.net> <200301301730.SAA31487@goedel.fjf.gnu.de> <1043992009.31980.52.camel@gigaflop.1gig.net> In-Reply-To: <1043992009.31980.52.camel@gigaflop.1gig.net> From: Frank Heckenbach X-Mailer: semail 20030101 X-Archive-Number: 200302/1 X-Sequence-Number: 27 Richard D. Jackson wrote: > > > return type/description ( may or may not need this ) > > > paramiter > > > > As for the syntax, these are clear from the declaration, therefore > > should not require further commenting. > > > > I think it should be enough to write the declaration in the > > "Synopsis" part. A Pascal programmer ought to know what the > > declaration means and how to use it. > > > > The semantics of each parameter and the return value (if any), of > > course, should be described in the text, but I'm not sure we need > > any formalities for that. > > > Take a look at this > http://java.sun.com/j2se/1.4.1/docs/api/index.html > ignore the stuf at the top and scroll down to the section containing the > method documentation. This is the type of format/output I would like to > see the html ouput engine produce for a function/procedure. I wouldn't > mind seeing that type of output on the texinfo side either but I > definatly want it on the html side. Now to do that type of formating > will require that the documenter mark what is what. Could you please give an exact URL of the page you mean? The URL above contains a frameset with several menus, I'm not sure exactly what to look at. > > > referance > > > > Yes, quite important. As I wrote in my program's comments, I'd > > prefer to make them as easily as possible, e.g., will write > > the identifier foo in the text, but also put it in the references > > section. It might seem a small issue, but not having to write the > > thing twice (in the text and the references) is more comfortable and > > will probably encourage people to use many references. :-) > The problem with using would be that now to include a <> in your > documentaion would mean you have to escape it so that a ref is not > created. So I think the first thing to deside is what do you use to > denote a command. example @ % * ~ whatever it is I would prefer > something that will mostlikly not be needed in the docmentation so we > don't have to worry about escapes. But code samples which can include `<>', `@' etc. should already be marked up as such. That's why I suggested `...' for code samples in my draft. Markup within code samples is pointless and shouldn't be recognized, therefore these characters are "harmless". OK, I admit, the single quote (') can appear in Pascal, so using it for the end of a code block is not good. So I'd now prefer another delimiter such as one of the chars that doesn't occur in any Pascal dialect which seem to be !%`|~, so perhaps |code| or `code` (hmm?) ... > > I basically agree. Though I think there is some amount of markup we > > need. E.g., to mark identifiers (see above, with references for > > identifiers mentioned besides the current ones), and to mark > > sections of code etc. E.g., the description of gpc.pas:CanRead > > currently says: > > > [...] This is similar to `not EOF (aFile)', but [...] > > > > So the `not EOF (aFile)' part should be marked in some way to avoid > > confusion -- preferably (to me) `...' in the input and @samp{...} in > > the texi output. > > > Yes I do agree with you in that we should have things like bold and > italics Nitpick: I don't want stuff like bold and italics, but stuff like emphasis and "code" markup (i.e., no physical, but logical markup). > > Also, it *might* be useful to write emphasis sometimes. In plain > > text formats which don't provide for this, people will often use > > *...* for it, so a tool could just as well convert it to proper > > emphasis in the output. > Yes the documenter can indicate that he/she wants emphasis and leave it > up to the backend to decide how to do it. Exactly. > > > First the question I would have is what is the target application of the > > > documenter? If for only documenting single monolithic units then a > > > single pass ( single file ) tool would do the job. But on the other hand > > > if you want to handle multi-module/unit applications that need to beable > > > to cross link the documention and or have a unified cross-referance > > > amogst all the code modules then what you really want to do is process > > > all of the files in a single pass. > > > > Not necessarily. If you're worried about cross-references, Texinfo > > handles them already (see below). > > > Yes Texinfo does but HTML does not. True you can just output Texinfo and > then convert that to HTML but doing it that way you loose some of the > things you can do in HTML that Texinfo was not designed for. I don't think we should use any such things in the documentation at all, i.e. stick to the lowest common denominator. Or do you have anything in particular in mind which is absolutely essential and not possible to texi? I also don't think it's worth the extra effort to create HTML directly rather than going via texi. At least for the GPC website, I probably wouldn't use it, anyway, since it's generated from one texi source so references work best. > > It's different when you want to refer to things from other projects > > (e.g., you write documentation for your own code and want to refer > > to the GPC manual directly). BTW, that's no different whether the > > tool will translate single or multiple files, since different > > projects are translated separately, anyway. Actually, all that's > > required then is to get the name of the other documentation file -- > > the texi reference would then look like `@ref{WriteLn,,,gpc}' > > instead of `@ref{WriteLn}'. > > > Again how would you go directly to WriteLn in the texi file. Yes going > to the main menu of the texi file would be easy but I want to link > directly into it. Well, just what I wrote. `@ref{WriteLn,,,gpc}' goes to the node `WriteLn' in the file `gpc' (in info and also the other texi outputs). > > To do this automatically, the cross reference list you suggested > > might be useful. I.e., while translating the GPC documentation, this > > list is produced and stored somewhere, and when translating the > > documentation of another project, it could use this list to find out > > which identifiers should have their references pointing to the GPC > > documentation. > > > Exactly! And with the list would be the exact link to it so you can go > directly to it. The problem is that Texinfo will split it up and I don't > know enough texinfo yet to look into how to do that for texinfo. HTML > would be easy as you are going direct to finished output where as > texinfo files will still need to be processed by maketexi? (makeinfo) But I think you're thinking of texi references as more difficult than they are -- unless I'm missing something ... > > Grant Jacobs wrote: > > > Don't include format per se, but include some style class information > > > like 'header' 'text' etc so that it can be appropriately formatted > > > later. > > > > I'd prefer sections to headers. The difference may be small, but > > rather than inserting headers here and there, this will structure > > the documentation. I suppose that smaller units will not need > > sections at all, but for larger ones they could be useful. One > > hierarchy level should be enough, though. > > > Yes and even better do the section at the top and down in the > function/procedure documenation have a tag that indicates what section > this belongs to. That way you have the formater do the work of filling > out the section documentation. I don't know exactly how you mean this, but what I do not want is to have to specify the section for each declaration. Most of the time, declarations belonging in one section are written next to each other (and I don't even see a problem to make this a fixed rule), so specifying where a new section starts should be all that's required. > But I do think the first things we need to decide is what do we use to > indicate a command/tag and what tags/commands do we need. And what the > tag/command should do. Lets keep it to that for now and leave how it > should work or how you should use them for later. For example: > > ~ = this indicates a command ( I'm not advicating ~ it is just a good > starting point as it is not reserved, it is not a compiler commad like > {@ is and will most likly not be used in documentation. ) See above. > ~bold = this will mark the following text in bold. > ~end = This ends a format command. My problem with these are that they make the text (in the source form) harder to read -- it's easier (mentally) to read over symbols than words. That's why I suggested symbolic forms for the most common purposes (`...', <...>, *...*). And even for the occasional "named" command, I prefer a symbol at the end (such as @foo{...}). Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 From gpc-doc-owner@gnu.de Sun Feb 2 03:05:42 2003 Received: from smtp2.clear.net.nz ([203.97.37.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18f9Vs-0003e1-00 for ; Sun, 02 Feb 2003 03:05:40 +0100 Received: from [203.167.170.214] (203-167-170-214.dialup.clear.net.nz [203.167.170.214]) by smtp2.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0H9N00LA4SFT2F@smtp2.clear.net.nz> for gpc-doc@gnu.de; Sun, 02 Feb 2003 15:04:43 +1300 (NZDT) Date: Sun, 02 Feb 2003 15:06:38 +1300 From: Grant Jacobs Subject: Re: Some observations [GHJ] In-reply-to: <1043681772.3862.32.camel@gigaflop.1gig.net> X-Sender: biot/grant.jacobs@pop.clear.net.nz To: gpc-doc@gnu.de Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <1043463322.32674.3.camel@gigaflop.1gig.net> <200301252359.AAA01691@goedel.fjf.gnu.de> <15923.51228.154634.150192@gargle.gargle.HOWL> <200301261454.PAA32546@goedel.fjf.gnu.de> <1043681772.3862.32.camel@gigaflop.1gig.net> X-Archive-Number: 200302/2 X-Sequence-Number: 28 At 9:36 AM -0600 27/1/03, Richard D. Jackson wrote: >On Mon, 2003-01-27 at 03:36, Grant Jacobs wrote: >> A few observations from trying out gpc (Linux). >> > >> 6. While I appreciate the effort that has been made, personally, I >> don't consider projects complete until the docs have been written... >> it seems to me much of the doc. at present is just a shell, full of >> '(Under construction)'! It would make a huge difference if some of >> the people who know how things are supposed to be filled in the odd >> gap... >> >I couldn't agree with you more. > >> Where is the original (text) document format? Is it the HTML format? >> I might try poke the odd bit in myself. > >It is in texinfo format in the ./p/doc/[lang] directory. also it seems >some of the doc is generated as well. Do you might telling me exactly where this is located :-) - ie. URL, etc. Is not on the website, nor my installation and ftp'ing ft.gnu.de doesn't any me any joy... Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs@bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. From gpc-doc-owner@gnu.de Sun Feb 2 03:19:02 2003 Received: from adsl-64-217-81-216.dsl.austtx.swbell.net ([64.217.81.216] helo=gigabyte.1gig.net ident=nobody) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18f9il-0003p9-00 for ; Sun, 02 Feb 2003 03:19:00 +0100 Received: from [192.168.1.2] (gigaflop.1gig.net [192.168.1.2]) by gigabyte.1gig.net (Postfix) with ESMTP id 14FCB5D10 for ; Sat, 1 Feb 2003 20:18:03 -0600 (CST) Subject: Re: Some observations [GHJ] From: "Richard D. Jackson" To: gpc-doc@gnu.de In-Reply-To: <200302010506.GAA26018@goedel.fjf.gnu.de> References: <1043911804.30673.50.camel@gigaflop.1gig.net> <200301301730.SAA31487@goedel.fjf.gnu.de> <1043992009.31980.52.camel@gigaflop.1gig.net> <200302010506.GAA26018@goedel.fjf.gnu.de> Content-Type: text/plain Organization: Message-Id: <1044152878.2081.10.camel@gigaflop.1gig.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1- Date: 01 Feb 2003 20:27:58 -0600 Content-Transfer-Encoding: 7bit X-Archive-Number: 200302/3 X-Sequence-Number: 29 On Fri, 2003-01-31 at 23:06, Frank Heckenbach wrote: > > > Take a look at this > > http://java.sun.com/j2se/1.4.1/docs/api/index.html > > ignore the stuf at the top and scroll down to the section containing the > > method documentation. This is the type of format/output I would like to > > see the html ouput engine produce for a function/procedure. I wouldn't > > mind seeing that type of output on the texinfo side either but I > > definatly want it on the html side. Now to do that type of formating > > will require that the documenter mark what is what. > > Could you please give an exact URL of the page you mean? The URL > above contains a frameset with several menus, I'm not sure exactly > what to look at. > Sorry about that try this: http://java.sun.com/j2se/1.4.1/docs/api/java/awt/Paint.html And look at the Method Detail section at the bottom. There happens to be only one method for this but it does show what I'm thinking about. > > > > referance > > > > > > Yes, quite important. As I wrote in my program's comments, I'd > > > prefer to make them as easily as possible, e.g., will write > > > the identifier foo in the text, but also put it in the references > > > section. It might seem a small issue, but not having to write the > > > thing twice (in the text and the references) is more comfortable and > > > will probably encourage people to use many references. :-) > > The problem with using would be that now to include a <> in your > > documentaion would mean you have to escape it so that a ref is not > > created. So I think the first thing to deside is what do you use to > > denote a command. example @ % * ~ whatever it is I would prefer > > something that will mostlikly not be needed in the docmentation so we > > don't have to worry about escapes. > > But code samples which can include `<>', `@' etc. should already be > marked up as such. That's why I suggested `...' for code samples in > my draft. Markup within code samples is pointless and shouldn't be > recognized, therefore these characters are "harmless". > > OK, I admit, the single quote (') can appear in Pascal, so using it > for the end of a code block is not good. So I'd now prefer another > delimiter such as one of the chars that doesn't occur in any Pascal > dialect which seem to be !%`|~, so perhaps |code| or `code` (hmm?) > ... > Ok I get it this time :) > > > I basically agree. Though I think there is some amount of markup we > > > need. E.g., to mark identifiers (see above, with references for > > > identifiers mentioned besides the current ones), and to mark > > > sections of code etc. E.g., the description of gpc.pas:CanRead > > > currently says: > > > > > [...] This is similar to `not EOF (aFile)', but [...] > > > > > > So the `not EOF (aFile)' part should be marked in some way to avoid > > > confusion -- preferably (to me) `...' in the input and @samp{...} in > > > the texi output. > > > > > Yes I do agree with you in that we should have things like bold and > > italics > > Nitpick: I don't want stuff like bold and italics, but stuff like > emphasis and "code" markup (i.e., no physical, but logical markup). > Ok > > > Also, it *might* be useful to write emphasis sometimes. In plain > > > text formats which don't provide for this, people will often use > > > *...* for it, so a tool could just as well convert it to proper > > > emphasis in the output. > > Yes the documenter can indicate that he/she wants emphasis and leave it > > up to the backend to decide how to do it. > > Exactly. > > > > > First the question I would have is what is the target application of the > > > > documenter? If for only documenting single monolithic units then a > > > > single pass ( single file ) tool would do the job. But on the other hand > > > > if you want to handle multi-module/unit applications that need to beable > > > > to cross link the documention and or have a unified cross-referance > > > > amogst all the code modules then what you really want to do is process > > > > all of the files in a single pass. > > > > > > Not necessarily. If you're worried about cross-references, Texinfo > > > handles them already (see below). > > > > > Yes Texinfo does but HTML does not. True you can just output Texinfo and > > then convert that to HTML but doing it that way you loose some of the > > things you can do in HTML that Texinfo was not designed for. > > I don't think we should use any such things in the documentation at > all, i.e. stick to the lowest common denominator. Or do you have > anything in particular in mind which is absolutely essential and not > possible to texi? > > I also don't think it's worth the extra effort to create HTML > directly rather than going via texi. At least for the GPC website, I > probably wouldn't use it, anyway, since it's generated from one texi > source so references work best. > Maybe I need to spend some time and learn texinfo better. As right now I know very little about what it can and can't do. > > > It's different when you want to refer to things from other projects > > > (e.g., you write documentation for your own code and want to refer > > > to the GPC manual directly). BTW, that's no different whether the > > > tool will translate single or multiple files, since different > > > projects are translated separately, anyway. Actually, all that's > > > required then is to get the name of the other documentation file -- > > > the texi reference would then look like `@ref{WriteLn,,,gpc}' > > > instead of `@ref{WriteLn}'. > > > > > Again how would you go directly to WriteLn in the texi file. Yes going > > to the main menu of the texi file would be easy but I want to link > > directly into it. > > Well, just what I wrote. `@ref{WriteLn,,,gpc}' goes to the node > `WriteLn' in the file `gpc' (in info and also the other texi > outputs). > > > > To do this automatically, the cross reference list you suggested > > > might be useful. I.e., while translating the GPC documentation, this > > > list is produced and stored somewhere, and when translating the > > > documentation of another project, it could use this list to find out > > > which identifiers should have their references pointing to the GPC > > > documentation. > > > > > Exactly! And with the list would be the exact link to it so you can go > > directly to it. The problem is that Texinfo will split it up and I don't > > know enough texinfo yet to look into how to do that for texinfo. HTML > > would be easy as you are going direct to finished output where as > > texinfo files will still need to be processed by maketexi? > > (makeinfo) > > But I think you're thinking of texi references as more difficult > than they are -- unless I'm missing something ... > > > > Grant Jacobs wrote: > > > > Don't include format per se, but include some style class information > > > > like 'header' 'text' etc so that it can be appropriately formatted > > > > later. > > > > > > I'd prefer sections to headers. The difference may be small, but > > > rather than inserting headers here and there, this will structure > > > the documentation. I suppose that smaller units will not need > > > sections at all, but for larger ones they could be useful. One > > > hierarchy level should be enough, though. > > > > > Yes and even better do the section at the top and down in the > > function/procedure documenation have a tag that indicates what section > > this belongs to. That way you have the formater do the work of filling > > out the section documentation. > > I don't know exactly how you mean this, but what I do not want is to > have to specify the section for each declaration. Most of the time, > declarations belonging in one section are written next to each other > (and I don't even see a problem to make this a fixed rule), so > specifying where a new section starts should be all that's required. > > > But I do think the first things we need to decide is what do we use to > > indicate a command/tag and what tags/commands do we need. And what the > > tag/command should do. Lets keep it to that for now and leave how it > > should work or how you should use them for later. For example: > > > > ~ = this indicates a command ( I'm not advicating ~ it is just a good > > starting point as it is not reserved, it is not a compiler commad like > > {@ is and will most likly not be used in documentation. ) > > See above. > > > ~bold = this will mark the following text in bold. > > ~end = This ends a format command. > > My problem with these are that they make the text (in the source > form) harder to read -- it's easier (mentally) to read over symbols > than words. > > That's why I suggested symbolic forms for the most common purposes > (`...', <...>, *...*). And even for the occasional "named" command, > I prefer a symbol at the end (such as @foo{...}). > As I stated above I need to learn more about texinfo. And I do agree that symbolic forms are/should be easer to read. Anyways give me a little time to look into texinfo a little more for the output side. But in the mean time I think we need to move this discusion over to what symbols do we need, What can we figure out from the code so don't need symbols for ect.... I will try to make a first pass today if for no other reason than to get it going. Richard From gpc-doc-owner@gnu.de Sun Feb 2 03:25:47 2003 Received: from smtp2.clear.net.nz ([203.97.37.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18f9pJ-0003tv-00 for ; Sun, 02 Feb 2003 03:25:45 +0100 Received: from [203.167.170.214] (203-167-170-214.dialup.clear.net.nz [203.167.170.214]) by smtp2.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0H9N00LQVTDA2F@smtp2.clear.net.nz> for gpc-doc@gnu.de; Sun, 02 Feb 2003 15:24:49 +1300 (NZDT) Date: Sun, 02 Feb 2003 15:26:43 +1300 From: Grant Jacobs Subject: Re: Some observations [GHJ] In-reply-to: <200301301730.SAA31487@goedel.fjf.gnu.de> X-Sender: biot/grant.jacobs@pop.clear.net.nz To: Frank Heckenbach , gpc-doc@gnu.de Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <200301280204.DAA12034@goedel.fjf.gnu.de> <1043732400.4799.36.camel@gigaflop.1gig.net> <200301290441.FAA30843@goedel.fjf.gnu.de> <1043911804.30673.50.camel@gigaflop.1gig.net> <200301301730.SAA31487@goedel.fjf.gnu.de> X-Archive-Number: 200302/4 X-Sequence-Number: 30 At 6:30 PM +0100 30/1/03, Frank Heckenbach wrote: >Richard D. Jackson wrote: > > > But not a whole lot of stuff. Leave formating and structure up to the >> output code. This is how POD, JavaDoc ( core stuff that is ) and a few >> others do. That way if you don't like the output you can write your own >> output generator that will format it the way you want. Core Doxygen does >> this as well but becasue the backend dictates the output form/layout it >> has had many output generaters created for it. But I think its down fall >> is that it does allow the programmer to use or embed form/layout stuff >> for specific output generaters which means the programmer spends can >> spend too much time trying to do some special form/layout verses just > > writing the doc. > >I basically agree. Though I think there is some amount of markup we >need. E.g., to mark identifiers (see above, with references for >identifiers mentioned besides the current ones), and to mark >sections of code etc. E.g., the description of gpc.pas:CanRead >currently says: [snip] >Grant Jacobs wrote: > >> Don't include format per se, but include some style class information >> like 'header' 'text' etc so that it can be appropriately formatted >> later. > >I'd prefer sections to headers. The difference may be small, but >rather than inserting headers here and there, this will structure >the documentation. I suppose that smaller units will not need >sections at all, but for larger ones they could be useful. One >hierarchy level should be enough, though. I think what Richard was driving at is that this level of annotation is to be done outside the code, after the fact. In the code, you just have the elements. Later you style the elements into some formatted structure. The formatted structure would be defined, say, in a style sheet (etc.) which would be separate from the code & initial doc output. Or are we missing eachother's points??? (Or agreeing and crossing on our explanations!?) > > Its a good point, but I think processing all the files in a single >> pass has exactly the same flaw as compiling code in the same fashion. >> The interface/implementation approach was developed for that reason. > >I don't know if speed is a real concern here, but still I'd prefer >the separate translation approach, too. I wasn't thinking of speed but independence of each module, ie. that documenting one module can go ahead independently of the other to a degree if the cross-referenced bits are accessed/checked/coordinated in some sensible manner. (Think of how given another module's definition components, you can (in principle!) develop a separate module, compiling against the definition module.) Put another way, I was probably thinking more along the lines where different (sub)projects need to refer to eachother, which as you commented is a somewhat different issue. Anyway, this is probably too complex for this project... Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs@bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. From gpc-doc-owner@gnu.de Sun Feb 2 03:49:28 2003 Received: from smtp1.clear.net.nz ([203.97.33.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18fACE-000462-00 for ; Sun, 02 Feb 2003 03:49:26 +0100 Received: from [203.167.170.214] (203-167-170-214.dialup.clear.net.nz [203.167.170.214]) by smtp1.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0H9N00M0QUGQOS@smtp1.clear.net.nz> for gpc-doc@gnu.de; Sun, 02 Feb 2003 15:48:29 +1300 (NZDT) Date: Sun, 02 Feb 2003 15:50:24 +1300 From: Grant Jacobs Subject: Re: Some observations [GHJ] In-reply-to: <1044152878.2081.10.camel@gigaflop.1gig.net> X-Sender: biot/grant.jacobs@pop.clear.net.nz To: gpc-doc@gnu.de Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <1043911804.30673.50.camel@gigaflop.1gig.net> <200301301730.SAA31487@goedel.fjf.gnu.de> <1043992009.31980.52.camel@gigaflop.1gig.net> <200302010506.GAA26018@goedel.fjf.gnu.de> <1044152878.2081.10.camel@gigaflop.1gig.net> X-Archive-Number: 200302/5 X-Sequence-Number: 31 At 8:27 PM -0600 1/2/03, Richard D. Jackson wrote: >On Fri, 2003-01-31 at 23:06, Frank Heckenbach wrote: >> >> > Take a look at this >> > http://java.sun.com/j2se/1.4.1/docs/api/index.html >> > ignore the stuf at the top and scroll down to the section containing the >> > method documentation. This is the type of format/output I would like to >> > see the html ouput engine produce for a function/procedure. I wouldn't >> > mind seeing that type of output on the texinfo side either but I >> > definatly want it on the html side. Now to do that type of formating >> > will require that the documenter mark what is what. >> >> Could you please give an exact URL of the page you mean? The URL >> above contains a frameset with several menus, I'm not sure exactly >> what to look at. >> >Sorry about that try this: >http://java.sun.com/j2se/1.4.1/docs/api/java/awt/Paint.html >And look at the Method Detail section at the bottom. There happens to be >only one method for this but it does show what I'm thinking about. Spot on. Much like that layout from Web Design in a Nutshell as I was referring to earlier (I did post that didn't I?), but with all the bits together in one place. I still prefer the layout of WDIN as it interates with written documentation well (not the automatic annotations, but the long hand description of the aims and use of some feature which usually written after the fact). Also it means there are short appendices with just the least needed to remind you of the keywords, parameters, etc. But this style is good for an on-line doc. FWIW, I'm interested in that particular layout as its how I intend to doc my APIs. Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs@bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. From gpc-doc-owner@gnu.de Sun Feb 2 04:18:37 2003 Received: from smtp2.clear.net.nz ([203.97.37.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18fAeR-0004Mg-00 for ; Sun, 02 Feb 2003 04:18:36 +0100 Received: from [203.167.170.214] (203-167-170-214.dialup.clear.net.nz [203.167.170.214]) by smtp2.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0H9N00I2AVTBLQ@smtp2.clear.net.nz> for gpc-doc@gnu.de; Sun, 02 Feb 2003 16:17:38 +1300 (NZDT) Date: Sun, 02 Feb 2003 16:19:33 +1300 From: Grant Jacobs Subject: Re: Some observations [GHJ] In-reply-to: <1043992009.31980.52.camel@gigaflop.1gig.net> X-Sender: biot/grant.jacobs@pop.clear.net.nz To: "Richard D. Jackson" , gpc-doc@gnu.de Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <200301280204.DAA12034@goedel.fjf.gnu.de> <1043732400.4799.36.camel@gigaflop.1gig.net> <200301290441.FAA30843@goedel.fjf.gnu.de> <1043911804.30673.50.camel@gigaflop.1gig.net> <200301301730.SAA31487@goedel.fjf.gnu.de> <1043992009.31980.52.camel@gigaflop.1gig.net> X-Archive-Number: 200302/6 X-Sequence-Number: 32 At 11:46 PM -0600 30/1/03, Richard D. Jackson wrote: >On Thu, 2003-01-30 at 11:30, Frank Heckenbach wrote: > > Richard D. Jackson wrote: > > > > To do this automatically, the cross reference list you suggested >> might be useful. I.e., while translating the GPC documentation, this >> list is produced and stored somewhere, and when translating the >> documentation of another project, it could use this list to find out >> which identifiers should have their references pointing to the GPC >> documentation. >> >Exactly! And with the list would be the exact link to it so you can go >directly to it. The problem is that Texinfo will split it up and I don't >know enough texinfo yet to look into how to do that for texinfo. HTML >would be easy as you are going direct to finished output where as >texinfo files will still need to be processed by maketexi? This is actually along the lines of what I was trying to refer to with the implementation/definition/cross-ref thing... you'd need doc modules to 'export' the references that other doc modules can refer to, etc. Practically, its probably better to have a program scan the docs for marked up keywords, which can simply be added to a cross-ref file. You could easily have one for each doc file, that represented the compiled symbol refs for that doc, which can then be referred to by any other, etc. You could do it via one long list, which I think is what you're suggesting, or one for each doc file. I was thinking of the latter originally, but one cross ref file is probably enough for this project I suspect ! :-) > > Grant Jacobs wrote: >> >> > Don't include format per se, but include some style class information >> > like 'header' 'text' etc so that it can be appropriately formatted >> > later. >> >> I'd prefer sections to headers. The difference may be small, but >> rather than inserting headers here and there, this will structure >> the documentation. I suppose that smaller units will not need >> sections at all, but for larger ones they could be useful. One >> hierarchy level should be enough, though. >> >Yes and even better do the section at the top and down in the >function/procedure documenation have a tag that indicates what section >this belongs to. That way you have the formater do the work of filling >out the section documentation. Do you mean "posting" to other sections of the resulting docs here (using a "target section" a kind of address concept here), so that different doc comments can go to different parts of the resulting docs? > > > Its a good point, but I think processing all the files in a single >> > pass has exactly the same flaw as compiling code in the same fashion. >> > The interface/implementation approach was developed for that reason. >> >> I don't know if speed is a real concern here, but still I'd prefer >> the separate translation approach, too. >> >I need to think about this some more :) See my previous post & above. I wasn't really referring to speed, but rather how to cross-ref docs yet maintain independence between them. Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs@bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. From gpc-doc-owner@gnu.de Sun Feb 2 04:31:47 2003 Received: from smtp2.clear.net.nz ([203.97.37.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18fArC-0004TZ-00 for ; Sun, 02 Feb 2003 04:31:46 +0100 Received: from [203.167.170.214] (203-167-170-214.dialup.clear.net.nz [203.167.170.214]) by smtp2.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0H9N00IFJWFALQ@smtp2.clear.net.nz> for gpc-doc@gnu.de; Sun, 02 Feb 2003 16:30:48 +1300 (NZDT) Date: Sun, 02 Feb 2003 16:32:43 +1300 From: Grant Jacobs Subject: Re: Some observations [GHJ] In-reply-to: <200301302203.XAA04807@goedel.fjf.gnu.de> X-Sender: biot/grant.jacobs@pop.clear.net.nz To: Frank Heckenbach , gpc-doc@gnu.de Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <200301302203.XAA04807@goedel.fjf.gnu.de> X-Archive-Number: 200302/7 X-Sequence-Number: 33 At 11:03 PM +0100 30/1/03, Frank Heckenbach wrote: >Grant Jacobs wrote: > >> What I'm suggesting is a little different. Provide a framework within >> the docs that users can add their own observations to, but one that >> such that readers can see that its a user contribution. Then users >> can add as little or much as they like. >> >> You'd occasionally want an editor to run over the whole thing and >> make it more consistent. (Or have two versions of the docs - last >> edited version and the free-for-all version) >> >> >In the end, it really comes down to the fact that someone has to >> >write the stuff ... >> > >> >Actually, it's not a big issue for me to apply documentation changes >> >I get (and to review them for serious mistakes) -- a simple patch >> >sent to me or the gpc-doc list will do. I've been getting some up to >> >now -- but unfortunately too sporadic and by far not enough to >> >really cover the holes ... >> >> If you can get the automatic docs out in some format, have a field >> 'user notes' or whatever present. Let the users add to that. You can >> then receive contrib.s as diffs or simply merge the new and old docs. > >OK, I think I can do that -- to add an input form at the bottom of >each page, so anything entered there will appear on the page (just >above the input form I guess) marked as user notes, and is sent to >me so I can put it into the main documentation if it's alright. Is >that what you mean? I was thinking more of a field like the ones already there. E.g. You have for each item synopsis, description ... see also. I was thinking after 'see also' add 'User's observations' (or some-such) This way their observations are tied to each element, rather the bottom of each page. Let that field be added to by users as they see fit. Periodically spring-clean shifting bits that look OK to the main ("certified" :-) ) part of the docs. Its a little awkward, but ideally you'd have a section like this after every section in the docs. You could filter the docs so that empty User observation sections are stripped (outside the appendix listings of the keywords, that is; these probably should have a fixed format as they do now so its easier for a reader to spot missing stuff) before making the PDFs, etc. So, say I want to add some of my own observations to '3.4.6 What about C strings', I can submit/add to a 3.4.6U (of sorts), which will appear under 'User observations' (or whatever) in that section. Later these can be integrated if they are deemed OK, or possibly junked if they can be contradicted. Would this be too difficult? Or am I too confusing :-) >I'm still skeptical how much it will gain us in the end, but since >there's not much to lose, I'll try it (with the next update) ... You gotta try!! If there is an easy route for people to add their bits they are more likely to do it - we hope... Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs@bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. From gpc-doc-owner@gnu.de Sun Feb 2 05:27:30 2003 Received: from adsl-64-217-81-216.dsl.austtx.swbell.net ([64.217.81.216] helo=gigabyte.1gig.net ident=nobody) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18fBj4-0004gZ-00 for ; Sun, 02 Feb 2003 05:27:27 +0100 Received: from [192.168.1.2] (gigaflop.1gig.net [192.168.1.2]) by gigabyte.1gig.net (Postfix) with ESMTP id 190F65D10 for ; Sat, 1 Feb 2003 22:26:29 -0600 (CST) Subject: Re: Some observations [GHJ] From: "Richard D. Jackson" To: gpc-doc@gnu.de In-Reply-To: References: <1043911804.30673.50.camel@gigaflop.1gig.net> <200301301730.SAA31487@goedel.fjf.gnu.de> <1043992009.31980.52.camel@gigaflop.1gig.net> <200302010506.GAA26018@goedel.fjf.gnu.de> <1044152878.2081.10.camel@gigaflop.1gig.net> Content-Type: text/plain Organization: Message-Id: <1044160584.2082.24.camel@gigaflop.1gig.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1- Date: 01 Feb 2003 22:36:24 -0600 Content-Transfer-Encoding: 7bit X-Archive-Number: 200302/8 X-Sequence-Number: 34 On Sat, 2003-02-01 at 20:50, Grant Jacobs wrote: > At 8:27 PM -0600 1/2/03, Richard D. Jackson wrote: > >On Fri, 2003-01-31 at 23:06, Frank Heckenbach wrote: > >> > >> > Take a look at this > >> > http://java.sun.com/j2se/1.4.1/docs/api/index.html > >> > ignore the stuf at the top and scroll down to the section containing the > >> > method documentation. This is the type of format/output I would like to > >> > see the html ouput engine produce for a function/procedure. I wouldn't > >> > mind seeing that type of output on the texinfo side either but I > >> > definatly want it on the html side. Now to do that type of formating > >> > will require that the documenter mark what is what. > >> > >> Could you please give an exact URL of the page you mean? The URL > >> above contains a frameset with several menus, I'm not sure exactly > >> what to look at. > >> > >Sorry about that try this: > >http://java.sun.com/j2se/1.4.1/docs/api/java/awt/Paint.html > >And look at the Method Detail section at the bottom. There happens to be > >only one method for this but it does show what I'm thinking about. > > Spot on. Much like that layout from Web Design in a Nutshell as I was > referring to earlier (I did post that didn't I?), No I don't recall seeing it. > but with all the > bits together in one place. I still prefer the layout of WDIN as it > interates with written documentation well (not the automatic > annotations, but the long hand description of the aims and use of > some feature which usually written after the fact). Also it means > there are short appendices with just the least needed to remind you > of the keywords, parameters, etc. do you have a URL for example output of WDIN? > But this style is good for an on-line doc. > > FWIW, I'm interested in that particular layout as its how I intend to > doc my APIs. > > Grant It is allso the way I want to do mine as well. But I think for a first pass I will take a harder look at what frank wants as it is not nearly as complicated as what we want. Besides I can add the stuff we want later but still have the things that frank wants as well. Also I like some of the ideas he has and adding some features to get fancer output should not be hard if I design it with that in mind from the get go. But one of the things I really need to do is look over what texinfo can or can'nt do. Because I would really like my online doc's and printed docs to have a simular layout if possible. Richard From gpc-doc-owner@gnu.de Sun Feb 2 08:01:51 2003 Received: from smtp2.clear.net.nz ([203.97.37.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18fE8S-0005FF-00 for ; Sun, 02 Feb 2003 08:01:49 +0100 Received: from [203.167.170.214] (203-167-170-214.dialup.clear.net.nz [203.167.170.214]) by smtp2.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0H9O0035I65ANR@smtp2.clear.net.nz> for gpc-doc@gnu.de; Sun, 02 Feb 2003 20:00:49 +1300 (NZDT) Date: Sun, 02 Feb 2003 20:02:43 +1300 From: Grant Jacobs Subject: Re: Some observations [GHJ] In-reply-to: <1044160584.2082.24.camel@gigaflop.1gig.net> X-Sender: biot/grant.jacobs@pop.clear.net.nz To: gpc-doc@gnu.de Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <1043911804.30673.50.camel@gigaflop.1gig.net> <200301301730.SAA31487@goedel.fjf.gnu.de> <1043992009.31980.52.camel@gigaflop.1gig.net> <200302010506.GAA26018@goedel.fjf.gnu.de> <1044152878.2081.10.camel@gigaflop.1gig.net> <1044160584.2082.24.camel@gigaflop.1gig.net> X-Archive-Number: 200302/9 X-Sequence-Number: 35 At 10:36 PM -0600 1/2/03, Richard D. Jackson wrote: > > Spot on. Much like that layout from Web Design in a Nutshell as I was >> referring to earlier (I did post that didn't I?), >No I don't recall seeing it. See below. > > but with all the >> bits together in one place. I still prefer the layout of WDIN as it >> interates with written documentation well (not the automatic >> annotations, but the long hand description of the aims and use of >> some feature which usually written after the fact). Also it means >> there are short appendices with just the least needed to remind you >> of the keywords, parameters, etc. > >do you have a URL for example output of WDIN? = Web Design in a Nutshell, in cause you didn't guess! If the sample chapter HTML page is anything to go by, I dont think the new book is quite as good as the old with respect the layout of this section; its shown better below in my typing I think. Here's the bit I though I'd posted earlier, which ought to explain it (makes me wonder if I ought to repost the full post - it had a few other bits in it too) : >Since the list is generated automatically, this should be rather >easy to do. But would it help, or be more confusing? Hmm. Both, but in my ideal world (!) I'd lay out the docs. in a different way. To me the best indexing/reference scheme I have seen is in 'Web Design in a Nutshell' (O'Reilly). I wish O'Reilly would use it in their other books. The index (or appendix) has the keywords in alphabetical order, referring you to an appendix with brief synopses of the keywords in alphabetical order. These, in turn, refer you to a complete synopsis at the head of a chapter. If you still can't remember how to use the thing, you're conveniently at the start of the chapter that covers that subject area needed to (re)learn it. The beauty of this is that it can be read either front-to-back or as a reference via the index/appendices without either disrupting the use of the other. For example, in the index, points to p473, which contains Chapter 11, page 207 ------------------------------------------------- Description: Frameset Attributes: border bordercolour cols frameborder framespacing ... Page 207 has the full synopsis, with standards support and short descriptions of the keyword's functions, eg: NN: 2,3,4 - MSIE: 3,4,5 - HTML 4 - WebTV - Opera3 ------------------------------------------------------------------------ ... Defines a collection of frames or other framesets Attributes border=number Sets frame border thickness (in pixels) ... ... If you're _still_ stuck, you read the chapter that follows. There is a nice hierarchy that you traverse, stopping when you've reached the level you need. If you're learning, you read from the front. This looks like a lot of work, but if done from HeaderDoc or the like, it might be possible to automate much of this straight from descriptions in the source code. It shouldn't be too hard to make the HTML docs like this with links for the page nos., or likewise links in PDFs. I have to admit I have a vested interest in this layout, as its its precisely how I'd like to publish my API docs... Besides, we could aim to write our own O'Reilly Nutshell book :-) JK! (And I really mean JK!) > > But this style is good for an on-line doc. > > > > FWIW, I'm interested in that particular layout as its how I intend to > > doc my APIs. >> >> Grant >It is allso the way I want to do mine as well. By this, I meant the way the WDIN book is laid out. Which, since you haven't seen it, can't be what you're referring to...! So, err, what _are_ you referring to?! >But I think for a first >pass I will take a harder look at what frank wants as it is not nearly >as complicated as what we want. I get that impression too. >But one of the things I really need to do is look over what texinfo can >or can'nt do. Because I would really like my online doc's and printed >docs to have a simular layout if possible. Personally I'm going to leave texinfo out of mine, but that has to do with the fact that I want it to tie in with my little computer language project and I don't want that too dependent on other things as if it even come to completion it'll have to stand on its own two little feet ;-) Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs@bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. From gpc-doc-owner@gnu.de Mon Feb 3 03:12:21 2003 Received: from adsl-64-217-81-216.dsl.austtx.swbell.net ([64.217.81.216] helo=gigabyte.1gig.net ident=nobody) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18fW5r-0000DS-00 for ; Mon, 03 Feb 2003 03:12:19 +0100 Received: from [192.168.1.2] (gigaflop.1gig.net [192.168.1.2]) by gigabyte.1gig.net (Postfix) with ESMTP id 91BC35C65 for ; Sun, 2 Feb 2003 20:11:08 -0600 (CST) Subject: Re: Some observations [GHJ] From: "Richard D. Jackson" To: gpc-doc@gnu.de In-Reply-To: References: <1043911804.30673.50.camel@gigaflop.1gig.net> <200301301730.SAA31487@goedel.fjf.gnu.de> <1043992009.31980.52.camel@gigaflop.1gig.net> <200302010506.GAA26018@goedel.fjf.gnu.de> <1044152878.2081.10.camel@gigaflop.1gig.net> <1044160584.2082.24.camel@gigaflop.1gig.net> Content-Type: text/plain Organization: Message-Id: <1044238861.4084.4.camel@gigaflop.1gig.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1- Date: 02 Feb 2003 20:21:01 -0600 Content-Transfer-Encoding: 7bit X-Archive-Number: 200302/10 X-Sequence-Number: 36 On Sun, 2003-02-02 at 01:02, Grant Jacobs wrote: > At 10:36 PM -0600 1/2/03, Richard D. Jackson wrote: > > > Spot on. Much like that layout from Web Design in a Nutshell as I was > >> referring to earlier (I did post that didn't I?), > >No I don't recall seeing it. > > See below. > > > > but with all the > >> bits together in one place. I still prefer the layout of WDIN as it > >> interates with written documentation well (not the automatic > >> annotations, but the long hand description of the aims and use of > >> some feature which usually written after the fact). Also it means > >> there are short appendices with just the least needed to remind you > >> of the keywords, parameters, etc. > > > >do you have a URL for example output of WDIN? > > = Web Design in a Nutshell, in cause you didn't guess! Oh you are talking about a book! No I did not know or guess. Which version is it. The local used book store may have a copy I can take a look at. > > > > But this style is good for an on-line doc. > > > > > > FWIW, I'm interested in that particular layout as its how I intend to > > > doc my APIs. > >> > >> Grant > >It is allso the way I want to do mine as well. > > By this, I meant the way the WDIN book is laid out. Which, since you > haven't seen it, can't be what you're referring to...! So, err, what > _are_ you referring to?! > I was refering to the link into the javadoc's > >But I think for a first > >pass I will take a harder look at what frank wants as it is not nearly > >as complicated as what we want. > > I get that impression too. > > >But one of the things I really need to do is look over what texinfo can > >or can'nt do. Because I would really like my online doc's and printed > >docs to have a simular layout if possible. > > Personally I'm going to leave texinfo out of mine, but that has to do > with the fact that I want it to tie in with my little computer > language project and I don't want that too dependent on other things > as if it even come to completion it'll have to stand on its own two > little feet ;-) > Then what are you going to use for hard copy production? Richard From gpc-doc-owner@gnu.de Mon Feb 3 05:46:05 2003 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian)) id 18fYUa-0000fY-00 for ; Mon, 03 Feb 2003 05:46:00 +0100 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id FAA30762 for ; Mon, 3 Feb 2003 05:00:50 +0100 Date: Mon, 3 Feb 2003 05:00:50 +0100 Message-Id: <200302030400.FAA30762@goedel.fjf.gnu.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii Subject: Re: Some observations [GHJ] To: gpc-doc@gnu.de References: <200301302203.XAA04807@goedel.fjf.gnu.de> In-Reply-To: From: Frank Heckenbach X-Mailer: semail 20030101 X-Archive-Number: 200302/11 X-Sequence-Number: 37 Grant Jacobs wrote: > >OK, I think I can do that -- to add an input form at the bottom of > >each page, so anything entered there will appear on the page (just > >above the input form I guess) marked as user notes, and is sent to > >me so I can put it into the main documentation if it's alright. Is > >that what you mean? > > I was thinking more of a field like the ones already there. E.g. You > have for each item synopsis, description ... see also. > > I was thinking after 'see also' add 'User's observations' (or some-such) > > This way their observations are tied to each element, rather the > bottom of each page. Let that field be added to by users as they see > fit. Periodically spring-clean shifting bits that look OK to the main > ("certified" :-) ) part of the docs. Perhaps we mean the same thing. By page I meant HTML pages, not printed pages in the PS/PDF version, and in HTML, each routine etc. has its own page. (Or do you actually mean one input field for synopsis, one for description, etc.? I think that would be too much.) I've now set up a test version of the GPC pages with the input forms as I understand them at http://www.gnu-pascal.de/test-input/. (Some links may not work correctly, or point to the original page, but this is only a demo.) This way has the advantage that it was relatively easy to set up, and it can be applied to basically any HTML page. Let me know what you think of it. Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 From gpc-doc-owner@gnu.de Mon Feb 3 05:46:07 2003 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian)) id 18fYUa-0000fa-00 for ; Mon, 03 Feb 2003 05:46:00 +0100 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id FAA30023 for ; Mon, 3 Feb 2003 05:42:44 +0100 Date: Mon, 3 Feb 2003 05:42:44 +0100 Message-Id: <200302030442.FAA30023@goedel.fjf.gnu.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii Subject: Re: Some observations [GHJ] To: gpc-doc@gnu.de References: <200301261454.PAA32546@goedel.fjf.gnu.de> <1043681772.3862.32.camel@gigaflop.1gig.net> <1044152878.2081.10.camel@gigaflop.1gig.net> <1044160584.2082.24.camel@gigaflop.1gig.net> In-Reply-To: <1044152878.2081.10.camel@gigaflop.1gig.net> <1044160584.2082.24.camel@gigaflop.1gig.net> From: Frank Heckenbach X-Mailer: semail 20030101 X-Archive-Number: 200302/12 X-Sequence-Number: 38 Grant Jacobs wrote: > >It is in texinfo format in the ./p/doc/[lang] directory. also it seems > >some of the doc is generated as well. > > Do you might telling me exactly where this is located :-) - ie. URL, > etc. Is not on the website, nor my installation and ftp'ing ft.gnu.de > doesn't any me any joy... It's in the GPC source distributions. Richard D. Jackson wrote: > As I stated above I need to learn more about texinfo. And I do agree > that symbolic forms are/should be easer to read. Anyways give me a > little time to look into texinfo a little more for the output side. Given the original copyright notice in my draft (1999) and that it's been laying around since then, I guess you can take all the time you need. :-) > But > in the mean time I think we need to move this discusion over to what > symbols do we need, What can we figure out from the code so don't need > symbols for ect.... Exactly. I think identifiers will have to be marked up in some way since some identifiers are words that occur in normal language, so automatic recognition would be overkill. What would be possible automatically though (however with some effort), is to detect whether a given identifier is - the current one - directly belonging to the current one (i.e., record/object field, routine parameter) - in another package (if we do the reference list) - in the same package (either via multi-pass, in case it's further down, or simply by assumption if nothing of the above cases matches) I think it's fair to say that all identifiers of the last two classes should go into the "see also" section automatically (which should take care of a large part of these sections already). Grant Jacobs wrote: > >Grant Jacobs wrote: > > > >> Don't include format per se, but include some style class information > >> like 'header' 'text' etc so that it can be appropriately formatted > >> later. > > > >I'd prefer sections to headers. The difference may be small, but > >rather than inserting headers here and there, this will structure > >the documentation. I suppose that smaller units will not need > >sections at all, but for larger ones they could be useful. One > >hierarchy level should be enough, though. > > I think what Richard was driving at is that this level of annotation > is to be done outside the code, after the fact. In the code, you just > have the elements. Later you style the elements into some formatted > structure. The formatted structure would be defined, say, in a style > sheet (etc.) which would be separate from the code & initial doc > output. Or are we missing eachother's points??? (Or agreeing and > crossing on our explanations!?) If that's Richard's point, I don't think I agree. I prefer to have all information contained in the source file. So everyone who gets the (Pascal) source also has the full documentation implicitly. I don't really see a "visual" problem with sectioning comments in a source file, either. Many use some kind of them (e.g., lines of `***', `===' or whatever) anyway, and turning them into a slightly different form would not be a big change. So you actually get up to three levels: - The units that a projects consists of (if several ones) which can be turned into sections automatically, of course. - The explicit sections within a unit via comments which can become subsections in the output. - If you will, blocks of related constants etc. (say, the color constants in the CRT unit) which do not need individual comments. Though they probably shouldn't be separate sections, but rather several entries on one page. > > > Its a good point, but I think processing all the files in a single > >> pass has exactly the same flaw as compiling code in the same fashion. > >> The interface/implementation approach was developed for that reason. > > > >I don't know if speed is a real concern here, but still I'd prefer > >the separate translation approach, too. > > I wasn't thinking of speed but independence of each module, ie. that > documenting one module can go ahead independently of the other to a > degree if the cross-referenced bits are accessed/checked/coordinated > in some sensible manner. (Think of how given another module's > definition components, you can (in principle!) develop a separate > module, compiling against the definition module.) Put another way, I > was probably thinking more along the lines where different > (sub)projects need to refer to eachother, which as you commented is a > somewhat different issue. This is probably also a concern with GPC for some time since the various units will probably be documented at different speeds. However, in my idea, the utility can even process a completely uncommented source file. It will then generate basically skeleton entries (though I can understand well if you don't exactly like them, given the amount of them in the current manual ;-). At least they would contain the unit name and synopsis, so they're better than nothing, and they'd allow for references from other modules to work (i.e., point to the skeleton instead of missing) ... Grant Jacobs wrote: > This is actually along the lines of what I was trying to refer to > with the implementation/definition/cross-ref thing... you'd need doc > modules to 'export' the references that other doc modules can refer > to, etc. > > Practically, its probably better to have a program scan the docs for > marked up keywords, which can simply be added to a cross-ref file. > You could easily have one for each doc file, that represented the > compiled symbol refs for that doc, which can then be referred to by > any other, etc. This might be useful. Though I think I'd rather have a single program do both (probably controllable by options), because having several "parsers" for the same "input language" (i.e., the marked up comments) can more easily lead to inconsistencies ... > You could do it via one long list, which I think is what you're > suggesting, or one for each doc file. I was thinking of the latter > originally, but one cross ref file is probably enough for this > project I suspect ! :-) If the files are translated separately, I guess also the reference files will have to be separate, but that's a detail and will turn out when it's implemented. Richard D. Jackson wrote: > But one of the things I really need to do is look over what texinfo can > or can'nt do. Because I would really like my online doc's and printed > docs to have a simular layout if possible. That's precisely the goal of texinfo. It is not a universal formatter (unless you use explicit conditionals for the different output formats), but within its scope, it provides for equivalent documentation in the various formats from a single source (which IMHO is absolutely essential for GPC, given the amount of stuff to be documented, and the lack of human resources to even maintain several overlapping documentations) ... Grant Jacobs wrote: > >But I think for a first > >pass I will take a harder look at what frank wants as it is not nearly > >as complicated as what we want. > > I get that impression too. When I reviewed my draft before posting, I actually wondered if it wasn't too complex already. ;-) But we can always discuss whether some particular features should be added or omitted ... Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 From gpc-doc-owner@gnu.de Mon Feb 3 07:17:12 2003 Received: from smtp1.clear.net.nz ([203.97.33.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18fZun-00012a-00 for ; Mon, 03 Feb 2003 07:17:09 +0100 Received: from [203.167.130.59] (203-167-130-59.dialup.clear.net.nz [203.167.130.59]) by smtp1.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0H9P002XDYQGI7@smtp1.clear.net.nz> for gpc-doc@gnu.de; Mon, 03 Feb 2003 19:15:55 +1300 (NZDT) Date: Mon, 03 Feb 2003 19:17:53 +1300 From: Grant Jacobs Subject: Re: Some observations [GHJ] In-reply-to: <200302030400.FAA30762@goedel.fjf.gnu.de> X-Sender: biot/grant.jacobs@pop.clear.net.nz To: Frank Heckenbach , gpc-doc@gnu.de Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <200301302203.XAA04807@goedel.fjf.gnu.de> <200302030400.FAA30762@goedel.fjf.gnu.de> X-Archive-Number: 200302/13 X-Sequence-Number: 39 At 5:00 AM +0100 3/2/03, Frank Heckenbach wrote: >Grant Jacobs wrote: > >> >OK, I think I can do that -- to add an input form at the bottom of >> >each page, so anything entered there will appear on the page (just >> >above the input form I guess) marked as user notes, and is sent to >> >me so I can put it into the main documentation if it's alright. Is >> >that what you mean? >> >> I was thinking more of a field like the ones already there. E.g. You >> have for each item synopsis, description ... see also. >> >> I was thinking after 'see also' add 'User's observations' (or some-such) >> >> This way their observations are tied to each element, rather the >> bottom of each page. Let that field be added to by users as they see >> fit. Periodically spring-clean shifting bits that look OK to the main >> ("certified" :-) ) part of the docs. > >Perhaps we mean the same thing. By page I meant HTML pages, not >printed pages in the PS/PDF version, and in HTML, each routine etc. >has its own page. (Or do you actually mean one input field for >synopsis, one for description, etc.? I think that would be too >much.) Right, we did get confused on the word page! Its like me trying not to use the word client in case my prospective customers think I'm referring to them instead of the client in the client-server stuff... What I was thinking was that 'User observations' would appear as the last keyword/section in each portion of the resulting documentation. >I've now set up a test version of the GPC pages with the input forms >as I understand them at http://www.gnu-pascal.de/test-input/. (Some >links may not work correctly, or point to the original page, but >this is only a demo.) This way has the advantage that it was >relatively easy to set up, and it can be applied to basically any >HTML page. > >Let me know what you think of it. You're way ahead of me :-) This is very nice! Its a wonder other projects don't do something this. (Do they?) Now I guess we (you!) get to sit back and if anything happens. Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs@bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. From gpc-doc-owner@gnu.de Mon Feb 3 11:38:52 2003 Received: from smtp1.clear.net.nz ([203.97.33.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18fXxS-0000ZU-00 for ; Mon, 03 Feb 2003 05:11:46 +0100 Received: from [203.167.180.187] (203-167-180-187.dialup.clear.net.nz [203.167.180.187]) by smtp1.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0H9P00IIGSXJFI@smtp1.clear.net.nz> for gpc-doc@gnu.de; Mon, 03 Feb 2003 17:10:34 +1300 (NZDT) Date: Mon, 03 Feb 2003 17:12:31 +1300 From: Grant Jacobs Subject: Re: Some observations [GHJ] In-reply-to: <1044238861.4084.4.camel@gigaflop.1gig.net> X-Sender: biot/grant.jacobs@pop.clear.net.nz To: gpc-doc@gnu.de Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <1043911804.30673.50.camel@gigaflop.1gig.net> <200301301730.SAA31487@goedel.fjf.gnu.de> <1043992009.31980.52.camel@gigaflop.1gig.net> <200302010506.GAA26018@goedel.fjf.gnu.de> <1044152878.2081.10.camel@gigaflop.1gig.net> <1044160584.2082.24.camel@gigaflop.1gig.net> <1044238861.4084.4.camel@gigaflop.1gig.net> X-Archive-Number: 200302/14 X-Sequence-Number: 40 At 8:21 PM -0600 2/2/03, Richard D. Jackson wrote: > > = Web Design in a Nutshell, in cause you didn't guess! >Oh you are talking about a book! No I did not know or guess. Which >version is it. The local used book store may have a copy I can take a >look at. Mine is version the first edition (its now second Ed.) 4/99 print run. > > Personally I'm going to leave texinfo out of mine, but that has to do > > with the fact that I want it to tie in with my little computer >> language project and I don't want that too dependent on other things >> as if it even come to completion it'll have to stand on its own two > > little feet ;-) > > >Then what are you going to use for hard copy production? I probably should have written this better. There are two reason I guess. I have my own data structure for playing around with text. Eventually, I'd like to try to use this for parsing, etc., but in the interim it seemed to me that doc notes would be simpler chance for me to try it out, etc. In that sense my aims are rather different. The other is that I wanted to leave the dependencies downstream as much as possible and hence the exact mechanism of hard copy production downstream too. There has to be a mechanism obviously, but I don't want to tie it to one (eg. textinfo) right from the onset. Its something of a contradiction in terms because obviously you have to tie it to _something_. Initially I want a basic key-word based internal text format that can be converted into whatever at a later stage. My initial thought is to use XML/HTML or the like. That said, I suppose it could just as easily be textinfo instead of XML... Precisely what it is could (and will) come later as its just a format after all. I want to focus on just getting a code-based layout going first. (In practice this will likely be a text rep. of the binary data structure, but that's another story; debugging, etc.) This project is a back burner as I have a hell of a lot of things to do to try make $$ -- I have a salary that comes out of the sky, so I can't afford to get _too_ sidetracked. That's why I thought it might be better for me to focus on the content of the docs and just making comments as far as the doc parser goes. [long-winded aren't I?!] I think you're probably heading roughly the same way, albeit just using plain text, so perhaps this textinfo thing is misleading. Out of curiosity: any thought to just allowing POD to work on GPC? Say by using //= as the lead-in (since // is a comment lead-in, and = is the POD lead-in. E.g. strip all ' '*// then hand off to POD). Spoils the fun though eh? Also I suppose dealing with the types/vars/etc might be clumsy. I suppose you could do the same with textinfo and //@. Sorry, I just had to throw this in ;-) Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs@bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. From gpc-doc-owner@gnu.de Tue Feb 4 10:57:16 2003 Received: from adsl-64-217-81-216.dsl.austtx.swbell.net ([64.217.81.216] helo=gigabyte.1gig.net ident=nobody) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18fvgz-0007fI-00 for ; Tue, 04 Feb 2003 06:32:21 +0100 Received: from [192.168.1.2] (gigaflop.1gig.net [192.168.1.2]) by gigabyte.1gig.net (Postfix) with ESMTP id 40FE05DA6 for ; Mon, 3 Feb 2003 23:30:54 -0600 (CST) Subject: Re: Some observations [GHJ] From: "Richard D. Jackson" To: gpc-doc@gnu.de In-Reply-To: References: <1043911804.30673.50.camel@gigaflop.1gig.net> <200301301730.SAA31487@goedel.fjf.gnu.de> <1043992009.31980.52.camel@gigaflop.1gig.net> <200302010506.GAA26018@goedel.fjf.gnu.de> <1044152878.2081.10.camel@gigaflop.1gig.net> <1044160584.2082.24.camel@gigaflop.1gig.net> <1044238861.4084.4.camel@gigaflop.1gig.net> Content-Type: text/plain Organization: Message-Id: <1044337244.16875.9.camel@gigaflop.1gig.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1- Date: 03 Feb 2003 23:40:44 -0600 Content-Transfer-Encoding: 7bit X-Archive-Number: 200302/15 X-Sequence-Number: 41 On Sun, 2003-02-02 at 22:12, Grant Jacobs wrote: > At 8:21 PM -0600 2/2/03, Richard D. Jackson wrote: > > > = Web Design in a Nutshell, in cause you didn't guess! > >Oh you are talking about a book! No I did not know or guess. Which > >version is it. The local used book store may have a copy I can take a > >look at. > > Mine is version the first edition (its now second Ed.) 4/99 print run. > > > > Personally I'm going to leave texinfo out of mine, but that has to do > > > with the fact that I want it to tie in with my little computer > >> language project and I don't want that too dependent on other things > >> as if it even come to completion it'll have to stand on its own two > > > little feet ;-) > > > > >Then what are you going to use for hard copy production? > > I probably should have written this better. There are two reason I guess. > > I have my own data structure for playing around with text. > Eventually, I'd like to try to use this for parsing, etc., but in the > interim it seemed to me that doc notes would be simpler chance for me > to try it out, etc. In that sense my aims are rather different. > > The other is that I wanted to leave the dependencies downstream as > much as possible and hence the exact mechanism of hard copy > production downstream too. There has to be a mechanism obviously, but > I don't want to tie it to one (eg. textinfo) right from the onset. You might want to take a look at texinfo as it looks to have most everything you would need for both printed and hard copy. It is also very strait forward. It is also less combersome than XML and requires fewer tools to work with. My biggest dislike of texinfo has mostly been with the online viewers ( aka info ) versas with texinfo itself. > Its something of a contradiction in terms because obviously you have > to tie it to _something_. Initially I want a basic key-word based > internal text format that can be converted into whatever at a later > stage. My initial thought is to use XML/HTML or the like. That said, > I suppose it could just as easily be textinfo instead of XML... > Precisely what it is could (and will) come later as its just a format > after all. I want to focus on just getting a code-based layout going > first. (In practice this will likely be a text rep. of the binary > data structure, but that's another story; debugging, etc.) This > project is a back burner as I have a hell of a lot of things to do to > try make $$ -- I have a salary that comes out of the sky, so I can't > afford to get _too_ sidetracked. That's why I thought it might be > better for me to focus on the content of the docs and just making > comments as far as the doc parser goes. [long-winded aren't I?!] > > I think you're probably heading roughly the same way, albeit just > using plain text, so perhaps this textinfo thing is misleading. > Out of curiosity: any thought to just allowing POD to work on GPC? > Say by using //= as the lead-in (since // is a comment lead-in, and = > is the POD lead-in. E.g. strip all ' '*// then hand off to POD). > Spoils the fun though eh? Also I suppose dealing with the > types/vars/etc might be clumsy. I suppose you could do the same with > textinfo and //@. Sorry, I just had to throw this in ;-) > > You could write a quick and dirty perl script to do that if it is what you want. But as you say dealing with the language ellements would be the tricky part. > Grant Take a look at my reply to Frank in the next email... Richard From gpc-doc-owner@gnu.de Tue Feb 4 10:57:26 2003 Received: from adsl-64-217-81-216.dsl.austtx.swbell.net ([64.217.81.216] helo=gigabyte.1gig.net ident=nobody) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18fwTB-0007qy-00 for ; Tue, 04 Feb 2003 07:22:09 +0100 Received: from [192.168.1.2] (gigaflop.1gig.net [192.168.1.2]) by gigabyte.1gig.net (Postfix) with ESMTP id 9B6694B22 for ; Tue, 4 Feb 2003 00:20:42 -0600 (CST) Subject: Re: Some observations [GHJ] From: "Richard D. Jackson" To: gpc-doc@gnu.de In-Reply-To: <200302030442.FAA30023@goedel.fjf.gnu.de> References: <200301261454.PAA32546@goedel.fjf.gnu.de> <1043681772.3862.32.camel@gigaflop.1gig.net> <1044152878.2081.10.camel@gigaflop.1gig.net> <1044160584.2082.24.camel@gigaflop.1gig.net> <200302030442.FAA30023@goedel.fjf.gnu.de> Content-Type: text/plain Organization: Message-Id: <1044340232.16880.56.camel@gigaflop.1gig.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1- Date: 04 Feb 2003 00:30:32 -0600 Content-Transfer-Encoding: 7bit X-Archive-Number: 200302/16 X-Sequence-Number: 42 On Sun, 2003-02-02 at 22:42, Frank Heckenbach wrote: > Grant Jacobs wrote: > > Richard D. Jackson wrote: > > > As I stated above I need to learn more about texinfo. And I do agree > > that symbolic forms are/should be easer to read. Anyways give me a > > little time to look into texinfo a little more for the output side. > > Given the original copyright notice in my draft (1999) and that it's > been laying around since then, I guess you can take all the time you > need. :-) > > > But > > in the mean time I think we need to move this discusion over to what > > symbols do we need, What can we figure out from the code so don't need > > symbols for ect.... > > Exactly. I think identifiers will have to be marked up in some way > since some identifiers are words that occur in normal language, so > automatic recognition would be overkill. What would be possible > automatically though (however with some effort), is to detect > whether a given identifier is > > - the current one > > - directly belonging to the current one (i.e., record/object field, > routine parameter) > > - in another package (if we do the reference list) > > - in the same package (either via multi-pass, in case it's further > down, or simply by assumption if nothing of the above cases > matches) > > I think it's fair to say that all identifiers of the last two > classes should go into the "see also" section automatically (which > should take care of a large part of these sections already). > I actualy got some time the other day and took a little harder look at pasdoc. And you know something it has most of what we want. Including a very simple markup style. It only looks at comments in the interface section and all non escaped comments are included in the documentation where the comment is placed right before the procedure/function var, const, class ect... It also contains a fairly complet pascal language parser. It uses this to figure out what the laguage elements are after the comment. And it fully indexes everything. The one down fall is that it only outputs TeX and HTML. But from what I can see adding texinfo should not be hard. So for the time being I'm going to spend some more time looking at it and see if I can get it to compile on gpc. Then I'm going to spend some time cleaning it up as the original author has allot of conditional code so it will build with quite a few differant compilers. Seeing that I'm only interested in gpc I may remove that stuff. I've tried to contact the auther ( Marco Schmidt ) but my email bounced. I will try again but he may have moved on. Luckly the code is under the GPL so it won't be a problem for me or gpc to use it. But I should change the name though. > Grant Jacobs wrote: > > > >Grant Jacobs wrote: > > > > > >> Don't include format per se, but include some style class information > > >> like 'header' 'text' etc so that it can be appropriately formatted > > >> later. > > > > > >I'd prefer sections to headers. The difference may be small, but > > >rather than inserting headers here and there, this will structure > > >the documentation. I suppose that smaller units will not need > > >sections at all, but for larger ones they could be useful. One > > >hierarchy level should be enough, though. > > > > I think what Richard was driving at is that this level of annotation > > is to be done outside the code, after the fact. In the code, you just > > have the elements. Later you style the elements into some formatted > > structure. The formatted structure would be defined, say, in a style > > sheet (etc.) which would be separate from the code & initial doc > > output. Or are we missing eachother's points??? (Or agreeing and > > crossing on our explanations!?) > > If that's Richard's point, I don't think I agree. I prefer to have > all information contained in the source file. So everyone who gets > the (Pascal) source also has the full documentation implicitly. I do agree with you here BTW. But I also think that Grant is thinking the same thing but we are crossing on explanations. Grant's comment above I think is on the presentation side of things versers the content side. > I don't really see a "visual" problem with sectioning comments in a > source file, either. Many use some kind of them (e.g., lines of > `***', `===' or whatever) anyway, and turning them into a slightly > different form would not be a big change. > > So you actually get up to three levels: > > - The units that a projects consists of (if several ones) which can > be turned into sections automatically, of course. > > - The explicit sections within a unit via comments which can become > subsections in the output. > > - If you will, blocks of related constants etc. (say, the color > constants in the CRT unit) which do not need individual comments. > Though they probably shouldn't be separate sections, but rather > several entries on one page. > > > > > Its a good point, but I think processing all the files in a single > > >> pass has exactly the same flaw as compiling code in the same fashion. > > >> The interface/implementation approach was developed for that reason. > > > > > >I don't know if speed is a real concern here, but still I'd prefer > > >the separate translation approach, too. > > > > I wasn't thinking of speed but independence of each module, ie. that > > documenting one module can go ahead independently of the other to a > > degree if the cross-referenced bits are accessed/checked/coordinated > > in some sensible manner. (Think of how given another module's > > definition components, you can (in principle!) develop a separate > > module, compiling against the definition module.) Put another way, I > > was probably thinking more along the lines where different > > (sub)projects need to refer to eachother, which as you commented is a > > somewhat different issue. > > This is probably also a concern with GPC for some time since the > various units will probably be documented at different speeds. > > However, in my idea, the utility can even process a completely > uncommented source file. It will then generate basically skeleton > entries (though I can understand well if you don't exactly like > them, given the amount of them in the current manual ;-). At least > they would contain the unit name and synopsis, so they're better > than nothing, and they'd allow for references from other modules to > work (i.e., point to the skeleton instead of missing) ... > Yes Even if no documentation is provided then if nothing else it should document what is there. What functions/procedures vars, records ect. where each is a seperate index/section point. > Grant Jacobs wrote: > > > This is actually along the lines of what I was trying to refer to > > with the implementation/definition/cross-ref thing... you'd need doc > > modules to 'export' the references that other doc modules can refer > > to, etc. > > > > Practically, its probably better to have a program scan the docs for > > marked up keywords, which can simply be added to a cross-ref file. > > You could easily have one for each doc file, that represented the > > compiled symbol refs for that doc, which can then be referred to by > > any other, etc. > > This might be useful. Though I think I'd rather have a single > program do both (probably controllable by options), because having > several "parsers" for the same "input language" (i.e., the marked up > comments) can more easily lead to inconsistencies ... Yes I agree a single tool to do both jobs. Where the default is to output both the documenation and a machine readable index. > > > You could do it via one long list, which I think is what you're > > suggesting, or one for each doc file. I was thinking of the latter > > originally, but one cross ref file is probably enough for this > > project I suspect ! :-) > > If the files are translated separately, I guess also the reference > files will have to be separate, but that's a detail and will turn > out when it's implemented. > > Richard D. Jackson wrote: > > > But one of the things I really need to do is look over what texinfo can > > or can'nt do. Because I would really like my online doc's and printed > > docs to have a simular layout if possible. > > That's precisely the goal of texinfo. It is not a universal > formatter (unless you use explicit conditionals for the different > output formats), but within its scope, it provides for equivalent > documentation in the various formats from a single source (which > IMHO is absolutely essential for GPC, given the amount of stuff to > be documented, and the lack of human resources to even maintain > several overlapping documentations) ... > I really need to make the time to read the texinfo manual :) If the explicit conditionals you mentioned above will let me do what I want for the HTML output then I just may end up with one output format. With a switch to pretty up the HTML if you want it. > Grant Jacobs wrote: > > > >But I think for a first > > >pass I will take a harder look at what frank wants as it is not nearly > > >as complicated as what we want. > > > > I get that impression too. > > When I reviewed my draft before posting, I actually wondered if it > wasn't too complex already. ;-) But we can always discuss whether > some particular features should be added or omitted ... > Your draft is significaly simpler than pasdoc but then again pasdoc spends most of its time figuring things out from the code so that the code becomes a source for the documentation. Which is the right way to do it as it makes writing the documentation easer on the programmer. Boy has my list of things todo increased from this conversation: 1) Read the texinfo manual 2) port and update pasdoc 3) learn more about pascal. Well if nothing else porting and updating pasdoc will make me learn more pascal. And I think it is a worthy first project as it will cover most of the language scope. Richard From gpc-doc-owner@gnu.de Wed Feb 5 05:17:26 2003 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian)) id 18gH01-0006Q5-00 for ; Wed, 05 Feb 2003 05:17:25 +0100 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id AAA28816 for ; Wed, 5 Feb 2003 00:01:21 +0100 Date: Wed, 5 Feb 2003 00:01:21 +0100 Message-Id: <200302042301.AAA28816@goedel.fjf.gnu.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii Subject: Re: Some observations [GHJ] To: gpc-doc@gnu.de References: <1044160584.2082.24.camel@gigaflop.1gig.net> <200302030442.FAA30023@goedel.fjf.gnu.de> <1044340232.16880.56.camel@gigaflop.1gig.net> <1044337244.16875.9.camel@gigaflop.1gig.net> In-Reply-To: <1044340232.16880.56.camel@gigaflop.1gig.net> <1044337244.16875.9.camel@gigaflop.1gig.net> From: Frank Heckenbach X-Mailer: semail 20030101 X-Archive-Number: 200302/17 X-Sequence-Number: 43 Richard D. Jackson wrote: > > That's precisely the goal of texinfo. It is not a universal > > formatter (unless you use explicit conditionals for the different > > output formats), but within its scope, it provides for equivalent > > documentation in the various formats from a single source (which > > IMHO is absolutely essential for GPC, given the amount of stuff to > > be documented, and the lack of human resources to even maintain > > several overlapping documentations) ... > > > I really need to make the time to read the texinfo manual :) It might look quite complex initially (there are many things that are rarely used). Sometimes it's easier to just look at some existing documentation ... > If the > explicit conditionals you mentioned above will let me do what I want for > the HTML output then I just may end up with one output format. Yes, they look like this (from GPC's documentation): @ifhtml @html
[Gnu and Blaise Pascal]
(PNG, 10 KB)
@end html @end ifhtml `@ifhtml' is the conditional (there are `@if[not]{html,info,plaintext,tex}'), and `@html' allows for verbatim HTML code. > With a > switch to pretty up the HTML if you want it. If you mean me, I'm not sure if I want it. I think I'd have too see a concrete example and what the "pretty up" would do, but I guess we'll find out in time ... > Your draft is significaly simpler than pasdoc but then again pasdoc > spends most of its time figuring things out from the code so that the > code becomes a source for the documentation. Which is the right way to > do it as it makes writing the documentation easer on the programmer. Yes, I expect this to be the difficult part. The output should be the considerably easier bit. > My biggest dislike of texinfo has mostly been > with the online viewers ( aka info ) versas with texinfo itself. You mean the "default" info reader? I don't like is as well (I find it harder to use than vi, and I'm not a fan of vi ;-). But that's not the only one that exists. RHIDE as well as my editor PENG contain their own info readers and I think emacs also does, and probably more programs. But if you prefer HTML or PDF, just use that. :-) Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 From gpc-doc-owner@gnu.de Wed Feb 5 05:56:32 2003 Received: from adsl-64-217-81-216.dsl.austtx.swbell.net ([64.217.81.216] helo=gigabyte.1gig.net ident=nobody) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18gHbp-0006g0-00 for ; Wed, 05 Feb 2003 05:56:29 +0100 Received: from [192.168.1.2] (gigaflop.1gig.net [192.168.1.2]) by gigabyte.1gig.net (Postfix) with ESMTP id 0281A5C65 for ; Tue, 4 Feb 2003 22:56:26 -0600 (CST) Subject: Re: Some observations [GHJ] From: "Richard D. Jackson" To: gpc-doc@gnu.de In-Reply-To: <200302042301.AAA28816@goedel.fjf.gnu.de> References: <1044160584.2082.24.camel@gigaflop.1gig.net> <200302030442.FAA30023@goedel.fjf.gnu.de> <1044340232.16880.56.camel@gigaflop.1gig.net> <1044337244.16875.9.camel@gigaflop.1gig.net> <200302042301.AAA28816@goedel.fjf.gnu.de> Content-Type: text/plain Organization: Message-Id: <1044421574.19649.15.camel@gigaflop.1gig.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1- Date: 04 Feb 2003 23:06:15 -0600 Content-Transfer-Encoding: 7bit X-Archive-Number: 200302/18 X-Sequence-Number: 44 On Tue, 2003-02-04 at 17:01, Frank Heckenbach wrote: > Richard D. Jackson wrote: > > > > That's precisely the goal of texinfo. It is not a universal > > > formatter (unless you use explicit conditionals for the different > > > output formats), but within its scope, it provides for equivalent > > > documentation in the various formats from a single source (which > > > IMHO is absolutely essential for GPC, given the amount of stuff to > > > be documented, and the lack of human resources to even maintain > > > several overlapping documentations) ... > > > > > I really need to make the time to read the texinfo manual :) > > It might look quite complex initially (there are many things that > are rarely used). Sometimes it's easier to just look at some > existing documentation ... > > > If the > > explicit conditionals you mentioned above will let me do what I want for > > the HTML output then I just may end up with one output format. > > Yes, they look like this (from GPC's documentation): > > @ifhtml > @html >
> > [Gnu and Blaise Pascal]
> (PNG, 10 KB) > >
> @end html > @end ifhtml > > `@ifhtml' is the conditional (there are > `@if[not]{html,info,plaintext,tex}'), and `@html' allows for > verbatim HTML code. > Great that will get what I need/want. But that is on the back burner as I want to get texinfo working first. > > With a > > switch to pretty up the HTML if you want it. > > If you mean me, I'm not sure if I want it. I think I'd have too see > a concrete example and what the "pretty up" would do, but I guess > we'll find out in time ... > When I get to it there I will make up some samples. > > Your draft is significaly simpler than pasdoc but then again pasdoc > > spends most of its time figuring things out from the code so that the > > code becomes a source for the documentation. Which is the right way to > > do it as it makes writing the documentation easer on the programmer. > > Yes, I expect this to be the difficult part. The output should be > the considerably easier bit. > True that is the reason I'm going to work on pasdoc as all of the hard stuff is done. I just need to figure out how it does it so I can maintain it and modify it for our use. > > My biggest dislike of texinfo has mostly been > > with the online viewers ( aka info ) versas with texinfo itself. > > You mean the "default" info reader? I don't like is as well (I find > it harder to use than vi, and I'm not a fan of vi ;-). But that's > not the only one that exists. RHIDE as well as my editor PENG > contain their own info readers and I think emacs also does, and > probably more programs. But if you prefer HTML or PDF, just use > that. :-) > I will have to look into RHIDE and PENG. Richard From gpc-doc-owner@gnu.de Thu Feb 6 06:37:42 2003 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian)) id 18gejF-0001Au-00 for ; Thu, 06 Feb 2003 06:37:41 +0100 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id AAA01187 for ; Thu, 6 Feb 2003 00:45:23 +0100 Date: Thu, 6 Feb 2003 00:45:23 +0100 Message-Id: <200302052345.AAA01187@goedel.fjf.gnu.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii Subject: Re: Some observations [GHJ] To: gpc-doc@gnu.de References: <200301302203.XAA04807@goedel.fjf.gnu.de> <200302030400.FAA30762@goedel.fjf.gnu.de> In-Reply-To: From: Frank Heckenbach X-Mailer: semail 20030101 X-Archive-Number: 200302/19 X-Sequence-Number: 45 Grant Jacobs wrote: > >I've now set up a test version of the GPC pages with the input forms > >as I understand them at http://www.gnu-pascal.de/test-input/. (Some > >links may not work correctly, or point to the original page, but > >this is only a demo.) This way has the advantage that it was > >relatively easy to set up, and it can be applied to basically any > >HTML page. > > > >Let me know what you think of it. > > You're way ahead of me :-) This is very nice! Its a wonder other > projects don't do something this. (Do they?) I haven't seen this before. This is just what came to my mind when I read your mails, and it was surprisingly easy to implement. > Now I guess we (you!) > get to sit back and if anything happens. As soon as it's on the official pages. I'll do that with the next update (perhaps next week). Until then, it would be nice of some of you could test it to make sure it basically works ... Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 From gpc-doc-owner@gnu.de Sat Feb 22 19:13:00 2003 Received: from adsl-64-217-81-216.dsl.austtx.swbell.net ([64.217.81.216] helo=gigabyte.1gig.net ident=nobody) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18me8w-0007df-00 for ; Sat, 22 Feb 2003 19:12:58 +0100 Received: from [192.168.1.2] (gigaflop.1gig.net [192.168.1.2]) by gigabyte.1gig.net (Postfix) with ESMTP id 3B5114B22 for ; Sat, 22 Feb 2003 12:12:11 -0600 (CST) Subject: More on documentation tool From: "Richard D. Jackson" To: gpc-doc@gnu.de Content-Type: multipart/mixed; boundary="=-uYkbIP2vW/ophFwJUVAC" Organization: Message-Id: <1045938078.20189.10.camel@gigaflop.1gig.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1- Date: 22 Feb 2003 12:21:18 -0600 X-Archive-Number: 200302/20 X-Sequence-Number: 46 --=-uYkbIP2vW/ophFwJUVAC Content-Type: text/plain Content-Transfer-Encoding: 7bit Well I've spent some time to learn texinfo. Well I should say I've gone over it and think I understand how it works that is. Anyways there are a few things I want to achive before working on pas2texi. They are in order: 1) A sample of expected output from the program. This will serve as a guide when I start to code. It will also let us agree on what that output should be. 2) A some what complete manual for the program. Again this will serve as a guide when I start to code. It will also allow us argue and or discuss the implementation details. 3) Start coding. So as a start here is an initial draft of what I think the output should be. It is the texinfo source that you can use makeinfo to transform into info/html. So after you have had a chance to look at it lets talk about it and revise it to fit what we want as far as output goes that is. Richard --=-uYkbIP2vW/ophFwJUVAC Content-Disposition: attachment; filename=rts.texi.gz Content-Type: application/x-gzip; name=rts.texi.gz Content-Transfer-Encoding: base64 H4sICBi7Vz4AA3J0cy50ZXhpAO1cbXPbNhL+jl+B6d1N7ZysOm6v19rTGylu nGjGcTyW3E7G15uDSMjChAJYArStpv7vt7sAQUqiX1O7Tnv+EgIEwGeBZ98A KP9WOi8dd/JC6YlhvYT/7dkz60ThuJnwqRSpLFjPSjdRmdRiJnnhbNe3hVqn XCb5aCr5q4NjfihsIjJ+VGqnoOVwbp2c8TdClyILQ0udNgdO+Hc3/2Gz7+VE acmtgXG1POdKp/JC2m63i293jQbM2vlq1kvlJDGppBJPjGZQpYpEOHlqinkT 674aF6JQ0lILqV0xZ8/4q8NdfjQabvM1kHa9yxf/WkT1w8wBDAoYR+olJp8r fcpGU2X5jCaCw9PEFNy1T1ocie1C30KdTh2nYejxwyV//u2332xsbW5u8b1C wiSbiTsXheR7ptSpcMroDh/oBAbol25qim1oJ/R7/lom76Uei2TKe3ImVPZh gvW9Xk4Auqe67KbyknmsmYeBYPNAhhosjN37uTSOvsYaQqBoCMoGUDt8bkqe CM0LmSrrCjUuneTKcaHTL2ASZiZVkzmDCgAv/aQ4WcwsfrCaoVdSywJGPyzH mUpghhKpreQCoGGNncqUjefU/Kop2eFSwfuCn8nCQplvdTh8fk04RFgwk2Or dYA15xnQJDYEURflq8VIgW300anJAfUUxgI5zlWW8bHkpZWTMutwaMl+HIxe vz0e8f7BO/5j/+iofzB6twMtYXlA9+SZ9OOoWZ4pGBaww8q4OcwBe/PyaPc1 tO+/GOwPRu8Q9N5gdPByOOR7b494nx/2j0aD3eP9/hE/PD46fDt82eVDKavJ Y1dM3oQmH+YolQ64YEHOd7BUFhBlKZ+KM1B0mUh1BngER/7dvCJMZEafklwN suxwG+CgCeG7bw/fDQ5edflgwrVxHX5eKKCEM9iEXU3pf3zLRxImSPLDTCSS b/BhiR2//HKzw18Y67DRmz7b3Hr+/PnG8y83/9nhx8M+qoEFCWwuEwWI5UUi cz+imhA7MwXK4ZDzhI/Q45MFqWc5PKSM6gTJFOoKBJwXJi0BCtAbbFFSOjHO ZMePlRoYAOQD8gMTGIpfSFtmDqxBozUOA2RJDNANZjqweHWKWZjiLiftjFLU 35macyBSAZw8E5mCWZNEZoOsZ4UUFkwkP5/6DzQAkNAzMjOtQK4gULB0tRWg YmXuWI8cQy5OZXi8xj+sgbVdZz1B1uqOxqrnP6EAUeGqrxOUGgBaYe3AIFtG 5huaT2DGHDoKDV6Cj0wOKE1+I8bQe/VjcUB0Rs9+y78VF3kC/hTszkzqkv90 C+e5/Eci/OYgEQ74zR/AlSKr7Pb2ks+MbzrRWcOjwIWa5xIZnZvC1cxj/Jq/ anEsLU4XPvxGQKcZMBHXrgCrCsGCB4Fv+KTUCbLU0hdBbxOZlqCP2HV3KgqR oMlf6Ad/9Zvr+g8wyFiRF//oDZpNAS7hrJ6Auj8NFwcPOkVz+fBEIi4dIP/j gtyJUA+AkLQxMgU+MBU5Tn9dxQba21crac4qpxRCK5zoUNOY72SRcKydcS3K 7/nF0RWlJilhYaA9Bj9LdL+a7eBeMW6NHylWmFtN/soYGFRH5H6c9LqBRiBV Kw1HJO4NQB6ZeZF71UzdhXoPzTzMbDy7Yg34X+tWqBUnNQSCLRSCOFqEeL7n HW4PMxMORYXc2hPv5WvwvvuQS0HEyXpnPmlZqQ+dhVU2dP1eJplAZ91HVYFB Pyx12oa4yGRS6J3L2MUmhaLIgUH8BQkcaEdl5Sz/13f8L3/9ZpMIL6wFwqch QMn8iD5WVTQNLDNNYwsaoj933Io5RP8hTFEYeb3PyvRUwiAUCVEGxzzrqj4U bSamgIDTQSyjN17qUwzruf8CSV4ZR+eXY+H5MfkaM80nwNcKS83XWLPA191F K3ItX/fb+VrR9Y242IcYf4AfBePkueorHVU2aMpXecoDUeth+HccGcvXQnl9 55K3kHVENv5CzcoZqF9WAj89sA+h3yVlmWO5RJMKNCjyUP0iF0HHytvoVt0e IEMBsafqjH/TplycvQlgLXbAECBajauJ/EhMjlxGx3C3GPKhmIxIahZTaYHB iy7s7uz1C3S4O4TUXZ+iNfUkaNa0cMB/LlIgtgYG/GdUFVqN66FR2vksMTZs o+ZoBdLoTpBGDUi4azDnJ5u8222wm0iKD28nfC20Xv8JJzYUWvH3aSxoZK/G Dhrw9VcRd1W6GTO1BLzwrzyFOVr7+qv1VhDQaqxwT4/atUE41upiBAvv+ROQ LFXeDKjZAXAFi9IK6dh6lzg1WRpiATRGMFElDMKRhF3eg0mDMT4cgu8Fj3dg nNy+rBwieNt0Az+bssDjakuhy783fstgKjR4TEjc282ZSgozlGDJUkQd5V6t v1n0pT43SU97dBSUFiXpahu+PRAGCbewKEuVNyNrdrgzrBZUQyfc3vBFOZng vnNAtVR5LaozWYwhwZxx1uwF0CBsMUUKCesLiFfeI+aOf7Qj40RWFXBra5vk kBZ95Q70QCGrVvTsGwXNYCDEjhel+vg9pH/0SMl7mNaM/CZv81D+pRVMnV+2 v2btIiznjcubETE7HCr9enubUjzrH/pFMhJ6i54HdqCBXMrNQxHMRP+gnI1l QRXDPFPuSIoMSo+enNEKIv67bzE91BIimjpE8KVJ0GIswLtyjMdKuME6nGuT kxpHxYHcw+K5zg6r9lu8gGsX2xyned3/s6JvjVGXA1JvqHCUtYv1y7iPAwbB lYW2/mwAzFcxNrhzavEACzzFRYefT1UypdMEb2DYrEG1bI5HG2vAMxiWbyDh 1jYu1tf5F3yruwDo5YXAHXFWtpiA5mxIyfuZNax3UcjJh9c1pL1q66mDiSpB nHa4L1x2HjEiJcKhntyVcA+XW9nXzbzK1nSjwj3oRuJ9NN1wlFvRLTEthGNV DH014f7+mIQDkDXhuo/Gt5PKFN/Zvj0U3wKemnKxIrCuKt+DeKHr2jxwjn8s B6sBLzrzJhGBSkmJp6eei6JIIPCAcEfHPM6dm8bu2QXD7dh5lw8c2kKrZgqS bgyvq5EQQstQc2AmsjqcgzE6e6WGVp1qOjseGzyyK05p09bSjlYZYvdU4gkz 6gb2+LkUKZ624mFrfUq3SPsj0jD+A8b6NA3Cofjr7TroR8AstYDuArke9A+l 5GPpzqXUbONwQNvR8M+a0klWWnUm1z9O31ra/eaEvWZXoY5pfudthUqrakC1 YjXrgm41qu6hXk2x0bxjiB/Uq9p/vaWG3bDMFRva1/7xFjqsdR2w3nq1H3Ch azTNpW7WxsVuVN5vuRuS/5EW/KqN75iKPJXgLAJqJAR1VZUVxJrbL3I8mW3I 3FzhHfResCy50eBWYqLuq9+AF1HWigYh7pFNVN+9rI+J0W1Uzsvie3Iz2hPQ d7u4xG0ywwXTppiJTP0CzauNaw/rkryN0KG6EuKSbuJ4J+u9ZWNIyxluSP0i C9PxH716dGgcO2JCjGc/uTkHiOCO0fN3yN3jmVB2Lua22sYtaLPr+RdbTTeI oj7HkDT6RY4wF5BFVPoW0LAxTQA9YLThTOH3ktnyhHyUC37UFH317sJtVPTB cqYVNPUWS8s71oL+1psr+3g0KI/zXWEl7Zf4in0TKwa28XZgF970s3wqms9g zZeKtK1mEyBJeDHMRVI9Hxagbf7k/9E3Z04WZH8a5zdNRLVNptqqMljlZt19 nO+C7GvJdJuYte7/WTa3V9rbXaOhkfPxuj/bDkYjmV6i7SnzHLUdPkL3BHNj raKzOzw2bzSliB5NJBpWXmrMP4C9eKbujwbomunLt3vefI7lVJwpUxY+IQJp o2Ro43XIzruMk0sIdzOx8TmmOGR9lCsd3RzyIBEjfiNDU0uFIE8qc5gMZsIh Q1ngnWR/pC7Bmu5BH+ltm8cG3xaYt3y2+xkPzbi/XogCsvfanHMxxgur5SwT Jd6msXhegaiqW7V08VHL6n7zDAUZ6HBrG95v8IWjfbycg/cTJeVnyxJYfxcT vsDocoAF+0wrWcstfy4VTDMItuOPBCGxg4mxMP05p+MWRBPE7Iarzc0ppwEy TP9g0cNpEHHrsvOScktyEP/d2BibApqlG/7+4ed4cRkHvKWn+D0DuJMF0/iU 7IVHtGQvqsqmvQh197cXQfb/24s/h70Ac7HBHs1geHL9cQyGNxpV+PQ0DEaF ppnbL0UWseJ+OX1LSHFFMn9NFtckSzKVyXu8ci/phyfRBlSb8XxWWrADdPlt 4SaBwH2BpmGoLAKqfLQzXCR47Ew7pKZNZT8Vrp3E4PyO2wsPx7Vlx1TXRK59 hEuK4j5xrpF9/WNxLdCNcrwncdk9YGlSLVREpvny/YhWJbNPnWrgggVCHUuH J5fVvsBOtUeE11dTUaQ+2PA3jzHScj6gqr167ZXXKpMOoq/zX3+Naodl3PTy YQZbCixmYo73nUWaKhRXZM370RimeCnDTTY/wTQiAyBAc7mxEaMRaomRig4/ PmxYb12FYFT8ZBTopEmqJ6RAAGdFh6huUY2w6s+hSbqcyaKpS1facPbJ2fCT 1m26G+n48BSswbSRsfl2hZaNlx9H0MaEPB5VialtRI0pLmshallDjTT9ZGh4 Um0JP5VDsQCnybxQEcnmy/fjl5f1aVOKWwL56ZHJ0ymeKtyeUg9HpgimSahG ZSRVXXdbYi3wqhb6aXNLz3keodZelY4sCQ5x75Nh3En4dfIdjdcDMs7/zy3V eWEowhw1pqnx02BaC0/BM7zxkfOt5db1z94Wmid0ctvSnn5ktNDU5e0tDxd/ wB0vNS50nuAaj+eS/Q9kE9HpY0cAAA== --=-uYkbIP2vW/ophFwJUVAC-- From gpc-doc-owner@gnu.de Mon Feb 24 09:50:59 2003 Received: from mond.dida.physik.uni-essen.de ([132.252.79.233]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18nEK9-0007ec-00 for ; Mon, 24 Feb 2003 09:50:57 +0100 Received: (from lange@localhost) by mond.dida.physik.uni-essen.de (8.11.6/8.11.6/SuSE Linux 0.5) id h1O8m9601749 for gpc-doc@gnu.de; Mon, 24 Feb 2003 09:48:09 +0100 Date: Mon, 24 Feb 2003 09:48:09 +0100 From: Eike Lange To: gpc-doc@gnu.de Subject: Re: More on documentation tool Message-ID: <20030224094809.A1124@mond.dida.physik.uni-essen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.1i X-Eike-Conspiracy: There is no conspiracy X-Archive-Number: 200302/21 X-Sequence-Number: 47 On Sat, Feb 22, 2003 at 12:21:18PM -0600, Richard D. Jackson wrote: > Anyways there are a few things I want to achive before working on > pas2texi. They are in order: You are working on pas2texi? Fine! > 1) A sample of expected output from the program. This will serve as a > guide when I start to code. It will also let us agree on what that > output should be. Ok, the code normally is licensed (by a header in the top of the .pas file) and the documentation itself must be licensed (always with GFDL or similar). > So as a start here is an initial draft of what I think the output should > be. It is the texinfo source that you can use makeinfo to transform into > info/html. The "node constants" (seen by comment) is really a "node variables". The rest looks fine to me. Happy Hacking ;-) Eike From gpc-doc-owner@gnu.de Thu Feb 27 20:04:47 2003 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian)) id 18oTKm-0006d7-00 for ; Thu, 27 Feb 2003 20:04:44 +0100 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id TAA08922 for ; Thu, 27 Feb 2003 19:53:21 +0100 Date: Thu, 27 Feb 2003 19:53:21 +0100 Message-Id: <200302271853.TAA08922@goedel.fjf.gnu.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii Subject: Re: More on documentation tool To: gpc-doc@gnu.de References: <1045938078.20189.10.camel@gigaflop.1gig.net> In-Reply-To: <1045938078.20189.10.camel@gigaflop.1gig.net> From: Frank Heckenbach X-Mailer: semail 20030101 X-Archive-Number: 200302/22 X-Sequence-Number: 48 Richard D. Jackson wrote: > Well I've spent some time to learn texinfo. Well I should say I've gone > over it and think I understand how it works that is. I think that's enough for most purposes. :-) > Anyways there are a few things I want to achive before working on > pas2texi. They are in order: > > 1) A sample of expected output from the program. This will serve as a > guide when I start to code. It will also let us agree on what that > output should be. > > So as a start here is an initial draft of what I think the output should > be. It is the texinfo source that you can use makeinfo to transform into > info/html. > > So after you have had a chance to look at it lets talk about it and > revise it to fit what we want as far as output goes that is. : * GPC RTS: (rts). GNU Pascal Runtime Library. We usually call it "Runtime System". But that's not a matter of the program -- it will get it from the input data. : @author Frank Heckenbach @email{frank@@pascal.gnu.de} And some more. I'm the only one listed in the file gpc.pas since I wrote this file alone, but the actual implementation was written by many others as well. (That's a special case since usually a unit contains its implementation while gpc.pas is a purely external interface module.) I guess I should simply list all authors in gpc.pas then (will do in the next release) ... : @c ***************************************************************************** : @c =============[ Main menu ]=================================================== : @c ***************************************************************************** I'm not really a friend of such "bold ASCII headers" -- and in an automatically generated file they're not necessary for an author to orientate. But then again, in an automatically generated file they also don't disturb anyone ... : * Variables:: Variables, Constants, and types exported by the : Runtime system. I think those variables, constants and types declared in the sections below should be documented there, so I'd rather call this initial section something like "Misc". But again, this must be done in gpc.pas and should not affect the program, so I don't mind ... (Of course, it's also useful to have a list of all constants etc., but that's already served for by the indices.) : @node Top : @top GNU Pascal Runtime System (GPC) : : [...] : : @chapter Variables BTW, the program should have options to shift down the whole hierarchy one or two levels, e.g. put the main menu in a section and the other nodes in sub- and subsubsections, for inclusion into other texts. (In this case, of course, the texi header and title page would be omitted and the copyright notice inserted only in the main menu node.) : @table @code : : @item MaxLongInt : @conindex MaxLontInt : @table @asis : @item Declared As : @code{MaxLongInt = High (LongInt);} (I'd add `const' here.) : @item Description : The maximum value a @code{LongInt} can be. : @end table : : @item MaxVarSize : @conindex MaxVarSize : @table @asis : @item Declared As : @code{MaxVarSize = MaxInt div 8;} : @item Description : Maximum size of a variable. : @end table : : @end table : @subheading Synopsis : @verbatim : uses GPC; : function SinH (x: Real): Real; : @end verbatim : @subheading Description : The @code{SinH(x)} function returns the hyperbolic sine of x, which is defined : mathematically as (exp(x) - exp(-x)) / 2. : @subheading Example : under construction : @subheading See Also : @xref{Hyperbolic Functions, libc sinh, , libc}, Why use different formatting for constants/variables and routines? I.e., why not use `Synopsis', and subheadings instead of the table for the former as well? Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 From gpc-doc-owner@gnu.de Fri Feb 28 00:23:13 2003 Received: from smtp1.clear.net.nz ([203.97.33.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18oXMt-0008Mj-00 for ; Fri, 28 Feb 2003 00:23:11 +0100 Received: from [203.167.170.152] (203-167-170-152.dialup.clear.net.nz [203.167.170.152]) by smtp1.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0HAZ001GPQ9SVA@smtp1.clear.net.nz> for gpc-doc@gnu.de; Fri, 28 Feb 2003 12:22:43 +1300 (NZDT) Date: Fri, 28 Feb 2003 12:24:33 +1300 From: Grant Jacobs Subject: Weird type/identifier conflicts In-reply-to: <200302271853.TAA08922@goedel.fjf.gnu.de> X-Sender: biot/grant.jacobs@pop.clear.net.nz To: gpc-doc@gnu.de Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <1045938078.20189.10.camel@gigaflop.1gig.net> <200302271853.TAA08922@goedel.fjf.gnu.de> X-Archive-Number: 200302/23 X-Sequence-Number: 49 Excuse my being frustrated. I am trying damn hard to get GPC (2.1 (20020510), based on gcc-2.95.3 20010315 (release)) to compile a Pascal program I wrote some time ago but keep running it things I can't make sense of. Maybe I'm being unfair, but I'll give you the whole story just in case its something new. The latest issue I'm having is a run of type vs. identifier conflict errors of the form: ./GHJ_AARegions.pas:49: type name expected, identifier `Fnames' given ./GHJ_AARegions.pas:49: warning: missing type in declaration of `Infname' ./GHJ_AARegions.pas:54: warning: parameter has incomplete type My trouble was fnames *is* a type. It is *only* defined as a type. So how the heck does the compiler come away thinking that its an identifier????? I eventually resolved this by directly 'using' modules, rather than rely on the hierarchy (read on). When this error occurred the GHJ_AARegions unit uses GHJFnames. GHJFnames in turn uses GHJFiles, which is where the type fnames is defined. (Really these two levels need to be the other way around, but this is a legacy program I am porting, so I have to deal with that after the port.) Since these uses statements were within the interface section, I presumed the definitions would propagate upwards so that they form a hierarchy. Or, put another way, I assumed the interface of a unit is extended by any units it uses in its interface section. Originally, I had: unit GHJ_AARegions ; { Holds routines for dealing with the region indicies. } interface uses GHJStdDefs, GHJStdMaths { for inrange() }, GHJttInterface { for press_return() }, {GHJTextIO} { for skip_aa_comments() } {,} GHJStrings { for get_string8() }, {=>} GHJFnames { for get_fname() }, GHJ_AAErrors, GHJ_AAUtils, GHJ_AAGlobalUnit ; By getting GHJ_AARegions to explicitly, directly, use GHJFiles, the compiler stopped complaining. ie. I changed the above code to: unit GHJ_AARegions ; { Holds routines for dealing with the region indicies. } interface uses GHJStdDefs, GHJStdMaths { for inrange() }, GHJttInterface { for press_return() }, {GHJTextIO} { for skip_aa_comments() } {,} GHJStrings { for get_string8() }, {=>} GHJFiles, GHJFnames { for get_fname() }, GHJ_AAErrors, GHJ_AAUtils, GHJ_AAGlobalUnit ; {=>} points out the offending line of source. If this is truly the problem, then I presume there is no way of building a hierarchy of units in GPC at present? (In this case my safest strategy is to have every unit uses *all* the lower units directly, "just in case". Or put, another way, I might just as well use includes to make everything one big flat program. Sorry, but I *am* frustrated!) Three thoughts: 1. This is the correct behaviour?: surely I should be able to use a higher-level module and have all the lower-level modules definitions within that higher-level module "gotten" at the same time without have to explicitly duck behind the scenes and drag out each module??? Excuse me for asking this, but its not terribly clear from the docs, at least on my reading of it. 2. Why the heck does the compiler report the message it does? "Missing type fnames" perhaps, but since fnames is only ever defined as a type and never as an identifier, it shouldn't be able to report the message it did... 3. Is there any chance you can tell the user where the "identifier" (see the error message) is defined so that in future users might have chance of trying to second-guess just what the compiler is "thinking"? Sorry I can't provide a full code example: I am porting a largish program (approx. 60,000 lines of sources in a dozen or so modules) and in any event I can't understand the problem well enough to create an example - catch-22... Looking at the known bugs for ver. 2.1 there are a couple that might be relevant, esp."Types declared in a module interface are not visible in the implementation" (but does this refer to the same module's interface section and how are units and modules related with reference to this?) While I'm writing, is there any chance you can make the compiler keep trying after one unit has failed, rather than stopping at that point? It seems that if there is even one error in a unit, the compilation is abandoned at the end of that unit. (Now to try figure out how GPC claims a type-mismatch on something that is definitely the same type and the type is only defined in one place... probably the same issue, we'll see...) Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs@bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. From gpc-doc-owner@gnu.de Fri Feb 28 02:51:32 2003 Received: from smtp2.clear.net.nz ([203.97.37.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18oZgR-0000Xv-00 for ; Fri, 28 Feb 2003 02:51:31 +0100 Received: from [203.167.180.17] (203-167-180-17.dialup.clear.net.nz [203.167.180.17]) by smtp2.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0HAZ00LB2X5QSY@smtp2.clear.net.nz> for gpc-doc@gnu.de; Fri, 28 Feb 2003 14:51:28 +1300 (NZDT) Date: Fri, 28 Feb 2003 14:53:20 +1300 From: Grant Jacobs Subject: Re: Weird type/identifier conflicts In-reply-to: X-Sender: biot/grant.jacobs@pop.clear.net.nz To: gpc-doc@gnu.de Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <1045938078.20189.10.camel@gigaflop.1gig.net> <200302271853.TAA08922@goedel.fjf.gnu.de> X-Archive-Number: 200302/24 X-Sequence-Number: 50 At 12:24 PM +1300 28/2/03, Grant Jacobs wrote: >Excuse my being frustrated. I am trying damn hard to get GPC (2.1 Whoops, wrong group, sorry... gpc@ and gpc-doc@ are rather similar if you're in a hurry! I'll try again... ignore my last post. Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs@bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. From gpc-doc-owner@gnu.de Sun Mar 2 06:00:28 2003 Received: from adsl-64-217-81-216.dsl.austtx.swbell.net ([64.217.81.216] helo=gigabyte.1gig.net ident=nobody) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18pLaL-0005SE-00 for ; Sun, 02 Mar 2003 06:00:25 +0100 Received: from [192.168.1.2] (gigaflop.1gig.net [192.168.1.2]) by gigabyte.1gig.net (Postfix) with ESMTP id 1EFA44B22 for ; Sat, 1 Mar 2003 22:59:53 -0600 (CST) Subject: Re: More on documentation tool From: "Richard D. Jackson" To: GNU Pascal Documentation In-Reply-To: <200302282109.WAA10087@goedel.fjf.gnu.de> References: <1045938078.20189.10.camel@gigaflop.1gig.net> <200302271853.TAA08922@goedel.fjf.gnu.de> <1046405155.1764.47.camel@gigaflop.1gig.net> <200302282109.WAA10087@goedel.fjf.gnu.de> Content-Type: text/plain Organization: Message-Id: <1046581723.4553.25.camel@gigaflop.1gig.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1- Date: 01 Mar 2003 23:08:43 -0600 Content-Transfer-Encoding: 7bit X-Archive-Number: 200303/1 X-Sequence-Number: 51 On Fri, 2003-02-28 at 15:09, Frank Heckenbach wrote: > > 1) When moving the vars into the section in which they are declared > > should I make a menu entry for each one or should I do a submenu of > > vars? > > Good question. I'd say it depends. Sometimes, each one deserves its > own entry, other times, there are a list of them which belong > together (e.g., the color constants in the CRT unit). > > Of course, the program can't find this out automatically. One rule > might be, if there's a comment for each of them, put them in > separate sections, like here: > > var > { Address of the lowest byte of heap used } > HeapLow: PtrCard; asmname '_p_HeapLow'; external; > > { Address of the highest byte of heap used } > HeapHigh: PtrCard; asmname '_p_HeapHigh'; external; > > { If set to true, `Dispose' etc. will raise a runtime error if > given an invalid pointer. } > HeapChecking: Boolean; asmname '_p_HeapChecking'; external; > Yes the above is going to strait forward to implement. > But if there's only one comment at the top, put them in one section > all together: > > const > { Foreground and background color constants } > Black = 0; > Blue = 1; > Green = 2; > Cyan = 3; > Red = 4; > Magenta = 5; > Brown = 6; > LightGray = 7; > > Of course, in the indices, there should be entries for each of them. Now this is tricky: 1) What do you call the node/section for this list of vars/functions ect...? 2) You can't just assume that because there is not a comment that it belongs to what was above. If you do what happens for those cases where I haven't finshed writing the documentation for my code? I'm thinking that to solve this we are going to need a group command. Something like {@group group name} .... {@end group } Where 'group name' would be the name used for the section/node. And Yes I agree that every item needs to be placed in the index but what happens in the case where you don't want them all in the index. maybe a option to the @group command. > > > 2) If I where to put them in the section menu how about this menu sytle: > > > > @menu > > * MaxInt:: Const > > * SomeVar:: Var > > * SomeType:: Type > > * FuncFoo:: function > > * ProcFoo:: Procedure > > @end menu > > > > Or > > @menu > > * Const MaxInt:: > > * Var foo:: > > * Type foo:: > > * SomeFunc:: > > * SomeProc:: > > @end menu > > Since the left part of the menu corresponds to the node name, I > prefer the former, so the node name equals the identifier. > > BTW, you sent this mail personally, so I'm replying personally. If > it was meant for the list, feel free to forward and/or quote my mail > there. > Sorry about that.. This one is going to the group... > Frank Oh FYI I've started to work on a manual for pas2texi. As soon as I get it roughed in I will send a copy to the list. Richard From gpc-doc-owner@gnu.de Sun Mar 2 13:01:38 2003 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian)) id 18pS9w-0008SA-00 for ; Sun, 02 Mar 2003 13:01:36 +0100 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id MAA23303 for ; Sun, 2 Mar 2003 12:55:28 +0100 Date: Sun, 2 Mar 2003 12:55:28 +0100 Message-Id: <200303021155.MAA23303@goedel.fjf.gnu.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii Subject: Re: More on documentation tool To: gpc-doc@gnu.de References: <200302271853.TAA08922@goedel.fjf.gnu.de> <1046405155.1764.47.camel@gigaflop.1gig.net> <200302282109.WAA10087@goedel.fjf.gnu.de> <1046581723.4553.25.camel@gigaflop.1gig.net> In-Reply-To: <1046581723.4553.25.camel@gigaflop.1gig.net> From: Frank Heckenbach X-Mailer: semail 20030101 X-Archive-Number: 200303/2 X-Sequence-Number: 52 Richard D. Jackson wrote: > > But if there's only one comment at the top, put them in one section > > all together: > > > > const > > { Foreground and background color constants } > > Black = 0; > > Blue = 1; > > Green = 2; > > Cyan = 3; > > Red = 4; > > Magenta = 5; > > Brown = 6; > > LightGray = 7; > > > > Of course, in the indices, there should be entries for each of them. > Now this is tricky: > 1) What do you call the node/section for this list of vars/functions > ect...? Indeed ... > 2) You can't just assume that because there is not a comment that it > belongs to what was above. If you do what happens for those cases where > I haven't finshed writing the documentation for my code? Well, user's fault. ;-) They can put in an empty comment if just for that, hmm? Of course, any new `const', `type' or `var' block should also break the node. > I'm thinking that to solve this we are going to need a group command. > Something like {@group group name} .... {@end group } > Where 'group name' would be the name used for the section/node. Might be a way to go. > And Yes I agree that every item needs to be placed in the index but what > happens in the case where you don't want them all in the index. maybe a > option to the @group command. Yes, perhaps. Or perhaps a little more general, an indicator that something (whether in a group or not) should not go to the index, or not appear in the documentation at all (`{@undocumented}'?). If expect it to be used very rarely, and still wonder if it's needed at all (in either case), but it probably can't hurt to have it available. Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 From gpc-doc-owner@gnu.de Tue Mar 11 02:54:27 2003 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian)) id 18sYyG-0001NB-00 for ; Tue, 11 Mar 2003 02:54:24 +0100 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id BAA09128 for ; Tue, 11 Mar 2003 01:16:11 +0100 Date: Tue, 11 Mar 2003 01:16:11 +0100 Message-Id: <200303110016.BAA09128@goedel.fjf.gnu.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii Subject: Removing the user input forms To: gpc-doc@gnu.de From: Frank Heckenbach X-Mailer: semail 20030303 X-Archive-Number: 200303/3 X-Sequence-Number: 53 Some weeks ago, I've installed the user input forms on the GPC web pages. Unfortunately, they've not proven too useful yet. The only entries of the intended kind came from Richard Jackson who suggested the forms initially ... Many of the other entries were silly stuff ("Micky Mouse" etc.). Some mistook the forms for a kind of "guestbook". The remaining ones were questions or discussion items. While not useless, they're probably better served by the mailing lists where more interested people will read them (in contrast to the web pages where only those who visit the page again will read it, and I guess many regular users only visit a few pages regularly). Maybe the text above the form isn't clear enough (but maybe it is, and people just don't read it; they see a form and just write whatever they have in mind ...). But as it's now, I don't think the forms are really useful. Therefore, unless someone has an idea how to "rescue" them, I'm afraid they'll be gone in a few days ... Frank -- Frank Heckenbach, frank@g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E) From gpc-doc-owner@gnu.de Tue Mar 11 04:45:43 2003 Received: from adsl-64-217-81-216.dsl.austtx.swbell.net ([64.217.81.216] helo=gigabyte.1gig.net ident=nobody) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18sahx-0001lq-00 for ; Tue, 11 Mar 2003 04:45:41 +0100 Received: from [192.168.1.2] (gigaflop.1gig.net [192.168.1.2]) by gigabyte.1gig.net (Postfix) with ESMTP id A1A714B22; Mon, 10 Mar 2003 21:44:15 -0600 (CST) Subject: Re: Removing the user input forms From: "Richard D. Jackson" To: Frank Heckenbach Cc: GNU Pascal Documentation In-Reply-To: <200303110016.BAA09128@goedel.fjf.gnu.de> References: <200303110016.BAA09128@goedel.fjf.gnu.de> Content-Type: text/plain Organization: Message-Id: <1047354762.2187.2.camel@gigaflop.1gig.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1- Date: 10 Mar 2003 21:52:42 -0600 Content-Transfer-Encoding: 7bit X-Archive-Number: 200303/4 X-Sequence-Number: 54 On Mon, 2003-03-10 at 18:16, Frank Heckenbach wrote: > Some weeks ago, I've installed the user input forms on the GPC web > pages. > > Unfortunately, they've not proven too useful yet. The only entries > of the intended kind came from Richard Jackson who suggested the > forms initially ... > Actualy Grant Jacobs suggested it. > Many of the other entries were silly stuff ("Micky Mouse" etc.). > > Some mistook the forms for a kind of "guestbook". > > The remaining ones were questions or discussion items. While not > useless, they're probably better served by the mailing lists where > more interested people will read them (in contrast to the web pages > where only those who visit the page again will read it, and I guess > many regular users only visit a few pages regularly). > > Maybe the text above the form isn't clear enough (but maybe it is, > and people just don't read it; they see a form and just write > whatever they have in mind ...). But as it's now, I don't think the > forms are really useful. > > Therefore, unless someone has an idea how to "rescue" them, I'm > afraid they'll be gone in a few days ... > I don't have a problem with it going away as I find it easer to just submit a patch to the TexInfo sources. Richard From gpc-doc-owner@gnu.de Tue Mar 11 09:54:30 2003 Received: from mond.dida.physik.uni-essen.de ([132.252.79.233]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18sfWm-0003AQ-00 for ; Tue, 11 Mar 2003 09:54:28 +0100 Received: (from lange@localhost) by mond.dida.physik.uni-essen.de (8.11.6/8.11.6/SuSE Linux 0.5) id h2B8pI401318 for gpc-doc@gnu.de; Tue, 11 Mar 2003 09:51:18 +0100 Date: Tue, 11 Mar 2003 09:51:18 +0100 From: Eike Lange To: gpc-doc@gnu.de Subject: Re: Removing the user input forms Message-ID: <20030311095118.B1124@mond.dida.physik.uni-essen.de> References: <200303110016.BAA09128@goedel.fjf.gnu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303110016.BAA09128@goedel.fjf.gnu.de> User-Agent: Mutt/1.3.22.1i X-Eike-Conspiracy: There is no conspiracy X-Archive-Number: 200303/5 X-Sequence-Number: 55 On Tue, Mar 11, 2003 at 01:16:11AM +0100, Frank Heckenbach wrote: > Some weeks ago, I've installed the user input forms on the GPC web > pages. [...] > Therefore, unless someone has an idea how to "rescue" them, I'm > afraid they'll be gone in a few days ... I'm the same opinion. Eike From gpc-doc-owner@gnu.de Tue Mar 11 21:58:34 2003 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian)) id 18sqpP-0006zm-00 for ; Tue, 11 Mar 2003 21:58:27 +0100 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id VAA26201 for ; Tue, 11 Mar 2003 21:53:52 +0100 Date: Tue, 11 Mar 2003 21:53:52 +0100 Message-Id: <200303112053.VAA26201@goedel.fjf.gnu.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii Subject: Re: Removing the user input forms To: gpc-doc@gnu.de References: <200303110016.BAA09128@goedel.fjf.gnu.de> <1047354762.2187.2.camel@gigaflop.1gig.net> In-Reply-To: <1047354762.2187.2.camel@gigaflop.1gig.net> From: Frank Heckenbach X-Mailer: semail 20030303 X-Archive-Number: 200303/6 X-Sequence-Number: 56 Richard D. Jackson wrote: > On Mon, 2003-03-10 at 18:16, Frank Heckenbach wrote: > > Some weeks ago, I've installed the user input forms on the GPC web > > pages. > > > > Unfortunately, they've not proven too useful yet. The only entries > > of the intended kind came from Richard Jackson who suggested the > > forms initially ... > > > Actualy Grant Jacobs suggested it. Sorry I got that mixed up. > > Therefore, unless someone has an idea how to "rescue" them, I'm > > afraid they'll be gone in a few days ... > > > I don't have a problem with it going away as I find it easer to just > submit a patch to the TexInfo sources. OK, thanks. Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 From gpc-doc-owner@gnu.de Tue Mar 11 23:16:36 2003 Received: from smtp1.clear.net.nz ([203.97.33.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 18ss30-0007UJ-00 for ; Tue, 11 Mar 2003 23:16:35 +0100 Received: from [203.167.180.238] (203-167-180-238.dialup.clear.net.nz [203.167.180.238]) by smtp1.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0HBL00MQ2V4WF0@smtp1.clear.net.nz> for gpc-doc@gnu.de; Wed, 12 Mar 2003 11:14:58 +1300 (NZDT) Date: Wed, 12 Mar 2003 11:16:58 +1300 From: Grant Jacobs Subject: Re: Removing the user input forms In-reply-to: <1047354762.2187.2.camel@gigaflop.1gig.net> X-Sender: biot/grant.jacobs@pop.clear.net.nz To: "Richard D. Jackson" , Frank Heckenbach Cc: GNU Pascal Documentation Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <200303110016.BAA09128@goedel.fjf.gnu.de> <1047354762.2187.2.camel@gigaflop.1gig.net> X-Archive-Number: 200303/7 X-Sequence-Number: 57 At 9:52 PM -0600 10/3/03, Richard D. Jackson wrote: >On Mon, 2003-03-10 at 18:16, Frank Heckenbach wrote: >> Some weeks ago, I've installed the user input forms on the GPC web >> pages. >> >> Unfortunately, they've not proven too useful yet. The only entries >> of the intended kind came from Richard Jackson who suggested the >> forms initially ... >> >Actualy Grant Jacobs suggested it. Almost, but not quite! I suggested a section in the docs; Frank came up with the web forms idea; you'll remember it caught me my surprise. But I did say I thought it a good idea at the time. I'd use it, except that I'm extremely busy until at least the end of April. Just do whatever you feel comfortable with Frank -- its your show! Just a thought: I thought the intention was to get observations from those people who haven't time for the back and forth of the chat group, testing, looking up standards, etc. At least that's what I meant for the doc section. And for those who want to "just write" rather than learn texinfo (which I haven't got time for myself). Cheers, Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs@bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. From gpc-doc-owner@gnu.de Mon Mar 31 16:37:44 2003 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian)) id 1900Pt-0007wN-00; Mon, 31 Mar 2003 16:37:41 +0200 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id NAA03839; Mon, 31 Mar 2003 13:33:44 +0200 Date: Mon, 31 Mar 2003 13:33:44 +0200 Message-Id: <200303311133.NAA03839@goedel.fjf.gnu.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-15 Subject: `True' and `False' To: gpc-doc@gnu.de, peter@stairways.com.au References: <200303210541.GAA28972@goedel.fjf.gnu.de> <200303211829.TAA00887@goedel.fjf.gnu.de> From: Frank Heckenbach X-Mailer: semail 20030303 X-Archive-Number: 200303/8 X-Sequence-Number: 58 When updating the documentation, Peter N Lewis and I came to the problem how to describe the Boolean values `True' and `False'. Peter suggested "true (conforming to reality) and false (different from reality", but I think "reality" is not a good term here (what do computer programs have to do with reality, anyway ;-). Perhaps the only thing that can be said is that there are two values, true and false, and that one is the opposite of the other. But they have some certain meanings as conditions in `if' and loops, and in expressions like `x = 2'. Does anyone have a useful description without being selfreferential and without referring to "reality"? BTW, ISO 10206 contains things like these: : The Boolean­type shall be an ordinal­type. The values : shall be the enumeration of truth values denoted by the required : constant­identifiers false and true, such that false is the predecessor : of true. The ordinal numbers of the truth values denoted by false and : true shall be the integer values 0 and 1 respectively. : The operator in shall yield the value true if : the value of the operand of ordinal­type is a member of the value of the : set­type; otherwise, it shall yield the value false. : If the Boolean­expression of the if­statement yields the value true, the : statement of the if­statement shall be executed. If the Boolean­expression : yields the value false, the statement of the if­statement shall not be : executed, and the statement of the else­part, if any, shall be executed. Frank -- Frank Heckenbach, frank@g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E) From gpc-doc-owner@gnu.de Mon Mar 31 16:47:18 2003 Received: from nemo.gerwinski.de ([194.77.120.82] helo=birdie.g-n-u.de) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 1900ZB-00080O-00; Mon, 31 Mar 2003 16:47:17 +0200 Received: from peter by birdie.g-n-u.de with local (Exim 3.35 #1 (Debian)) id 1900Xw-00086N-00; Mon, 31 Mar 2003 16:46:00 +0200 Date: Mon, 31 Mar 2003 16:46:00 +0200 From: Peter Gerwinski To: Frank Heckenbach Cc: gpc-doc@gnu.de, peter@stairways.com.au Subject: Re: `True' and `False' Message-ID: <20030331144600.GI16189@g-n-u.de> Mail-Followup-To: Peter Gerwinski , Frank Heckenbach , gpc-doc@gnu.de, peter@stairways.com.au References: <200303210541.GAA28972@goedel.fjf.gnu.de> <200303211829.TAA00887@goedel.fjf.gnu.de> <200303311133.NAA03839@goedel.fjf.gnu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303311133.NAA03839@goedel.fjf.gnu.de> User-Agent: Mutt/1.3.28i X-Archive-Number: 200303/9 X-Sequence-Number: 59 Frank Heckenbach wrote: > When updating the documentation, Peter N Lewis and I came to the > problem how to describe the Boolean values `True' and `False'. > > Peter suggested "true (conforming to reality) and false (different > from reality", but I think "reality" is not a good term here (what > do computer programs have to do with reality, anyway ;-). What about this? "True" stands for a condition which is always fullfilled - such as "2 = 2" - and "False" stands for a condition which is never fullfilled - such as "1 = 0". Formally spoken, "condition" ties it "too much" to the usage in "if" statements etc. - but this is what Boolean values are used for in reality. ;-) In order to illustrate that other uses are possible at all, an example with a Boolean variable should follow. Just my 2 CentiEuro, Peter -- WARNING: Do not execute! This software is patented! See: http://swpat.ffii.org/patents/txt/ep/0394/160/ echo -ne PROGRESS\\r;for i in `seq 8`;do sleep 1;echo -n %;done;echo From gpc-doc-owner@gnu.de Tue Apr 1 01:16:08 2003 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian)) id 1908VZ-0002xa-00; Tue, 01 Apr 2003 01:16:05 +0200 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id UAA03059; Mon, 31 Mar 2003 20:14:44 +0200 Date: Mon, 31 Mar 2003 20:14:44 +0200 Message-Id: <200303311814.UAA03059@goedel.fjf.gnu.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii Subject: Re: `True' and `False' To: gpc-doc@gnu.de, peter@stairways.com.au References: <200303211829.TAA00887@goedel.fjf.gnu.de> <200303311133.NAA03839@goedel.fjf.gnu.de> <20030331144600.GI16189@g-n-u.de> In-Reply-To: <20030331144600.GI16189@g-n-u.de> From: Frank Heckenbach X-Mailer: semail 20030303 X-Archive-Number: 200304/1 X-Sequence-Number: 60 Peter Gerwinski wrote: > Frank Heckenbach wrote: > > When updating the documentation, Peter N Lewis and I came to the > > problem how to describe the Boolean values `True' and `False'. > > > > Peter suggested "true (conforming to reality) and false (different > > from reality", but I think "reality" is not a good term here (what > > do computer programs have to do with reality, anyway ;-). > > What about this? > > "True" stands for a condition which is always fullfilled - such as > "2 = 2" - and "False" stands for a condition which is never > fullfilled - such as "1 = 0". There might be a danger of confusion WRT "always": if (i >= 0) = True then Foo Someone might think that `Foo' is only executed only if i is *always* >= 0 (e.g., declared as an unsigned type). It's silly, I know ... > In order to illustrate that other uses are possible at all, an > example with a Boolean variable should follow. Actually, the current example reads: program TrueDemo; var a: Boolean; begin a := 1 = 1; { True } WriteLn (Ord (a)); { 1 } WriteLn (a); { True } end. So perhaps it would be better to add the more common usage in conditionals and loops. ;-) Or, actually, add `True' in the first place. It might be useful for a demo program to contain the thing that is demonstrated at all (not only in comments). ;-) Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 From gpc-doc-owner@gnu.de Tue Apr 1 01:19:45 2003 Received: from smtp2.clear.net.nz ([203.97.37.27]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 1908Z5-0002yy-00 for ; Tue, 01 Apr 2003 01:19:44 +0200 Received: from [203.167.180.170] (203-167-180-170.dialup.clear.net.nz [203.167.180.170]) by smtp2.clear.net.nz (CLEAR Net Mail) with ESMTPA id <0HCM005SJZEAY4@smtp2.clear.net.nz> for gpc-doc@gnu.de; Tue, 01 Apr 2003 11:18:13 +1200 (NZST) Date: Tue, 01 Apr 2003 11:20:48 +1200 From: Grant Jacobs Subject: Re: `True' and `False' In-reply-to: <20030331144600.GI16189@g-n-u.de> X-Sender: biot/grant.jacobs@pop.clear.net.nz To: Peter Gerwinski Cc: gpc-doc@gnu.de Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <200303210541.GAA28972@goedel.fjf.gnu.de> <200303211829.TAA00887@goedel.fjf.gnu.de> <200303311133.NAA03839@goedel.fjf.gnu.de> <20030331144600.GI16189@g-n-u.de> X-Archive-Number: 200304/2 X-Sequence-Number: 61 I'd back this, after all they refer to logical states which are "black and white", either always correct or never correct. No half-way "maybe correct, etc." Replace 'correct' with fulfilled depending on the context. (Just CentiAEuro-pinching: I'm think its spelt fulfilled, one 'l' the first time, two 'l's the second time.) Maybe someone who plays with logical algebra will have a better answer? Grant At 4:46 PM +0200 31/3/03, Peter Gerwinski wrote: >Frank Heckenbach wrote: >> When updating the documentation, Peter N Lewis and I came to the >> problem how to describe the Boolean values `True' and `False'. >> >> Peter suggested "true (conforming to reality) and false (different >> from reality", but I think "reality" is not a good term here (what >> do computer programs have to do with reality, anyway ;-). > >What about this? > > "True" stands for a condition which is always fullfilled - such as > "2 = 2" - and "False" stands for a condition which is never > fullfilled - such as "1 = 0". > >Formally spoken, "condition" ties it "too much" to the usage in "if" >statements etc. - but this is what Boolean values are used for in >reality. ;-) > >In order to illustrate that other uses are possible at all, an >example with a Boolean variable should follow. > >Just my 2 CentiEuro, > > Peter >-- >WARNING: Do not execute! This software is patented! >See: http://swpat.ffii.org/patents/txt/ep/0394/160/ > >echo -ne PROGRESS\\r;for i in `seq 8`;do sleep 1;echo -n %;done;echo -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs@bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. From gpc-doc-owner@gnu.de Fri May 2 17:29:24 2003 Received: from domac.alu.hr ([161.53.235.3] ident=root) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 19BcTS-0008Au-00 for ; Fri, 02 May 2003 17:29:22 +0200 Received: from localhost (mtodorov@localhost [127.0.0.1]) by domac.alu.hr (8.12.6/8.12.6/Debian-8) with ESMTP id h42FSkdR029890 for ; Fri, 2 May 2003 17:28:46 +0200 Date: Fri, 2 May 2003 17:28:46 +0200 (CEST) From: Mirsad Todorovac To: gpc-doc@gnu.de Subject: Test, please ignore Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200305/1 X-Sequence-Number: 62 I've just subscribed. Testing. M. -- "I have a dream!" -- Martin Luther King Jr. "You can't hold someone down ... without staying down with him." -- Booker T. Washington From gpc-doc-owner@gnu.de Fri May 2 17:39:14 2003 Received: from domac.alu.hr ([161.53.235.3] ident=root) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 19Bccz-0008I8-00 for ; Fri, 02 May 2003 17:39:13 +0200 Received: from localhost (mtodorov@localhost [127.0.0.1]) by domac.alu.hr (8.12.6/8.12.6/Debian-8) with ESMTP id h42FcadR030006 for ; Fri, 2 May 2003 17:38:36 +0200 Date: Fri, 2 May 2003 17:38:36 +0200 (CEST) From: Mirsad Todorovac To: gpc-doc@gnu.de Subject: Question Re: GPC website docs 4 online browsing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200305/2 X-Sequence-Number: 63 Hi, Frank, others! I wondered whether we could change what is seen on http://www.gnu-pascal.de/gpc-hr/index.html in that way that Croatian text comes first, or after the "Short Contents" section? This way, it took me time to even think that something is bellow the long "Table of Contents", which includes even "Alphabetical language reference"? Alternativelly, there could be some link leading to main chapter of docs in some more intuitive way ... Thanks, Mirsad -- "I have a dream!" -- Martin Luther King Jr. "You can't hold someone down ... without staying down with him." -- Booker T. Washington From gpc-doc-owner@gnu.de Sun May 4 13:31:17 2003 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian)) id 19CHi6-0002wu-00 for ; Sun, 04 May 2003 13:31:14 +0200 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id EAA08499 for ; Sun, 4 May 2003 04:10:38 +0200 Date: Sun, 4 May 2003 04:10:38 +0200 Message-Id: <200305040210.EAA08499@goedel.fjf.gnu.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii Subject: Re: Question Re: GPC website docs 4 online To: gpc-doc@gnu.de References: In-Reply-To: From: Frank Heckenbach X-Mailer: semail 20030303 X-Archive-Number: 200305/3 X-Sequence-Number: 64 Mirsad Todorovac wrote: > I wondered whether we could change what is seen on > > http://www.gnu-pascal.de/gpc-hr/index.html > > in that way that Croatian text comes first, or after the "Short Contents" > section? This way, it took me time to even think that something is > bellow the long "Table of Contents", which includes even "Alphabetical > language reference"? > > Alternativelly, there could be some link leading to main chapter of docs > in some more intuitive way ... I can link to #Top in the future. If you (or someone) have any other idea, let me know (preferably in form of a patch to the documentation sources) ... Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 From gpc-doc-owner@gnu.de Mon May 5 13:53:46 2003 Received: from domac.alu.hr ([161.53.235.3] ident=root) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 19CeXR-0002J5-00 for ; Mon, 05 May 2003 13:53:45 +0200 Received: from localhost (mtodorov@localhost [127.0.0.1]) by domac.alu.hr (8.12.6/8.12.6/Debian-8) with ESMTP id h45BqTdR019684 for ; Mon, 5 May 2003 13:52:29 +0200 Date: Mon, 5 May 2003 13:52:29 +0200 (CEST) From: Mirsad Todorovac cc: gpc-doc@gnu.de Subject: Re: Question Re: GPC website docs 4 online In-Reply-To: <200305040210.EAA08499@goedel.fjf.gnu.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200305/4 X-Sequence-Number: 65 On Sun, 4 May 2003, Frank Heckenbach wrote: > Mirsad Todorovac wrote: > > > I wondered whether we could change what is seen on > > > > http://www.gnu-pascal.de/gpc-hr/index.html > > > > in that way that Croatian text comes first, or after the "Short Contents" > > section? This way, it took me time to even think that something is > > bellow the long "Table of Contents", which includes even "Alphabetical > > language reference"? > > > > Alternativelly, there could be some link leading to main chapter of docs > > in some more intuitive way ... > > I can link to #Top in the future. > > If you (or someone) have any other idea, let me know (preferably in > form of a patch to the documentation sources) ... > > Frank Thank you, Frank! What I meant to say is that - the way it is - virtually nothing in Croatian is actually seen in first screenful of information, so my first impression was that there must be something wrong, until I scrolled to the bottom. I thought of the researches telling how some or even most people do not scroll at all if nothing understandable is on the first screen ... Also ... since most of the titles belong to the FAQ, "Programming" book and reference, first impression is that 1% to max. 3% of manual is translated - while the actual quantity of translated text is slightly bellow 20%. IMHO this could discourage reader. (The best, perhaps, would be to have expandable/shrinkable +/- items, if you know what I mean, yet if that can't be auto-generated by makeinfo --html, then I rest my case ...) Thanks, Mirsad From gpc-doc-owner@gnu.de Mon May 5 14:06:53 2003 Received: from mond.dida.physik.uni-essen.de ([132.252.79.233]) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 19Cek7-0002PL-00 for ; Mon, 05 May 2003 14:06:51 +0200 Received: (from lange@localhost) by mond.dida.physik.uni-essen.de (8.11.6/8.11.6/SuSE Linux 0.5) id h45C3gI02377 for gpc-doc@gnu.de; Mon, 5 May 2003 14:03:42 +0200 Date: Mon, 5 May 2003 14:03:42 +0200 From: Eike Lange To: gpc-doc@gnu.de Subject: Re: Question Re: GPC website docs 4 online Message-ID: <20030505140342.C1874@mond.dida.physik.uni-essen.de> References: <200305040210.EAA08499@goedel.fjf.gnu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-Eike-Conspiracy: There is no conspiracy X-Archive-Number: 200305/5 X-Sequence-Number: 66 On Mon, May 05, 2003 at 01:52:29PM +0200, Mirsad Todorovac wrote: > (The best, perhaps, would be to have expandable/shrinkable +/- items, if > you know what I mean, yet if that can't be auto-generated by makeinfo > --html, then I rest my case ...) AFAIK, they cannot be generated by makeinfo, because there is no such thing in texi. Eike From gpc-doc-owner@gnu.de Tue May 6 16:45:00 2003 Received: from domac.alu.hr ([161.53.235.3] ident=root) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 19D3gg-0003QK-00 for ; Tue, 06 May 2003 16:44:58 +0200 Received: from localhost (mtodorov@localhost [127.0.0.1]) by domac.alu.hr (8.12.6/8.12.6/Debian-8) with ESMTP id h46EhNdR015955; Tue, 6 May 2003 16:43:23 +0200 Date: Tue, 6 May 2003 16:43:23 +0200 (CEST) From: Mirsad Todorovac To: gpc-doc@gnu.de cc: serrador@arrakis.es Subject: Re: Doc changes GPC In-Reply-To: <200305022223.AAA10596@goedel.fjf.gnu.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200305/6 X-Sequence-Number: 67 On Sat, 3 May 2003, Frank Heckenbach wrote: > > BTW, I thought of making [Example]s follow-able in "Highlights" section. > > Can this be done without much hassle? > > They are in the HTML output (via `examplehref'). I don't think > there's any way to link to external (plain-text, or Pascal) files > from Info, DVI, PS or PDF. > > Frank BTW, Frank, have you seen the HTML-ized listings (done by their LXR) at http://lxr.mozilla.org/ ?? What do you think -- I think generating cross-refs and line numbers is a piece of cake, such as seen at http://lxr.nozilla.org/mozilla1.0/source/jpeg/example.c Also I had dillemas about generating and including texinfo source for all examples mentioned as examples or something else. Especially since source may not always be available, and users are sometimes l@zy ... Even not that. I.e. at home, at my mandrake box, I had gpc docs only, and alas no internet connection -- this sort of situation can happen to people who are not online. (I switched the reply to gpc-doc@gnu.de, so you don't get two messages.) Mirsad -- "I have a dream!" -- Martin Luther King Jr. "You can't hold someone down ... without staying down with him." -- Booker T. Washington From gpc-doc-owner@gnu.de Wed May 7 01:16:32 2003 Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian)) id 19DBfe-0007v1-00 for ; Wed, 07 May 2003 01:16:26 +0200 Received: from goedel.fjf.gnu.de (localhost [127.0.0.1]) by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id BAA29165 for ; Wed, 7 May 2003 01:07:48 +0200 Date: Wed, 7 May 2003 01:07:48 +0200 Message-Id: <200305062307.BAA29165@goedel.fjf.gnu.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii Subject: Re: Doc changes GPC To: gpc-doc@gnu.de References: In-Reply-To: From: Frank Heckenbach X-Mailer: semail 20030303 X-Archive-Number: 200305/7 X-Sequence-Number: 68 Mirsad Todorovac wrote: > On Sat, 3 May 2003, Frank Heckenbach wrote: > > > > BTW, I thought of making [Example]s follow-able in "Highlights" section. > > > Can this be done without much hassle? > > > > They are in the HTML output (via `examplehref'). I don't think > > there's any way to link to external (plain-text, or Pascal) files > > from Info, DVI, PS or PDF. > > > > Frank > > BTW, Frank, have you seen the HTML-ized listings (done by their LXR) at > http://lxr.mozilla.org/ ?? > > What do you think -- I think generating cross-refs and line numbers > is a piece of cake, such as seen at > > http://lxr.nozilla.org/mozilla1.0/source/jpeg/example.c > > Also I had dillemas about generating and including texinfo source for all > examples mentioned as examples or something else. Especially since source > may not always be available, and users are sometimes l@zy ... > > Even not that. I.e. at home, at my mandrake box, I had gpc docs only, and > alas no internet connection -- this sort of situation can happen to people > who are not online. I'm not sure if I understand exactly what you mean. Anyway, the examples mentioned in about.texi are included in source and binary distributions in a demos/ directory, so one should always have them if one has GPC. The "docdemos" are part of the texi source (within `@example') and are extracted when installing GPC (and therefore part of binary distributions), so also "everyone" should have them. If you have the GPC sources (and a number of tools, which should be no problem on GNU/Linux), you can even build a local copy of the home page (`make pascal.html'), with all the examples etc. included. Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 From gpc-doc-owner@gnu.de Wed May 7 10:22:00 2003 Received: from domac.alu.hr ([161.53.235.3] ident=root) by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian)) id 19DKBa-0005jt-00 for ; Wed, 07 May 2003 10:21:58 +0200 Received: from localhost (mtodorov@localhost [127.0.0.1]) by domac.alu.hr (8.12.6/8.12.6/Debian-8) with ESMTP id h478KFdR010838; Wed, 7 May 2003 10:20:15 +0200 Date: Wed, 7 May 2003 10:20:15 +0200 (CEST) From: Mirsad Todorovac To: Frank Heckenbach cc: gpc-doc@gnu.de Subject: Re: Doc changes GPC In-Reply-To: <200305062307.BAA29165@goedel.fjf.gnu.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200305/8 X-Sequence-Number: 69 On Wed, 7 May 2003, Frank Heckenbach wrote: > Mirsad Todorovac wrote: > > > On Sat, 3 May 2003, Frank Heckenbach wrote: > > > > > > BTW, I thought of making [Example]s follow-able in "Highlights" section. > > > > Can this be done without much hassle? > > > > > > They are in the HTML output (via `examplehref'). I don't think > > > there's any way to link to external (plain-text, or Pascal) files > > > from Info, DVI, PS or PDF. > > > > > > Frank > > > > BTW, Frank, have you seen the HTML-ized listings (done by their LXR) at > > http://lxr.mozilla.org/ ?? > > > > What do you think -- I think generating cross-refs and line numbers > > is a piece of cake, such as seen at > > > > http://lxr.nozilla.org/mozilla1.0/source/jpeg/example.c > > > > Also I had dillemas about generating and including texinfo source for all > > examples mentioned as examples or something else. Especially since source > > may not always be available, and users are sometimes l@zy ... > > > > Even not that. I.e. at home, at my mandrake box, I had gpc docs only, and > > alas no internet connection -- this sort of situation can happen to people > > who are not online. > > I'm not sure if I understand exactly what you mean. > > Anyway, the examples mentioned in about.texi are included in source > and binary distributions in a demos/ directory, so one should always > have them if one has GPC. Err, well. On Debian, it didn't come in my default configuration. But it didn't include any info files, just gpc.1 manpage. It takes a root intervention to install gpc-2.95-doc pkg. True, .../docdemos/*.pas are in the same package as gpc-295.info ... Yet, if we had docdemos html-ized, then I could reference particular line or construction within the demo! (As seen at lrx.mozzila.org example.) > The "docdemos" are part of the texi source (within `@example') and > are extracted when installing GPC (and therefore part of binary > distributions), so also "everyone" should have them. With the exception of being on a [Debian or other] server where admin deprecates GPC ... > If you have the GPC sources (and a number of tools, which should be > no problem on GNU/Linux), you can even build a local copy of the > home page (`make pascal.html'), with all the examples etc. included. Err, yes -- then again, if I had something like this _______________________________________________________________ Example 1 

1 /* Copyright FSF 2003
2    Copying by terms of GPL */
3
4 program demo(output);
5
6 uses GPC;
7 uses GMP;
8
.
.
.
_______________________________________________________________

... then I could refer to it as this:

you can include GMP arbitrary precision mathematical in your program like
in this example.

In a longer example, not this simplistic one, it could make a difference
for the reader IMHO.

I'd have to see, however, how they manage to have link
http://lxr.mozilla.org/.../example.c that gives a HTML document type ...

Mirsad

-- 
"I have a dream!" -- Martin Luther King Jr.

"You can't hold someone down ... without staying down with him."
        -- Booker T. Washington


From gpc-doc-owner@gnu.de  Wed May  7 15:45:20 2003
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 19DPEU-0007Lk-00
	for ; Wed, 07 May 2003 15:45:18 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id PAA27393
	for ; Wed, 7 May 2003 15:05:05 +0200
Date: Wed, 7 May 2003 15:05:05 +0200
Message-Id: <200305071305.PAA27393@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: Doc changes GPC
To: gpc-doc@gnu.de
References: 
	
In-Reply-To: 
	
From: Frank Heckenbach 
X-Mailer: semail 20030303
X-Archive-Number: 200305/9
X-Sequence-Number: 70

Mirsad Todorovac wrote:

> Err, well. On Debian, it didn't come in my default configuration. But it
> didn't include any info files, just gpc.1 manpage.
> 
> It takes a root intervention to install gpc-2.95-doc pkg.
> 
> True, .../docdemos/*.pas are in the same package as gpc-295.info ...

Well, that's the decision of the Debian maintainers. I don't really
approve of the decision to put programs and documentation in
separate packages (neither libraries and headers, etc.). It might
save a few computer resources, but it seems to waste much more
valuable human resources with questions and discussions (such as
these ...). But if it's a general Debian policy, I guess we can't
change it ...

> Yet, if we had docdemos html-ized, then I could reference particular line
> or construction within the demo! (As seen at lrx.mozzila.org example.)

If you have an idea how to support it in all the output formats
(HTML is not the only one) ...

> > The "docdemos" are part of the texi source (within `@example') and
> > are extracted when installing GPC (and therefore part of binary
> > distributions), so also "everyone" should have them.
> 
> With the exception of being on a [Debian or other] server where admin
> deprecates GPC ...

You mean he let you install GPC, but not the documentation? Then
just ask him to install the source package (he's required to, by the
GPL), which includes the examples, too. (He could remove them again,
since they're not directly the source of the installed executables,
but this will be extra work for him. ;-)

And, of course, you can always install it in your home if you have a
few 100 MB spare. ;-)

> I'd have to see, however, how they manage to have link
> http://lxr.mozilla.org/.../example.c that gives a HTML document type ...

AFAIK, they do not use Texinfo, so it might not be very relevant
(just to prevent you from wasting your time) ...

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Sat May 24 14:52:15 2003
Received: from domac.alu.hr ([161.53.235.3] ident=root)
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 19JYVR-0005cW-00
	for ; Sat, 24 May 2003 14:52:13 +0200
Received: from localhost (mtodorov@localhost [127.0.0.1])
	by domac.alu.hr (8.12.6/8.12.6/Debian-8) with ESMTP id h4OCpPg5015753
	for ; Sat, 24 May 2003 14:51:25 +0200
Date: Sat, 24 May 2003 14:51:25 +0200 (CEST)
From: Mirsad Todorovac 
To: gpc-doc@gnu.de
Subject: GPC docs writing team
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Archive-Number: 200305/10
X-Sequence-Number: 71


Hi, all!

I wanted to know about the GPC documentation writing group Frank told me
about.

He noted how we must watch not to duplicate the work.

So, I'm using this occassion to contact you on the list, to see whether I
can get an assignment to get all this done.

As for myself, there occured about some clarifications about shl and shr
that could be done, so if nobody has an objection, I think I could take
this for start. Of course, I plan to offer everyting to the list for
review/revision, unless it's too much work for everybody; in which case we
can do what we agree upon.

So, to translate, I'd like to write some clarification about shr and shl
and I think I can already use some things I wrote from earlier
discussions, so tell me what you think about it.

// Please pardon my (I guess) (somewhat and sometimes) broken English,
// since English is my second language.

Thanks,
Mirsad

-- 
"I have a dream!" -- Martin Luther King Jr.
"You can't hold someone down ... without staying down with him."
     -- Booker T. Washington
"... one thing is for sure about the rat race:
     Even if you win, you're still a rat." -- S. Baars


From gpc-doc-owner@gnu.de  Sat May 24 15:36:27 2003
Received: from mailout1.uni-essen.de ([132.252.184.12])
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 19JZCE-0005s5-00
	for ; Sat, 24 May 2003 15:36:26 +0200
Received: from ascend3-64.extern.uni-essen.de ([132.252.241.64] helo=localhost)
	by mailout1.uni-essen.de with esmtp (Exim 4.05-VA-mm1)
	id 19JZBR-0006K0-09
	for gpc-doc@gnu.de; Sat, 24 May 2003 15:35:38 +0200
Received: from eike by localhost with local (Exim 3.35 #1 (Debian))
	id 19JZ07-00004a-00
	for ; Sat, 24 May 2003 15:23:55 +0200
Date: Sat, 24 May 2003 15:23:55 +0200
From: Eike Lange 
To: gpc-doc@gnu.de
Subject: Re: GPC docs writing team
Message-ID: <20030524132355.GA259@natalie.rechner.all>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.3.28i
X-Eike-Conspiracy: There is no conspiracy
X-Archive-Number: 200305/11
X-Sequence-Number: 72

On Sat, May 24, 2003 at 02:51:25PM +0200, Mirsad Todorovac wrote:
> I wanted to know about the GPC documentation writing group Frank told me
> about.
> He noted how we must watch not to duplicate the work.

I don't think so as we are a little group contacting Frank
with all we do. ;-)

Eike

-- 
"Freie Software braucht Freie Dokumentation."
Das GNU-Pascal Buch!         http://www.gnu-pascal.de/~eike/


From gpc-doc-owner@gnu.de  Sat May 24 19:30:38 2003
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 19Jcqr-0007MI-00
	for ; Sat, 24 May 2003 19:30:37 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id TAA03812
	for ; Sat, 24 May 2003 19:29:17 +0200
Date: Sat, 24 May 2003 19:29:17 +0200
Message-Id: <200305241729.TAA03812@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: GPC docs writing team
To: gpc-doc@gnu.de
References: 
	
	<20030524132355.GA259@natalie.rechner.all>
In-Reply-To: 
	<20030524132355.GA259@natalie.rechner.all>
From: Frank Heckenbach 
X-Mailer: semail 20030303
X-Archive-Number: 200305/12
X-Sequence-Number: 73

Eike Lange wrote:

> On Sat, May 24, 2003 at 02:51:25PM +0200, Mirsad Todorovac wrote:
> > I wanted to know about the GPC documentation writing group Frank told me
> > about.
> > He noted how we must watch not to duplicate the work.
> 
> I don't think so as we are a little group contacting Frank
> with all we do. ;-)

To avoid further misunderstandings: Mirsad and I had some
discusssions, and I suggested him to contact this list.

Specifically, he was interested in putting the documentation in the
source and extracting it automatically. This was discussed recently
here (BTW, anyone working on it?), so I suggested to check the
archives and if things are unclear contact this group (about the
format etc.).

I did not mean that any small update must be discussed here in
advance, sorry if I was unclear. (Major changes (restructuring etc.)
should be announced here and perhaps discussed, though.)

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Sun May 25 17:01:30 2003
Received: from domac.alu.hr ([161.53.235.3] ident=root)
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 19Jx04-0005DP-00
	for ; Sun, 25 May 2003 17:01:28 +0200
Received: from localhost (mtodorov@localhost [127.0.0.1])
	by domac.alu.hr (8.12.6/8.12.6/Debian-8) with ESMTP id h4PF0Ng5008653;
	Sun, 25 May 2003 17:00:23 +0200
Date: Sun, 25 May 2003 17:00:23 +0200 (CEST)
From: Mirsad Todorovac 
To: Frank Heckenbach 
cc: gpc-doc@gnu.de
Subject: Re: GPC docs writing team
In-Reply-To: <200305241729.TAA03812@goedel.fjf.gnu.de>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Archive-Number: 200305/13
X-Sequence-Number: 74


Eike Lange wrote:

> > On Sat, May 24, 2003 at 02:51:25PM +0200, Mirsad Todorovac wrote:
> > > I wanted to know about the GPC documentation writing group Frank told me
> > > about.
> > > He noted how we must watch not to duplicate the work.
> >
> > I don't think so as we are a little group contacting Frank
> > with all we do. ;-)

;-)

Frank wrote:

> To avoid further misunderstandings: Mirsad and I had some
> discusssions, and I suggested him to contact this list.
>
> Specifically, he was interested in putting the documentation in the
> source and extracting it automatically. This was discussed recently
> here (BTW, anyone working on it?), so I suggested to check the
> archives and if things are unclear contact this group (about the
> format etc.).

Of course, only according to standards group agreed upon.

> I did not mean that any small update must be discussed here in
> advance, sorry if I was unclear. (Major changes (restructuring etc.)
> should be announced here and perhaps discussed, though.)

I'm sorry to have created confusion. I'll have to check the list archives.
Besides, considering documentation in the source, some questions and
discomforts arise. I have to check where the group has got to, to see what
has been done so far.

Mirsad

-- 
"I have a dream!" -- Martin Luther King Jr.
"You can't hold someone down ... without staying down with him."
     -- Booker T. Washington
"... one thing is for sure about the rat race:
     Even if you win, you're still a rat." -- S. Baars


From gpc-doc-owner@gnu.de  Sat Jun 28 05:51:00 2003
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 19W6jU-0005ty-00; Sat, 28 Jun 2003 05:50:36 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id EAA15049;
	Sat, 28 Jun 2003 04:08:39 +0200
Date: Sat, 28 Jun 2003 04:08:39 +0200
Message-Id: <200306280208.EAA15049@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Installation instructions
To: gpc@gnu.de, gpc-doc@gnu.de
Reply-To: gpc@gnu.de, gpc-doc@gnu.de
From: Frank Heckenbach 
X-Mailer: semail 20030303
X-Archive-Number: 200306/1
X-Sequence-Number: 75

The installation instructions in the manual are somewhat outdated
(and have always been, at least for some years now). There are
probably a number of things which are not quite accurate, missing or
unnecessary (perhaps kludges that were once necessary). Also, the
structure of the chapter is probably not optimal.

Furthermore, there's information (partly overlapping, but also
containing things not mentioned in the manual) that was once in the
FAQ, but was taken out since it should be merged with the install
instructions (because having two parallel, but not quite identical
instructions would only add to the confusion).

This merging hasn't been done, so the old FAQ information has rotted
since then (probably all URLs in it are wrong now etc.), so it must
be carefully updated and then merged with the install chapter.

Obviously, I'm looking for people to do that. (I'm not going to,
since my perspective, especially here, is a bit different from the
average user's ...)

Ideally, perhaps for each "essentially" different platform (i.e.,
DJGPP, Cygwin, Mingw, Mac OS, Unix and perhaps GNU/Linux as a
special case of Unix where some things are easier, so it might be
worth making it a separate section which doesn't confuse the user
with details necessary for other Unices) one user should write one
compact section. It should describe both compiling from sources and
installing binaries. (Of course, this doesn't mean completely
rewriting it -- the existing material can be used and rearranged, of
course.)

There should be some coordination (by one of them or someone else),
so the sections will not look more different from each other than
necessary, and common things need to be described only once. I'd
like to not have to do this myself, but instead get the collected
material from the coordinator in a new install.texi when it's ready.

(I'm sending this mail to both gpc and gpc-doc, since it concerns
the documentation, but also "regular" GPC users, and since the
archives currently don't work, please reply to both lists. Once the
volunteers have found, they can coordinate via gpc-doc only or
private mail, of course ...)

I've put the install chapter from the current sources as well as the
old information from the FAQ at http://fjf.gnu.de/gpc-install.tar.gz

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Sat Jun 28 16:39:18 2003
Received: from postbode02.zonnet.nl ([62.58.50.89])
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 19WGrD-0004Gr-00
	for ; Sat, 28 Jun 2003 16:39:15 +0200
Received: (qmail 6624 invoked by uid 0); 28 Jun 2003 14:38:32 -0000
Received: from ppp8-97-166-62.dialup.zonnet.nl (HELO microbizz.nl) ([62.166.97.8])
          (envelope-sender )
          by postbode02.zonnet.nl (qmail-ldap-1.03) with SMTP
          for < >; 28 Jun 2003 14:38:31 -0000
Date: Sat, 28 Jun 2003 16:40:07 +0200
Subject: Re: Installation instructions
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
From: Adriaan van Os 
To: gpc@gnu.de,
 gpc-doc@gnu.de
Content-Transfer-Encoding: 7bit
In-Reply-To: <200306280208.EAA15049@goedel.fjf.gnu.de>
Message-Id: <69CC50B6-A976-11D7-A42F-000A27944772@microbizz.nl>
X-Mailer: Apple Mail (2.551)
X-Archive-Number: 200306/2
X-Sequence-Number: 76

Frank Heckenbach wrote:

> Ideally, perhaps for each "essentially" different platform (i.e.,
> DJGPP, Cygwin, Mingw, Mac OS, Unix and perhaps GNU/Linux as a
> special case of Unix where some things are easier, so it might be
> worth making it a separate section which doesn't confuse the user
> with details necessary for other Unices) one user should write one
> compact section. It should describe both compiling from sources and
> installing binaries. (Of course, this doesn't mean completely
> rewriting it -- the existing material can be used and rearranged, of
> course.)

The GPC source code distribution for Mac OS X includes a separate file 
with building-instructions for the platform. It can be merged with the 
gpc docs (if somebody volunteers to coordinate it (come on guys)). I 
can send it in on request.

Regards,

Adriaan van Os


From gpc-doc-owner@gnu.de  Sat Jun 28 18:36:35 2003
Received: from mail.storm.ca ([209.87.239.66])
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 19WIC3-0007bm-00; Sat, 28 Jun 2003 18:04:51 +0200
Received: from coraxnetworks.com (gw-corax-networks.storm.ca [209.87.242.99])
	by mail.storm.ca (8.11.7+Sun/8.11.7) with ESMTP id h5SG4ZD23462;
	Sat, 28 Jun 2003 12:04:36 -0400 (EDT)
Date: Sat, 28 Jun 2003 12:04:35 -0400
Subject: Re: Installation instructions
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: gpc@gnu.de, gpc-doc@gnu.de
To: Adriaan van Os 
From: Paul Davidson 
In-Reply-To: <69CC50B6-A976-11D7-A42F-000A27944772@microbizz.nl>
Message-Id: <36798FCE-A982-11D7-AA4E-000393C7EFDA@coraxnetworks.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
X-Archive-Number: 200306/3
X-Sequence-Number: 77

Pick me!!!!!!!

On Saturday, June 28, 2003, at 10:40  AM, Adriaan van Os wrote:

> Frank Heckenbach wrote:
>
>> Ideally, perhaps for each "essentially" different platform (i.e.,
>> DJGPP, Cygwin, Mingw, Mac OS, Unix and perhaps GNU/Linux as a
>> special case of Unix where some things are easier, so it might be
>> worth making it a separate section which doesn't confuse the user
>> with details necessary for other Unices) one user should write one
>> compact section. It should describe both compiling from sources and
>> installing binaries. (Of course, this doesn't mean completely
>> rewriting it -- the existing material can be used and rearranged, of
>> course.)
>
> The GPC source code distribution for Mac OS X includes a separate file 
> with building-instructions for the platform. It can be merged with the 
> gpc docs (if somebody volunteers to coordinate it (come on guys)). I 
> can send it in on request.
>
> Regards,
>
> Adriaan van Os
>
>


From gpc-doc-owner@gnu.de  Sun Jun 29 00:54:10 2003
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 19WOa7-00088F-00
	for ; Sun, 29 Jun 2003 00:54:07 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id AAA03088
	for ; Sun, 29 Jun 2003 00:52:57 +0200
Date: Sun, 29 Jun 2003 00:52:57 +0200
Message-Id: <200306282252.AAA03088@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Test
To: gpc-doc@gnu.de
From: Frank Heckenbach 
X-Mailer: semail 20030303
X-Archive-Number: 200306/4
X-Sequence-Number: 78

Just a test, please ignore. (Trying to get the archives running
again.)

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Sun Jun 29 01:08:43 2003
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 19WOoD-0000LP-00
	for ; Sun, 29 Jun 2003 01:08:41 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id BAA03253
	for ; Sun, 29 Jun 2003 01:07:26 +0200
Date: Sun, 29 Jun 2003 01:07:26 +0200
Message-Id: <200306282307.BAA03253@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Test
To: gpc-doc@gnu.de
From: Frank Heckenbach 
X-Mailer: semail 20030303
X-Archive-Number: 200306/5
X-Sequence-Number: 79

Another test.

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Sun Jun 29 03:49:30 2003
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 19WRJn-00005F-00
	for ; Sun, 29 Jun 2003 03:49:27 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id DAA06078
	for ; Sun, 29 Jun 2003 03:48:33 +0200
Date: Sun, 29 Jun 2003 03:48:33 +0200
Message-Id: <200306290148.DAA06078@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Archives working again
To: gpc-doc@gnu.de
From: Frank Heckenbach 
X-Mailer: semail 20030303
X-Archive-Number: 200306/6
X-Sequence-Number: 80

The archives of this mailing list and the (experimental) search
function on the GPC site should now be working again.

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Mon Jun 30 10:56:44 2003
Received: from amazone.ujf-grenoble.fr ([193.54.238.254])
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 19WuSp-0002pL-00; Mon, 30 Jun 2003 10:56:43 +0200
Received: from spectro.ujf-grenoble.fr (spectro.ujf-grenoble.fr [152.77.253.226])
	by amazone.ujf-grenoble.fr (Switch-2.2.6/Switch-2.2.0/Configured  by JE 06 12 2001) with ESMTP id h5U8tYU15061;
	Mon, 30 Jun 2003 10:55:34 +0200 (MEST)
Received: from ujf-grenoble.fr (knautie.ujf-grenoble.fr [152.77.252.196])
	by spectro.ujf-grenoble.fr (8.9.1a/8.8.5) with ESMTP id KAA16463;
	Mon, 30 Jun 2003 10:53:51 +0200
Message-ID: <3EFFFBE9.9020008@ujf-grenoble.fr>
Date: Mon, 30 Jun 2003 10:59:21 +0200
From: Maurice Lombardi 
User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: fr-fr, it, en
MIME-Version: 1.0
To: gpc@gnu.de, gpc-doc@gnu.de
Subject: Re: Installation instructions
References: <200306280208.EAA15049@goedel.fjf.gnu.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by amazone.ujf-grenoble.fr id h5U8tYU15061
X-Archive-Number: 200306/7
X-Sequence-Number: 81

Frank Heckenbach a =E9crit:
> The installation instructions in the manual are somewhat outdated
> (and have always been, at least for some years now). There are
> probably a number of things which are not quite accurate, missing or
> unnecessary (perhaps kludges that were once necessary). Also, the
> structure of the chapter is probably not optimal.
>=20
> Obviously, I'm looking for people to do that. (I'm not going to,
> since my perspective, especially here, is a bit different from the
> average user's ...)

OK for DJGPP.

Maurice


--=20
        Maurice Lombardi
Laboratoire de  Spectrometrie Physique,
Universite Joseph Fourier de Grenoble, BP87
38402 Saint Martin d'Heres Cedex     FRANCE
Tel: 33 (0)4 76 51 47 51
Fax: 33 (0)4 76 63 54 95
mailto:Maurice.Lombardi@ujf-grenoble.fr


From gpc-doc-owner@gnu.de  Tue Jul  1 14:55:49 2003
Received: from domac.alu.hr ([161.53.235.3] ident=root)
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 19XKfe-0000Ea-00; Tue, 01 Jul 2003 14:55:42 +0200
Received: from localhost (mtodorov@localhost [127.0.0.1])
	by domac.alu.hr (8.12.6/8.12.6/Debian-8) with ESMTP id h61CsmCS017179;
	Tue, 1 Jul 2003 14:54:48 +0200
Date: Tue, 1 Jul 2003 14:54:48 +0200 (CEST)
From: Mirsad Todorovac 
To: gpc@gnu.de, 
Subject: Re: Installation instructions
In-Reply-To: <200306280208.EAA15049@goedel.fjf.gnu.de>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at domac
X-Archive-Number: 200307/1
X-Sequence-Number: 82

On Sat, 28 Jun 2003, Frank Heckenbach wrote:

> The installation instructions in the manual are somewhat outdated
> (and have always been, at least for some years now). There are
> probably a number of things which are not quite accurate, missing or
> unnecessary (perhaps kludges that were once necessary). Also, the
> structure of the chapter is probably not optimal.

Also, if I may add, the installation procedure itself is somewhat not
optimal. It's frequent to change a line of code and want to see how it
works. Then makefile installs all docs, sometimes rebuilds them, docdemos
and various stuff again, while actually only the compiler proper has
changed.

Obviously, a change to Makefiles would be required, to process the build
work in higher resolution (don't look at me). I know Frank is busy with
more important things, but it could be added to TODO list at least ...

OTOH and IMHO, it could pay out in faster development
change-save-compile-test cycle. For compiler developers, I mean. End users
shouldn't notice the difference on average.

My $0.02,

Mirsad

-- 
"I have a dream!" -- Martin Luther King Jr.


From gpc-doc-owner@gnu.de  Fri Jul 11 14:45:52 2003
Received: from domac.alu.hr ([161.53.235.3] ident=root)
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 19axHa-0008D6-00
	for ; Fri, 11 Jul 2003 14:45:51 +0200
Received: from localhost (mtodorov@localhost [127.0.0.1])
	by domac.alu.hr (8.12.6/8.12.6/Debian-8) with ESMTP id h6BCjGtD023012
	for ; Fri, 11 Jul 2003 14:45:16 +0200
Date: Fri, 11 Jul 2003 14:45:16 +0200 (CEST)
From: Mirsad Todorovac 
To: gpc-doc@gnu.de
Subject: Docs modification
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at domac
X-Archive-Number: 200307/2
X-Sequence-Number: 83


Hi, all!

The problems with gcc-2.95.x documentation build require a very small
update to the install.texi:

--- p.dist/doc/en/install.texi	2003-03-22 21:52:50.000000000 +0100
+++ p/doc/en/install.texi	2003-07-11 14:39:51.000000000 +0200
@@ -613,6 +613,16 @@
 compiler and RTS, RTSFLAGS are for RTS only, i.e.:@:
 @samp{make CFLAGS="-O2" RTSFLAGS=-Wall}

+@samp{NOTE} that documentation may fail to build from *.texi sources
+if GCC tries to use @samp{makeinfo} supplied in package with an older
+back-end. In this case you can bail out with:
+
+@example
+% make MAKEINFO=/path/to/makeinfo
+@end example
+
+optionally followed by the rest of arguments.
+
 @item
 Completing the installation



-- 
"I have a dream!" -- Martin Luther King Jr.


From gpc-doc-owner@gnu.de  Sun Jul 13 12:01:31 2003
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 19bdfd-00033i-00
	for ; Sun, 13 Jul 2003 12:01:29 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id LAA08610
	for ; Sun, 13 Jul 2003 11:59:44 +0200
Date: Sun, 13 Jul 2003 11:59:44 +0200
Message-Id: <200307130959.LAA08610@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: Docs modification
To: gpc-doc@gnu.de
References: 
	
In-Reply-To: 
	
From: Frank Heckenbach 
X-Mailer: semail 20030303
X-Archive-Number: 200307/3
X-Sequence-Number: 84

Mirsad Todorovac wrote:

> The problems with gcc-2.95.x documentation build require a very small
> update to the install.texi:
> 
> --- p.dist/doc/en/install.texi	2003-03-22 21:52:50.000000000 +0100
> +++ p/doc/en/install.texi	2003-07-11 14:39:51.000000000 +0200
> @@ -613,6 +613,16 @@
>  compiler and RTS, RTSFLAGS are for RTS only, i.e.:@:
>  @samp{make CFLAGS="-O2" RTSFLAGS=-Wall}
> 
> +@samp{NOTE} that documentation may fail to build from *.texi sources
> +if GCC tries to use @samp{makeinfo} supplied in package with an older
> +back-end. In this case you can bail out with:
> +
> +@example
> +% make MAKEINFO=/path/to/makeinfo
> +@end example
> +
> +optionally followed by the rest of arguments.
> +
>  @item
>  Completing the installation

Please add 2.95 in the note.

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Mon Jul 14 15:42:02 2003
Received: from domac.alu.hr ([161.53.235.3] ident=root)
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 19c3aa-0005hk-00
	for ; Mon, 14 Jul 2003 15:42:00 +0200
Received: from localhost (mtodorov@localhost [127.0.0.1])
	by domac.alu.hr (8.12.6/8.12.6/Debian-8) with ESMTP id h6EDeftD006767;
	Mon, 14 Jul 2003 15:40:41 +0200
Date: Mon, 14 Jul 2003 15:40:41 +0200 (CEST)
From: Mirsad Todorovac 
To: Frank Heckenbach 
cc: gpc-doc@gnu.de
Subject: Re: Docs modification
In-Reply-To: <200307130959.LAA08610@goedel.fjf.gnu.de>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at domac
X-Archive-Number: 200307/4
X-Sequence-Number: 85

On Sun, 13 Jul 2003, Frank Heckenbach wrote:

> Please add 2.95 in the note.

Sure:

diff -u -r p.dist/doc/en/install.texi p/doc/en/install.texi
--- p.dist/doc/en/install.texi  2003-03-22 21:52:50.000000000 +0100
+++ p/doc/en/install.texi       2003-07-14 15:39:32.000000000 +0200
@@ -613,6 +613,16 @@
 compiler and RTS, RTSFLAGS are for RTS only, i.e.:@:
 @samp{make CFLAGS="-O2" RTSFLAGS=-Wall}

+@samp{NOTE} that documentation may fail to build from *.texi sources
+if GCC tries to use @samp{makeinfo} supplied in package with an older
+back-end (seen with @file{gcc-2.95.x}). In such case you can bail out
with:
+
+@example
+% make MAKEINFO=/path/to/makeinfo
+@end example
+
+optionally followed by the rest of arguments.
+
 @item
 Completing the installation


Mirsad


From gpc-doc-owner@gnu.de  Tue Jul 15 02:04:07 2003
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 19cDIX-0007sE-00
	for ; Tue, 15 Jul 2003 02:04:01 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id BAA08298
	for ; Tue, 15 Jul 2003 01:59:54 +0200
Date: Tue, 15 Jul 2003 01:59:54 +0200
Message-Id: <200307142359.BAA08298@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: Docs modification
To: gpc-doc@gnu.de
References: 
	
In-Reply-To: 
	
From: Frank Heckenbach 
X-Mailer: semail 20030303
X-Archive-Number: 200307/5
X-Sequence-Number: 86

Mirsad Todorovac wrote:

> +back-end (seen with @file{gcc-2.95.x}). In such case you can bail out

It *is* gcc-2.95.x (and only gcc-2.95.x, of the versions GPC
supports).

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Tue Jul 15 12:06:25 2003
Received: from domac.alu.hr ([161.53.235.3] ident=root)
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 19cMhU-0002oE-00
	for ; Tue, 15 Jul 2003 12:06:24 +0200
Received: from localhost (mtodorov@localhost [127.0.0.1])
	by domac.alu.hr (8.12.6/8.12.6/Debian-8) with ESMTP id h6FA4stD000570;
	Tue, 15 Jul 2003 12:04:54 +0200
Date: Tue, 15 Jul 2003 12:04:54 +0200 (CEST)
From: Mirsad Todorovac 
To: Frank Heckenbach 
cc: gpc-doc@gnu.de
Subject: Re: Docs modification
In-Reply-To: <200307142359.BAA08298@goedel.fjf.gnu.de>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at domac
X-Archive-Number: 200307/6
X-Sequence-Number: 87

On Tue, 15 Jul 2003, Frank Heckenbach wrote:

> Mirsad Todorovac wrote:
>
> > +back-end (seen with @file{gcc-2.95.x}). In such case you can bail out
>
> It *is* gcc-2.95.x (and only gcc-2.95.x, of the versions GPC
> supports).

I thought someone might want to build with 2.8.x, and I couldn't check if
it behaves in the same way. Hence this formulation.

But I'm not religious about it.

-- 
"I have a dream!" -- Martin Luther King Jr.


From gpc-doc-owner@gnu.de  Tue Jul 15 18:25:37 2003
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 19cScR-0001lf-00
	for ; Tue, 15 Jul 2003 18:25:35 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id RAA20813
	for ; Tue, 15 Jul 2003 17:52:40 +0200
Date: Tue, 15 Jul 2003 17:52:40 +0200
Message-Id: <200307151552.RAA20813@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: Docs modification
To: gpc-doc@gnu.de
References: 
	
In-Reply-To: 
	
From: Frank Heckenbach 
X-Mailer: semail 20030303
X-Archive-Number: 200307/7
X-Sequence-Number: 88

Mirsad Todorovac wrote:

> On Tue, 15 Jul 2003, Frank Heckenbach wrote:
> 
> > Mirsad Todorovac wrote:
> >
> > > +back-end (seen with @file{gcc-2.95.x}). In such case you can bail out
> >
> > It *is* gcc-2.95.x (and only gcc-2.95.x, of the versions GPC
> > supports).
> 
> I thought someone might want to build with 2.8.x, and I couldn't check if
> it behaves in the same way.

It doesn't.

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Tue Jul 15 18:31:37 2003
Received: from domac.alu.hr ([161.53.235.3] ident=root)
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 19cSiF-0002Cv-00
	for ; Tue, 15 Jul 2003 18:31:35 +0200
Received: from localhost (mtodorov@localhost [127.0.0.1])
	by domac.alu.hr (8.12.6/8.12.6/Debian-8) with ESMTP id h6FGU21i003369;
	Tue, 15 Jul 2003 18:30:02 +0200
Date: Tue, 15 Jul 2003 18:30:02 +0200 (CEST)
From: Mirsad Todorovac 
To: Frank Heckenbach 
cc: gpc-doc@gnu.de
Subject: Re: Docs modification
In-Reply-To: <200307151552.RAA20813@goedel.fjf.gnu.de>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at domac
X-Archive-Number: 200307/8
X-Sequence-Number: 89

On Tue, 15 Jul 2003, Frank Heckenbach wrote:

> Mirsad Todorovac wrote:
>
> > On Tue, 15 Jul 2003, Frank Heckenbach wrote:
> >
> > > Mirsad Todorovac wrote:
> > >
> > > > +back-end (seen with @file{gcc-2.95.x}). In such case you can bail out
> > >
> > > It *is* gcc-2.95.x (and only gcc-2.95.x, of the versions GPC
> > > supports).
> >
> > I thought someone might want to build with 2.8.x, and I couldn't check if
> > it behaves in the same way.
>
> It doesn't.

Good, then I'll improve it. Perhaps "bail out" sounds too slang also?

Mirsad

-- 
"I have a dream!" -- Martin Luther King Jr.


From gpc-doc-owner@gnu.de  Tue Jul 15 18:45:33 2003
Received: from domac.alu.hr ([161.53.235.3] ident=root)
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 19cSsl-0002Hg-00
	for ; Tue, 15 Jul 2003 18:42:27 +0200
Received: from localhost (mtodorov@localhost [127.0.0.1])
	by domac.alu.hr (8.12.6/8.12.6/Debian-8) with ESMTP id h6FGer1i003548;
	Tue, 15 Jul 2003 18:40:53 +0200
Date: Tue, 15 Jul 2003 18:40:53 +0200 (CEST)
From: Mirsad Todorovac 
To: Frank Heckenbach 
cc: gpc-doc@gnu.de
Subject: Re: Docs modification
In-Reply-To: <200307151552.RAA20813@goedel.fjf.gnu.de>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at domac
X-Archive-Number: 200307/9
X-Sequence-Number: 90

On Tue, 15 Jul 2003, Frank Heckenbach wrote:

> Mirsad Todorovac wrote:
>
> > On Tue, 15 Jul 2003, Frank Heckenbach wrote:
> >
> > > Mirsad Todorovac wrote:
> > >
> > > > +back-end (seen with @file{gcc-2.95.x}). In such case you can bail out
> > >
> > > It *is* gcc-2.95.x (and only gcc-2.95.x, of the versions GPC
> > > supports).
> >
> > I thought someone might want to build with 2.8.x, and I couldn't check if
> > it behaves in the same way.
>
> It doesn't.

I think this will be alright.

------------------------------------------------------------------
diff -u p.dist/doc/en/install.texi p/doc/en/install.texi
--- p.dist/doc/en/install.texi  2003-03-22 21:52:50.000000000 +0100
+++ p/doc/en/install.texi       2003-07-15 18:39:13.000000000 +0200
@@ -613,6 +613,17 @@
 compiler and RTS, RTSFLAGS are for RTS only, i.e.:@:
 @samp{make CFLAGS="-O2" RTSFLAGS=-Wall}

+@samp{NOTE} that documentation may fail to build from *.texi sources
+if GCC @file{gcc-2.95.x} tries to use an older version of @samp{makeinfo}
+supplied in GCC package itself. This can be prevented by supplying explicit
+instruction to use your system's @samp{makeinfo}:
+
+@example
+% make MAKEINFO=/path/to/makeinfo
+@end example
+
+optionally followed by the rest of arguments.
+
 @item
 Completing the installation


From gpc-doc-owner@gnu.de  Wed Jul 16 12:42:10 2003
Received: from postbode02.zonnet.nl ([62.58.50.89])
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 19cjjd-0008EQ-00
	for ; Wed, 16 Jul 2003 12:42:09 +0200
Received: (qmail 23486 invoked by uid 0); 16 Jul 2003 10:41:34 -0000
Received: from unknown (HELO microbizz.nl) ([62.166.116.152])
          (envelope-sender )
          by postbode02.zonnet.nl (qmail-ldap-1.03) with SMTP
          for < >; 16 Jul 2003 10:41:34 -0000
Date: Wed, 16 Jul 2003 12:43:37 +0200
Mime-Version: 1.0 (Apple Message framework v551)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: --field-widths
From: Adriaan van Os 
To: gpc-doc@gnu.de
Content-Transfer-Encoding: 7bit
Message-Id: <5B67BC5F-B77A-11D7-B1F3-000A27944772@microbizz.nl>
X-Mailer: Apple Mail (2.551)
X-Archive-Number: 200307/10
X-Sequence-Number: 91

The docs for the "--field-widths" option read "Comma-separated list of 
default field widths for Integer, Real, Boolean, LongInt,
LongReal."

I assume "Comma" has to be "Colon".

Regards,

Adriaan van Os


From gpc-doc-owner@gnu.de  Wed Jul 16 16:40:53 2003
Received: from postbode01.zonnet.nl ([62.58.50.88])
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 19cnSd-0004ps-00
	for ; Wed, 16 Jul 2003 16:40:51 +0200
Received: (qmail 13134 invoked by uid 0); 16 Jul 2003 14:40:14 -0000
Received: from unknown (HELO microbizz.nl) ([62.166.102.86])
          (envelope-sender )
          by postbode01.zonnet.nl (qmail-ldap-1.03) with SMTP
          for < >; 16 Jul 2003 14:40:14 -0000
Date: Wed, 16 Jul 2003 16:42:17 +0200
Mime-Version: 1.0 (Apple Message framework v551)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: --progress-bar
From: Adriaan van Os 
To: gpc-doc@gnu.de
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: Apple Mail (2.551)
X-Archive-Number: 200307/11
X-Sequence-Number: 92

 From the gpc docs:

--progress-bar
Output number of processed lines while compiling.
--progress-bar
Do not output number of processed lines while compiling (default).

I assume the second should be "--no-progress-bar".

Regards,

Adriaan van Os


From gpc-doc-owner@gnu.de  Wed Jul 16 17:25:29 2003
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 19co9j-0005Yn-00
	for ; Wed, 16 Jul 2003 17:25:23 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id RAA04294
	for ; Wed, 16 Jul 2003 17:07:59 +0200
Date: Wed, 16 Jul 2003 17:07:59 +0200
Message-Id: <200307161507.RAA04294@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: --field-widths
To: gpc-doc@gnu.de
References: 
	<5B67BC5F-B77A-11D7-B1F3-000A27944772@microbizz.nl>
In-Reply-To: 
	<5B67BC5F-B77A-11D7-B1F3-000A27944772@microbizz.nl>
From: Frank Heckenbach 
X-Mailer: semail 20030303
X-Archive-Number: 200307/12
X-Sequence-Number: 93

Adriaan van Os wrote:

> The docs for the "--field-widths" option read "Comma-separated list of 
> default field widths for Integer, Real, Boolean, LongInt,
> LongReal."
> 
> I assume "Comma" has to be "Colon".

Indeed, thanks. (BTW, the reason is that compiler directives like
`{$field-widths 42:17,stack-checking}' are possible without
conflicts in the comma.)

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Wed Jul 16 20:44:13 2003
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 19crG8-0002GB-00
	for ; Wed, 16 Jul 2003 20:44:12 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id RAA04654
	for ; Wed, 16 Jul 2003 17:26:21 +0200
Date: Wed, 16 Jul 2003 17:26:21 +0200
Message-Id: <200307161526.RAA04654@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: --progress-bar
To: gpc-doc@gnu.de
References: 
	
In-Reply-To: 
	
From: Frank Heckenbach 
X-Mailer: semail 20030303
X-Archive-Number: 200307/13
X-Sequence-Number: 94

Adriaan van Os wrote:

>  From the gpc docs:
> 
> --progress-bar
> Output number of processed lines while compiling.
> --progress-bar
> Do not output number of processed lines while compiling (default).
> 
> I assume the second should be "--no-progress-bar".

Yes. (Not only the documentation, also the implementation was wrong,
will be fixed in the next release.)

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Wed Jul 30 23:04:32 2003
Received: from domac.alu.hr ([161.53.235.3] ident=root)
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 19huID-0002v2-00
	for ; Wed, 30 Jul 2003 18:59:13 +0200
Received: from localhost (mtodorov@localhost [127.0.0.1])
	by domac.alu.hr (8.12.6/8.12.6/Debian-8) with ESMTP id h6UGx2vf013240
	for ; Wed, 30 Jul 2003 18:59:02 +0200
Date: Wed, 30 Jul 2003 18:59:02 +0200 (CEST)
From: Mirsad Todorovac 
To: gpc-doc@gnu.de
Subject: GPC DOC hr translation update
Message-ID: 
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="899744747-2057276171-1059584342=:10392"
X-Virus-Scanned: by amavisd-new at domac
X-Archive-Number: 200307/14
X-Sequence-Number: 95

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--899744747-2057276171-1059584342=:10392
Content-Type: TEXT/PLAIN; charset=US-ASCII


Hi!

Here is the requested change to hr translation: DEBIANLYCORRECT-related
changes have been removed.

The diff is the latest progress against what's released with gpc-20030507
distribution.

Mirsad

-- 
"I have a dream!" -- Martin Luther King Jr.

--899744747-2057276171-1059584342=:10392
Content-Type: TEXT/plain; name="gpc-doc-hr-20030730-20030507dist.diff"
Content-Transfer-Encoding: BASE64
Content-ID: 
Content-Description: Latest diff
Content-Disposition: attachment; filename="gpc-doc-hr-20030730-20030507dist.diff"

ZGlmZiAtciAtdSAtdyBoci0yMDAzMDUwNy5kaXN0L1BST0NJVEFKX01FIGhy
LTIwMDMwNzMwL1BST0NJVEFKX01FDQotLS0gaHItMjAwMzA1MDcuZGlzdC9Q
Uk9DSVRBSl9NRQkyMDAyLTA5LTIzIDA5OjM5OjEyLjAwMDAwMDAwMCArMDIw
MA0KKysrIGhyLTIwMDMwNzMwL1BST0NJVEFKX01FCTIwMDMtMDctMDcgMTM6
MzM6MDUuMDAwMDAwMDAwICswMjAwDQpAQCAtMiw2ICsyLDggQEANCiBQcm92
amVyaSBkYSBsaSBzdSAnbmFzYScgc2xvdmEgdXpyb2sgZGEgc2UgYG1ha2Vp
bmZvJyBibGVzaXJhIG5hIGF1dGhvcnMudGV4aQ0KIC0gcHJvdmplcmlvIGkg
bmEgZW5nbGVza2ltIG9yaWdpbmFsaW1hIGlzcGFkYSBkb2JybyAhPz8hPw0K
IA0KKyhVc3Rhbm92bGplbm8ga2FvIGJ1ZyB1IG1ha2VpbmZvLXByb2dyYW11
LCBpc3ByYXZsamVubyB1IFRleGluZm8tNC4xKD8pKQ0KKw0KICgyMDAyLzAx
LzAyKQ0KIA0KIE5lLCByYXpsb2cgamUgYmlvIHUgdG9tZSBzdG8gc2FtIHBv
a3VwaW8gJ15NJyA8Q1I+PExGPiBzZWt2ZW5jdSBrb2QNCmRpZmYgLXIgLXUg
LXcgaHItMjAwMzA1MDcuZGlzdC9hYm91dC50ZXhpIGhyLTIwMDMwNzMwL2Fi
b3V0LnRleGkNCi0tLSBoci0yMDAzMDUwNy5kaXN0L2Fib3V0LnRleGkJMjAw
My0wNC0zMCAxOToxOTozOC4wMDAwMDAwMDAgKzAyMDANCisrKyBoci0yMDAz
MDczMC9hYm91dC50ZXhpCTIwMDMtMDctMDggMTI6Mzk6MDcuMDAwMDAwMDAw
ICswMjAwDQpAQCAtNSw3ICs1LDcgQEANCiBAYyBBdXRob3JzOiBQZXRlciBH
ZXJ3aW5za2kgPHBldGVyQGdlcndpbnNraS5kZT4NCiBAYyAgICAgICAgICBG
cmFuayBIZWNrZW5iYWNoIDxmcmFua0BwYXNjYWwuZ251LmRlPg0KIEBjDQot
QGMgTGFzdCBtb2RpZmljYXRpb246IDIwMDMtMDQtMjggKGZpbGUgdXAgdG8g
ZGF0ZSkNCitAYyBMYXN0IG1vZGlmaWNhdGlvbjogMjAwMy0wNS0yNSAoZmls
ZSB1cCB0byBkYXRlKQ0KIEBjDQogQGMgQ3JvYXRpYW4gdHJhbnNsYXRpb24N
CiBAYyBDaGFyc2V0OiAgICBpc28tODg1OS0yIChsYXRpbiAyKQ0KQEAgLTIy
LDEzICsyMiwxMyBAQA0KIEBjaW5kZXggaGlnaGxpZ2h0cw0KIA0KIEdOVSBQ
YXNjYWwgcHJldm9kaWxhYyAoR1BDKSBqZSwga2FvILl0byBpbWUgZ292b3Jp
LCBQYXNjYWwgcHJldm9kaWxhYyAoZW5nbC4NCi1jb21waWxlcikgaXogR05V
IG9iaXRlbGppIChAcHhyZWZ7R05VfSkuIE92byB6bmHoaToNCitjb21waWxl
cikgaXogR05VIG9iaXRlbGppIChAdXJlZntodHRwOi8vd3d3LmdudS5vcmcv
c29mdHdhcmUvZ2NjL30pLiBPdm8gem5h6Gk6DQogDQogQGl0ZW1pemUgQGJ1
bGxldA0KIA0KIEBpdGVtIEdQQyBqZSAzMi82NC1iaXRuaSBwcmV2b2RpbGFj
LA0KIA0KLUBpdGVtIG5lbWEgb2dyYW5p6GVuamEga2FvILl0byBqZSA2NCBr
QiBpbGkgNjQwIGtiIGxpbWl0IHBvem5hdCBpeiBuZWtpaA0KK0BpdGVtIG5l
bWEgb2dyYW5p6GVuamEga2FvILl0byBqZSA2NCBrQiBpbGkgNjQwIGtCIGxp
bWl0IHBvem5hdCBpeiBuZWtpaA0KIG9wZXJhY2lqc2tpaCBzdXN0YXZhIC0t
IOhhayBpIG5hIHRpbSBzdXN0YXZpbWEgLS0sDQogDQogQGl0ZW0gcmFkaSBu
YSBzdmltIG9wZXJhY2lqc2tpbSBzdXN0YXZpbWEgcG9kcr5hbmltIG9kIEdO
VSBDIHByZXZvZGlvY2EsDQpAQCAtNTUsMTMgKzU1LDE5IEBADQogQGl0ZW0g
TUlQUy1TR0ktSVJJWCwNCiBAaXRlbSBBbHBoYS1ERUMtT1NGLA0KIEBpdGVt
IFNwYXJjLVN1bi1Tb2xhcmlzLA0KLUBpdGVtIEhQL1VYDQorQGl0ZW0gSFAv
VVgsDQogQGVuZCBpdGVtaXplDQotQG5vaW5kZW50IGkgZHJ1Z2UsDQogDQor
QG5vaW5kZW50IGkgZHJ1Z2UgKHphYmlsamW5a2E6IHJ1bnRpbWUgc2lzdGVt
IHBvZHK+YXZhIHNhbW8gQVNDSUkgYmF6aXJhbmUNCitzaXN0ZW1lOyB0byB1
a2xqdeh1amUgZ290b3ZvIHN2ZSBkYW5huW5qZSBzdXN0YXZlLCBtZfB1dGlt
IG5la29saWtvIElCTQ0KK3N0cm9qZXZhIGpvuSB1dmlqZWsga29yaXN0aSBF
QkNESUM7IG5hIHRpbWEsIHByZXZvZGlsYWMgYmkgc2UgbW9nYW8gaXp2crlh
dmF0aSwNCithbGkgYmkgcnVudGltZSBwb2RyuWthIHRyZWJhbGEgdmVsaWtl
IGl6bWplbmUpLA0KKw0KK0BjIEZJWE1FIC0tIFRNDQogQGMgbkVFZCB0byBm
aW5kIG1vcmUgc3VpdGFibGUgdHJhbnNsYXRpb24gZm9yICduYXRpdmUnIGFu
ZCAnY3Jvc3MnIGNvbXBpbGVyDQotQGl0ZW0gbW++ZSBzbHW+aXRpIGthbyBu
YXRpdm5pIHByZXZvZGlsYWMgaWxpIHByZXZvZGlsYWMgaXptZfB1IHNpc3Rl
bWENCi0oZW5nbC4gY3Jvc3MtY29tcGlsZXIpIC0gaXptZfB1IHN2aWggcG9k
cr5hbmloIHNpc3RlbWEsDQorQGl0ZW0gbW++ZSBzbHW+aXRpIGthbyBuYXRp
dm5pIHByZXZvZGlsYWMgKGVuZ2wuIEBzYW1we25hdGl2ZSBjb21waWxlcn0p
IGlsaQ0KK3ByZXZvZGlsYWMgaXptZfB1IHNpc3RlbWEgKGVuZ2wuIEBzYW1w
e2Nyb3NzLWNvbXBpbGVyfSkgLSBpem1l8HUgc3ZpaCBwb2RyvmFuaWgNCitz
aXN0ZW1hLA0KIA0KIEBpdGVtIHByb2l6dm9kaSB2aXNva28gb3B0aW1pcmFu
aSBrb2QgemEgc3ZlIHRlIHNpc3RlbWUsDQogDQpAQCAtNzAsNyArNzYsNyBA
QA0KIChAdXJlZntodHRwOi8vd3d3Lm9wZW5zb3VyY2Uub3JnLE9wZW4tU291
cmNlIFNvZnR3YXJlfSkNCiB1IHNrbGFkdSBzYQ0KIEB1cmVme2h0dHA6Ly93
d3cuZ251Lm9yZy9jb3B5bGVmdC9ncGwuaHRtbCxAc3Ryb25ne0dOVSBHZW5l
cmFsIFB1YmxpYyBMaWNlbnNlfX0NCi1saWNlbmNvbSAoQHB4cmVme0dOVX0s
IHphIHByaW1qZWRiZSBpIHByaWpldm9kZSksDQorbGljZW5jb20pLA0KIA0K
IEBpdGVtIGtvbXBhdGliaWxhbiBqZSBzYSBvc3RhbGltIEdOVSBqZXppY2lt
YSBpIGFsYXRpbWEga2FvILl0byBzdSBHTlUgQyBpDQogR05VIGRlYnVnZ2Vy
IChpbGksIGFrbyB2abllIHZvbGl0ZSwgcHJvZ3JhbSB6YSBzaW1ib2xp6Gtv
IGlzcHJhdmxqYW5qZQ0KQEAgLTg1LDcgKzkxLDcgQEANCiBAaXRlbSBJU08g
NzE4NSBQYXNjYWwgKEBweHJlZntSZXN1cnNpfSksDQogQGl0ZW0gdmXmaW51
IGRpamVsb3ZhIElTTyAxMDIwNiBFeHRlbmRlZCBQYXNjYWxhLA0KIEBpdGVt
IEJvcmxhbmQgUGFzY2FsIDcuMCwNCi1AaXRlbSBkaWplbG92ZSBCb3JsYW5k
IERlbHBoaSBpIFBhc2NhbC1TQyAoUFhTQykuDQorQGl0ZW0gZGlqZWxvdmUg
Qm9ybGFuZCBEZWxwaGksIE1hYyBQYXNjYWxhIGkgUGFzY2FsLVNDIChQWFND
KS4NCiBAZW5kIGl0ZW1pemUNCiANCiBAYW5jaHtwcm99QGMNCkBAIC0xMTIs
OCArMTE4LDYgQEANCiBAaXRlbQ0KIEBhbmNoe2ZpbGVidWYxZGVtb31AYw0K
IEBhbmNoe2ZpbGVidWYyZGVtb31AYw0KLUBjIEhlcmUgSSdtIG5vdCByZXNv
bHV0ZSBhYm91dCBtZWFuaW5nIG9mIHRoZSBvcmlnaW5hbCAtPiBJIG5FRWQg
dG8NCi1AYyAgIGxvb2sgYXQgdGhlIGV4YW1wbGVzLCBvciBhc2sgRnJhbms6
IC0tIE1UIDIwMDExMjAxIERvbmUgMjAwMjAxMDMNCiBBdXRvbWF0c2tpIGRh
dG90ZehuaSBtZfB1c3ByZW1uaWNpIChlbmdsLiBmaWxlIGJ1ZmZlcnMpIGkg
c3RhbmRhcmRuZSBAc2FtcHtHZXR9DQogaSBAc2FtcHtQdXR9IHByb2NlZHVy
ZS4gUHJlZHZp8GFqdeZlIOhpdGFuamUgKGVuZ2wuIHJlYWQtYWhlYWQpIGJl
eiBwcml2cmVtZW5paA0KIHZhcmlqYWJsaS4gQGV4YW1wbGVocmVme2ZpbGVi
dWYxZGVtby5wYXN9IE92byBkb3p2b2xqYXZhLCBuYSBwcmltamVyLCBkYSBz
ZQ0KQEAgLTE3Niw4ICsxODAsOCBAQA0KIEluaWNpamFsaXppcmFuZSB2YXJp
amFibGUuIEBleGFtcGxlaHJlZntpbml0dmFyZGVtby5wYXN9DQogQGl0ZW0g
RnVua2NpamUgbW9ndSB2cmHmYXRpIHZyaWplZG5vc3QgdGlwYSB6YXBpcyBp
bGkgcG9samUgKFJlY29yZCwgQXJyYXkpLg0KIEBpdGVtDQotQGFuY2h7cmVz
dWx0dmFyZGVtb31AYyBuRUVkIDIgbG9vayBhdCBleG1wbCB0byBjbGVhbiB4
bGF0aW9uIC0tIFRNIDIwMDExMjAxIERvbmUgMjAwMjAxMDMNCi1WYXJpamFi
bGUgemEgaW1lbm92YW51IHBvdnJhdG51IHZyaWplZG5vc3QgdSBmdW5rY2lq
YW1hLg0KK0BhbmNoe3Jlc3VsdHZhcmRlbW99QGMNCitWYXJpamFibGUgemEg
aW1lbm92YW51IHBvdnJhdG51IHZyaWplZG5vc3QgdSBmdW5rY2lqYW1hIChl
bmdsLiBAc2FtcHtyZXN1bHQgdmFyaWFibGVzfSkNCiBAZXhhbXBsZWhyZWZ7
cmVzdWx0dmFyZGVtby5wYXN9DQogQGl0ZW0gTW9kdWxpLg0KIEBpdGVtIE5l
LWRla2Fkc2tpIGJyb2pldmkgdSBiYXphbWEgb2QgMiBkbyAzNjogQHNhbXB7
YmF6YSNicm9qfS4NCmRpZmYgLXIgLXUgLXcgaHItMjAwMzA1MDcuZGlzdC9h
dXRob3JzLnRleGkgaHItMjAwMzA3MzAvYXV0aG9ycy50ZXhpDQotLS0gaHIt
MjAwMzA1MDcuZGlzdC9hdXRob3JzLnRleGkJMjAwMy0wNS0wMSAxMzoxNjoy
Mi4wMDAwMDAwMDAgKzAyMDANCisrKyBoci0yMDAzMDczMC9hdXRob3JzLnRl
eGkJMjAwMy0wNy0wOCAxMzoyNDowNS4wMDAwMDAwMDAgKzAyMDANCkBAIC01
LDcgKzUsNyBAQA0KIEBjIEF1dGhvcnM6IFBldGVyIEdlcndpbnNraSA8cGV0
ZXJAZ2Vyd2luc2tpLmRlPg0KIEBjICAgICAgICAgIEZyYW5rIEhlY2tlbmJh
Y2ggPGZyYW5rQHBhc2NhbC5nbnUuZGU+DQogQGMNCi1AYyBMYXN0IG1vZGlm
aWNhdGlvbjogMjAwMy0wNC0yOCAoZmlsZSB1cCB0byBkYXRlKQ0KK0BjIExh
c3QgbW9kaWZpY2F0aW9uOiAyMDAzLTA2LTIxIChmaWxlIHVwIHRvIGRhdGUp
DQogQGMNCiBAYyBUcmFuc2xhdGlvbiB0byBDcm9hdGlhbiAoSFJfaHIpDQog
QGMgQ2hhcnNldDoJaXNvLTg4NTktMg0KQEAgLTE1LDEwICsxNSwxMSBAQA0K
IEBpbmNsdWRlIG1hY3Jvcy50ZXhpDQogDQogQGlmY2xlYXIgQVVUSE9SU09O
TFkNCi1AYyBOb3RlOiBUaGUgdGl0bGUgYEFja25vd2xlZGdtZW50cycgaGFz
IGEgc3BlY2lhbCBtZWFuaW5nIGJ5IHRoZSBGREwuDQorQGMgTk9URTogQWNr
bm93bGVkZ21lbnRzIChQcml6bmFuamEpIGhhcyBzcGVjaWFsIG1lYW5pbmcg
YnkgRkRMLg0KIEBub2RlIFByaXpuYW5qYQ0KIEBhcHBlbmRpeCBBdXRvcmkg
aSBzdXJhZG5pY2kgbmEgR05VIFBhc2NhbCBwcm9qZWt0dS4NCiBAY2luZGV4
IHByaXpuYW5qYQ0KK0BjaW5kZXggYWNrbm93bGVkZ21lbnRzDQogQGNpbmRl
eCBzdXJhZG5pY2kNCiBAY2luZGV4IGF1dG9yaQ0KIEBjaW5kZXggcmF6dm9q
bmkgdGltDQpAQCAtNDksNyArNTAsNyBAQA0KIEBpdGVtIEB1cmVme2h0dHA6
Ly93d3cuZ2Vyd2luc2tpLmRlL35wZXRlci8sRHIuQDogUGV0ZXIgR2Vyd2lu
c2tpfQ0KIEBhbmNoe3BldGVyfUBjDQogQGMgNDU2Nzg5MTEyMzQ1Njc4OTIx
MjM0NTY3ODkzMTIzNDU2Nzg5NDEyMzQ1Njc4OTUxMjM0NTY3ODk2MTIzNDU2
Nzg5Nw0KLWRvZGFvIGplIEJvcmxhbmQtUGFzY2FsIGtvcmVsaXJhbmUgaSBk
cnVnZSBla3N0ZW56aWplIEdOVSBQYXNjYWx1IHUNCitkb2RhbyBqZSBCb3Js
YW5kIFBhc2NhbCBrb3JlbGlyYW5lIGkgZHJ1Z2UgZWtzdGVuemlqZSBHTlUg
UGFzY2FsdSB1DQogbGpldG8gMTk5NSwgcHJlbmlvIEdQQyBuYSBFTVggcGxh
dGZvcm11LCByYWRpIG5hIG5hanZl5mVtIGRpamVsdQ0KIHJhenZvamEgcHJl
dm9kaXRlbGphIChlbmdsLiBjb21waWxlcikgb2QgMTk5Ni1lLCBuYXBpc2Fv
IGkNCiBvZHK+YXZhIFdXVyBob21lIHBhZ2UsIG9kcr5hdmEgR05VIFBhc2Nh
bCBtYWlsaW5nIGxpc3R1LCByYWRpDQpAQCAtNTgsNyArNTksNyBAQA0KIEBp
ZnNldCBBVVRIT1JTT05MWQ0KIE5hcGlzYW8gamUgQGZpbGV7cnRzL21vdmUu
cGFzfSwgZGF0b3Rla2UgdSBAZmlsZXtkb2MvfSAoemFqZWRubw0KIHNhIEph
bi1KYWFwb20pLCAoYml2uWUpIGRhdG90ZWtlIHUgQGZpbGV7Y29uZmlnL2Vt
eC99IGkNCi1AZmlsZXtncGMtbm9kZXMuZGVmfSwgaSB6bmHoYWpubyBtb2Rp
ZmlyYW8gc3ZlIGRhdG90ZWtlLg0KK0BmaWxle2dwYy1ub2Rlcy5kZWZ9LCBp
IHpuYehham5vIG1vZGlmaWNpcmFvIHN2ZSBkYXRvdGVrZS4NCiBAZW5kIGlm
c2V0DQogDQogQGl0ZW0gSmFuLUphYXAgdmFuIGRlciBIZWlqZGVuDQpAQCAt
ODYsNyArODcsNyBAQA0KIGl0ZC4NCiANCiBAaWZzZXQgQVVUSE9SU09OTFkN
Ci1LcmVpcmFvIGplIEBzYW1we2dwaS5ofSwgdmXmaW51IGRhdG90ZWthIHUg
QGZpbGV7dW5pdHMvfSwgQGZpbGV7ZGVtb3MvfSwNCitLcmVpcmFvIGplIEBz
YW1we2dwYy1vcHRpb25zLmh9LCB2ZeZpbnUgZGF0b3Rla2EgdSBAZmlsZXt1
bml0cy99LCBAZmlsZXtkZW1vcy99LCANCiBAZmlsZXtzY3JpcHQvfSwgaSBA
c2FtcHt1dGlscy99IGkgQGZpbGV7cnRzL30gaSBtbm9nbyBkYXRvdGVrYSB1
DQogQGZpbGV7dGVzdC99OyBtb2RpZmljaXJhbyBqZSB2ZeZpbnUgb3N0YWxp
aCBkYXRvdGVrYS4NCiBAZW5kIGlmc2V0DQpAQCAtMTA4LDggKzEwOSw4IEBA
DQogaXNwcmF2aW8gbmVrZSBidWdvdmUgaSBwb+hpc3RpbyBHUEMgdSBzdmli
bmp1IDE5OTgsIGl0ZC4NCiANCiBAaWZzZXQgQVVUSE9SU09OTFkNCi1Nb2Rp
ZmljaXJhbyBqZSBAZmlsZXtleHByZXNzaW9ucy5jfSwgQGZpbGV7cGFyc2Uu
eX0sIEBmaWxle21vZHVsZS5jfQ0KLWkgbmVrZSBkcnVnZSBkYXRvdGVrZS4N
CitNb2RpZmljaXJhbyBqZSBAZmlsZXtleHByZXNzaW9ucy5jfSwgQGZpbGV7
cGFyc2UueX0sIEBmaWxle21vZHVsZS5jfSBpDQorbmVrZSBkcnVnZSBkYXRv
dGVrZS4NCiBAZW5kIGlmc2V0DQogDQogQGl0ZW0gTWF0dGhpYXMgS2xvc2UN
CkBAIC0xNTksMTIgKzE2MCwyMiBAQA0KIA0KIEBpdGVtIEVpa2UgTGFuZ2UN
CiBAYW5jaHtFaWtlfUBjDQotcHJldmVvIGplIHRla3N0IEdOVSBQYXNjYWwg
Q29kaW5nIFN0YW5kYXJkcyBuYSBuamVtYehraS4NCitqZSBuYXBpc2FvIGpl
ZGluaWN1IEBzYW1we3VuaXR9IHphIGludGVybmFjaW9uYWxpemFjaWp1LCBw
cmV2ZW8gamUgdGVrc3QgR05VDQorUGFzY2FsIENvZGluZyBTdGFuZGFyZHMg
bmEgbmplbWHoa2kgaSByYWRpbyBuYSBkb2t1bWVudGFjaWppLg0KIA0KIEBp
ZnNldCBBVVRIT1JTT05MWQ0KIEtyZWlyYW8gamUgQGZpbGV7ZG9jL2RlL2dw
Y3MudGV4aX0uDQogQGVuZCBpZnNldA0KIA0KK0BpdGVtIEZyYW5jaXNjbyBK
YXZpZXIgRmVybmFuZGV6IFNlcnJhZG9yDQorQGFuY2h7RnJhbmNpc2NvfUBj
DQorcHJldmVvIGplIEdQQyBkb2t1bWVudGFjaWp1IG5hILlwYW5qb2xza2ku
DQorDQorQGlmc2V0IEFVVEhPUlNPTkxZDQorS3JlaXJhbyBqZSBzdmUgZGF0
b3Rla2UgdSBAZmlsZXtkb2MvZXMvfSAoa29qZSBqb7kgbmlzdSBpbnRlZ3Jp
cmFuZSB1IEdQQw0KK25hIGRhbiBwaXNhbmphIDIxLjA2LjIwMDMuKQ0KK0Bl
bmQgaWZzZXQNCisNCiBAZW5kIHRhYmxlDQogDQogQGlmc2V0IEFVVEhPUlNP
TkxZDQpAQCAtMjQ0LDkgKzI1NSwxMCBAQA0KIGtyZWlyYW8gamUgc3VzdGF2
IHphIHByaWphdnUgYnVnb3ZhIHphIEdQQyB1IGxpc3RvcGFkdSAxOTk2Lg0K
IA0KIEBpdGVtIEB1cmVme1JvYmVydCBI9mhuZX0NCi1uYXBpc2FvIGplIEB1
cmVme2h0dHA6Ly93d3cucmhpZGUuY29tLFJISURFfSwgaW50ZWdyaXJhbnUg
cmF6dm9qbnUNCi1va29saW51IHphIEdOVSBwcmV2b2RpdGVsamUga29qYSBz
ZSB2cnRpIHBvZCBET1Mtb20gKERKR1BQKSBpDQotTGludXhvbSwgdGUgZG9k
YW8gcG9kcrlrdSB6YSBHTlUgUGFzY2FsIHUgamVzZW4gMTk5Ni4NCituYXBp
c2FvIGplIEB1cmVme2h0dHA6Ly93d3cucmhpZGUuY29tLFJISURFfSwNCitp
bnRlZ3JpcmFudSByYXp2b2pudSBva29saW51IHphIEdOVSBwcmV2b2RpdGVs
amUga29qYSBzZSB2cnRpIHBvZA0KK0RPUy1vbSAoREpHUFApIGkgTGludXhv
bSwgdGUgZG9kYW8gcG9kcrlrdSB6YSBHTlUgUGFzY2FsIHUgamVzZW4NCisx
OTk2Lg0KIA0KIEBpdGVtIFN2ZW4gSGlsc2NoZXINCiBuYXBpc2FvIChwcmV0
Zb5ubykgQlAga29tcGF0aWJpbG51IEBzYW1we0dyYXBofSBqZWRpbmljdSB6
YSBuZWtvbGlrbw0KZGlmZiAtciAtdSAtdyBoci0yMDAzMDUwNy5kaXN0L2Zh
cS50ZXhpIGhyLTIwMDMwNzMwL2ZhcS50ZXhpDQotLS0gaHItMjAwMzA1MDcu
ZGlzdC9mYXEudGV4aQkyMDAzLTA1LTA3IDAwOjM5OjIwLjAwMDAwMDAwMCAr
MDIwMA0KKysrIGhyLTIwMDMwNzMwL2ZhcS50ZXhpCTIwMDMtMDctMDcgMTM6
MTk6MDYuMDAwMDAwMDAwICswMjAwDQpAQCAtMTUsNyArMTUsNyBAQA0KIA0K
IEBpZmNsZWFyIEZBUU9OTFkNCiBAbm9kZSBGQVENCi1AY2hhcHRlciDIZXN0
byBwb3N0YXZsamFuYSBwaXRhbmphIChGQVEpIG8gR05VIHBhc2NhbHUuDQor
QGNoYXB0ZXIgyGVzdG8gcG9zdGF2bGphbmEgcGl0YW5qYSAoRkFRKSBvIEdO
VSBQYXNjYWx1Lg0KIEBzdWJoZWFkaW5nIEl6ZGFuamUgMC45LCBrb2xvdm96
IDIwMDANCiBAY2luZGV4IEZBUQ0KIEBjaW5kZXggRnJlcXVlbnRseSBBc2tl
ZCBRdWVzdGlvbnMNCkBAIC0yNyw4ICsyNyw4IEBADQogQGluY2x1ZGUgdmVy
c2lvbi50ZXhpDQogQGMgTm90ZTogVGhlIGZvbGxvd2luZyBsaW5lIGdldHMg
aW5zZXJ0ZWQgaW50byB0aGUgZGVzdGluYXRpb24gZmlsZSwNCiBAYyAgICAg
ICBpdCBkb2VzIG5vdCBhcHBseSB0byB0aGlzIFRleGluZm8gZmlsZSENCi1U
aGlzIGZpbGUgd2FzIGdlbmVyYXRlZCBhdXRvbWF0aWNhbGx5IGZyb20gZmFx
LnRleGkuQCoNCi1Ac2N7RE8gTk9UIENIQU5HRSBUSElTIEZJTEUgTUFOVUFM
TFkhfQ0KK092YSBqZSBkYXRvdGVrYSBnZW5lcmlyYW5hIGF1dG9tYXRza2kg
aXogZmFxLnRleGkuQCoNCitAc2N7TkUgTUlKRU5KQUpURSBPVlUgREFUT1RF
S1UgUlXITk8hfQ0KIA0KIEBzZXR0aXRsZSBHUEMgbGlzdGEg6GVzdG8gcG9z
dGF2bGphbmloIHBpdGFuamENCiBAbm9kZSBUb3ANCkBAIC0zNywxNyArMzcs
MTcgQEANCiANCiBPdmFqIGRva3VtZW50IGplIGRpbyBHUEMgZG9rdW1lbnRh
Y2lqZS4gUHJpamUgaXpyYWRlLCBrb3BpcmFuamEgaQ0KIGRpc3RyaWJ1aXJh
bmphIG1vZGlmaWNpcmFuaWggdmVyemlqYSBvdm9nIGRva3VtZW50YSBtb2xp
bW8gcG9nbGVkYWp0ZSBHUEMNCi1kb3VtZW50YWNpanUuDQorZG9rdW1lbnRh
Y2lqdS4NCiBAZW5kIGlmc2V0DQogDQogT3ZvIGplIGxpc3RhIOhlc3RvIHBv
c3RhdmxqYW5paCBwaXRhbmplIChGQVEpIHphIEdOVSBwYXNjYWwuIEFrbw0K
IHZhbSBuaXRpIEZBUSBuaXRpIGRva3VtZW50YWNpamEgbmUgcG9tYb51LCBk
ZXRla3RpcmFsaSBzdGUNCiBAc3Ryb25ne2J1Z30gdSBkb2t1bWVudGFjaWpp
IGtvamkgYmlzdGUgdHJlYmFsaSBwcmlqYXZpdGksDQogQHJlZntNYWlsaW5n
IExpc3R9LiBNb2xpbW8gdmFzIGRhIHphaXN0YSB0byBpIHXoaW5pdGUsIGth
a28NCi1iaXNhbW8gbW9nbGkgcG9ib2xquWF0aSBkb2t1bWVudGFjaWp1Lg0K
K2Jpc21vIG1vZ2xpIHBvYm9sarlhdGkgZG9rdW1lbnRhY2lqdS4NCiANCiBA
bWVudQ0KLSogR05VIHBhc2NhbDo6ICAgICAgICAgICAgICAgR05VIHBhc2Nh
bA0KKyogR05VIFBhc2NhbDo6ICAgICAgICAgICAgICAgR05VIFBhc2NhbA0K
ICogSW5zdGFsaXJhbmplIEdQQy1hOjogICAgICAgSW5zdGFsaXJhbmplIEdQ
Qy1hDQogKiBHUEMgbmEgREpHUFAtdTo6ICAgICAgICAgICBHTlUgUGFzY2Fs
IG5hIERKR1BQIChNUy1ET1MpIHBsYXRmb3JtaQ0KICogWm5ha292bmkgbml6
b3ZpIHUgR1BDLXU6OiAgWm5ha292bmkgbml6b3ZpIChzdHJpbmdzKQ0KQEAg
LTU1LDEzICs1NSwxNCBAQA0KICogRkFRICJSYXpubyI6OiAgICAgICAgICAg
ICAgUmF6bm8NCiBAZW5kIG1lbnUNCiANCi1Abm9kZSBHTlUgcGFzY2FsDQot
QHNlY3Rpb24gR05VIHBhc2NhbA0KK0Bub2RlIEdOVSBQYXNjYWwNCitAc2Vj
dGlvbiBHTlUgUGFzY2FsDQogDQogQG1lbnUNCiAqIKl0byBpIHphuXRvOjog
ICAgICAgICAgICAgICAgICAgICAgICCpdG8gaSB6Ybl0bz8NCiAqIFRyZW51
dG5hIHZlcnppamE6OiAgICAgICAgICAgICAgICAgICBLb2phIGplIHRyZW51
dG5hIHZlcnppamE/DQotKiBLb21wYXRpYmlsbm9zdCBzYSBUdXJibyBQYXNj
YWwtb206OiAgRGEgbGkgamUga29tcGF0aWJpbGFuIHMgVHVyYm8gUGFzY2Fs
LW9tIChSKT8NCisqIEtvbXBhdGliaWxub3N0IHNhIFR1cmJvIFBhc2NhbG9t
OjogIERhIGxpIGplIGtvbXBhdGliaWxhbiBzDQorICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBUdXJibyBQYXNjYWxvbSAoUik/
DQogKiBQb2RyvmFuZSBwbGF0Zm9ybWU6OiAgICAgICAgICAgICAgICAgTmEg
a29qaW0gcGxhdGZvcm1hbWEgR05VIFBhc2NhbCByYWRpPw0KIEBlbmQgbWVu
dQ0KIA0KQEAgLTcxLDE3ICs3MiwxNyBAQA0KIEBpbmNsdWRlIHB1cnBvc2Uu
dGV4aQ0KIA0KIEBub2RlIFRyZW51dG5hIHZlcnppamENCi1Ac3Vic2VjdGlv
biBLb2phIGplIHRyZW51dG5hIGRpdmVyemlqYT8NCitAc3Vic2VjdGlvbiBL
b2phIGplIHRyZW51dG5hIHZlcnppamE/DQogDQogUHJpamUgc3JwbmphIDIw
MDAgcmVsZWFzZSB2ZXJ6aWplIHN1IG9iaehubyBzbGlqZWRpbGUgbmVrb2xp
a28NCiBtamVzZWNpIGplZG5hIGRydWd1LiBPZCB0YWRhIHNlIG5vdmEgdmVy
emlqYSBwb2phdmlsYSBnb3Rvdm8gc3Zha2loDQogbmVrb2xpa28gZGFuYSwg
ZG9zdHVwbmEga2FvIHNvdXJjZSBhcmhpdmENCiBAYyBpbGkgcyBDVlMgc2Vy
dmVyYQ0KLXMgR1BDIHdlYiBzaXRlLWEsDQorcyBHUEMgd2ViIHNpdGVhLA0K
IEB1cmVme2h0dHA6Ly93d3cuZ251LXBhc2NhbC5kZX0uDQogDQogWmEgZGV0
YWxqZSBvZCBub3ZpbSBtb2d15m5vc3RpbWEsIHBvZ2xlZGFqdGUgc2VrY2lq
dSBAc2FtcHtOZXdzfQ0KLW5hIHdlYiBzaXRlLXUuIE8gYnVnLW92aW1hIGtv
amkgc3UgbmVkYXZubyBwb3ByYXZsamVuaSwgbW9saW1vDQorbmEgd2ViIHNp
dGV1LiBPIGJ1Z292aW1hIGtvamkgc3UgbmVkYXZubyBwb3ByYXZsamVuaSwg
bW9saW1vDQogcG9nbGVkYWp0ZSBAc2FtcHtEb25lfSBzZWtjaWp1IG5hIFRv
LURvICgicHJlb3N0YWxvIHphIG5hcHJhdml0aSIpDQogbGlzdGkuDQogDQpA
QCAtOTEsMTAgKzkyLDEwIEBADQogemFrcnBlIHphIEdDQyAyLjguMSBpIEdD
QyAyLjk1LngsIGFsaSBzZSBwcmVwb3J16HVqZSBkYSBrb3Jpc3RpdGUgR0ND
IDIuOTUueC4NCiBAYyBGSVhNRSBzZWUgZm9yIEdDQyAzLngueA0KIA0KLUBu
b2RlIEtvbXBhdGliaWxub3N0IHNhIFR1cmJvIFBhc2NhbC1vbQ0KLUBzdWJz
ZWN0aW9uIERhIGxpIGplIGtvbXBhdGliaWxhbiBzIFR1cmJvIFBhc2NhbC1v
bSAoUik/DQorQG5vZGUgS29tcGF0aWJpbG5vc3Qgc2EgVHVyYm8gUGFzY2Fs
b20NCitAc3Vic2VjdGlvbiBEYSBsaSBqZSBrb21wYXRpYmlsYW4gcyBUdXJi
byBQYXNjYWxvbSAoUik/DQogDQotR1BDIG5pamUgdXNwdXRuaSBuYWRvbWpl
c3RhayB6YSBEb3JsYW5kb3YgVHVyYm8gUGFzY2FsIChSKS4NCitHUEMgbmlq
ZSB1c3B1dG5pIG5hZG9tamVzdGFrIHphIEJvcmxhbmRvdiBUdXJibyBQYXNj
YWwgKFIpLg0KIEdvdG92byBzdmUgamV6aehuZSBtb2d15m5vc3RpIEJQLWEg
c3UgcG9kcr5hbmUuIFByaW1qZXRuZQ0KIGl6bmlta2Ugc3UgZm9ybWF0aSB6
bmFrb3ZuaWggbml6b3ZhIChrYW8guXRvIGplIGRpc2t1dGlyYW5vIG5pvmUN
CiB1IGRva3VtZW50dSksIGlsaSBAc2FtcHtNZW19IGkgQHNhbXB7UG9ydH0g
cHNldWRvLXBvbGphLCBpYWtvDQpAQCAtMTE1LDcgKzExNiw3IEBADQogQG5v
ZGUgUG9kcr5hbmUgcGxhdGZvcm1lDQogQHN1YnNlY3Rpb24gTmEga29qaW0g
cGxhdGZvcm1hbWEgR05VIFBhc2NhbCByYWRpPw0KIA0KLUdPQyBrb3Jpc3Rp
IEdDQyAiYmFja2VuZCIsIHRha28gZGEgYmkgdHJlYmFvIHJhZGl0aSBuYSBz
dmltIHN1c3RhdmltYQ0KK0dQQyBrb3Jpc3RpIEdDQyAiYmFja2VuZCIsIHRh
a28gZGEgYmkgdHJlYmFvIHJhZGl0aSBuYSBzdmltIHN1c3RhdmltYQ0KIHBv
ZHK+YW5pbSBvZCBHTlUgQ0MtYS4gT3ZvIHVrbGp16HVqZSC5aXJvayByYXNw
b24gVW5peCBzdXN0YXZhLA0KIE1TLURPUywgT1MvMiBpIFdpbjMyLiBQdW5h
IGxpc3RhIHBsYXRmb3JtaSBwb2RyvmFuaWggb2QgR0NDLWENCiBtb75lIHNl
IG5h5mkgdSBkYXRvdGVjaSBAZmlsZXtJTlNUQUxMfSBHQ0MgZGlzdHJpYnVj
aWplLiBTdmUNCkBAIC0xNDYsMTIgKzE0NywxMyBAQA0KIEBpdGVtICAgICAg
ICBzMzkwLWlibS1saW51eC1nbnUNCiBAZW5kIG11bHRpdGFibGUNCiANCi1A
c3Ryb25ne09LIG5hcm9kZSAtLSC5YWxqaXRlIG5hbSBzdm9qZSBwcmlwb3Zq
ZXN0aSBvIHVzcGplaHUsIHMga2Fub25p6GtpbSBpbWVuaW1hIG1huWluYSF9
DQorQHN0cm9uZ3tPSyBuYXJvZGUgLS0guWFsaml0ZSBuYW0gc3ZvamUgcHJp
cG92amVzdGkgbyB1c3BqZWh1LCBzDQora2Fub25p6GtpbSBpbWVuaW1hIG1h
uWluYSF9DQogDQogQG5vZGUgSW5zdGFsaXJhbmplIEdQQy1hDQogQHNlY3Rp
b24gSW5zdGFsaXJhbmplIEdQQy1hDQogDQotbmFqc3ZqZb5pamUgaW5zdHJ1
a2NpamUgemEgaW5zdGFsYWNpanUgbW++ZXRlIG5h5mkgdSBHUEMgcHJpcnXo
bmlrdQ0KK05hanN2amW+aWplIGluc3RydWtjaWplIHphIGluc3RhbGFjaWp1
IG1vvmV0ZSBuYeZpIHUgR1BDIHByaXJ16G5pa3UNCiBpbGkgdSBkYXRvdGVj
aSBAc2FtcHtJTlNUQUxMfSB1IHNvdXJjZSBkaXN0cmlidWNpamFtYSwgaWxp
IG5hIEdQQw0KIHdlYiBwb3Nsdb5pdGVsanUuDQogQGlmY2xlYXIgRkFRT05M
WQ0KQEAgLTE2NCwxMSArMTY2LDEzIEBADQogQGMgRklYTUUgLS0gIkxpYnJh
cmllcyIgbGVmdCB1bnRyYW5zbGF0ZWQgYmVjYXVzZSByZWZlcmVuY2VkIGZy
b20gZW4vaW5zdGFsbC50ZXhpDQogQG1lbnUNCiAqIERva3VtZW50YWNpanNr
ZSBkYXRvdGVrZTo6ICCpdG8gc2xpamVkZeZlIOhpdGF0aT8NCi0qIEtvbXBv
bmVudGU6OiAgICAgICAgICAgICAgICBLb2plIGtvbXBvbmVudGUgdHJlYmFt
IHphIHBlcnZv8GVuamUgUGFzY2FsIGtvZGE/DQorKiBLb21wb25lbnRlOjog
ICAgICAgICAgICAgICAgS29qZSBrb21wb25lbnRlIHRyZWJhbSB6YSBwcmV2
b/BlbmplIFBhc2NhbCBrb2RhPw0KICogRGVidWdnZXI6OiAgICAgICAgICAg
ICAgICAgIEtha28gZGEgaXNwcmF2bGphbSBtb2plIFBhc2NhbCBwcm9ncmFt
ZT8NCi0qIExpYnJhcmllczo6ICAgICAgICAgICAgICAgICBCaWJsaW90ZWtl
IC0ga29qZSBiaWggZG9kYXRuZSBiaWJsaW90ZWtlIHRyZWJhbyBpbWF0aT8N
CisqIExpYnJhcmllczo6ICAgICAgICAgICAgICAgICBCaWJsaW90ZWtlIC0g
a29qZSBiaWggZG9kYXRuZSBiaWJsaW90ZWtlIHRyZWJhbw0KKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgaW1hdGk/DQogKiBEYXJvdmFuZSBq
ZWRpbmljZTo6ICAgICAgICAgRGFyb3ZhbmUgamVkaW5pY2UNCi0qIElERTo6
ICAgICAgICAgICAgICAgICAgICAgICBNb75ldGUgbGkgcHJlcG9ydehpdGkg
aW50ZWdyaXJhbnUgcmF6dm9qbnUgb2tvbGludSAoSURFKT8NCisqIElERTo6
ICAgICAgICAgICAgICAgICAgICAgICBNb75ldGUgbGkgcHJlcG9ydehpdGkg
aW50ZWdyaXJhbnUgcmF6dm9qbnUNCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIG9rb2xpbnUgKElERSk/DQogQGVuZCBtZW51DQogDQogQG5v
ZGUgRG9rdW1lbnRhY2lqc2tlIGRhdG90ZWtlDQpAQCAtMTg4LDcgKzE5Miw3
IEBADQogQGVuZCBtdWx0aXRhYmxlDQogDQogQG5vZGUgS29tcG9uZW50ZQ0K
LUBzdWJzZWN0aW9uIEtvamUga29tcG9uZW50ZSB0cmViYW0gemEgcGVydm/w
ZW5qZSBQYXNjYWwga29kYT8NCitAc3Vic2VjdGlvbiBLb2plIGtvbXBvbmVu
dGUgdHJlYmFtIHphIHByZXZv8GVuamUgUGFzY2FsIGtvZGE/DQogDQogS29t
cGxldGlyYW4gc3VzdGF2IFBhc2NhbCBwcmV2b2Rpb2NhIGJpIHRyZWJhbyBp
bWF0aSBiYXJlbToNCiANCkBAIC0yMTAsNyArMjE0LDcgQEANCiBAbm9kZSBE
ZWJ1Z2dlcg0KIEBzdWJzZWN0aW9uIEtha28gZGEgaXNwcmF2bGphbSBtb2pl
IFBhc2NhbCBwcm9ncmFtZT8NCiANCi1EYSBiaXN0ZSBkdWJ1Z2dpcmFsaSBz
dm9qZSBwcm9ncmFtZSwgKGEpIEdOVSBQYXNjYWwgbW9yYSBiaXRpIHUNCitE
YSBiaXN0ZSBkZWJ1Z2dpcmFsaSBzdm9qZSBwcm9ncmFtZSwgKGEpIEdOVSBQ
YXNjYWwgbW9yYSBiaXRpIHUNCiBtb2d15m5vc3RpIGdlbmVyaXJhdGkgZGVi
dWcgaW5mb3JtYWNpamUgemEgdmG5dSBwbGF0Zm9ybXUsIGkNCiAoYikgbW9y
YXRpIGltYXRpIGRlYnVnZ2VyIGtvamkganUgem5hZGUgcmF6dW1qZXRpLg0K
IA0KQEAgLTIyMywxMyArMjI3LDEzIEBADQogb25kYSB0byB6bmHoaSBkYSBH
UEMgbmUgbW++ZSBnZW5lcmlyYXRpIGRlYnVnZ2luZyBpbmZvcm1hY2lqZS4g
T2Jp6G5vLA0KIGluc3RhbGlyYW5qZQ0KIEBzYW1we2dhc30gKGRpbyBHTlUg
YmludXRpbHMpIHVtamVzdG8gdmG5ZWcgInNpc3RlbXNrb2ciIGFzZW1ibGVy
YQ0KLW1vvmUgcmlqZbl0aXRpIHByb2JsZW0uIEthZCBrb25maWd1cmlyYXRl
IEdDQyBrb2ppIEdQQyBrb3Jpc3RpLCBzcGVjaWZpY2lyYWp0ZQ0KK21vvmUg
cmlqZblpdGkgcHJvYmxlbS4gS2FkIGtvbmZpZ3VyaXJhdGUgR0NDIGtvamkg
R1BDIGtvcmlzdGksIHNwZWNpZmljaXJhanRlDQogQHNhbXB7LS13aXRoLWdu
dS1hc30sIGkgLSBwbyBtb2d15m5vc3RpIC0gQHNhbXB7LS13aXRoLWdudS1s
ZH0gaS9pbGkNCiBAc2FtcHstLXdpdGgtc3RhYnN9LiBWabllIGluZm9ybWFj
aWphIG1vvmUgc2UgbmHmaSB1DQogQGZpbGV7SU5TVEFMTH0gZGF0b3RlY2kg
dSBHTlUgQ0Mgc291cmNlIGRpcmVrdG9yaWp1Lg0KIA0KIEBpdGVtDQotRGVi
dWdnZXIgdmG5ZWcgc3VzdGF2YSBuZSBtb3JhIHJhenVtaWpldGkgZGVidWcg
aW5mb3JtYWNpamUgZ2VuZXJpcmFuZQ0KK0RlYnVnZ2VyIHZhuWVnIHN1c3Rh
dmEgbmUgbW9yYSByYXp1bWpldGkgZGVidWcgaW5mb3JtYWNpamUgZ2VuZXJp
cmFuZQ0KIEdOVSBhbGF0a2FtYS4gVSB0b20gc2x16GFqdSBtb75lIHBvbW/m
aSBpbnN0YWxpcmFuamUgQHNhbXB7Z2RifS1hLg0KIEBlbmQgaXRlbWl6ZQ0K
IA0KQEAgLTI2MCw3ICsyNjQsNyBAQA0KIA0KIEBjIEZJWE1FIC0tIHRoZSBm
b2xsb3dpbmcgbGVmdCB1bnRyYW5zbGF0ZWQgYmVjYXVzZSByZWZlcmVuY2Vk
IGZyb20gZW4vaW5zdGFsbC50ZXhpDQogQG5vZGUgTGlicmFyaWVzDQotQHN1
YnNlY3Rpb24gS29qZSBiaSBkb2RhdG5lIGJpYmxpb3Rla2UgdHJlYmFvIGlt
YXRpPw0KK0BzdWJzZWN0aW9uIEJpYmxpb3Rla2UgLS0ga29qZSBiaSBkb2Rh
dG5lIGJpYmxpb3Rla2UgdHJlYmFvIGltYXRpPw0KIEBjaW5kZXggbGlicmFy
aWVzDQogQGNpbmRleCBiaWJsaW90ZWtlDQogQGNpbmRleCBnbXANCkBAIC0z
MDYsMTAgKzMxMCwxMCBAQA0KIEB1cmVme2h0dHA6Ly9mamYuZ251LmRlL3Bl
bmcvfS4NCiANCiBAY2luZGV4IFJISURFDQotQGl0ZW0gUkhJREUuIERKR1BQ
IGtvcmlzbmljaSBtb2dsaSBiaSBwb2t1uWF0aSBSSElERS4gUG9zbGplZG5q
YQ0KK0BpdGVtIFJISURFLiBESkdQUCBrb3Jpc25pY2kgbW9nbGkgYmkgaXNw
cm9iYXRpIFJISURFLiBQb3NsamVkbmphDQogKGJldGEpIHZlcnppamEgamUg
a29tcGF0aWJpbG5hIHMgR05VIFBhc2NhbG9tIGkgb21vZ3XmYXZhIHN0ZXAs
DQogdHJhY2UgaSB3YXRjaCBmdW5rY2lqZSBwb3B1dCBvbmloIHUgQm9ybGFu
ZCBJREUtdS4gTW++ZSBzZSBuYeZpIG5hDQotQHVyZWZ7aHR0cDovL3d3dy50
dS1jaGVtbml0ei5kZS9+c2hvL3Joby9yaGlkZS9yaGlkZS5odG1sfS4NCitA
dXJlZntodHRwOi8vd3d3LnJoaWRlLmNvbX0uDQogDQogQGNpbmRleCBEZXZQ
YXNjYWwNCiBAaXRlbSBEZXZQYXNjYWwuIERldlBhc2NhbCBqZSBmcmVlIHNv
ZnR3YXJlIElERSB6YSBtaW5ndzMyIHBsYXRmb3JtdS4NCkBAIC0zNDUsMTEg
KzM0OSwxMSBAQA0KIEBub2RlIKl0byBqZSBESkdQUA0KIEBzdWJzZWN0aW9u
IKl0byBqZSBESkdQUD8NCiANCi1TbGlqZWRl5mkgcGFyYWdyYWYgamUgcyBz
aXRlLWENCitTbGlqZWRl5mkgcGFyYWdyYWYgamUgcHJldXpldCBzYSBzaXRl
LWENCiBAdXJlZntodHRwOi8vd3d3LmRlbG9yaWUuY29tL2RqZ3BwL306DQog
DQogREpHUFAgamUga29tcGxldGFuIDMyLWJpdCBDL0MrKyByYXp2b2puaSBz
aXN0ZW0gbmEgSW50ZWwgODAzODYNCi0oaSB2ablpbSkgUEMtamltYSBrb2pp
IHZydGUgRE9TLiBVa2xqdeh1amUgcHJpamVub3MgbW5vZ2ltIEdOVQ0KKyhp
IHZpuWltKSBQQy1qaW1hIGtvamkgdnJ0ZSBET1MuIFVrbGp16HVqZSBwcmlq
ZW5vcyBtbm9naWggR05VDQogcmF6dm9qbmloIGFsYXRraS4gUmF6dm9qbmUg
YWxhdGtlIHphaHRpamV2YWp1IDgwMzg2IGlsaSBub3ZpamUNCiByYeh1bmFs
bywga2FvIGkgcHJvZ3JhbWkga29qZSBvbmUgcHJvaXp2b2RlLiBVIG5hanZl
5mVtIGJyb2p1DQogc2x16GFqZXZhLCBwcm9ncmFtaSBrb2plIHByb2l6dm9k
aSBzZSBtb2d1IGtvbWVyY2lqYWxubyBwcm9kYXZhdGkNCkBAIC00MTksNyAr
NDIzLDcgQEANCiANCiBHUEMgb25saW5lIGRva3VtZW50YWNpamEgamUgdSBH
TlUgaW5mbyBmb3JtYXR1OyBwb3RyZWJhbiB2YW0gamUNCiBpbmZvLXJlYWRl
ciAoQGZpbGV7dHhpMzkwYi56aXB9KSBkYSBnYSBwcm/oaXRhdGUsIGlsaSBr
b3Jpc3RpdGUNCi11Z3Jh8GVuaSBpbmZvLXJlYWRlciBSSElERSBpbGkgUEVO
RyBJREUuIERhIGJpc3RlIGRvZGFsaSBHUEMNCit1Z3Jh8GVuaSBpbmZvLXJl
YWRlciBpeiBSSElERSBpbGkgUEVORyBJREUuIERhIGJpc3RlIGRvZGFsaSBH
UEMNCiBkb2t1bWVudGFjaWp1IHUgaW5mbyAiZGlyZWN0b3J5IiBkYXRvdGVr
dSwgZWRpdGlyYWp0ZSBkYXRvdGVrdQ0KIEBmaWxle2M6XGdwY1xpbmZvXGRp
cn0sIGkgbmHwaXRlIHNsaWplZGXmaSBvZGxvbWFrOg0KIA0KQEAgLTQzNCw3
ICs0MzgsNyBAQA0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIEBlbmQgZXhhbXBsZQ0KIA0K
LURhIGJpc3RlIGRvZGFsaSBHUEMsIHByb21pamVudGl0ZSBvdmUgcmV0a2Ug
dGFrbyBkYSBpemdsZWRhanUNCitEYSBiaXN0ZSBkb2RhbGkgR1BDLCBwcm9t
aWplbml0ZSBvdmUgcmV0a2UgdGFrbyBkYSBpemdsZWRhanUNCiBvdmFrbzoN
CiANCiBAZXhhbXBsZQ0KQEAgLTQ5NCw3ICs0OTgsNyBAQA0KIGluc3RydWtj
aWplIHUgc3ZvamUgcHJvZ3JhbWUsIHpuYXRubyDmZXRlIHNtYW5qaXRpIG5q
aWhvdnUga29yaXNub3N0Lg0KIA0KIEFrbyBtaXNsaXRlIGRhIHphaXN0ZSBg
YHRyZWJhdGUnJyBhc2VtYmxlcnNraSBrb2QgcmFkaSBicnppbmUgLS0gaQ0K
LXByb3ZqZXJpbGkgc3RlIGRhIHNlIGFzZW1ibGVyc2tpIGtvZCB6YWlzdGEg
dnJ0aSBicnplIG5lZ28gUGFzY2FsIGtvZA0KK3Byb3ZqZXJpbGkgc3RlIGRh
IHNlIGFzZW1ibGVyc2tpIGtvZCB6YWlzdGEgdnJ0aSBicr5lIG5lZ28gUGFz
Y2FsIGtvZA0KIHNhIHByaWtsYWRuaW0gb3B0aW1pemFjaWphbWEgLS0gbW9n
bGkgYmlzdGUgcG++ZWxqZXRpIG9ib2plLCBpIFBhc2NhbA0KIGkgYXNlbWJs
ZXJza3UgdmVyemlqdSwgaSBkb3p2b2xpdGkgbnByLiBkYSBqZWRhbiBAc2Ft
cHtAeyRpZmRlZiBpMzg2QH19DQogb2Rsdeh1amUga29qdSDmZSBrb3Jpc3Rp
dGkuIE5hIG92YWogbmHoaW4sIHByb2dyYW0g5mUgc2UgYmFyZW0gcHJldmVz
dGkNCkBAIC01MDIsOCArNTA2LDggQEANCiANCiBAbm9kZSBESkdQUC1zcGVj
aWZp6GFuIGtvZA0KIEBzdWJzZWN0aW9uIFJlY2kgbWkga2FrbyBkYSBrb3Jp
c3RpbSBEUE1JLCBCSU9TIGkgb3N0YWxlIHN0dmFyaSBwb3ZlemFuZSBzIERP
Uy1vbQ0KLURQTUksIEJJU08gaSBvc3RhbGUgZnVua2NpamUgbmUgcmF6bGlr
dWp1IHNlIG9kIG9zdGFsaWggc2lzdGVtc2tpaA0KLWZ1bmtjaWphLiBQb2ds
ZWRhanRlIHUgR1BDIHByaXJ16G5payBrYWtvIHByaXN0dXBpdGkgQy1iaWJs
aW90ZWNpIHN2b2cNCitEUE1JLCBCSU9TIGkgb3N0YWxlIGZ1bmtjaWplIG5l
IHJhemxpa3VqdSBzZSBvZCBvc3RhbGloIHNpc3RlbXNraWgNCitmdW5rY2lq
YS4gUG9nbGVkYWp0ZSB1IEdQQyBwcmlydehuaWsga2FrbyBwcmlzdHVwaXRp
IEMgYmlibGlvdGVjaSBzdm9nDQogc3VzdGF2YS4gT3ZhaiBtYWxpIHByaW1q
ZXIgcG9rYXp1amUga2FrbyBrb3Jpc3RpdGkgRFBNSSwga29waXJhanXmaQ0K
IG5la2Ugc3RydWt0dXJlIGkgcHJvdG90aXBvdmUgaXogQHNhbXB7PGRwbWku
aD59Og0KIA0KQEAgLTU3Nyw3ICs1ODEsNyBAQA0KIEBub2RlIFZlbGnoaW5h
IHN0b2dhIChzdGFjaykNCiBAc3Vic2VjdGlvbiBEb2JpbyBzYW0gYGBleGNl
cHRpb24nJyBrb2QgcHJpc3R1cGFuamEgQHNhbXB7YXJyYXkgWzEgLi4gNDAw
MDAwMF0gb2YgQnl0ZX0NCiANCi1QbyBgYGRlZmF1bHQtdScnLCBtYWtzaW1h
bG5hIHZlbGljaW5hIHN0b2dhIERKR1BQIGFwbGlrYWNpamUgamUgMjU2Sy4N
CitQbyBgYGRlZmF1bHQtdScnLCBtYWtzaW1hbG5hIHZlbGnoaW5hIHN0b2dh
IERKR1BQIGFwbGlrYWNpamUgamUgMjU2Sy4NCiBBa28gdHJlYmF0ZSB2abll
LCB0byB0cmViYXRlIHBvZGVzaXRpIHNhIHN0dWJlZGl0IHByb2dyYW1vbSwN
CiBucHIuDQogDQpAQCAtNTg4LDEwICs1OTIsMTUgQEANCiBEcnVnYehpamkg
bmHoaW4gamUgZGEgZG9kYXRlIHNsaWplZGXmaSBrb2QgdmG5ZW0gcHJvZ3Jh
bXUga2FrbyBiaQ0KIGRlZmluaXJhbGkgbWluaW1hbG51IHZlbGnoaW51IHN0
b2dhIChvdmRqZTogMiBNQikuIE92YSDmZSB2cmlqZWRub3N0IGJpdGkNCiBw
b7l0b3ZhbmEg6GFrIGkgYWtvIGtvcmlzbmlrIHBvc3RhdmkgbWFuamUgdnJp
amVkbm9zdGkga29yaXN0ZeZpIHN0dWJlZGl0LA0KLXRha28gZGEgYmkgb3Zh
IG1ldG9kYSBtb2dsYSBiaXRpIG5luXRvIHNpZ3VybmlqYS4NCit0YWtvIGRh
IGJpIG92YSBtZXRvZGEgbW9nbGEgYml0aSBuZbl0byBzaWd1cm5pamEuIChJ
bWUgbGlua2VyYSBAc2FtcHtfc3RrbGVufQ0KK2plIGVzZW5jaWphbG5vOyBp
bWUga29yabl0ZW5vIHUgUGFzY2FsdSBuaWplIG9kIHpuYehhamEuIEtvbnN0
YW50YSBzZSBuZSBtb3JhDQora29yaXN0aXRpIGJpbG8gZ2RqZSB1IHByb2dy
YW11LiBQcmVwb3J16HVqZSBzZSBkYSBvdnUgZGVrbGFyYWNpanUNCitzdGF2
aXRlIHUgZ2xhdm51IHByb2dyYW1za3UgZGF0b3Rla3UsIG5lIHUgYmVrdSBq
ZWRpbmljdS9tb2R1bCwgdGFrbw0KK2RhIHByb2dyYW1pIGtvamkga29yaXN0
ZSBtb2R1bC9qZWRpbmljdSBtb2d1IHBvc3Rhdml0aSBrb2ppIGdvZCBsaW1p
dA0KK2ltIGplIHBvdHJlYmFuLikNCiANCiBAZXhhbXBsZQ0KLUB7JGlmZGVm
IERKR1BQQH0NCitAeyRpZmRlZiBfX0dPMzJfX0B9DQogY29uc3QNCiAgIE1p
blN0YWNrU2l6ZTogQ2FyZGluYWwgPSAkMjAwMDAwOyBhdHRyaWJ1dGUgKG5h
bWUgPSAnX3N0a2xlbicpOw0KIEB7JGVuZGlmQH0NCkBAIC02MTksOSArNjI4
LDEwIEBADQogKiBTdHJpbmcgc2NoZW1hOjogICAgICAgICAgICAgICAgICAg
ICAgIMhlbXUgc3ZhIHRhIHpicmthIG9rbyBuaXpvdmE/DQogKiBOaXpvdmkg
dSB2YXJpYW50IHJlY29yZC1pbWE6OiAgICAgICAgIFByZWtsYXBhbmplIG5p
em92YSB1IHZhcmlhbnQgcmVjb3JkLWltYQ0KICogQmFqdCB6YSBkdWxqaW51
OjogICAgICAgICAgICAgICAgICAgICBaYbl0byBAc2FtcHtzWzBdfSBuZSBz
YWRyvmF2YSBkdWxqaW51Pw0KLSogTml6b3ZpIGthbyBwYXJhbWV0cmkgcG8g
dnJpamVkbm9zdGk6OiBQYb5uamEgc2Egem5ha292bmltIG5pem92aW1hIGth
byBwYXJhbWV0cmltYQ0KLSogS3JhdGtpIHpuYWtvdm5pIG5pem92aTo6ICAg
ICAgICAgICAgICBQb2RyuWthIHphIEJQIGtvbXBhdGliaWxuZSBrcmF0a2Ug
em5ha292bmUNCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBuaXpvdmUNCisqIE5pem92aSBrYW8gcGFyYW1ldHJpIHBvIHZy
aWplZG5vc3RpOjogUGG+bmphIHNhIHpuYWtvdm5pbSBuaXpvdmltYSBrYW8N
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBw
YXJhbWV0cmltYQ0KKyogS3JhdGtpIHpuYWtvdm5pIG5pem92aTo6ICAgICAg
ICAgICAgICBQb2RyuWthIHphIEJQIGtvbXBhdGliaWxuZSBrcmF0a2UNCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB6bmFr
b3ZuZSBuaXpvdmUNCiAqIEMgem5ha292bmkgbml6b3ZpOjogICAgICAgICAg
ICAgICAgICAgqXRvIHNhIEMgem5ha292bmltIG5pem92aW1hPw0KIEBlbmQg
bWVudQ0KIA0KQEAgLTY1MywxNCArNjYzLDE0IEBADQogQG5vZGUgTml6b3Zp
IHUgdmFyaWFudCByZWNvcmQtaW1hDQogQHN1YnNlY3Rpb24gUHJla2xhcGFu
amUgbml6b3ZhIHUgdmFyaWFudCByZWNvcmQtaW1hDQogDQotUTogRGEgbGkg
YmkgcmFsaehpdGUgdmFyaWphbnRlIHUgdmFyaWphbnQgcmVjb3JkLXUgdHJl
YmFsZQ0KK1E6IERhIGxpIGJpIHJhemxp6Gl0ZSB2YXJpamFudGUgdSAidmFy
aWphbnQiIHJlY29yZC11IHRyZWJhbGUNCiB6YXBhZGF0aSB1IGlzdHUgbWVt
b3JpanNrdSBsb2thY2lqdT8gUHJldGhvZG5pIFBhc2NhbGkga29qZSBzYW0N
CiBrb3Jpc3RpbyBzdSBvdm8gZ2FyYW50aXJhbGksIGkgbmFwaXNhbyBzYW0g
bG93LWxldmVsIGtvZCBrb2ppDQogc2Ugb3NsYW5qYSBuYSB0by4gVmFyaWph
bnRlIG5pc3UgaXN0ZSBkdWxqaW5lLCBuaXRpIGplIGJpbGENCiBuYW1qZXJh
IGRhIGJ1ZHUuDQogDQotQTogbmUsIG5hbWplcm5vIGplIHXoaW5qZW5vIGRh
IGRpc2tyaW1pbmFudGUgbmlzdSBwcmVwaXNhbmUsDQotZGEgYmkgb25lIG1v
Z2xlIGJpdGkgaXNwcmF2bm8gaW5pY2lqYWxpemlyYW5lIHByaWplIHN2ZWdh
Lg0KK0E6IE5lLCBuYW1qZXJubyBqZSB16GluamVubyBkYSBkaXNrcmltaW5h
bnRlIG5pc3UgcHJla2xvcGxqZW5lDQordSBtZW1vcmlqaSwgZGEgYmkgc2Ug
b25lIG1vZ2xlIGJpdGkgaXNwcmF2bm8gaW5pY2lqYWxpemlyYXRpIHByaWpl
IHN2ZWdhLg0KIFJhem1vdHJpdGU6DQogDQogQGV4YW1wbGUNCkBAIC02OTEs
NyArNzAxLDcgQEANCiBtZW1vcmlqZSAob2JhIG5lc3RhbmRhcmRuYSwgbmFy
YXZubywgYnVkdeZpIGRhIHN0YW5kYXJkIG5lIHByZXRwb3N0YXZsamENCiBu
abl0YSBvIGludGVybmltIHJlcHJlemVudGFjaWphbWE7IGFsaSBzdSBvYmEg
QlAta29tcGF0aWJpbG5hKSwNCiBAc2FtcHthYnNvbHV0ZX0gZGVrbGFyYWNp
amUgaSB2YXJpamFiaWxubyBkb2RqZWxqaXZhbmplIHRpcG92YQ0KLSh2YXJp
YWJsZSB0eXBlIGNhc3RzKS4gTnByLiBkYSBiaSBzZSBwcmFrbGFwYWxvIHBv
bGplIGJhanRvdmEgQHNhbXB7Yn0NCisodmFyaWFibGUgdHlwZSBjYXN0cyku
IE5wci4gZGEgYmkgc2UgcHJla2xhcGFsbyBwb2xqZSBiYWp0b3ZhIEBzYW1w
e2J9DQogc2EgdmFyaWphYmxvbSBAc2FtcHt2fToNCiANCiBAZXhhbXBsZQ0K
QEAgLTcwNiw3ICs3MTYsOCBAQA0KICAgdCA9IGFycmF5IFsxIC4uIFNpemVP
ZiAodildIG9mIEJ5dGU7DQogQGVuZCBleGFtcGxlDQogDQotbmFrb24g6GVn
YSBAc2FtcHt0ICh2KX0gbW++ZSBiaXRpIGtvcmm5dGVuIGthbyBwb2xqZSBw
cmVrbG9wbGplbiBzYSBAc2FtcHt2fS4NCituYWtvbiDoZWdhIEBzYW1we3Qg
KHYpfSBtb75lIGJpdGkga29yabl0ZW4ga2FvIHBvbGplIHByZWtsb3BsamVu
bw0KKyh1IG1lbW9yaWppIHNlIG5hbGF6aSBuYSBpc3RvbSBtamVzdHUpIHNh
IEBzYW1we3Z9Lg0KIA0KIEBub2RlIEJhanQgemEgZHVsamludQ0KIEBzdWJz
ZWN0aW9uIFphuXRvIEBzYW1we3NbMF19IG5lIHNhZHK+YXZhIGR1bGppbnU/
DQpAQCAtNzY0LDcgKzc3NSw3IEBADQogDQogUTogS2FkYSDmZSB0aSBrcmF0
a2kgbml6b3ZpIGJpdGkgbmEgcmFzcG9sYWdhbmp1Pw0KIA0KLUE6IFBsYW5p
cmEgc2UgdmXmIGR1vmUgb2QgZ29pbmUuIFpha2G5bmplbmplIGplIHV6cm9r
b3Zhbm8gcHJvYmxlbWltYQ0KK0E6IFBsYW5pcmEgc2UgdmXmIGR1vmUgb2Qg
Z29kaW5lLiBaYWthuW5qZW5qZSBqZSB1enJva292YW5vIHByb2JsZW1pbWEN
CiBrb2ppIHN1IHZpuWUgcHJpdGlza2FsaSB0aW0uDQogDQogQG5vZGUgQyB6
bmFrb3ZuaSBuaXpvdmkNCkBAIC04MzMsMTAgKzg0NCwxMSBAQA0KIEBpZnNl
dCBGQVFPTkxZDQogU2xpamVkZeZlIGluZm9ybWFjaWplIHN1IGl6IHRvZyBw
b2dsYXZsamEuDQogDQorQGMgRklYTUUgLS0gIk1haWxpbmcgTGlzdCIgaXMg
bGVmdCB1bnRyYW5zbGF0ZWQgYmVjYXVzZSBvZiB4cmVmcw0KIEBtZW51DQot
KiBNYWlsaW5nIGxpc3RhOjogICAgICAgICAgUHJpZHJ1vml0ZSBzZSBHUEMg
bWFpbGluZyBsaXN0aQ0KKyogTWFpbGluZyBMaXN0OjogICAgICAgICAgIFBy
aWRydb5pdGUgc2UgR1BDIG1haWxpbmcgbGlzdGkNCiAqIEFyaGl2ZSBtYWls
aW5nIGxpc3RpOjogICBQb2dsZWRhanRlIHUgYXJoaXZhbWEgbWFpbGluZyBs
aXN0ZQ0KLSogTmV3c2dyb3Vwczo6ICAgICAgICAgICAgIFBpdGFqdGUgbmEg
bmV3c2dyb3VwaSAoZ3J1cGEgdmlqZXN0aSBuYSBVU0VORVR1KQ0KKyogTmV3
c2dyb3Vwczo6ICAgICAgICAgICAgIFBpdGFqdGUgbmEgbmV3c2dyb3VwaSAo
Z3J1cGEgdmlqZXN0aSBuYSBVU0VORVQtdSkNCiAqIFByb2Zlc2lvbmFsbmEg
cG9kcrlrYTo6ICBQb3RyYb5pdGUgaW5kaXZpZHVhbG51IHBvZHK5a3UgemEg
R1BDDQogKiBLcmFob3ZpIHByZXZvZGlvY2E6OiAgICAgS2FkIHNlIGNvbXBp
bGVyIHNrcrlpIEBkb3Rze30NCiAqIFJlcG9ydGluZyBCdWdzOjogICAgICAg
ICBQcm9uYfBpdGUga2FrbyBwcmlqYXZpdGkgR1BDIGJ1Z292ZQ0KZGlmZiAt
ciAtdSAtdyBoci0yMDAzMDUwNy5kaXN0L2dwYy50ZXhpIGhyLTIwMDMwNzMw
L2dwYy50ZXhpDQotLS0gaHItMjAwMzA1MDcuZGlzdC9ncGMudGV4aQkyMDAz
LTA1LTAzIDAwOjAzOjQyLjAwMDAwMDAwMCArMDIwMA0KKysrIGhyLTIwMDMw
NzMwL2dwYy50ZXhpCTIwMDMtMDctMzAgMTg6NTA6MzUuMDAwMDAwMDAwICsw
MjAwDQpAQCAtMTUsNyArMTUsNyBAQA0KIEBjICAgICAgICAgIERvbWluaWsg
RnJlY2hlIDxkb21pbmlrLmZyZWNoZUBtYWlsYm94LnR1LWRyZXNkZW4uZGU+
DQogQGMgICAgICAgICAgRWlrZSBMYW5nZSA8ZWlrZUBnLW4tdS5kZT4NCiBA
Yw0KLUBjIExhc3QgbW9kaWZpY2F0aW9uOiAyMDAzLTA0LTMwIChmaWxlIHVw
IHRvIGRhdGUpDQorQGMgTGFzdCBtb2RpZmljYXRpb246IDIwMDMtMDUtMjUg
KGZpbGUgdXAgdG8gZGF0ZSkNCiBAYw0KIEBjIENyb2F0aWFuIHRyYW5zbGF0
aW9uDQogQGMgVHJhbnNsYXRvcjogTWlyc2FkIFRvZG9yb3ZhYyA8bXRvZG9y
b3ZfNjlAeWFob28uY29tPg0KQEAgLTg1LDE0ICs4NSwzNCBAQA0KIGBgQ29w
eWluZyAtLSBUaGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UnJywNCiBg
YExpYnJhcnkgQ29weWluZyAtLSBUaGUgR05VIExlc3NlciBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlJycsDQogYGBEb2N1bWVudGF0aW9uIENvcHlpbmcgLS0g
VGhlIEdOVSBGcmVlIERvY3VtZW50YXRpb24gTGljZW5zZScnLA0KK2BgRGVt
byBDb3B5aW5nIC0tIEdQQyB3aXRoIGV4Y2VwdGlvbicnLA0KIGBgR05VIC0t
IFRoZSBHTlUgUHJvamVjdCcnLA0KIGBgTWFuaWZlc3RvIC0tIFRoZSBHTlUg
TWFuaWZlc3RvJycgYW5kDQogYGBGdW5kaW5nIC0tIEhvdyB0byBoZWxwIGFz
c3VyZSBmdW5kaW5nIGZvciBGcmVlIFNvZnR3YXJlJycsDQogd2l0aCB0aGUg
RnJvbnQtQ292ZXIgVGV4dHMgYmVpbmcNCi1gYEdOVSBQYXNjYWwgcHJpcnXo
bmlrJycsDQorYGBUaGUgR05VIFBhc2NhbCBNYW51YWwnJywNCiBhbmQgd2l0
aCBubyBCYWNrLUNvdmVyIFRleHRzLiBBIGNvcHkgb2YgdGhlIGxpY2Vuc2Ug
aXMgaW5jbHVkZWQNCiBpbiB0aGUgc2VjdGlvbiBlbnRpdGxlZA0KIGBgRG9j
dW1lbnRhdGlvbiBDb3B5aW5nIC0tIFRoZSBHTlUgRnJlZSBEb2N1bWVudGF0
aW9uIExpY2Vuc2UnJy4NCisNCitJbiBhZGRpdGlvbiwgcGVybWlzc2lvbiBp
cyBncmFudGVkIHRvIGNvcHksIGRpc3RyaWJ1dGUgYW5kL29yIG1vZGlmeQ0K
K3RoaXMgZG9jdW1lbnQgZXhjZXB0IGZvciB0aGUgc2VjdGlvbnMNCitgYEdO
VSAtLSBUaGUgR05VIFByb2plY3QnJywNCitgYE1hbmlmZXN0byAtLSBUaGUg
R05VIE1hbmlmZXN0bycnIGFuZA0KK2BgRnVuZGluZyAtLSBIb3cgdG8gaGVs
cCBhc3N1cmUgZnVuZGluZyBmb3IgRnJlZSBTb2Z0d2FyZScnLA0KK3VuZGVy
IHRoZSB0ZXJtcyBvZiB0aGUgR05VIEZyZWUgRG9jdW1lbnRhdGlvbiBMaWNl
bnNlLCBWZXJzaW9uIDEuMQ0KK3B1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0
d2FyZSBGb3VuZGF0aW9uOw0KK3dpdGggdGhlIEludmFyaWFudCBTZWN0aW9u
cyBiZWluZw0KK2BgQ29weWluZyAtLSBUaGUgR05VIEdlbmVyYWwgUHVibGlj
IExpY2Vuc2UnJywNCitgYExpYnJhcnkgQ29weWluZyAtLSBUaGUgR05VIExl
c3NlciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlJycsDQorYGBEb2N1bWVudGF0
aW9uIENvcHlpbmcgLS0gVGhlIEdOVSBGcmVlIERvY3VtZW50YXRpb24gTGlj
ZW5zZScnIGFuZA0KK2BgRGVtbyBDb3B5aW5nIC0tIEdQTCB3aXRoIGV4Y2Vw
dGlvbicnLA0KK3dpdGggdGhlIEZyb250LUNvdmVyIFRleHRzIGJlaW5nDQor
YGBUaGUgR05VIFBhc2NhbCBNYW51YWwnJywNCithbmQgd2l0aCBubyBCYWNr
LUNvdmVyIFRleHRzLiBBIGNvcHkgb2YgdGhlIGxpY2Vuc2UgaXMgaW5jbHVk
ZWQNCitpbiB0aGUgc2VjdGlvbiBlbnRpdGxlZA0KK2BgRG9jdW1lbnRhdGlv
biBDb3B5aW5nIC0tIFRoZSBHTlUgRnJlZSBEb2N1bWVudGF0aW9uIExpY2Vu
c2UnJy4NCisNCiBAZW5kIGlmaW5mbw0KIA0KIEBzZXRjaGFwdGVybmV3cGFn
ZSBvZGQNCkBAIC0xNDgsNiArMTY4LDcgQEANCiBgYENvcHlpbmcnJywNCiBg
YEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMgTGljZW5zZScnLA0KIGBgR05V
IEZyZWUgRG9jdW1lbnRhdGlvbiBMaWNlbnNlJycsDQorYGBEZW1vIENvcHlp
bmcnJywNCiBgYFRoZSBHTlUgUHJvamVjdCcnLA0KIGBgVGhlIEdOVSBNYW5p
ZmVzdG8nJyBhbmQNCiBgYEZ1bmRpbmcgRnJlZSBTb2Z0d2FyZScnLA0KQEAg
LTE1Niw2ICsxNzcsNyBAQA0KIGFuZCB3aXRoIG5vIEJhY2stQ292ZXIgVGV4
dHMuDQogQSBjb3B5IG9mIHRoZSBsaWNlbnNlIGlzIGluY2x1ZGVkIGluIHRo
ZSBzZWN0aW9uIGVudGl0bGVkDQogYGBEb2N1bWVudGF0aW9uIENvcHlpbmcg
LS0gVGhlIEdOVSBGcmVlIERvY3VtZW50YXRpb24gTGljZW5zZScnLg0KKw0K
IEBlbmQgdGl0bGVwYWdlDQogQHN1bW1hcnljb250ZW50cw0KIEBjb250ZW50
cw0KQEAgLTE3OCw3ICsyMDAsNyBAQA0KICogRG9icm9kb7lsaTo6ICAgICAg
ICBEb2Jyb2RvuWxpIG5hIEdOVSBQYXNjYWwgQGRvdHN7fQ0KICogTmFnbGFz
Y2k6OiAgICAgICAgICBOZWtlIG9kIEdQQy1vdmloIGludGVyZXNhbnRuaWgg
em5h6GFqa2kuDQogKiBOZXdzOjogICAgICAgICAgICAgIE5vdm9zdGkgLSBO
b3ZhIHN2b2pzdHZhIEdOVSBQYXNjYWxhIChlbmdsZXNraSkuDQotKiBGQVE6
OiAgICAgICAgICAgICAgIExpc3RhIOhlc3RvIHBvc3RhdmxqYW5hIHBpdGFu
amEgbyBHTlUgUGFzY2FsdS4NCisqIEZBUTo6ICAgICAgICAgICAgICAgTGlz
dGEg6GVzdG8gcG9zdGF2bGphbmloIHBpdGFuamEgbyBHTlUgUGFzY2FsdS4N
CiANCiBJbnN0YWxhY2lqYToNCiANCkBAIC0yMTgsOSArMjQwLDcgQEANCiAN
CiAqIFByaXpuYW5qYTo6ICAgICAgICAgU3VyYWRuaWNpIG5hIEdOVSBQYXNj
YWwgcHJvamVrdHUuDQogKiBSZXN1cnNpOjogICAgICAgICAgIHJlc3Vyc2kg
emEga29yabl0ZW5qZSBzIEdQQy1vbS4NCi0NCiAqIEdOVTo6ICAgICAgICAg
ICAgICAgR05VIHByb2pla3QuDQotDQogKiBHUEMgaW5kZWtzOjogICAgICAg
IEluZGVrcyBrb25jZXB0YSBpIGltZW5hIHNpbWJvbGEgKG5lZG92crllbm8p
Lg0KIA0KIChOYXBvbWVuYTogbmFzbG92aSBuZWtpaCBwb2dsYXZsamEgbmlz
dSBwcmV2ZWRlbmkgemJvZyB1bmFrcnNuaWggcmVmZXJlbmNpIGl6DQpAQCAt
MjU0LDYgKzI3NCw3IEBADQogDQogQGluY2x1ZGUgYXV0aG9ycy50ZXhpDQog
QGluY2x1ZGUgcmVzb3VyY2VzLnRleGkNCisNCiBAaW5jbHVkZSBnbnUudGV4
aQ0KIA0KIEBub2RlIEdQQyBpbmRla3MNCmRpZmYgLXIgLXUgLXcgaHItMjAw
MzA1MDcuZGlzdC9ncGNzLnRleGkgaHItMjAwMzA3MzAvZ3Bjcy50ZXhpDQot
LS0gaHItMjAwMzA1MDcuZGlzdC9ncGNzLnRleGkJMjAwMy0wNS0wMyAwMDow
Mzo0Mi4wMDAwMDAwMDAgKzAyMDANCisrKyBoci0yMDAzMDczMC9ncGNzLnRl
eGkJMjAwMy0wNy0wOCAxODozMzoyMi4wMDAwMDAwMDAgKzAyMDANCkBAIC0x
NCw3ICsxNCw3IEBADQogQGMNCiBAYyBSZW1lbWJlciB0byB1cGRhdGUgdGhp
cyB3aGVuIHlvdSBzYXZlOg0KIEBzZXQgbGFzdHVwZGF0ZSAyMDAzLTA0LTI4
DQotQHNldCBsYXN0dHJhbnNsYXRpb251cGRhdGUgMjAwMy0wNC0yNw0KK0Bz
ZXQgbGFzdHRyYW5zbGF0aW9udXBkYXRlIDIwMDMtMDctMDgNCiANCiBAZGly
ZW50cnkNCiAqIFBhc2NhbCBDb2RpbmcgU3RhbmRhcmRzOiAoZ3Bjcy1ociku
ICAgR05VIFBhc2NhbCBDb2RpbmcgU3RhbmRhcmRzIChDcm9hdGlhbikuDQpA
QCAtMTk3LDExICsxOTcsMTAgQEANCiB3cmFwcGVyZSB0YWtvIGRhIFBhc2Nh
bCBwcm9ncmFtaSBpbGkgamVkaW5pY2UgKEBzYW1we3VuaXR9KSByYWRlDQog
cyBiaWxvIGtvam9tIHZlcnppam9tIGJpYmxpb3Rla2Uga29qYSB2YW0gamUg
bmEgcmFzcG9sYWdhbmp1Lg0KIA0KLUBjIEZJWE1FIC0tIHdoYXQgZG9lcyB0
aGlzIGFjdHVhbGx5IG1lYW4/Pz8gLSBBc2sgRnJhbmshLCBNVCAyMDAyMDEx
NQ0KIFUgbmVraW0gc2l0dWFjaWphbWEga2FkIHJ1a3VqZXRlIHMgdmVsaWtp
bSBwYWtldGltYSBuZSBtb75ldGUNCiBsYWtvIHphZHK+YXRpIGtvbXBhdGli
aWxub3N0IGl6bWXwdSByYXpsaehpdGloIHZlcnppamEgc2FtaWggcGFrZXRh
Lg0KIFUgb3Zha292b20gc2x16GFqdSwgbW++ZXRlIHBvdmV6aXZhdGkgKGVu
Z2wuIGxpbmtpbmcpIGl6cmF2bm8gcw0KLWJpYmxpb3Rla29tIHMga29qb20g
cGxhbmlyYXRlIHJhZGl0aSwgdGUgcG92Zb5pdGUgdSBwYWtldCBkb2RhdG51
DQordmVyemlqb20gYmlibGlvdGVrZSBzIGtvam9tIHBsYW5pcmF0ZSByYWRp
dGksIHRlIHBvdmW+aXRlIHUgcGFrZXQgcG9tb+ZudQ0KIEMgZGF0b3Rla3Ug
a29qYSBuZSByYWRpIG5puXRhIG9zaW0gcHJvdmplcmUgdmVyemlqZS4gRXZv
IHByaW1qZXJhDQogKG5hIGVuZ2xlc2tvbSBqZXppa3UpOg0KIA0KQEAgLTIy
MSw3ICsyMjAsNyBAQA0KIA0KIEBjaW5kZXggaGVhZGVyIHRyYW5zbGF0b3IN
CiBAY2luZGV4IHByZXZvZGlsYWMgaGVhZGVyIGRhdG90ZWthDQotQXV0b21h
dHNraSBwcmV2b2RpbGFjIGhlYWRlciBkYXRvdGVrYSBqZSB1IHBsYW51IGtv
amkgYmkgdehpbmlvIEMNCitVIHBsYW51IGplIGF1dG9tYXRza2kgcHJldm9k
aWxhYyBoZWFkZXIgZGF0b3Rla2Ega29qaSBiaSB16GluaW8gQw0KIHdyYXBw
ZXJlIHN1dmm5bmltYS4gT3ZvIGplLCBtZfB1dGltLCBuaW1hbG8gdHJpdmlq
YWxhbiB6YWRhdGFrIGkNCiBuaWplIHNpZ3Vybm8gZGEgamUgdSBwb3RwdW5v
c3RpIG1vZ3XmLCB0YWtvIGRhIOZlIHBvdHJhamF0aSBuZWtvDQogdnJpamVt
ZSBwcmlqZSBuZWdvILl0byBidWRlIG5hIHJhc3BvbGFnYW5qdS4NCkBAIC0z
MzAsNyArMzI5LDcgQEANCiANCiBPdm8gYmkgcmVzZXRpcmFsbyBzYW1vIHBv
bGplIGR1bGppbmUgem5ha292bm9nIG5pemEgQHNhbXB7c30uDQogDQotQGMg
RklYTUUgLS0gY2xhcmlmeSAic2NoZW1hdGEiIE1ULCAyMDAyMDExNQ0KK0Bj
IEZJWE1FIC0tIGNsYXJpZnkgInNjaGVtYXRhIiBNVCwgInNoZW1lIGRla2xh
cmlyYW5qYSB0aXBhIiBpcyByYXRoZXIgdW5jbGVhciAtLSBUTTIwMDMwNzA4
DQogQGl0ZW0NCiB2ZeZpbmEgc2x16GFqZXZhIGtvcmm5dGVuamEgQHNhbXB7
R2V0TWVtfSBpIEBzYW1we0ZyZWVNZW19IC0tIG9uaSBzdQ0KIG9iaehubyAn
d29yay1hcm91bmQnIHphIG5lZG9zdGFqdeZlIHNoZW1lIGRla2xhcmlyYW5q
YSB0aXBhDQpAQCAtMTM1MSw5ICsxMzUwLDcgQEANCiBtbm9nbyBkaXJla3Rp
dmEgemFqZWRubywgbmUgc3RhdmxqYWp0ZSByYXptYWtlIGl6bWXwdSBzdmFr
ZSwgamVkYW4NCiB6YXJleiBqZSBkb3ZvbGphbi4NCiANCi1AYyBGSVhNRQ0K
LUBjDQotQGMgTWF5YmUgc29tZW9uZSBoYXMgZ29vZCByZWFzb25zIHRvIHVz
ZSB0aGUgc3BhY2UgYWZ0ZXIgdGhlIGNvbW1hcy4NCitAYyBGSVhNRSAtLSBN
YXliZSBzb21lb25lIGhhcyBnb29kIHJlYXNvbnMgdG8gdXNlIHRoZSBzcGFj
ZSBhZnRlciB0aGUgY29tbWFzLg0KIA0KIEBjaW5kZXggZGlyZWt0aXZlIGkg
a29tZW50YXJpDQogVW51dGFyIGRpcmVrdGl2YSBuZSBiaSB0cmViYWxvIGJp
dGkga29tZW50YXJhLiBQablpdGUgaWggb2R2b2plbm8NCkBAIC0xNDAwLDkg
KzEzOTcsNyBAQA0KIEBjaW5kZXggbm8td2FybmluZyBkaXJla3RpdmENCiBA
c2FtcHtAeyRXLUB9fSAobm8gd2FybmluZ3MgLS0gYmV6IHVwb3pvcmVuamEp
IHNtaWplIHNlIGtvcmlzdGl0aSBzYW1vDQogbG9rYWxubywgaSBtb3JhIGlt
YXRpIGBgZml4bWUnJyAocG9wcmF2aSBtZSkga29tZW50YXIgKEBweHJlZntL
b21lbnRhcml9KSwNCi1qZXIgc2l0dWFjaWphIGluZGljaXJhIHByb2JsZW0g
cyBrb2RvbSBpbGkgcyBwcmV2b2Rpb2NlbS4gQWtvIHN1IG5hDQotcmFwb2xh
Z2FuanUsIGtvcmlzdGl0ZSBkaXJla3RpdmUgZGEgc2Ugb25lbW9ndeZlIHBv
amVkaW5hIHVwb3pvcmVuamEgbw0KLXByb2JsZW1pbWEgcyBwcmV2b2Rpb2Nl
bS4NCitqZXIgc2l0dWFjaWphIGluZGljaXJhIHByb2JsZW0gcyBrb2RvbSBp
bGkgcyBwcmV2b2Rpb2NlbS4NCiANCiBNb2xpbW8sIG5lbW9qdGUgb25lbW9n
deZpdmF0aSB1cG96b3JlbmphIGthZCBzdGUgc2FtbyBwcmVsaWplbmkgZGEg
bmFwablldGUNCiBrb2Qga29qaSBuZSBwcm9penZvZGkgdXBvem9yZW5qYS4N
CkBAIC0xNDk2LDkgKzE0OTEsOSBAQA0KIFRXaW5kb3dYWSA9IHBhY2tlZCBy
ZWNvcmQNCiAgIEB7JGlmZGVmIF9fQllURVNfQklHX0VORElBTl9fQH0NCiAg
IEZpbGw6IFRXaW5kb3dYWUludGVybmFsRmlsbDsNCi0gIHksIHg6IFRXaW5k
b3dYWUludGVybmFsQ2FyZDgNCisgIFksIFg6IFRXaW5kb3dYWUludGVybmFs
Q2FyZDggDQogICBAeyRlbGlmIGRlZmluZWQgKF9fQllURVNfTElUVExFX0VO
RElBTl9fKUB9DQotICB4LCB5OiBUV2luZG93WFlJbnRlcm5hbENhcmQ4Ow0K
KyAgWCwgWTogVFdpbmRvd1hZSW50ZXJuYWxDYXJkODsNCiAgIEZpbGw6IFRX
aW5kb3dYWUludGVybmFsRmlsbA0KICAgQHskZWxzZUB9DQogICBAeyRlcnJv
ciBFbmRpYW5uZXNzIGlzIG5vdCBkZWZpbmVkIUB9DQpAQCAtMTg3Niw5ICsx
ODcxLDcgQEANCiBiYXJlbSBqZWRhbiBwb3Rwcm9ncmFtKSBpbGkgbmFrb24g
emFyZXphLCBzIHV2bGHoZW5qZW0gcmVkYWthIHRha3ZpbQ0KIGRhIHNlIHpu
YehlbmplIHXoaW5pIGphc25pbToNCiANCi1AYyBGSVhNRQ0KLUBjDQotQGMg
SSBkb24ndCB0aGluayBpdCdzIGNvbnNpc3RlbnQgdG8gYWxsb3cgYm90aCBi
ZWZvcmUgYW5kIGFmdGVyLg0KK0BjIEZJWE1FIC0tIEkgZG9uJ3QgdGhpbmsg
aXQncyBjb25zaXN0ZW50IHRvIGFsbG93IGJvdGggYmVmb3JlIGFuZCBhZnRl
ci4NCiANCiBAZXhhbXBsZQ0KIGlmICh4ID0geSkNCkBAIC0yMzUwLDcgKzIz
NDMsNyBAQA0KIHZyaWplZG5vc3RpIGkgcG9rYXppdmHoZSBkb2ssIG5wci4g
cG9samEgamVkbm9iYWp0bmloIHpuYWtvdmEgbmlzdQ0KIHRpbWUgcG9nb/Bl
bmEuIChAcHhyZWZ7RW5kaWFubmVzcywgLCAsIGdwY30pDQogDQotQGVtcGh7
UHJpbWlqZXRpOn0gRHJ1Z2kgc2Ugc3RhdmtlIG1vZ3UgZG9kYXRpIG92ZGpl
IGFrbyB2YW0gc2UgdG8g6GluaQ0KK0BlbXBoe1ByaW1pamV0aTp9IEkgZHJ1
Z2Ugc2Ugc3RhdmtlIG1vZ3UgZG9kYXRpIG92ZGplIGFrbyB2YW0gc2UgdG8g
6GluaQ0KIGtvcmlzbmltLiBBa28gYmlzdGUgvmVsamVsaSBkZWZpbmljaWp1
IG5la29nIGRydWdvZyBwb2ptYSwgZGFqdGUgbmFtDQogZG8gem5hbmphLg0K
IA0KZGlmZiAtciAtdSAtdyBoci0yMDAzMDUwNy5kaXN0L2luZGV4Lmh0bWwu
aW4gaHItMjAwMzA3MzAvaW5kZXguaHRtbC5pbg0KLS0tIGhyLTIwMDMwNTA3
LmRpc3QvaW5kZXguaHRtbC5pbgkyMDAzLTA1LTA0IDA2OjEzOjU0LjAwMDAw
MDAwMCArMDIwMA0KKysrIGhyLTIwMDMwNzMwL2luZGV4Lmh0bWwuaW4JMjAw
My0wNy0wNyAxMjoxNjowNC4wMDAwMDAwMDAgKzAyMDANCkBAIC00Nyw4ICs0
Nyw4IEBADQogPHVsPg0KICAgPGxpPjxlbT5HUEMgcHJpcnXobmlrPC9lbT4N
CiAgICAgPHVsPg0KLSAgICAgIDxsaT5IVE1MIGZvcm1hdHUgemEgb25saW5l
IHByZWdsZWRhdmFuamU6IDxhIGhyZWY9Ii4uL2dwYy9pbmRleC5odG1sI1Rv
cCI+aHJ2YXRza2k8L2E+LCA8YSBocmVmPSIuLi9ncGMtaHIvaW5kZXguaHRt
bCNUb3AiPmVuZ2xlc2tpPC9hPg0KLSAgICAgIDxsaT50YXIuYnoyIGFyaGl2
YSBIVE1MIHN0cmFuaWNhOiA8YSBocmVmPSIuLi9ncGMtaHItaHRtbC50YXIu
YnoyIj5ocnZhdHNraTwvYT4sIDxhIGhyZWY9Ii4uL2dwYy1odG1sLnRhci5i
ejIiPmVuZ2xlc2tpPC9hPg0KKyAgICAgIDxsaT5IVE1MIGZvcm1hdHUgemEg
b25saW5lIHByZWdsZWRhdmFuamU6IDxhIGhyZWY9Ii4uL2dwYy9pbmRleC5o
dG1sIj5ocnZhdHNraTwvYT4sIDxhIGhyZWY9Ii4uL2dwYy1oci9pbmRleC5o
dG1sIj5lbmdsZXNraTwvYT4sIDxhIGhyZWY9Ii4uL2dwYy1lcy9pbmRleC5o
dG1sI1RvcCI+uXBhbmpvbHNraTwvYT4NCisgICAgICA8bGk+dGFyLmJ6MiBh
cmhpdmEgSFRNTCBzdHJhbmljYTogPGEgaHJlZj0iLi4vZ3BjLWhyLWh0bWwu
dGFyLmJ6MiI+aHJ2YXRza2k8L2E+LCA8YSBocmVmPSIuLi9ncGMtaHRtbC50
YXIuYnoyIj5lbmdsZXNraTwvYT4gPGEgaHJlZj0iLi4vZ3BjLWVzLWh0bWwu
dGFyLmJ6MiI+uXBhbmpvbHNraTwvYT4NCiAgICAgICA8bGk+PGEgaHJlZj0i
Li4vZ3BjLnBkZiI+UERGIGZvcm1hdCAoZW5nbGVza2kpPC9hPg0KICAgICAg
IDxsaT48YSBocmVmPSIuLi9ncGMucHMuYnoyIj5Qb3N0U2NyaXB0IGZvcm1h
dCAoYnppcDIpIChlbmdsZXNraSk8L2E+DQogICAgICAgICAgIHphIGlzcGlz
IG5hILl0YW1wYegNCkBAIC01Niw3ICs1Niw3IEBADQogICAgICAgICAgICh6
YWh0aWpldmENCiAgICAgICAgICAgPGEgaHJlZj0iLi4vaW1hZ2VzL0dudVBh
c2NhbC5lcHMiPkVQUyBkYXRvdGVrdSBHTlUgUGFzY2FsIGNydGW+YTwvYT4p
DQogICAgIDwvdWw+DQotICA8bGk+R05VIFBhc2NhbCBzdGFuZGFyZGkga29k
aXJhbmphOiA8YSBocmVmPSIuLi9ncGNzLWhyLmh0bWwiPmhydmF0c2tpPC9h
PiwgPGEgaHJlZj0iLi4vZ3Bjcy1lbi5odG1sIj5lbmdsZXNraTwvYT4sIDxh
IGhyZWY9Ii4uL2dwY3MtZGUuaHRtbCI+bmplbWHoa2k8L2E+DQorICA8bGk+
R05VIFBhc2NhbCBzdGFuZGFyZGkga29kaXJhbmphOiA8YSBocmVmPSIuLi9n
cGNzLWhyLmh0bWwiPmhydmF0c2tpPC9hPiwgPGEgaHJlZj0iLi4vZ3Bjcy1l
bi5odG1sIj5lbmdsZXNraTwvYT4sIDxhIGhyZWY9Ii4uL2dwY3MtZGUuaHRt
bCI+bmplbWHoa2k8L2E+LCA8YSBocmVmPSIuLi9oLWdwY3MtZXMuaHRtbCI+
uXBhbmpvbHNraTwvYT4NCiAgIDxsaT5FbWFpbCBpIE5ld3NHcm91cCAoVVNF
TkVUKSBwb2RyuWthDQogICA8bGk+R05VIFNlcnZpY2UgRGlyZWN0b3J5DQog
PC91bD4NCmRpZmYgLXIgLXUgLXcgaHItMjAwMzA1MDcuZGlzdC9pbnZva2Uu
dGV4aSBoci0yMDAzMDczMC9pbnZva2UudGV4aQ0KLS0tIGhyLTIwMDMwNTA3
LmRpc3QvaW52b2tlLnRleGkJMjAwMy0wNC0zMCAxOToxOTozOC4wMDAwMDAw
MDAgKzAyMDANCisrKyBoci0yMDAzMDczMC9pbnZva2UudGV4aQkyMDAzLTA3
LTA3IDEzOjQ2OjIzLjAwMDAwMDAwMCArMDIwMA0KQEAgLTUsNyArNSw3IEBA
DQogQGMgQXV0aG9yczogUGV0ZXIgR2Vyd2luc2tpIDxwZXRlckBnZXJ3aW5z
a2kuZGU+DQogQGMgICAgICAgICAgRnJhbmsgSGVja2VuYmFjaCA8ZnJhbmtA
cGFzY2FsLmdudS5kZT4NCiBAYw0KLUBjIExhc3QgbW9kaWZpY2F0aW9uOiAy
MDAzLTA0LTI4IChmaWxlIHVwIHRvIGRhdGUpDQorQGMgTGFzdCBtb2RpZmlj
YXRpb246IDIwMDMtMDEtMDEgKGZpbGUgdXAgdG8gZGF0ZSkNCiBAYw0KIEBj
IENyb2F0aWFuIHRyYW5zbGF0aW9uDQogQGMgQ2hhcnNldDogICAgaXNvLTg4
NTktMiAobGF0aW4gMikNCmRpZmYgLXIgLXUgLXcgaHItMjAwMzA1MDcuZGlz
dC9rZXl3b3Jkcy50ZXhpIGhyLTIwMDMwNzMwL2tleXdvcmRzLnRleGkNCi0t
LSBoci0yMDAzMDUwNy5kaXN0L2tleXdvcmRzLnRleGkJMjAwMy0wNC0zMCAx
OToxOTozOC4wMDAwMDAwMDAgKzAyMDANCisrKyBoci0yMDAzMDczMC9rZXl3
b3Jkcy50ZXhpCTIwMDMtMDctMDcgMTM6NDY6MzkuMDAwMDAwMDAwICswMjAw
DQpAQCAtNSw3ICs1LDcgQEANCiBAYyBBdXRob3JzOiBQZXRlciBHZXJ3aW5z
a2kgPHBldGVyQGdlcndpbnNraS5kZT4NCiBAYyAgICAgICAgICBGcmFuayBI
ZWNrZW5iYWNoIDxmcmFua0BwYXNjYWwuZ251LmRlPg0KIEBjDQotQGMgTGFz
dCBtb2RpZmljYXRpb246IDIwMDMtMDQtMjggKGZpbGUgdXAgdG8gZGF0ZSkN
CitAYyBMYXN0IG1vZGlmaWNhdGlvbjogMjAwMy0wNC0wNSAoZmlsZSB1cCB0
byBkYXRlKQ0KIEBjDQogQGMgQ3JvYXRpYW4gdHJhbnNsYXRpb24NCiBAYyBD
aGFyc2V0OiAgICBpc28tODg1OS0yIChsYXRpbiAyKQ0KQEAgLTI2LDcgKzI2
LDcgQEANCiBLbGp16G5lIHJpamXoaSBzdSBwcmV1emV0ZSBpeiBzbGlqZWRl
5mloIHN0YW5kYXJkYToNCiANCiBAaXRlbWl6ZSBAYnVsbGV0DQotQGl0ZW0g
SVNPIDcxODUgUGFzY2FsIChTUCkNCitAaXRlbSBJU08gNzE4NSBQYXNjYWwg
KENQKQ0KIEBpdGVtIElTTyAxMDIwNiBFeHRlbmRlZCBQYXNjYWwgKEVQKQ0K
IEBpdGVtIEFOU0kgcHJlbGltaW5hcm5pIE9iamVjdCBQYXNjYWwgKE9QKQ0K
IEBpdGVtIEJvcmxhbmQgUGFzY2FsIDcuMCAoQlApDQpAQCAtMzQsNyArMzQs
OCBAQA0KIEBpdGVtIFBhc2NhbC1TQyAoUFhTQywgUGFzY2FsIGVYdGVuc2lv
bnMgZm9yIFNjaWVudGlmaWMgQ2FsY3VsYXRpb25zIC0gUGFzY2FsDQogcHJv
uWlyZW5qYSB6YSB6bmFuc3R2ZW5lIHByb3Jh6HVuZSkNCiBAaXRlbSBWQVgg
UGFzY2FsIChWUCkNCi1AaXRlbSBNYWMgUGFzY2FsIChNUCkNCitAaXRlbSBT
dW4gUGFzY2FsIChTUCkNCitAaXRlbSBUcmFkaXRpb25hbCBNYWNpbnRvc2gg
UGFzY2FsIChNUCkNCiBAaXRlbSBHTlUgUGFzY2FsIHByb7lpcmVuamEgKEdQ
QykNCiBAZW5kIGl0ZW1pemUNCiANCmRpZmYgLXIgLXUgLXcgaHItMjAwMzA1
MDcuZGlzdC9saWJzLnRleGkgaHItMjAwMzA3MzAvbGlicy50ZXhpDQotLS0g
aHItMjAwMzA1MDcuZGlzdC9saWJzLnRleGkJMjAwMy0wNC0zMCAxOToxOToz
OC4wMDAwMDAwMDAgKzAyMDANCisrKyBoci0yMDAzMDczMC9saWJzLnRleGkJ
MjAwMy0wNy0wNyAxMzo0Njo1Ny4wMDAwMDAwMDAgKzAyMDANCkBAIC00LDcg
KzQsNyBAQA0KIEBjDQogQGMgQXV0aG9yOiBGcmFuayBIZWNrZW5iYWNoIDxm
cmFua0BwYXNjYWwuZ251LmRlPg0KIEBjDQotQGMgTGFzdCBtb2RpZmljYXRp
b246IDIwMDMtMDQtMzAgKGZpbGUgdXAgdG8gZGF0ZSkNCitAYyBMYXN0IG1v
ZGlmaWNhdGlvbjogMjAwMy0wMS0wMSAoZmlsZSB1cCB0byBkYXRlKQ0KIEBj
DQogQGMgQ3JvYXRpYW4gdHJhbnNsYXRpb24NCiBAYyBDaGFyc2V0OiAgICBp
c28tODg1OS0yIChsYXRpbiAyKQ0KZGlmZiAtciAtdSAtdyBoci0yMDAzMDUw
Ny5kaXN0L3B1cnBvc2UudGV4aSBoci0yMDAzMDczMC9wdXJwb3NlLnRleGkN
Ci0tLSBoci0yMDAzMDUwNy5kaXN0L3B1cnBvc2UudGV4aQkyMDAzLTA0LTMw
IDE5OjE5OjM4LjAwMDAwMDAwMCArMDIwMA0KKysrIGhyLTIwMDMwNzMwL3B1
cnBvc2UudGV4aQkyMDAzLTA3LTA3IDEzOjQ4OjE0LjAwMDAwMDAwMCArMDIw
MA0KQEAgLTYsNyArNiw3IEBADQogQGMgICAgICAgICAgSi5KLiB2YW4gZGVu
IEhlaWRlbiA8ai5qLnZhbmRlcmhlaWRlbkBzdHVkZW50LnV0d2VudGUubmw+
DQogQGMgICAgICAgICAgUGV0ZXIgR2Vyd2luc2tpIDxwZXRlckBnZXJ3aW5z
a2kuZGU+DQogQGMNCi1AYyBMYXN0IG1vZGlmaWNhdGlvbjogMjAwMy0wNC0z
MCAoZmlsZSB1cCB0byBkYXRlKQ0KK0BjIExhc3QgbW9kaWZpY2F0aW9uOiAy
MDAzLTAzLTA3IChmaWxlIHVwIHRvIGRhdGUpDQogQGMNCiBAYyBDcm9hdGlh
biB0cmFuc2xhdGlvbg0KIEBjIENoYXJzZXQ6ICAgIGlzby04ODU5LTIgKGxh
dGluIDIpDQpAQCAtNDIsNyArNDIsNyBAQA0KIHZl5mludSBFeHRlbmRlZCBQ
YXNjYWxhIChJU08gMTAyMDYsIHRlvmXmaSBwb3RwdW5vbSBpc3B1bmphdmFu
anUNCiBzdGFuZGFyZGEpLCB2aXNva28gamUga29tcGF0aWJpbGFuIHNhIEJv
cmxhbmQgUGFzY2Fsb20gKHZlcnppamEgNy4wKSwNCiB0ZSBpbWEgbmVrYSBw
b2dvZG5vc3RpIHphIGtvbXBhdGliaWxub3N0IHNhIGRydWdpbSBwcmV2b2Rp
b2NpbWENCi0oa2FvILl0byBqZSBWQVggUGFzY2FsLCBNYWMgUGFzY2FsLCBC
b3JsYW5kIERlbHBoaSBpIFBhc2NhbC1TQykuDQorKGthbyC5dG8gamUgVkFY
IFBhc2NhbCwgU3VuIFBhc2NhbCwgTWFjIFBhc2NhbCwgQm9ybGFuZCBEZWxw
aGkgaSBQYXNjYWwtU0MpLg0KIA0KIFRyZW51dG5vIGl6ZGFuamUgdGFrb/Bl
ciBwcnW+YSBtbm9nbyBrb3Jpc25paCBHTlUgZWtzdGVuemlqYSBrb2plIHNl
DQogbmUgbmFsYXplIHUgb3N0YWxpbSBQYXNjYWwgcHJldm9kaW9jaW1hLCBu
cHIuIGRhIHNlIG9sYWu5YSBwb3Zleml2YW5qZQ0KZGlmZiAtciAtdSAtdyBo
ci0yMDAzMDUwNy5kaXN0L3Jlc291cmNlcy50ZXhpIGhyLTIwMDMwNzMwL3Jl
c291cmNlcy50ZXhpDQotLS0gaHItMjAwMzA1MDcuZGlzdC9yZXNvdXJjZXMu
dGV4aQkyMDAzLTA0LTMwIDE5OjE5OjM4LjAwMDAwMDAwMCArMDIwMA0KKysr
IGhyLTIwMDMwNzMwL3Jlc291cmNlcy50ZXhpCTIwMDMtMDctMDcgMTM6NDg6
MjguMDAwMDAwMDAwICswMjAwDQpAQCAtNSw3ICs1LDcgQEANCiBAYyBBdXRo
b3JzOiBQZXRlciBHZXJ3aW5za2kgPHBldGVyQGdlcndpbnNraS5kZT4NCiBA
YyAgICAgICAgICBGcmFuayBIZWNrZW5iYWNoIDxmcmFua0BwYXNjYWwuZ251
LmRlPg0KIEBjDQotQGMgTGFzdCBtb2RpZmljYXRpb246IDIwMDMtMDQtMzAg
KGZpbGUgdXAgdG8gZGF0ZSkNCitAYyBMYXN0IG1vZGlmaWNhdGlvbjogMjAw
My0wMS0wMSAoZmlsZSB1cCB0byBkYXRlKQ0KIEBjDQogQGMgQ3JvYXRpYW4g
dHJhbnNsYXRpb24NCiBAYyBDaGFyc2V0OiAgICBpc28tODg1OS0yIChsYXRp
biAyKQ0KQEAgLTMwOSw2ICszMDksMTEgQEANCiBvZCBTY290dCBBLiBNb29y
ZS1hIG9iamG5bmphdmEgcmF6bGlrZSBpem1l8HUgZHZhIGRpamFsZWt0YSB1
DQogZGV0YWxqZS4NCiANCitEcmFmdCBzdGFuZGFyZCBgYE9iamVrdG5vLW9y
aWplbnRpcmFuYSBwcm+5aXJlbmphIFBhc2NhbGEnJyBtb2d1IHNlIG5h5mkg
bmENCitAZXhhbXBsZQ0KK0B1cmVme2h0dHA6Ly9wYXNjYWwtY2VudHJhbC5j
b20vT09FLXN0ZHMuaHRtbH0NCitAZW5kIGV4YW1wbGUNCisNCiBAaHRtbGhy
dWxlDQogDQogQHN1YmhlYWRpbmcgWmG5dGl0aXRlIHN2b2p1IHNsb2JvZHUh
DQpkaWZmIC1yIC11IC13IGhyLTIwMDMwNTA3LmRpc3Qvc3VwcG9ydC50ZXhp
IGhyLTIwMDMwNzMwL3N1cHBvcnQudGV4aQ0KLS0tIGhyLTIwMDMwNTA3LmRp
c3Qvc3VwcG9ydC50ZXhpCTIwMDMtMDUtMDcgMDA6Mzk6MzQuMDAwMDAwMDAw
ICswMjAwDQorKysgaHItMjAwMzA3MzAvc3VwcG9ydC50ZXhpCTIwMDMtMDct
MDcgMTM6NDg6NDEuMDAwMDAwMDAwICswMjAwDQpAQCAtNSw3ICs1LDcgQEAN
CiBAYyBBdXRob3JzOiBQZXRlciBHZXJ3aW5za2kgPHBldGVyQGdlcndpbnNr
aS5kZT4NCiBAYyAgICAgICAgICBGcmFuayBIZWNrZW5iYWNoIDxmcmFua0Bw
YXNjYWwuZ251LmRlPg0KIEBjDQotQGMgTGFzdCBtb2RpZmljYXRpb246IDIw
MDMtMDQtMzAgKGZpbGUgdXAgdG8gZGF0ZSkNCitAYyBMYXN0IG1vZGlmaWNh
dGlvbjogMjAwMy0wMS0wMSAoZmlsZSB1cCB0byBkYXRlKQ0KIEBjDQogQGMg
Q3JvYXRpYW4gdHJhbnNsYXRpb24NCiBAYyBDaGFyc2V0OiAgICBpc28tODg1
OS0yIChsYXRpbiAyKQ0KQEAgLTE0LDYgKzE0LDggQEANCiANCiBAaW5jbHVk
ZSBtYWNyb3MudGV4aQ0KIA0KK0BjIEZJWE1FIC0tICJzdXBwb3J0IiB1bnRy
YW5zbGF0ZWQgYmVjYXVzZSBiZWluZyB4cmVmJ2QgZnJvbSB1bnRyYW5zbGF0
ZWQNCitAYyAgICAgICAgICAgcGFydHMgb2YgZG9jcw0KIEBpZmNsZWFyIEZB
UU9OTFkNCiBAaWZjbGVhciBURVNUUkVBRE1FT05MWQ0KIEBub2RlIFN1cHBv
cnQNCmRpZmYgLXIgLXUgLXcgaHItMjAwMzA1MDcuZGlzdC93ZWxjb21lLnRl
eGkgaHItMjAwMzA3MzAvd2VsY29tZS50ZXhpDQotLS0gaHItMjAwMzA1MDcu
ZGlzdC93ZWxjb21lLnRleGkJMjAwMy0wNC0zMCAxOToxOTozOC4wMDAwMDAw
MDAgKzAyMDANCisrKyBoci0yMDAzMDczMC93ZWxjb21lLnRleGkJMjAwMy0w
Ny0zMCAxODo1MjoxMC4wMDAwMDAwMDAgKzAyMDANCkBAIC01LDcgKzUsNyBA
QA0KIEBjIEF1dGhvcnM6IFBldGVyIEdlcndpbnNraSA8cGV0ZXJAZ2Vyd2lu
c2tpLmRlPg0KIEBjICAgICAgICAgIEZyYW5rIEhlY2tlbmJhY2ggPGZyYW5r
QHBhc2NhbC5nbnUuZGU+DQogQGMNCi1AYyBMYXN0IG1vZGlmaWNhdGlvbjog
MjAwMy0wNC0zMCAoZmlsZSB1cCB0byBkYXRlKQ0KK0BjIExhc3QgbW9kaWZp
Y2F0aW9uOiAyMDAzLTA1LTI1IChmaWxlIHVwIHRvIGRhdGUpDQogQGMgQ3Jv
YXRpYW4gdHJhbnNsYXRpb24NCiBAYyBDaGFyc2V0OiAgICBpc28tODg1OS0y
IChsYXRpbiAyKQ0KIEBjIFRyYW5zbGF0b3I6IE1pcnNhZCBUb2Rvcm92YWMg
PG10b2Rvcm92XzY5QHlhaG9vLmNvbT4NCkBAIC05NCw3ICs5NCw3IEBADQog
dSB1bXUsIHZpZGkgQHJlZntHTlV9Lg0KIEBlbmQgaXRlbWl6ZQ0KIA0KLUBj
ICEhISEgaG93IHRvIHRyYW5zbGF0ZSBtb3JlIHByZWNpc2VseSAic3RydWN0
dXJlZCB2YWx1ZSBpbml0aWFsaXplcnMiDQorQGMgRklYTUUgLS0gaG93IHRv
IHRyYW5zbGF0ZSBtb3JlIHByZWNpc2VseSAic3RydWN0dXJlZCB2YWx1ZSBp
bml0aWFsaXplcnMiDQogDQogQWtvIHN0ZSB1cG96bmF0aSBzIHByb2dyYW1p
cmFuamVtIHUgU3RhbmRhcmQgUGFzY2FsdSAoSVNPIDcxODUpLA0KIHZqZXJv
amF0bm8g5mV0ZSBtb+ZpIGplZG5vc3Rhdm5vIHBv6GV0aSBpIHByZXZlc3Rp
IHN2b2plIHByb2dyYW1lLg0K

--899744747-2057276171-1059584342=:10392--


From gpc-doc-owner@gnu.de  Thu Jul 31 15:18:58 2003
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 19iDKY-0002H3-00
	for ; Thu, 31 Jul 2003 15:18:54 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id CAA23168
	for ; Thu, 31 Jul 2003 02:24:49 +0200
Date: Thu, 31 Jul 2003 02:24:49 +0200
Message-Id: <200307310024.CAA23168@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: GPC DOC hr translation update
To: gpc-doc@gnu.de
References: 
	
In-Reply-To: 
	
From: Frank Heckenbach 
User-Agent: semail 20030730
X-Archive-Number: 200307/15
X-Sequence-Number: 96

Mirsad Todorovac wrote:

> Here is the requested change to hr translation: DEBIANLYCORRECT-related
> changes have been removed.
> 
> The diff is the latest progress against what's released with gpc-20030507
> distribution.

I've applied your previous patches, so I can't use this. Please send
me a patch against what you sent me. (Private mail should be enough
here, I think.)

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Sat Aug 16 12:11:05 2003
Received: from domac.alu.hr ([161.53.235.3] ident=root)
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 19ny1Y-0003qy-00
	for ; Sat, 16 Aug 2003 12:11:04 +0200
Received: from localhost (mtodorov@localhost [127.0.0.1])
	by domac.alu.hr (8.12.6/8.12.6/Debian-8) with ESMTP id h7GAAG7S026170
	for ; Sat, 16 Aug 2003 12:10:16 +0200
Date: Sat, 16 Aug 2003 12:10:16 +0200 (CEST)
From: Mirsad Todorovac 
To: gpc-doc@gnu.de
Message-ID: 
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="899744747-487299801-1061028616=:2601"
X-Virus-Scanned: by amavisd-new at domac
X-Archive-Number: 200308/1
X-Sequence-Number: 97

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--899744747-487299801-1061028616=:2601
Content-Type: TEXT/PLAIN; charset=US-ASCII


Here is the `Val' update.

I've attached also preliminary versions of Integer2StringBase[Ext]

Mirsad

-- 
"I have a dream!" -- Martin Luther King Jr.

--899744747-487299801-1061028616=:2601
Content-Type: TEXT/plain; name="gpc-doc-ref-2003-08-16.diff"
Content-Transfer-Encoding: BASE64
Content-ID: 
Content-Description: Val diff
Content-Disposition: attachment; filename="gpc-doc-ref-2003-08-16.diff"

LS0tIC4uL2djYy0zLjIuMS9nY2MvcC5kaXN0L2RvYy9lbi9yZWZlcmVuY2Uu
dGV4aQkyMDAzLTA1LTAzIDE4OjMzOjM3LjAwMDAwMDAwMCArMDIwMA0KKysr
IC4uL2djYy0zLjIuMS9nY2MvcC9kb2MvZW4vcmVmZXJlbmNlLnRleGkJMjAw
My0wOC0xNiAxMjowNjo1OS4wMDAwMDAwMDAgKzAyMDANCkBAIC01ODUxLDYg
KzU4NTEsMTA4IEBADQogQHJlZntJbnRlZ2VyIFR5cGVzfSwNCiBAcmVme1N1
YnJhbmdlIFR5cGVzfS4NCiANCitAYyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQorDQorQG5vZGUgSW50ZWdlcjJTdHJpbmdCYXNlDQorQHVu
bnVtYmVyZWRzZWMgSW50ZWdlcjJTdHJpbmdCYXNlDQorQGNpbmRleCBJbnRl
Z2VyMlN0cmluZ0Jhc2UNCisNCisoVW5kZXIgY29uc3RydWN0aW9uLikNCisN
CitAc3ViaGVhZGluZyBTeW5vcHNpcw0KKw0KK0BleGFtcGxlDQordHlwZSBU
Q29udmVyc2lvbkJhc2UgID0gMi4uMzY7DQorICAgICANCitmdW5jdGlvbiBJ
bnRlZ2VyMlN0cmluZ0Jhc2UgKFNvdXJjZUludDogTG9uZ0ludDsgQmFzZTog
VENvbnZlcnNpb25CYXNlKTogVFN0cmluZzsNCitAZW5kIGV4YW1wbGUNCisN
CitAc3ViaGVhZGluZyBEZXNjcmlwdGlvbg0KKw0KK0BzYW1we0ludGVnZXIy
U3RyaW5nQmFzZX0gcmV0dXJucyBudW1iZXIgQHNhbXB7U291cmNlSW50fSBj
b252ZXJ0ZWQgdG8NCitzdHJpbmcgcmVwcmVzZW50YXRpb24gaW4gYmFzZSBA
c2FtcHtCYXNlfS4gQmFzZSBjYW4gYmUgMiB0byAzNiwgYW5kIHNvdXJjZQ0K
K251bWJlciBjYW4gYmUgbmVnYXRpdmUsIGluIHdoaWNoIGNhc2UgdGhlIG51
bWJlciBpcyBjb252ZXJ0ZWQgaW4NCityZXByZXNlbnRhdGlvbiB3aXRoIGEg
c2lnbiwgbm90IGEgMidzIGNvbXBsZW1lbnQgb3Igc2ltaWxhci4NCisNCitU
aGUgc3RyaW5nIGlzIG5vdCBwcmVmaXhlZCB3aXRoIGEgYmFzZSBwcmVmaXgg
LSBpZiB5b3UgbmVlZCB0aGF0IHJlcHJlc2VudGF0aW9uDQoreW91IGNhbiB1
c2UgQHNhbXB7SW50ZWdlcjJTdHJpbmdCYXNlRXh0fS4NCisNCitAc3ViaGVh
ZGluZyBDb25mb3JtaW5nIHRvDQorDQorQHNhbXB7SW50ZWdlcjJTdHJpbmdC
YXNlfSBpcyBhIEdOVSBQYXNjYWwgZXh0ZW5zaW9uLg0KKw0KK0BzdWJoZWFk
aW5nIEV4YW1wbGUNCisNCitAZXhhbXBsZQ0KK3Byb2dyYW0gaW50MnN0cmI7
DQordXNlcyBHUEM7DQordmFyIHMgOiBTdHJpbmc7DQorYmVnaW4NCisgIHMg
Oj0gSW50ZWdlcjJTdHJpbmdCYXNlICg0MiwgMik7ICAgICB7IHMgOj0gJzEw
MTAxMCc7IH0NCisgIHMgOj0gSW50ZWdlcjJTdHJpbmdCYXNlICgtNDIsIDgp
OyAgICB7IHMgOj0gJy01Mic7ICAgIH0NCitlbmQuDQorQGVuZCBleGFtcGxl
DQorDQorQHN1YmhlYWRpbmcgU2VlIGFsc28NCisNCitAcmVme0ludGVnZXIy
U3RyaW5nQmFzZUV4dH0sIEByZWZ7UmVhZFN0cn0sIEByZWZ7VmFsfSwgQHJl
ZntTdHJ9LEByZWZ7V3JpdGVTdHJ9Lg0KKw0KK0BjIC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NCisNCitAbm9kZSBJbnRlZ2VyMlN0cmluZ0Jh
c2VFeHQNCitAdW5udW1iZXJlZHNlYyBJbnRlZ2VyMlN0cmluZ0Jhc2VFeHQN
CitAY2luZGV4IEludGVnZXIyU3RyaW5nQmFzZUV4dA0KKw0KKyhVbmRlciBj
b25zdHJ1Y3Rpb24uKQ0KKw0KK0BzdWJoZWFkaW5nIFN5bm9wc2lzDQorDQor
QGV4YW1wbGUNCit0eXBlIFRDb252ZXJzaW9uQmFzZSAgPSAyLi4zNjsNCisg
ICAgIFRDb252ZXJzaW9uV2lkdGggPSAwLi5IaWdoKFRTdHJpbmcpOw0KKyAg
ICAgDQorZnVuY3Rpb24gSW50ZWdlcjJTdHJpbmdCYXNlIChTb3VyY2VJbnQ6
IExvbmdJbnQ7DQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCYXNl
OiBUQ29udmVyc2lvbkJhc2U7IFdpZHRoOiBUQ29udmVyc2lvbldpZHRoOw0K
KwkJCSAgICAgVXBwZXJDYXNlOiBCb29sZWFuOyBBZGRCYXNlUHJlZml4OiBC
b29sZW4pOiBUU3RyaW5nOw0KK0BlbmQgZXhhbXBsZQ0KKw0KK0BzdWJoZWFk
aW5nIERlc2NyaXB0aW9uDQorDQorQHNhbXB7SW50ZWdlcjJTdHJpbmdCYXNl
RXh0fSByZXR1cm5zIG51bWJlciBAc2FtcHtTb3VyY2VJbnR9IGNvbnZlcnRl
ZCB0bw0KK3N0cmluZyByZXByZXNlbnRhdGlvbiBpbiBiYXNlIEBzYW1we0Jh
c2V9LiBCYXNlIGNhbiBiZSAyIHRvIDM2LCBhbmQgc291cmNlDQorbnVtYmVy
IGNhbiBiZSBuZWdhdGl2ZSwgaW4gd2hpY2ggY2FzZSB0aGUgbnVtYmVyIGlz
IGNvbnZlcnRlZCBpbg0KK3JlcHJlc2VudGF0aW9uIHdpdGggYSBzaWduLCBu
b3QgYSAyJ3MgY29tcGxlbWVudCBvciBzaW1pbGFyLg0KKw0KK1RoZSBTdHJp
bmcgaXMgb3B0aW9uYWxseSBwcmVmaXhlZCB3aXRoIHplcm8gZGlnaXRzIHRv
IGhhdmUgQHNhbXB7V2lkdGh9IGRpZ2l0cw0KK3RvZ2V0aGVyIHdpdGggb3B0
aW9uYWwgYmFzZSBwcmVmaXggaWYgQHNhbXB7QWRkYmFzZVByZWZpeH0gaXMg
c2V0IHRvIEBzYW1we1RydWV9Lg0KK1RoZSBkaWdpdHMgYXJlIGluIHJhbmdl
IDAuLkJhc2UtMSwgd2hpbGUgZGlnaXRzIHdpdGggdmFsdWUgaGlnaGVyIHRo
YW4gOSBhcmUNCityZXByZXNlbnRlZCBieSBsb3dlcmNhc2UgbGV0dGVycyAn
YScgdG8gJ3onLCBzaW1pbGFyIHRvICdhJyAuLiAnZicgaW4gaGV4YWRlY2lt
YWwNCitub3RhdGlvbiAob3IgdXBwZXJjYXNlIGxldHRlcnMgaWYgQHNhbXB7
VXBwZXJDYXNlfSBpcyBzZXQgdG8gQHNhbXB7VHJ1ZX0pLg0KKw0KK1N0cmlu
ZyByZXN1bHRpbmcgZnJvbSBudW1iZXIgY29udmVyc2lvbiBpcyBhbHdheXMg
YXQgbGVhc3QgQHNhbXB7V2lkdGh9IGNoYXJhY3RlcnMNCitsb25nLiBJZiB5
b3UgZG9uJ3Qgd2FudCB6ZXJvIHBhZGRpbmcsIHN1cHBseSBAc2FtcHswfSBh
cyBAc2FtcHtXaWR0aH0gcGFyYW1ldGVyLg0KKw0KK0BzdWJoZWFkaW5nIENv
bmZvcm1pbmcgdG8NCisNCitAc2FtcHtJbnRlZ2VyMlN0cmluZ0Jhc2VFeHR9
IGlzIGEgR05VIFBhc2NhbCBleHRlbnNpb24uDQorDQorQHN1YmhlYWRpbmcg
RXhhbXBsZQ0KKw0KK0BleGFtcGxlDQorcHJvZ3JhbSBpbnQyc3RyYjsNCit1
c2VzIEdQQzsNCit2YXIgcyA6IFN0cmluZzsNCitiZWdpbg0KKyAgcyA6PSBJ
bnRlZ2VyMlN0cmluZ0Jhc2VFeHQgKDQyLCAyLCA4LCBGYWxzZSwgVHJ1ZSk7
ICAgICAgeyBzIDo9ICcyIzAwMTAxMDEwJzsgfQ0KKyAgcyA6PSBJbnRlZ2Vy
MlN0cmluZ0Jhc2VFeHQgKC00MiwgOCwgMCwgRmFsc2UsIFRydWUpOyAgICAg
eyBzIDo9ICctOCM1Mic7ICAgICAgfQ0KKyAgcyA6PSBJbnRlZ2VyMlN0cmlu
Z0Jhc2VFeHQgKDMyODAzNjIwNDIxNjU1NzUsIDM2LCAwLCBUcnVlLCBGYWtz
ZSk7DQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB7IHMgOj0gJ1dhc2hpbmd0b24nOyB9DQor
ZW5kLg0KK0BlbmQgZXhhbXBsZQ0KKw0KK0BzdWJoZWFkaW5nIFNlZSBhbHNv
DQorDQorQHJlZntJbnRlZ2VyMlN0cmluZ0Jhc2V9LCBAcmVme1JlYWRTdHJ9
LCBAcmVme1ZhbH0sIEByZWZ7U3RyfSxAcmVme1dyaXRlU3RyfS4NCiANCiBA
YyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogDQpAQCAtMTI0
MTMsMTQgKzEyNTE1LDQ2IEBADQogDQogQHN1YmhlYWRpbmcgRGVzY3JpcHRp
b24NCiANCitAc2FtcHtWYWx9IGNvbnZlcnRzIHRoZSBpbnRlZ2VyIG9yIHJl
YWwgbnVtYmVyIHRoYXQgaXMgcmVwcmVzZW50ZWQgYnkNCitjaGFyYWN0ZXJz
IGluIHN0cmluZyBAc2FtcHtTb3VyY2V9IGFuZCBwbGFjZXMgaXQgaW50byBA
c2FtcHt4fS4NCisNCitAc2FtcHtTb3VyY2V9IHN0cmluZyBjYW4gaGF2ZSBh
IGJhc2UgcHJlZml4LiBPcHRpb25hbCBAc2FtcHtFcnJvckNvZGV9DQord2ls
bCBiZSBzZXQgdG8gdGhlIHBvc2l0aW9uIG9mIHRoZSBmaXJzdCBjaGFyYWN0
ZXIgaWxsZWdhbCBmb3IgdGhlIHJhbmdlDQorb2YgdmFsaWQgZGlnaXRzIGZv
ciB0aGUgZ2l2ZW4gY29udmVyc2lvbiBiYXNlLCBvciB0byBhIDAgaWYgZW50
aXJlIHN0cmluZw0KK3JlcHJlc2VudHMgYSB2YWxpZCBudW1iZXIuIEluIGNh
c2UgaWxsZWdhbCBjaGFyYWN0ZXIgb2NjdXJlZCBpbg0KK0BzYW1we1NvdXJj
ZX0sIEBzYW1we3h9IHdpbGwgYmUgdW5kZWZpbmVkLg0KKw0KIEBzdWJoZWFk
aW5nIENvbmZvcm1pbmcgdG8NCiANCiBAc2FtcHtWYWx9IGlzIGEgQm9ybGFu
ZCBQYXNjYWwgZXh0ZW5zaW9uLg0KIA0KIEBzdWJoZWFkaW5nIEV4YW1wbGUN
CiANCitAZXhhbXBsZQ0KK3Byb2dyYW0gVmFsVGVzdDsNCit2YXIgeCwgZWM6
IEludGVnZXI7DQorICAgIGwgICAgOiBMb25nSW50Ow0KKyAgICByICAgIDog
UmVhbDsNCisNCitiZWdpbg0KKyAgVmFsICgnMTIzJywgeCk7ICAgICAgICAg
ICAgICAgICAgICB7IHggOj0gICAgICAgICAgICAxMjM7ICAgICAgICAgIH0N
CisgIFZhbCAoJy0xMjMnLCB4KTsgICAgICAgICAgICAgICAgICAgeyB4IDo9
ICAgICAgICAgICAtMTIzOyAgICAgICAgICB9DQorICBWYWwgKCcxMjMuNDU2
Jywgcik7ICAgICAgICAgICAgICAgIHsgciA6PSAgICAgICAgMTIzLjQ1Njsg
ICAgICAgICAgfQ0KKyAgVmFsICgnJGZmZmYnLCB4KTsgICAgICAgICAgICAg
ICAgICB7IHggOj0gICAgICAgICAgNjU1MzU7ICAgICAgICAgIH0NCisgIFZh
bCAoJyRGMDAwJywgeCk7ICAgICAgICAgICAgICAgICAgeyB4IDo9ICAgICAg
ICAgIDYxNDQwOyAgICAgICAgICB9DQorICBWYWwgKCctJGZmZmYnLCB4KTsg
ICAgICAgICAgICAgICAgIHsgeCA6PSAgICAgICAgIC02NTUzNTsgICAgICAg
ICAgfQ0KKyAgVmFsICgnMTIjMTAwJywgeCwgZWMpOyAgICAgICAgICAgICB7
IHggOj0gICAgICAgICAgICAxNDQ7IGVjIDo9IDA7IH0NCisgIFZhbCAoJy0y
IzExMTExMTExJywgeCwgZWMpOyAgICAgICAgeyB4IDo9ICAgICAgICAgICAt
MjU1OyBlYyA6PSAwOyB9DQorICB7IGhlcmUgd2UgaGF2ZSBpbnZhbGlkIGNo
YXJhY3RlciAnWCcgZm9yIGJhc2UgMTYgfQ0KKyAgVmFsICgnJGZmZmVYJywg
eCwgZWMpOyAgICAgICAgICAgICB7IHggOj0gICAgPHVuZGVmaW5lZD47IGVj
IDo9IDY7IH0NCisgIFZhbCAoJzEyIzEwMGludmFsaWQnLCB4LCBlYyk7ICAg
ICAgeyB4IDo9ICAgIDx1bmRlZmluZWQ+OyBlYyA6PSA3OyB9DQorICBWYWwg
KCczNiNKZXJ1c2FsZW0nLCBsLCBlYyk7ICAgICAgIHsgbCA6PSA1NDc1ODgy
MTE3MDkxMDsgZWMgOj0gMDsgfQ0KK2VuZC4NCitAZW5kIGV4YW1wbGUNCisN
CiBAc3ViaGVhZGluZyBTZWUgYWxzbw0KIA0KK0ByZWZ7UmVhZExufSwgQHJl
ZntSZWFkU3RyfSwgQHJlZntXcml0ZUxufSwgQHJlZntXcml0ZVN0cn0sIEBy
ZWZ7U3RyfS4NCiANCiBAYyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQogDQo=

--899744747-487299801-1061028616=:2601--


From gpc-doc-owner@gnu.de  Sun Aug 17 16:59:51 2003
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 19oP0X-0000hU-00
	for ; Sun, 17 Aug 2003 16:59:49 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id FAA26298
	for ; Sun, 17 Aug 2003 05:29:02 +0200
Date: Sun, 17 Aug 2003 05:29:02 +0200
Message-Id: <200308170329.FAA26298@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: (no subject)
To: gpc-doc@gnu.de
References: 
	
In-Reply-To: 
	
From: Frank Heckenbach 
User-Agent: semail 20030730
X-Archive-Number: 200308/2
X-Sequence-Number: 98

Mirsad Todorovac wrote:

> Here is the `Val' update.

Thanks. I've made these changes:

- s/illegal/invalid/ as I already mentioned. (It's really not a
  criminal offense to put an invalid character into a string, at
  least not yet. ;-)

- Quoted `{', `}' in the example. (I wonder how you got makeinfo to
  accept it without when you tested it.)

> I've attached also preliminary versions of Integer2StringBase[Ext]

That's nice, but actually reference.texi is only for compiler
built-ins. Other RTS things should be documented via interface
comments (and later handled using pas2texi which was discussed here
a while ago, but I haven't heard of it since then).

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Sat Mar 27 14:33:44 2004
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 1B7DwL-0007Jj-00; Sat, 27 Mar 2004 14:33:33 +0100
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id OAA13277;
	Sat, 27 Mar 2004 14:32:20 +0100
Date: Sat, 27 Mar 2004 14:32:20 +0100
Message-Id: <200403271332.OAA13277@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Mailing list problems (March 20-23)
To: gpc-announce@gnu.de, gpc-doc@gnu.de, gpc-de@gnu.de
From: Frank Heckenbach 
User-Agent: semail 20040101
X-Archive-Number: 200403/1
X-Sequence-Number: 99

Hallo,

due to a problem when installing spam and virus filters, the mailing
lists were out of order from last Saturday till Tuesday. Incoming
mails were probably dropped without notice.

If you sent any mail to the lists in this time, please check in the
archives to find out if it got through, and otherwise please resend
it.

Sorry for the inconvenience,
Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Sun Apr  4 23:26:51 2004
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 1BAF8d-00071B-00; Sun, 04 Apr 2004 23:26:43 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id XAA13666;
	Sun, 4 Apr 2004 23:25:28 +0200
Date: Sun, 4 Apr 2004 23:25:28 +0200
Message-Id: <200404042125.XAA13666@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Old mails in the archive
To: gpc-announce@gnu.de, gpc-doc@gnu.de, gpc-de@gnu.de
From: Frank Heckenbach 
User-Agent: semail 20040101
X-Archive-Number: 200404/1
X-Sequence-Number: 100

Hi,

some old mails (from the time 1999-2001) that Anja Gerwinski found
on an old server are now available in the online archives of gpc-doc
and gpc-announce. (They are numbered 0 and below, to avoid shifting
the numbers of current mails.)

Frank

-- 
Frank Heckenbach, frank@g-n-u.de
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)


From gpc-doc-owner@gnu.de  Sun May 30 19:41:58 2004
Received: from ipdial-245-238.info.com.ph ([202.163.245.238] helo=speed.info.com.ph)
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 1BUUJi-0004Vr-00
	for ; Sun, 30 May 2004 19:41:52 +0200
Received: from rmsmightbegod.glimpsebbs.net (localhost [127.0.0.1])
	by speed.info.com.ph (8.12.8/8.12.8) with ESMTP id i4V1mm7A000958
	for ; Mon, 31 May 2004 01:48:50 GMT
Received: (from nsantos@localhost)
	by rmsmightbegod.glimpsebbs.net (8.12.8/8.12.8/Submit) id i4V1mma8000957
	for gpc-doc@gnu.de; Mon, 31 May 2004 01:48:48 GMT
Date: Mon, 31 May 2004 01:48:47 +0000
From: Neil Santos 
To: gpc-doc@gnu.de
Subject: Request for doc sources
Message-ID: <20040531014847.GE682@rmsmightbegod>
Reply-To: gpc-doc@gnu.de
Mail-Followup-To: gpc-doc@gnu.de
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="Dzs2zDY0zgkG72+7"
Content-Disposition: inline
User-Agent: Mutt/1.4.2i
Organization: Disgruntled Paradigms, Inc.
X-PGP-Key: http://nsantos.f2o.org/nsantos-key.asc
X-Archive-Number: 200405/1
X-Sequence-Number: 101

--Dzs2zDY0zgkG72+7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I'd like to request that the documentation sources be put up as a
separate download from GPC's source tarball.  This way, people who
want to work on the docs (and, for any reason, can't/won't use CVS)
don't have to download the whole GPC suite.

TIA.

--=20
Political Dissident                                        Neil Santos
Free Software Advocate                      Jabber: nsantos@jabber.org

     Please avoid sending me attachments encoded in secret formatting.
            See http://www.fsf.org/philosophy/no-word-attachments.html

--Dzs2zDY0zgkG72+7
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.4 (GNU/Linux)

iEYEARECAAYFAkC6jv8ACgkQcpujh3OVmbvXTwCfePZ0sOX8jtYUrun3mxvzbu9v
/v8AnRNFIBS9R0DCZ5IY4Hb2jZlS71kv
=LC0f
-----END PGP SIGNATURE-----

--Dzs2zDY0zgkG72+7--


From gpc-doc-owner@gnu.de  Sun May 30 23:17:33 2004
Received: from smtp2.clear.net.nz ([203.97.37.27])
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 1BUXgO-0007v2-00
	for ; Sun, 30 May 2004 23:17:29 +0200
Received: from [203.167.171.5]
 (203-167-171-5.dialup.clear.net.nz [203.167.171.5])
 by smtp2.clear.net.nz (CLEAR Net Mail)
 with ESMTPA id <0HYJ00L4FPQZTN@smtp2.clear.net.nz> for gpc-doc@gnu.de; Mon,
 31 May 2004 09:16:13 +1200 (NZST)
Date: Mon, 31 May 2004 09:23:38 +1200
From: Grant Jacobs 
Subject: Re: Request for doc sources
In-reply-to: <20040531014847.GE682@rmsmightbegod>
X-Sender: biot/grant.jacobs@pop.clear.net.nz
To: gpc-doc@gnu.de
Message-id: 
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
References: <20040531014847.GE682@rmsmightbegod>
X-Archive-Number: 200405/2
X-Sequence-Number: 102


I'd second that. If it were easy enough I'd tap away as I'm 
(re)learning things, I'd poke the odd thing in myself. I don't want 
to have to fiddle around with CVS, even though I'm supposed to be 
teaching myself subversion (a CVS replacement) I barely need it as a 
one-many operation. Put it another way, if I'm going to contrib. to 
the docs if going have to be absolutely trivial.

Grant

At 1:48 AM +0000 31/5/04, Neil Santos wrote:
>I'd like to request that the documentation sources be put up as a
>separate download from GPC's source tarball.  This way, people who
>want to work on the docs (and, for any reason, can't/won't use CVS)
>don't have to download the whole GPC suite.
>
>TIA.

-- 
-------------------------------------------------------------------
Grant Jacobs Ph.D.                                     BioinfoTools
ph. +64 3 478 0095  (office, after 10am)               PO Box 6129,
or  +64 25 601 5917 (mobile)                               Dunedin,
gjacobs@bioinfotools.com                               NEW ZEALAND.
    Bioinformatics tools: deriving knowledge from biological data
Bioinformatics tools - software development - consulting - training
Check out the website for more details: http://www.bioinfotools.com

The information contained in this mail message is  confidential and
may be legally privileged.  Readers of this message who are not the
intended recipient are hereby notified that any use, dissemination,
distribution or reproduction of this message is prohibited.  If you
have received this message in error please notify the sender immed-
iately and destroy the original message.  This applies also to  any
attached documents.


From gpc-doc-owner@gnu.de  Mon May 31 22:32:42 2004
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 1BUtSY-00052e-00
	for ; Mon, 31 May 2004 22:32:38 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id WAA30929
	for ; Mon, 31 May 2004 22:30:20 +0200
Date: Mon, 31 May 2004 22:30:20 +0200
Message-Id: <200405312030.WAA30929@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: Request for doc sources
To: gpc-doc@gnu.de
References: 
	<20040531014847.GE682@rmsmightbegod>
	
In-Reply-To: 
	
From: Frank Heckenbach 
User-Agent: semail 20040101
X-Archive-Number: 200405/3
X-Sequence-Number: 103

Grant Jacobs wrote:

> I'd second that. If it were easy enough I'd tap away as I'm
> (re)learning things, I'd poke the odd thing in myself. I don't want 
> to have to fiddle around with CVS, even though I'm supposed to be 
> teaching myself subversion (a CVS replacement) I barely need it as a 
> one-many operation. Put it another way, if I'm going to contrib. to 
> the docs if going have to be absolutely trivial.

I've put an archive at . I've tried
to extract the relevant parts of GPC's Makefile (see comments at
top), hope that's enough to be usable. (All the other files are
identical to GPC's `p/doc' subdirectory.)

(BTW, where's this GPC CVS I keep hearing about? I haven't set up
one. ;-)

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Tue Jun  8 14:57:51 2004
Received: from ipdial-245-39.info.com.ph ([202.163.245.39] helo=speed.info.com.ph)
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 1BXgAg-00005C-00
	for ; Tue, 08 Jun 2004 14:57:44 +0200
Received: from rmsmightbegod.glimpsebbs.net (localhost [127.0.0.1])
	by speed.info.com.ph (8.12.8/8.12.8) with ESMTP id i58LFe0J000468
	for ; Tue, 8 Jun 2004 21:15:42 GMT
Received: (from nsantos@localhost)
	by rmsmightbegod.glimpsebbs.net (8.12.8/8.12.8/Submit) id i58LFeag000467
	for gpc-doc@gnu.de; Tue, 8 Jun 2004 21:15:40 GMT
Date: Tue, 8 Jun 2004 21:15:40 +0000
From: Neil Santos 
To: gpc-doc@gnu.de
Subject: Re: Version information
Message-ID: <20040608211539.GA398@rmsmightbegod>
Reply-To: gpc-doc@gnu.de
Mail-Followup-To: gpc-doc@gnu.de
References: <200406011309.i51D9KAA023377@rrzmx1.rz.uni-regensburg.de> <200406030152.DAA15428@goedel.fjf.gnu.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0"
Content-Disposition: inline
In-Reply-To: <200406030152.DAA15428@goedel.fjf.gnu.de>
User-Agent: Mutt/1.4.2i
Organization: Disgruntled Paradigms, Inc.
X-PGP-Key: http://nsantos.f2o.org/nsantos-key.asc
X-Archive-Number: 200406/1
X-Sequence-Number: 104

--6TrnltStXW4iwmi0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[Moved this to gpc-doc]

On 03:52 03/06/04, Frank Heckenbach wrote:

> While we're at it, could anybody please kindly update all the other
> parts of the documentation that need updating (mostly programming
> and reference)? :-)

Since I'm working on an OO project right now, I guess I have a moral
obligation to update the OO-related areas.  I'm working on some of the
OO-related Reference items (in particular, `private', `protected' and
`public'), although I can't say it's easy, considering:

	1) I have never worked with and so don't know Texinfo, and I'm
	figuring things out as I go along; and,
	2) Most of what I know about OO Pascal comes from Borland, and
	I can't exactly copy stuff from their textbooks.

Diffs to the archive you've uploaded will come in as soon as I've
made significant changes.

--=20
Political Dissident                                        Neil Santos
Free Software Advocate                      Jabber: nsantos@jabber.org

     Please avoid sending me attachments encoded in secret formatting.
            See http://www.fsf.org/philosophy/no-word-attachments.html

--6TrnltStXW4iwmi0
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.4 (GNU/Linux)

iEYEARECAAYFAkDGLHsACgkQcpujh3OVmbuuvACaA0MoVGHB18TYKl9lb7ZsxrE5
RcAAoKKkXzOLiLnlFlFC5oawaSfSiTkn
=g7xT
-----END PGP SIGNATURE-----

--6TrnltStXW4iwmi0--


From gpc-doc-owner@gnu.de  Tue Jun  8 16:12:05 2004
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 1BXhKa-0001Wz-00
	for ; Tue, 08 Jun 2004 16:12:00 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id PAA10685
	for ; Tue, 8 Jun 2004 15:34:26 +0200
Date: Tue, 8 Jun 2004 15:34:26 +0200
Message-Id: <200406081334.PAA10685@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: Version information
To: gpc-doc@gnu.de
References: 
	<200406011309.i51D9KAA023377@rrzmx1.rz.uni-regensburg.de>
	<200406030152.DAA15428@goedel.fjf.gnu.de>
	<20040608211539.GA398@rmsmightbegod>
In-Reply-To: 
	<20040608211539.GA398@rmsmightbegod>
From: Frank Heckenbach 
User-Agent: semail 20040101
X-Archive-Number: 200406/2
X-Sequence-Number: 105

Neil Santos wrote:

> Since I'm working on an OO project right now, I guess I have a moral
> obligation to update the OO-related areas.  I'm working on some of the
> OO-related Reference items (in particular, `private', `protected' and
> `public'), although I can't say it's easy, considering:
> 
> 	1) I have never worked with and so don't know Texinfo, and I'm
> 	figuring things out as I go along; and,

> 	2) Most of what I know about OO Pascal comes from Borland,

That's good since GPC's model is mostly like Borland's. (BP doesn't
have `protected' AFAIR, and there are some other GPC extensions such
as `is' and `as', but generally OOP is one the areas where BP
knowledge helps most.)

> 	and
> 	I can't exactly copy stuff from their textbooks.

No. In fact you shouldn't even look at the textbooks during the time
you write something and some time before to avoid "mental copying"
...

> Diffs to the archive you've uploaded will come in as soon as I've
> made significant changes.

Thanks.

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Sat Jun 12 19:09:41 2004
Received: from ipdial-245-4.info.com.ph ([202.163.245.4] helo=speed.info.com.ph)
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 1BZC0e-00088F-00
	for ; Sat, 12 Jun 2004 19:09:38 +0200
Received: from rmsmightbegod.glimpsebbs.net (localhost [127.0.0.1])
	by speed.info.com.ph (8.12.8/8.12.8) with ESMTP id i5D0aFO5001209
	for ; Sun, 13 Jun 2004 00:36:19 GMT
Received: (from nsantos@localhost)
	by rmsmightbegod.glimpsebbs.net (8.12.8/8.12.8/Submit) id i5D0ZxAu001208
	for gpc-doc@gnu.de; Sun, 13 Jun 2004 00:35:59 GMT
Resent-Message-Id: <200406130035.i5D0ZxAu001208@rmsmightbegod.glimpsebbs.net>
Date: Fri, 11 Jun 2004 08:51:51 +0000
From: Neil Santos 
To: Frank Heckenbach 
Subject: Re: Version information
Message-ID: <20040611085151.GA379@rmsmightbegod>
References: <200406011309.i51D9KAA023377@rrzmx1.rz.uni-regensburg.de> <200406030152.DAA15428@goedel.fjf.gnu.de> <20040608211539.GA398@rmsmightbegod> <200406081334.PAA10685@goedel.fjf.gnu.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz"
Content-Disposition: inline
In-Reply-To: <200406081334.PAA10685@goedel.fjf.gnu.de>
User-Agent: Mutt/1.4.2i
Organization: Disgruntled Paradigms, Inc.
X-PGP-Key: http://nsantos.f2o.org/nsantos-key.asc
Resent-From: nsantos@sexmagnet.com
Resent-Date: Sun, 13 Jun 2004 00:35:59 +0000
Resent-To: gpc-doc@gnu.de
X-Archive-Number: 200406/3
X-Sequence-Number: 106

--3V7upXqbjpZ4EhLz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 15:34 08/06/04, Frank Heckenbach wrote:
>=20
> > 	2) Most of what I know about OO Pascal comes from Borland,
>=20
> That's good since GPC's model is mostly like Borland's. (BP doesn't
> have `protected' AFAIR, and there are some other GPC extensions such

No; I think Delphi has it, though.

> as `is' and `as', but generally OOP is one the areas where BP
> knowledge helps most.)

Well, it's technically good as, like you've said, GPC's current object
implementation is similar to Borland's; but it's practically bad,
because we're trying to write a free manual here. ;)

> > 	and I can't exactly copy stuff from their textbooks.
>=20
> No. In fact you shouldn't even look at the textbooks during the time
> you write something and some time before to avoid "mental copying"

Yes, I know; I've read it in an FSF paper--the Coding Standard, I
believe.  I remember reading a few tips on how to go about your work,
if you *vaguely* remember reading another work, but it's of little use
for writing free manuals.

After all, the CS deals with code, and `[organizing] internally along
different lines' is something that doesn't mean much for English
sentences. :D

> > Diffs to the archive you've uploaded will come in as soon as I've
> > made significant changes.
>=20
> Thanks.

Thank me when I've sent diffs in--and not even then, since I'm merely
doing my job. :)

--=20
Political Dissident                                        Neil Santos
Free Software Advocate                      Jabber: nsantos@jabber.org

     Please avoid sending me attachments encoded in secret formatting.
            See http://www.fsf.org/philosophy/no-word-attachments.html

--3V7upXqbjpZ4EhLz
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.4 (GNU/Linux)

iEYEARECAAYFAkDJcqcACgkQcpujh3OVmbtkwACeNCWVhSX6gXLe9URjUHLJ48Mr
hVUAnRVwzyvFOxfdEDI46xiq5QqkTaQA
=x/jo
-----END PGP SIGNATURE-----

--3V7upXqbjpZ4EhLz--


From gpc-doc-owner@gnu.de  Sun Jun 13 01:04:30 2004
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 1BZHXy-0003zK-00; Sun, 13 Jun 2004 01:04:22 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id AAA16487;
	Sun, 13 Jun 2004 00:29:23 +0200
Date: Sun, 13 Jun 2004 00:29:23 +0200
Message-Id: <200406122229.AAA16487@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: Version information
To: nsantos@sexmagnet.com, gpc-doc@gnu.de
References: 
	<200406030152.DAA15428@goedel.fjf.gnu.de>
	<20040608211539.GA398@rmsmightbegod>
	<200406081334.PAA10685@goedel.fjf.gnu.de>
	<20040611085151.GA379@rmsmightbegod>
In-Reply-To: 
	<20040611085151.GA379@rmsmightbegod>
From: Frank Heckenbach 
User-Agent: semail 20040101
X-Archive-Number: 200406/4
X-Sequence-Number: 107

> After all, the CS deals with code, and `[organizing] internally along
> different lines' is something that doesn't mean much for English
> sentences. :D

I think it's a common situation with technical documentation,
whether free or proprietary. Most people who write some have read
some before.

I even think it's easier to formulate differently in language than
in programming ...

Frank

-- 
Frank Heckenbach, frank@g-n-u.de
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)


From gpc-doc-owner@gnu.de  Sun Jun 27 18:42:16 2004
Received: from [202.163.225.22] (helo=avmx.speed.info.com.ph ident=wscvwy)
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 1BecjK-0005NT-00
	for ; Sun, 27 Jun 2004 18:42:11 +0200
Received: from localhost (localhost.localdomain [127.0.0.1])
	by avmx.speed.info.com.ph (Postfix) with ESMTP id 644183941AF
	for ; Mon, 28 Jun 2004 00:41:01 +0800 (PHT)
Received: from avmx.speed.info.com.ph ([127.0.0.1])
 by localhost (avmx.speed.info.com.ph [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 00776-01 for ;
 Mon, 28 Jun 2004 00:40:58 +0800 (PHT)
Received: from email.warpspeed.com.ph (qradius3.warpspeed.com.ph [202.163.225.20])
	by avmx.speed.info.com.ph (Postfix) with ESMTP id 746FF3941AD
	for ; Mon, 28 Jun 2004 00:40:58 +0800 (PHT)
Received: from rmsmightbegod.glimpsebbs.net (ipdial-245-231.info.com.ph [202.163.245.231])
	by email.warpspeed.com.ph (Postfix) with ESMTP id 22E1B21DD03
	for ; Mon, 28 Jun 2004 00:40:56 +0800 (PHT)
From: Neil Santos 
Message-ID: <16607.28186.347598.954194@rmsmightbegod.glimpsebbs.net>
Date: Mon, 28 Jun 2004 01:02:17 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: gpc-doc@gnu.de
Subject: Anyone else working on the documentation?
X-Mailer: VM 7.18 under Emacs 21.2.2
Organization: Disgruntled Paradigms, Inc.
X-Attribution: RLS
X-PGP-Key: http://nsantos.f2o.org/nsantos-key.asc
X-Virus-Scanned: by amavisd-new at warpspeed.com.ph
X-Archive-Number: 200406/5
X-Sequence-Number: 108

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is anybody else working on the docs?  Could you let us know which
parts you're working on?

As for me, I'm working on reference.texi (the OO-related parts).

If anybody else is working on them, we really ought to communicate,
since we don't have the luxury of a CVS server (Frank: *nudge nudge*
*wink wink* *poke poke*)

That's all for today. :)

- -- 
Political Dissident                                        Neil Santos
Free Software Advocate                      Jabber: nsantos@jabber.org

     Please avoid sending me attachments encoded in secret formatting.
            See http://www.fsf.org/philosophy/no-word-attachments.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iEYEARECAAYFAkDfbhIACgkQcpujh3OVmbuvrgCgw3qyZu8YxA31cuEjsrIk5UJO
408AoJ5ZUqY2VCTs9EVW9u44Up9biwdH
=VuZR
-----END PGP SIGNATURE-----




From gpc-doc-owner@gnu.de  Sun Jun 27 19:15:21 2004
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 1BedFI-0005uz-00
	for ; Sun, 27 Jun 2004 19:15:12 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id TAA07138
	for ; Sun, 27 Jun 2004 19:11:59 +0200
Date: Sun, 27 Jun 2004 19:11:59 +0100
Message-ID: 
	<1088356319.7136.776644@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: Anyone else working on the
To: gpc-doc@gnu.de
References: 
	<16607.28186.347598.954194@rmsmightbegod.glimpsebbs.net>
In-Reply-To: 
	<16607.28186.347598.954194@rmsmightbegod.glimpsebbs.net>
From: Frank Heckenbach 
User-Agent: semail 20040101
X-Archive-Number: 200406/6
X-Sequence-Number: 109

Neil Santos wrote:

> Is anybody else working on the docs?  Could you let us know which
> parts you're working on?

(Quite unlikely, I'd guess ...)

> As for me, I'm working on reference.texi (the OO-related parts).
> 
> If anybody else is working on them, we really ought to communicate,
> since we don't have the luxury of a CVS server (Frank: *nudge nudge*
> *wink wink* *poke poke*)

No, sorry. We once tried it, but it never really worked. Actually,
to me CVS is rather uncomprehensible (and a bit too complicated ;-).
I'm having enough trouble downloading something from a public CVS
server when I have to. Add to that the complications of getting the
required versions os various tools needed for building (the
generated files are included in the source archives, but shouldn't
be in a CVS).

Besides, I don't think CVS solves any real problems here. When a
conflict arises, it will report it, but one still has to sort it out
manually. I can do the same with diffs.

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Fri Aug 20 10:37:26 2004
Received: from slip-202-135-90-238.ma.ph.prserv.net ([202.135.90.238] helo=speed.info.com.ph)
	by adele.gerwinski.de with esmtp (Exim 3.35 #1 (Debian))
	id 1By4tg-0001Ov-00
	for ; Fri, 20 Aug 2004 10:37:17 +0200
Received: from rmsmightbegod.glimpsebbs.net (localhost [127.0.0.1])
	by speed.info.com.ph (8.12.8/8.12.8) with ESMTP id i7KGwQGe003008
	for ; Fri, 20 Aug 2004 16:58:28 GMT
From: Neil Santos 
Message-ID: <16676.35937.150548.969310@rmsmightbegod.glimpsebbs.net>
Date: Thu, 19 Aug 2004 11:17:53 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: gpc-doc@gnu.de
Subject: Quick questions regarding the docs
X-Mailer: VM 7.18 under Emacs 21.2.2
Organization: Disgruntled Paradigms, Inc.
X-Attribution: RLS
X-PGP-Key: http://nsantos.f2o.org/nsantos-key.asc
X-Archive-Number: 200408/1
X-Sequence-Number: 110

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

First off, let me apologize for being gone for so long.  I've been
ABEND for quite a while, and while Real Life(tm) threatened to sue me
for negligence.  The usual bullcrap.

Anyway, I declined to follow the established semantics, as practice in
the whole of reference.texi; i.e., sticking to the uses set forth in
Texinfo's info pages.

I was wondering if I should go ahead and submit this, then work on
changing the rest of the docs, or if I should just go shove my changes
up my arse. :)

I haven't done much during my absence (just expanded private,
protected, public, and a few others, IIRC), so I hope I haven't done
much damage.

I'm planning on putting more work into the docs while I also work on
my other projects; should I go ahead with the semantic changes, or
should I just roll with what's already been done?

- -- 
Political Dissident                                        Neil Santos
Free Software Advocate                      Jabber: nsantos@jabber.org

     Please avoid sending me attachments encoded in secret formatting.
            See http://www.fsf.org/philosophy/no-word-attachments.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iEYEARECAAYFAkEkjEAACgkQcpujh3OVmbtd2QCfYhURzRxALFWkIMuwthykxTgR
bRoAoKuzLTxw8FqGbKHJa/5hgdXMYKmk
=GUyZ
-----END PGP SIGNATURE-----




From gpc-doc-owner@gnu.de  Mon Sep  6 19:37:02 2004
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 1C4NQD-000308-00
	for ; Mon, 06 Sep 2004 19:36:53 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id SAA06141
	for ; Mon, 6 Sep 2004 18:44:59 +0200
Date: Mon, 6 Sep 2004 18:44:59 +0200
Message-ID: 
	<1094489099.6139.338715@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: Quick questions regarding the docs
To: gpc-doc@gnu.de
References: 
	<16676.35937.150548.969310@rmsmightbegod.glimpsebbs.net>
In-Reply-To: 
	<16676.35937.150548.969310@rmsmightbegod.glimpsebbs.net>
From: Frank Heckenbach 
User-Agent: semail 20040101
X-Archive-Number: 200409/1
X-Sequence-Number: 111

Neil Santos wrote:

> Anyway, I declined to follow the established semantics, as practice in
> the whole of reference.texi; i.e., sticking to the uses set forth in
> Texinfo's info pages.
> 
> I was wondering if I should go ahead and submit this, then work on
> changing the rest of the docs, or if I should just go shove my changes
> up my arse. :)

Could you perhaps be somewhat more concrete? I don't really know
what you mean.

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707


From gpc-doc-owner@gnu.de  Sat Nov  6 18:52:02 2004
Received: from uucp by adele.gerwinski.de with local-rmail (Exim 3.35 #1 (Debian))
	id 1CQUiu-00025h-00; Sat, 06 Nov 2004 18:51:36 +0100
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id SAA12459;
	Sat, 6 Nov 2004 18:51:14 +0100
Date: Sat, 6 Nov 2004 18:51:14 +0100
Message-ID: 
	<1099763474.12457.844616@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: GPC web site is back
To: gpc-announce@gnu.de, gpc-doc@gnu.de
From: Frank Heckenbach 
User-Agent: semail 20041018
X-Archive-Number: 200411/1
X-Sequence-Number: 112

Hi everybody,

I am happy to announce that the GPC web site
 is back online, after several weeks of
problems on the server.

The current GPC beta release (20041017) is on the download page.
Previous alphas/betas between 2.1 and this one have been omitted
since I'd have to reconstruct them from my archives and verify them
to be trushworthy, and I don't think it's worth the effort. If there
are serious problems with 20041017, I'd rather fix them, so everyone
can ugprade.

Thanks to Eike Lange and Benedikt Wildenhain for helping set up the
server again and to G-N-U GmbH for hosting the current GPC beta
release in the meantime.

Frank

-- 
Frank Heckenbach, frank@g-n-u.de
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)


From gpc-doc-owner@gnu.de  Tue Jan 11 22:42:08 2005
Received: from [65.19.234.25] (helo=gcs4.gentrychristian.edu)
	by adele.gerwinski.de with esmtp (Exim 4.34)
	id 1CoTkE-0007K1-Dq
	for gpc-doc@gnu.de; Tue, 11 Jan 2005 22:40:07 +0100
Received: from [127.0.0.1] (gcs4.gentrychristian.edu [127.0.0.1])
	by gcs4.gentrychristian.edu (8.12.8/8.12.8) with ESMTP id j0BLdfqY028223
	for ; Tue, 11 Jan 2005 14:39:41 -0700
Message-ID: <41E4479D.5090100@montanasky.net>
Date: Tue, 11 Jan 2005 14:39:41 -0700
From: "John W. Loux" 
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: gpc-doc@gnu.de
Subject: gpc-doc
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Archive-Number: 200501/1
X-Sequence-Number: 113

subscribe gpc-doc johnloux@montanasky.net


From gpc-doc-owner@gnu.de  Tue Mar  1 12:58:50 2005
Received: from [62.23.212.56] (helo=smail3.alcatel.fr)
	by ngc224.gerwinski.de with esmtp (Exim 4.34 #1 (Debian))
	id 1D65Hk-0000tl-Sx
	for ; Tue, 01 Mar 2005 12:11:38 +0100
Received: from itmail01.netfr.alcatel.fr (itmail01.netfr.alcatel.fr [155.132.182.197])
	by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id j21BAOrH011840
	for ; Tue, 1 Mar 2005 12:10:42 +0100
Received: from Fumagalli ([151.98.40.124])
          by itmail01.netfr.alcatel.fr (Lotus Domino Release 5.0.12HF788)
          with SMTP id 2005030112101198:3192 ;
          Tue, 1 Mar 2005 12:10:11 +0100 
Message-ID: <008401c51e4c$b30cb770$7c286297@Fumagalli>
Reply-To: "Angelo FUMAGALLI" 
From: Angelo.Fumagalli@alcatel.it
To: 
Subject: subscribe gpc-doc
Date: Tue, 1 Mar 2005 11:52:01 +0100
Organization: Alcatel
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
Disposition-Notification-To: "Angelo FUMAGALLI" 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-MIMETrack: Itemize by SMTP Server on ITMAIL01/IT/ALCATEL(Release 5.0.12HF788 | September
 23, 2004) at 03/01/2005 12:10:12,
	Serialize by Router on ITMAIL01/IT/ALCATEL(Release 5.0.12HF788 | September
 23, 2004) at 03/01/2005 12:10:42,
	Serialize complete at 03/01/2005 12:10:42
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0081_01C51E55.14AF8DB0"
X-Alcanet-MTA-scanned-and-authorized: yes
X-Spam-Score: 0.3 (/)
X-Archive-Number: 200503/1
X-Sequence-Number: 114

This is a multi-part message in MIME format.

------=_NextPart_000_0081_01C51E55.14AF8DB0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset="iso-8859-1"

subscribe gpc-doc angelo.fumagalli@alcatel.it
------=_NextPart_000_0081_01C51E55.14AF8DB0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset="iso-8859-1"











subscribe gpc-doc angelo.fumagalli@alcatel.it


------=_NextPart_000_0081_01C51E55.14AF8DB0--



From gpc-doc-owner+M115@gnu.de Sat Jul 23 02:08:17 2005
Received: from [127.0.0.1] (helo=gnu.de)
	by ngc224.gerwinski.de with smtp (Exim 4.50 #1 (Debian))
	id 1Dw7Yb-0000Go-2W; Sat, 23 Jul 2005 02:07:57 +0200
Received: from uucp by ngc224.gerwinski.de with local-rmail (Exim 4.50 #1 (Debian))
	id 1Dw7YL-0000FY-3s; Sat, 23 Jul 2005 02:07:41 +0200
Received: from goedel.fjf.gnu.de (localhost [127.0.0.1])
	by goedel.fjf.gnu.de (8.8.8/8.8.8) with ESMTP id CAA14091;
	Sat, 23 Jul 2005 02:05:26 +0200
Date: Sat, 23 Jul 2005 02:05:26 +0200
Message-ID: 
	<1122077126.14089.399108@goedel.fjf.gnu.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii
Subject: Mailing list archive is back
To: gpc-announce@gnu.de, gpc-doc@gnu.de
From: Frank Heckenbach 
User-Agent: semail 20050409
Precedence: bulk
Sender: gpc-doc-owner@gnu.de

After some time of problems the mailing list archives are back at
their usual places:

http://www.gnu-pascal.de/crystal/gpc/en/
http://www.gnu-pascal.de/crystal/gpc-announce/en/
http://www.gnu-pascal.de/crystal/gpc-doc/en/

The full GPC web site will be restored next week I hope.

Frank

-- 
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE  D101 CD02 4C9D 0FE0 E5E8



From gpc-doc-owner+M116@gnu.de Sat Feb 20 05:33:44 2010
Received: from localhost ([127.0.0.1] helo=gnu.de)
	by ngc224.gerwinski.de with smtp (Exim 4.50 #1 (Debian))
	id 1Nih1O-0002xw-Oi; Sat, 20 Feb 2010 05:32:50 +0100
Received: from mail-pw0-f45.google.com ([209.85.160.45])
	by ngc224.gerwinski.de with esmtp (Exim 4.50 #1 (Debian))
	id 1NigyR-0002pb-8v; Sat, 20 Feb 2010 05:29:55 +0100
Received: by pwi4 with SMTP id 4so730490pwi.32
        for ; Fri, 19 Feb 2010 20:29:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:date:message-id:subject
         :from:to:cc:content-type;
        bh=dlF/L6mMhiebgSBCmy+wfpTv/WxJwVCr4zIVD/YrJSQ=;
        b=lQKRGm4pXs8TLCLF/zlSuUQ8TdMjUVV6u4lbfkh8hj3br+Xv8QEsXW84DJQ+8pDops
         P7YczYWminzuNKSpUcsFYTlBAB8W2p6BfEBbi3jRiWOpdXelNoOiilhT35ZbfN5mfHhj
         NnDf63G8mW4Jnoqvbmf1NKnODxkNEZK6Jhw1Q=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:cc:content-type;
        b=p16uw83LojQwHP1yd3Qen2m3LiV3fTCOF/9QfbAoOa3+HH2Ee2GRYIIEDEp5lglOCM
         93TEswhML198yzI94rXgj/IxHw/FV3fI2cj7OGgE7m999qalh4VoLN7q/l8O1lzVzymu
         Vimimb24gDlxpD9Ie2JksZR3xVm/oCW0mx3KI=
MIME-Version: 1.0
Received: by 10.141.2.4 with SMTP id e4mr7724852rvi.192.1266640179550; Fri, 19 
	Feb 2010 20:29:39 -0800 (PST)
Date: Sat, 20 Feb 2010 09:59:39 +0530
Message-ID: <92235e271002192029w760bfa5dnc26def29b5fc6047@mail.gmail.com>
Subject: GPC
From: kriti panday 
To: gpc-doc-owner@gnu.de
Cc: gpc-doc@gnu.de
Content-Type: multipart/alternative; boundary=000e0cd1191ef5da15048000a5a3
X-Spam-Score: 0.1 (/)
Precedence: bulk
Sender: gpc-doc-owner@gnu.de

--000e0cd1191ef5da15048000a5a3
Content-Type: text/plain; charset=ISO-8859-1

Hello,

How can we install GPC on linux(Red Hat).
How can i get assistance for it.
Urgent

Thanx
kriti

--000e0cd1191ef5da15048000a5a3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hello,


=A0


How can we install GPC on linux(Red Hat).


How can i get assistance for it.=20

Urgent


=A0


Thanx


kriti


=A0


--000e0cd1191ef5da15048000a5a3--



From gpc-doc-owner+M117@gnu.de Tue Feb 23 06:45:56 2010
Received: from localhost ([127.0.0.1] helo=gnu.de)
	by ngc224.gerwinski.de with smtp (Exim 4.50 #1 (Debian))
	id 1NjnZx-0003fo-1D; Tue, 23 Feb 2010 06:45:05 +0100
Received: from mail-pv0-f173.google.com ([74.125.83.173])
	by ngc224.gerwinski.de with esmtp (Exim 4.50 #1 (Debian))
	id 1NjnZi-0003en-VV
	for ; Tue, 23 Feb 2010 06:45:03 +0100
Received: by pvg13 with SMTP id 13so229964pvg.32
        for ; Mon, 22 Feb 2010 21:44:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:date:message-id:subject
         :from:to:content-type;
        bh=qoov867IrPBYaqsTHlVe5kzHwf/cVgQA0V9GKkcUlI4=;
        b=UZ3wX7JS4kugW6QeRwjoQYxW9sfgr/kg7oOwk4XNsoZ8/7DCGdK3NAschHuvLlm076
         bZUItOSnYPHvrg88NYpgf1INls+pheY0JGNpf+ZQQUzvOkBvivgieor0BuEPVZ5IFhSU
         yjB8FMOnUm7N0ffYBH0tcec6rcb0nw1aNeHQQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=k/ltA+ubADJNFToxdq16mLN0Ou/xQcawZkvOyosXTqcSz04Sbj9JGBMRX/CkBAqujV
         DDIYP2P6xn5eFIP7YTOQw1QrvJG+TEGPtlti6RzqLFBoEPKvip6x+CxIfQimO9tXcXI2
         Fu5NC2j7Kyb5Yt1dgfYj3yVUjtjd6CQTxVo4g=
MIME-Version: 1.0
Received: by 10.141.124.21 with SMTP id b21mr9101123rvn.23.1266903884348; Mon, 
	22 Feb 2010 21:44:44 -0800 (PST)
Date: Tue, 23 Feb 2010 11:14:44 +0530
Message-ID: <92235e271002222144i3e25c13byab0e1dffefaa3bf3@mail.gmail.com>
Subject: GPC
From: kriti panday 
To: gpc-doc@gnu.de
Content-Type: multipart/alternative; boundary=0003255652b2fdbe8704803e0b5b
X-Spam-Score: -1.8 (-)
Precedence: bulk
Sender: gpc-doc-owner@gnu.de

--0003255652b2fdbe8704803e0b5b
Content-Type: text/plain; charset=ISO-8859-1

Please tell me how can we install gnu pascal compiler on unix.

regards
Kriti

--0003255652b2fdbe8704803e0b5b
Content-Type: text/html; charset=ISO-8859-1

Please tell me how can we install gnu pascal compiler on unix.

regards
Kriti


--0003255652b2fdbe8704803e0b5b--



From gpc-doc-owner+M118@gnu.de Tue Feb 23 07:54:47 2010
Received: from localhost ([127.0.0.1] helo=gnu.de)
	by ngc224.gerwinski.de with smtp (Exim 4.50 #1 (Debian))
	id 1Njoed-0005TQ-NF; Tue, 23 Feb 2010 07:53:59 +0100
Received: from mail-pv0-f173.google.com ([74.125.83.173])
	by ngc224.gerwinski.de with esmtp (Exim 4.50 #1 (Debian))
	id 1NjoeK-0005SR-LV
	for ; Tue, 23 Feb 2010 07:53:55 +0100
Received: by pvg13 with SMTP id 13so237384pvg.32
        for ; Mon, 22 Feb 2010 22:53:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:date:message-id:subject
         :from:to:content-type;
        bh=QNPaO0yU41tp3abbyueKvIihVv3DvkSii2UCEgqQZeg=;
        b=i87d/H+mNQv1EJMHpWGIkZ5TpieI/GHAtQPA0kxZIuMumdFZFH2Iqgf5zjKM9G+1Jv
         MFlzZp0G/AyWJiMLbqPGo24wIJyzJyYqx7auVjFPuQvKYBFTrpH84sbnJZdRDxdYnWnz
         Wb2vpoZSOwVdEFUEFdu3lKuXW6rphW4rWKqcc=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=ovbbn3g5JX679UlGEx9O3L/ovxz4zPeq5PAfl8oA+s6JZVgkltX9Ncut8vILC2vlBO
         HPmVaZA6VJWvwXJAFiNM4/eNmfOX9W6Wmpc1aOn3+kVIf2u9CWQErOG+LIIYllIFk0Ln
         t8glFUjZUeF5LJTLa2eaOfS6EoYu7oLlc1qtM=
MIME-Version: 1.0
Received: by 10.140.57.4 with SMTP id f4mr1021517rva.222.1266908014042; Mon, 
	22 Feb 2010 22:53:34 -0800 (PST)
Date: Tue, 23 Feb 2010 12:23:34 +0530
Message-ID: <92235e271002222253r37cae2d2t3612809f322496dd@mail.gmail.com>
Subject: gpc installation support
From: kriti panday 
To: gpc-doc@gnu.de
Content-Type: multipart/alternative; boundary=001636b2b01f23dd6304803f02ce
X-Spam-Score: -2.7 (--)
Precedence: bulk
Sender: gpc-doc-owner@gnu.de

--001636b2b01f23dd6304803f02ce
Content-Type: text/plain; charset=ISO-8859-1

HELLO
Please tell me how can i get support for gpc installation.To which mail ID
,i will send my question.
Please support me.Tell me the procedure for GPC installation on Unix.

Thanx

--001636b2b01f23dd6304803f02ce
Content-Type: text/html; charset=ISO-8859-1

HELLO
Please tell me how can i get support for gpc installation.To which mail ID ,i will send my question.
Please support me.Tell me the procedure for GPC installation on Unix.

Thanx

--001636b2b01f23dd6304803f02ce--



From gpc-doc-owner+M119@gnu.de Tue Feb 23 11:56:07 2010
Received: from localhost ([127.0.0.1] helo=gnu.de)
	by ngc224.gerwinski.de with smtp (Exim 4.50 #1 (Debian))
	id 1NjsQD-00052j-Ry; Tue, 23 Feb 2010 11:55:21 +0100
Received: from smtp-out.vodafone.nl ([195.232.199.126] helo=smtp.vodafone.nl)
	by ngc224.gerwinski.de with esmtp (Exim 4.50 #1 (Debian))
	id 1NjsQ4-00051q-LK
	for ; Tue, 23 Feb 2010 11:55:20 +0100
Received: from conversion-daemon.vfnlw43s.vfnl.dc-ratingen.de by
 vfnlw43s.vfnl.dc-ratingen.de
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0KYA00001IXS5A00@vfnlw43s.vfnl.dc-ratingen.de>
 (original mail from gpc@microbizz.nl); Tue, 23 Feb 2010 11:49:54 +0100 (MET)
Received: from [77.211.85.19] by vfnlw43s.vfnl.dc-ratingen.de
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPA id <0KYA00H2HJF14O30@vfnlw43s.vfnl.dc-ratingen.de>; Tue,
 23 Feb 2010 11:49:54 +0100 (MET)
Date: Tue, 23 Feb 2010 11:49:49 +0100
From: Adriaan van Os 
Subject: Re: gpc installation support
In-reply-to: <92235e271002222253r37cae2d2t3612809f322496dd@mail.gmail.com>
To: gpc@gnu.de, gpc-doc@gnu.de
Message-id: <4B83B2CD.8070201@microbizz.nl>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <92235e271002222253r37cae2d2t3612809f322496dd@mail.gmail.com>
User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516)
X-Spam-Score: 0.1 (/)
Precedence: bulk
Sender: gpc-doc-owner@gnu.de

kriti panday wrote:
> HELLO
> Please tell me how can i get support for gpc installation.To which mail 
> ID ,i will send my question.
> Please support me.Tell me the procedure for GPC installation on Unix.

More info here 

Regards,

Adriaan van Os



From gpc-doc-owner+M120@gnu.de Tue Feb 23 11:57:43 2010
Received: from localhost ([127.0.0.1] helo=gnu.de)
	by ngc224.gerwinski.de with smtp (Exim 4.50 #1 (Debian))
	id 1NjsRn-00058X-QA; Tue, 23 Feb 2010 11:56:59 +0100
Received: from amazone1.ujf-grenoble.fr ([193.54.238.254])
	by ngc224.gerwinski.de with esmtp (Exim 4.50 #1 (Debian))
	id 1NjsRe-00057R-Po
	for ; Tue, 23 Feb 2010 11:56:58 +0100
Received: from tana3.ujf-grenoble.fr (tana3.ujf-grenoble.fr [152.77.18.201])
	by amazone1.ujf-grenoble.fr (8.13.7/8.13.7/Configured  by JE 21 07 2006) with ESMTP id o1NAIIf9046465;
	Tue, 23 Feb 2010 11:18:18 +0100 (CET)
Received: from localhost (unknown [127.0.0.1])
	by tana3.ujf-grenoble.fr (Postfix) with ESMTP id 44F505C03;
	Tue, 23 Feb 2010 11:18:18 +0100 (CET)
X-UJF-AV: Scanned on tana3.ujf-grenoble.fr
Received: from tibre3.ujf-grenoble.fr (tibre3.ujf-grenoble.fr [152.77.24.147])
	by tana3.ujf-grenoble.fr (Postfix) with ESMTP id 2521A5C21;
	Tue, 23 Feb 2010 11:18:18 +0100 (CET)
Received: from [152.77.233.127] (lombarma.vpn.ujf-grenoble.fr [152.77.233.127])
	by tibre3.ujf-grenoble.fr (8.14.3/8.14.3/SyS-1.10) with ESMTP id o1NAIFO0098256;
	Tue, 23 Feb 2010 11:18:18 +0100 (CET)
	(envelope-from Maurice.Lombardi@ujf-grenoble.fr)
Message-ID: <4B83AB6B.9090604@ujf-grenoble.fr>
Date: Tue, 23 Feb 2010 11:18:19 +0100
From: Maurice Lombardi 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: gpc , gpc-doc@gnu.de
Subject: Re: gpc installation support
References: <92235e271002222253r37cae2d2t3612809f322496dd@mail.gmail.com>
In-Reply-To: <92235e271002222253r37cae2d2t3612809f322496dd@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by amazone1.ujf-grenoble.fr id o1NAIIf9046465
X-Spam-Score: 0.0 (/)
Precedence: bulk
Sender: gpc-doc-owner@gnu.de

kriti panday a =E9crit :
> HELLO
> Please tell me how can i get support for gpc installation.To which mail=
=20
> ID ,i will send my question.
> Please support me.Tell me the procedure for GPC installation on Unix.

send mail to the gpc list, not to gpc-doc which is specialized and=20
pretty dead

download the latest gpc snapshot

http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20070904.tar.bz2

and gcc sources for backend (3.4.x and 4.1.x are fine)

The instructions are in p/INSTALL in the gpc snapshot: in Unix better=20
compile the compiler than install binaries.

There has been posted in this list a script to automate the building,
but I never used it. Maybe the author will give the reference.

Maurice

--=20
        Maurice Lombardi
Laboratoire de  Spectrometrie Physique,
Universite Joseph Fourier de Grenoble, BP87
38402 Saint Martin d'Heres Cedex     FRANCE
Tel: 33 (0)4 76 51 47 51
Fax: 33 (0)4 76 63 54 95
mailto:Maurice.Lombardi@ujf-grenoble.fr