Well I have to say I hate MDF files but I have succeeded where EDID failed
and I have the monitor I currently use, an old Dell P2714T, running at
1920x1080 on my A9home :)
--
Paul Stewart
Sent from A9home running RISC OS 4.42
--
This mailing list is hosted by RISCOSitory/Soft Rock Software
http://www.riscository.com/mailing-lists/
Sunday, 28 April 2024
[netsurf-users] Re: 6696 fails to start on RISC OS
In message <5b53b78dd7mec@npost.uk>
Chris Newman <mec@npost.uk> wrote:
> 6697 works happily on my FAST Pi Compute Module 4 RISC OS 5.29
Also working fine here on my A9home RISC OS 4.39
Regards
Paul Stewart
Chris Newman <mec@npost.uk> wrote:
> 6697 works happily on my FAST Pi Compute Module 4 RISC OS 5.29
Also working fine here on my A9home RISC OS 4.39
Regards
Paul Stewart
Saturday, 20 April 2024
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <bb8ceea8-189b-fdb0-6ba6-241cb9e83bfe@netsurf-browser.org>,
John-Mark Bell <jmb@netsurf-browser.org> wrote:
> On 20/04/2024 12:32, Chris Newman wrote:
> > In article <5b53b78dd7mec@npost.uk>, Chris Newman <mec@npost.uk>
> >
> >> I looked inside the !System that came with the download. There is no
> >> Socketwatch in the 310 modules directory so I added 0.07 manually.
> >> Made no difference.
> >
> The SocketWatch changes have been removed (with no timeline for
> reintroduction, if ever), hence it is no longer provided in the !System
> in the distribution archive.
> >> ARMEABISupport 1.05 is in the 400 modules folder.
> >
> > Stuart Painting sent me an idea thus...
> >
> >> "AHA! I think I may have spotted what is going wrong. At Netsurf
> >> 3.11, the !Run file has the RMLoad of ARMEABISupport commented out
> >> (at or near line 72 of !Netsurf.!Run). If you uncomment the two
> >> RMEnsure lines, things might work better."
> Please don't do that. The !Run file as-shipped is correct and does not
> require modification.
> > Right. Had a look at all machines and made a chart thus...
> >
> > ARMEABISupport, if there, is in !Boot.Resources.!System.400.Modules
> > (not Network directory).
> >
> >
> > FAST TB 3.12 6697 ARMEABISupport 1.05 OK Lenovo TB 3.11 5433
> > ARMEABISupport none OK AcerNet TB 3.12 6697 ARMEABISupport 1.05
> > Duff
> >
> > --------------------------------------------------- Checked 3.11 on
> > the big Lenovo laptop also running 4.39 & it does indeed have those
> > lines commented out.
> >
> > I then found the !Run file in Netsurf 6697 on the netbook and
> > commented out the lines. Got an "Application may have gone wrong
> > error." SWI &59D01 not known.
> It would. If the ARMEABISupport requirements are uncommented in the
> !Run file, the module is required.
> The problem you have is that, for the last year, the NetSurf CI system
> has produced two different builds of each version for RISC OS:
> * NetSurf-arm-unknown-riscos-gcc-VERSION.zip: built using the old
> GCC 4.7 compiler and compatible with all RISC OS machines capable of
> running RISC OS 4 or later. *
> NetSurf-arm-riscos-gnueabi-gcc-VERSION.zip: built using a newer
> compiler (GCC10) and compatible with machines that have at least a
> StrongARM CPU and running modern versions of RISC OS 5.
> If you are running on old systems (which you are here), you want the
> former. Official releases (so far) have been from the GCC4.7 builds, so
> work everywhere.
Thanks for thet. I'll look for the correct version.
--
Chris Newman
John-Mark Bell <jmb@netsurf-browser.org> wrote:
> On 20/04/2024 12:32, Chris Newman wrote:
> > In article <5b53b78dd7mec@npost.uk>, Chris Newman <mec@npost.uk>
> >
> >> I looked inside the !System that came with the download. There is no
> >> Socketwatch in the 310 modules directory so I added 0.07 manually.
> >> Made no difference.
> >
> The SocketWatch changes have been removed (with no timeline for
> reintroduction, if ever), hence it is no longer provided in the !System
> in the distribution archive.
> >> ARMEABISupport 1.05 is in the 400 modules folder.
> >
> > Stuart Painting sent me an idea thus...
> >
> >> "AHA! I think I may have spotted what is going wrong. At Netsurf
> >> 3.11, the !Run file has the RMLoad of ARMEABISupport commented out
> >> (at or near line 72 of !Netsurf.!Run). If you uncomment the two
> >> RMEnsure lines, things might work better."
> Please don't do that. The !Run file as-shipped is correct and does not
> require modification.
> > Right. Had a look at all machines and made a chart thus...
> >
> > ARMEABISupport, if there, is in !Boot.Resources.!System.400.Modules
> > (not Network directory).
> >
> >
> > FAST TB 3.12 6697 ARMEABISupport 1.05 OK Lenovo TB 3.11 5433
> > ARMEABISupport none OK AcerNet TB 3.12 6697 ARMEABISupport 1.05
> > Duff
> >
> > --------------------------------------------------- Checked 3.11 on
> > the big Lenovo laptop also running 4.39 & it does indeed have those
> > lines commented out.
> >
> > I then found the !Run file in Netsurf 6697 on the netbook and
> > commented out the lines. Got an "Application may have gone wrong
> > error." SWI &59D01 not known.
> It would. If the ARMEABISupport requirements are uncommented in the
> !Run file, the module is required.
> The problem you have is that, for the last year, the NetSurf CI system
> has produced two different builds of each version for RISC OS:
> * NetSurf-arm-unknown-riscos-gcc-VERSION.zip: built using the old
> GCC 4.7 compiler and compatible with all RISC OS machines capable of
> running RISC OS 4 or later. *
> NetSurf-arm-riscos-gnueabi-gcc-VERSION.zip: built using a newer
> compiler (GCC10) and compatible with machines that have at least a
> StrongARM CPU and running modern versions of RISC OS 5.
> If you are running on old systems (which you are here), you want the
> former. Official releases (so far) have been from the GCC4.7 builds, so
> work everywhere.
Thanks for thet. I'll look for the correct version.
--
Chris Newman
[netsurf-users] Re: 6696 fails to start on RISC OS
On 20/04/2024 12:32, Chris Newman wrote:
> In article <5b53b78dd7mec@npost.uk>, Chris Newman <mec@npost.uk> wrote:
>
>
>
>> I looked inside the !System that came with the download. There is no
>> Socketwatch in the 310 modules directory so I added 0.07 manually. Made
>> no difference.
>
The SocketWatch changes have been removed (with no timeline for
reintroduction, if ever), hence it is no longer provided in the !System
in the distribution archive.
>> ARMEABISupport 1.05 is in the 400 modules folder.
>
> Stuart Painting sent me an idea thus...
>
>> "AHA! I think I may have spotted what is going wrong. At Netsurf 3.11,
>> the !Run file has the RMLoad of ARMEABISupport commented out (at or
>> near line 72 of !Netsurf.!Run). If you uncomment the two RMEnsure
>> lines, things might work better."
Please don't do that. The !Run file as-shipped is correct and does not
require modification.
> Right. Had a look at all machines and made a chart thus...
>
> ARMEABISupport, if there, is in !Boot.Resources.!System.400.Modules (not
> Network directory).
>
>
> FAST TB 3.12 6697 ARMEABISupport 1.05 OK
> Lenovo TB 3.11 5433 ARMEABISupport none OK
> AcerNet TB 3.12 6697 ARMEABISupport 1.05 Duff
>
> ---------------------------------------------------
> Checked 3.11 on the big Lenovo laptop also running 4.39 & it does indeed
> have those lines commented out.
>
> I then found the !Run file in Netsurf 6697 on the netbook and commented
> out the lines. Got an "Application may have gone wrong error." SWI &59D01
> not known.
It would. If the ARMEABISupport requirements are uncommented in the !Run
file, the module is required.
The problem you have is that, for the last year, the NetSurf CI system
has produced two different builds of each version for RISC OS:
* NetSurf-arm-unknown-riscos-gcc-VERSION.zip:
built using the old GCC 4.7 compiler and compatible with all
RISC OS machines capable of running RISC OS 4 or later.
* NetSurf-arm-riscos-gnueabi-gcc-VERSION.zip:
built using a newer compiler (GCC10) and compatible with
machines that have at least a StrongARM CPU and running modern
versions of RISC OS 5.
If you are running on old systems (which you are here), you want the
former. Official releases (so far) have been from the GCC4.7 builds, so
work everywhere.
John-Mark.
> In article <5b53b78dd7mec@npost.uk>, Chris Newman <mec@npost.uk> wrote:
>
>
>
>> I looked inside the !System that came with the download. There is no
>> Socketwatch in the 310 modules directory so I added 0.07 manually. Made
>> no difference.
>
The SocketWatch changes have been removed (with no timeline for
reintroduction, if ever), hence it is no longer provided in the !System
in the distribution archive.
>> ARMEABISupport 1.05 is in the 400 modules folder.
>
> Stuart Painting sent me an idea thus...
>
>> "AHA! I think I may have spotted what is going wrong. At Netsurf 3.11,
>> the !Run file has the RMLoad of ARMEABISupport commented out (at or
>> near line 72 of !Netsurf.!Run). If you uncomment the two RMEnsure
>> lines, things might work better."
Please don't do that. The !Run file as-shipped is correct and does not
require modification.
> Right. Had a look at all machines and made a chart thus...
>
> ARMEABISupport, if there, is in !Boot.Resources.!System.400.Modules (not
> Network directory).
>
>
> FAST TB 3.12 6697 ARMEABISupport 1.05 OK
> Lenovo TB 3.11 5433 ARMEABISupport none OK
> AcerNet TB 3.12 6697 ARMEABISupport 1.05 Duff
>
> ---------------------------------------------------
> Checked 3.11 on the big Lenovo laptop also running 4.39 & it does indeed
> have those lines commented out.
>
> I then found the !Run file in Netsurf 6697 on the netbook and commented
> out the lines. Got an "Application may have gone wrong error." SWI &59D01
> not known.
It would. If the ARMEABISupport requirements are uncommented in the !Run
file, the module is required.
The problem you have is that, for the last year, the NetSurf CI system
has produced two different builds of each version for RISC OS:
* NetSurf-arm-unknown-riscos-gcc-VERSION.zip:
built using the old GCC 4.7 compiler and compatible with all
RISC OS machines capable of running RISC OS 4 or later.
* NetSurf-arm-riscos-gnueabi-gcc-VERSION.zip:
built using a newer compiler (GCC10) and compatible with
machines that have at least a StrongARM CPU and running modern
versions of RISC OS 5.
If you are running on old systems (which you are here), you want the
former. Official releases (so far) have been from the GCC4.7 builds, so
work everywhere.
John-Mark.
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b53b78dd7mec@npost.uk>, Chris Newman <mec@npost.uk> wrote:
> > 6696 has an updated SockWatch module. Have you merged the !System in
> > the zip with your own?
> 6697 works happily on my FAST Pi Compute Module 4 RISC OS 5.29
> On Virtual Acorn Adjust 4.39 Windows 10 Acer netbook
> It fails with "Process not known to ARMABI support".
> I have merged the !Boot & !System.
> I looked inside the !System that came with the download. There is no
> Socketwatch in the 310 modules directory so I added 0.07 manually. Made
> no difference.
> ARMEABISupport 1.05 is in the 400 modules folder.
Stuart Painting sent me an idea thus...
> "AHA! I think I may have spotted what is going wrong. At Netsurf 3.11,
> the !Run file has the RMLoad of ARMEABISupport commented out (at or
> near line 72 of !Netsurf.!Run). If you uncomment the two RMEnsure
> lines, things might work better."
Right. Had a look at all machines and made a chart thus...
ARMEABISupport, if there, is in !Boot.Resources.!System.400.Modules (not
Network directory).
FAST TB 3.12 6697 ARMEABISupport 1.05 OK
Lenovo TB 3.11 5433 ARMEABISupport none OK
AcerNet TB 3.12 6697 ARMEABISupport 1.05 Duff
---------------------------------------------------
Checked 3.11 on the big Lenovo laptop also running 4.39 & it does indeed
have those lines commented out.
I then found the !Run file in Netsurf 6697 on the netbook and commented
out the lines. Got an "Application may have gone wrong error." SWI &59D01
not known.
Reverted to my old copy of N 3.10. That works.
Updated to the stable release of 3.11 & that works.
--
Chris Newman
> > 6696 has an updated SockWatch module. Have you merged the !System in
> > the zip with your own?
> 6697 works happily on my FAST Pi Compute Module 4 RISC OS 5.29
> On Virtual Acorn Adjust 4.39 Windows 10 Acer netbook
> It fails with "Process not known to ARMABI support".
> I have merged the !Boot & !System.
> I looked inside the !System that came with the download. There is no
> Socketwatch in the 310 modules directory so I added 0.07 manually. Made
> no difference.
> ARMEABISupport 1.05 is in the 400 modules folder.
Stuart Painting sent me an idea thus...
> "AHA! I think I may have spotted what is going wrong. At Netsurf 3.11,
> the !Run file has the RMLoad of ARMEABISupport commented out (at or
> near line 72 of !Netsurf.!Run). If you uncomment the two RMEnsure
> lines, things might work better."
Right. Had a look at all machines and made a chart thus...
ARMEABISupport, if there, is in !Boot.Resources.!System.400.Modules (not
Network directory).
FAST TB 3.12 6697 ARMEABISupport 1.05 OK
Lenovo TB 3.11 5433 ARMEABISupport none OK
AcerNet TB 3.12 6697 ARMEABISupport 1.05 Duff
---------------------------------------------------
Checked 3.11 on the big Lenovo laptop also running 4.39 & it does indeed
have those lines commented out.
I then found the !Run file in Netsurf 6697 on the netbook and commented
out the lines. Got an "Application may have gone wrong error." SWI &59D01
not known.
Reverted to my old copy of N 3.10. That works.
Updated to the stable release of 3.11 & that works.
--
Chris Newman
Thursday, 18 April 2024
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b4c526636Lists@Torrens.org>,
Richard Torrens (lists) <Lists@Torrens.org> wrote:
> In article <5b4c408979bob@mightyoak.org.uk>,
> Bob Latham <bob@mightyoak.org.uk> wrote:
> > Latest development version 6696 fails to start on RISC OS.
> > Immediate error:
> > "Still watching sockets; can't be killed yet."
> > A machine re-boot does not change this.
> > Bob.
>
> 6696 has an updated SockWatch module. Have you merged the !System in the
> zip with your own?
6697 works happily on my FAST Pi Compute Module 4 RISC OS 5.29
On Virtual Acorn Adjust 4.39 Windows 10 Acer netbook
It fails with "Process not known to ARMABI support".
I have merged the !Boot & !System.
I looked inside the !System that came with the download. There is no
Socketwatch in the 310 modules directory so I added 0.07 manually. Made
no difference.
ARMEABISupport 1.05 is in the 400 modules folder.
Any ideas?
--
Chris Newman
Richard Torrens (lists) <Lists@Torrens.org> wrote:
> In article <5b4c408979bob@mightyoak.org.uk>,
> Bob Latham <bob@mightyoak.org.uk> wrote:
> > Latest development version 6696 fails to start on RISC OS.
> > Immediate error:
> > "Still watching sockets; can't be killed yet."
> > A machine re-boot does not change this.
> > Bob.
>
> 6696 has an updated SockWatch module. Have you merged the !System in the
> zip with your own?
6697 works happily on my FAST Pi Compute Module 4 RISC OS 5.29
On Virtual Acorn Adjust 4.39 Windows 10 Acer netbook
It fails with "Process not known to ARMABI support".
I have merged the !Boot & !System.
I looked inside the !System that came with the download. There is no
Socketwatch in the 310 modules directory so I added 0.07 manually. Made
no difference.
ARMEABISupport 1.05 is in the 400 modules folder.
Any ideas?
--
Chris Newman
Saturday, 13 April 2024
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b504a7c4fnetsurf-users-sub@aconet.nl>,
Frank de Bruijn <netsurf-users-sub@aconet.nl> wrote:
> On 11 Apr, Chris Newman <mec@npost.uk> wrote:
> > I ran the !ModInst from the 0.07 download but got an undefined
> > instruction error
> Not surprising. !ModInst appears to have a more than two decades old
> !RunImage. It was a useful tool at the time, but I should really remove
> it and switch to using the OS's System Merge. I'll look at that later
> today.
Excellent. Thanks for your hard work.
--
Chris Newman
Frank de Bruijn <netsurf-users-sub@aconet.nl> wrote:
> On 11 Apr, Chris Newman <mec@npost.uk> wrote:
> > I ran the !ModInst from the 0.07 download but got an undefined
> > instruction error
> Not surprising. !ModInst appears to have a more than two decades old
> !RunImage. It was a useful tool at the time, but I should really remove
> it and switch to using the OS's System Merge. I'll look at that later
> today.
Excellent. Thanks for your hard work.
--
Chris Newman
Thursday, 11 April 2024
[netsurf-users] Re: 6696 fails to start on RISC OS
On 11 Apr, Chris Newman <mec@npost.uk> wrote:
> I ran the !ModInst from the 0.07 download but got an undefined
> instruction error
Not surprising. !ModInst appears to have a more than two decades old
!RunImage. It was a useful tool at the time, but I should really remove
it and switch to using the OS's System Merge. I'll look at that later
today.
Regards,
--
Frank
> I ran the !ModInst from the 0.07 download but got an undefined
> instruction error
Not surprising. !ModInst appears to have a more than two decades old
!RunImage. It was a useful tool at the time, but I should really remove
it and switch to using the OS's System Merge. I'll look at that later
today.
Regards,
--
Frank
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b500541e6dave@triffid.co.uk>, Dave <dave@triffid.co.uk>
wrote:
> In article <5b4ff405camec@npost.uk>, Chris Newman <mec@npost.uk> wrote:
> > In article <5b4d8b51fbnetsurf@avisoft.f9.co.uk>, Martin Avison
> > <netsurf@avisoft.f9.co.uk> wrote:
> > <Big snip>
> > > The correct way is that the latest version should be used
> > > everywhere, and the old ones removed (as long as the later fixed
> > > version has no incompatible API changes).
> > > Please see the long list of changes made since v0.04y (02-12-2002)
> > > that are included in v0.07 (11-01-2019) some 16 years later.
> > > Other applications may rely on some of those fixes and changes!
> > > The latest v0.07 AFAIK is available at https://www.aconet.nl/tools/
> > I have downloaded v0.07. It has an installation app to put the module
> > in
> > !System.310.Modules.Network.SockWatch
> > Ignoring that for the moment, I delved into the innards and put the
> > module in Hermes inside Netfetch in place of v0.04. Everything seems
> > to be working as normal. Nothing has fallen over. Therefore it seems
> > Hermes would not have any problem with v0.07.
> > I've not yet put it in 310 in case it clashes with Netsurf. I may
> > 'speriment later.
> Each to their own... :-)
> If you remember, I fixed my Hermes and Uniprint to use the SockWatch
> 0.07 in ...!System.310.Modules.Network.
> Neither Hermes nor Uniprint have had any problems with SockWatch 0.07
> in ...!System.310.Modules.Network since I made the changes.
> Netsurf 6696 needs SockWatch 0.07
Just wanted to se what would happen without fiddling with !un files
I ran the !ModInst from the 0.07 download but got an undefined
instruction error so I put it manually in System 310. Now running Netsurf
6697 happily.
--
Chris Newman
wrote:
> In article <5b4ff405camec@npost.uk>, Chris Newman <mec@npost.uk> wrote:
> > In article <5b4d8b51fbnetsurf@avisoft.f9.co.uk>, Martin Avison
> > <netsurf@avisoft.f9.co.uk> wrote:
> > <Big snip>
> > > The correct way is that the latest version should be used
> > > everywhere, and the old ones removed (as long as the later fixed
> > > version has no incompatible API changes).
> > > Please see the long list of changes made since v0.04y (02-12-2002)
> > > that are included in v0.07 (11-01-2019) some 16 years later.
> > > Other applications may rely on some of those fixes and changes!
> > > The latest v0.07 AFAIK is available at https://www.aconet.nl/tools/
> > I have downloaded v0.07. It has an installation app to put the module
> > in
> > !System.310.Modules.Network.SockWatch
> > Ignoring that for the moment, I delved into the innards and put the
> > module in Hermes inside Netfetch in place of v0.04. Everything seems
> > to be working as normal. Nothing has fallen over. Therefore it seems
> > Hermes would not have any problem with v0.07.
> > I've not yet put it in 310 in case it clashes with Netsurf. I may
> > 'speriment later.
> Each to their own... :-)
> If you remember, I fixed my Hermes and Uniprint to use the SockWatch
> 0.07 in ...!System.310.Modules.Network.
> Neither Hermes nor Uniprint have had any problems with SockWatch 0.07
> in ...!System.310.Modules.Network since I made the changes.
> Netsurf 6696 needs SockWatch 0.07
Just wanted to se what would happen without fiddling with !un files
I ran the !ModInst from the 0.07 download but got an undefined
instruction error so I put it manually in System 310. Now running Netsurf
6697 happily.
--
Chris Newman
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b4ff405camec@npost.uk>,
Chris Newman <mec@npost.uk> wrote:
> In article <5b4d8b51fbnetsurf@avisoft.f9.co.uk>, Martin Avison
> <netsurf@avisoft.f9.co.uk> wrote:
> <Big snip>
> > The correct way is that the latest version should be used everywhere,
> > and the old ones removed (as long as the later fixed version has no
> > incompatible API changes).
> > Please see the long list of changes made since v0.04y (02-12-2002) that
> > are included in v0.07 (11-01-2019) some 16 years later.
> > Other applications may rely on some of those fixes and changes!
> > The latest v0.07 AFAIK is available at https://www.aconet.nl/tools/
> I have downloaded v0.07. It has an installation app to put the module in
> !System.310.Modules.Network.SockWatch
> Ignoring that for the moment, I delved into the innards and put the
> module in Hermes inside Netfetch in place of v0.04. Everything seems to
> be working as normal. Nothing has fallen over. Therefore it seems Hermes
> would not have any problem with v0.07.
> I've not yet put it in 310 in case it clashes with Netsurf. I may
> 'speriment later.
Each to their own... :-)
If you remember, I fixed my Hermes and Uniprint to use the SockWatch 0.07
in ...!System.310.Modules.Network.
Neither Hermes nor Uniprint have had any problems with SockWatch 0.07 in
...!System.310.Modules.Network since I made the changes.
Netsurf 6696 needs SockWatch 0.07
Dave
--
Dave Triffid
Chris Newman <mec@npost.uk> wrote:
> In article <5b4d8b51fbnetsurf@avisoft.f9.co.uk>, Martin Avison
> <netsurf@avisoft.f9.co.uk> wrote:
> <Big snip>
> > The correct way is that the latest version should be used everywhere,
> > and the old ones removed (as long as the later fixed version has no
> > incompatible API changes).
> > Please see the long list of changes made since v0.04y (02-12-2002) that
> > are included in v0.07 (11-01-2019) some 16 years later.
> > Other applications may rely on some of those fixes and changes!
> > The latest v0.07 AFAIK is available at https://www.aconet.nl/tools/
> I have downloaded v0.07. It has an installation app to put the module in
> !System.310.Modules.Network.SockWatch
> Ignoring that for the moment, I delved into the innards and put the
> module in Hermes inside Netfetch in place of v0.04. Everything seems to
> be working as normal. Nothing has fallen over. Therefore it seems Hermes
> would not have any problem with v0.07.
> I've not yet put it in 310 in case it clashes with Netsurf. I may
> 'speriment later.
Each to their own... :-)
If you remember, I fixed my Hermes and Uniprint to use the SockWatch 0.07
in ...!System.310.Modules.Network.
Neither Hermes nor Uniprint have had any problems with SockWatch 0.07 in
...!System.310.Modules.Network since I made the changes.
Netsurf 6696 needs SockWatch 0.07
Dave
--
Dave Triffid
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b4d8b51fbnetsurf@avisoft.f9.co.uk>, Martin Avison
<netsurf@avisoft.f9.co.uk> wrote:
<Big snip>
> The correct way is that the latest version should be used everywhere,
> and the old ones removed (as long as the later fixed version has no
> incompatible API changes).
> Please see the long list of changes made since v0.04y (02-12-2002) that
> are included in v0.07 (11-01-2019) some 16 years later.
> Other applications may rely on some of those fixes and changes!
> The latest v0.07 AFAIK is available at https://www.aconet.nl/tools/
I have downloaded v0.07. It has an installation app to put the module in
!System.310.Modules.Network.SockWatch
Ignoring that for the moment, I delved into the innards and put the
module in Hermes inside Netfetch in place of v0.04. Everything seems to
be working as normal. Nothing has fallen over. Therefore it seems Hermes
would not have any problem with v0.07.
I've not yet put it in 310 in case it clashes with Netsurf. I may
'speriment later.
--
Chris Newman
<netsurf@avisoft.f9.co.uk> wrote:
<Big snip>
> The correct way is that the latest version should be used everywhere,
> and the old ones removed (as long as the later fixed version has no
> incompatible API changes).
> Please see the long list of changes made since v0.04y (02-12-2002) that
> are included in v0.07 (11-01-2019) some 16 years later.
> Other applications may rely on some of those fixes and changes!
> The latest v0.07 AFAIK is available at https://www.aconet.nl/tools/
I have downloaded v0.07. It has an installation app to put the module in
!System.310.Modules.Network.SockWatch
Ignoring that for the moment, I delved into the innards and put the
module in Hermes inside Netfetch in place of v0.04. Everything seems to
be working as normal. Nothing has fallen over. Therefore it seems Hermes
would not have any problem with v0.07.
I've not yet put it in 310 in case it clashes with Netsurf. I may
'speriment later.
--
Chris Newman
[netsurf-users] Re: HTTP login does not work with netsurf; works with other browser
In article <b2a3cbb1-275c-4193-bae3-3d304ba0f04c@jeremia.dev>,
Jeremia Dominguez <me@jeremia.dev> wrote:
> some renaming rule that removed ".html" from URLs. If you find a page
> that seems to be gone, just add to the ending.
... but before the anchor, eg:
https://www.netsurf-browser.org/documentation/info#JavaScript which is
linked from the Progress page,
--
John Harrison
Website http://jaharrison.me.uk
Using 4té and ARMX6, both running RISC OS
Jeremia Dominguez <me@jeremia.dev> wrote:
> some renaming rule that removed ".html" from URLs. If you find a page
> that seems to be gone, just add to the ending.
... but before the anchor, eg:
https://www.netsurf-browser.org/documentation/info#JavaScript which is
linked from the Progress page,
--
John Harrison
Website http://jaharrison.me.uk
Using 4té and ARMX6, both running RISC OS
[netsurf-users] Re: HTTP login does not work with netsurf; works with other browser
In article <b2a3cbb1-275c-4193-bae3-3d304ba0f04c@jeremia.dev>,
Jeremia Dominguez <me@jeremia.dev> wrote:
> The website and other online assets seem to have migrated services
> recently, but not all of the old configurations seem to have
> carried over. Among those, seems to be some renaming rule that
> removed ".html" from URLs. If you find a page that seems to be
> gone, just add to the ending.
> https://www.netsurf-browser.org/documentation/progress.html
Not sure how much use that page is though, as it says...
"Last updated 20 December 2012"
> On 4/10/24 03:29, John Harrison wrote:
> > That was a long while ago but the progress page no longer seems
> > to be there.
> > https://www.netsurf-browser.org/documentation/progress
Jeremia Dominguez <me@jeremia.dev> wrote:
> The website and other online assets seem to have migrated services
> recently, but not all of the old configurations seem to have
> carried over. Among those, seems to be some renaming rule that
> removed ".html" from URLs. If you find a page that seems to be
> gone, just add to the ending.
> https://www.netsurf-browser.org/documentation/progress.html
Not sure how much use that page is though, as it says...
"Last updated 20 December 2012"
> On 4/10/24 03:29, John Harrison wrote:
> > That was a long while ago but the progress page no longer seems
> > to be there.
> > https://www.netsurf-browser.org/documentation/progress
[netsurf-users] Re: HTTP login does not work with netsurf; works with other browser
-----BEGIN PGP PUBLIC KEY BLOCK-----
xsDNBGSEBn0BDAC/TmGGNgKk1i0zzyFpcCYEcqaICAwGDA9RDpkL8r9251YSrAXv
5DESCUedSFBHN7tbLoxzgcrVI7Va1eS+HfqHjn1hzVRuk23NRYZvrOLqD7CSKAgt
+z3qSjQweCMZrUnPJ8xUk536TCleaFrShLTgGxDcI4hXxuEVM2YEyt/aw7YCE5pl
wnXc7yeEGVvt21SEHC6oh82rtVUrpkfjM7cOurzGHAPt9hFyJTltf3nZaeZ9PiJ4
plexui3sWYDWcps71LTug7J2rrKE/jsW37kPdklI80PAQQ9ScUhlKAPnSOIah8ii
FP53IVlud/lAkK7JDY23GUodXFL4eWelGzLUZsJws4hHOZOCExNVZPElSfD5DxMG
EjWZ7ftokSCfAjf/QWoct3XhYeYJE2cBrhzZYf4mG8M0dZlTh03mF4x1LaADLGFl
lD7kG0pyLZBdzAc4UC15O3GFJK2mXUqjNQgFP6GV0a++5o4VoS1bDlN/TzrEsUXt
ecc3SWKcpySjY/sAEQEAAc0YSmVyZW1pYSA8bWVAamVyZW1pYS5kZXY+wsENBBMB
CAA3FiEEzl0RNMn3/ZTHXQd3gWSx324JiyMFAmSEBn0FCQWjmoACGwMECwkIBwUV
CAkKCwUWAgMBAAAKCRCBZLHfbgmLI0iiC/9EcULuTRg+GTnZfhWckPWZ2uJL38+L
ge79GZJPmHSvz7GrXo+fhIsjpWIYLWYYeKN78k0SIbm4VPVCvxn0HOv3tN3i4xNI
2dceceELq3qL6PcTFmPdq8PdqMZjW6A0AgP4WIwUvpa9Wt7tzDiT51Wn/hcPiJ92
9UPGZitTAuWSb8OZHqsReWm7YH964d/9MyxapV44KnEXkro7WhbBh5ilc4ydowO2
sFf+tySN/uVS+Jo5yafVT0vWbq6vt+UXeIShTv5ffrcoLeZr2kuBbzcG3Pa4RaG0
As279nhGegRRUGcWk8G0ECrGDOD8lmmgRQg+3oavP+lUxcZz0mdDnqoUPuh9aKAE
GfVF23WE13VY0cMHrdXEE8gdb74WtMVtmNzUHg01fshfzWykx5JoLFKArBRjrU7d
+zp/+cyR+9t9eooZ+VjUJIrk78KEYBDdVIiuZMWW6I3BWkSC7PEzEMGbY+Y6ugpz
dFcZTvvz/3Xg5566aDDYAAcuP0CFGyF0vfvOwM0EZIQGfQEMAM4uqFh6NziCvUx4
nQ2kTe32shvCWShUR2hEMY8j0Y5p4bactAsdLWMSMfngN11JUkP9DFuajP9x+qi/
HzlgRP32W1RI7Zw4TTzoePEW9vw1lW5iJy633klucgHV+4QQLCBLM0ZiEp0xqG4M
eZZZ56K/aKg/CwhKabAbBtpgjCvoRZS97eNlHwMoCAwpisZNO+SIF9z4ag8jgK2I
h0/eT3WbcdGlDH5HjUQQJCe3I3Zfy9betuHwjUqq9x81XsoOR+BbPogU4nuq6RVj
4tsPzjzAjSQM0B5+wF2AJZLevt6aP1xIWne9WpFeLonuEr/1I4AaKBJev6GyqOTe
s7LOq/MbTgug79UgP+/7CHpE1St9g+Yi2UjSGDJb0+SbflL8Dw6iQtrgBU5bBQoL
r8y4EuoT3AApX2Lk0FOygepuRsBkugUFdxdr7pwPUmeQBQzPmcT8ywTpufXZLHBd
gKtJOVSuG/uHn+5jHtq0Fit9N1FF3Vjzp4HsXZygK46C+QbeMQARAQABwsD8BBgB
CAAmFiEEzl0RNMn3/ZTHXQd3gWSx324JiyMFAmSEBn4FCQWjmoACGwwACgkQgWSx
324JiyMohwv/c5caLMcMEOvQXCRU6HCOvlAEbrgJC2kuFzXy1FKCOO8BqtKo6MQC
zFj83u6plqRDWhlE7kPKIHy6aFOAiWBQLjZwYE3rym9aQKqFcqRL/+dWixMDSu1w
ErPHevJMfbmPy3BibsH8A8BtWf45Gvu3o0IIJM1MtsQ6NMZr/2INNHN91tABEyuQ
N8K9M70hw8deym6VwOzrgqaril5zJsZkA1+P6bz2G6kEQX+PgPlGh8zEB8jLlsGQ
wbGHnnh2hgQ9GbwbVbG0QAnogjyDfkk5ZuhQzkV448uqxd0Mknm5fHC3cGWxdu9r
FKEy6vWrqaBRj9WIkrsI0OPKDOikZZa3I+hkL9OorKLLTMvOJzDlTmv0MXBeZKfI
ApkvFX8YMgxVidSbnwZLhFD4zmf2aqNmAchSUbMaOebK2Lw9RuLJVWS892PwwlqJ
YwOPf1olfwsWbMSscYO5tmdS7uVoDqJEAPuewuXEmDq6RgRRr022wgxBrQD3lRQR
GQU3SMesM0o7
=qctb
-----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
wsD5BAABCAAjFiEEzl0RNMn3/ZTHXQd3gWSx324JiyMFAmYXjQ8FAwAAAAAACgkQgWSx324JiyMO
ZAv8DGefkU4rTpGj9ZuRRdUiirWHoDAS2r8RXV8W5zqPW1sAptBQTd27EdFYT+e+fNREzHLmn+gS
Wetce2GqLcP1HHnj3XalHa6ziRAGa7n/SkXuBghWYQeW/qUAupoAmOF245Yqd+YTcM8eDvgnUXcM
hk3Yz/FaQHxrWZPQdkk2hjM1s55BdmNREC5scMh3KPIwIBNX7nn26474nvkK3DMOxP/ca5jd/472
4Lwf+OHeT3O3Hoo6++eem1WzACc+k5EPinGcuLwTDkE0TOk2jIIrUWKbL1vOEw1ybfo1t81N3RbQ
THHnZjQhx0EFgh+xywZqJgfsdYNgHZ3E74fS3fr1+158n/n6SeJKfro6eHe8Pmfkf7945LySzdh5
Fn8ACYH/UYA5S2/WuNa6WeUu0otvCjtbyiPI/aTkS0QP+5AAaIy8/Dk+3Qn9hOF7SL8PwqvcDr7H
VRrP5gIwBZFodQC0IYUHOr1kCHpuG00M3Aynk4FxFXUhBuBJvQY5rGjWASq6
=rPLR
-----END PGP SIGNATURE-----
The website and other online assets seem to have migrated services
recently, but not all of the old configurations seem to have carried
over. Among those, seems to be some renaming rule that removed ".html"
from URLs. If you find a page that seems to be gone, just add to the ending.
https://www.netsurf-browser.org/documentation/progress.html
On 4/10/24 03:29, John Harrison wrote:
> That was a long while ago but the progress page no longer seems to be
> there. https://www.netsurf-browser.org/documentation/progress
xsDNBGSEBn0BDAC/TmGGNgKk1i0zzyFpcCYEcqaICAwGDA9RDpkL8r9251YSrAXv
5DESCUedSFBHN7tbLoxzgcrVI7Va1eS+HfqHjn1hzVRuk23NRYZvrOLqD7CSKAgt
+z3qSjQweCMZrUnPJ8xUk536TCleaFrShLTgGxDcI4hXxuEVM2YEyt/aw7YCE5pl
wnXc7yeEGVvt21SEHC6oh82rtVUrpkfjM7cOurzGHAPt9hFyJTltf3nZaeZ9PiJ4
plexui3sWYDWcps71LTug7J2rrKE/jsW37kPdklI80PAQQ9ScUhlKAPnSOIah8ii
FP53IVlud/lAkK7JDY23GUodXFL4eWelGzLUZsJws4hHOZOCExNVZPElSfD5DxMG
EjWZ7ftokSCfAjf/QWoct3XhYeYJE2cBrhzZYf4mG8M0dZlTh03mF4x1LaADLGFl
lD7kG0pyLZBdzAc4UC15O3GFJK2mXUqjNQgFP6GV0a++5o4VoS1bDlN/TzrEsUXt
ecc3SWKcpySjY/sAEQEAAc0YSmVyZW1pYSA8bWVAamVyZW1pYS5kZXY+wsENBBMB
CAA3FiEEzl0RNMn3/ZTHXQd3gWSx324JiyMFAmSEBn0FCQWjmoACGwMECwkIBwUV
CAkKCwUWAgMBAAAKCRCBZLHfbgmLI0iiC/9EcULuTRg+GTnZfhWckPWZ2uJL38+L
ge79GZJPmHSvz7GrXo+fhIsjpWIYLWYYeKN78k0SIbm4VPVCvxn0HOv3tN3i4xNI
2dceceELq3qL6PcTFmPdq8PdqMZjW6A0AgP4WIwUvpa9Wt7tzDiT51Wn/hcPiJ92
9UPGZitTAuWSb8OZHqsReWm7YH964d/9MyxapV44KnEXkro7WhbBh5ilc4ydowO2
sFf+tySN/uVS+Jo5yafVT0vWbq6vt+UXeIShTv5ffrcoLeZr2kuBbzcG3Pa4RaG0
As279nhGegRRUGcWk8G0ECrGDOD8lmmgRQg+3oavP+lUxcZz0mdDnqoUPuh9aKAE
GfVF23WE13VY0cMHrdXEE8gdb74WtMVtmNzUHg01fshfzWykx5JoLFKArBRjrU7d
+zp/+cyR+9t9eooZ+VjUJIrk78KEYBDdVIiuZMWW6I3BWkSC7PEzEMGbY+Y6ugpz
dFcZTvvz/3Xg5566aDDYAAcuP0CFGyF0vfvOwM0EZIQGfQEMAM4uqFh6NziCvUx4
nQ2kTe32shvCWShUR2hEMY8j0Y5p4bactAsdLWMSMfngN11JUkP9DFuajP9x+qi/
HzlgRP32W1RI7Zw4TTzoePEW9vw1lW5iJy633klucgHV+4QQLCBLM0ZiEp0xqG4M
eZZZ56K/aKg/CwhKabAbBtpgjCvoRZS97eNlHwMoCAwpisZNO+SIF9z4ag8jgK2I
h0/eT3WbcdGlDH5HjUQQJCe3I3Zfy9betuHwjUqq9x81XsoOR+BbPogU4nuq6RVj
4tsPzjzAjSQM0B5+wF2AJZLevt6aP1xIWne9WpFeLonuEr/1I4AaKBJev6GyqOTe
s7LOq/MbTgug79UgP+/7CHpE1St9g+Yi2UjSGDJb0+SbflL8Dw6iQtrgBU5bBQoL
r8y4EuoT3AApX2Lk0FOygepuRsBkugUFdxdr7pwPUmeQBQzPmcT8ywTpufXZLHBd
gKtJOVSuG/uHn+5jHtq0Fit9N1FF3Vjzp4HsXZygK46C+QbeMQARAQABwsD8BBgB
CAAmFiEEzl0RNMn3/ZTHXQd3gWSx324JiyMFAmSEBn4FCQWjmoACGwwACgkQgWSx
324JiyMohwv/c5caLMcMEOvQXCRU6HCOvlAEbrgJC2kuFzXy1FKCOO8BqtKo6MQC
zFj83u6plqRDWhlE7kPKIHy6aFOAiWBQLjZwYE3rym9aQKqFcqRL/+dWixMDSu1w
ErPHevJMfbmPy3BibsH8A8BtWf45Gvu3o0IIJM1MtsQ6NMZr/2INNHN91tABEyuQ
N8K9M70hw8deym6VwOzrgqaril5zJsZkA1+P6bz2G6kEQX+PgPlGh8zEB8jLlsGQ
wbGHnnh2hgQ9GbwbVbG0QAnogjyDfkk5ZuhQzkV448uqxd0Mknm5fHC3cGWxdu9r
FKEy6vWrqaBRj9WIkrsI0OPKDOikZZa3I+hkL9OorKLLTMvOJzDlTmv0MXBeZKfI
ApkvFX8YMgxVidSbnwZLhFD4zmf2aqNmAchSUbMaOebK2Lw9RuLJVWS892PwwlqJ
YwOPf1olfwsWbMSscYO5tmdS7uVoDqJEAPuewuXEmDq6RgRRr022wgxBrQD3lRQR
GQU3SMesM0o7
=qctb
-----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
wsD5BAABCAAjFiEEzl0RNMn3/ZTHXQd3gWSx324JiyMFAmYXjQ8FAwAAAAAACgkQgWSx324JiyMO
ZAv8DGefkU4rTpGj9ZuRRdUiirWHoDAS2r8RXV8W5zqPW1sAptBQTd27EdFYT+e+fNREzHLmn+gS
Wetce2GqLcP1HHnj3XalHa6ziRAGa7n/SkXuBghWYQeW/qUAupoAmOF245Yqd+YTcM8eDvgnUXcM
hk3Yz/FaQHxrWZPQdkk2hjM1s55BdmNREC5scMh3KPIwIBNX7nn26474nvkK3DMOxP/ca5jd/472
4Lwf+OHeT3O3Hoo6++eem1WzACc+k5EPinGcuLwTDkE0TOk2jIIrUWKbL1vOEw1ybfo1t81N3RbQ
THHnZjQhx0EFgh+xywZqJgfsdYNgHZ3E74fS3fr1+158n/n6SeJKfro6eHe8Pmfkf7945LySzdh5
Fn8ACYH/UYA5S2/WuNa6WeUu0otvCjtbyiPI/aTkS0QP+5AAaIy8/Dk+3Qn9hOF7SL8PwqvcDr7H
VRrP5gIwBZFodQC0IYUHOr1kCHpuG00M3Aynk4FxFXUhBuBJvQY5rGjWASq6
=rPLR
-----END PGP SIGNATURE-----
The website and other online assets seem to have migrated services
recently, but not all of the old configurations seem to have carried
over. Among those, seems to be some renaming rule that removed ".html"
from URLs. If you find a page that seems to be gone, just add to the ending.
https://www.netsurf-browser.org/documentation/progress.html
On 4/10/24 03:29, John Harrison wrote:
> That was a long while ago but the progress page no longer seems to be
> there. https://www.netsurf-browser.org/documentation/progress
Wednesday, 10 April 2024
[netsurf-users] Re: HTTP login does not work with netsurf; works with other browser
In article <493c75ce-4045-40a3-b317-d347795af177@gmx.net>,
Edwin Steiner <dmarc-noreply@freelists.org> (edwin.steiner) wrote:
> Either the web interface uses some incompatible scripting or NetSurf is
> missing support for some things.
When I last saw the progress page, script support was very incomplete.
That was a long while ago but the progress page no longer seems to be
there. https://www.netsurf-browser.org/documentation/progress
--
John Harrison
Website http://jaharrison.me.uk
Using 4té and ARMX6, both running RISC OS
Edwin Steiner <dmarc-noreply@freelists.org> (edwin.steiner) wrote:
> Either the web interface uses some incompatible scripting or NetSurf is
> missing support for some things.
When I last saw the progress page, script support was very incomplete.
That was a long while ago but the progress page no longer seems to be
there. https://www.netsurf-browser.org/documentation/progress
--
John Harrison
Website http://jaharrison.me.uk
Using 4té and ARMX6, both running RISC OS
Tuesday, 9 April 2024
[netsurf-dev] Re: NetSurf 6696 fails to start on RISC OS
On 09/04/2024 21:14, David Higton wrote:
> For background, quoting Rob Kendrick:
>
>> My /guess/ is that SocketWatch (or similar) is running via an
>> application launched at boot and it is an earlier version than NetSurf
>> requires, so NetSurf's !Run's RMEnsure tries to replace it with a newer
>> version?
>
> At last Saturday nights RISC OS coding zoom meeting there was discussion
> of this SocketWatch issue and John Rickman was asked to write to this
> list seeking some information. (He's only subscribed to ns-users, so
> I've taken over the task.) We looked at the change log for v0.07 and
> tested the latest NetSurf against v0.04. It appeared to run without
> problems.
>
> Would you be willing in the short term to RMensure against v0.04 instead
> of v0.07. This would avoid some breakage and people having to change
> their run files.
>
I have now reverted all this functionality completely as I would prefer
not to declare a dependency on something with which we have not tested.
> The documentation provided with 0.07 specifically says that it is an
> unofficial release. The last "official" release seems to have been
> 0.04. Is it wise to force people to update their master !System with
> an unofficial release?
Yes, it is. The original author moved on over 20 years ago, the module
was made 32bit compatible by the Nettle developers in 2003 and committed
to their CVS at that time. Later, Frank de Bruijn became the de-facto
maintainer after his attempts to feed his changes back failed.
Further, in June 2012, the Nettle developers committed the sources for
his version 0.06 to their CVS and removed the historic 0.04y sources
they had been carrying up to that point. I cannot point you at the
Nettle CVS repository on Sourceforge because there is no longer a web
interface for it, and I wouldn't want to force anyone to use a CVS
client in 2024. Instead, here's the commit history from a copy of the
Nettle source repository in Git:
https://github.com/dpt/Nettle/commits/master/SocketWatch
To all intents and purposes, therefore, Frank's version is the official,
maintained, source of the module.
> Surely better to RMensure the official version if it works as expected.
> (The changelog shows no functional/API changes since 0.04). By all means
> include 0.07 in your zip, but use "RMensure" they way it was designed -
> to specify the minimum version the will function with your software.
We tested with, and thus declared a dependency on, the 0.07 release,
which is now 5 years old. We considered that 5 years was plenty of time
for people to have upgraded and, tbh, I'm somewhat surprised by the
suggestion that reverting to a dependency on 20+ year old abandonware is
a sensible course of action, given the existence of newer, less buggy,
maintained versions.
That this caused NetSurf not to run on systems running software that
vendored its own copy of the module, instead of using the system-wide
resources, is unfortunate, but was hardly foreseeable. Regardless,
lesson learned: never change anything in the RISC OS frontend.
J.
> For background, quoting Rob Kendrick:
>
>> My /guess/ is that SocketWatch (or similar) is running via an
>> application launched at boot and it is an earlier version than NetSurf
>> requires, so NetSurf's !Run's RMEnsure tries to replace it with a newer
>> version?
>
> At last Saturday nights RISC OS coding zoom meeting there was discussion
> of this SocketWatch issue and John Rickman was asked to write to this
> list seeking some information. (He's only subscribed to ns-users, so
> I've taken over the task.) We looked at the change log for v0.07 and
> tested the latest NetSurf against v0.04. It appeared to run without
> problems.
>
> Would you be willing in the short term to RMensure against v0.04 instead
> of v0.07. This would avoid some breakage and people having to change
> their run files.
>
I have now reverted all this functionality completely as I would prefer
not to declare a dependency on something with which we have not tested.
> The documentation provided with 0.07 specifically says that it is an
> unofficial release. The last "official" release seems to have been
> 0.04. Is it wise to force people to update their master !System with
> an unofficial release?
Yes, it is. The original author moved on over 20 years ago, the module
was made 32bit compatible by the Nettle developers in 2003 and committed
to their CVS at that time. Later, Frank de Bruijn became the de-facto
maintainer after his attempts to feed his changes back failed.
Further, in June 2012, the Nettle developers committed the sources for
his version 0.06 to their CVS and removed the historic 0.04y sources
they had been carrying up to that point. I cannot point you at the
Nettle CVS repository on Sourceforge because there is no longer a web
interface for it, and I wouldn't want to force anyone to use a CVS
client in 2024. Instead, here's the commit history from a copy of the
Nettle source repository in Git:
https://github.com/dpt/Nettle/commits/master/SocketWatch
To all intents and purposes, therefore, Frank's version is the official,
maintained, source of the module.
> Surely better to RMensure the official version if it works as expected.
> (The changelog shows no functional/API changes since 0.04). By all means
> include 0.07 in your zip, but use "RMensure" they way it was designed -
> to specify the minimum version the will function with your software.
We tested with, and thus declared a dependency on, the 0.07 release,
which is now 5 years old. We considered that 5 years was plenty of time
for people to have upgraded and, tbh, I'm somewhat surprised by the
suggestion that reverting to a dependency on 20+ year old abandonware is
a sensible course of action, given the existence of newer, less buggy,
maintained versions.
That this caused NetSurf not to run on systems running software that
vendored its own copy of the module, instead of using the system-wide
resources, is unfortunate, but was hardly foreseeable. Regardless,
lesson learned: never change anything in the RISC OS frontend.
J.
[netsurf-dev] Re: NetSurf 6696 fails to start on RISC OS
On Tue, Apr 09, 2024 at 09:14:37PM +0100, David Higton wrote:
> R-Comp have already confirmed that they will QA this new version with
> their software and update as necessary. The upgrades won't, of course,
> help those who don't/won't upgrate directly.
The fix is for R-Comp to ship a !System containing the module they want,
and users use the SysMerge facility when installing.
This is how shared modules are meant to be distributed and managed -
this isn't our bug. 0.07 is only "unofficial" in that the original
author no longer apparently has any interest in RISC OS to make releases
so somebody else has taken over maintainership and is using language
that avoids any toe-stepping.
To repeat, R-Comp's bug, us bodging around it doesn't fix the issue
which may happen with other applications too. It's resolved by them
fixing their software.
(I note that SocketWatch is GPLed? It is probably sticky for R-Comp to
be distributing that bundled anyway unless they're including a written
offer or its source as part of Hermes et al.)
B.
> R-Comp have already confirmed that they will QA this new version with
> their software and update as necessary. The upgrades won't, of course,
> help those who don't/won't upgrate directly.
The fix is for R-Comp to ship a !System containing the module they want,
and users use the SysMerge facility when installing.
This is how shared modules are meant to be distributed and managed -
this isn't our bug. 0.07 is only "unofficial" in that the original
author no longer apparently has any interest in RISC OS to make releases
so somebody else has taken over maintainership and is using language
that avoids any toe-stepping.
To repeat, R-Comp's bug, us bodging around it doesn't fix the issue
which may happen with other applications too. It's resolved by them
fixing their software.
(I note that SocketWatch is GPLed? It is probably sticky for R-Comp to
be distributing that bundled anyway unless they're including a written
offer or its source as part of Hermes et al.)
B.
[netsurf-users] Re: HTTP login does not work with netsurf; works with other browser
Apr 9, 2024 15:45:56 John Harrison <john@jaharrison.me.uk>:
> I can't login to my router with NetSurf. I get a different error (Unable
> to fetch document) but the effect is the same. I have always assumed it
> was because NetSurf couldn't handle Script.
About the scripting: The login attempt still fails when I enable JavaScript in NetSurf with the same behavior. However, with JavaScript enabled, I see errors from running the script in the console.
Either the web interface uses some incompatible scripting or NetSurf is missing support for some things.
Too bad! It would have been nice to use NetSurf as a light, locally installed browser for admin tasks. I love that I can build it from source in a reasonable time even on weak hardware and that it has such a small set of dependencies.
best regards
Edwin
> I can't login to my router with NetSurf. I get a different error (Unable
> to fetch document) but the effect is the same. I have always assumed it
> was because NetSurf couldn't handle Script.
About the scripting: The login attempt still fails when I enable JavaScript in NetSurf with the same behavior. However, with JavaScript enabled, I see errors from running the script in the console.
Either the web interface uses some incompatible scripting or NetSurf is missing support for some things.
Too bad! It would have been nice to use NetSurf as a light, locally installed browser for admin tasks. I love that I can build it from source in a reasonable time even on weak hardware and that it has such a small set of dependencies.
best regards
Edwin
[netsurf-dev] NetSurf 6696 fails to start on RISC OS
For background, quoting Rob Kendrick:
> My /guess/ is that SocketWatch (or similar) is running via an
> application launched at boot and it is an earlier version than NetSurf
> requires, so NetSurf's !Run's RMEnsure tries to replace it with a newer
> version?
At last Saturday nights RISC OS coding zoom meeting there was discussion
of this SocketWatch issue and John Rickman was asked to write to this
list seeking some information. (He's only subscribed to ns-users, so
I've taken over the task.) We looked at the change log for v0.07 and
tested the latest NetSurf against v0.04. It appeared to run without
problems.
Would you be willing in the short term to RMensure against v0.04 instead
of v0.07. This would avoid some breakage and people having to change
their run files.
This is significant only because older/current versions of SocketWatch
cannot be replaced "live" as they are in use. Thus simply RMensuring a
newer version will fail.
R-Comp have already confirmed that they will QA this new version with
their software and update as necessary. The upgrades won't, of course,
help those who don't/won't upgrate directly.
The documentation provided with 0.07 specifically says that it is an
unofficial release. The last "official" release seems to have been
0.04. Is it wise to force people to update their master !System with
an unofficial release?
Surely better to RMensure the official version if it works as expected.
(The changelog shows no functional/API changes since 0.04). By all means
include 0.07 in your zip, but use "RMensure" they way it was designed -
to specify the minimum version the will function with your software.
David
> My /guess/ is that SocketWatch (or similar) is running via an
> application launched at boot and it is an earlier version than NetSurf
> requires, so NetSurf's !Run's RMEnsure tries to replace it with a newer
> version?
At last Saturday nights RISC OS coding zoom meeting there was discussion
of this SocketWatch issue and John Rickman was asked to write to this
list seeking some information. (He's only subscribed to ns-users, so
I've taken over the task.) We looked at the change log for v0.07 and
tested the latest NetSurf against v0.04. It appeared to run without
problems.
Would you be willing in the short term to RMensure against v0.04 instead
of v0.07. This would avoid some breakage and people having to change
their run files.
This is significant only because older/current versions of SocketWatch
cannot be replaced "live" as they are in use. Thus simply RMensuring a
newer version will fail.
R-Comp have already confirmed that they will QA this new version with
their software and update as necessary. The upgrades won't, of course,
help those who don't/won't upgrate directly.
The documentation provided with 0.07 specifically says that it is an
unofficial release. The last "official" release seems to have been
0.04. Is it wise to force people to update their master !System with
an unofficial release?
Surely better to RMensure the official version if it works as expected.
(The changelog shows no functional/API changes since 0.04). By all means
include 0.07 in your zip, but use "RMensure" they way it was designed -
to specify the minimum version the will function with your software.
David
[netsurf-users] Re: HTTP login does not work with netsurf; works with other browser
In article <b9e95eb0-8e06-4925-b6e0-fc610abe6f4c@gmx.net>,
Edwin Steiner <dmarc-noreply@freelists.org> (edwin.steiner) wrote:
> I'm interested in using netsurf for some admin tasks. I just tried to
> log in to the HTTP web interface of my DSL modem using netsurf but the
> login failed, claiming user name and password are not valid.
I can't login to my router with NetSurf. I get a different error (Unable
to fetch document) but the effect is the same. I have always assumed it
was because NetSurf couldn't handle Script.
--
John Harrison
Website http://jaharrison.me.uk
Using 4té and ARMX6, both running RISC OS
Edwin Steiner <dmarc-noreply@freelists.org> (edwin.steiner) wrote:
> I'm interested in using netsurf for some admin tasks. I just tried to
> log in to the HTTP web interface of my DSL modem using netsurf but the
> login failed, claiming user name and password are not valid.
I can't login to my router with NetSurf. I get a different error (Unable
to fetch document) but the effect is the same. I have always assumed it
was because NetSurf couldn't handle Script.
--
John Harrison
Website http://jaharrison.me.uk
Using 4té and ARMX6, both running RISC OS
[netsurf-users] HTTP login does not work with netsurf; works with other browser
Hello!
I'm interested in using netsurf for some admin tasks. I just tried to log in
to the HTTP web interface of my DSL modem using netsurf but the login
failed, claiming user name and password are not valid.
Using Chrome, I can log in to the same box using the same user/password
just fine.
I'm wondering what could be wrong here and how I could go about
debugging this problem.
best regards
Edwin
I'm interested in using netsurf for some admin tasks. I just tried to log in
to the HTTP web interface of my DSL modem using netsurf but the login
failed, claiming user name and password are not valid.
Using Chrome, I can log in to the same box using the same user/password
just fine.
I'm wondering what could be wrong here and how I could go about
debugging this problem.
best regards
Edwin
Monday, 8 April 2024
[netsurf-dev] [PATCH] Fix spelling mistakes in implementing-new-frontend.md
---
docs/implementing-new-frontend.md | 78 +++++++++++++++----------------
1 file changed, 39 insertions(+), 39 deletions(-)
diff --git a/docs/implementing-new-frontend.md b/docs/implementing-new-frontend.md
index 4bda47af0..b0069531f 100644
--- a/docs/implementing-new-frontend.md
+++ b/docs/implementing-new-frontend.md
@@ -54,14 +54,14 @@ cookie, bookmark, history windows which require only minimal frontend
support with the [core window API](docs/core-window-interface.md).
A frontend developer is free to implement any and all of this generic
-functionality thelselves in a manner more integrated into a toolkit.
+functionality themselves in a manner more integrated into a toolkit.
# Implementation
A frontend is generally named for the toolkit it is implementing (i.e
gtk for the GTK+ toolkit). It is advisable to be as specific as
possible e.g. the frontend for the windows operating system should
-have been named win32 allowing for an impementation using a differnt
+have been named win32 allowing for an implementation using a different
toolkit (e.g mfc)
All the files needed for the frontend are contained in a single
@@ -80,7 +80,7 @@ included from the core Makefile):
- `Makefile.defaults` - allows setting frontend specific makefile variables and overriding of the default core build variables.
- `Makefile.tools` - allows setting up frontend specific build tooling (as a minimum a tool for the package configuration in PKG_CONFIG)
-Source code modules can be named as the devloper desires within the
+Source code modules can be named as the developer desires within the
frontend directory and should be added to the SOURCES variable as
desired.
@@ -93,17 +93,17 @@ The usual shape for the `main()` function is a six step process:
1. The frontends operation tables are registered with NetSurf
2. The toolkit specific initialisation is performed (which may involve calling NetSurf provided utility functions for support operations like logging, message translations etc.)
3. Initialise the NetSurf core. After this point all browser functionality is available and registered operations can be called.
- 4. Perform toolkiit setup, usually opening the initial browsing window (perhaps according to user preferences)
- 5. Run the toolkits main loop while ensuring the Netsurf scheduled operations are also run at teh apropriate time.
+ 4. Perform toolkit setup, usually opening the initial browsing window (perhaps according to user preferences)
+ 5. Run the toolkits main loop while ensuring the Netsurf scheduled operations are also run at the appropriate time.
6. Finalisation on completion.
## NetSurf operations tables
The frontend will generally call netsurf interfaces to get a desired
-behaviour e.g. `browser_window_create()` to create a new browsing
+behavior e.g. `browser_window_create()` to create a new browsing
context (the `browser_window_` prefix is historical and does not
necessarily create a window e.g. on gtk it is more likely to open a
-tab in an existing window). To achive the desired operation some
+tab in an existing window). To achieve the desired operation some
operations need to be performed by the frontend under control of
NetSurf, these operations are listed in tables.
@@ -113,22 +113,22 @@ tables (and the tables themselves) must remain valid until
`netsurf_exit()` is called.
There are (currently) twelve sets of operation tables held in separate
-structures. Only five of these are mandantory (misc, window, fetch,
+structures. Only five of these are mandatory (misc, window, fetch,
bitmap and layout).
-In this context mandantory means the tables must be non NULL and do
-not have a suitable default. Each of the mandantory sets contain
+In this context mandatory means the tables must be non NULL and do
+not have a suitable default. Each of the mandatory sets contain
function pointers to implement operations.
### misc operation table
-The only mandantory operation in this table is schedule.
+The only mandatory operation in this table is schedule.
When schedule is called the frontend must arrange for the passed
callback to be called with the context parameter after a number of
-miliseconds.
+milliseconds.
-This callback is typicaly driven through the toolkits event loop and
+This callback is typically driven through the toolkits event loop and
it is important such callbacks are not attempted from an operation.
### window operation table
@@ -143,9 +143,9 @@ generally assumed to contain at least a reference to the underlying
`browser_window` which is provided in the initial create operation to
allow subsequent use of various core functionality.
-The mandantory window operations are:
+The mandatory window operations are:
- create - create a new browsing context widget in the frontend toolkit
- - destroy - destoy a previously created `gui_window`
+ - destroy - destroy a previously created `gui_window`
- invalidate - mark an area of the browsing context viewport as requiring redraw (note no redraw should be attempted from here)
- get_scroll - get the scroll offsets from the toolkit drawing widget
- set_scroll - set the scroll offsets on the toolkit drawing widget
@@ -157,13 +157,13 @@ The mandantory window operations are:
The fetch operations allow the built in scheme fetchers (file, about, resource) to obtain additional information necessary to complete their operation.
-The two mandantory operations are:
+The two mandatory operations are:
- `filetype` - allows the file scheme to obtain a mime type from a file path e.g. `a.file.name.png` would result in `image/png`
- `get_resource_url` - maps resource scheme paths to URL e.g. `resource:default.css` to `file:///usr/share/netsurf/default.css`
### bitmap operation table
-The bitmap table and all of its operations are mandantory only because
+The bitmap table and all of its operations are mandatory only because
the empty defaults have not been included as it is assumed a browser
will want to display images.
@@ -173,7 +173,7 @@ until full implementations are made.
### layout operation table
The layout table is used to layout text. All operations are given
-strings to manipulate encoded in UTF-8. There are three mandantory
+strings to manipulate encoded in UTF-8. There are three mandatory
operations:
- `width` - Calculate the width of a string.
- `position` - Find the position in a string where an x coordinate falls.
@@ -184,7 +184,7 @@ operations:
Rather than attempt to describe every aspect of an implementation we
will rather work from an actual minimal example for the FLTK toolkit.
-This is availble as a single commit (`git show 28ecbf82ed3024f51be4c87928fd91bacfc15cbc`) in the NetSurf source repository. Alternatively it can be [viewed in a web browser](https://git.netsurf-browser.org/netsurf.git/commit/?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc).
+This is available as a single commit (`git show 28ecbf82ed3024f51be4c87928fd91bacfc15cbc`) in the NetSurf source repository. Alternatively it can be [viewed in a web browser](https://git.netsurf-browser.org/netsurf.git/commit/?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc).
This represents the absolute minimum implementation to get a browser
window on screen (and be able to click visible links). It is
@@ -201,13 +201,13 @@ As previously described the three GNU Make files are added:
[Makefile](https://git.netsurf-browser.org/netsurf.git/diff/frontends/fltk/Makefile?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc)
this shows how the flags are extended to add the fltk headers and
-library. Additionaly the list of sources are built here, as teh
+library. Additionally the list of sources are built here, as the
comment suggests it is important the SOURCES variable is not expanded
-here so the S_FRONTEND variable is used to allow expansion at teh
+here so the S_FRONTEND variable is used to allow expansion at the
correct time in the build process.
[Makefile.defaults](https://git.netsurf-browser.org/netsurf.git/diff/frontends/fltk/Makefile.defaults?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc)
-has the default setting to control the build parameters and file locations. These can be overriden by the `Makefile.config` at compile time.
+has the default setting to control the build parameters and file locations. These can be overridden by the `Makefile.config` at compile time.
[Makefile.tools](https://git.netsurf-browser.org/netsurf.git/diff/frontends/fltk/Makefile.tools?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc)
allows the configuration of additional tools necessary to build for the target as a minimum pkg-config is usually required to find libraries.
@@ -224,17 +224,17 @@ The `netsurf_table` structure is initialised and passed to
`netsurf_register()`. It should be noted that the approach taken here
and in most frontends is to have a source module for each operation
table. The header for each module exposes just the pointer to the
-indivial operation set, this allows for all the operation functions to
+individual operation set, this allows for all the operation functions to
be static to their module and hence helps reduce global symbol usage.
### Frontend specific initialisation
-Her it is implemented in `nsfltk_init()` this function performs all
+Here it is implemented in `nsfltk_init()` this function performs all
the operations specific to the frontend which must be initialised
before netsurf itself. In some toolkits this would require calling the
toolkit initialisation (e.g. `gtk_init()`).
-It is nessesary to initialise netsurf logging and user options at this
+It is necessary to initialise netsurf logging and user options at this
point. A more fully featured implementation would also initialise the
message translation system here.
@@ -256,7 +256,7 @@ example here is a good start.
### Toolkit run loop
-The function `nsfltk_run()` runs the toolkit event loop. In this case it is using the generic scheduleing in the [misc.cpp](https://git.netsurf-browser.org/netsurf.git/diff/frontends/fltk/misc.cpp?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc) module to ensure callbacks get made at the apropriate time.
+The function `nsfltk_run()` runs the toolkit event loop. In this case it is using the generic scheduling in the [misc.cpp](https://git.netsurf-browser.org/netsurf.git/diff/frontends/fltk/misc.cpp?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc) module to ensure callbacks get made at the appropriate time.
There is a `nsfltk_done` boolean global checked here so when all the
browser windows are closed the program will exit.
@@ -265,7 +265,7 @@ A more fully featured port might use the toolkits scheduling rather
than open coding a solution with a linked list as is done
here.
-A futher optimisation would be to obtain the set of file descriptors
+A further optimisation would be to obtain the set of file descriptors
being used (with `fetch_fdset()`) for active fetches allowing for
activity based fetch progress instead of the fallback polling method.
@@ -276,7 +276,7 @@ up any resource usage. After the call to `netsurf_exit()` no more
operation calls will be made and all caches used by the core will be
flushed.
-If user option chnages are to be made persistant `nsoption_finalise()`
+If user option changes are to be made persistent `nsoption_finalise()`
should be called.
The finalisation of logging will ensure that any output buffers are
@@ -288,12 +288,12 @@ Amongst all the boilerplate of the default implementation the only novel code is
### `nsfltk_window_create`
-The create operation instansiates a new `NS_Window` object and
+The create operation instantiates a new `NS_Window` object and
references it in the gui_window structure which it returns to the
caller. Technically we could simply return the `NS_Window` object as
the gui_window pointer but this implementation is avoiding the cast.
-Secondly `Fl_Double_Window` is subclassed as `NS_Widget`. The sublass
+Secondly `Fl_Double_Window` is subclassed as `NS_Widget`. The subclass
allows the close callback to be accessed so the global `nsfltk_done`
boolean can be set during the destructor method.
@@ -303,11 +303,11 @@ more extensive implementation would add other window furniture here
The implementation subclasses `Fl_Widget` implementing the draw
method to render the browsing context and the handle method to handle
-mouse events to allow teh user to click.
+mouse events to allow the user to click.
The `NS_Widget::handle()` method simply translates the mouse press
-event from widget coordinates to netsurf canvas cooridinates and maps
-teh mouse button state. The core is informed of these events using
+event from widget coordinates to netsurf canvas coordinates and maps
+the mouse button state. The core is informed of these events using
`browser_window_mouse_click()`
The `NS_Widget::draw` method similarly translates the fltk toolkits
@@ -317,7 +317,7 @@ the plotting context to render the browsing context within the area
specified. One thing to note here is the translation between the
coordinates of the render area and the internal page canvas given as
the second and third parameters to the draw call. When scrolling is
-required this is achived by altering these offsets.
+required this is achieved by altering these offsets.
### `nsfltk_window_invalidate()`
@@ -343,7 +343,7 @@ colour and performs the appropriate fltk draw function (`fl_line`,
# Worked Example next steps
The previous section outlined the absolute minimum
-implementation. Here we can exmaine some next steps taken to extend
+implementation. Here we can examine some next steps taken to extend
the frontend.
## Improving the user interface
@@ -397,17 +397,17 @@ perceived functionality.
The [core window interface](docs/core-window-interface.md) allows a
frontend to use inbuilt rendering for several interfaces gaining a
-great deal of functionality for very litte code. This one interface
+great deal of functionality for very little code. This one interface
set gives a cookie viewer,a local and global history viewer and a
hotlist(bookmarks) viewer.
# Conclusion
-Hopefully this breif overview and worked example should give the
-prospectinve frontend developer enough information to understand how
+Hopefully this brief overview and worked example should give the
+prospective frontend developer enough information to understand how
to get started implementing a new frontend toolkit for NetSurf.
-As can be seen there is actualy very little novel code necessary to
+As can be seen there is actually very little novel code necessary to
get started though I should mention that the move from "minimal" to
"full" implementation is a large undertaking and it would be wise to
talk with the NetSurf developers if undertaking such work.
--
2.44.0
docs/implementing-new-frontend.md | 78 +++++++++++++++----------------
1 file changed, 39 insertions(+), 39 deletions(-)
diff --git a/docs/implementing-new-frontend.md b/docs/implementing-new-frontend.md
index 4bda47af0..b0069531f 100644
--- a/docs/implementing-new-frontend.md
+++ b/docs/implementing-new-frontend.md
@@ -54,14 +54,14 @@ cookie, bookmark, history windows which require only minimal frontend
support with the [core window API](docs/core-window-interface.md).
A frontend developer is free to implement any and all of this generic
-functionality thelselves in a manner more integrated into a toolkit.
+functionality themselves in a manner more integrated into a toolkit.
# Implementation
A frontend is generally named for the toolkit it is implementing (i.e
gtk for the GTK+ toolkit). It is advisable to be as specific as
possible e.g. the frontend for the windows operating system should
-have been named win32 allowing for an impementation using a differnt
+have been named win32 allowing for an implementation using a different
toolkit (e.g mfc)
All the files needed for the frontend are contained in a single
@@ -80,7 +80,7 @@ included from the core Makefile):
- `Makefile.defaults` - allows setting frontend specific makefile variables and overriding of the default core build variables.
- `Makefile.tools` - allows setting up frontend specific build tooling (as a minimum a tool for the package configuration in PKG_CONFIG)
-Source code modules can be named as the devloper desires within the
+Source code modules can be named as the developer desires within the
frontend directory and should be added to the SOURCES variable as
desired.
@@ -93,17 +93,17 @@ The usual shape for the `main()` function is a six step process:
1. The frontends operation tables are registered with NetSurf
2. The toolkit specific initialisation is performed (which may involve calling NetSurf provided utility functions for support operations like logging, message translations etc.)
3. Initialise the NetSurf core. After this point all browser functionality is available and registered operations can be called.
- 4. Perform toolkiit setup, usually opening the initial browsing window (perhaps according to user preferences)
- 5. Run the toolkits main loop while ensuring the Netsurf scheduled operations are also run at teh apropriate time.
+ 4. Perform toolkit setup, usually opening the initial browsing window (perhaps according to user preferences)
+ 5. Run the toolkits main loop while ensuring the Netsurf scheduled operations are also run at the appropriate time.
6. Finalisation on completion.
## NetSurf operations tables
The frontend will generally call netsurf interfaces to get a desired
-behaviour e.g. `browser_window_create()` to create a new browsing
+behavior e.g. `browser_window_create()` to create a new browsing
context (the `browser_window_` prefix is historical and does not
necessarily create a window e.g. on gtk it is more likely to open a
-tab in an existing window). To achive the desired operation some
+tab in an existing window). To achieve the desired operation some
operations need to be performed by the frontend under control of
NetSurf, these operations are listed in tables.
@@ -113,22 +113,22 @@ tables (and the tables themselves) must remain valid until
`netsurf_exit()` is called.
There are (currently) twelve sets of operation tables held in separate
-structures. Only five of these are mandantory (misc, window, fetch,
+structures. Only five of these are mandatory (misc, window, fetch,
bitmap and layout).
-In this context mandantory means the tables must be non NULL and do
-not have a suitable default. Each of the mandantory sets contain
+In this context mandatory means the tables must be non NULL and do
+not have a suitable default. Each of the mandatory sets contain
function pointers to implement operations.
### misc operation table
-The only mandantory operation in this table is schedule.
+The only mandatory operation in this table is schedule.
When schedule is called the frontend must arrange for the passed
callback to be called with the context parameter after a number of
-miliseconds.
+milliseconds.
-This callback is typicaly driven through the toolkits event loop and
+This callback is typically driven through the toolkits event loop and
it is important such callbacks are not attempted from an operation.
### window operation table
@@ -143,9 +143,9 @@ generally assumed to contain at least a reference to the underlying
`browser_window` which is provided in the initial create operation to
allow subsequent use of various core functionality.
-The mandantory window operations are:
+The mandatory window operations are:
- create - create a new browsing context widget in the frontend toolkit
- - destroy - destoy a previously created `gui_window`
+ - destroy - destroy a previously created `gui_window`
- invalidate - mark an area of the browsing context viewport as requiring redraw (note no redraw should be attempted from here)
- get_scroll - get the scroll offsets from the toolkit drawing widget
- set_scroll - set the scroll offsets on the toolkit drawing widget
@@ -157,13 +157,13 @@ The mandantory window operations are:
The fetch operations allow the built in scheme fetchers (file, about, resource) to obtain additional information necessary to complete their operation.
-The two mandantory operations are:
+The two mandatory operations are:
- `filetype` - allows the file scheme to obtain a mime type from a file path e.g. `a.file.name.png` would result in `image/png`
- `get_resource_url` - maps resource scheme paths to URL e.g. `resource:default.css` to `file:///usr/share/netsurf/default.css`
### bitmap operation table
-The bitmap table and all of its operations are mandantory only because
+The bitmap table and all of its operations are mandatory only because
the empty defaults have not been included as it is assumed a browser
will want to display images.
@@ -173,7 +173,7 @@ until full implementations are made.
### layout operation table
The layout table is used to layout text. All operations are given
-strings to manipulate encoded in UTF-8. There are three mandantory
+strings to manipulate encoded in UTF-8. There are three mandatory
operations:
- `width` - Calculate the width of a string.
- `position` - Find the position in a string where an x coordinate falls.
@@ -184,7 +184,7 @@ operations:
Rather than attempt to describe every aspect of an implementation we
will rather work from an actual minimal example for the FLTK toolkit.
-This is availble as a single commit (`git show 28ecbf82ed3024f51be4c87928fd91bacfc15cbc`) in the NetSurf source repository. Alternatively it can be [viewed in a web browser](https://git.netsurf-browser.org/netsurf.git/commit/?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc).
+This is available as a single commit (`git show 28ecbf82ed3024f51be4c87928fd91bacfc15cbc`) in the NetSurf source repository. Alternatively it can be [viewed in a web browser](https://git.netsurf-browser.org/netsurf.git/commit/?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc).
This represents the absolute minimum implementation to get a browser
window on screen (and be able to click visible links). It is
@@ -201,13 +201,13 @@ As previously described the three GNU Make files are added:
[Makefile](https://git.netsurf-browser.org/netsurf.git/diff/frontends/fltk/Makefile?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc)
this shows how the flags are extended to add the fltk headers and
-library. Additionaly the list of sources are built here, as teh
+library. Additionally the list of sources are built here, as the
comment suggests it is important the SOURCES variable is not expanded
-here so the S_FRONTEND variable is used to allow expansion at teh
+here so the S_FRONTEND variable is used to allow expansion at the
correct time in the build process.
[Makefile.defaults](https://git.netsurf-browser.org/netsurf.git/diff/frontends/fltk/Makefile.defaults?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc)
-has the default setting to control the build parameters and file locations. These can be overriden by the `Makefile.config` at compile time.
+has the default setting to control the build parameters and file locations. These can be overridden by the `Makefile.config` at compile time.
[Makefile.tools](https://git.netsurf-browser.org/netsurf.git/diff/frontends/fltk/Makefile.tools?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc)
allows the configuration of additional tools necessary to build for the target as a minimum pkg-config is usually required to find libraries.
@@ -224,17 +224,17 @@ The `netsurf_table` structure is initialised and passed to
`netsurf_register()`. It should be noted that the approach taken here
and in most frontends is to have a source module for each operation
table. The header for each module exposes just the pointer to the
-indivial operation set, this allows for all the operation functions to
+individual operation set, this allows for all the operation functions to
be static to their module and hence helps reduce global symbol usage.
### Frontend specific initialisation
-Her it is implemented in `nsfltk_init()` this function performs all
+Here it is implemented in `nsfltk_init()` this function performs all
the operations specific to the frontend which must be initialised
before netsurf itself. In some toolkits this would require calling the
toolkit initialisation (e.g. `gtk_init()`).
-It is nessesary to initialise netsurf logging and user options at this
+It is necessary to initialise netsurf logging and user options at this
point. A more fully featured implementation would also initialise the
message translation system here.
@@ -256,7 +256,7 @@ example here is a good start.
### Toolkit run loop
-The function `nsfltk_run()` runs the toolkit event loop. In this case it is using the generic scheduleing in the [misc.cpp](https://git.netsurf-browser.org/netsurf.git/diff/frontends/fltk/misc.cpp?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc) module to ensure callbacks get made at the apropriate time.
+The function `nsfltk_run()` runs the toolkit event loop. In this case it is using the generic scheduling in the [misc.cpp](https://git.netsurf-browser.org/netsurf.git/diff/frontends/fltk/misc.cpp?h=vince/fltk&id=28ecbf82ed3024f51be4c87928fd91bacfc15cbc) module to ensure callbacks get made at the appropriate time.
There is a `nsfltk_done` boolean global checked here so when all the
browser windows are closed the program will exit.
@@ -265,7 +265,7 @@ A more fully featured port might use the toolkits scheduling rather
than open coding a solution with a linked list as is done
here.
-A futher optimisation would be to obtain the set of file descriptors
+A further optimisation would be to obtain the set of file descriptors
being used (with `fetch_fdset()`) for active fetches allowing for
activity based fetch progress instead of the fallback polling method.
@@ -276,7 +276,7 @@ up any resource usage. After the call to `netsurf_exit()` no more
operation calls will be made and all caches used by the core will be
flushed.
-If user option chnages are to be made persistant `nsoption_finalise()`
+If user option changes are to be made persistent `nsoption_finalise()`
should be called.
The finalisation of logging will ensure that any output buffers are
@@ -288,12 +288,12 @@ Amongst all the boilerplate of the default implementation the only novel code is
### `nsfltk_window_create`
-The create operation instansiates a new `NS_Window` object and
+The create operation instantiates a new `NS_Window` object and
references it in the gui_window structure which it returns to the
caller. Technically we could simply return the `NS_Window` object as
the gui_window pointer but this implementation is avoiding the cast.
-Secondly `Fl_Double_Window` is subclassed as `NS_Widget`. The sublass
+Secondly `Fl_Double_Window` is subclassed as `NS_Widget`. The subclass
allows the close callback to be accessed so the global `nsfltk_done`
boolean can be set during the destructor method.
@@ -303,11 +303,11 @@ more extensive implementation would add other window furniture here
The implementation subclasses `Fl_Widget` implementing the draw
method to render the browsing context and the handle method to handle
-mouse events to allow teh user to click.
+mouse events to allow the user to click.
The `NS_Widget::handle()` method simply translates the mouse press
-event from widget coordinates to netsurf canvas cooridinates and maps
-teh mouse button state. The core is informed of these events using
+event from widget coordinates to netsurf canvas coordinates and maps
+the mouse button state. The core is informed of these events using
`browser_window_mouse_click()`
The `NS_Widget::draw` method similarly translates the fltk toolkits
@@ -317,7 +317,7 @@ the plotting context to render the browsing context within the area
specified. One thing to note here is the translation between the
coordinates of the render area and the internal page canvas given as
the second and third parameters to the draw call. When scrolling is
-required this is achived by altering these offsets.
+required this is achieved by altering these offsets.
### `nsfltk_window_invalidate()`
@@ -343,7 +343,7 @@ colour and performs the appropriate fltk draw function (`fl_line`,
# Worked Example next steps
The previous section outlined the absolute minimum
-implementation. Here we can exmaine some next steps taken to extend
+implementation. Here we can examine some next steps taken to extend
the frontend.
## Improving the user interface
@@ -397,17 +397,17 @@ perceived functionality.
The [core window interface](docs/core-window-interface.md) allows a
frontend to use inbuilt rendering for several interfaces gaining a
-great deal of functionality for very litte code. This one interface
+great deal of functionality for very little code. This one interface
set gives a cookie viewer,a local and global history viewer and a
hotlist(bookmarks) viewer.
# Conclusion
-Hopefully this breif overview and worked example should give the
-prospectinve frontend developer enough information to understand how
+Hopefully this brief overview and worked example should give the
+prospective frontend developer enough information to understand how
to get started implementing a new frontend toolkit for NetSurf.
-As can be seen there is actualy very little novel code necessary to
+As can be seen there is actually very little novel code necessary to
get started though I should mention that the move from "minimal" to
"full" implementation is a large undertaking and it would be wise to
talk with the NetSurf developers if undertaking such work.
--
2.44.0
Sunday, 7 April 2024
[netsurf-users] Re: Parsing Error
On 7 Apr 2024 as I do recall,
Bob Latham wrote:
[snip]
> I have found that if I remove a whole chunk of code from the <head>
> section and another chunk from the start of the <body> the page then
> displays and seems to show all the information and pictures..
>
> See attached file (anonymized)
I can confirm that it certainly fails here.
--
Harriet Bazley == Loyaulte me lie ==
Own nothing you do not know to be useful or believe to be beautiful.
Bob Latham wrote:
[snip]
> I have found that if I remove a whole chunk of code from the <head>
> section and another chunk from the start of the <body> the page then
> displays and seems to show all the information and pictures..
>
> See attached file (anonymized)
I can confirm that it certainly fails here.
--
Harriet Bazley == Loyaulte me lie ==
Own nothing you do not know to be useful or believe to be beautiful.
[netsurf-users] Re: 6696 fails to start on RISC OS
I have just sent this email to Andrew Rawnsley drawing his attention to
the problem
-------------------------------------------------------------------------
Hi Andrew,
The hardwired SockWatch in !Uniprint is causing errors and will prevent it
using updated SockWatch modules when they are issued. !NetSurf is being
shipped with a newer version of SockWatch
People are having to go into the applications and modify the run file
themselves, which is not good. Please will you change this. See the two
Mailing list entries I have quoted below.
Dave's entry may be referring to RO6 but I find three entries for
SockWatch myself in RO5
In my case, in RO5.28, I have copies in:
$.!Boot.Resources.!Internet
$.!Boot.Resources.!System.310.Modules.Network
and
$.!Boot.Choices.Boot.PreDesk.!Uniprint
I don't have Hermes and I don't use !Netsurf much because I have Iris, so
I've not updated it recently.
Stuart
From the NetSurf mailing list:
-----------------------------------------------------------------------
In article
<tkwjo6jwfaypr3o2gyuyvilcltskbmuysm4hol6i67igqry4j3@ycgl6bhhi3f6>,
Rob Kendrick <rjek@rjek.com> wrote:
> On Thu, Apr 04, 2024 at 04:52:58PM +0100, Bob Latham wrote:
> > Yes, but an earlier socket is loaded by both UniPrint and Hermes from
> > within the applications, there may be more.
> This is a bug in UniPrint and Hermes: the reason we have the System
> Merge tool is to prevent this exact situation: apps shouldn't be
> shipping their own modules internally because there will inevitably be a
> clash, as you have just experienced.
> I'm sure they've done this in the name of ease of installation, but it
> just messes stuff up for everyone else :(
> B.
---------------------------------------------------------------------------
In article <5b4cba41f5dave@triffid.co.uk>,
Dave <dave@triffid.co.uk> wrote:
[Snippy]
> If it's of any use to anyone else, on the RISC OS 6.20 install here,
> there are three occurrences of "SockWatch".
> ..$.!Boot.Choices.Users.Single.Boot.PreDesk.!UniPrint.SockWatch
> ..$.!Boot.Resources.!System.310.Modules.Network.SockWatch [The updated
> one] ..$.Net.NetFetches.!NetFetch.Apps.!Hermes.Resources.SockWatch
> The UniPrint one is hard wired in the Run file to Run it's internal
> SockWatch, as is Hermes.
> Dave
Sorry was busy with other things and forgot to mention...
I fixed it here by changing the Uniserver and Hermes !Run file "RMEnsure
SocketWatch" entries to point to System:Modules.Network.SockWatch instead
of their own internal SockWatch modules.
Dave
--------------------------------------------------------------------------
--
Stuart Winsor
Tools With A Mission
sending tools across the world
http://www.twam.co.uk/
--
Stuart Winsor
Tools With A Mission
sending tools across the world
http://www.twam.co.uk/
the problem
-------------------------------------------------------------------------
Hi Andrew,
The hardwired SockWatch in !Uniprint is causing errors and will prevent it
using updated SockWatch modules when they are issued. !NetSurf is being
shipped with a newer version of SockWatch
People are having to go into the applications and modify the run file
themselves, which is not good. Please will you change this. See the two
Mailing list entries I have quoted below.
Dave's entry may be referring to RO6 but I find three entries for
SockWatch myself in RO5
In my case, in RO5.28, I have copies in:
$.!Boot.Resources.!Internet
$.!Boot.Resources.!System.310.Modules.Network
and
$.!Boot.Choices.Boot.PreDesk.!Uniprint
I don't have Hermes and I don't use !Netsurf much because I have Iris, so
I've not updated it recently.
Stuart
From the NetSurf mailing list:
-----------------------------------------------------------------------
In article
<tkwjo6jwfaypr3o2gyuyvilcltskbmuysm4hol6i67igqry4j3@ycgl6bhhi3f6>,
Rob Kendrick <rjek@rjek.com> wrote:
> On Thu, Apr 04, 2024 at 04:52:58PM +0100, Bob Latham wrote:
> > Yes, but an earlier socket is loaded by both UniPrint and Hermes from
> > within the applications, there may be more.
> This is a bug in UniPrint and Hermes: the reason we have the System
> Merge tool is to prevent this exact situation: apps shouldn't be
> shipping their own modules internally because there will inevitably be a
> clash, as you have just experienced.
> I'm sure they've done this in the name of ease of installation, but it
> just messes stuff up for everyone else :(
> B.
---------------------------------------------------------------------------
In article <5b4cba41f5dave@triffid.co.uk>,
Dave <dave@triffid.co.uk> wrote:
[Snippy]
> If it's of any use to anyone else, on the RISC OS 6.20 install here,
> there are three occurrences of "SockWatch".
> ..$.!Boot.Choices.Users.Single.Boot.PreDesk.!UniPrint.SockWatch
> ..$.!Boot.Resources.!System.310.Modules.Network.SockWatch [The updated
> one] ..$.Net.NetFetches.!NetFetch.Apps.!Hermes.Resources.SockWatch
> The UniPrint one is hard wired in the Run file to Run it's internal
> SockWatch, as is Hermes.
> Dave
Sorry was busy with other things and forgot to mention...
I fixed it here by changing the Uniserver and Hermes !Run file "RMEnsure
SocketWatch" entries to point to System:Modules.Network.SockWatch instead
of their own internal SockWatch modules.
Dave
--------------------------------------------------------------------------
--
Stuart Winsor
Tools With A Mission
sending tools across the world
http://www.twam.co.uk/
--
Stuart Winsor
Tools With A Mission
sending tools across the world
http://www.twam.co.uk/
[netsurf-users] Parsing Error
I'll try again with the correct list address :-)
When I order items from the internet the Post Office often send me an
email informing me of when they intend to deliver the package.
This arrives as an HTML attachment which I drop into Netsurf.
Until recently this worked fine but no longer. They now fail every
time with :
Error occurred fetching page
Parsing the document failed.
Other browsers don't seem to have a problem with this file.
I have found that if I remove a whole chunk of code from the <head>
section and another chunk from the start of the <body> the page then
displays and seems to show all the information and pictures..
See attached file (anonymized)
Cheers
Bob.
When I order items from the internet the Post Office often send me an
email informing me of when they intend to deliver the package.
This arrives as an HTML attachment which I drop into Netsurf.
Until recently this worked fine but no longer. They now fail every
time with :
Error occurred fetching page
Parsing the document failed.
Other browsers don't seem to have a problem with this file.
I have found that if I remove a whole chunk of code from the <head>
section and another chunk from the start of the <body> the page then
displays and seems to show all the information and pictures..
See attached file (anonymized)
Cheers
Bob.
Saturday, 6 April 2024
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <0650874d5b.John@rickman.argonet.co.uk>,
John Rickman <rickman@argonet.co.uk> wrote:
> In message <g4wacql5n6npzdrjcgdjuslz7kvokfjqyh3gwky6cwywkgbvr7@5le2zo43v3z7>
> Rob Kendrick <rjek@rjek.com> wrote:
> > My /guess/ is that SocketWatch (or similar) is running via an
> > application launched at boot and it is an earlier version than
> > NetSurf requires, so NetSurf's !Run's RMEnsure tries to replace
> > it with a newer version?
> At last nights RISC OS coding zoom meeting there was discussion of
> this SocketWatch issue and I was asked to write to this list
> seeking some information. We looked at the change log for v0.07
> and tested the latest NetSurf against v0.04. It appeared to run
> without problems.
> Would you be willing in the short term to RMensure against v0.04
> instead of v0.07. This would avoid some breakage and people
> having to change their run files.
> This is significant only because older/current versions of
> SocketWatch cannot be replaced "live" as they are in use. Thus
> simply RMensuring a newer version will fail.
That is NOT the way to go!
The correct way is that the latest version should be used everywhere,
and the old ones removed (as long as the later fixed version has no
incompatible API changes).
Please see the long list of changes made since v0.04y (02-12-2002)
that are included in v0.07 (11-01-2019) some 16 years later.
Other applications may rely on some of those fixes and changes!
The latest v0.07 AFAIK is available at https://www.aconet.nl/tools/
Martin
John Rickman <rickman@argonet.co.uk> wrote:
> In message <g4wacql5n6npzdrjcgdjuslz7kvokfjqyh3gwky6cwywkgbvr7@5le2zo43v3z7>
> Rob Kendrick <rjek@rjek.com> wrote:
> > My /guess/ is that SocketWatch (or similar) is running via an
> > application launched at boot and it is an earlier version than
> > NetSurf requires, so NetSurf's !Run's RMEnsure tries to replace
> > it with a newer version?
> At last nights RISC OS coding zoom meeting there was discussion of
> this SocketWatch issue and I was asked to write to this list
> seeking some information. We looked at the change log for v0.07
> and tested the latest NetSurf against v0.04. It appeared to run
> without problems.
> Would you be willing in the short term to RMensure against v0.04
> instead of v0.07. This would avoid some breakage and people
> having to change their run files.
> This is significant only because older/current versions of
> SocketWatch cannot be replaced "live" as they are in use. Thus
> simply RMensuring a newer version will fail.
That is NOT the way to go!
The correct way is that the latest version should be used everywhere,
and the old ones removed (as long as the later fixed version has no
incompatible API changes).
Please see the long list of changes made since v0.04y (02-12-2002)
that are included in v0.07 (11-01-2019) some 16 years later.
Other applications may rely on some of those fixes and changes!
The latest v0.07 AFAIK is available at https://www.aconet.nl/tools/
Martin
[netsurf-users] Re: 6696 fails to start on RISC OS
On Sat, Apr 06, 2024 at 10:22:54PM +0100, John Rickman wrote:
> At last nights RISC OS coding zoom meeting there was discussion of this
> SocketWatch issue and I was asked to write to this list seeking some
> information. We looked at the change log for v0.07 and tested the latest
> NetSurf against v0.04. It appeared to run without problems.
>
> Would you be willing in the short term to RMensure against v0.04 instead
> of v0.07. This would avoid some breakage and people having to change
> their run files.
I don't think NetSurf adding this hack to fix somebody else's bug is a
sustainable or appropriate fix. The bug is absolutely with the software
that is embeddeding a shared resource. If they used the !System merge
facility the OS has had for decades the problem would not occur.
> This is significant only because older/current versions of SocketWatch
> cannot be replaced "live" as they are in use. Thus simply RMensuring a
> newer version will fail.
This is the same with many modules, not just SocketWatch.
B.
> At last nights RISC OS coding zoom meeting there was discussion of this
> SocketWatch issue and I was asked to write to this list seeking some
> information. We looked at the change log for v0.07 and tested the latest
> NetSurf against v0.04. It appeared to run without problems.
>
> Would you be willing in the short term to RMensure against v0.04 instead
> of v0.07. This would avoid some breakage and people having to change
> their run files.
I don't think NetSurf adding this hack to fix somebody else's bug is a
sustainable or appropriate fix. The bug is absolutely with the software
that is embeddeding a shared resource. If they used the !System merge
facility the OS has had for decades the problem would not occur.
> This is significant only because older/current versions of SocketWatch
> cannot be replaced "live" as they are in use. Thus simply RMensuring a
> newer version will fail.
This is the same with many modules, not just SocketWatch.
B.
[netsurf-users] Re: 6696 fails to start on RISC OS
In message <g4wacql5n6npzdrjcgdjuslz7kvokfjqyh3gwky6cwywkgbvr7@5le2zo43v3z
7>
Rob Kendrick <rjek@rjek.com> wrote:
> My /guess/ is that SocketWatch (or similar) is running via an
> application launched at boot and it is an earlier version than NetSurf
> requires, so NetSurf's !Run's RMEnsure tries to replace it with a newer
> version?
At last nights RISC OS coding zoom meeting there was discussion of this
SocketWatch issue and I was asked to write to this list seeking some
information. We looked at the change log for v0.07 and tested the latest
NetSurf against v0.04. It appeared to run without problems.
Would you be willing in the short term to RMensure against v0.04 instead
of v0.07. This would avoid some breakage and people having to change
their run files.
This is significant only because older/current versions of SocketWatch
cannot be replaced "live" as they are in use. Thus simply RMensuring a
newer version will fail.
John
--
John Rickman
7>
Rob Kendrick <rjek@rjek.com> wrote:
> My /guess/ is that SocketWatch (or similar) is running via an
> application launched at boot and it is an earlier version than NetSurf
> requires, so NetSurf's !Run's RMEnsure tries to replace it with a newer
> version?
At last nights RISC OS coding zoom meeting there was discussion of this
SocketWatch issue and I was asked to write to this list seeking some
information. We looked at the change log for v0.07 and tested the latest
NetSurf against v0.04. It appeared to run without problems.
Would you be willing in the short term to RMensure against v0.04 instead
of v0.07. This would avoid some breakage and people having to change
their run files.
This is significant only because older/current versions of SocketWatch
cannot be replaced "live" as they are in use. Thus simply RMensuring a
newer version will fail.
John
--
John Rickman
Friday, 5 April 2024
[netsurf-users] Re: Mailing list host change
On 05 Apr, Martin Avison <netsurf@avisoft.f9.co.uk> wrote:
> In article
> <ye72hwetmto22fvadr7bo5i5up6hoz6qpdxjxfgpa3curadyjk@ubusv72yx4x5>,
> Daniel Silverstone <dsilvers@digital-scurf.org> wrote:
> > Hi Everyone,
> > Assuming this email reaches you, then our migration to a new
> > mailing list host has worked.
> > We are now hosted on freelists.org. Hopefully things went smoothly
> > and nobody has to change anything, however if you filtered on
> > list-id before, then you may have to adjust that filtering; and if
> > you used digest mode then you will need to log into the
> > freelists.org interface and fix that up.
> > Please let me know **directly** if you're having any problems -
> > let's not flood the list with problems please.
> > I hope that we'll have the archives migrated soon too, but for now
> > they're missing.
> It has just come to my attention that this change has caused some
> Pluto users (includiong myself) to have some posts to the users
> mailing list filtered wrongly.
> This I think is caused by some posts being sent to the old address
> netsurf-users@netsurf-browser.org
> and some to the the new address
> netsurf-users@freelists.org
> I think this would be resolved if subscribers change the Mailing List
> from using the old address to the new one (which I have just done
> myself!) and then normal service will I think resume.
> Martin
Ooer! I don't remember seeing a note about the change, so I've still been
posting via the old list.
Now changed.
Dave
--
Dave Triffid
> In article
> <ye72hwetmto22fvadr7bo5i5up6hoz6qpdxjxfgpa3curadyjk@ubusv72yx4x5>,
> Daniel Silverstone <dsilvers@digital-scurf.org> wrote:
> > Hi Everyone,
> > Assuming this email reaches you, then our migration to a new
> > mailing list host has worked.
> > We are now hosted on freelists.org. Hopefully things went smoothly
> > and nobody has to change anything, however if you filtered on
> > list-id before, then you may have to adjust that filtering; and if
> > you used digest mode then you will need to log into the
> > freelists.org interface and fix that up.
> > Please let me know **directly** if you're having any problems -
> > let's not flood the list with problems please.
> > I hope that we'll have the archives migrated soon too, but for now
> > they're missing.
> It has just come to my attention that this change has caused some
> Pluto users (includiong myself) to have some posts to the users
> mailing list filtered wrongly.
> This I think is caused by some posts being sent to the old address
> netsurf-users@netsurf-browser.org
> and some to the the new address
> netsurf-users@freelists.org
> I think this would be resolved if subscribers change the Mailing List
> from using the old address to the new one (which I have just done
> myself!) and then normal service will I think resume.
> Martin
Ooer! I don't remember seeing a note about the change, so I've still been
posting via the old list.
Now changed.
Dave
--
Dave Triffid
[netsurf-users] Re: Mailing list host change
In article
<ye72hwetmto22fvadr7bo5i5up6hoz6qpdxjxfgpa3curadyjk@ubusv72yx4x5>,
Daniel Silverstone <dsilvers@digital-scurf.org> wrote:
> Hi Everyone,
> Assuming this email reaches you, then our migration to a new
> mailing list host has worked.
> We are now hosted on freelists.org. Hopefully things went smoothly
> and nobody has to change anything, however if you filtered on
> list-id before, then you may have to adjust that filtering; and if
> you used digest mode then you will need to log into the
> freelists.org interface and fix that up.
> Please let me know **directly** if you're having any problems -
> let's not flood the list with problems please.
> I hope that we'll have the archives migrated soon too, but for now
> they're missing.
It has just come to my attention that this change has caused some
Pluto users (includiong myself) to have some posts to the users
mailing list filtered wrongly.
This I think is caused by some posts being sent to the old address
netsurf-users@netsurf-browser.org
and some to the the new address
netsurf-users@freelists.org
I think this would be resolved if subscribers change the Mailing List
from using the old address to the new one (which I have just done
myself!) and then normal service will I think resume.
Martin
<ye72hwetmto22fvadr7bo5i5up6hoz6qpdxjxfgpa3curadyjk@ubusv72yx4x5>,
Daniel Silverstone <dsilvers@digital-scurf.org> wrote:
> Hi Everyone,
> Assuming this email reaches you, then our migration to a new
> mailing list host has worked.
> We are now hosted on freelists.org. Hopefully things went smoothly
> and nobody has to change anything, however if you filtered on
> list-id before, then you may have to adjust that filtering; and if
> you used digest mode then you will need to log into the
> freelists.org interface and fix that up.
> Please let me know **directly** if you're having any problems -
> let's not flood the list with problems please.
> I hope that we'll have the archives migrated soon too, but for now
> they're missing.
It has just come to my attention that this change has caused some
Pluto users (includiong myself) to have some posts to the users
mailing list filtered wrongly.
This I think is caused by some posts being sent to the old address
netsurf-users@netsurf-browser.org
and some to the the new address
netsurf-users@freelists.org
I think this would be resolved if subscribers change the Mailing List
from using the old address to the new one (which I have just done
myself!) and then normal service will I think resume.
Martin
[netsurf-users] Re: 6696 fails to start on RISC OS
On 05 Apr, David Higton <dave@davehigton.me.uk> wrote:
> > If you do the recommended SysMerge with the !System supplied in the
> > Netsurf development download, the latest SockWatch module will be
> > placed in: Boot:Resources.!System.310.Modules.Network
I always to the merge but the last version I downloaded was #6657, which
didn't have SockWatch.
--
John Harrison
Website http://jaharrison.me.uk
Using 4té and ARMX6, both running RISC OS
> > If you do the recommended SysMerge with the !System supplied in the
> > Netsurf development download, the latest SockWatch module will be
> > placed in: Boot:Resources.!System.310.Modules.Network
I always to the merge but the last version I downloaded was #6657, which
didn't have SockWatch.
--
John Harrison
Website http://jaharrison.me.uk
Using 4té and ARMX6, both running RISC OS
[netsurf-users] Re: 6696 fails to start on RISC OS
In message <57b8cf4c5b.boase@bernard>
bernard@boase.myzen.co.uk wrote:
> On 5 Apr 2024, john@jaharrison.me.uk wrote:
>
> > I have nothing at: System:Modules.Network.SockWatch. The only copy is
> > the one inside Hermes. There isn't even a: System:Modules.Network
> > directory. Should I be worried?
>
> If you do the recommended SysMerge with the !System supplied in the
> Netsurf development download, the latest SockWatch module will be placed
> in:
>
> Boot:Resources.!System.310.Modules.Network
>
> which is where it belongs (and not elsewhere AFAIUI).
Ah yes, thank you. I sit corrected.
David
bernard@boase.myzen.co.uk wrote:
> On 5 Apr 2024, john@jaharrison.me.uk wrote:
>
> > I have nothing at: System:Modules.Network.SockWatch. The only copy is
> > the one inside Hermes. There isn't even a: System:Modules.Network
> > directory. Should I be worried?
>
> If you do the recommended SysMerge with the !System supplied in the
> Netsurf development download, the latest SockWatch module will be placed
> in:
>
> Boot:Resources.!System.310.Modules.Network
>
> which is where it belongs (and not elsewhere AFAIUI).
Ah yes, thank you. I sit corrected.
David
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b4cc7c00cbob@mightyoak.org.uk>,
Bob Latham <bob@mightyoak.org.uk> wrote:
> In article <5b4cbd5005dave@triffid.co.uk>,
> Dave <dave@triffid.co.uk> wrote:
> > I fixed it here by changing the Uniserver and Hermes !Run file
> > "RMEnsure SocketWatch" entries to point to
> > System:Modules.Network.SockWatch instead of their own internal
> > SockWatch modules.
> Yes, that is a sensible way to do it but then it will likely get
> broken again next time Hermes gets an update.
I did consider replacing each within the app with the new one, replacing
the old ones, but I thought it would be better to stick with the central
resources way.
> And don't forget !Grapevine, that's another.
> Bob.
I don't have Grapevine, but thanks for the prompt.
Dave
--
Dave Triffid
Bob Latham <bob@mightyoak.org.uk> wrote:
> In article <5b4cbd5005dave@triffid.co.uk>,
> Dave <dave@triffid.co.uk> wrote:
> > I fixed it here by changing the Uniserver and Hermes !Run file
> > "RMEnsure SocketWatch" entries to point to
> > System:Modules.Network.SockWatch instead of their own internal
> > SockWatch modules.
> Yes, that is a sensible way to do it but then it will likely get
> broken again next time Hermes gets an update.
I did consider replacing each within the app with the new one, replacing
the old ones, but I thought it would be better to stick with the central
resources way.
> And don't forget !Grapevine, that's another.
> Bob.
I don't have Grapevine, but thanks for the prompt.
Dave
--
Dave Triffid
[netsurf-users] Re: 6696 fails to start on RISC OS
In message <5b4cca8189john@jaharrison.me.uk>
John Harrison <john@jaharrison.me.uk> wrote:
> I have nothing at: System:Modules.Network.SockWatch. The only copy is
> the one inside Hermes. There isn't even a: System:Modules.Network
> directory. Should I be worried?
>
> RO 5.29 (15 February 21)
> IPv6 (25 December 23)
I don't think you should be worried. SockWatch is not an inherent part
of RISC OS, so there's no reason to assume that it must be there.
But if it is anywhere, System:Modules.Network.SockWatch is, I'm sure,
where it should be.
David
John Harrison <john@jaharrison.me.uk> wrote:
> I have nothing at: System:Modules.Network.SockWatch. The only copy is
> the one inside Hermes. There isn't even a: System:Modules.Network
> directory. Should I be worried?
>
> RO 5.29 (15 February 21)
> IPv6 (25 December 23)
I don't think you should be worried. SockWatch is not an inherent part
of RISC OS, so there's no reason to assume that it must be there.
But if it is anywhere, System:Modules.Network.SockWatch is, I'm sure,
where it should be.
David
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b4cba41f5dave@triffid.co.uk>,
Dave <dave@triffid.co.uk> wrote:
> If it's of any use to anyone else, on the RISC OS 6.20 install here,
> there are three occurrences of "SockWatch".
> ..$.!Boot.Choices.Users.Single.Boot.PreDesk.!UniPrint.SockWatch
> ..$.!Boot.Resources.!System.310.Modules.Network.SockWatch [The updated
> one] ..$.Net.NetFetches.!NetFetch.Apps.!Hermes.Resources.SockWatch
> The UniPrint one is hard wired in the Run file to Run it's internal
> SockWatch, as is Hermes.
In my case, in RO5.28, I have copies in:
$.!Boot.Resources.!Internet
$.!Boot.Resources.!System.310.Modules.Network
and
$.!Boot.Choices.Boot.PreDesk.!Uniprint
I don't have Hermes and I don't use !Netsurf much because I have Iris, so
I've not updated it recently.
Perhaps this is something I need to look into.
--
Stuart Winsor
Tools With A Mission
sending tools across the world
http://www.twam.co.uk/
Dave <dave@triffid.co.uk> wrote:
> If it's of any use to anyone else, on the RISC OS 6.20 install here,
> there are three occurrences of "SockWatch".
> ..$.!Boot.Choices.Users.Single.Boot.PreDesk.!UniPrint.SockWatch
> ..$.!Boot.Resources.!System.310.Modules.Network.SockWatch [The updated
> one] ..$.Net.NetFetches.!NetFetch.Apps.!Hermes.Resources.SockWatch
> The UniPrint one is hard wired in the Run file to Run it's internal
> SockWatch, as is Hermes.
In my case, in RO5.28, I have copies in:
$.!Boot.Resources.!Internet
$.!Boot.Resources.!System.310.Modules.Network
and
$.!Boot.Choices.Boot.PreDesk.!Uniprint
I don't have Hermes and I don't use !Netsurf much because I have Iris, so
I've not updated it recently.
Perhaps this is something I need to look into.
--
Stuart Winsor
Tools With A Mission
sending tools across the world
http://www.twam.co.uk/
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b4cbd5005dave@triffid.co.uk>,
Dave <dave@triffid.co.uk> wrote:
> I fixed it here by changing the Uniserver and Hermes !Run file
> "RMEnsure SocketWatch" entries to point to
> System:Modules.Network.SockWatch instead of their own internal
> SockWatch modules.
I have nothing at: System:Modules.Network.SockWatch. The only copy is
the one inside Hermes. There isn't even a: System:Modules.Network
directory. Should I be worried?
RO 5.29 (15 February 21)
IPv6 (25 December 23)
--
John Harrison
Website http://jaharrison.me.uk
Using 4té and ARMX6, both running RISC OS
Dave <dave@triffid.co.uk> wrote:
> I fixed it here by changing the Uniserver and Hermes !Run file
> "RMEnsure SocketWatch" entries to point to
> System:Modules.Network.SockWatch instead of their own internal
> SockWatch modules.
I have nothing at: System:Modules.Network.SockWatch. The only copy is
the one inside Hermes. There isn't even a: System:Modules.Network
directory. Should I be worried?
RO 5.29 (15 February 21)
IPv6 (25 December 23)
--
John Harrison
Website http://jaharrison.me.uk
Using 4té and ARMX6, both running RISC OS
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b4cbd5005dave@triffid.co.uk>,
Dave <dave@triffid.co.uk> wrote:
> I fixed it here by changing the Uniserver and Hermes !Run file
> "RMEnsure SocketWatch" entries to point to
> System:Modules.Network.SockWatch instead of their own internal
> SockWatch modules.
Yes, that is a sensible way to do it but then it will likely get
broken again next time Hermes gets an update.
And don't forget !Grapevine, that's another.
Bob.
Dave <dave@triffid.co.uk> wrote:
> I fixed it here by changing the Uniserver and Hermes !Run file
> "RMEnsure SocketWatch" entries to point to
> System:Modules.Network.SockWatch instead of their own internal
> SockWatch modules.
Yes, that is a sensible way to do it but then it will likely get
broken again next time Hermes gets an update.
And don't forget !Grapevine, that's another.
Bob.
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b4cba41f5dave@triffid.co.uk>,
Dave <dave@triffid.co.uk> wrote:
<OT>
> > !Locate will happily look for ...
> Ah Yes, I'd forgotten about that app, ...
It's extremely useful, and flexible. I use it a lot.
Thanks to Steve for producing it.
</OT>
--
John Harrison
Website http://jaharrison.me.uk
Using 4té and ARMX6, both running RISC OS
Dave <dave@triffid.co.uk> wrote:
<OT>
> > !Locate will happily look for ...
> Ah Yes, I'd forgotten about that app, ...
It's extremely useful, and flexible. I use it a lot.
Thanks to Steve for producing it.
</OT>
--
John Harrison
Website http://jaharrison.me.uk
Using 4té and ARMX6, both running RISC OS
[netsurf-users] Netsurf Parsin error
Hi,
When I order items from the internet the Post Office often send me an
email informing me of when they intend to deliver the package.
This arrives as an HTML attachment which I drop into Netsurf.
Until recently this worked fine but no longer. They now fail every
time with :
Error occurred fetching page
Parsing the document failed.
Other browsers don't seem to have a problem with this file.
I have found that if I remove a whole chunk of code from the <head>
section and another chunk from the start of the <body> the page then
displays and seems to show all the information and pictures..
I imagine you need to see this file but I'm concerned about private
information and also how to get this file to you.
I could supply just the removed code which i doubt has much private
information in it, would that be good enough?
How should I get this to you??
Cheers
Bob.
When I order items from the internet the Post Office often send me an
email informing me of when they intend to deliver the package.
This arrives as an HTML attachment which I drop into Netsurf.
Until recently this worked fine but no longer. They now fail every
time with :
Error occurred fetching page
Parsing the document failed.
Other browsers don't seem to have a problem with this file.
I have found that if I remove a whole chunk of code from the <head>
section and another chunk from the start of the <body> the page then
displays and seems to show all the information and pictures..
I imagine you need to see this file but I'm concerned about private
information and also how to get this file to you.
I could supply just the removed code which i doubt has much private
information in it, would that be good enough?
How should I get this to you??
Cheers
Bob.
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b4cba41f5dave@triffid.co.uk>,
Dave <dave@triffid.co.uk> wrote:
[Snippy]
> If it's of any use to anyone else, on the RISC OS 6.20 install here,
> there are three occurrences of "SockWatch".
> ..$.!Boot.Choices.Users.Single.Boot.PreDesk.!UniPrint.SockWatch
> ..$.!Boot.Resources.!System.310.Modules.Network.SockWatch [The updated
> one] ..$.Net.NetFetches.!NetFetch.Apps.!Hermes.Resources.SockWatch
> The UniPrint one is hard wired in the Run file to Run it's internal
> SockWatch, as is Hermes.
> Dave
Sorry was busy with other things and forgot to mention...
I fixed it here by changing the Uniserver and Hermes !Run file "RMEnsure
SocketWatch" entries to point to System:Modules.Network.SockWatch instead
of their own internal SockWatch modules.
Dave
--
Dave Triffid
Dave <dave@triffid.co.uk> wrote:
[Snippy]
> If it's of any use to anyone else, on the RISC OS 6.20 install here,
> there are three occurrences of "SockWatch".
> ..$.!Boot.Choices.Users.Single.Boot.PreDesk.!UniPrint.SockWatch
> ..$.!Boot.Resources.!System.310.Modules.Network.SockWatch [The updated
> one] ..$.Net.NetFetches.!NetFetch.Apps.!Hermes.Resources.SockWatch
> The UniPrint one is hard wired in the Run file to Run it's internal
> SockWatch, as is Hermes.
> Dave
Sorry was busy with other things and forgot to mention...
I fixed it here by changing the Uniserver and Hermes !Run file "RMEnsure
SocketWatch" entries to point to System:Modules.Network.SockWatch instead
of their own internal SockWatch modules.
Dave
--
Dave Triffid
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b4c7d5616netsurf@avisoft.f9.co.uk>,
Martin Avison <netsurf@avisoft.f9.co.uk> wrote:
> In article <5b4c7ad502dave@triffid.co.uk>,
> Dave <dave@triffid.co.uk> wrote:
> > Begs a question, how does one go about finding any other apps that
> > are loading/using that old module?
> !Locate will happily look for instances of a file in a directory ...
> which could be the whole disc if you want.
> Most useful for finding things in obscure places!
Ah Yes, I'd forgotten about that app, I must dig it out and see what I can
see... Or not see ;-)
Thanks for the prompt Martin.
Regards
Dave
Sometime after... A case of Not see!
What a (Paragraph of Bob the builder choice expletives), can't you wonder
I turn into a GOM.
Verma shows... SocketWatch, so that's what I've been searching in vain for.
It appears in ...!Boot.Resources.!System.310.Modules.Network as
"SockWatch" but internally is notated as "Socketwatch".
Gordon Bennett...
If it's of any use to anyone else, on the RISC OS 6.20 install here, there
are three occurrences of "SockWatch".
..$.!Boot.Choices.Users.Single.Boot.PreDesk.!UniPrint.SockWatch
..$.!Boot.Resources.!System.310.Modules.Network.SockWatch [The updated one]
..$.Net.NetFetches.!NetFetch.Apps.!Hermes.Resources.SockWatch
The UniPrint one is hard wired in the Run file to Run it's internal
SockWatch, as is Hermes.
Dave
--
Dave Triffid
Martin Avison <netsurf@avisoft.f9.co.uk> wrote:
> In article <5b4c7ad502dave@triffid.co.uk>,
> Dave <dave@triffid.co.uk> wrote:
> > Begs a question, how does one go about finding any other apps that
> > are loading/using that old module?
> !Locate will happily look for instances of a file in a directory ...
> which could be the whole disc if you want.
> Most useful for finding things in obscure places!
Ah Yes, I'd forgotten about that app, I must dig it out and see what I can
see... Or not see ;-)
Thanks for the prompt Martin.
Regards
Dave
Sometime after... A case of Not see!
What a (Paragraph of Bob the builder choice expletives), can't you wonder
I turn into a GOM.
Verma shows... SocketWatch, so that's what I've been searching in vain for.
It appears in ...!Boot.Resources.!System.310.Modules.Network as
"SockWatch" but internally is notated as "Socketwatch".
Gordon Bennett...
If it's of any use to anyone else, on the RISC OS 6.20 install here, there
are three occurrences of "SockWatch".
..$.!Boot.Choices.Users.Single.Boot.PreDesk.!UniPrint.SockWatch
..$.!Boot.Resources.!System.310.Modules.Network.SockWatch [The updated one]
..$.Net.NetFetches.!NetFetch.Apps.!Hermes.Resources.SockWatch
The UniPrint one is hard wired in the Run file to Run it's internal
SockWatch, as is Hermes.
Dave
--
Dave Triffid
Thursday, 4 April 2024
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b4c7ad502dave@triffid.co.uk>,
Dave <dave@triffid.co.uk> wrote:
> Begs a question, how does one go about finding any other apps that
> are loading/using that old module?
!Locate will happily look for instances of a file in a directory ...
which could be the whole disc if you want.
Most useful for finding things in obscure places!
Dave <dave@triffid.co.uk> wrote:
> Begs a question, how does one go about finding any other apps that
> are loading/using that old module?
!Locate will happily look for instances of a file in a directory ...
which could be the whole disc if you want.
Most useful for finding things in obscure places!
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b4c6d1356dave@triffid.co.uk>,
Dave <dave@triffid.co.uk> wrote:
> In article <5b4c616f4dbob@mightyoak.org.uk>,
> Bob Latham <bob@mightyoak.org.uk> wrote:
> > In article <5b4c526636Lists@Torrens.org>,
> > Richard Torrens (lists) <Lists@Torrens.org> wrote:
> > > In article <5b4c408979bob@mightyoak.org.uk>,
> > > Bob Latham <bob@mightyoak.org.uk> wrote:
> > > > Latest development version 6696 fails to start on RISC OS.
> > > > Immediate error:
> > > > "Still watching sockets; can't be killed yet."
> > > > A machine re-boot does not change this.
> > > > Bob.
> > >
> > > 6696 has an updated SockWatch module. Have you merged the !System
> > > in the zip with your own?
> > Yes, but an earlier socket is loaded by both UniPrint and Hermes from
> > within the applications, there may be more.
> > Bob.
> After updating System with the new one.
> I just went inside ...!Hermes.Resources.SockWatch and named it out
> (SockWatchXXX).
> No problems after that.
> Dave
Begs a question, how does one go about finding any other apps that are
loading/using that old module?
Thanks
Dave
--
Dave Triffid
Dave <dave@triffid.co.uk> wrote:
> In article <5b4c616f4dbob@mightyoak.org.uk>,
> Bob Latham <bob@mightyoak.org.uk> wrote:
> > In article <5b4c526636Lists@Torrens.org>,
> > Richard Torrens (lists) <Lists@Torrens.org> wrote:
> > > In article <5b4c408979bob@mightyoak.org.uk>,
> > > Bob Latham <bob@mightyoak.org.uk> wrote:
> > > > Latest development version 6696 fails to start on RISC OS.
> > > > Immediate error:
> > > > "Still watching sockets; can't be killed yet."
> > > > A machine re-boot does not change this.
> > > > Bob.
> > >
> > > 6696 has an updated SockWatch module. Have you merged the !System
> > > in the zip with your own?
> > Yes, but an earlier socket is loaded by both UniPrint and Hermes from
> > within the applications, there may be more.
> > Bob.
> After updating System with the new one.
> I just went inside ...!Hermes.Resources.SockWatch and named it out
> (SockWatchXXX).
> No problems after that.
> Dave
Begs a question, how does one go about finding any other apps that are
loading/using that old module?
Thanks
Dave
--
Dave Triffid
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b4c616f4dbob@mightyoak.org.uk>,
Bob Latham <bob@mightyoak.org.uk> wrote:
> In article <5b4c526636Lists@Torrens.org>,
> Richard Torrens (lists) <Lists@Torrens.org> wrote:
> > In article <5b4c408979bob@mightyoak.org.uk>,
> > Bob Latham <bob@mightyoak.org.uk> wrote:
> > > Latest development version 6696 fails to start on RISC OS.
> > > Immediate error:
> > > "Still watching sockets; can't be killed yet."
> > > A machine re-boot does not change this.
> > > Bob.
> >
> > 6696 has an updated SockWatch module. Have you merged the !System
> > in the zip with your own?
> Yes, but an earlier socket is loaded by both UniPrint and Hermes from
> within the applications, there may be more.
> Bob.
After updating System with the new one.
I just went inside ...!Hermes.Resources.SockWatch and named it out
(SockWatchXXX).
No problems after that.
Dave
--
Dave Triffid
Bob Latham <bob@mightyoak.org.uk> wrote:
> In article <5b4c526636Lists@Torrens.org>,
> Richard Torrens (lists) <Lists@Torrens.org> wrote:
> > In article <5b4c408979bob@mightyoak.org.uk>,
> > Bob Latham <bob@mightyoak.org.uk> wrote:
> > > Latest development version 6696 fails to start on RISC OS.
> > > Immediate error:
> > > "Still watching sockets; can't be killed yet."
> > > A machine re-boot does not change this.
> > > Bob.
> >
> > 6696 has an updated SockWatch module. Have you merged the !System
> > in the zip with your own?
> Yes, but an earlier socket is loaded by both UniPrint and Hermes from
> within the applications, there may be more.
> Bob.
After updating System with the new one.
I just went inside ...!Hermes.Resources.SockWatch and named it out
(SockWatchXXX).
No problems after that.
Dave
--
Dave Triffid
[netsurf-users] Re: 6696 fails to start on RISC OS
On Thu, Apr 04, 2024 at 04:52:58PM +0100, Bob Latham wrote:
> Yes, but an earlier socket is loaded by both UniPrint and Hermes from
> within the applications, there may be more.
This is a bug in UniPrint and Hermes: the reason we have the System
Merge tool is to prevent this exact situation: apps shouldn't be
shipping their own modules internally because there will inevitably be a
clash, as you have just experienced.
I'm sure they've done this in the name of ease of installation, but it
just messes stuff up for everyone else :(
B.
> Yes, but an earlier socket is loaded by both UniPrint and Hermes from
> within the applications, there may be more.
This is a bug in UniPrint and Hermes: the reason we have the System
Merge tool is to prevent this exact situation: apps shouldn't be
shipping their own modules internally because there will inevitably be a
clash, as you have just experienced.
I'm sure they've done this in the name of ease of installation, but it
just messes stuff up for everyone else :(
B.
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b4c526636Lists@Torrens.org>,
Richard Torrens (lists) <Lists@Torrens.org> wrote:
> In article <5b4c408979bob@mightyoak.org.uk>,
> Bob Latham <bob@mightyoak.org.uk> wrote:
> > Latest development version 6696 fails to start on RISC OS.
> > Immediate error:
> > "Still watching sockets; can't be killed yet."
> > A machine re-boot does not change this.
> > Bob.
>
> 6696 has an updated SockWatch module. Have you merged the !System
> in the zip with your own?
Yes, but an earlier socket is loaded by both UniPrint and Hermes from
within the applications, there may be more.
Bob.
Richard Torrens (lists) <Lists@Torrens.org> wrote:
> In article <5b4c408979bob@mightyoak.org.uk>,
> Bob Latham <bob@mightyoak.org.uk> wrote:
> > Latest development version 6696 fails to start on RISC OS.
> > Immediate error:
> > "Still watching sockets; can't be killed yet."
> > A machine re-boot does not change this.
> > Bob.
>
> 6696 has an updated SockWatch module. Have you merged the !System
> in the zip with your own?
Yes, but an earlier socket is loaded by both UniPrint and Hermes from
within the applications, there may be more.
Bob.
[netsurf-users] Re: 6696 fails to start on RISC OS
On 04 Apr, David Higton <dave@davehigton.me.uk> wrote:
> In message <g4wacql5n6npzdrjcgdjuslz7kvokfjqyh3gwky6cwywkgbvr7@5le2zo43v3z7>
> Rob Kendrick <rjek@rjek.com> wrote:
> > On Thu, Apr 04, 2024 at 10:53:38AM +0100, Bob Latham wrote:
> > > Latest development version 6696 fails to start on RISC OS.
> > >
> > > Immediate error: "Still watching sockets; can't be killed yet."
> > >
> > > A machine re-boot does not change this.
> >
> > My /guess/ is that SocketWatch (or similar) is running via an
> > application launched at boot and it is an earlier version than
> > NetSurf requires, so NetSurf's !Run's RMEnsure tries to replace
> > it with a newer version?
> >
> > What other software is running, and does quitting any of it (or
> > not running it at boot) help at all?
> I've been running 6696 since March 19 with no problem, so it must
> be something to do with the OP's particular system.
> (Mine is a RasPi 3B+, RO from 26-Mar-24).
The issue seems to be Hermes and UniPrint which both load SocketWatch
0.04y(02 Dec 2002). The "y" is not an error.
I can see several fixes now but I emailed Andrew Rawnsley to see what
he advises.
Thanks...
Bob.
--
Bob Latham
Stourbridge, West Midlands
> In message <g4wacql5n6npzdrjcgdjuslz7kvokfjqyh3gwky6cwywkgbvr7@5le2zo43v3z7>
> Rob Kendrick <rjek@rjek.com> wrote:
> > On Thu, Apr 04, 2024 at 10:53:38AM +0100, Bob Latham wrote:
> > > Latest development version 6696 fails to start on RISC OS.
> > >
> > > Immediate error: "Still watching sockets; can't be killed yet."
> > >
> > > A machine re-boot does not change this.
> >
> > My /guess/ is that SocketWatch (or similar) is running via an
> > application launched at boot and it is an earlier version than
> > NetSurf requires, so NetSurf's !Run's RMEnsure tries to replace
> > it with a newer version?
> >
> > What other software is running, and does quitting any of it (or
> > not running it at boot) help at all?
> I've been running 6696 since March 19 with no problem, so it must
> be something to do with the OP's particular system.
> (Mine is a RasPi 3B+, RO from 26-Mar-24).
The issue seems to be Hermes and UniPrint which both load SocketWatch
0.04y(02 Dec 2002). The "y" is not an error.
I can see several fixes now but I emailed Andrew Rawnsley to see what
he advises.
Thanks...
Bob.
--
Bob Latham
Stourbridge, West Midlands
[netsurf-users] Re: 6696 fails to start on RISC OS
In article <5b4c408979bob@mightyoak.org.uk>,
Bob Latham <bob@mightyoak.org.uk> wrote:
> Latest development version 6696 fails to start on RISC OS.
> Immediate error:
> "Still watching sockets; can't be killed yet."
> A machine re-boot does not change this.
> Bob.
6696 has an updated SockWatch module. Have you merged the !System in the
zip with your own?
--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!
Bob Latham <bob@mightyoak.org.uk> wrote:
> Latest development version 6696 fails to start on RISC OS.
> Immediate error:
> "Still watching sockets; can't be killed yet."
> A machine re-boot does not change this.
> Bob.
6696 has an updated SockWatch module. Have you merged the !System in the
zip with your own?
--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!
[netsurf-users] Re: 6696 fails to start on RISC OS
In message <g4wacql5n6npzdrjcgdjuslz7kvokfjqyh3gwky6cwywkgbvr7@5le2zo43v3z7>
Rob Kendrick <rjek@rjek.com> wrote:
> On Thu, Apr 04, 2024 at 10:53:38AM +0100, Bob Latham wrote:
> > Latest development version 6696 fails to start on RISC OS.
> >
> > Immediate error: "Still watching sockets; can't be killed yet."
> >
> > A machine re-boot does not change this.
>
> My /guess/ is that SocketWatch (or similar) is running via an application
> launched at boot and it is an earlier version than NetSurf requires, so
> NetSurf's !Run's RMEnsure tries to replace it with a newer version?
>
> What other software is running, and does quitting any of it (or not running
> it at boot) help at all?
I've been running 6696 since March 19 with no problem, so it must be
something to do with the OP's particular system.
(Mine is a RasPi 3B+, RO from 26-Mar-24).
David
Rob Kendrick <rjek@rjek.com> wrote:
> On Thu, Apr 04, 2024 at 10:53:38AM +0100, Bob Latham wrote:
> > Latest development version 6696 fails to start on RISC OS.
> >
> > Immediate error: "Still watching sockets; can't be killed yet."
> >
> > A machine re-boot does not change this.
>
> My /guess/ is that SocketWatch (or similar) is running via an application
> launched at boot and it is an earlier version than NetSurf requires, so
> NetSurf's !Run's RMEnsure tries to replace it with a newer version?
>
> What other software is running, and does quitting any of it (or not running
> it at boot) help at all?
I've been running 6696 since March 19 with no problem, so it must be
something to do with the OP's particular system.
(Mine is a RasPi 3B+, RO from 26-Mar-24).
David
[netsurf-users] Re: 6696 fails to start on RISC OS
On Thu, Apr 04, 2024 at 10:53:38AM +0100, Bob Latham wrote:
> Latest development version 6696 fails to start on RISC OS.
>
> Immediate error:
> "Still watching sockets; can't be killed yet."
>
> A machine re-boot does not change this.
My /guess/ is that SocketWatch (or similar) is running via an
application launched at boot and it is an earlier version than NetSurf
requires, so NetSurf's !Run's RMEnsure tries to replace it with a newer
version?
What other software is running, and does quitting any of it (or not
running it at boot) help at all?
B.
> Latest development version 6696 fails to start on RISC OS.
>
> Immediate error:
> "Still watching sockets; can't be killed yet."
>
> A machine re-boot does not change this.
My /guess/ is that SocketWatch (or similar) is running via an
application launched at boot and it is an earlier version than NetSurf
requires, so NetSurf's !Run's RMEnsure tries to replace it with a newer
version?
What other software is running, and does quitting any of it (or not
running it at boot) help at all?
B.
[netsurf-users] 6696 fails to start on RISC OS
Latest development version 6696 fails to start on RISC OS.
Immediate error:
"Still watching sockets; can't be killed yet."
A machine re-boot does not change this.
Bob.
Immediate error:
"Still watching sockets; can't be killed yet."
A machine re-boot does not change this.
Bob.
Subscribe to:
Posts (Atom)