Sunday, 31 December 2017

[Rpcemu] v 0,8.100

I now realise I needed to configure HostFS, install a ROM and a !BOOT,
Perhaps copying HostFS from this version was not the wisest thing.
I dont seem to have a Network conexion or access to CD.

Chris

--
chris.j.craig@btinternet.com
Rpcemu V 0.8.14 RISC OS 5.22

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

[Rpcemu] v0.8.100

On starting the new version I get

Error: Use *Desktop to start TaskManager

I do not know what to do here?

I have copied my 5.22 rom.

I tried typing *config. filesystem hostfs
and Config. boot
but it saw disc unknown?

Any help gratefully received

Chris
--
chris.j.craig@btinternet.com
Rpcemu RISC OS 5.22

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

Re: [Rpcemu] RPCEmu pre release test version 0.8.100

Also just noticed that HostFS access crashes the recompiler except for CPU=StrongARM but it's not a regression as it does so in 0.8.15 as well. Think you must already be aware of it - is there a list of known issues somewhere?

Regards,
James

On 31 December 2017 at 12:56, J Percival <perciv.js@gmail.com> wrote:
Great work on the new version!
All fixes mentioned on the webpage seem to work except for the Alt-Handling. The menus are no longer accessed accidentally but it seems the key is now also ignored in the emulated system.
I noticed this when trying to strafe in !Doom but it's easier to see just by pressing F12 from RiscOS and hitting Alt-A which should produce an 'ae' character.

I also noticed that Escape didn't work on the first run but that may well have been caused by my antivirus delaying execution or messing something up. I haven't been able to reproduce it in any case.

Regards,
James

On 30 December 2017 at 22:19, Peter Howkins <rpcemu.howkins@marutan.net> wrote:
This is the second test release of RPCEmu based on the wide ranging
changes made for qt5.

https://www.marutan.net/rpcemu/testing/

Please test this version as thoroughly as possible, and if you previously
reported an issue with 0.8.99 and it is listed below, please test and
confirm it is fixed.

 - HostFS now working on Windows build.
 - Crash bug caused by dragging window to bottom of screen fixed.
 - Disable some keyboard shortcuts in the frontend. Allows them to be
   passed to the emulated OS and fixes issue where 'alt' key seemed to get
   stuck down.
 - Syncclock module not included in default distribution, please check
   for clock drift.
 - Mouse will work when changing between A7000 and RPC modes without
   having to rerun RPCEmu.
 - UI will no longer report 'I need to reboot' when changing VRAM
   settings of machines that don't have VRAM (A7000/A7000+/Phoebe).

For further information and downloads please visit

https://www.marutan.net/rpcemu/testing/

Matthew Howkins
Peter Howkins

--
Peter Howkins
peter.howkins@marutan.net

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


Re: [Rpcemu] RPCEmu pre release test version 0.8.100

Great work on the new version!
All fixes mentioned on the webpage seem to work except for the Alt-Handling. The menus are no longer accessed accidentally but it seems the key is now also ignored in the emulated system.
I noticed this when trying to strafe in !Doom but it's easier to see just by pressing F12 from RiscOS and hitting Alt-A which should produce an 'ae' character.

I also noticed that Escape didn't work on the first run but that may well have been caused by my antivirus delaying execution or messing something up. I haven't been able to reproduce it in any case.

Regards,
James

On 30 December 2017 at 22:19, Peter Howkins <rpcemu.howkins@marutan.net> wrote:
This is the second test release of RPCEmu based on the wide ranging
changes made for qt5.

https://www.marutan.net/rpcemu/testing/

Please test this version as thoroughly as possible, and if you previously
reported an issue with 0.8.99 and it is listed below, please test and
confirm it is fixed.

 - HostFS now working on Windows build.
 - Crash bug caused by dragging window to bottom of screen fixed.
 - Disable some keyboard shortcuts in the frontend. Allows them to be
   passed to the emulated OS and fixes issue where 'alt' key seemed to get
   stuck down.
 - Syncclock module not included in default distribution, please check
   for clock drift.
 - Mouse will work when changing between A7000 and RPC modes without
   having to rerun RPCEmu.
 - UI will no longer report 'I need to reboot' when changing VRAM
   settings of machines that don't have VRAM (A7000/A7000+/Phoebe).

For further information and downloads please visit

https://www.marutan.net/rpcemu/testing/

Matthew Howkins
Peter Howkins

--
Peter Howkins
peter.howkins@marutan.net

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

Saturday, 30 December 2017

[Rpcemu] RPCEmu pre release test version 0.8.100

This is the second test release of RPCEmu based on the wide ranging
changes made for qt5.

https://www.marutan.net/rpcemu/testing/

Please test this version as thoroughly as possible, and if you previously
reported an issue with 0.8.99 and it is listed below, please test and
confirm it is fixed.

- HostFS now working on Windows build.
- Crash bug caused by dragging window to bottom of screen fixed.
- Disable some keyboard shortcuts in the frontend. Allows them to be
passed to the emulated OS and fixes issue where 'alt' key seemed to get
stuck down.
- Syncclock module not included in default distribution, please check
for clock drift.
- Mouse will work when changing between A7000 and RPC modes without
having to rerun RPCEmu.
- UI will no longer report 'I need to reboot' when changing VRAM
settings of machines that don't have VRAM (A7000/A7000+/Phoebe).

For further information and downloads please visit

https://www.marutan.net/rpcemu/testing/

Matthew Howkins
Peter Howkins

--
Peter Howkins
peter.howkins@marutan.net

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

Monday, 25 December 2017

Re: [Rpcemu] Website problem

On Sun, Dec 24, 2017 at 05:28:39PM +0000, J Percival wrote:
> Just noticed that the security certificate seems to have expired on
> [1]https://www.marutan.net/

Resolved now.

Peter

--
Peter Howkins
peter.howkins@marutan.net

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

Sunday, 24 December 2017

Re: [Rpcemu] Website problem

Hi James,

> Hmm, I'm also using 57.0.2 but it says "This site uses HTTP Strict
> Transport Security (HSTS) to specify that Firefox only connect to it
> securely. As a result, it is not possible to add an exception for this
> certificate." Strange!

Yes, strange. I do see the `Strict-Transport-Security:
max-age=15552000' header in the HTTPS reply for `GET /'.

--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

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

Re: [Rpcemu] Website problem

Hmm, I'm also using 57.0.2 but it says "This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox only connect to it securely. As a result, it is not possible to add an exception for this certificate."
Strange!

On 24 December 2017 at 17:42, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
Hi James,

> https://www.marutan.net/ - Firefox won't even allow an exception to be
> added.

Just FYI, Firefox 57.0.2 does here.

--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

Re: [Rpcemu] Website problem

Hi James,

> https://www.marutan.net/ - Firefox won't even allow an exception to be
> added.

Just FYI, Firefox 57.0.2 does here.

--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

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

[Rpcemu] Website problem

Just noticed that the security certificate seems to have expired on https://www.marutan.net/ - Firefox won't even allow an exception to be added.

Regards,
James

Saturday, 23 December 2017

Re: [Rpcemu] Questions/issues

In message <ccd171ac56.Chris@btinternet.com>
Chris Craig <chris.j.craig@btinternet.com> wrote:

> A version of Aemulor would be nice to access old Impression documents

You just need to install a 26bit version of RISC OS (3,4,6) on RPCemu
then Impression will work fine :-)

Bryan.

--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/

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

Thursday, 21 December 2017

Sanitizing libnsbmp

I've been running libnsbmp under the LLVM sanitizers (particularly
UBSan), and I've found quite a few errors. Are you guys open to taking
patches to fix these issues (things like undefined shift overflows,
etc)? I didn't see much about the contribution process on the website.

Re: [Rpcemu] Questions/issues

Thanks very much for the link, Steffen!

On 21 December 2017 at 11:20, Steffen Huber <steffen@huber-net.de> wrote:
> J Percival <perciv.js@gmail.com> hat am 21. Dezember 2017 um 00:32 geschrieben:
>
>
> Great to hear about the fixes!
>
> I'm not sure about the shared-c-library but it would appear that:
> V4.85 is included with RO 3.71
> V5.53 was hosted on the iyonix site you linked (seems to be 26-bit judging
> from the webpage)
> V5.77 is included in UniBoot2 (maybe this one is 32-bit?)
> For what it's worth, !Doom is happy with either V5.53 or V5.77. I don't
> know if the later versions break things though.

The canonical source for the current SharedCLib for 26bit pre-RO5
systems is the ROOL website:
https://www.riscosopen.org/content/downloads/common
Download "System resources". It currently has SharedCLib 5.94 inside.
I use it all the time on my RO4 emulator systems, no problems found.

Have fun
hubersn

--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/

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

Re: [Rpcemu] Questions/issues

> J Percival <perciv.js@gmail.com> hat am 21. Dezember 2017 um 00:32 geschrieben:
>
>
> Great to hear about the fixes!
>
> I'm not sure about the shared-c-library but it would appear that:
> V4.85 is included with RO 3.71
> V5.53 was hosted on the iyonix site you linked (seems to be 26-bit judging
> from the webpage)
> V5.77 is included in UniBoot2 (maybe this one is 32-bit?)
> For what it's worth, !Doom is happy with either V5.53 or V5.77. I don't
> know if the later versions break things though.

The canonical source for the current SharedCLib for 26bit pre-RO5
systems is the ROOL website:
https://www.riscosopen.org/content/downloads/common
Download "System resources". It currently has SharedCLib 5.94 inside.
I use it all the time on my RO4 emulator systems, no problems found.

Have fun
hubersn

--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/

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

Wednesday, 20 December 2017

Re: [Rpcemu] Questions/issues

Great to hear about the fixes!

I'm not sure about the shared-c-library but it would appear that:
V4.85 is included with RO 3.71
V5.53 was hosted on the iyonix site you linked (seems to be 26-bit judging from the webpage)
V5.77 is included in UniBoot2 (maybe this one is 32-bit?)
For what it's worth, !Doom is happy with either V5.53 or V5.77. I don't know if the later versions break things though.

I can understand you wanting to keep the recommend install stuff to a minimum. I've never used a real Risc PC, only older Archimedes models, which is why I struggled a bit. Heh!
I'm not sure what the issue is with the MDFs. They do appear to be there under !Boot\Resources\Configure\Monitors\Acorn but I found that without the 'anymode' module only old-style numbered modes seemed to work and everything was grayed out in the Display Manager settings.

Looking forward to the next test version. I'll be sure to give it a try and see if I can find any other issues. Thanks for the quick reply!

Kind Regards,
James

On 20 December 2017 at 21:56, Peter Howkins <rpcemu.howkins@marutan.net> wrote:
On Mon, Dec 18, 2017 at 03:39:38PM +0000, J Percival wrote:
>    Hi there! Been using this great emulator for a while but have noticed some
>    issues. You're probably already aware of them but I thought I would
>    mention them anyway. These refer mainly to the 0.8.99 super-secret
>    pre-release.
>
>    Setup:
>    Windows 10/64-bit
>    V0.8.99 Interpreter
>    RISC OS 3.71
>    Configuration: 2/8MB VRAM, 32MB RAM, Sound Enabled
>    - HostFS shows as empty both from the desktop and command line. No
>    files/folders added via Windows or RISC OS appear even though it will
>    happily create them (ok on 0.8.15). I wondered if it might be a
>    permissions issue at first but that doesn't seem to be the case.

It was related to us not setting the correct character encoding in the
hostfs code, it was trying to use unicode. This has been fixed now.

>    - Keyboard handling problem after a menu is accessed via ALT (largely acts
>    like ALT gets stuck down afterwards) (ok on 0.8.15).

Yep, we spotted this very weird behaviour too, it's now been fixed.

>    - Graphical corruption when configured as RiscPC/ARM810.

This, I'm probably not going to investigated now, as ARM810 is very very
experimental code ... unless someone wants to give me an arm810 card I can
test against :)

>    - Starting as an A7000 model means mouse doesn't work when switched to a
>    RiscPC model and vice versa.

Ooh, well spotted, this is an 6 year old bug. I've got a fix in now. (this
is a fullscreen/mouse capture issue only, not 'follow host mouse')

>    - Configuration options let you try and set VRAM on an A7000 model at
>    which point it says it needs to restart (but doesn't do so

I've fixed this issue of the erroneous 'you must restart'.

> and then
>    indicates it being present until the emulator is closed and reloaded.
>    Maybe it would be better to have separate options provided and saved for
>    each machine type.

But I'm not going to fix this now, eventually I have a different idea
about how machines and models should be setup.

>    - In fullscreen mode there doesn't seem to be any way to switch back to
>    windowed mode. Selecting the fullscreen option again via ALT-S does
>    nothing and the conventional Windows Alt-Enter also has no effect. In
>    addition the menu bar doesn't show up when you press ALT, which is a minor
>    thing but could definitely confuse some people.

The keyboard shortcut for leaving fullscreen is crtl-end

>    Finally, a few difficulties I had with the emulator when I was starting
>    out:
>    Getting RISC OS up and running was easy enough but the universal-boot
>    provided on your website seems to be missing the Shared C Library. I ended
>    up using the 'UniBoot 2' version at
>    [1]https://www.retro-kit.co.uk/page.cfm/content/UniBoot-for-RISC-OS/
>    instead.

I presume you mean the 32-bit Shared C-Library? Which used to live at
http://www.iyonix.com/32bit/system.shtml
now
https://web.archive.org/web/20150412211454/http://www.iyonix.com/32bit/system.shtml

One reason I generally don't provide large amounts of pre-setup stuff as
theoretically the emulator is just like a real Risc PC in respect to
allowing people to pick the version of the OS and the software themselves.

Also, it's too hard to support everyone's issues with risc os in general.

>    I was then confused why I couldn't change the display mode in RISC OS
>    until I eventually remembered that the newer machines rely on monitor
>    definition files. Could these perhaps be provided with the emulator?

I believe all the boot sequences include the MDFs?


At some point soon, I'd like to roll a second test version (0.8.100) to
allow everyone to check their reported bugs are fixed now, and a second
chance to spot new ones.

Peter

--
Peter Howkins
peter.howkins@marutan.net

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

Re: [Rpcemu] Questions/issues

On Mon, Dec 18, 2017 at 03:39:38PM +0000, J Percival wrote:
> Hi there! Been using this great emulator for a while but have noticed some
> issues. You're probably already aware of them but I thought I would
> mention them anyway. These refer mainly to the 0.8.99 super-secret
> pre-release.
>
> Setup:
> Windows 10/64-bit
> V0.8.99 Interpreter
> RISC OS 3.71
> Configuration: 2/8MB VRAM, 32MB RAM, Sound Enabled
> - HostFS shows as empty both from the desktop and command line. No
> files/folders added via Windows or RISC OS appear even though it will
> happily create them (ok on 0.8.15). I wondered if it might be a
> permissions issue at first but that doesn't seem to be the case.

It was related to us not setting the correct character encoding in the
hostfs code, it was trying to use unicode. This has been fixed now.

> - Keyboard handling problem after a menu is accessed via ALT (largely acts
> like ALT gets stuck down afterwards) (ok on 0.8.15).

Yep, we spotted this very weird behaviour too, it's now been fixed.

> - Graphical corruption when configured as RiscPC/ARM810.

This, I'm probably not going to investigated now, as ARM810 is very very
experimental code ... unless someone wants to give me an arm810 card I can
test against :)

> - Starting as an A7000 model means mouse doesn't work when switched to a
> RiscPC model and vice versa.

Ooh, well spotted, this is an 6 year old bug. I've got a fix in now. (this
is a fullscreen/mouse capture issue only, not 'follow host mouse')

> - Configuration options let you try and set VRAM on an A7000 model at
> which point it says it needs to restart (but doesn't do so

I've fixed this issue of the erroneous 'you must restart'.

> and then
> indicates it being present until the emulator is closed and reloaded.
> Maybe it would be better to have separate options provided and saved for
> each machine type.

But I'm not going to fix this now, eventually I have a different idea
about how machines and models should be setup.

> - In fullscreen mode there doesn't seem to be any way to switch back to
> windowed mode. Selecting the fullscreen option again via ALT-S does
> nothing and the conventional Windows Alt-Enter also has no effect. In
> addition the menu bar doesn't show up when you press ALT, which is a minor
> thing but could definitely confuse some people.

The keyboard shortcut for leaving fullscreen is crtl-end

> Finally, a few difficulties I had with the emulator when I was starting
> out:
> Getting RISC OS up and running was easy enough but the universal-boot
> provided on your website seems to be missing the Shared C Library. I ended
> up using the 'UniBoot 2' version at
> [1]https://www.retro-kit.co.uk/page.cfm/content/UniBoot-for-RISC-OS/
> instead.

I presume you mean the 32-bit Shared C-Library? Which used to live at
http://www.iyonix.com/32bit/system.shtml
now
https://web.archive.org/web/20150412211454/http://www.iyonix.com/32bit/system.shtml

One reason I generally don't provide large amounts of pre-setup stuff as
theoretically the emulator is just like a real Risc PC in respect to
allowing people to pick the version of the OS and the software themselves.

Also, it's too hard to support everyone's issues with risc os in general.

> I was then confused why I couldn't change the display mode in RISC OS
> until I eventually remembered that the newer machines rely on monitor
> definition files. Could these perhaps be provided with the emulator?

I believe all the boot sequences include the MDFs?


At some point soon, I'd like to roll a second test version (0.8.100) to
allow everyone to check their reported bugs are fixed now, and a second
chance to spot new ones.

Peter

--
Peter Howkins
peter.howkins@marutan.net

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

Monday, 18 December 2017

Re: [Rpcemu] Questions/issues

In message <CAFWmK8wH22ayj-UzQr4sjN=0CquXYYCPQ=FMznOWQm2LvcNzBw@mail.g
mail.com>
J Percival <perciv.js@gmail.com> wrote:

> Hi there! Been using this great emulator for a while but have noticed some
> issues. You're probably already aware of them but I thought I would mention
> them anyway. These refer mainly to the 0.8.99 super-secret pre-release.

> Setup:
> Windows 10/64-bit
> V0.8.99 Interpreter
> RISC OS 3.71
> Configuration: 2/8MB VRAM, 32MB RAM, Sound Enabled

> - HostFS shows as empty both from the desktop and command line. No
> files/folders added via Windows or RISC OS appear even though it will
> happily create them (ok on 0.8.15). I wondered if it might be a permissions
> issue at first but that doesn't seem to be the case.

> - Keyboard handling problem after a menu is accessed via ALT (largely acts
> like ALT gets stuck down afterwards) (ok on 0.8.15).

> - Graphical corruption when configured as RiscPC/ARM810.

> - Starting as an A7000 model means mouse doesn't work when switched to a
> RiscPC model and vice versa.

> - Configuration options let you try and set VRAM on an A7000 model at which
> point it says it needs to restart (but doesn't do so) and then indicates it
> being present until the emulator is closed and reloaded. Maybe it would be
> better to have separate options provided and saved for each machine type.

> - In fullscreen mode there doesn't seem to be any way to switch back to
> windowed mode. Selecting the fullscreen option again via ALT-S does nothing
> and the conventional Windows Alt-Enter also has no effect. In addition the
> menu bar doesn't show up when you press ALT, which is a minor thing but
> could definitely confuse some people.

> Finally, a few difficulties I had with the emulator when I was starting out:

> Getting RISC OS up and running was easy enough but the universal-boot
> provided on your website seems to be missing the Shared C Library. I ended
> up using the 'UniBoot 2' version at
> https://www.retro-kit.co.uk/page.cfm/content/UniBoot-for-RISC-OS/ instead.

> I was then confused why I couldn't change the display mode in RISC OS until
> I eventually remembered that the newer machines rely on monitor definition
> files. Could these perhaps be provided with the emulator? In the end I used
> the 'anymode' module from http://www.pi-star.co.uk/anymode/ which allowed
> games such as Jeff Doggett's Doom port to work, although not all available
> modes are displayed in the desktop display manager.

> Finally, my apologies if I missed any instructions/info in the
> documentation regarding these points. Thanks for creating such a great
> piece of software!

> - James
Hi

I have started Rpcemu
The main problem I have is with instability of the Menu button on my
mouse. I have to press the R alt to get menus to stay up.
HostFS works fine here. I also have Uniprint working and can use
LanMan to access other drives. I did find it difficult to under stand
bridging to get internet access. I have transfered many apps from my
old Iyonix. A version of Aemulor would be nice to access old
Impression documents
I have Win 10 64 bit with the Fall creators update

Chris

--
chris.j.craig@btinternet.com
Rpcemu RISC OS 5.22


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

[Rpcemu] Questions/issues

Hi there! Been using this great emulator for a while but have noticed some issues. You're probably already aware of them but I thought I would mention them anyway. These refer mainly to the 0.8.99 super-secret pre-release.

Setup:
Windows 10/64-bit
V0.8.99 Interpreter
RISC OS 3.71
Configuration: 2/8MB VRAM, 32MB RAM, Sound Enabled

- HostFS shows as empty both from the desktop and command line. No files/folders added via Windows or RISC OS appear even though it will happily create them (ok on 0.8.15). I wondered if it might be a permissions issue at first but that doesn't seem to be the case.

- Keyboard handling problem after a menu is accessed via ALT (largely acts like ALT gets stuck down afterwards) (ok on 0.8.15).

- Graphical corruption when configured as RiscPC/ARM810.

- Starting as an A7000 model means mouse doesn't work when switched to a RiscPC model and vice versa.

- Configuration options let you try and set VRAM on an A7000 model at which point it says it needs to restart (but doesn't do so) and then indicates it being present until the emulator is closed and reloaded. Maybe it would be better to have separate options provided and saved for each machine type.

- In fullscreen mode there doesn't seem to be any way to switch back to windowed mode. Selecting the fullscreen option again via ALT-S does nothing and the conventional Windows Alt-Enter also has no effect. In addition the menu bar doesn't show up when you press ALT, which is a minor thing but could definitely confuse some people.

Finally, a few difficulties I had with the emulator when I was starting out:

Getting RISC OS up and running was easy enough but the universal-boot provided on your website seems to be missing the Shared C Library. I ended up using the 'UniBoot 2' version at https://www.retro-kit.co.uk/page.cfm/content/UniBoot-for-RISC-OS/ instead.

I was then confused why I couldn't change the display mode in RISC OS until I eventually remembered that the newer machines rely on monitor definition files. Could these perhaps be provided with the emulator? In the end I used the 'anymode' module from http://www.pi-star.co.uk/anymode/ which allowed games such as Jeff Doggett's Doom port to work, although not all available modes are displayed in the desktop display manager.

Finally, my apologies if I missed any instructions/info in the documentation regarding these points. Thanks for creating such a great piece of software!

- James

Sunday, 17 December 2017

Re: Validation

In article <56abf2cfb6Lists@Torrens.org>, Richard Torrens (lists)
<Lists@Torrens.org> wrote:

> Thhanks - I can't have dug dseep enough. But what a pain - I extract
> URLs from NetSurf's URL bar using !Transfer2. It of course picks up the
> unglyphed version.

Indeed, I am someone who will often S&R & for &amp; in a webpage when the
validator complains about them. It has to be an attended S&R though!

Transfer2? Why not just drag the URL into your editor?

--

Tim Hill

timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk

Re: Validation

In article <56abf12512tim@timil.com>,
Tim Hill <tim@timil.com> wrote:
> No, &amp; won't work from your editor. It will work only in the Browser.

> The four amp version of the link above will be
> http://www.google.co.uk/search?hl=en&amp;source=hp&amp;ie=ISO-8859-1&amp;q=omeprazole+causes+bile+reflux&amp;btnG=Google+Search

> And, buried in HTML, it works fine. It doesn't work in Pluto or StrongED
> though, so don't expect it to. They are happy with '&' and don't
> translate the '&amp;'s as a browser does/has to.

Thhanks - I can't have dug dseep enough. But what a pain - I extract URLs
from NetSurf's URL bar using !Transfer2. It of course picks up the
unglyphed version.

--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!

Re: Validation

In article <56abea205fLists@Torrens.org>, Richard Torrens (lists)
<Lists@Torrens.org> wrote:
> I was trying to validate an html page using w3c validator. I could not!

> The reason was that the page contains lots of links to Google searches
> etc. e.g. <a
> href="http://www.google.co.uk/search?hl=en&source=hp&ie=ISO-8859-1&q=omeprazole+causes+bile+reflux&btnG=Google+Search">

> The validator complains about the & in there - it wants &amp; but the
> link with that in won't work.

No, &amp; won't work from your editor. It will work only in the Browser.

The four amp version of the link above will be
http://www.google.co.uk/search?hl=en&amp;source=hp&amp;ie=ISO-8859-1&amp;q=omeprazole+causes+bile+reflux&amp;btnG=Google+Search

And, buried in HTML, it works fine. It doesn't work in Pluto or StrongED
though, so don't expect it to. They are happy with '&' and don't
translate the '&amp;'s as a browser does/has to.

> So is this a fault in the validator - or something which should be
> accomodated in NetSurf?

It's working just as it should. Your example elsewhere had a typo.

--

Tim Hill

timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk

Validation

I was trying to validate an html page using w3c validator. I could not!

The reason was that the page contains lots of links to Google searches
etc. e.g.
<a
href="http://www.google.co.uk/search?hl=en&source=hp&ie=ISO-8859-1&q=omeprazole+causes+bile+reflux&btnG=Google+Search">

The validator complains about the & in there - it wants &amp; but the link
with that in won't work.

So is this a fault in the validator - or something which should be
accomodated in NetSurf?

--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!

Thursday, 14 December 2017

Re: Image/text alignment

In article <56aa42426cLists@Torrens.org>, Richard Torrens (lists)
<Lists@Torrens.org> wrote:
> I have been trying to get some .png images aligned with text using CSS.
> Is there yet a way to do so in Netsurf?

[Snip]

There doesn't seem to be, except with table cells as they say.

As flex containers aren't implemented in NetSurf I tried for a while to
create a vertical-aligning non-flex div in a NS specific style sheet. I
gave it up as impossible but would be happy to be proved wrong.

--

Tim Hill

timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk

Image/text alignment

I have been trying to get some .png images aligned with text using CSS. Is
there yet a way to do so in Netsurf?

img {vertical-align:"middle;" }
etc. do not work.

The progress page
http://www.netsurf-browser.org/documentation/progress.html#CSSFeatures
says "in progress - Only implemented for table cells."


This page seems to have been "Last updated 20 December 2012" - I know -
keeping documentation up to date seems nearly as much work as the
programming!

--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!

Tuesday, 12 December 2017

Re: OpenSSL

On Tue, Dec 12, 2017 at 12:29:08PM +0100, Thorsten Otto wrote:
> On Dienstag, 12. Dezember 2017 10:45:10 CET Vincent Sanders wrote:
> > I have failed to update the atari toolchains once again. They remain
> > badly broken in that they:
> >
> > 1. cannot generate a working cross compiler on a modern Debian OS
> > 2. compiled on an old OS they produce a broken SDK with OpenSSL 1.1
> > 3. Are very old compilers which generate poor code, especialy for m68k
>
> Both linux versions on my homepage (4.6.4 and 7.2) were compiled on a recent
> SuSE distribution, so in general there should be not much problem doing the
> same on recent Debian system. The scripts use a different directory layout
> though than the one that your toolchains expect.
>
> If i understand it right, your CI system uses a pre-compiled toolchain, so
> this has to be done only once?

Our CI system builds the toolchains from source to ensure complete
reproducability for our releases.

>
> Are the scripts that you use for automatic building are downloadable
> somewhere? I could not find them.
>

The toolchain reposity http://source.netsurf-browser.org/toolchains.git/
contains the makefiles which construct a correctly patched set of
sources to generate a cross compiler and then build it.

In addition the libraries and tools necessary to cross compile the
browser are contained in a common SDK in the toolchains repo.

it should be as simple as:

git clone git://git.netsurf-browser.org/toolchains.git
cd toolchains
mkdir -p /opt/netsurf
make -C m68k-atari-mint

> >any assistance would be gratefully recieved.
>
> Feel free to ask any questions. I can also try to compile the toolchain on a
> debian jessie system running under VirtualBox.

if it works on SuSE that should just work elsewhere.

I have a branch vince/atari-gcc7 which is my current work in progress,
this gets a compiler built but crashes and burns at the mintlib stage

Once the cross environment is completely working the SDK build can be
attempted with:

GCCSDK_INSTALL_CROSSBIN=/opt/netsurf/m68k-atari-mint/cross/bin GCCSDK_INSTALL_ENV=/opt/netsurf/m68k-atari-mint/env make -C sdk

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

Re: OpenSSL

On Dienstag, 12. Dezember 2017 10:45:10 CET Vincent Sanders wrote:
> I have failed to update the atari toolchains once again. They remain
> badly broken in that they:
>
> 1. cannot generate a working cross compiler on a modern Debian OS
> 2. compiled on an old OS they produce a broken SDK with OpenSSL 1.1
> 3. Are very old compilers which generate poor code, especialy for m68k

Both linux versions on my homepage (4.6.4 and 7.2) were compiled on a recent
SuSE distribution, so in general there should be not much problem doing the
same on recent Debian system. The scripts use a different directory layout
though than the one that your toolchains expect.

If i understand it right, your CI system uses a pre-compiled toolchain, so
this has to be done only once?

Are the scripts that you use for automatic building are downloadable
somewhere? I could not find them.

>any assistance would be gratefully recieved.

Feel free to ask any questions. I can also try to compile the toolchain on a
debian jessie system running under VirtualBox.

Re: OpenSSL

On 12 December 2017 09:45:10 GMT+00:00, Vincent Sanders <vince@netsurf-browser.org> wrote:
>
>There may be some issues with the new library build on some
>platforms. To date the only one which has been reported as problematic
>is the m68k Amiga os3 build which Chris Young is aware of and looking
>to resolve.
>

I was trying to but not getting very far!


>To assist in this I have extended the CI system to build Amiga os3
>packages and publish the results [3] I have no way to test these
>packages so their usefulnes may be limited but they do now exist,
>perhaps Chris can comment on their status.
>

I'll get somebody to check them.

Thanks
Chris

OpenSSL

I have recently completed updating all the toolchains/SDK [1] to use
OpenSSL 1.1 instead of 1.0. This is prudent because OpenSSL 1.0 is
reaching the end of its life [2] and it is advisable to use an
actively supported version of a such a sensitive library in a web
browser.

There may be some issues with the new library build on some
platforms. To date the only one which has been reported as problematic
is the m68k Amiga os3 build which Chris Young is aware of and looking
to resolve.

To assist in this I have extended the CI system to build Amiga os3
packages and publish the results [3] I have no way to test these
packages so their usefulnes may be limited but they do now exist,
perhaps Chris can comment on their status.

I have failed to update the atari toolchains once again. They remain
badly broken in that they:

1. cannot generate a working cross compiler on a modern Debian OS
2. compiled on an old OS they produce a broken SDK with OpenSSL 1.1
3. Are very old compilers which generate poor code, especialy for m68k

I have been trying to use the patches provided by Thorsten Otto [4] to
fix these toolchains but any assistance would be gratefully recieved.

[1] http://source.netsurf-browser.org/toolchains.git/
[2] https://www.openssl.org/policies/releasestrat.html
[3] http://ci.netsurf-browser.org/builds/amigaos3/
[4] http://tho-otto.de/crossmint.php

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

Sunday, 10 December 2017

Re: Survey form

In article <000693bf.01e9b490a247@smtp.freeola.net>, Peter Slegg
<p.slegg@scubadivers.co.uk> wrote:

> Hi,

> I was sent a survey form to fill in.

> 1a is a mandatory question but it is not being rendered in Netsurf.
> (Atari 4258).

> This is the <div> section:

> <div class="fb-item fb-side-by-side fb-50-item-column
> fb_cond_applied" id="item82" style="padding: 1px; opacity: 1;">
> <div class="fb-grouplabel"> <label id="item82_label_0"
> style="display: inline;">1a. Your main vehicle fuel?</label>

[Snip]

> I don't know if this is bad html or a NS issue but it seems to be the
> fb_cond_applied that causes it not to display.


The CSS definitions for body, div, label, fb-item, fb-side-by-side,
fb-50-item-column, fb-grouplabel or item82_label_0 could be the problem
too. They could be in the files header or there referenced in a LINKed
CSS file. Or several.

It's arguably easier to open the page in Chrome on a PC for two reasons:
1. the page will render (!)
2. right click an object and 'Inspect' it. It will show you all the CSS
which applies to that object and where its definitions came from.

Having identified the CSS which applies, you could then construct an
experimental page with only the html you quoted and the relevant styles
defined, commenting them out one at a time may then reveal the culprit
for a bug report.

--

Tim Hill

timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk

Survey form

Hi,

I was sent a survey form to fill in.

1a is a mandatory question but it is not being rendered in Netsurf.
(Atari 4258).

This is the <div> section:

<div class="fb-item fb-side-by-side fb-50-item-column fb_cond_applied"
id="item82" style="padding: 1px; opacity: 1;">
<div class="fb-grouplabel">
<label id="item82_label_0" style="display: inline;">1a. Your main vehicle fuel?</label>
</div>
<div class="fb-radio">
<label id="item82_0_label"><input name="FuelType" id="item82_0_radio" required type="radio" data-hint="" value="Petrol" /><span class="fb-fieldlabel" id="item82_0_span">Petrol</span></label>
<label id="item82_1_label"><input name="FuelType" id="item82_1_radio" required type="radio" value="Diesel" /><span class="fb-fieldlabel" id="item82_1_span">Diesel</span></label>
<label id="item82_2_label"><input name="FuelType" id="item82_2_radio" required type="radio" value="LPG" /><span class="fb-fieldlabel" id="item82_2_span">LPG</span></label>
<label id="item82_3_label"><input name="FuelType" id="item82_3_radio" required type="radio" value="Hybrid" /><span class="fb-fieldlabel" id="item82_3_span">Hybrid</span></label>
<label id="item82_4_label"><input name="FuelType" id="item82_4_radio" required type="radio" value="Plug in Hybrid" /><span class="fb-fieldlabel" id="item82_4_span">Plug in Hybrid</span></label>
<label id="item82_5_label"><input name="FuelType" id="item82_5_radio" required type="radio" value="Other" /><span class="fb-fieldlabel" id="item82_5_span">Other</span></label>
</div>
</div>

I don't know if this is bad html or a NS issue but it seems to be the
fb_cond_applied that causes it not to display.


Peter

Thursday, 7 December 2017

Re: Failure to initialise Unicode font library

In article <20171207113455.GK32015@platypus.pepperfish.net>,
Rob Kendrick <rjek@netsurf-browser.org> wrote:

> Have you added any fonts recently?

No. Of course, the first thing both these apps normally do after a
start-up is to scan fonts, and a file !Scrap.ScrapDirs.ScrapDir.RUfl_cache
appears.

That seems to be there, so perhaps it is corrupted and present, thus
inhibiting a further scan. I'll try renaming it or moving it.

Of course, as I copied all the resources over, that included Scrap!

That seems to have done the trick!

Though it doesn't explain why it didn't work before I copied over the
resources from back-up!

No matter, sorted now, thanks!

John

--
| John Williams
| johnrw@ukgateway.net

Names for Soul Band:- Soul Expression *

Re: Failure to initialise Unicode font library

On Thu, Dec 07, 2017 at 11:12:07AM +0000, John Williams wrote:
> Any suggestions as to what to look at next?

Have you added any fonts recently?

B.

Re: Failure to initialise Unicode font library

On 07/12/17 11:12, John Williams wrote:
>
> My RPi has suddenly developed an inability to load NetSurf:
>
> The Unicode font library could not be initialized. Please report
> this to the developers.

[snip]

> Any suggestions as to what to look at next?

I think the usual cause is the installation of a subtly broken font.
Have you installed any fonts recently?

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

Failure to initialise Unicode font library

My RPi has suddenly developed an inability to load NetSurf:

The Unicode font library could not be initialized. Please report
this to the developers.

and James Bursa's Sargasso:

Failed to initialise Unicode font library

Both of these apps were working perfectly in France on 4/12/17, but the
problem cropped up on my reconnection on my return home.

Thinking this was a problem with a shared resource as it affected two
applications, I restored my previously backed-up Boot:Resources directory
in its entirety, as I did not know which particular resource would produce
this error, but to no avail.

Any suggestions as to what to look at next?

John

--
| John Williams
| johnrw@ukgateway.net

Names for Soul Band:- Soul Agent(s) *

Wednesday, 6 December 2017

Re: German Messages for NetSurf - updated

On Wed, Dec 06, 2017 at 12:06:39PM +0100, Sebastian Barthel wrote:
> Hello all.
>
> I've tried to send an eMail to Michael Drake directly but without succes
> - so I'm testing to reach somebody else by using this address.

Can I ask which address you tried?

> Since some years passed by and something changed in !NetSurf I thought
> it might be a good idea to add some entries to the messages
> file. I hope I've done this in the correct manner and didn't introduced
> new errors.
>
> If You are in the mode wich allows You to add some data into the GitHub
> - I would ask and please You to introduce into the sourcetree the
> FatMessages file which i add to this mail.

We don't use GitHub. Can you provide your changes to FatMessages as a
patch/diff to the current git master at this repository?
http://git.netsurf-browser.org/netsurf.git/

Many thanks!

B.

Monday, 4 December 2017

Re: netsurf-dev Digest, Vol 134, Issue 3

Err, most crypto wallets I know are based off of *-core forks, and that's all written in C++. I'm not sure of anything that _does_ use electron.

On Mon, Dec 4, 2017 at 7:00 AM, <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://listmaster.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. Re: netsurf-dev Digest, Vol 134, Issue 2 (Erik Poupaert)


----------------------------------------------------------------------

Message: 1
Date: Sun, 3 Dec 2017 19:29:36 +0700
From: Erik Poupaert <erik@sankuru.biz>
Subject: Re: netsurf-dev Digest, Vol 134, Issue 2
To: netsurf-dev@netsurf-browser.org
Message-ID:
        <CAFqk0_KCRByzG_YFYvT3QW5OA2BHfX2pk_miORWoQw+TBGOaJw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

>> The http://www.netsurf-browser.org gives the impression of offering
>> all the same building bricks, and also that it could possibly be a
>> much smaller alternative.
> Except that we lack 90% (or more) of the bindings, rendering, etc, right now :(
> 1. Help with the CSS engine
> 2. Help with the dynamic layout engine
> 3. Help integrate that into NS
> 4. Assist with the JavaScript bindings

On the one side, there is the interesting goal of being able to
compete with the existing browser oligopoly and offer an extra, less
bloated alternative, which is indeed a commendable endeavour. That
would indeed allow users to surf the existing web without having to
trust the existing cartel.

On the other side, for a desktop application, the existing netsurf
capabilities are already way more than "good enough". Lacking more
than 90% of the bindings, rendering, etc is quite immaterial in that
context. A desktop application has no need to be compatible with
existing websites.

Still, I concede that your goal -- no matter how different from mine
-- is certainly commendable.

> 5. Worry about whether or not it's a good plan to promulgate the idea that
> desktop applications built out of web browsers isn't the work of an evil
> mind aiming to destroy all semblance of reliable and uniform user interfaces.

Yes, but -- except for the original, universal evil -- it is always
possible to find situations for every given evil in which it is the
lesser evil. That is why I reject the belief in absolute evil.
Seriously, I am not a follower of absolute evil or its principle.

Even chopping off someone's limbs is not necessarily an absolute evil.
A doctor calls that an "amputation". That is also why pharmacies are
allowed and even encouraged to sell their dangerous poisons.
Furthermore -- except for the original, universal good -- there are
always situations, for every given good, in which it is actually an
evil. Pure water may be good, but not when you try to swallow an
entire tropical river. That is called "drowning".

I originally looked into doing a desktop application with lua + lgi
(gtk bindings), but unfortunately, I cannot find
sufficiently-effective cryptocurrency-related source code in lua,
while this is way less of a problem in javascript. Maintaining a lua
port would end up burning a lot of energy just to allow a few people
to have their way, especially, since not everybody is a fan of small,
embeddable scripting engines.

At the moment, pretty much everybody else uses a 100+ MB web-runtime
to create even the simplest crypto-wallet on the desktop. It allows
for deploying an almost unmodified app to the mobile phone too. So,
they are doing some kind of understandable trade-off engineering with
lots of advantages and disadvantages.

I am certainly not trying to push anybody to go off on a tangent that
does not serve their own goals. I was just trying to find people who
would have similar goals already.



End of netsurf-dev Digest, Vol 134, Issue 3
*******************************************

Sunday, 3 December 2017

Re: netsurf-dev Digest, Vol 134, Issue 2

>> The http://www.netsurf-browser.org gives the impression of offering
>> all the same building bricks, and also that it could possibly be a
>> much smaller alternative.
> Except that we lack 90% (or more) of the bindings, rendering, etc, right now :(
> 1. Help with the CSS engine
> 2. Help with the dynamic layout engine
> 3. Help integrate that into NS
> 4. Assist with the JavaScript bindings

On the one side, there is the interesting goal of being able to
compete with the existing browser oligopoly and offer an extra, less
bloated alternative, which is indeed a commendable endeavour. That
would indeed allow users to surf the existing web without having to
trust the existing cartel.

On the other side, for a desktop application, the existing netsurf
capabilities are already way more than "good enough". Lacking more
than 90% of the bindings, rendering, etc is quite immaterial in that
context. A desktop application has no need to be compatible with
existing websites.

Still, I concede that your goal -- no matter how different from mine
-- is certainly commendable.

> 5. Worry about whether or not it's a good plan to promulgate the idea that
> desktop applications built out of web browsers isn't the work of an evil
> mind aiming to destroy all semblance of reliable and uniform user interfaces.

Yes, but -- except for the original, universal evil -- it is always
possible to find situations for every given evil in which it is the
lesser evil. That is why I reject the belief in absolute evil.
Seriously, I am not a follower of absolute evil or its principle.

Even chopping off someone's limbs is not necessarily an absolute evil.
A doctor calls that an "amputation". That is also why pharmacies are
allowed and even encouraged to sell their dangerous poisons.
Furthermore -- except for the original, universal good -- there are
always situations, for every given good, in which it is actually an
evil. Pure water may be good, but not when you try to swallow an
entire tropical river. That is called "drowning".

I originally looked into doing a desktop application with lua + lgi
(gtk bindings), but unfortunately, I cannot find
sufficiently-effective cryptocurrency-related source code in lua,
while this is way less of a problem in javascript. Maintaining a lua
port would end up burning a lot of energy just to allow a few people
to have their way, especially, since not everybody is a fan of small,
embeddable scripting engines.

At the moment, pretty much everybody else uses a 100+ MB web-runtime
to create even the simplest crypto-wallet on the desktop. It allows
for deploying an almost unmodified app to the mobile phone too. So,
they are doing some kind of understandable trade-off engineering with
lots of advantages and disadvantages.

I am certainly not trying to push anybody to go off on a tangent that
does not serve their own goals. I was just trying to find people who
would have similar goals already.

Friday, 1 December 2017

Re: Thanks for Netsurf and few comments

Forwarded to dev list.
Mathias please join the netsurf-dev list and continue discussion there.

Thanks
Chris

On 1 December 2017 22:06:58 GMT+00:00, Mathias Parnaudeau <mathias.p@wanadoo.fr> wrote:
>Hi Chris
>
>First, I would like to thank you because I installed Netsurf on my
>Amiga
>machines and I think it's a smart application. I like to use it, it is
>improved at each new release and is quite fast browsing.
>
>Then, you know, I am a developer and I like quality software, including
>
>things like continuous integration, static code analyzers, ... and I
>have to say I am impressed by Netsurf for all what is done in this
>area.
>That's not common.
>
>About that, I like to use the compiler sanitizers that really help to
>find problems / bugs at execution.
>
>So I compiled Netsurf on Linux with:
>
>make CC="gcc -fsanitize=undefined,address"
>
>I have to say I did not find easily where to modify CFLAGS and if I was
>
>forced or not to modify one or several makefiles.
>
>Anyway, compiling like that provides instrumented code that checks some
>
>errors. If I run Netsurf and then I quit it, I get:
>
>
>content/handlers/javascript/duktape/duktape.c:52791:6: runtime error:
>load of misaligned address 0x61400000b7cf for type 'duk_uint32_t',
>which
>requires 4 byte alignment
>0x61400000b7cf: note: pointer points here
> 02 00 00 00 05  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 00 00
>
>00 00 00 00 00 00  00 00 00
>              ^
>src/libnsbmp.c:287:43: runtime error: shift exponent 32 is too large
>for
>32-bit type 'int'
>src/libnsbmp.c:569:64: runtime error: left shift of 150 by 24 places
>cannot be represented in type 'int'
>src/libnsbmp.c:71:88: runtime error: left shift of 150 by 24 places
>cannot be represented in type 'int'
>src/parse/properties/utils.c:889:15: runtime error: left shift of 255
>by
>24 places cannot be represented in type 'int'
>/home/mathias/Sources/netsurf-all-3.7/libcss/src/select/bloom.h:63:21:
>runtime error: left shift of 1 by 31 places cannot be represented in
>type 'int'
>
>=================================================================
>==22287==ERROR: LeakSanitizer: detected memory leaks
>
>Direct leak of 3145728 byte(s) in 1 object(s) allocated from:
>     #0 0x7fc36b8c1ed0 in calloc
>(/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1ed0)
>     #1 0x55a757175395 in read_entries content/fs_backing_store.c:1229
>     #2 0x55a757175395 in initialise content/fs_backing_store.c:1556
>     #3 0x55a75787f977
>(/home/mathias/Sources/netsurf-all-3.7/netsurf/nsgtk+0x13a2977)
>
>...
>
>SUMMARY: AddressSanitizer: 5300121 byte(s) leaked in 1958
>allocation(s).
>
>Leaks could also certainly be found by valgrind (not used looking at
>Jenkins jobs).
>
>
>If I start and click on the CNN link and thenk I quit, I get (as part
>of
>the output):
>
>src/libnsbmp.c:287:43: runtime error: shift exponent 32 is too large
>for
>32-bit type 'int'
>src/libnsbmp.c:569:64: runtime error: left shift of 150 by 24 places
>cannot be represented in type 'int'
>src/libnsbmp.c:71:88: runtime error: left shift of 150 by 24 places
>cannot be represented in type 'int'
>src/parse/properties/utils.c:889:15: runtime error: left shift of 255
>by
>24 places cannot be represented in type 'int'
>/home/mathias/Sources/netsurf-all-3.7/libcss/src/select/bloom.h:63:21:
>runtime error: left shift of 1 by 31 places cannot be represented in
>type 'int'
>src/utils/utils.c:130:18: runtime error: left shift of negative value
>-1
>/home/mathias/Sources/netsurf-all-3.7/libcss/src/select/bloom.h:63:21:
>runtime error: left shift of 1 by 31 places cannot be represented in
>type 'int'
>src/parse/properties/utils.c:655:16: runtime error: left shift of 191
>by
>24 places cannot be represented in type 'int'
>src/libnsbmp.c:848:54: runtime error: left shift of 255 by 24 places
>cannot be represented in type 'int'
>render/layout.c:1343:32: runtime error: negation of -2147483648 cannot
>be represented in type 'int [4]'; cast to an unsigned type to negate
>this value to itself
>
>
>So maybe you (or the team) could use these useful sanitizers to help
>finding bugs.
>
>Let me know if you prefer me to create a ticket in the bugtracker.
>
>
>A last comment: looking for your email in os4depot, I've just noticed
>that the latest version there is 3.6.
>
>
>Regards,
>
>Mathias

Re: Fwd: A nw.js-like use of netsurf

On Fri, Dec 01, 2017 at 18:20:25 +0700, Erik Poupaert wrote:
> The http://nw.js project reuses webkit and node.js in order to offer
> an interesting alternative to build desktop applications in html, css,
> and javascript. The http://electronjs.org project does something quite
> similar.

Sad, isn't it? :(

> The http://www.netsurf-browser.org gives the impression of offering
> all the same building bricks, and also that it could possibly be a
> much smaller alternative.

Except that we lack 90% (or more) of the bindings, rendering, etc, right now :(

> Does anybody feel like offering remarks on what would be a reasonable
> starting point to massage the netsurf source code in that general
> direction? Would a plan like that actually be viable?

1. Help with the CSS engine
2. Help with the dynamic layout engine
3. Help integrate that into NS
4. Assist with the JavaScript bindings
5. Worry about whether or not it's a good plan to promulgate the idea that
desktop applications built out of web browsers isn't the work of an evil
mind aiming to destroy all semblance of reliable and uniform user interfaces.

D.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

Fwd: A nw.js-like use of netsurf

The http://nw.js project reuses webkit and node.js in order to offer
an interesting alternative to build desktop applications in html, css,
and javascript. The http://electronjs.org project does something quite
similar.

The http://www.netsurf-browser.org gives the impression of offering
all the same building bricks, and also that it could possibly be a
much smaller alternative.

Does anybody feel like offering remarks on what would be a reasonable
starting point to massage the netsurf source code in that general
direction? Would a plan like that actually be viable?

Better yet, is anybody possibly already working on a similar idea? If
you are interested in this subject, I would be more than happy to have
a chat about it, and explore the possibilities.

Thursday, 30 November 2017

Re: URL lengths

On 30 Nov, Tim Hill wrote in message
<56a3223323tim@timil.com>:

> I just can't believe that a URL can contain 33% more letters than the King
> James Bible's 3,116,480.
>
> "four gigabytes per URL"
>
> LOL

In RISC OS terms, it's another way of saying "limited by available
memory"...

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

Re: URL lengths

On 30 Nov, Harriet Bazley wrote in message
<bb00dfa256.harriet@blueyonder.co.uk>:

> On 28 Nov 2017 as I do recall,
> Daniel Silverstone wrote:
>
> > I don't believe we limit URL length per-se, though they get interned and
> > as such four gigabytes per URL is probably the absolute limit. In
> > addition, POST data is nominally unlimited though I believe we have a
> > similar four gigabyte limit.
>
> I had an error today from Netsurf, reporting that a URL was too long to
> display (although it seemed to work).

Due to the problems that the Wimp has changing the allocation of writable
icon buffers, there's an arbitrary limit (255 characters, perhaps?) in the
RISC OS front-end's URL bar. If the core tries to display a longer URL, the
bar is just cleared and you get a warning -- but it doesn't otherwise affect
the browser's operation.

This obviously means that there's a limit to the size of URL that you can
type in, too. But that's it. You can follow any length of link in NetSurf,
and launch any length of URL via the launch protocols.

All subject to that 4GB limit, of course.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

Re: URL lengths

On 2017-11-30 14:32, Tim Hill wrote:

> I just can't believe that a URL can contain 33% more letters than the
> King James Bible's 3,116,480.

Hmm; 33% more than 3,116,480 is roughly 4 MB, not GB.

--
Jeremy Nicoll - my opinions are my own

Re: URL lengths

In article <56a1aa7e00JohnRW@ukgateway.net>,
John Williams <JohnRW@ukgateway.net> wrote:
> What is the maximum URL length (including POST data) that NetSurf can
> handle?

What may be relevant is the following entry from my web server error
logs:

2017-10-02 02:57:45: (response.c.553) file not found ... or so: File name
too long
/YesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreSc
ann ->

At which point the Web server (lighttpd) logs it as an error.

--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!

Re: URL lengths

On Thu, Nov 30, 2017 at 02:32:29PM +0000, Tim Hill wrote:
>
> I just can't believe that a URL can contain 33% more letters than the
> King James Bible's 3,116,480.
>
> "four gigabytes per URL"

It's probably much greater than that on modern systems, too!

B.

Re: URL lengths

In article <bb00dfa256.harriet@blueyonder.co.uk>, Harriet Bazley
<lists@bazleyfamily.co.uk> wrote:
> On 28 Nov 2017 as I do recall, Daniel Silverstone wrote:

> > On Mon, Nov 27, 2017 at 18:08:46 +0000, John Williams wrote:
> > > What is the maximum URL length (including POST data) that NetSurf
> > > can handle?
> >
> > I don't believe we limit URL length per-se, though they get interned
> > and as such four gigabytes per URL is probably the absolute limit.
> > In addition, POST data is nominally unlimited though I believe we
> > have a similar four gigabyte limit.

> I had an error today from Netsurf, reporting that a URL was too long to
> display (although it seemed to work).

I just can't believe that a URL can contain 33% more letters than the
King James Bible's 3,116,480.

"four gigabytes per URL"

LOL

--

Tim Hill

timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk

Wednesday, 29 November 2017

Re: URL lengths

On 28 Nov 2017 as I do recall,
Daniel Silverstone wrote:

> On Mon, Nov 27, 2017 at 18:08:46 +0000, John Williams wrote:
> > What is the maximum URL length (including POST data) that NetSurf can
> > handle?
>
> I don't believe we limit URL length per-se, though they get interned and as
> such four gigabytes per URL is probably the absolute limit. In addition, POST
> data is nominally unlimited though I believe we have a similar four gigabyte
> limit.

I had an error today from Netsurf, reporting that a URL was too long to
display (although it seemed to work).

--
Harriet Bazley == Loyaulte me lie ==

No man has a right to live - but every man has a duty to save him if he can

Tuesday, 28 November 2017

Re: URL lengths

In article <20171128115425.22cudniq3zrfba3l@somnambulist.local>,
Daniel Silverstone <dsilvers@netsurf-browser.org> wrote:

> I don't believe we limit URL length per-se, though they get interned and
> as such four gigabytes per URL is probably the absolute limit. In
> addition, POST data is nominally unlimited though I believe we have a
> similar four gigabyte limit.

Right, so it will be an arbitrary comparatively small allowance I will
make, and then politely refuse to handle anything larger.

Thank you all for your assistance.

John

--
| John Williams
| johnrw@ukgateway.net

Names for Soul Band:- Soul Doubt *

Re: URL lengths

On Mon, Nov 27, 2017 at 18:08:46 +0000, John Williams wrote:
> What is the maximum URL length (including POST data) that NetSurf can
> handle?

I don't believe we limit URL length per-se, though they get interned and as
such four gigabytes per URL is probably the absolute limit. In addition, POST
data is nominally unlimited though I believe we have a similar four gigabyte
limit.


So if you want to store any possible URL plus POST data you'd need eight
gigabytes per allocation.

D.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

Re: URL lengths

On Mon, Nov 27, 2017 at 06:08:46PM +0000, John Williams wrote:
> An genuine real-life number would be better!

>From memory, they are dynamically allocated as needed and can be of
arbitrary length. This is a lot more efficient than using
statically-sized buffers for the worst common case, especially in a
piece of software that might be storing information on tens of thousands
of URLs (Everything in your history, the links to all the resources on
every page you have open, etc).

My advice is firstly to either measure and then allocate, or read in the
data and reallocate as needed dynamically. Secondly, use a different
language; BBC Basic really isn't good for this sort of thing :) (If
using a modern interpreted language like Lua, Python, or even Perl,
asking this question would never have occurred to you.)

B.

Monday, 27 November 2017

Re: URL lengths

In message <56a1b699dcJohnRW@ukgateway.net>
John Williams <JohnRW@ukgateway.net> wrote:

> In article <0612b1a156.gavin@wra1th.plus.com>,
> Gavin Wraith <gavin@wra1th.plus.com> wrote:

> So you're suggesting that I measure each URL length first, perhaps BGETting
> it until I encounter a terminator, and then DIM a variable accordingly -
> or, actually, a series of concatenating variables as I intend to BPUT them
> later; so I don't really need to have a long variable, just a series of
> suitable GET variables.

Not BGET. You do not need to work byte by byte. Why not GET$?
It is a long time ago since I used BASIC.

Do you know about StrongED scripts? Here is one that replaces the text
in a StrongED window by a list of the URLs occurring in it, ignoring duplicates.

Here it is:

#! lua
local pat, used ="(https?://[^%s\t]+)", { }
for line in io.lines (arg[1]) do
for url in line:gmatch (pat) do
if not used[url] then
print (url)
used[url] = true
end -- if
end -- for
end -- for

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

Re: URL lengths

On 27 Nov, John Williams wrote in message
<56a1b699dcJohnRW@ukgateway.net>:

> In article <0612b1a156.gavin@wra1th.plus.com>,
> Gavin Wraith <gavin@wra1th.plus.com> wrote:
>
> > I would DIM buffers for URLs from the heap as you need them.
>
> So you're suggesting that I measure each URL length first, perhaps
> BGETting it until I encounter a terminator, and then DIM a variable
> accordingly - or, actually, a series of concatenating variables as I
> intend to BPUT them later; so I don't really need to have a long variable,
> just a series of suitable GET variables.

Allocating the necessary memory is the correct way to do it, yes.

> A number would be easier! How many?

As long as the URL is? My memory is that the RISC OS GUI might apply some
limits, but that the core probably doesn't.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

Re: URL lengths

In article <0612b1a156.gavin@wra1th.plus.com>,
Gavin Wraith <gavin@wra1th.plus.com> wrote:

> From a quick glance at the NetSurf 3.7 sources I would guess that the
> answer rather depends on which platform, and then on the particular
> machine NetSurf is running on.

I am, of course, running RISC OS.

> If your menu program is in BBC BASIC

which it is

> I would DIM buffers for URLs from the heap as you need them.

So you're suggesting that I measure each URL length first, perhaps BGETting
it until I encounter a terminator, and then DIM a variable accordingly -
or, actually, a series of concatenating variables as I intend to BPUT them
later; so I don't really need to have a long variable, just a series of
suitable GET variables.

A number would be easier! How many?

John

--
| John Williams
| johnrw@ukgateway.net

Does 'expostulation' refer to the antics of former nuns? *

Re: URL lengths

In message <56a1aa7e00JohnRW@ukgateway.net>
John Williams <JohnRW@ukgateway.net> wrote:

> What is the maximum URL length (including POST data) that NetSurf can
> handle?

>From a quick glance at the NetSurf 3.7 sources I would guess that the
answer rather depends on which platform, and then on the particular machine
NetSurf is running on. If your menu program is in BBC BASIC I would
DIM buffers for URLs from the heap as you need them. In C I would use alloc.
In Lua, Python or PERL all that is done for you anyway, and you do not
need to think about maximum string lengths.

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

URL lengths

I'm writing a little menu program to generate URL index pages. It's to
make URLs easily available to my Linux machine if there are any problems
with a page/site under NetSurf.

What is the maximum URL length (including POST data) that NetSurf can
handle?

My program is taking text URLs, Ant URL files or Acorn URI files and
parsing them (in the latter case!) to extract the URL string for use in the
menu page, but I need to know the maximum length NetSurf can handle so that
I can provide for all possibilities that it may throw my way.

Or I could just choose an arbitrary large maximum - but what would a
sensible limit be before complaining? 500 characters /seems/ reasonable,
but is it actually?

An genuine real-life number would be better!

John

--
| John Williams
| johnrw@ukgateway.net

Names for Soul Band:- The Soul Criterion *

Friday, 17 November 2017

Re: Name from NetSurf has underscores for percents

On 17 Nov 2017 John Rickman <rickman@argonet.co.uk> wrote:


> Is this a bug?

> If you open this link in NetSurf :-
> https://hu.123rf.com/photo_34178186_soil-grooves-farming-earth-soil-gr
> ooves-over-field-for-crop-planting-on-rural-countryside-farm-lands.htm
> l

> The webpage shows a JPEG of a ploughed field.
> Then if you menu>Object>Object>Save... and drag/drop the jpeg onto
> an application eg Artworks, ChangeFSI etc the load fails because the
> file name is not correct.

Different here. If I try to save that image into Transient's directory
for today, I get:

Transient: Message block is too big / not a multiple of 4 (code2484)

If I drag it straight to DPlngScan, the image opens correctly, but I
can't save it. The error message here is:

Error from DPlngScan: Can't open
SCSI::SSD.$.Utilities.Computer.Transient.Default.2017/11/17.<Wimp$Scrap>

I don't understand what any of that means!

Best wishes,

Peter.

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

Re: Name from NetSurf has underscores for percents

In article <3a91789c56.John@rickman.argonet..co.uk>,
John Rickman <rickman@argonet.co.uk> wrote:
> Is this a bug?

No. It is a function of the RISC OS filer and the wimp message
protocol.

See my post in the ArtWorks maillist, where you also posted this
message.

--
Chris Johnson

Re: Name from NetSurf has underscores for percents

On 17 Nov, John Rickman wrote in message
<3a91789c56.John@rickman.argonet..co.uk>:

> NetSurf has output the file name as
>
> 34178186-talaj-hornyok-mez_C5_91gazdas_C3_A1gi-earth-talaj-b
> ar_C3_A1zd_C3_A1k-f_C3_B6l_C3_B6tt-mez_C5_91-n_C3_B6v_C3_A9n
> y-_C3_BCltet_C3_A9si-a-vid_C3_A9ken-m/jpg
>
> but the underscores should be percent signs to code for letters with
> Hungarian diacritics in Unicode:
>
> 34178186-talaj-hornyok-mez_C5%91gazdas%C3%A1gi-earth-talaj-b
> ar%C3%A1zd%C3%A1k-f%C3%B6l%C3%B6tt-mez%C5%91-n%C3%B6v%C3%A9n
> y-%C3%BCltet%C3%A9si-a-vid%C3%A9ken-m/jpg
>
> whereupon it works into the apps.

Is % actually a valid character in a Fileswitch filename? It represents the
CSD, and is included in the reserved characters list, so I'd suggest not.

So NetSurf is correct to replace % with _ when saving to a RISC OS filing
system.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

Name from NetSurf has underscores for percents

Is this a bug?

If you open this link in NetSurf :-
https://hu.123rf.com/photo_34178186_soil-grooves-farming-earth-soil-grooves-over-field-for-crop-planting-on-rural-countryside-farm-lands.html

The webpage shows a JPEG of a ploughed field.
Then if you menu>Object>Object>Save... and drag/drop the jpeg onto
an application eg Artworks, ChangeFSI etc the load fails because the
file name is not correct.

(quoting Bernard Boase)-

NetSurf has output the file name as

34178186-talaj-hornyok-mez_C5_91gazdas_C3_A1gi-earth-talaj-b
ar_C3_A1zd_C3_A1k-f_C3_B6l_C3_B6tt-mez_C5_91-n_C3_B6v_C3_A9n
y-_C3_BCltet_C3_A9si-a-vid_C3_A9ken-m/jpg

but the underscores should be percent signs to code for letters with
Hungarian diacritics in Unicode:

34178186-talaj-hornyok-mez_C5%91gazdas%C3%A1gi-earth-talaj-b
ar%C3%A1zd%C3%A1k-f%C3%B6l%C3%B6tt-mez%C5%91-n%C3%B6v%C3%A9n
y-%C3%BCltet%C3%A9si-a-vid%C3%A9ken-m/jpg

whereupon it works into the apps.

--
John Rickman

Monday, 13 November 2017

LibCSS: new units and autogen script for the selection engine

I wanted to add some new length units to LibCSS, such as rem, vw, vh and others. The problem is that the css_unit value, which is stored in the style bits array, would need to gain a bit to accomodate the new values. Since many properties have length units, this change would require rewriting the files select/computed.h, propget.h and propset.h, because they need to be kept in sync.

My solution, in the git branch lcneves/select-autogen, is a Python script that autogenerates most of computed.h, propget.h and propset.h based on a simple configuration of properties and values. The bits array for each property group is automatically created by a "best fit" heuristics, which has produced optimal results for our data in all of my tests -- not guaranteed, though, since the bin packing problem is np-hard! This way, all three files are kept in sync.

Adding or modifying a property or value is just a matter of editing one line in the file select-config.py. If the property needs special functions in propget.h or propset.h, these can be provided in the file overrides.py (note that the index in the bits array and the bitwise mask and shift will still be autogenerated). Additional header and footer text for the autogenerated files goes in assets.py.

In the future, the script can be easily extended to autogenerate the files in select/properties/. Also, the script treats the groups "style" and "page" as special, but not "uncommon", so that adding more groups like "uncommon" can be done entirely in the config file -- but this would require autogenerating parts of computed.c and arena.c as well, to ensure that these groups are properly created and destroyed.

So, to sum it up: the branch libcss/lcneves/select-autogen features a generator script for a big chunk of the selection engine. Plus, 13 new length units.


Best,
Lucas

Saturday, 11 November 2017

Re: list just quiet, or am I still cut off?

Funnily enuf, a handful of postings came through in the past couple of
hours, from Martin Avison, Tim Hill and myself. All dated today.

Tim Hill wrote on 11 Nov:
> I can see eight postings dated 8 Nov. Message IDs are

> <20171108112311.GG13106@platypus.pepperfish.net>
> <d16f6b19706a9cad2b9edde199d5d9ab@wingsandbeaks.org.uk>
> <d492fd9756.ricp@user.minijem.plus.com>
> <5697c374a7Lists@Torrens.org>
> <5697cbebe8Lists@Torrens.org>
> <5697d25908tim@timil.com>
> <5697c81778tim@timil.com>
> <5697fb898ccvjazz@waitrose.com>

The last one on your list (Chris Newman, "Pane srolling") is the only
one that I see.


--
Jim Nagel www.archivemag.co.uk

i am cut off again

Thanks to those who replied by email to my earlier posting today. I
haven't received any of the Netsurf items they received in the past
few days, nor my own.

It does indeed appear that my Netsurf feed is blocked again. Thought
it was cured last week. Will take it up again with my mail host.

--
Jim Nagel www.archivemag.co.uk

Re: list just quiet, or am I still cut off?

In article <6c9e4e9956.jim@abbeypress.net>,
Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> The last item delivered to me from this list was Dave Higton's, dated
> Nov07 at 20:56.

> I understood that the firewall block of Netsurf traffic (a "port
> flooed") that had somehow come into being at my mail server had been
> cleared on Nov07 at 17:31.

> So have there been 0 postings to this list since Nov07 20:56, or has
> some new blockage come into being?

> I shall now see whether I receive my own post.

I can see eight postings dated 8 Nov. Message IDs are

<20171108112311.GG13106@platypus.pepperfish.net>
<d16f6b19706a9cad2b9edde199d5d9ab@wingsandbeaks.org.uk>
<d492fd9756.ricp@user.minijem.plus.com>
<5697c374a7Lists@Torrens.org>
<5697cbebe8Lists@Torrens.org>
<5697d25908tim@timil.com>
<5697c81778tim@timil.com>
<5697fb898ccvjazz@waitrose.com>

bcc abbeypress

--

Tim Hill

timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk