Re: Crash on loading NetSurf
In message on 21 Feb 2019 Steve Fryatt wrote: > On 21 Feb, David Higton wrote in message > : >> My best suggestion is to delete your existing NS application, then install >> NS again *properly*, following the instructions, i.e. there are a !Boot >> and a !System to merge. > Have the various cache files, which reside in Scrap (IIRC), been deleted? I > have a recollation of corrupt Unicode cache (RUFL) data preventing the > browser from starting. Thanks, Steve, that has solved the problem :-) Regards Andrew -- Andrew Pinder
Re: Crash on loading NetSurf
In message <57895fcbc1ron.bris...@blueyonder.co.uk> on 20 Feb 2019 Ron Briscoe wrote: > In article <56b3fc8857.andrew-...@waitrose.com>, >Andrew Pinder wrote: >> My best guess is that a Unicode file has been corrupted. How do I >> check? Where do I find an up to date version of Unicode to install? > There is a Unicode application in the !Boot supplied in the NetSurf zip. On checking I seem to have messed up restoring files - I had reverted to r4316 from Jan 2018, not r4335 from May 2018. Also, I hadn't reverted the !Unicode folder in Boot.Resources when I thought I had. But doing those correctly and then rebooting doesn't solve the problem. Regards Andrew -- Andrew Pinder
Crash on loading NetSurf
Message from NetSurf: "The Unicode font library could not be initialised. Please report this to the developers." I don't believe this is a bug - it's the aftermath of a crash. This ARMini (RO 5.22) had been out of use for a period due to a house move. I had been using release 4335, which seemed stable. I downloaded release 4528 as the then most recent. This ran but wasn't displaying some pages correctly. I think the next day I had a crash while downloading email with NetFetch. This caused disc problems. After using DiscKnight and repairing Messenger I then tried loading NetSurf. I got the above error message. I deleted r4528 and reverted to r4335. The error message still occurs on attempting to load NetSurf. I double checked the modules in System to make sure they were the ones that came with r4335. My best guess is that a Unicode file has been corrupted. How do I check? Where do I find an up to date version of Unicode to install? Regards Andrew -- Andrew Pinder
Re: NetSurf 3.7
In message <ba98ba9556.davem...@my.inbox.com> on 4 Nov 2017 Dave Higton <d...@davehigton.me.uk> wrote: > Did I miss an announcement of the release of 3.7, or is it still not > released? Build #4210 declares itself to be version 3.7. Andrew -- Andrew Pinder
Re: Segmentation fault started with no apparent cause
In message <20160826091352.gp26...@platypus.pepperfish.net> on 26 Aug 2016 Rob Kendrick <r...@netsurf-browser.org> wrote: > On Thu, Aug 25, 2016 at 10:21:52PM +0100, Andrew Pinder wrote: >> There appear to be 106 URLs in there. I'm not going to test each one >> to find where the problem is. > Assuming there is nothing personally identifying or secret in your URL > file, attaching it to the bug would be helpful. It did occur to me that one way to search for the problem was binary - split the file in two and find which half has the problem. Then repeat. Except after splitting it, neither half caused problems. Putting the original back also didn't restore the problem. My thought is that one conceivable explanation could be the file had got too big. It was over 42KB in size. It seems to have shrunk down to 39KB. If things are still as clear as mud then waiting to see if anyone else has a similar problem may be a good way forward. Regards Andrew -- Andrew Pinder
Re: Segmentation fault started with no apparent cause
In message <abc84eb555.andrew-...@waitrose.com> on 25 Aug 2016 Andrew Pinder <andrew.pin...@tiscali.co.uk> wrote: > I've just reported to the bug tracker that NetSurf is now refusing to > load and exiting with a Segmentation fault. I have been running CI # > 3625 since 9 Aug without any problems before this morning. Reverting > to #3594 gives the same error. > Should I delete the files in !Boot.Choices.WWW.NetSurf ? That strikes > me as a possible place for a problem to be located that clearly isn't > in the actual application. I've tracked the problem down to something in Boot:^.!Boot.Choices.WWW.NetSurf.URL Moving it elsewhere so it isn't accessible to NetSurf allows NetSurf to load normally. Putting it back brings the problem back. There appear to be 106 URLs in there. I'm not going to test each one to find where the problem is. Regards Andrew -- Andrew Pinder
Re: Problems with bug reporting
In message <2682a91555.davem...@my.inbox.com> on 20 Oct 2015 Dave Higton <d...@davehigton.me.uk> wrote: > I've reproduced the crash. It appears to be the same as bug 2367, so > I've added a note and the resulting log file. Thanks > I don't understand why you were unable to upload the log file. It > works every time for me. I did it just now with CI#3000. Maybe because I was doing it with NetSurf itself on this ARMini rather than via a PC? -- Andrew Pinder
Re: Problems with bug reporting
In message <358bb81555.davem...@my.inbox.com> on 20 Oct 2015 Dave Higton <d...@davehigton.me.uk> wrote: > In message <d7b7b31555.pnyo...@pnyoung.ormail.co.uk> > Peter Young <pnyo...@ormail.co.uk> wrote: >>On 20 Oct 2015 Harriet Bazley <li...@orange.wingsandbeaks.org.uk> >>wrote: >> >>> On 20 Oct 2015 as I do recall, >>> Andrew Pinder wrote: >> >>>> In message <2682a91555.davem...@my.inbox.com> >>>> on 20 Oct 2015 Dave Higton <d...@davehigton.me.uk> wrote: >> >>> [snip] >> >>>>> I don't understand why you were unable to upload the log file. It >>>>> works every time for me. I did it just now with CI#3000. >>>> >>>> Maybe because I was doing it with NetSurf itself on this ARMini rather >>>> than via a PC? >>>> >>> I successfully uploaded a log file this morning using Netsurf on Iyonix - >>> must have been something more local to you :-( >> >>Or is it the problem that I've come across in the past, that the bug >>reporter wouldn't accept an attachment over a certain size? Since I >>came across this, I've always send the logfile in a zip. > It should be normal practice to send it zipped. > Anyway, a fix has just been checked in for bug 2367. The file my machine generated from a fresh load of NetSurf was only 127k. Next time I have a bug report I will try sending it from my Iyonix. Regards Andrew -- Andrew Pinder
Re: Bug 2367
In message <add3b81555.davem...@my.inbox.com> on 20 Oct 2015 Dave Higton <d...@davehigton.me.uk> wrote: > Netsurf CI version #3001 (freshly cooked!) fixes bug 2367. NS should > now crash on rather less sites. > I claim no credit. Indeed it does now load teh page rather than crashing. Thanks :-) Regards Andrew -- Andrew Pinder
Problems with bug reporting
I installed CI #3000 on an ARMini running RO5.22. I used Google to search for "Jordan souvenirs". The fifth link was to Lonely Planet. www.lonelyplanet.com/jordan/shopping/souvenir-gifts Clicking on it caused a crash with "Please attach log file" etc. Using the bug tracker proved tricky as it wouldn't upload the log file: "Failed to open/read local data from file/application". So I'm reporting it here. It's a reproducible bug. Regards Andrew -- Andrew Pinder
Re: even Wikipedia times out now
In message <20151002084212.gb11...@kyllikki.org> on 2 Oct 2015 Vincent Sanders <vi...@netsurf-browser.org> wrote: > The bugtracker is always available, please feel free to report issues > in development builds. Please do not be offended if we close them with > "we know" but in the same breath we do apreciate you taking the time. A couple of pages that come up blank even with JS off: https://www.ryanair.com/en/questions/photo-id/ https://www.ryanair.com/en/terms-and-conditions/regulations-traveldocumentation/ Build #2962 on ARMini RO 5.22 Regards Andrew -- Andrew Pinder
Re: Fail 2890 json
In message 20150814072335.GB10674@somnambulist.local on 14 Aug 2015 Daniel Silverstone dsilv...@netsurf-browser.org wrote: We've already found what we believe to be a bug in UNIXLib and we are investingating it -- it can cause the browser to segfault and thus vanish without apparent error. Sadly I can't give you an ETA on this, though I hope we'll be fairly close to our goal by the end of next week. Some of us (myself and Vince included) have been spending a huge amount of our time on this, we're not leaving you in the lurch; and John-Mark has been instrumental in helping track down the UNIXLib issue. Thanks, as always, for your work on NetSurf. If I understand the position correctly, UnixLib is part of the development environment you use and isn't part of RISCOS itself? So once it has been fixed I won't have to install an update on this machine? Regards Andrew -- Andrew Pinder
Re: More disc cache improvements
In message ac1710c154.andrew-...@waitrose.com on 9 May 2015 Andrew Pinder andrew.pin...@tiscali.co.uk wrote: In message 20150508154706.gb2...@kyllikki.org on 8 May 2015 Vincent Sanders vi...@netsurf-browser.org wrote: The information I want is contained in the log file at exit as most of you have discovered. I have improved whats reported with build CI 2774 and would appreciate two lines of output which appear all together near the end of the log. An example is: content/fs_backing_store.c finalise 1613: Cache total/hit/miss/fail (counts) 2620/240/2380/0 (100%/9%/90%/0%) content/llcache.c llcache_finalise 3361: Backing store wrote 96531600 bytes in 6617 ms average 14626000 bytes/second ARMini RO 5.22 with !Boot and !NetSurf #2774 on the SD card. It has returned a cache too slow message in the two sessions since installing #2774. Results from the most recent one are: (10335.07) content/fs_backing_store.c finalise 1613: Cache total/hit/miss/fail (counts) 523/88/435/0 (100%/16%/83%/0%) (20076.05) content/llcache.c llcache_finalise 3361: Backing store wrote 577764 bytes in 0 ms average 4530 bytes/second After a subsequent lengthy but intermittent session I eventually got the bandwidth warning so then quit and got: (17974.94) content/fs_backing_store.c finalise 1613: Cache total/hit/miss/fail (counts) 563/78/485/0 (100%/13%/86%/0%) (17990.75) content/llcache.c llcache_finalise 3361: Backing store wrote 1222126 bytes in 0 ms average 9334 bytes/second Regards Andrew -- Andrew Pinder
Re: More disc cache improvements
In message 20150508154706.gb2...@kyllikki.org on 8 May 2015 Vincent Sanders vi...@netsurf-browser.org wrote: OK perhaps I needed to be more explicit in what I wanted to achieve from this testing. Thanks for the clarification [snip] The information I want is contained in the log file at exit as most of you have discovered. I have improved whats reported with build CI 2774 and would appreciate two lines of output which appear all together near the end of the log. An example is: content/fs_backing_store.c finalise 1613: Cache total/hit/miss/fail (counts) 2620/240/2380/0 (100%/9%/90%/0%) content/llcache.c llcache_finalise 3361: Backing store wrote 96531600 bytes in 6617 ms average 14626000 bytes/second [Snip] I would like these two lines from the logfile along with the OS and hardware spec of the system. E.g. RISC OS 5 on Iyonix with FAT formatted hard drive or ROOL beta on Raspberry Pi 2 with FAT formatted SD card ARMini RO 5.22 with !Boot and !NetSurf #2774 on the SD card. It has returned a cache too slow message in the two sessions since installing #2774. Results from the most recent one are: (10335.07) content/fs_backing_store.c finalise 1613: Cache total/hit/miss/fail (counts) 523/88/435/0 (100%/16%/83%/0%) (20076.05) content/llcache.c llcache_finalise 3361: Backing store wrote 577764 bytes in 0 ms average 4530 bytes/second Regards Andrew -- Andrew Pinder
Re: More disc cache improvements
In message e75637c054.andrew-...@waitrose.com on 7 May 2015 Andrew Pinder andrew.pin...@tiscali.co.uk wrote: I wonder how stable the measurements are. I've just upgraded this ARMini to RO 5.22 so have redone the measurements, still with NS#2771: 161126 bytes/second. That's a massive increase. I had visited a number of websites for that. Trying going to just www.buxtonweather.co.uk (my homepage) as before now gives 154588 bytes/second - only 4% different. Have I missed something, or have ROOL done something spectacular in the changes from 5.20 to 5.22? More measurements: Various sites including BBC election coverage: 212787 bytes/second Relaunch, load home page only and quit: 0 bytes/second ??? Same again, but force a refresh and then quit: 31146 bytes/second Same again, but after the buxtonweather.co.uk site has done its regular update (every five minutes): 0 bytes/second A wide range of sites, mostly new to me: 328299 bytes/second I'm curious that there is so much variability! Regards Andrew -- Andrew Pinder
Re: More disc cache improvements
In message 54c085ed15ch...@chris-johnson.org.uk on 8 May 2015 cj ch...@chris-johnson.org.uk wrote: In article 0c9680c054.andrew-...@waitrose.com, Andrew Pinder andrew.pin...@tiscali.co.uk wrote: I'm curious that there is so much variability! Will some of this not be due to the fact that stuff is already in the cache and won't be saved again? I expect so, but if so it makes it difficult to assess the performance of the cache without explicit instructions on whether it should be cleared. Regards Andrew -- Andrew Pinder
Re: Google
In message 20150508125407.ga2...@kyllikki.org on 8 May 2015 Vincent Sanders vi...@netsurf-browser.org wrote: On Fri, May 08, 2015 at 01:26:32PM +0100, Richard Torrens (lists) wrote: Yesterday Google stopped working with Netsurf. Has anyone any cures or suggestions? It has been reported in the tracker as bug number 2314. Google have changed the non javascript portion of their reply (the noscript entry) to comtain completely broken html that simply causes the browser to refresh and fail to work usefully. We cannot do anything about this in NetSurf itself and need Google to unbreak their noscript, If you can get anyone there to listen that would be good as I have been unable to find someone to contact. This affects all non javascript browser (or those with it turned off) and cannot be worked around. Which version of NetSurf are we talking about here? I'm on 3.4 (Dev CI #2771) on RO 5.22 and haven't seen any problems with Google. Regards Andrew -- Andrew Pinder
Re: Google
In message f28197c054.old_coaster@old_coaster.yahoo.co.uk on 8 May 2015 Tony Moore old_coas...@yahoo.co.uk wrote: On 8 May 2015, Andrew Pinder andrew.pin...@tiscali.co.uk wrote: [snip] Which version of NetSurf are we talking about here? I'm on 3.4 (Dev CI #2771) on RO 5.22 and haven't seen any problems with Google. Try tuning off JavaScript. Sorry, I wasnt paying enough attention to spot that aspect! Regards Andrew -- Andrew Pinder
Re: More disc cache improvements
In message 019bfbbe54.andrew-...@waitrose.com on 5 May 2015 Andrew Pinder andrew.pin...@tiscali.co.uk wrote: In message 20150505103028.gg19...@kyllikki.org on 5 May 2015 Vincent Sanders vi...@netsurf-browser.org wrote: Further to my previous efforts I have made an attempt to improve the disc cache performance even more. I would again be grateful if suitably interested users could try test CI build 2771 or later. [snip] I have also adjusted how the computation of low bandwidth is made to try and make it more stable and less trigger happy. I would be interested in getting the details from using the updated test release in the same way as previously detailed. (The overall bandwidth message from the log) I am especially interested in testing from the Iyonix as this was right on the edge of usefulness previously. It is probably not worth bothering with the RPi and ARM mini platforms as their reported bandwidth last time was awful and I do not envisage an improvement of that many orders of magnitude. As you expected, no benefit for ARMini users: ARMini with RO 5.20 (10 June 2013) and !Boot on the SD card, not the USB drive. NS #2771 There was no complaint about the bandwidth being too low but the reported average from going only to the www.buxtonweather.co.uk site was 27269 bytes/second. The previous figure I reported was 33092 bytes/second (NS#2697). I wonder how stable the measurements are. I've just upgraded this ARMini to RO 5.22 so have redone the measurements, still with NS#2771: 161126 bytes/second. That's a massive increase. I had visited a number of websites for that. Trying going to just www.buxtonweather.co.uk (my homepage) as before now gives 154588 bytes/second - only 4% different. Have I missed something, or have ROOL done something spectacular in the changes from 5.20 to 5.22? Regards Andrew -- Andrew Pinder
Re: More disc cache improvements
In message 20150505103028.gg19...@kyllikki.org on 5 May 2015 Vincent Sanders vi...@netsurf-browser.org wrote: Further to my previous efforts I have made an attempt to improve the disc cache performance even more. I would again be grateful if suitably interested users could try test CI build 2771 or later. The previous changes switched to using a small number of large files to hold all the small entries within the cache instead of them using individual files. This drastically improved the cache performance on several RISC OS machines. The new update extended this approach so that these block files get created with their maximum size instead of being grown every time a new cache entry is added. This change should be beneficial to RISC OS users as filecore is (apparently) dreadful at this kind of usage pattern. I have also adjusted how the computation of low bandwidth is made to try and make it more stable and less trigger happy. I would be interested in getting the details from using the updated test release in the same way as previously detailed. (The overall bandwidth message from the log) I am especially interested in testing from the Iyonix as this was right on the edge of usefulness previously. It is probably not worth bothering with the RPi and ARM mini platforms as their reported bandwidth last time was awful and I do not envisage an improvement of that many orders of magnitude. As you expected, no benefit for ARMini users: ARMini with RO 5.20 (10 June 2013) and !Boot on the SD card, not the USB drive. NS #2771 There was no complaint about the bandwidth being too low but the reported average from going only to the www.buxtonweather.co.uk site was 27269 bytes/second. The previous figure I reported was 33092 bytes/second (NS#2697). Regards Andrew -- Andrew Pinder
Re: Small, but old bug
In message 20150409203946.gb19...@kyllikki.org on 9 Apr 2015 Vincent Sanders vi...@netsurf-browser.org wrote: Fixing this is earmarked for our 4.0 series and needs a re-written render engine. The new engine is a job comparable in size to the entire project to date and has not yet been started. You guys are brave - or maybe foolhardy! Thanks for your efforts so far :-) Regards Andrew -- Andrew Pinder
Re: Updated disc cache
In message 20150403111441.gb18...@kyllikki.org on 3 Apr 2015 Vincent Sanders vi...@netsurf-browser.org wrote: 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 disc bandwidth. 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 something like: (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 ARMini with RO 5.20 (10 June 2013) NS #2697 I went only to the www.buxtonweather.co.uk website. In the log I found these (20.42) content/llcache.c llcache_persist 2494: Overran timeslot (30.88) content/llcache.c llcache_persist_slowcheck 2438: Cannot write minimum bandwidth (59.82) content/llcache.c llcache_finalise 3352: Backing store average bandwidth 33092 bytes/second That last line was many more than 20 lines from the end of the file Regards Andrew -- Andrew Pinder
Re: Updated disc cache
In message 54af215e1bch...@chris-johnson.org.uk on 4 Apr 2015 cj ch...@chris-johnson.org.uk wrote: In article 54aec5195fstuartli...@orpheusinternet.co.uk, lists stuartli...@orpheusinternet.co.uk wrote: Average bandwidth 355822 bytes/second NetSurf CI #2680 ARMX6 So nothing much to write home about there, considering some of the hype surrounding the disc speed of the ARMX6. Stuart is reporting values from a version (#2680) before the upgrade that improves things (after #2696). Regards Andrew -- Andrew Pinder
Re: JavaScript
In message CAC85+4L83aiXwPEhZsqrq-oRS6kPeAWDEihZnw_UmWmgH1YOJw@mail.g mail.com on 30 Mar 2015 David Feugey dfeu...@ascinfo.fr wrote: ... but nothing about JavaScript support. Just work in progress. I take you point about lack of detail, but I'm only a user rather than a developer, so am not in a position to know what has been done but hasn't been listed on the support web pages. I do recall having a conversation with one of the developers at the Wakefield show, possibly two years ago, who said that one aspect of providing JS support involved working through a very large number of bindings in order to check they worked correctly. Regards Andrew -- Andrew Pinder
Re: JavaScript
In message CAC85+4JSSvqQ8TmKNfYKLiczPapgU7x95Mw9PFSs1CUY3=WNsg@mail.g mail.com on 29 Mar 2015 David Feugey dfeu...@ascinfo.fr wrote: Hi. I worked on several appliances since 2000, and I'm now switching back to RISC OS. As I have total control on the applications, I would like to try to provide client appliances for these applications. I know that NetSurf has only a limited support of JavaScript. But what can we do exactly? Do you have examples of working code? The more code I'll get, the more modern will be my interfaces, and the more chance I'll have to convince my clients :) Nota: I work only with web standards, but if I can narrow my choices to be compatible with NetSurf, why not. Sounds good :-) Hopefully a developer will be along to give more complete answers, but you will find a summary of features at http://www.netsurf-browser.org/ and more detail at http://www.netsurf-browser.org/documentation/progress.html Regards Andrew -- Andrew Pinder
Re: Disc cache updates
In message 20141201160839.gh10...@kyllikki.org on 1 Dec 2014 Vincent Sanders vi...@netsurf-browser.org wrote: The disc cache has recently been updated to track the speed of write operations. As a result of this performance tracking The browser will now detect if a system cannot sustain a write speed of one Megabit (120kilobytes/ second) the cache will disable itself and display a warning. I'm finding this on my ARMini. Is this common? Presumably using !Cache on a RAM disc would be a waste of time as stuff would not be saved when the computer was turned off. Regards Andrew -- Andrew Pinder
Re: #2463 - Scanning fonts
In message 54797458f6bbai...@argonet.co.uk on 21 Dec 2014 Brian bbai...@argonet.co.uk wrote: NetSurf has very recently started scanning fonts during loading. This hasn't happened for ages. Is this a glitch, perhaps, or revised behaviour? I think a relevant factor may be the number of fonts you have installed. Quite a while ago I installed the EFF collection of fonts on my Iyonix. Ever since then whenever !NetSurf loads it displays a window showing progress on scanning fonts. It always appears to stick briefly when scanning Swz.narrow and then completes I can't see anything about that font to know why it takes longer to scan. When I bought this ARMini I copied the fonts across and have always had the same behaviour. So, having read the other responses, I suspect that if you just have the original fonts supplied installed then the scanning of them will normally be so quick that you don't notice it. So maybe a recent change slowed that down. Regards Andrew -- Andrew Pinder
Re: #2463 - Scanning fonts
In message 5479b57ad5bbai...@argonet.co.uk on 21 Dec 2014 Brian bbai...@argonet.co.uk wrote: In article f74fa67954.andrew-...@waitrose.com, Andrew Pinder andrew.pin...@tiscali.co.uk wrote: In message 54797458f6bbai...@argonet.co.uk on 21 Dec 2014 Brian bbai...@argonet.co.uk wrote: NetSurf has very recently started scanning fonts during loading. This hasn't happened for ages. Is this a glitch, perhaps, or revised behaviour? I think a relevant factor may be the number of fonts you have installed. Quite a while ago I installed the EFF collection of fonts on my Iyonix. Ever since then whenever !NetSurf loads it displays a window showing progress on scanning fonts. It always appears to stick briefly when scanning Swz.narrow and then completes I can't see anything about that font to know why it takes longer to scan. When I bought this ARMini I copied the fonts across and have always had the same behaviour. So, having read the other responses, I suspect that if you just have the original fonts supplied installed then the scanning of them will normally be so quick that you don't notice it. So maybe a recent change slowed that down. Please read elsewhere in the thread. No recent changes have been made and in any event very few fonts have been installed originally, as a matter of principle, to avoid the kind of issues that you mention. Previous to the issue that I reported, following any initial scan, ages ago, when the scan window was clearly visible and quite slow, if there are subsequent scans then they are just so fast that no window is visible that I am aware of, just scrolling of the hourglass momentarily. So I have no explanation as to why scanning should become clearly visible of late and that is no longer so following a NetSurf update!?! Thanks for your comment anyway. http://ci.netsurf-browser.org/builds/ says Notice: At any given time these builds may be broken, unstable, have verbose logging enabled, or exhibit any other undesirable behaviour. I suspect that one of the NetSurf developers made a change that had the undesirable side-effect of slowing down font scanning and has now made another change that speeds it up again :-) Regards Andrew -- Andrew Pinder
Server error on Genes Reunited (HTTP 503.0)
Hi all I received an email from Genes Reunited containing a link. Clicking on that gives HTTP Error 503.0 - Service Unavailable It lists as Most likely causes An invalid identity in the application pool could cause this error. The application pool is no longer running because of configuration or reaching application failure limits. The concurrent application request limit was reached. It also tells me that This error occurs when the worker process was unable to start. Accessing the Genes Reunited website from a PC seems to show no problems so it is possible that NetSurf can't yet handle the link. It it will be of help I can add it to the bug tracker. I'm running NetSurf on an ARMini with RO5.20. This error occurs with both NetSurf 2311 and 2381. Regards Andrew -- Andrew Pinder
Re: Server error on Genes Reunited (HTTP 503.0)
In message 20141123160713.gj25...@platypus.pepperfish.net on 23 Nov 2014 Rob Kendrick r...@netsurf-browser.org wrote: Accessing the Genes Reunited website from a PC seems to show no problems so it is possible that NetSurf can't yet handle the link. It it will be of help I can add it to the bug tracker. This error is from the server. NetSurf won't even have had access to any of the page's HTML or images or anything. The server is probably trying to be clever and is getting confused when something that doesn't announce itself to be Mozilla connects, or similar. Not at lot we can do. Ah, thanks. This made me try the GR homepage - same error. Module = WindsorModule. Regards Andrew -- Andrew Pinder
Re: Warning from Netsurf
In message 20140929114457.gm20...@platypus.pepperfish.net on 29 Sep 2014 Rob Kendrick r...@netsurf-browser.org wrote: On Mon, Sep 29, 2014 at 12:27:16PM +0100, Jim Nagel wrote: 1. By what process was this message generated? JavaScript. Some sites produce this kind of message with IE8 2. Is it indeed Netsurf that generates the message? If so, it's ironic that I'm using a very recent build, Netsurf #2124. No, it's JavaScript. So there's a downside to NetSurf having acquired JS support ;-) Regards Andrew -- Andrew Pinder
Re: Not enough application memory to start Basic
In message d55ad31754.andrew-...@waitrose.com on 14 Jun 2014 Andrew Pinder andrew.pin...@tiscali.co.uk wrote: In message mpro.n768be0c1izuo01q9.li...@stevefryatt.org.uk on 14 Jun 2014 Steve Fryatt li...@stevefryatt.org.uk wrote: I don't run NetSurf during the boot sequence -- are all the people seeing issues doing that? What are people's Next slots configured to during the boot process? On completion of booting, my Next slot is set to 640k. I don't know how to tell if it's different during boot. Adding WimpSlot -min 16k -max 16k to the !Run file just before Run Cache$AppDir.!RunImage gets rid of the error message. It does, however, lead the application to think it has not been invoked via its !Boot file, so it opens the Cache directory. This is tested via SYS XOS_ReadVarVal,Cache$FromBoot,block%,-1 TO ,,exists% Cache$From!Boot is set in the !Boot file before the !Run file is called and then unset immediately afterwards. Regards Andrew -- Andrew Pinder
Re: Not enough application memory to start Basic
In message 539c4cfe.6020...@netsurf-browser.org on 14 Jun 2014 Michael Drake t...@netsurf-browser.org wrote: We recently decided to make use of !Cache as we assumed it would be suitable and correct. (None of the core developers are actually using RISC OS at the moment, so we hadn't checked it actually worked.) If you give some clues as to how to test it, some of us may be able to give feedback :-) Regards Andrew -- Andrew Pinder
Re: Not enough application memory to start Basic
In message mpro.n768be0c1izuo01q9.li...@stevefryatt.org.uk on 14 Jun 2014 Steve Fryatt li...@stevefryatt.org.uk wrote: I don't run NetSurf during the boot sequence -- are all the people seeing issues doing that? What are people's Next slots configured to during the boot process? On completion of booting, my Next slot is set to 640k. I don't know how to tell if it's different during boot. I've taken !NetSurf out of the boot sequence and that doesn't solve the problem. I've moved !Cache from !Boot.Resources to Utilities.Caution. Putting it at the end of the Look at list in Boot causes the problem to occur. I then moved it to last in the list of items to be Run, which also causes the error. In this case I got a very brief flash of the ARMini splash box before the error box covered it. Only after I closed this did the apps that had been run before Cache (including !Clock, !Messenger, !NetFetch) appear on the icon bar. This suggests that these apps are multitasking while being loaded. Looking at the !Cache.!Boot file, the second line is If Cache$Dir = Then Run Obey$Dir.!Run I thought the norm was for a !Boot file to set up variables etc, but not to run the application immediately. Could this be the source of the problem? Regards Andrew -- Andrew Pinder
Not enough application memory to start Basic
I've been getting this error when the desktop starts since installing NetSurf CI #1959. Clicking on Cancel allow the Boot to complete. I mistakenly thought that installing CI #1965 had solved the problem. Has anyone else had this problem? Is it associated with the installation of the !Cache resource, which wsa the main change in !Boot due to #1959? Regards Andrew -- Andrew Pinder
Re: Not enough application memory to start Basic
In message 20140613143931.gp3...@platypus.pepperfish.net on 13 Jun 2014 Rob Kendrick r...@netsurf-browser.org wrote: On Fri, Jun 13, 2014 at 03:32:26PM +0100, Bob Latham wrote: In article bb69011754.andrew-...@waitrose.com, Andrew Pinder andrew.pin...@tiscali.co.uk wrote: I've been getting this error when the desktop starts since installing NetSurf CI #1959. Clicking on Cancel allow the Boot to complete. I mistakenly thought that installing CI #1965 had solved the problem. Has anyone else had this problem? Is it associated with the installation of the !Cache resource, which wsa the main change in !Boot due to #1959? Yes I'm getting this too. I've actually killed the !cache application because it kept causing this problem over an over again. Couple people try moving it elsewhere (ie, outside !Boot.Resources), and configure !Boot to look at !Cache *BEFORE* it looks at or runs !NetSurf, and see if this solves the problem? Well, that put it slightly *later* in the Boot sequence but still before looking at !NetSurf. Same error. Regards Andrew -- Andrew Pinder
Re: Username and password problem
In message 5415a8f2f5...@mightyoak.org.uk on 10 Jun 2014 Bob Latham b...@mightyoak.org.uk wrote: In article out-5394e6bd.md-1.4.17.chris.yo...@unsatisfactorysoftware.co.uk, Chris Young chris.yo...@unsatisfactorysoftware.co.uk wrote: On Sun, 08 Jun 2014 19:27:15 +0100, Bob Latham wrote: Chris Young has asked for a copy of the log and I've sent it to him zipped. It's the same cause as Richard's problem. I'll see if I can find some time to look into it again, however it would be very helpful if somebody could create a bug report for this, as it makes it easier to manage and ensures it doesn't get forgotten. In article 20140609201043.gs27...@kyllikki.org, Vincent Sanders vi...@netsurf-browser.org wrote: I have commited a possible fix which is available from the CI system as build #1962 Hopefully this fix will fare better than Ranger 3 did in 1962. I can confirm that I have installed version 1964 today and that it does fix my problem. I've installed CI #1965 and it has fixed the BoxConvert problem I had with an email attachment with 1959. It's also got rid of the Not enough application memory to start Basic error that 1959 gave when the desktop was starting. Well done and thanks to all of you. Agreed Andrew -- Andrew Pinder
Re: Options/Choices refactor
In message 5353116372t...@netsurf-browser.org on 28 May 2013 Michael Drake t...@netsurf-browser.org wrote: Actually, I'd recommend simply deleting your old Choices file. I take it you mean this file: !Boot.Choices.WWW.NetSurf.Choices Regards Andrew -- Andrew Pinder
Re: Orpheus Home page
In message cfd9b04753.old_coaster@old_coaster.yahoo.co.uk on 6 May 2013 Tony Moore old_coas...@yahoo.co.uk wrote: If you go to http://ci.netsurf-browser.org/builds/riscos/ you will find that the first half of the listed builds are -jsoff- and the second half are -json- I'm aware of that - thank you. The point is that some people choose to use the stable releases, instead of the development builds. This discussion had its origin in a post to csa.apps by someone who had downloaded NetSurf 3.0 and was 'having some difficulty with its JS'. Oops. Eggs. Sucking. Grandmother. Dont teach. ;-( Regards Andrew -- Andrew Pinder
Re: Orpheus Home page
In message 3c58a64753.old_coaster@old_coaster.yahoo.co.uk on 6 May 2013 Tony Moore old_coas...@yahoo.co.uk wrote: On 1 May 2013, Chris Young chris.yo...@unsatisfactorysoftware.co.uk wrote: [snip] I think it is highly likely that NetSurf 3.0 has been built without JavaScript support. At present, both http://www.riscosopen.org/forum/forums/1/topics/1847 and the ChangeLog assert that NetSurf 3.0 offers 'early and primitive JavaScript support'. However, it would appear that this is untrue. Is it intended to rebuild NetSurf 3.0 and/or alter the ChangeLog so that they are mutually consistent? If you go to http://ci.netsurf-browser.org/builds/riscos/ you will find that the first half of the listed builds are -jsoff- and the second half are -json- Scroll right down to the bottom to find the most recent json build. Regards Andrew -- Andrew Pinder
