On 28/12/2019 23:48, Chris Young wrote:
> Not working on AmigaOS 4/PPC, just fails to recognise them at all (once
> I'd remembered to disable my old WebP datatype).
I think the Amiga (and Atari) toolchain builds need to have libwebp
enabled in the SDK.
--
Michael Drake https://www.codethink.co.uk/
Monday, 30 December 2019
Sunday, 29 December 2019
Re: [Rpcemu] Startup question.
In article
<CAFWmK8yviiPz0_Lb=WmgYyzn_UWFwbad5+s+=VCayfG96x3kYg@mail.gmail.com>, J
Percival <perciv.js@gmail.com> wrote:
> The recompiler converts sections of ARM code as used by Acorn machines
> to the system's native code (x86 on PC) which are then executed directly
> which usually gives a speed boost compared to interpretation. The
> interpreter looks at each ARM instruction in turn and processes it
> without actually converting it. There are a few rare situations where
> the dynamic recompiler makes mistakes so it's basically a tradeoff
> between accuracy and speed. In general the recompiler works fine but if
> you run into problems, you can try the slower interpreter. You'll find
> recompiler/interpreter choices in many emulators for exactly this
> reason. The reason there's two different executables to choose between
> interpreter and recompiler is just an oddity specific to RPCEmu, most
> emulators just have the one executable and then let you configure it in
> the options.
> On Sun, 29 Dec 2019 at 07:47, Dave <dave@triffid.co.uk> wrote:
> > RPCEmu 0.9.2 on Win 10 Pro 64bit.
> > Running RISC OS 6.20 and RISC OS 5.27
> >
> > I was recently asked by a shoulder over-looker...
> > What's the difference between "Recompiler.exe" and "Interpreter.exe"?
> > And immediately followed on with, "Why two different ways to Run
> > something"?
> >
> > I have absolutely no idea, so couldn't answer.
> >
> > Is there an answer to each of the above questions?
> >
> > Thanks
> > Dave
> >
Thanks for the illumination, appreciated.
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<CAFWmK8yviiPz0_Lb=WmgYyzn_UWFwbad5+s+=VCayfG96x3kYg@mail.gmail.com>, J
Percival <perciv.js@gmail.com> wrote:
> The recompiler converts sections of ARM code as used by Acorn machines
> to the system's native code (x86 on PC) which are then executed directly
> which usually gives a speed boost compared to interpretation. The
> interpreter looks at each ARM instruction in turn and processes it
> without actually converting it. There are a few rare situations where
> the dynamic recompiler makes mistakes so it's basically a tradeoff
> between accuracy and speed. In general the recompiler works fine but if
> you run into problems, you can try the slower interpreter. You'll find
> recompiler/interpreter choices in many emulators for exactly this
> reason. The reason there's two different executables to choose between
> interpreter and recompiler is just an oddity specific to RPCEmu, most
> emulators just have the one executable and then let you configure it in
> the options.
> On Sun, 29 Dec 2019 at 07:47, Dave <dave@triffid.co.uk> wrote:
> > RPCEmu 0.9.2 on Win 10 Pro 64bit.
> > Running RISC OS 6.20 and RISC OS 5.27
> >
> > I was recently asked by a shoulder over-looker...
> > What's the difference between "Recompiler.exe" and "Interpreter.exe"?
> > And immediately followed on with, "Why two different ways to Run
> > something"?
> >
> > I have absolutely no idea, so couldn't answer.
> >
> > Is there an answer to each of the above questions?
> >
> > Thanks
> > Dave
> >
Thanks for the illumination, appreciated.
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Startup question.
The recompiler converts sections of ARM code as used by Acorn machines to the system's native code (x86 on PC) which are then executed directly which usually gives a speed boost compared to interpretation.
The interpreter looks at each ARM instruction in turn and processes it without actually converting it. There are a few rare situations where the dynamic recompiler makes mistakes so it's basically a tradeoff between accuracy and speed. In general the recompiler works fine but if you run into problems, you can try the slower interpreter. You'll find recompiler/interpreter choices in many emulators for exactly this reason.
The reason there's two different executables to choose between interpreter and recompiler is just an oddity specific to RPCEmu, most emulators just have the one executable and then let you configure it in the options.
On Sun, 29 Dec 2019 at 07:47, Dave <dave@triffid.co.uk> wrote:
RPCEmu 0.9.2 on Win 10 Pro 64bit.
Running RISC OS 6.20 and RISC OS 5.27
I was recently asked by a shoulder over-looker...
What's the difference between "Recompiler.exe" and "Interpreter.exe"?
And immediately followed on with, "Why two different ways to Run
something"?
I have absolutely no idea, so couldn't answer.
Is there an answer to each of the above questions?
Thanks
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Saturday, 28 December 2019
[Rpcemu] Startup question.
RPCEmu 0.9.2 on Win 10 Pro 64bit.
Running RISC OS 6.20 and RISC OS 5.27
I was recently asked by a shoulder over-looker...
What's the difference between "Recompiler.exe" and "Interpreter.exe"?
And immediately followed on with, "Why two different ways to Run
something"?
I have absolutely no idea, so couldn't answer.
Is there an answer to each of the above questions?
Thanks
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Running RISC OS 6.20 and RISC OS 5.27
I was recently asked by a shoulder over-looker...
What's the difference between "Recompiler.exe" and "Interpreter.exe"?
And immediately followed on with, "Why two different ways to Run
something"?
I have absolutely no idea, so couldn't answer.
Is there an answer to each of the above questions?
Thanks
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: Please test webp image format
On 07/12/2019 13:49, Michael Drake wrote:
> Hello,
>
> Recently we added the webp library to our SDK. NetSurf Builds from
> our CI should now have webp support.
>
> So far we've only tested on Linux. Please could users of other
> platforms visit
>
> https://developers.google.com/speed/webp/gallery1
>
> and let us know if it's working?
Not working on AmigaOS 4/PPC, just fails to recognise them at all (once
I'd remembered to disable my old WebP datatype).
Chris
> Hello,
>
> Recently we added the webp library to our SDK. NetSurf Builds from
> our CI should now have webp support.
>
> So far we've only tested on Linux. Please could users of other
> platforms visit
>
> https://developers.google.com/speed/webp/gallery1
>
> and let us know if it's working?
Not working on AmigaOS 4/PPC, just fails to recognise them at all (once
I'd remembered to disable my old WebP datatype).
Chris
Friday, 20 December 2019
Re: NetSurf Illegal Window Handle (RISC OS)
In message <mpro.q2tm1q008157j00kj.mlist@ypical.myzen.co.uk>
Frederick Bambrough <mlist@ypical.myzen.co.uk> wrote:
>I started a thread on the RISC OS open Forum at
>
>https://www.riscosopen.org/forum/forums/5/topics/14945?page=1#posts-97826
>
>for more details. To sum;
>
>On closing windows in NetSurf choices/configuration I'm seeing the error,
>'An unexpected error occurred: Illegal window handle'. It only happens on
>alternate config categories and on first look doesn't appear to do harm.
>
>It's on RISC OS 5.27 (19-12-19) ROM, NetSurf 3.10(DEV CI #4956).
>
>To summarise the thread, it's due to the latest version of RISC OS
>improved reporting of errors, showing this one up. It's been confirmed by
>others and is said to be related to changes in that ROM relating to
>clipboard caret/task fixes.
>
>
>NetSurf log extract;
>
>(9.520000) frontends/riscos/wimp_event.c:1654
>ro_gui_wimp_event_get_window: Creating structure for window 0x20481e39
>
>(10.850000) frontends/riscos/dialog.c:378 ro_gui_dialog_close:
>xwimp_set_caret_position: 0x288: Illegal window handle
>
>(10.850000) frontends/riscos/gui.c:2112 ro_warn_user: WimpError Illegal
>window handle
>
>(10.850000) frontends/riscos/wimp_event.c:1112
>ro_gui_wimp_event_close_window: Close event received for window 0x20481e39
>
>
>Anything else - best to follow the ROOL forum thread. I'm not qualified
>:-)
I've reported this as Mantis bug 2728.
David
Frederick Bambrough <mlist@ypical.myzen.co.uk> wrote:
>I started a thread on the RISC OS open Forum at
>
>https://www.riscosopen.org/forum/forums/5/topics/14945?page=1#posts-97826
>
>for more details. To sum;
>
>On closing windows in NetSurf choices/configuration I'm seeing the error,
>'An unexpected error occurred: Illegal window handle'. It only happens on
>alternate config categories and on first look doesn't appear to do harm.
>
>It's on RISC OS 5.27 (19-12-19) ROM, NetSurf 3.10(DEV CI #4956).
>
>To summarise the thread, it's due to the latest version of RISC OS
>improved reporting of errors, showing this one up. It's been confirmed by
>others and is said to be related to changes in that ROM relating to
>clipboard caret/task fixes.
>
>
>NetSurf log extract;
>
>(9.520000) frontends/riscos/wimp_event.c:1654
>ro_gui_wimp_event_get_window: Creating structure for window 0x20481e39
>
>(10.850000) frontends/riscos/dialog.c:378 ro_gui_dialog_close:
>xwimp_set_caret_position: 0x288: Illegal window handle
>
>(10.850000) frontends/riscos/gui.c:2112 ro_warn_user: WimpError Illegal
>window handle
>
>(10.850000) frontends/riscos/wimp_event.c:1112
>ro_gui_wimp_event_close_window: Close event received for window 0x20481e39
>
>
>Anything else - best to follow the ROOL forum thread. I'm not qualified
>:-)
I've reported this as Mantis bug 2728.
David
NetSurf Illegal Window Handle (RISC OS)
I started a thread on the RISC OS open Forum at
https://www.riscosopen.org/forum/forums/5/topics/14945?page=1#posts-97826
for more details. To sum;
On closing windows in NetSurf choices/configuration I'm seeing the error,
'An unexpected error occurred: Illegal window handle'. It only happens on
alternate config categories and on first look doesn't appear to do harm.
It's on RISC OS 5.27 (19-12-19) ROM, NetSurf 3.10(DEV CI #4956).
To summarise the thread, it's due to the latest version of RISC OS
improved reporting of errors, showing this one up. It's been confirmed by
others and is said to be related to changes in that ROM relating to
clipboard caret/task fixes.
NetSurf log extract;
(9.520000) frontends/riscos/wimp_event.c:1654
ro_gui_wimp_event_get_window: Creating structure for window 0x20481e39
(10.850000) frontends/riscos/dialog.c:378 ro_gui_dialog_close:
xwimp_set_caret_position: 0x288: Illegal window handle
(10.850000) frontends/riscos/gui.c:2112 ro_warn_user: WimpError Illegal
window handle
(10.850000) frontends/riscos/wimp_event.c:1112
ro_gui_wimp_event_close_window: Close event received for window 0x20481e39
Anything else - best to follow the ROOL forum thread. I'm not qualified
:-)
https://www.riscosopen.org/forum/forums/5/topics/14945?page=1#posts-97826
for more details. To sum;
On closing windows in NetSurf choices/configuration I'm seeing the error,
'An unexpected error occurred: Illegal window handle'. It only happens on
alternate config categories and on first look doesn't appear to do harm.
It's on RISC OS 5.27 (19-12-19) ROM, NetSurf 3.10(DEV CI #4956).
To summarise the thread, it's due to the latest version of RISC OS
improved reporting of errors, showing this one up. It's been confirmed by
others and is said to be related to changes in that ROM relating to
clipboard caret/task fixes.
NetSurf log extract;
(9.520000) frontends/riscos/wimp_event.c:1654
ro_gui_wimp_event_get_window: Creating structure for window 0x20481e39
(10.850000) frontends/riscos/dialog.c:378 ro_gui_dialog_close:
xwimp_set_caret_position: 0x288: Illegal window handle
(10.850000) frontends/riscos/gui.c:2112 ro_warn_user: WimpError Illegal
window handle
(10.850000) frontends/riscos/wimp_event.c:1112
ro_gui_wimp_event_close_window: Close event received for window 0x20481e39
Anything else - best to follow the ROOL forum thread. I'm not qualified
:-)
Tuesday, 10 December 2019
Re: Please test webp image format
>
> > So far we've only tested on Linux. Please could users of other
> > platforms visit https://developers.google.com/speed/webp/gallery1
Struggling to test this with Atari build 4950 because 9 times
out of 10 it says:
FetchErrorTitle
An error occurred when connecting to developers.google.com
Failure when receiving data from the peer
Peter
> > So far we've only tested on Linux. Please could users of other
> > platforms visit https://developers.google.com/speed/webp/gallery1
Struggling to test this with Atari build 4950 because 9 times
out of 10 it says:
FetchErrorTitle
An error occurred when connecting to developers.google.com
Failure when receiving data from the peer
Peter
Monday, 9 December 2019
Re: Please test webp image format
On 7 Dec, tlsa@netsurf-browser.org typed:
> So far we've only tested on Linux. Please could users of other
> platforms visit https://developers.google.com/speed/webp/gallery1
and Wikipedia example WebP file at:
https://upload.wikimedia.org/wikipedia/commons/b/b2/Vulphere_WebP_OTAGROOVE_demonstration_2.webp
with RISC OS NetSurf 3.10 (Dev CI #4951) some anomalies:
RISC OS 5.25 ARMX6
Displayed both test page and WebP file(*) okay once. Then some unexplained
waits with hourglass. Then no further ability to display the WenP data,
even after reloading NetSurf.
(*) by dragging in the saved file despite its being typed Data. Has a RISC
OS file type been assigned?
RISC OS 5.24 Iyonix
Displayed test page repeatedly okay. Did not display the file.
--
Bernard
> So far we've only tested on Linux. Please could users of other
> platforms visit https://developers.google.com/speed/webp/gallery1
and Wikipedia example WebP file at:
https://upload.wikimedia.org/wikipedia/commons/b/b2/Vulphere_WebP_OTAGROOVE_demonstration_2.webp
with RISC OS NetSurf 3.10 (Dev CI #4951) some anomalies:
RISC OS 5.25 ARMX6
Displayed both test page and WebP file(*) okay once. Then some unexplained
waits with hourglass. Then no further ability to display the WenP data,
even after reloading NetSurf.
(*) by dragging in the saved file despite its being typed Data. Has a RISC
OS file type been assigned?
RISC OS 5.24 Iyonix
Displayed test page repeatedly okay. Did not display the file.
--
Bernard
Re: Please test webp image format
On 7 Dec, tlsa@netsurf-browser.org typed:
> The CI builds are available from here:
> https://ci.netsurf-browser.org/builds/
Don't you mean 'Continuous' on that page's <h1>...</h1> ?
--
Bernard
> The CI builds are available from here:
> https://ci.netsurf-browser.org/builds/
Don't you mean 'Continuous' on that page's <h1>...</h1> ?
--
Bernard
Re: Please test webp image format
In article <e801691f58.Brian@bhowlett.plus.net>, Brian Howlett
<brian.groups@brianhowlett.me.uk> wrote:
> On 8 Dec, David Higton wrote:
> > In message <514e111f-108b-c4aa-b35b-081f9544d844@codethink.co.uk>
> > Michael Drake <tlsa@netsurf-browser.org> wrote:
> >> Hello,
> >>
> >> Recently we added the webp library to our SDK. NetSurf Builds from
> >> our CI should now have webp support.
> >>
> >> So far we've only tested on Linux. Please could users of other
> >> platforms visit
> >>
> >> https://developers.google.com/speed/webp/gallery1
> >>
> >> and let us know if it's working?
> > Working correctly here: BBxM, RO 5.27 (28-Oct-19), NS CI#4947. The
> > pairs of photos look identical to me.
> I had the wrong colours showing on this TiMachine yesterday, but just
> now with CI#4950 it works correctly.
Ditto Pi 3B+ RO 5.24
All looking splendid now. Good job.
--
Tim Hill
Webmaster, www.timil.com
websites : php : RISC OS
<brian.groups@brianhowlett.me.uk> wrote:
> On 8 Dec, David Higton wrote:
> > In message <514e111f-108b-c4aa-b35b-081f9544d844@codethink.co.uk>
> > Michael Drake <tlsa@netsurf-browser.org> wrote:
> >> Hello,
> >>
> >> Recently we added the webp library to our SDK. NetSurf Builds from
> >> our CI should now have webp support.
> >>
> >> So far we've only tested on Linux. Please could users of other
> >> platforms visit
> >>
> >> https://developers.google.com/speed/webp/gallery1
> >>
> >> and let us know if it's working?
> > Working correctly here: BBxM, RO 5.27 (28-Oct-19), NS CI#4947. The
> > pairs of photos look identical to me.
> I had the wrong colours showing on this TiMachine yesterday, but just
> now with CI#4950 it works correctly.
Ditto Pi 3B+ RO 5.24
All looking splendid now. Good job.
--
Tim Hill
Webmaster, www.timil.com
websites : php : RISC OS
Sunday, 8 December 2019
Re: Please test webp image format
On 8 Dec, David Higton wrote:
> In message <514e111f-108b-c4aa-b35b-081f9544d844@codethink.co.uk>
> Michael Drake <tlsa@netsurf-browser.org> wrote:
>> Hello,
>>
>> Recently we added the webp library to our SDK. NetSurf Builds from our CI
>> should now have webp support.
>>
>> So far we've only tested on Linux. Please could users of other platforms
>> visit
>>
>> https://developers.google.com/speed/webp/gallery1
>>
>> and let us know if it's working?
> Working correctly here: BBxM, RO 5.27 (28-Oct-19), NS CI#4947. The pairs
> of photos look identical to me.
I had the wrong colours showing on this TiMachine yesterday, but just now
with CI#4950 it works correctly.
--
Brian Howlett
-----------------------------------------------------
I stayed up all night playing poker with Tarot cards.
I got a full house, and four people died.
> In message <514e111f-108b-c4aa-b35b-081f9544d844@codethink.co.uk>
> Michael Drake <tlsa@netsurf-browser.org> wrote:
>> Hello,
>>
>> Recently we added the webp library to our SDK. NetSurf Builds from our CI
>> should now have webp support.
>>
>> So far we've only tested on Linux. Please could users of other platforms
>> visit
>>
>> https://developers.google.com/speed/webp/gallery1
>>
>> and let us know if it's working?
> Working correctly here: BBxM, RO 5.27 (28-Oct-19), NS CI#4947. The pairs
> of photos look identical to me.
I had the wrong colours showing on this TiMachine yesterday, but just now
with CI#4950 it works correctly.
--
Brian Howlett
-----------------------------------------------------
I stayed up all night playing poker with Tarot cards.
I got a full house, and four people died.
Re: Please test webp image format
On 8 Dec 2019 Geoffrey Baxendale <thebears@onetel.com> wrote:
> In message <7971b81e58.thebears@thebears.onetel.com>
> Geoffrey Baxendale <thebears@onetel.com> wrote:
>> In message <d467b11e58.pnyoung@pnyoung.ormail.co.uk>
>> Peter Young <pnyoung@ormail.co.uk> wrote:
>>
>>> On 7 Dec 2019 Michael Drake <tlsa@netsurf-browser.org> wrote:
>>>
>>>> Hello,
>>>
>>>> Recently we added the webp library to our SDK. NetSurf Builds from
>>>> our CI should now have webp support.
>>>
>>>> So far we've only tested on Linux. Please could users of other
>>>> platforms visit
>>>
>>>> https://developers.google.com/speed/webp/gallery1
>>>
>>>> and let us know if it's working?
>>>
>>>
>>>> The CI builds are available from here:
>>>
>>>> https://ci.netsurf-browser.org/builds/
>>>
>>> Working well here with RISC OS, Dev CI#4945. Many thanks.
>>>
>>> Best wishes,
>>>
>>> Peter.
>>>
>> Not here. (4945, RISC OS 5,27 on Titanium.)
>>
>> (colours are wrong. Blue is orange, orange is blue, green is a cyan type
>> colour.)
>>
>> TTFN
> Sorted with #4950. :-)
So it is!
> Thanks
Thanks from me too.
Best wishes,
Peter.
--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> In message <7971b81e58.thebears@thebears.onetel.com>
> Geoffrey Baxendale <thebears@onetel.com> wrote:
>> In message <d467b11e58.pnyoung@pnyoung.ormail.co.uk>
>> Peter Young <pnyoung@ormail.co.uk> wrote:
>>
>>> On 7 Dec 2019 Michael Drake <tlsa@netsurf-browser.org> wrote:
>>>
>>>> Hello,
>>>
>>>> Recently we added the webp library to our SDK. NetSurf Builds from
>>>> our CI should now have webp support.
>>>
>>>> So far we've only tested on Linux. Please could users of other
>>>> platforms visit
>>>
>>>> https://developers.google.com/speed/webp/gallery1
>>>
>>>> and let us know if it's working?
>>>
>>>
>>>> The CI builds are available from here:
>>>
>>>> https://ci.netsurf-browser.org/builds/
>>>
>>> Working well here with RISC OS, Dev CI#4945. Many thanks.
>>>
>>> Best wishes,
>>>
>>> Peter.
>>>
>> Not here. (4945, RISC OS 5,27 on Titanium.)
>>
>> (colours are wrong. Blue is orange, orange is blue, green is a cyan type
>> colour.)
>>
>> TTFN
> Sorted with #4950. :-)
So it is!
> Thanks
Thanks from me too.
Best wishes,
Peter.
--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: Please test webp image format
In message <7971b81e58.thebears@thebears.onetel.com>
Geoffrey Baxendale <thebears@onetel.com> wrote:
> In message <d467b11e58.pnyoung@pnyoung.ormail.co.uk>
> Peter Young <pnyoung@ormail.co.uk> wrote:
>
> > On 7 Dec 2019 Michael Drake <tlsa@netsurf-browser.org> wrote:
> >
> > > Hello,
> >
> > > Recently we added the webp library to our SDK. NetSurf Builds from
> > > our CI should now have webp support.
> >
> > > So far we've only tested on Linux. Please could users of other
> > > platforms visit
> >
> > > https://developers.google.com/speed/webp/gallery1
> >
> > > and let us know if it's working?
> >
> >
> > > The CI builds are available from here:
> >
> > > https://ci.netsurf-browser.org/builds/
> >
> > Working well here with RISC OS, Dev CI#4945. Many thanks.
> >
> > Best wishes,
> >
> > Peter.
> >
> Not here. (4945, RISC OS 5,27 on Titanium.)
>
> (colours are wrong. Blue is orange, orange is blue, green is a cyan type
> colour.)
>
> TTFN
Sorted with #4950. :-)
Thanks
TTFN
--
Geoff.
Using Elesar Titanium.
Isn't that a pip?
Geoffrey Baxendale <thebears@onetel.com> wrote:
> In message <d467b11e58.pnyoung@pnyoung.ormail.co.uk>
> Peter Young <pnyoung@ormail.co.uk> wrote:
>
> > On 7 Dec 2019 Michael Drake <tlsa@netsurf-browser.org> wrote:
> >
> > > Hello,
> >
> > > Recently we added the webp library to our SDK. NetSurf Builds from
> > > our CI should now have webp support.
> >
> > > So far we've only tested on Linux. Please could users of other
> > > platforms visit
> >
> > > https://developers.google.com/speed/webp/gallery1
> >
> > > and let us know if it's working?
> >
> >
> > > The CI builds are available from here:
> >
> > > https://ci.netsurf-browser.org/builds/
> >
> > Working well here with RISC OS, Dev CI#4945. Many thanks.
> >
> > Best wishes,
> >
> > Peter.
> >
> Not here. (4945, RISC OS 5,27 on Titanium.)
>
> (colours are wrong. Blue is orange, orange is blue, green is a cyan type
> colour.)
>
> TTFN
Sorted with #4950. :-)
Thanks
TTFN
--
Geoff.
Using Elesar Titanium.
Isn't that a pip?
Re: Please test webp image format
In message <0481301f58.DaveMeUK@BeagleBoard-xM>
David Higton <dave@davehigton.me.uk> wrote:
> In message <514e111f-108b-c4aa-b35b-081f9544d844@codethink.co.uk>
> Michael Drake <tlsa@netsurf-browser.org> wrote:
>
> > Hello,
> >
> > Recently we added the webp library to our SDK. NetSurf Builds from our
> > CI should now have webp support.
> >
> > So far we've only tested on Linux. Please could users of other
> > platforms visit
> >
> > https://developers.google.com/speed/webp/gallery1
> >
> > and let us know if it's working?
>
> Working correctly here: BBxM, RO 5.27 (28-Oct-19), NS CI#4947. The
> pairs of photos look identical to me.
To confirm, this version of NetSurf is now showing identical colours on my
BB -xM, RISC OS 5.27.
--
Fred
David Higton <dave@davehigton.me.uk> wrote:
> In message <514e111f-108b-c4aa-b35b-081f9544d844@codethink.co.uk>
> Michael Drake <tlsa@netsurf-browser.org> wrote:
>
> > Hello,
> >
> > Recently we added the webp library to our SDK. NetSurf Builds from our
> > CI should now have webp support.
> >
> > So far we've only tested on Linux. Please could users of other
> > platforms visit
> >
> > https://developers.google.com/speed/webp/gallery1
> >
> > and let us know if it's working?
>
> Working correctly here: BBxM, RO 5.27 (28-Oct-19), NS CI#4947. The
> pairs of photos look identical to me.
To confirm, this version of NetSurf is now showing identical colours on my
BB -xM, RISC OS 5.27.
--
Fred
Re: Please test webp image format
In article <514e111f-108b-c4aa-b35b-081f9544d844@codethink.co.uk>,
Michael Drake <tlsa@netsurf-browser.org> wrote:
> So far we've only tested on Linux. Please could users of other
> platforms visit
Dev CI #4947 fixes the colour swapping for me on my original Pi2 and for
David Pitt, who reported elsewhere:
> Oh dear I can't now get to the Netsurf mailing list with Plusnet's
> webmail.
> I only wanted to report that webp image colours are OK now with #4947.
> Tested on Titanium and RPi3B+.
John
--
| John Williams
| johnrw@ukgateway.net
Michael Drake <tlsa@netsurf-browser.org> wrote:
> So far we've only tested on Linux. Please could users of other
> platforms visit
Dev CI #4947 fixes the colour swapping for me on my original Pi2 and for
David Pitt, who reported elsewhere:
> Oh dear I can't now get to the Netsurf mailing list with Plusnet's
> webmail.
> I only wanted to report that webp image colours are OK now with #4947.
> Tested on Titanium and RPi3B+.
John
--
| John Williams
| johnrw@ukgateway.net
Re: Please test webp image format
In message <514e111f-108b-c4aa-b35b-081f9544d844@codethink.co.uk>
Michael Drake <tlsa@netsurf-browser.org> wrote:
> Hello,
>
> Recently we added the webp library to our SDK. NetSurf Builds from our CI
> should now have webp support.
>
> So far we've only tested on Linux. Please could users of other platforms
> visit
>
> https://developers.google.com/speed/webp/gallery1
>
> and let us know if it's working?
Working correctly here: BBxM, RO 5.27 (28-Oct-19), NS CI#4947. The pairs
of photos look identical to me.
David
Michael Drake <tlsa@netsurf-browser.org> wrote:
> Hello,
>
> Recently we added the webp library to our SDK. NetSurf Builds from our CI
> should now have webp support.
>
> So far we've only tested on Linux. Please could users of other platforms
> visit
>
> https://developers.google.com/speed/webp/gallery1
>
> and let us know if it's working?
Working correctly here: BBxM, RO 5.27 (28-Oct-19), NS CI#4947. The pairs
of photos look identical to me.
David
Re: Please test webp image format
Date: Sat, 7 Dec 2019 23:48:22 +0000 (GMT)
From: Peter Slegg <pslegg@scubadivers.co.uk>
Subject: Re: Please test webp image format
To: <netsurf-users@netsurf-browser.org>
Message-ID: <00771621.0419b4904ec6@smtp.freeola.net>
On , netsurf-users-request@netsurf-browser.org wrote:
>>
>> https://developers.google.com/speed/webp/gallery1
>>
>
>Atari build 4946. The link to the fire breathing page shows an
>image without any reversed colours.
>
>
>Peter
I should correct myself.
The jpeg image is being shown but the webp image is not shown at all.
I did a check with firefox (the webp image quality is terrible).
Peter
From: Peter Slegg <pslegg@scubadivers.co.uk>
Subject: Re: Please test webp image format
To: <netsurf-users@netsurf-browser.org>
Message-ID: <00771621.0419b4904ec6@smtp.freeola.net>
On , netsurf-users-request@netsurf-browser.org wrote:
>>
>> https://developers.google.com/speed/webp/gallery1
>>
>
>Atari build 4946. The link to the fire breathing page shows an
>image without any reversed colours.
>
>
>Peter
I should correct myself.
The jpeg image is being shown but the webp image is not shown at all.
I did a check with firefox (the webp image quality is terrible).
Peter
Re: Please test webp image format
Here Atari Coldfire build 4945 doesnt show webp pictures at all.
Chers,
Vido
V V ned., 8. dec. 2019 ob 00:48 je oseba Peter Slegg <pslegg@scubadivers.co.uk> napisala:
On , netsurf-users-request@netsurf-browser.org wrote:
> Date: Sat, 7 Dec 2019 13:49:50 +0000
> From: Michael Drake <tlsa@netsurf-browser.org>
> Subject: Please test webp image format
> To: netsurf-users@netsurf-browser.org
> Message-ID: <514e111f-108b-c4aa-b35b-081f9544d844@codethink.co.uk>
> Hello,
>
> Recently we added the webp library to our SDK. NetSurf Builds from
> our CI should now have webp support.
>
> So far we've only tested on Linux. Please could users of other
> platforms visit
>
> https://developers.google.com/speed/webp/gallery1
>
> and let us know if it's working?
>
>
> The CI builds are available from here:
>
> https://ci.netsurf-browser.org/builds/
>
> Cheers,
>
> Michael
>
Atari build 4946. The link to the fire breathing page shows an
image without any reversed colours.
Peter
Saturday, 7 December 2019
Re: Please test webp image format
On , netsurf-users-request@netsurf-browser.org wrote:
> Date: Sat, 7 Dec 2019 13:49:50 +0000
> From: Michael Drake <tlsa@netsurf-browser.org>
> Subject: Please test webp image format
> To: netsurf-users@netsurf-browser.org
> Message-ID: <514e111f-108b-c4aa-b35b-081f9544d844@codethink.co.uk>
> Hello,
>
> Recently we added the webp library to our SDK. NetSurf Builds from
> our CI should now have webp support.
>
> So far we've only tested on Linux. Please could users of other
> platforms visit
>
> https://developers.google.com/speed/webp/gallery1
>
> and let us know if it's working?
>
>
> The CI builds are available from here:
>
> https://ci.netsurf-browser.org/builds/
>
> Cheers,
>
> Michael
>
Atari build 4946. The link to the fire breathing page shows an
image without any reversed colours.
Peter
> Date: Sat, 7 Dec 2019 13:49:50 +0000
> From: Michael Drake <tlsa@netsurf-browser.org>
> Subject: Please test webp image format
> To: netsurf-users@netsurf-browser.org
> Message-ID: <514e111f-108b-c4aa-b35b-081f9544d844@codethink.co.uk>
> Hello,
>
> Recently we added the webp library to our SDK. NetSurf Builds from
> our CI should now have webp support.
>
> So far we've only tested on Linux. Please could users of other
> platforms visit
>
> https://developers.google.com/speed/webp/gallery1
>
> and let us know if it's working?
>
>
> The CI builds are available from here:
>
> https://ci.netsurf-browser.org/builds/
>
> Cheers,
>
> Michael
>
Atari build 4946. The link to the fire breathing page shows an
image without any reversed colours.
Peter
Re: Please test webp image format
On 7 Dec 2019 cj <chris@chris-johnson.org.uk> wrote:
> In article <1c52658a2840684728dce5b1fa248d21@imap.plus.net>,
> David Pitt <pittdj@pittdj.co.uk> wrote:
>> The bad news is that there is colour transposition seen on RISC OS
>> 5 on the Titaniun and RPi3B+, and OS4.02 on RPCEmu. Yellows appear
>> as blue and vice versa. Red and blue transposed, probably.
> The colours are reversed on iMX6 as well, so it is not limited to the
> OS rgb/bgr reversal.
That's odd, as it doesn't seem to happen here on this ARMX6. Hang on a
minute though. On the first pair of images, the water in the fjord is blue
in one image and orange in the second. Similarly, the sky behind the tree
is blue in one image and orange in the other.
This is way beyond my understanding.
Best wishes,
Peter.
--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> In article <1c52658a2840684728dce5b1fa248d21@imap.plus.net>,
> David Pitt <pittdj@pittdj.co.uk> wrote:
>> The bad news is that there is colour transposition seen on RISC OS
>> 5 on the Titaniun and RPi3B+, and OS4.02 on RPCEmu. Yellows appear
>> as blue and vice versa. Red and blue transposed, probably.
> The colours are reversed on iMX6 as well, so it is not limited to the
> OS rgb/bgr reversal.
That's odd, as it doesn't seem to happen here on this ARMX6. Hang on a
minute though. On the first pair of images, the water in the fjord is blue
in one image and orange in the second. Similarly, the sky behind the tree
is blue in one image and orange in the other.
This is way beyond my understanding.
Best wishes,
Peter.
--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: Please test webp image format
In article <514e111f-108b-c4aa-b35b-081f9544d844@codethink.co.uk>,
Michael Drake <tlsa@netsurf-browser.org> wrote:
> Hello,
> Recently we added the webp library to our SDK. NetSurf Builds from
> our CI should now have webp support.
> So far we've only tested on Linux. Please could users of other
> platforms visit
> https://developers.google.com/speed/webp/gallery1
> and let us know if it's working?
> The CI builds are available from here:
> https://ci.netsurf-browser.org/builds/
> Cheers,
> Michael
No colour problem here RISC OS 6.20 VRPC-DL NetSurf 3.10 (Dev C1 #4945)
C16M Screen colours.
Dave
--
Dave Triffid
Michael Drake <tlsa@netsurf-browser.org> wrote:
> Hello,
> Recently we added the webp library to our SDK. NetSurf Builds from
> our CI should now have webp support.
> So far we've only tested on Linux. Please could users of other
> platforms visit
> https://developers.google.com/speed/webp/gallery1
> and let us know if it's working?
> The CI builds are available from here:
> https://ci.netsurf-browser.org/builds/
> Cheers,
> Michael
No colour problem here RISC OS 6.20 VRPC-DL NetSurf 3.10 (Dev C1 #4945)
C16M Screen colours.
Dave
--
Dave Triffid
Re: Please test webp image format
> In article <1c52658a2840684728dce5b1fa248d21@imap.plus.net>,
> David Pitt <pittdj@pittdj.co.uk> wrote:
>> The bad news is that there is colour transposition seen on RISC OS
>> 5 on the Titaniun and RPi3B+, and OS4.02 on RPCEmu. Yellows appear
>> as blue and vice versa. Red and blue transposed, probably.
cj wrote on 7 Dec:
> The colours are reversed on iMX6 as well, so it is not limited to the
> OS rgb/bgr reversal.a
Yes, same. Here on ArmX6 (Ro 5.25, RComp 2018-apr) the fire shown in the
last photo looks quite surreal when coloured cyan.
Welcome news, though, ye Netsurf team! Only yesterday I was frustrated
when somebody shared me a photo that arrived in Google's newfangled WebP
format.
--
Jim Nagel www.archivemag.co.uk
> David Pitt <pittdj@pittdj.co.uk> wrote:
>> The bad news is that there is colour transposition seen on RISC OS
>> 5 on the Titaniun and RPi3B+, and OS4.02 on RPCEmu. Yellows appear
>> as blue and vice versa. Red and blue transposed, probably.
cj wrote on 7 Dec:
> The colours are reversed on iMX6 as well, so it is not limited to the
> OS rgb/bgr reversal.a
Yes, same. Here on ArmX6 (Ro 5.25, RComp 2018-apr) the fire shown in the
last photo looks quite surreal when coloured cyan.
Welcome news, though, ye Netsurf team! Only yesterday I was frustrated
when somebody shared me a photo that arrived in Google's newfangled WebP
format.
--
Jim Nagel www.archivemag.co.uk
Re: Please test webp image format
In article <mpro.q25l5l005dtlr00cj.mlist@ypical.myzen.co.uk>, Frederick
Bambrough <mlist@ypical.myzen.co.uk> wrote:
> In message <1c52658a2840684728dce5b1fa248d21@imap.plus.net> David Pitt
> <pittdj@pittdj.co.uk> wrote:
> > On 2019-12-07 16:34, Geoffrey Baxendale wrote:
> > > In message <d467b11e58.pnyoung@pnyoung.ormail.co.uk> Peter Young
> > > <pnyoung@ormail.co.uk> wrote:
> > >
> > > > On 7 Dec 2019 Michael Drake <tlsa@netsurf-browser.org> wrote:
> > >>
> > > > > Hello,
[Snip]
> > >>
> > > Not here. (4945, RISC OS 5,27 on Titanium.)
> > >
> > > (colours are wrong. Blue is orange, orange is blue, green is a cyan
> > > type colour.)
> >
> > Not quite right here either.
> >
> > Using NetSurf 4945.
> >
> > The bad news is that there is colour transposition seen on RISC OS 5
> > on the Titaniun and RPi3B+, and OS4.02 on RPCEmu. Yellows appear as
> > blue and vice versa. Red and blue transposed, probably.
> >
> > (Having to send via webmail, Plusnet won't let me reply by email.)
> Same colour issue here on Beagleboard -xM, RISC OS 5.27(01-Dec-19) &
> NetSurf CI #4945
I can confirm same colour issues on Pi3B+ with RO 5.24
--
Tim Hill
Webmaster, www.timil.com
websites : php : RISC OS
Bambrough <mlist@ypical.myzen.co.uk> wrote:
> In message <1c52658a2840684728dce5b1fa248d21@imap.plus.net> David Pitt
> <pittdj@pittdj.co.uk> wrote:
> > On 2019-12-07 16:34, Geoffrey Baxendale wrote:
> > > In message <d467b11e58.pnyoung@pnyoung.ormail.co.uk> Peter Young
> > > <pnyoung@ormail.co.uk> wrote:
> > >
> > > > On 7 Dec 2019 Michael Drake <tlsa@netsurf-browser.org> wrote:
> > >>
> > > > > Hello,
[Snip]
> > >>
> > > Not here. (4945, RISC OS 5,27 on Titanium.)
> > >
> > > (colours are wrong. Blue is orange, orange is blue, green is a cyan
> > > type colour.)
> >
> > Not quite right here either.
> >
> > Using NetSurf 4945.
> >
> > The bad news is that there is colour transposition seen on RISC OS 5
> > on the Titaniun and RPi3B+, and OS4.02 on RPCEmu. Yellows appear as
> > blue and vice versa. Red and blue transposed, probably.
> >
> > (Having to send via webmail, Plusnet won't let me reply by email.)
> Same colour issue here on Beagleboard -xM, RISC OS 5.27(01-Dec-19) &
> NetSurf CI #4945
I can confirm same colour issues on Pi3B+ with RO 5.24
--
Tim Hill
Webmaster, www.timil.com
websites : php : RISC OS
Re: Please test webp image format
In article <1c52658a2840684728dce5b1fa248d21@imap.plus.net>,
David Pitt <pittdj@pittdj.co.uk> wrote:
> The bad news is that there is colour transposition seen on RISC OS
> 5 on the Titaniun and RPi3B+, and OS4.02 on RPCEmu. Yellows appear
> as blue and vice versa. Red and blue transposed, probably.
The colours are reversed on iMX6 as well, so it is not limited to the
OS rgb/bgr reversal.
--
Chris Johnson
Edinburgh
David Pitt <pittdj@pittdj.co.uk> wrote:
> The bad news is that there is colour transposition seen on RISC OS
> 5 on the Titaniun and RPi3B+, and OS4.02 on RPCEmu. Yellows appear
> as blue and vice versa. Red and blue transposed, probably.
The colours are reversed on iMX6 as well, so it is not limited to the
OS rgb/bgr reversal.
--
Chris Johnson
Edinburgh
Re: Please test webp image format
In message <1c52658a2840684728dce5b1fa248d21@imap.plus.net>
David Pitt <pittdj@pittdj.co.uk> wrote:
> On 2019-12-07 16:34, Geoffrey Baxendale wrote:
> > In message <d467b11e58.pnyoung@pnyoung.ormail.co.uk>
> > Peter Young <pnyoung@ormail.co.uk> wrote:
> >
> > > On 7 Dec 2019 Michael Drake <tlsa@netsurf-browser.org> wrote:
> >>
> > > > Hello,
> >>
> > > > Recently we added the webp library to our SDK. NetSurf Builds from
> > > > our CI should now have webp support.
> >>
> > > > So far we've only tested on Linux. Please could users of other
> > > > platforms visit
> >>
> >> > https://developers.google.com/speed/webp/gallery1
> >>
> > > > and let us know if it's working?
> >>
> >>
> > > > The CI builds are available from here:
> >>
> >> > https://ci.netsurf-browser.org/builds/
> >>
> > > Working well here with RISC OS, Dev CI#4945. Many thanks.
> >>
> > > Best wishes,
> >>
> > > Peter.
> >>
> > Not here. (4945, RISC OS 5,27 on Titanium.)
> >
> > (colours are wrong. Blue is orange, orange is blue, green is a cyan
> > type colour.)
>
> Not quite right here either.
>
> Using NetSurf 4945.
>
> The bad news is that there is colour transposition seen on RISC OS 5 on
> the Titaniun and RPi3B+, and OS4.02 on RPCEmu. Yellows appear as blue
> and vice versa. Red and blue transposed, probably.
>
> (Having to send via webmail, Plusnet won't let me reply by email.)
Same colour issue here on Beagleboard -xM, RISC OS 5.27(01-Dec-19) &
NetSurf CI #4945
David Pitt <pittdj@pittdj.co.uk> wrote:
> On 2019-12-07 16:34, Geoffrey Baxendale wrote:
> > In message <d467b11e58.pnyoung@pnyoung.ormail.co.uk>
> > Peter Young <pnyoung@ormail.co.uk> wrote:
> >
> > > On 7 Dec 2019 Michael Drake <tlsa@netsurf-browser.org> wrote:
> >>
> > > > Hello,
> >>
> > > > Recently we added the webp library to our SDK. NetSurf Builds from
> > > > our CI should now have webp support.
> >>
> > > > So far we've only tested on Linux. Please could users of other
> > > > platforms visit
> >>
> >> > https://developers.google.com/speed/webp/gallery1
> >>
> > > > and let us know if it's working?
> >>
> >>
> > > > The CI builds are available from here:
> >>
> >> > https://ci.netsurf-browser.org/builds/
> >>
> > > Working well here with RISC OS, Dev CI#4945. Many thanks.
> >>
> > > Best wishes,
> >>
> > > Peter.
> >>
> > Not here. (4945, RISC OS 5,27 on Titanium.)
> >
> > (colours are wrong. Blue is orange, orange is blue, green is a cyan
> > type colour.)
>
> Not quite right here either.
>
> Using NetSurf 4945.
>
> The bad news is that there is colour transposition seen on RISC OS 5 on
> the Titaniun and RPi3B+, and OS4.02 on RPCEmu. Yellows appear as blue
> and vice versa. Red and blue transposed, probably.
>
> (Having to send via webmail, Plusnet won't let me reply by email.)
Same colour issue here on Beagleboard -xM, RISC OS 5.27(01-Dec-19) &
NetSurf CI #4945
Re: Please test webp image format
On 2019-12-07 16:34, Geoffrey Baxendale wrote:
> In message <d467b11e58.pnyoung@pnyoung.ormail.co.uk>
> Peter Young <pnyoung@ormail.co.uk> wrote:
>
>> On 7 Dec 2019 Michael Drake <tlsa@netsurf-browser.org> wrote:
>>
>> > Hello,
>>
>> > Recently we added the webp library to our SDK. NetSurf Builds from
>> > our CI should now have webp support.
>>
>> > So far we've only tested on Linux. Please could users of other
>> > platforms visit
>>
>> > https://developers.google.com/speed/webp/gallery1
>>
>> > and let us know if it's working?
>>
>>
>> > The CI builds are available from here:
>>
>> > https://ci.netsurf-browser.org/builds/
>>
>> Working well here with RISC OS, Dev CI#4945. Many thanks.
>>
>> Best wishes,
>>
>> Peter.
>>
> Not here. (4945, RISC OS 5,27 on Titanium.)
>
> (colours are wrong. Blue is orange, orange is blue, green is a cyan
> type
> colour.)
Not quite right here either.
Using NetSurf 4945.
The bad news is that there is colour transposition seen on RISC OS 5 on
the
Titaniun and RPi3B+, and OS4.02 on RPCEmu. Yellows appear as blue and
vice
versa. Red and blue transposed, probably.
(Having to send via webmail, Plusnet won't let me reply by email.)
--
David Pitt
> In message <d467b11e58.pnyoung@pnyoung.ormail.co.uk>
> Peter Young <pnyoung@ormail.co.uk> wrote:
>
>> On 7 Dec 2019 Michael Drake <tlsa@netsurf-browser.org> wrote:
>>
>> > Hello,
>>
>> > Recently we added the webp library to our SDK. NetSurf Builds from
>> > our CI should now have webp support.
>>
>> > So far we've only tested on Linux. Please could users of other
>> > platforms visit
>>
>> > https://developers.google.com/speed/webp/gallery1
>>
>> > and let us know if it's working?
>>
>>
>> > The CI builds are available from here:
>>
>> > https://ci.netsurf-browser.org/builds/
>>
>> Working well here with RISC OS, Dev CI#4945. Many thanks.
>>
>> Best wishes,
>>
>> Peter.
>>
> Not here. (4945, RISC OS 5,27 on Titanium.)
>
> (colours are wrong. Blue is orange, orange is blue, green is a cyan
> type
> colour.)
Not quite right here either.
Using NetSurf 4945.
The bad news is that there is colour transposition seen on RISC OS 5 on
the
Titaniun and RPi3B+, and OS4.02 on RPCEmu. Yellows appear as blue and
vice
versa. Red and blue transposed, probably.
(Having to send via webmail, Plusnet won't let me reply by email.)
--
David Pitt
Re: Please test webp image format
In message <d467b11e58.pnyoung@pnyoung.ormail.co.uk>
Peter Young <pnyoung@ormail.co.uk> wrote:
> On 7 Dec 2019 Michael Drake <tlsa@netsurf-browser.org> wrote:
>
> > Hello,
>
> > Recently we added the webp library to our SDK. NetSurf Builds from
> > our CI should now have webp support.
>
> > So far we've only tested on Linux. Please could users of other
> > platforms visit
>
> > https://developers.google.com/speed/webp/gallery1
>
> > and let us know if it's working?
>
>
> > The CI builds are available from here:
>
> > https://ci.netsurf-browser.org/builds/
>
> Working well here with RISC OS, Dev CI#4945. Many thanks.
>
> Best wishes,
>
> Peter.
>
Not here. (4945, RISC OS 5,27 on Titanium.)
(colours are wrong. Blue is orange, orange is blue, green is a cyan type
colour.)
TTFN
--
Geoff. Baxendale, Darwen, Lancashire.
Using Elesar Titanium.
Oxymoron of the day: "Almost Exactly"
Peter Young <pnyoung@ormail.co.uk> wrote:
> On 7 Dec 2019 Michael Drake <tlsa@netsurf-browser.org> wrote:
>
> > Hello,
>
> > Recently we added the webp library to our SDK. NetSurf Builds from
> > our CI should now have webp support.
>
> > So far we've only tested on Linux. Please could users of other
> > platforms visit
>
> > https://developers.google.com/speed/webp/gallery1
>
> > and let us know if it's working?
>
>
> > The CI builds are available from here:
>
> > https://ci.netsurf-browser.org/builds/
>
> Working well here with RISC OS, Dev CI#4945. Many thanks.
>
> Best wishes,
>
> Peter.
>
Not here. (4945, RISC OS 5,27 on Titanium.)
(colours are wrong. Blue is orange, orange is blue, green is a cyan type
colour.)
TTFN
--
Geoff. Baxendale, Darwen, Lancashire.
Using Elesar Titanium.
Oxymoron of the day: "Almost Exactly"
Re: Please test webp image format
On 7 Dec 2019 Michael Drake <tlsa@netsurf-browser.org> wrote:
> Hello,
> Recently we added the webp library to our SDK. NetSurf Builds from
> our CI should now have webp support.
> So far we've only tested on Linux. Please could users of other
> platforms visit
> https://developers.google.com/speed/webp/gallery1
> and let us know if it's working?
> The CI builds are available from here:
> https://ci.netsurf-browser.org/builds/
Working well here with RISC OS, Dev CI#4945. Many thanks.
Best wishes,
Peter.
--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> Hello,
> Recently we added the webp library to our SDK. NetSurf Builds from
> our CI should now have webp support.
> So far we've only tested on Linux. Please could users of other
> platforms visit
> https://developers.google.com/speed/webp/gallery1
> and let us know if it's working?
> The CI builds are available from here:
> https://ci.netsurf-browser.org/builds/
Working well here with RISC OS, Dev CI#4945. Many thanks.
Best wishes,
Peter.
--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Please test webp image format
Hello,
Recently we added the webp library to our SDK. NetSurf Builds from
our CI should now have webp support.
So far we've only tested on Linux. Please could users of other
platforms visit
https://developers.google.com/speed/webp/gallery1
and let us know if it's working?
The CI builds are available from here:
https://ci.netsurf-browser.org/builds/
Cheers,
Michael
Recently we added the webp library to our SDK. NetSurf Builds from
our CI should now have webp support.
So far we've only tested on Linux. Please could users of other
platforms visit
https://developers.google.com/speed/webp/gallery1
and let us know if it's working?
The CI builds are available from here:
https://ci.netsurf-browser.org/builds/
Cheers,
Michael
Saturday, 30 November 2019
Re: [retrocomputing devroom] FOSDEM 2020 - Retrocomputing DevRoom Call for Participation
Hi all,
Note that I will make a presentation on the Linux Framebuffer
(Graphics devroom) in which NetSurf will be mentionned (mainly on
libnsfb part).
For sure, a dedicated presentation about NetSurf would be really interesting!
Nicolas Caramelli
Le mar. 26 nov. 2019 à 16:28, François Revol <revol@free.fr> a écrit :
>
> Hi,
>
> it would be cool to have a NS talk this year at FOSDEM…
>
> François.
>
>
> -------- Message transféré --------
> Sujet : [retrocomputing devroom] FOSDEM 2020 - Retrocomputing DevRoom
> Call for Participation
> Date : Sun, 27 Oct 2019 23:48:33 +0100
> De : Pau Garcia Quiles <pgquiles@elpauer.org>
> Pour : retrocomputing-devroom@lists.fosdem.org
>
> Hello,
>
> FOSDEM is a free software event that offers open source communities a
> place to meet, share ideas and collaborate. It is renowned for being
> highly developer-oriented and brings together 8000+ participants from
> all over the world. It is held in the city of Brussels (Belgium).
>
> FOSDEM 2020 will take place during the weekend of February 1st-2nd
> 2020. More details about the event can be found at
> http://www.fosdem.org.
>
>
> CALL FOR PARTICIPATION
>
> After success in the past two years, the Retrocomputing DevRoom will
> be back in 2020, with talks about usage of older computing hardware
> and software in modern times.
>
> Presentation topics could include but are not limited to:
> - Emulation of old systems to run videogames, legacy software, etc
> - New software, hardware or related to be used with classic systems
> - Open source software emulation/simulation
> - Open hardware
> - Operating systems/executives for retrocomputers/retrosystems
> - Uses of retrocomputing today
> - Other retrosystems topics
> - Opportunities in retrocomputing
>
> You are not limited to slide presentations, of course. Be creative.
>
> However, FOSDEM is an open source conference, therefore we ask you to
> stay clear of marketing presentations. We are not afraid of technical
> stuff: devrooms are a place for development teams to meet, discuss,
> hack and publicly present their project's latest improvements and
> future directions.
>
> If you will have special needs for your talk (e. g. because you will
> need to plug some sort of a system, you need sound, etc), please note
> that clearly in your proposal so that we can provide it.
>
> You can use the Wikipedia definition of retrocomputing as a reference
> definition to see if you talk qualifies, although it is not exclusive:
> https://en.wikipedia.org/wiki/Retrocomputing
>
>
> IMPORTANT DATES
> - 30 November 2019: submission deadline for talk proposals
> - 14 December 2019: announcement of the final schedule
> - 1 February 2020: Retrocomputing DevRoom
>
>
> USEFUL INFORMATION
>
> Use the FOSDEM Pentabarf tool to submit your proposal:
> https://penta.fosdem.org/submission/FOSDEM20
>
> - If necessary, create a Pentabarf account and activate it. Please
> reuse your account from previous years if you have already created it.
> - In the "Person" section, provide First name, Last name (in the
> "General" tab), Email (in the "Contact" tab) and Bio ("Abstract" field
> in the "Description" tab).
> - Submit a proposal by clicking on "Create event".
> - Important! Select the "Retrocomputing DevRoom" track (on the
> "General" tab). If you do not select a track, then nobody, from any
> track, will look at your submission!
> - Provide the title of your talk ("Event title" in the "General" tab).
> - Provide a description of the subject of the talk and the intended
> audience (in the "Abstract" field of the "Description" tab)
> - Provide a rough outline of the talk or goals of the session (a short
> list of bullet points covering topics that will be discussed) in the
> "Full description" field in the "Description" tab
> - Provide an expected length of your talk in the "Duration" field,
> including discussion. The default duration is 30 minutes.
> - Slides are NOT required at the moment of submission
>
> Please note neither FOSDEM nor the Retrocomputing DevRoom will
> reimburse any expenses you incur.
>
>
> RECORDING OF TALKS
>
> The FOSDEM organizers plan to have live streaming and recording fully
> working, both for remote/later viewing of talks, and so that people
> can watch streams in the hallways when rooms are full. This requires
> speakers to consent to being recorded and streamed.
>
> If you plan to be a speaker, please understand that by doing so you
> implicitly give consent for your talk to be recorded and streamed. The
> recordings will be published under the same license as all FOSDEM
> content (CC-BY).
>
> Hope to hear from you soon! And please forward this announcement.
>
>
> CONTACT
>
> The Retrocomputing DevRoom is managed by Pau Garcia Quiles and
> François Revol (retro-devroom-manager@fosdem.org).
>
> A mailing list of speakers, audience and the curious is available,
> please subscribe at:
> https://lists.fosdem.org/listinfo/retrocomputing-devroom
>
>
> --
> Pau Garcia Quiles
> http://www.elpauer.org
> _______________________________________________
> retrocomputing-devroom mailing list
> retrocomputing-devroom@lists.fosdem.org
> https://lists.fosdem.org/listinfo/retrocomputing-devroom
>
Note that I will make a presentation on the Linux Framebuffer
(Graphics devroom) in which NetSurf will be mentionned (mainly on
libnsfb part).
For sure, a dedicated presentation about NetSurf would be really interesting!
Nicolas Caramelli
Le mar. 26 nov. 2019 à 16:28, François Revol <revol@free.fr> a écrit :
>
> Hi,
>
> it would be cool to have a NS talk this year at FOSDEM…
>
> François.
>
>
> -------- Message transféré --------
> Sujet : [retrocomputing devroom] FOSDEM 2020 - Retrocomputing DevRoom
> Call for Participation
> Date : Sun, 27 Oct 2019 23:48:33 +0100
> De : Pau Garcia Quiles <pgquiles@elpauer.org>
> Pour : retrocomputing-devroom@lists.fosdem.org
>
> Hello,
>
> FOSDEM is a free software event that offers open source communities a
> place to meet, share ideas and collaborate. It is renowned for being
> highly developer-oriented and brings together 8000+ participants from
> all over the world. It is held in the city of Brussels (Belgium).
>
> FOSDEM 2020 will take place during the weekend of February 1st-2nd
> 2020. More details about the event can be found at
> http://www.fosdem.org.
>
>
> CALL FOR PARTICIPATION
>
> After success in the past two years, the Retrocomputing DevRoom will
> be back in 2020, with talks about usage of older computing hardware
> and software in modern times.
>
> Presentation topics could include but are not limited to:
> - Emulation of old systems to run videogames, legacy software, etc
> - New software, hardware or related to be used with classic systems
> - Open source software emulation/simulation
> - Open hardware
> - Operating systems/executives for retrocomputers/retrosystems
> - Uses of retrocomputing today
> - Other retrosystems topics
> - Opportunities in retrocomputing
>
> You are not limited to slide presentations, of course. Be creative.
>
> However, FOSDEM is an open source conference, therefore we ask you to
> stay clear of marketing presentations. We are not afraid of technical
> stuff: devrooms are a place for development teams to meet, discuss,
> hack and publicly present their project's latest improvements and
> future directions.
>
> If you will have special needs for your talk (e. g. because you will
> need to plug some sort of a system, you need sound, etc), please note
> that clearly in your proposal so that we can provide it.
>
> You can use the Wikipedia definition of retrocomputing as a reference
> definition to see if you talk qualifies, although it is not exclusive:
> https://en.wikipedia.org/wiki/Retrocomputing
>
>
> IMPORTANT DATES
> - 30 November 2019: submission deadline for talk proposals
> - 14 December 2019: announcement of the final schedule
> - 1 February 2020: Retrocomputing DevRoom
>
>
> USEFUL INFORMATION
>
> Use the FOSDEM Pentabarf tool to submit your proposal:
> https://penta.fosdem.org/submission/FOSDEM20
>
> - If necessary, create a Pentabarf account and activate it. Please
> reuse your account from previous years if you have already created it.
> - In the "Person" section, provide First name, Last name (in the
> "General" tab), Email (in the "Contact" tab) and Bio ("Abstract" field
> in the "Description" tab).
> - Submit a proposal by clicking on "Create event".
> - Important! Select the "Retrocomputing DevRoom" track (on the
> "General" tab). If you do not select a track, then nobody, from any
> track, will look at your submission!
> - Provide the title of your talk ("Event title" in the "General" tab).
> - Provide a description of the subject of the talk and the intended
> audience (in the "Abstract" field of the "Description" tab)
> - Provide a rough outline of the talk or goals of the session (a short
> list of bullet points covering topics that will be discussed) in the
> "Full description" field in the "Description" tab
> - Provide an expected length of your talk in the "Duration" field,
> including discussion. The default duration is 30 minutes.
> - Slides are NOT required at the moment of submission
>
> Please note neither FOSDEM nor the Retrocomputing DevRoom will
> reimburse any expenses you incur.
>
>
> RECORDING OF TALKS
>
> The FOSDEM organizers plan to have live streaming and recording fully
> working, both for remote/later viewing of talks, and so that people
> can watch streams in the hallways when rooms are full. This requires
> speakers to consent to being recorded and streamed.
>
> If you plan to be a speaker, please understand that by doing so you
> implicitly give consent for your talk to be recorded and streamed. The
> recordings will be published under the same license as all FOSDEM
> content (CC-BY).
>
> Hope to hear from you soon! And please forward this announcement.
>
>
> CONTACT
>
> The Retrocomputing DevRoom is managed by Pau Garcia Quiles and
> François Revol (retro-devroom-manager@fosdem.org).
>
> A mailing list of speakers, audience and the curious is available,
> please subscribe at:
> https://lists.fosdem.org/listinfo/retrocomputing-devroom
>
>
> --
> Pau Garcia Quiles
> http://www.elpauer.org
> _______________________________________________
> retrocomputing-devroom mailing list
> retrocomputing-devroom@lists.fosdem.org
> https://lists.fosdem.org/listinfo/retrocomputing-devroom
>
Wednesday, 27 November 2019
[Rpcemu] Re my request for help compiling RPCemu 0.9.2
Hi all,
I have solved the problem, I downloaded the source code again and started afresh, it seems that there was a error created by me when I extracted the source.
With the newly downloaded source file duly extracted, and a suitable ROM image filed in the correct directory the source compiled correctly
and I now have a fully functioning RISC OS 5 emulation running sweetly on my MX-Linux desktop.
Thanks for the advice,
John
Primary: johnmcculloch1<@>gmail.com
As Last Resort: johnmcculloch1956<@>outlook.com
Windows 10, Linux MX 17.1 and Android 8.1.0
Remove < > to use!!!!
As Last Resort: johnmcculloch1956<@>outlook.com
Windows 10, Linux MX 17.1 and Android 8.1.0
Remove < > to use!!!!
Tuesday, 26 November 2019
Fwd: [retrocomputing devroom] FOSDEM 2020 - Retrocomputing DevRoom Call for Participation
Hi,
it would be cool to have a NS talk this year at FOSDEM…
François.
-------- Message transféré --------
Sujet : [retrocomputing devroom] FOSDEM 2020 - Retrocomputing DevRoom
Call for Participation
Date : Sun, 27 Oct 2019 23:48:33 +0100
De : Pau Garcia Quiles <pgquiles@elpauer.org>
Pour : retrocomputing-devroom@lists.fosdem.org
Hello,
FOSDEM is a free software event that offers open source communities a
place to meet, share ideas and collaborate. It is renowned for being
highly developer-oriented and brings together 8000+ participants from
all over the world. It is held in the city of Brussels (Belgium).
FOSDEM 2020 will take place during the weekend of February 1st-2nd
2020. More details about the event can be found at
http://www.fosdem.org.
CALL FOR PARTICIPATION
After success in the past two years, the Retrocomputing DevRoom will
be back in 2020, with talks about usage of older computing hardware
and software in modern times.
Presentation topics could include but are not limited to:
- Emulation of old systems to run videogames, legacy software, etc
- New software, hardware or related to be used with classic systems
- Open source software emulation/simulation
- Open hardware
- Operating systems/executives for retrocomputers/retrosystems
- Uses of retrocomputing today
- Other retrosystems topics
- Opportunities in retrocomputing
You are not limited to slide presentations, of course. Be creative.
However, FOSDEM is an open source conference, therefore we ask you to
stay clear of marketing presentations. We are not afraid of technical
stuff: devrooms are a place for development teams to meet, discuss,
hack and publicly present their project's latest improvements and
future directions.
If you will have special needs for your talk (e. g. because you will
need to plug some sort of a system, you need sound, etc), please note
that clearly in your proposal so that we can provide it.
You can use the Wikipedia definition of retrocomputing as a reference
definition to see if you talk qualifies, although it is not exclusive:
https://en.wikipedia.org/wiki/Retrocomputing
IMPORTANT DATES
- 30 November 2019: submission deadline for talk proposals
- 14 December 2019: announcement of the final schedule
- 1 February 2020: Retrocomputing DevRoom
USEFUL INFORMATION
Use the FOSDEM Pentabarf tool to submit your proposal:
https://penta.fosdem.org/submission/FOSDEM20
- If necessary, create a Pentabarf account and activate it. Please
reuse your account from previous years if you have already created it.
- In the "Person" section, provide First name, Last name (in the
"General" tab), Email (in the "Contact" tab) and Bio ("Abstract" field
in the "Description" tab).
- Submit a proposal by clicking on "Create event".
- Important! Select the "Retrocomputing DevRoom" track (on the
"General" tab). If you do not select a track, then nobody, from any
track, will look at your submission!
- Provide the title of your talk ("Event title" in the "General" tab).
- Provide a description of the subject of the talk and the intended
audience (in the "Abstract" field of the "Description" tab)
- Provide a rough outline of the talk or goals of the session (a short
list of bullet points covering topics that will be discussed) in the
"Full description" field in the "Description" tab
- Provide an expected length of your talk in the "Duration" field,
including discussion. The default duration is 30 minutes.
- Slides are NOT required at the moment of submission
Please note neither FOSDEM nor the Retrocomputing DevRoom will
reimburse any expenses you incur.
RECORDING OF TALKS
The FOSDEM organizers plan to have live streaming and recording fully
working, both for remote/later viewing of talks, and so that people
can watch streams in the hallways when rooms are full. This requires
speakers to consent to being recorded and streamed.
If you plan to be a speaker, please understand that by doing so you
implicitly give consent for your talk to be recorded and streamed. The
recordings will be published under the same license as all FOSDEM
content (CC-BY).
Hope to hear from you soon! And please forward this announcement.
CONTACT
The Retrocomputing DevRoom is managed by Pau Garcia Quiles and
François Revol (retro-devroom-manager@fosdem.org).
A mailing list of speakers, audience and the curious is available,
please subscribe at:
https://lists.fosdem.org/listinfo/retrocomputing-devroom
--
Pau Garcia Quiles
http://www.elpauer.org
_______________________________________________
retrocomputing-devroom mailing list
retrocomputing-devroom@lists.fosdem.org
https://lists.fosdem.org/listinfo/retrocomputing-devroom
it would be cool to have a NS talk this year at FOSDEM…
François.
-------- Message transféré --------
Sujet : [retrocomputing devroom] FOSDEM 2020 - Retrocomputing DevRoom
Call for Participation
Date : Sun, 27 Oct 2019 23:48:33 +0100
De : Pau Garcia Quiles <pgquiles@elpauer.org>
Pour : retrocomputing-devroom@lists.fosdem.org
Hello,
FOSDEM is a free software event that offers open source communities a
place to meet, share ideas and collaborate. It is renowned for being
highly developer-oriented and brings together 8000+ participants from
all over the world. It is held in the city of Brussels (Belgium).
FOSDEM 2020 will take place during the weekend of February 1st-2nd
2020. More details about the event can be found at
http://www.fosdem.org.
CALL FOR PARTICIPATION
After success in the past two years, the Retrocomputing DevRoom will
be back in 2020, with talks about usage of older computing hardware
and software in modern times.
Presentation topics could include but are not limited to:
- Emulation of old systems to run videogames, legacy software, etc
- New software, hardware or related to be used with classic systems
- Open source software emulation/simulation
- Open hardware
- Operating systems/executives for retrocomputers/retrosystems
- Uses of retrocomputing today
- Other retrosystems topics
- Opportunities in retrocomputing
You are not limited to slide presentations, of course. Be creative.
However, FOSDEM is an open source conference, therefore we ask you to
stay clear of marketing presentations. We are not afraid of technical
stuff: devrooms are a place for development teams to meet, discuss,
hack and publicly present their project's latest improvements and
future directions.
If you will have special needs for your talk (e. g. because you will
need to plug some sort of a system, you need sound, etc), please note
that clearly in your proposal so that we can provide it.
You can use the Wikipedia definition of retrocomputing as a reference
definition to see if you talk qualifies, although it is not exclusive:
https://en.wikipedia.org/wiki/Retrocomputing
IMPORTANT DATES
- 30 November 2019: submission deadline for talk proposals
- 14 December 2019: announcement of the final schedule
- 1 February 2020: Retrocomputing DevRoom
USEFUL INFORMATION
Use the FOSDEM Pentabarf tool to submit your proposal:
https://penta.fosdem.org/submission/FOSDEM20
- If necessary, create a Pentabarf account and activate it. Please
reuse your account from previous years if you have already created it.
- In the "Person" section, provide First name, Last name (in the
"General" tab), Email (in the "Contact" tab) and Bio ("Abstract" field
in the "Description" tab).
- Submit a proposal by clicking on "Create event".
- Important! Select the "Retrocomputing DevRoom" track (on the
"General" tab). If you do not select a track, then nobody, from any
track, will look at your submission!
- Provide the title of your talk ("Event title" in the "General" tab).
- Provide a description of the subject of the talk and the intended
audience (in the "Abstract" field of the "Description" tab)
- Provide a rough outline of the talk or goals of the session (a short
list of bullet points covering topics that will be discussed) in the
"Full description" field in the "Description" tab
- Provide an expected length of your talk in the "Duration" field,
including discussion. The default duration is 30 minutes.
- Slides are NOT required at the moment of submission
Please note neither FOSDEM nor the Retrocomputing DevRoom will
reimburse any expenses you incur.
RECORDING OF TALKS
The FOSDEM organizers plan to have live streaming and recording fully
working, both for remote/later viewing of talks, and so that people
can watch streams in the hallways when rooms are full. This requires
speakers to consent to being recorded and streamed.
If you plan to be a speaker, please understand that by doing so you
implicitly give consent for your talk to be recorded and streamed. The
recordings will be published under the same license as all FOSDEM
content (CC-BY).
Hope to hear from you soon! And please forward this announcement.
CONTACT
The Retrocomputing DevRoom is managed by Pau Garcia Quiles and
François Revol (retro-devroom-manager@fosdem.org).
A mailing list of speakers, audience and the curious is available,
please subscribe at:
https://lists.fosdem.org/listinfo/retrocomputing-devroom
--
Pau Garcia Quiles
http://www.elpauer.org
_______________________________________________
retrocomputing-devroom mailing list
retrocomputing-devroom@lists.fosdem.org
https://lists.fosdem.org/listinfo/retrocomputing-devroom
Re: [gccsdk] FILE structure
Hi Ronald,
> In trying to implement wget's own support lib there was a requirement
> for an implementation of freading().
Here's glibc's description. https://manned.org/__freading.3
> It looks like some extra system flag would need to be set on every
> read, and negated on a write.
That may be needed anyway as a side effect of tracking a buffer's state,
e.g.
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/refill.c;h=87a715b848b0009624f3fc76d938ef49a35bc282;hb=HEAD#l33
--
Cheers, Ralph.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> In trying to implement wget's own support lib there was a requirement
> for an implementation of freading().
Here's glibc's description. https://manned.org/__freading.3
> It looks like some extra system flag would need to be set on every
> read, and negated on a write.
That may be needed anyway as a side effect of tracking a buffer's state,
e.g.
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/refill.c;h=87a715b848b0009624f3fc76d938ef49a35bc282;hb=HEAD#l33
--
Cheers, Ralph.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Tuesday, 19 November 2019
Re: [Rpcemu] Help rpcemu-0.9.2
In article <CAF9eEQEPrJyc_NVgGQk0XONW6TqnjK4so-kPoz_cTrr6axB0Bg@mail.gmail.com>,
John McCulloch <johnmcculloch1@gmail.com> wrote:
> So I have tried to do the same on my HP G56 64bit laptop, running 64bit
> MX-Linux 19.1, have installed the source to the same location on my hard
> drive, but when I try to compile the source, an error occurs when I run the
> ./buildit.sh command in my terminal.
> /home/JohnMcCulloch/rpcemu-0.9.2/src/qt5/rpcemu.pro:3: Assignment needs
> exactly one word on the left hand side.
Check line 3 in /home/JohnMcCulloch/rpcemu-0.9.2/src/qt5/rpcemu.pro. It
should look like this:
CONFIG += debug_and_release
or this:
CONFIG += debug_and_release dynarec
The error message indicates there's something more (or less) than the
variable name CONFIG before the +=.
Regards,
Frank
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
John McCulloch <johnmcculloch1@gmail.com> wrote:
> So I have tried to do the same on my HP G56 64bit laptop, running 64bit
> MX-Linux 19.1, have installed the source to the same location on my hard
> drive, but when I try to compile the source, an error occurs when I run the
> ./buildit.sh command in my terminal.
> /home/JohnMcCulloch/rpcemu-0.9.2/src/qt5/rpcemu.pro:3: Assignment needs
> exactly one word on the left hand side.
Check line 3 in /home/JohnMcCulloch/rpcemu-0.9.2/src/qt5/rpcemu.pro. It
should look like this:
CONFIG += debug_and_release
or this:
CONFIG += debug_and_release dynarec
The error message indicates there's something more (or less) than the
variable name CONFIG before the +=.
Regards,
Frank
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Help rpcemu-0.9.2
Hi there,
I have successfully downloaded the Source for 0.9.2 to my Dell Latitude 32bit laptop, and compiled
it on my 32bit MX-Linux v18.3.
And it runs well with RISC OS 3.71.
So I have tried to do the same on my HP G56 64bit laptop, running 64bit MX-Linux 19.1, have installed the source to the same location on my hard drive, but when I try to compile the source, an error occurs when I run the ./buildit.sh command in my terminal.
/home/JohnMcCulloch/rpcemu-0.9.2/src/qt5/rpcemu.pro:3: Assignment needs
exactly one word on the left hand side.
Error processing project file:
/home/JohnMcCulloch/rpcemu-0.9.2/src/qt5/rpcemu.pro
exactly one word on the left hand side.
Error processing project file:
/home/JohnMcCulloch/rpcemu-0.9.2/src/qt5/rpcemu.pro
I cannot work out what is wrong.
Can someone help me please.
John
Primary: johnmcculloch1<@>gmail.com
As Last Resort: johnmcculloch1956<@>outlook.com
Windows 10, Linux MX 17.1 and Android 8.1.0
Remove < > to use!!!!
As Last Resort: johnmcculloch1956<@>outlook.com
Windows 10, Linux MX 17.1 and Android 8.1.0
Remove < > to use!!!!
Sunday, 10 November 2019
Re: [gccsdk] Native GCC 'hangs'
On 06/11/2019 12:05, Chris Johns wrote:
> Hi all
>
> I've found the GCC 4.7.4 compiler "hangs" while compiling some files
> when running natively. This is running RISC OS 5 under RPCEmu, but it
> also does it on an ARMBook. The gccsdk cross-compiler running on Linux
> compiles the same file fine.
>
> One example is Objects/longobject.c from Python 3.8.
>
> #if 0-ing out the PyLong_FromString function will actually let it
> compile the rest. It's a big function, so maybe I just need to wait
> longer? However I did leave it for >30 minutes the other day.
I recall that I've experienced apparent hangs when compiling code that
calls the log() function; I was able to work around it by passing
`-fno-builtin-log` on the command line.
--
James Harper
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Hi all
>
> I've found the GCC 4.7.4 compiler "hangs" while compiling some files
> when running natively. This is running RISC OS 5 under RPCEmu, but it
> also does it on an ARMBook. The gccsdk cross-compiler running on Linux
> compiles the same file fine.
>
> One example is Objects/longobject.c from Python 3.8.
>
> #if 0-ing out the PyLong_FromString function will actually let it
> compile the rest. It's a big function, so maybe I just need to wait
> longer? However I did leave it for >30 minutes the other day.
I recall that I've experienced apparent hangs when compiling code that
calls the log() function; I was able to work around it by passing
`-fno-builtin-log` on the command line.
--
James Harper
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Saturday, 9 November 2019
Re: RISC OS CI#4886 - can't type reply
In message <202f3b0f58.DaveMeUK@BeagleBoard-xM> I wrote:
> Something appears to have gone wrong betweem the RISC OS CI versions 4885
> and 4886. I tried typing a reply in the ROOL site, but no keyboard input
> appeared. The same is true for for 4886 and 4887, but 4885 is OK for me.
>
> Can someone else please try this and let me know if you can reproduce it -
> if so, I will report it.
>
> I did update !Boot and !System.
The issue appears fixed in version 4891.
David
> Something appears to have gone wrong betweem the RISC OS CI versions 4885
> and 4886. I tried typing a reply in the ROOL site, but no keyboard input
> appeared. The same is true for for 4886 and 4887, but 4885 is OK for me.
>
> Can someone else please try this and let me know if you can reproduce it -
> if so, I will report it.
>
> I did update !Boot and !System.
The issue appears fixed in version 4891.
David
Friday, 8 November 2019
Re: RISC OS CI#4886 - can't type reply
Vincent Sanders wrote on 8 Nov:
> This was reported as issue
> https://bugs.netsurf-browser.org/mantis/view.php?id=2715
> I resolved the issue and should be fixed in 4890 and onwards
I loaded #4891 and re-tried the text-area thing I reported in this thread.
That problem too has now disappeared, though I'm not clear how they were
connected.
Thanks, Vincent.
--
Jim Nagel www.archivemag.co.uk
> This was reported as issue
> https://bugs.netsurf-browser.org/mantis/view.php?id=2715
> I resolved the issue and should be fixed in 4890 and onwards
I loaded #4891 and re-tried the text-area thing I reported in this thread.
That problem too has now disappeared, though I'm not clear how they were
connected.
Thanks, Vincent.
--
Jim Nagel www.archivemag.co.uk
Re: RISC OS CI#4886 - can't type reply
On Thu, Nov 07, 2019 at 02:43:09PM +0000, David Higton wrote:
> Something appears to have gone wrong betweem the RISC OS CI versions 4885
> and 4886. I tried typing a reply in the ROOL site, but no keyboard input
> appeared. The same is true for for 4886 and 4887, but 4885 is OK for me.
>
> Can someone else please try this and let me know if you can reproduce it
> - if so, I will report it.
>
> I did update !Boot and !System.
>
> David
>
>
This was reported as issue https://bugs.netsurf-browser.org/mantis/view.php?id=2715
I resolved the issue and should be fixed in 4890 and onwards
--
Regards Vincent
http://www.kyllikki.org/
> Something appears to have gone wrong betweem the RISC OS CI versions 4885
> and 4886. I tried typing a reply in the ROOL site, but no keyboard input
> appeared. The same is true for for 4886 and 4887, but 4885 is OK for me.
>
> Can someone else please try this and let me know if you can reproduce it
> - if so, I will report it.
>
> I did update !Boot and !System.
>
> David
>
>
This was reported as issue https://bugs.netsurf-browser.org/mantis/view.php?id=2715
I resolved the issue and should be fixed in 4890 and onwards
--
Regards Vincent
http://www.kyllikki.org/
Re: RISC OS CI#4886 - can't type reply
David Higton wrote on 7 Nov:
> Something appears to have gone wrong betweem the RISC OS CI versions 4885
> and 4886. I tried typing a reply in the ROOL site, but no keyboard input
> appeared. The same is true for for 4886 and 4887, but 4885 is OK for me.
> Can someone else please try this and let me know if you can reproduce it
> - if so, I will report it.
I was using #4887 earlier today and found that none of the controls for a
text area would work (Ctrl-A, Ctrl-C, Ctrl-X etc).
Went back to my previous version, #4881, and all is well.
--
Jim Nagel www.archivemag.co.uk
> Something appears to have gone wrong betweem the RISC OS CI versions 4885
> and 4886. I tried typing a reply in the ROOL site, but no keyboard input
> appeared. The same is true for for 4886 and 4887, but 4885 is OK for me.
> Can someone else please try this and let me know if you can reproduce it
> - if so, I will report it.
I was using #4887 earlier today and found that none of the controls for a
text area would work (Ctrl-A, Ctrl-C, Ctrl-X etc).
Went back to my previous version, #4881, and all is well.
--
Jim Nagel www.archivemag.co.uk
Thursday, 7 November 2019
Re: "Warning from Netsurf: Unknown"
On , netsurf-users-request@netsurf-browser.org wrote:
> Date: Mon, 04 Nov 2019 13:40:25 +0000 (GMT)
> From: "Richard Torrens (lists)" <Lists@Torrens.org>
> Subject: Re: "Warning from Netsurf: Unknown"
> To: netsurf-users@netsurf-browser.org
> Message-ID: <580da9eeabLists@Torrens.org>
> In article <20191104112318.oax3l5xs43fqrmzq@kyllikki.org>,
> Vincent Sanders <vince@netsurf-browser.org> wrote:
> > I have changed how all network errors are reported to be a proper
> > error page instead of a popup. please can those affected (using CI
> > builds) confirm that the new behaviour is more informative and works
> > for them.
>
> Nice one!
>
> Yes, the error "Couldn't resolve host name" is reported nicely.
>
I was worried that these error pages might be very slow on an
Atari (68060) but they aren't.
Although "FetchErrorTitle" is a little confusing:
-
FetchErrorTitle
An error occurred when connecting to www.45jgf945hf0.omv
Couldn't resolve host name
-
Peter
> Date: Mon, 04 Nov 2019 13:40:25 +0000 (GMT)
> From: "Richard Torrens (lists)" <Lists@Torrens.org>
> Subject: Re: "Warning from Netsurf: Unknown"
> To: netsurf-users@netsurf-browser.org
> Message-ID: <580da9eeabLists@Torrens.org>
> In article <20191104112318.oax3l5xs43fqrmzq@kyllikki.org>,
> Vincent Sanders <vince@netsurf-browser.org> wrote:
> > I have changed how all network errors are reported to be a proper
> > error page instead of a popup. please can those affected (using CI
> > builds) confirm that the new behaviour is more informative and works
> > for them.
>
> Nice one!
>
> Yes, the error "Couldn't resolve host name" is reported nicely.
>
I was worried that these error pages might be very slow on an
Atari (68060) but they aren't.
Although "FetchErrorTitle" is a little confusing:
-
FetchErrorTitle
An error occurred when connecting to www.45jgf945hf0.omv
Couldn't resolve host name
-
Peter
RISC OS CI#4886 - can't type reply
Something appears to have gone wrong betweem the RISC OS CI versions 4885
and 4886. I tried typing a reply in the ROOL site, but no keyboard input
appeared. The same is true for for 4886 and 4887, but 4885 is OK for me.
Can someone else please try this and let me know if you can reproduce it
- if so, I will report it.
I did update !Boot and !System.
David
and 4886. I tried typing a reply in the ROOL site, but no keyboard input
appeared. The same is true for for 4886 and 4887, but 4885 is OK for me.
Can someone else please try this and let me know if you can reproduce it
- if so, I will report it.
I did update !Boot and !System.
David
page refresh -- still a problem
This problem again (using Netsurf #4881 on ArmX6 OS 5.25). See threads in
this list dated 2016-may-03 (when #4088 was in use) and 2018-july-13.
Did some further updates on the Archive site today, and again came up
against the old fails-to-reload problem. None of these do the trick:
F5 or ^F5 or ^R or the buttonbar route or Adjust-click on the
buttonbar or ^buttonbar or Netsurf menu "Navigate > Reload this
page".
The old page always reappears.
Tried quitting and restarting Netsurf, still no joy.
Before anybody asks: the site does not use frames.
I guess the item will have to be cleared from my local cache. Is there a
straightforward way of doing this that I don't know about? Iconbar
"Choices > Cache" does not offer one.
Seems to me the "Reload this page" option ain't strong enuf.
--
Jim Nagel www.archivemag.co.uk
this list dated 2016-may-03 (when #4088 was in use) and 2018-july-13.
Did some further updates on the Archive site today, and again came up
against the old fails-to-reload problem. None of these do the trick:
F5 or ^F5 or ^R or the buttonbar route or Adjust-click on the
buttonbar or ^buttonbar or Netsurf menu "Navigate > Reload this
page".
The old page always reappears.
Tried quitting and restarting Netsurf, still no joy.
Before anybody asks: the site does not use frames.
I guess the item will have to be cleared from my local cache. Is there a
straightforward way of doing this that I don't know about? Iconbar
"Choices > Cache" does not offer one.
Seems to me the "Reload this page" option ain't strong enuf.
--
Jim Nagel www.archivemag.co.uk
Wednesday, 6 November 2019
[gccsdk] Native GCC 'hangs'
Hi all
I've found the GCC 4.7.4 compiler "hangs" while compiling some files
when running natively. This is running RISC OS 5 under RPCEmu, but it
also does it on an ARMBook. The gccsdk cross-compiler running on Linux
compiles the same file fine.
One example is Objects/longobject.c from Python 3.8.
#if 0-ing out the PyLong_FromString function will actually let it
compile the rest. It's a big function, so maybe I just need to wait
longer? However I did leave it for >30 minutes the other day.
Thanks
Chris
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
I've found the GCC 4.7.4 compiler "hangs" while compiling some files
when running natively. This is running RISC OS 5 under RPCEmu, but it
also does it on an ARMBook. The gccsdk cross-compiler running on Linux
compiles the same file fine.
One example is Objects/longobject.c from Python 3.8.
#if 0-ing out the PyLong_FromString function will actually let it
compile the rest. It's a big function, so maybe I just need to wait
longer? However I did leave it for >30 minutes the other day.
Thanks
Chris
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Monday, 4 November 2019
Re: "Warning from Netsurf: Unknown"
Vincent Sanders wrote on 4 Nov:
> I have changed how all network errors are reported to be a proper error
> page instead of a popup. please can those affected (using CI builds)
> confirm that the new behaviour is more informative and works for them.
Thanks for that welcome change, Vincent. I downloaded and installed #4881
just now and tried the site that I first reported in this thread.
I now get a "Connection timed out" error page -- screenshot here :
http://archivemag.co.uk/TEMP/NS-timedout.png (45K)
But I'm not clear whether this page came from Netsurf or from the site
named in the URL bar of the page. If Netsurf, could I suggest that your
design say so? (Maybe just add a Netsurf logo.)
Anyway, it *is* more informative!
Cheers.
--
Jim Nagel www.archivemag.co.uk
> I have changed how all network errors are reported to be a proper error
> page instead of a popup. please can those affected (using CI builds)
> confirm that the new behaviour is more informative and works for them.
Thanks for that welcome change, Vincent. I downloaded and installed #4881
just now and tried the site that I first reported in this thread.
I now get a "Connection timed out" error page -- screenshot here :
http://archivemag.co.uk/TEMP/NS-timedout.png (45K)
But I'm not clear whether this page came from Netsurf or from the site
named in the URL bar of the page. If Netsurf, could I suggest that your
design say so? (Maybe just add a Netsurf logo.)
Anyway, it *is* more informative!
Cheers.
--
Jim Nagel www.archivemag.co.uk
Re: "Warning from Netsurf: Unknown"
On 4 Nov 2019 "Richard Torrens (lists)" <Lists@Torrens.org> wrote:
> In article <20191104112318.oax3l5xs43fqrmzq@kyllikki.org>,
> Vincent Sanders <vince@netsurf-browser.org> wrote:
>> I have changed how all network errors are reported to be a proper
>> error page instead of a popup. please can those affected (using CI
>> builds) confirm that the new behaviour is more informative and works
>> for them.
> Nice one!
> Yes, the error "Couldn't resolve host name" is reported nicely.
And here with CI 4881. Many thanks.
Best wishes,
Peter.
--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> In article <20191104112318.oax3l5xs43fqrmzq@kyllikki.org>,
> Vincent Sanders <vince@netsurf-browser.org> wrote:
>> I have changed how all network errors are reported to be a proper
>> error page instead of a popup. please can those affected (using CI
>> builds) confirm that the new behaviour is more informative and works
>> for them.
> Nice one!
> Yes, the error "Couldn't resolve host name" is reported nicely.
And here with CI 4881. Many thanks.
Best wishes,
Peter.
--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
Re: [Rpcemu] Revised 0.9.2 patch for Mac
In message <1F04925E-AF93-4D6E-B193-42DBF6B30313@maemagel.com>
Timothy Coltman <lists@maemagel.com> wrote:
> Hello all
> Following on from my earlier posts, please find attached a revised
> patch for 0.9.2 that resolves the issue with dynamic recompilation. I
> have tested with 10.14.6 (Mojave) and 10.15.1 (Catalina) and it works
> in both.
Many thanks, it is working nicely here on Catalina 10.15.1 and very
welcome.
--
David Pitt
Titanium
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Timothy Coltman <lists@maemagel.com> wrote:
> Hello all
> Following on from my earlier posts, please find attached a revised
> patch for 0.9.2 that resolves the issue with dynamic recompilation. I
> have tested with 10.14.6 (Mojave) and 10.15.1 (Catalina) and it works
> in both.
Many thanks, it is working nicely here on Catalina 10.15.1 and very
welcome.
--
David Pitt
Titanium
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: "Warning from Netsurf: Unknown"
In article <20191104112318.oax3l5xs43fqrmzq@kyllikki.org>,
Vincent Sanders <vince@netsurf-browser.org> wrote:
> I have changed how all network errors are reported to be a proper
> error page instead of a popup. please can those affected (using CI
> builds) confirm that the new behaviour is more informative and works
> for them.
Nice one!
Yes, the error "Couldn't resolve host name" is reported nicely.
--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!
Vincent Sanders <vince@netsurf-browser.org> wrote:
> I have changed how all network errors are reported to be a proper
> error page instead of a popup. please can those affected (using CI
> builds) confirm that the new behaviour is more informative and works
> for them.
Nice one!
Yes, the error "Couldn't resolve host name" is reported nicely.
--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!
Re: "Warning from Netsurf: Unknown"
On Tue, Oct 22, 2019 at 01:21:26PM +0100, Richard Porter wrote:
> On 22 Oct 2019 David Pitt wrote:
>
> > It is on the bug tracker now. The example above is a very broken site,
> > neither Safari or Firefox get anywhere with it.
>
> I get the same response after a long wait.
>
I have changed how all network errors are reported to be a proper
error page instead of a popup. please can those affected (using CI
builds) confirm that the new behaviour is more informative and works
for them.
--
Regards Vincent
http://www.kyllikki.org/
> On 22 Oct 2019 David Pitt wrote:
>
> > It is on the bug tracker now. The example above is a very broken site,
> > neither Safari or Firefox get anywhere with it.
>
> I get the same response after a long wait.
>
I have changed how all network errors are reported to be a proper
error page instead of a popup. please can those affected (using CI
builds) confirm that the new behaviour is more informative and works
for them.
--
Regards Vincent
http://www.kyllikki.org/
Sunday, 3 November 2019
[Rpcemu] Revised 0.9.2 patch for Mac
Hello all
Following on from my earlier posts, please find attached a revised patch for 0.9.2 that resolves the issue with dynamic recompilation. I have tested with 10.14.6 (Mojave) and 10.15.1 (Catalina) and it works in both.
The compilation instructions are the same as before (see my email dated 27/10/2019).
Tim
Following on from my earlier posts, please find attached a revised patch for 0.9.2 that resolves the issue with dynamic recompilation. I have tested with 10.14.6 (Mojave) and 10.15.1 (Catalina) and it works in both.
The compilation instructions are the same as before (see my email dated 27/10/2019).
Tim
Monday, 28 October 2019
Re: [Rpcemu] RPCEmu 0.9.2
> On 26 Oct 2019, at 20:42, Theo Markettos <theo@markettos.org.uk> wrote:
>
> Apple is tightening up the use of code generated at runtime, since code
> injection is a common attack pathway. It's not possible to do it at all on
> iOS, for example. For macOS, it appears you need to pass MAP_JIT to mmap()
> and also have the feature enabled at code signing time:
> https://github.com/dotnet/coreclr/issues/18617
>
> I think you also need pages RW or RX - macOS has almost no pages that are
> RWX and I suspect they want to keep it that way.
>
> Theo
Interesting, thanks for that.
I *think* I have fixed this, at least on OS X 10.14.6. I found an example of a call to mmap() that I could actually understand and popped it into the method I mentioned previously. It appears to work now, though I'm not using MAP_JIT (if I do, I get an invalid argument error), and I haven't changed code-signing. Perhaps it needs to be different on Catalina - hopefully someone will be able to test this.
A revised patch will follow in the next few days.
Tim
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
>
> Apple is tightening up the use of code generated at runtime, since code
> injection is a common attack pathway. It's not possible to do it at all on
> iOS, for example. For macOS, it appears you need to pass MAP_JIT to mmap()
> and also have the feature enabled at code signing time:
> https://github.com/dotnet/coreclr/issues/18617
>
> I think you also need pages RW or RX - macOS has almost no pages that are
> RWX and I suspect they want to keep it that way.
>
> Theo
Interesting, thanks for that.
I *think* I have fixed this, at least on OS X 10.14.6. I found an example of a call to mmap() that I could actually understand and popped it into the method I mentioned previously. It appears to work now, though I'm not using MAP_JIT (if I do, I get an invalid argument error), and I haven't changed code-signing. Perhaps it needs to be different on Catalina - hopefully someone will be able to test this.
A revised patch will follow in the next few days.
Tim
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] V0.9.2 patch for Mac keyboard and networking support
Timothy Coltman, on 27 Oct, wrote:
> Following the release of 0.9.2, I have updated my Mac patches to work with
> this new release
[snip]
> Please note that due to a recent update to OS X (at least in 10.14.6),
> dynamic recompilation does not work in that particular version of OS X. I
> haven't upgraded to Catalina yet, but I suspect it's the same. Older
> versions of the operating system should (?) be unaffected.
RPCEmu 0.9.2 interpreter has built here on Catalina 10.15 with Xcode 11.1
and Qt 5.12.5.
The only oddity was that the 'netroms' folder and the EtherRPCEm module
within were not recognised, Verma showed no sign of the podule in RISC OS.
Moving the EtherRPCEmu module into 'poduleroms' sorted that and networking
then worked.
I will try a recompiler build later.
Thanks for the good work.
--
David Pitt
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Sunday, 27 October 2019
Re: [Rpcemu] RPCEmu 0.9.2
In article <58092b907fdave@triffid.co.uk>,
Dave <dave@triffid.co.uk> wrote:
> In article
> <CANc9Z=xCR-qg+CFbguRhe9ffVQGUbL+cf1LRw+7Qmx=XmBz0fw@mail.gmail.com>,
> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> > A new version of RPCEmu is available, 0.9.2
> [Snippy]
> Excellent... good work folks...
> However, after spending some hours trying to get networking working, both
> Static (Preferred) and then DHCP not much luck.
> Problem is here I'm using RISC OS 6.20 the config options are different
> to 5.nn.
> The problem is undoubtedly mine not RPCEmus so I'll have another go at it
> tomorrow.
> Dave
Well... Interesting day...
I have two RPCEmu installs that need networking, a RISC OS 6.20 and a ROOL
RISC OS 5.27
Neither of them had active networking set up in the old bridge way...
Technical reasons I'll not expand upon...
After yesterday evenings fun and failures I set out with some purpose
today to sort it.
Yesterday I started to do a manual configure but that didn't work out, but
I did eventually managed to get them working via DHCP the easy peasy way.
New day, refreshed bonce and managed the ROOL RISC OS 5.27 manual
networking configuration without a hitch.
The RISC OS 6.20 was slightly more difficult as the Network config options
are a bit different, however with perseverance I got there in the end.
So I now have both RPCEmu 0.9.2 installs networking... Well within what
they can ATM manage. ;-)
*So thanks for for all the work you must have done to achieve that...*
Dave
Afternotes:
Lanman98 on RISC OS 6.20 networks okay.
Lanman98 on RISC OS 5.27 doesn't at all.
From what I read...
ShareFS doesn't work at all... Can that please be on the list of things to
fix at some point as I normally use ShareFS a lot.
Printing over the network to the printers I have on my LAN works okay with
both 6.20 and 5.27.
Now a question...
On RISC OS 5.27
Upon starting the shutdown process we end up with a small pane that notes:
"The computer is now ready to be switched off"
Accompanied by a "Restart" button, if this button is clicked (I did want a
restart) a new pane is displayed with the following:
RPCEmu Fatal Error.
Bad PC fc001000 fc001000
RPCEmu vanishes... Dead and gone.
This happens every time the Restart button is clicked.
Any particular reason this is happening?
Obvious answer, don't use it... :-)
FWIW. A restart action during the close down of RISC OS 6.20 does not fail
and reboots the RPCEmu.
Thanks
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Dave <dave@triffid.co.uk> wrote:
> In article
> <CANc9Z=xCR-qg+CFbguRhe9ffVQGUbL+cf1LRw+7Qmx=XmBz0fw@mail.gmail.com>,
> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> > A new version of RPCEmu is available, 0.9.2
> [Snippy]
> Excellent... good work folks...
> However, after spending some hours trying to get networking working, both
> Static (Preferred) and then DHCP not much luck.
> Problem is here I'm using RISC OS 6.20 the config options are different
> to 5.nn.
> The problem is undoubtedly mine not RPCEmus so I'll have another go at it
> tomorrow.
> Dave
Well... Interesting day...
I have two RPCEmu installs that need networking, a RISC OS 6.20 and a ROOL
RISC OS 5.27
Neither of them had active networking set up in the old bridge way...
Technical reasons I'll not expand upon...
After yesterday evenings fun and failures I set out with some purpose
today to sort it.
Yesterday I started to do a manual configure but that didn't work out, but
I did eventually managed to get them working via DHCP the easy peasy way.
New day, refreshed bonce and managed the ROOL RISC OS 5.27 manual
networking configuration without a hitch.
The RISC OS 6.20 was slightly more difficult as the Network config options
are a bit different, however with perseverance I got there in the end.
So I now have both RPCEmu 0.9.2 installs networking... Well within what
they can ATM manage. ;-)
*So thanks for for all the work you must have done to achieve that...*
Dave
Afternotes:
Lanman98 on RISC OS 6.20 networks okay.
Lanman98 on RISC OS 5.27 doesn't at all.
From what I read...
ShareFS doesn't work at all... Can that please be on the list of things to
fix at some point as I normally use ShareFS a lot.
Printing over the network to the printers I have on my LAN works okay with
both 6.20 and 5.27.
Now a question...
On RISC OS 5.27
Upon starting the shutdown process we end up with a small pane that notes:
"The computer is now ready to be switched off"
Accompanied by a "Restart" button, if this button is clicked (I did want a
restart) a new pane is displayed with the following:
RPCEmu Fatal Error.
Bad PC fc001000 fc001000
RPCEmu vanishes... Dead and gone.
This happens every time the Restart button is clicked.
Any particular reason this is happening?
Obvious answer, don't use it... :-)
FWIW. A restart action during the close down of RISC OS 6.20 does not fail
and reboots the RPCEmu.
Thanks
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] V0.9.2 patch for Mac keyboard and networking support
Hello all
Following the release of 0.9.2, I have updated my Mac patches to work with this new release, and would like to submit this for inclusion in the proper source for the emulator. This implements keyboard support, and also adds support for networking.
Attached is a ZIP file containing a "macosx" folder and a patch in unified "diff" format. You should unpack this in the "rpcemu-0.9.2/src" folder and apply the patch from there, i.e.:
patch -p0 -i ./rpcemu-0.9.2-mac-keyboard-patch.diff
The patch should successfully apply without error. Next, change into the "qt5" folder, and type the following:
qmake
make -j3
(Increase the 3 to however many cores you've got.)
This should produce an "rpcemu-interpreter.app" application in the top-level "rpcemu-0.9.2" folder. Double-click to run in the normal way. It should work in the same way as the previous Mac releases I've contributed to.
Please note that due to a recent update to OS X (at least in 10.14.6), dynamic recompilation does not work in that particular version of OS X. I haven't upgraded to Catalina yet, but I suspect it's the same. Older versions of the operating system should (?) be unaffected.
As ever, comments and bug reports are welcome.
Tim
Following the release of 0.9.2, I have updated my Mac patches to work with this new release, and would like to submit this for inclusion in the proper source for the emulator. This implements keyboard support, and also adds support for networking.
Attached is a ZIP file containing a "macosx" folder and a patch in unified "diff" format. You should unpack this in the "rpcemu-0.9.2/src" folder and apply the patch from there, i.e.:
patch -p0 -i ./rpcemu-0.9.2-mac-keyboard-patch.diff
The patch should successfully apply without error. Next, change into the "qt5" folder, and type the following:
qmake
make -j3
(Increase the 3 to however many cores you've got.)
This should produce an "rpcemu-interpreter.app" application in the top-level "rpcemu-0.9.2" folder. Double-click to run in the normal way. It should work in the same way as the previous Mac releases I've contributed to.
Please note that due to a recent update to OS X (at least in 10.14.6), dynamic recompilation does not work in that particular version of OS X. I haven't upgraded to Catalina yet, but I suspect it's the same. Older versions of the operating system should (?) be unaffected.
As ever, comments and bug reports are welcome.
Tim
Re: [Rpcemu] RPCEmu 0.9.2
Hi Peter,
> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>
[snip]
> 10.10.10.10 is correct. NAT provides a 10.10.10.x network inside the RPCEmu
> binary.
> The DHCP server inside the RPCEmu binary will return 10.10.10.10 as the IP
> address
> to RISC OS.
Thanks to this advice, Timothy's heads-up and finally reading
the (very clear!) instructions, it just looks like it was
all my fault, together with some strange coincidence in my
networking (both laptops I operate from while watching TV are
WLANed to an access ponit that is then connected via PowerLan to
the main router, which is not the most stable arrangement one
could think of). Just trying to get to the bottom of that, but I
now have plain RISC OS 5.24 running NetSurf OK.
So there is hope for me! Just a shame Access won't work, but
I am certainly happy with all the rest!
Thanks again
Steffen
--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.9.2
At some point Steffen Huber <steffen@huber-net.de> wrote:
> I probably got confused by my RISC OS 4.02 installation not detecting
> a networking interface at all, then I read the docs and somehow jumped
> to the wrong conclusion (and after extracting AutoSense content from
> Mercurial, it DID detect the interface, which was probably even more
> confusing looking back now).
This is wrong, or rather you do not need to copy any autosense files in,
since version 0.9.1 (the previous release) the EtherRPCEm module will
automatically create the autosense files in the !Boot directory for you.
Can you tell me the contents of the 'netroms' directory in the RPCEmu
directory (alongside 'hostfs', 'roms', 'poduleroms' etc) there should
be one file 'EtherRPCEm,ffa'.
Can you tell me the output of '*help etherrpcem', it should be version
1.04 (06 Oct 2019) for version 0.9.2.
Can you double check that 'Network Address Translation' is selected in
Settings->Networking... windows. Only because you mentioned that you'd
hit the Bad PC bug on RISC OS 5 restart, this actually caused RPCEmu
to 'crash' out and not save its config (both these things are going
to get looked at).
> a networking interface at all, then I read the docs and somehow jumped
> to the wrong conclusion (and after extracting AutoSense content from
> Mercurial, it DID detect the interface, which was probably even more
> confusing looking back now).
This is wrong, or rather you do not need to copy any autosense files in,
since version 0.9.1 (the previous release) the EtherRPCEm module will
automatically create the autosense files in the !Boot directory for you.
Can you tell me the contents of the 'netroms' directory in the RPCEmu
directory (alongside 'hostfs', 'roms', 'poduleroms' etc) there should
be one file 'EtherRPCEm,ffa'.
Can you tell me the output of '*help etherrpcem', it should be version
1.04 (06 Oct 2019) for version 0.9.2.
Can you double check that 'Network Address Translation' is selected in
Settings->Networking... windows. Only because you mentioned that you'd
hit the Bad PC bug on RISC OS 5 restart, this actually caused RPCEmu
to 'crash' out and not save its config (both these things are going
to get looked at).
I can't get networking to work. Neither on Windows 10, nor on Windows 7.
Neither via WLAN nor via LAN. Neither running as Admin or not. Neither
via DHCP nor via static IP. Neither with or without active Windows
firewall. Neither with my usual RISC OS 5 and RISC OS 4 installations
nor with a fresh reinstall of RISC OS 5.
DHCP gets 10.10.10.10 as IP. Which is certainly not an IP address
that my only DHCP server in the network would ever supply. Something
is very wrong here and I am running out of ideas what to try.
10.10.10.10 is correct. NAT provides a 10.10.10.x network inside the RPCEmu binary.
The DHCP server inside the RPCEmu binary will return 10.10.10.10 as the IP address
to RISC OS.
Check the above advice about the netroms directory, it appears the module hasn't
been loaded from the there and that your autosense hackery has loaded an older
version (from your !System).
Peter
Re: [Rpcemu] RPCEmu 0.9.2
Hi altogether,
> Steffen Huber <steffen@huber-net.de> wrote:
>
[snip]
> > I have also the IP 10.10.10.10
>
> But presumably your router is somewhere at 10.x.x.x and is configured
> to hand out addresses like 10.x.x.x. This is not the case for me.
> My router is 192.168.1.1 and is configured to hand out IPs via DHCP
> between 192.168.1.100 and 192.168.1.200 (because the rest is reserved
> for static IPs in my home network).
>
> So if a device gets 10.10.10.10 as an IP address here, there is
> something very wrong.
Having just re-read
http://www.marutan.net/rpcemu/manual/net-ro-nat.html
that address seems to be expected in DHCP situation because
of the way NAT works. I need to read the docs more closely before
complaining...
But NetSurf does not work, and DNS does not work, so there is
still something wrong. I'll investigate further.
Thanks
Steffen
--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.9.2
On 27 Oct 2019, at 15:17, Steffen Huber <steffen@huber-net.de> wrote:
By "not working" I mean that ifconfig -a shows that (in the static
IP case) the IP address is correctly assigned, and route shows that
the route to the router is correctly set, and DNS is correctly
configured. But pinging the router/DNS server does not work. Pinging
any other machine on the network does not work. Name resolving
obviously does not work, either.
Pinging doesn't work for me either, but it seems that's a quirk of the NAT implementation. From the website (http://www.marutan.net/rpcemu/manual/net-ro-nat.html):
"ICMP packets are not forwarded through the Network Address Translation, only IP packets, as such 'ping' will not be able to ping any host other than 10.10.10.10 and 10.10.10.2".
Tim
Re: [Rpcemu] RPCEmu 0.9.2
Hi David,
> dfeugey@ascinfo.fr wrote
>
>
> Le 2019-10-27 16:17, Steffen Huber a écrit :
> > Hi David,
> >
> > DHCP gets 10.10.10.10 as IP. Which is certainly not an IP address
> > that my only DHCP server in the network would ever supply. Something
> > is very wrong here and I am running out of ideas what to try.
> >
> I have also the IP 10.10.10.10
But presumably your router is somewhere at 10.x.x.x and is configured
to hand out addresses like 10.x.x.x. This is not the case for me.
My router is 192.168.1.1 and is configured to hand out IPs via DHCP
between 192.168.1.100 and 192.168.1.200 (because the rest is reserved
for static IPs in my home network).
So if a device gets 10.10.10.10 as an IP address here, there is
something very wrong.
> > By "not working" I mean that ifconfig -a shows that (in the static
> > IP case) the IP address is correctly assigned, and route shows that
> > the route to the router is correctly set, and DNS is correctly
> > configured.
>
> I remove all information in the DNS and Gateway configuration applet,
> and it works.
> Here, I have 10.10.10.2 as the gateway (auto configured) and no DNS.
Whatever I configure - either DHCP in the same way that works just fine
for any RISC OS 4 Select or RISC OS 5 machine, or static IP like I
do for the RISC OS 4 and previous machines - it does not work.
> > But pinging the router/DNS server does not work. Pinging
> > any other machine on the network does not work. Name resolving
> > obviously does not work, either.
>
> I suspect you defined the gateway and DNS, and that's the reason why it
> does not work.
You suspect wrongly. And even if I did, there is no way that could
result in an IP address assignment like 10.10.10.10. And it does not
make failure in static IP situation plausible at all.
Steffen
--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.9.2
Le 2019-10-27 16:17, Steffen Huber a écrit :
> Hi David,
>
> DHCP gets 10.10.10.10 as IP. Which is certainly not an IP address
> that my only DHCP server in the network would ever supply. Something
> is very wrong here and I am running out of ideas what to try.
>
I have also the IP 10.10.10.10
> Hi David,
>
> DHCP gets 10.10.10.10 as IP. Which is certainly not an IP address
> that my only DHCP server in the network would ever supply. Something
> is very wrong here and I am running out of ideas what to try.
>
I have also the IP 10.10.10.10
> By "not working" I mean that ifconfig -a shows that (in the static
> IP case) the IP address is correctly assigned, and route shows that
> the route to the router is correctly set, and DNS is correctly
> configured.
I remove all information in the DNS and Gateway configuration applet,
and it works.
Here, I have 10.10.10.2 as the gateway (auto configured) and no DNS.
> But pinging the router/DNS server does not work. Pinging
> any other machine on the network does not work. Name resolving
> obviously does not work, either.
I suspect you defined the gateway and DNS, and that's the reason why it
does not work.
David
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.9.2
Hi David,
> dfeugey@ascinfo.fr wrote:
>
>
> Le 2019-10-26 16:11, Steffen Huber a écrit :
>
> >
> > Anyway, it does not work for me, neither with DHCP
>
> Be sure to remove all options for gateway and DNS server as all is done
> with DHCP.
I configured RISC OS networking perhaps a thousand times,
so I have that feeling that that part is not the problem.
> Here, it works well, apart from 'reduce CPU usage' completely broken on
> RISC OS 5 and the lack of CallWin32 (it would be useful for so many
> things).
>
> RPCEmu is almost perfect now :)
I can't get networking to work. Neither on Windows 10, nor on Windows 7.
Neither via WLAN nor via LAN. Neither running as Admin or not. Neither
via DHCP nor via static IP. Neither with or without active Windows
firewall. Neither with my usual RISC OS 5 and RISC OS 4 installations
nor with a fresh reinstall of RISC OS 5.
DHCP gets 10.10.10.10 as IP. Which is certainly not an IP address
that my only DHCP server in the network would ever supply. Something
is very wrong here and I am running out of ideas what to try.
By "not working" I mean that ifconfig -a shows that (in the static
IP case) the IP address is correctly assigned, and route shows that
the route to the router is correctly set, and DNS is correctly
configured. But pinging the router/DNS server does not work. Pinging
any other machine on the network does not work. Name resolving
obviously does not work, either.
Any ideas?
Thanks
Steffen
--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Saturday, 26 October 2019
Re: [Rpcemu] RPCEmu 0.9.2
In article
<CANc9Z=xCR-qg+CFbguRhe9ffVQGUbL+cf1LRw+7Qmx=XmBz0fw@mail.gmail.com>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> A new version of RPCEmu is available, 0.9.2
[Snippy]
Excellent... good work folks...
However, after spending some hours trying to get networking working, both
Static (Preferred) and then DHCP not much luck.
Problem is here I'm using RISC OS 6.20 the config options are different to
5.nn.
The problem is undoubtedly mine not RPCEmus so I'll have another go at it
tomorrow.
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<CANc9Z=xCR-qg+CFbguRhe9ffVQGUbL+cf1LRw+7Qmx=XmBz0fw@mail.gmail.com>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> A new version of RPCEmu is available, 0.9.2
[Snippy]
Excellent... good work folks...
However, after spending some hours trying to get networking working, both
Static (Preferred) and then DHCP not much luck.
Problem is here I'm using RISC OS 6.20 the config options are different to
5.nn.
The problem is undoubtedly mine not RPCEmus so I'll have another go at it
tomorrow.
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.9.2
There was (I believe) an issue with the pointer/length calculations for that mprotect() code at one point, for which I submitted an (untested) patch. The current code doesn't really resemble mine but I'm pretty sure it gets the correct values anyway, and so I suspect Tim is correct about it being some new sandboxing protection.
On Sat, Oct 26, 2019 at 6:30 PM Timothy Coltman <lists@maemagel.com> wrote:
On 26 Oct 2019, at 10:02, Peter Howkins <rpcemu.howkins@marutan.net> wrote:_______________________________________________
Hi Peter
I'm pleased to report that from a Mac point of view, 0.9.2 does compile and run once it's been patched with my previous work from 0.9.1. I'll issue a revised patch in due course.
Even better, networking works - I can connect to my NAS via !FTPc and use Netsurf to connect to a few web sites. I did have to write some dummy functions for the various functions in a Mac equivalent "network-linux.c" to get the code to compile.
However, compiling with the "dynarec" option turned on gives an access denied error when you run the emulator (the "mprotect" line in "set_memory_executable" of "ArmDynarec.c"). This is OS X 10.14.6, with the latest software updates. This looks like an Apple change or something, as previous versions of the emulator did work with dynamic compilation turned on. It seems to object to PROT_EXEC - no idea why, though reading around suggests it may be something to do with sandboxing.
Tim
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.9.2
On Sat, Oct 26, 2019 at 06:28:58PM +0100, Timothy Coltman wrote:
> However, compiling with the "dynarec" option turned on gives an access
> denied error when you run the emulator (the "mprotect" line in
> "set_memory_executable" of "ArmDynarec.c"). This is OS X 10.14.6, with
> the latest software updates. This looks like an Apple change or
> something, as previous versions of the emulator did work with dynamic
> compilation turned on. It seems to object to PROT_EXEC - no idea why,
> though reading around suggests it may be something to do with sandboxing.
Apple is tightening up the use of code generated at runtime, since code
injection is a common attack pathway. It's not possible to do it at all on
iOS, for example. For macOS, it appears you need to pass MAP_JIT to mmap()
and also have the feature enabled at code signing time:
https://github.com/dotnet/coreclr/issues/18617
I think you also need pages RW or RX - macOS has almost no pages that are
RWX and I suspect they want to keep it that way.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> However, compiling with the "dynarec" option turned on gives an access
> denied error when you run the emulator (the "mprotect" line in
> "set_memory_executable" of "ArmDynarec.c"). This is OS X 10.14.6, with
> the latest software updates. This looks like an Apple change or
> something, as previous versions of the emulator did work with dynamic
> compilation turned on. It seems to object to PROT_EXEC - no idea why,
> though reading around suggests it may be something to do with sandboxing.
Apple is tightening up the use of code generated at runtime, since code
injection is a common attack pathway. It's not possible to do it at all on
iOS, for example. For macOS, it appears you need to pass MAP_JIT to mmap()
and also have the feature enabled at code signing time:
https://github.com/dotnet/coreclr/issues/18617
I think you also need pages RW or RX - macOS has almost no pages that are
RWX and I suspect they want to keep it that way.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.9.2
On 26 Oct 2019, at 10:02, Peter Howkins <rpcemu.howkins@marutan.net> wrote:
Hi Peter
I'm pleased to report that from a Mac point of view, 0.9.2 does compile and run once it's been patched with my previous work from 0.9.1. I'll issue a revised patch in due course.
Even better, networking works - I can connect to my NAS via !FTPc and use Netsurf to connect to a few web sites. I did have to write some dummy functions for the various functions in a Mac equivalent "network-linux.c" to get the code to compile.
However, compiling with the "dynarec" option turned on gives an access denied error when you run the emulator (the "mprotect" line in "set_memory_executable" of "ArmDynarec.c"). This is OS X 10.14.6, with the latest software updates. This looks like an Apple change or something, as previous versions of the emulator did work with dynamic compilation turned on. It seems to object to PROT_EXEC - no idea why, though reading around suggests it may be something to do with sandboxing.
Tim
Hi Peter
I'm pleased to report that from a Mac point of view, 0.9.2 does compile and run once it's been patched with my previous work from 0.9.1. I'll issue a revised patch in due course.
Even better, networking works - I can connect to my NAS via !FTPc and use Netsurf to connect to a few web sites. I did have to write some dummy functions for the various functions in a Mac equivalent "network-linux.c" to get the code to compile.
However, compiling with the "dynarec" option turned on gives an access denied error when you run the emulator (the "mprotect" line in "set_memory_executable" of "ArmDynarec.c"). This is OS X 10.14.6, with the latest software updates. This looks like an Apple change or something, as previous versions of the emulator did work with dynamic compilation turned on. It seems to object to PROT_EXEC - no idea why, though reading around suggests it may be something to do with sandboxing.
Tim
Subscribe to:
Posts (Atom)