Re: bad formatting of news page

On 30/03/16 12:51, Chris Young wrote:
> On 30 March 2016 12:34:45 BST, Jim Nagel <jim@archivemag.co.uk> wrote:

>> I'm guessing that my local paper and yours both use Media Queries
>> software to generate web pages.

It means we need to implement the media queries specification:

https://www.w3.org/TR/mediaqueries-4/

--

Michael Drake http://www.codethink.co.uk/

Re: bad formatting of news page

On 30 March 2016 12:34:45 BST, Jim Nagel <jim@archivemag.co.uk> wrote:
>Chris Young wrote on 30 Mar:
>
>> On 30 March 2016 00:20:52 BST, Jim Nagel <netsurf@abbeypress.co.uk>
>wrote:
>>>What is it about the formatting of my local newspaper's web pages?
>>>Netsurf shows the main column of text so narrow that every line
>>>requires horizontal scrolling. Typical example:
>>>http://www.centralsomersetgazette.co.uk/Baily-s-costs-dream-revive-2-0
>>>00-jobs-Morland-s/story-28054944-detail/story.html
>...
>
>> Is it the same as this?
>> http://bugs.netsurf-browser.org/mantis/view.php?id=2426
>
>Yes, seems to be same. I note that Michael Drake (of the Netsurf
>team) replied to your post at 9:01 this morning.
>
>I might be jumping to conclusions from his rather cryptic reply, but
>I'm guessing that my local paper and yours both use Media Queries
>software to generate web pages. Results certainly look alike!
>
>By the way, did you mean to reply to me privately rather than to the
>Netsurf list?

I did a "reply all", should have gone to both. Replying to this to ensure the trail is all on the list.

Chris

Re: bad formatting of news page

I find on the Netsurf bugtracker (Mantis) that back in Feb, Chris
Young reported the same problem with web pages from his local paper in
Bedford. http://bugs.netsurf-browser.org/mantis/view.php?id=2426

The Bedford pages bear an uncanny resemblance to those from my
Somerset local, so I'm guessing they use the same software to generate
them.

Michael Drake, of the Netsurf team, replied this morning in the
bugtracker thread, rather cryptically:
This is: LibCSS needs to gain support for Media Queries.

--
Jim Nagel www.archivemag.co.uk

Re: bad formatting of news page

On 30 March 2016 00:20:52 BST, Jim Nagel <netsurf@abbeypress.co.uk> wrote:
>What is it about the formatting of my local newspaper's web pages?
>
>Netsurf shows the main column of text so narrow that every line
>requires horizontal scrolling. Typical example:
>http://www.centralsomersetgazette.co.uk/Baily-s-costs-dream-revive-2-000-jobs-Morland-s/story-28054944-detail/story.html
>
>I find the least painful way to read the story is to save the whole
>page as text and then read the textfile.
>
>Has the website programmer made some inept setting in the stylesheet
>(CSS), or is Netsurf making some mistake or interpreting something too
>literally?
>
>I presume browsers such as Firefox show what the designer intended.

Is it the same as this? http://bugs.netsurf-browser.org/mantis/view.php?id=2426

Chris

Re: bad formatting of news page

In article <d9d0aa6855.jim@abbeypress.net>,
Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> What is it about the formatting of my local newspaper's web pages?

> Netsurf shows the main column of text so narrow that every line
> requires horizontal scrolling. Typical example:
> http://www.centralsomersetgazette.co.uk/Baily-s-costs-dream-revive-2-000-jobs-Morland-s/story-28054944-detail/story.html

> I find the least painful way to read the story is to save the whole
> page as text and then read the textfile.

> Has the website programmer made some inept setting in the stylesheet
> (CSS), or is Netsurf making some mistake or interpreting something too
> literally?

> I presume browsers such as Firefox show what the designer intended.

It's interesting that Firefox 45.0.1 does display the the text okay, but
some of the site material down the Right hand side column is missing.

With both MS Internet Explorer and Google Chrome both the article and the
RH column material displays what appears to be correctly.

Dave

--

Dave Triffid

bad formatting of news page

What is it about the formatting of my local newspaper's web pages?

Netsurf shows the main column of text so narrow that every line
requires horizontal scrolling. Typical example:
http://www.centralsomersetgazette.co.uk/Baily-s-costs-dream-revive-2-000-jobs-Morland-s/story-28054944-detail/story.html

I find the least painful way to read the story is to save the whole
page as text and then read the textfile.

Has the website programmer made some inept setting in the stylesheet
(CSS), or is Netsurf making some mistake or interpreting something too
literally?

I presume browsers such as Firefox show what the designer intended.

--
Jim Nagel www.archivemag.co.uk

Re: multi-core processors

In article <mpro.o4n6y000qiel505ac.atdotcodotuk@dotcodotukat.co.uk>, Vince
M Hudd <atdotcodotuk@dotcodotukat.co.uk> wrote:
> Brian <bbailey@argonet.co.uk> wrote:

> > It does beg the question. What happens when NetSurf runs in VRPC on a
> > Win 7 machine with a multi-core processor? Does VRPC take advantage of
> > multiple cores?

> This isn't really a NetSurf question since you're asking about VRPC, so
> I'm reluctant to answer it here. I've therefore sent my reply to it to
> the VirtualAcorn mailing list.

> I'm not sure if you subscribe, so now that the message has appeared, it
> can be found in the list archive here:

http://riscository.co.uk/pipermail/virtualacorn-list_riscository.co.uk/2016-March/002311.html

Thank you. I was just curious.

Re: multi-core processors

On Sat, Mar 26, 2016 at 06:14:29AM +0000, Brian wrote:
> > NetSurf is single-threaded, by design. It won't take direct advantange
> > of multiple cores. It'll still be faster on those systems which support
> > multiple CPUs, because the OS can run on one while NetSurf runs on
> > another.
>
> It does beg the question. What happens when NetSurf runs in VRPC on a Win
> 7 machine with a multi-core processor? Does VRPC take advantage of
> multiple cores?

No idea, but NetSurf can do nothing to help in that respect.

B.

Re: multi-core processors

Brian <bbailey@argonet.co.uk> wrote:

> It does beg the question. What happens when NetSurf runs in VRPC on a Win
> 7 machine with a multi-core processor? Does VRPC take advantage of
> multiple cores?

This isn't really a NetSurf question since you're asking about VRPC, so I'm
reluctant to answer it here. I've therefore sent my reply to it to the
VirtualAcorn mailing list.

I'm not sure if you subscribe, so now that the message has appeared, it can
be found in the list archive here:

http://riscository.co.uk/pipermail/virtualacorn-list_riscository.co.uk/2016-March/002311.html

--
Vince M Hudd
Soft Rock Software

Re: multi-core processors

In article <20160325182319.GL23212@platypus.pepperfish.net>,
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> On Fri, Mar 25, 2016 at 04:58:05PM +0000, Jim Nagel wrote:
> > Some of the new Arm hardware running RiscOS (e.g. the ArmX6 and
> > Titanium) has a multi-core processor. So far, of course, RiscOS lacks
> > the ability to make use of the extra potential.
> >
> > Question occurs to me: what's the situation with the other platforms
> > on which Netsurf runs -- Amiga, Atari, etc? Does multi-core ability
> > exist in hardware there?
> >
> > Do the Netsurf developers have ideas for how Netsurf could take
> > advantage of the extra processing power when the OSes allow it?

> NetSurf is single-threaded, by design. It won't take direct advantange
> of multiple cores. It'll still be faster on those systems which support
> multiple CPUs, because the OS can run on one while NetSurf runs on
> another.

It does beg the question. What happens when NetSurf runs in VRPC on a Win
7 machine with a multi-core processor? Does VRPC take advantage of
multiple cores?

> B.

Re: RISC OS/RPi 3 support

John-Mark Bell, on 25 Mar, wrote:

> All,
>
> Build 3460 or later should run fine on the Raspberry Pi 3 under RISC OS.
> As none of the developers have such hardware, please could somebody who
> does please test this and ensure it works.

I can confirm the #3460 does work on the RPi3.

Many thanks indeed.


--
David Pitt

RISC OS/RPi 3 support

All,

Build 3460 or later should run fine on the Raspberry Pi 3 under RISC OS.
As none of the developers have such hardware, please could somebody who
does please test this and ensure it works.

Thanks,


John-Mark.

Re: multi-core processors

On Fri, Mar 25, 2016 at 04:58:05PM +0000, Jim Nagel wrote:
> Some of the new Arm hardware running RiscOS (e.g. the ArmX6 and
> Titanium) has a multi-core processor. So far, of course, RiscOS lacks
> the ability to make use of the extra potential.
>
> Question occurs to me: what's the situation with the other platforms
> on which Netsurf runs -- Amiga, Atari, etc? Does multi-core ability
> exist in hardware there?
>
> Do the Netsurf developers have ideas for how Netsurf could take
> advantage of the extra processing power when the OSes allow it?

NetSurf is single-threaded, by design. It won't take direct advantange
of multiple cores. It'll still be faster on those systems which support
multiple CPUs, because the OS can run on one while NetSurf runs on
another.

B.

multi-core processors

Some of the new Arm hardware running RiscOS (e.g. the ArmX6 and
Titanium) has a multi-core processor. So far, of course, RiscOS lacks
the ability to make use of the extra potential.

Question occurs to me: what's the situation with the other platforms
on which Netsurf runs -- Amiga, Atari, etc? Does multi-core ability
exist in hardware there?

Do the Netsurf developers have ideas for how Netsurf could take
advantage of the extra processing power when the OSes allow it?

--
Jim Nagel www.archivemag.co.uk

Re: Crash on Atari build

In message <0024b6cb.02131490bfd5@smtp.freeola.net>
Peter Slegg <p.slegg@scubadivers.co.uk> wrote:

>> Date: Thu, 24 Mar 2016 23:40:54 GMT
>> From: Dave Higton <dave@davehigton.me.uk>
>> Subject: Re: Crash on Atari build
>> To: netsurf-users@netsurf-browser.org
>>
>> Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
>>
>> >
>> >I recent builds (last week or so) I have had problems exiting ns,
>> >it would just hang and I've also had a few situations where it
>> >would hang while awaiting a page.
>> >
>> >I've just had a proper crash:
>> >
>> >Failure when receiving data from the peer
>> >render/html_object.c:125: html_object_callback: Assertion `c->base.status != CONTENT_STATUS_ERROR' failed.
>> >
>> >I was trying to view:
>> >
>> >https://github.com/vinriviere/m68k-atari-mint-gcc/blob/
>>
>> 404 for me.
>>
>> Dave
>
>Sorry, I had to guess the link after the crash.
>
>I just tried this:
>
>https://github.com/vinriviere/m68k-atari-mint-gcc/
>
>First the peer failure dialogue pops up and then ns crashes with:
>
>Failure when receiving data from the peer
>render/html_object.c:125: html_object_callback: Assertion `c->base.status != CONTENT_STATUS_ERROR' failed.

OK, thanks. All I can add is that it works on RISC OS CI #3457,
neither of your observed symptoms occurs, so it appears to be
specific to the Atari build.

Dave

____________________________________________________________
Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
Check it out at http://mysecurelogon.com/manager

Re: Crash on Atari build

> Date: Thu, 24 Mar 2016 23:40:54 GMT
> From: Dave Higton <dave@davehigton.me.uk>
> Subject: Re: Crash on Atari build
> To: netsurf-users@netsurf-browser.org
>
> Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
>
> >
> >I recent builds (last week or so) I have had problems exiting ns,
> >it would just hang and I've also had a few situations where it
> >would hang while awaiting a page.
> >
> >I've just had a proper crash:
> >
> >Failure when receiving data from the peer
> >render/html_object.c:125: html_object_callback: Assertion `c->base.status != CONTENT_STATUS_ERROR' failed.
> >
> >I was trying to view:
> >
> >https://github.com/vinriviere/m68k-atari-mint-gcc/blob/
>
> 404 for me.
>
> Dave

Sorry, I had to guess the link after the crash.

I just tried this:

https://github.com/vinriviere/m68k-atari-mint-gcc/

First the peer failure dialogue pops up and then ns crashes with:

Failure when receiving data from the peer
render/html_object.c:125: html_object_callback: Assertion `c->base.status != CONTENT_STATUS_ERROR' failed.


Regards,

Peter

Re: Crash on Atari build

In message <000b5dac.022974902866@smtp.freeola.net>
Peter Slegg <p.slegg@scubadivers.co.uk> wrote:

>
>I recent builds (last week or so) I have had problems exiting ns,
>it would just hang and I've also had a few situations where it
>would hang while awaiting a page.
>
>I've just had a proper crash:
>
>Failure when receiving data from the peer
>render/html_object.c:125: html_object_callback: Assertion `c->base.status != CONTENT_STATUS_ERROR' failed.
>
>I was trying to view:
>
>https://github.com/vinriviere/m68k-atari-mint-gcc/blob/

404 for me.

Dave

____________________________________________________________
Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
Check it out at http://mysecurelogon.com/manager

Crash on Atari build

I recent builds (last week or so) I have had problems exiting ns,
it would just hang and I've also had a few situations where it
would hang while awaiting a page.

I've just had a proper crash:

Failure when receiving data from the peer
render/html_object.c:125: html_object_callback: Assertion `c->base.status != CONTENT_STATUS_ERROR' failed.

I was trying to view:

https://github.com/vinriviere/m68k-atari-mint-gcc/blob/

Build 3449


Peter

Re: Fwd: Bug report for libnsbmp

Hi Renchen

On Wed, 16 Mar 2016 11:00:21 -0700, Renchen.Sun wrote:

> Not sure if it's the correct email address to talk about this. I use
> libnsbmp lib in my project and realize that it crashes on decoding a
> bmp file as attached in this email.
>
> Please take a look and fix it if possible. This bimap has rle-8
> encoding and it seems like libnsbmp has out-of-bound access to the
> memory.

I can reproduce this here. Can you raise it on the bugtracker please?
http://bugs.netsurf-browser.org

Thanks
Chris


Stack trace:
bmp_decode_rle.part.0()+0x40c (section 1 @ 0x2A02B0)
bmp_decode_rle.part.0()+0x60 (section 1 @ 0x29FF04)
[image/bmp.c:183] nsbmp_redraw()+0x88 (section 1 @ 0x14590C)
[content/content.c:636] content_scaled_redraw()+0x138 (section 1 @ 0xE7210)
[amiga/bitmap.c:593] bitmap_render()+0xbc (section 1 @ 0x22A4)
[desktop/browser_history.c:524] browser_window_history_add()+0x284 (section 1 @ 0x11DE98)
[desktop/browser.c:1409] browser_window_callback()+0x6ec (section 1 @ 0x11A978)
[content/hlcache.c:191] hlcache_content_callback()+0x4c (section 1 @ 0xF50D0)
[content/content.c:772] content_set_ready()+0xf8 (section 1 @ 0xE5ED8)
[image/bmp.c:168] nsbmp_convert()+0x148 (section 1 @ 0x145AB8)
[content/content.c:286] content_llcache_callback()+0x210 (section 1 @ 0xE62A4)
[content/llcache.c:3003] llcache_object_notify_users()+0x1ec (section 1 @ 0xF8678)
[content/llcache.c:3430] llcache_catch_up_all_users()+0x5c (section 1 @ 0xF882C)
[amiga/schedule.c:248] ami_schedule_handle()+0x16c (section 1 @ 0x3B3E0)
[amiga/gui.c:2819] ami_get_msg()+0x4f4 (section 1 @ 0x1D6B8)
[amiga/gui.c:5702] main()+0xea8 (section 1 @ 0x21798)
native kernel module newlib.library.kmod+0x000020ac
native kernel module newlib.library.kmod+0x00002d5c
native kernel module newlib.library.kmod+0x00002ef0
_start()+0x170 (section 1 @ 0x16C)
native kernel module dos.library.kmod+0x00024c18
native kernel module kernel+0x0003b648
native kernel module kernel+0x0003b6c8

Re: Bug report for libnsbmp

Hello Ashish,

That bmp file is in this email's attachment. 

Thank you

Renchen

On Mar 16, 2016, at 22:02, Ashish Gupta <ashmew2@gmail.com> wrote:

Hi

I think the attachment was scrubbed automatically ( if you did indeed attach it ) because I cannot see it . Is it possible for you to upload the BMP somewhere so that someone can have a look ?

Thanks!

Regards,
Ashish Gupta

On Mar 17, 2016 9:50 AM, "Renchen.Sun" <sunrenchen@gmail.com> wrote:

---------- Forwarded message ----------
From: Renchen.Sun <sunrenchen@gmail.com>
Date: Wed, Mar 16, 2016 at 10:41 AM
Subject: Bug report for libnsbmp
To: netsurf-dev@netsurf-browser.org

Hello,

Not sure if it's the correct email address to talk about this. I use libnsbmp lib in my project and realize that it crashes on decoding a bmp file as attached in this email.

Please take a look and fix it if possible. This bimap has rle-8 encoding and it seems like libnsbmp has out-of-bound access to the memory.

Regards,

Renchen

<crash.bmp>

Re: Fwd: Bug report for libnsbmp

Hi

I think the attachment was scrubbed automatically ( if you did indeed attach it ) because I cannot see it . Is it possible for you to upload the BMP somewhere so that someone can have a look ?

Thanks!

Regards,
Ashish Gupta

On Mar 17, 2016 9:50 AM, "Renchen.Sun" <sunrenchen@gmail.com> wrote:

---------- Forwarded message ----------
From: Renchen.Sun <sunrenchen@gmail.com>
Date: Wed, Mar 16, 2016 at 10:41 AM
Subject: Bug report for libnsbmp
To: netsurf-dev@netsurf-browser.org

Hello,

Not sure if it's the correct email address to talk about this. I use libnsbmp lib in my project and realize that it crashes on decoding a bmp file as attached in this email.

Please take a look and fix it if possible. This bimap has rle-8 encoding and it seems like libnsbmp has out-of-bound access to the memory.

Regards,

Renchen

Fwd: Bug report for libnsbmp

---------- Forwarded message ----------
From: Renchen.Sun <sunrenchen@gmail.com>
Date: Wed, Mar 16, 2016 at 10:41 AM
Subject: Bug report for libnsbmp
To: netsurf-dev@netsurf-browser.org

Hello,

Not sure if it's the correct email address to talk about this. I use libnsbmp lib in my project and realize that it crashes on decoding a bmp file as attached in this email.

Please take a look and fix it if possible. This bimap has rle-8 encoding and it seems like libnsbmp has out-of-bound access to the memory.

Regards,

Renchen

Re: [gccsdk] UnixLib and ARMv8

On 12/03/16 11:53, Chris Gransden wrote:
> In article <56E2EDD9.7020802@sky.com>,
> Lee Noar <leenoar@sky.com> wrote:
>> On 05/03/16 17:23, Theo Markettos wrote:
>>> On Sat, Mar 05, 2016 at 04:06:12PM +0100, John Tytgat wrote:
>>>> On 03/01/2016 07:26 PM, Theo Markettos wrote:
>>>>> [...]
>>>>> I can do some implementation and testing, if this is deemed to be
>>>>> a good idea. ('testing' in a loose sense - provoking concurrency
>>>>> conditions being somewhat hard)
>>>>
>>>> FYI, UnixLib has some testing code in its 'test' subdirectory (incl.
>>>> pthread). It might be useful to verify nothing gets obviously
>>>> broken.
>>>
>>> Useful to know.
>
>>> I'll let Lee take the lead since he probably knows more than I about the
>>> internals, but let me know if you need help.
>
>> I've just committed some changes that determine whether to use SWP
>> or LDREX/STREX at runtime using the info that Ben posted as a guide.
>> Perhaps if you have a RPi3, you could see if Otter works?
>
>> I think the pthread testing code may need some work to bring it up
>> to date, plus all the tests need to be built with the -static flag, but
>> that's proving difficult to achieve.
>
> QupZilla and Otter browser seem to run ok at first but then crash with the
> same stack trace. Sometimes straight away or after a couple of minutes use.
> MPlayer also crashes in a silimar way but there is no stack trace. Command
> line programs run OK. Also ArcEm and !Nettle run OK too.
>
> Here's the stack trace from Otter browser,

[snip]

Those programs that don't use pthreads should be okay, it's the
pthread code that's the problem.
I've order a RPi3, so hopefully some hands on experimenting will
help. In the meantime, if anyone can spot the issue, let me know.

Thanks,
Lee.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

re: Atari front end

On , netsurf-users-request@netsurf-browser.org wrote:
> Date: Thu, 10 Mar 2016 19:34:20 +0000
> From: Michael Drake <tlsa@netsurf-browser.org>
> Subject: Atari front end
> To: netsurf-users@netsurf-browser.org
> Message-ID: <56E1CC3C.5000209@netsurf-browser.org>
>
> Are there any Atari users around?
>
> Could you let us know if the current m5475 and m68k builds are working?
>
> http://ci.netsurf-browser.org/builds/atari/?C=M;O=D
>
>

These might not be specific to the Atari build but now that js is
implemented I gave my router admin pages another test.


Enter the ip address of the router 192.168.0.1 and NS reports
that it is running out of memory.

Enter it as http://192.168.0.1 and the login dialogue appears.

I have to backspace to remove the - characters.

The password is not hidden.

The page has a js a redirect which doesn't work.

<script language="javascript" type="text/javascript">
function loadnext() {top.location.href="./start.htm"; }</script></head>
<body bgcolor="#ffffff" onload="loadnext()" > Loading file ...</body></html>

Regards,

Peter

Re: Missing images

In message <19cbe65f55.pnyoung@pnyoung.ormail.co.uk>
Peter Young <pnyoung@ormail.co.uk> wrote:

>On 12 Mar 2016 Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
>
>
>> This page seems to behave in a similar way:
>
>> http://www.itv.com/news/granada/
>
>No images at at all here. RISC OS, NetSurf #3434
>
>Will you do a bug report?

I think you'll find that this is the same as Mantis case 532, which
was raised in 2012.

Dave

____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop!
Check it out at http://www.inbox.com/marineaquarium

Re: Missing images

On 12 Mar 2016 Peter Slegg <p.slegg@scubadivers.co.uk> wrote:


> This page seems to behave in a similar way:

> http://www.itv.com/news/granada/

No images at at all here. RISC OS, NetSurf #3434

Will you do a bug report?

Best wishes,

Peter.

--
Peter Young (zfc Os) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Re: Missing images

This page seems to behave in a similar way:

http://www.itv.com/news/granada/

Peter

Re: [gccsdk] UnixLib and ARMv8

In article <56E2EDD9.7020802@sky.com>,
Lee Noar <leenoar@sky.com> wrote:
> On 05/03/16 17:23, Theo Markettos wrote:
> > On Sat, Mar 05, 2016 at 04:06:12PM +0100, John Tytgat wrote:
> >> On 03/01/2016 07:26 PM, Theo Markettos wrote:
> >>> [...]
> >>> I can do some implementation and testing, if this is deemed to be
> >>> a good idea. ('testing' in a loose sense - provoking concurrency
> >>> conditions being somewhat hard)
> >>
> >> FYI, UnixLib has some testing code in its 'test' subdirectory (incl.
> >> pthread). It might be useful to verify nothing gets obviously
> >> broken.
> >
> > Useful to know.

> > I'll let Lee take the lead since he probably knows more than I about the
> > internals, but let me know if you need help.

> I've just committed some changes that determine whether to use SWP
> or LDREX/STREX at runtime using the info that Ben posted as a guide.
> Perhaps if you have a RPi3, you could see if Otter works?

> I think the pthread testing code may need some work to bring it up
> to date, plus all the tests need to be built with the -static flag, but
> that's proving difficult to achieve.

QupZilla and Otter browser seem to run ok at first but then crash with the
same stack trace. Sometimes straight away or after a couple of minutes use.
MPlayer also crashes in a silimar way but there is no stack trace. Command
line programs run OK. Also ArcEm and !Nettle run OK too.

Here's the stack trace from Otter browser,

Fatal signal received: Aborted

Stack backtrace:

Running thread 0x9a28a0 (Qt bearer thread)
( f06b5c) pc: 4ba7d980 lr: 4ba7dd9c sp: f06b60 __write_backtrace()
( f06bc8) pc: 4ba7dad0 lr: 4ba7e2e4 sp: f06bcc
__unixlib_raise_signal()
( f06bd8) pc: 4ba7e2bc lr: 4ba8a468 sp: f06bdc raise()
( f06bec) pc: 4ba8a41c lr: 4ba5e7f4 sp: f06bf0 abort()
( f06c04) pc: 4ba5e7bc lr: 4ba60fa4 sp: f06c08
__pthread_fatal_error()
( f06c14) pc: 4ba60f74 lr: 4baa2800 sp: f06c18 pthread_yield()

Register dump at 00f06c18:

a1: 9ab050 a2: 9ab13c a3: 9ab228 a4: f06dec
v1: f06c38 v2: 4682e548 v3: 4682e578 v4: 0
v5: 7 v6: 6123e8 sl: 0 fp: 0
ip: 0 sp: 0 lr: 0 pc: 0
cpsr: 0

[Disassembly not available]

( f06db4) pc: 4baa2420 lr: 4baa15c0 sp: f06db8 select()
( f06dec) pc: 4baa1550 lr: 4a4f5648 sp: f06df0 pselect()
( f06e38) pc: 4a4f55b4 lr: 4a4f5b88 sp: f06e3c qt_safe_select(int,
__fd_set*, __fd_set*, __fd_set*, timespec const*)
( f06e4c) pc: 4a4f5b60 lr: 4a4f7258 sp: f06e50
QEventDispatcherUNIX::select(int, __fd_set*, __fd_set*, __fd_set*,
timespec*)
( f06ed8) pc: 4a4f7168 lr: 4a4f777c sp: f06edc
QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timespec*)
( f06f08) pc: 4a4f7648 lr: 4a489674 sp: f06f0c
QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
( f06f1c) pc: 4a489640 lr: 4a489c78 sp: f06f20
QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
( f06f64) pc: 4a489b70 lr: 4a25d67c sp: f06f68
QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)
( f06f88) pc: 4a25d5cc lr: 4a25d748 sp: f06f8c QThread::exec()
( f06f98) pc: 4a25d73c lr: 4a26308c sp: f06f9c QThread::run()
( f06fd4) pc: 4a262f24 lr: 4ba5e504 sp: f06fd8
QThreadPrivate::start(void*)
( f06fe4) pc: 4ba5e4ec lr: 99f100 sp: f06fe8 __pthread_create()


Thread 0x9b1950 (JavaScriptCore::BlockFree)
( f06b3c) pc: 4ba6100c lr: 4ba5dfd4 sp: f04ec4
__pthread_yield_return()
( f04ed0) pc: 4ba60f74 lr: 4ba5dfd4 sp: f04ed4 pthread_yield()
( f04ef8) pc: 4ba5deb8 lr: 483e48d0 sp: f04efc
pthread_cond_timedwait()
( f04f20) pc: 483e4828 lr: 48153494 sp: f04f24
WTF::ThreadCondition::timedWait(WTF::Mutex&, double)
( f04f40) pc: 48153448 lr: 48153508 sp: f04f44
JSC::BlockAllocator::waitForRelativeTimeWhileHoldingLock(double)
( f04f60) pc: 481534d8 lr: 4815358c sp: f04f64
JSC::BlockAllocator::waitForRelativeTime(double)
( f04f84) pc: 48153558 lr: 4815374c sp: f04f88
JSC::BlockAllocator::blockFreeingThreadMain()
( f04f94) pc: 48153740 lr: 483cb76c sp: f04f98
JSC::BlockAllocator::blockFreeingThreadStartFunc(void*)
( f04fb0) pc: 483cb724 lr: 483e40b8 sp: f04fb4
WTF::threadEntryPoint(void*)
( f04fc4) pc: 483e4098 lr: 4ba5e504 sp: f04fc8
WTF::wtfThreadEntryPoint(void*)
( f04fd4) pc: 4ba5e4ec lr: 60 sp: f04fd8 __pthread_create()


Thread 0x61d248 (Main Thread)
( f06b3c) pc: 4ba6100c lr: 4a48967c sp: 1006d00
__pthread_yield_return()
( 1006d0c) pc: 4ba60f74 lr: 4a48967c sp: 1006d10 pthread_yield()
( 1006d20) pc: 4a489640 lr: 4a489c78 sp: 1006d24
QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
( 1006d68) pc: 4a489b70 lr: 4b1a56a0 sp: 1006d6c
QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)
( 1006db4) pc: 4b1a5420 lr: 4593c sp: 1006db8 QDialog::exec()
( 1006fec) pc: 45398 lr: 4ba94844 sp: 1006ff0 main()

Chris.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] UnixLib and ARMv8

On 05/03/16 17:23, Theo Markettos wrote:
> On Sat, Mar 05, 2016 at 04:06:12PM +0100, John Tytgat wrote:
>> On 03/01/2016 07:26 PM, Theo Markettos wrote:
>>> [...]
>>> I can do some implementation and testing, if this is deemed to be
>>> a good idea. ('testing' in a loose sense - provoking concurrency
>>> conditions being somewhat hard)
>>
>> FYI, UnixLib has some testing code in its 'test' subdirectory (incl.
>> pthread). It might be useful to verify nothing gets obviously
>> broken.
>
> Useful to know.

> I'll let Lee take the lead since he probably knows more than I about the
> internals, but let me know if you need help.

I've just committed some changes that determine whether to use SWP
or LDREX/STREX at runtime using the info that Ben posted as a guide.
Perhaps if you have a RPi3, you could see if Otter works?

I think the pthread testing code may need some work to bring it up
to date, plus all the tests need to be built with the -static flag, but
that's proving difficult to achieve.

Lee.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: Updated RISC OS !Run file

In message <555edef345webpages@sprow.co.uk>
Sprow <webpages@sprow.co.uk> wrote:

>In article <dc3edc5e55.DaveMeUK@my.inbox.com>,
> Dave Higton <dave@davehigton.me.uk> wrote:
>> The checks for 5 of the modules that are distributed with NS are
>> out of date.
>
>Rather than pointing at mirrors of the old Acorn FTP site and dregs of the
>Iyonix site, you can get SharedCLib, CallASWI and DrawFile from the !System
>archive on ROOL's download page all in one hit.

Good point. I've amended them too. I wan't sure whether to assume
that anything that doesn't have them must be pre-RO5 so I've just
given the URL of the misc downloads page rather than a particular
archive there.

>Also, typo "verson" slipped in,

Been there for ages, but fixed too.

Thanks for your review!

OK, devs, it's over to you for consideration for inclusion in 3.5.

Dave

____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!

Re: Missing images

On 11 Mar 2016 John Rickman Iyonix <rickman@argonet.co.uk> wrote:

> Peter Young wrote

>> On 10 Mar 2016 Peter Slegg <p.slegg@scubadivers.co.uk> wrote:

>>> Using the recent Atari builds on this newspaper:

>>> http://www.express.co.uk/

>>> the first few images are displayed but when I scroll down, the
>>> rest are missing.

>> The same on RISC OS, with #3434.

> Works ok on my Iyonix 5.23 with #3434 images displayed right down to
> the bottom of the page.

Odd! Still doesn't work fully here. Same OS and same build on an
ARMX6.

Best wishes,

Peter.

--
Peter Young (zfc Os) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Re: Missing images

Peter Young wrote

> On 10 Mar 2016 Peter Slegg <p.slegg@scubadivers.co.uk> wrote:

>> Using the recent Atari builds on this newspaper:

>> http://www.express.co.uk/

>> the first few images are displayed but when I scroll down, the
>> rest are missing.

> The same on RISC OS, with #3434.

Works ok on my Iyonix 5.23 with #3434 images displayed right down to
the bottom of the page.


--
John Rickman - http://rickman.orpheusweb.co.uk/lynx
Nothing in this world is to be feared... only understood. Marie Curie

Re: Missing images

On 10 Mar 2016 Peter Slegg <p.slegg@scubadivers.co.uk> wrote:

> Using the recent Atari builds on this newspaper:

> http://www.express.co.uk/

> the first few images are displayed but when I scroll down, the
> rest are missing.

> Currently using build 3434 but this has been the case for a few weeks.
> I wondered if it is a time-out issue perhaps ?

The same on RISC OS, with #3434.

Best wishes,

Peter.

--
Peter Young (zfc Os) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Re: Updated RISC OS !Run file

In article <dc3edc5e55.DaveMeUK@my.inbox.com>,
Dave Higton <dave@davehigton.me.uk> wrote:
> The checks for 5 of the modules that are distributed with NS are
> out of date.

Rather than pointing at mirrors of the old Acorn FTP site and dregs of the
Iyonix site, you can get SharedCLib, CallASWI and DrawFile from the !System
archive on ROOL's download page all in one hit.

Also, typo "verson" slipped in,
Sprow.

Updated RISC OS !Run file

Attached is an updated RISC OS !Run file for your consideration.

The checks for 5 of the modules that are distributed with NS are
out of date. Rather than pointing failures at dead links, we
should get the user to update the computer's !System.

Bearing in mind a recent user's mishap, I've worded it so as to
try to head off such activity... anyway, read it and you'll see,
but if anyone can think of less clumsy wording, I'll happily
accept it!

Dave

____________________________________________________________
Receive Notifications of Incoming Messages
Easily monitor multiple email accounts & access them with a click.
Visit http://www.inbox.com/notifier and check it out!

Missing images

Using the recent Atari builds on this newspaper:

http://www.express.co.uk/

the first few images are displayed but when I scroll down, the
rest are missing.

Currently using build 3434 but this has been the case for a few weeks.
I wondered if it is a time-out issue perhaps ?


Peter

Re: Atari front end

Hello Michael,

Am Donnerstag, den 10.03.2016, 19:34 +0000 schrieb Michael Drake:
> Are there any Atari users around?
>
> Could you let us know if the current m5475 and m68k builds are working?
>
> http://ci.netsurf-browser.org/builds/atari/?C=M;O=D

I tried the m68k version. Rendering and JS seems to work fine. GUI
actions work fine, all the windows (history, cookies, bookmarks,
browser) show up and do their job. Except verbose-log, selecting the
menu entry "verbose log" without having started netsurf from the
console, causes a crash.

I did NOT test network access. Browsing local files works fine.

Greets,
Ole

Atari front end

Are there any Atari users around?

Could you let us know if the current m5475 and m68k builds are working?

http://ci.netsurf-browser.org/builds/atari/?C=M;O=D


--
Michael Drake http://www.netsurf-browser.org/

Re: [gccsdk] Shared library code and modules

On Tue, 08 Mar 2016 22:30:43 -0000, Theo Markettos <theo@markettos.org.uk> wrote:

> On Tue, Mar 08, 2016 at 06:33:23PM +0000, Lee Noar wrote:
>> If you wanted to execute the library code in USR mode after being called
>> in SVC mode from a SWI, then you would have to set up the C environment
>> first, ie, stack, sp, sl, fp, malloc, stdio, etc.
>
> Hmm, yes, it does look more complicated than I thought. Unwinding the SVC stack to the point of SVC entry you could do (would have to know how
> far down it takes to call into your SWI handler, somewhat fragile)

Indeed - the layout of the SVC stack (effectively the stack frame layout
used by the kernel) has changed in the past and it's entirely possible that
it will have to change again in future. There's also the nasty complication
of what happens if you get nested SWI calls; the inner one can't be
expected how to unwind the outer one safely in order to flatten the SVC
stack and drop out to USR mode.

There's a more insidious problem with this approach though, and that's that
you'll end up skipping callbacks (both transient and non-transient) if you
attempt to drop out to USR mode directly within your SWI handler instead of
returning to the kernel and letting it do the return for you. Depending on
the nature of the code - particularly if it is spending most of the CPU
time making calls to that library - that could have a catastrophic effect
on callback latency, with all sorts of unpredictable side-effects.

A better way would be to use the non-transient callback handler to override
the USR mode registers that are restored at the end of the kernel's SWI and
IRQ dispatcher return code. But there's a drawback that RISC OS only
supports one of these being installed at once, so for example you would
experience trouble running such code under TaskWindow, or with code that
calls Wimp_Poll, both of which rely on non-transient callback handlers.
Ideally, the kernel shouldn't be farming out responsibility for USR mode
switching like that, because no single non-transient callback handler can
have knowledge of all other programs in the system that are also queuing up
for a context change. But to fix that would require the kernel to understand
process state, whilst at the moment that's all private to the Wimp. The
move started in RISC OS 3.7, with OS_AMBControl, but it remains unfinished
business.

If you want a degree of "kernel mode" threading, I'd point you at the
RTSupport module, which supports multiple threads each with their own stack
chunk chain, sl, sp etc. It does this using SYS mode though, so if your
main motivation is memory protection (which I think it is) then that won't
help you.

Ben

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] Shared library code and modules

In message <56DEF637.9040509@sky.com>
on 8 Mar 2016 Lee Noar wrote:

> The shared library system relies on each client having a few words of
> workspace located at &8034 (after the ELF header). This means that the
> location of the workspace is constant, but the contents can be
> different for each client.
>
> Unfortunately, this does rule out its use in modules.

Thanks for the reply: this is certainly way beyond me! Good luck to Theo in
staring hard at stuff...

Matthew

--
Matthew Phillips
Durham

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] Shared library code and modules

On Tue, Mar 08, 2016 at 06:33:23PM +0000, Lee Noar wrote:
> On 08/03/16 16:41, Theo Markettos wrote:
> >How feasible would it be to add another initialisation/entry method that made use
> >of a different shared data location?
>
> Well, it's not just that. A module would also be missing the ELF bits
> that make dynamic linking possible, such as the Global Offset Table
> (GOT), the Procedure Linkage Table (PLT) and the dynamic symbol table.

I was thinking of a RunDll kind of interface, ie start, dlopen(), dlsym()
and then call the function pointer. I imagine the tricky part is getting
the data areas initialised, particularly when you don't necessarily have
rights to assume things about the client's memory.

> If you wanted to execute the library code in USR mode after being called
> in SVC mode from a SWI, then you would have to set up the C environment
> first, ie, stack, sp, sl, fp, malloc, stdio, etc.

Hmm, yes, it does look more complicated than I thought. Unwinding the SVC
stack to the point of SVC entry you could do (would have to know how far
down it takes to call into your SWI handler, somewhat fragile), but sl you
couldn't necessarily infer unless you trusted the caller to provide its own
stack. fp could be fixed up. stdio might be tricky. And malloc is a pain
because you can't allocate anything in the user process' memory - it would
probably need a dynamic area with its own allocator.

> >Can you point me in the direction of the documentation of the shared library
> >system? I think we probably ought to have a wiki page with at the very
> >least pointers to what can be found where - I'm happy to write such a thing
> >if you point in the right direction.
>
> gcc4/riscos/soloader/dist/!SharedLibs/docs/Technical
>
> in the source tree.

Thanks. I think I ought to stare at them and think about the issues in more
detail.

Theo

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] Shared library code and modules

On 08/03/16 16:41, Theo Markettos wrote:
> On Tue, Mar 08, 2016 at 03:56:39PM +0000, Lee Noar wrote:
>> The shared library system relies on each client having a few words of
>> workspace located at &8034 (after the ELF header). This means that the
>> location of the workspace is constant, but the contents can be
>> different for each client.
>>
>> Unfortunately, this does rule out its use in modules.
>
> How feasible would it be to add another initialisation/entry method that made use
> of a different shared data location?

Well, it's not just that. A module would also be missing the ELF bits
that make dynamic linking possible, such as the Global Offset Table
(GOT), the Procedure Linkage Table (PLT) and the dynamic symbol table.

> The other problem is that the pre-existing SecureSockets SWI interface means
> an entry point would be in supervisor mode, so some mode switching would be
> required. What I was trying to explore was how tricky that would be,
> assuming a synchronous SWI interface is required (ie can't just schedule a
> callback and call the user mode library later). Can a SWI call out to user
> mode, do some work and return to the caller via SVC mode, without getting
> the SWI context confused? Or can a SWI call drop into user mode code and
> fix up the stack and return address so it returns direct to the caller
> without going back up to SVC mode?

If you wanted to execute the library code in USR mode after being called
in SVC mode from a SWI, then you would have to set up the C environment
first, ie, stack, sp, sl, fp, malloc, stdio, etc.

> Can you point me in the direction of the documentation of the shared library
> system? I think we probably ought to have a wiki page with at the very
> least pointers to what can be found where - I'm happy to write such a thing
> if you point in the right direction.

gcc4/riscos/soloader/dist/!SharedLibs/docs/Technical

in the source tree.

Lee.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] Shared library code and modules

On Tue, Mar 08, 2016 at 03:56:39PM +0000, Lee Noar wrote:
> The shared library system relies on each client having a few words of
> workspace located at &8034 (after the ELF header). This means that the
> location of the workspace is constant, but the contents can be
> different for each client.
>
> Unfortunately, this does rule out its use in modules.

How feasible would it be to add another initialisation/entry method that made use
of a different shared data location?

The other problem is that the pre-existing SecureSockets SWI interface means
an entry point would be in supervisor mode, so some mode switching would be
required. What I was trying to explore was how tricky that would be,
assuming a synchronous SWI interface is required (ie can't just schedule a
callback and call the user mode library later). Can a SWI call out to user
mode, do some work and return to the caller via SVC mode, without getting
the SWI context confused? Or can a SWI call drop into user mode code and
fix up the stack and return address so it returns direct to the caller
without going back up to SVC mode?

Can you point me in the direction of the documentation of the shared library
system? I think we probably ought to have a wiki page with at the very
least pointers to what can be found where - I'm happy to write such a thing
if you point in the right direction.

Theo

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] Shared library code and modules

On 07/03/16 23:13, Matthew Phillips wrote:
> There is a thread running on the ROOL forum regarding SecureSockets, a ratehr
> elderly module which provides a SWI interface for SSL/TLS communication:
> https://www.riscosopen.org/forum/forums/5/topics/3955?page=1
>
> As part of the discussion it was suggedted by Theo that the best way to
> update SecureSockets would be to write a shim module which would link to a
> shared library port of OpenSSL or similar. This would have the advantage that
> the security code in the preferred library could easily be updated without
> rebuilding the module.
>
> Is such an approach possible? I have very little understanding of how the
> shared library ELF loader works, and the thread has now got diverted onto
> whether German ISPs insist on a more recent SSL version than SecureSockets
> supports.
>
> Is there a good guide to what really happens behind the scenes when a shared
> library is loaded? I don't even know what memory space these things live in.

The shared library system relies on each client having a few words of
workspace located at &8034 (after the ELF header). This means that the
location of the workspace is constant, but the contents can be
different for each client.

Unfortunately, this does rule out its use in modules.

Lee.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

[gccsdk] Shared library code and modules

There is a thread running on the ROOL forum regarding SecureSockets, a ratehr
elderly module which provides a SWI interface for SSL/TLS communication:
https://www.riscosopen.org/forum/forums/5/topics/3955?page=1

As part of the discussion it was suggedted by Theo that the best way to
update SecureSockets would be to write a shim module which would link to a
shared library port of OpenSSL or similar. This would have the advantage that
the security code in the preferred library could easily be updated without
rebuilding the module.

Is such an approach possible? I have very little understanding of how the
shared library ELF loader works, and the thread has now got diverted onto
whether German ISPs insist on a more recent SSL version than SecureSockets
supports.

Is there a good guide to what really happens behind the scenes when a shared
library is loaded? I don't even know what memory space these things live in.

Thanks,

Matthew

--
Matthew Phillips
Durham

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] UnixLib and ARMv8

On Sat, Mar 05, 2016 at 04:06:12PM +0100, John Tytgat wrote:
> On 03/01/2016 07:26 PM, Theo Markettos wrote:
> >[...]
> >I can do some implementation and testing, if this is deemed to be
> >a good idea. ('testing' in a loose sense - provoking concurrency
> >conditions being somewhat hard)
>
> FYI, UnixLib has some testing code in its 'test' subdirectory (incl.
> pthread). It might be useful to verify nothing gets obviously
> broken.

Useful to know.

I'll let Lee take the lead since he probably knows more than I about the
internals, but let me know if you need help.

Theo

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: NetSurf 3.5 release

In article <20160304093519.GC30707@kyllikki.org>,
Vincent Sanders <vince@netsurf-browser.org> wrote:
> So the 3.4 release was a bit of a lemon and due to lack of testing
> appears to have been non functional on most supported platforms

> Because of this I will be aiming for a 3.5 release on 12th March 2016.

> Please can all front end maintainers ensure they are confident with
> the state of their implementations before this date.

> The toolchains have been updated for this release to include the
> recent openssl critical fixes, however this has resulted in the amiga
> frontendusing a new toolchain for this release

> Can the amiga maintainers please ensure this toolchain change was what
> they wanted and let us know if we need to back it out as soon as
> possible.

> One final plea. Making a release is a lot of work and generally
> devolves to me, there is a wiki page for the release [1] can other
> mainatiners add anything they are aware of and help get it fixed so
> this release is not another complete stuff up and I can actually
> announce this one!

> [1] http://wiki.netsurf-browser.org/NetSurf_3.5

Something to be aware of. With the recent release of RISC OS running on the
RaspBerry Pi 3 anything linked with the Unixlib library crashes on start
up. This is due to the SWP/B instructions no longer existing in ARMv8. They
are used in a few places in Unixlib.
I believe a fix is being worked on but I'm not sure how long it will take.

--
Email: chrisg@care4free.net

Re: unresizable web page (last bank standing)

In article <89691e5c55.jim@abbeypress.net>, Jim Nagel
<netsurf@abbeypress.co.uk> wrote:
> Richard Ashbery wrote on 5 Mar:
> > Now downloaded C1 #3433 and image displays correctly. Resizing
> > enlarges picture as expected. Text remains same size.

> Yes, here too, having newly updated to #3433. So thanks to the
> Netsurf team for correcting whatever it was.

Would problem be associated with one of the third party apps.

I always use Fetch_NS to retrieve the latese NS release which I
suspect does the third party installation as well. I've just realised
I'm using an older Fetch_NS than I should - must update this.


Is there anyway of getting into the NASA site? All I get is a blank
page - presumably because it is Javascript rich Grhhh :-(

Richard
NS C1 #3433

Re: unresizable web page (last bank standing)

In article <89691e5c55.jim@abbeypress.net>,
Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> Richard Ashbery wrote on 5 Mar:
> > Now downloaded C1 #3433 and image displays correctly. Resizing
> > enlarges picture as expected. Text remains same size.

> Yes, here too, having newly updated to #3433.

Same here, looks to be perfect.

> So thanks to the Netsurf team for correcting whatever it was.

[snip]

Re: [gccsdk] UnixLib and ARMv8

On 03/01/2016 07:26 PM, Theo Markettos wrote:
> [...]
> I can do some implementation and testing, if this is deemed to be a
> good idea. ('testing' in a loose sense - provoking concurrency
> conditions being somewhat hard)

FYI, UnixLib has some testing code in its 'test' subdirectory (incl.
pthread). It might be useful to verify nothing gets obviously broken.

John.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: unresizable web page (last bank standing)

Richard Ashbery wrote on 5 Mar:
> Now downloaded C1 #3433 and image displays correctly. Resizing
> enlarges picture as expected. Text remains same size.

Yes, here too, having newly updated to #3433. So thanks to the
Netsurf team for correcting whatever it was.

(Now if only the Lloyds suits will be so cooperative, they will be the
last bank standing in this town and could mop up all the customers the
other three banks have deserted.)


--
Jim Nagel www.archivemag.co.uk
Glastonbury

Re: unresizable web page (last bank standing)

In article <d47bc75b55.DaveMeUK@my.inbox.com>, Dave Higton
<dave@davehigton.me.uk> wrote:
> In message <555bc1e2c8tim@timil.com> Tim Hill <tim@timil.com> wrote:

> > In article <f7788d5b55.jim@abbeypress.net>, Jim Nagel
> > <netsurf@abbeypress.co.uk> wrote:
> > > Is it something about the coding of this site or about
> > > Netsurf's rendering of it? Or maybe it's in the CSS of the
> > > page?
> >
> > > https://www.change.org/p/last-bank-standing-don-t-let-communities-lose-their-only-bank
> >
> >
> > > The picture displays so huge as to be unrecognizable pixels;
> > > paragraphs of text are a single line so wide that they are
> > > unreadable.
> >
> > > Resizing the Netsurf window (even with Ctrl on the Resize icon)
> > > does nothing but make the font smaller -- text remains a single
> > > line.
> >
> > > Using Netsurf #3382 on Ro 5.23.
> >
> > 3403 on 5.18 looks 'okay'. Though not perfect, it doesn't do what
> > you describe and is legible.

> It works fine with CI #3433. The image adjusts to fit the width of

3305 displays the picture correctly but when I tried yesterday
it displayed exactly as Jim described. Weird :-(

Now downloaded C1 #3433 and image displays correctly. Resizing enlarges
picture as expected. Text remains same size.

Richard

Iyonix RISC OS 5.20

Re: NetSurf 3.5 release

On Fri, 4 Mar 2016 09:35:19 +0000, Vincent Sanders wrote:

> The toolchains have been updated for this release to include the
> recent openssl critical fixes, however this has resulted in the amiga
> frontendusing a new toolchain for this release
>
> Can the amiga maintainers please ensure this toolchain change was what
> they wanted and let us know if we need to back it out as soon as
> possible.

Probably would have been better if it had been left until after this
release, however I've been using NetSurf built with gcc 5.3 and the
same patches for a couple of months with no problems - it's only
really the integration into the NetSurf toolchain which is new.

CI#3433 is working fine so I suggest sticking with it.

Chris

Re: unresizable web page (last bank standing)

In message <555bc1e2c8tim@timil.com>
Tim Hill <tim@timil.com> wrote:

> In article <f7788d5b55.jim@abbeypress.net>, Jim Nagel
> <netsurf@abbeypress.co.uk> wrote:
> > Is it something about the coding of this site or about Netsurf's
> > rendering of it? Or maybe it's in the CSS of the page?
>
> > https://www.change.org/p/last-bank-standing-don-t-let-communities-lose-their-only-bank
>
>
> > The picture displays so huge as to be unrecognizable pixels; paragraphs
> > of text are a single line so wide that they are unreadable.
>
> > Resizing the Netsurf window (even with Ctrl on the Resize icon) does
> > nothing but make the font smaller -- text remains a single line.
>
> > Using Netsurf #3382 on Ro 5.23.
>
> 3403 on 5.18 looks 'okay'. Though not perfect, it doesn't do what you
> describe and is legible.

It works fine with CI #3433. The image adjusts to fit the width
of the window, minus a small margin each side. This is the first
time I can remember NS doing so.

Dave

____________________________________________________________
Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
Check it out at http://mysecurelogon.com/password-manager

Re: unresizable web page (last bank standing)

In article <f7788d5b55.jim@abbeypress.net>, Jim Nagel
<netsurf@abbeypress.co.uk> wrote:
> Is it something about the coding of this site or about Netsurf's
> rendering of it? Or maybe it's in the CSS of the page?

> https://www.change.org/p/last-bank-standing-don-t-let-communities-lose-their-only-bank


> The picture displays so huge as to be unrecognizable pixels;
> paragraphs of text are a single line so wide that they are unreadable.

> Resizing the Netsurf window (even with Ctrl on the Resize icon) does
> nothing but make the font smaller -- text remains a single line.

> Using Netsurf #3382 on Ro 5.23.

3403 on 5.18 looks 'okay'. Though not perfect, it doesn't do what you
describe and is legible.

--
Tim Hill
www.timil.com

web sites * multimedia * training

unresizable web page (last bank standing)

Is it something about the coding of this site or about Netsurf's
rendering of it? Or maybe it's in the CSS of the page?

https://www.change.org/p/last-bank-standing-don-t-let-communities-lose-their-only-bank


The picture displays so huge as to be unrecognizable pixels;
paragraphs of text are a single line so wide that they are unreadable.

Resizing the Netsurf window (even with Ctrl on the Resize icon) does
nothing but make the font smaller -- text remains a single line.

Using Netsurf #3382 on Ro 5.23.

===
(A propos the site cited, Barclays Bank closes its branch in this town
at this very moment. Natwest closed a year ago, HSBC a few months
ago. That leaves Lloyds. And Lloyds closes later this month.)

--
Jim Nagel www.archivemag.co.uk
Glastonbury

NetSurf 3.5 release

So the 3.4 release was a bit of a lemon and due to lack of testing
appears to have been non functional on most supported platforms

Because of this I will be aiming for a 3.5 release on 12th March 2016.

Please can all front end maintainers ensure they are confident with
the state of their implementations before this date.

The toolchains have been updated for this release to include the
recent openssl critical fixes, however this has resulted in the amiga
frontendusing a new toolchain for this release

Can the amiga maintainers please ensure this toolchain change was what
they wanted and let us know if we need to back it out as soon as
possible.

One final plea. Making a release is a lot of work and generally
devolves to me, there is a wiki page for the release [1] can other
mainatiners add anything they are aware of and help get it fixed so
this release is not another complete stuff up and I can actually
announce this one!

[1] http://wiki.netsurf-browser.org/NetSurf_3.5

--
Regards Vincent
http://www.kyllikki.org/

Re: [Rpcemu] Large files in HostFS was Re. RPCEmu Mac OS X test build of 0.8.14

Hi,

In article <20160219203733.GA16763@spod.org>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> On Tue, Feb 16, 2016 at 05:52:36PM +0000, Sprow wrote:
> > In article <20160216173419.GA20045@spod.org>,
> > > For the long explanation of why this HostFS patch is not included in
> > > RPCEmu, please see this post from 2011.
> > >
> > > http://www.riscos.info/pipermail/rpcemu/2011-October/001383.html
> >
> > I recall that discussion at the time, and the thread continued
> > http://www.riscos.info/pipermail/rpcemu/2011-October/001384.html
> > then fell silent.
>
> Unfortuanately it is not harmless on OSes < 5.20 nor harmless on >= 5.20.
>
> At this time it seems to be important to state the requirements that
> HostFS should have. These may only have been implicit before.
>
> 1) HostFS needs to work on all versions of RISC OS that RPCEmu can run (at
> least 3.5, possibly even 3.1 for arcem support).
> 2) RPCEmu users can place any size file in their HostFS directory on the
> Host Side, and HostFS must handle this gracefully.
> 3) HostFS should protect RPCEmu user's data from loss or corruption.
>
> One specific case discussed here of 3) is that allowing files to be opened
> that are larger than the maximum size that RO supports risks data loss, as
> a program can only work on only some of the data in a file, which can cause
> corruption.

I think we've come full circle now, because it was when I spotted that RPCEmu
was causing loss and corruption that I traced the problem to HostFS not
implementing 4GB files properly.

> Here follows a table describing the current situation in RPCEmu.
> I have used the phrase 'Data Safe' to represent that they don't allow
> files to be opened that are larger than OS supports.
>
> 32bit builds 64bit builds
>
> RO 3,4,6 Data Safe (2GB filesize limit) Data Unsafe (no filesize limit)
> RO 5 Data Safe (2GB filesize limit) Data Unsafe (no filesize limit)
>
> This is the effect your patch has:
>
> 32bit builds 64bit builds
>
> RO 3,4,6 Data Unsafe (no filesize limit) Data Unsafe (no filesize limit)
> RO 5 Data Unsafe (no filesize limit) Data Unsafe (no filesize limit)

I used the following simple test program

*Create test 7FFFFFF0
F=OPENUP"test"
IFF=0 THENPRINT"Where's it gone?":END
PRINT~EXT#F
PTR#F=EXT#F
BPUT#F,"The quick brown fox jumps over the lazy dog"
PRINT~EXT#F
CLOSE#F

I only checked with RISC OS 3.71 (since you'd grouped it with 4 & 6, I'd tend
to agree they'll behave the same) and RISC OS 5.22.

With a vanilla 0.8.14 download I get
RO 3.71 Written data is lost, file remains at &7FFFFFF0.
RO 5.22 Written data is lost, but extent is reported at &8000001C,
file on host disc is now &80000400. Attempting to *DUMP the data
carries on beyond &80000400 because EOF is never reported.

With 0.8.14 with my HostFS patch applied
RO 3.71 Written data is lost, file remains at &7FFFFFF0.
RO 5.22 Written data is saved, file is now &8000001C.

No doubt other more complex edge cases can be dreamed up, I just picked an
easy one to do in BASIC here.

Casual inspection of hostfs.c suggests that there's no extra code in there to
guard against case (3) it's just a happy coincidence that the original file
I/O functions were limited to 2GB, and RISC OS had problems above 2GB.

You're quite right about (2) in that a file parachuted in from outside the
emulator could cause confusion (larger than 2GB for 3,4,6; larger than 4GB
for 5) but I've managed not to do that in 4 years of using the patch,
Sprow.


_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [gccsdk] UnixLib and ARMv8

On 01/03/16 15:42, Ben Avison wrote:
> Hi folks,
>
> As you'll probably have heard, Raspberry Pi have launched a new board based
> on the ARMv8 Cortex-A53.
>
> One of the main compatibility issues remaining is that anything built on
> UnixLib is rather unlikely to work. I did a bit of investigating and found
> the problem was with the use of SWP in __pthread_disable_ints in
> libunixlib/pthread/_ints.s (although the lack of pushing a stack frame
> means that blame will be attributed elsewhere in backtraces). There are a
> couple of other instances of SWP elsewhere in UnixLib.
>
> Now, we're now living in a world where there is no one simple code sequence
> which can do atomic operations from USR mode across all CPUs from ARMv2(a)
> to ARMv8. A crude solution would be to replace
>
> LDR a1, .L0 @=__ul_global
> PICEQ "LDR a1, [a2, a1]"
> ADD a1, a1, #GBL_PTH_WORKSEMAPHORE
> MOV a3, #1
> SWP a2, a3, [a1]
> @ From this point onwards we will not be interrupted by the callback
> ADD a2, a2, #1
> STR a2, [a1]
> MOV pc, lr
>
> with something like
>
> LDR a1, .L0 @=__ul_global
> PICEQ "LDR a1, [a2, a1]"
> ADD a3, a1, #GBL_PTH_WORKSEMAPHORE
> MOV a1, #0
> SWI XOS_ReadPlatformFeatures
> MOVVS a1, #0
> TST a1, #1<<12 @ does the CPU support LDREX?
> BNE 1f
> @ SWP version
> MOV a1, #1
> SWP a2, a1, [a3]
> @ From this point onwards we will not be interrupted by the callback
> ADD a2, a2, #1
> STR a2, [a3]
> MOV pc, lr
> 1: @ LDREX version
> LDREX a2, [a3]
> ADD a2, a2, #1
> STREX a1, a2, [a3]
> TEQ a1, #1
> BEQ 1b
> MOV pc, lr
>
> and something similar for the other instances of SWP. However, I can't help
> thinking it would be neater to do the ReadPlatformFeatures once somewhere
> very early on in library initialisation and store the result in library
> static data somewhere. This is where I suspect my lack of knowledge of
> UnixLib internals means that I expect someone more familiar with it could
> knock up a solution far quicker - so, any takers?

Yes, I'll have a go when I get a chance. Thanks for the sample code,
that should make it easier.

Lee.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] UnixLib and ARMv8

On Tue, Mar 01, 2016 at 03:42:55PM -0000, Ben Avison wrote:
> and something similar for the other instances of SWP. However, I can't help
> thinking it would be neater to do the ReadPlatformFeatures once somewhere
> very early on in library initialisation and store the result in library
> static data somewhere. This is where I suspect my lack of knowledge of
> UnixLib internals means that I expect someone more familiar with it could
> knock up a solution far quicker - so, any takers?

We could put a bit in ul_global and have the __pthread_prog_init code set it
up, in the absence of better places? I'm not particularly au fait with the
Unixlib code either, so open to better solutions.

I can do some implementation and testing, if this is deemed to be a good idea.
('testing' in a loose sense - provoking concurrency conditions being somewhat
hard)

It does mean rebuilding Unixlib static-linked programs, since it isn't in
the tiny part of code that lives in SharedUnixLib. That's a bit of a pain,
but easier for the things we have autobuilt and packaged.

Theo

_______________________________________________
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] UnixLib and ARMv8

Hi folks,

As you'll probably have heard, Raspberry Pi have launched a new board based
on the ARMv8 Cortex-A53.

One of the main compatibility issues remaining is that anything built on
UnixLib is rather unlikely to work. I did a bit of investigating and found
the problem was with the use of SWP in __pthread_disable_ints in
libunixlib/pthread/_ints.s (although the lack of pushing a stack frame
means that blame will be attributed elsewhere in backtraces). There are a
couple of other instances of SWP elsewhere in UnixLib.

Now, we're now living in a world where there is no one simple code sequence
which can do atomic operations from USR mode across all CPUs from ARMv2(a)
to ARMv8. A crude solution would be to replace

LDR a1, .L0 @=__ul_global
PICEQ "LDR a1, [a2, a1]"
ADD a1, a1, #GBL_PTH_WORKSEMAPHORE
MOV a3, #1
SWP a2, a3, [a1]
@ From this point onwards we will not be interrupted by the callback
ADD a2, a2, #1
STR a2, [a1]
MOV pc, lr

with something like

LDR a1, .L0 @=__ul_global
PICEQ "LDR a1, [a2, a1]"
ADD a3, a1, #GBL_PTH_WORKSEMAPHORE
MOV a1, #0
SWI XOS_ReadPlatformFeatures
MOVVS a1, #0
TST a1, #1<<12 @ does the CPU support LDREX?
BNE 1f
@ SWP version
MOV a1, #1
SWP a2, a1, [a3]
@ From this point onwards we will not be interrupted by the callback
ADD a2, a2, #1
STR a2, [a3]
MOV pc, lr
1: @ LDREX version
LDREX a2, [a3]
ADD a2, a2, #1
STREX a1, a2, [a3]
TEQ a1, #1
BEQ 1b
MOV pc, lr

and something similar for the other instances of SWP. However, I can't help
thinking it would be neater to do the ReadPlatformFeatures once somewhere
very early on in library initialisation and store the result in library
static data somewhere. This is where I suspect my lack of knowledge of
UnixLib internals means that I expect someone more familiar with it could
knock up a solution far quicker - so, any takers?

Ben

_______________________________________________
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