In article <mpro.n7qhjo04212yb005b.tim@powys.org>,
Tim Powys-Lybbe <tim@powys.org> wrote:
> > Rather than hijack this mailing list, you'd be welcome to post these
> > questions to the ROOL bounty forum:
> >
> > https://www.riscosopen.org/forum/forums/8
> Can't stand forums.
Rather than attempt to get Tim to grapple with his personal demons, I have
taken the liberty of posting his suggestions myself so that they might
reach a better target audience. Didn't take long, as he'd already done
most of the necessary typing!
John
--
| John Williams
| johnrw@ukgateway.net
Names for Soul Band:- Soul Beneficiary *
Wednesday, 25 June 2014
Re: Disc cache worth it?
On 25 Jun at 15:22, "Steve (plusnet)" <steve@revi11.plus.com> wrote:
> On 2014-06-25 14:57, Tim Powys-Lybbe wrote:
> > I have intermittently subscribed to a bounty or two.
>
> Rather than hijack this mailing list, you'd be welcome to post these
> questions to the ROOL bounty forum:
>
> https://www.riscosopen.org/forum/forums/8
Can't stand forums. Too much hassle to find the site and the
discussion. Mailing lists and usenet are so much easier: the discussion
just appears on MessengerPro.
I take it that you are not interested in following up your comments on
bounties, to which I was merely replying?
--
Tim Powys-Lybbe tim@powys.org
for a miscellany of bygones: http://powys.org/
> On 2014-06-25 14:57, Tim Powys-Lybbe wrote:
> > I have intermittently subscribed to a bounty or two.
>
> Rather than hijack this mailing list, you'd be welcome to post these
> questions to the ROOL bounty forum:
>
> https://www.riscosopen.org/forum/forums/8
Can't stand forums. Too much hassle to find the site and the
discussion. Mailing lists and usenet are so much easier: the discussion
just appears on MessengerPro.
I take it that you are not interested in following up your comments on
bounties, to which I was merely replying?
--
Tim Powys-Lybbe tim@powys.org
for a miscellany of bygones: http://powys.org/
Re: Disc cache worth it?
On 2014-06-25 14:57, Tim Powys-Lybbe wrote:
> I have intermittently subscribed to a bounty or two.
Rather than hijack this mailing list, you'd be welcome to post these
questions to the ROOL bounty forum:
https://www.riscosopen.org/forum/forums/8
Cheers,
Steve
> I have intermittently subscribed to a bounty or two.
Rather than hijack this mailing list, you'd be welcome to post these
questions to the ROOL bounty forum:
https://www.riscosopen.org/forum/forums/8
Cheers,
Steve
Re: Disc cache worth it?
On 25 Jun at 13:32, "Steve (plusnet)" <steve@revi11.plus.com> wrote:
<snip of technical discussion>
> It is hoped that one of the later stages of "filesystem improvements"
> that we've been hosting bounties about on the ROOL site will address
> some of these issues, but at the current rate that the bounty scheme
> has been gathering donations, we'll all be dead and gone before any of
> that work happens.
I have intermittently subscribed to a bounty or two.
I wonder if the ROOL systems could improve the volume of subscriptions
received:
1. By issuing a public report occasionally (yearly? And to csaa?) on
what has been achieved and what could do with more funding.
2. When a Bounty has been fulfilled, write to the subscribers to tell
them of this good news and invite them to subscribe to other bounties
instead, even including with this a list of priorities for RISC OS.
3. Consider changing some aspects of ROOL to a charity, certainly
including the Bounty aspect. This would enable the trustees to
reclaim income tax paid by the bounty donors. Further the donors who
pay higher rate tax could deduct their subscription from the higher
rate income, thereby reducing their higher rate tax; if they felt so
minded they could then increase their donation by the amount of this
higher rate tax relief.
That said, how much do you think is needed in the relevant bounty
(which?) to encourage a developer to start work?
--
Tim Powys-Lybbe tim@powys.org
for a miscellany of bygones: http://powys.org/
<snip of technical discussion>
> It is hoped that one of the later stages of "filesystem improvements"
> that we've been hosting bounties about on the ROOL site will address
> some of these issues, but at the current rate that the bounty scheme
> has been gathering donations, we'll all be dead and gone before any of
> that work happens.
I have intermittently subscribed to a bounty or two.
I wonder if the ROOL systems could improve the volume of subscriptions
received:
1. By issuing a public report occasionally (yearly? And to csaa?) on
what has been achieved and what could do with more funding.
2. When a Bounty has been fulfilled, write to the subscribers to tell
them of this good news and invite them to subscribe to other bounties
instead, even including with this a list of priorities for RISC OS.
3. Consider changing some aspects of ROOL to a charity, certainly
including the Bounty aspect. This would enable the trustees to
reclaim income tax paid by the bounty donors. Further the donors who
pay higher rate tax could deduct their subscription from the higher
rate income, thereby reducing their higher rate tax; if they felt so
minded they could then increase their donation by the amount of this
higher rate tax relief.
That said, how much do you think is needed in the relevant bounty
(which?) to encourage a developer to start work?
--
Tim Powys-Lybbe tim@powys.org
for a miscellany of bygones: http://powys.org/
Re: Disc cache worth it?
On 2014-06-25 13:51, Rob Kendrick wrote:
> Of course not :) But from the user's point of view, everything does
> stop :)
Pesky users... :)
Steve
> Of course not :) But from the user's point of view, everything does
> stop :)
Pesky users... :)
Steve
Re: Disc cache worth it?
On Wed, Jun 25, 2014 at 01:44:01PM +0100, Steve (plusnet) wrote:
> On 2014-06-25 13:36, Rob Kendrick wrote:
> >(Getting into the technical distinctions between WIMP and non-WIMP
> >tasks
> >was something I was trying to avoid getting into on the user's
> >mailing
> >list :)
>
> Fair enough, but if you're going to say things like "the whole system
> stops while the individual chunks are written" and "Under RISC OS,
> file system writes stop /everthing/ until they complete" you can't
> expect
> me to just sit by and say nothing...
Of course not :) But from the user's point of view, everything does
stop :)
B.
> On 2014-06-25 13:36, Rob Kendrick wrote:
> >(Getting into the technical distinctions between WIMP and non-WIMP
> >tasks
> >was something I was trying to avoid getting into on the user's
> >mailing
> >list :)
>
> Fair enough, but if you're going to say things like "the whole system
> stops while the individual chunks are written" and "Under RISC OS,
> file system writes stop /everthing/ until they complete" you can't
> expect
> me to just sit by and say nothing...
Of course not :) But from the user's point of view, everything does
stop :)
B.
Re: Disc cache worth it?
On 2014-06-25 13:36, Rob Kendrick wrote:
> (Getting into the technical distinctions between WIMP and non-WIMP
> tasks
> was something I was trying to avoid getting into on the user's
> mailing
> list :)
Fair enough, but if you're going to say things like "the whole system
stops while the individual chunks are written" and "Under RISC OS,
file system writes stop /everthing/ until they complete" you can't
expect
me to just sit by and say nothing...
;)
Steve
> (Getting into the technical distinctions between WIMP and non-WIMP
> tasks
> was something I was trying to avoid getting into on the user's
> mailing
> list :)
Fair enough, but if you're going to say things like "the whole system
stops while the individual chunks are written" and "Under RISC OS,
file system writes stop /everthing/ until they complete" you can't
expect
me to just sit by and say nothing...
;)
Steve
Re: Disc cache worth it?
On Wed, Jun 25, 2014 at 01:32:58PM +0100, Steve (plusnet) wrote:
> Secondly, it's not true to say file system operations block everything
> in RISC OS - some file systems (notably ADFS) implement "background
> transfers" which allow much of RISC OS to continue to operate while the
> underlying file operation runs (e.g. via DMA or some such). However,
> many
> file systems _don't_ implement background transfers - e.g. SDFS - so
> these will hog the system for the duration of the low-level operation.
But even with background transfers, the Wimp will typically not
continue, no? My understanding is that OS_File SWIs that write data
only return when the data is written, and thus the application cannot
call Wimp_Poll to allow multitasking to continue - and even if you're
using UnixLib threads this doesn't help you because threading does not
continue over such SWIs.
(Getting into the technical distinctions between WIMP and non-WIMP tasks
was something I was trying to avoid getting into on the user's mailing
list :)
B.
> Secondly, it's not true to say file system operations block everything
> in RISC OS - some file systems (notably ADFS) implement "background
> transfers" which allow much of RISC OS to continue to operate while the
> underlying file operation runs (e.g. via DMA or some such). However,
> many
> file systems _don't_ implement background transfers - e.g. SDFS - so
> these will hog the system for the duration of the low-level operation.
But even with background transfers, the Wimp will typically not
continue, no? My understanding is that OS_File SWIs that write data
only return when the data is written, and thus the application cannot
call Wimp_Poll to allow multitasking to continue - and even if you're
using UnixLib threads this doesn't help you because threading does not
continue over such SWIs.
(Getting into the technical distinctions between WIMP and non-WIMP tasks
was something I was trying to avoid getting into on the user's mailing
list :)
B.
Re: Disc cache worth it?
On 2014-06-25 12:57, Rob Kendrick wrote:
> On Wed, Jun 25, 2014 at 12:14:16PM +0100, george greenfield wrote:
>
>> Does that mean that selecting 'Make file operations multitask' in
>> !Configure-Filer, actually doesn't?
>
> It means that it writes smaller chunks and calls Wimp_Poll in between
> them
> to give other applications a chance, at the expense of expediency.
> The
> whole system stops while the individual chunks are written, being
> accepted by FileSwitch, which then in turn passes them to the
> handling
> file system (most likely FileCore), which then hands them to the
> block
> device driver (ADFS, IDEFS, SDFS, etc), percolating the
> success/failure
> result back up the stack to the application.
I think there are a couple of errors in that explanation.
First of all, IIRC ticking that option only affects FilerAction. This
is a
desktop facility for doing multitasking operations on files and
directories
(such as copy, move, delete, etc) with a window opening to show
progress.
Unticking that option causes these operations to revert to using the
single-tasking command line equivalents for these operations (e.g.
*copy)
which could end up being faster at the expense that your desktop stops
multitasking.
Secondly, it's not true to say file system operations block everything
in RISC OS - some file systems (notably ADFS) implement "background
transfers" which allow much of RISC OS to continue to operate while the
underlying file operation runs (e.g. via DMA or some such). However,
many
file systems _don't_ implement background transfers - e.g. SDFS - so
these will hog the system for the duration of the low-level operation.
Adding background transfers to SDFS has always been on the roadmap but
it's a lot of work; implementing background transfers on RISC OS is a
particularly tricky task and SDFS is complex enough already for various
reasons. It is hoped that one of the later stages of "filesystem
improvements" that we've been hosting bounties about on the ROOL site
will address some of these issues, but at the current rate that the
bounty scheme has been gathering donations, we'll all be dead and gone
before any of that work happens.
Ta,
Steve
> On Wed, Jun 25, 2014 at 12:14:16PM +0100, george greenfield wrote:
>
>> Does that mean that selecting 'Make file operations multitask' in
>> !Configure-Filer, actually doesn't?
>
> It means that it writes smaller chunks and calls Wimp_Poll in between
> them
> to give other applications a chance, at the expense of expediency.
> The
> whole system stops while the individual chunks are written, being
> accepted by FileSwitch, which then in turn passes them to the
> handling
> file system (most likely FileCore), which then hands them to the
> block
> device driver (ADFS, IDEFS, SDFS, etc), percolating the
> success/failure
> result back up the stack to the application.
I think there are a couple of errors in that explanation.
First of all, IIRC ticking that option only affects FilerAction. This
is a
desktop facility for doing multitasking operations on files and
directories
(such as copy, move, delete, etc) with a window opening to show
progress.
Unticking that option causes these operations to revert to using the
single-tasking command line equivalents for these operations (e.g.
*copy)
which could end up being faster at the expense that your desktop stops
multitasking.
Secondly, it's not true to say file system operations block everything
in RISC OS - some file systems (notably ADFS) implement "background
transfers" which allow much of RISC OS to continue to operate while the
underlying file operation runs (e.g. via DMA or some such). However,
many
file systems _don't_ implement background transfers - e.g. SDFS - so
these will hog the system for the duration of the low-level operation.
Adding background transfers to SDFS has always been on the roadmap but
it's a lot of work; implementing background transfers on RISC OS is a
particularly tricky task and SDFS is complex enough already for various
reasons. It is hoped that one of the later stages of "filesystem
improvements" that we've been hosting bounties about on the ROOL site
will address some of these issues, but at the current rate that the
bounty scheme has been gathering donations, we'll all be dead and gone
before any of that work happens.
Ta,
Steve
Re: Disc cache worth it?
On Wed, Jun 25, 2014 at 12:14:16PM +0100, george greenfield wrote:
> In message <20140624211245.GM1754@platypus.pepperfish.net>
> Rob Kendrick <rjek@netsurf-browser.org> wrote:
>
> > On Tue, Jun 24, 2014 at 06:36:18PM +0100, Chris Young wrote:
> >>
> >> It would be interesting to see if a Raspberry Pi running the GTK
> >> version from SD card has the same slowness.
> >
> > Assuming you were running it on one of the flavours of UNIX available
> > for it (Linux, NetBSD), then no.
> >
> > These operating systems receive the write requests from applications and
> > queue them for writing to underlying block devices in the background,
> > while other apps sit there waiting for input or idling. Under RISC OS,
> > file system writes stop /everthing/ until they complete.
>
> Does that mean that selecting 'Make file operations multitask' in
> !Configure-Filer, actually doesn't?
It means that it writes smaller chunks and calls Wimp_Poll in between them
to give other applications a chance, at the expense of expediency. The
whole system stops while the individual chunks are written, being
accepted by FileSwitch, which then in turn passes them to the handling
file system (most likely FileCore), which then hands them to the block
device driver (ADFS, IDEFS, SDFS, etc), percolating the success/failure
result back up the stack to the application.
On other operating systems (UNIX, Windows, BeOS, AmigaOS, OS X), the
equivalent of FileSwitch passes the request onto the file system which
then writes the data through a buffering system and thus can return
almost straight away, while a background process in the kernel then
flushes the buffer to the block device while the system is not busy, or
a timeout expires. During this process, reads are satisfied through the
buffer because they've not yet reached the block device.
There is some functionality in Vince's disc cache work to allow for
something similar to the "file operations multitask" option, and may
need tuning. As he said, this is an experimental feature and the
feedback that has been happening does have some value.
B.
> In message <20140624211245.GM1754@platypus.pepperfish.net>
> Rob Kendrick <rjek@netsurf-browser.org> wrote:
>
> > On Tue, Jun 24, 2014 at 06:36:18PM +0100, Chris Young wrote:
> >>
> >> It would be interesting to see if a Raspberry Pi running the GTK
> >> version from SD card has the same slowness.
> >
> > Assuming you were running it on one of the flavours of UNIX available
> > for it (Linux, NetBSD), then no.
> >
> > These operating systems receive the write requests from applications and
> > queue them for writing to underlying block devices in the background,
> > while other apps sit there waiting for input or idling. Under RISC OS,
> > file system writes stop /everthing/ until they complete.
>
> Does that mean that selecting 'Make file operations multitask' in
> !Configure-Filer, actually doesn't?
It means that it writes smaller chunks and calls Wimp_Poll in between them
to give other applications a chance, at the expense of expediency. The
whole system stops while the individual chunks are written, being
accepted by FileSwitch, which then in turn passes them to the handling
file system (most likely FileCore), which then hands them to the block
device driver (ADFS, IDEFS, SDFS, etc), percolating the success/failure
result back up the stack to the application.
On other operating systems (UNIX, Windows, BeOS, AmigaOS, OS X), the
equivalent of FileSwitch passes the request onto the file system which
then writes the data through a buffering system and thus can return
almost straight away, while a background process in the kernel then
flushes the buffer to the block device while the system is not busy, or
a timeout expires. During this process, reads are satisfied through the
buffer because they've not yet reached the block device.
There is some functionality in Vince's disc cache work to allow for
something similar to the "file operations multitask" option, and may
need tuning. As he said, this is an experimental feature and the
feedback that has been happening does have some value.
B.
Re: Disc cache worth it?
In message <20140624211245.GM1754@platypus.pepperfish.net>
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> On Tue, Jun 24, 2014 at 06:36:18PM +0100, Chris Young wrote:
>>
>> It would be interesting to see if a Raspberry Pi running the GTK
>> version from SD card has the same slowness.
>
> Assuming you were running it on one of the flavours of UNIX available
> for it (Linux, NetBSD), then no.
>
> These operating systems receive the write requests from applications and
> queue them for writing to underlying block devices in the background,
> while other apps sit there waiting for input or idling. Under RISC OS,
> file system writes stop /everthing/ until they complete.
>
[snip]
Does that mean that selecting 'Make file operations multitask' in
!Configure-Filer, actually doesn't?
--
George
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> On Tue, Jun 24, 2014 at 06:36:18PM +0100, Chris Young wrote:
>>
>> It would be interesting to see if a Raspberry Pi running the GTK
>> version from SD card has the same slowness.
>
> Assuming you were running it on one of the flavours of UNIX available
> for it (Linux, NetBSD), then no.
>
> These operating systems receive the write requests from applications and
> queue them for writing to underlying block devices in the background,
> while other apps sit there waiting for input or idling. Under RISC OS,
> file system writes stop /everthing/ until they complete.
>
[snip]
Does that mean that selecting 'Make file operations multitask' in
!Configure-Filer, actually doesn't?
--
George
Re: Persistant disc cache
On Tue, Jun 24, 2014 at 21:18:07 +0100, Chris Young wrote:
> > I am pleased to be able to announce that I have enabled the persistent
> > source object cache on the RISC OS build. This means that RISC OS CI
> > builds from #1956 onwards have the capability to store cacheable
> > objects fetched from from the web to disc.
>
> There is a problem with Base64 being used to create the filenames, as
> on case insensitive filesystems, half the characters are treated as
> equivalent. After some brief looking into this, Base32 might be a
> better option.
You know, I'd forgotten that there exist such daftnesses. Despite being stuck
working with Windows and MacOS regularly :-(
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> > I am pleased to be able to announce that I have enabled the persistent
> > source object cache on the RISC OS build. This means that RISC OS CI
> > builds from #1956 onwards have the capability to store cacheable
> > objects fetched from from the web to disc.
>
> There is a problem with Base64 being used to create the filenames, as
> on case insensitive filesystems, half the characters are treated as
> equivalent. After some brief looking into this, Base32 might be a
> better option.
You know, I'd forgotten that there exist such daftnesses. Despite being stuck
working with Windows and MacOS regularly :-(
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Tuesday, 24 June 2014
Re: Disc cache worth it?
On Tue, Jun 24, 2014 at 06:36:18PM +0100, Chris Young wrote:
>
> It would be interesting to see if a Raspberry Pi running the GTK
> version from SD card has the same slowness.
Assuming you were running it on one of the flavours of UNIX available
for it (Linux, NetBSD), then no.
These operating systems receive the write requests from applications and
queue them for writing to underlying block devices in the background,
while other apps sit there waiting for input or idling. Under RISC OS,
file system writes stop /everthing/ until they complete.
(Under UNIX, applications should call the fdatasync() function when the
data stored to disc is in a consistent/useful state, which guarentees
the data has reached backing store, but then they also have pre-emptive
multitasking so you can still use your computer when this happens.)
B.
>
> It would be interesting to see if a Raspberry Pi running the GTK
> version from SD card has the same slowness.
Assuming you were running it on one of the flavours of UNIX available
for it (Linux, NetBSD), then no.
These operating systems receive the write requests from applications and
queue them for writing to underlying block devices in the background,
while other apps sit there waiting for input or idling. Under RISC OS,
file system writes stop /everthing/ until they complete.
(Under UNIX, applications should call the fdatasync() function when the
data stored to disc is in a consistent/useful state, which guarentees
the data has reached backing store, but then they also have pre-emptive
multitasking so you can still use your computer when this happens.)
B.
Re: Persistant disc cache
On Thu, 5 Jun 2014 16:01:05 +0100, Vincent Sanders wrote:
> I am pleased to be able to announce that I have enabled the persistent
> source object cache on the RISC OS build. This means that RISC OS CI
> builds from #1956 onwards have the capability to store cacheable
> objects fetched from from the web to disc.
There is a problem with Base64 being used to create the filenames, as
on case insensitive filesystems, half the characters are treated as
equivalent. After some brief looking into this, Base32 might be a
better option.
Chris
> I am pleased to be able to announce that I have enabled the persistent
> source object cache on the RISC OS build. This means that RISC OS CI
> builds from #1956 onwards have the capability to store cacheable
> objects fetched from from the web to disc.
There is a problem with Base64 being used to create the filenames, as
on case insensitive filesystems, half the characters are treated as
equivalent. After some brief looking into this, Base32 might be a
better option.
Chris
Re: Disc cache worth it?
On 24 Jun 2014 Vincent Sanders <vince@netsurf-browser.org> wrote:
> Although this reply is to Peter it applies to all the subsequent
> discussion.
> Firstly, as I did memntion in my original mail this feature is new and
> not tuned yet so may have adverse behaviour on some systems. Please do
> not draw any conclusions about the usefulness or otherwise of this
> feature from *development* snapshots.
> If you want stable behaviour the 3.1 release should be used. It may
> well turn out that this feature is simply unsuitable for RISC OS but
> we are at the beginning of a long road.
> As we have seen with the issues around !Cache and now with general
> perfomance, the challenges of building a cache suitable for use across
> many systems are not inconsiderable
[snip very interesting bits, but a lot of which goes right over my
head!]
> In summary, the cache:
> - Is still in development.
> - Is not a panacea and will not benefit everyone.
> - Is a compromise trade, and it seems for some systems with slow disc
> it is literally faster to retrieve from network than from local
> storage.
> - Is likely to be very large to be effective as the source web pages
> are large.
> - Can be disabled by setting its size to zero.
> I will look into adding a heuristic to disable or at least tune the
> cache writeout if it detects it is exceeding the available disc
> bandwidth.
Many thanks for this, and I did realise that it's still rather a test
feature and a compromise, but I just wondered whether I was doing
things right, and I'm glad I am. I'm also glad the my logfile was of
interest.
I'll stick with it (like many people of my age, I find I get more
patient as I get older), and will await developments with interest.
Best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> Although this reply is to Peter it applies to all the subsequent
> discussion.
> Firstly, as I did memntion in my original mail this feature is new and
> not tuned yet so may have adverse behaviour on some systems. Please do
> not draw any conclusions about the usefulness or otherwise of this
> feature from *development* snapshots.
> If you want stable behaviour the 3.1 release should be used. It may
> well turn out that this feature is simply unsuitable for RISC OS but
> we are at the beginning of a long road.
> As we have seen with the issues around !Cache and now with general
> perfomance, the challenges of building a cache suitable for use across
> many systems are not inconsiderable
[snip very interesting bits, but a lot of which goes right over my
head!]
> In summary, the cache:
> - Is still in development.
> - Is not a panacea and will not benefit everyone.
> - Is a compromise trade, and it seems for some systems with slow disc
> it is literally faster to retrieve from network than from local
> storage.
> - Is likely to be very large to be effective as the source web pages
> are large.
> - Can be disabled by setting its size to zero.
> I will look into adding a heuristic to disable or at least tune the
> cache writeout if it detects it is exceeding the available disc
> bandwidth.
Many thanks for this, and I did realise that it's still rather a test
feature and a compromise, but I just wondered whether I was doing
things right, and I'm glad I am. I'm also glad the my logfile was of
interest.
I'll stick with it (like many people of my age, I find I get more
patient as I get older), and will await developments with interest.
Best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: Disc cache worth it?
On Tue, 24 Jun 2014 15:20:55 +0100, Vincent Sanders wrote:
> Because the code does not moderate its write rate you have to watch
> the hourglass as it saves those files to disc. This is made much
> worse, as as I understand it from knowlageable RISC OS people, because
> disc writes are not performed in the background.
Same problem on AmigaOS I think, although as I'm using a proper HDD
the delay is negligible (and the disk cache makes a noticeable
difference).
> In your example if we assume you managed to get four megabytes of
> cached data to be written and it took 30 seconds to achive that, we
> get a write rate of around 130K/second or roughly a Megabit/second.
> Your network connection does not have to be very good at all to outrun
> the disc and hence the disc cache is making a horrible trade in your
> case.
Remember that write speeds on SD cards are significantly slower than
read speeds, and lots of small writes are slower still.
It would be interesting to see if a Raspberry Pi running the GTK
version from SD card has the same slowness.
Chris
> Because the code does not moderate its write rate you have to watch
> the hourglass as it saves those files to disc. This is made much
> worse, as as I understand it from knowlageable RISC OS people, because
> disc writes are not performed in the background.
Same problem on AmigaOS I think, although as I'm using a proper HDD
the delay is negligible (and the disk cache makes a noticeable
difference).
> In your example if we assume you managed to get four megabytes of
> cached data to be written and it took 30 seconds to achive that, we
> get a write rate of around 130K/second or roughly a Megabit/second.
> Your network connection does not have to be very good at all to outrun
> the disc and hence the disc cache is making a horrible trade in your
> case.
Remember that write speeds on SD cards are significantly slower than
read speeds, and lots of small writes are slower still.
It would be interesting to see if a Raspberry Pi running the GTK
version from SD card has the same slowness.
Chris
Re: Disc cache worth it?
Although this reply is to Peter it applies to all the subsequent
discussion.
Firstly, as I did memntion in my original mail this feature is new and
not tuned yet so may have adverse behaviour on some systems. Please do
not draw any conclusions about the usefulness or otherwise of this
feature from *development* snapshots.
If you want stable behaviour the 3.1 release should be used. It may
well turn out that this feature is simply unsuitable for RISC OS but
we are at the beginning of a long road.
As we have seen with the issues around !Cache and now with general
perfomance, the challenges of building a cache suitable for use across
many systems are not inconsiderable
On Mon, Jun 23, 2014 at 05:58:52PM +0100, Peter Young wrote:
> I've been using the disc cache on RISC OS 2.19, ARMini, and I seem to
> have found some downsides to it, and I wonder if (a) I'm doing it
> correctly and (b) if it's worth the occasional faster opening of some
> sites.
Subsequent mails indicate you were using this correctly, as to the
"worth it" that is what we need to evaluate. I prevoiusly mentioned
it, but I shall re-iterate:
The persistant cache is purely a trade, in this case it is trading
disc resource for network resources.
I use the term disc resource carefully, it includes both storage space
*and* the time to store and retrieve the files. Similarly network
resource is the data downloaded *and* the latency getting that
data.
>
> If I load, for instance, http://www.bbc.co.uk/news/ as the first site
> of a session, it loads maybe a little faster, but then I get
> intermittent hourglass activity for sometimes up to thirty seconds,
> during which I can't do anything else. There are several other sites,
> for instance Wikipedia home page, which do the same. And the next day
> the same happens.
What is happening here is that when your browser has gone idle after
retrieving the website you have numerous objects (images html files
etc.) which are eligible to be written out to the persistent cache.
Given the front page of the BBC news site is (right now) 1.1 Megabytes
in 187 files which can rise to in the region of 2 Megabytes or more if
there are a image heavy news stories, that represents a great deal of
data to be written out.
The write out task then starts writing these to disc limited by a
bandwidth cap. In the current implementation this is hard wired to a
maximum write bandwidth of 512K/second. It had not occurred to me that
such a rate would not be achievable.
Because the code does not moderate its write rate you have to watch
the hourglass as it saves those files to disc. This is made much
worse, as as I understand it from knowlageable RISC OS people, because
disc writes are not performed in the background.
In your example if we assume you managed to get four megabytes of
cached data to be written and it took 30 seconds to achive that, we
get a write rate of around 130K/second or roughly a Megabit/second.
Your network connection does not have to be very good at all to outrun
the disc and hence the disc cache is making a horrible trade in your
case.
>
> Looking in !Cache, which is in !Boot.!Resources, I find that in the
> Caches.Default.NetSurf directory there are currently 1933 files,
> totalling 22449384 bytes. Is this to be expected, as I don't use
> NetSurf a huge amount? I've already excluded this directory from my
> daily backup, which has been taking a lot longer since I started using
> !Cache.
The web is huge these days, 22 Megabytes is literally only 20 pages on
most sites, even if the site shares those objects between multiple
pages, just visiting all the heading sections of BBC news requires
10Megabytes of persistant storage and over 1000 files.
For example google chrome by default uses 16Megabyte blocks to store
sub 16k sized objects and creates four of those to start with
It is not uncommon for a well used browser to have several gigabytes
of disc used for web caches. In most current systems using a gigabyte
of RAM let alone Disc is not uncommon.
In summary, the cache:
- Is still in development.
- Is not a panacea and will not benefit everyone.
- Is a compromise trade, and it seems for some systems with slow disc
it is literally faster to retrieve from network than from local
storage.
- Is likely to be very large to be effective as the source web pages
are large.
- Can be disabled by setting its size to zero.
I will look into adding a heuristic to disable or at least tune the
cache writeout if it detects it is exceeding the available disc
bandwidth.
--
Regards Vincent
http://www.kyllikki.org/
discussion.
Firstly, as I did memntion in my original mail this feature is new and
not tuned yet so may have adverse behaviour on some systems. Please do
not draw any conclusions about the usefulness or otherwise of this
feature from *development* snapshots.
If you want stable behaviour the 3.1 release should be used. It may
well turn out that this feature is simply unsuitable for RISC OS but
we are at the beginning of a long road.
As we have seen with the issues around !Cache and now with general
perfomance, the challenges of building a cache suitable for use across
many systems are not inconsiderable
On Mon, Jun 23, 2014 at 05:58:52PM +0100, Peter Young wrote:
> I've been using the disc cache on RISC OS 2.19, ARMini, and I seem to
> have found some downsides to it, and I wonder if (a) I'm doing it
> correctly and (b) if it's worth the occasional faster opening of some
> sites.
Subsequent mails indicate you were using this correctly, as to the
"worth it" that is what we need to evaluate. I prevoiusly mentioned
it, but I shall re-iterate:
The persistant cache is purely a trade, in this case it is trading
disc resource for network resources.
I use the term disc resource carefully, it includes both storage space
*and* the time to store and retrieve the files. Similarly network
resource is the data downloaded *and* the latency getting that
data.
>
> If I load, for instance, http://www.bbc.co.uk/news/ as the first site
> of a session, it loads maybe a little faster, but then I get
> intermittent hourglass activity for sometimes up to thirty seconds,
> during which I can't do anything else. There are several other sites,
> for instance Wikipedia home page, which do the same. And the next day
> the same happens.
What is happening here is that when your browser has gone idle after
retrieving the website you have numerous objects (images html files
etc.) which are eligible to be written out to the persistent cache.
Given the front page of the BBC news site is (right now) 1.1 Megabytes
in 187 files which can rise to in the region of 2 Megabytes or more if
there are a image heavy news stories, that represents a great deal of
data to be written out.
The write out task then starts writing these to disc limited by a
bandwidth cap. In the current implementation this is hard wired to a
maximum write bandwidth of 512K/second. It had not occurred to me that
such a rate would not be achievable.
Because the code does not moderate its write rate you have to watch
the hourglass as it saves those files to disc. This is made much
worse, as as I understand it from knowlageable RISC OS people, because
disc writes are not performed in the background.
In your example if we assume you managed to get four megabytes of
cached data to be written and it took 30 seconds to achive that, we
get a write rate of around 130K/second or roughly a Megabit/second.
Your network connection does not have to be very good at all to outrun
the disc and hence the disc cache is making a horrible trade in your
case.
>
> Looking in !Cache, which is in !Boot.!Resources, I find that in the
> Caches.Default.NetSurf directory there are currently 1933 files,
> totalling 22449384 bytes. Is this to be expected, as I don't use
> NetSurf a huge amount? I've already excluded this directory from my
> daily backup, which has been taking a lot longer since I started using
> !Cache.
The web is huge these days, 22 Megabytes is literally only 20 pages on
most sites, even if the site shares those objects between multiple
pages, just visiting all the heading sections of BBC news requires
10Megabytes of persistant storage and over 1000 files.
For example google chrome by default uses 16Megabyte blocks to store
sub 16k sized objects and creates four of those to start with
It is not uncommon for a well used browser to have several gigabytes
of disc used for web caches. In most current systems using a gigabyte
of RAM let alone Disc is not uncommon.
In summary, the cache:
- Is still in development.
- Is not a panacea and will not benefit everyone.
- Is a compromise trade, and it seems for some systems with slow disc
it is literally faster to retrieve from network than from local
storage.
- Is likely to be very large to be effective as the source web pages
are large.
- Can be disabled by setting its size to zero.
I will look into adding a heuristic to disable or at least tune the
cache writeout if it detects it is exceeding the available disc
bandwidth.
--
Regards Vincent
http://www.kyllikki.org/
Re: Disc cache worth it?
In article <mpro.n7mvk5008hres0700.pittdj@pittdj.co.uk>, David Pitt
<pittdj@pittdj.co.uk> wrote:
> Peter Young, on 23 Jun, wrote:
> > I've been using the disc cache on RISC OS 2.19, ARMini, and I seem to
> > have found some downsides to it, and I wonder if (a) I'm doing it
> > correctly and (b) if it's worth the occasional faster opening of some
> > sites.
> >
[snip]
> Overall I was not persuaded that the cache results is any meaningful
> speed up and could even slow things up, not just on the Raspberry Pi but
> also on the Iyonix and VRPC on a Windows 7 laptop with an SSD.
It's all a bit technical for me and I just tried it to see what might
happen on a Windows 7 VRPC machine that is fitted with a Crucial
Adrenaline SSD cache.
I am, thus far, not getting problems and it fairly motors. Might the SSD
cache have any relevance?
[snip]
> I have uninstalled !Cache.
It's staying where it is on this machine for now.
<pittdj@pittdj.co.uk> wrote:
> Peter Young, on 23 Jun, wrote:
> > I've been using the disc cache on RISC OS 2.19, ARMini, and I seem to
> > have found some downsides to it, and I wonder if (a) I'm doing it
> > correctly and (b) if it's worth the occasional faster opening of some
> > sites.
> >
[snip]
> Overall I was not persuaded that the cache results is any meaningful
> speed up and could even slow things up, not just on the Raspberry Pi but
> also on the Iyonix and VRPC on a Windows 7 laptop with an SSD.
It's all a bit technical for me and I just tried it to see what might
happen on a Windows 7 VRPC machine that is fitted with a Crucial
Adrenaline SSD cache.
I am, thus far, not getting problems and it fairly motors. Might the SSD
cache have any relevance?
[snip]
> I have uninstalled !Cache.
It's staying where it is on this machine for now.
Re: Disc cache worth it?
Tony Moore, on 24 Jun, wrote:
> On 24 Jun 2014, David Pitt <pittdj@pittdj.co.uk> wrote:
>
> [snip]
>
> > !Cache on a RamDisc looks much more promising. This is much better, the
> > improvement is clear, and the machine is not taken over as the cache is
> > written.
>
> NetSurf already has a Memory Cache. For the Disc Cache to serve any useful
> purpose, it needs to be written to a non-volatile medium.
Indeed. I do agree, I was just testing something.
--
David Pitt
> On 24 Jun 2014, David Pitt <pittdj@pittdj.co.uk> wrote:
>
> [snip]
>
> > !Cache on a RamDisc looks much more promising. This is much better, the
> > improvement is clear, and the machine is not taken over as the cache is
> > written.
>
> NetSurf already has a Memory Cache. For the Disc Cache to serve any useful
> purpose, it needs to be written to a non-volatile medium.
Indeed. I do agree, I was just testing something.
--
David Pitt
Re: Disc cache worth it?
On 24 Jun 2014, David Pitt <pittdj@pittdj.co.uk> wrote:
[snip]
> !Cache on a RamDisc looks much more promising. This is much better,
> the improvement is clear, and the machine is not taken over as the
> cache is written.
NetSurf already has a Memory Cache. For the Disc Cache to serve any
useful purpose, it needs to be written to a non-volatile medium.
Tony
[snip]
> !Cache on a RamDisc looks much more promising. This is much better,
> the improvement is clear, and the machine is not taken over as the
> cache is written.
NetSurf already has a Memory Cache. For the Disc Cache to serve any
useful purpose, it needs to be written to a non-volatile medium.
Tony
Re: Disc cache worth it?
Daniel Silverstone, on 24 Jun, wrote:
> On Tue, Jun 24, 2014 at 08:10:29 +0100, David Pitt wrote:
> > !Cache on a RamDisc looks much more promising. This is much better, the
> > improvement is clear, and the machine is not taken over as the cache is
> > written.
>
> You do realise that this is more work for the computer to do than simply
> increasing the maximum size of the RAM cache in the browser?
I had not got that far. The notion was just to highlight where the blockage
is.
In practice the two options perform similarly, as very briefly tested.
--
David Pitt
> On Tue, Jun 24, 2014 at 08:10:29 +0100, David Pitt wrote:
> > !Cache on a RamDisc looks much more promising. This is much better, the
> > improvement is clear, and the machine is not taken over as the cache is
> > written.
>
> You do realise that this is more work for the computer to do than simply
> increasing the maximum size of the RAM cache in the browser?
I had not got that far. The notion was just to highlight where the blockage
is.
In practice the two options perform similarly, as very briefly tested.
--
David Pitt
Re: Disc cache worth it?
On Tue, Jun 24, 2014 at 08:10:29 +0100, David Pitt wrote:
> !Cache on a RamDisc looks much more promising. This is much better, the
> improvement is clear, and the machine is not taken over as the cache is
> written.
You do realise that this is more work for the computer to do than simply
increasing the maximum size of the RAM cache in the browser?
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> !Cache on a RamDisc looks much more promising. This is much better, the
> improvement is clear, and the machine is not taken over as the cache is
> written.
You do realise that this is more work for the computer to do than simply
increasing the maximum size of the RAM cache in the browser?
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Re: Disc cache worth it?
On 23 Jun 2014 "Chris Young"
<chris.young@unsatisfactorysoftware.co.uk> wrote:
> On Mon, 23 Jun 2014 22:43:52 +0100, Peter Young wrote:
>>>> Thanks, Chris. I've a couple of busy days coming up, with one early
>>>> start, but I'll try to save a log after a new day's start-up, and give
>>>> some timings of the hourglass activity on the BBC news site. Where or
>>>> to whom should I post the log?
>>
>>> The best thing to do is raise a bug report and attach it to that.
>>
>> OK, but is it really a bug? I'll do as you suggest, anyway.
> If it's not working as it should, it's a bug. :)
> There may be something that can be done to improve matters, such as
> delaying disk cache writes until the browser isn't busy, or only
> writing out when the item is removed from the memory cache. It may be
> that it is a true bug and is writing when it shouldn't be, or there is
> some performance problem which is nothing to do with disk I/O.
Bug report submitted, with this mornings timings, and the logfile.
Best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
<chris.young@unsatisfactorysoftware.co.uk> wrote:
> On Mon, 23 Jun 2014 22:43:52 +0100, Peter Young wrote:
>>>> Thanks, Chris. I've a couple of busy days coming up, with one early
>>>> start, but I'll try to save a log after a new day's start-up, and give
>>>> some timings of the hourglass activity on the BBC news site. Where or
>>>> to whom should I post the log?
>>
>>> The best thing to do is raise a bug report and attach it to that.
>>
>> OK, but is it really a bug? I'll do as you suggest, anyway.
> If it's not working as it should, it's a bug. :)
> There may be something that can be done to improve matters, such as
> delaying disk cache writes until the browser isn't busy, or only
> writing out when the item is removed from the memory cache. It may be
> that it is a true bug and is writing when it shouldn't be, or there is
> some performance problem which is nothing to do with disk I/O.
Bug report submitted, with this mornings timings, and the logfile.
Best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: Disc cache worth it?
Rob Kendrick, on 23 Jun, wrote:
[snip]
> > Overall I was not persuaded that the cache results is any meaningful
> > speed up and could even slow things up, not just on the Raspberry Pi but
> > also on the Iyonix and VRPC on a Windows 7 laptop with an SSD.
>
> Certainly on UNIX and BeOS, it seems to provide a significant performance
> boost, but this is probably because of their far superior IO layers.
!Cache on a RamDisc confirms that.
--
David Pitt
[snip]
> > Overall I was not persuaded that the cache results is any meaningful
> > speed up and could even slow things up, not just on the Raspberry Pi but
> > also on the Iyonix and VRPC on a Windows 7 laptop with an SSD.
>
> Certainly on UNIX and BeOS, it seems to provide a significant performance
> boost, but this is probably because of their far superior IO layers.
!Cache on a RamDisc confirms that.
--
David Pitt
Re: Disc cache worth it?
Malcolm Hussain-Gambles, on 23 Jun, wrote:
> Just for a positive, I have a panda board my Internet connection is
> 120mbit. I do notice a difference.
The Panda is going to be faster than a Raspberry Pi.
> From my understanding and benchmarks the sd card can write at 20MB/sec
> and the fastest tcp I can get is 6MB/sec read and that's off a local
> webserver for testing purposes.
> So I can't see how it would be slower to be honest. I'm slightly confused.
As I understand it the small file write speed even on supposedly fast SD
cards can be very slow. This certainly seems to be the case on the Pi. It
first became really apparent after a particularly long winded !PackMan
installation. A large number of small files is a problem. External drives
are better but are only USB1.
!Cache on a RamDisc looks much more promising. This is much better, the
improvement is clear, and the machine is not taken over as the cache is
written.
--
David Pitt
> Just for a positive, I have a panda board my Internet connection is
> 120mbit. I do notice a difference.
The Panda is going to be faster than a Raspberry Pi.
> From my understanding and benchmarks the sd card can write at 20MB/sec
> and the fastest tcp I can get is 6MB/sec read and that's off a local
> webserver for testing purposes.
> So I can't see how it would be slower to be honest. I'm slightly confused.
As I understand it the small file write speed even on supposedly fast SD
cards can be very slow. This certainly seems to be the case on the Pi. It
first became really apparent after a particularly long winded !PackMan
installation. A large number of small files is a problem. External drives
are better but are only USB1.
!Cache on a RamDisc looks much more promising. This is much better, the
improvement is clear, and the machine is not taken over as the cache is
written.
--
David Pitt
Monday, 23 June 2014
Re: Disc cache worth it?
On 23 Jun 2014, Rob Kendrick <rjek@netsurf-browser.org> wrote:
[snip]
> On RISC OS, the disc cache *may* only be a win for people on slow
> connections.
Using RISC OS on a RiscPC, with a slow internet connection, and Cache
enabled, I found that launching half a dozen stories from Google News
caused the machine to be virtually unusable for half an hour, or more.
Judging by the hard-drive activity light, Cache writes to disc on the
fly. However, if it were to postpone writing until NetSurf was quit, the
delay would occur then. Either way, inconvenient.
Tony
[snip]
> On RISC OS, the disc cache *may* only be a win for people on slow
> connections.
Using RISC OS on a RiscPC, with a slow internet connection, and Cache
enabled, I found that launching half a dozen stories from Google News
caused the machine to be virtually unusable for half an hour, or more.
Judging by the hard-drive activity light, Cache writes to disc on the
fly. However, if it were to postpone writing until NetSurf was quit, the
delay would occur then. Either way, inconvenient.
Tony
Re: Disc cache worth it?
On Mon, 23 Jun 2014 22:43:52 +0100, Peter Young wrote:
> >> Thanks, Chris. I've a couple of busy days coming up, with one early
> >> start, but I'll try to save a log after a new day's start-up, and give
> >> some timings of the hourglass activity on the BBC news site. Where or
> >> to whom should I post the log?
>
> > The best thing to do is raise a bug report and attach it to that.
>
> OK, but is it really a bug? I'll do as you suggest, anyway.
If it's not working as it should, it's a bug. :)
There may be something that can be done to improve matters, such as
delaying disk cache writes until the browser isn't busy, or only
writing out when the item is removed from the memory cache. It may be
that it is a true bug and is writing when it shouldn't be, or there is
some performance problem which is nothing to do with disk I/O.
Chris
> >> Thanks, Chris. I've a couple of busy days coming up, with one early
> >> start, but I'll try to save a log after a new day's start-up, and give
> >> some timings of the hourglass activity on the BBC news site. Where or
> >> to whom should I post the log?
>
> > The best thing to do is raise a bug report and attach it to that.
>
> OK, but is it really a bug? I'll do as you suggest, anyway.
If it's not working as it should, it's a bug. :)
There may be something that can be done to improve matters, such as
delaying disk cache writes until the browser isn't busy, or only
writing out when the item is removed from the memory cache. It may be
that it is a true bug and is writing when it shouldn't be, or there is
some performance problem which is nothing to do with disk I/O.
Chris
Re: Disc cache worth it?
Perhaps having scrap and cache is causing issues on the same card?
I use memphis for scrap?
-- Sent with K-@ Mail - the evolution of emailing.
I use memphis for scrap?
On 23 Jun 2014, Rob Kendrick wrote:
On Mon, Jun 23, 2014 at 07:04:53PM +0100, David Pitt wrote:Peter Young, on 23 Jun, wrote:I've been using the disc cache on RISC OS 2.19, ARMini, and I seem to have
found some downsides to it, and I wonder if (a) I'm doing it correctly and
(b) if it's worth the occasional faster opening of some sites.
If I load, for instance, http://www.bbc.co.uk/news/ as the first site of a
session, it loads maybe a little faster, but then I get intermittent
hourglass activity for sometimes up to thirty seconds, during which I
can't do anything else. There are several other sites, for instance
Wikipedia home page, which do the same. And the next day the same happens.
I have found much the same, a really good example of this is the Daily
Mail's heavy weight site.
Ultimately, my advice is to not visit this service. This stands
regardless of any cache issues that may exist :)http://www.dailymail.co.uk/home/index.html
Writes to the Raspberry Pi's SD Card are so slow that !Cache is not going to
be good news on it. It is better with !Cache on a Fat32 harddisc connected
to the Pi and on the Iyonix but is still an issue.
Indeed, SD has poor write performance almost anywhere, like most
flash-based devices.Overall I was not persuaded that the cache results is any meaningful speed
up and could even slow things up, not just on the Raspberry Pi but also on
the Iyonix and VRPC on a Windows 7 laptop with an SSD.
Certainly on UNIX and BeOS, it seems to provide a significant
performance boost, but this is probably because of their far superior IO
layers.
On RISC OS, the disc cache *may* only be a win for people on slow
connections.
B.
-- Sent with K-@ Mail - the evolution of emailing.
Re: Disc cache worth it?
Just for a positive, I have a panda board my Internet connection is 120mbit. I do notice a difference.
>From my understanding and benchmarks the sd card can write at 20MB/sec and the fastest tcp I can get is 6MB/sec read and that's off a local webserver for testing purposes.
So I can't see how it would be slower to be honest. I'm slightly confused.
Cheers,
Malcolm
-- Sent with K-@ Mail - the evolution of emailing.
>From my understanding and benchmarks the sd card can write at 20MB/sec and the fastest tcp I can get is 6MB/sec read and that's off a local webserver for testing purposes.
So I can't see how it would be slower to be honest. I'm slightly confused.
Cheers,
Malcolm
On 23 Jun 2014, Rob Kendrick wrote:
On Mon, Jun 23, 2014 at 07:04:53PM +0100, David Pitt wrote:Peter Young, on 23 Jun, wrote:I've been using the disc cache on RISC OS 2.19, ARMini, and I seem to have
found some downsides to it, and I wonder if (a) I'm doing it correctly and
(b) if it's worth the occasional faster opening of some sites.
If I load, for instance, http://www.bbc.co.uk/news/ as the first site of a
session, it loads maybe a little faster, but then I get intermittent
hourglass activity for sometimes up to thirty seconds, during which I
can't do anything else. There are several other sites, for instance
Wikipedia home page, which do the same. And the next day the same happens.
I have found much the same, a really good example of this is the Daily
Mail's heavy weight site.
Ultimately, my advice is to not visit this service. This stands
regardless of any cache issues that may exist :)http://www.dailymail.co.uk/home/index.html
Writes to the Raspberry Pi's SD Card are so slow that !Cache is not going to
be good news on it. It is better with !Cache on a Fat32 harddisc connected
to the Pi and on the Iyonix but is still an issue.
Indeed, SD has poor write performance almost anywhere, like most
flash-based devices.Overall I was not persuaded that the cache results is any meaningful speed
up and could even slow things up, not just on the Raspberry Pi but also on
the Iyonix and VRPC on a Windows 7 laptop with an SSD.
Certainly on UNIX and BeOS, it seems to provide a significant
performance boost, but this is probably because of their far superior IO
layers.
On RISC OS, the disc cache *may* only be a win for people on slow
connections.
B.
-- Sent with K-@ Mail - the evolution of emailing.
Re: Disc cache worth it?
On Mon, Jun 23, 2014 at 07:04:53PM +0100, David Pitt wrote:
> Peter Young, on 23 Jun, wrote:
>
> > I've been using the disc cache on RISC OS 2.19, ARMini, and I seem to have
> > found some downsides to it, and I wonder if (a) I'm doing it correctly and
> > (b) if it's worth the occasional faster opening of some sites.
> >
> > If I load, for instance, http://www.bbc.co.uk/news/ as the first site of a
> > session, it loads maybe a little faster, but then I get intermittent
> > hourglass activity for sometimes up to thirty seconds, during which I
> > can't do anything else. There are several other sites, for instance
> > Wikipedia home page, which do the same. And the next day the same happens.
>
> I have found much the same, a really good example of this is the Daily
> Mail's heavy weight site.
Ultimately, my advice is to not visit this service. This stands
regardless of any cache issues that may exist :)
> http://www.dailymail.co.uk/home/index.html
>
> Writes to the Raspberry Pi's SD Card are so slow that !Cache is not going to
> be good news on it. It is better with !Cache on a Fat32 harddisc connected
> to the Pi and on the Iyonix but is still an issue.
Indeed, SD has poor write performance almost anywhere, like most
flash-based devices.
> Overall I was not persuaded that the cache results is any meaningful speed
> up and could even slow things up, not just on the Raspberry Pi but also on
> the Iyonix and VRPC on a Windows 7 laptop with an SSD.
Certainly on UNIX and BeOS, it seems to provide a significant
performance boost, but this is probably because of their far superior IO
layers.
On RISC OS, the disc cache *may* only be a win for people on slow
connections.
B.
> Peter Young, on 23 Jun, wrote:
>
> > I've been using the disc cache on RISC OS 2.19, ARMini, and I seem to have
> > found some downsides to it, and I wonder if (a) I'm doing it correctly and
> > (b) if it's worth the occasional faster opening of some sites.
> >
> > If I load, for instance, http://www.bbc.co.uk/news/ as the first site of a
> > session, it loads maybe a little faster, but then I get intermittent
> > hourglass activity for sometimes up to thirty seconds, during which I
> > can't do anything else. There are several other sites, for instance
> > Wikipedia home page, which do the same. And the next day the same happens.
>
> I have found much the same, a really good example of this is the Daily
> Mail's heavy weight site.
Ultimately, my advice is to not visit this service. This stands
regardless of any cache issues that may exist :)
> http://www.dailymail.co.uk/home/index.html
>
> Writes to the Raspberry Pi's SD Card are so slow that !Cache is not going to
> be good news on it. It is better with !Cache on a Fat32 harddisc connected
> to the Pi and on the Iyonix but is still an issue.
Indeed, SD has poor write performance almost anywhere, like most
flash-based devices.
> Overall I was not persuaded that the cache results is any meaningful speed
> up and could even slow things up, not just on the Raspberry Pi but also on
> the Iyonix and VRPC on a Windows 7 laptop with an SSD.
Certainly on UNIX and BeOS, it seems to provide a significant
performance boost, but this is probably because of their far superior IO
layers.
On RISC OS, the disc cache *may* only be a win for people on slow
connections.
B.
Re: Disc cache worth it?
On 23 Jun 2014 "Chris Young"
<chris.young@unsatisfactorysoftware.co.uk> wrote:
> On Mon, 23 Jun 2014 21:13:17 +0100, Peter Young wrote:
>> Thanks, Chris. I've a couple of busy days coming up, with one early
>> start, but I'll try to save a log after a new day's start-up, and give
>> some timings of the hourglass activity on the BBC news site. Where or
>> to whom should I post the log?
> The best thing to do is raise a bug report and attach it to that.
OK, but is it really a bug? I'll do as you suggest, anyway.
Best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
<chris.young@unsatisfactorysoftware.co.uk> wrote:
> On Mon, 23 Jun 2014 21:13:17 +0100, Peter Young wrote:
>> Thanks, Chris. I've a couple of busy days coming up, with one early
>> start, but I'll try to save a log after a new day's start-up, and give
>> some timings of the hourglass activity on the BBC news site. Where or
>> to whom should I post the log?
> The best thing to do is raise a bug report and attach it to that.
OK, but is it really a bug? I'll do as you suggest, anyway.
Best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: Disc cache worth it?
On Mon, 23 Jun 2014 21:13:17 +0100, Peter Young wrote:
> Thanks, Chris. I've a couple of busy days coming up, with one early
> start, but I'll try to save a log after a new day's start-up, and give
> some timings of the hourglass activity on the BBC news site. Where or
> to whom should I post the log?
The best thing to do is raise a bug report and attach it to that.
Chris
> Thanks, Chris. I've a couple of busy days coming up, with one early
> start, but I'll try to save a log after a new day's start-up, and give
> some timings of the hourglass activity on the BBC news site. Where or
> to whom should I post the log?
The best thing to do is raise a bug report and attach it to that.
Chris
Re: Disc cache worth it?
On 23 Jun 2014 David Pitt <pittdj@pittdj.co.uk> wrote:
> Peter Young, on 23 Jun, wrote:
>> I've been using the disc cache on RISC OS 2.19, ARMini, and I seem to have
>> found some downsides to it, and I wonder if (a) I'm doing it correctly and
>> (b) if it's worth the occasional faster opening of some sites.
>>
>> If I load, for instance, http://www.bbc.co.uk/news/ as the first site of a
>> session, it loads maybe a little faster, but then I get intermittent
>> hourglass activity for sometimes up to thirty seconds, during which I
>> can't do anything else. There are several other sites, for instance
>> Wikipedia home page, which do the same. And the next day the same happens.
> I have found much the same, a really good example of this is the Daily
> Mail's heavy weight site.
> http://www.dailymail.co.uk/home/index.html
> Writes to the Raspberry Pi's SD Card are so slow that !Cache is not going to
> be good news on it. It is better with !Cache on a Fat32 harddisc connected
> to the Pi and on the Iyonix but is still an issue.
> Overall I was not persuaded that the cache results is any meaningful speed
> up and could even slow things up, not just on the Raspberry Pi but also on
> the Iyonix and VRPC on a Windows 7 laptop with an SSD.
Thanks, David, and I'm glad it's not just me. I'll await what Chris
makes of a logfile, when I get a round tuit, and will maybe then
uninstall !Cache.
Best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> Peter Young, on 23 Jun, wrote:
>> I've been using the disc cache on RISC OS 2.19, ARMini, and I seem to have
>> found some downsides to it, and I wonder if (a) I'm doing it correctly and
>> (b) if it's worth the occasional faster opening of some sites.
>>
>> If I load, for instance, http://www.bbc.co.uk/news/ as the first site of a
>> session, it loads maybe a little faster, but then I get intermittent
>> hourglass activity for sometimes up to thirty seconds, during which I
>> can't do anything else. There are several other sites, for instance
>> Wikipedia home page, which do the same. And the next day the same happens.
> I have found much the same, a really good example of this is the Daily
> Mail's heavy weight site.
> http://www.dailymail.co.uk/home/index.html
> Writes to the Raspberry Pi's SD Card are so slow that !Cache is not going to
> be good news on it. It is better with !Cache on a Fat32 harddisc connected
> to the Pi and on the Iyonix but is still an issue.
> Overall I was not persuaded that the cache results is any meaningful speed
> up and could even slow things up, not just on the Raspberry Pi but also on
> the Iyonix and VRPC on a Windows 7 laptop with an SSD.
Thanks, David, and I'm glad it's not just me. I'll await what Chris
makes of a logfile, when I get a round tuit, and will maybe then
uninstall !Cache.
Best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: Disc cache worth it?
On 23 Jun 2014 "Chris Young"
<chris.young@unsatisfactorysoftware.co.uk> wrote:
> On Mon, 23 Jun 2014 17:58:52 +0100, Peter Young wrote:
>> If I load, for instance, http://www.bbc.co.uk/news/ as the first site
>> of a session, it loads maybe a little faster, but then I get
>> intermittent hourglass activity for sometimes up to thirty seconds,
>> during which I can't do anything else. There are several other sites,
>> for instance Wikipedia home page, which do the same. And the next day
>> the same happens.
> I'm sure Vince will correct me here, but I believe NetSurf saves the
> cache files to disk when they are downloaded (as opposed to when they
> are evicted from the memory cache), so you will get a delay as NetSurf
> gets busy saving the files.
> If you've gone back to the same site though most of the files should
> be loading from disk and I wouldn't expect any additional delay. You
> will need to post a log file so we can get a handle on exactly what is
> causing the pauses.
Thanks, Chris. I've a couple of busy days coming up, with one early
start, but I'll try to save a log after a new day's start-up, and give
some timings of the hourglass activity on the BBC news site. Where or
to whom should I post the log?
>> Looking in !Cache, which is in !Boot.!Resources, I find that in the
>> Caches.Default.NetSurf directory there are currently 1933 files,
>> totalling 22449384 bytes. Is this to be expected, as I don't use
>> NetSurf a huge amount?
> Yes. That's only 22MB. The default limit is 1GB.
>> I've already excluded this directory from my
>> daily backup, which has been taking a lot longer since I started using
>> !Cache.
> There's no point in backing up these files.
Thanks again for these two points.
Best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
<chris.young@unsatisfactorysoftware.co.uk> wrote:
> On Mon, 23 Jun 2014 17:58:52 +0100, Peter Young wrote:
>> If I load, for instance, http://www.bbc.co.uk/news/ as the first site
>> of a session, it loads maybe a little faster, but then I get
>> intermittent hourglass activity for sometimes up to thirty seconds,
>> during which I can't do anything else. There are several other sites,
>> for instance Wikipedia home page, which do the same. And the next day
>> the same happens.
> I'm sure Vince will correct me here, but I believe NetSurf saves the
> cache files to disk when they are downloaded (as opposed to when they
> are evicted from the memory cache), so you will get a delay as NetSurf
> gets busy saving the files.
> If you've gone back to the same site though most of the files should
> be loading from disk and I wouldn't expect any additional delay. You
> will need to post a log file so we can get a handle on exactly what is
> causing the pauses.
Thanks, Chris. I've a couple of busy days coming up, with one early
start, but I'll try to save a log after a new day's start-up, and give
some timings of the hourglass activity on the BBC news site. Where or
to whom should I post the log?
>> Looking in !Cache, which is in !Boot.!Resources, I find that in the
>> Caches.Default.NetSurf directory there are currently 1933 files,
>> totalling 22449384 bytes. Is this to be expected, as I don't use
>> NetSurf a huge amount?
> Yes. That's only 22MB. The default limit is 1GB.
>> I've already excluded this directory from my
>> daily backup, which has been taking a lot longer since I started using
>> !Cache.
> There's no point in backing up these files.
Thanks again for these two points.
Best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: Disc cache worth it?
Peter Young, on 23 Jun, wrote:
> I've been using the disc cache on RISC OS 2.19, ARMini, and I seem to have
> found some downsides to it, and I wonder if (a) I'm doing it correctly and
> (b) if it's worth the occasional faster opening of some sites.
>
> If I load, for instance, http://www.bbc.co.uk/news/ as the first site of a
> session, it loads maybe a little faster, but then I get intermittent
> hourglass activity for sometimes up to thirty seconds, during which I
> can't do anything else. There are several other sites, for instance
> Wikipedia home page, which do the same. And the next day the same happens.
I have found much the same, a really good example of this is the Daily
Mail's heavy weight site.
http://www.dailymail.co.uk/home/index.html
Writes to the Raspberry Pi's SD Card are so slow that !Cache is not going to
be good news on it. It is better with !Cache on a Fat32 harddisc connected
to the Pi and on the Iyonix but is still an issue.
Overall I was not persuaded that the cache results is any meaningful speed
up and could even slow things up, not just on the Raspberry Pi but also on
the Iyonix and VRPC on a Windows 7 laptop with an SSD.
> Looking in !Cache, which is in !Boot.!Resources, I find that in the
> Caches.Default.NetSurf directory there are currently 1933 files, totalling
> 22449384 bytes. Is this to be expected, as I don't use NetSurf a huge
> amount? I've already excluded this directory from my daily backup, which
> has been taking a lot longer since I started using !Cache.
A lot of stuff is cached and the default maximum cache size is 1GB. It's not
worth backing up, it's transient data that expires in a default of 28 days.
I have uninstalled !Cache.
--
David Pitt
> I've been using the disc cache on RISC OS 2.19, ARMini, and I seem to have
> found some downsides to it, and I wonder if (a) I'm doing it correctly and
> (b) if it's worth the occasional faster opening of some sites.
>
> If I load, for instance, http://www.bbc.co.uk/news/ as the first site of a
> session, it loads maybe a little faster, but then I get intermittent
> hourglass activity for sometimes up to thirty seconds, during which I
> can't do anything else. There are several other sites, for instance
> Wikipedia home page, which do the same. And the next day the same happens.
I have found much the same, a really good example of this is the Daily
Mail's heavy weight site.
http://www.dailymail.co.uk/home/index.html
Writes to the Raspberry Pi's SD Card are so slow that !Cache is not going to
be good news on it. It is better with !Cache on a Fat32 harddisc connected
to the Pi and on the Iyonix but is still an issue.
Overall I was not persuaded that the cache results is any meaningful speed
up and could even slow things up, not just on the Raspberry Pi but also on
the Iyonix and VRPC on a Windows 7 laptop with an SSD.
> Looking in !Cache, which is in !Boot.!Resources, I find that in the
> Caches.Default.NetSurf directory there are currently 1933 files, totalling
> 22449384 bytes. Is this to be expected, as I don't use NetSurf a huge
> amount? I've already excluded this directory from my daily backup, which
> has been taking a lot longer since I started using !Cache.
A lot of stuff is cached and the default maximum cache size is 1GB. It's not
worth backing up, it's transient data that expires in a default of 28 days.
I have uninstalled !Cache.
--
David Pitt
Re: Disc cache worth it?
On Mon, 23 Jun 2014 17:58:52 +0100, Peter Young wrote:
> If I load, for instance, http://www.bbc.co.uk/news/ as the first site
> of a session, it loads maybe a little faster, but then I get
> intermittent hourglass activity for sometimes up to thirty seconds,
> during which I can't do anything else. There are several other sites,
> for instance Wikipedia home page, which do the same. And the next day
> the same happens.
I'm sure Vince will correct me here, but I believe NetSurf saves the
cache files to disk when they are downloaded (as opposed to when they
are evicted from the memory cache), so you will get a delay as NetSurf
gets busy saving the files.
If you've gone back to the same site though most of the files should
be loading from disk and I wouldn't expect any additional delay. You
will need to post a log file so we can get a handle on exactly what is
causing the pauses.
> Looking in !Cache, which is in !Boot.!Resources, I find that in the
> Caches.Default.NetSurf directory there are currently 1933 files,
> totalling 22449384 bytes. Is this to be expected, as I don't use
> NetSurf a huge amount?
Yes. That's only 22MB. The default limit is 1GB.
> I've already excluded this directory from my
> daily backup, which has been taking a lot longer since I started using
> !Cache.
There's no point in backing up these files.
Chris
> If I load, for instance, http://www.bbc.co.uk/news/ as the first site
> of a session, it loads maybe a little faster, but then I get
> intermittent hourglass activity for sometimes up to thirty seconds,
> during which I can't do anything else. There are several other sites,
> for instance Wikipedia home page, which do the same. And the next day
> the same happens.
I'm sure Vince will correct me here, but I believe NetSurf saves the
cache files to disk when they are downloaded (as opposed to when they
are evicted from the memory cache), so you will get a delay as NetSurf
gets busy saving the files.
If you've gone back to the same site though most of the files should
be loading from disk and I wouldn't expect any additional delay. You
will need to post a log file so we can get a handle on exactly what is
causing the pauses.
> Looking in !Cache, which is in !Boot.!Resources, I find that in the
> Caches.Default.NetSurf directory there are currently 1933 files,
> totalling 22449384 bytes. Is this to be expected, as I don't use
> NetSurf a huge amount?
Yes. That's only 22MB. The default limit is 1GB.
> I've already excluded this directory from my
> daily backup, which has been taking a lot longer since I started using
> !Cache.
There's no point in backing up these files.
Chris
Disc cache worth it?
I've been using the disc cache on RISC OS 2.19, ARMini, and I seem to
have found some downsides to it, and I wonder if (a) I'm doing it
correctly and (b) if it's worth the occasional faster opening of some
sites.
If I load, for instance, http://www.bbc.co.uk/news/ as the first site
of a session, it loads maybe a little faster, but then I get
intermittent hourglass activity for sometimes up to thirty seconds,
during which I can't do anything else. There are several other sites,
for instance Wikipedia home page, which do the same. And the next day
the same happens.
Looking in !Cache, which is in !Boot.!Resources, I find that in the
Caches.Default.NetSurf directory there are currently 1933 files,
totalling 22449384 bytes. Is this to be expected, as I don't use
NetSurf a huge amount? I've already excluded this directory from my
daily backup, which has been taking a lot longer since I started using
!Cache.
Best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
have found some downsides to it, and I wonder if (a) I'm doing it
correctly and (b) if it's worth the occasional faster opening of some
sites.
If I load, for instance, http://www.bbc.co.uk/news/ as the first site
of a session, it loads maybe a little faster, but then I get
intermittent hourglass activity for sometimes up to thirty seconds,
during which I can't do anything else. There are several other sites,
for instance Wikipedia home page, which do the same. And the next day
the same happens.
Looking in !Cache, which is in !Boot.!Resources, I find that in the
Caches.Default.NetSurf directory there are currently 1933 files,
totalling 22449384 bytes. Is this to be expected, as I don't use
NetSurf a huge amount? I've already excluded this directory from my
daily backup, which has been taking a lot longer since I started using
!Cache.
Best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Sunday, 15 June 2014
Re: Not enough application memory to start Basic
In article <5418100903bob@mightyoak.org.uk>,
Bob Latham <bob@mightyoak.org.uk> wrote:
> I've tried hiding !cache so I can control when it is filer_booted but it
> still gives the problem.
I downloaded #1967 a day or so ago, merged the provided !Boot and !System
directories with my existing and I have seen no problems with RO4.39.
!NetSurf isn't loaded unless I need to use it.
--
Tools With A Mission
sending tools across the world
http://www.twam.co.uk/
Bob Latham <bob@mightyoak.org.uk> wrote:
> I've tried hiding !cache so I can control when it is filer_booted but it
> still gives the problem.
I downloaded #1967 a day or so ago, merged the provided !Boot and !System
directories with my existing and I have seen no problems with RO4.39.
!NetSurf isn't loaded unless I need to use it.
--
Tools With A Mission
sending tools across the world
http://www.twam.co.uk/
Re: Not enough application memory to start Basic
In article <9ed6811754.Andrew-Pin@waitrose.com>,
Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
> In message <20140613221516.GC1754@platypus.pepperfish.net>
> on 13 Jun 2014 Rob Kendrick <rjek@netsurf-browser.org> wrote:
> > On Fri, Jun 13, 2014 at 09:42:54PM +0100, Andrew Pinder wrote:
> >>> Couple people try moving it elsewhere (ie, outside !Boot.Resources),
> >>> and configure !Boot to "look at" !Cache *BEFORE* it looks at or runs
> >>> !NetSurf, and see if this solves the problem?
> >>
> >> Well, that put it slightly *later* in the Boot sequence but still
> >> before looking at !NetSurf. Same error.
> > Thanks, that's a useful data point. We'll look more closely.
> I forgot to mention, I'm running 5.20 on an ARMini.
I'm using ARMiniX 5.21.
> I tried moving !Cache from Look at to Run, with no change. At that
> stage I also removed !NetSurf from the boot completely. Eventually
> removing !Cache completely from the boot sequence got rid of the error
> and brought back the ARMini splash banner, which I now realise is what
> had been missing.
I've tried hiding !cache so I can control when it is filer_booted but it
still gives the problem.
Bob.
Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
> In message <20140613221516.GC1754@platypus.pepperfish.net>
> on 13 Jun 2014 Rob Kendrick <rjek@netsurf-browser.org> wrote:
> > On Fri, Jun 13, 2014 at 09:42:54PM +0100, Andrew Pinder wrote:
> >>> Couple people try moving it elsewhere (ie, outside !Boot.Resources),
> >>> and configure !Boot to "look at" !Cache *BEFORE* it looks at or runs
> >>> !NetSurf, and see if this solves the problem?
> >>
> >> Well, that put it slightly *later* in the Boot sequence but still
> >> before looking at !NetSurf. Same error.
> > Thanks, that's a useful data point. We'll look more closely.
> I forgot to mention, I'm running 5.20 on an ARMini.
I'm using ARMiniX 5.21.
> I tried moving !Cache from Look at to Run, with no change. At that
> stage I also removed !NetSurf from the boot completely. Eventually
> removing !Cache completely from the boot sequence got rid of the error
> and brought back the ARMini splash banner, which I now realise is what
> had been missing.
I've tried hiding !cache so I can control when it is filer_booted but it
still gives the problem.
Bob.
Re: Not enough application memory to start Basic
Andrew Pinder, on 15 Jun, wrote:
> In message <d55ad31754.Andrew-Pin@waitrose.com>
> on 14 Jun 2014 Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
>
> > In message <mpro.n768be0c1izuo01q9.lists@stevefryatt.org.uk>
> > on 14 Jun 2014 Steve Fryatt <lists@stevefryatt.org.uk> wrote:
>
> > > I don't run NetSurf during the boot sequence -- are all the people
> > > seeing issues doing that? What are people's Next slots configured to
> > > during the boot process?
>
> > On completion of booting, my Next slot is set to 640k. I don't know how
> > to tell if it's different during boot.
>
> Adding
>
> WimpSlot -min 16k -max 16k
>
> to the !Run file just before
>
> Run <Cache$AppDir>.!RunImage
>
> gets rid of the error message. It does, however, lead the application to
> think it has not been invoked via its !Boot file, so it opens the Cache
> directory. This is tested via
>
> SYS "XOS_ReadVarVal","Cache$FromBoot",block%,-1 TO ,,exists%
>
> Cache$From!Boot is set in the !Boot file before the !Run file is called
> and then unset immediately afterwards.
If the error being seen above is the same as the error I saw here then the
easy way to duck it is to comment out the Run <SysLog$Dir>.!Run line in
!Cache.!Run. But then I never saw a problem with !Cache in !Boot.Resources,
the problem only showed up on attempting to use !Boot's 'Look at' tool.
I do have a very much simpler cache providing application here using only
Obey files. This may or may not be of interest to the NetSurf developers.
--
David Pitt
> In message <d55ad31754.Andrew-Pin@waitrose.com>
> on 14 Jun 2014 Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
>
> > In message <mpro.n768be0c1izuo01q9.lists@stevefryatt.org.uk>
> > on 14 Jun 2014 Steve Fryatt <lists@stevefryatt.org.uk> wrote:
>
> > > I don't run NetSurf during the boot sequence -- are all the people
> > > seeing issues doing that? What are people's Next slots configured to
> > > during the boot process?
>
> > On completion of booting, my Next slot is set to 640k. I don't know how
> > to tell if it's different during boot.
>
> Adding
>
> WimpSlot -min 16k -max 16k
>
> to the !Run file just before
>
> Run <Cache$AppDir>.!RunImage
>
> gets rid of the error message. It does, however, lead the application to
> think it has not been invoked via its !Boot file, so it opens the Cache
> directory. This is tested via
>
> SYS "XOS_ReadVarVal","Cache$FromBoot",block%,-1 TO ,,exists%
>
> Cache$From!Boot is set in the !Boot file before the !Run file is called
> and then unset immediately afterwards.
If the error being seen above is the same as the error I saw here then the
easy way to duck it is to comment out the Run <SysLog$Dir>.!Run line in
!Cache.!Run. But then I never saw a problem with !Cache in !Boot.Resources,
the problem only showed up on attempting to use !Boot's 'Look at' tool.
I do have a very much simpler cache providing application here using only
Obey files. This may or may not be of interest to the NetSurf developers.
--
David Pitt
Re: Not enough application memory to start Basic
In message <d55ad31754.Andrew-Pin@waitrose.com>
on 14 Jun 2014 Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
> In message <mpro.n768be0c1izuo01q9.lists@stevefryatt.org.uk>
> on 14 Jun 2014 Steve Fryatt <lists@stevefryatt.org.uk> wrote:
>> I don't run NetSurf during the boot sequence -- are all the people seeing
>> issues doing that? What are people's Next slots configured to during the
>> boot process?
> On completion of booting, my Next slot is set to 640k. I don't know
> how to tell if it's different during boot.
Adding
WimpSlot -min 16k -max 16k
to the !Run file just before
Run <Cache$AppDir>.!RunImage
gets rid of the error message. It does, however, lead the application
to think it has not been invoked via its !Boot file, so it opens the
Cache directory. This is tested via
SYS "XOS_ReadVarVal","Cache$FromBoot",block%,-1 TO ,,exists%
Cache$From!Boot is set in the !Boot file before the !Run file is
called and then unset immediately afterwards.
Regards
Andrew
--
Andrew Pinder
on 14 Jun 2014 Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
> In message <mpro.n768be0c1izuo01q9.lists@stevefryatt.org.uk>
> on 14 Jun 2014 Steve Fryatt <lists@stevefryatt.org.uk> wrote:
>> I don't run NetSurf during the boot sequence -- are all the people seeing
>> issues doing that? What are people's Next slots configured to during the
>> boot process?
> On completion of booting, my Next slot is set to 640k. I don't know
> how to tell if it's different during boot.
Adding
WimpSlot -min 16k -max 16k
to the !Run file just before
Run <Cache$AppDir>.!RunImage
gets rid of the error message. It does, however, lead the application
to think it has not been invoked via its !Boot file, so it opens the
Cache directory. This is tested via
SYS "XOS_ReadVarVal","Cache$FromBoot",block%,-1 TO ,,exists%
Cache$From!Boot is set in the !Boot file before the !Run file is
called and then unset immediately afterwards.
Regards
Andrew
--
Andrew Pinder
Saturday, 14 June 2014
Re: Not enough application memory to start Basic
In message <mpro.n768be0c1izuo01q9.lists@stevefryatt.org.uk>
on 14 Jun 2014 Steve Fryatt <lists@stevefryatt.org.uk> wrote:
> I don't run NetSurf during the boot sequence -- are all the people seeing
> issues doing that? What are people's Next slots configured to during the
> boot process?
On completion of booting, my Next slot is set to 640k. I don't know
how to tell if it's different during boot.
I've taken !NetSurf out of the boot sequence and that doesn't solve
the problem. I've moved !Cache from !Boot.Resources to
Utilities.Caution. Putting it at the end of the Look at list in Boot
causes the problem to occur. I then moved it to last in the list of
items to be Run, which also causes the error. In this case I got a
very brief flash of the ARMini splash box before the error box covered
it. Only after I closed this did the apps that had been run before
Cache (including !Clock, !Messenger, !NetFetch) appear on the icon
bar. This suggests that these apps are multitasking while being
loaded.
Looking at the !Cache.!Boot file, the second line is
If "<Cache$Dir>" = "" Then Run <Obey$Dir>.!Run
I thought the norm was for a !Boot file to set up variables etc, but
not to run the application immediately. Could this be the source of
the problem?
Regards
Andrew
--
Andrew Pinder
on 14 Jun 2014 Steve Fryatt <lists@stevefryatt.org.uk> wrote:
> I don't run NetSurf during the boot sequence -- are all the people seeing
> issues doing that? What are people's Next slots configured to during the
> boot process?
On completion of booting, my Next slot is set to 640k. I don't know
how to tell if it's different during boot.
I've taken !NetSurf out of the boot sequence and that doesn't solve
the problem. I've moved !Cache from !Boot.Resources to
Utilities.Caution. Putting it at the end of the Look at list in Boot
causes the problem to occur. I then moved it to last in the list of
items to be Run, which also causes the error. In this case I got a
very brief flash of the ARMini splash box before the error box covered
it. Only after I closed this did the apps that had been run before
Cache (including !Clock, !Messenger, !NetFetch) appear on the icon
bar. This suggests that these apps are multitasking while being
loaded.
Looking at the !Cache.!Boot file, the second line is
If "<Cache$Dir>" = "" Then Run <Obey$Dir>.!Run
I thought the norm was for a !Boot file to set up variables etc, but
not to run the application immediately. Could this be the source of
the problem?
Regards
Andrew
--
Andrew Pinder
Re: Not enough application memory to start Basic
On 14 Jun 2014 Steve Fryatt <lists@stevefryatt.org.uk> wrote:
> On 14 Jun, Michael Drake wrote in message
> <539C509C.8090109@netsurf-browser.org>:
>>
>>
>> On 14/06/14 14:30, Andrew Pinder wrote:
>>
>>>> We recently decided to make use of "!Cache" as we assumed it would be
>>>> suitable and correct. (None of the core developers are actually using
>>>> RISC OS at the moment, so we hadn't checked it actually worked.)
>>
>>> If you give some clues as to how to test it, some of us may be able to
>>> give feedback :-)
>>
>> Thanks, but I think it's already been tested enough to show it doesn't
>> work, as it stands. You should be able to put it in !Boot without it
>> throwing up errors or having other side-effects.
>>
>> Our options are to get Cache from http://www.snowstone.org.uk/riscos/
>> fixed, and continue using it, or create our own simpler solution.
>>
>> Steve Fryatt: any thoughts on this?
> Well, I can't reproduce the problems that people are seeing. That's on
> RISC OS 5, with reasonably recent copies of !Boot, and !Cache placed in
> !Boot.Resources then left to be processed from there.
> I don't run NetSurf during the boot sequence -- are all the people seeing
> issues doing that? What are people's Next slots configured to during the
> boot process?
I don't see any problems either, FWIW. Don't run NetSurf at Boot, and
Next at Boot is set at 1024K. ARMini, RISC OS 5.19 at the moment,
with !Cache in Resources. No idea of any of this is useful info.
[snip]
Best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> On 14 Jun, Michael Drake wrote in message
> <539C509C.8090109@netsurf-browser.org>:
>>
>>
>> On 14/06/14 14:30, Andrew Pinder wrote:
>>
>>>> We recently decided to make use of "!Cache" as we assumed it would be
>>>> suitable and correct. (None of the core developers are actually using
>>>> RISC OS at the moment, so we hadn't checked it actually worked.)
>>
>>> If you give some clues as to how to test it, some of us may be able to
>>> give feedback :-)
>>
>> Thanks, but I think it's already been tested enough to show it doesn't
>> work, as it stands. You should be able to put it in !Boot without it
>> throwing up errors or having other side-effects.
>>
>> Our options are to get Cache from http://www.snowstone.org.uk/riscos/
>> fixed, and continue using it, or create our own simpler solution.
>>
>> Steve Fryatt: any thoughts on this?
> Well, I can't reproduce the problems that people are seeing. That's on
> RISC OS 5, with reasonably recent copies of !Boot, and !Cache placed in
> !Boot.Resources then left to be processed from there.
> I don't run NetSurf during the boot sequence -- are all the people seeing
> issues doing that? What are people's Next slots configured to during the
> boot process?
I don't see any problems either, FWIW. Don't run NetSurf at Boot, and
Next at Boot is set at 1024K. ARMini, RISC OS 5.19 at the moment,
with !Cache in Resources. No idea of any of this is useful info.
[snip]
Best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: Not enough application memory to start Basic
In article <mpro.n768be0c1izuo01q9.lists@stevefryatt.org.uk>,
Steve Fryatt <lists@stevefryatt.org.uk> wrote:
> I don't run NetSurf during the boot sequence
Neither do I.
--
Chris Johnson
Steve Fryatt <lists@stevefryatt.org.uk> wrote:
> I don't run NetSurf during the boot sequence
Neither do I.
--
Chris Johnson
Re: Not enough application memory to start Basic
On 14 Jun, Michael Drake wrote in message
<539C509C.8090109@netsurf-browser.org>:
>
>
> On 14/06/14 14:30, Andrew Pinder wrote:
>
> > > We recently decided to make use of "!Cache" as we assumed it would be
> > > suitable and correct. (None of the core developers are actually using
> > > RISC OS at the moment, so we hadn't checked it actually worked.)
>
> > If you give some clues as to how to test it, some of us may be able to
> > give feedback :-)
>
> Thanks, but I think it's already been tested enough to show it doesn't
> work, as it stands. You should be able to put it in !Boot without it
> throwing up errors or having other side-effects.
>
> Our options are to get Cache from http://www.snowstone.org.uk/riscos/
> fixed, and continue using it, or create our own simpler solution.
>
> Steve Fryatt: any thoughts on this?
Well, I can't reproduce the problems that people are seeing. That's on
RISC OS 5, with reasonably recent copies of !Boot, and !Cache placed in
!Boot.Resources then left to be processed from there.
I don't run NetSurf during the boot sequence -- are all the people seeing
issues doing that? What are people's Next slots configured to during the
boot process?
The contents of !Cache don't seem too unreasonable. The !RunImage is just
there to set some system variables in a sensible way and make double-clicks
on the application behave differently once it's been set up (to open the
cache folder). As Chris says, there's Select profile support, and it logs
its setup decisions to SysLog if that's available.
You could probably do the whole lot from within an obey file, but it would
get messy.
I'm not sure what the MimeMan cache stuff is, but wonder if that got left in
by accident. It looks to be cache data for MimeMan.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
<539C509C.8090109@netsurf-browser.org>:
>
>
> On 14/06/14 14:30, Andrew Pinder wrote:
>
> > > We recently decided to make use of "!Cache" as we assumed it would be
> > > suitable and correct. (None of the core developers are actually using
> > > RISC OS at the moment, so we hadn't checked it actually worked.)
>
> > If you give some clues as to how to test it, some of us may be able to
> > give feedback :-)
>
> Thanks, but I think it's already been tested enough to show it doesn't
> work, as it stands. You should be able to put it in !Boot without it
> throwing up errors or having other side-effects.
>
> Our options are to get Cache from http://www.snowstone.org.uk/riscos/
> fixed, and continue using it, or create our own simpler solution.
>
> Steve Fryatt: any thoughts on this?
Well, I can't reproduce the problems that people are seeing. That's on
RISC OS 5, with reasonably recent copies of !Boot, and !Cache placed in
!Boot.Resources then left to be processed from there.
I don't run NetSurf during the boot sequence -- are all the people seeing
issues doing that? What are people's Next slots configured to during the
boot process?
The contents of !Cache don't seem too unreasonable. The !RunImage is just
there to set some system variables in a sensible way and make double-clicks
on the application behave differently once it's been set up (to open the
cache folder). As Chris says, there's Select profile support, and it logs
its setup decisions to SysLog if that's available.
You could probably do the whole lot from within an obey file, but it would
get messy.
I'm not sure what the MimeMan cache stuff is, but wonder if that got left in
by accident. It looks to be cache data for MimeMan.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
Re: Not enough application memory to start Basic
In article <539C509C.8090109@netsurf-browser.org>,
Michael Drake <tlsa@netsurf-browser.org> wrote:
> Our options are to get Cache from
> http://www.snowstone.org.uk/riscos/
> fixed, and continue using it, or create our own simpler solution.
Having had a very *quick* look, it seems !Cache is implementing a
method of being compatible with Select, i.e. a multiuser system, and
keeps each users cache separate.
I should just say that I have the latest NetSurf, and !Cache,
installed on an Iyonix and a PandaBoard, both running a very recent
version of RISC OS 5.21 and it seems fine.
--
Chris Johnson
Michael Drake <tlsa@netsurf-browser.org> wrote:
> Our options are to get Cache from
> http://www.snowstone.org.uk/riscos/
> fixed, and continue using it, or create our own simpler solution.
Having had a very *quick* look, it seems !Cache is implementing a
method of being compatible with Select, i.e. a multiuser system, and
keeps each users cache separate.
I should just say that I have the latest NetSurf, and !Cache,
installed on an Iyonix and a PandaBoard, both running a very recent
version of RISC OS 5.21 and it seems fine.
--
Chris Johnson
Re: Not enough application memory to start Basic
On 14/06/14 14:30, Andrew Pinder wrote:
>> We recently decided to make use of "!Cache" as we assumed it would be
>> suitable and correct. (None of the core developers are actually using
>> RISC OS at the moment, so we hadn't checked it actually worked.)
> If you give some clues as to how to test it, some of us may be able to
> give feedback :-)
Thanks, but I think it's already been tested enough to show it doesn't
work, as it stands. You should be able to put it in !Boot without it
throwing up errors or having other side-effects.
Our options are to get Cache from http://www.snowstone.org.uk/riscos/
fixed, and continue using it, or create our own simpler solution.
Steve Fryatt: any thoughts on this?
Cheers,
--
Michael Drake http://www.netsurf-browser.org/
>> We recently decided to make use of "!Cache" as we assumed it would be
>> suitable and correct. (None of the core developers are actually using
>> RISC OS at the moment, so we hadn't checked it actually worked.)
> If you give some clues as to how to test it, some of us may be able to
> give feedback :-)
Thanks, but I think it's already been tested enough to show it doesn't
work, as it stands. You should be able to put it in !Boot without it
throwing up errors or having other side-effects.
Our options are to get Cache from http://www.snowstone.org.uk/riscos/
fixed, and continue using it, or create our own simpler solution.
Steve Fryatt: any thoughts on this?
Cheers,
--
Michael Drake http://www.netsurf-browser.org/
Re: Not enough application memory to start Basic
In message <539C4CFE.6020205@netsurf-browser.org>
on 14 Jun 2014 Michael Drake <tlsa@netsurf-browser.org> wrote:
> We recently decided to make use of "!Cache" as we assumed it would be
> suitable and correct. (None of the core developers are actually using
> RISC OS at the moment, so we hadn't checked it actually worked.)
If you give some clues as to how to test it, some of us may be able to
give feedback :-)
Regards
Andrew
--
Andrew Pinder
on 14 Jun 2014 Michael Drake <tlsa@netsurf-browser.org> wrote:
> We recently decided to make use of "!Cache" as we assumed it would be
> suitable and correct. (None of the core developers are actually using
> RISC OS at the moment, so we hadn't checked it actually worked.)
If you give some clues as to how to test it, some of us may be able to
give feedback :-)
Regards
Andrew
--
Andrew Pinder
Re: Not enough application memory to start Basic
On 14/06/14 13:48, David Pitt wrote:
> > All the NetSurf needs to run its cache is a value for Cache$Dir
> > pointing to the chosen location.
Indeed. The original proposal for Cache by Rob Kendrick[1] simply set
two variables in its !Run file. These were:
Caches$Write - Expands to where you should write new cache data
Caches$Path - Expands to where you should read cached data
We recently decided to make use of "!Cache" as we assumed it would be
suitable and correct. (None of the core developers are actually using
RISC OS at the moment, so we hadn't checked it actually worked.)
Looking at the content of the supplied "!Cache" it seems to contain a
lot of extra stuff and unexpected complexity.
As shipped, it currently looks like this:
!Cache/
!Cache/!Boot,feb
!Cache/!Help,feb
!Cache/!Run,feb
!Cache/!RunImage,ffb
!Cache/!Sprites22,ff9
!Cache/!Sprites,ff9
!Cache/Caches
!Cache/Caches/Blank
!Cache/Caches/Single
!Cache/Caches/Single/MimeMan
!Cache/Caches/Single/MimeMan/MimeBase,ffd
!Cache/Caches/Single/MimeMan/PluginMime,ffd
!Cache/Resources
!Cache/Resources/MultiError,ffb
!Cache/Resources/ResFind,ffb
!Cache/Resources/UK
!Cache/Resources/UK/Help
!Cache/Resources/UK/Messages
!Cache/Resources/UK/!Meta
!Cache/Resources/UK/Templates,fec
While we'd expect something like:
!Cache/
!Cache/!Boot,feb
!Cache/!Help,feb
!Cache/!Run,feb
!Cache/!Sprites,ff9
!Cache/!Sprites22,ff9
!Cache/Caches
We can either create our own "!Caches" that behaves as we expect, or we
can try to get the upstream "!Cache" fixed and continue to use that.
Although "!Cache" does seem over-complex; I'm not sure why it needs a
!RunImage, for example.
Also, whichever we choose, we should move the RUfl cache to the
persistent cache, rather than storing it in Scrap.
[1] See this thread:
http://vlists.pepperfish.net/pipermail/netsurf-users-netsurf-browser.org/2006-June/005356.html
--
Michael Drake http://www.netsurf-browser.org/
> > All the NetSurf needs to run its cache is a value for Cache$Dir
> > pointing to the chosen location.
Indeed. The original proposal for Cache by Rob Kendrick[1] simply set
two variables in its !Run file. These were:
Caches$Write - Expands to where you should write new cache data
Caches$Path - Expands to where you should read cached data
We recently decided to make use of "!Cache" as we assumed it would be
suitable and correct. (None of the core developers are actually using
RISC OS at the moment, so we hadn't checked it actually worked.)
Looking at the content of the supplied "!Cache" it seems to contain a
lot of extra stuff and unexpected complexity.
As shipped, it currently looks like this:
!Cache/
!Cache/!Boot,feb
!Cache/!Help,feb
!Cache/!Run,feb
!Cache/!RunImage,ffb
!Cache/!Sprites22,ff9
!Cache/!Sprites,ff9
!Cache/Caches
!Cache/Caches/Blank
!Cache/Caches/Single
!Cache/Caches/Single/MimeMan
!Cache/Caches/Single/MimeMan/MimeBase,ffd
!Cache/Caches/Single/MimeMan/PluginMime,ffd
!Cache/Resources
!Cache/Resources/MultiError,ffb
!Cache/Resources/ResFind,ffb
!Cache/Resources/UK
!Cache/Resources/UK/Help
!Cache/Resources/UK/Messages
!Cache/Resources/UK/!Meta
!Cache/Resources/UK/Templates,fec
While we'd expect something like:
!Cache/
!Cache/!Boot,feb
!Cache/!Help,feb
!Cache/!Run,feb
!Cache/!Sprites,ff9
!Cache/!Sprites22,ff9
!Cache/Caches
We can either create our own "!Caches" that behaves as we expect, or we
can try to get the upstream "!Cache" fixed and continue to use that.
Although "!Cache" does seem over-complex; I'm not sure why it needs a
!RunImage, for example.
Also, whichever we choose, we should move the RUfl cache to the
persistent cache, rather than storing it in Scrap.
[1] See this thread:
http://vlists.pepperfish.net/pipermail/netsurf-users-netsurf-browser.org/2006-June/005356.html
--
Michael Drake http://www.netsurf-browser.org/
Re: Not enough application memory to start Basic
David Pitt, on 14 Jun, wrote:
[snip - !Cache memory issues]
Have spent an entertaining morning with this the penny finally dropped.
All the NetSurf needs to run its cache is a value for Cache$Dir pointing to
the chosen location.
--
David Pitt
[snip - !Cache memory issues]
Have spent an entertaining morning with this the penny finally dropped.
All the NetSurf needs to run its cache is a value for Cache$Dir pointing to
the chosen location.
--
David Pitt
Re: Not enough application memory to start Basic
Andrew Pinder, on 14 Jun, wrote:
> In message <20140613221516.GC1754@platypus.pepperfish.net>
> on 13 Jun 2014 Rob Kendrick <rjek@netsurf-browser.org> wrote:
>
> > On Fri, Jun 13, 2014 at 09:42:54PM +0100, Andrew Pinder wrote:
> > > > Couple people try moving it elsewhere (ie, outside !Boot.Resources),
> > > > and configure !Boot to "look at" !Cache *BEFORE* it looks at or runs
> > > > !NetSurf, and see if this solves the problem?
> >>
> > > Well, that put it slightly *later* in the Boot sequence but still
> > > before looking at !NetSurf. Same error.
>
> > Thanks, that's a useful data point. We'll look more closely.
>
> I forgot to mention, I'm running 5.20 on an ARMini.
>
> I tried moving !Cache from Look at to Run, with no change. At that stage
> I also removed !NetSurf from the boot completely. Eventually removing
> !Cache completely from the boot sequence got rid of the error and brought
> back the ARMini splash banner, which I now realise is what had been
> missing.
!Cache does not error here when in !Boot.Resources, but it also cannot use
its SysLog calls as !SysLog is booted after !Cache.
If I try to use !Boot's 'Look at' the error here is "Not enough memory", and
the cache doesn't.
One work around is to comment out the SysLog run line in !Cache.!Run.
Another work around is to Filer_Run <SysLog$Dir>.!Run which had the
disadvantage the the SysLog module is not loaded in time for
!Cache.!RunImage to use it and is therefore somewhat useless.
A more useful evasion is to ensure the the SysLog module is loaded before
!Cache is booted.
That is what is happening here but so far I have not seen the "Not enough
application memory to start Basic" error.
Raspberry Pi, OS5.21 (03-Jun-14).
Hope this helps.
--
David Pitt
> In message <20140613221516.GC1754@platypus.pepperfish.net>
> on 13 Jun 2014 Rob Kendrick <rjek@netsurf-browser.org> wrote:
>
> > On Fri, Jun 13, 2014 at 09:42:54PM +0100, Andrew Pinder wrote:
> > > > Couple people try moving it elsewhere (ie, outside !Boot.Resources),
> > > > and configure !Boot to "look at" !Cache *BEFORE* it looks at or runs
> > > > !NetSurf, and see if this solves the problem?
> >>
> > > Well, that put it slightly *later* in the Boot sequence but still
> > > before looking at !NetSurf. Same error.
>
> > Thanks, that's a useful data point. We'll look more closely.
>
> I forgot to mention, I'm running 5.20 on an ARMini.
>
> I tried moving !Cache from Look at to Run, with no change. At that stage
> I also removed !NetSurf from the boot completely. Eventually removing
> !Cache completely from the boot sequence got rid of the error and brought
> back the ARMini splash banner, which I now realise is what had been
> missing.
!Cache does not error here when in !Boot.Resources, but it also cannot use
its SysLog calls as !SysLog is booted after !Cache.
If I try to use !Boot's 'Look at' the error here is "Not enough memory", and
the cache doesn't.
One work around is to comment out the SysLog run line in !Cache.!Run.
Another work around is to Filer_Run <SysLog$Dir>.!Run which had the
disadvantage the the SysLog module is not loaded in time for
!Cache.!RunImage to use it and is therefore somewhat useless.
A more useful evasion is to ensure the the SysLog module is loaded before
!Cache is booted.
That is what is happening here but so far I have not seen the "Not enough
application memory to start Basic" error.
Raspberry Pi, OS5.21 (03-Jun-14).
Hope this helps.
--
David Pitt
Friday, 13 June 2014
Re: Not enough application memory to start Basic
In message <20140613221516.GC1754@platypus.pepperfish.net>
on 13 Jun 2014 Rob Kendrick <rjek@netsurf-browser.org> wrote:
> On Fri, Jun 13, 2014 at 09:42:54PM +0100, Andrew Pinder wrote:
>>> Couple people try moving it elsewhere (ie, outside !Boot.Resources), and
>>> configure !Boot to "look at" !Cache *BEFORE* it looks at or runs
>>> !NetSurf, and see if this solves the problem?
>>
>> Well, that put it slightly *later* in the Boot sequence but still
>> before looking at !NetSurf. Same error.
> Thanks, that's a useful data point. We'll look more closely.
I forgot to mention, I'm running 5.20 on an ARMini.
I tried moving !Cache from Look at to Run, with no change. At that
stage I also removed !NetSurf from the boot completely. Eventually
removing !Cache completely from the boot sequence got rid of the error
and brought back the ARMini splash banner, which I now realise is what
had been missing.
Regards
Andrew
--
Andrew Pinder
on 13 Jun 2014 Rob Kendrick <rjek@netsurf-browser.org> wrote:
> On Fri, Jun 13, 2014 at 09:42:54PM +0100, Andrew Pinder wrote:
>>> Couple people try moving it elsewhere (ie, outside !Boot.Resources), and
>>> configure !Boot to "look at" !Cache *BEFORE* it looks at or runs
>>> !NetSurf, and see if this solves the problem?
>>
>> Well, that put it slightly *later* in the Boot sequence but still
>> before looking at !NetSurf. Same error.
> Thanks, that's a useful data point. We'll look more closely.
I forgot to mention, I'm running 5.20 on an ARMini.
I tried moving !Cache from Look at to Run, with no change. At that
stage I also removed !NetSurf from the boot completely. Eventually
removing !Cache completely from the boot sequence got rid of the error
and brought back the ARMini splash banner, which I now realise is what
had been missing.
Regards
Andrew
--
Andrew Pinder
Re: Not enough application memory to start Basic
On Fri, Jun 13, 2014 at 09:42:54PM +0100, Andrew Pinder wrote:
> > Couple people try moving it elsewhere (ie, outside !Boot.Resources), and
> > configure !Boot to "look at" !Cache *BEFORE* it looks at or runs
> > !NetSurf, and see if this solves the problem?
>
> Well, that put it slightly *later* in the Boot sequence but still
> before looking at !NetSurf. Same error.
Thanks, that's a useful data point. We'll look more closely.
B.
> > Couple people try moving it elsewhere (ie, outside !Boot.Resources), and
> > configure !Boot to "look at" !Cache *BEFORE* it looks at or runs
> > !NetSurf, and see if this solves the problem?
>
> Well, that put it slightly *later* in the Boot sequence but still
> before looking at !NetSurf. Same error.
Thanks, that's a useful data point. We'll look more closely.
B.
Re: Not enough application memory to start Basic
In message <20140613143931.GP3021@platypus.pepperfish.net>
on 13 Jun 2014 Rob Kendrick <rjek@netsurf-browser.org> wrote:
> On Fri, Jun 13, 2014 at 03:32:26PM +0100, Bob Latham wrote:
>> In article <bb69011754.Andrew-Pin@waitrose.com>,
>> Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
>>> I've been getting this error when the desktop starts since installing
>>> NetSurf CI #1959. Clicking on Cancel allow the Boot to complete. I
>>> mistakenly thought that installing CI #1965 had solved the problem.
>>
>>> Has anyone else had this problem?
>>> Is it associated with the installation of the !Cache resource, which
>>> wsa the main change in !Boot due to #1959?
>>
>> Yes I'm getting this too. I've actually killed the !cache application
>> because it kept causing this problem over an over again.
> Couple people try moving it elsewhere (ie, outside !Boot.Resources), and
> configure !Boot to "look at" !Cache *BEFORE* it looks at or runs
> !NetSurf, and see if this solves the problem?
Well, that put it slightly *later* in the Boot sequence but still
before looking at !NetSurf. Same error.
Regards
Andrew
--
Andrew Pinder
on 13 Jun 2014 Rob Kendrick <rjek@netsurf-browser.org> wrote:
> On Fri, Jun 13, 2014 at 03:32:26PM +0100, Bob Latham wrote:
>> In article <bb69011754.Andrew-Pin@waitrose.com>,
>> Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
>>> I've been getting this error when the desktop starts since installing
>>> NetSurf CI #1959. Clicking on Cancel allow the Boot to complete. I
>>> mistakenly thought that installing CI #1965 had solved the problem.
>>
>>> Has anyone else had this problem?
>>> Is it associated with the installation of the !Cache resource, which
>>> wsa the main change in !Boot due to #1959?
>>
>> Yes I'm getting this too. I've actually killed the !cache application
>> because it kept causing this problem over an over again.
> Couple people try moving it elsewhere (ie, outside !Boot.Resources), and
> configure !Boot to "look at" !Cache *BEFORE* it looks at or runs
> !NetSurf, and see if this solves the problem?
Well, that put it slightly *later* in the Boot sequence but still
before looking at !NetSurf. Same error.
Regards
Andrew
--
Andrew Pinder
Re: Facebook URLs
On 13 Jun 2014 Rob Kendrick wrote:
> On Fri, Jun 13, 2014 at 03:41:52PM +0000, Cristopher Dewhurst wrote:
>>
>> Is this a Netsurf peculiarity or a Facebook one? If the latter, is
>> there a workaround? You don't seem to be able to highlight and copy
>> just the URL without activating it.
> A Facebook one. They want to know who follows your link, so they proxy
> it.
Exactly. Google does the same. The workaround is to save the link as
text, extract the embedded URL and replace the escaped characters (%2F
= / and &3A = : in your example). Once you get to the unescaped
ampersand it and all the rest is Facebook garbage which you can
delete.
--
Richard Porter http://www.minijem.plus.com/
Skype: minijem2 mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
> On Fri, Jun 13, 2014 at 03:41:52PM +0000, Cristopher Dewhurst wrote:
>>
>> Is this a Netsurf peculiarity or a Facebook one? If the latter, is
>> there a workaround? You don't seem to be able to highlight and copy
>> just the URL without activating it.
> A Facebook one. They want to know who follows your link, so they proxy
> it.
Exactly. Google does the same. The workaround is to save the link as
text, extract the embedded URL and replace the escaped characters (%2F
= / and &3A = : in your example). Once you get to the unescaped
ampersand it and all the rest is Facebook garbage which you can
delete.
--
Richard Porter http://www.minijem.plus.com/
Skype: minijem2 mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Re: Facebook URLs
On 13 Jun 2014 as I do recall,
Cristopher Dewhurst wrote:
> Hi all, I use the mobile site (m.facebook.com) with Netsurf but I've
> never understood why links on posts such as:
>
> http://www.yorkpress.co.uk/news/11276158.Puppy_love_as_guide_dog_visit_stressed_out_university_students/
>
> turn into something horrendously long such as:
>
> http://lm.facebook.com/l.php?u=http%3A%2F%2Fwww.yorkpress.co.uk%2Fnews%2F11276158.Puppy_love_as_guide_dogs_visit_stressed_out_university_students%2F&h=nAQFw8k0a&enc=AZPXMdNOFY5jft7xFZWvoSPStvrU8djNkRBAwOKIq8doXAYlOtrL4URq2aezoNDxStaN79e3VneS85f4-L-6JTw51xN-2OHAu0rap3MdNZz-WZ3zgb6exV5wlYZX11ZMveZkJNiouE27lobN2iqq4ZGW&s=1
>
> and a subsequent blank page when you click on them in Netsurf. Above
> example is purely for illustration, not that I usually surf the
> internet for puppies or even the York press !
>
What really puzzles me is that *occasionally* the links work and take
you to the intended(?) 'redirecting' page and thence to their
destination. But I've never been able to establish what the triggering
factor is.
--
Harriet Bazley == Loyaulte me lie ==
Neuroses are red, Melancholia's blue.... I'm schizophrenic, What are you?
Cristopher Dewhurst wrote:
> Hi all, I use the mobile site (m.facebook.com) with Netsurf but I've
> never understood why links on posts such as:
>
> http://www.yorkpress.co.uk/news/11276158.Puppy_love_as_guide_dog_visit_stressed_out_university_students/
>
> turn into something horrendously long such as:
>
> http://lm.facebook.com/l.php?u=http%3A%2F%2Fwww.yorkpress.co.uk%2Fnews%2F11276158.Puppy_love_as_guide_dogs_visit_stressed_out_university_students%2F&h=nAQFw8k0a&enc=AZPXMdNOFY5jft7xFZWvoSPStvrU8djNkRBAwOKIq8doXAYlOtrL4URq2aezoNDxStaN79e3VneS85f4-L-6JTw51xN-2OHAu0rap3MdNZz-WZ3zgb6exV5wlYZX11ZMveZkJNiouE27lobN2iqq4ZGW&s=1
>
> and a subsequent blank page when you click on them in Netsurf. Above
> example is purely for illustration, not that I usually surf the
> internet for puppies or even the York press !
>
What really puzzles me is that *occasionally* the links work and take
you to the intended(?) 'redirecting' page and thence to their
destination. But I've never been able to establish what the triggering
factor is.
--
Harriet Bazley == Loyaulte me lie ==
Neuroses are red, Melancholia's blue.... I'm schizophrenic, What are you?
Re: Facebook URLs
On Fri, Jun 13, 2014 at 03:41:52PM +0000, Cristopher Dewhurst wrote:
>
> Is this a Netsurf peculiarity or a Facebook one? If the latter, is
> there a workaround? You don't seem to be able to highlight and copy
> just the URL without activating it.
A Facebook one. They want to know who follows your link, so they proxy
it.
B.
>
> Is this a Netsurf peculiarity or a Facebook one? If the latter, is
> there a workaround? You don't seem to be able to highlight and copy
> just the URL without activating it.
A Facebook one. They want to know who follows your link, so they proxy
it.
B.
Facebook URLs
Hi all, I use the mobile site (m.facebook.com) with Netsurf but I've
never understood why links on posts such as:
http://www.yorkpress.co.uk/news/11276158.Puppy_love_as_guide_dog_visit_stressed_out_university_students/
turn into something horrendously long such as:
http://lm.facebook.com/l.php?u=http%3A%2F%2Fwww.yorkpress.co.uk%2Fnews%2F11276158.Puppy_love_as_guide_dogs_visit_stressed_out_university_students%2F&h=nAQFw8k0a&enc=AZPXMdNOFY5jft7xFZWvoSPStvrU8djNkRBAwOKIq8doXAYlOtrL4URq2aezoNDxStaN79e3VneS85f4-L-6JTw51xN-2OHAu0rap3MdNZz-WZ3zgb6exV5wlYZX11ZMveZkJNiouE27lobN2iqq4ZGW&s=1
and a subsequent blank page when you click on them in Netsurf. Above
example is purely for illustration, not that I usually surf the
internet for puppies or even the York press !
Is this a Netsurf peculiarity or a Facebook one? If the latter, is
there a workaround? You don't seem to be able to highlight and copy
just the URL without activating it.
thanks
Chris.
--
never understood why links on posts such as:
http://www.yorkpress.co.uk/news/11276158.Puppy_love_as_guide_dog_visit_stressed_out_university_students/
turn into something horrendously long such as:
http://lm.facebook.com/l.php?u=http%3A%2F%2Fwww.yorkpress.co.uk%2Fnews%2F11276158.Puppy_love_as_guide_dogs_visit_stressed_out_university_students%2F&h=nAQFw8k0a&enc=AZPXMdNOFY5jft7xFZWvoSPStvrU8djNkRBAwOKIq8doXAYlOtrL4URq2aezoNDxStaN79e3VneS85f4-L-6JTw51xN-2OHAu0rap3MdNZz-WZ3zgb6exV5wlYZX11ZMveZkJNiouE27lobN2iqq4ZGW&s=1
and a subsequent blank page when you click on them in Netsurf. Above
example is purely for illustration, not that I usually surf the
internet for puppies or even the York press !
Is this a Netsurf peculiarity or a Facebook one? If the latter, is
there a workaround? You don't seem to be able to highlight and copy
just the URL without activating it.
thanks
Chris.
--
Re: Not enough application memory to start Basic
On Fri, Jun 13, 2014 at 03:32:26PM +0100, Bob Latham wrote:
> In article <bb69011754.Andrew-Pin@waitrose.com>,
> Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
> > I've been getting this error when the desktop starts since installing
> > NetSurf CI #1959. Clicking on Cancel allow the Boot to complete. I
> > mistakenly thought that installing CI #1965 had solved the problem.
>
> > Has anyone else had this problem?
> > Is it associated with the installation of the !Cache resource, which
> > wsa the main change in !Boot due to #1959?
>
> Yes I'm getting this too. I've actually killed the !cache application
> because it kept causing this problem over an over again.
Couple people try moving it elsewhere (ie, outside !Boot.Resources), and
configure !Boot to "look at" !Cache *BEFORE* it looks at or runs
!NetSurf, and see if this solves the problem?
I'm wondering if there's something odd about memory availabilty at
certain points at boot, or if the !Run/!Boot of !Cache needs tweaking.
B.
> In article <bb69011754.Andrew-Pin@waitrose.com>,
> Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
> > I've been getting this error when the desktop starts since installing
> > NetSurf CI #1959. Clicking on Cancel allow the Boot to complete. I
> > mistakenly thought that installing CI #1965 had solved the problem.
>
> > Has anyone else had this problem?
> > Is it associated with the installation of the !Cache resource, which
> > wsa the main change in !Boot due to #1959?
>
> Yes I'm getting this too. I've actually killed the !cache application
> because it kept causing this problem over an over again.
Couple people try moving it elsewhere (ie, outside !Boot.Resources), and
configure !Boot to "look at" !Cache *BEFORE* it looks at or runs
!NetSurf, and see if this solves the problem?
I'm wondering if there's something odd about memory availabilty at
certain points at boot, or if the !Run/!Boot of !Cache needs tweaking.
B.
Re: Not enough application memory to start Basic
In article <bb69011754.Andrew-Pin@waitrose.com>,
Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
> I've been getting this error when the desktop starts since installing
> NetSurf CI #1959. Clicking on Cancel allow the Boot to complete. I
> mistakenly thought that installing CI #1965 had solved the problem.
> Has anyone else had this problem?
> Is it associated with the installation of the !Cache resource, which
> wsa the main change in !Boot due to #1959?
Yes I'm getting this too. I've actually killed the !cache application
because it kept causing this problem over an over again.
Bob.
Andrew Pinder <Andrew.Pinder@tiscali.co.uk> wrote:
> I've been getting this error when the desktop starts since installing
> NetSurf CI #1959. Clicking on Cancel allow the Boot to complete. I
> mistakenly thought that installing CI #1965 had solved the problem.
> Has anyone else had this problem?
> Is it associated with the installation of the !Cache resource, which
> wsa the main change in !Boot due to #1959?
Yes I'm getting this too. I've actually killed the !cache application
because it kept causing this problem over an over again.
Bob.
Not enough application memory to start Basic
I've been getting this error when the desktop starts since installing
NetSurf CI #1959. Clicking on Cancel allow the Boot to complete. I
mistakenly thought that installing CI #1965 had solved the problem.
Has anyone else had this problem?
Is it associated with the installation of the !Cache resource, which
wsa the main change in !Boot due to #1959?
Regards
Andrew
--
Andrew Pinder
NetSurf CI #1959. Clicking on Cancel allow the Boot to complete. I
mistakenly thought that installing CI #1965 had solved the problem.
Has anyone else had this problem?
Is it associated with the installation of the !Cache resource, which
wsa the main change in !Boot due to #1959?
Regards
Andrew
--
Andrew Pinder
Thursday, 12 June 2014
Re: web page is blank with new vwersion on NeSurf
On 10 Jun 2014 as I do recall,
Vincent Sanders wrote:
> On Tue, Jun 10, 2014 at 11:27:46PM +0100, Harriet Bazley wrote:
[snip]
> > I wonder if this is the same as the behaviour I was seeing in bug
> > http://bugs.netsurf-browser.org/mantis/view.php?id=2143 ...
> > (had to revert to version 1932 due to the segfault part of the report!)
>
> As I already said, this is caused by the overflow css changes, needs a
> bug creating and tlsa to fix it.
>
I've created a new bug report, as my previous one was confusing two
separate issues.
--
Harriet Bazley == Loyaulte me lie ==
Do not underestimate the power of the Force.
Vincent Sanders wrote:
> On Tue, Jun 10, 2014 at 11:27:46PM +0100, Harriet Bazley wrote:
[snip]
> > I wonder if this is the same as the behaviour I was seeing in bug
> > http://bugs.netsurf-browser.org/mantis/view.php?id=2143 ...
> > (had to revert to version 1932 due to the segfault part of the report!)
>
> As I already said, this is caused by the overflow css changes, needs a
> bug creating and tlsa to fix it.
>
I've created a new bug report, as my previous one was confusing two
separate issues.
--
Harriet Bazley == Loyaulte me lie ==
Do not underestimate the power of the Force.
Wednesday, 11 June 2014
Re: BoxConvert?
On Wed, Jun 11, 2014 at 07:57:03AM +0100, Richard Torrens (lists) wrote:
> I can confirm that the latest build allows the page to display.
>
> What Netsurf should do with the line
> <a href="http://<!--#echo var="HTTP_HOST" --><!--#echo var="DOCUMENT_URI"
> -->">Top of page</a>
> I leave to others ... it's never going to do the right thing locally, so
> as long as it doesn't stop display I think it's unimportant what happens.
One wonders what's wrong with a #top anchor, anyway.
B.
> I can confirm that the latest build allows the page to display.
>
> What Netsurf should do with the line
> <a href="http://<!--#echo var="HTTP_HOST" --><!--#echo var="DOCUMENT_URI"
> -->">Top of page</a>
> I leave to others ... it's never going to do the right thing locally, so
> as long as it doesn't stop display I think it's unimportant what happens.
One wonders what's wrong with a #top anchor, anyway.
B.
Tuesday, 10 June 2014
BoxConvert?
I can confirm that the latest build allows the page to display.
What Netsurf should do with the line
<a href="http://<!--#echo var="HTTP_HOST" --><!--#echo var="DOCUMENT_URI"
-->">Top of page</a>
I leave to others ... it's never going to do the right thing locally, so
as long as it doesn't stop display I think it's unimportant what happens.
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
What Netsurf should do with the line
<a href="http://<!--#echo var="HTTP_HOST" --><!--#echo var="DOCUMENT_URI"
-->">Top of page</a>
I leave to others ... it's never going to do the right thing locally, so
as long as it doesn't stop display I think it's unimportant what happens.
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
Re: web page is blank with new vwersion on NeSurf
On Tue, Jun 10, 2014 at 11:27:46PM +0100, Harriet Bazley wrote:
> On 7 Jun 2014 as I do recall,
> John Rickman Iyonix wrote:
>
> > John Williams wrote
> >
> > > Fred Bambrough <netsurf@ypical-daemon.co.uk> wrote:
> > >> Ah, having seen what it's supposed to be on my Mac... yes, it's blank.
> >
> > > It broke between 1932 and 1935.
> >
> > Thanks to all who tested and confirmed the problem.
> > I will report it as a bug.
> >
> I wonder if this is the same as the behaviour I was seeing in bug
> http://bugs.netsurf-browser.org/mantis/view.php?id=2143 ...
> (had to revert to version 1932 due to the segfault part of the report!)
As I already said, this is caused by the overflow css changes, needs a
bug creating and tlsa to fix it.
>
> --
> Harriet Bazley == Loyaulte me lie ==
>
> I mean to live forever - or die trying!
>
>
--
Regards Vincent
http://www.kyllikki.org/
> On 7 Jun 2014 as I do recall,
> John Rickman Iyonix wrote:
>
> > John Williams wrote
> >
> > > Fred Bambrough <netsurf@ypical-daemon.co.uk> wrote:
> > >> Ah, having seen what it's supposed to be on my Mac... yes, it's blank.
> >
> > > It broke between 1932 and 1935.
> >
> > Thanks to all who tested and confirmed the problem.
> > I will report it as a bug.
> >
> I wonder if this is the same as the behaviour I was seeing in bug
> http://bugs.netsurf-browser.org/mantis/view.php?id=2143 ...
> (had to revert to version 1932 due to the segfault part of the report!)
As I already said, this is caused by the overflow css changes, needs a
bug creating and tlsa to fix it.
>
> --
> Harriet Bazley == Loyaulte me lie ==
>
> I mean to live forever - or die trying!
>
>
--
Regards Vincent
http://www.kyllikki.org/
Re: web page is blank with new vwersion on NeSurf
On 7 Jun 2014 as I do recall,
John Rickman Iyonix wrote:
> John Williams wrote
>
> > Fred Bambrough <netsurf@ypical-daemon.co.uk> wrote:
> >> Ah, having seen what it's supposed to be on my Mac... yes, it's blank.
>
> > It broke between 1932 and 1935.
>
> Thanks to all who tested and confirmed the problem.
> I will report it as a bug.
>
I wonder if this is the same as the behaviour I was seeing in bug
http://bugs.netsurf-browser.org/mantis/view.php?id=2143 ...
(had to revert to version 1932 due to the segfault part of the report!)
--
Harriet Bazley == Loyaulte me lie ==
I mean to live forever - or die trying!
John Rickman Iyonix wrote:
> John Williams wrote
>
> > Fred Bambrough <netsurf@ypical-daemon.co.uk> wrote:
> >> Ah, having seen what it's supposed to be on my Mac... yes, it's blank.
>
> > It broke between 1932 and 1935.
>
> Thanks to all who tested and confirmed the problem.
> I will report it as a bug.
>
I wonder if this is the same as the behaviour I was seeing in bug
http://bugs.netsurf-browser.org/mantis/view.php?id=2143 ...
(had to revert to version 1932 due to the segfault part of the report!)
--
Harriet Bazley == Loyaulte me lie ==
I mean to live forever - or die trying!
Re: Username and password problem
In message <5415a8f2f5bob@mightyoak.org.uk>
on 10 Jun 2014 Bob Latham <bob@mightyoak.org.uk> wrote:
> In article
> <OUT-5394E6BD.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
> Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
>> On Sun, 08 Jun 2014 19:27:15 +0100, Bob Latham wrote:
>>> Chris Young has asked for a copy of the log and I've sent it to him
>>> zipped.
>> It's the same cause as Richard's problem.
>> I'll see if I can find some time to look into it again, however it
>> would be very helpful if somebody could create a bug report for this,
>> as it makes it easier to manage and ensures it doesn't get forgotten.
> In article <20140609201043.GS27671@kyllikki.org>,
> Vincent Sanders <vince@netsurf-browser.org> wrote:
>> I have commited a possible fix which is available from the CI system
>> as build #1962 Hopefully this fix will fare better than Ranger 3 did
>> in 1962.
> I can confirm that I have installed version 1964 today and that it does
> fix my problem.
I've installed CI #1965 and it has fixed the BoxConvert problem I had
with an email attachment with 1959. It's also got rid of the "Not
enough application memory to start Basic" error that 1959 gave when
the desktop was starting.
> Well done and thanks to all of you.
Agreed
Andrew
--
Andrew Pinder
on 10 Jun 2014 Bob Latham <bob@mightyoak.org.uk> wrote:
> In article
> <OUT-5394E6BD.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
> Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
>> On Sun, 08 Jun 2014 19:27:15 +0100, Bob Latham wrote:
>>> Chris Young has asked for a copy of the log and I've sent it to him
>>> zipped.
>> It's the same cause as Richard's problem.
>> I'll see if I can find some time to look into it again, however it
>> would be very helpful if somebody could create a bug report for this,
>> as it makes it easier to manage and ensures it doesn't get forgotten.
> In article <20140609201043.GS27671@kyllikki.org>,
> Vincent Sanders <vince@netsurf-browser.org> wrote:
>> I have commited a possible fix which is available from the CI system
>> as build #1962 Hopefully this fix will fare better than Ranger 3 did
>> in 1962.
> I can confirm that I have installed version 1964 today and that it does
> fix my problem.
I've installed CI #1965 and it has fixed the BoxConvert problem I had
with an email attachment with 1959. It's also got rid of the "Not
enough application memory to start Basic" error that 1959 gave when
the desktop was starting.
> Well done and thanks to all of you.
Agreed
Andrew
--
Andrew Pinder
Re: Username and password problem
In article
<OUT-5394E6BD.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
> On Sun, 08 Jun 2014 19:27:15 +0100, Bob Latham wrote:
> > Chris Young has asked for a copy of the log and I've sent it to him
> > zipped.
> It's the same cause as Richard's problem.
> I'll see if I can find some time to look into it again, however it
> would be very helpful if somebody could create a bug report for this,
> as it makes it easier to manage and ensures it doesn't get forgotten.
In article <20140609201043.GS27671@kyllikki.org>,
Vincent Sanders <vince@netsurf-browser.org> wrote:
> I have commited a possible fix which is available from the CI system
> as build #1962 Hopefully this fix will fare better than Ranger 3 did
> in 1962.
I can confirm that I have installed version 1964 today and that it does
fix my problem.
Well done and thanks to all of you.
Cheers,
Bob.
<OUT-5394E6BD.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
> On Sun, 08 Jun 2014 19:27:15 +0100, Bob Latham wrote:
> > Chris Young has asked for a copy of the log and I've sent it to him
> > zipped.
> It's the same cause as Richard's problem.
> I'll see if I can find some time to look into it again, however it
> would be very helpful if somebody could create a bug report for this,
> as it makes it easier to manage and ensures it doesn't get forgotten.
In article <20140609201043.GS27671@kyllikki.org>,
Vincent Sanders <vince@netsurf-browser.org> wrote:
> I have commited a possible fix which is available from the CI system
> as build #1962 Hopefully this fix will fare better than Ranger 3 did
> in 1962.
I can confirm that I have installed version 1964 today and that it does
fix my problem.
Well done and thanks to all of you.
Cheers,
Bob.
Monday, 9 June 2014
Re: Persistant disc cache
On 9 Jun, Vincent Sanders wrote in message
<20140609195833.GR27671@kyllikki.org>:
> On Mon, Jun 09, 2014 at 06:32:47PM +0100, Steve Fryatt wrote:
>
> > It was more that it started creating negative sizes in the GUI.
> > Although on reflection that will need fixing in the GUI code, anyway.
>
> Ah, well I fixed it in the options code and amiga and gtk frontends,
> cannot do the same with RISC OS though.
It's sorted in RISC OS too, now.
> Are you wanting me to merge your branch as is then?
Yes, please!
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
<20140609195833.GR27671@kyllikki.org>:
> On Mon, Jun 09, 2014 at 06:32:47PM +0100, Steve Fryatt wrote:
>
> > It was more that it started creating negative sizes in the GUI.
> > Although on reflection that will need fixing in the GUI code, anyway.
>
> Ah, well I fixed it in the options code and amiga and gtk frontends,
> cannot do the same with RISC OS though.
It's sorted in RISC OS too, now.
> Are you wanting me to merge your branch as is then?
Yes, please!
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
Re: BoxConvert?
On Sat, Jun 07, 2014 at 04:50:01PM +0100, Richard Torrens (lists) wrote:
> What does the message BoxConvert mean? It's obscure to say the least!
It is, and it is a implementation detail from some code that requires
improvment in its error reporting. It efectively means "it went badly
wrong" and was caused as a side effect from ChrisY nice work
supporting IDNA hostname format.
Any URL where the hostname was invalid for the IDNA parser caused the
new code to report that error, unfortunately as I mentioned the higher
level code delt with this poorly.
I have commited a possible fix which is available from the CI system
as build #1962 Hopefully this fix will fare better than Ranger 3 did
in 1962.
>
> I now (3.2 (Dev CI #1959)) get it on every local www page I run. Which is
> a pain - as I cannot then check a www page before uploading.
>
> I suspect it may be because I use SSI on my www pages: they contain, for
> example
> <!--#include virtual="+NavTable.inc" -->
> and
> <h2>Page Information</h2>
> <BR>Document URL: <!--#echo var="SERVER_NAME" --><!--#echo
> var="DOCUMENT_URI" -->
> <BR>Page first published 30th July 2005
> <BR>Last modified: <!--#echo var="LAST_MODIFIED" -->
> <!--#config timefmt="%Y" -->
> <BR>© 2005-<!--#echo var="DATE_LOCAL" --> 4QD
>
> --
> Richard Torrens.
> http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
> and more!
>
>
--
Regards Vincent
http://www.kyllikki.org/
> What does the message BoxConvert mean? It's obscure to say the least!
It is, and it is a implementation detail from some code that requires
improvment in its error reporting. It efectively means "it went badly
wrong" and was caused as a side effect from ChrisY nice work
supporting IDNA hostname format.
Any URL where the hostname was invalid for the IDNA parser caused the
new code to report that error, unfortunately as I mentioned the higher
level code delt with this poorly.
I have commited a possible fix which is available from the CI system
as build #1962 Hopefully this fix will fare better than Ranger 3 did
in 1962.
>
> I now (3.2 (Dev CI #1959)) get it on every local www page I run. Which is
> a pain - as I cannot then check a www page before uploading.
>
> I suspect it may be because I use SSI on my www pages: they contain, for
> example
> <!--#include virtual="+NavTable.inc" -->
> and
> <h2>Page Information</h2>
> <BR>Document URL: <!--#echo var="SERVER_NAME" --><!--#echo
> var="DOCUMENT_URI" -->
> <BR>Page first published 30th July 2005
> <BR>Last modified: <!--#echo var="LAST_MODIFIED" -->
> <!--#config timefmt="%Y" -->
> <BR>© 2005-<!--#echo var="DATE_LOCAL" --> 4QD
>
> --
> Richard Torrens.
> http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
> and more!
>
>
--
Regards Vincent
http://www.kyllikki.org/
Re: Persistant disc cache
On Mon, Jun 09, 2014 at 06:32:47PM +0100, Steve Fryatt wrote:
> On 9 Jun, Vincent Sanders wrote in message
> <20140609122032.GP27671@kyllikki.org>:
>
> > On Sun, Jun 08, 2014 at 05:45:17PM +0100, Steve Fryatt wrote:
> >
> > Indeed, although disc_cache_age is not implemented right now, there is
> > provision within the new system to allow for it. It will mean objects that
> > have not been used older than this value will be discarded preventing the
> > disc cache from filling with old files no longer used. This is in addition
> > to them being discarded when the cache size limit is exceeded.
>
> Would I be best removing the option from the front-end for now?
Well I intend to get round to it sometime this week and I fixed it in
the gtk gui so if it is there it will be useful very soon.
>
> [snip]
>
> > > I don't know if this upsets the underlying cache, but I've limited the
> > > RISC OS GUI to 2047MB for now.
> >
> > Underlying cache does calculations in size_t (unsigned 32bit on RISC OS)
> > so should be fine.
>
> It was more that it started creating negative sizes in the GUI. Although on
> reflection that will need fixing in the GUI code, anyway.
>
Ah, well I fixed it in the options code and amiga and gtk frontends,
cannot do the same with RISC OS though.
Are you wanting me to merge your branch as is then?
--
Regards Vincent
http://www.kyllikki.org/
> On 9 Jun, Vincent Sanders wrote in message
> <20140609122032.GP27671@kyllikki.org>:
>
> > On Sun, Jun 08, 2014 at 05:45:17PM +0100, Steve Fryatt wrote:
> >
> > Indeed, although disc_cache_age is not implemented right now, there is
> > provision within the new system to allow for it. It will mean objects that
> > have not been used older than this value will be discarded preventing the
> > disc cache from filling with old files no longer used. This is in addition
> > to them being discarded when the cache size limit is exceeded.
>
> Would I be best removing the option from the front-end for now?
Well I intend to get round to it sometime this week and I fixed it in
the gtk gui so if it is there it will be useful very soon.
>
> [snip]
>
> > > I don't know if this upsets the underlying cache, but I've limited the
> > > RISC OS GUI to 2047MB for now.
> >
> > Underlying cache does calculations in size_t (unsigned 32bit on RISC OS)
> > so should be fine.
>
> It was more that it started creating negative sizes in the GUI. Although on
> reflection that will need fixing in the GUI code, anyway.
>
Ah, well I fixed it in the options code and amiga and gtk frontends,
cannot do the same with RISC OS though.
Are you wanting me to merge your branch as is then?
--
Regards Vincent
http://www.kyllikki.org/
Re: Persistant disc cache
On 9 Jun, Vincent Sanders wrote in message
<20140609122032.GP27671@kyllikki.org>:
> On Sun, Jun 08, 2014 at 05:45:17PM +0100, Steve Fryatt wrote:
>
> Indeed, although disc_cache_age is not implemented right now, there is
> provision within the new system to allow for it. It will mean objects that
> have not been used older than this value will be discarded preventing the
> disc cache from filling with old files no longer used. This is in addition
> to them being discarded when the cache size limit is exceeded.
Would I be best removing the option from the front-end for now?
[snip]
> > I don't know if this upsets the underlying cache, but I've limited the
> > RISC OS GUI to 2047MB for now.
>
> Underlying cache does calculations in size_t (unsigned 32bit on RISC OS)
> so should be fine.
It was more that it started creating negative sizes in the GUI. Although on
reflection that will need fixing in the GUI code, anyway.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
<20140609122032.GP27671@kyllikki.org>:
> On Sun, Jun 08, 2014 at 05:45:17PM +0100, Steve Fryatt wrote:
>
> Indeed, although disc_cache_age is not implemented right now, there is
> provision within the new system to allow for it. It will mean objects that
> have not been used older than this value will be discarded preventing the
> disc cache from filling with old files no longer used. This is in addition
> to them being discarded when the cache size limit is exceeded.
Would I be best removing the option from the front-end for now?
[snip]
> > I don't know if this upsets the underlying cache, but I've limited the
> > RISC OS GUI to 2047MB for now.
>
> Underlying cache does calculations in size_t (unsigned 32bit on RISC OS)
> so should be fine.
It was more that it started creating negative sizes in the GUI. Although on
reflection that will need fixing in the GUI code, anyway.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
Re: BoxConvert?
On 9 Jun, Bob Latham wrote in message
<541506117abob@mightyoak.org.uk>:
> In article <20140609101514.GE2612@somnambulist.local>,
> Daniel Silverstone <dsilvers@netsurf-browser.org> wrote:
> > On Sun, Jun 08, 2014 at 12:18:49 +0100, Bob Latham wrote:
> >
> > > At this point I walked away pretty wound up if I'm honest.
>
> This was my fight with the bug tracker system.
>
> > I can understand that. I am sorry that I'm part of what upset you but I
> > will again point out that we do this for our own delight and enjoyment
> > and sometimes real-life does intrude for us.
>
> Absolutely, I was only reporting the facts, not complaining except I did
> moan about the bug tracker.
>From a post on the dev list, there would seem to have been hardware issues
affecting the bug tracker over the weekend (which are now fixed). Maybe try
again?
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
<541506117abob@mightyoak.org.uk>:
> In article <20140609101514.GE2612@somnambulist.local>,
> Daniel Silverstone <dsilvers@netsurf-browser.org> wrote:
> > On Sun, Jun 08, 2014 at 12:18:49 +0100, Bob Latham wrote:
> >
> > > At this point I walked away pretty wound up if I'm honest.
>
> This was my fight with the bug tracker system.
>
> > I can understand that. I am sorry that I'm part of what upset you but I
> > will again point out that we do this for our own delight and enjoyment
> > and sometimes real-life does intrude for us.
>
> Absolutely, I was only reporting the facts, not complaining except I did
> moan about the bug tracker.
>From a post on the dev list, there would seem to have been hardware issues
affecting the bug tracker over the weekend (which are now fixed). Maybe try
again?
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
Recent issues with the CI system and bugtracker
Over the weekend 6th-9th June the bugtracker and CI system have been
intermitantly unavailable, returning 503 error messages and similar.
This was caused by a half broken network switch at our hosting
provider. As this hosting is provided to us without cost there is no
SLA.
However this morning the issue was fixed and everything should be back
to correct operation. Please let me know if this is not the case.
--
Regards Vincent
http://www.kyllikki.org/
intermitantly unavailable, returning 503 error messages and similar.
This was caused by a half broken network switch at our hosting
provider. As this hosting is provided to us without cost there is no
SLA.
However this morning the issue was fixed and everything should be back
to correct operation. Please let me know if this is not the case.
--
Regards Vincent
http://www.kyllikki.org/
Re: Persistant disc cache
On Sun, Jun 08, 2014 at 05:45:17PM +0100, Steve Fryatt wrote:
> On 5 Jun, Vincent Sanders wrote in message
> <20140605150105.GL27671@kyllikki.org>:
>
> > The amount of disc used for this cache is selected using the
> > disc_cache_size option in the choices file. The RISC OS frontend does not
> > currently have a user interface to set this value.
>
> It does now (or it will soon; I've just spotted disc_cache_age, which
> probably needs a field as well).
>
> :-)
Indeed, although disc_cache_age is not implemented right now, there is
provision within the new system to allow for it. It will mean objects
that have not been used older than this value will be discarded
preventing the disc cache from filling with old files no longer
used. This is in addition to them being discarded when the cache size
limit is exceeded.
>
> > The cache value is number of bytes to use on disc and a value of 0 will
> > disable the cache completely. The default value is set to a gigabyte.
>
> Apologies if I'm missing something, but does disc_cache_size really want to
> be a signed int? It goes negative before you get to a 2GB cache (on RISC OS,
> at least), which seems a little close to the 1GB default.
You were quite right, changed the option to an unsigned int so its now 4gigabytes
>
> I don't know if this upsets the underlying cache, but I've limited the
> RISC OS GUI to 2047MB for now.
Underlying cache does calculations in size_t (unsigned 32bit on RISC
OS) so should be fine.
>
> --
> Steve Fryatt - Leeds, England
>
> http://www.stevefryatt.org.uk/
>
>
--
Regards Vincent
http://www.kyllikki.org/
> On 5 Jun, Vincent Sanders wrote in message
> <20140605150105.GL27671@kyllikki.org>:
>
> > The amount of disc used for this cache is selected using the
> > disc_cache_size option in the choices file. The RISC OS frontend does not
> > currently have a user interface to set this value.
>
> It does now (or it will soon; I've just spotted disc_cache_age, which
> probably needs a field as well).
>
> :-)
Indeed, although disc_cache_age is not implemented right now, there is
provision within the new system to allow for it. It will mean objects
that have not been used older than this value will be discarded
preventing the disc cache from filling with old files no longer
used. This is in addition to them being discarded when the cache size
limit is exceeded.
>
> > The cache value is number of bytes to use on disc and a value of 0 will
> > disable the cache completely. The default value is set to a gigabyte.
>
> Apologies if I'm missing something, but does disc_cache_size really want to
> be a signed int? It goes negative before you get to a 2GB cache (on RISC OS,
> at least), which seems a little close to the 1GB default.
You were quite right, changed the option to an unsigned int so its now 4gigabytes
>
> I don't know if this upsets the underlying cache, but I've limited the
> RISC OS GUI to 2047MB for now.
Underlying cache does calculations in size_t (unsigned 32bit on RISC
OS) so should be fine.
>
> --
> Steve Fryatt - Leeds, England
>
> http://www.stevefryatt.org.uk/
>
>
--
Regards Vincent
http://www.kyllikki.org/
Subscribe to:
Posts (Atom)