In article <546ee1fc64dave@triffid.co.uk>,
Dave Symes <dave@triffid.co.uk> wrote:
> On my failing Real SARPC RO 6.20 I use the Nudge facility in the IClear
> module a lot. (Late Martyn Fox).
> However, having now moved my stuff to a RPCEmu install I find the the
> nudge is not working.
> Has anyone else found this to be the case, or is it just my system?
> I'm using the latest version of IClear (1.34)
> RPCEmu 0.8.12 and RO 6.20
> Thanks
> Dave
Okay dokay, I have discovered the problem...
On the Real SARPC 6.02 using the normal Left, Right, Up, Down arrow keys
actions the nudge move, however on RPCEmu (Win 7) with either RO 4.39 or
RO 6.20 only the Numeric keyboard will do the business.
Sorted.
Dave
FWIW. On VRPC_Adjust SA 6.20 (Win 7) it works as per usual, either Arrow
keys or the Numeric keyboard (Numlock off).
D.
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Sunday, 30 November 2014
Re: netsurf: branch master updated. release/3.2-500-gd08acbc
On Sun, 30 Nov 2014 19:52:03 +0000, John-Mark Bell wrote:
> > > That variance is insanely large. I presume I/O performance is consistent
> > > on Amiga OS?
> >
> > Nothing to do with I/O, that's not writing anything to disk - just
> > spawning a process and returning, so it's basically doing nothing.
>
> I must be missing something fundamental here, then. What is spawning a
> process?
The store operation I've set to offload to another process. For the
purposes of testing this that function should then return almost
immediately. I get the "too slow" error whether I do that or not.
> > > I don't think so, no. If the system scheduler is preventing tasks
> > > running for prolonged periods, then performance is going to suck,
> > > regardless. Thus, disabling the cache under these conditions isn't the
> > > world's worst idea.
> >
> > Yes, but the performance of the whole browser will suck so disabling
> > the cache is the wrong solution.
>
> Why? We care about throughput, which needs to be measured against some
> real clock; if we don't take scheduler context switches into account,
> then that will skew the results such that, as far as the bandwidth
> calculator is concerned, everything is fine, whereas in reality, it's
> not.
My point was that if this is affecting disk writing, it is also
affecting network access. If NetSurf for some reason is getting
randomly suspended during the caching code for an extended period, it
will also be getting randomly suspended during network access for an
extended period. Therefore the net gain for using the disk cache is
the same, even if it is sometimes taking a longer time than deemed
normal.
The disk cache throughput should be measured against network
throughput, not against some arbitrary ideal. I'd argue that it
shouldn't be disabling itself based on one bad result either, which is
what is happening here.
> > In this case the OS has seemingly decided that some other task is more
> > important whilst NetSurf is timing something critical, and
> > re-allocated the CPU for rather more milliseconds than the bandwidth
> > checker would like.
>
> We're talking about a difference of over 1000ms here, though. That
> doesn't sound like normal behaviour for any scheduling algorithm.
People do tell me Exec's task scheduler sucks, so it's not
inconceivable that it has handed the CPU to something (or many things)
more important for a second at the exact point we're trying to
measure. There are lots of processes that run at a higher priority
than NetSurf, although mostly they don't hog the CPU.
Chris
> > > That variance is insanely large. I presume I/O performance is consistent
> > > on Amiga OS?
> >
> > Nothing to do with I/O, that's not writing anything to disk - just
> > spawning a process and returning, so it's basically doing nothing.
>
> I must be missing something fundamental here, then. What is spawning a
> process?
The store operation I've set to offload to another process. For the
purposes of testing this that function should then return almost
immediately. I get the "too slow" error whether I do that or not.
> > > I don't think so, no. If the system scheduler is preventing tasks
> > > running for prolonged periods, then performance is going to suck,
> > > regardless. Thus, disabling the cache under these conditions isn't the
> > > world's worst idea.
> >
> > Yes, but the performance of the whole browser will suck so disabling
> > the cache is the wrong solution.
>
> Why? We care about throughput, which needs to be measured against some
> real clock; if we don't take scheduler context switches into account,
> then that will skew the results such that, as far as the bandwidth
> calculator is concerned, everything is fine, whereas in reality, it's
> not.
My point was that if this is affecting disk writing, it is also
affecting network access. If NetSurf for some reason is getting
randomly suspended during the caching code for an extended period, it
will also be getting randomly suspended during network access for an
extended period. Therefore the net gain for using the disk cache is
the same, even if it is sometimes taking a longer time than deemed
normal.
The disk cache throughput should be measured against network
throughput, not against some arbitrary ideal. I'd argue that it
shouldn't be disabling itself based on one bad result either, which is
what is happening here.
> > In this case the OS has seemingly decided that some other task is more
> > important whilst NetSurf is timing something critical, and
> > re-allocated the CPU for rather more milliseconds than the bandwidth
> > checker would like.
>
> We're talking about a difference of over 1000ms here, though. That
> doesn't sound like normal behaviour for any scheduling algorithm.
People do tell me Exec's task scheduler sucks, so it's not
inconceivable that it has handed the CPU to something (or many things)
more important for a second at the exact point we're trying to
measure. There are lots of processes that run at a higher priority
than NetSurf, although mostly they don't hog the CPU.
Chris
[Rpcemu] RPCEmu and IClear
On my failing Real SARPC RO 6.20 I use the Nudge facility in the IClear
module a lot. (Late Martyn Fox).
However, having now moved my stuff to a RPCEmu install I find the the
nudge is not working.
Has anyone else found this to be the case, or is it just my system?
I'm using the latest version of IClear (1.34)
RPCEmu 0.8.12 and RO 6.20
Thanks
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
module a lot. (Late Martyn Fox).
However, having now moved my stuff to a RPCEmu install I find the the
nudge is not working.
Has anyone else found this to be the case, or is it just my system?
I'm using the latest version of IClear (1.34)
RPCEmu 0.8.12 and RO 6.20
Thanks
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: netsurf: branch master updated. release/3.2-500-gd08acbc
On Sun, Nov 30, 2014 at 07:19:55PM +0000, Chris Young wrote:
> On Sun, 30 Nov 2014 18:18:31 +0000, John-Mark Bell wrote:
>
> > > I thought it might be wrong, so I rewrote it using a different timer.
> > > I get very similar results to before.
> >
> > You've verified that the timer returns sane answers, presumably? What
> > does this print out?:
>
> 1417374580.535953 : 1304710
> 1417374580.537786 : 1304712
> 1417374580.539558 : 1304714
> 1417374580.541320 : 1304716
> 1417374580.543073 : 1304717
>
> (after I changed the printf to %llu for now_mt)
OK, so modulo usleep(1000) sleeping for ~2ms, rather than 1, that looks
about right.
> > > When I return immediately, I'm still getting things like:
> > > Wrote 94314 bytes in 1305ms
> > > even though above it says:
> > > Wrote 91944 bytes in 1ms
> >
> > That variance is insanely large. I presume I/O performance is consistent
> > on Amiga OS?
>
> Nothing to do with I/O, that's not writing anything to disk - just
> spawning a process and returning, so it's basically doing nothing.
I must be missing something fundamental here, then. What is spawning a
process? (I'd also suggest that it's not doing nothing if, in some
circumstances, it's taking >1000 times longer to complete than in
others)
> > I don't think so, no. If the system scheduler is preventing tasks
> > running for prolonged periods, then performance is going to suck,
> > regardless. Thus, disabling the cache under these conditions isn't the
> > world's worst idea.
>
> Yes, but the performance of the whole browser will suck so disabling
> the cache is the wrong solution.
Why? We care about throughput, which needs to be measured against some
real clock; if we don't take scheduler context switches into account,
then that will skew the results such that, as far as the bandwidth
calculator is concerned, everything is fine, whereas in reality, it's
not.
> In this case the OS has seemingly decided that some other task is more
> important whilst NetSurf is timing something critical, and
> re-allocated the CPU for rather more milliseconds than the bandwidth
> checker would like.
We're talking about a difference of over 1000ms here, though. That
doesn't sound like normal behaviour for any scheduling algorithm.
> Using clock() seems to be a better solution and rather more portable.
That then means we're not measuring the right thing, though.
J.
> On Sun, 30 Nov 2014 18:18:31 +0000, John-Mark Bell wrote:
>
> > > I thought it might be wrong, so I rewrote it using a different timer.
> > > I get very similar results to before.
> >
> > You've verified that the timer returns sane answers, presumably? What
> > does this print out?:
>
> 1417374580.535953 : 1304710
> 1417374580.537786 : 1304712
> 1417374580.539558 : 1304714
> 1417374580.541320 : 1304716
> 1417374580.543073 : 1304717
>
> (after I changed the printf to %llu for now_mt)
OK, so modulo usleep(1000) sleeping for ~2ms, rather than 1, that looks
about right.
> > > When I return immediately, I'm still getting things like:
> > > Wrote 94314 bytes in 1305ms
> > > even though above it says:
> > > Wrote 91944 bytes in 1ms
> >
> > That variance is insanely large. I presume I/O performance is consistent
> > on Amiga OS?
>
> Nothing to do with I/O, that's not writing anything to disk - just
> spawning a process and returning, so it's basically doing nothing.
I must be missing something fundamental here, then. What is spawning a
process? (I'd also suggest that it's not doing nothing if, in some
circumstances, it's taking >1000 times longer to complete than in
others)
> > I don't think so, no. If the system scheduler is preventing tasks
> > running for prolonged periods, then performance is going to suck,
> > regardless. Thus, disabling the cache under these conditions isn't the
> > world's worst idea.
>
> Yes, but the performance of the whole browser will suck so disabling
> the cache is the wrong solution.
Why? We care about throughput, which needs to be measured against some
real clock; if we don't take scheduler context switches into account,
then that will skew the results such that, as far as the bandwidth
calculator is concerned, everything is fine, whereas in reality, it's
not.
> In this case the OS has seemingly decided that some other task is more
> important whilst NetSurf is timing something critical, and
> re-allocated the CPU for rather more milliseconds than the bandwidth
> checker would like.
We're talking about a difference of over 1000ms here, though. That
doesn't sound like normal behaviour for any scheduling algorithm.
> Using clock() seems to be a better solution and rather more portable.
That then means we're not measuring the right thing, though.
J.
Re: netsurf: branch master updated. release/3.2-500-gd08acbc
On Sun, 30 Nov 2014 18:18:31 +0000, John-Mark Bell wrote:
> > I thought it might be wrong, so I rewrote it using a different timer.
> > I get very similar results to before.
>
> You've verified that the timer returns sane answers, presumably? What
> does this print out?:
1417374580.535953 : 1304710
1417374580.537786 : 1304712
1417374580.539558 : 1304714
1417374580.541320 : 1304716
1417374580.543073 : 1304717
(after I changed the printf to %llu for now_mt)
> > When I return immediately, I'm still getting things like:
> > Wrote 94314 bytes in 1305ms
> > even though above it says:
> > Wrote 91944 bytes in 1ms
>
> That variance is insanely large. I presume I/O performance is consistent
> on Amiga OS?
Nothing to do with I/O, that's not writing anything to disk - just
spawning a process and returning, so it's basically doing nothing.
> > I've just had a thought that some other task might be nicking the CPU
> > whilst the timing is happening - We're measuring how long it takes,
> > not how much CPU time it takes. Perhaps the monotonic timer should be
> > measuring CPU time for the task it's running under?
>
> I don't think so, no. If the system scheduler is preventing tasks
> running for prolonged periods, then performance is going to suck,
> regardless. Thus, disabling the cache under these conditions isn't the
> world's worst idea.
Yes, but the performance of the whole browser will suck so disabling
the cache is the wrong solution.
In this case the OS has seemingly decided that some other task is more
important whilst NetSurf is timing something critical, and
re-allocated the CPU for rather more milliseconds than the bandwidth
checker would like.
Using clock() seems to be a better solution and rather more portable.
Chris
> > I thought it might be wrong, so I rewrote it using a different timer.
> > I get very similar results to before.
>
> You've verified that the timer returns sane answers, presumably? What
> does this print out?:
1417374580.535953 : 1304710
1417374580.537786 : 1304712
1417374580.539558 : 1304714
1417374580.541320 : 1304716
1417374580.543073 : 1304717
(after I changed the printf to %llu for now_mt)
> > When I return immediately, I'm still getting things like:
> > Wrote 94314 bytes in 1305ms
> > even though above it says:
> > Wrote 91944 bytes in 1ms
>
> That variance is insanely large. I presume I/O performance is consistent
> on Amiga OS?
Nothing to do with I/O, that's not writing anything to disk - just
spawning a process and returning, so it's basically doing nothing.
> > I've just had a thought that some other task might be nicking the CPU
> > whilst the timing is happening - We're measuring how long it takes,
> > not how much CPU time it takes. Perhaps the monotonic timer should be
> > measuring CPU time for the task it's running under?
>
> I don't think so, no. If the system scheduler is preventing tasks
> running for prolonged periods, then performance is going to suck,
> regardless. Thus, disabling the cache under these conditions isn't the
> world's worst idea.
Yes, but the performance of the whole browser will suck so disabling
the cache is the wrong solution.
In this case the OS has seemingly decided that some other task is more
important whilst NetSurf is timing something critical, and
re-allocated the CPU for rather more milliseconds than the bandwidth
checker would like.
Using clock() seems to be a better solution and rather more portable.
Chris
Re: netsurf: branch master updated. release/3.2-500-gd08acbc
On Sun, Nov 30, 2014 at 04:09:51PM +0000, Chris Young wrote:
> On Sun, 30 Nov 2014 15:01:54 +0000, Vincent Sanders wrote:
>
> > Is it possible that your implementation of a milisecond monotonic
> > counter in libnsutils is problematic? If it is returning microseconds
> > instead of miliseconds that would cause this erroneus behaviour.
>
> I thought it might be wrong, so I rewrote it using a different timer.
> I get very similar results to before.
You've verified that the timer returns sane answers, presumably? What
does this print out?:
#include <inttypes.h>
#include <stdio.h>
#include <time.h>
#include <unistd.h>
#include <nsutils/time.h>
int main(void)
{
int i;
uint64_t now_mt;
struct timeval tv;
for (i = 5; i > 0; --i) {
nsu_getmonotonic_ms(&now_mt);
gettimeofday(&tv, NULL);
printf("%ld.%ld : %lu\n", tv.tv_sec, tv.tv_usec, now_mt);
usleep(1000);
}
return 0;
}
> When I return immediately, I'm still getting things like:
> Wrote 94314 bytes in 1305ms
> even though above it says:
> Wrote 91944 bytes in 1ms
That variance is insanely large. I presume I/O performance is consistent
on Amiga OS?
> I've just had a thought that some other task might be nicking the CPU
> whilst the timing is happening - We're measuring how long it takes,
> not how much CPU time it takes. Perhaps the monotonic timer should be
> measuring CPU time for the task it's running under?
I don't think so, no. If the system scheduler is preventing tasks
running for prolonged periods, then performance is going to suck,
regardless. Thus, disabling the cache under these conditions isn't the
world's worst idea.
J.
> On Sun, 30 Nov 2014 15:01:54 +0000, Vincent Sanders wrote:
>
> > Is it possible that your implementation of a milisecond monotonic
> > counter in libnsutils is problematic? If it is returning microseconds
> > instead of miliseconds that would cause this erroneus behaviour.
>
> I thought it might be wrong, so I rewrote it using a different timer.
> I get very similar results to before.
You've verified that the timer returns sane answers, presumably? What
does this print out?:
#include <inttypes.h>
#include <stdio.h>
#include <time.h>
#include <unistd.h>
#include <nsutils/time.h>
int main(void)
{
int i;
uint64_t now_mt;
struct timeval tv;
for (i = 5; i > 0; --i) {
nsu_getmonotonic_ms(&now_mt);
gettimeofday(&tv, NULL);
printf("%ld.%ld : %lu\n", tv.tv_sec, tv.tv_usec, now_mt);
usleep(1000);
}
return 0;
}
> When I return immediately, I'm still getting things like:
> Wrote 94314 bytes in 1305ms
> even though above it says:
> Wrote 91944 bytes in 1ms
That variance is insanely large. I presume I/O performance is consistent
on Amiga OS?
> I've just had a thought that some other task might be nicking the CPU
> whilst the timing is happening - We're measuring how long it takes,
> not how much CPU time it takes. Perhaps the monotonic timer should be
> measuring CPU time for the task it's running under?
I don't think so, no. If the system scheduler is preventing tasks
running for prolonged periods, then performance is going to suck,
regardless. Thus, disabling the cache under these conditions isn't the
world's worst idea.
J.
Re: netsurf: branch master updated. release/3.2-500-gd08acbc
On Sun, 30 Nov 2014 15:01:54 +0000, Vincent Sanders wrote:
> > (22.696681) content/llcache.c llcache_persist 2414: Wrote 884 bytes in 225ms bw:3928 http://aminet.net/pics/at.gif
> > (22.696759) content/llcache.c llcache_persist 2420: Overran timeslot
> > (22.696828) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth
> > (22.697699) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache
>
> well under 4000 bytes a second is so slow that it is not useful.
Agreed...
> The
> disc caching really needs to be several multiples of the network
> conenction speed to be useful. Although the minimum bandwidth setting
> is a passe din parameter and you can chnage the default value in
> desktop/netsurf.c to experiment.
I'll have a look at that.
> Is it possible that your implementation of a milisecond monotonic
> counter in libnsutils is problematic? If it is returning microseconds
> instead of miliseconds that would cause this erroneus behaviour.
I thought it might be wrong, so I rewrote it using a different timer.
I get very similar results to before.
When I return immediately, I'm still getting things like:
Wrote 94314 bytes in 1305ms
even though above it says:
Wrote 91944 bytes in 1ms
So there's something weird with the timer, or something slow is
happening between the timing interval.
I've just had a thought that some other task might be nicking the CPU
whilst the timing is happening - We're measuring how long it takes,
not how much CPU time it takes. Perhaps the monotonic timer should be
measuring CPU time for the task it's running under?
Chris
> > (22.696681) content/llcache.c llcache_persist 2414: Wrote 884 bytes in 225ms bw:3928 http://aminet.net/pics/at.gif
> > (22.696759) content/llcache.c llcache_persist 2420: Overran timeslot
> > (22.696828) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth
> > (22.697699) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache
>
> well under 4000 bytes a second is so slow that it is not useful.
Agreed...
> The
> disc caching really needs to be several multiples of the network
> conenction speed to be useful. Although the minimum bandwidth setting
> is a passe din parameter and you can chnage the default value in
> desktop/netsurf.c to experiment.
I'll have a look at that.
> Is it possible that your implementation of a milisecond monotonic
> counter in libnsutils is problematic? If it is returning microseconds
> instead of miliseconds that would cause this erroneus behaviour.
I thought it might be wrong, so I rewrote it using a different timer.
I get very similar results to before.
When I return immediately, I'm still getting things like:
Wrote 94314 bytes in 1305ms
even though above it says:
Wrote 91944 bytes in 1ms
So there's something weird with the timer, or something slow is
happening between the timing interval.
I've just had a thought that some other task might be nicking the CPU
whilst the timing is happening - We're measuring how long it takes,
not how much CPU time it takes. Perhaps the monotonic timer should be
measuring CPU time for the task it's running under?
Chris
Re: netsurf: branch master updated. release/3.2-500-gd08acbc
On Sun, Nov 30, 2014 at 01:40:47PM +0000, Chris Young wrote:
> On Sat, 29 Nov 2014 23:57:22 +0000, Commit Mailer wibbled on for an age:
>
> > correctly calculate writeout bandwidth and properly impose limits
>
> Is this really right?
>
> (22.696681) content/llcache.c llcache_persist 2414: Wrote 884 bytes in 225ms bw:3928 http://aminet.net/pics/at.gif
> (22.696759) content/llcache.c llcache_persist 2420: Overran timeslot
> (22.696828) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth
> (22.697699) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache
well under 4000 bytes a second is so slow that it is not useful. The
disc caching really needs to be several multiples of the network
conenction speed to be useful. Although the minimum bandwidth setting
is a passe din parameter and you can chnage the default value in
desktop/netsurf.c to experiment.
>
> (22.497406) content/llcache.c llcache_persist 2414: Wrote 1480 bytes in 114ms bw:12982 http://news.bbcimg.co.uk/view/1_4_38/cream/hi/news/img/services.gif
> (22.497485) content/llcache.c llcache_persist 2420: Overran timeslot
> (22.497549) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth
> (22.497751) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache
>
> (16.366240) content/llcache.c llcache_persist 2414: Wrote 3931 bytes in 263ms bw:14946 http://i2.cdnds.net/13/47/hearst.png
> (16.366319) content/llcache.c llcache_persist 2420: Overran timeslot
> (16.366384) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth
> (16.366585) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache
>
> Even if I spawn it off to another process (so store returns
> immediately) I still get the not enough bandwidth message.
Is it possible that your implementation of a milisecond monotonic
counter in libnsutils is problematic? If it is returning microseconds
instead of miliseconds that would cause this erroneus behaviour.
>
> Chris
>
>
--
Regards Vincent
http://www.kyllikki.org/
> On Sat, 29 Nov 2014 23:57:22 +0000, Commit Mailer wibbled on for an age:
>
> > correctly calculate writeout bandwidth and properly impose limits
>
> Is this really right?
>
> (22.696681) content/llcache.c llcache_persist 2414: Wrote 884 bytes in 225ms bw:3928 http://aminet.net/pics/at.gif
> (22.696759) content/llcache.c llcache_persist 2420: Overran timeslot
> (22.696828) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth
> (22.697699) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache
well under 4000 bytes a second is so slow that it is not useful. The
disc caching really needs to be several multiples of the network
conenction speed to be useful. Although the minimum bandwidth setting
is a passe din parameter and you can chnage the default value in
desktop/netsurf.c to experiment.
>
> (22.497406) content/llcache.c llcache_persist 2414: Wrote 1480 bytes in 114ms bw:12982 http://news.bbcimg.co.uk/view/1_4_38/cream/hi/news/img/services.gif
> (22.497485) content/llcache.c llcache_persist 2420: Overran timeslot
> (22.497549) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth
> (22.497751) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache
>
> (16.366240) content/llcache.c llcache_persist 2414: Wrote 3931 bytes in 263ms bw:14946 http://i2.cdnds.net/13/47/hearst.png
> (16.366319) content/llcache.c llcache_persist 2420: Overran timeslot
> (16.366384) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth
> (16.366585) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache
>
> Even if I spawn it off to another process (so store returns
> immediately) I still get the not enough bandwidth message.
Is it possible that your implementation of a milisecond monotonic
counter in libnsutils is problematic? If it is returning microseconds
instead of miliseconds that would cause this erroneus behaviour.
>
> Chris
>
>
--
Regards Vincent
http://www.kyllikki.org/
Re: netsurf: branch master updated. release/3.2-500-gd08acbc
On Sat, 29 Nov 2014 23:57:22 +0000, Commit Mailer wibbled on for an age:
> correctly calculate writeout bandwidth and properly impose limits
Is this really right?
(22.696681) content/llcache.c llcache_persist 2414: Wrote 884 bytes in 225ms bw:3928 http://aminet.net/pics/at.gif
(22.696759) content/llcache.c llcache_persist 2420: Overran timeslot
(22.696828) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth
(22.697699) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache
(22.497406) content/llcache.c llcache_persist 2414: Wrote 1480 bytes in 114ms bw:12982 http://news.bbcimg.co.uk/view/1_4_38/cream/hi/news/img/services.gif
(22.497485) content/llcache.c llcache_persist 2420: Overran timeslot
(22.497549) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth
(22.497751) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache
(16.366240) content/llcache.c llcache_persist 2414: Wrote 3931 bytes in 263ms bw:14946 http://i2.cdnds.net/13/47/hearst.png
(16.366319) content/llcache.c llcache_persist 2420: Overran timeslot
(16.366384) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth
(16.366585) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache
Even if I spawn it off to another process (so store returns
immediately) I still get the not enough bandwidth message.
Chris
> correctly calculate writeout bandwidth and properly impose limits
Is this really right?
(22.696681) content/llcache.c llcache_persist 2414: Wrote 884 bytes in 225ms bw:3928 http://aminet.net/pics/at.gif
(22.696759) content/llcache.c llcache_persist 2420: Overran timeslot
(22.696828) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth
(22.697699) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache
(22.497406) content/llcache.c llcache_persist 2414: Wrote 1480 bytes in 114ms bw:12982 http://news.bbcimg.co.uk/view/1_4_38/cream/hi/news/img/services.gif
(22.497485) content/llcache.c llcache_persist 2420: Overran timeslot
(22.497549) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth
(22.497751) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache
(16.366240) content/llcache.c llcache_persist 2414: Wrote 3931 bytes in 263ms bw:14946 http://i2.cdnds.net/13/47/hearst.png
(16.366319) content/llcache.c llcache_persist 2420: Overran timeslot
(16.366384) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth
(16.366585) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache
Even if I spawn it off to another process (so store returns
immediately) I still get the not enough bandwidth message.
Chris
Tuesday, 25 November 2014
Re: netsurf: branch master updated. release/3.2-493-g81417ae
On Tue, Nov 25, 2014 at 11:14:28PM +0000, NetSurf Browser Project wrote:
>
> - Log -----------------------------------------------------------------
> commitdiff http://git.netsurf-browser.org/netsurf.git/commit/?id=81417ae4a5a58ef75ac4113ea2b2d8c72474ea97
> commit 81417ae4a5a58ef75ac4113ea2b2d8c72474ea97
> Author: Vincent Sanders <vince@kyllikki.org>
> Commit: Vincent Sanders <vince@kyllikki.org>
>
> caclulate the total amount of time spent writing an object out
[...]
> +write_backing_store(struct llcache_object *object, size_t *written_out, unsigned long *elapsed)
[...]
> + gettimeofday(&start_tv, NULL);
[...]
> + gettimeofday(&end_tv, NULL);
> +
> + timersub(&end_tv, &start_tv, &elapsed_tv);
> +
> object->store_state = LLCACHE_STATE_DISC;
>
> *written_out = object->source_len + metadatasize;
>
> + *elapsed = (elapsed_tv.tv_sec * 1000) + (elapsed_tv.tv_usec / 1000);
> +
This doesn't cope with time going backwards during the write out
operation (as gettimeofday is affected by NTP, amongst other things).
The upshot will be that the computed elapsed time comes out as a large
unsigned value (time_t is signed on most systems), and thus we'll decide
that write bandwidth is non-existent.
Ideally, we'd have a way to read the value of the monotonic timer on the
system. That's platform-specific, however, so a fairly invasive change.
Is there a better way of dealing with this?
J.
>
> - Log -----------------------------------------------------------------
> commitdiff http://git.netsurf-browser.org/netsurf.git/commit/?id=81417ae4a5a58ef75ac4113ea2b2d8c72474ea97
> commit 81417ae4a5a58ef75ac4113ea2b2d8c72474ea97
> Author: Vincent Sanders <vince@kyllikki.org>
> Commit: Vincent Sanders <vince@kyllikki.org>
>
> caclulate the total amount of time spent writing an object out
[...]
> +write_backing_store(struct llcache_object *object, size_t *written_out, unsigned long *elapsed)
[...]
> + gettimeofday(&start_tv, NULL);
[...]
> + gettimeofday(&end_tv, NULL);
> +
> + timersub(&end_tv, &start_tv, &elapsed_tv);
> +
> object->store_state = LLCACHE_STATE_DISC;
>
> *written_out = object->source_len + metadatasize;
>
> + *elapsed = (elapsed_tv.tv_sec * 1000) + (elapsed_tv.tv_usec / 1000);
> +
This doesn't cope with time going backwards during the write out
operation (as gettimeofday is affected by NTP, amongst other things).
The upshot will be that the computed elapsed time comes out as a large
unsigned value (time_t is signed on most systems), and thus we'll decide
that write bandwidth is non-existent.
Ideally, we'd have a way to read the value of the monotonic timer on the
system. That's platform-specific, however, so a fairly invasive change.
Is there a better way of dealing with this?
J.
Re: [gccsdk] Trunk binutils configuration options
On 21/11/14 19:08, John-Mark Bell wrote:
> All,
>
> Last weekend we played around with using GCC 4.7.4 to cross compile
> NetSurf (we're still using 4.1.2r2 for CI builds). Mostly this worked
> fine without much additional effort (full details in the most recent
> four commits on [1]).
>
> One oddity I'd like some input on, however, is the changeset at [2].
> Specifically, without this change (which enables binutils plugins),
> we cannot use the toolchain to compile OpenSSL (it runs into
> difficulty when linking the OpenSSL command line tools).
>
> I'd like to know if this change is safe
Looking at the binutils source, it seems to be the usual plugin type
code using dlopen, dlsym, etc in libdl, so I don't see this causing
any problems.
> and also whether it's actually something that should be the default
> in GCCSDK itself?
Looks like --enable-plugins now defaults to on in mainline binutils:
<https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=log;h=b879806f2fdd2eca7092d7b854d6cbbbbbd0493b>
We might need some tweaks to the native binutils so that it gets the
plugin location right, but the linker already depends on libdl, so
enabling plugin support shouldn't be a problem.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> All,
>
> Last weekend we played around with using GCC 4.7.4 to cross compile
> NetSurf (we're still using 4.1.2r2 for CI builds). Mostly this worked
> fine without much additional effort (full details in the most recent
> four commits on [1]).
>
> One oddity I'd like some input on, however, is the changeset at [2].
> Specifically, without this change (which enables binutils plugins),
> we cannot use the toolchain to compile OpenSSL (it runs into
> difficulty when linking the OpenSSL command line tools).
>
> I'd like to know if this change is safe
Looking at the binutils source, it seems to be the usual plugin type
code using dlopen, dlsym, etc in libdl, so I don't see this causing
any problems.
> and also whether it's actually something that should be the default
> in GCCSDK itself?
Looks like --enable-plugins now defaults to on in mainline binutils:
<https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=log;h=b879806f2fdd2eca7092d7b854d6cbbbbbd0493b>
We might need some tweaks to the native binutils so that it gets the
plugin location right, but the linker already depends on libdl, so
enabling plugin support shouldn't be a problem.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Monday, 24 November 2014
Re: !Cache management
In article <18f1976b54.jim@abbeypress.net>,
Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> cj wrote on 16 Nov:
> > Is anyone else finding that the new Cache feature does not seem to
> > expire its content?
> Well, that was a revelation. Did a count on
> !Boot.resources.!cache.caches.default.netsurf and find 222 megabytes
> of stuff. Earliest date seems to be Sept 06.
I wondered about this having read your post. I don't have !Cache and its
sub-directories but I do have
!Boot.Resources.!Scrap.ScrapDirs.IDdisabled.WWW.NetSurf.Cache. In there I
found I had 45 megabytes of said stuff - earliest from 2006, latest from
May this year.
> Ah, Netsurf choices--cache. Disc cache size is set at 1024M (which
> I presume is meant as a max),
In my case it's set at 2MB but there's no option to set the expiry. I'm
using NS 3.1, 25 April 2014.
I see that NS 3.2 is available on the website and the changelog mentions
support for disc caching. I'll give it a go but wonder what the disk cache
setting was doing in NS 3.1 if it was just storing stuff without deleting
it and why the last cached item was in May this year!
Alan
[Snip]
--
Alan Calder, Milton Keynes, UK.
Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> cj wrote on 16 Nov:
> > Is anyone else finding that the new Cache feature does not seem to
> > expire its content?
> Well, that was a revelation. Did a count on
> !Boot.resources.!cache.caches.default.netsurf and find 222 megabytes
> of stuff. Earliest date seems to be Sept 06.
I wondered about this having read your post. I don't have !Cache and its
sub-directories but I do have
!Boot.Resources.!Scrap.ScrapDirs.IDdisabled.WWW.NetSurf.Cache. In there I
found I had 45 megabytes of said stuff - earliest from 2006, latest from
May this year.
> Ah, Netsurf choices--cache. Disc cache size is set at 1024M (which
> I presume is meant as a max),
In my case it's set at 2MB but there's no option to set the expiry. I'm
using NS 3.1, 25 April 2014.
I see that NS 3.2 is available on the website and the changelog mentions
support for disc caching. I'll give it a go but wonder what the disk cache
setting was doing in NS 3.1 if it was just storing stuff without deleting
it and why the last cached item was in May this year!
Alan
[Snip]
--
Alan Calder, Milton Keynes, UK.
[gccsdk] [Bug 254] C++11 threads do not work and cause a crash
http://www.riscos.info/bugzilla3/show_bug.cgi?id=254
Lee <leenoar@sky.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |leenoar@sky.com
Resolution| |FIXED
--- Comment #1 from Lee <leenoar@sky.com> 2014-11-24 10:11:37 PST ---
For some reason the static linker doesn't pull in the required pthread
functions
which are declared weak by the libstdc++ build system. Fortunately, the
build system allows the weakrefs to be disabled. As we know that pthreads are
always available in Unixlib, this is not a problem. However, weakrefs are still
required for SCL as that has no pthread support.
Fixed with r6748 and r6749.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Lee <leenoar@sky.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |leenoar@sky.com
Resolution| |FIXED
--- Comment #1 from Lee <leenoar@sky.com> 2014-11-24 10:11:37 PST ---
For some reason the static linker doesn't pull in the required pthread
functions
which are declared weak by the libstdc++ build system. Fortunately, the
build system allows the weakrefs to be disabled. As we know that pthreads are
always available in Unixlib, this is not a problem. However, weakrefs are still
required for SCL as that has no pthread support.
Fixed with r6748 and r6749.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: !Cache management
In article <18f1976b54.jim@abbeypress.net>,
Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> The runfile of my active copy in Boot Resources (which presumably
> came with a recent-ish version of Netsurf inside its usual
> boot-update file) is dated 2014-09-16, but !Sidediff shows it is
> identical to the 2007 runfile.
This is a fact of life with several apps/systems that do auto updates
each day and rebuild the download files, whatever, in that datestamps
of files are updated whether they have changed or not.
The ROOL hard drive image is a particular case, where it is
impossible to check what, if anything has changed.
--
Chris Johnson
Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> The runfile of my active copy in Boot Resources (which presumably
> came with a recent-ish version of Netsurf inside its usual
> boot-update file) is dated 2014-09-16, but !Sidediff shows it is
> identical to the 2007 runfile.
This is a fact of life with several apps/systems that do auto updates
each day and rebuild the download files, whatever, in that datestamps
of files are updated whether they have changed or not.
The ROOL hard drive image is a particular case, where it is
impossible to check what, if anything has changed.
--
Chris Johnson
Re: !Cache management
On Mon, Nov 24, 2014 at 01:15:26PM +0000, Jim Nagel wrote:
> A typical item within this folder is filetyped as text but contains
> gobbledygook.
"Text" is the default file type for files created using UnixLib. Given
these files are not meant to be consumed by humans, I don't see a
problem there.
(The actual gobbledydook is the cached data and headers.)
> What is supposed to control expiry? Can't find anything about expiry
> within the !Cache application itself.
!Cache is not NetSurf-specific. The control settings are in each
application that uses it.
> Ah, Netsurf choices--cache. Disc cache size is set at 1024M (which
> I presume is meant as a max), and expiry at 28 days. Those figures
> seem to be defaults, because I have never altered them.
>
> Don't recall any discussion or explanation when Netsurf adopted !Cache
> -- when was that? Maybe it happened while I was away and I missed it.
It happened when Vince implemented disc caching :) This was some time
ago, perhaps even before our last stable release. If that's the case,
the last release announcement would have included a mention. If it
isn't, then it'll be mentioned via version control for our test builds.
> !Cache, according to its helpfile, was written by Adam Richardson
> ("Snowstone") in 2007. The current version 1.13 on his website has a
> runfile dated 2007-june-14. The runfile of my active copy in Boot
> Resources (which presumably came with a recent-ish version of Netsurf
> inside its usual boot-update file) is dated 2014-09-16, but !Sidediff
> shows it is identical to the 2007 runfile.
Time stamps on files are advisory, not gospel. :) The 2014-09-16 is
probably when you merged your first build of NetSurf that included it.
B.
> A typical item within this folder is filetyped as text but contains
> gobbledygook.
"Text" is the default file type for files created using UnixLib. Given
these files are not meant to be consumed by humans, I don't see a
problem there.
(The actual gobbledydook is the cached data and headers.)
> What is supposed to control expiry? Can't find anything about expiry
> within the !Cache application itself.
!Cache is not NetSurf-specific. The control settings are in each
application that uses it.
> Ah, Netsurf choices--cache. Disc cache size is set at 1024M (which
> I presume is meant as a max), and expiry at 28 days. Those figures
> seem to be defaults, because I have never altered them.
>
> Don't recall any discussion or explanation when Netsurf adopted !Cache
> -- when was that? Maybe it happened while I was away and I missed it.
It happened when Vince implemented disc caching :) This was some time
ago, perhaps even before our last stable release. If that's the case,
the last release announcement would have included a mention. If it
isn't, then it'll be mentioned via version control for our test builds.
> !Cache, according to its helpfile, was written by Adam Richardson
> ("Snowstone") in 2007. The current version 1.13 on his website has a
> runfile dated 2007-june-14. The runfile of my active copy in Boot
> Resources (which presumably came with a recent-ish version of Netsurf
> inside its usual boot-update file) is dated 2014-09-16, but !Sidediff
> shows it is identical to the 2007 runfile.
Time stamps on files are advisory, not gospel. :) The 2014-09-16 is
probably when you merged your first build of NetSurf that included it.
B.
Re: !Cache management
cj wrote on 16 Nov:
> Is anyone else finding that the new Cache feature does not seem to
> expire its content?
Well, that was a revelation. Did a count on
!Boot.resources.!cache.caches.default.netsurf and find 222 megabytes
of stuff. Earliest date seems to be Sept 06.
A typical item within this folder is filetyped as text but contains
gobbledygook.
What is supposed to control expiry? Can't find anything about expiry
within the !Cache application itself.
Ah, Netsurf choices--cache. Disc cache size is set at 1024M (which
I presume is meant as a max), and expiry at 28 days. Those figures
seem to be defaults, because I have never altered them.
Don't recall any discussion or explanation when Netsurf adopted !Cache
-- when was that? Maybe it happened while I was away and I missed it.
!Cache, according to its helpfile, was written by Adam Richardson
("Snowstone") in 2007. The current version 1.13 on his website has a
runfile dated 2007-june-14. The runfile of my active copy in Boot
Resources (which presumably came with a recent-ish version of Netsurf
inside its usual boot-update file) is dated 2014-09-16, but !Sidediff
shows it is identical to the 2007 runfile.
--
Jim Nagel www.archivemag.co.uk
> Is anyone else finding that the new Cache feature does not seem to
> expire its content?
Well, that was a revelation. Did a count on
!Boot.resources.!cache.caches.default.netsurf and find 222 megabytes
of stuff. Earliest date seems to be Sept 06.
A typical item within this folder is filetyped as text but contains
gobbledygook.
What is supposed to control expiry? Can't find anything about expiry
within the !Cache application itself.
Ah, Netsurf choices--cache. Disc cache size is set at 1024M (which
I presume is meant as a max), and expiry at 28 days. Those figures
seem to be defaults, because I have never altered them.
Don't recall any discussion or explanation when Netsurf adopted !Cache
-- when was that? Maybe it happened while I was away and I missed it.
!Cache, according to its helpfile, was written by Adam Richardson
("Snowstone") in 2007. The current version 1.13 on his website has a
runfile dated 2007-june-14. The runfile of my active copy in Boot
Resources (which presumably came with a recent-ish version of Netsurf
inside its usual boot-update file) is dated 2014-09-16, but !Sidediff
shows it is identical to the 2007 runfile.
--
Jim Nagel www.archivemag.co.uk
Sunday, 23 November 2014
Re: [Rpcemu] Some advice please
In article <20141123205616.GA4126@spod.org>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> On Sun, Nov 23, 2014 at 08:00:27PM +0000, Dave Symes wrote:
> > Running RPCEmu 0.8.12 with Select RISC OS under ADFS, I understand it
> > is possible to revert it back to HostFS by some process. I've played,
> > but had some problems, so forgetting what I've been doing.... It would
> > be much simpler if some kind person could lead me through the process.
> 1) copy the files from ADFS to hostfs (including !Boot and the like)
> 2) Issue the command '*configure filesystem hostfs', this should make
> hostfs the boot drive.
> Peter
Thanks
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> On Sun, Nov 23, 2014 at 08:00:27PM +0000, Dave Symes wrote:
> > Running RPCEmu 0.8.12 with Select RISC OS under ADFS, I understand it
> > is possible to revert it back to HostFS by some process. I've played,
> > but had some problems, so forgetting what I've been doing.... It would
> > be much simpler if some kind person could lead me through the process.
> 1) copy the files from ADFS to hostfs (including !Boot and the like)
> 2) Issue the command '*configure filesystem hostfs', this should make
> hostfs the boot drive.
> Peter
Thanks
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Some advice please
On Sun, Nov 23, 2014 at 08:00:27PM +0000, Dave Symes wrote:
> Running RPCEmu 0.8.12 with Select RISC OS under ADFS, I understand it is
> possible to revert it back to HostFS by some process.
> I've played, but had some problems, so forgetting what I've been doing....
> It would be much simpler if some kind person could lead me through the
> process.
1) copy the files from ADFS to hostfs (including !Boot and the like)
2) Issue the command '*configure filesystem hostfs', this should make
hostfs the boot drive.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Running RPCEmu 0.8.12 with Select RISC OS under ADFS, I understand it is
> possible to revert it back to HostFS by some process.
> I've played, but had some problems, so forgetting what I've been doing....
> It would be much simpler if some kind person could lead me through the
> process.
1) copy the files from ADFS to hostfs (including !Boot and the like)
2) Issue the command '*configure filesystem hostfs', this should make
hostfs the boot drive.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Some advice please
Running RPCEmu 0.8.12 with Select RISC OS under ADFS, I understand it is
possible to revert it back to HostFS by some process.
I've played, but had some problems, so forgetting what I've been doing....
It would be much simpler if some kind person could lead me through the
process.
Thanks
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
possible to revert it back to HostFS by some process.
I've played, but had some problems, so forgetting what I've been doing....
It would be much simpler if some kind person could lead me through the
process.
Thanks
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: Server error on Genes Reunited (HTTP 503.0)
In message <20141123160713.GJ25628@platypus.pepperfish.net>
on 23 Nov 2014 Rob Kendrick <rjek@netsurf-browser.org> wrote:
>> Accessing the Genes Reunited website from a PC seems to show no
>> problems so it is possible that NetSurf can't yet handle the link. It
>> it will be of help I can add it to the bug tracker.
> This error is from the server. NetSurf won't even have had access to
> any of the page's HTML or images or anything. The server is probably
> trying to be clever and is getting confused when something that doesn't
> announce itself to be Mozilla connects, or similar. Not at lot we can
> do.
Ah, thanks. This made me try the GR homepage - same error. Module =
WindsorModule.
Regards
Andrew
--
Andrew Pinder
on 23 Nov 2014 Rob Kendrick <rjek@netsurf-browser.org> wrote:
>> Accessing the Genes Reunited website from a PC seems to show no
>> problems so it is possible that NetSurf can't yet handle the link. It
>> it will be of help I can add it to the bug tracker.
> This error is from the server. NetSurf won't even have had access to
> any of the page's HTML or images or anything. The server is probably
> trying to be clever and is getting confused when something that doesn't
> announce itself to be Mozilla connects, or similar. Not at lot we can
> do.
Ah, thanks. This made me try the GR homepage - same error. Module =
WindsorModule.
Regards
Andrew
--
Andrew Pinder
Re: Server error on Genes Reunited (HTTP 503.0)
On Sun, Nov 23, 2014 at 03:35:12PM +0000, Andrew Pinder wrote:
> Hi all
>
> I received an email from Genes Reunited containing a link. Clicking
> on that gives
>
> HTTP Error 503.0 - Service Unavailable
>
> It lists as "Most likely causes"
> An invalid identity in the application pool could cause this error.
> The application pool is no longer running because of configuration
> or reaching application failure limits.
> The concurrent application request limit was reached.
>
> It also tells me that "This error occurs when the worker process was
> unable to start."
>
> Accessing the Genes Reunited website from a PC seems to show no
> problems so it is possible that NetSurf can't yet handle the link. It
> it will be of help I can add it to the bug tracker.
This error is from the server. NetSurf won't even have had access to
any of the page's HTML or images or anything. The server is probably
trying to be clever and is getting confused when something that doesn't
announce itself to be Mozilla connects, or similar. Not at lot we can
do.
B.
> Hi all
>
> I received an email from Genes Reunited containing a link. Clicking
> on that gives
>
> HTTP Error 503.0 - Service Unavailable
>
> It lists as "Most likely causes"
> An invalid identity in the application pool could cause this error.
> The application pool is no longer running because of configuration
> or reaching application failure limits.
> The concurrent application request limit was reached.
>
> It also tells me that "This error occurs when the worker process was
> unable to start."
>
> Accessing the Genes Reunited website from a PC seems to show no
> problems so it is possible that NetSurf can't yet handle the link. It
> it will be of help I can add it to the bug tracker.
This error is from the server. NetSurf won't even have had access to
any of the page's HTML or images or anything. The server is probably
trying to be clever and is getting confused when something that doesn't
announce itself to be Mozilla connects, or similar. Not at lot we can
do.
B.
Server error on Genes Reunited (HTTP 503.0)
Hi all
I received an email from Genes Reunited containing a link. Clicking
on that gives
HTTP Error 503.0 - Service Unavailable
It lists as "Most likely causes"
An invalid identity in the application pool could cause this error.
The application pool is no longer running because of configuration
or reaching application failure limits.
The concurrent application request limit was reached.
It also tells me that "This error occurs when the worker process was
unable to start."
Accessing the Genes Reunited website from a PC seems to show no
problems so it is possible that NetSurf can't yet handle the link. It
it will be of help I can add it to the bug tracker.
I'm running NetSurf on an ARMini with RO5.20. This error occurs with
both NetSurf 2311 and 2381.
Regards
Andrew
--
Andrew Pinder
I received an email from Genes Reunited containing a link. Clicking
on that gives
HTTP Error 503.0 - Service Unavailable
It lists as "Most likely causes"
An invalid identity in the application pool could cause this error.
The application pool is no longer running because of configuration
or reaching application failure limits.
The concurrent application request limit was reached.
It also tells me that "This error occurs when the worker process was
unable to start."
Accessing the Genes Reunited website from a PC seems to show no
problems so it is possible that NetSurf can't yet handle the link. It
it will be of help I can add it to the bug tracker.
I'm running NetSurf on an ARMini with RO5.20. This error occurs with
both NetSurf 2311 and 2381.
Regards
Andrew
--
Andrew Pinder
Saturday, 22 November 2014
Re: Error message about Possible Security Violation
Cristopher Dewhurst, on 21 Nov, wrote:
> In message <mpro.nf1jjs0092ypk01i3.pittdj@pittdj.co.uk>
> David Pitt <pittdj@pittdj.co.uk> wrote:
>
> [snip]
> >
https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID=09873000Jp
> >>
> > > (click on the "search" button")
>
> [snip]
>
> > The URL above has been wrapped and truncated, getting dropped 'p' back
> > gives a working URL on Safari and NetSurf #2321 on the Raspberry Pi.
>
> >
https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID=09873000Jp
>
>
> Thanks David but what do you get when you actually click on "search"
I get some job offers at the URL below.
>
https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF?USESSION=6D257B4671AE11E4B495EBAE27254D7A&WVID=09873000Jp&LANG=USA
Entering that URL directly however does trigger thee error below.
>
> I'm using Dev #2369 Raspberry Pi RISC OS 5.21 and still get the following
> error:
>
> "A possible security violation has been detected on displaying this page"
This is however nothing to with NetSurf.
--
David Pitt
> In message <mpro.nf1jjs0092ypk01i3.pittdj@pittdj.co.uk>
> David Pitt <pittdj@pittdj.co.uk> wrote:
>
> [snip]
> >
https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID=09873000Jp
> >>
> > > (click on the "search" button")
>
> [snip]
>
> > The URL above has been wrapped and truncated, getting dropped 'p' back
> > gives a working URL on Safari and NetSurf #2321 on the Raspberry Pi.
>
> >
https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID=09873000Jp
>
>
> Thanks David but what do you get when you actually click on "search"
I get some job offers at the URL below.
>
https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF?USESSION=6D257B4671AE11E4B495EBAE27254D7A&WVID=09873000Jp&LANG=USA
Entering that URL directly however does trigger thee error below.
>
> I'm using Dev #2369 Raspberry Pi RISC OS 5.21 and still get the following
> error:
>
> "A possible security violation has been detected on displaying this page"
This is however nothing to with NetSurf.
--
David Pitt
Hotlist and strange mouse behaviour (Atari)
I suspect this is an Atari only issue (build 2369).
When the mouse is over the Netsurf window, pressing F6 does
nothing but move the mouse outside the window and F6 opens
the Hotlist immediately.
Peter
When the mouse is over the Netsurf window, pressing F6 does
nothing but move the mouse outside the window and F6 opens
the Hotlist immediately.
Peter
Friday, 21 November 2014
[gccsdk] Trunk binutils configuration options
All,
Last weekend we played around with using GCC 4.7.4 to cross compile
NetSurf (we're still using 4.1.2r2 for CI builds). Mostly this worked
fine without much additional effort (full details in the most recent
four commits on [1]).
One oddity I'd like some input on, however, is the changeset at [2].
Specifically, without this change (which enables binutils plugins),
we cannot use the toolchain to compile OpenSSL (it runs into
difficulty when linking the OpenSSL command line tools).
I'd like to know if this change is safe and also whether it's actually
something that should be the default in GCCSDK itself?
Ta,
J.
1. http://git.netsurf-browser.org/toolchains.git/log/?h=rjek/gccsdk-4.7.4
2. http://git.netsurf-browser.org/toolchains.git/commit/?h=rjek/gccsdk-4.7.4&id=388d9098dc3578a41e07d720ba3708012c0a10e2
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Last weekend we played around with using GCC 4.7.4 to cross compile
NetSurf (we're still using 4.1.2r2 for CI builds). Mostly this worked
fine without much additional effort (full details in the most recent
four commits on [1]).
One oddity I'd like some input on, however, is the changeset at [2].
Specifically, without this change (which enables binutils plugins),
we cannot use the toolchain to compile OpenSSL (it runs into
difficulty when linking the OpenSSL command line tools).
I'd like to know if this change is safe and also whether it's actually
something that should be the default in GCCSDK itself?
Ta,
J.
1. http://git.netsurf-browser.org/toolchains.git/log/?h=rjek/gccsdk-4.7.4
2. http://git.netsurf-browser.org/toolchains.git/commit/?h=rjek/gccsdk-4.7.4&id=388d9098dc3578a41e07d720ba3708012c0a10e2
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: Error message about Possible Security Violation
In message <mpro.nf1jjs0092ypk01i3.pittdj@pittdj.co.uk>
David Pitt <pittdj@pittdj.co.uk> wrote:
[snip]
> https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID
> =09873000J
>> p
>>
>> (click on the "search" button")
[snip]
> The URL above has been wrapped and truncated, getting dropped 'p' back gives
> a working URL on Safari and NetSurf #2321 on the Raspberry Pi.
> https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID
> =09873000Jp
Thanks David but what do you get when you actually click on "search"
https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF?USESSION=6D257B4671
AE11E4B495EBAE27254D7A&WVID=09873000Jp&LANG=USA
I'm using Dev #2369 Raspberry Pi RISC OS 5.21 and still get the
following error:
"A possible security violation has been detected on displaying this
page"
thanks
--
Chris
David Pitt <pittdj@pittdj.co.uk> wrote:
[snip]
> https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID
> =09873000J
>> p
>>
>> (click on the "search" button")
[snip]
> The URL above has been wrapped and truncated, getting dropped 'p' back gives
> a working URL on Safari and NetSurf #2321 on the Raspberry Pi.
> https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID
> =09873000Jp
Thanks David but what do you get when you actually click on "search"
https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF?USESSION=6D257B4671
AE11E4B495EBAE27254D7A&WVID=09873000Jp&LANG=USA
I'm using Dev #2369 Raspberry Pi RISC OS 5.21 and still get the
following error:
"A possible security violation has been detected on displaying this
page"
thanks
--
Chris
Re: [gccsdk] New RISC OS GCC package
Hi Alan,
Sorry for not replying sooner.
On 03/11/14 09:54, alan buckley wrote:
> Is the GCCSDK trunk in a state where it would be possible to create
> a new RISC OS GCC package?
I would say so. There are a couple of outstanding bugs, eg,
bug#254 which need looking at, but such a complex program is never
going to be completely bug free. All we can do is try to fix any
reported bugs and continue to release updated versions.
> I have just switch my TBX library to be cross-compiled with
> the GCCSDK and realised I can't upload it as it would be
> unusable for anyone who is just programming on a RISC OS
> machine as it won't link with a program compiled with
> GCC 4.1.2. I mix use of the cross-compiler with the native
> compiler as well, so it would be helpful for me as well.
> I have a virtual Ubuntu machine set up, so if the compiler
> is thought to be stable enough I'm willing to do the
> work of building it and creating the packages.
> i.e. Checking the packaging scripts work with this release
> and trying them out.
Yes, that would be great, thanks.
> If it is OK for me to generate the packages, what would
> the version numbers be?
GCC V4.7.4
Unixlib V5.0.0
libstdc++ V6.0.17
SOManager V2.10
I think everything else (libgcc, libm, etc) is as it was in 4.1.2.
> If it's not in a sufficiently stable state, is there any idea
> when it would be?
The only way we'll know for sure how stable it is, is if
people use it, so we may as well make it more generally
available. Personally, I always use the 4.7.4 cross compiler,
and I can't say I've found any show stoppers.
Obviously, 4.1.2 should remain available too for those
who want it.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Sorry for not replying sooner.
On 03/11/14 09:54, alan buckley wrote:
> Is the GCCSDK trunk in a state where it would be possible to create
> a new RISC OS GCC package?
I would say so. There are a couple of outstanding bugs, eg,
bug#254 which need looking at, but such a complex program is never
going to be completely bug free. All we can do is try to fix any
reported bugs and continue to release updated versions.
> I have just switch my TBX library to be cross-compiled with
> the GCCSDK and realised I can't upload it as it would be
> unusable for anyone who is just programming on a RISC OS
> machine as it won't link with a program compiled with
> GCC 4.1.2. I mix use of the cross-compiler with the native
> compiler as well, so it would be helpful for me as well.
> I have a virtual Ubuntu machine set up, so if the compiler
> is thought to be stable enough I'm willing to do the
> work of building it and creating the packages.
> i.e. Checking the packaging scripts work with this release
> and trying them out.
Yes, that would be great, thanks.
> If it is OK for me to generate the packages, what would
> the version numbers be?
GCC V4.7.4
Unixlib V5.0.0
libstdc++ V6.0.17
SOManager V2.10
I think everything else (libgcc, libm, etc) is as it was in 4.1.2.
> If it's not in a sufficiently stable state, is there any idea
> when it would be?
The only way we'll know for sure how stable it is, is if
people use it, so we may as well make it more generally
available. Personally, I always use the 4.7.4 cross compiler,
and I can't say I've found any show stoppers.
Obviously, 4.1.2 should remain available too for those
who want it.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Tuesday, 18 November 2014
Re: RISC OS experimental build with new compiler
On 16 Nov 2014, Rob Kendrick <rjek@netsurf-browser.org> wrote:
> I have built a copy of RISC OS NetSurf using a much newer version of
> the compiler (GCCSDK's prerelease based on 4.7). If people could give
> a few minutes to playing with it to give us some confidence of it
> working, that'd be great. (Also any comments on performance
> difference, better or worse, would be of interest.)
I donwloaded 3.3 (Dev) EXPERIMENTAL on 16 November and have used it
since then. So far, there has been one crash, which occurred after I had
launched several urls from Google News. While I was reading one page it
seems that another page,which was still loading,caused the crash. The
log is at https://dl.dropbox.com/u/77062274/log.zip
Since then, no problem. I've not noticed any performance difference as
compared to the 'normal' 3.3 builds.
RiscPC, RISC OS 6.20
Tony
> I have built a copy of RISC OS NetSurf using a much newer version of
> the compiler (GCCSDK's prerelease based on 4.7). If people could give
> a few minutes to playing with it to give us some confidence of it
> working, that'd be great. (Also any comments on performance
> difference, better or worse, would be of interest.)
I donwloaded 3.3 (Dev) EXPERIMENTAL on 16 November and have used it
since then. So far, there has been one crash, which occurred after I had
launched several urls from Google News. While I was reading one page it
seems that another page,which was still loading,caused the crash. The
log is at https://dl.dropbox.com/u/77062274/log.zip
Since then, no problem. I've not noticed any performance difference as
compared to the 'normal' 3.3 builds.
RiscPC, RISC OS 6.20
Tony
Monday, 17 November 2014
Re: !Cache management
On Sun, Nov 16, 2014 at 09:49:06PM +0000, cj wrote:
> In article <20141116145722.GC21287@platypus.pepperfish.net>,
> Rob Kendrick <rjek@netsurf-browser.org> wrote:
> > Currently, if NetSurf crashes (or your computer does) without
> > quitting cleanly, newly-created cached items will be "leaked"; ie
> > they will not be stored in the index which is written out on exit.
>
> Ahhh - that could explain it. My machines normally run 24/7, and the
> only time Netsurf is quit is when I move to the most recent version,
> which may be a week or more between upgrades. I do get the occasional
> crash of Netsurf, so it could be that a week or more of cache
> contents is not being indexed.
This does sound like it may be the cause then. A solution (ie,
detection of an unclean exit and thus a garbage collection and index
rebuild etc) is on the to do list.
Sadly I think the only solution at the moment however is to empty the
whole cache directory manually.
B.
> In article <20141116145722.GC21287@platypus.pepperfish.net>,
> Rob Kendrick <rjek@netsurf-browser.org> wrote:
> > Currently, if NetSurf crashes (or your computer does) without
> > quitting cleanly, newly-created cached items will be "leaked"; ie
> > they will not be stored in the index which is written out on exit.
>
> Ahhh - that could explain it. My machines normally run 24/7, and the
> only time Netsurf is quit is when I move to the most recent version,
> which may be a week or more between upgrades. I do get the occasional
> crash of Netsurf, so it could be that a week or more of cache
> contents is not being indexed.
This does sound like it may be the cause then. A solution (ie,
detection of an unclean exit and thus a garbage collection and index
rebuild etc) is on the to do list.
Sadly I think the only solution at the moment however is to empty the
whole cache directory manually.
B.
Sunday, 16 November 2014
Re: !Cache management
In article <20141116145722.GC21287@platypus.pepperfish.net>,
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> Currently, if NetSurf crashes (or your computer does) without
> quitting cleanly, newly-created cached items will be "leaked"; ie
> they will not be stored in the index which is written out on exit.
Ahhh - that could explain it. My machines normally run 24/7, and the
only time Netsurf is quit is when I move to the most recent version,
which may be a week or more between upgrades. I do get the occasional
crash of Netsurf, so it could be that a week or more of cache
contents is not being indexed.
--
Chris Johnson
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> Currently, if NetSurf crashes (or your computer does) without
> quitting cleanly, newly-created cached items will be "leaked"; ie
> they will not be stored in the index which is written out on exit.
Ahhh - that could explain it. My machines normally run 24/7, and the
only time Netsurf is quit is when I move to the most recent version,
which may be a week or more between upgrades. I do get the occasional
crash of Netsurf, so it could be that a week or more of cache
contents is not being indexed.
--
Chris Johnson
Re: RISC OS experimental build with new compiler
On Sun, Nov 16, 2014 at 06:10:17PM +0000, Fred Bambrough wrote:
> In message <20141116101839.GA21287@platypus.pepperfish.net>
> Rob Kendrick <rjek@netsurf-browser.org> wrote:
>
> > Hi,
> >
> > I have built a copy of RISC OS NetSurf using a much newer version of the
> > compiler (GCCSDK's prerelease based on 4.7). If people could give a few
> > minutes to playing with it to give us some confidence of it working,
> > that'd be great. (Also any comments on performance difference, better
> > or worse, would be of interest.)
>
> Was playing nicely. Downloaded a couple of files from ROOL and checked out
> a few web sites. Then it crashed on my closing the window. Would you like
> the log? Where to if so?
Emailing it to me directly is probably best, rather than opening a bug
for something that doesn't really exist on the bug tracker.
B.
> In message <20141116101839.GA21287@platypus.pepperfish.net>
> Rob Kendrick <rjek@netsurf-browser.org> wrote:
>
> > Hi,
> >
> > I have built a copy of RISC OS NetSurf using a much newer version of the
> > compiler (GCCSDK's prerelease based on 4.7). If people could give a few
> > minutes to playing with it to give us some confidence of it working,
> > that'd be great. (Also any comments on performance difference, better
> > or worse, would be of interest.)
>
> Was playing nicely. Downloaded a couple of files from ROOL and checked out
> a few web sites. Then it crashed on my closing the window. Would you like
> the log? Where to if so?
Emailing it to me directly is probably best, rather than opening a bug
for something that doesn't really exist on the bug tracker.
B.
Re: RISC OS experimental build with new compiler
In message <20141116101839.GA21287@platypus.pepperfish.net>
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> Hi,
>
> I have built a copy of RISC OS NetSurf using a much newer version of the
> compiler (GCCSDK's prerelease based on 4.7). If people could give a few
> minutes to playing with it to give us some confidence of it working,
> that'd be great. (Also any comments on performance difference, better
> or worse, would be of interest.)
Was playing nicely. Downloaded a couple of files from ROOL and checked out
a few web sites. Then it crashed on my closing the window. Would you like
the log? Where to if so?
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> Hi,
>
> I have built a copy of RISC OS NetSurf using a much newer version of the
> compiler (GCCSDK's prerelease based on 4.7). If people could give a few
> minutes to playing with it to give us some confidence of it working,
> that'd be great. (Also any comments on performance difference, better
> or worse, would be of interest.)
Was playing nicely. Downloaded a couple of files from ROOL and checked out
a few web sites. Then it crashed on my closing the window. Would you like
the log? Where to if so?
Re: Amiga window data structures
On Sat, 17 May 2014 15:37:31 +0100, Michael Drake wrote:
> I have been looking at stopping the Amiga front end from #including
> desktop/browser_private.h, like I did for the Windows front end earlier
> this week.
>
> The big problem with the Amiga code at the moment is that the tabs
> implementation seems to depend on being able to dereference struct
> browser_window (bw), to get to the struct gui_window (gw).
[...]
> I suggest that the gw2 be changed to have a pointer to a gw representing
> the current tab, and add a pointer to bw entry in the gw.
I've now fixed this.
Chris
> I have been looking at stopping the Amiga front end from #including
> desktop/browser_private.h, like I did for the Windows front end earlier
> this week.
>
> The big problem with the Amiga code at the moment is that the tabs
> implementation seems to depend on being able to dereference struct
> browser_window (bw), to get to the struct gui_window (gw).
[...]
> I suggest that the gw2 be changed to have a pointer to a gw representing
> the current tab, and add a pointer to bw entry in the gw.
I've now fixed this.
Chris
Re: !Cache management
On Sun, Nov 16, 2014 at 02:33:57PM +0000, cj wrote:
> I checked on the PandaBoard today and lo and behold, the cache
> contained more than 8 GB of files. This machine was also configured
> for a 1 GB max and 10 days expiry. I have now deleted and disabled
> the cache on the PandaRO.
>
> On all my machines I use recent versions of RISC OS 5.21, and recent
> development versions of Netsurf.
>
> Am I misunderstanding what the cache settings are?
Currently, if NetSurf crashes (or your computer does) without quitting
cleanly, newly-created cached items will be "leaked"; ie they will not
be stored in the index which is written out on exit.
We plan to have this situation detected on next start and automatically
remove orphan items.
At the moment, the only simple way to recover the space taken up by
these lost cache items is to delete the contents of the NetSurf folder
inside !Cache.
B.
> I checked on the PandaBoard today and lo and behold, the cache
> contained more than 8 GB of files. This machine was also configured
> for a 1 GB max and 10 days expiry. I have now deleted and disabled
> the cache on the PandaRO.
>
> On all my machines I use recent versions of RISC OS 5.21, and recent
> development versions of Netsurf.
>
> Am I misunderstanding what the cache settings are?
Currently, if NetSurf crashes (or your computer does) without quitting
cleanly, newly-created cached items will be "leaked"; ie they will not
be stored in the index which is written out on exit.
We plan to have this situation detected on next start and automatically
remove orphan items.
At the moment, the only simple way to recover the space taken up by
these lost cache items is to delete the contents of the NetSurf folder
inside !Cache.
B.
Re: Warning! Crash in recent development builds
In article <mpro.nf3cpb0072n0v0136.pittdj@pittdj.co.uk>, David Pitt
<pittdj@pittdj.co.uk> wrote:
> Brian Jordan, on 15 Nov, wrote:
> > In article <f4a9f06654.pittdj+@iyonix.home>, David Pitt
> > <pittdj@pittdj.co.uk> wrote:
> > > In message <5466e9f50bbrian.jordan9@btinternet.com> Brian Jordan
> > > <brian.jordan9@btinternet.com> wrote:
> >
> > > > I have discovered that attempting to complete forms rendered in
> > > > 3.3 (Dev CI #2327) can crash NetSurf and stiff the computer. In
> > > > particular ists, where one selects from a list to complete the
> > > > form, fail to show the list and everything hangs - here anyway.
> > > > Bug report raised (after reverting to an earlier NetSurf to
> > > > circumvent this problem on the tracker).
> >
> > > I have uploaded a log. On the Raspberry Pi an alt-break stopped
> > > NetSurf without the whole machine going down.
> >
> > Here alt-break delays the agony momentarily. Pressing "Stop" in the
> > Window Messenger dialogue box stiffs the emulator.
> It is fixed in #2335, for which many thanks.
That also seems to fix an infinite loop and crash on,
http://flux3dp.com/
or has it? A second opinion, please. The full page isn't displayed!
<pittdj@pittdj.co.uk> wrote:
> Brian Jordan, on 15 Nov, wrote:
> > In article <f4a9f06654.pittdj+@iyonix.home>, David Pitt
> > <pittdj@pittdj.co.uk> wrote:
> > > In message <5466e9f50bbrian.jordan9@btinternet.com> Brian Jordan
> > > <brian.jordan9@btinternet.com> wrote:
> >
> > > > I have discovered that attempting to complete forms rendered in
> > > > 3.3 (Dev CI #2327) can crash NetSurf and stiff the computer. In
> > > > particular ists, where one selects from a list to complete the
> > > > form, fail to show the list and everything hangs - here anyway.
> > > > Bug report raised (after reverting to an earlier NetSurf to
> > > > circumvent this problem on the tracker).
> >
> > > I have uploaded a log. On the Raspberry Pi an alt-break stopped
> > > NetSurf without the whole machine going down.
> >
> > Here alt-break delays the agony momentarily. Pressing "Stop" in the
> > Window Messenger dialogue box stiffs the emulator.
> It is fixed in #2335, for which many thanks.
That also seems to fix an infinite loop and crash on,
http://flux3dp.com/
or has it? A second opinion, please. The full page isn't displayed!
!Cache management
Is anyone else finding that the new Cache feature does not seem to
expire its content?
I wondered a few weeks ago why the main harddrive on the Iyonix was
filling up more quickly than I thought it should. I found the Netsurf
cache was close to 10 GB in size. Netsurf was configured for a cache
maximum of 1 GB with expiry set to 10 days. Randomly checking
datestamps of some of the files in the cache showed them to be weeks
and even months old. I had been assuming that (a) old files would be
deleted after the configured expiry time and (b) if the cache size
approached the configured maximum size, then the older files would be
deleted anyway to keep the size under the limit. I deleted the whole
cache at the time, and it is well under 1 GB at the moment, although
checking a few random datestamps, there are certainly files going
back to early August, even with an expiry now set to 7 days.
I checked on the PandaBoard today and lo and behold, the cache
contained more than 8 GB of files. This machine was also configured
for a 1 GB max and 10 days expiry. I have now deleted and disabled
the cache on the PandaRO.
On all my machines I use recent versions of RISC OS 5.21, and recent
development versions of Netsurf.
Am I misunderstanding what the cache settings are?
--
Chris Johnson
expire its content?
I wondered a few weeks ago why the main harddrive on the Iyonix was
filling up more quickly than I thought it should. I found the Netsurf
cache was close to 10 GB in size. Netsurf was configured for a cache
maximum of 1 GB with expiry set to 10 days. Randomly checking
datestamps of some of the files in the cache showed them to be weeks
and even months old. I had been assuming that (a) old files would be
deleted after the configured expiry time and (b) if the cache size
approached the configured maximum size, then the older files would be
deleted anyway to keep the size under the limit. I deleted the whole
cache at the time, and it is well under 1 GB at the moment, although
checking a few random datestamps, there are certainly files going
back to early August, even with an expiry now set to 7 days.
I checked on the PandaBoard today and lo and behold, the cache
contained more than 8 GB of files. This machine was also configured
for a 1 GB max and 10 days expiry. I have now deleted and disabled
the cache on the PandaRO.
On all my machines I use recent versions of RISC OS 5.21, and recent
development versions of Netsurf.
Am I misunderstanding what the cache settings are?
--
Chris Johnson
Re: RISC OS experimental build with new compiler
In message <20141116110249.GB21287@platypus.pepperfish.net>
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> On Sun, Nov 16, 2014 at 10:57:43AM +0000, David Pitt wrote:
>> In message <20141116101839.GA21287@platypus.pepperfish.net>
>> Rob Kendrick <rjek@netsurf-browser.org> wrote:
>>
>>> Hi,
>>
>>> I have built a copy of RISC OS NetSurf using a much newer version of the
>>> compiler (GCCSDK's prerelease based on 4.7). If people could give a few
>>> minutes to playing with it to give us some confidence of it working,
>>> that'd be great. (Also any comments on performance difference, better
>>> or worse, would be of interest.)
>>
>>> http://www.rjek.com/netsurf-gccsdk-4.7.zip
>>
>> It has had a few minutes on the Raspberry Pi, it works, it didn't
>> explode at all. In fact as far as I can see it is indistinguishable
>> from #2335.
> Check about:testament to make sure it really is my build you're using :)
That seems a weird comment.
I did check which was running from Info on the iconbar menu.
--
David Pitt
OS4.39, VRPC, iMac
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> On Sun, Nov 16, 2014 at 10:57:43AM +0000, David Pitt wrote:
>> In message <20141116101839.GA21287@platypus.pepperfish.net>
>> Rob Kendrick <rjek@netsurf-browser.org> wrote:
>>
>>> Hi,
>>
>>> I have built a copy of RISC OS NetSurf using a much newer version of the
>>> compiler (GCCSDK's prerelease based on 4.7). If people could give a few
>>> minutes to playing with it to give us some confidence of it working,
>>> that'd be great. (Also any comments on performance difference, better
>>> or worse, would be of interest.)
>>
>>> http://www.rjek.com/netsurf-gccsdk-4.7.zip
>>
>> It has had a few minutes on the Raspberry Pi, it works, it didn't
>> explode at all. In fact as far as I can see it is indistinguishable
>> from #2335.
> Check about:testament to make sure it really is my build you're using :)
That seems a weird comment.
I did check which was running from Info on the iconbar menu.
--
David Pitt
OS4.39, VRPC, iMac
Re: RISC OS experimental build with new compiler
On Sun, Nov 16, 2014 at 10:57:43AM +0000, David Pitt wrote:
> In message <20141116101839.GA21287@platypus.pepperfish.net>
> Rob Kendrick <rjek@netsurf-browser.org> wrote:
>
> > Hi,
>
> > I have built a copy of RISC OS NetSurf using a much newer version of the
> > compiler (GCCSDK's prerelease based on 4.7). If people could give a few
> > minutes to playing with it to give us some confidence of it working,
> > that'd be great. (Also any comments on performance difference, better
> > or worse, would be of interest.)
>
> > http://www.rjek.com/netsurf-gccsdk-4.7.zip
>
> It has had a few minutes on the Raspberry Pi, it works, it didn't
> explode at all. In fact as far as I can see it is indistinguishable
> from #2335.
Check about:testament to make sure it really is my build you're using :)
B.
> In message <20141116101839.GA21287@platypus.pepperfish.net>
> Rob Kendrick <rjek@netsurf-browser.org> wrote:
>
> > Hi,
>
> > I have built a copy of RISC OS NetSurf using a much newer version of the
> > compiler (GCCSDK's prerelease based on 4.7). If people could give a few
> > minutes to playing with it to give us some confidence of it working,
> > that'd be great. (Also any comments on performance difference, better
> > or worse, would be of interest.)
>
> > http://www.rjek.com/netsurf-gccsdk-4.7.zip
>
> It has had a few minutes on the Raspberry Pi, it works, it didn't
> explode at all. In fact as far as I can see it is indistinguishable
> from #2335.
Check about:testament to make sure it really is my build you're using :)
B.
Re: RISC OS experimental build with new compiler
In message <20141116101839.GA21287@platypus.pepperfish.net>
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> Hi,
> I have built a copy of RISC OS NetSurf using a much newer version of the
> compiler (GCCSDK's prerelease based on 4.7). If people could give a few
> minutes to playing with it to give us some confidence of it working,
> that'd be great. (Also any comments on performance difference, better
> or worse, would be of interest.)
> http://www.rjek.com/netsurf-gccsdk-4.7.zip
It has had a few minutes on the Raspberry Pi, it works, it didn't
explode at all. In fact as far as I can see it is indistinguishable
from #2335.
--
David Pitt
OS4.39, VRPC, iMac
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> Hi,
> I have built a copy of RISC OS NetSurf using a much newer version of the
> compiler (GCCSDK's prerelease based on 4.7). If people could give a few
> minutes to playing with it to give us some confidence of it working,
> that'd be great. (Also any comments on performance difference, better
> or worse, would be of interest.)
> http://www.rjek.com/netsurf-gccsdk-4.7.zip
It has had a few minutes on the Raspberry Pi, it works, it didn't
explode at all. In fact as far as I can see it is indistinguishable
from #2335.
--
David Pitt
OS4.39, VRPC, iMac
Re: RISC OS experimental build with new compiler
On 16 Nov 2014 Rob Kendrick wrote:
> I have built a copy of RISC OS NetSurf using a much newer version of the
> compiler (GCCSDK's prerelease based on 4.7). If people could give a few
> minutes to playing with it to give us some confidence of it working,
> that'd be great. (Also any comments on performance difference, better
> or worse, would be of interest.)
> http://www.rjek.com/netsurf-gccsdk-4.7.zip
I've had a quick play. Nothing too difficult but it seems fine here.
KRPC, RO6.14
--
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.
> I have built a copy of RISC OS NetSurf using a much newer version of the
> compiler (GCCSDK's prerelease based on 4.7). If people could give a few
> minutes to playing with it to give us some confidence of it working,
> that'd be great. (Also any comments on performance difference, better
> or worse, would be of interest.)
> http://www.rjek.com/netsurf-gccsdk-4.7.zip
I've had a quick play. Nothing too difficult but it seems fine here.
KRPC, RO6.14
--
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.
RISC OS experimental build with new compiler
Hi,
I have built a copy of RISC OS NetSurf using a much newer version of the
compiler (GCCSDK's prerelease based on 4.7). If people could give a few
minutes to playing with it to give us some confidence of it working,
that'd be great. (Also any comments on performance difference, better
or worse, would be of interest.)
http://www.rjek.com/netsurf-gccsdk-4.7.zip
B.
I have built a copy of RISC OS NetSurf using a much newer version of the
compiler (GCCSDK's prerelease based on 4.7). If people could give a few
minutes to playing with it to give us some confidence of it working,
that'd be great. (Also any comments on performance difference, better
or worse, would be of interest.)
http://www.rjek.com/netsurf-gccsdk-4.7.zip
B.
Saturday, 15 November 2014
Re: Warning! Crash in recent development builds
In article <mpro.nf3cpb0072n0v0136.pittdj@pittdj.co.uk>,
David Pitt <pittdj@pittdj.co.uk> wrote:
> Brian Jordan, on 15 Nov, wrote:
> > In article <f4a9f06654.pittdj+@iyonix.home>,
> > David Pitt <pittdj@pittdj.co.uk> wrote:
> > > In message <5466e9f50bbrian.jordan9@btinternet.com>
> > > Brian Jordan <brian.jordan9@btinternet.com> wrote:
> >
> > > > I have discovered that attempting to complete forms rendered in
> > > > 3.3 (Dev CI #2327) can crash NetSurf and stiff the computer. In
> > > > particular ists, where one selects from a list to complete the
> > > > form, fail to show the list and everything hangs - here anyway.
> > > > Bug report raised (after reverting to an earlier NetSurf to
> > > > circumvent this problem on the tracker).
> >
> > > I have uploaded a log. On the Raspberry Pi an alt-break stopped
> > > NetSurf without the whole machine going down.
> >
> > Here alt-break delays the agony momentarily. Pressing "Stop" in the
> > Window Messenger dialogue box stiffs the emulator.
> It is fixed in #2335, for which many thanks.
So it is! Your thanks very much seconded here. For anyone who doubts the
value of raising a bug report it is absolutely worthwhile, the developers
are doing a fantastic job and it is nice, in a humble way, to help them.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
David Pitt <pittdj@pittdj.co.uk> wrote:
> Brian Jordan, on 15 Nov, wrote:
> > In article <f4a9f06654.pittdj+@iyonix.home>,
> > David Pitt <pittdj@pittdj.co.uk> wrote:
> > > In message <5466e9f50bbrian.jordan9@btinternet.com>
> > > Brian Jordan <brian.jordan9@btinternet.com> wrote:
> >
> > > > I have discovered that attempting to complete forms rendered in
> > > > 3.3 (Dev CI #2327) can crash NetSurf and stiff the computer. In
> > > > particular ists, where one selects from a list to complete the
> > > > form, fail to show the list and everything hangs - here anyway.
> > > > Bug report raised (after reverting to an earlier NetSurf to
> > > > circumvent this problem on the tracker).
> >
> > > I have uploaded a log. On the Raspberry Pi an alt-break stopped
> > > NetSurf without the whole machine going down.
> >
> > Here alt-break delays the agony momentarily. Pressing "Stop" in the
> > Window Messenger dialogue box stiffs the emulator.
> It is fixed in #2335, for which many thanks.
So it is! Your thanks very much seconded here. For anyone who doubts the
value of raising a bug report it is absolutely worthwhile, the developers
are doing a fantastic job and it is nice, in a humble way, to help them.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
Re: Warning! Crash in recent development builds
Brian Jordan, on 15 Nov, wrote:
> In article <f4a9f06654.pittdj+@iyonix.home>,
> David Pitt <pittdj@pittdj.co.uk> wrote:
> > In message <5466e9f50bbrian.jordan9@btinternet.com>
> > Brian Jordan <brian.jordan9@btinternet.com> wrote:
>
> > > I have discovered that attempting to complete forms rendered in 3.3
> > > (Dev CI #2327) can crash NetSurf and stiff the computer. In particular
> > > ists, where one selects from a list to complete the form, fail to show
> > > the list and everything hangs - here anyway. Bug report raised (after
> > > reverting to an earlier NetSurf to circumvent this problem on the
> > > tracker).
>
> > I have uploaded a log. On the Raspberry Pi an alt-break stopped NetSurf
> > without the whole machine going down.
>
> Here alt-break delays the agony momentarily. Pressing "Stop" in the Window
> Messenger dialogue box stiffs the emulator.
It is fixed in #2335, for which many thanks.
--
David Pitt
> In article <f4a9f06654.pittdj+@iyonix.home>,
> David Pitt <pittdj@pittdj.co.uk> wrote:
> > In message <5466e9f50bbrian.jordan9@btinternet.com>
> > Brian Jordan <brian.jordan9@btinternet.com> wrote:
>
> > > I have discovered that attempting to complete forms rendered in 3.3
> > > (Dev CI #2327) can crash NetSurf and stiff the computer. In particular
> > > ists, where one selects from a list to complete the form, fail to show
> > > the list and everything hangs - here anyway. Bug report raised (after
> > > reverting to an earlier NetSurf to circumvent this problem on the
> > > tracker).
>
> > I have uploaded a log. On the Raspberry Pi an alt-break stopped NetSurf
> > without the whole machine going down.
>
> Here alt-break delays the agony momentarily. Pressing "Stop" in the Window
> Messenger dialogue box stiffs the emulator.
It is fixed in #2335, for which many thanks.
--
David Pitt
Cannot Save hotlist
Sometimes I have noticed that when exiting Netsurf it
says it cannot save the hotlist.
I have noticed this issue for months but only recently
made a connection.
It only seems to occur whenever I have used the "View source"
option.
It could be that the editor I am using to view the source
is holding a file lock but why would it lock the hotlist ?
Currently using Atari build 2327.
Peter
says it cannot save the hotlist.
I have noticed this issue for months but only recently
made a connection.
It only seems to occur whenever I have used the "View source"
option.
It could be that the editor I am using to view the source
is holding a file lock but why would it lock the hotlist ?
Currently using Atari build 2327.
Peter
AGM Minutes, 2014
NetSurf AGM - 2014
==================
Attendance
----------
* Daniel Silverstone
* Rob Kendrick
* Michael Drake
* Vincent Sanders
* John-Mark Bell
* Chris Young
Secretary's report
------------------
Last year's society committee consisted of:
* Michael Drake, Chair
* John-Mark Bell, Treasurer
* Daniel Silverstone, Secretary
Last year's non-committee membership consisted of:
* Rob Kendrick
* Chris Young
* Vincent Sanders
* François Revol
* Steve Fryatt
This year we welcome Rupinder Singh Khokhar and Anthony J. Bentley
Noone has dropped out
The society is therefore quorate
Treasurer's report
------------------
Chair's report
--------------
* NetSurf is still actively developed, and new people turn up who are
interested in both the browser and its libraries. We've made releases in the
last year, and have done plenty of work since the last release.
* We had a successful GSoC student, who made nice progress on the libraries.
* At the developer hack weekend we are discussing future development.
* Thanks to everyone for their contributions this year.
GSoC Donation
-------------
Due to difficulty navigating through the complexities of international tax law,
we won't be receiving the mentor payment from this year's GSoC.
We have the option of donating it to the Software Freedom Conservancy
Kinnison seconds this option
tlsa votes that we do that
The committee has hereby voted to donate our mentor payment from GSoC 2014 to
the Software Freedom Conservancy
AI: John-Mark Bell to organise that donation.
AOB
---
Each of the RISC OS, Atari and Cocoa frontends are not being actively supported
by any of the developers on the project at this time. Noone was prepared to
step forward to offer assistance during the AGM.
When asked what impact this would have, Vincent explained that the releases are
therefore at risk of being unreleasable for verison 3.3 and forward from there.
The Atari toolchain (NetSurf toolchain) is currently not functional on our CI
infrastructure. When asked what impact this would have Vincent noted that we
are unable to build newer toolchains and thus close security holes
Vincent also noted that the support burden for maintaining the Cocoa frontend
means that it is very much at risk of being dropped without an active
maintainer.
AI: Release Manager to produce report to development *and* user mailing lists
detailing at-risk builds and their likely remaining lifetime
Close
-----
Michael thanked everyone and made special note that Daniel Silverstone donated
an SSD to the Cocoa CI engine.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
==================
Attendance
----------
* Daniel Silverstone
* Rob Kendrick
* Michael Drake
* Vincent Sanders
* John-Mark Bell
* Chris Young
Secretary's report
------------------
Last year's society committee consisted of:
* Michael Drake, Chair
* John-Mark Bell, Treasurer
* Daniel Silverstone, Secretary
Last year's non-committee membership consisted of:
* Rob Kendrick
* Chris Young
* Vincent Sanders
* François Revol
* Steve Fryatt
This year we welcome Rupinder Singh Khokhar and Anthony J. Bentley
Noone has dropped out
The society is therefore quorate
Treasurer's report
------------------
Chair's report
--------------
* NetSurf is still actively developed, and new people turn up who are
interested in both the browser and its libraries. We've made releases in the
last year, and have done plenty of work since the last release.
* We had a successful GSoC student, who made nice progress on the libraries.
* At the developer hack weekend we are discussing future development.
* Thanks to everyone for their contributions this year.
GSoC Donation
-------------
Due to difficulty navigating through the complexities of international tax law,
we won't be receiving the mentor payment from this year's GSoC.
We have the option of donating it to the Software Freedom Conservancy
Kinnison seconds this option
tlsa votes that we do that
The committee has hereby voted to donate our mentor payment from GSoC 2014 to
the Software Freedom Conservancy
AI: John-Mark Bell to organise that donation.
AOB
---
Each of the RISC OS, Atari and Cocoa frontends are not being actively supported
by any of the developers on the project at this time. Noone was prepared to
step forward to offer assistance during the AGM.
When asked what impact this would have, Vincent explained that the releases are
therefore at risk of being unreleasable for verison 3.3 and forward from there.
The Atari toolchain (NetSurf toolchain) is currently not functional on our CI
infrastructure. When asked what impact this would have Vincent noted that we
are unable to build newer toolchains and thus close security holes
Vincent also noted that the support burden for maintaining the Cocoa frontend
means that it is very much at risk of being dropped without an active
maintainer.
AI: Release Manager to produce report to development *and* user mailing lists
detailing at-risk builds and their likely remaining lifetime
Close
-----
Michael thanked everyone and made special note that Daniel Silverstone donated
an SSD to the Cocoa CI engine.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
NetSurf Society Financial Report
NetSurf Society Financial Report, November 2014
===============================================
Overview
--------
This is a summary of the society's financial status as of 2014-11-15.
No income is reported for this period.
All outgoings have been in the form of reimbursements for
project-related activities.
As resolved at the 2010 AGM, the society will now pay up to 15 pence per
mile for mileage.
Detail
------
Balance carried forward: 1648.21
Expenditure:
Michael Drake -- train tickets:
EDB->CBG->EDB Dev. Weekend Jan 2014 (102.20)
Vincent Sanders:
Hosting for CI system (340.25)
Remaining Funds: 1205.76
Notes
-----
The project did attend the Wakefield 2014 show. The income and
expenditure statement for the show did not make it in time to be
included in this report.
As a result of the complexities of international tax law, the
expected income from GSoC will not be forthcoming. There is an
option to donate it to the Software Freedom Conservancy. This
should be decided at the AGM.
===============================================
Overview
--------
This is a summary of the society's financial status as of 2014-11-15.
No income is reported for this period.
All outgoings have been in the form of reimbursements for
project-related activities.
As resolved at the 2010 AGM, the society will now pay up to 15 pence per
mile for mileage.
Detail
------
Balance carried forward: 1648.21
Expenditure:
Michael Drake -- train tickets:
EDB->CBG->EDB Dev. Weekend Jan 2014 (102.20)
Vincent Sanders:
Hosting for CI system (340.25)
Remaining Funds: 1205.76
Notes
-----
The project did attend the Wakefield 2014 show. The income and
expenditure statement for the show did not make it in time to be
included in this report.
As a result of the complexities of international tax law, the
expected income from GSoC will not be forthcoming. There is an
option to donate it to the Software Freedom Conservancy. This
should be decided at the AGM.
Re: Warning! Crash in recent development builds
In article <f4a9f06654.pittdj+@iyonix.home>,
David Pitt <pittdj@pittdj.co.uk> wrote:
> In message <5466e9f50bbrian.jordan9@btinternet.com>
> Brian Jordan <brian.jordan9@btinternet.com> wrote:
> > I have discovered that attempting to complete forms rendered in 3.3
> > (Dev CI #2327) can crash NetSurf and stiff the computer. In
> > particular ists, where one selects from a list to complete the form,
> > fail to show the list and everything hangs - here anyway. Bug report
> > raised (after reverting to an earlier NetSurf to circumvent this
> > problem on the tracker).
> I have uploaded a log. On the Raspberry Pi an alt-break stopped
> NetSurf without the whole machine going down.
Here alt-break delays the agony momentarily. Pressing "Stop" in the
Window Messenger dialogue box stiffs the emulator.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
David Pitt <pittdj@pittdj.co.uk> wrote:
> In message <5466e9f50bbrian.jordan9@btinternet.com>
> Brian Jordan <brian.jordan9@btinternet.com> wrote:
> > I have discovered that attempting to complete forms rendered in 3.3
> > (Dev CI #2327) can crash NetSurf and stiff the computer. In
> > particular ists, where one selects from a list to complete the form,
> > fail to show the list and everything hangs - here anyway. Bug report
> > raised (after reverting to an earlier NetSurf to circumvent this
> > problem on the tracker).
> I have uploaded a log. On the Raspberry Pi an alt-break stopped
> NetSurf without the whole machine going down.
Here alt-break delays the agony momentarily. Pressing "Stop" in the
Window Messenger dialogue box stiffs the emulator.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
Re: Britmovie rendering
In message <0004812d.01eff490b490@smtp.freeola.net>
Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
> Hi all,
> http://www.britmovie.co.uk/
> On my Atari with build No. 2327 the line of buttons
> below the banner is rendered off to the right-hand side.
Likewise on RISC OS, #2328.
--
David Pitt
OS4.39, VRPC, iMac
Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
> Hi all,
> http://www.britmovie.co.uk/
> On my Atari with build No. 2327 the line of buttons
> below the banner is rendered off to the right-hand side.
Likewise on RISC OS, #2328.
--
David Pitt
OS4.39, VRPC, iMac
Britmovie rendering
Hi all,
http://www.britmovie.co.uk/
On my Atari with build No. 2327 the line of buttons
below the banner is rendered off to the right-hand side.
Peter
http://www.britmovie.co.uk/
On my Atari with build No. 2327 the line of buttons
below the banner is rendered off to the right-hand side.
Peter
Re: Warning! Crash in recent development builds
In message <5466e9f50bbrian.jordan9@btinternet.com>
Brian Jordan <brian.jordan9@btinternet.com> wrote:
> I have discovered that attempting to complete forms rendered in 3.3 (Dev
> CI #2327) can crash NetSurf and stiff the computer. In particular ists,
> where one selects from a list to complete the form, fail to show the list
> and everything hangs - here anyway.
> Bug report raised (after reverting to an earlier NetSurf to circumvent
> this problem on the tracker).
I have uploaded a log. On the Raspberry Pi an alt-break stopped
NetSurf without the whole machine going down.
--
David Pitt
OS4.39, VRPC, iMac
Brian Jordan <brian.jordan9@btinternet.com> wrote:
> I have discovered that attempting to complete forms rendered in 3.3 (Dev
> CI #2327) can crash NetSurf and stiff the computer. In particular ists,
> where one selects from a list to complete the form, fail to show the list
> and everything hangs - here anyway.
> Bug report raised (after reverting to an earlier NetSurf to circumvent
> this problem on the tracker).
I have uploaded a log. On the Raspberry Pi an alt-break stopped
NetSurf without the whole machine going down.
--
David Pitt
OS4.39, VRPC, iMac
Warning! Crash in recent development builds
I have discovered that attempting to complete forms rendered in 3.3 (Dev
CI #2327) can crash NetSurf and stiff the computer. In particular ists,
where one selects from a list to complete the form, fail to show the list
and everything hangs - here anyway.
Bug report raised (after reverting to an earlier NetSurf to circumvent
this problem on the tracker).
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
CI #2327) can crash NetSurf and stiff the computer. In particular ists,
where one selects from a list to complete the form, fail to show the list
and everything hangs - here anyway.
Bug report raised (after reverting to an earlier NetSurf to circumvent
this problem on the tracker).
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
Re: Error message about Possible Security Violation
Tony Moore, on 15 Nov, wrote:
> On 14 Nov 2014, David Pitt <pittdj@pittdj.co.uk> wrote:
> > Cristopher Dewhurst, on 14 Nov, wrote:
> >
> > > When searching for vacancies on this website:
>
> [snip truncated url]
>
> > > (click on the "search" button")
> > >
> > > I get an error "A possible security violation has been detected on
> > > displaying this page".
> > >
> > > Anyone know what's going on?
>
> [snip]
>
> > The URL above has been wrapped and truncated, getting dropped 'p' back
> > gives a working URL on Safari and NetSurf #2321 on the Raspberry Pi.
> >
> >
https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID=09873000Jp
>
> True, but what of the 'security violation' error message? - which I also
> see here.
I don't think it is anything too exciting, it just means 'page not found' or
'you don't have permission to be here', not logged in that is. The site
thinks it might be being hacked.
The link above is to a third party site which may be accessed via
http://www.babergh.gov.uk
--
David Pitt
> On 14 Nov 2014, David Pitt <pittdj@pittdj.co.uk> wrote:
> > Cristopher Dewhurst, on 14 Nov, wrote:
> >
> > > When searching for vacancies on this website:
>
> [snip truncated url]
>
> > > (click on the "search" button")
> > >
> > > I get an error "A possible security violation has been detected on
> > > displaying this page".
> > >
> > > Anyone know what's going on?
>
> [snip]
>
> > The URL above has been wrapped and truncated, getting dropped 'p' back
> > gives a working URL on Safari and NetSurf #2321 on the Raspberry Pi.
> >
> >
https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID=09873000Jp
>
> True, but what of the 'security violation' error message? - which I also
> see here.
I don't think it is anything too exciting, it just means 'page not found' or
'you don't have permission to be here', not logged in that is. The site
thinks it might be being hacked.
The link above is to a third party site which may be accessed via
http://www.babergh.gov.uk
--
David Pitt
Re: Error message about Possible Security Violation
On 14 Nov 2014, David Pitt <pittdj@pittdj.co.uk> wrote:
> Cristopher Dewhurst, on 14 Nov, wrote:
>
> > When searching for vacancies on this website:
[snip truncated url]
> > (click on the "search" button")
> >
> > I get an error "A possible security violation has been detected on
> > displaying this page".
> >
> > Anyone know what's going on?
[snip]
> The URL above has been wrapped and truncated, getting dropped 'p' back
> gives a working URL on Safari and NetSurf #2321 on the Raspberry Pi.
>
> https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID=09873000Jp
True, but what of the 'security violation' error message? - which I also
see here.
Tony
> Cristopher Dewhurst, on 14 Nov, wrote:
>
> > When searching for vacancies on this website:
[snip truncated url]
> > (click on the "search" button")
> >
> > I get an error "A possible security violation has been detected on
> > displaying this page".
> >
> > Anyone know what's going on?
[snip]
> The URL above has been wrapped and truncated, getting dropped 'p' back
> gives a working URL on Safari and NetSurf #2321 on the Raspberry Pi.
>
> https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID=09873000Jp
True, but what of the 'security violation' error message? - which I also
see here.
Tony
Re: Developer weekend and AGM
On Fri, Oct 10, 2014 at 10:21:00 +0100, Daniel Silverstone wrote:
> I will send a separate doodle for the AGM timing at some point today.
For various reasons, the doodle never happened so we're defaulting to
14:00 UTC for the AGM.
See you there.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> I will send a separate doodle for the AGM timing at some point today.
For various reasons, the doodle never happened so we're defaulting to
14:00 UTC for the AGM.
See you there.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Friday, 14 November 2014
Re: Error message about Possible Security Violation
Cristopher Dewhurst, on 14 Nov, wrote:
> HI all
>
> When searching for vacancies on this website:
>
>
https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID=09873000J
> p
>
> (click on the "search" button")
>
> I get an error "A possible security violation has been detected on
> displaying this page".
>
> Anyone know what's going on? I'll report it using the "Website Feedback
> Form" if it's not to do with Netsurf. (Feedback form *does* look like it
> works but haven't actually filled it out yet)
>
> thanks
The URL above has been wrapped and truncated, getting dropped 'p' back gives
a working URL on Safari and NetSurf #2321 on the Raspberry Pi.
https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID=09873000Jp
--
David Pitt
> HI all
>
> When searching for vacancies on this website:
>
>
https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID=09873000J
> p
>
> (click on the "search" button")
>
> I get an error "A possible security violation has been detected on
> displaying this page".
>
> Anyone know what's going on? I'll report it using the "Website Feedback
> Form" if it's not to do with Netsurf. (Feedback form *does* look like it
> works but haven't actually filled it out yet)
>
> thanks
The URL above has been wrapped and truncated, getting dropped 'p' back gives
a working URL on Safari and NetSurf #2321 on the Raspberry Pi.
https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID=09873000Jp
--
David Pitt
Error message about Possible Security Violation
HI all
When searching for vacancies on this website:
https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID=09873000J
p
(click on the "search" button")
I get an error "A possible security violation has been detected on
displaying this page".
Anyone know what's going on? I'll report it using the "Website
Feedback Form" if it's not to do with Netsurf. (Feedback form *does*
look like it works but haven't actually filled it out yet)
thanks
--
Chris
When searching for vacancies on this website:
https://bamscli.webitrent.com/bamscli_web/wrd/run/ETREC105GF.open?WVID=09873000J
p
(click on the "search" button")
I get an error "A possible security violation has been detected on
displaying this page".
Anyone know what's going on? I'll report it using the "Website
Feedback Form" if it's not to do with Netsurf. (Feedback form *does*
look like it works but haven't actually filled it out yet)
thanks
--
Chris
Library change
I have just split the utf8proc library out from the NetSurf utils
directory into a core conveniance library (libutf8proc).
The only impact this will have for most of us is that the env.sh
script should be updated to the latest one and "ns-clone;
ns-pull-install" run before trying to build netsurf itself.
The new libutf8proc library [1] is a simple checkin of the 1.1.6
public software group library converted to use the core library build
system. There is one additional change added which exposes the
normalise capability of the library.
In future this should allow us to update this library to new upstream
releases with a clear separation from the main NetSurf codebase.
[1] http://git.netsurf-browser.org/libutf8proc.git/
--
Regards Vincent
http://www.kyllikki.org/
directory into a core conveniance library (libutf8proc).
The only impact this will have for most of us is that the env.sh
script should be updated to the latest one and "ns-clone;
ns-pull-install" run before trying to build netsurf itself.
The new libutf8proc library [1] is a simple checkin of the 1.1.6
public software group library converted to use the core library build
system. There is one additional change added which exposes the
normalise capability of the library.
In future this should allow us to update this library to new upstream
releases with a clear separation from the main NetSurf codebase.
[1] http://git.netsurf-browser.org/libutf8proc.git/
--
Regards Vincent
http://www.kyllikki.org/
Monday, 10 November 2014
Re: RISC OS Save-as PDF file
On Mon, 10 Nov 2014 23:02:19 +0000, Vincent Sanders wrote:
> On Mon, Nov 10, 2014 at 08:04:02PM +0000, John Williams wrote:
> >
> > I noticed recently (from another posting) that (some) other platforms seem
> > to still have Save as PDF which was implemented under RISC OS and later
> > removed.
>
> The export as PDF was implemented as a core feature using a library
> called libharu. unfortunately the library has not had a new release
> since version 2.2 (several years ago) and NetSurf requires fixes that
> have never been released.
>
> This issue combined with the original author abandoning the work and
> the feature becoming broken has resulted in PDF export being
> configured off for some time now.
Further to that, I believe it also relies on the core printing API,
which has also been disabled for a long time pending (IIRC) some work
on duplicating contents.
Chris
> On Mon, Nov 10, 2014 at 08:04:02PM +0000, John Williams wrote:
> >
> > I noticed recently (from another posting) that (some) other platforms seem
> > to still have Save as PDF which was implemented under RISC OS and later
> > removed.
>
> The export as PDF was implemented as a core feature using a library
> called libharu. unfortunately the library has not had a new release
> since version 2.2 (several years ago) and NetSurf requires fixes that
> have never been released.
>
> This issue combined with the original author abandoning the work and
> the feature becoming broken has resulted in PDF export being
> configured off for some time now.
Further to that, I believe it also relies on the core printing API,
which has also been disabled for a long time pending (IIRC) some work
on duplicating contents.
Chris
Re: RISC OS Save-as PDF file
On Mon, Nov 10, 2014 at 08:04:02PM +0000, John Williams wrote:
>
> I noticed recently (from another posting) that (some) other platforms seem
> to still have Save as PDF which was implemented under RISC OS and later
> removed.
The export as PDF was implemented as a core feature using a library
called libharu. unfortunately the library has not had a new release
since version 2.2 (several years ago) and NetSurf requires fixes that
have never been released.
This issue combined with the original author abandoning the work and
the feature becoming broken has resulted in PDF export being
configured off for some time now.
Making it work once again would require a great deal of work which
no one has yet committed to doing.
>
> I was wondering about the status of this, as it seemed like a miracle at
> the time.
>
> I know we can still use the Drawfile export and print to a PDF file, but
> the direct option seemed so much more elegant!
Unless someone fixes it this feature is unlikely to ever return.
>
> John
>
> --
> | John Williams
> | johnrw@ukgateway.net
>
> Names for Soul Band:- Soul Proprietor(s) *
>
>
--
Regards Vincent
http://www.kyllikki.org/
>
> I noticed recently (from another posting) that (some) other platforms seem
> to still have Save as PDF which was implemented under RISC OS and later
> removed.
The export as PDF was implemented as a core feature using a library
called libharu. unfortunately the library has not had a new release
since version 2.2 (several years ago) and NetSurf requires fixes that
have never been released.
This issue combined with the original author abandoning the work and
the feature becoming broken has resulted in PDF export being
configured off for some time now.
Making it work once again would require a great deal of work which
no one has yet committed to doing.
>
> I was wondering about the status of this, as it seemed like a miracle at
> the time.
>
> I know we can still use the Drawfile export and print to a PDF file, but
> the direct option seemed so much more elegant!
Unless someone fixes it this feature is unlikely to ever return.
>
> John
>
> --
> | John Williams
> | johnrw@ukgateway.net
>
> Names for Soul Band:- Soul Proprietor(s) *
>
>
--
Regards Vincent
http://www.kyllikki.org/
Re: RISC OS Save-as PDF file
On 10 Nov 2014 John Williams wrote:
> I noticed recently (from another posting) that (some) other platforms seem
> to still have Save as PDF which was implemented under RISC OS and later
> removed.
> I was wondering about the status of this, as it seemed like a miracle at
> the time.
I think there's still a PDF printer driver, but I just print using
Martin W's excellent PostScript 3 driver and then use PrintPDF to
convert to PDF and optionally add metadata.
--
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.
> I noticed recently (from another posting) that (some) other platforms seem
> to still have Save as PDF which was implemented under RISC OS and later
> removed.
> I was wondering about the status of this, as it seemed like a miracle at
> the time.
I think there's still a PDF printer driver, but I just print using
Martin W's excellent PostScript 3 driver and then use PrintPDF to
convert to PDF and optionally add metadata.
--
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: RISC OS Save-as PDF file
On 10 Nov 2014 John Williams <JohnRW@ukgateway.net> wrote:
> I noticed recently (from another posting) that (some) other platforms seem
> to still have Save as PDF which was implemented under RISC OS and later
> removed.
> I was wondering about the status of this, as it seemed like a miracle at
> the time.
> I know we can still use the Drawfile export and print to a PDF file, but
> the direct option seemed so much more elegant!
Or print directly via Steve Fryatt's excellent PrintPDF?
Best wishes,
Peter.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> I noticed recently (from another posting) that (some) other platforms seem
> to still have Save as PDF which was implemented under RISC OS and later
> removed.
> I was wondering about the status of this, as it seemed like a miracle at
> the time.
> I know we can still use the Drawfile export and print to a PDF file, but
> the direct option seemed so much more elegant!
Or print directly via Steve Fryatt's excellent PrintPDF?
Best wishes,
Peter.
--
Peter Young (zfc Re) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: RISC OS Save-as PDF file
In message <546487a5a8JohnRW@ukgateway.net>
John Williams <JohnRW@ukgateway.net> wrote:
> I noticed recently (from another posting) that (some) other platforms seem
> to still have Save as PDF which was implemented under RISC OS and later
> removed.
> I was wondering about the status of this, as it seemed like a miracle at
> the time.
> I know we can still use the Drawfile export and print to a PDF file, but
> the direct option seemed so much more elegant!
> John
Was it really, by Jove? I must have missed it. Sounds a great feature
but not as important as work on Javascript, I'd say.
best wishes
Chris.
John Williams <JohnRW@ukgateway.net> wrote:
> I noticed recently (from another posting) that (some) other platforms seem
> to still have Save as PDF which was implemented under RISC OS and later
> removed.
> I was wondering about the status of this, as it seemed like a miracle at
> the time.
> I know we can still use the Drawfile export and print to a PDF file, but
> the direct option seemed so much more elegant!
> John
Was it really, by Jove? I must have missed it. Sounds a great feature
but not as important as work on Javascript, I'd say.
best wishes
Chris.
RISC OS Save-as PDF file
I noticed recently (from another posting) that (some) other platforms seem
to still have Save as PDF which was implemented under RISC OS and later
removed.
I was wondering about the status of this, as it seemed like a miracle at
the time.
I know we can still use the Drawfile export and print to a PDF file, but
the direct option seemed so much more elegant!
John
--
| John Williams
| johnrw@ukgateway.net
Names for Soul Band:- Soul Proprietor(s) *
to still have Save as PDF which was implemented under RISC OS and later
removed.
I was wondering about the status of this, as it seemed like a miracle at
the time.
I know we can still use the Drawfile export and print to a PDF file, but
the direct option seemed so much more elegant!
John
--
| John Williams
| johnrw@ukgateway.net
Names for Soul Band:- Soul Proprietor(s) *
Sunday, 9 November 2014
Re: New User - Hello to all - some Ideas concerning Netsurf for arm
Daniel Silverstone wrote
> the JS work is done by Vincent
> Sanders who is overworked and underappreciated by us all :-(
Irony intended I hope. I for one am grateful for Vincent's work on JS.
--
John Rickman - http://rickman.orpheusweb.co.uk/lynx
Tout a été dit, mais comme personne n'écoute, il faut toujours
répéter.
> the JS work is done by Vincent
> Sanders who is overworked and underappreciated by us all :-(
Irony intended I hope. I for one am grateful for Vincent's work on JS.
--
John Rickman - http://rickman.orpheusweb.co.uk/lynx
Tout a été dit, mais comme personne n'écoute, il faut toujours
répéter.
Re: quick on-off for Javascript
Jim Nagel wrote
> Brian Jordan wrote on 23 Oct (in thread "Maps"):
>> Strangely I have no black background problems here with build 3.3 (Dev
>> CI #2193) if JavaScript is disabled. If JS is enabled the page doesn't
>> render at all.
> Leads tme to ask: is there a quick way of switching Javascript on or
> off while viewing a given page?
> If not, could I make a UI suggestion?
> I recall way back when, when Fresco was attempting rudimentary
> Javascript (or Ecmascript), its toolbar had a button to toggle it on
> and off; the button also indicated the current state. Often proved
> useful, in cases like Brian cites.
plus ca change?
> > > > In message <2f9bf20d53.jim@nails.abbeypress.net> Jim Nagel
> > > > <netsurf@abbeypress.co.uk> wrote:
>
> > [snip]
>
> > > > > A wee handy-feature suggestion (if it's not a lot of
> > > > > programming effort): A "Javascript on/off button" on the
> > > > > toolbar.
--
John Rickman - http://rickman.orpheusweb.co.uk/lynx
Politics is the art of the possible, the attainable ˜ the art of the
next best - OvB
> Brian Jordan wrote on 23 Oct (in thread "Maps"):
>> Strangely I have no black background problems here with build 3.3 (Dev
>> CI #2193) if JavaScript is disabled. If JS is enabled the page doesn't
>> render at all.
> Leads tme to ask: is there a quick way of switching Javascript on or
> off while viewing a given page?
> If not, could I make a UI suggestion?
> I recall way back when, when Fresco was attempting rudimentary
> Javascript (or Ecmascript), its toolbar had a button to toggle it on
> and off; the button also indicated the current state. Often proved
> useful, in cases like Brian cites.
plus ca change?
> > > > In message <2f9bf20d53.jim@nails.abbeypress.net> Jim Nagel
> > > > <netsurf@abbeypress.co.uk> wrote:
>
> > [snip]
>
> > > > > A wee handy-feature suggestion (if it's not a lot of
> > > > > programming effort): A "Javascript on/off button" on the
> > > > > toolbar.
--
John Rickman - http://rickman.orpheusweb.co.uk/lynx
Politics is the art of the possible, the attainable ˜ the art of the
next best - OvB
Wednesday, 5 November 2014
[Rpcemu] RPCemu 0.8.12 on Mint 17 problem
I have installed 0.8.12 under Linux Mint 17, and very easy
compared to previous versions and Allegro difficulties. I took note of
the advice to use the associated files, and it was working very well
when first used. Many thanks to Peter for his hard work.
If I just load using ./812rpcemu in a root terminal, all is well,
but of course I don't get internet use. If I start by using the iptables
programme that I've used for some time now (suitably amended for the
version number) , I go through to the desktop, but get the message "Bad
opcode 14 41435452 at 20187980^ ". If I go back and restart the
iptables again, sometimes all is well, sometimes the error message. Can
anyone see where I am going wrong?
--
sent from my Acer Aspire, running Linux Mint 17.
Regards,
Philip Glover
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
compared to previous versions and Allegro difficulties. I took note of
the advice to use the associated files, and it was working very well
when first used. Many thanks to Peter for his hard work.
If I just load using ./812rpcemu in a root terminal, all is well,
but of course I don't get internet use. If I start by using the iptables
programme that I've used for some time now (suitably amended for the
version number) , I go through to the desktop, but get the message "Bad
opcode 14 41435452 at 20187980^ ". If I go back and restart the
iptables again, sometimes all is well, sometimes the error message. Can
anyone see where I am going wrong?
--
sent from my Acer Aspire, running Linux Mint 17.
Regards,
Philip Glover
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Monday, 3 November 2014
[gccsdk] New RISC OS GCC package
Is the GCCSDK trunk in a state where it would be possible to create
a new RISC OS GCC package?
I have just switch my TBX library to be cross-compiled with
the GCCSDK and realised I can't upload it as it would be
unusable for anyone who is just programming on a RISC OS
machine as it won't link with a program compiled with
GCC 4.1.2. I mix use of the cross-compiler with the native
compiler as well, so it would be helpful for me as well.
I have a virtual Ubuntu machine set up, so if the compiler
is thought to be stable enough I'm willing to do the
work of building it and creating the packages.
i.e. Checking the packaging scripts work with this release
and trying them out.
If it is OK for me to generate the packages, what would
the version numbers be?
If it's not in a sufficiently stable state, is there any idea
when it would be?
I'd rather switch to using the latest GCC on RISC OS, but
it it's a long way off, I can just go back to building it
with GCC 4.1.2.
Regards,
Alan
Sunday, 2 November 2014
NetSurf crashing when pressing 'Menu' button
A short while ago I reported a bug where, using NetSurf from version 2261
through to 2264 crashed when the 'Menu' button was pressed.
I am pleased to offer my grateful thanks, that by version 2266 the problem has
been settled.
Quick work lads and thanks :-)).
Regards Ron.
through to 2264 crashed when the 'Menu' button was pressed.
I am pleased to offer my grateful thanks, that by version 2266 the problem has
been settled.
Quick work lads and thanks :-)).
Regards Ron.
Saturday, 1 November 2014
Re: [gccsdk] gtk glib or gmodule problem
On 31/10/14 21:42, Ron wrote:
> In message <5453CF91.3030400@sky.com>
> Lee Noar <leenoar@sky.com> wrote:
>
>> On 31/10/14 01:53, Ron wrote:
>>> Can anyone say what could be causing these errors?
>>>
>>> Running a gtk2 calculater emulator I get:
>>> RISC OS error:
>>> 'has suffered a fatal internal error (Window Manager is currently in
>>> use) and must quit immediately'
>>
>> I would assume that the gtk2 program is a WIMP application, so you would
>> run it as such, ie, from an obey file that sets up the environment
>> (wimpslot, system variables, etc) and then runs the binary.
>> It sounds like you're trying to run it from a taskwindow which is I
>> believe a WIMP task and is why you get the Window Manager in use error.
>
>>
> OK, similar to the way a .sh file can manage a gcc build process.
> Using a nextslot and the *Wimptask command provides the temporary
> traceback window, but I will go the obey file route.
Sometimes, Reporter can be useful for providing 'live' debug info
while a task is running, although it wont display all the program
output, only values that you tell it to. I use these inline functions:
---8<---
/* 32 bit hex to string
* return pointer to terminating null in buffer
*/
static inline char *
hex_to_string(unsigned int v, char *buffer, int l)
{
char *term;
__asm__ volatile (" MOV r0, %1;\n"
" MOV r1, %2;\n"
" MOV r2, %3;\n"
" SWI %[os_converthex8];\n"
" MOV %0, r1;\n"
: "=r" (term)
: "r" (v), "r" (buffer), "rI" (l), [os_converthex8] "i" (0xD4)
: "a1", "a2", "a3", "cc");
return term;
}
/* Signed 32 bit integer to string
* return pointer to terminating null in buffer
*/
static inline char *
sint32_to_string(int v, char *buffer, int l)
{
char *term;
__asm__ volatile (" MOV r0, %1;\n"
" MOV r1, %2;\n"
" MOV r2, %3;\n"
" SWI %[os_convertint4];\n"
" MOV %0, r1;\n"
: "=r" (term)
: "r" (v), "r" (buffer), "rI" (l), [os_convertint4] "i" (0xDC)
: "a1", "a2", "a3", "cc");
return term;
}
static inline void report_text0(const char *s)
{
__asm__ volatile (" MOV r0, %0;\n"
" SWI %[report_text0];\n"
: /* no outputs */
: "r" (s), [report_text0] "i" (0x54C80)
: "a1", "cc");
}
static inline void report_hex(unsigned int v)
{
char buf[12];
hex_to_string(v, buf, 10);
report_text0(buf);
}
static inline void report_dec(int v)
{
char buf[20];
sint32_to_string(v, buf, 20);
report_text0(buf);
}
---8<---
You can even set the colour of the lines so that they stand out better.
If you redirect stdout/stderr to a file, sometimes you can
open and view the file while the program is running (it's a snapshot
rather than a live update), but I think that depends on the filing
system; possibly it only works on hostfs in rpcemu.
>>> And then the TaskWindow outputs:
>>> Using 'dlopen' requires dynamic linking: Success
>>
>> Are you static linking? dlopen doesn't work in static binaries; you have
>> to use dynamic linking. When static linking, the dlopen, dlsym and
>> dlclose functions are dummy versions that return an error like the one
>> above.
>>
>>> (free42bin:134785469): GModule-CRITICAL **: g_module_symbol: assertion
>>> `module != NULL' failed
>> >
>>> (free42bin:134785469): GModule-CRITICAL **: g_module_close: assertion `module != NULL' failed
>>
>> These are the result of dlopen failing.
>>
>>> I've tried a few things in the makefile, but always the same errors.
>>
>> If your program needs to load libraries at runtime using dlopen, then
>> dynamic linking is required.
>>
>> Lee.
>>
>
> Yes everything is /supposed/ to be static.
Do you mean that the project needs to be statically linked for some
reason?
> I'll try --disable-shared on my top level program, before delving into
> the autobuilder libraries. I think it is possible to do a non static
> build with .a libs so just removing .so libs wouldn't serve as a
> safeguard, but it would be nice to have confirmation.
> Somewhere a ldd command was mentioned as showing info.
>
> The libglib2.0 manual sort of says that dlopen() can will be used
> internally for loading modules when statically linking. Maybe this is
> the dummy versions you speak of.
The dummy versions are in the GCCSDK source tree here:
gcc4/riscos/soloader/dynamic/ld.so-1.9.9/d-link/libdl/static.c
When I said that dlopen requires dynamic linking, I meant under
RISC OS specifically. It may well be possible to use it in static
programs under Linux, but I couldn't see how it would work.
Under RISC OS, dynamically linked programs and shared libraries are
registered by SOManager at runtime. That way if you try to dlopen
a library that is already in use, the system will know and use the
copy it already has loaded. That applies to its dependencies as well.
Statically linked binaries are not registered at all. In theory, if
your binary was statically linked against Unixlib and you dlopen a
library that is dynamically linked to Unixlib, then the system will
load Unixlib and you would now have 2 versions with separate data
sections. If you dlopen a library that requires gtk2 (for example),
then again you have a conflict between the version statically linked to
the binary and the shared version loaded by dlopen, not to mention the
dependencies that would be loaded that may also be statically linked
to the binary. It would be quite wasteful of memory too.
So it all gets a bit messy. In the end I decided that if dlopen was
required, then it was easier to just use dynamic linking.
> In the autobuilder, The symbol
> underscore variable was set 'on', which corresponds with 'system
> supports dlopen()/dlsym()'.
AFAIK, the Autobuilder checks if RO_SHAREDLIBS is set to yes and if so
tells configure that dlfcn.h exists and that dlopen is therefore
supported. If RO_SHAREDLIBS is set to no, then Autobuilder sets some
variables that tell configure that dlopen is not supported.
So for dynamic linking you need 'RO_SHAREDLIBS=yes' somewhere, either
at the top of your setvars for that particular package or in a file
called build-setvars in the root of your autobuilder build directory
for all packages.
> The other (maybe unnecessary) complication is that libtdl can be used
> to get dlopen() functionality in static libs,
> It needs initialising in the source somewhere and the linker command
> line has -dlopen 'modulename' added.
>
> Should libtdl be necessary, or what is this 'internal dynamic linking'
> aimed at doing?
libtdl is I believe merely a wrapper around dlopen, dlsym and dlclose
under Linux and their equivalent on other systems, the idea being to
present a consistent interface for all systems. So you still
require an implementation of dlopen, etc. If you dump its symbols with
'nm -Dn', you'll see that dlopen is listed as undefined. Also
'readelf -d' shows libdl as a dynamic dependency.
If you can go the dynamic linking route, then that is the much easier
option; dlopen works well then.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> In message <5453CF91.3030400@sky.com>
> Lee Noar <leenoar@sky.com> wrote:
>
>> On 31/10/14 01:53, Ron wrote:
>>> Can anyone say what could be causing these errors?
>>>
>>> Running a gtk2 calculater emulator I get:
>>> RISC OS error:
>>> 'has suffered a fatal internal error (Window Manager is currently in
>>> use) and must quit immediately'
>>
>> I would assume that the gtk2 program is a WIMP application, so you would
>> run it as such, ie, from an obey file that sets up the environment
>> (wimpslot, system variables, etc) and then runs the binary.
>> It sounds like you're trying to run it from a taskwindow which is I
>> believe a WIMP task and is why you get the Window Manager in use error.
>
>>
> OK, similar to the way a .sh file can manage a gcc build process.
> Using a nextslot and the *Wimptask command provides the temporary
> traceback window, but I will go the obey file route.
Sometimes, Reporter can be useful for providing 'live' debug info
while a task is running, although it wont display all the program
output, only values that you tell it to. I use these inline functions:
---8<---
/* 32 bit hex to string
* return pointer to terminating null in buffer
*/
static inline char *
hex_to_string(unsigned int v, char *buffer, int l)
{
char *term;
__asm__ volatile (" MOV r0, %1;\n"
" MOV r1, %2;\n"
" MOV r2, %3;\n"
" SWI %[os_converthex8];\n"
" MOV %0, r1;\n"
: "=r" (term)
: "r" (v), "r" (buffer), "rI" (l), [os_converthex8] "i" (0xD4)
: "a1", "a2", "a3", "cc");
return term;
}
/* Signed 32 bit integer to string
* return pointer to terminating null in buffer
*/
static inline char *
sint32_to_string(int v, char *buffer, int l)
{
char *term;
__asm__ volatile (" MOV r0, %1;\n"
" MOV r1, %2;\n"
" MOV r2, %3;\n"
" SWI %[os_convertint4];\n"
" MOV %0, r1;\n"
: "=r" (term)
: "r" (v), "r" (buffer), "rI" (l), [os_convertint4] "i" (0xDC)
: "a1", "a2", "a3", "cc");
return term;
}
static inline void report_text0(const char *s)
{
__asm__ volatile (" MOV r0, %0;\n"
" SWI %[report_text0];\n"
: /* no outputs */
: "r" (s), [report_text0] "i" (0x54C80)
: "a1", "cc");
}
static inline void report_hex(unsigned int v)
{
char buf[12];
hex_to_string(v, buf, 10);
report_text0(buf);
}
static inline void report_dec(int v)
{
char buf[20];
sint32_to_string(v, buf, 20);
report_text0(buf);
}
---8<---
You can even set the colour of the lines so that they stand out better.
If you redirect stdout/stderr to a file, sometimes you can
open and view the file while the program is running (it's a snapshot
rather than a live update), but I think that depends on the filing
system; possibly it only works on hostfs in rpcemu.
>>> And then the TaskWindow outputs:
>>> Using 'dlopen' requires dynamic linking: Success
>>
>> Are you static linking? dlopen doesn't work in static binaries; you have
>> to use dynamic linking. When static linking, the dlopen, dlsym and
>> dlclose functions are dummy versions that return an error like the one
>> above.
>>
>>> (free42bin:134785469): GModule-CRITICAL **: g_module_symbol: assertion
>>> `module != NULL' failed
>> >
>>> (free42bin:134785469): GModule-CRITICAL **: g_module_close: assertion `module != NULL' failed
>>
>> These are the result of dlopen failing.
>>
>>> I've tried a few things in the makefile, but always the same errors.
>>
>> If your program needs to load libraries at runtime using dlopen, then
>> dynamic linking is required.
>>
>> Lee.
>>
>
> Yes everything is /supposed/ to be static.
Do you mean that the project needs to be statically linked for some
reason?
> I'll try --disable-shared on my top level program, before delving into
> the autobuilder libraries. I think it is possible to do a non static
> build with .a libs so just removing .so libs wouldn't serve as a
> safeguard, but it would be nice to have confirmation.
> Somewhere a ldd command was mentioned as showing info.
>
> The libglib2.0 manual sort of says that dlopen() can will be used
> internally for loading modules when statically linking. Maybe this is
> the dummy versions you speak of.
The dummy versions are in the GCCSDK source tree here:
gcc4/riscos/soloader/dynamic/ld.so-1.9.9/d-link/libdl/static.c
When I said that dlopen requires dynamic linking, I meant under
RISC OS specifically. It may well be possible to use it in static
programs under Linux, but I couldn't see how it would work.
Under RISC OS, dynamically linked programs and shared libraries are
registered by SOManager at runtime. That way if you try to dlopen
a library that is already in use, the system will know and use the
copy it already has loaded. That applies to its dependencies as well.
Statically linked binaries are not registered at all. In theory, if
your binary was statically linked against Unixlib and you dlopen a
library that is dynamically linked to Unixlib, then the system will
load Unixlib and you would now have 2 versions with separate data
sections. If you dlopen a library that requires gtk2 (for example),
then again you have a conflict between the version statically linked to
the binary and the shared version loaded by dlopen, not to mention the
dependencies that would be loaded that may also be statically linked
to the binary. It would be quite wasteful of memory too.
So it all gets a bit messy. In the end I decided that if dlopen was
required, then it was easier to just use dynamic linking.
> In the autobuilder, The symbol
> underscore variable was set 'on', which corresponds with 'system
> supports dlopen()/dlsym()'.
AFAIK, the Autobuilder checks if RO_SHAREDLIBS is set to yes and if so
tells configure that dlfcn.h exists and that dlopen is therefore
supported. If RO_SHAREDLIBS is set to no, then Autobuilder sets some
variables that tell configure that dlopen is not supported.
So for dynamic linking you need 'RO_SHAREDLIBS=yes' somewhere, either
at the top of your setvars for that particular package or in a file
called build-setvars in the root of your autobuilder build directory
for all packages.
> The other (maybe unnecessary) complication is that libtdl can be used
> to get dlopen() functionality in static libs,
> It needs initialising in the source somewhere and the linker command
> line has -dlopen 'modulename' added.
>
> Should libtdl be necessary, or what is this 'internal dynamic linking'
> aimed at doing?
libtdl is I believe merely a wrapper around dlopen, dlsym and dlclose
under Linux and their equivalent on other systems, the idea being to
present a consistent interface for all systems. So you still
require an implementation of dlopen, etc. If you dump its symbols with
'nm -Dn', you'll see that dlopen is listed as undefined. Also
'readelf -d' shows libdl as a dynamic dependency.
If you can go the dynamic linking route, then that is the much easier
option; dlopen works well then.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Subscribe to:
Posts (Atom)