A few observations from trying out gpc (Linux).
1. --interface-only -c doesn't (always) produce a .o as the docs say, but rather only a .gpi (and a .gpm in the case of modules), at least in my case. 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.
2. The blocksize parameter to reset() appears not to be optional (as the doc says it is) 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.
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? (that's new as in, in the last 10 years!) There is no info. in the doc.: both are "under construction".
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.
5. The index on the left of the PDF format seems to always "point" to immediately _after_ the item, rather than to the item (minor quibble).
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...
Where is the original (text) document format? Is it the HTML format? I might try poke the odd bit in myself.
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.
Really the implementors ought to be using something like HeaderDoc or whatever and write these descriptions as they code... just a thought...
Grant