lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev lynx2.8.3pre.1 (SOURCE_CACHE!=NONE problem)


From: Klaus Weide
Subject: Re: lynx-dev lynx2.8.3pre.1 (SOURCE_CACHE!=NONE problem)
Date: Mon, 3 Apr 2000 16:03:13 -0500 (CDT)

On Sat, 1 Apr 2000, Leonid Pauzner wrote:

> I confirm the problem previously reported by Vlad:
> 
> If you try any html document with pre.1 and SOURCE_CACHE enabled,
> switch to source mode and than switch back (press "\" twice)
> you will see the second reloading flash source cache.

I don't see that the cache is not used in switching back in the trace
lines below. They rather seem to show the opposite.

You may say it is being flashed or flushed or regenerated, in some meaning
of the words, but that's not really what matters.

> (to see this for local files try compiling with -DDEBUG_SOURCE_CACHE).

If you want to see what happens in the normal case, i.e., without
DEBUG_SOURCE_CACHE, then compile without -DDEBUG_SOURCE_CACHE.
Defining DEBUG_SOURCE_CACHE changes what's happening (it is rather
badly named for what it does).

Your traces below must have been made with DEBUG_SOURCE_CACHE defined.
I assume the first "SourceCache: Reparsing" message in each case is
for going to source view, the second for returning frrom source view
to normal mode.

> I made a trace log, grep "Cache" is listed below:
> ================================================
> 
> SourceCache: Reparsing from memory chunk 227680
> SourceCache: Reparsing from memory chunk 227680

This shows that returning from source mode takes the data, again,
from the cache.  There are no messages from HTLoadFile and its
auxiliary functions that would show that a new copy is fetched
from the original location.  (Well they wouldn't show up in your grep
output anyway, but I assume they aren't in the full Lynx.trace either.)

> SourceCacheWriter: If successful, will replace memory chunk 227680
> SourceCacheWriter: Caching source for URL 
> file://localhost/c:/tools/lynx/lynx_help/lynx_help_main.html in memory chunk 
> 2365c8
> StreamStack: Returning "PassThruCache"
> SourceCacheWriter: Removing previous memory chunk 227680
> SourceCacheWriter: Committing memory chunk 2365c8 for URL 
> file://localhost/c:/tools/lynx/lynx_help/lynx_help_main.html to anchor

That's just a roundabout way of copying the data around, from the old
chunk to a new chunk, as a side effect of parsing-as-HTML.  Yes, a new
cache chunk is generated, and at the end replaces the old one, but the
contents come from the old cache chunk.

This just happens with DEBUG_SOURCE_CACHE, because DEBUG_SOURCE_CACHE
means "cache everything that comes through as to-be-parsed HTML,
regardless of origin", so contents from cache gets re-cached, too.
I didn't invent DEBUG_SOURCE_CACHE, I'm not saying it makes much sense,
I just tried to make sure that the code can deal with this situation
when it comes up.

> SourceCache: Reparsing file c:\tmp\615566.htm
> SourceCache: Reparsing file c:\tmp\615566.htm
> SourceCacheWriter: If successful, will replace source cache file 
> c:\tmp\615566.htm
> SourceCacheWriter: Caching source for URL 
> file://localhost/c:/tools/lynx/lynx_help/keystrokes/keystroke_help.html in 
> file c:\tmp\715566.htm
> StreamStack: Returning "PassThruCache"
> SourceCacheWriter: Removing previous file c:\tmp\615566.htm
> SourceCacheWriter: Committing file c:\tmp\715566.htm for URL 
> file://localhost/c:/tools/lynx/lynx_help/keystrokes/keystroke_help.html to 
> anchor

(Same story here.)

   Klaus


reply via email to

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