Could you change the saving of the hot list?
At present it only saves when NS is quit - a pain if you have just made
changes and NS quits1
It either needs a Menu Item: Save Hot List or it should save automatically
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
I've been told by a webmaster that Netsurf doesn't log into his site
properly because the timestamps on the cookies that it is creating are set
wrongly (that is, they are set to expire in 1970). Is there any way of
manipulating the cookie data manually to check this theory?
e.g. I have one cookie displaying as "Expires Sun May 03 20:03:56 2015/Last
used Sun Apr 26 22:21:34 2015" and another one from the same site/session
displaying as "Expires Thu Jan 01 00:59:59 1970/Last used Sun Apr 26
22:21:34 2015" -- these were presumably both sent by the site at the same
Harriet Bazley == Loyaulte me lie ==
Cleanliness is next to impossible.
I have tried to report this on the bug tracker, but can't. It didn't
accept my username and password, I have tried twice to change the
password, and still can't get in. Perhaps someone who can access the
tracker might kindly like to report it.
ARMini, RISC OS 5.18, NS #2720
I tried to access http://www.remapglos.org.uk/ and get "Warning from
NetSurf: OK". The site works properly on Chrome in Windows. I have the
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
Just to summarise the outcome of all the observations on the improved
The improvements make the cache viable on many more supported systems,
including more RISC OS systems.
On PC with modern OS it made no great improvement as their OS could
already cope with the directory layout and had a plentiful write speed
No test I ran on PC saw the write rate, before or after the changes,
drop below 30 megabytes a second. Although the updated cache does use
less processor time to achieve its results.
On RISC OS the benefit is stark and very clear. Most tests show a five
fold or more improvement in write performace using the new code and
many fewer directories created.
The sumamry of results from all the data points I have access to:
| System | Rate K/s |
| Rpi | 7 |
| ARM mini | 33 |
| Iyonix  | 300 |
| a9 | 500 |
| vrpc | 570 |
| ARMX6 | 2700 |
This shows that the disc cache is now useful on RISC OS for most non
SD based systems.
The Raspberry Pi running RISC OS and the ARM mini both appear to react
very poorly indeed to the write pattern used by the disc cache. Users
on such systems should ensure the cache is disabled by setting it to 0
size in the options.
The Iyonix is a bit of a difficult one to call, its disc write speed
appears to be very volatile. Though on average it is beneficial to
enable the cache on this hardware.
The standout here is the ARMX6 which is managing a very respectable
(for RISC OS) 2.7 megabytes per second with the new code some 8 times
better than before the changes.
 The Iyonix write rate seems highly variable and ranges between 90
and 400 K/s
When I made a page with accents, all is OK with Unicode.
For example "élément"
But if I use HTML codes, (éléments), NetSurf considers that
there are 3 words "é"+"lé"+"memts". A cut after each special characters.
And so carriage return is sometimes applied at the wrong place.
Will this bug be corrected?
I know several RISC OS users regularly use the CI builds and have had
issues with the disc cache. This is partly a request for assistance
and partly a warning.
I have recently changed the disc based caching to use fewer small
files. This change is not backwards compatible and will leave the old
cache files behind.
I would suggest that any of you using the disc cache to delete it
before running a NetSurf CI version after #2696 NetSurf will continue
to run just fine if you do not but all the old cache files will be
left behind and never cleaned up.
The upside of this change is that it *may* help with performance for
those of you that were seeing repeated warnings about insufficient
As I have explained previously on several occasions the RISC OS
filesystem performance appears to be very poor when using several
small files, the new system uses a handful of large files as well to
remove this as an issue.
If you have previously disabled the cache please can I ask you to
retry with the newer versions and see if the performance has improved?
If you are feeling very adventurous you can report the bandwidth
achieved. This is a line in the debug Log file held in scrap *after*
the browser has been quit. The last line of the Log will read
(2298.806358) desktop/netsurf.c netsurf_exit 294: Exited successfully
The bandwidth line will be about 20 lines from the end of the log and look like
(2298.804881) content/llcache.c llcache_finalise 3352: Backing store average bandwidth 128324035 bytes/second
I suppose someone knows that Google Books does not show the pages any
longer in any version of Netsurf I have. One 2 years old, NS 3.2, and
a test build from today.
It used to work fine, but Google must have put some spanners in their
Get fit: Recycle your bicycle