lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

lynx-dev Re: LYNX-DEV lynx_w32.zip feedback


From: Foteos Macrides
Subject: lynx-dev Re: LYNX-DEV lynx_w32.zip feedback
Date: Wed, 15 Apr 1998 14:55:06 -0400

Wayne Buttles <address@hidden> wrote:
On Tue, 14 Apr 1998, Foteos Macrides wrote:
>>[...] 
>> I don't know if this problem is fixed, but the trace log feature isn't
>> working properly for me.
> 
>No, it doesn't work yet.  I have looked at it since but haven't figured it
>out.  I haven't given up yet, but i'm still nursing my forehead from the
>first attempt. 

        Is this a new problem?  I distictly remember Doug recommending to
someone to use trace file logging as the default, and thus assuming that
the redirection of stderr via an equality statement gimmick was OK for the
DOS/WIN.NT ports as well.

        I don't want to get into the thread that's developed, because I've
posted this numeous times before,  but I don't see how the W32 binary can
be used as a "production" utility by "general users" (which includes me,
now :) without the trace file log feature working, so I'll summarize for
your benefit.

        I initially did it with freopen(), which is supposedly the function
intended for redirection of stdfoos, and it worked fine on VMS, but on Unix
the redirection inappropriately was extending to subprocesses and on exit
from Lynx.  It's possible that freopen() would work sanely for DOS/WIN/NT,
as for VMS.  Be that as it may, when the problem with freopen() on Unix
became apparent, Laura tried redirection via an equality statement and
claimed it worked fine on Unix.  I confirmed that for the Unix flavors to
which I had access, and found it worked on VMS as well.  That was intended
to be temporary, and the v2.7.2 code was set up for doing it "right"
without freopen, someday, which would involve modifying every trace clause
in every module of the code.  The mod would be to set up a CTRACE define
(that would be the same string as in current libwww code) for passing the
message to a function which checks globals for whether trace mode is on
and then if logging to a file is on.  If both, the message is sent to the
file's descriptor.  If not, but trace is on, the message is sent to stderr.
Otherwise, nothing is done.  No redirection is done at all.  The v2.7.2
code had all the appropriate globals established, and it was "simply" a
matter of next setting up the defined function and changing the zillions
of trace clauses to CTRACE(message).

        The v2.7.2 code uses both fflushes and closing/reopening of the
trace log file to ensure everything has been written to it when the ';'
command for viewing it is issued.  It also blocks the sleeps appropriately.
That all should be in the v2.8 code as well (Klaus incorporated it).

 
>>         I'm also unclear from the sendmail.txt file how to set that up.
>> I have a POP3 account set up for access via modem with email address
>> address@hidden so that's obviously what should be in the -f
>> field, but I'm unsure what to put in the other fields.
> 
>Oh my, the SYSTEM_MAIL settings were split up.  I guess the proper
>settings now would be: 
> 
>SYSTEM_MAIL:sendmail
>SYSTEM_MAIL_FLAGS:-f address@hidden -h gte.net -r smtp.gte.net -m SMTP

        There's also the issue of authentication and use of Virtual Key. 
(sigh...)


>There is still a dev-wide CC problem at the moment that hasn't been
>resolved.  I haven't had time to look into it.  CCs just don't go. 

        I thought, from earlier posts, that this was just a problem of v2.8
mods having created a situation in which a blank line is being inserted, so
the CCs end up being treated as part of the body rather than as headers.  If
so, that should be simple to track down and fix.  ;( but if not... );


                                Fote
--
Foteos Macrides (address@hidden during April, '98)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]