In article <17bd023054.cris@cdewhurst2010.btinternet.com>,
Christopher Dewhurst <cdewhurst2010@btinternet.com> wrote:
> Hi all,
> Have just uploaded a .ZIP file and needed to test I have the right URL
> to give out to people so I tried pointing to it with Netsurf (typing
> in the full URL) but it's complaining "Unacceptable Type".
> This doesn't seem to happen with other browsers/platforms (where said
> Zipfile downloads OK).
> Have looked for documentation on this error but to no avail.
> Is it something I am doing wrong with Netsurf ?
> #2040 on Raspberry Pi RO 5.21
> thanks
Not much help in solving your problem, but FWIW.
Netsurf #2041 on RO 6.20 works correctly when pointed at .zip file URLs I
have.
Dave
--
Dave Triffid
Thursday, 31 July 2014
Re: Unacceptable Type
On 31/07/14 21:29, Christopher Dewhurst wrote:
> Is it something I am doing wrong with Netsurf ?
Without being able to try the URL in question, I'm unable to say.
Possibly it's a NetSurf bug, but we can't do much without the means to
reproduce it.
--
Michael Drake http://www.netsurf-browser.org/
> Is it something I am doing wrong with Netsurf ?
Without being able to try the URL in question, I'm unable to say.
Possibly it's a NetSurf bug, but we can't do much without the means to
reproduce it.
--
Michael Drake http://www.netsurf-browser.org/
Unacceptable Type
Hi all,
Have just uploaded a .ZIP file and needed to test I have the right URL
to give out to people so I tried pointing to it with Netsurf (typing
in the full URL) but it's complaining "Unacceptable Type".
This doesn't seem to happen with other browsers/platforms (where said
Zipfile downloads OK).
Have looked for documentation on this error but to no avail.
Is it something I am doing wrong with Netsurf ?
#2040 on Raspberry Pi RO 5.21
thanks
--
Chris
Have just uploaded a .ZIP file and needed to test I have the right URL
to give out to people so I tried pointing to it with Netsurf (typing
in the full URL) but it's complaining "Unacceptable Type".
This doesn't seem to happen with other browsers/platforms (where said
Zipfile downloads OK).
Have looked for documentation on this error but to no avail.
Is it something I am doing wrong with Netsurf ?
#2040 on Raspberry Pi RO 5.21
thanks
--
Chris
Monday, 28 July 2014
★ Artur napisał do Ciebie wiadomość
Artur napisał do Ciebie wiadomośćNadawca i treść wiadomości będą widoczne tylko dla Ciebie i możesz je skasować w każdej chwili. Możesz odpisać na wiadomość używając komunikatora. Jeśli chcesz przeczytać wiadomość, kliknij ten link:
Ten e-mail jest częścią procesu dostarczania wiadomości od użytkownika Artur. Jeśli otrzymałeś ten e-mail przez pomyłkę, po prostu go zignoruj. W najbliższym czasie wiadomość zostanie usunięta Dziękujemy, Zespół Badoo  Otrzymałeś ten e-mail od Badoo Trading Limited (adres korespondencyjny znajduje się poniżej). Jeśli nie chcesz otrzymywać więcej wiadomości od Badoo, prosimy kliknąć tutaj, aby zrezygnować. |
Re: Stack usage
On 28/07/14 18:29, Chris Young wrote:
> My hunch is that either libdom or libcss are the culprit, rather than
> NetSurf itself. I think the extra crashing (due to stack usage) I
> spotted coincided with a big libdom merge, although that could well
> not be related.
There's a bug for this with some details here:
http://bugs.netsurf-browser.org/mantis/view.php?id=2177
--
Michael Drake http://www.smoothartist.com/
> My hunch is that either libdom or libcss are the culprit, rather than
> NetSurf itself. I think the extra crashing (due to stack usage) I
> spotted coincided with a big libdom merge, although that could well
> not be related.
There's a bug for this with some details here:
http://bugs.netsurf-browser.org/mantis/view.php?id=2177
--
Michael Drake http://www.smoothartist.com/
Re: Stack usage
On Sun, 27 Jul 2014 23:23:12 +0100, Vincent Sanders wrote:
> On Sat, Jul 26, 2014 at 01:22:01AM +0100, Chris Young wrote:
> > I have just discovered that
> > http://git.netsurf-browser.org/netsurf.git/tree/amiga/gui.c is using
> > ~450K of stack space.
> >
> > Visiting
> > http://libxad.cvs.sourceforge.net/viewvc/libxad/libxad/portable/clients/LhA.c?view=markup
> > uses just short of 1MB of stack.
> >
>
> well that would seem to be excessive on any scale!
>
> > I don't know about the second link, but I'm sure it wasn't that long
> > ago when the top link was viewable in 256K of stack or maybe even
> > 128K.
>
> I would have expected 64k or so at most but analysis of stack usage
> seems to be somewhat difficult.
I'm using a tool which shows me the maximum stack usage up to that
point. So I can only see when something has gone over, but not what.
> I have done an experiment with the gtk frontend which you migth want
> to do for amiga.
>
> add -fstack-usage to your CFLAGS in your Makefile.target and recompile
> from clean (needs gcc 4.6 or later) though this seems to interact
> badly with ccache so I just commented it out in netsurfs Makefile
> (line 307)
I'm using gcc 4.7.2, but it doesn't seem to like that option.
> most of which does not seem exsessive (aside from urldb, which we
> already know "as a project" smells bad)
>
> so assuming amiga gets similar output I must conclude eiher we are
> recursing somewhere or something is dynamicaly allocating to the stack
> where it should not.
My hunch is that either libdom or libcss are the culprit, rather than
NetSurf itself. I think the extra crashing (due to stack usage) I
spotted coincided with a big libdom merge, although that could well
not be related.
Chris
> On Sat, Jul 26, 2014 at 01:22:01AM +0100, Chris Young wrote:
> > I have just discovered that
> > http://git.netsurf-browser.org/netsurf.git/tree/amiga/gui.c is using
> > ~450K of stack space.
> >
> > Visiting
> > http://libxad.cvs.sourceforge.net/viewvc/libxad/libxad/portable/clients/LhA.c?view=markup
> > uses just short of 1MB of stack.
> >
>
> well that would seem to be excessive on any scale!
>
> > I don't know about the second link, but I'm sure it wasn't that long
> > ago when the top link was viewable in 256K of stack or maybe even
> > 128K.
>
> I would have expected 64k or so at most but analysis of stack usage
> seems to be somewhat difficult.
I'm using a tool which shows me the maximum stack usage up to that
point. So I can only see when something has gone over, but not what.
> I have done an experiment with the gtk frontend which you migth want
> to do for amiga.
>
> add -fstack-usage to your CFLAGS in your Makefile.target and recompile
> from clean (needs gcc 4.6 or later) though this seems to interact
> badly with ccache so I just commented it out in netsurfs Makefile
> (line 307)
I'm using gcc 4.7.2, but it doesn't seem to like that option.
> most of which does not seem exsessive (aside from urldb, which we
> already know "as a project" smells bad)
>
> so assuming amiga gets similar output I must conclude eiher we are
> recursing somewhere or something is dynamicaly allocating to the stack
> where it should not.
My hunch is that either libdom or libcss are the culprit, rather than
NetSurf itself. I think the extra crashing (due to stack usage) I
spotted coincided with a big libdom merge, although that could well
not be related.
Chris
Saturday, 26 July 2014
Hide address bar
Hello,
I use netsurf in framebuffer, and search to not display the address bar,
is this a way to hide it in a configuration file?
And if yes, what is the name of the configuration file.
Best Regards,
Nicolas de Marqué
I use netsurf in framebuffer, and search to not display the address bar,
is this a way to hide it in a configuration file?
And if yes, what is the name of the configuration file.
Best Regards,
Nicolas de Marqué
Friday, 25 July 2014
Stack usage
I have just discovered that
http://git.netsurf-browser.org/netsurf.git/tree/amiga/gui.c is using
~450K of stack space.
Visiting
http://libxad.cvs.sourceforge.net/viewvc/libxad/libxad/portable/clients/LhA.c?view=markup
uses just short of 1MB of stack.
I don't know about the second link, but I'm sure it wasn't that long
ago when the top link was viewable in 256K of stack or maybe even
128K.
I doubt much can be done about it, but am curious as to what has
changed to increase stack usage this much?
Whilst NetSurf is usually pretty good at not going mad with the stack
(it usually sits at <64K), suddenly using 1MB on certain pages seems a
bit excessive.
Chris
http://git.netsurf-browser.org/netsurf.git/tree/amiga/gui.c is using
~450K of stack space.
Visiting
http://libxad.cvs.sourceforge.net/viewvc/libxad/libxad/portable/clients/LhA.c?view=markup
uses just short of 1MB of stack.
I don't know about the second link, but I'm sure it wasn't that long
ago when the top link was viewable in 256K of stack or maybe even
128K.
I doubt much can be done about it, but am curious as to what has
changed to increase stack usage this much?
Whilst NetSurf is usually pretty good at not going mad with the stack
(it usually sits at <64K), suddenly using 1MB on certain pages seems a
bit excessive.
Chris
Tuesday, 22 July 2014
Re: Selecting text gone crazy
On 22 Jul 2014 Richard Porter wrote:
> On 22 Jul 2014 John Rickman Iyonix wrote:
>> #2023 when I try to select some text as soon as I click on the page
>> everything from the click to the end of the article is highlit.
> Yes, I've raised a bug report. It happens in spades in The Register.
See bug report 2144.
--
Richard Porter http://www.minijem.plus.com/
Skype: minijem2 mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
> On 22 Jul 2014 John Rickman Iyonix wrote:
>> #2023 when I try to select some text as soon as I click on the page
>> everything from the click to the end of the article is highlit.
> Yes, I've raised a bug report. It happens in spades in The Register.
See bug report 2144.
--
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: Selecting text gone crazy
On 22 Jul 2014 John Rickman Iyonix wrote:
> #2023 when I try to select some text as soon as I click on the page
> everything from the click to the end of the article is highlit.
> This has been happening since at least #1980
> Is anyone else seeing this?
> (Iyonix RISC OS 5.21 9 July)
Yes, I've raised a bug report. It happens in spades in The Register.
--
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.
> #2023 when I try to select some text as soon as I click on the page
> everything from the click to the end of the article is highlit.
> This has been happening since at least #1980
> Is anyone else seeing this?
> (Iyonix RISC OS 5.21 9 July)
Yes, I've raised a bug report. It happens in spades in The Register.
--
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: Selecting text gone crazy
Dave Higton wrote
> Fred Bambrough <netsurf@ypical-daemon.co.uk> wrote:
>> John Rickman Iyonix <rickman@argonet.co.uk> wrote:
>>
>>> #2023 when I try to select some text as soon as I click on the page
>>> everything from the click to the end of the article is highlit.
>>> This has been happening since at least #1980
>>> Is anyone else seeing this?
>>> (Iyonix RISC OS 5.21 9 July)
>>
>>Same here. BB -xM RISC OS 5.21 21 July NS 1024
> I've had this sometimes, but I can't guarantee to be able to reproduce
> the symptoms. I agree that it started to happen a few weeks ago.
In this link - http://en.wikipedia.org/wiki/RISC_OS
clicking on the bold "RISC OS" at the start of the article reproduces
the symptoms. Ie everything is selected with one click.
If you click in the body of the text there is no problem. It seems to
be headings that go wrong. Eg the word "History", "Supported hardware"
"RISC OS Compatible", etc after the contents list.
John
--
John Rickman - http://rickman.orpheusweb.co.uk/lynx
For ye have the poor always with you; but me ye have not always.
> Fred Bambrough <netsurf@ypical-daemon.co.uk> wrote:
>> John Rickman Iyonix <rickman@argonet.co.uk> wrote:
>>
>>> #2023 when I try to select some text as soon as I click on the page
>>> everything from the click to the end of the article is highlit.
>>> This has been happening since at least #1980
>>> Is anyone else seeing this?
>>> (Iyonix RISC OS 5.21 9 July)
>>
>>Same here. BB -xM RISC OS 5.21 21 July NS 1024
> I've had this sometimes, but I can't guarantee to be able to reproduce
> the symptoms. I agree that it started to happen a few weeks ago.
In this link - http://en.wikipedia.org/wiki/RISC_OS
clicking on the bold "RISC OS" at the start of the article reproduces
the symptoms. Ie everything is selected with one click.
If you click in the body of the text there is no problem. It seems to
be headings that go wrong. Eg the word "History", "Supported hardware"
"RISC OS Compatible", etc after the contents list.
John
--
John Rickman - http://rickman.orpheusweb.co.uk/lynx
For ye have the poor always with you; but me ye have not always.
Re: Selecting text gone crazy
In message <mpro.n94rp6003uaoa021j.netsurf@ypical-daemon.co.uk>
Fred Bambrough <netsurf@ypical-daemon.co.uk> wrote:
>In message <f873582b54.iyojohn@rickman.argonet.co.uk>
> John Rickman Iyonix <rickman@argonet.co.uk> wrote:
>
>> #2023 when I try to select some text as soon as I click on the page
>> everything from the click to the end of the article is highlit.
>>
>> This has been happening since at least #1980
>>
>> Is anyone else seeing this?
>>
>> (Iyonix RISC OS 5.21 9 July)
>>
>
>Same here. BB -xM RISC OS 5.21 21 July NS 1024
I've had this sometimes, but I can't guarantee to be able to reproduce
the symptoms. I agree that it started to happen a few weeks ago.
Dave
____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!
Fred Bambrough <netsurf@ypical-daemon.co.uk> wrote:
>In message <f873582b54.iyojohn@rickman.argonet.co.uk>
> John Rickman Iyonix <rickman@argonet.co.uk> wrote:
>
>> #2023 when I try to select some text as soon as I click on the page
>> everything from the click to the end of the article is highlit.
>>
>> This has been happening since at least #1980
>>
>> Is anyone else seeing this?
>>
>> (Iyonix RISC OS 5.21 9 July)
>>
>
>Same here. BB -xM RISC OS 5.21 21 July NS 1024
I've had this sometimes, but I can't guarantee to be able to reproduce
the symptoms. I agree that it started to happen a few weeks ago.
Dave
____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!
Re: Selecting text gone crazy
In message <f873582b54.iyojohn@rickman.argonet.co.uk>
John Rickman Iyonix <rickman@argonet.co.uk> wrote:
>#2023 when I try to select some text as soon as I click on the page
>everything from the click to the end of the article is highlit.
>
>This has been happening since at least #1980
>
>Is anyone else seeing this?
>
>(Iyonix 9 July)
No, a click deselects, for me. Hard to select in the first place.
(Rpi RC12 RISC OS 22 July)
--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/
John Rickman Iyonix <rickman@argonet.co.uk> wrote:
>#2023 when I try to select some text as soon as I click on the page
>everything from the click to the end of the article is highlit.
>
>This has been happening since at least #1980
>
>Is anyone else seeing this?
>
>(Iyonix 9 July)
No, a click deselects, for me. Hard to select in the first place.
(Rpi RC12 RISC OS 22 July)
--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/
Re: Selecting text gone crazy
In message <f873582b54.iyojohn@rickman.argonet.co.uk>
John Rickman Iyonix <rickman@argonet.co.uk> wrote:
> #2023 when I try to select some text as soon as I click on the page
> everything from the click to the end of the article is highlit.
>
> This has been happening since at least #1980
>
> Is anyone else seeing this?
>
> (Iyonix RISC OS 5.21 9 July)
>
Same here. BB -xM RISC OS 5.21 21 July NS 1024
John Rickman Iyonix <rickman@argonet.co.uk> wrote:
> #2023 when I try to select some text as soon as I click on the page
> everything from the click to the end of the article is highlit.
>
> This has been happening since at least #1980
>
> Is anyone else seeing this?
>
> (Iyonix RISC OS 5.21 9 July)
>
Same here. BB -xM RISC OS 5.21 21 July NS 1024
Selecting text gone crazy
#2023 when I try to select some text as soon as I click on the page
everything from the click to the end of the article is highlit.
This has been happening since at least #1980
Is anyone else seeing this?
(Iyonix RISC OS 5.21 9 July)
--
John Rickman - http://rickman.orpheusweb.co.uk/lynx
everything from the click to the end of the article is highlit.
This has been happening since at least #1980
Is anyone else seeing this?
(Iyonix RISC OS 5.21 9 July)
--
John Rickman - http://rickman.orpheusweb.co.uk/lynx
Monday, 21 July 2014
Re: Libhubbub status
On Mon, 21 Jul 2014 19:58:01 +0530, Rupinder Singh wrote:
> Intel on this will be greatly appreciated:
>
> http://wiki.netsurf-browser.org/LibHubbub
I'm not really qualified to respond to this, so take anything I say
with a bucket of salt, but I think:
#3 (slowdown due to strndup) might be solved by using libwapcaplet, as
that's the sort of thing it was designed for - although I suspect
that'll mean changing hubbub to use lwc_strings throughout, which
isn't a quick job (and there may be good reasons for not doing this).
#7 (auto-detect document encoding) sounds like something which should
be handled by libparserutils, although AFAIK it doesn't have the
ability to do it currently.
Chris
> Intel on this will be greatly appreciated:
>
> http://wiki.netsurf-browser.org/LibHubbub
I'm not really qualified to respond to this, so take anything I say
with a bucket of salt, but I think:
#3 (slowdown due to strndup) might be solved by using libwapcaplet, as
that's the sort of thing it was designed for - although I suspect
that'll mean changing hubbub to use lwc_strings throughout, which
isn't a quick job (and there may be good reasons for not doing this).
#7 (auto-detect document encoding) sounds like something which should
be handled by libparserutils, although AFAIK it doesn't have the
ability to do it currently.
Chris
Saturday, 19 July 2014
[gccsdk] [Bug 256] New: GCC 4.7.4 Rel 1 Dev 2014-05-29: C++ exceptions failure
http://www.riscos.info/bugzilla3/show_bug.cgi?id=256
Summary: GCC 4.7.4 Rel 1 Dev 2014-05-29: C++ exceptions failure
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: C++ compiler
AssignedTo: John.Tytgat@aaug.net
ReportedBy: duncan.moore@gmx.com
Estimated Hours: 0.0
gcc (GCCSDK GCC 4.7.4 Release 1 Development) 4.7.4 20140529 (prerelease)
[gcc-4_7-branch revision 211052]
SharedUnixLibrary 1.12
VirtualRPC-Adjust RISCOS 4.39, ARM 710
With this program:
#include <iostream>
int main(void) {
try {
throw 5;
}
catch (int i) {
std::cout << "caught " << i << std::endl;
}
return 0;
}
I get:
*g++ exceptions.cc
*a/out
terminate called after throwing an instance of 'int'
terminate called recursively
Fatal signal received: Aborted
Stack backtrace:
Running thread 0x1eb80
( 1006e88) pc: 24aff10 lr: 24b0324 sp: 1006e8c __write_backtrace()
( 1006ef4) pc: 24b0058 lr: 24b086c sp: 1006ef8 __unixlib_raise_signal()
( 1006f04) pc: 24b0844 lr: 24bc9e4 sp: 1006f08 raise()
( 1006f18) pc: 24bc998 lr: 2370b80 sp: 1006f1c abort()
( 1006f3c) pc: 2370a8c lr: 236d3dc sp: 1006f40
__gnu_cxx::__verbose_terminate_handler()()
( 1006f4c) pc: 236d3cc lr: 236d444 sp: 1006f50
__cxxabiv1::__terminate(void (*)())()
( 1006f94) pc: 2370a8c lr: 236d3dc sp: 1006f98
__gnu_cxx::__verbose_terminate_handler()()
( 1006fa4) pc: 236d3cc lr: 236d444 sp: 1006fa8
__cxxabiv1::__terminate(void (*)())()
( 1006fec) pc: 8af8 lr: 24c6ac8 sp: 1006ff0 main()
*
With gcc 4.1.2 I get, as expected:
*a/out
caught 5
*
--
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
Summary: GCC 4.7.4 Rel 1 Dev 2014-05-29: C++ exceptions failure
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: C++ compiler
AssignedTo: John.Tytgat@aaug.net
ReportedBy: duncan.moore@gmx.com
Estimated Hours: 0.0
gcc (GCCSDK GCC 4.7.4 Release 1 Development) 4.7.4 20140529 (prerelease)
[gcc-4_7-branch revision 211052]
SharedUnixLibrary 1.12
VirtualRPC-Adjust RISCOS 4.39, ARM 710
With this program:
#include <iostream>
int main(void) {
try {
throw 5;
}
catch (int i) {
std::cout << "caught " << i << std::endl;
}
return 0;
}
I get:
*g++ exceptions.cc
*a/out
terminate called after throwing an instance of 'int'
terminate called recursively
Fatal signal received: Aborted
Stack backtrace:
Running thread 0x1eb80
( 1006e88) pc: 24aff10 lr: 24b0324 sp: 1006e8c __write_backtrace()
( 1006ef4) pc: 24b0058 lr: 24b086c sp: 1006ef8 __unixlib_raise_signal()
( 1006f04) pc: 24b0844 lr: 24bc9e4 sp: 1006f08 raise()
( 1006f18) pc: 24bc998 lr: 2370b80 sp: 1006f1c abort()
( 1006f3c) pc: 2370a8c lr: 236d3dc sp: 1006f40
__gnu_cxx::__verbose_terminate_handler()()
( 1006f4c) pc: 236d3cc lr: 236d444 sp: 1006f50
__cxxabiv1::__terminate(void (*)())()
( 1006f94) pc: 2370a8c lr: 236d3dc sp: 1006f98
__gnu_cxx::__verbose_terminate_handler()()
( 1006fa4) pc: 236d3cc lr: 236d444 sp: 1006fa8
__cxxabiv1::__terminate(void (*)())()
( 1006fec) pc: 8af8 lr: 24c6ac8 sp: 1006ff0 main()
*
With gcc 4.1.2 I get, as expected:
*a/out
caught 5
*
--
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
[gccsdk] [Bug 255] New: GCC 4.7.4 Rel 1 Dev 2014-05-29: infinite loop with level 2 optimisation
http://www.riscos.info/bugzilla3/show_bug.cgi?id=255
Summary: GCC 4.7.4 Rel 1 Dev 2014-05-29: infinite loop with
level 2 optimisation
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: C compiler
AssignedTo: John.Tytgat@aaug.net
ReportedBy: duncan.moore@gmx.com
Estimated Hours: 0.0
gcc (GCCSDK GCC 4.7.4 Release 1 Development) 4.7.4 20140529 (prerelease)
[gcc-4_7-branch revision 211052]
SharedUnixLibrary 1.12
VirtualRPC-Adjust RISCOS 4.39, ARM 710
I've previously reported this problem on the GCC mailing list (thread "GCC
4.7.4 Rel 1 Dev 2014-01-08: initial comments and feedback" starting 2014-02-27,
where there's more information), but thought I'd put it in the bug tracking
system so it doesn't get forgotten.
With this program:
#include <stdio.h>
int main(void) {
int i;
for (i=0;i<6;++i)
printf("%i\n",i);
return 0;
}
I get an infinite loop with -O2 optimisation:
*gcc abc.c -O2
*a/out
0
1
2
3
4
5
6
7
8
9
10
11
12
etc
With -O1 or -O3 optimisation, it works properly and just prints the integers 0
to 5.
As far as I know, no one else has been able to reproduce this.
--
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
Summary: GCC 4.7.4 Rel 1 Dev 2014-05-29: infinite loop with
level 2 optimisation
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: C compiler
AssignedTo: John.Tytgat@aaug.net
ReportedBy: duncan.moore@gmx.com
Estimated Hours: 0.0
gcc (GCCSDK GCC 4.7.4 Release 1 Development) 4.7.4 20140529 (prerelease)
[gcc-4_7-branch revision 211052]
SharedUnixLibrary 1.12
VirtualRPC-Adjust RISCOS 4.39, ARM 710
I've previously reported this problem on the GCC mailing list (thread "GCC
4.7.4 Rel 1 Dev 2014-01-08: initial comments and feedback" starting 2014-02-27,
where there's more information), but thought I'd put it in the bug tracking
system so it doesn't get forgotten.
With this program:
#include <stdio.h>
int main(void) {
int i;
for (i=0;i<6;++i)
printf("%i\n",i);
return 0;
}
I get an infinite loop with -O2 optimisation:
*gcc abc.c -O2
*a/out
0
1
2
3
4
5
6
7
8
9
10
11
12
etc
With -O1 or -O3 optimisation, it works properly and just prints the integers 0
to 5.
As far as I know, no one else has been able to reproduce this.
--
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
Monday, 14 July 2014
Re: Fwd: libhubbub: branch rupindersingh/libhubbub updated. release/0.3.0-30-g1b8977f
On Mon, Jul 14, 2014 at 09:11:05PM +0530, Rupinder Singh wrote:
> On Sat, Jul 12, 2014 at 10:47:48PM +0100, NetSurf Browser Project wrote:
>
> > I don't understand this changeset. Why have you exposed the tokeniser's
> > internal state to the outside world? It is extremely dangerous to do
> > this, as it makes it utterly unclear what triggers a state transition.
> > Additionally, only the tokeniser needs to know what state it is in; the
> > client of the tokeniser must treat it as a black box.
> >
>
> > I had the same concerns. Wanted to, but couldn't discuss it earlier. I
> did it as the specs say that the treebuilder must change tokeniser's state
> here, under "script" start tag, step 7.
> http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inhead
> .. There can be workarounds to avoid this. Please suggest some, or I'll try
> to work out some.
Well, the existing precedent for this kind of thing is the tokeniser's
content model, or the pause flag. Essentially, hubbub_tokeniser_setopt
is used to inject configuration into the tokeniser, which it is
perfectly at liberty to ignore, if it wants. The point here is that the
injection of configuration is a *request* to do something, which allows
the internals of the tokeniser to be kept private from its client.
J.
> On Sat, Jul 12, 2014 at 10:47:48PM +0100, NetSurf Browser Project wrote:
>
> > I don't understand this changeset. Why have you exposed the tokeniser's
> > internal state to the outside world? It is extremely dangerous to do
> > this, as it makes it utterly unclear what triggers a state transition.
> > Additionally, only the tokeniser needs to know what state it is in; the
> > client of the tokeniser must treat it as a black box.
> >
>
> > I had the same concerns. Wanted to, but couldn't discuss it earlier. I
> did it as the specs say that the treebuilder must change tokeniser's state
> here, under "script" start tag, step 7.
> http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inhead
> .. There can be workarounds to avoid this. Please suggest some, or I'll try
> to work out some.
Well, the existing precedent for this kind of thing is the tokeniser's
content model, or the pause flag. Essentially, hubbub_tokeniser_setopt
is used to inject configuration into the tokeniser, which it is
perfectly at liberty to ignore, if it wants. The point here is that the
injection of configuration is a *request* to do something, which allows
the internals of the tokeniser to be kept private from its client.
J.
Re: libhubbub: branch rupindersingh/libhubbub updated. release/0.3.0-30-g1b8977f
There is no way a tokeniser could itself change to a state in the script domain. the only way it could do is through the treebuilder signalling it to do so. The change can be treated as if it is the intial state to the tokeniser, as it once began tokenising. This could be shifted to the content model flags, but that would mean larger code in the tokeniser, & would do nothing to change black-boxiness of the tokeniser. Instead, there would be added labour, as there would then be many overlapping & conflicting states in the script content flag itself. I have already changed the tokeniser to accomodate the changing of state, & it works fine with the script tags ... A precautionary measure that could be taken is to allow changing only to a set of pre-defined states.
If this doesn't look fine, then I'll try scraping off some commits and try redoing it using content model flags.On Mon, Jul 14, 2014 at 8:53 PM, John-Mark Bell <jmb@netsurf-browser.org> wrote:
On Sat, Jul 12, 2014 at 10:47:48PM +0100, NetSurf Browser Project wrote:
>
> - Log -----------------------------------------------------------------
> commitdiff http://git.netsurf-browser.org/libhubbub.git/commit/?id=1b8977f12ae4b9a88b6bea16540661c31a5bb326
> commit 1b8977f12ae4b9a88b6bea16540661c31a5bb326
> Author: Rupinder Singh Khokhar <rsk1coder99@gmail.com>
> Commit: Rupinder Singh Khokhar <rsk1coder99@gmail.com>
>
> Added provision for the treebuilder to change tokeniser's state. Additionally, in every loop of the dispatcher, it will be checked whether it is safe for tokeniser to process CDATA, and corresponding opts on the tokeniser will be set. this may slow the library down because of repeated checking in every loop.
I don't understand this changeset. Why have you exposed the tokeniser's
internal state to the outside world? It is extremely dangerous to do
this, as it makes it utterly unclear what triggers a state transition.
Additionally, only the tokeniser needs to know what state it is in; the
client of the tokeniser must treat it as a black box.
J.
Fwd: libhubbub: branch rupindersingh/libhubbub updated. release/0.3.0-30-g1b8977f
On Sat, Jul 12, 2014 at 10:47:48PM +0100, NetSurf Browser Project wrote:
I don't understand this changeset. Why have you exposed the tokeniser's
internal state to the outside world? It is extremely dangerous to do
this, as it makes it utterly unclear what triggers a state transition.
Additionally, only the tokeniser needs to know what state it is in; the
client of the tokeniser must treat it as a black box.
> I had the same concerns. Wanted to, but couldn't discuss it earlier. I did it as the specs say that the treebuilder must change tokeniser's state here, under "script" start tag, step 7. http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inhead .. There can be workarounds to avoid this. Please suggest some, or I'll try to work out some.
J.
Re: libhubbub: branch rupindersingh/libhubbub updated. release/0.3.0-30-g1b8977f
On Sat, Jul 12, 2014 at 10:47:48PM +0100, NetSurf Browser Project wrote:
>
> - Log -----------------------------------------------------------------
> commitdiff http://git.netsurf-browser.org/libhubbub.git/commit/?id=1b8977f12ae4b9a88b6bea16540661c31a5bb326
> commit 1b8977f12ae4b9a88b6bea16540661c31a5bb326
> Author: Rupinder Singh Khokhar <rsk1coder99@gmail.com>
> Commit: Rupinder Singh Khokhar <rsk1coder99@gmail.com>
>
> Added provision for the treebuilder to change tokeniser's state. Additionally, in every loop of the dispatcher, it will be checked whether it is safe for tokeniser to process CDATA, and corresponding opts on the tokeniser will be set. this may slow the library down because of repeated checking in every loop.
I don't understand this changeset. Why have you exposed the tokeniser's
internal state to the outside world? It is extremely dangerous to do
this, as it makes it utterly unclear what triggers a state transition.
Additionally, only the tokeniser needs to know what state it is in; the
client of the tokeniser must treat it as a black box.
J.
>
> - Log -----------------------------------------------------------------
> commitdiff http://git.netsurf-browser.org/libhubbub.git/commit/?id=1b8977f12ae4b9a88b6bea16540661c31a5bb326
> commit 1b8977f12ae4b9a88b6bea16540661c31a5bb326
> Author: Rupinder Singh Khokhar <rsk1coder99@gmail.com>
> Commit: Rupinder Singh Khokhar <rsk1coder99@gmail.com>
>
> Added provision for the treebuilder to change tokeniser's state. Additionally, in every loop of the dispatcher, it will be checked whether it is safe for tokeniser to process CDATA, and corresponding opts on the tokeniser will be set. this may slow the library down because of repeated checking in every loop.
I don't understand this changeset. Why have you exposed the tokeniser's
internal state to the outside world? It is extremely dangerous to do
this, as it makes it utterly unclear what triggers a state transition.
Additionally, only the tokeniser needs to know what state it is in; the
client of the tokeniser must treat it as a black box.
J.
Re: Some queries reguarding LibHubbub
On Sat, Jul 12, 2014 at 03:18:17AM +0530, Rupinder Singh wrote:
> Hi,
>
> 1) Ref:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-incdata
> :- The current support for scripting in Libhuubbub treebuilder is quite
> incomplete. The algorithms for scripting require running the script from
> external sources among other things. Completely implementing it, I think
> isn't possible at the moment, given the existing support. However it could
> be done partly. To what extent should I extend the support? Or should I
> leave it at the level we have it currently? The tokeniser has been updated
> to accomodate the script tags but the treebuilder lacks it.
Script execution is handled by the client of libhubbub. There is no need
whatsoever for libhubbub to have any explicit knowledge of script
execution. I'm sure Vincent is better placed to provide a more complete
answer here.
> 2) Ref:
> http://git.netsurf-browser.org/libhubbub.git/tree/src/tokeniser/tokeniser.c?h=rupindersingh/libhubbub#n206
> This variable here is to be set from the treebuilder or the client, I am
> not clear with that. Where exactly in the code should I set this variable?
> The condition for whether to handle the CDATA or not is specified here:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#markup-declaration-open-state
The treebuilder is responsible for setting this. When the current node
is updated, it must set the flag to true if the current node is not in
the HTML namespace; otherwise, it must set it to false.
J.
> Hi,
>
> 1) Ref:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-incdata
> :- The current support for scripting in Libhuubbub treebuilder is quite
> incomplete. The algorithms for scripting require running the script from
> external sources among other things. Completely implementing it, I think
> isn't possible at the moment, given the existing support. However it could
> be done partly. To what extent should I extend the support? Or should I
> leave it at the level we have it currently? The tokeniser has been updated
> to accomodate the script tags but the treebuilder lacks it.
Script execution is handled by the client of libhubbub. There is no need
whatsoever for libhubbub to have any explicit knowledge of script
execution. I'm sure Vincent is better placed to provide a more complete
answer here.
> 2) Ref:
> http://git.netsurf-browser.org/libhubbub.git/tree/src/tokeniser/tokeniser.c?h=rupindersingh/libhubbub#n206
> This variable here is to be set from the treebuilder or the client, I am
> not clear with that. Where exactly in the code should I set this variable?
> The condition for whether to handle the CDATA or not is specified here:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#markup-declaration-open-state
The treebuilder is responsible for setting this. When the current node
is updated, it must set the flag to true if the current node is not in
the HTML namespace; otherwise, it must set it to false.
J.
Friday, 11 July 2014
Some queries reguarding LibHubbub
Hi,
1) Ref: http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-incdata :- The current support for scripting in Libhuubbub treebuilder is quite incomplete. The algorithms for scripting require running the script from external sources among other things. Completely implementing it, I think isn't possible at the moment, given the existing support. However it could be done partly. To what extent should I extend the support? Or should I leave it at the level we have it currently? The tokeniser has been updated to accomodate the script tags but the treebuilder lacks it.
2) Ref: http://git.netsurf-browser.org/libhubbub.git/tree/src/tokeniser/tokeniser.c?h=rupindersingh/libhubbub#n206 This variable here is to be set from the treebuilder or the client, I am not clear with that. Where exactly in the code should I set this variable? The condition for whether to handle the CDATA or not is specified here: http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#markup-declaration-open-state .
2) Ref: http://git.netsurf-browser.org/libhubbub.git/tree/src/tokeniser/tokeniser.c?h=rupindersingh/libhubbub#n206 This variable here is to be set from the treebuilder or the client, I am not clear with that. Where exactly in the code should I set this variable? The condition for whether to handle the CDATA or not is specified here: http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#markup-declaration-open-state .
Regards,
Rupinder.
Thursday, 10 July 2014
Re: question of networking part
On Thu, Jul 10, 2014 at 02:50:45AM +0000, ���ſ� wrote:
> Hello,
> I��m newbie in netsurf.
> I��m trying to adapt netsurf on different networking environment.
> I would like to know where is network related source code.
> Networking part is actually ��send�� and ��receive�� the HTTP Request/Response.
HTTP requests (and networking) are handled by libcurl. The binding to
the libcurl library can be found in content/fetches/curl.c
B.
> Hello,
> I��m newbie in netsurf.
> I��m trying to adapt netsurf on different networking environment.
> I would like to know where is network related source code.
> Networking part is actually ��send�� and ��receive�� the HTTP Request/Response.
HTTP requests (and networking) are handled by libcurl. The binding to
the libcurl library can be found in content/fetches/curl.c
B.
Wednesday, 9 July 2014
question of networking part
Hello,
I'm newbie in netsurf.
I'm trying to adapt netsurf on different networking environment.
I would like to know where is network related source code.
Networking part is actually "send" and "receive" the HTTP Request/Response.
Cyoung.
Re: 2004: curious behaviour
In message <5424850262brian.jordan9@btinternet.com>
Brian Jordan <brian.jordan9@btinternet.com> wrote:
>In article <5423a02fbdbrian.jordan9@btinternet.com>,
> Brian Jordan <brian.jordan9@btinternet.com> wrote:
>
>[Snip]
>
>> Possibly related... I can't put the cursor into the search box in
>> www.google.co.uk in 2004 whereas it's OK in 2000.
>
>This and everything else mentioned in this thread appears to be fixed in
>2011.
I can confirm it's fixed in 2013.
> My thanks, as always, to the developers.
Mine too!
Dave
____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop!
Check it out at http://www.inbox.com/marineaquarium
Brian Jordan <brian.jordan9@btinternet.com> wrote:
>In article <5423a02fbdbrian.jordan9@btinternet.com>,
> Brian Jordan <brian.jordan9@btinternet.com> wrote:
>
>[Snip]
>
>> Possibly related... I can't put the cursor into the search box in
>> www.google.co.uk in 2004 whereas it's OK in 2000.
>
>This and everything else mentioned in this thread appears to be fixed in
>2011.
I can confirm it's fixed in 2013.
> My thanks, as always, to the developers.
Mine too!
Dave
____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop!
Check it out at http://www.inbox.com/marineaquarium
[gccsdk] cloog version needs changing
Hi,
I'm just trying to build the cross-compiler on Ubuntu and have found it stops complaining about the cloog version.
I'm updating my makefile to 0.15.11 and was wondering if someone would like to do that in svn (assuming that version is OK)
Thanks,
Alan
I'm just trying to build the cross-compiler on Ubuntu and have found it stops complaining about the cloog version.
I'm updating my makefile to 0.15.11 and was wondering if someone would like to do that in svn (assuming that version is OK)
Thanks,
Alan
Re: 2004: curious behaviour
In article <5423a02fbdbrian.jordan9@btinternet.com>,
Brian Jordan <brian.jordan9@btinternet.com> wrote:
[Snip]
> Possibly related... I can't put the cursor into the search box in
> www.google.co.uk in 2004 whereas it's OK in 2000.
This and everything else mentioned in this thread appears to be fixed in
2011. My thanks, as always, to the developers.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Brian Jordan <brian.jordan9@btinternet.com> wrote:
[Snip]
> Possibly related... I can't put the cursor into the search box in
> www.google.co.uk in 2004 whereas it's OK in 2000.
This and everything else mentioned in this thread appears to be fixed in
2011. My thanks, as always, to the developers.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Re: 2000 plus behaviour
On Wed, Jul 09, 2014 at 10:12:45AM +0100, Brian wrote:
> So far as I can tell, every version since 2000 goes into some kind of loop
> when downloading and rendering pages. Though a page may appear to have
> been completely rendered the 'eggtimer' continues to scroll and obstructs
> other activities like quitting NetSurf.
>
> --
> bbailey@argonet.co.uk
>
>
Try 2011 or later
--
Regards Vincent
http://www.kyllikki.org/
> So far as I can tell, every version since 2000 goes into some kind of loop
> when downloading and rendering pages. Though a page may appear to have
> been completely rendered the 'eggtimer' continues to scroll and obstructs
> other activities like quitting NetSurf.
>
> --
> bbailey@argonet.co.uk
>
>
Try 2011 or later
--
Regards Vincent
http://www.kyllikki.org/
Re: Bug reporting
On Wed, Jul 09, 2014 at 03:48:11AM -0800, Dave Higton wrote:
> On Wed, 09 Jul 2014 11:51:10 +0100 Richard Porter wrote:
>
> > On 8 Jul 2014 Dave Higton wrote:
> >
> >> The first thing the bug tracker asks is Category, which is a
> >> list of platforms from which I have to choose one, indicating
> >> that the bug is specific to a platform.
> >
> >> But, since I only have one platform, how do I know if what I'm
> >> reporting is specific to that platform?
> >
> > You don't but the developers may need to know what platform you are
> > running on. I take it to mean hardware platform since the OS and
> > version are asked for separately.
>
> OK, but that's not what it actually says. The options under
> "Category" are:
>
> ABEND
> Amiga-specific
> Atari-specific
> BeOS-specific
> Cocoa-sepcific
> Framebuffer-specific
> GTK-specific
> Javascript
> Layout
> RISC OS-specific
> Win32-specific
> [All Projects] General
If you are in any doubt of the category to use then use the General
category (it is a universal default category for all projects). For
you as a risc os user your options are limited to:
Javascript - issues obviously related to javascript.
Layout - Issues where the layout of the page is incorrect.
RISC OS-specific - Issues related to the RISC OS UI specifically, like
errors in the toolbar or configuration windows etc.
[All Projects] General - As already mentioned this is the default, if
you are unsure at all, just use this.
>
> I, as a user of a single OS, cannot tell whether the problem is
> specific to that OS, yet the field is required input from me.
>
The catagory is intended for issues specific to those OS frontends, if
you are not using them it cannot possibly be relevant to you. As I
outlined above, you (currently) have a choice of four.
> I don't want to make a big deal out of it, but it does look to
> be a misnomer, and I was just looking for some clarification of
> its significance to the developers. I've got it.
>
> AAMOI: what is the ABEND option about?
ABnormal END is a special classification for reported issues where the
program terminated abnormally with invalid state, literally the program
termination was abnormal. Generally these are aborts not caused by
assert() debug macros or our code dereferencing bad pointers those
are "normal" aborts.
This class is only useful to developers triaging bugs and I would hide
it from normal users if mantis allowed it.
>
> Dave
>
> ____________________________________________________________
> Protect your computer files with professional cloud backup.
> Get PCRx Backup and upload unlimited files automatically.
> Learn more at http://backup.pcrx.com/mail
>
>
--
Regards Vincent
http://www.kyllikki.org/
> On Wed, 09 Jul 2014 11:51:10 +0100 Richard Porter wrote:
>
> > On 8 Jul 2014 Dave Higton wrote:
> >
> >> The first thing the bug tracker asks is Category, which is a
> >> list of platforms from which I have to choose one, indicating
> >> that the bug is specific to a platform.
> >
> >> But, since I only have one platform, how do I know if what I'm
> >> reporting is specific to that platform?
> >
> > You don't but the developers may need to know what platform you are
> > running on. I take it to mean hardware platform since the OS and
> > version are asked for separately.
>
> OK, but that's not what it actually says. The options under
> "Category" are:
>
> ABEND
> Amiga-specific
> Atari-specific
> BeOS-specific
> Cocoa-sepcific
> Framebuffer-specific
> GTK-specific
> Javascript
> Layout
> RISC OS-specific
> Win32-specific
> [All Projects] General
If you are in any doubt of the category to use then use the General
category (it is a universal default category for all projects). For
you as a risc os user your options are limited to:
Javascript - issues obviously related to javascript.
Layout - Issues where the layout of the page is incorrect.
RISC OS-specific - Issues related to the RISC OS UI specifically, like
errors in the toolbar or configuration windows etc.
[All Projects] General - As already mentioned this is the default, if
you are unsure at all, just use this.
>
> I, as a user of a single OS, cannot tell whether the problem is
> specific to that OS, yet the field is required input from me.
>
The catagory is intended for issues specific to those OS frontends, if
you are not using them it cannot possibly be relevant to you. As I
outlined above, you (currently) have a choice of four.
> I don't want to make a big deal out of it, but it does look to
> be a misnomer, and I was just looking for some clarification of
> its significance to the developers. I've got it.
>
> AAMOI: what is the ABEND option about?
ABnormal END is a special classification for reported issues where the
program terminated abnormally with invalid state, literally the program
termination was abnormal. Generally these are aborts not caused by
assert() debug macros or our code dereferencing bad pointers those
are "normal" aborts.
This class is only useful to developers triaging bugs and I would hide
it from normal users if mantis allowed it.
>
> Dave
>
> ____________________________________________________________
> Protect your computer files with professional cloud backup.
> Get PCRx Backup and upload unlimited files automatically.
> Learn more at http://backup.pcrx.com/mail
>
>
--
Regards Vincent
http://www.kyllikki.org/
Re: Bug reporting
On 9 Jul 2014 Dave Higton wrote:
> OK, but that's not what it actually says.
Sorry I was thinking of a different field.
> The options under
> "Category" are:
> ABEND
> Amiga-specific
> Atari-specific
> BeOS-specific
> Cocoa-sepcific
> Framebuffer-specific
> GTK-specific
> Javascript
> Layout
> RISC OS-specific
> Win32-specific
> [All Projects] General
> I, as a user of a single OS, cannot tell whether the problem is
> specific to that OS, yet the field is required input from me.
I just select RISC OS-specific as it's the only one that fits the bill
unless it's a pure layout problem.
> I don't want to make a big deal out of it, but it does look to
> be a misnomer, and I was just looking for some clarification of
> its significance to the developers. I've got it.
> AAMOI: what is the ABEND option about?
No idea. ABEND goes back to IBM 360 days if not before. It's short for
"Abnormal End".
Richard
--
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.
> OK, but that's not what it actually says.
Sorry I was thinking of a different field.
> The options under
> "Category" are:
> ABEND
> Amiga-specific
> Atari-specific
> BeOS-specific
> Cocoa-sepcific
> Framebuffer-specific
> GTK-specific
> Javascript
> Layout
> RISC OS-specific
> Win32-specific
> [All Projects] General
> I, as a user of a single OS, cannot tell whether the problem is
> specific to that OS, yet the field is required input from me.
I just select RISC OS-specific as it's the only one that fits the bill
unless it's a pure layout problem.
> I don't want to make a big deal out of it, but it does look to
> be a misnomer, and I was just looking for some clarification of
> its significance to the developers. I've got it.
> AAMOI: what is the ABEND option about?
No idea. ABEND goes back to IBM 360 days if not before. It's short for
"Abnormal End".
Richard
--
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: Bug reporting
On Wed, Jul 09, 2014 at 03:48:11AM -0800, Dave Higton wrote:
> OK, but that's not what it actually says. The options under
> "Category" are:
>
> ABEND
> Amiga-specific
> Atari-specific
> BeOS-specific
> Cocoa-sepcific
> Framebuffer-specific
> GTK-specific
> Javascript
> Layout
> RISC OS-specific
> Win32-specific
> [All Projects] General
>
> I, as a user of a single OS, cannot tell whether the problem is
> specific to that OS, yet the field is required input from me.
Then "General" is the one to go for, at a guess.
> I don't want to make a big deal out of it, but it does look to
> be a misnomer, and I was just looking for some clarification of
> its significance to the developers. I've got it.
>
> AAMOI: what is the ABEND option about?
Abnormal End. This is probably a hang-over from the default
configuration of Mantis.
B.
> OK, but that's not what it actually says. The options under
> "Category" are:
>
> ABEND
> Amiga-specific
> Atari-specific
> BeOS-specific
> Cocoa-sepcific
> Framebuffer-specific
> GTK-specific
> Javascript
> Layout
> RISC OS-specific
> Win32-specific
> [All Projects] General
>
> I, as a user of a single OS, cannot tell whether the problem is
> specific to that OS, yet the field is required input from me.
Then "General" is the one to go for, at a guess.
> I don't want to make a big deal out of it, but it does look to
> be a misnomer, and I was just looking for some clarification of
> its significance to the developers. I've got it.
>
> AAMOI: what is the ABEND option about?
Abnormal End. This is probably a hang-over from the default
configuration of Mantis.
B.
Re: Bug reporting
On Wed, 09 Jul 2014 11:51:10 +0100 Richard Porter wrote:
> On 8 Jul 2014 Dave Higton wrote:
>
>> The first thing the bug tracker asks is Category, which is a
>> list of platforms from which I have to choose one, indicating
>> that the bug is specific to a platform.
>
>> But, since I only have one platform, how do I know if what I'm
>> reporting is specific to that platform?
>
> You don't but the developers may need to know what platform you are
> running on. I take it to mean hardware platform since the OS and
> version are asked for separately.
OK, but that's not what it actually says. The options under
"Category" are:
ABEND
Amiga-specific
Atari-specific
BeOS-specific
Cocoa-sepcific
Framebuffer-specific
GTK-specific
Javascript
Layout
RISC OS-specific
Win32-specific
[All Projects] General
I, as a user of a single OS, cannot tell whether the problem is
specific to that OS, yet the field is required input from me.
I don't want to make a big deal out of it, but it does look to
be a misnomer, and I was just looking for some clarification of
its significance to the developers. I've got it.
AAMOI: what is the ABEND option about?
Dave
____________________________________________________________
Protect your computer files with professional cloud backup.
Get PCRx Backup and upload unlimited files automatically.
Learn more at http://backup.pcrx.com/mail
> On 8 Jul 2014 Dave Higton wrote:
>
>> The first thing the bug tracker asks is Category, which is a
>> list of platforms from which I have to choose one, indicating
>> that the bug is specific to a platform.
>
>> But, since I only have one platform, how do I know if what I'm
>> reporting is specific to that platform?
>
> You don't but the developers may need to know what platform you are
> running on. I take it to mean hardware platform since the OS and
> version are asked for separately.
OK, but that's not what it actually says. The options under
"Category" are:
ABEND
Amiga-specific
Atari-specific
BeOS-specific
Cocoa-sepcific
Framebuffer-specific
GTK-specific
Javascript
Layout
RISC OS-specific
Win32-specific
[All Projects] General
I, as a user of a single OS, cannot tell whether the problem is
specific to that OS, yet the field is required input from me.
I don't want to make a big deal out of it, but it does look to
be a misnomer, and I was just looking for some clarification of
its significance to the developers. I've got it.
AAMOI: what is the ABEND option about?
Dave
____________________________________________________________
Protect your computer files with professional cloud backup.
Get PCRx Backup and upload unlimited files automatically.
Learn more at http://backup.pcrx.com/mail
Re: Bug reporting
On 8 Jul 2014 Dave Higton wrote:
> The first thing the bug tracker asks is Category, which is a
> list of platforms from which I have to choose one, indicating
> that the bug is specific to a platform.
> But, since I only have one platform, how do I know if what I'm
> reporting is specific to that platform?
You don't but the developers may need to know what platform you are
running on. I take it to mean hardware platform since the OS and
version are asked for separately.
Richard
--
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.
> The first thing the bug tracker asks is Category, which is a
> list of platforms from which I have to choose one, indicating
> that the bug is specific to a platform.
> But, since I only have one platform, how do I know if what I'm
> reporting is specific to that platform?
You don't but the developers may need to know what platform you are
running on. I take it to mean hardware platform since the OS and
version are asked for separately.
Richard
--
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.
2000 plus behaviour
So far as I can tell, every version since 2000 goes into some kind of loop
when downloading and rendering pages. Though a page may appear to have
been completely rendered the 'eggtimer' continues to scroll and obstructs
other activities like quitting NetSurf.
--
bbailey@argonet.co.uk
when downloading and rendering pages. Though a page may appear to have
been completely rendered the 'eggtimer' continues to scroll and obstructs
other activities like quitting NetSurf.
--
bbailey@argonet.co.uk
Re: BBC Programme Pages
In article <20140709072018.GH1926@platypus.pepperfish.net>,
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> JavaScript replaces it with a higher-quality one once the page render has
> completed.
Ah - understood.
John
--
| John Williams
| johnrw@ukgateway.net
Names for Soul Band:- Soul Requirements *
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> JavaScript replaces it with a higher-quality one once the page render has
> completed.
Ah - understood.
John
--
| John Williams
| johnrw@ukgateway.net
Names for Soul Band:- Soul Requirements *
Re: BBC Programme Pages
On Tue, Jul 08, 2014 at 07:08:05PM +0100, John Williams wrote:
>
> I notice that, when I click on a programme page from the Radio 4 Schedule
> Page, the main photo is pixellated, whilst other photos on the page are OK.
>
> Under Ubuntu in Firefox, the photos are rendered correctly.
>
> I suspect this may be something to do with NetSurf trying to render a
> thumbnail instead of the main JPEG - perhaps an EXIF file with embedded
> thumbnail?
>
> However, other browsers get it right, so why can't my preferred browser,
> NetSurf under RISC OS, get it right?
>
> Look at, say, http://www.bbc.co.uk/programmes/b044mc1g - the page for the
> programme I've just listened to - to see what I mean.
>
> Or is there some other explanation?
First guess at looking at it in Firefox is that the image is streamed,
ie, a low-quality small version is mentioned in the HTML to make page
render prompt, and then JavaScript replaces it with a higher-quality one
once the page render has completed.
B.
>
> I notice that, when I click on a programme page from the Radio 4 Schedule
> Page, the main photo is pixellated, whilst other photos on the page are OK.
>
> Under Ubuntu in Firefox, the photos are rendered correctly.
>
> I suspect this may be something to do with NetSurf trying to render a
> thumbnail instead of the main JPEG - perhaps an EXIF file with embedded
> thumbnail?
>
> However, other browsers get it right, so why can't my preferred browser,
> NetSurf under RISC OS, get it right?
>
> Look at, say, http://www.bbc.co.uk/programmes/b044mc1g - the page for the
> programme I've just listened to - to see what I mean.
>
> Or is there some other explanation?
First guess at looking at it in Firefox is that the image is streamed,
ie, a low-quality small version is mentioned in the HTML to make page
render prompt, and then JavaScript replaces it with a higher-quality one
once the page render has completed.
B.
Tuesday, 8 July 2014
BBC Programme Pages
I notice that, when I click on a programme page from the Radio 4 Schedule
Page, the main photo is pixellated, whilst other photos on the page are OK.
Under Ubuntu in Firefox, the photos are rendered correctly.
I suspect this may be something to do with NetSurf trying to render a
thumbnail instead of the main JPEG - perhaps an EXIF file with embedded
thumbnail?
However, other browsers get it right, so why can't my preferred browser,
NetSurf under RISC OS, get it right?
Look at, say, http://www.bbc.co.uk/programmes/b044mc1g - the page for the
programme I've just listened to - to see what I mean.
Or is there some other explanation?
John
--
| John Williams
| johnrw@ukgateway.net
Names for Soul Band:- Soul Survivors *
Page, the main photo is pixellated, whilst other photos on the page are OK.
Under Ubuntu in Firefox, the photos are rendered correctly.
I suspect this may be something to do with NetSurf trying to render a
thumbnail instead of the main JPEG - perhaps an EXIF file with embedded
thumbnail?
However, other browsers get it right, so why can't my preferred browser,
NetSurf under RISC OS, get it right?
Look at, say, http://www.bbc.co.uk/programmes/b044mc1g - the page for the
programme I've just listened to - to see what I mean.
Or is there some other explanation?
John
--
| John Williams
| johnrw@ukgateway.net
Names for Soul Band:- Soul Survivors *
Re: Bug reporting
On Mon, Jul 07, 2014 at 11:15:09PM -0800, Dave Higton wrote:
> The first thing the bug tracker asks is Category, which is a
> list of platforms from which I have to choose one, indicating
> that the bug is specific to a platform.
>
> But, since I only have one platform, how do I know if what I'm
> reporting is specific to that platform?
>
It is intended to give us more information. All bug fixing runs through
the basic stages of replicate, isolate and ameliorate. In order to
replicate a bug to start this process we require as much information
as possible.
> How to the developers react to it? Now that RISC OS is a
> minority platform for Netsurf, does it make the developers
> take less notice of the report?
makes no difference response wise
>
> Or do the developers take it as simply the platform on which
> it was first observed, and find if it's common to other
> platforms?
pretty much, might also let us decide it is frontend specific and
assign it to the appropriate frontend maintainer.
If the issue is not specific often we will just change the catagory to
suit.
The main issue with bugs right now is we have more of them being
reported than we are managing to fix (gaining about one a day
currently) but its more useful to have them reported than not.
>
> Dave
>
> ____________________________________________________________
> FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
> Check it out at http://www.inbox.com/earth
>
>
--
Regards Vincent
http://www.kyllikki.org/
> The first thing the bug tracker asks is Category, which is a
> list of platforms from which I have to choose one, indicating
> that the bug is specific to a platform.
>
> But, since I only have one platform, how do I know if what I'm
> reporting is specific to that platform?
>
It is intended to give us more information. All bug fixing runs through
the basic stages of replicate, isolate and ameliorate. In order to
replicate a bug to start this process we require as much information
as possible.
> How to the developers react to it? Now that RISC OS is a
> minority platform for Netsurf, does it make the developers
> take less notice of the report?
makes no difference response wise
>
> Or do the developers take it as simply the platform on which
> it was first observed, and find if it's common to other
> platforms?
pretty much, might also let us decide it is frontend specific and
assign it to the appropriate frontend maintainer.
If the issue is not specific often we will just change the catagory to
suit.
The main issue with bugs right now is we have more of them being
reported than we are managing to fix (gaining about one a day
currently) but its more useful to have them reported than not.
>
> Dave
>
> ____________________________________________________________
> FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
> Check it out at http://www.inbox.com/earth
>
>
--
Regards Vincent
http://www.kyllikki.org/
Bug reporting
The first thing the bug tracker asks is Category, which is a
list of platforms from which I have to choose one, indicating
that the bug is specific to a platform.
But, since I only have one platform, how do I know if what I'm
reporting is specific to that platform?
How to the developers react to it? Now that RISC OS is a
minority platform for Netsurf, does it make the developers
take less notice of the report?
Or do the developers take it as simply the platform on which
it was first observed, and find if it's common to other
platforms?
Dave
____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth
list of platforms from which I have to choose one, indicating
that the bug is specific to a platform.
But, since I only have one platform, how do I know if what I'm
reporting is specific to that platform?
How to the developers react to it? Now that RISC OS is a
minority platform for Netsurf, does it make the developers
take less notice of the report?
Or do the developers take it as simply the platform on which
it was first observed, and find if it's common to other
platforms?
Dave
____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth
Monday, 7 July 2014
Re: 2004: curious behaviour
On 7 Jul 2014 Brian Jordan <brian.jordan9@btinternet.com> wrote:
> In article <dd51262354.DaveMeUK@my.inbox.com>,
> Dave Higton <dave@davehigton.me.uk> wrote:
>> I noticed, with NS 2004, on the ROOL fora pages, that when I click on
>> a link with a hash and then try to scroll up, NS rapidly oscillates
>> between redrawing the window at the original location and my chosen
>> scrolled-to location. 2000 is OK, 2004 not.
>> Can someone else please confirm this before I raise a bug report?
> Possibly related... I can't put the cursor into the search box in
> www.google.co.uk in 2004 whereas it's OK in 2000.
Yes, I noticed that too. However, if you click in the search box, the
cursor appears for a split second, and then you can type into the box.
Best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> In article <dd51262354.DaveMeUK@my.inbox.com>,
> Dave Higton <dave@davehigton.me.uk> wrote:
>> I noticed, with NS 2004, on the ROOL fora pages, that when I click on
>> a link with a hash and then try to scroll up, NS rapidly oscillates
>> between redrawing the window at the original location and my chosen
>> scrolled-to location. 2000 is OK, 2004 not.
>> Can someone else please confirm this before I raise a bug report?
> Possibly related... I can't put the cursor into the search box in
> www.google.co.uk in 2004 whereas it's OK in 2000.
Yes, I noticed that too. However, if you click in the search box, the
cursor appears for a split second, and then you can type into the box.
Best wishes,
Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: 2004: curious behaviour
In article <dd51262354.DaveMeUK@my.inbox.com>,
Dave Higton <dave@davehigton.me.uk> wrote:
> I noticed, with NS 2004, on the ROOL fora pages, that when I click on
> a link with a hash and then try to scroll up, NS rapidly oscillates
> between redrawing the window at the original location and my chosen
> scrolled-to location. 2000 is OK, 2004 not.
> Can someone else please confirm this before I raise a bug report?
Possibly related... I can't put the cursor into the search box in
www.google.co.uk in 2004 whereas it's OK in 2000.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Dave Higton <dave@davehigton.me.uk> wrote:
> I noticed, with NS 2004, on the ROOL fora pages, that when I click on
> a link with a hash and then try to scroll up, NS rapidly oscillates
> between redrawing the window at the original location and my chosen
> scrolled-to location. 2000 is OK, 2004 not.
> Can someone else please confirm this before I raise a bug report?
Possibly related... I can't put the cursor into the search box in
www.google.co.uk in 2004 whereas it's OK in 2000.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Re: 2004: curious behaviour
On Mon, 07 Jul 2014 10:13:45 +0100 Brian Jordan wrote:
> In article <mpro.n8btb9002psgu059v.pittdj@pittdj.co.uk>,
> David Pitt <pittdj@pittdj.co.uk> wrote:
>> Dave Higton, on 6 Jul, wrote:
>
>>> I noticed, with NS 2004, on the ROOL fora pages, that when I click on
>>> a link with a hash and then try to scroll up, NS rapidly oscillates
>>> between redrawing the window at the original location and my chosen
>>> scrolled-to location. 2000 is OK, 2004 not.
>>>
>>> Can someone else please confirm this before I raise a bug report?
>
>> Confirmed.
>
>> https://www.riscosopen.org/forum/forums/3/topics/2597#posts-32716
>
>> I also notice the title bar flickering.
>
> Confirmed here too. This behaviour is seen in 2002 and and 2003 but not
> 2000; I don't have a copy of 2001 so can't comment on that build.
Thanks, Brian and David. Bug 2169 reported. Refers to this thread.
Dave
____________________________________________________________
Protect your computer files with professional cloud backup.
Get PCRx Backup and upload unlimited files automatically.
Learn more at http://backup.pcrx.com/mail
> In article <mpro.n8btb9002psgu059v.pittdj@pittdj.co.uk>,
> David Pitt <pittdj@pittdj.co.uk> wrote:
>> Dave Higton, on 6 Jul, wrote:
>
>>> I noticed, with NS 2004, on the ROOL fora pages, that when I click on
>>> a link with a hash and then try to scroll up, NS rapidly oscillates
>>> between redrawing the window at the original location and my chosen
>>> scrolled-to location. 2000 is OK, 2004 not.
>>>
>>> Can someone else please confirm this before I raise a bug report?
>
>> Confirmed.
>
>> https://www.riscosopen.org/forum/forums/3/topics/2597#posts-32716
>
>> I also notice the title bar flickering.
>
> Confirmed here too. This behaviour is seen in 2002 and and 2003 but not
> 2000; I don't have a copy of 2001 so can't comment on that build.
Thanks, Brian and David. Bug 2169 reported. Refers to this thread.
Dave
____________________________________________________________
Protect your computer files with professional cloud backup.
Get PCRx Backup and upload unlimited files automatically.
Learn more at http://backup.pcrx.com/mail
Re: 2004: curious behaviour
In article <mpro.n8btb9002psgu059v.pittdj@pittdj.co.uk>,
David Pitt <pittdj@pittdj.co.uk> wrote:
> Dave Higton, on 6 Jul, wrote:
> > I noticed, with NS 2004, on the ROOL fora pages, that when I click on
> > a link with a hash and then try to scroll up, NS rapidly oscillates
> > between redrawing the window at the original location and my chosen
> > scrolled-to location. 2000 is OK, 2004 not.
> >
> > Can someone else please confirm this before I raise a bug report?
> Confirmed.
> https://www.riscosopen.org/forum/forums/3/topics/2597#posts-32716
> I also notice the title bar flickering.
Confirmed here too. This behaviour is seen in 2002 and and 2003 but not
2000; I don't have a copy of 2001 so can't comment on that build.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
David Pitt <pittdj@pittdj.co.uk> wrote:
> Dave Higton, on 6 Jul, wrote:
> > I noticed, with NS 2004, on the ROOL fora pages, that when I click on
> > a link with a hash and then try to scroll up, NS rapidly oscillates
> > between redrawing the window at the original location and my chosen
> > scrolled-to location. 2000 is OK, 2004 not.
> >
> > Can someone else please confirm this before I raise a bug report?
> Confirmed.
> https://www.riscosopen.org/forum/forums/3/topics/2597#posts-32716
> I also notice the title bar flickering.
Confirmed here too. This behaviour is seen in 2002 and and 2003 but not
2000; I don't have a copy of 2001 so can't comment on that build.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Re: Bugs everywhere!
On 07/07/2014 10:47, Vincent Sanders wrote:
> It has come to my attention that our bug tracker is working well, alas
> this also reveals we are, on average, gaining a new bug every day
> right now.
>
> Can I make a plea to other developers to try and address some bugs in
> the forthcoming weeks? I was looking to make a 3.2 release soon to
> include all the recent improvements but we are not in plausible
> release state.
>
At least I created an account there last week, so it's definitely going
in the right direction ;-)
François.
> It has come to my attention that our bug tracker is working well, alas
> this also reveals we are, on average, gaining a new bug every day
> right now.
>
> Can I make a plea to other developers to try and address some bugs in
> the forthcoming weeks? I was looking to make a 3.2 release soon to
> include all the recent improvements but we are not in plausible
> release state.
>
At least I created an account there last week, so it's definitely going
in the right direction ;-)
François.
Bugs everywhere!
It has come to my attention that our bug tracker is working well, alas
this also reveals we are, on average, gaining a new bug every day
right now.
Can I make a plea to other developers to try and address some bugs in
the forthcoming weeks? I was looking to make a 3.2 release soon to
include all the recent improvements but we are not in plausible
release state.
--
Regards Vincent
http://www.kyllikki.org/
this also reveals we are, on average, gaining a new bug every day
right now.
Can I make a plea to other developers to try and address some bugs in
the forthcoming weeks? I was looking to make a 3.2 release soon to
include all the recent improvements but we are not in plausible
release state.
--
Regards Vincent
http://www.kyllikki.org/
Sunday, 6 July 2014
Re: 2004: curious behaviour
Dave Higton, on 6 Jul, wrote:
> I noticed, with NS 2004, on the ROOL fora pages, that when I click on a
> link with a hash and then try to scroll up, NS rapidly oscillates between
> redrawing the window at the original location and my chosen scrolled-to
> location. 2000 is OK, 2004 not.
>
> Can someone else please confirm this before I raise a bug report?
Confirmed.
https://www.riscosopen.org/forum/forums/3/topics/2597#posts-32716
I also notice the title bar flickering.
--
David Pitt
> I noticed, with NS 2004, on the ROOL fora pages, that when I click on a
> link with a hash and then try to scroll up, NS rapidly oscillates between
> redrawing the window at the original location and my chosen scrolled-to
> location. 2000 is OK, 2004 not.
>
> Can someone else please confirm this before I raise a bug report?
Confirmed.
https://www.riscosopen.org/forum/forums/3/topics/2597#posts-32716
I also notice the title bar flickering.
--
David Pitt
2004: curious behaviour
I noticed, with NS 2004, on the ROOL fora pages, that when I click on
a link with a hash and then try to scroll up, NS rapidly oscillates
between redrawing the window at the original location and my chosen
scrolled-to location. 2000 is OK, 2004 not.
Can someone else please confirm this before I raise a bug report?
Dave
____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth
a link with a hash and then try to scroll up, NS rapidly oscillates
between redrawing the window at the original location and my chosen
scrolled-to location. 2000 is OK, 2004 not.
Can someone else please confirm this before I raise a bug report?
Dave
____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth
Re: CSS Base
> I can see the following message in the log:
>
> (13.530001) render/html_css.c html_convert_css_callback 112:
> stylesheet
> file:///u%3A%5Cg%5CApplications%5Cnetsurf%5Cres%5Cdefault.css failed:
> UnacceptableType
Also, I hope that the URL appearance is OK at that point, the URL
Encoding must
be removed when it is used as file path. I did not follow the URL
handling changes
and maybe this doesn't work correctly at the atari version.
Greets,
Ole
>
> (13.530001) render/html_css.c html_convert_css_callback 112:
> stylesheet
> file:///u%3A%5Cg%5CApplications%5Cnetsurf%5Cres%5Cdefault.css failed:
> UnacceptableType
Also, I hope that the URL appearance is OK at that point, the URL
Encoding must
be removed when it is used as file path. I did not follow the URL
handling changes
and maybe this doesn't work correctly at the atari version.
Greets,
Ole
Re: CSS Base
> Looks like it's failing to find its resources. Neither the default
> style sheet or the Messages file have loaded. I don't know how the
> Atari front end deals with loading them.
>
Nope. These files are loaded correctly, I had a look at the debug log.
I suspect the Messages file isn't up to date. Peter, did you also update
the Messages file?
When you updated the Messages file, and still get the CSSBase error,
the archived Messages file inside the atari autobuild is erroneous.
However, CSSBase stands for the well known error "Base stylesheet
failed to load".
I can see the following message in the log:
(13.530001) render/html_css.c html_convert_css_callback 112: stylesheet
file:///u%3A%5Cg%5CApplications%5Cnetsurf%5Cres%5Cdefault.css failed:
UnacceptableType
(13.530002) render/html_css.c html_convert_css_callback 116: 2 fetches
active
(13.550000) render/html_css.c html_convert_css_callback 112: stylesheet
file:///user.css failed: UnacceptableType
(13.550001) render/html_css.c html_convert_css_callback 116: 1 fetches
active
(13.565000) render/html_css.c html_convert_css_callback 112: stylesheet
file:///u%3A%5Cg%5CApplications%5Cnetsurf%5Cres%5Cquirks.css failed:
UnacceptableType
(13.565001) render/html_css.c html_convert_css_callback 116: 0 fetches
active
(13.570000) render/html.c html_begin_conversion 1085: Completing parse
To me that looks like some function stopped to return correct filetype
now fails for some reason, maybe here:
http://git.netsurf-browser.org/netsurf.git/tree/atari/filetype.c#n34
But I'm not sure, maybe the netsurf dev team knows about changes in
that region.
Greets,
Ole
> style sheet or the Messages file have loaded. I don't know how the
> Atari front end deals with loading them.
>
Nope. These files are loaded correctly, I had a look at the debug log.
I suspect the Messages file isn't up to date. Peter, did you also update
the Messages file?
When you updated the Messages file, and still get the CSSBase error,
the archived Messages file inside the atari autobuild is erroneous.
However, CSSBase stands for the well known error "Base stylesheet
failed to load".
I can see the following message in the log:
(13.530001) render/html_css.c html_convert_css_callback 112: stylesheet
file:///u%3A%5Cg%5CApplications%5Cnetsurf%5Cres%5Cdefault.css failed:
UnacceptableType
(13.530002) render/html_css.c html_convert_css_callback 116: 2 fetches
active
(13.550000) render/html_css.c html_convert_css_callback 112: stylesheet
file:///user.css failed: UnacceptableType
(13.550001) render/html_css.c html_convert_css_callback 116: 1 fetches
active
(13.565000) render/html_css.c html_convert_css_callback 112: stylesheet
file:///u%3A%5Cg%5CApplications%5Cnetsurf%5Cres%5Cquirks.css failed:
UnacceptableType
(13.565001) render/html_css.c html_convert_css_callback 116: 0 fetches
active
(13.570000) render/html.c html_begin_conversion 1085: Completing parse
To me that looks like some function stopped to return correct filetype
now fails for some reason, maybe here:
http://git.netsurf-browser.org/netsurf.git/tree/atari/filetype.c#n34
But I'm not sure, maybe the netsurf dev team knows about changes in
that region.
Greets,
Ole
Saturday, 5 July 2014
Re: CSS Base
> Does anyone know what is wrong with the Atari daily builds?
>
> Any page just opens a dialogue box saying CSS Base (attached).
> No pages are rendered.
>
Can you please send the log?
I'm not at home because I broke my leg, but maybe there is something
interesting to see within the log.
Please also try to run netsurf from U:\ and via toswin2 shell, etc...
You and I know the desktops behave differently when it comes to the
current working directory...
maybe it's still not handled absolutly correct.
Please, also provide which desktop / AES you are using.
Greets and Thanks for reporting.
>
> Any page just opens a dialogue box saying CSS Base (attached).
> No pages are rendered.
>
Can you please send the log?
I'm not at home because I broke my leg, but maybe there is something
interesting to see within the log.
Please also try to run netsurf from U:\ and via toswin2 shell, etc...
You and I know the desktops behave differently when it comes to the
current working directory...
maybe it's still not handled absolutly correct.
Please, also provide which desktop / AES you are using.
Greets and Thanks for reporting.
Re: CSS Base
On 05/07/14 14:19, Peter Slegg wrote:
> Does anyone know what is wrong with the Atari daily builds?
>
> Any page just opens a dialogue box saying CSS Base (attached).
> No pages are rendered.
Looks like it's failing to find its resources. Neither the default
style sheet or the Messages file have loaded. I don't know how the
Atari front end deals with loading them.
--
Michael Drake http://www.netsurf-browser.org/
> Does anyone know what is wrong with the Atari daily builds?
>
> Any page just opens a dialogue box saying CSS Base (attached).
> No pages are rendered.
Looks like it's failing to find its resources. Neither the default
style sheet or the Messages file have loaded. I don't know how the
Atari front end deals with loading them.
--
Michael Drake http://www.netsurf-browser.org/
CSS Base
Any page just opens a dialogue box saying CSS Base (attached).
No pages are rendered.
Peter
Friday, 4 July 2014
Re: netsurf: branch master updated. release/3.1-312-geccfdec
On Thu, Jul 03, 2014 at 11:49:22PM +0100, Chris Young wrote:
> On Thu, 03 Jul 2014 22:05:23 +0100, Michael Drake wrote:
>
> > > Wait for network activity instead of polling.
> >
> > I'd be interested to know if that made any noticeable difference to page
> > load times. e.g. for BBC News homepage.
>
> None whatsoever.
I would not have expected it to impact load times significantly unless
you were pulling web pages from a very fast local web server.
Polling every 10ms is probably capable of dealing with all the data a
home internet link is capable of delivering
The fdset function will mainly improve responsiveness as NetSurf does
not need to poll the fetchers unecessarily. On slow connections
instead of polling the fetchers 100 times a second for data that
simply has not arrived yet it will instead only use processor when
data is available to process.
>
> I even did a quick test with three pages:
> | CI#1995 | CI#1996
> news.bbc.co.uk | 6.1s | 6.0s
> www.bbc.co.uk | 3.5s | 3.4s
> en.wikipedia.org | 4.8s | 5.1s
>
> Entirely non-scientific, but it doesn't seem any faster. They are
> both significantly quicker than the values in the screenshots on the
> NetSurf site though. :)
>
we should update those then ;-)
fyi GTK port on my laptop (at work with 200Mbit) connection completes
news.bbc.co.uk in 0.8s using fdset, and 1.9s using polled (no cache)
> I'm hoping it is stopping NetSurf taking processor time away from
> other tasks.
Thats exactly what it will be doing, if there is any to spare ;-)
>
> Chris
>
>
--
Regards Vincent
http://www.kyllikki.org/
> On Thu, 03 Jul 2014 22:05:23 +0100, Michael Drake wrote:
>
> > > Wait for network activity instead of polling.
> >
> > I'd be interested to know if that made any noticeable difference to page
> > load times. e.g. for BBC News homepage.
>
> None whatsoever.
I would not have expected it to impact load times significantly unless
you were pulling web pages from a very fast local web server.
Polling every 10ms is probably capable of dealing with all the data a
home internet link is capable of delivering
The fdset function will mainly improve responsiveness as NetSurf does
not need to poll the fetchers unecessarily. On slow connections
instead of polling the fetchers 100 times a second for data that
simply has not arrived yet it will instead only use processor when
data is available to process.
>
> I even did a quick test with three pages:
> | CI#1995 | CI#1996
> news.bbc.co.uk | 6.1s | 6.0s
> www.bbc.co.uk | 3.5s | 3.4s
> en.wikipedia.org | 4.8s | 5.1s
>
> Entirely non-scientific, but it doesn't seem any faster. They are
> both significantly quicker than the values in the screenshots on the
> NetSurf site though. :)
>
we should update those then ;-)
fyi GTK port on my laptop (at work with 200Mbit) connection completes
news.bbc.co.uk in 0.8s using fdset, and 1.9s using polled (no cache)
> I'm hoping it is stopping NetSurf taking processor time away from
> other tasks.
Thats exactly what it will be doing, if there is any to spare ;-)
>
> Chris
>
>
--
Regards Vincent
http://www.kyllikki.org/
Re: [Rpcemu] Stuck on installing RPCemu/Mint 16
Hi...I'm still completely stuck. I'm using the latest version I can
find. Can you (or anybody) tell me how/where I add the -lm?
Thanks,
Sean.
On 18/05/14 21:20, Peter Howkins wrote:
> On Tue, May 13, 2014 at 08:59:57AM +0100, Seán Kelly wrote:
>> Hi,
>>
>> I'm a Linux newbie - trying to install RPCemu under Mint 16.
>>
>> After a few false starts I got Allegro in place and all seemed to be
>> going well (following
>> http://www.marutan.net/rpcemuspoon/linuxcompile.html), until I typed
>
>
> Hi Sean, can you tell me which version of rpcemu you're trying to compile
> and where you got it from?
>
> In theory the issue you're reporting was fixed a few years ago, so it
> might be out of date source. [1]
>
> Peter
>
> [1] http://home.marutan.net/hg/rpcemu/rev/74ba3f3c9241
>
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
find. Can you (or anybody) tell me how/where I add the -lm?
Thanks,
Sean.
On 18/05/14 21:20, Peter Howkins wrote:
> On Tue, May 13, 2014 at 08:59:57AM +0100, Seán Kelly wrote:
>> Hi,
>>
>> I'm a Linux newbie - trying to install RPCemu under Mint 16.
>>
>> After a few false starts I got Allegro in place and all seemed to be
>> going well (following
>> http://www.marutan.net/rpcemuspoon/linuxcompile.html), until I typed
>
>
> Hi Sean, can you tell me which version of rpcemu you're trying to compile
> and where you got it from?
>
> In theory the issue you're reporting was fixed a few years ago, so it
> might be out of date source. [1]
>
> Peter
>
> [1] http://home.marutan.net/hg/rpcemu/rev/74ba3f3c9241
>
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Thursday, 3 July 2014
Re: netsurf: branch master updated. release/3.1-312-geccfdec
On Thu, 03 Jul 2014 22:05:23 +0100, Michael Drake wrote:
> > Wait for network activity instead of polling.
>
> I'd be interested to know if that made any noticeable difference to page
> load times. e.g. for BBC News homepage.
None whatsoever.
I even did a quick test with three pages:
| CI#1995 | CI#1996
news.bbc.co.uk | 6.1s | 6.0s
www.bbc.co.uk | 3.5s | 3.4s
en.wikipedia.org | 4.8s | 5.1s
Entirely non-scientific, but it doesn't seem any faster. They are
both significantly quicker than the values in the screenshots on the
NetSurf site though. :)
I'm hoping it is stopping NetSurf taking processor time away from
other tasks.
Chris
> > Wait for network activity instead of polling.
>
> I'd be interested to know if that made any noticeable difference to page
> load times. e.g. for BBC News homepage.
None whatsoever.
I even did a quick test with three pages:
| CI#1995 | CI#1996
news.bbc.co.uk | 6.1s | 6.0s
www.bbc.co.uk | 3.5s | 3.4s
en.wikipedia.org | 4.8s | 5.1s
Entirely non-scientific, but it doesn't seem any faster. They are
both significantly quicker than the values in the screenshots on the
NetSurf site though. :)
I'm hoping it is stopping NetSurf taking processor time away from
other tasks.
Chris
Re: netsurf: branch master updated. release/3.1-312-geccfdec
On 03/07/14 20:53, NetSurf Browser Project (Commit Mailer) wrote:
> commit eccfdec27ac1f59c18374edfec517749b47bfff6
> Author: Chris Young <chris@unsatisfactorysoftware.co.uk>
> Commit: Chris Young <chris@unsatisfactorysoftware.co.uk>
>
> Wait for network activity instead of polling.
I'd be interested to know if that made any noticeable difference to page
load times. e.g. for BBC News homepage.
Cheers,
--
Michael Drake http://www.netsurf-browser.org/
> commit eccfdec27ac1f59c18374edfec517749b47bfff6
> Author: Chris Young <chris@unsatisfactorysoftware.co.uk>
> Commit: Chris Young <chris@unsatisfactorysoftware.co.uk>
>
> Wait for network activity instead of polling.
I'd be interested to know if that made any noticeable difference to page
load times. e.g. for BBC News homepage.
Cheers,
--
Michael Drake http://www.netsurf-browser.org/
Wednesday, 2 July 2014
Re: Object fetchers moved to scheduled operation
On Wed, 2 Jul 2014 17:50:01 +0100, Vincent Sanders wrote:
> I think I properly documented these API as part of the great operation
> table rework.
>
> Ah yes
> desktop/gui.h:453 has the API docs, the relevant bit is:
>
> * Additional calls with the same callback and user parameter will
> * reset the callback time to the newly specified value.
Fixed :) (bit of code duplication which I don't have time to sort out
now)
> scale changes are the main reason, although gtk uses it when the debug
> rendering is turned on too.
Scaling is still working here.
Chris
> I think I properly documented these API as part of the great operation
> table rework.
>
> Ah yes
> desktop/gui.h:453 has the API docs, the relevant bit is:
>
> * Additional calls with the same callback and user parameter will
> * reset the callback time to the newly specified value.
Fixed :) (bit of code duplication which I don't have time to sort out
now)
> scale changes are the main reason, although gtk uses it when the debug
> rendering is turned on too.
Scaling is still working here.
Chris
Re: Object fetchers moved to scheduled operation
On Wed, Jul 02, 2014 at 05:36:09PM +0100, Chris Young wrote:
> I'm missing a load of emails so I've had to manually copy this from
> the archive to reply to it, so apologies for thread breakage.
no worries, just FYI i received a bounce from your email earlier when
I posted the reply.
>
> Vincent Sanders wrote:
>
> > As an *extension* fetcher_fdset() exists. This allows a frontend to
> > obtain a set of file descriptors the fetchers are using. The
> > frontend may then wait for activity on those file descriptors in
> > addition to events from the windowing system. Thus only servicing
> > the fetchers when there is activity.
>
> OK, that sounds useful. I should be able to use that.
Cool, if you need any more help just let me know.
>
> > The fetch servicing occurs specifically when fetcher_fdset() is
> > called. In addition the polling is rescheduled to a "long" time in
> > the future (currently a second) rather than cancelled altogether.
>
> Just as an aside, I notice this does a schedule for 1s every time it
> is called. Should the schedule code be ignoring/rescheduling/deleting
> events that are the same? As if this is scheduling a lot of events
> for 1s in the future, after a second all those events are going to
> fire, which is nearly as bad as polling? Or is there a deletion of
> the pending event happening somewhere that I've overlooked?
>
I think I properly documented these API as part of the great operation
table rework.
Ah yes
desktop/gui.h:453 has the API docs, the relevant bit is:
* Additional calls with the same callback and user parameter will
* reset the callback time to the newly specified value.
> >> I should be able to check the reformat one tonight, would have done
> >> so yesterday but my Internet was playing up and (possibly
> >> unrelated)
> >> this email account wasn't receiving messages - so I didn't see it
> >> until this morning.
>
> > Thats fine, that one I am a bit suspect of, hence the not merging
> > yet.
>
> Seems to be working fine, although I'm not entirely sure what triggers
> a reformat event (other than me manually resizing the window, which
> might not go the same route), so maybe something is broken and I just
> don't know it yet!
scale changes are the main reason, although gtk uses it when the debug
rendering is turned on too.
If noone else has any objections I will merge this tonight then.
--
Regards Vincent
http://www.kyllikki.org/
> I'm missing a load of emails so I've had to manually copy this from
> the archive to reply to it, so apologies for thread breakage.
no worries, just FYI i received a bounce from your email earlier when
I posted the reply.
>
> Vincent Sanders wrote:
>
> > As an *extension* fetcher_fdset() exists. This allows a frontend to
> > obtain a set of file descriptors the fetchers are using. The
> > frontend may then wait for activity on those file descriptors in
> > addition to events from the windowing system. Thus only servicing
> > the fetchers when there is activity.
>
> OK, that sounds useful. I should be able to use that.
Cool, if you need any more help just let me know.
>
> > The fetch servicing occurs specifically when fetcher_fdset() is
> > called. In addition the polling is rescheduled to a "long" time in
> > the future (currently a second) rather than cancelled altogether.
>
> Just as an aside, I notice this does a schedule for 1s every time it
> is called. Should the schedule code be ignoring/rescheduling/deleting
> events that are the same? As if this is scheduling a lot of events
> for 1s in the future, after a second all those events are going to
> fire, which is nearly as bad as polling? Or is there a deletion of
> the pending event happening somewhere that I've overlooked?
>
I think I properly documented these API as part of the great operation
table rework.
Ah yes
desktop/gui.h:453 has the API docs, the relevant bit is:
* Additional calls with the same callback and user parameter will
* reset the callback time to the newly specified value.
> >> I should be able to check the reformat one tonight, would have done
> >> so yesterday but my Internet was playing up and (possibly
> >> unrelated)
> >> this email account wasn't receiving messages - so I didn't see it
> >> until this morning.
>
> > Thats fine, that one I am a bit suspect of, hence the not merging
> > yet.
>
> Seems to be working fine, although I'm not entirely sure what triggers
> a reformat event (other than me manually resizing the window, which
> might not go the same route), so maybe something is broken and I just
> don't know it yet!
scale changes are the main reason, although gtk uses it when the debug
rendering is turned on too.
If noone else has any objections I will merge this tonight then.
--
Regards Vincent
http://www.kyllikki.org/
Re: Object fetchers moved to scheduled operation
I'm missing a load of emails so I've had to manually copy this from
the archive to reply to it, so apologies for thread breakage.
Vincent Sanders wrote:
> As an *extension* fetcher_fdset() exists. This allows a frontend to
> obtain a set of file descriptors the fetchers are using. The
> frontend may then wait for activity on those file descriptors in
> addition to events from the windowing system. Thus only servicing
> the fetchers when there is activity.
OK, that sounds useful. I should be able to use that.
> The fetch servicing occurs specifically when fetcher_fdset() is
> called. In addition the polling is rescheduled to a "long" time in
> the future (currently a second) rather than cancelled altogether.
Just as an aside, I notice this does a schedule for 1s every time it
is called. Should the schedule code be ignoring/rescheduling/deleting
events that are the same? As if this is scheduling a lot of events
for 1s in the future, after a second all those events are going to
fire, which is nearly as bad as polling? Or is there a deletion of
the pending event happening somewhere that I've overlooked?
> Also I feel a bit guilty for how slow we were in integrating and
> debugging the IDN changes (I hope its all settled down now). On that
> note, if you have done with those branches now they are merged can
> you do a bit of housekeeping and remove the unused branches from
> git?
I think I already have...
>> I should be able to check the reformat one tonight, would have done
>> so yesterday but my Internet was playing up and (possibly
>> unrelated)
>> this email account wasn't receiving messages - so I didn't see it
>> until this morning.
> Thats fine, that one I am a bit suspect of, hence the not merging
> yet.
Seems to be working fine, although I'm not entirely sure what triggers
a reformat event (other than me manually resizing the window, which
might not go the same route), so maybe something is broken and I just
don't know it yet!
> So no rush, hope your net connection improves.
That's working ok today, and this email account seems to be working
again too, it just didn't receive a bunch of messages. Only mailing
lists on it anyway so nothing important.
Regards
Chris
the archive to reply to it, so apologies for thread breakage.
Vincent Sanders wrote:
> As an *extension* fetcher_fdset() exists. This allows a frontend to
> obtain a set of file descriptors the fetchers are using. The
> frontend may then wait for activity on those file descriptors in
> addition to events from the windowing system. Thus only servicing
> the fetchers when there is activity.
OK, that sounds useful. I should be able to use that.
> The fetch servicing occurs specifically when fetcher_fdset() is
> called. In addition the polling is rescheduled to a "long" time in
> the future (currently a second) rather than cancelled altogether.
Just as an aside, I notice this does a schedule for 1s every time it
is called. Should the schedule code be ignoring/rescheduling/deleting
events that are the same? As if this is scheduling a lot of events
for 1s in the future, after a second all those events are going to
fire, which is nearly as bad as polling? Or is there a deletion of
the pending event happening somewhere that I've overlooked?
> Also I feel a bit guilty for how slow we were in integrating and
> debugging the IDN changes (I hope its all settled down now). On that
> note, if you have done with those branches now they are merged can
> you do a bit of housekeeping and remove the unused branches from
> git?
I think I already have...
>> I should be able to check the reformat one tonight, would have done
>> so yesterday but my Internet was playing up and (possibly
>> unrelated)
>> this email account wasn't receiving messages - so I didn't see it
>> until this morning.
> Thats fine, that one I am a bit suspect of, hence the not merging
> yet.
Seems to be working fine, although I'm not entirely sure what triggers
a reformat event (other than me manually resizing the window, which
might not go the same route), so maybe something is broken and I just
don't know it yet!
> So no rush, hope your net connection improves.
That's working ok today, and this email account seems to be working
again too, it just didn't receive a bunch of messages. Only mailing
lists on it anyway so nothing important.
Regards
Chris
Re: Object fetchers moved to scheduled operation
On 02/07/2014 11:07, Vincent Sanders wrote:
>>
>> Seems to work on Haiku.
>
> good to hear
>
>>
>> Btw, straight from select(2) manpage:
>> "nfds is the highest-numbered file descriptor in any of the three sets,
>> plus 1."
>> So the @todo is solved :D
>>
>
> I fear one of us is misunderstanding.
>
> The fetcher_fdset() api will return an fd set and the number of the
> highest used fd in that set for example if the returned set has
> 4,5,7,8,9 in it the max_fd variable will be 9.
Hmm indeed,
I always had the impression curl_multi_fdset() was already adding one,
but it seems not:
http://curl.haxx.se/libcurl/c/curl_multi_fdset.html
In any case, select() needs the +1.
> Surely that means the todo was asking if the max_fd needed 1 adding to
> it inside the MAX statement? a sit stands in my example nfds will be
> passed to select as 9 not 10? and actually it would better read as:
>
> max_fd = MAX(max_fd, sEventPipe[0]) + 1;
Indeed this looks more correct.
François.
>>
>> Seems to work on Haiku.
>
> good to hear
>
>>
>> Btw, straight from select(2) manpage:
>> "nfds is the highest-numbered file descriptor in any of the three sets,
>> plus 1."
>> So the @todo is solved :D
>>
>
> I fear one of us is misunderstanding.
>
> The fetcher_fdset() api will return an fd set and the number of the
> highest used fd in that set for example if the returned set has
> 4,5,7,8,9 in it the max_fd variable will be 9.
Hmm indeed,
I always had the impression curl_multi_fdset() was already adding one,
but it seems not:
http://curl.haxx.se/libcurl/c/curl_multi_fdset.html
In any case, select() needs the +1.
> Surely that means the todo was asking if the max_fd needed 1 adding to
> it inside the MAX statement? a sit stands in my example nfds will be
> passed to select as 9 not 10? and actually it would better read as:
>
> max_fd = MAX(max_fd, sEventPipe[0]) + 1;
Indeed this looks more correct.
François.
Re: Object fetchers moved to scheduled operation
On Wed, Jul 02, 2014 at 10:25:03AM +0100, Chris Young wrote:
>
>
> On 1 July 2014 09:25:38 BST, Vincent Sanders <vince@netsurf-browser.org> wrote:
>
> >The API has also been extended with fetcher_fdset() which allows the
> >fd sets of all active fetchers to be obtained for frontends that wish
> >to wait on fd activity instead of polling unnecessarily.
>
> I don't understand this. If it is scheduling the fetches rather than
> polling, I can ignore this, right? As I'm waiting for messages from
> the scheduler anyway?
Ok I need to explain this better as Michael asked too.
The fetchers are now completely run off the scheduler in a self
contained manner and not through a poll event in the main loop. While
there are active fetches a callback is repeatedly scheduled which
ensures all fetches are dispatched and the fetchers serviced.
This mode of operation is slightly more expensive than it strictly
needs to be as we service the fetchers even if they have no work to
do.
As an *extension* fetcher_fdset() exists. This allows a frontend to
obtain a set of file descriptors the fetchers are using. The frontend
may then wait for activity on those file descriptors in addition to
events from the windowing system. Thus only servicing the fetchers
when there is activity.
The fetch servicing occurs specifically when fetcher_fdset() is
called. In addition the polling is rescheduled to a "long" time in the
future (currently a second) rather than cancelled altogether. This
allows for the failure where a frontend is servicing scheduled events
but has failed to call fetcher_fdset() on further occasions.
>
> >Please can all frontend maintainers check I have not made a glaring
> >error on their platform as this is pretty invasive for such a small
> >cleanup. Especially ChrisY needs to check the amiga frontend as that
> >used to rely on a config to schedule curl directly which is no longer
> >present.
>
> Slight paranoia showing through :) but it is working bar the bug report I've raised.
It is not paranoia if they are out to get you! ;-) More seriously
though, you are the most responsive frontend maintainer and I feel bad
for potentially braking things for you because I cannot test. Please do
not think I do it deliberately!
Also I feel a bit guilty for how slow we were in integrating and
debugging the IDN changes (I hope its all settled down now). On that
note, if you have done with those branches now they are merged can you
do a bit of housekeeping and remove the unused branches from git?
> I should be able to check the reformat one tonight, would have done
> so yesterday but my Internet was playing up and (possibly unrelated)
> this email account wasn't receiving messages - so I didn't see it
> until this morning.
Thats fine, that one I am a bit suspect of, hence the not merging
yet. So no rush, hope your net connection improves.
>
> Chris
>
--
Regards Vincent
http://www.kyllikki.org/
>
>
> On 1 July 2014 09:25:38 BST, Vincent Sanders <vince@netsurf-browser.org> wrote:
>
> >The API has also been extended with fetcher_fdset() which allows the
> >fd sets of all active fetchers to be obtained for frontends that wish
> >to wait on fd activity instead of polling unnecessarily.
>
> I don't understand this. If it is scheduling the fetches rather than
> polling, I can ignore this, right? As I'm waiting for messages from
> the scheduler anyway?
Ok I need to explain this better as Michael asked too.
The fetchers are now completely run off the scheduler in a self
contained manner and not through a poll event in the main loop. While
there are active fetches a callback is repeatedly scheduled which
ensures all fetches are dispatched and the fetchers serviced.
This mode of operation is slightly more expensive than it strictly
needs to be as we service the fetchers even if they have no work to
do.
As an *extension* fetcher_fdset() exists. This allows a frontend to
obtain a set of file descriptors the fetchers are using. The frontend
may then wait for activity on those file descriptors in addition to
events from the windowing system. Thus only servicing the fetchers
when there is activity.
The fetch servicing occurs specifically when fetcher_fdset() is
called. In addition the polling is rescheduled to a "long" time in the
future (currently a second) rather than cancelled altogether. This
allows for the failure where a frontend is servicing scheduled events
but has failed to call fetcher_fdset() on further occasions.
>
> >Please can all frontend maintainers check I have not made a glaring
> >error on their platform as this is pretty invasive for such a small
> >cleanup. Especially ChrisY needs to check the amiga frontend as that
> >used to rely on a config to schedule curl directly which is no longer
> >present.
>
> Slight paranoia showing through :) but it is working bar the bug report I've raised.
It is not paranoia if they are out to get you! ;-) More seriously
though, you are the most responsive frontend maintainer and I feel bad
for potentially braking things for you because I cannot test. Please do
not think I do it deliberately!
Also I feel a bit guilty for how slow we were in integrating and
debugging the IDN changes (I hope its all settled down now). On that
note, if you have done with those branches now they are merged can you
do a bit of housekeeping and remove the unused branches from git?
> I should be able to check the reformat one tonight, would have done
> so yesterday but my Internet was playing up and (possibly unrelated)
> this email account wasn't receiving messages - so I didn't see it
> until this morning.
Thats fine, that one I am a bit suspect of, hence the not merging
yet. So no rush, hope your net connection improves.
>
> Chris
>
--
Regards Vincent
http://www.kyllikki.org/
Re: Object fetchers moved to scheduled operation
On 1 July 2014 09:25:38 BST, Vincent Sanders <vince@netsurf-browser.org> wrote:
>The API has also been extended with fetcher_fdset() which allows the
>fd sets of all active fetchers to be obtained for frontends that wish
>to wait on fd activity instead of polling unnecessarily.
I don't understand this. If it is scheduling the fetches rather than polling, I can ignore this, right? As I'm waiting for messages from the scheduler anyway?
>Please can all frontend maintainers check I have not made a glaring
>error on their platform as this is pretty invasive for such a small
>cleanup. Especially ChrisY needs to check the amiga frontend as that
>used to rely on a config to schedule curl directly which is no longer
>present.
Slight paranoia showing through :) but it is working bar the bug report I've raised.
I should be able to check the reformat one tonight, would have done so yesterday but my Internet was playing up and (possibly unrelated) this email account wasn't receiving messages - so I didn't see it until this morning.
Chris
>The API has also been extended with fetcher_fdset() which allows the
>fd sets of all active fetchers to be obtained for frontends that wish
>to wait on fd activity instead of polling unnecessarily.
I don't understand this. If it is scheduling the fetches rather than polling, I can ignore this, right? As I'm waiting for messages from the scheduler anyway?
>Please can all frontend maintainers check I have not made a glaring
>error on their platform as this is pretty invasive for such a small
>cleanup. Especially ChrisY needs to check the amiga frontend as that
>used to rely on a config to schedule curl directly which is no longer
>present.
Slight paranoia showing through :) but it is working bar the bug report I've raised.
I should be able to check the reformat one tonight, would have done so yesterday but my Internet was playing up and (possibly unrelated) this email account wasn't receiving messages - so I didn't see it until this morning.
Chris
Re: Object fetchers moved to scheduled operation
>
> Seems to work on Haiku.
good to hear
>
> Btw, straight from select(2) manpage:
> "nfds is the highest-numbered file descriptor in any of the three sets,
> plus 1."
> So the @todo is solved :D
>
I fear one of us is misunderstanding.
The fetcher_fdset() api will return an fd set and the number of the
highest used fd in that set for example if the returned set has
4,5,7,8,9 in it the max_fd variable will be 9.
if your sEventPipe[0] is (as an example) fd 6 then the select in this
case wants to see an fdset with 4,5,6,7,8,9 in it and nfds as 10
(i.e. 9 + 1)
Surely that means the todo was asking if the max_fd needed 1 adding to
it inside the MAX statement? a sit stands in my example nfds will be
passed to select as 9 not 10? and actually it would better read as:
max_fd = MAX(max_fd, sEventPipe[0]) + 1;
though that would mean we are reusing max_fd instead of having a
separate nfds which is a bit dirty but understandable.
Perhaps I have misunderstood though. this is why it was left as a todo
for the maintainer, though even if it is wrong at worst the browser
waits a second for the polling to resume so its not a big deal.
--
Regards Vincent
http://www.kyllikki.org/
> Seems to work on Haiku.
good to hear
>
> Btw, straight from select(2) manpage:
> "nfds is the highest-numbered file descriptor in any of the three sets,
> plus 1."
> So the @todo is solved :D
>
I fear one of us is misunderstanding.
The fetcher_fdset() api will return an fd set and the number of the
highest used fd in that set for example if the returned set has
4,5,7,8,9 in it the max_fd variable will be 9.
if your sEventPipe[0] is (as an example) fd 6 then the select in this
case wants to see an fdset with 4,5,6,7,8,9 in it and nfds as 10
(i.e. 9 + 1)
Surely that means the todo was asking if the max_fd needed 1 adding to
it inside the MAX statement? a sit stands in my example nfds will be
passed to select as 9 not 10? and actually it would better read as:
max_fd = MAX(max_fd, sEventPipe[0]) + 1;
though that would mean we are reusing max_fd instead of having a
separate nfds which is a bit dirty but understandable.
Perhaps I have misunderstood though. this is why it was left as a todo
for the maintainer, though even if it is wrong at worst the browser
waits a second for the polling to resume so its not a big deal.
--
Regards Vincent
http://www.kyllikki.org/
Tuesday, 1 July 2014
Re: Object fetchers moved to scheduled operation
On 01/07/2014 10:25, Vincent Sanders wrote:
> As a continuation of the work done by Daniel to adjust the llcache
> behaviour to use scheduler for user notification I have now changed
> the fetcher system to also be run from the scheduler.
>
> The fetcher API has been simplified to remove the need for polling
> from the main loop which gets us very close to netsurf_poll() becoming
> obsolete.
>
> The API has also been extended with fetcher_fdset() which allows the
> fd sets of all active fetchers to be obtained for frontends that wish
> to wait on fd activity instead of polling unnecessarily.
>
> Please can all frontend maintainers check I have not made a glaring
> error on their platform as this is pretty invasive for such a small
> cleanup. Especially ChrisY needs to check the amiga frontend as that
> used to rely on a config to schedule curl directly which is no longer
> present.
>
> This change should improve the overall code cleanliness and gets us
> much closer to being able to have frontends run their own dispatch
> loop.
>
Seems to work on Haiku.
Btw, straight from select(2) manpage:
"nfds is the highest-numbered file descriptor in any of the three sets,
plus 1."
So the @todo is solved :D
François.
> As a continuation of the work done by Daniel to adjust the llcache
> behaviour to use scheduler for user notification I have now changed
> the fetcher system to also be run from the scheduler.
>
> The fetcher API has been simplified to remove the need for polling
> from the main loop which gets us very close to netsurf_poll() becoming
> obsolete.
>
> The API has also been extended with fetcher_fdset() which allows the
> fd sets of all active fetchers to be obtained for frontends that wish
> to wait on fd activity instead of polling unnecessarily.
>
> Please can all frontend maintainers check I have not made a glaring
> error on their platform as this is pretty invasive for such a small
> cleanup. Especially ChrisY needs to check the amiga frontend as that
> used to rely on a config to schedule curl directly which is no longer
> present.
>
> This change should improve the overall code cleanliness and gets us
> much closer to being able to have frontends run their own dispatch
> loop.
>
Seems to work on Haiku.
Btw, straight from select(2) manpage:
"nfds is the highest-numbered file descriptor in any of the three sets,
plus 1."
So the @todo is solved :D
François.
Re: Moving reformat to scheduled operation
On 01/07/14 17:47, Vincent Sanders wrote:
> I have a branch vince/reformatpending which changes this to being a
> scheduled callback and reduces the frontend involvment to providing a
> single callback entry in the window operation table.
Looks good to me.
+1.
--
Michael Drake http://www.netsurf-browser.org/
> I have a branch vince/reformatpending which changes this to being a
> scheduled callback and reduces the frontend involvment to providing a
> single callback entry in the window operation table.
Looks good to me.
+1.
--
Michael Drake http://www.netsurf-browser.org/
Moving reformat to scheduled operation
The final remaining operation performed within the frontends dispatch
loop is that of pending reformats.
The reformat call differs from the redraw in that it is used when a
browser windows scale or extents changes.
The current operation is to set the browser_reformat_pending global to
signal one or more browser_windows required updating and then each
browser window has its own flag which must be checked.
This was ineficient as the frontends had to check every browser window
even if only one required reformatting and broke our data hiding model
for browser_window meaning we had to expose browser_window internals
all over the codebase.
I have a branch vince/reformatpending which changes this to being a
scheduled callback and reduces the frontend involvment to providing a
single callback entry in the window operation table.
This has revealed some dreadful code in many areas including several
frontends that never do anything with the flag at all!
Because of this this change is much more invasive and alters behaviour
in frontends I could not test. I would appreciate frontend maintainers
(I have tested/fixed gtk/framebuffer/monkey and riscos) trying this
branch and giving feedback before I commit it.
Especialy Chris Young on amiga where my changes are untested and I
fear I may have broken the frontend altogether (sorry Chris)
Hopefully this is the end of the road with these type of changes, my
next is to remove the poll entry and let frontends run the main loop
themselves.
--
Regards Vincent
http://www.kyllikki.org/
loop is that of pending reformats.
The reformat call differs from the redraw in that it is used when a
browser windows scale or extents changes.
The current operation is to set the browser_reformat_pending global to
signal one or more browser_windows required updating and then each
browser window has its own flag which must be checked.
This was ineficient as the frontends had to check every browser window
even if only one required reformatting and broke our data hiding model
for browser_window meaning we had to expose browser_window internals
all over the codebase.
I have a branch vince/reformatpending which changes this to being a
scheduled callback and reduces the frontend involvment to providing a
single callback entry in the window operation table.
This has revealed some dreadful code in many areas including several
frontends that never do anything with the flag at all!
Because of this this change is much more invasive and alters behaviour
in frontends I could not test. I would appreciate frontend maintainers
(I have tested/fixed gtk/framebuffer/monkey and riscos) trying this
branch and giving feedback before I commit it.
Especialy Chris Young on amiga where my changes are untested and I
fear I may have broken the frontend altogether (sorry Chris)
Hopefully this is the end of the road with these type of changes, my
next is to remove the poll entry and let frontends run the main loop
themselves.
--
Regards Vincent
http://www.kyllikki.org/
Re: netsurf-dev Digest, Vol 98, Issue 1
On Tue, Jul 01, 2014 at 17:19:09 +0530, Navdeep Nayar wrote:
> we are checking XML file .In XML Java Script using DOMParser() function to
> get the data from xml file. BUT in Netsurf browser this function is not
> working.
> can anyone help me ?
NetSurf's JavaScript integration is very incomplete as of now. I'd be
surprised if much beyond the shonky JS some people use to populate dropdowns in
<script> tags works. Sorry.
Also, please do not use digest subscription if you ever intend to post to the
list, it's very bad form. If if you *must* then please don't reply to, and
then quote the entire of the digest when you post.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> we are checking XML file .In XML Java Script using DOMParser() function to
> get the data from xml file. BUT in Netsurf browser this function is not
> working.
> can anyone help me ?
NetSurf's JavaScript integration is very incomplete as of now. I'd be
surprised if much beyond the shonky JS some people use to populate dropdowns in
<script> tags works. Sorry.
Also, please do not use digest subscription if you ever intend to post to the
list, it's very bad form. If if you *must* then please don't reply to, and
then quote the entire of the digest when you post.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Re: netsurf-dev Digest, Vol 98, Issue 1
Hello All,
Testing some sample html on Netsurf browser in ubuntu system.
we are checking XML file .In XML Java Script using DOMParser() function to get the data from xml file. BUT in Netsurf browser this function is not working.
Testing some sample html on Netsurf browser in ubuntu system.
we are checking XML file .In XML Java Script using DOMParser() function to get the data from xml file. BUT in Netsurf browser this function is not working.
can anyone help me ?
Thanks & Regards
Navdeep N.
On Tue, Jul 1, 2014 at 4:30 PM, <netsurf-dev-request@netsurf-browser.org> wrote:
Send netsurf-dev mailing list submissions to
netsurf-dev@netsurf-browser.org
To subscribe or unsubscribe via the World Wide Web, visit
http://vlists.pepperfish.net/cgi-bin/mailman/listinfo/netsurf-dev-netsurf-browser.org
or, via email, send a message with subject or body 'help' to
netsurf-dev-request@netsurf-browser.org
You can reach the person managing the list at
netsurf-dev-owner@netsurf-browser.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netsurf-dev digest..."
Today's Topics:
1. Object fetchers moved to scheduled operation (Vincent Sanders)
----------------------------------------------------------------------
Message: 1
Date: Tue, 1 Jul 2014 09:25:38 +0100
From: Vincent Sanders <vince@netsurf-browser.org>
Subject: Object fetchers moved to scheduled operation
To: netsurf-dev@netsurf-browser.org
Message-ID: <20140701082537.GX27671@kyllikki.org>
Content-Type: text/plain; charset=us-ascii
As a continuation of the work done by Daniel to adjust the llcache
behaviour to use scheduler for user notification I have now changed
the fetcher system to also be run from the scheduler.
The fetcher API has been simplified to remove the need for polling
from the main loop which gets us very close to netsurf_poll() becoming
obsolete.
The API has also been extended with fetcher_fdset() which allows the
fd sets of all active fetchers to be obtained for frontends that wish
to wait on fd activity instead of polling unnecessarily.
Please can all frontend maintainers check I have not made a glaring
error on their platform as this is pretty invasive for such a small
cleanup. Especially ChrisY needs to check the amiga frontend as that
used to rely on a config to schedule curl directly which is no longer
present.
This change should improve the overall code cleanliness and gets us
much closer to being able to have frontends run their own dispatch
loop.
--
Regards Vincent
http://www.kyllikki.org/
End of netsurf-dev Digest, Vol 98, Issue 1
******************************************
Object fetchers moved to scheduled operation
As a continuation of the work done by Daniel to adjust the llcache
behaviour to use scheduler for user notification I have now changed
the fetcher system to also be run from the scheduler.
The fetcher API has been simplified to remove the need for polling
from the main loop which gets us very close to netsurf_poll() becoming
obsolete.
The API has also been extended with fetcher_fdset() which allows the
fd sets of all active fetchers to be obtained for frontends that wish
to wait on fd activity instead of polling unnecessarily.
Please can all frontend maintainers check I have not made a glaring
error on their platform as this is pretty invasive for such a small
cleanup. Especially ChrisY needs to check the amiga frontend as that
used to rely on a config to schedule curl directly which is no longer
present.
This change should improve the overall code cleanliness and gets us
much closer to being able to have frontends run their own dispatch
loop.
--
Regards Vincent
http://www.kyllikki.org/
behaviour to use scheduler for user notification I have now changed
the fetcher system to also be run from the scheduler.
The fetcher API has been simplified to remove the need for polling
from the main loop which gets us very close to netsurf_poll() becoming
obsolete.
The API has also been extended with fetcher_fdset() which allows the
fd sets of all active fetchers to be obtained for frontends that wish
to wait on fd activity instead of polling unnecessarily.
Please can all frontend maintainers check I have not made a glaring
error on their platform as this is pretty invasive for such a small
cleanup. Especially ChrisY needs to check the amiga frontend as that
used to rely on a config to schedule curl directly which is no longer
present.
This change should improve the overall code cleanliness and gets us
much closer to being able to have frontends run their own dispatch
loop.
--
Regards Vincent
http://www.kyllikki.org/
Subscribe to:
Posts (Atom)