On Wed, 24 Dec 2014 09:55:37 +0000, Vincent Sanders wrote:
> as we discovered with beos, gcc 2.95 support is a bit hit and
> miss. Though I beleive the main issue there was g++, even so I fear
> 2.95 is too primative and is almost 14 years old at this point.
I agree we shouldn't go back to such an old version.
> > There are loads of patches here:
> > https://github.com/cahirwpz/m68k-amigaos-toolchain
> >
> > There are an excessive number and I have no idea which are relevant.
>
> That is terrifying, I really do think that if they want continuing
> compiler support they need to look at a modern gcc version or a clang
> port.
And getting the patches merged back upstream would be a good idea too.
It looks like that must never have happened for m68k-amigaos.
> Alas wishing does not make it so, being pragmatic, if there is a
> "cannonical" cross toolchain for the target I might be persuaded to
> put it on the CI as long as we can "package" it under /opt/netsurf
> correctly so builds are repeatbale. I dislike this a lot but if it is
> the only way...
I'd rather get the official 3.4.6 source and import the patches we
need from that repo (even if that's all of them under
patches/gcc-3.4.6). I did try building it with our current patches
but it clearly needs more as I get errors with register defines
(REG_A0 etc), unless I'm doing something wrong.
Chris
Wednesday, 24 December 2014
Core buildsystem changes
The recent developer weekend gave John-Mark and myself opportunity to
improve the core buildsystem (used for all the libraries) to use
standard "triplet" type identifiers for the ABI being compiled. This
means we now query the compiler [1] about the binary it will build to
setup cross compiling.
We use the environment values for HOST, HOST_CC, BUILD and CC in a
similar manner to how the gnu tooling uses them. Simply:
BUILD - The compiler triplet of the system running the compiler, this
can almost always be omitted and will be detected automatically.
CC - The build systems compiler, allows overriding of the default
compiler (cc) searched for on the PATH
HOST - This is the compiler triplet of the system we are building for,
it it differs from BUILD then we are performing a cross compile.
The compiler name is constructed using this unless HOST_CC is
specified.
HOST_CC - override the constructed compiler name for cross
compilation, the path and details for all the tools are
derived from this.
The core buildsystem has been updated along with the environment
script [2] so in general this has a low impact on developers but a
great gain for more complex build setups such as the CI system.
[1] This uses "cc -dumpmachine"
[2] http://git.netsurf-browser.org/netsurf.git/plain/Docs/env.sh
--
Regards Vincent
http://www.kyllikki.org/
improve the core buildsystem (used for all the libraries) to use
standard "triplet" type identifiers for the ABI being compiled. This
means we now query the compiler [1] about the binary it will build to
setup cross compiling.
We use the environment values for HOST, HOST_CC, BUILD and CC in a
similar manner to how the gnu tooling uses them. Simply:
BUILD - The compiler triplet of the system running the compiler, this
can almost always be omitted and will be detected automatically.
CC - The build systems compiler, allows overriding of the default
compiler (cc) searched for on the PATH
HOST - This is the compiler triplet of the system we are building for,
it it differs from BUILD then we are performing a cross compile.
The compiler name is constructed using this unless HOST_CC is
specified.
HOST_CC - override the constructed compiler name for cross
compilation, the path and details for all the tools are
derived from this.
The core buildsystem has been updated along with the environment
script [2] so in general this has a low impact on developers but a
great gain for more complex build setups such as the CI system.
[1] This uses "cc -dumpmachine"
[2] http://git.netsurf-browser.org/netsurf.git/plain/Docs/env.sh
--
Regards Vincent
http://www.kyllikki.org/
RSS feed and Sargasso
I use Sargasso to show the RISC OS Open posts feed.
Noticing an RSS link on:
http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/changes
which, as I have noted earlier no longer gives much/any useful information,
I tried the link:
http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/rssAll
in Sargasso, but it doesn't work.
Can anyone advise on a correct URL, ie, one that /will/ work?
John
--
| John Williams
| johnrw@ukgateway.net
Names for Soul Band:- Soul Trader(s) *
Noticing an RSS link on:
http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/changes
which, as I have noted earlier no longer gives much/any useful information,
I tried the link:
http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/rssAll
in Sargasso, but it doesn't work.
Can anyone advise on a correct URL, ie, one that /will/ work?
John
--
| John Williams
| johnrw@ukgateway.net
Names for Soul Band:- Soul Trader(s) *
CI updates
I have recently had the opportunity to greatly improve the NetSurf CI
build infrastructure both in terms of hardware and software.
On the hardware side I would like to thank Mythic Beasts [1] for once
again generously donating a 1u rack server. This is a 8 core Xeon with
24G of memory which replaces their previous donation of a 4 core 8G
system.
This server is the projects primary VM host for CI build slaves and
the bug tracker. It continues to be hosted by Collabora [2] in
Cambridge. Other services the project uses, like the website,
remain hosted by Pepperfish [3] for which I would also like to extend
my appreciation.
The new hardware has reduced the NetSurf CI rebuild time under
150seconds (down from 300) on all ten currently built operating
systems and allowed the addition of more build combinations improving
the utility to the developers.
The additional memory has allowed us to add more build slaves and
hence extend the number of OS built for. Also the number of checks
performed in analysis jobs[4] was extended.
The CI software has been upgraded to the latest version of jenkins
along with all the other plugins.
I used the opportunity to complete the improvements to the development
build process which was started at the developer weekend. This has
resulted in the job history and rss feed data for many CI jobs
(including the main NetSurf job) being reset, apologies if this
adversely affects anyone but as new builds are performed the history
backlog will build up again.
As a note builds are only performed if commits to the git
repository[5] occur, we do not perform periodic (daily) builds in
general. As there have not been many commits recently there have been
very few builds, this is correct and expected behaviour.
[1] https://www.mythic-beasts.com/
[2] https://www.collabora.com/
[3] http://www.pepperfish.net/
[4] http://ci.netsurf-browser.org/jenkins/job/scan-build-netsurf/
[5] http://git.netsurf-browser.org/
--
Regards Vincent
http://www.kyllikki.org/
build infrastructure both in terms of hardware and software.
On the hardware side I would like to thank Mythic Beasts [1] for once
again generously donating a 1u rack server. This is a 8 core Xeon with
24G of memory which replaces their previous donation of a 4 core 8G
system.
This server is the projects primary VM host for CI build slaves and
the bug tracker. It continues to be hosted by Collabora [2] in
Cambridge. Other services the project uses, like the website,
remain hosted by Pepperfish [3] for which I would also like to extend
my appreciation.
The new hardware has reduced the NetSurf CI rebuild time under
150seconds (down from 300) on all ten currently built operating
systems and allowed the addition of more build combinations improving
the utility to the developers.
The additional memory has allowed us to add more build slaves and
hence extend the number of OS built for. Also the number of checks
performed in analysis jobs[4] was extended.
The CI software has been upgraded to the latest version of jenkins
along with all the other plugins.
I used the opportunity to complete the improvements to the development
build process which was started at the developer weekend. This has
resulted in the job history and rss feed data for many CI jobs
(including the main NetSurf job) being reset, apologies if this
adversely affects anyone but as new builds are performed the history
backlog will build up again.
As a note builds are only performed if commits to the git
repository[5] occur, we do not perform periodic (daily) builds in
general. As there have not been many commits recently there have been
very few builds, this is correct and expected behaviour.
[1] https://www.mythic-beasts.com/
[2] https://www.collabora.com/
[3] http://www.pepperfish.net/
[4] http://ci.netsurf-browser.org/jenkins/job/scan-build-netsurf/
[5] http://git.netsurf-browser.org/
--
Regards Vincent
http://www.kyllikki.org/
Re: m68k amigaos toolchain
On Sat, Dec 20, 2014 at 09:47:14PM +0000, Chris Young wrote:
> On 20 Dec 2014 20:52:25 +0000, Chris Young wrote:
>
> > Furthermore, there's something broken in the compiler as
> > everything it builds causes a system freeze on exit.
>
> I suspect this is down to the version of gcc being used. Everybody
> seems to be stuck on 2.95 still, and the only other version I've seen
> in use for m68k-amigaos is 3.4 (along with notes saying it doesn't
> generate as good 68k code compared to 2.95)
as we discovered with beos, gcc 2.95 support is a bit hit and
miss. Though I beleive the main issue there was g++, even so I fear
2.95 is too primative and is almost 14 years old at this point.
>
> There are loads of patches here:
> https://github.com/cahirwpz/m68k-amigaos-toolchain
>
> There are an excessive number and I have no idea which are relevant.
That is terrifying, I really do think that if they want continuing
compiler support they need to look at a modern gcc version or a clang
port.
Alas wishing does not make it so, being pragmatic, if there is a
"cannonical" cross toolchain for the target I might be persuaded to
put it on the CI as long as we can "package" it under /opt/netsurf
correctly so builds are repeatbale. I dislike this a lot but if it is
the only way...
>
> I've pushed the patches to make libcurl build as a pure clib2 library,
> so the SDK at least completes.
Excellent, thanks for that. I pushed the rebuild on the CI so we
should be able to get a build through in an hour or so. I also enabled
the target for most of the libraries, as expected the netsurf build
itself does not yet work but when you are ready let me know whats
needed and I will turn it on.
>
> Chris
>
>
--
Regards Vincent
http://www.kyllikki.org/
> On 20 Dec 2014 20:52:25 +0000, Chris Young wrote:
>
> > Furthermore, there's something broken in the compiler as
> > everything it builds causes a system freeze on exit.
>
> I suspect this is down to the version of gcc being used. Everybody
> seems to be stuck on 2.95 still, and the only other version I've seen
> in use for m68k-amigaos is 3.4 (along with notes saying it doesn't
> generate as good 68k code compared to 2.95)
as we discovered with beos, gcc 2.95 support is a bit hit and
miss. Though I beleive the main issue there was g++, even so I fear
2.95 is too primative and is almost 14 years old at this point.
>
> There are loads of patches here:
> https://github.com/cahirwpz/m68k-amigaos-toolchain
>
> There are an excessive number and I have no idea which are relevant.
That is terrifying, I really do think that if they want continuing
compiler support they need to look at a modern gcc version or a clang
port.
Alas wishing does not make it so, being pragmatic, if there is a
"cannonical" cross toolchain for the target I might be persuaded to
put it on the CI as long as we can "package" it under /opt/netsurf
correctly so builds are repeatbale. I dislike this a lot but if it is
the only way...
>
> I've pushed the patches to make libcurl build as a pure clib2 library,
> so the SDK at least completes.
Excellent, thanks for that. I pushed the rebuild on the CI so we
should be able to get a build through in an hour or so. I also enabled
the target for most of the libraries, as expected the netsurf build
itself does not yet work but when you are ready let me know whats
needed and I will turn it on.
>
> Chris
>
>
--
Regards Vincent
http://www.kyllikki.org/
Tuesday, 23 December 2014
Re: Daily builds
On Tue, Dec 23, 2014 at 13:22:32 +0000, Peter Slegg wrote:
> Have the daily builds been running since the 21st ?
We do not run 'daily builds' -- we run builds whenever a developer adds code to
the project. Given it is the Christmas period, most of the developers are a
tad busy.
I'd guess you might see new builds after Boxing day when we all start to get a
little fed up with 'family' :-)
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> Have the daily builds been running since the 21st ?
We do not run 'daily builds' -- we run builds whenever a developer adds code to
the project. Given it is the Christmas period, most of the developers are a
tad busy.
I'd guess you might see new builds after Boxing day when we all start to get a
little fed up with 'family' :-)
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Sunday, 21 December 2014
Re: #2463 - Scanning fonts
Brian, on 22 Dec, wrote:
> In article <618eb77954.Andrew-Pin@waitrose.com>, Andrew Pinder
> <Andrew.Pinder@tiscali.co.uk> wrote:
[snip]
> > 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."
>
> Fairy nuff! I had forgotten, I've just got used to NetSurf being stable
> and well behaved of late.
>
> > 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 :-)
>
> That thought had occurred to me, but then it is the season of the year and
> a time of max stress. 8-)
Up until a few weeks ago I was subscribed to an RSS feed from Jenkins which
gave clear indication of recent changes. That feed disappeared and the only
replacements I have found on Jenkins are sporadic and incomplete.
This, and its RSS, is currently only showing the latest version :-
http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/changes
This RSS feed seems to have stopped at #2451 :-
http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/BUILD=arm-unknown-riscos,BUILD_JS=json,CC=gcc,TARGET=riscos/rssAll
And this only has #2471 :-
http://ci.netsurf-browser.org/jenkins/job/netsurf/BUILD_JS=json,CC=gcc,HOST=arm-unknown-riscos,TARGET=riscos/rssAll
OTOH I have not actually seen any recent difficulties.
--
David Pitt
> In article <618eb77954.Andrew-Pin@waitrose.com>, Andrew Pinder
> <Andrew.Pinder@tiscali.co.uk> wrote:
[snip]
> > 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."
>
> Fairy nuff! I had forgotten, I've just got used to NetSurf being stable
> and well behaved of late.
>
> > 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 :-)
>
> That thought had occurred to me, but then it is the season of the year and
> a time of max stress. 8-)
Up until a few weeks ago I was subscribed to an RSS feed from Jenkins which
gave clear indication of recent changes. That feed disappeared and the only
replacements I have found on Jenkins are sporadic and incomplete.
This, and its RSS, is currently only showing the latest version :-
http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/changes
This RSS feed seems to have stopped at #2451 :-
http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/BUILD=arm-unknown-riscos,BUILD_JS=json,CC=gcc,TARGET=riscos/rssAll
And this only has #2471 :-
http://ci.netsurf-browser.org/jenkins/job/netsurf/BUILD_JS=json,CC=gcc,HOST=arm-unknown-riscos,TARGET=riscos/rssAll
OTOH I have not actually seen any recent difficulties.
--
David Pitt
Re: #2463 - Scanning fonts
In article <618eb77954.Andrew-Pin@waitrose.com>, Andrew Pinder
<Andrew.Pinder@tiscali.co.uk> wrote:
[snip]
> > 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."
Fairy nuff! I had forgotten, I've just got used to NetSurf being stable
and well behaved of late.
> 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 :-)
That thought had occurred to me, but then it is the season of the year and
a time of max stress. 8-)
Best wishes
Brian
<Andrew.Pinder@tiscali.co.uk> wrote:
[snip]
> > 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."
Fairy nuff! I had forgotten, I've just got used to NetSurf being stable
and well behaved of late.
> 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 :-)
That thought had occurred to me, but then it is the season of the year and
a time of max stress. 8-)
Best wishes
Brian
Re: #2463 - Scanning fonts
In message <5479b57ad5bbailey@argonet.co.uk>
on 21 Dec 2014 Brian <bbailey@argonet.co.uk> wrote:
> In article <f74fa67954.Andrew-Pin@waitrose.com>,
> Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
>> In message <54797458f6bbailey@argonet.co.uk>
>> on 21 Dec 2014 Brian <bbailey@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
on 21 Dec 2014 Brian <bbailey@argonet.co.uk> wrote:
> In article <f74fa67954.Andrew-Pin@waitrose.com>,
> Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
>> In message <54797458f6bbailey@argonet.co.uk>
>> on 21 Dec 2014 Brian <bbailey@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
Re: #2463 - Scanning fonts
In article <f74fa67954.Andrew-Pin@waitrose.com>,
Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
> In message <54797458f6bbailey@argonet.co.uk>
> on 21 Dec 2014 Brian <bbailey@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.
Brian
Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
> In message <54797458f6bbailey@argonet.co.uk>
> on 21 Dec 2014 Brian <bbailey@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.
Brian
Re: #2463 - Scanning fonts
In message <f74fa67954.Andrew-Pin@waitrose.com>
Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
> In message <54797458f6bbailey@argonet.co.uk>
> on 21 Dec 2014 Brian <bbailey@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.
I agree. NetSurf 3.2 scans fonts here (RaspPi 5.21) on loading
(automatic on booting as it's installed in Configure-Boot
sequence-Run) every time. I have 2658 files in !Boot.Resources.!Fonts.
--
George
Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
> In message <54797458f6bbailey@argonet.co.uk>
> on 21 Dec 2014 Brian <bbailey@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.
I agree. NetSurf 3.2 scans fonts here (RaspPi 5.21) on loading
(automatic on booting as it's installed in Configure-Boot
sequence-Run) every time. I have 2658 files in !Boot.Resources.!Fonts.
--
George
Re: #2463 - Scanning fonts
In message <54797458f6bbailey@argonet.co.uk>
on 21 Dec 2014 Brian <bbailey@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
on 21 Dec 2014 Brian <bbailey@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
Brian <bbailey@argonet.co.uk> wrote:
>Umm, that's a thought, but likewise, how do you know which one other than
>by deleting and replacing successively.
Look at modification dates (if RO has them) on the font files? If you're
using VRPC then HOSTFS's access to an underlying FS will maybe give better
info.
Or binary-compare the files with some backups.
Otherwise, delete & replace half of them. If the fault stays/goes you know
which half is the problem (assuming there's only one fault, of course).
Repeat process to narrow down which half of the guilty group...
--
Jeremy C B Nicoll - my opinions are my own.
>Umm, that's a thought, but likewise, how do you know which one other than
>by deleting and replacing successively.
Look at modification dates (if RO has them) on the font files? If you're
using VRPC then HOSTFS's access to an underlying FS will maybe give better
info.
Or binary-compare the files with some backups.
Otherwise, delete & replace half of them. If the fault stays/goes you know
which half is the problem (assuming there's only one fault, of course).
Repeat process to narrow down which half of the guilty group...
--
Jeremy C B Nicoll - my opinions are my own.
Re: #2463 - Scanning fonts
In article <54798534c6bbailey@argonet.co.uk>,
Brian <bbailey@argonet.co.uk> wrote:
[snip]
> > Isn't this repeating font scan possibly down to a corrupt font? No idea
> > how to tell which font to blame.
> Umm, that's a thought, but likewise, how do you know which one other than
> by deleting and replacing successively.
> However, I have just updated NetSurf on my A7000+, which I haven't used
> for a while, and NetSurf #2464 doesn't scan fonts there when loaded.
> #2466 installed on my VRPC still scans fonts, just now.
Just, very rashly, overwrote !Fonts with a back up copy, and #2466 still
scanned fonts.
However, just updated to #2467, and fonts are no longer scanned.
QED, or summat. Thanks for the interest shown!
Brian
Brian <bbailey@argonet.co.uk> wrote:
[snip]
> > Isn't this repeating font scan possibly down to a corrupt font? No idea
> > how to tell which font to blame.
> Umm, that's a thought, but likewise, how do you know which one other than
> by deleting and replacing successively.
> However, I have just updated NetSurf on my A7000+, which I haven't used
> for a while, and NetSurf #2464 doesn't scan fonts there when loaded.
> #2466 installed on my VRPC still scans fonts, just now.
Just, very rashly, overwrote !Fonts with a back up copy, and #2466 still
scanned fonts.
However, just updated to #2467, and fonts are no longer scanned.
QED, or summat. Thanks for the interest shown!
Brian
Re: #2463 - Scanning fonts
In article <mpro.ngxlxt008k4h700ww.pittdj@pittdj.co.uk>, David Pitt
<pittdj@pittdj.co.uk> wrote:
> David Pitt, on 21 Dec, wrote:
> > cj, on 21 Dec, wrote:
> >
> > > In article <547974ef73JohnRW@ukgateway.net>, John Williams
> > > <JohnRW@ukgateway.net> wrote:
> > > > Not happening here!
> > >
> > > <aol> Nor here, on three different machines </aol>
> > >
> >
> > Nor here, OS5.21.
> P.S. Had just got sat down with a cup of coffee and the paper and a
> thought occurred.
Must be all that caffeine. I can't do that, I am allergic to caffeine.
> Isn't this repeating font scan possibly down to a corrupt font? No idea
> how to tell which font to blame.
Umm, that's a thought, but likewise, how do you know which one other than
by deleting and replacing successively.
However, I have just updated NetSurf on my A7000+, which I haven't used
for a while, and NetSurf #2464 doesn't scan fonts there when loaded.
#2466 installed on my VRPC still scans fonts, just now.
Brian
<pittdj@pittdj.co.uk> wrote:
> David Pitt, on 21 Dec, wrote:
> > cj, on 21 Dec, wrote:
> >
> > > In article <547974ef73JohnRW@ukgateway.net>, John Williams
> > > <JohnRW@ukgateway.net> wrote:
> > > > Not happening here!
> > >
> > > <aol> Nor here, on three different machines </aol>
> > >
> >
> > Nor here, OS5.21.
> P.S. Had just got sat down with a cup of coffee and the paper and a
> thought occurred.
Must be all that caffeine. I can't do that, I am allergic to caffeine.
> Isn't this repeating font scan possibly down to a corrupt font? No idea
> how to tell which font to blame.
Umm, that's a thought, but likewise, how do you know which one other than
by deleting and replacing successively.
However, I have just updated NetSurf on my A7000+, which I haven't used
for a while, and NetSurf #2464 doesn't scan fonts there when loaded.
#2466 installed on my VRPC still scans fonts, just now.
Brian
Re: #2463 - Scanning fonts
On 21 Dec, Brian wrote in message
<5479763023bbailey@argonet.co.uk>:
> In article <547974ef73JohnRW@ukgateway.net>,
> John Williams <JohnRW@ukgateway.net> wrote:
> > In article <54797458f6bbailey@argonet.co.uk>,
> > Brian <bbailey@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?
>
> > Not happening here! Could something have changed in your font
> > collection?
>
> No, John. Not for ages.
>
> In any event shouldn't this only happen the first time after changes to
> the fonts collection in !Fonts then not again thereafter?
Or whenever NetSurf can't find, or correctly generate and save, its font
list.
> The above behaviour now happens every time that NetSurf is run.
Where do you have !Scrap located, and is its contents retained across
sessions? Are the files in it all writable?
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
<5479763023bbailey@argonet.co.uk>:
> In article <547974ef73JohnRW@ukgateway.net>,
> John Williams <JohnRW@ukgateway.net> wrote:
> > In article <54797458f6bbailey@argonet.co.uk>,
> > Brian <bbailey@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?
>
> > Not happening here! Could something have changed in your font
> > collection?
>
> No, John. Not for ages.
>
> In any event shouldn't this only happen the first time after changes to
> the fonts collection in !Fonts then not again thereafter?
Or whenever NetSurf can't find, or correctly generate and save, its font
list.
> The above behaviour now happens every time that NetSurf is run.
Where do you have !Scrap located, and is its contents retained across
sessions? Are the files in it all writable?
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
Re: #2463 - Scanning fonts
David Pitt, on 21 Dec, wrote:
> cj, on 21 Dec, wrote:
>
> > In article <547974ef73JohnRW@ukgateway.net>,
> > John Williams <JohnRW@ukgateway.net> wrote:
> > > Not happening here!
> >
> > <aol> Nor here, on three different machines </aol>
> >
>
> Nor here, OS5.21.
P.S. Had just got sat down with a cup of coffee and the paper and a thought
occurred.
Isn't this repeating font scan possibly down to a corrupt font? No idea how
to tell which font to blame.
--
David Pitt
> cj, on 21 Dec, wrote:
>
> > In article <547974ef73JohnRW@ukgateway.net>,
> > John Williams <JohnRW@ukgateway.net> wrote:
> > > Not happening here!
> >
> > <aol> Nor here, on three different machines </aol>
> >
>
> Nor here, OS5.21.
P.S. Had just got sat down with a cup of coffee and the paper and a thought
occurred.
Isn't this repeating font scan possibly down to a corrupt font? No idea how
to tell which font to blame.
--
David Pitt
Re: #2463 - Scanning fonts
cj, on 21 Dec, wrote:
> In article <547974ef73JohnRW@ukgateway.net>,
> John Williams <JohnRW@ukgateway.net> wrote:
> > Not happening here!
>
> <aol> Nor here, on three different machines </aol>
>
Nor here, OS5.21.
--
David Pitt
> In article <547974ef73JohnRW@ukgateway.net>,
> John Williams <JohnRW@ukgateway.net> wrote:
> > Not happening here!
>
> <aol> Nor here, on three different machines </aol>
>
Nor here, OS5.21.
--
David Pitt
Re: #2463 - Scanning fonts
In article <547974ef73JohnRW@ukgateway.net>,
John Williams <JohnRW@ukgateway.net> wrote:
> Not happening here!
<aol>
Nor here, on three different machines
</aol>
--
Chris Johnson
John Williams <JohnRW@ukgateway.net> wrote:
> Not happening here!
<aol>
Nor here, on three different machines
</aol>
--
Chris Johnson
Re: #2463 - Scanning fonts
In article <5479763023bbailey@argonet.co.uk>, Brian
<bbailey@argonet.co.uk> wrote:
> In article <547974ef73JohnRW@ukgateway.net>, John Williams
> <JohnRW@ukgateway.net> wrote:
> > In article <54797458f6bbailey@argonet.co.uk>, Brian
> > <bbailey@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?
> > Not happening here! Could something have changed in your font
> > collection?
> No, John. Not for ages.
> In any event shouldn't this only happen the first time after changes to
> the fonts collection in !Fonts then not again thereafter?
> The above behaviour now happens every time that NetSurf is run.
Just a thought, John.
You are running RISC OS 5.21, yes? I am running VRPC RISC OS 4.02. Might
that account for our different experience, perhaps?
Brian
<bbailey@argonet.co.uk> wrote:
> In article <547974ef73JohnRW@ukgateway.net>, John Williams
> <JohnRW@ukgateway.net> wrote:
> > In article <54797458f6bbailey@argonet.co.uk>, Brian
> > <bbailey@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?
> > Not happening here! Could something have changed in your font
> > collection?
> No, John. Not for ages.
> In any event shouldn't this only happen the first time after changes to
> the fonts collection in !Fonts then not again thereafter?
> The above behaviour now happens every time that NetSurf is run.
Just a thought, John.
You are running RISC OS 5.21, yes? I am running VRPC RISC OS 4.02. Might
that account for our different experience, perhaps?
Brian
Re: #2463 - Scanning fonts
In article <547974ef73JohnRW@ukgateway.net>,
John Williams <JohnRW@ukgateway.net> wrote:
> In article <54797458f6bbailey@argonet.co.uk>,
> Brian <bbailey@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?
> Not happening here! Could something have changed in your font collection?
No, John. Not for ages.
In any event shouldn't this only happen the first time after changes to
the fonts collection in !Fonts then not again thereafter?
The above behaviour now happens every time that NetSurf is run.
Brian
John Williams <JohnRW@ukgateway.net> wrote:
> In article <54797458f6bbailey@argonet.co.uk>,
> Brian <bbailey@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?
> Not happening here! Could something have changed in your font collection?
No, John. Not for ages.
In any event shouldn't this only happen the first time after changes to
the fonts collection in !Fonts then not again thereafter?
The above behaviour now happens every time that NetSurf is run.
Brian
Re: #2463 - Scanning fonts
In article <54797458f6bbailey@argonet.co.uk>,
Brian <bbailey@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?
Not happening here! Could something have changed in your font collection?
John
--
| John Williams
| johnrw@ukgateway.net
This tagline has been removed to save bandwidth *
Brian <bbailey@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?
Not happening here! Could something have changed in your font collection?
John
--
| John Williams
| johnrw@ukgateway.net
This tagline has been removed to save bandwidth *
#2463 - Scanning fonts
NetSurf has very recently started scanning fonts during loading. This
hasn't happened for ages. Is this a glitch, perhaps, or revised behaviour?
hasn't happened for ages. Is this a glitch, perhaps, or revised behaviour?
Saturday, 20 December 2014
Re: m68k amigaos toolchain
On 20 Dec 2014 20:52:25 +0000, Chris Young wrote:
> Furthermore, there's something broken in the compiler as
> everything it builds causes a system freeze on exit.
I suspect this is down to the version of gcc being used. Everybody
seems to be stuck on 2.95 still, and the only other version I've seen
in use for m68k-amigaos is 3.4 (along with notes saying it doesn't
generate as good 68k code compared to 2.95)
There are loads of patches here:
https://github.com/cahirwpz/m68k-amigaos-toolchain
There are an excessive number and I have no idea which are relevant.
I've pushed the patches to make libcurl build as a pure clib2 library,
so the SDK at least completes.
Chris
> Furthermore, there's something broken in the compiler as
> everything it builds causes a system freeze on exit.
I suspect this is down to the version of gcc being used. Everybody
seems to be stuck on 2.95 still, and the only other version I've seen
in use for m68k-amigaos is 3.4 (along with notes saying it doesn't
generate as good 68k code compared to 2.95)
There are loads of patches here:
https://github.com/cahirwpz/m68k-amigaos-toolchain
There are an excessive number and I have no idea which are relevant.
I've pushed the patches to make libcurl build as a pure clib2 library,
so the SDK at least completes.
Chris
Re: m68k amigaos toolchain
On Sat, 20 Dec 2014 19:51:25 +0000, Vincent Sanders wrote:
> I have unfortunately failed to make the SDK build. libcurl is failing
> because of a missing include. This can be seen in the CI systems build
> log [2]
The cause is because we are missing the AmiTCP includes. However, I'm
not sure adding them is the correct solution. I think what we should
be doing is removing the Amiga-specific stuff from curl (as we do on
ppc-amigaos) and using the clib2 functions, as it should be able to
handle this itself.
Unfortunately I can't get a working curl binary out of it using either
method. Furthermore, there's something broken in the compiler as
everything it builds causes a system freeze on exit.
> If someone knows the answer to this please can they apply it
> to the toolchains repo and let me know. Once this is working I will
> sort out adding this target to the libs
The libs appear to build ok, which is nice.
> and netsurf.
Not much chance of that for the moment. I was prodding the m68k
toolchain in the hope that if I got it working it would encourage
somebody to back-port the OS4 frontend to OS3 (or at least make it
easier for me to, very slowly, do the required work).
Chris
> I have unfortunately failed to make the SDK build. libcurl is failing
> because of a missing include. This can be seen in the CI systems build
> log [2]
The cause is because we are missing the AmiTCP includes. However, I'm
not sure adding them is the correct solution. I think what we should
be doing is removing the Amiga-specific stuff from curl (as we do on
ppc-amigaos) and using the clib2 functions, as it should be able to
handle this itself.
Unfortunately I can't get a working curl binary out of it using either
method. Furthermore, there's something broken in the compiler as
everything it builds causes a system freeze on exit.
> If someone knows the answer to this please can they apply it
> to the toolchains repo and let me know. Once this is working I will
> sort out adding this target to the libs
The libs appear to build ok, which is nice.
> and netsurf.
Not much chance of that for the moment. I was prodding the m68k
toolchain in the hope that if I got it working it would encourage
somebody to back-port the OS4 frontend to OS3 (or at least make it
easier for me to, very slowly, do the required work).
Chris
m68k amigaos toolchain
I have attempted to get the m68k-unknown-amigaos toolchain up so i can
get the CI system building for the target[1]. I managed to get the
main toolchain building once I fixed the already known issues with gmp
and autoconf versioning (applied the same fixes we already had for the
ppc-amigaos toolchain)
I have unfortunately failed to make the SDK build. libcurl is failing
because of a missing include. This can be seen in the CI systems build
log [2] If someone knows the answer to this please can they apply it
to the toolchains repo and let me know. Once this is working I will
sort out adding this target to the libs and netsurf.
[1] http://ci.netsurf-browser.org/jenkins/computer/cislave9/
[2] http://ci.netsurf-browser.org/jenkins/job/toolchain-m68k-unknown-amigaos/6/console
--
Regards Vincent
http://www.kyllikki.org/
get the CI system building for the target[1]. I managed to get the
main toolchain building once I fixed the already known issues with gmp
and autoconf versioning (applied the same fixes we already had for the
ppc-amigaos toolchain)
I have unfortunately failed to make the SDK build. libcurl is failing
because of a missing include. This can be seen in the CI systems build
log [2] If someone knows the answer to this please can they apply it
to the toolchains repo and let me know. Once this is working I will
sort out adding this target to the libs and netsurf.
[1] http://ci.netsurf-browser.org/jenkins/computer/cislave9/
[2] http://ci.netsurf-browser.org/jenkins/job/toolchain-m68k-unknown-amigaos/6/console
--
Regards Vincent
http://www.kyllikki.org/
Friday, 19 December 2014
Re: BBC sites very slow.
On 19 Dec 2014 Jeremy Nicoll - ml netsurf
<jn.ml.nso.71@wingsandbeaks.org.uk> wrote:
> Peter Young <pnyoung@ormail.co.uk> wrote:
>>Good point. Using http://www.bbc.co.uk/weather/gl52 1 minute 20
>>seconds with RISC OS NetSurf, already on the icon bar; with Chrome in
>>Windows, again already running, less than 2 seconds. Is this worth a
>>bug report?
> It might be more interesting to compare the times for a subsequent fetch.
> The first one you did, form whatever OS, will have involved a lot of DNS
> lookups, whihc - apart from being managed by RO (or Netsuf itself?) and
> maybe cached there, may have been cached by your router.
> If the latter happened, that's one reason why the second fetch might have
> been a lot faster.
I've just done two fetches of the BBC weather site with RISC OS
NetSurf. They were both slow, but the second one was a bit less slow.
> I dunno about Chrome's facilities, but if you have Firefox, it has a set of
> developer's tools, one of which allows you to see all the things it does to
> fetch a page (eg fetch the base html, fetch the files that refers to, fetch
> the files the subsidiary ones referred to etc) and it will display the times
> taken for different stages of the overall process, showing you which bits
> took all the time.
Understanding that would be beyond my capabilities. O imagine some
relevant information would also be in NetSurf's logfile, but I
wouldn't understand that either. The thing that's puzzling me is that
this slowness has only happened recently, and doesn't affect other
websites.
Best wishes,
Peter Young.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
<jn.ml.nso.71@wingsandbeaks.org.uk> wrote:
> Peter Young <pnyoung@ormail.co.uk> wrote:
>>Good point. Using http://www.bbc.co.uk/weather/gl52 1 minute 20
>>seconds with RISC OS NetSurf, already on the icon bar; with Chrome in
>>Windows, again already running, less than 2 seconds. Is this worth a
>>bug report?
> It might be more interesting to compare the times for a subsequent fetch.
> The first one you did, form whatever OS, will have involved a lot of DNS
> lookups, whihc - apart from being managed by RO (or Netsuf itself?) and
> maybe cached there, may have been cached by your router.
> If the latter happened, that's one reason why the second fetch might have
> been a lot faster.
I've just done two fetches of the BBC weather site with RISC OS
NetSurf. They were both slow, but the second one was a bit less slow.
> I dunno about Chrome's facilities, but if you have Firefox, it has a set of
> developer's tools, one of which allows you to see all the things it does to
> fetch a page (eg fetch the base html, fetch the files that refers to, fetch
> the files the subsidiary ones referred to etc) and it will display the times
> taken for different stages of the overall process, showing you which bits
> took all the time.
Understanding that would be beyond my capabilities. O imagine some
relevant information would also be in NetSurf's logfile, but I
wouldn't understand that either. The thing that's puzzling me is that
this slowness has only happened recently, and doesn't affect other
websites.
Best wishes,
Peter Young.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: BBC sites very slow.
Peter Young <pnyoung@ormail.co.uk> wrote:
>Good point. Using http://www.bbc.co.uk/weather/gl52 1 minute 20
>seconds with RISC OS NetSurf, already on the icon bar; with Chrome in
>Windows, again already running, less than 2 seconds. Is this worth a
>bug report?
It might be more interesting to compare the times for a subsequent fetch.
The first one you did, form whatever OS, will have involved a lot of DNS
lookups, whihc - apart from being managed by RO (or Netsuf itself?) and
maybe cached there, may have been cached by your router.
If the latter happened, that's one reason why the second fetch might have
been a lot faster.
I dunno about Chrome's facilities, but if you have Firefox, it has a set of
developer's tools, one of which allows you to see all the things it does to
fetch a page (eg fetch the base html, fetch the files that refers to, fetch
the files the subsidiary ones referred to etc) and it will display the times
taken for different stages of the overall process, showing you which bits
took all the time.
--
Jeremy C B Nicoll - my opinions are my own.
>Good point. Using http://www.bbc.co.uk/weather/gl52 1 minute 20
>seconds with RISC OS NetSurf, already on the icon bar; with Chrome in
>Windows, again already running, less than 2 seconds. Is this worth a
>bug report?
It might be more interesting to compare the times for a subsequent fetch.
The first one you did, form whatever OS, will have involved a lot of DNS
lookups, whihc - apart from being managed by RO (or Netsuf itself?) and
maybe cached there, may have been cached by your router.
If the latter happened, that's one reason why the second fetch might have
been a lot faster.
I dunno about Chrome's facilities, but if you have Firefox, it has a set of
developer's tools, one of which allows you to see all the things it does to
fetch a page (eg fetch the base html, fetch the files that refers to, fetch
the files the subsidiary ones referred to etc) and it will display the times
taken for different stages of the overall process, showing you which bits
took all the time.
--
Jeremy C B Nicoll - my opinions are my own.
Thursday, 18 December 2014
Re: BBC sites very slow.
In message <235c187854.pnyoung@pnyoung.ormail.co.uk>
Peter Young <pnyoung@ormail.co.uk> wrote:
> On 18 Dec 2014 Brian Howlett <brian.groups@brianhowlett.me.uk> wrote:
>
>> On 18 Dec, Peter Young wrote:
>
>>> Using http://www.bbc.co.uk/weather/gl52 1 minute 20 seconds with RISC
>>> OS NetSurf, already on the icon bar
>
>> 12.1 seconds here, without Netsurf running, then 9.6 seconds on a
>> second load with Netsurf running.
>
>> Using CI #2441 on Iyonix with RO 5.20.
>
> 13 seconds here with NetSurf on the icon bar, so better than this
> morning, but still slow. Perhaps there's something odd with my setup.
> Would a logfile be helpful to anyone?
>
> #2441, ARMini, RISC OS 5.19
>
> Best wishes,
>
> Peter.
>
3.7 secs here (RaspPi 900Mhz, 5.21, NS 3.2)
--
George
Peter Young <pnyoung@ormail.co.uk> wrote:
> On 18 Dec 2014 Brian Howlett <brian.groups@brianhowlett.me.uk> wrote:
>
>> On 18 Dec, Peter Young wrote:
>
>>> Using http://www.bbc.co.uk/weather/gl52 1 minute 20 seconds with RISC
>>> OS NetSurf, already on the icon bar
>
>> 12.1 seconds here, without Netsurf running, then 9.6 seconds on a
>> second load with Netsurf running.
>
>> Using CI #2441 on Iyonix with RO 5.20.
>
> 13 seconds here with NetSurf on the icon bar, so better than this
> morning, but still slow. Perhaps there's something odd with my setup.
> Would a logfile be helpful to anyone?
>
> #2441, ARMini, RISC OS 5.19
>
> Best wishes,
>
> Peter.
>
3.7 secs here (RaspPi 900Mhz, 5.21, NS 3.2)
--
George
Re: BBC sites very slow.
On 18 Dec 2014 Brian Howlett <brian.groups@brianhowlett.me.uk> wrote:
> On 18 Dec, Peter Young wrote:
>> Using http://www.bbc.co.uk/weather/gl52 1 minute 20 seconds with RISC
>> OS NetSurf, already on the icon bar
> 12.1 seconds here, without Netsurf running, then 9.6 seconds on a
> second load with Netsurf running.
> Using CI #2441 on Iyonix with RO 5.20.
13 seconds here with NetSurf on the icon bar, so better than this
morning, but still slow. Perhaps there's something odd with my setup.
Would a logfile be helpful to anyone?
#2441, ARMini, RISC OS 5.19
Best wishes,
Peter.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> On 18 Dec, Peter Young wrote:
>> Using http://www.bbc.co.uk/weather/gl52 1 minute 20 seconds with RISC
>> OS NetSurf, already on the icon bar
> 12.1 seconds here, without Netsurf running, then 9.6 seconds on a
> second load with Netsurf running.
> Using CI #2441 on Iyonix with RO 5.20.
13 seconds here with NetSurf on the icon bar, so better than this
morning, but still slow. Perhaps there's something odd with my setup.
Would a logfile be helpful to anyone?
#2441, ARMini, RISC OS 5.19
Best wishes,
Peter.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: BBC sites very slow.
On 18 Dec, Peter Young wrote:
> Using http://www.bbc.co.uk/weather/gl52 1 minute 20 seconds with RISC
> OS NetSurf, already on the icon bar
12.1 seconds here, without Netsurf running, then 9.6 seconds on a
second load with Netsurf running.
Using CI #2441 on Iyonix with RO 5.20.
--
Brian Howlett
--------------------------------
"I'm Brian, and so's my wife..."
> Using http://www.bbc.co.uk/weather/gl52 1 minute 20 seconds with RISC
> OS NetSurf, already on the icon bar
12.1 seconds here, without Netsurf running, then 9.6 seconds on a
second load with Netsurf running.
Using CI #2441 on Iyonix with RO 5.20.
--
Brian Howlett
--------------------------------
"I'm Brian, and so's my wife..."
Re: BBC sites very slow.
On 18 Dec 2014 Malcolm Hussain-Gambles <malcolm@paymentlabs.com>
wrote:
> An unashamed plug for my two apps - doesn't help netsurf though.
> Newsuk and weatheruk pull the data off the BBC. Available on the
> plingstore (free).
> Cheers
> Malcolm
Yes, I've got them both. I must remember the the weather one!
Peter.
> On 18 Dec 2014, Peter Young <pnyoung@ormail.co.uk> wrote:
>>On 18 Dec 2014 David Pitt <pittdj@pittdj.co.uk> wrote:
>>
>>> Peter Young, on 18 Dec, wrote:
>>
>>>> On 17 Dec 2014 Steve Fryatt <lists@stevefryatt.org.uk> wrote:
>>>>
>>>>> On 17 Dec, Peter Young wrote in message
>>>>> <22e59c7754.pnyoung@pnyoung.ormail.co.uk>:
>>>>
>>>>>> This is with RISC OS and development builds, currently #2441, but
>>has
>>>>>> been happening for several days now.
>>>>>>
>>>>>> Any of the BBC sires are now taking a lot longer to download,
>>maybe by
>>>>>> a factor of five to ten times as long. They are now even slower
>>than
>>>>>> the www.msscociety.org.uk sites which till now have been the
>>slowest
>>>>>> to download. I've checked my connection speed, and it's much the
>>same
>>>>>> as usual.
>>>>>>
>>>>>> Is this a problem with NetSurf or with the BBC sites? I suspect
>>the
>>>>>> latter.
>>>>
>>>>> Have you done the same comparison using another browser (on another
>>OS),
>>>>> to confirm that it's actually NetSurf and not the sites themselves?
>>For
>>>>> many sites, your connection speed won't be the limiting factor.
>>>>
>>>> Good point. Using http://www.bbc.co.uk/weather/gl52 1 minute 20
>>seconds
>>>> with RISC OS NetSurf, already on the icon bar; with Chrome in
>>Windows,
>>>> again already running, less than 2 seconds. Is this worth a bug
>>report?
>>
>>> NetSurf #2441 downloads the weather in 4.6s on the RaspberryPi.
>>
>>> Is there by any chance spurious junk in a previously used NetSurf
>>Cache?
>>
>>No, I gave up using the disc cache, as it made everything very slow.
>>
>>Best wishes,
>>
>>Peter.
> -- Sent with K-@ Mail - the evolution of emailing.
wrote:
> An unashamed plug for my two apps - doesn't help netsurf though.
> Newsuk and weatheruk pull the data off the BBC. Available on the
> plingstore (free).
> Cheers
> Malcolm
Yes, I've got them both. I must remember the the weather one!
Peter.
> On 18 Dec 2014, Peter Young <pnyoung@ormail.co.uk> wrote:
>>On 18 Dec 2014 David Pitt <pittdj@pittdj.co.uk> wrote:
>>
>>> Peter Young, on 18 Dec, wrote:
>>
>>>> On 17 Dec 2014 Steve Fryatt <lists@stevefryatt.org.uk> wrote:
>>>>
>>>>> On 17 Dec, Peter Young wrote in message
>>>>> <22e59c7754.pnyoung@pnyoung.ormail.co.uk>:
>>>>
>>>>>> This is with RISC OS and development builds, currently #2441, but
>>has
>>>>>> been happening for several days now.
>>>>>>
>>>>>> Any of the BBC sires are now taking a lot longer to download,
>>maybe by
>>>>>> a factor of five to ten times as long. They are now even slower
>>than
>>>>>> the www.msscociety.org.uk sites which till now have been the
>>slowest
>>>>>> to download. I've checked my connection speed, and it's much the
>>same
>>>>>> as usual.
>>>>>>
>>>>>> Is this a problem with NetSurf or with the BBC sites? I suspect
>>the
>>>>>> latter.
>>>>
>>>>> Have you done the same comparison using another browser (on another
>>OS),
>>>>> to confirm that it's actually NetSurf and not the sites themselves?
>>For
>>>>> many sites, your connection speed won't be the limiting factor.
>>>>
>>>> Good point. Using http://www.bbc.co.uk/weather/gl52 1 minute 20
>>seconds
>>>> with RISC OS NetSurf, already on the icon bar; with Chrome in
>>Windows,
>>>> again already running, less than 2 seconds. Is this worth a bug
>>report?
>>
>>> NetSurf #2441 downloads the weather in 4.6s on the RaspberryPi.
>>
>>> Is there by any chance spurious junk in a previously used NetSurf
>>Cache?
>>
>>No, I gave up using the disc cache, as it made everything very slow.
>>
>>Best wishes,
>>
>>Peter.
> -- Sent with K-@ Mail - the evolution of emailing.
Re: BBC sites very slow.
An unashamed plug for my two apps - doesn't help netsurf though.
Newsuk and weatheruk pull the data off the BBC. Available on the plingstore (free).
Cheers
Malcolm
-- Sent with K-@ Mail - the evolution of emailing.
Newsuk and weatheruk pull the data off the BBC. Available on the plingstore (free).
Cheers
Malcolm
On 18 Dec 2014, Peter Young <pnyoung@ormail.co.uk> wrote:
On 18 Dec 2014 David Pitt <pittdj@pittdj.co.uk> wrote:Peter Young, on 18 Dec, wrote:On 17 Dec 2014 Steve Fryatt <lists@stevefryatt.org.uk> wrote:On 17 Dec, Peter Young wrote in message
<22e59c7754.pnyoung@pnyoung.ormail.co.uk>:This is with RISC OS and development builds, currently #2441, but has
been happening for several days now.
Any of the BBC sires are now taking a lot longer to download, maybe by
a factor of five to ten times as long. They are now even slower than
the www.msscociety.org.uk sites which till now have been the slowest
to download. I've checked my connection speed, and it's much the same
as usual.
Is this a problem with NetSurf or with the BBC sites? I suspect the
latter.
Have you done the same comparison using another browser (on another OS),
to confirm that it's actually NetSurf and not the sites themselves? For
many sites, your connection speed won't be the limiting factor.
Good point. Using http://www.bbc.co.uk/weather/gl52 1 minute 20 seconds
with RISC OS NetSurf, already on the icon bar; with Chrome in Windows,
again already running, less than 2 seconds. Is this worth a bug report?
NetSurf #2441 downloads the weather in 4.6s on the RaspberryPi.
Is there by any chance spurious junk in a previously used NetSurf Cache?
No, I gave up using the disc cache, as it made everything very slow.
Best wishes,
Peter.
-- Sent with K-@ Mail - the evolution of emailing.
Re: BBC sites very slow.
On 18 Dec 2014 David Pitt <pittdj@pittdj.co.uk> wrote:
> Peter Young, on 18 Dec, wrote:
>> On 17 Dec 2014 Steve Fryatt <lists@stevefryatt.org.uk> wrote:
>>
>>> On 17 Dec, Peter Young wrote in message
>>> <22e59c7754.pnyoung@pnyoung.ormail.co.uk>:
>>
>>>> This is with RISC OS and development builds, currently #2441, but has
>>>> been happening for several days now.
>>>>
>>>> Any of the BBC sires are now taking a lot longer to download, maybe by
>>>> a factor of five to ten times as long. They are now even slower than
>>>> the www.msscociety.org.uk sites which till now have been the slowest
>>>> to download. I've checked my connection speed, and it's much the same
>>>> as usual.
>>>>
>>>> Is this a problem with NetSurf or with the BBC sites? I suspect the
>>>> latter.
>>
>>> Have you done the same comparison using another browser (on another OS),
>>> to confirm that it's actually NetSurf and not the sites themselves? For
>>> many sites, your connection speed won't be the limiting factor.
>>
>> Good point. Using http://www.bbc.co.uk/weather/gl52 1 minute 20 seconds
>> with RISC OS NetSurf, already on the icon bar; with Chrome in Windows,
>> again already running, less than 2 seconds. Is this worth a bug report?
> NetSurf #2441 downloads the weather in 4.6s on the RaspberryPi.
> Is there by any chance spurious junk in a previously used NetSurf Cache?
No, I gave up using the disc cache, as it made everything very slow.
Best wishes,
Peter.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> Peter Young, on 18 Dec, wrote:
>> On 17 Dec 2014 Steve Fryatt <lists@stevefryatt.org.uk> wrote:
>>
>>> On 17 Dec, Peter Young wrote in message
>>> <22e59c7754.pnyoung@pnyoung.ormail.co.uk>:
>>
>>>> This is with RISC OS and development builds, currently #2441, but has
>>>> been happening for several days now.
>>>>
>>>> Any of the BBC sires are now taking a lot longer to download, maybe by
>>>> a factor of five to ten times as long. They are now even slower than
>>>> the www.msscociety.org.uk sites which till now have been the slowest
>>>> to download. I've checked my connection speed, and it's much the same
>>>> as usual.
>>>>
>>>> Is this a problem with NetSurf or with the BBC sites? I suspect the
>>>> latter.
>>
>>> Have you done the same comparison using another browser (on another OS),
>>> to confirm that it's actually NetSurf and not the sites themselves? For
>>> many sites, your connection speed won't be the limiting factor.
>>
>> Good point. Using http://www.bbc.co.uk/weather/gl52 1 minute 20 seconds
>> with RISC OS NetSurf, already on the icon bar; with Chrome in Windows,
>> again already running, less than 2 seconds. Is this worth a bug report?
> NetSurf #2441 downloads the weather in 4.6s on the RaspberryPi.
> Is there by any chance spurious junk in a previously used NetSurf Cache?
No, I gave up using the disc cache, as it made everything very slow.
Best wishes,
Peter.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: BBC sites very slow.
Peter Young, on 18 Dec, wrote:
> On 17 Dec 2014 Steve Fryatt <lists@stevefryatt.org.uk> wrote:
>
> > On 17 Dec, Peter Young wrote in message
> > <22e59c7754.pnyoung@pnyoung.ormail.co.uk>:
>
> > > This is with RISC OS and development builds, currently #2441, but has
> > > been happening for several days now.
> >>
> > > Any of the BBC sires are now taking a lot longer to download, maybe by
> > > a factor of five to ten times as long. They are now even slower than
> > > the www.msscociety.org.uk sites which till now have been the slowest
> > > to download. I've checked my connection speed, and it's much the same
> > > as usual.
> >>
> > > Is this a problem with NetSurf or with the BBC sites? I suspect the
> > > latter.
>
> > Have you done the same comparison using another browser (on another OS),
> > to confirm that it's actually NetSurf and not the sites themselves? For
> > many sites, your connection speed won't be the limiting factor.
>
> Good point. Using http://www.bbc.co.uk/weather/gl52 1 minute 20 seconds
> with RISC OS NetSurf, already on the icon bar; with Chrome in Windows,
> again already running, less than 2 seconds. Is this worth a bug report?
NetSurf #2441 downloads the weather in 4.6s on the RaspberryPi.
Is there by any chance spurious junk in a previously used NetSurf Cache?
--
David Pitt
> On 17 Dec 2014 Steve Fryatt <lists@stevefryatt.org.uk> wrote:
>
> > On 17 Dec, Peter Young wrote in message
> > <22e59c7754.pnyoung@pnyoung.ormail.co.uk>:
>
> > > This is with RISC OS and development builds, currently #2441, but has
> > > been happening for several days now.
> >>
> > > Any of the BBC sires are now taking a lot longer to download, maybe by
> > > a factor of five to ten times as long. They are now even slower than
> > > the www.msscociety.org.uk sites which till now have been the slowest
> > > to download. I've checked my connection speed, and it's much the same
> > > as usual.
> >>
> > > Is this a problem with NetSurf or with the BBC sites? I suspect the
> > > latter.
>
> > Have you done the same comparison using another browser (on another OS),
> > to confirm that it's actually NetSurf and not the sites themselves? For
> > many sites, your connection speed won't be the limiting factor.
>
> Good point. Using http://www.bbc.co.uk/weather/gl52 1 minute 20 seconds
> with RISC OS NetSurf, already on the icon bar; with Chrome in Windows,
> again already running, less than 2 seconds. Is this worth a bug report?
NetSurf #2441 downloads the weather in 4.6s on the RaspberryPi.
Is there by any chance spurious junk in a previously used NetSurf Cache?
--
David Pitt
Re: BBC sites very slow.
On 17 Dec 2014 george greenfield <george.greenfield@tiscali.co.uk>
wrote:
> In message <a564a07754.pnyoung@pnyoung.ormail.co.uk>
> Peter Young <pnyoung@ormail.co.uk> wrote:
>> On 17 Dec 2014 Peter Young <pnyoung@ormail.co.uk> wrote:
>>
>>> This is with RISC OS and development builds, currently #2441, but has
>>> been happening for several days now.
>>
>>> Any of the BBC sites are now taking a lot longer to download, maybe by
>>> a factor of five to ten times as long. They are now even slower than
>>> the www.msscociety.org.uk sites which till now have been the slowest
>>
>> Sorry, typo. http://www.mssociety.org.uk/
>>
>>
>>> to download. I've checked my connection speed, and it's much the same
>>> as usual.
>>
>>> Is this a problem with NetSurf or with the BBC sites? I suspect the
>>> latter.
>>
>>> Best wishes,
>>
>>> Peter.
>>
>>
> Haven't noticed the Beeb being slow, but the MS Society link you gave
> loaded here in 4.7 secs, the forum link in 0.7 and the support link in
> 2.6 secs respectively - I wouldn't call that slow, personally. Setup
> is a RaspPi RO 5.21 (900Mhz) running NS 3.2 official release.
7 seconds to the MS/Cheltnham site, and 5 seconds from this to the
forum. Roughly the same timings with Chrome on Windows. This is a lot
quicker than normal with both platforms.
Best wishes,
Peter.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
wrote:
> In message <a564a07754.pnyoung@pnyoung.ormail.co.uk>
> Peter Young <pnyoung@ormail.co.uk> wrote:
>> On 17 Dec 2014 Peter Young <pnyoung@ormail.co.uk> wrote:
>>
>>> This is with RISC OS and development builds, currently #2441, but has
>>> been happening for several days now.
>>
>>> Any of the BBC sites are now taking a lot longer to download, maybe by
>>> a factor of five to ten times as long. They are now even slower than
>>> the www.msscociety.org.uk sites which till now have been the slowest
>>
>> Sorry, typo. http://www.mssociety.org.uk/
>>
>>
>>> to download. I've checked my connection speed, and it's much the same
>>> as usual.
>>
>>> Is this a problem with NetSurf or with the BBC sites? I suspect the
>>> latter.
>>
>>> Best wishes,
>>
>>> Peter.
>>
>>
> Haven't noticed the Beeb being slow, but the MS Society link you gave
> loaded here in 4.7 secs, the forum link in 0.7 and the support link in
> 2.6 secs respectively - I wouldn't call that slow, personally. Setup
> is a RaspPi RO 5.21 (900Mhz) running NS 3.2 official release.
7 seconds to the MS/Cheltnham site, and 5 seconds from this to the
forum. Roughly the same timings with Chrome on Windows. This is a lot
quicker than normal with both platforms.
Best wishes,
Peter.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: BBC sites very slow.
On 17 Dec 2014 Steve Fryatt <lists@stevefryatt.org.uk> wrote:
> On 17 Dec, Peter Young wrote in message
> <22e59c7754.pnyoung@pnyoung.ormail.co.uk>:
>> This is with RISC OS and development builds, currently #2441, but has been
>> happening for several days now.
>>
>> Any of the BBC sires are now taking a lot longer to download, maybe by a
>> factor of five to ten times as long. They are now even slower than the
>> www.msscociety.org.uk sites which till now have been the slowest to
>> download. I've checked my connection speed, and it's much the same as
>> usual.
>>
>> Is this a problem with NetSurf or with the BBC sites? I suspect the
>> latter.
> Have you done the same comparison using another browser (on another OS), to
> confirm that it's actually NetSurf and not the sites themselves? For many
> sites, your connection speed won't be the limiting factor.
Good point. Using http://www.bbc.co.uk/weather/gl52 1 minute 20
seconds with RISC OS NetSurf, already on the icon bar; with Chrome in
Windows, again already running, less than 2 seconds. Is this worth a
bug report?
Best wishes,
Peter.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> On 17 Dec, Peter Young wrote in message
> <22e59c7754.pnyoung@pnyoung.ormail.co.uk>:
>> This is with RISC OS and development builds, currently #2441, but has been
>> happening for several days now.
>>
>> Any of the BBC sires are now taking a lot longer to download, maybe by a
>> factor of five to ten times as long. They are now even slower than the
>> www.msscociety.org.uk sites which till now have been the slowest to
>> download. I've checked my connection speed, and it's much the same as
>> usual.
>>
>> Is this a problem with NetSurf or with the BBC sites? I suspect the
>> latter.
> Have you done the same comparison using another browser (on another OS), to
> confirm that it's actually NetSurf and not the sites themselves? For many
> sites, your connection speed won't be the limiting factor.
Good point. Using http://www.bbc.co.uk/weather/gl52 1 minute 20
seconds with RISC OS NetSurf, already on the icon bar; with Chrome in
Windows, again already running, less than 2 seconds. Is this worth a
bug report?
Best wishes,
Peter.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Wednesday, 17 December 2014
Re: BBC sites very slow.
In message <a564a07754.pnyoung@pnyoung.ormail.co.uk>
Peter Young <pnyoung@ormail.co.uk> wrote:
> On 17 Dec 2014 Peter Young <pnyoung@ormail.co.uk> wrote:
>
>> This is with RISC OS and development builds, currently #2441, but has
>> been happening for several days now.
>
>> Any of the BBC sites are now taking a lot longer to download, maybe by
>> a factor of five to ten times as long. They are now even slower than
>> the www.msscociety.org.uk sites which till now have been the slowest
>
> Sorry, typo. http://www.mssociety.org.uk/
>
>
>> to download. I've checked my connection speed, and it's much the same
>> as usual.
>
>> Is this a problem with NetSurf or with the BBC sites? I suspect the
>> latter.
>
>> Best wishes,
>
>> Peter.
>
>
Haven't noticed the Beeb being slow, but the MS Society link you gave
loaded here in 4.7 secs, the forum link in 0.7 and the support link in
2.6 secs respectively - I wouldn't call that slow, personally. Setup
is a RaspPi RO 5.21 (900Mhz) running NS 3.2 official release.
--
George
Peter Young <pnyoung@ormail.co.uk> wrote:
> On 17 Dec 2014 Peter Young <pnyoung@ormail.co.uk> wrote:
>
>> This is with RISC OS and development builds, currently #2441, but has
>> been happening for several days now.
>
>> Any of the BBC sites are now taking a lot longer to download, maybe by
>> a factor of five to ten times as long. They are now even slower than
>> the www.msscociety.org.uk sites which till now have been the slowest
>
> Sorry, typo. http://www.mssociety.org.uk/
>
>
>> to download. I've checked my connection speed, and it's much the same
>> as usual.
>
>> Is this a problem with NetSurf or with the BBC sites? I suspect the
>> latter.
>
>> Best wishes,
>
>> Peter.
>
>
Haven't noticed the Beeb being slow, but the MS Society link you gave
loaded here in 4.7 secs, the forum link in 0.7 and the support link in
2.6 secs respectively - I wouldn't call that slow, personally. Setup
is a RaspPi RO 5.21 (900Mhz) running NS 3.2 official release.
--
George
Re: BBC sites very slow.
On 17 Dec, Peter Young wrote in message
<22e59c7754.pnyoung@pnyoung.ormail.co.uk>:
> This is with RISC OS and development builds, currently #2441, but has been
> happening for several days now.
>
> Any of the BBC sires are now taking a lot longer to download, maybe by a
> factor of five to ten times as long. They are now even slower than the
> www.msscociety.org.uk sites which till now have been the slowest to
> download. I've checked my connection speed, and it's much the same as
> usual.
>
> Is this a problem with NetSurf or with the BBC sites? I suspect the
> latter.
Have you done the same comparison using another browser (on another OS), to
confirm that it's actually NetSurf and not the sites themselves? For many
sites, your connection speed won't be the limiting factor.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
<22e59c7754.pnyoung@pnyoung.ormail.co.uk>:
> This is with RISC OS and development builds, currently #2441, but has been
> happening for several days now.
>
> Any of the BBC sires are now taking a lot longer to download, maybe by a
> factor of five to ten times as long. They are now even slower than the
> www.msscociety.org.uk sites which till now have been the slowest to
> download. I've checked my connection speed, and it's much the same as
> usual.
>
> Is this a problem with NetSurf or with the BBC sites? I suspect the
> latter.
Have you done the same comparison using another browser (on another OS), to
confirm that it's actually NetSurf and not the sites themselves? For many
sites, your connection speed won't be the limiting factor.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
Re: BBC sites very slow.
On 17 Dec 2014 Peter Young <pnyoung@ormail.co.uk> wrote:
> This is with RISC OS and development builds, currently #2441, but has
> been happening for several days now.
> Any of the BBC sites are now taking a lot longer to download, maybe by
> a factor of five to ten times as long. They are now even slower than
> the www.msscociety.org.uk sites which till now have been the slowest
Sorry, typo. http://www.mssociety.org.uk/
> to download. I've checked my connection speed, and it's much the same
> as usual.
> Is this a problem with NetSurf or with the BBC sites? I suspect the
> latter.
> Best wishes,
> Peter.
> This is with RISC OS and development builds, currently #2441, but has
> been happening for several days now.
> Any of the BBC sites are now taking a lot longer to download, maybe by
> a factor of five to ten times as long. They are now even slower than
> the www.msscociety.org.uk sites which till now have been the slowest
Sorry, typo. http://www.mssociety.org.uk/
> to download. I've checked my connection speed, and it's much the same
> as usual.
> Is this a problem with NetSurf or with the BBC sites? I suspect the
> latter.
> Best wishes,
> Peter.
Re: BBC sites very slow.
Peter Young <pnyoung@ormail.co.uk> wrote:
>Is this a problem with NetSurf or with the BBC sites? I suspect the
>latter.
Maybe the season - too many people researching their christmas shopping etc?
Everywhere I've tried to browse today has been very slow, with Firefox on a
very fast broadband connection.
--
Jeremy C B Nicoll - my opinions are my own.
>Is this a problem with NetSurf or with the BBC sites? I suspect the
>latter.
Maybe the season - too many people researching their christmas shopping etc?
Everywhere I've tried to browse today has been very slow, with Firefox on a
very fast broadband connection.
--
Jeremy C B Nicoll - my opinions are my own.
BBC sites very slow.
This is with RISC OS and development builds, currently #2441, but has
been happening for several days now.
Any of the BBC sires are now taking a lot longer to download, maybe by
a factor of five to ten times as long. They are now even slower than
the www.msscociety.org.uk sites which till now have been the slowest
to download. I've checked my connection speed, and it's much the same
as usual.
Is this a problem with NetSurf or with the BBC sites? I suspect the
latter.
Best wishes,
Peter.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
been happening for several days now.
Any of the BBC sires are now taking a lot longer to download, maybe by
a factor of five to ten times as long. They are now even slower than
the www.msscociety.org.uk sites which till now have been the slowest
to download. I've checked my connection speed, and it's much the same
as usual.
Is this a problem with NetSurf or with the BBC sites? I suspect the
latter.
Best wishes,
Peter.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Tuesday, 16 December 2014
Re: unicode Font initialization problem
In article <00e601d0194c$ae4b1730$0ae14590$@hughes@blueyonder.co.uk>,
Bob Hughes <bob.hughes@blueyonder.co.uk> wrote:
> I am running Riscos Select 6.1 kernel 10.49 under Virtual RISCPC
> with EasyFont Pro 5.03.
I do not think that RISC OS 6 has a unicode capable font manager does
it?
--
Chris Johnson
Bob Hughes <bob.hughes@blueyonder.co.uk> wrote:
> I am running Riscos Select 6.1 kernel 10.49 under Virtual RISCPC
> with EasyFont Pro 5.03.
I do not think that RISC OS 6 has a unicode capable font manager does
it?
--
Chris Johnson
Re: unicode Font initialization problem
In article <00e601d0194c$ae4b1730$0ae14590$@hughes@blueyonder.co.uk>,
Bob Hughes <bob.hughes@blueyonder.co.uk> wrote:
> Trying to run Netsurf results in "the Unicode Font library could
> not be initialized. Please report this to the developers."
You have merged the !Boot supplied with Netsurf? This contains the
!Unicode resources.
--
Chris Johnson
Bob Hughes <bob.hughes@blueyonder.co.uk> wrote:
> Trying to run Netsurf results in "the Unicode Font library could
> not be initialized. Please report this to the developers."
You have merged the !Boot supplied with Netsurf? This contains the
!Unicode resources.
--
Chris Johnson
unicode Font initialization problem
I am running Riscos Select 6.1 kernel 10.49 under Virtual RISCPC with EasyFont Pro 5.03.
Trying to run Netsurf results in “the Unicode Font library could not be initialized. Please report this to the developers.”
I tried the latest version 3.2 and then backwards versions with the same result.
I have googled and found similar errors and discussions but no fix?
If anybody can direct me to fix I’d be very grateful or do I need to switch to Firefox??
Grateful for any advice and my apologies if this has been sorted already.
TIA
Bob Hughes
Re: Fwd: Netsurf Porting
On Tue, Dec 16, 2014 at 05:59:20PM +0530, Honey Sukesan wrote:
> 1. First of all, a direct question. Is Netsurf supported in QNX 4.25?
QNX 4 is very old! I'm not even sure if the Wacom-based C compiler it
ships with will be able to compile anything reasonably modern (we use
C99 extensively). Have things changed on this front?
> 2. We understood that NetSurf has different front ends like SDL,
> framebuffer, GTK etc. But haven't seen support for Photon GUI toolkit
> supported in QNX. We are quite confused on the framebuffer/SDL support in
> QNX 4.25.
There is no current support for Photon, either QNX 4's or 6's. If there
is an SDL port to QNX 4, it may build against that.
> We assume this toolkit may be used only by the browser part to get the user
> interface part. If so, can it be possible for us to only to port the
> rendering engine part to QNX 4.25 and use the Photon APIs in QNX for the
> front end part?
Yes, that's how the various front ends work; the renderer is shared.
> 3. If query #2 is not a possible option, could you share your thoughts on
> porting Netsurf to such an OS like us where any of these front ends are not
> supported?
You get to write the code for that :)
B.
> 1. First of all, a direct question. Is Netsurf supported in QNX 4.25?
QNX 4 is very old! I'm not even sure if the Wacom-based C compiler it
ships with will be able to compile anything reasonably modern (we use
C99 extensively). Have things changed on this front?
> 2. We understood that NetSurf has different front ends like SDL,
> framebuffer, GTK etc. But haven't seen support for Photon GUI toolkit
> supported in QNX. We are quite confused on the framebuffer/SDL support in
> QNX 4.25.
There is no current support for Photon, either QNX 4's or 6's. If there
is an SDL port to QNX 4, it may build against that.
> We assume this toolkit may be used only by the browser part to get the user
> interface part. If so, can it be possible for us to only to port the
> rendering engine part to QNX 4.25 and use the Photon APIs in QNX for the
> front end part?
Yes, that's how the various front ends work; the renderer is shared.
> 3. If query #2 is not a possible option, could you share your thoughts on
> porting Netsurf to such an OS like us where any of these front ends are not
> supported?
You get to write the code for that :)
B.
Fwd: Netsurf Porting
Dear all,
A very good day to all of you.
We have read about Netsurf very recently.Seems very interesting for us as we are looking into porting a rendering engine with HTML4 support to QNX 4.25 platform.
1. First of all, a direct question. Is Netsurf supported in QNX 4.25?
2. We understood that NetSurf has different front ends like SDL, framebuffer, GTK etc. But haven't seen support for Photon GUI toolkit supported in QNX. We are quite confused on the framebuffer/SDL support in QNX 4.25. Looking forward to hear from you soon.
Thanking you in advance, Lullaby
Monday, 15 December 2014
[Rpcemu] Networking: second try
And that's what you get for replying on a smartphone. Missing middle paragraph:
"Early next week I will bite the bullet and restore the RPCEmu network
bridge and see if I can replicate your problem."
Cheerio!
Mike
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
"Early next week I will bite the bullet and restore the RPCEmu network
bridge and see if I can replicate your problem."
Cheerio!
Mike
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Sunday, 14 December 2014
Re: Image Link issue
I had a quick look at the code with the Inspect tool in Firefox (nice
feature) and the image links don't look particularly unusual apart from a
JS onclick for Google analytics.
I have reported it:
http://bugs.netsurf-browser.org/mantis/view.php?id=2243
Peter
feature) and the image links don't look particularly unusual apart from a
JS onclick for Google analytics.
I have reported it:
http://bugs.netsurf-browser.org/mantis/view.php?id=2243
Peter
[Rpcemu] Networking
I can't check the below for sure as I've stopped using the networking
on RPCEmu because the RPCEmu bridge interfered with VirtualBox's
bridge.
I was able to see a shared drive on the VRPC using, IIRC, !Samba.
Cheerio!
Mike
On 7 December 2014 at 20:00, <rpcemu-request@riscos.info> wrote:
> Send Rpcemu mailing list submissions to
> rpcemu@riscos.info
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> or, via email, send a message with subject or body 'help' to
> rpcemu-request@riscos.info
>
> You can reach the person managing the list at
> rpcemu-owner@riscos.info
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Rpcemu digest..."
>
>
> Today's Topics:
>
> 1. Network problems (Dave Symes)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 06 Dec 2014 21:40:30 +0000 (GMT)
> From: Dave Symes <dave@triffid.co.uk>
> To: <rpcemu@riscos.info>
> Subject: [Rpcemu] Network problems
> Message-ID: <5471f436cadave@triffid.co.uk>
> Content-Type: text/plain
>
> I'm wondering if anyone here intimately connected with RPCEmu might have
> some insights into the problem.
> I've been banging my head against a wall on comp.sys.acorn.networking, and
> while chaps have been trying to help, and we've been through/eliminated a
> lot of stuff, the problem remains.
>
> RPCEmu 0.8.12 running RO 6.20 (But same problem with 4.39 and 5.21)
>
> RPCEmu Networking is setup as per instructions, and the install has an IP
> address of 192.168.0.13.
>
> The Win 7 Pro SP1 64 bit PC had the network adaptor bridged as per
> instructions, right down to the cli commands.
>
> To all intents and purposes the RPCEmu networking has done for some time,
> and continues to work okay.
> Down/upload Post, News. Browse etc, but there's on thing it won't do and
> that's announce itself on the network.
>
> >From RPCEmu using ShareFS it can see other RO installs on the network, but
> none of the other RO installs can see it.
>
> Any first thoughts before we get into what I've tried over the past week.
>
> Thanks
> Dave
>
> --
>
> Dave Triffid
>
>
>
> ------------------------------
>
> _______________________________________________
> Rpcemu mailing list
> Rpcemu@riscos.info
> http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
>
>
> End of Rpcemu Digest, Vol 88, Issue 2
> *************************************
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
on RPCEmu because the RPCEmu bridge interfered with VirtualBox's
bridge.
I was able to see a shared drive on the VRPC using, IIRC, !Samba.
Cheerio!
Mike
On 7 December 2014 at 20:00, <rpcemu-request@riscos.info> wrote:
> Send Rpcemu mailing list submissions to
> rpcemu@riscos.info
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> or, via email, send a message with subject or body 'help' to
> rpcemu-request@riscos.info
>
> You can reach the person managing the list at
> rpcemu-owner@riscos.info
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Rpcemu digest..."
>
>
> Today's Topics:
>
> 1. Network problems (Dave Symes)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 06 Dec 2014 21:40:30 +0000 (GMT)
> From: Dave Symes <dave@triffid.co.uk>
> To: <rpcemu@riscos.info>
> Subject: [Rpcemu] Network problems
> Message-ID: <5471f436cadave@triffid.co.uk>
> Content-Type: text/plain
>
> I'm wondering if anyone here intimately connected with RPCEmu might have
> some insights into the problem.
> I've been banging my head against a wall on comp.sys.acorn.networking, and
> while chaps have been trying to help, and we've been through/eliminated a
> lot of stuff, the problem remains.
>
> RPCEmu 0.8.12 running RO 6.20 (But same problem with 4.39 and 5.21)
>
> RPCEmu Networking is setup as per instructions, and the install has an IP
> address of 192.168.0.13.
>
> The Win 7 Pro SP1 64 bit PC had the network adaptor bridged as per
> instructions, right down to the cli commands.
>
> To all intents and purposes the RPCEmu networking has done for some time,
> and continues to work okay.
> Down/upload Post, News. Browse etc, but there's on thing it won't do and
> that's announce itself on the network.
>
> >From RPCEmu using ShareFS it can see other RO installs on the network, but
> none of the other RO installs can see it.
>
> Any first thoughts before we get into what I've tried over the past week.
>
> Thanks
> Dave
>
> --
>
> Dave Triffid
>
>
>
> ------------------------------
>
> _______________________________________________
> Rpcemu mailing list
> Rpcemu@riscos.info
> http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
>
>
> End of Rpcemu Digest, Vol 88, Issue 2
> *************************************
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Saturday, 13 December 2014
Re: Image Link issue
On Sat, 13 Dec 2014 15:26:52 +0000 (GMT), Peter Slegg wrote:
> http://www.express.co.uk/news/nature/546649/Geminids-meteor-shower-live-stream-best-places-to-watch
>
> On the page above there are image links down the right-hand
> side.
>
> The top one is shown with the wrong width.
>
> The numbered ones are ok but when the mouse is moved over the
> ones further down the link shown is the same for all the images
> and when it is clicked the same page is opened regarless of the
> image.
>
> This is with Atari build no. 2427
>
> Can someone confirm this with other versions ?
Getting the same here with the Amiga frontend. Also the top banner
cuts off on the right, ie. "LIFE & STYLE PUZZLES P".
There are bits of banner behind the text of the top items in each
"block" of pictures, which looks wrong too - one of those is
apparently Stuart Winter. There's two lots of text over the top
of him which has appropriate ALT text, but the links both point to his
column - which is all about birds and nothing to do with the text
(which is asteriods, and weather bombs).
I suspect it all stems from some CSS we either don't support yet or
isn't being handled correctly. Put it on the big tracker.
Chris
> http://www.express.co.uk/news/nature/546649/Geminids-meteor-shower-live-stream-best-places-to-watch
>
> On the page above there are image links down the right-hand
> side.
>
> The top one is shown with the wrong width.
>
> The numbered ones are ok but when the mouse is moved over the
> ones further down the link shown is the same for all the images
> and when it is clicked the same page is opened regarless of the
> image.
>
> This is with Atari build no. 2427
>
> Can someone confirm this with other versions ?
Getting the same here with the Amiga frontend. Also the top banner
cuts off on the right, ie. "LIFE & STYLE PUZZLES P".
There are bits of banner behind the text of the top items in each
"block" of pictures, which looks wrong too - one of those is
apparently Stuart Winter. There's two lots of text over the top
of him which has appropriate ALT text, but the links both point to his
column - which is all about birds and nothing to do with the text
(which is asteriods, and weather bombs).
I suspect it all stems from some CSS we either don't support yet or
isn't being handled correctly. Put it on the big tracker.
Chris
Re: Image Link issue
In article <00195d22.01ffd490d93c@smtp.freeola.net>,
Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
> Can someone confirm this with other versions ?
Same here with #2438 under RISC OS.
John
--
| John Williams
| johnrw@ukgateway.net
Magic tricks are like boiled eggs - hard to see how they are done *
Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
> Can someone confirm this with other versions ?
Same here with #2438 under RISC OS.
John
--
| John Williams
| johnrw@ukgateway.net
Magic tricks are like boiled eggs - hard to see how they are done *
Image Link issue
http://www.express.co.uk/news/nature/546649/Geminids-meteor-shower-live-stream-best-places-to-watch
On the page above there are image links down the right-hand
side.
The top one is shown with the wrong width.
The numbered ones are ok but when the mouse is moved over the
ones further down the link shown is the same for all the images
and when it is clicked the same page is opened regarless of the
image.
This is with Atari build no. 2427
Can someone confirm this with other versions ?
Peter
On the page above there are image links down the right-hand
side.
The top one is shown with the wrong width.
The numbered ones are ok but when the mouse is moved over the
ones further down the link shown is the same for all the images
and when it is clicked the same page is opened regarless of the
image.
This is with Atari build no. 2427
Can someone confirm this with other versions ?
Peter
Friday, 12 December 2014
AW: Netsurf 3.2 framebuffer BadEncoding
Hello,
i had the same behaviour while first compiling and running nsfb.
My system and libs are almost the same.
AM335x
Kernel 3.x
Busybox 1.22.1
I solved this issue with bringing the resources and fonts to the target.
Generating /root/.netsurf and copying the files from netsurf resource directory.
A good hint is to call nsfb with verbose option –v like:
nsfb -v -w 320 -h 240 http://www.....
There you will see lots of hints regarding the use of the resources.
Think most of this „Bad Encoding" stuff was because of missing some default .css files.
You can write me a direct mail and i can send you my tar file of used resources if you want.
Yours Christian Lepper
Hello,
I've compiled Netsurf 3.2 for arm-none-linux-gnueabi for a mini6410 from FriendlyARM.
when it starts, I get a white screen and get the message BadEncoding.
It also won't load a simple html page with only text from another server. But it can upload a picture from it.
I think it has some thing to do with the character encoding but I don't know how to fix it.
system:
Hardware: FriendlyARM mini 6410
Kernel: linux-2.6.38
Rootfs: busybox 1.17.2
I use the following libraries:
curl-7.39.0
jpeg-9
libiconv-1.14
libidn-1.29
libpng-1.6.15
libxml2-2.9.2
SDL-1.2.15
zlib-1.2.8
and from the netsurf-all-3.2
buildsystem
libcss
libdom
libhubbub
libnsbmp
libnsfb
libnsgif
libparserutils
librosprite
libwapcaplet
netsurf
for compiling I've followed the BUILDING-Framebuffer
Thanks!!!!
Kind regards
Daan Wijnberg
Thursday, 11 December 2014
Netsurf 3.2 framebuffer BadEncoding
Hello,
I've compiled Netsurf 3.2 for arm-none-linux-gnueabi for a mini6410 from FriendlyARM.
when it starts, I get a white screen and get the message BadEncoding.
It also won't load a simple html page with only text from another server. But it can upload a picture from it.
I think it has some thing to do with the character encoding but I don't know how to fix it.
system:
Hardware: FriendlyARM mini 6410
Kernel: linux-2.6.38
Rootfs: busybox 1.17.2
I use the following libraries:
curl-7.39.0
jpeg-9
libiconv-1.14
libidn-1.29
libpng-1.6.15
libxml2-2.9.2
SDL-1.2.15
zlib-1.2.8
and from the netsurf-all-3.2
buildsystem
libcss
libdom
libhubbub
libnsbmp
libnsfb
libnsgif
libparserutils
librosprite
libwapcaplet
netsurf
for compiling I've followed the BUILDING-Framebuffer
Thanks!!!!
Kind regards
Daan Wijnberg
Re: Change.org massively scaled images
On 03/12/14 19:10, Cristopher Dewhurst wrote:
> Does anyone know why NetSurf scales the images on www.change.org to
> what seems like several thousand percent?
They use media queries, a CSS3 feature that we don't yet support.
http://www.w3.org/TR/css3-mediaqueries/
Support needs added to both libcss and NetSurf.
Cheers,
--
Michael Drake http://www.netsurf-browser.org/
> Does anyone know why NetSurf scales the images on www.change.org to
> what seems like several thousand percent?
They use media queries, a CSS3 feature that we don't yet support.
http://www.w3.org/TR/css3-mediaqueries/
Support needs added to both libcss and NetSurf.
Cheers,
--
Michael Drake http://www.netsurf-browser.org/
Re: Change.org massively scaled images
Cristopher Dewhurst wrote on 3 Dec:
> Does anyone know why Netsurf scales the images on www.change.org to
> what seems like several thousand percent?
> For example on the recent petition
> https://www.change.org/p/new-era-should-not-become-the-end-of-an-era?u
> tm_source=action_alert&utm_medium=email&utm_campaign=192906
[That is all one long link -- beware spurious newlines that
might be inserted by email system]
> pixels in some of the images are about an inch square on the screen so
> you have to scroll over large areas to read the text.
> At least this is what I get on NS 3.3 Dev Cl#2419, RISC OS 5.21
> Raspberry Pi, be interesting to see what happens on other platforms?
On Iyonix with Netsurf #2432 I see two logos apparently at intended
size and no other graphics. After the "letterhead" at top of page,
Netsurf shows a massive grey rectangle (see separate thread) about
8 screens wide and 16 screens high. Following that is a small body of
text that is up to 16 screens wide without wrapping.
--
Jim Nagel www.archivemag.co.uk
> Does anyone know why Netsurf scales the images on www.change.org to
> what seems like several thousand percent?
> For example on the recent petition
> https://www.change.org/p/new-era-should-not-become-the-end-of-an-era?u
> tm_source=action_alert&utm_medium=email&utm_campaign=192906
[That is all one long link -- beware spurious newlines that
might be inserted by email system]
> pixels in some of the images are about an inch square on the screen so
> you have to scroll over large areas to read the text.
> At least this is what I get on NS 3.3 Dev Cl#2419, RISC OS 5.21
> Raspberry Pi, be interesting to see what happens on other platforms?
On Iyonix with Netsurf #2432 I see two logos apparently at intended
size and no other graphics. After the "letterhead" at top of page,
Netsurf shows a massive grey rectangle (see separate thread) about
8 screens wide and 16 screens high. Following that is a small body of
text that is up to 16 screens wide without wrapping.
--
Jim Nagel www.archivemag.co.uk
Re: Raspberry-Pi B+ problem
In article <e014447454.cris@cdewhurst2010.btinternet.com>,
Chris Dewhurst <cdewhurst2010@btinternet.com> wrote:
> Hi Richard,
> Not sure if the below will help but you could give them a try, even if
> to eliminate from your enquiries.
> (1) On my R-Pi sometimes Netsurf gets stuck in a loop of redirecting
> itself to its home page. Quitting Netsurf and deleting the folder:
> SDFS::16GbPi.$.!Boot.Resources.!Scrap.ScrapDirs.ScrapDir.WWW
> (or wherever the WWW folder resides in your !Boot folder)
> then restarting Netsurf cures it.
Excellent! Thanks.
I renamed SDFS::RISCOSpi.$.!Boot.Choices.WWW.NetSurf
to .....NetSurfX
NetSurf then started fine
then I quit Netsurf and started moving the old files back.
The problem was a corrupted Hotlist in there. It was 7M and most of that
was junk looking very much like a memory dump.
The section immediately after the hotlist was a load of lines such as
(27736.960000) render/html_object.c html_object_free_objects 651: object
0x67ea3858
which is clearly dumped from Netsurf.
Deleting all the junk after the final </ul> of the hotlist proper, nothing
has been lost.
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
Chris Dewhurst <cdewhurst2010@btinternet.com> wrote:
> Hi Richard,
> Not sure if the below will help but you could give them a try, even if
> to eliminate from your enquiries.
> (1) On my R-Pi sometimes Netsurf gets stuck in a loop of redirecting
> itself to its home page. Quitting Netsurf and deleting the folder:
> SDFS::16GbPi.$.!Boot.Resources.!Scrap.ScrapDirs.ScrapDir.WWW
> (or wherever the WWW folder resides in your !Boot folder)
> then restarting Netsurf cures it.
Excellent! Thanks.
I renamed SDFS::RISCOSpi.$.!Boot.Choices.WWW.NetSurf
to .....NetSurfX
NetSurf then started fine
then I quit Netsurf and started moving the old files back.
The problem was a corrupted Hotlist in there. It was 7M and most of that
was junk looking very much like a memory dump.
The section immediately after the hotlist was a load of lines such as
(27736.960000) render/html_object.c html_object_free_objects 651: object
0x67ea3858
which is clearly dumped from Netsurf.
Deleting all the junk after the final </ul> of the hotlist proper, nothing
has been lost.
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
Changes page
http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/changes no
longer seems to have content.
Has the page/system moved somewhere else?
John
--
| John Williams
| johnrw@ukgateway.net
I think, therefore I am unsure - I think! *
longer seems to have content.
Has the page/system moved somewhere else?
John
--
| John Williams
| johnrw@ukgateway.net
I think, therefore I am unsure - I think! *
Re: Netsurf 3.2 Fullscreen kiosk mode
On Thu, Dec 11, 2014 at 10:23:34AM +0100, Daan Wijnberg wrote:
> Hello,
>
> is it possible to run netsurf 3.2 fullscreen without the bars etc (kiosk mode)? . I've compiled it for frame buffer on a mini6410 from FriendlyARM but can't figure out how to get it full screen. I want to use it as GUI.
>
> is there a command that I need to use?
I believe the "fb_toolbar_layout" and "fb_toolbar_size" options (either
via command line or Choices file) can control what appears and how big
it is, but I forgot exact details.
Grep the source for "toolbar_layout" :)
B.
> Hello,
>
> is it possible to run netsurf 3.2 fullscreen without the bars etc (kiosk mode)? . I've compiled it for frame buffer on a mini6410 from FriendlyARM but can't figure out how to get it full screen. I want to use it as GUI.
>
> is there a command that I need to use?
I believe the "fb_toolbar_layout" and "fb_toolbar_size" options (either
via command line or Choices file) can control what appears and how big
it is, but I forgot exact details.
Grep the source for "toolbar_layout" :)
B.
Re: Raspberry-Pi B+ problem
Hi Richard,
Not sure if the below will help but you could give them a try, even if
to eliminate from your enquiries.
(1) On my R-Pi sometimes Netsurf gets stuck in a loop of redirecting
itself to its home page. Quitting Netsurf and deleting the folder:
SDFS::16GbPi.$.!Boot.Resources.!Scrap.ScrapDirs.ScrapDir.WWW
(or wherever the WWW folder resides in your !Boot folder)
then restarting Netsurf cures it.
(2) I had to reinstall the boot sequence once to fix a Netsurf problem
though this may have been on a Beagleboard, and as you've replaced the
SD card I guess by defintion you've already reinstalled !Boot.
Chris.
Not sure if the below will help but you could give them a try, even if
to eliminate from your enquiries.
(1) On my R-Pi sometimes Netsurf gets stuck in a loop of redirecting
itself to its home page. Quitting Netsurf and deleting the folder:
SDFS::16GbPi.$.!Boot.Resources.!Scrap.ScrapDirs.ScrapDir.WWW
(or wherever the WWW folder resides in your !Boot folder)
then restarting Netsurf cures it.
(2) I had to reinstall the boot sequence once to fix a Netsurf problem
though this may have been on a Beagleboard, and as you've replaced the
SD card I guess by defintion you've already reinstalled !Boot.
Chris.
Netsurf 3.2 Fullscreen kiosk mode
Hello,
is it possible to run netsurf 3.2 fullscreen without the bars etc (kiosk mode)? . I've compiled it for frame buffer on a mini6410 from FriendlyARM but can't figure out how to get it full screen. I want to use it as GUI.
is there a command that I need to use?
Thanks!
Kind regards
Daan Wijnberg
Re: Raspberry-Pi B+ problem
In article <mpro.nge0qd0027ord01rk@wingsandbeaks.org.uk.invalid>,
Jeremy Nicoll - ml netsurf <jn.ml.nso.71@wingsandbeaks.org.uk> wrote:
> Why do you think that 'Disc error' is beng reported falsely?
The disk verifies fine every time.
DiscKnight usually reports "Disc good". Or on occasion it can find and
repair a fault such as a broken map.
> I find it hard to believe that whatever detects such things would be
> making spurious reports.
Which makes me think it's a timing problem.
ROOL first diagnosed that I had a faulty R-Pi. So I had it replaced. The
second one is the same.
This is the second µSD supplied by ROOL.
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
Jeremy Nicoll - ml netsurf <jn.ml.nso.71@wingsandbeaks.org.uk> wrote:
> Why do you think that 'Disc error' is beng reported falsely?
The disk verifies fine every time.
DiscKnight usually reports "Disc good". Or on occasion it can find and
repair a fault such as a broken map.
> I find it hard to believe that whatever detects such things would be
> making spurious reports.
Which makes me think it's a timing problem.
ROOL first diagnosed that I had a faulty R-Pi. So I had it replaced. The
second one is the same.
This is the second µSD supplied by ROOL.
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
Wednesday, 10 December 2014
Re: Raspberry-Pi B+ problem
"Richard Torrens (lists)" <Lists@Torrens.org.uk> wrote:
>However the B+ appears to be extremely unreliable: "Disc error" keeps
>being reported. Usually falsely - but sometimes ther is a corruption, so I
>thin something may have been corrupted. But what?
Why do you think that 'Disc error' is beng reported falsely?
I find it hard to believe that whatever detects such things would be making
spurious reports.
--
Jeremy C B Nicoll - my opinions are my own.
>However the B+ appears to be extremely unreliable: "Disc error" keeps
>being reported. Usually falsely - but sometimes ther is a corruption, so I
>thin something may have been corrupted. But what?
Why do you think that 'Disc error' is beng reported falsely?
I find it hard to believe that whatever detects such things would be making
spurious reports.
--
Jeremy C B Nicoll - my opinions are my own.
Raspberry-Pi B+ problem
In article <5473e1e3dbchris@chris-johnson.org.uk>,
cj <chris@chris-johnson.org.uk> wrote:
> In article <5473d22af9Lists@Torrens.org.uk>,
> Richard Torrens (lists) <Lists@Torrens.org.uk> wrote:
> > I have Reporter running: this gives me no clues. It reports
> > *Filer_run .... !Netsurf.
> > Then after the Alt-Break, it lists a whole host of output, stopping at
> > [Appl/0B2039C4] RMEnsure Iconv 0.04 Error 16_10F iconv support requires
> > the Iconv module 0.04 or newer
> > ** WimpError ** from Window Manager
> > Error : &050DEAD0
> > Message: Press Stop to terminate Unknown.
> Can it be assumed that the 'whole host' corresponds to the Netsurf
> !Run file up to the point where it tries to rmensure Iconv?
Yes, exactly as the !Run file.
> The unknown may be the !Run obey file itself or Iconv trying to
> initialise.
I thought Iconv might be corrupt, replaced it. No change.
> The implication is that you haven't changed Netsurf or any of its
> support modules.
a working NetSurf stopped working for no apparent reason. So I tred a
completely new one. It now has RunImage dated December 4th - I think
that's 2425.
> From the error message you are running a fairly old
> version. What actual versions are you running? What compatibility
> mode are you running the Pi in?
I have just tried all 3 modes. It makes no difference.
I also tried executing (via a StrongED task window) the !Run file step by
step. This gives a "Window Manager is currently in use" after
/<NetSurf$Dir>.KickNS
and after
Run <NetSurf$Dir>.!RunImage %*0 2><Wimp$ScrapDir>.WWW.NetSurf.Log
First is thrown back to the Task Window, second is a Wimp error Box.
Netsurf doesn't run, but machine does not freeze.
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
cj <chris@chris-johnson.org.uk> wrote:
> In article <5473d22af9Lists@Torrens.org.uk>,
> Richard Torrens (lists) <Lists@Torrens.org.uk> wrote:
> > I have Reporter running: this gives me no clues. It reports
> > *Filer_run .... !Netsurf.
> > Then after the Alt-Break, it lists a whole host of output, stopping at
> > [Appl/0B2039C4] RMEnsure Iconv 0.04 Error 16_10F iconv support requires
> > the Iconv module 0.04 or newer
> > ** WimpError ** from Window Manager
> > Error : &050DEAD0
> > Message: Press Stop to terminate Unknown.
> Can it be assumed that the 'whole host' corresponds to the Netsurf
> !Run file up to the point where it tries to rmensure Iconv?
Yes, exactly as the !Run file.
> The unknown may be the !Run obey file itself or Iconv trying to
> initialise.
I thought Iconv might be corrupt, replaced it. No change.
> The implication is that you haven't changed Netsurf or any of its
> support modules.
a working NetSurf stopped working for no apparent reason. So I tred a
completely new one. It now has RunImage dated December 4th - I think
that's 2425.
> From the error message you are running a fairly old
> version. What actual versions are you running? What compatibility
> mode are you running the Pi in?
I have just tried all 3 modes. It makes no difference.
I also tried executing (via a StrongED task window) the !Run file step by
step. This gives a "Window Manager is currently in use" after
/<NetSurf$Dir>.KickNS
and after
Run <NetSurf$Dir>.!RunImage %*0 2><Wimp$ScrapDir>.WWW.NetSurf.Log
First is thrown back to the Task Window, second is a Wimp error Box.
Netsurf doesn't run, but machine does not freeze.
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
Re: Raspberry-Pi B+ problem
In article <5473d22af9Lists@Torrens.org.uk>,
Richard Torrens (lists) <Lists@Torrens.org.uk> wrote:
> I have Reporter running: this gives me no clues. It reports
> *Filer_run .... !Netsurf.
> Then after the Alt-Break, it lists a whole host of output, stopping at
> [Appl/0B2039C4] RMEnsure Iconv 0.04 Error 16_10F iconv support requires
> the Iconv module 0.04 or newer
> ** WimpError ** from Window Manager
> Error : &050DEAD0
> Message: Press Stop to terminate Unknown.
Can it be assumed that the 'whole host' corresponds to the Netsurf
!Run file up to the point where it tries to rmensure Iconv?
The unknown may be the !Run obey file itself or Iconv trying to
initialise.
The implication is that you haven't changed Netsurf or any of its
support modules. From the error message you are running a fairly old
version. What actual versions are you running? What compatibility
mode are you running the Pi in?
--
Chris Johnson
Richard Torrens (lists) <Lists@Torrens.org.uk> wrote:
> I have Reporter running: this gives me no clues. It reports
> *Filer_run .... !Netsurf.
> Then after the Alt-Break, it lists a whole host of output, stopping at
> [Appl/0B2039C4] RMEnsure Iconv 0.04 Error 16_10F iconv support requires
> the Iconv module 0.04 or newer
> ** WimpError ** from Window Manager
> Error : &050DEAD0
> Message: Press Stop to terminate Unknown.
Can it be assumed that the 'whole host' corresponds to the Netsurf
!Run file up to the point where it tries to rmensure Iconv?
The unknown may be the !Run obey file itself or Iconv trying to
initialise.
The implication is that you haven't changed Netsurf or any of its
support modules. From the error message you are running a fairly old
version. What actual versions are you running? What compatibility
mode are you running the Pi in?
--
Chris Johnson
libsvgtiny: -Werror causes build failures for toolchains with glibc-2.0
glibc-2.20 includes some changes to the include/features.h file
introduced by this commit:
https://sourceware.org/git/?p=glibc.git;a=commit;h=ade40b10ff5fa59a318cf55b9d8414b758e8df78
Those changes make libsvgtiny fail because some warnings are thrown and
the build system is using the -Werror option. The errors are this one:
GPERF: src/colors.gperf
COMPILE: build-Linux-Linux-release-lib-static/src_colors.c
In file included from
/br/output/host/usr/mipsel-buildroot-linux-gnu/sysroot/usr/include/string.h:25:0,
from src/colors.gperf:16:
/br/output/host/usr/mipsel-buildroot-linux-gnu/sysroot/usr/include/features.h:148:3:
error: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use
_DEFAULT_SOURCE" [-Werror=cpp]
and this one:
In file included from src/colors.gperf:18:0:
/home/ldap/vriera/work/mips-buildroots/mips32/output/build/libsvgtiny-12121/src/svgtiny_internal.h:71:0:
error: "strndup" redefined [-Werror]
Any chance to fix the code upstream?
Best regards,
--
Vicente Olivert Riera
Graduate Software Engineer, MIPS Platforms
Imagination Technologies Limited
t: +44 (0)113 2429814
www.imgtec.com
introduced by this commit:
https://sourceware.org/git/?p=glibc.git;a=commit;h=ade40b10ff5fa59a318cf55b9d8414b758e8df78
Those changes make libsvgtiny fail because some warnings are thrown and
the build system is using the -Werror option. The errors are this one:
GPERF: src/colors.gperf
COMPILE: build-Linux-Linux-release-lib-static/src_colors.c
In file included from
/br/output/host/usr/mipsel-buildroot-linux-gnu/sysroot/usr/include/string.h:25:0,
from src/colors.gperf:16:
/br/output/host/usr/mipsel-buildroot-linux-gnu/sysroot/usr/include/features.h:148:3:
error: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use
_DEFAULT_SOURCE" [-Werror=cpp]
and this one:
In file included from src/colors.gperf:18:0:
/home/ldap/vriera/work/mips-buildroots/mips32/output/build/libsvgtiny-12121/src/svgtiny_internal.h:71:0:
error: "strndup" redefined [-Werror]
Any chance to fix the code upstream?
Best regards,
--
Vicente Olivert Riera
Graduate Software Engineer, MIPS Platforms
Imagination Technologies Limited
t: +44 (0)113 2429814
www.imgtec.com
Subscribe to:
Posts (Atom)