Re: lynx-dev Can you help me please (fwd)

[Foteos Macrides]

Philip Webb <address@hidden> wrote:
>980510 FM wrote concerning TD's handling of the following problem:
>>>   extern int bzero(); 
>>>   .................^ 
>>>   %CC-W-TOOFEWACTUALS, Too few actual parameters in macro call. 
>>>   at line number 292 in file 
>>>   DKA200:[LYNX.LYNX2-8.WWW.LIBRARY.IMPLEMENTATION]TCP.H;1
>> This was explained in the PROBLEMS file through v2.7.2,
>> with emphasis in the INTALLATION file that VMSers read it.
>> there are extensive comments in the for-VMS-with-MultiNet sections of tcp.h
>> to guide people in acting on what is explained in the PROBLEMS file.
>> Al, at my request, has included a prominent entry for this in his VFAQ.
>> -- remainder snipped --
> 
>whether or not this is fair, it's not very accurate.
> 
>PROBLEMS 2-7 has the following paragraph:
> 
>  On VMS, Lynx & other TCP-IP software, have been experiencing
>  chronic problems of incompatibilites between DECC and MultiNet headers
>  whenever new versions of either DECC or MultiNet are released.
>  The Lynx build procedure for VMS & a maze of spaghetti #ifdef-ing in tcp.h
>  of the libwww-FM had previously been successful in dealing with this problem
>  across all versions of MultiNet & of DECC, VAXC & Pat Rankin's VMS port
>  of GNUC, but are now not 100% successful.  If you get compiler messages
>  about "struct timeval timeout" having no linkage, add this immediately
>  below the inclusion of ioctl.h for MultiNet in tcp.h:
>  
>    [...]
>    #include "multinet_root:[multinet.include.sys]ioctl.h"
>    struct timeval {
>        long tv_sec;                /* seconds since Jan. 1, 1970 */
>        long tv_usec;                /* microseconds */
>    };
>    [...]
>    
>  For the most current versions of MultiNet,
>  you can modify tcp.h to use the DECC socket and related headers.
> 
>there is nothing here which relates to the compile problem in question,
>except the reference to  tcp.h ; this PROBLEMS paragraph is very cryptic
>& would do nothing to help ordinary users solve their particular problem:
>it looks as if it needs a thorough update by a VMSer.
> 
>i see nothing in INSTALLATION 2-7 relating to this, let alone emphasis.
> 
> tcp.h  is not to be found as a separate file in the 2-7 package
>& there is nothing in PROBLEMS or INSTALLATION to tell users
>where to find it, so that they can insert whatever fixes are called for.
> 
>`Al's Picks' has an entry for the problem mentioned in PROBLEMS,
>but it simply refers readers to an URL `PROBLEMS', which is "not found",
>ie  www.slcc.edu/lynx/fote/lynx2-7-1/PROBLEMS .
> 
>i don't believe it's fair to expect any co-ordinator to keep in mind
>all the oddities of all the platforms Lynx has been ported to;
>the co-ordinator must be able to rely on communal expertise
>& currently VMS seems not to be well represented among lynx-devers.

        We each have to judge for ourselves what is "fair", we each have
to judge for ourselves what are "reasonable" expectations, and we each
have our own set of *actual* expectations based on our accummulated set
of experiences and observations about various people.  For example,
despite your recent post about bugtrap not considering the latest
versions of Lynx, and your citing a URL which clearly indicates that
the lynx-dev discussions to which I referred occurred after release of
v2.7.1, I am not personally surprised that you read and cited from the
v2.7 PROBLEMS file (which is not to say that the v2.7.1 and v2.7.2
PROBLEMS files do not still have lots of room for improvement).

        You were subscribed and "participating" on this list when those
discusssions/explanations were posted, but I would personally consider
it unreasonable to expect that you (or Henry, for example) grasp the
content of discussions about MultiNet having a number of unprototyped
or variably prototyped functions or macros across versions of its
libraries, which cause problems with various versions of VMS compilers.
But since my posts were directed toward TD, I think it's not unreasonable
to have expected that he pay attention to them.  Bear in mind that I
stepped down as coordinator upon release of v2.6, and that the "official"
development code set which was finally released as v2.8 had been about
two years in the making.  The v2.7, v2.7.1, and v2.7.2 releases were all
of purely personal code, being made available to the "official"
coordinators should they or anyone else find it useful, but ended up
as "official" releases for a variety of unfortunate reasons.

        More importantly, I do not think it is unreasoneable to expect
(though it may be unrealistic) that someone who has at this point spent
close to two years purportedly cleaning up and making the Lynx code more
portable across the supported platforms, and has made a large number of
changes in tcp.h toward that end, be aware of this in the v2.8 tcp.h:

[...]
#ifdef MULTINET  /* Include from standard Multinet directories */
/*
**  Delete any of these multinet_foo() and associated prototypes
**  as MultiNet adds them to its socket library headers.  You'll
**  get compiler warnings about them, due the absence of arguments
**  in the generic prototyping here, and the warnings will include
**  the names of the functions whose prototype entries can be
**  deleted here. - FM
*/
extern int multinet_accept();
extern int multinet_bind();
extern int bzero();
extern int multinet_connect();
extern int multinet_gethostname();
extern int multinet_getsockname();
extern unsigned short multinet_htons(unsigned short __val);
extern unsigned short multinet_ntohs(unsigned short __val);
extern int multinet_listen();
extern int multinet_select();
extern int multinet_socket();
extern char *vms_errno_string();
[...]

which he and Klaus incorporated from my "personal, but unfortunately
three times officially released" code sets.

        I do not think that this, or its implications for those who are
still critically dependent on Lynx, are a laughing matter, or that the
quality of anyone's sense of humor is a relevant consideration.  But
of course a large part of the Lynx usership is not critically dependent
on it, and could just walk away if becomes unviable (perhaps to care for
a sick parent :).

                                        Fote
-- 
Foteos Macrides