Re: LYNX-DEV patch for devel code on VMS

[Foteos Macrides]

"T.E.Dickey" <address@hidden>  wrote:
>> - $ if f$trnlnm("SYS").eqs."" then define sys sys$library:
>this was needed afaik (see below)
>
>> *** lynx2-7-1/WWW/Library/Implementation/tcp.h_ori   Thu Sep 11 20:18:32 1997
>> --- lynx2-7-1/WWW/Library/Implementation/tcp.h       Tue Sep 23 16:29:37 1997
>> ***************
>> *** 67,72 ****
>> --- 67,73 ----
>>   
>>   #include <sys/types.h>
>--------------here, for instance.
>   
>> + #ifndef VMS
>is this necessary? (all of this chain of ifdef's is inactive for VMS)
>
>>   #if HAVE_DIRENT_H
>>   # include <dirent.h>
>>   # define D_NAMLEN(dirent) strlen((dirent)->d_name)
>> ***************
>> *** 85,90 ****
>> --- 86,92 ----
>>   #  include <ndir.h>
>>   # endif
>>   #endif
>> + #endif /* !VMS */

        You were counting on #if HAVE_DIRENT_H to make it inactive
for VMS, but in fact you have an #else in that chain for then defining
STRUCT_DIRENT to struct direct and other stuff also inappropriate for
VMS.  I long ago added a struct dirent for VMS in HTVMSUtils.c and
defined STRUCT_DIRENT to struct dirent there for use with a number
of Unix-emulation functions in that module.  So I got a compiler
redefinition warning, and was concerned that the emulation functions
might be messed up.

        Current VMS compilers will treat <sys/foo.h> as <foo.h>, so
I missed the problem of your having added an #include <sys/types.h>
higher up in tcp.h.  I'm not sure why you did that, because further
down in tcp.h there is spaghetti #ifdef'ing for including types.h
headers from various places and in appropriate orders.  That's
particularly important for VMS, although at this point it's impossible
to get perfect with just #ifdef'ing across all version of MultiNet
and DECC, VAXC or GNUC compilers (so the stuff in PROBLEMS will still
apply to the devel code as things presently stand, i.e., if a VMSer
doesn't get involved with adding the equivalent of autoconf for VMS).

        It's a bad idea to do it externally via a logical definition
for SYS, and only if one doesn't exist.  For all you know there's a
pre-existing logical defined to a file with information about the system,
so users can do  lynx sys  if it's a text/html file, or  most sys  if
it's text/plain (and only those who still don't understand the important
differences between a hypertext browser and file viewer would use lynx
in preference to most for a text/plain file :).  Thus far, the Lynx
code has followed the principle of setting prefixed (LYNX_foo) logicals,
(if they're not the standard ones for proxying or accessing a news
server) with documentation about all of them.


>> ! PUBLIC int UCGetcharset_byMIMEname PARAMS((char * UC_MIMEcharset));
>> ! PUBLIC int UCGetcharset_byLYNXname PARAMS((char * UC_LYNXcharset));
>>   #endif /* NOTDEFINED */
>>   
>>   PUBLIC int UCTransUniChar ARGS2(
>> --- 882,889 ----
>>    *  OK now, finally, some stuff that is more specifically for Lynx: - KW
>>    */
>>   #ifdef NOTDEFINED
>> ! PUBLIC int UCGetcharset_byMIMEname PARAMS((CONST char * UC_MIMEcharset));
>> ! PUBLIC int UCGetcharset_byLYNXname PARAMS((CONST char * UC_LYNXcharset));
>>   #endif /* NOTDEFINED */
>this is ifdef'd out, and probably doesn't need to be changed.

        I don't know what plans Klaus has for the chartrans enhancements,
and whether that's a marker for planned functions.  If so, they would need
the CONST.  The chartrans stuff was started long, long ago, during Lynx2-5FM
development, as was the external style sheet support.  They were the top
priorities upon release of v2.6 -- on Sept. 2, 1996 -- more than a year
ago!  I had stepped down from the coordinator role with that release, but
ended up putting out v2.7 on Feb. 15, 1997 based on the "keep mods besides
external style sheet support fully ported to both Unix and VMS and at
production quality ASAP" side-project which Hiram and I had taken on.
The currently active developers took charge upon that release, but
I ended up putting out v2.7.1 on April 4, 1997, based on purely personal
mods, because it was "time for another release", and the devel code was
far from ready for a release.  Yet another 6 months have passed, the
longest period between releases in Lynx's history, but the external style
sheet support is still "utterly alpha", and works, perhaps, only on linux,
and the chartrans mods are still beta (EXP_CHARTRANS), with anything that
comes up, or just busy work if nothing comes up, being done instead of
bringing the chartrans mods to true production quality.  And there's
still no clear indication of when a release might be forthcoming, or
clear definition of priorities in the devel code.

        When it appeared that Klaus had dropped out without explanation
and for so long that we had to assume for good, I stopped waiting for
another VMSer to get involved actively with Lynx development, and ported
the chartrans stuff to VMS in the fotemods so I could work on it
substantively and then passes that back to the devel code.  Klaus came
back, claims he's going to finish up the chartrans enhancements, but
doesn't, nor even include the "better than nothing, for now," handling
of attribute values.   It bugs me to now have that in the fotemods, but
not production quality, and still no idea what Klaus intends to do
about it, or when!

        Due to the CERT advisory, people are using the fotemods as
if that were "FM development code" --  at or close to production
quality ASAP.   That bugs me too, and as a self-proclaimed professional,
perhaps you have enough "context" here to understand why (although
nobody, except perhaps at SCO, works on Lynx in a "professional"
capacity :).


Klaus Weide <address@hidden> wrote:
>On Tue, 23 Sep 1997, Foteos Macrides wrote:
>[...]
>>      Also note that the .com and .mms files still have not been
>> modified to include the new devel .c modules, and I haven't tried
>> to build or use those on VMS.
>
>Which new .c modules do you mean?  I can think only of chartrans, and
>LYExtern.c, and the RP stuff.

and "T.E.Dickey" <address@hidden> wrote:
>> >    Also note that the .com and .mms files still have not been
>> > modified to include the new devel .c modules, and I haven't tried
>> > to build or use those on VMS.
>> 
>> Which new .c modules do you mean?  I can think only of chartrans, and
>> LYExtern.c, and the RP stuff.
>nor I - perhaps a list would help.

        The descrip.mms files are the homologs of makefiles, but for
MMS or MMK, which are the homolog of make.  The build.com and libmake.com
do the equivalent of a clean make.   Whenever modules get added to the
appropriate makefiles, if they are not also added to the appropriate .mms
and .com files, they won't get built on VMS.  I added .com but not .mms
files for the chartrans on VMS.  That kind of thing ideally should be
done by any VMSer who becomes a "currently active Lynx developer".  But
a list of what the currently active Lynx developers have added could be
generated easily by themselves (and I still don't know why someone
with 13 years of experience developing on VMS would need that help :).

        I'm not trying to insult anyone, but I do feel bad about the
situation on behalf the a large number of Lynx users at sites which
need a "release" for upgrades.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;