Thanks!! Actually I was just to answer myself. The thing is that now it starts on linux framebuffer, but I cannot move the mouse cursor and the image only gets updated during the page loading. If I move the mouse, the image dissapears as if I were painting with a black paintbrush..
Keyboard doesnt work either..
Any ideas???
Thanks!!
El 31/10/2013, a las 23:42, Ole <ole@monochrom.net> escribió:
> Am Donnerstag, den 31.10.2013, 15:08 +0100 schrieb Andrés Martinelli <andmarti@gmail.com>:
>
>> How can I start netsurf with the linux "surface", so it uses the
>> terminal framebuffer instead of tty7/tty8 ???
>
> Hello,
>
> you can use -f=linux or maybe -f linux
>
> That should work, at least in the source tells it looks that way:
> http://git.netsurf-browser.org/netsurf.git/tree/framebuffer/gui.c#n437
>
> Greets,
> Ole
>
Thursday, 31 October 2013
Re: netsurf-fb - linux framebuffer
Am Donnerstag, den 31.10.2013, 15:08 +0100 schrieb Andrés Martinelli
<andmarti@gmail.com>:
> How can I start netsurf with the linux "surface", so it uses the
> terminal framebuffer instead of tty7/tty8 ???
Hello,
you can use -f=linux or maybe -f linux
That should work, at least in the source tells it looks that way:
http://git.netsurf-browser.org/netsurf.git/tree/framebuffer/gui.c#n437
Greets,
Ole
<andmarti@gmail.com>:
> How can I start netsurf with the linux "surface", so it uses the
> terminal framebuffer instead of tty7/tty8 ???
Hello,
you can use -f=linux or maybe -f linux
That should work, at least in the source tells it looks that way:
http://git.netsurf-browser.org/netsurf.git/tree/framebuffer/gui.c#n437
Greets,
Ole
netsurf-fb - linux framebuffer
Hello Everyone!
I've installed netsurf-fb from the debian repositories with:
sudo apt-get install netsurf-fb.
When I start it, I believe it uses SDL and not the linux framebuffer.I've installed netsurf-fb from the debian repositories with:
sudo apt-get install netsurf-fb.
I have to press Ctrl-Alt-Fx to go back to console, and Alt-F7 or Alt-F8 to go back to netsurf.
How can I start netsurf with the linux "surface", so it uses the terminal framebuffer instead of tty7/tty8 ???Andrés
Monday, 28 October 2013
Re: [Rpcemu] RPCEmu and RO 5.20 Time/Date
In message <779021a153.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 27 Oct 2013, Frank de Bruijn <rpcemu-sub@aconet.nl> wrote:
>> In article <df8bd7a053.old_coaster@old_coaster.yahoo.co.uk>,
>> Tony Moore <old_coaster@yahoo.co.uk> wrote:
>
>> > I should be grateful for comments: Is this problem a bug, in RPCEmu?
>>
>> Well, *I* think it is. That's why I reported it. Last January. See the
>> thread "RPCEmu abort 'Bad opcode 14 41435452'" starting 11 January.
I've had the same experience exactly on 0810/520 on a Win7/64 PC, with
'Set from the Network', 'Pick a server automatically' and 'Switch DST
automatically' all selected. Switching to manual setting and editing
the HostFS:$.!Boot.Choices.Boot.Tasks.TimeSetup file as specified by
Tony earlier seems to restore stable booting. FWIW, testing with just
'Set from the Network' enabled did not invariably cause problems, but
in combination with automatic server picking and DST switching, it
did.
In passing, thanks to Tony (and Frank) for spotting this and to Tony
for working out the solution - I can now use networked 0810/520, which
hitherto I had abandoned due to the 'bad opcode' issue!
[snip]
>
> If, indeed, 'Set manually' causes the time to be read from the host OS,
> thus making 'Set from the net' unneccessary, and unwise, perhaps a note
> to this effect needs to be added to the User Manual?
Agreed.
--
George
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 27 Oct 2013, Frank de Bruijn <rpcemu-sub@aconet.nl> wrote:
>> In article <df8bd7a053.old_coaster@old_coaster.yahoo.co.uk>,
>> Tony Moore <old_coaster@yahoo.co.uk> wrote:
>
>> > I should be grateful for comments: Is this problem a bug, in RPCEmu?
>>
>> Well, *I* think it is. That's why I reported it. Last January. See the
>> thread "RPCEmu abort 'Bad opcode 14 41435452'" starting 11 January.
I've had the same experience exactly on 0810/520 on a Win7/64 PC, with
'Set from the Network', 'Pick a server automatically' and 'Switch DST
automatically' all selected. Switching to manual setting and editing
the HostFS:$.!Boot.Choices.Boot.Tasks.TimeSetup file as specified by
Tony earlier seems to restore stable booting. FWIW, testing with just
'Set from the Network' enabled did not invariably cause problems, but
in combination with automatic server picking and DST switching, it
did.
In passing, thanks to Tony (and Frank) for spotting this and to Tony
for working out the solution - I can now use networked 0810/520, which
hitherto I had abandoned due to the 'bad opcode' issue!
[snip]
>
> If, indeed, 'Set manually' causes the time to be read from the host OS,
> thus making 'Set from the net' unneccessary, and unwise, perhaps a note
> to this effect needs to be added to the User Manual?
Agreed.
--
George
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Sunday, 27 October 2013
Re: IP address with no scheme
On Sun, 27 Oct 2013 10:20:51 +0000, Rob Kendrick wrote:
> On Sun, Oct 27, 2013 at 10:10:55AM +0000, Chris Young wrote:
> > Hi
> >
> > This has just been pointed out to me. When typing an IP address into
> > NetSurf's URL bar with no scheme attached (eg. just 192.168.0.10),
> > NetSurf appears to pass this directly to gui_launch_url() rather than
> > handling it the same as if a dotted host name had been typed in.
> > However, it's slightly worse than that, as even 192.com is not
> > recognised.
>
> While it's obviously not ideal behavior, it is worth noting that
> "192.com" is not a legal domain name; elements in names must not start
> with a digit, in order to be able to distinguish them easily from IP
> addresses. 3com should also know better.
Even so, shouldn't NetSurf be assuming the http:// part whether it is
an IP address or name?
> Sadly, domain registrars have let this go on for too long to take it
> back now.
Yeah, 192.com has existed for as long as I remember.
Chris
> On Sun, Oct 27, 2013 at 10:10:55AM +0000, Chris Young wrote:
> > Hi
> >
> > This has just been pointed out to me. When typing an IP address into
> > NetSurf's URL bar with no scheme attached (eg. just 192.168.0.10),
> > NetSurf appears to pass this directly to gui_launch_url() rather than
> > handling it the same as if a dotted host name had been typed in.
> > However, it's slightly worse than that, as even 192.com is not
> > recognised.
>
> While it's obviously not ideal behavior, it is worth noting that
> "192.com" is not a legal domain name; elements in names must not start
> with a digit, in order to be able to distinguish them easily from IP
> addresses. 3com should also know better.
Even so, shouldn't NetSurf be assuming the http:// part whether it is
an IP address or name?
> Sadly, domain registrars have let this go on for too long to take it
> back now.
Yeah, 192.com has existed for as long as I remember.
Chris
Re: IP address with no scheme
On Sun, Oct 27, 2013 at 10:10:55AM +0000, Chris Young wrote:
> Hi
>
> This has just been pointed out to me. When typing an IP address into
> NetSurf's URL bar with no scheme attached (eg. just 192.168.0.10),
> NetSurf appears to pass this directly to gui_launch_url() rather than
> handling it the same as if a dotted host name had been typed in.
> However, it's slightly worse than that, as even 192.com is not
> recognised.
While it's obviously not ideal behavior, it is worth noting that
"192.com" is not a legal domain name; elements in names must not start
with a digit, in order to be able to distinguish them easily from IP
addresses. 3com should also know better.
Sadly, domain registrars have let this go on for too long to take it
back now.
B.
> Hi
>
> This has just been pointed out to me. When typing an IP address into
> NetSurf's URL bar with no scheme attached (eg. just 192.168.0.10),
> NetSurf appears to pass this directly to gui_launch_url() rather than
> handling it the same as if a dotted host name had been typed in.
> However, it's slightly worse than that, as even 192.com is not
> recognised.
While it's obviously not ideal behavior, it is worth noting that
"192.com" is not a legal domain name; elements in names must not start
with a digit, in order to be able to distinguish them easily from IP
addresses. 3com should also know better.
Sadly, domain registrars have let this go on for too long to take it
back now.
B.
IP address with no scheme
Hi
This has just been pointed out to me. When typing an IP address into
NetSurf's URL bar with no scheme attached (eg. just 192.168.0.10),
NetSurf appears to pass this directly to gui_launch_url() rather than
handling it the same as if a dotted host name had been typed in.
However, it's slightly worse than that, as even 192.com is not
recognised.
http://192.168.0.10 - works
192.168.0.10 - gets forwarded to gui_launch_url
192.com - gets forwarded to gui_launch_url
http://192.com - works
www.192.com - works
I don't think this is intended behaviour?
Chris
This has just been pointed out to me. When typing an IP address into
NetSurf's URL bar with no scheme attached (eg. just 192.168.0.10),
NetSurf appears to pass this directly to gui_launch_url() rather than
handling it the same as if a dotted host name had been typed in.
However, it's slightly worse than that, as even 192.com is not
recognised.
http://192.168.0.10 - works
192.168.0.10 - gets forwarded to gui_launch_url
192.com - gets forwarded to gui_launch_url
http://192.com - works
www.192.com - works
I don't think this is intended behaviour?
Chris
Re: [Rpcemu] RPCEmu and RO 5.20 Time/Date
On 27 Oct 2013, Frank de Bruijn <rpcemu-sub@aconet.nl> wrote:
> In article <df8bd7a053.old_coaster@old_coaster.yahoo.co.uk>,
> Tony Moore <old_coaster@yahoo.co.uk> wrote:
> > I should be grateful for comments: Is this problem a bug, in RPCEmu?
>
> Well, *I* think it is. That's why I reported it. Last January. See the
> thread "RPCEmu abort 'Bad opcode 14 41435452'" starting 11 January.
Found it. My memory is becoming shorter and shorter!
> > What are the recommended settings for Configure > 'Time and date'?
>
> I've left it at "Set manually", obviously.
That's where mine is now. I notice that the clocks of emuleated RO 4.39,
5.20 and 6.20 all trail the Win7 clock by one or two seconds, suggesting
that 'Set manually' causes the time to be read from the host OS. This
corresponds with my earlier understanding, but I'm at a loss as to how,
a few days ago, emulated 5.20 was more than an hour adrift, which set me
off on this particular excursion.
If, indeed, 'Set manually' causes the time to be read from the host OS,
thus making 'Set from the net' unneccessary, and unwise, perhaps a note
to this effect needs to be added to the User Manual?
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> In article <df8bd7a053.old_coaster@old_coaster.yahoo.co.uk>,
> Tony Moore <old_coaster@yahoo.co.uk> wrote:
> > I should be grateful for comments: Is this problem a bug, in RPCEmu?
>
> Well, *I* think it is. That's why I reported it. Last January. See the
> thread "RPCEmu abort 'Bad opcode 14 41435452'" starting 11 January.
Found it. My memory is becoming shorter and shorter!
> > What are the recommended settings for Configure > 'Time and date'?
>
> I've left it at "Set manually", obviously.
That's where mine is now. I notice that the clocks of emuleated RO 4.39,
5.20 and 6.20 all trail the Win7 clock by one or two seconds, suggesting
that 'Set manually' causes the time to be read from the host OS. This
corresponds with my earlier understanding, but I'm at a loss as to how,
a few days ago, emulated 5.20 was more than an hour adrift, which set me
off on this particular excursion.
If, indeed, 'Set manually' causes the time to be read from the host OS,
thus making 'Set from the net' unneccessary, and unwise, perhaps a note
to this effect needs to be added to the User Manual?
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Saturday, 26 October 2013
Re: [Rpcemu] RPCEmu and RO 5.20 Time/Date
In article <df8bd7a053.old_coaster@old_coaster.yahoo.co.uk>,
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> I should be grateful for comments: Is this problem a bug, in RPCEmu?
Well, *I* think it is. That's why I reported it. Last January. See the
thread "RPCEmu abort 'Bad opcode 14 41435452'" starting 11 January.
> What are the recommended settings for Configure > 'Time and date'?
I've left it at "Set manually", obviously.
Regards,
Frank
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> I should be grateful for comments: Is this problem a bug, in RPCEmu?
Well, *I* think it is. That's why I reported it. Last January. See the
thread "RPCEmu abort 'Bad opcode 14 41435452'" starting 11 January.
> What are the recommended settings for Configure > 'Time and date'?
I've left it at "Set manually", obviously.
Regards,
Frank
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] RPCEmu and RO 5.20 Time/Date
I had thought that RPCEmu read its time and date from its host but, a
few days ago, I saw that the clock of my RPCEmu0810/RO520 installation
differed from its Win7 host clock, by more than an hour.
To fix this, I went to Configure > 'Time and date' and changed 'Set
manually' to 'Set from the network'. When I clicked 'Set', the RPCEmu
clock immediately corrected itself, so I assumed that all was well, and
forgot about the change.
However, yesterday, when I started RPCEmu0810/RO520 the boot sequence
aborted, just after the appearance of the desktop, and a Windows-type
error, from RPCEmu, reported 'Bad opcode 1441435452 at 20182480'. On
clearing the error, RPCEmu crashed, and disappeared.
I eventually discovered that HostFS:$.!Boot.Choices.Boot.Tasks.TimeSetup
was the cause of the problem. That file is generated automatically from
Configure > 'Time and date' settings. Having deleted the active contents
of TimeSetup, to return to 'Set manually', RPCEmu boots normally again.
When 'Set from the network' is chosen, TimeSetup contains:
| This file was automatically generated by !TimeSetup
| Format:5
| Locality:UTC+00:00_UK_'GMT'
| ServerSelector:0
Set NetTime$Server pool.ntp.org
SetEval NetTime$Loaded 1
RMEnsure NetTime 0.39 X RMLoad System:Modules.Network.NetTime
RMEnsure NetTime 0.39 SetEval NetTime$Loaded 0
If <NetTime$Loaded> Then NetTime_PollInterval 86400
The NetTime module is active:
*help nettime
==> Help on keyword NetTime
Module is: NetTime 0.40 (10 Apr 2012)
Commands provided:
NetTime_Kick NetTime_Status NetTime_PollInterval
I should be grateful for comments: Is this problem a bug, in RPCEmu?
What are the recommended settings for Configure > 'Time and date'?
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
few days ago, I saw that the clock of my RPCEmu0810/RO520 installation
differed from its Win7 host clock, by more than an hour.
To fix this, I went to Configure > 'Time and date' and changed 'Set
manually' to 'Set from the network'. When I clicked 'Set', the RPCEmu
clock immediately corrected itself, so I assumed that all was well, and
forgot about the change.
However, yesterday, when I started RPCEmu0810/RO520 the boot sequence
aborted, just after the appearance of the desktop, and a Windows-type
error, from RPCEmu, reported 'Bad opcode 1441435452 at 20182480'. On
clearing the error, RPCEmu crashed, and disappeared.
I eventually discovered that HostFS:$.!Boot.Choices.Boot.Tasks.TimeSetup
was the cause of the problem. That file is generated automatically from
Configure > 'Time and date' settings. Having deleted the active contents
of TimeSetup, to return to 'Set manually', RPCEmu boots normally again.
When 'Set from the network' is chosen, TimeSetup contains:
| This file was automatically generated by !TimeSetup
| Format:5
| Locality:UTC+00:00_UK_'GMT'
| ServerSelector:0
Set NetTime$Server pool.ntp.org
SetEval NetTime$Loaded 1
RMEnsure NetTime 0.39 X RMLoad System:Modules.Network.NetTime
RMEnsure NetTime 0.39 SetEval NetTime$Loaded 0
If <NetTime$Loaded> Then NetTime_PollInterval 86400
The NetTime module is active:
*help nettime
==> Help on keyword NetTime
Module is: NetTime 0.40 (10 Apr 2012)
Commands provided:
NetTime_Kick NetTime_Status NetTime_PollInterval
I should be grateful for comments: Is this problem a bug, in RPCEmu?
What are the recommended settings for Configure > 'Time and date'?
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Friday, 25 October 2013
Re: [Rpcemu] RCPEmu 0.8.11 for Windows less functional than 0.8.10
Configuration ? Ah, I forgot to copy the CMOS file from 0.8.10.
That did solve the problem.
Concerning the switch to full screen, only the recompiler version is affected by the problem.
Cheers,
André
From: Gerald Holdsworth [mailto:gerald@hollypops.co.uk]
Sent: Friday, October 25, 2013 9:15 PM
To: Timmermans, Andre
Cc: rpcemu@riscos.info
Subject: Re: [Rpcemu] RCPEmu 0.8.11 for Windows less functional than 0.8.10
On 25 Oct 2013, at 18:22, Timmermans, Andre wrote:
Hi,
I gave a little trial on the new version and quickly noticed 2 problems:
RISC OS 6 don’t work on it: it complains early in the boot sequence about fonts being for RISC OS 4 and drops to CLI. Typing *Desktop doesn’t seem to do anything.
A switch to full screen brings the application down.
Kind Regards,
André
This is a RISC OS configuration. Can't remember the link (and I don't have the guide to hand), but I wrote a little guide to installing RISC OS 6 on RPCemu, and this was one of the problems that you may encounter. It is quite simply a module you'll need to *INSERT, if memory serves.
Cheers,
Gerald.
Re: [Rpcemu] RCPEmu 0.8.11 for Windows less functional than 0.8.10
On 25 Oct 2013, at 18:22, Timmermans, Andre wrote:
This is a RISC OS configuration. Can't remember the link (and I don't have the guide to hand), but I wrote a little guide to installing RISC OS 6 on RPCemu, and this was one of the problems that you may encounter. It is quite simply a module you'll need to *INSERT, if memory serves.Hi,I gave a little trial on the new version and quickly noticed 2 problems:RISC OS 6 don't work on it: it complains early in the boot sequence about fonts being for RISC OS 4 and drops to CLI. Typing *Desktop doesn't seem to do anything.A switch to full screen brings the application down.Kind Regards,André
Cheers,
Gerald.
Re: [Rpcemu] RCPEmu 0.8.11 for Windows less functional than 0.8.10
In article
<2796FB2D03D57A4D816B2B61ADF569DD1A556003@DEFTHW99EZ3MSX.ww931.my-it-solutions.net>,
"Timmermans, Andre" <andre.timmermans@atos.net> wrote:
> Hi,
> I gave a little trial on the new version and quickly noticed 2 problems:
> RISC OS 6 don't work on it: it complains early in the boot sequence
> about fonts being for RISC OS 4 and drops to CLI. Typing *Desktop
> doesn't seem to do anything. A switch to full screen brings the
> application down.
> Kind Regards,
> André
Mnnn! Can't help with your problem, but FWIW RO 6.20 on RPCEmu 0.8.11
works here without any noticeable problems, as it does on 4.02, 4.39 and
5.21
In Configure it is set as RiscPC-StrongArm.
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<2796FB2D03D57A4D816B2B61ADF569DD1A556003@DEFTHW99EZ3MSX.ww931.my-it-solutions.net>,
"Timmermans, Andre" <andre.timmermans@atos.net> wrote:
> Hi,
> I gave a little trial on the new version and quickly noticed 2 problems:
> RISC OS 6 don't work on it: it complains early in the boot sequence
> about fonts being for RISC OS 4 and drops to CLI. Typing *Desktop
> doesn't seem to do anything. A switch to full screen brings the
> application down.
> Kind Regards,
> André
Mnnn! Can't help with your problem, but FWIW RO 6.20 on RPCEmu 0.8.11
works here without any noticeable problems, as it does on 4.02, 4.39 and
5.21
In Configure it is set as RiscPC-StrongArm.
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] RCPEmu 0.8.11 for Windows less functional than 0.8.10
Hi,
I gave a little trial on the new version and quickly noticed 2 problems:
RISC OS 6 don’t work on it: it complains early in the boot sequence about fonts being for RISC OS 4 and drops to CLI. Typing *Desktop doesn’t seem to do anything.
A switch to full screen brings the application down.
Kind Regards,
André
Re: [Rpcemu] RPCEmu 0.8.11
In message <1382637922.58886.YahooMailNeo@web172302.mail.ir2.yahoo.com
>
Tom Walker <tommowalker@yahoo.co.uk> wrote:
> On Thursday, 24 October 2013, 13:36, george greenfield
> <george.greenfield@tiscali.co.uk> wrote:
>
>>> There is the oft repeated story that !Desk_Bogo favours VRPC, but
>>> Dhrystones indicate rpcemu is faster.
>
[snip]
>>Indeed: that suspicion is supported by Chris Hall's benchmarks here
>>https://www.riscosopen.org/forum/forums/5/topics/466?page=8
>>where VRPC on a 2668MHz PC gives only 175% compared to a bog-standard
>>S/ARM RPC, i.e. 1524MHz = 100%; the corresponding figure for RPCEmu
>>here is approx. 1000MHz = 100%. Obviously that assumes a similar
>>processor type in the 2668MHz machine, which may not be the case.
>
> The frequently quoted 2668 MHz machine is most likely a Pentium 4. The
> Core i7 quoted for the RPCemu results will be vastly quicker
> clock-for-clock, therefore comparing performance across the different
> emulators based solely on clock speeds of these two very different
> machines is not very meaningful.
>
Fair enough, but the point is not whether exact measurements can be
made, but whether a trend is revealed. RPCEmu0.8.8/4.02 Recompiler on
my elderly Celeron 1500MHz XP laptop manages 112%, which is still
relatively better than the VRPC result on the 2668MHz machine (not
allowing for the >5% speed-up on later versions of RPCEmu), so the
suspicion that VRPC runs slower remains intact. But granted, until
someone with time on their hands /and/ both emulators on the same PC
runs ROMark on both we're never going to know for sure.
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
>
Tom Walker <tommowalker@yahoo.co.uk> wrote:
> On Thursday, 24 October 2013, 13:36, george greenfield
> <george.greenfield@tiscali.co.uk> wrote:
>
>>> There is the oft repeated story that !Desk_Bogo favours VRPC, but
>>> Dhrystones indicate rpcemu is faster.
>
[snip]
>>Indeed: that suspicion is supported by Chris Hall's benchmarks here
>>https://www.riscosopen.org/forum/forums/5/topics/466?page=8
>>where VRPC on a 2668MHz PC gives only 175% compared to a bog-standard
>>S/ARM RPC, i.e. 1524MHz = 100%; the corresponding figure for RPCEmu
>>here is approx. 1000MHz = 100%. Obviously that assumes a similar
>>processor type in the 2668MHz machine, which may not be the case.
>
> The frequently quoted 2668 MHz machine is most likely a Pentium 4. The
> Core i7 quoted for the RPCemu results will be vastly quicker
> clock-for-clock, therefore comparing performance across the different
> emulators based solely on clock speeds of these two very different
> machines is not very meaningful.
>
Fair enough, but the point is not whether exact measurements can be
made, but whether a trend is revealed. RPCEmu0.8.8/4.02 Recompiler on
my elderly Celeron 1500MHz XP laptop manages 112%, which is still
relatively better than the VRPC result on the 2668MHz machine (not
allowing for the >5% speed-up on later versions of RPCEmu), so the
suspicion that VRPC runs slower remains intact. But granted, until
someone with time on their hands /and/ both emulators on the same PC
runs ROMark on both we're never going to know for sure.
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Thursday, 24 October 2013
Re: Amiga CI build fix >> Re: toolchains: branch chris/sdk-53-24 created.
On Thu, 24 Oct 2013 14:04:55 +0100, Michael Drake wrote:
> It seems to be working now with this extra change:
>
> http://git.netsurf-browser.org/toolchains.git/commit/?id=1894883ba6970d8990f31c99ab846e58100683c9
I knew I'd miss something! Builds now working again, thanks.
Chris
> It seems to be working now with this extra change:
>
> http://git.netsurf-browser.org/toolchains.git/commit/?id=1894883ba6970d8990f31c99ab846e58100683c9
I knew I'd miss something! Builds now working again, thanks.
Chris
Re: [Rpcemu] RPCEmu 0.8.11
On Thursday, 24 October 2013, 13:36, george greenfield <george.greenfield@tiscali.co.uk> wrote:
>> There is the oft repeated story that !Desk_Bogo favours VRPC, but
>> Dhrystones indicate rpcemu is faster.
Haven't heard this one personally, however I should point out !Desk_Bogo is utterly useless as a benchmark, as it benchmarks literally doing nothing (hence the name). Dhrystone is only marginally more useful.
>Indeed: that suspicion is supported by Chris Hall's benchmarks here
>https://www.riscosopen.org/forum/forums/5/topics/466?page=8
>where VRPC on a 2668MHz PC gives only 175% compared to a bog-standard
>S/ARM RPC, i.e. 1524MHz = 100%; the corresponding figure for RPCEmu
>here is approx. 1000MHz = 100%. Obviously that assumes a similar
>processor type in the 2668MHz machine, which may not be the case.
The frequently quoted 2668 MHz machine is most likely a Pentium 4. The Core i7 quoted for the RPCemu results will be vastly quicker clock-for-clock, therefore comparing performance across the different emulators based solely on clock speeds of these two very different machines is not very meaningful.
Tom
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
>> There is the oft repeated story that !Desk_Bogo favours VRPC, but
>> Dhrystones indicate rpcemu is faster.
Haven't heard this one personally, however I should point out !Desk_Bogo is utterly useless as a benchmark, as it benchmarks literally doing nothing (hence the name). Dhrystone is only marginally more useful.
>Indeed: that suspicion is supported by Chris Hall's benchmarks here
>https://www.riscosopen.org/forum/forums/5/topics/466?page=8
>where VRPC on a 2668MHz PC gives only 175% compared to a bog-standard
>S/ARM RPC, i.e. 1524MHz = 100%; the corresponding figure for RPCEmu
>here is approx. 1000MHz = 100%. Obviously that assumes a similar
>processor type in the 2668MHz machine, which may not be the case.
The frequently quoted 2668 MHz machine is most likely a Pentium 4. The Core i7 quoted for the RPCemu results will be vastly quicker clock-for-clock, therefore comparing performance across the different emulators based solely on clock speeds of these two very different machines is not very meaningful.
Tom
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.8.11
On 23 Oct 2013, at 21:26, Peter Howkins wrote:
> A new version of RPCEmu is available, 0.8.11
>
> http://www.marutan.net/rpcemu/
I notice that the version for Mac OS X is still at 0.8.9. I know the source code is there, but I have no idea on how to compile this into a working application for the Mac (I don't know C, or it's derivatives, that well...I'm more a Pascal guy - and PHP, JavaScript, CSS and HTML).
Can anyone advise, or even compile it for Mac OS X?
I have got Xcode installed on this machine, although I've never really used it.
Many cheers,
Gerald.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> A new version of RPCEmu is available, 0.8.11
>
> http://www.marutan.net/rpcemu/
I notice that the version for Mac OS X is still at 0.8.9. I know the source code is there, but I have no idea on how to compile this into a working application for the Mac (I don't know C, or it's derivatives, that well...I'm more a Pascal guy - and PHP, JavaScript, CSS and HTML).
Can anyone advise, or even compile it for Mac OS X?
I have got Xcode installed on this machine, although I've never really used it.
Many cheers,
Gerald.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: Amiga CI build fix >> Re: toolchains: branch chris/sdk-53-24 created.
In article
<OUT-52680A9A.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
> OK, I've merged it to master, can you give it another prod please? It
> should find something new to do now.
It seems to be working now with this extra change:
http://git.netsurf-browser.org/toolchains.git/commit/?id=1894883ba6970d8990f31c99ab846e58100683c9
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
<OUT-52680A9A.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
> OK, I've merged it to master, can you give it another prod please? It
> should find something new to do now.
It seems to be working now with this extra change:
http://git.netsurf-browser.org/toolchains.git/commit/?id=1894883ba6970d8990f31c99ab846e58100683c9
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: [Rpcemu] RPCEmu 0.8.11
In message <a0f19f9f53.pittdj+@iyonix.home>
David Pitt <pittdj@pittdj.co.uk> wrote:
> In message <6d9d959f53.George@tiscali..co.uk>
> george greenfield <george.greenfield@tiscali.co.uk> wrote:
>
>> In message <mpro.mv61td00381ke03n2.pittdj@pittdj.co.uk>
>> David Pitt <pittdj@pittdj.co.uk> wrote:
>
>>> Peter Howkins, on 23 Oct, wrote:
>>>
[Snip]
>
> I have just tried a brief test or two but they don't really tell us
> much. The tests are !Desk_Bogo and Dhrystones.
>
> bogomips dhrystones
>
> Ubuntu 12.04 on VMware on an iMac, rpcemu 0.8.11
> Phoebe OS3.80 Interpreter 41 98,396
> SA110 OS5.21 Recompiler 117 481,463
>
> This is not like for like, no surprises, the Recompiler is a lot
> faster.
>
> Mac OS X Mavericks, rpcemu 0.8.9
> SA110 OS5.21 Recompiler 159 627,746
ROMark scores c.610k dhrystone MIPs on my 0810/520 Recompiler
installation here, running on a Dell XPS 3.4GHz i7 Win7/64 platform.
>
> This is more interesting there is that much difference between the
> Virtual Machine and native installations.
>
> Mac OS X Mavericks, VRPC
> OS4.39 320 484,730
>
> There is the oft repeated story that !Desk_Bogo favours VRPC, but
> Dhrystones indicate rpcemu is faster.
Indeed: that suspicion is supported by Chris Hall's benchmarks here
https://www.riscosopen.org/forum/forums/5/topics/466?page=8
where VRPC on a 2668MHz PC gives only 175% compared to a bog-standard
S/ARM RPC, i.e. 1524MHz = 100%; the corresponding figure for RPCEmu
here is approx. 1000MHz = 100%. Obviously that assumes a similar
processor type in the 2668MHz machine, which may not be the case.
>
> Raspberry Pi
> OS5.21 401 995,024
That's a very high dhrystone figure for a Pi: I got 450,080 when I
tested one recently.
>
> Emulators not too dusty then!
No indeed.
>
> Phoebe in hardware might have been a step forward but that might not
> apply to an emulation.
>
As Peter H has just explained.
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
David Pitt <pittdj@pittdj.co.uk> wrote:
> In message <6d9d959f53.George@tiscali..co.uk>
> george greenfield <george.greenfield@tiscali.co.uk> wrote:
>
>> In message <mpro.mv61td00381ke03n2.pittdj@pittdj.co.uk>
>> David Pitt <pittdj@pittdj.co.uk> wrote:
>
>>> Peter Howkins, on 23 Oct, wrote:
>>>
[Snip]
>
> I have just tried a brief test or two but they don't really tell us
> much. The tests are !Desk_Bogo and Dhrystones.
>
> bogomips dhrystones
>
> Ubuntu 12.04 on VMware on an iMac, rpcemu 0.8.11
> Phoebe OS3.80 Interpreter 41 98,396
> SA110 OS5.21 Recompiler 117 481,463
>
> This is not like for like, no surprises, the Recompiler is a lot
> faster.
>
> Mac OS X Mavericks, rpcemu 0.8.9
> SA110 OS5.21 Recompiler 159 627,746
ROMark scores c.610k dhrystone MIPs on my 0810/520 Recompiler
installation here, running on a Dell XPS 3.4GHz i7 Win7/64 platform.
>
> This is more interesting there is that much difference between the
> Virtual Machine and native installations.
>
> Mac OS X Mavericks, VRPC
> OS4.39 320 484,730
>
> There is the oft repeated story that !Desk_Bogo favours VRPC, but
> Dhrystones indicate rpcemu is faster.
Indeed: that suspicion is supported by Chris Hall's benchmarks here
https://www.riscosopen.org/forum/forums/5/topics/466?page=8
where VRPC on a 2668MHz PC gives only 175% compared to a bog-standard
S/ARM RPC, i.e. 1524MHz = 100%; the corresponding figure for RPCEmu
here is approx. 1000MHz = 100%. Obviously that assumes a similar
processor type in the 2668MHz machine, which may not be the case.
>
> Raspberry Pi
> OS5.21 401 995,024
That's a very high dhrystone figure for a Pi: I got 450,080 when I
tested one recently.
>
> Emulators not too dusty then!
No indeed.
>
> Phoebe in hardware might have been a step forward but that might not
> apply to an emulation.
>
As Peter H has just explained.
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.8.11
In message <6d9d959f53.George@tiscali..co.uk>
george greenfield <george.greenfield@tiscali.co.uk> wrote:
> In message <mpro.mv61td00381ke03n2.pittdj@pittdj.co.uk>
> David Pitt <pittdj@pittdj.co.uk> wrote:
>> Peter Howkins, on 23 Oct, wrote:
>>
>>> A new version of RPCEmu is available, 0.8.11
>>>
>>> http://www.marutan.net/rpcemu/
>>>
>>> * All Platforms
>>> - Support for emulating Phoebe, the Risc PC 2. Produced with the
>>> assistance of The Centre for Computing History.
>>>
>>> Instructions on how to setup Phoebe emulation and the required files
>>> are on the 4corn website.
>>>
>>> http://www.4corn.co.uk/articles/phoebe/
>>>
>>> Note, this is a prototype machine, so is more for historical interest
>>> than running production code.
>>
>>
>> Phoebe is running OK here in Ubuntu 12.04 LTS.
>>
>> An interesting turn up, many thanks.
>>
>>
> Indeed. What's it like compared to a standard StrongARM? Presumably
> running under RPCEmu-Interpreter rather than -Recompiler more than
> offsets any possible emulated architecture improvements. Have
> you/could you run any benchmarks (e.g. ROmark)?
I have just tried a brief test or two but they don't really tell us
much. The tests are !Desk_Bogo and Dhrystones.
bogomips dhrystones
Ubuntu 12.04 on VMware on an iMac, rpcemu 0.8.11
Phoebe OS3.80 Interpreter 41 98,396
SA110 OS5.21 Recompiler 117 481,463
This is not like for like, no surprises, the Recompiler is a lot
faster.
Mac OS X Mavericks, rpcemu 0.8.9
SA110 OS5.21 Recompiler 159 627,746
This is more interesting there is that much difference between the
Virtual Machine and native installations.
Mac OS X Mavericks, VRPC
OS4.39 320 484,730
There is the oft repeated story that !Desk_Bogo favours VRPC, but
Dhrystones indicate rpcemu is faster.
Raspberry Pi
OS5.21 401 995,024
Emulators not too dusty then!
Phoebe in hardware might have been a step forward but that might not
apply to an emulation.
--
David Pitt
iMac, VMware Fusion, Ubuntu, rpcemu v0.8.11, RISC OS 5.21
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
george greenfield <george.greenfield@tiscali.co.uk> wrote:
> In message <mpro.mv61td00381ke03n2.pittdj@pittdj.co.uk>
> David Pitt <pittdj@pittdj.co.uk> wrote:
>> Peter Howkins, on 23 Oct, wrote:
>>
>>> A new version of RPCEmu is available, 0.8.11
>>>
>>> http://www.marutan.net/rpcemu/
>>>
>>> * All Platforms
>>> - Support for emulating Phoebe, the Risc PC 2. Produced with the
>>> assistance of The Centre for Computing History.
>>>
>>> Instructions on how to setup Phoebe emulation and the required files
>>> are on the 4corn website.
>>>
>>> http://www.4corn.co.uk/articles/phoebe/
>>>
>>> Note, this is a prototype machine, so is more for historical interest
>>> than running production code.
>>
>>
>> Phoebe is running OK here in Ubuntu 12.04 LTS.
>>
>> An interesting turn up, many thanks.
>>
>>
> Indeed. What's it like compared to a standard StrongARM? Presumably
> running under RPCEmu-Interpreter rather than -Recompiler more than
> offsets any possible emulated architecture improvements. Have
> you/could you run any benchmarks (e.g. ROmark)?
I have just tried a brief test or two but they don't really tell us
much. The tests are !Desk_Bogo and Dhrystones.
bogomips dhrystones
Ubuntu 12.04 on VMware on an iMac, rpcemu 0.8.11
Phoebe OS3.80 Interpreter 41 98,396
SA110 OS5.21 Recompiler 117 481,463
This is not like for like, no surprises, the Recompiler is a lot
faster.
Mac OS X Mavericks, rpcemu 0.8.9
SA110 OS5.21 Recompiler 159 627,746
This is more interesting there is that much difference between the
Virtual Machine and native installations.
Mac OS X Mavericks, VRPC
OS4.39 320 484,730
There is the oft repeated story that !Desk_Bogo favours VRPC, but
Dhrystones indicate rpcemu is faster.
Raspberry Pi
OS5.21 401 995,024
Emulators not too dusty then!
Phoebe in hardware might have been a step forward but that might not
apply to an emulation.
--
David Pitt
iMac, VMware Fusion, Ubuntu, rpcemu v0.8.11, RISC OS 5.21
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] 26/10/2013 RPCEmu and the real Phoebe at the RISC OS London Show
This coming Saturday, RPCEmu will be having a stand at RISC OS London Show
http://www.riscoslondonshow.co.uk/
Come along and see all the latest improvements, chat about new features
and bother us with bug reports!
As a special treat, the Centre for Computing History have lent us the only
working Phoebe in the world, so you can compare the new RPCEmu with the
real machine and check we are bug for bug compatable :)
Matthew Howkins
Peter Howkins
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
http://www.riscoslondonshow.co.uk/
Come along and see all the latest improvements, chat about new features
and bother us with bug reports!
As a special treat, the Centre for Computing History have lent us the only
working Phoebe in the world, so you can compare the new RPCEmu with the
real machine and check we are bug for bug compatable :)
Matthew Howkins
Peter Howkins
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.8.11
On Thu, Oct 24, 2013 at 10:44:40AM +0100, george greenfield wrote:
>
> Indeed. What's it like compared to a standard StrongARM? Presumably
> running under RPCEmu-Interpreter rather than -Recompiler more than
> offsets any possible emulated architecture improvements. Have
> you/could you run any benchmarks (e.g. ROmark)?
Real Phoebe performance with ROMark is compared on this page,
http://www.stardot.org.uk/forums/viewtopic.php?f=16&t=6753
On the emulator however the speed will be pretty much the same as RPC1
(SA, arm 610, arm 710) running in interpreter mode. The speed of the
emulator isn't limited to the speed of the emulated hardware, it just goes
as fast as your computer will allow regardless of settings.
There are no significant changes to the architecture that have an impact
on emulated performance.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
>
> Indeed. What's it like compared to a standard StrongARM? Presumably
> running under RPCEmu-Interpreter rather than -Recompiler more than
> offsets any possible emulated architecture improvements. Have
> you/could you run any benchmarks (e.g. ROmark)?
Real Phoebe performance with ROMark is compared on this page,
http://www.stardot.org.uk/forums/viewtopic.php?f=16&t=6753
On the emulator however the speed will be pretty much the same as RPC1
(SA, arm 610, arm 710) running in interpreter mode. The speed of the
emulator isn't limited to the speed of the emulated hardware, it just goes
as fast as your computer will allow regardless of settings.
There are no significant changes to the architecture that have an impact
on emulated performance.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.8.11
In message <mpro.mv61td00381ke03n2.pittdj@pittdj.co.uk>
David Pitt <pittdj@pittdj.co.uk> wrote:
> Peter Howkins, on 23 Oct, wrote:
>
>> A new version of RPCEmu is available, 0.8.11
>>
>> http://www.marutan.net/rpcemu/
>>
>> * All Platforms
>> - Support for emulating Phoebe, the Risc PC 2. Produced with the
>> assistance of The Centre for Computing History.
>>
>> Instructions on how to setup Phoebe emulation and the required files
>> are on the 4corn website.
>>
>> http://www.4corn.co.uk/articles/phoebe/
>>
>> Note, this is a prototype machine, so is more for historical interest
>> than running production code.
>
>
> Phoebe is running OK here in Ubuntu 12.04 LTS.
>
> An interesting turn up, many thanks.
>
>
Indeed. What's it like compared to a standard StrongARM? Presumably
running under RPCEmu-Interpreter rather than -Recompiler more than
offsets any possible emulated architecture improvements. Have
you/could you run any benchmarks (e.g. ROmark)?
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
David Pitt <pittdj@pittdj.co.uk> wrote:
> Peter Howkins, on 23 Oct, wrote:
>
>> A new version of RPCEmu is available, 0.8.11
>>
>> http://www.marutan.net/rpcemu/
>>
>> * All Platforms
>> - Support for emulating Phoebe, the Risc PC 2. Produced with the
>> assistance of The Centre for Computing History.
>>
>> Instructions on how to setup Phoebe emulation and the required files
>> are on the 4corn website.
>>
>> http://www.4corn.co.uk/articles/phoebe/
>>
>> Note, this is a prototype machine, so is more for historical interest
>> than running production code.
>
>
> Phoebe is running OK here in Ubuntu 12.04 LTS.
>
> An interesting turn up, many thanks.
>
>
Indeed. What's it like compared to a standard StrongARM? Presumably
running under RPCEmu-Interpreter rather than -Recompiler more than
offsets any possible emulated architecture improvements. Have
you/could you run any benchmarks (e.g. ROmark)?
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.8.11
Peter Howkins, on 23 Oct, wrote:
> A new version of RPCEmu is available, 0.8.11
>
> http://www.marutan.net/rpcemu/
>
> * All Platforms
> - Support for emulating Phoebe, the Risc PC 2. Produced with the
> assistance of The Centre for Computing History.
>
> Instructions on how to setup Phoebe emulation and the required files
> are on the 4corn website.
>
> http://www.4corn.co.uk/articles/phoebe/
>
> Note, this is a prototype machine, so is more for historical interest
> than running production code.
Phoebe is running OK here in Ubuntu 12.04 LTS.
An interesting turn up, many thanks.
--
David Pitt
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> A new version of RPCEmu is available, 0.8.11
>
> http://www.marutan.net/rpcemu/
>
> * All Platforms
> - Support for emulating Phoebe, the Risc PC 2. Produced with the
> assistance of The Centre for Computing History.
>
> Instructions on how to setup Phoebe emulation and the required files
> are on the 4corn website.
>
> http://www.4corn.co.uk/articles/phoebe/
>
> Note, this is a prototype machine, so is more for historical interest
> than running production code.
Phoebe is running OK here in Ubuntu 12.04 LTS.
An interesting turn up, many thanks.
--
David Pitt
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Wednesday, 23 October 2013
[Rpcemu] RPCEmu 0.8.11
A new version of RPCEmu is available, 0.8.11
http://www.marutan.net/rpcemu/
* All Platforms
- Support for emulating Phoebe, the Risc PC 2. Produced with the
assistance of The Centre for Computing History.
Instructions on how to setup Phoebe emulation and the required files
are on the 4corn website.
http://www.4corn.co.uk/articles/phoebe/
Note, this is a prototype machine, so is more for historical interest
than running production code.
- Introduced the concept of configuring the Hardware Model rather than
using CPU type to determine hardware. See the Settings->Settings
window for details. You may need to reselect a model based on your
previous CPU choice.
- Fix very rare bug in which the MIPS count was sometimes wildly
incorrect.
* Windows
- Fix 'Follows Host Mouse' bug, where the host and emulated mouse
pointers were not lined up until the RPCEmu window had been moved.
- Fix network GUI bug where the selected networking type was not
correctly set.
Note: Using the windows install to upgrade from
previous versions may overwrite your cmos.ram
and rpc.cfg files.
Matthew Howkins
Peter Howkins
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
http://www.marutan.net/rpcemu/
* All Platforms
- Support for emulating Phoebe, the Risc PC 2. Produced with the
assistance of The Centre for Computing History.
Instructions on how to setup Phoebe emulation and the required files
are on the 4corn website.
http://www.4corn.co.uk/articles/phoebe/
Note, this is a prototype machine, so is more for historical interest
than running production code.
- Introduced the concept of configuring the Hardware Model rather than
using CPU type to determine hardware. See the Settings->Settings
window for details. You may need to reselect a model based on your
previous CPU choice.
- Fix very rare bug in which the MIPS count was sometimes wildly
incorrect.
* Windows
- Fix 'Follows Host Mouse' bug, where the host and emulated mouse
pointers were not lined up until the RPCEmu window had been moved.
- Fix network GUI bug where the selected networking type was not
correctly set.
Note: Using the windows install to upgrade from
previous versions may overwrite your cmos.ram
and rpc.cfg files.
Matthew Howkins
Peter Howkins
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: BBC website
On Wednesday 23 October 2013 20:37:03 Peter Young wrote:
> On 23 Oct 2013 Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
> > I noticed some of the headlines on the BBC website are over-written:
> >
> > http://www.bbc.co.uk/news/
> >
> > I am using today's daily Atari build.
>
> Looks fine in the RISC OS build, though that's not helpful to Peter!
The Atari Build 1381 seems OK to me, though it took 63 seconds to display the
page! Peter, is it as slow on your Milan?
Cheers,
JFL
--
Jean-François Lemaire
> On 23 Oct 2013 Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
> > I noticed some of the headlines on the BBC website are over-written:
> >
> > http://www.bbc.co.uk/news/
> >
> > I am using today's daily Atari build.
>
> Looks fine in the RISC OS build, though that's not helpful to Peter!
The Atari Build 1381 seems OK to me, though it took 63 seconds to display the
page! Peter, is it as slow on your Milan?
Cheers,
JFL
--
Jean-François Lemaire
Re: BBC website
On 23 Oct 2013 Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
> Hi all,
> I noticed some of the headlines on the BBC website are over-written:
> http://www.bbc.co.uk/news/
> I am using today's daily Atari build.
Looks fine in the RISC OS build, though that's not helpful to Peter!
With best wishes,
Another Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
> Hi all,
> I noticed some of the headlines on the BBC website are over-written:
> http://www.bbc.co.uk/news/
> I am using today's daily Atari build.
Looks fine in the RISC OS build, though that's not helpful to Peter!
With best wishes,
Another Peter.
--
Peter Young (zfc W) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
BBC website
Hi all,
I noticed some of the headlines on the BBC website are over-written:
http://www.bbc.co.uk/news/
I am using today's daily Atari build.
Regards,
Peter
I noticed some of the headlines on the BBC website are over-written:
http://www.bbc.co.uk/news/
I am using today's daily Atari build.
Regards,
Peter
Re: Amiga CI build fix >> Re: toolchains: branch chris/sdk-53-24 created.
On Tue, 22 Oct 2013 19:56:25 +0100, Chris Young wrote:
> Michael Drake <tlsa@netsurf-browser.org> wrote:
> >I did poke the CI to do a rebuild on Oct 13th, but it didn't seem to
> >pick
> >up any changes from the Git repo:
> >
> > http://ci.netsurf-browser.org/jenkins/job/toolchain-ppc-amigaos/16/
OK, I've merged it to master, can you give it another prod please? It
should find something new to do now.
Thanks
Chris
> Michael Drake <tlsa@netsurf-browser.org> wrote:
> >I did poke the CI to do a rebuild on Oct 13th, but it didn't seem to
> >pick
> >up any changes from the Git repo:
> >
> > http://ci.netsurf-browser.org/jenkins/job/toolchain-ppc-amigaos/16/
OK, I've merged it to master, can you give it another prod please? It
should find something new to do now.
Thanks
Chris
Tuesday, 22 October 2013
Amiga CI build fix >> Re: toolchains: branch chris/sdk-53-24 created.
*bump* Can somebody look at this please as I have no way of testing?
On 12 Oct 2013 10:34:38 +0000, Chris Young wrote:
> Hi
>
> > The branch, chris/sdk-53-24 has been created
> > at 39f4157a9c7dcb9ab514f70d45cee7e40d8745bc (commit)
>
> Please can somebody check the toolchain still builds with this change
> (still can't build it myself here), and then merge it in.
>
> Thanks
> Chris
>
On 12 Oct 2013 10:34:38 +0000, Chris Young wrote:
> Hi
>
> > The branch, chris/sdk-53-24 has been created
> > at 39f4157a9c7dcb9ab514f70d45cee7e40d8745bc (commit)
>
> Please can somebody check the toolchain still builds with this change
> (still can't build it myself here), and then merge it in.
>
> Thanks
> Chris
>
Re: Amiga CI build fix >> Re: toolchains: branch chris/sdk-53-24 created.
Michael Drake <tlsa@netsurf-browser.org> wrote:
>In article
><OUT-5266CECD.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
> Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
>> *bump* Can somebody look at this please as I have no way of testing?
>
>I did poke the CI to do a rebuild on Oct 13th, but it didn't seem to
>pick
>up any changes from the Git repo:
>
> http://ci.netsurf-browser.org/jenkins/job/toolchain-ppc-amigaos/16/
Hmm, does it only pick it up from master? So I need to commit it there regardless and then revert back if it doesn't work?
>In article
><OUT-5266CECD.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
> Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
>> *bump* Can somebody look at this please as I have no way of testing?
>
>I did poke the CI to do a rebuild on Oct 13th, but it didn't seem to
>pick
>up any changes from the Git repo:
>
> http://ci.netsurf-browser.org/jenkins/job/toolchain-ppc-amigaos/16/
Hmm, does it only pick it up from master? So I need to commit it there regardless and then revert back if it doesn't work?
Re: Amiga CI build fix >> Re: toolchains: branch chris/sdk-53-24 created.
In article
<OUT-5266CECD.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
> *bump* Can somebody look at this please as I have no way of testing?
I did poke the CI to do a rebuild on Oct 13th, but it didn't seem to pick
up any changes from the Git repo:
http://ci.netsurf-browser.org/jenkins/job/toolchain-ppc-amigaos/16/
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
<OUT-5266CECD.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
> *bump* Can somebody look at this please as I have no way of testing?
I did poke the CI to do a rebuild on Oct 13th, but it didn't seem to pick
up any changes from the Git repo:
http://ci.netsurf-browser.org/jenkins/job/toolchain-ppc-amigaos/16/
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Wednesday, 16 October 2013
1391 build and dancinggiraffe.com
Hi all
A friend is helping an organisation develop a web page at
http://v3.dancinggiraffe.com
(a test version of an update before it goes live at
www.dancinggiraffe.com apparently)
The small grey icon labelled "menu" doesn't do anything as it stands
on Netsurf.
I've found that commenting out the line:
<link rel='stylesheet' id='twentytwelve-style-css'
href='http://v3.dancinggiraffe.com/wp-content/themes/twentytwelve-child-dancingg
iraffe/style.css?ver=3.6.1' type='text/css' media='all' />
in the header section of the HTML source code renders the menu options
as a usable, bulleted list.
Is this a suspect Style sheet, or something Netsurf is not rendering
properly ?
thanks
--
Chris
A friend is helping an organisation develop a web page at
http://v3.dancinggiraffe.com
(a test version of an update before it goes live at
www.dancinggiraffe.com apparently)
The small grey icon labelled "menu" doesn't do anything as it stands
on Netsurf.
I've found that commenting out the line:
<link rel='stylesheet' id='twentytwelve-style-css'
href='http://v3.dancinggiraffe.com/wp-content/themes/twentytwelve-child-dancingg
iraffe/style.css?ver=3.6.1' type='text/css' media='all' />
in the header section of the HTML source code renders the menu options
as a usable, bulleted list.
Is this a suspect Style sheet, or something Netsurf is not rendering
properly ?
thanks
--
Chris
Re: Atari daily build 1391
On Tue, 15 Oct 2013 23:29:07 , Ole <ole@monochrom.net> wrote:
> Am Dienstag, den 15.10.2013, 23:23 +0200 schrieb Peter Slegg
> <p.slegg@scubadivers.co.uk>:
>
> > "CF-Lib Panic: get_string()! Objekt 60 hat unbekannten typ 20!"
>
>
> Did you also update the resource file? Anyway, the resource file is a
> bit odd right now, the
> throbber has white background, instead of transparent. I once used that
> for "debugging" something
> and forgot to remove it again. Anyway, AFAIK the resource file should
> work fine. So please make sure you unpacked it
> to the correct place.
>
> Greets,
> Ole
My apologies. I forgot that Netsurf reads the rsc from the res folder
in a slightly non-Atari way.
It's working fine now and the hotlist is working too. I am able to
create folders and drag-drop items in them.
Peter
> Am Dienstag, den 15.10.2013, 23:23 +0200 schrieb Peter Slegg
> <p.slegg@scubadivers.co.uk>:
>
> > "CF-Lib Panic: get_string()! Objekt 60 hat unbekannten typ 20!"
>
>
> Did you also update the resource file? Anyway, the resource file is a
> bit odd right now, the
> throbber has white background, instead of transparent. I once used that
> for "debugging" something
> and forgot to remove it again. Anyway, AFAIK the resource file should
> work fine. So please make sure you unpacked it
> to the correct place.
>
> Greets,
> Ole
My apologies. I forgot that Netsurf reads the rsc from the res folder
in a slightly non-Atari way.
It's working fine now and the hotlist is working too. I am able to
create folders and drag-drop items in them.
Peter
Re: [Rpcemu] HostFS and MPro
In message <cf64269b53.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 15 Oct 2013, David Pitt <pittdj@pittdj.co.uk> wrote:
>> Tony Moore, on 15 Oct, wrote:
>>
>> > Using Windows 7 32bit / RPCEmu 0.8.10 / RO 5.20 / MPro 7.06
Here Win7/64, RPCEmu 0.8.9/4.02, MPro 4.23.
[snip
>
>> (That said Messenger Pro is profoundly unstable on RPCEmu 0.8.9 on
>> this Mac, the networking crashes badly. I don't think it is due to
>> this issue though, there are other networking crashes. (0.8.9 is the
>> last build for the Mac.))
Networking is rock-solid here, though I find I need to connect within
a few minutes of the PC getting switched on: if RPCEmu fails to
connect in 3 tries, a reboot of the PC is the best solution. I suspect
the network bridge goes to sleep after a period of time if not
connected to. Once up and running, networking is absolutely reliable.
>
> I'm pleased to say that MPro running on RPCEmu 0.8.10 is stable, and
> reliable.
Ditto here on 0.8.9/4.02, albeit running from HD4, not HostFS. However
MPro 4.23 did have a debatching problem on 0.8.10/5.20 here: it would
freeze, requiring an Alt-Break: on restarting MPro the incoming mails
could be seen to have arrived. Outgoing emails behaved normally.
>> It might be worth running it by Rcomp as a similar issue on Fat32FS
>> discs got fixed.
>
> I suspect that the fix may have been to ignore the warning message.
I asked R-Comp if a more up-to-date version would cure my debatching
problem, but Andrew (perhaps understandably) would not commit himself
regarding behaviour on an unknown platform, pointing out that in
general newest versions were likely to be the most bug-free, and best
supported. As I've reverted to /4.02 for general use, and my current
version of MPro works, I haven't upgraded.
HTH, George
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 15 Oct 2013, David Pitt <pittdj@pittdj.co.uk> wrote:
>> Tony Moore, on 15 Oct, wrote:
>>
>> > Using Windows 7 32bit / RPCEmu 0.8.10 / RO 5.20 / MPro 7.06
Here Win7/64, RPCEmu 0.8.9/4.02, MPro 4.23.
[snip
>
>> (That said Messenger Pro is profoundly unstable on RPCEmu 0.8.9 on
>> this Mac, the networking crashes badly. I don't think it is due to
>> this issue though, there are other networking crashes. (0.8.9 is the
>> last build for the Mac.))
Networking is rock-solid here, though I find I need to connect within
a few minutes of the PC getting switched on: if RPCEmu fails to
connect in 3 tries, a reboot of the PC is the best solution. I suspect
the network bridge goes to sleep after a period of time if not
connected to. Once up and running, networking is absolutely reliable.
>
> I'm pleased to say that MPro running on RPCEmu 0.8.10 is stable, and
> reliable.
Ditto here on 0.8.9/4.02, albeit running from HD4, not HostFS. However
MPro 4.23 did have a debatching problem on 0.8.10/5.20 here: it would
freeze, requiring an Alt-Break: on restarting MPro the incoming mails
could be seen to have arrived. Outgoing emails behaved normally.
>> It might be worth running it by Rcomp as a similar issue on Fat32FS
>> discs got fixed.
>
> I suspect that the fix may have been to ignore the warning message.
I asked R-Comp if a more up-to-date version would cure my debatching
problem, but Andrew (perhaps understandably) would not commit himself
regarding behaviour on an unknown platform, pointing out that in
general newest versions were likely to be the most bug-free, and best
supported. As I've reverted to /4.02 for general use, and my current
version of MPro works, I haven't upgraded.
HTH, George
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Tuesday, 15 October 2013
Re: Atari daily build 1391
Am Dienstag, den 15.10.2013, 23:23 +0200 schrieb Peter Slegg
<p.slegg@scubadivers.co.uk>:
> "CF-Lib Panic: get_string()! Objekt 60 hat unbekannten typ 20!"
Did you also update the resource file? Anyway, the resource file is a
bit odd right now, the
throbber has white background, instead of transparent. I once used that
for "debugging" something
and forgot to remove it again. Anyway, AFAIK the resource file should
work fine. So please make sure you unpacked it
to the correct place.
Greets,
Ole
<p.slegg@scubadivers.co.uk>:
> "CF-Lib Panic: get_string()! Objekt 60 hat unbekannten typ 20!"
Did you also update the resource file? Anyway, the resource file is a
bit odd right now, the
throbber has white background, instead of transparent. I once used that
for "debugging" something
and forgot to remove it again. Anyway, AFAIK the resource file should
work fine. So please make sure you unpacked it
to the correct place.
Greets,
Ole
Atari daily build 1391
I just tried the Atari 1391 build and it fails at start-up with error:
"CF-Lib Panic: get_string()! Objekt 60 hat unbekannten typ 20!"
Regards,
Peter
"CF-Lib Panic: get_string()! Objekt 60 hat unbekannten typ 20!"
Regards,
Peter
Re: [Rpcemu] HostFS and MPro
On 15 Oct 2013, David Pitt <pittdj@pittdj.co.uk> wrote:
> Tony Moore, on 15 Oct, wrote:
>
> > Using Windows 7 32bit / RPCEmu 0.8.10 / RO 5.20 / MPro 7.06
> >
> > When MPro runs from HostFS, the log of a typical mail fetch is as
> > follows:
> >
> > 13 Oct 22:12:34 080 Messenger does not have enough free disc space
> >
> > The line concerning inadequate disc space suggests that HostFS does
> > not correctly report the value (20GB). However, MPro ignores the
> > warning and goes ahead to save the message, without problem.
> >
> > Can anyone please comment?
>
> As far as I can see the RPCEmu HostFS does not even know of the
> concept of free.
True, *free leads to "File 'free' not found", moreover the HostFS
iconbar has no menu, which could otherwise lead to 'Free space'..
> HostFS on VRPC does.
>
> I would be reasonably certain the error is spurious, nothing actually
> breaks.
MPro seems to ignore the message, and carries on regardless. My query
arises from a thread, on the MPro mailing list, which is concerned with
identifying the possible causes of delays in debatching, experienced on
someone else's Iyonix. I had not previouly looked at MPro's log, and was
surprised to see the warning message.
> (That said Messenger Pro is profoundly unstable on RPCEmu 0.8.9 on
> this Mac, the networking crashes badly. I don't think it is due to
> this issue though, there are other networking crashes. (0.8.9 is the
> last build for the Mac.))
I'm pleased to say that MPro running on RPCEmu 0.8.10 is stable, and
reliable.
> It might be worth running it by Rcomp as a similar issue on Fat32FS
> discs got fixed.
I suspect that the fix may have been to ignore the warning message.
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Tony Moore, on 15 Oct, wrote:
>
> > Using Windows 7 32bit / RPCEmu 0.8.10 / RO 5.20 / MPro 7.06
> >
> > When MPro runs from HostFS, the log of a typical mail fetch is as
> > follows:
> >
> > 13 Oct 22:12:34 080 Messenger does not have enough free disc space
> >
> > The line concerning inadequate disc space suggests that HostFS does
> > not correctly report the value (20GB). However, MPro ignores the
> > warning and goes ahead to save the message, without problem.
> >
> > Can anyone please comment?
>
> As far as I can see the RPCEmu HostFS does not even know of the
> concept of free.
True, *free leads to "File 'free' not found", moreover the HostFS
iconbar has no menu, which could otherwise lead to 'Free space'..
> HostFS on VRPC does.
>
> I would be reasonably certain the error is spurious, nothing actually
> breaks.
MPro seems to ignore the message, and carries on regardless. My query
arises from a thread, on the MPro mailing list, which is concerned with
identifying the possible causes of delays in debatching, experienced on
someone else's Iyonix. I had not previouly looked at MPro's log, and was
surprised to see the warning message.
> (That said Messenger Pro is profoundly unstable on RPCEmu 0.8.9 on
> this Mac, the networking crashes badly. I don't think it is due to
> this issue though, there are other networking crashes. (0.8.9 is the
> last build for the Mac.))
I'm pleased to say that MPro running on RPCEmu 0.8.10 is stable, and
reliable.
> It might be worth running it by Rcomp as a similar issue on Fat32FS
> discs got fixed.
I suspect that the fix may have been to ignore the warning message.
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] HostFS and MPro
Tony Moore, on 15 Oct, wrote:
> Using Windows 7 32bit / RPCEmu 0.8.10 / RO 5.20 / MPro 7.06
>
> When MPro runs from HostFS, the log of a typical mail fetch is as follows:
>
> 13 Oct 22:12:34 080 Messenger does not have enough free disc space
>
> The line concerning inadequate disc space suggests that HostFS does not
> correctly report the value (20GB). However, MPro ignores the warning and
> goes ahead to save the message, without problem.
>
> Can anyone please comment?
As far as I can see the RPCEmu HostFS does not even know of the concept of
free. HostFS on VRPC does.
I would be reasonably certain the error is spurious, nothing actually
breaks. (That said Messenger Pro is profoundly unstable on RPCEmu 0.8.9 on
this Mac, the networking crashes badly. I don't think it is due to this
issue though, there are other networking crashes. (0.8.9 is the last build
for the Mac.))
It might be worth running it by Rcomp as a similar issue on Fat32FS discs
got fixed.
--
David Pitt
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Using Windows 7 32bit / RPCEmu 0.8.10 / RO 5.20 / MPro 7.06
>
> When MPro runs from HostFS, the log of a typical mail fetch is as follows:
>
> 13 Oct 22:12:34 080 Messenger does not have enough free disc space
>
> The line concerning inadequate disc space suggests that HostFS does not
> correctly report the value (20GB). However, MPro ignores the warning and
> goes ahead to save the message, without problem.
>
> Can anyone please comment?
As far as I can see the RPCEmu HostFS does not even know of the concept of
free. HostFS on VRPC does.
I would be reasonably certain the error is spurious, nothing actually
breaks. (That said Messenger Pro is profoundly unstable on RPCEmu 0.8.9 on
this Mac, the networking crashes badly. I don't think it is due to this
issue though, there are other networking crashes. (0.8.9 is the last build
for the Mac.))
It might be worth running it by Rcomp as a similar issue on Fat32FS discs
got fixed.
--
David Pitt
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] HostFS and MPro
Using Windows 7 32bit / RPCEmu 0.8.10 / RO 5.20 / MPro 7.06
When MPro runs from HostFS, the log of a typical mail fetch is as
follows:
13 Oct 22:12:34 150 Checking for new arrivals...
13 Oct 22:12:34 150 Found batch file '<Hermes$MailDir>.mailin.spool.old_coaster'
13 Oct 22:12:34 140 Debug store to 'NewsDir:MsgServe.Backup.Mail.old_coaster.539a2fe4'
13 Oct 22:12:34 120 Debatching file 'NewsDir:MsgServe.Backup.Mail.old_coaster.539a2fe4'
13 Oct 22:12:34 090 Storing message old_coaster/Incoming mail:8545
13 Oct 22:12:34 080 Messenger does not have enough free disc space
13 Oct 22:12:38 140 Running transport command 'MsgServe:Transports.NewsHound.postnews'
13 Oct 22:12:39 150 Transport command completed successfully
13 Oct 22:12:41 150 Checking for new arrivals...
The line concerning inadequate disc space suggests that HostFS does not
correctly report the value (20GB). However, MPro ignores the warning and
goes ahead to save the message, without problem.
Can anyone please comment?
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
When MPro runs from HostFS, the log of a typical mail fetch is as
follows:
13 Oct 22:12:34 150 Checking for new arrivals...
13 Oct 22:12:34 150 Found batch file '<Hermes$MailDir>.mailin.spool.old_coaster'
13 Oct 22:12:34 140 Debug store to 'NewsDir:MsgServe.Backup.Mail.old_coaster.539a2fe4'
13 Oct 22:12:34 120 Debatching file 'NewsDir:MsgServe.Backup.Mail.old_coaster.539a2fe4'
13 Oct 22:12:34 090 Storing message old_coaster/Incoming mail:8545
13 Oct 22:12:34 080 Messenger does not have enough free disc space
13 Oct 22:12:38 140 Running transport command 'MsgServe:Transports.NewsHound.postnews'
13 Oct 22:12:39 150 Transport command completed successfully
13 Oct 22:12:41 150 Checking for new arrivals...
The line concerning inadequate disc space suggests that HostFS does not
correctly report the value (20GB). However, MPro ignores the warning and
goes ahead to save the message, without problem.
Can anyone please comment?
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Possible AcornURI load bug
On Mon, 14 October, 2013 6:42 pm, Malcolm Amir Hussain-Gambles wrote:
> I've developed !NewsUK that loads the BBC rss feed.
> When you click on a news item it opens a URL using AcornURI.
>
> However I noticed that it randomly works and more often than not it
> just opened a browser.
> After digging into this I found there were two mechanisms I was using,
> one if Netsurf wasn't running, and another if it was.
>
> When Netsurf runs it does an rmload on AcornURI, this is strangely
> enough wrong from what I have found.
>
> According to the documentation AcornURI has to be run using Filer_Run,
> otherwise it doesn't start all of the components necessary (some wimp
> task apparently), and URI_Dispatch doesn't work.
>
> The !Run file in netsurf should use Filer_Run rather than RMLOAD.
> I modified my !Run to do the following, which means it always "works
> for me" TM
>
> RMENSURE AcornURI 0.12 IfThere System:Modules.Network.URI Then
> Filer_Run System:Modules.Network.URI
>
> Not sure if I've got that correct or not, it does seem bizarre to not
> rmload a module though!
>
> Cheers,
>
> Malcolm
>
Cross-posted to dev list
--
Regards,
Dave Lawton
HTML emails are just a security risk, and nobody needs that.
> I've developed !NewsUK that loads the BBC rss feed.
> When you click on a news item it opens a URL using AcornURI.
>
> However I noticed that it randomly works and more often than not it
> just opened a browser.
> After digging into this I found there were two mechanisms I was using,
> one if Netsurf wasn't running, and another if it was.
>
> When Netsurf runs it does an rmload on AcornURI, this is strangely
> enough wrong from what I have found.
>
> According to the documentation AcornURI has to be run using Filer_Run,
> otherwise it doesn't start all of the components necessary (some wimp
> task apparently), and URI_Dispatch doesn't work.
>
> The !Run file in netsurf should use Filer_Run rather than RMLOAD.
> I modified my !Run to do the following, which means it always "works
> for me" TM
>
> RMENSURE AcornURI 0.12 IfThere System:Modules.Network.URI Then
> Filer_Run System:Modules.Network.URI
>
> Not sure if I've got that correct or not, it does seem bizarre to not
> rmload a module though!
>
> Cheers,
>
> Malcolm
>
Cross-posted to dev list
--
Regards,
Dave Lawton
HTML emails are just a security risk, and nobody needs that.
Monday, 14 October 2013
Re: [Rpcemu] Windows Junction Point to a CD
On 14 Oct 2013, "Gerald GF" <gf@fittons.me.uk> wrote:
> At the Windows command prompt I use MKLINK /J / <full path to a
> 'link-name' (e.g. CD) within the HostFS folder> D:\
>
> What this does is to insert into HostFS a link called 'link-name'
> (e.g. CD) which can be clicked on from within RPCEmu. When you click
> on this link you see the contents of the CD.
Link Shell Extension saves much tricky typing
http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> At the Windows command prompt I use MKLINK /J / <full path to a
> 'link-name' (e.g. CD) within the HostFS folder> D:\
>
> What this does is to insert into HostFS a link called 'link-name'
> (e.g. CD) which can be clicked on from within RPCEmu. When you click
> on this link you see the contents of the CD.
Link Shell Extension saves much tricky typing
http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Possible AcornURI load bug
I've developed !NewsUK that loads the BBC rss feed.
When you click on a news item it opens a URL using AcornURI.
However I noticed that it randomly works and more often than not it
just opened a browser.
After digging into this I found there were two mechanisms I was using,
one if Netsurf wasn't running, and another if it was.
When Netsurf runs it does an rmload on AcornURI, this is strangely
enough wrong from what I have found.
According to the documentation AcornURI has to be run using Filer_Run,
otherwise it doesn't start all of the components necessary (some wimp
task apparently), and URI_Dispatch doesn't work.
The !Run file in netsurf should use Filer_Run rather than RMLOAD.
I modified my !Run to do the following, which means it always "works
for me" TM
RMENSURE AcornURI 0.12 IfThere System:Modules.Network.URI Then
Filer_Run System:Modules.Network.URI
Not sure if I've got that correct or not, it does seem bizarre to not
rmload a module though!
Cheers,
Malcolm
When you click on a news item it opens a URL using AcornURI.
However I noticed that it randomly works and more often than not it
just opened a browser.
After digging into this I found there were two mechanisms I was using,
one if Netsurf wasn't running, and another if it was.
When Netsurf runs it does an rmload on AcornURI, this is strangely
enough wrong from what I have found.
According to the documentation AcornURI has to be run using Filer_Run,
otherwise it doesn't start all of the components necessary (some wimp
task apparently), and URI_Dispatch doesn't work.
The !Run file in netsurf should use Filer_Run rather than RMLOAD.
I modified my !Run to do the following, which means it always "works
for me" TM
RMENSURE AcornURI 0.12 IfThere System:Modules.Network.URI Then
Filer_Run System:Modules.Network.URI
Not sure if I've got that correct or not, it does seem bizarre to not
rmload a module though!
Cheers,
Malcolm
[Rpcemu] Windows Junction Point to a CD
At the Windows command prompt I use MKLINK /J / <full path to a 'link-name' (e.g. CD) within the HostFS folder> D:\
What this does is to insert into HostFS a link called 'link-name' (e.g. CD) which can be clicked on from within RPCEmu. When you click on this link you see the contents of the CD.
I previously used Red Squirrel so I have created a link called RSS (Red Squirrel Sharing). When I double click on this link I see all the content of the Sharing folder which is within Red Squirrel.
Gerald
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
What this does is to insert into HostFS a link called 'link-name' (e.g. CD) which can be clicked on from within RPCEmu. When you click on this link you see the contents of the CD.
I previously used Red Squirrel so I have created a link called RSS (Red Squirrel Sharing). When I double click on this link I see all the content of the Sharing folder which is within Red Squirrel.
Gerald
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Sunday, 13 October 2013
Saturday, 12 October 2013
Re: toolchains: branch chris/sdk-53-24 created. 39f4157a9c7dcb9ab514f70d45cee7e40d8745bc
Hi
> The branch, chris/sdk-53-24 has been created
> at 39f4157a9c7dcb9ab514f70d45cee7e40d8745bc (commit)
Please can somebody check the toolchain still builds with this change
(still can't build it myself here), and then merge it in.
Thanks
Chris
> The branch, chris/sdk-53-24 has been created
> at 39f4157a9c7dcb9ab514f70d45cee7e40d8745bc (commit)
Please can somebody check the toolchain still builds with this change
(still can't build it myself here), and then merge it in.
Thanks
Chris
Wednesday, 9 October 2013
Re: Atari Treeviews
Am Mi, 9.10.2013, 21:19 schrieb Jean-François Lemaire:
> Seems good so far and looking better overall. Good work! I wonder though
> why I
> have black or white background to what should be images with transparent
> backgrounds (e.g. atari-forum.com). Is this an issue specific to the Atari
> build?
Yes, I'm sorry. This was fixed with a recent commit. The configuration
dialog was buggy.
Once you saved the choices, it saved the transparency setting, but handled it
as bool, instead of int. So when you look into your Choices file, you
will see an very large value for atari_transparency. Set it back to 1, and
everything should be fine again.
(The bug should be fixed, so clicking save inside the configuration dialog
shouldn't write wrong value anymore.)
Greets,
Ole
> Seems good so far and looking better overall. Good work! I wonder though
> why I
> have black or white background to what should be images with transparent
> backgrounds (e.g. atari-forum.com). Is this an issue specific to the Atari
> build?
Yes, I'm sorry. This was fixed with a recent commit. The configuration
dialog was buggy.
Once you saved the choices, it saved the transparency setting, but handled it
as bool, instead of int. So when you look into your Choices file, you
will see an very large value for atari_transparency. Set it back to 1, and
everything should be fine again.
(The bug should be fixed, so clicking save inside the configuration dialog
shouldn't write wrong value anymore.)
Greets,
Ole
Re: Atari Treeviews
> The next autobuild should build with the new TreeView API. This means some
> changes to the Treeviews, and maybe some features have been improved, some
> maybe not. I also implemented the missing Treeview Windows: Cookies and
> SSL Cert Info.
Seems good so far and looking better overall. Good work! I wonder though why I
have black or white background to what should be images with transparent
backgrounds (e.g. atari-forum.com). Is this an issue specific to the Atari
build?
Cheers,
JFL
--
Jean-François Lemaire
> changes to the Treeviews, and maybe some features have been improved, some
> maybe not. I also implemented the missing Treeview Windows: Cookies and
> SSL Cert Info.
Seems good so far and looking better overall. Good work! I wonder though why I
have black or white background to what should be images with transparent
backgrounds (e.g. atari-forum.com). Is this an issue specific to the Atari
build?
Cheers,
JFL
--
Jean-François Lemaire
Tuesday, 8 October 2013
Re: Daily build 1374 - crash on Yahoo
In article <0033b38d.01dc65003b98@smtp.freeola.net>,
Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
> I noticed that it does seem to depend on which Yahoo sign-in page is
> used.
I've not been able to reproduce this. Please give the URL of the sign-in
page that leads to a problem, and the exact steps to reproduce it.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
> I noticed that it does seem to depend on which Yahoo sign-in page is
> used.
I've not been able to reproduce this. Please give the URL of the sign-in
page that leads to a problem, and the exact steps to reproduce it.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Monday, 7 October 2013
patch: Toolchains SDK / Do not generate OpenSSL Docs
diff --git a/sdk/Makefile b/sdk/Makefile
index f130088..d37288f 100644
--- a/sdk/Makefile
+++ b/sdk/Makefile
@@ -347,7 +347,7 @@ ifneq ($(realpath $(RECIPES)/patches/openssl/$(TARGET)),)
for p in `ls $(RECIPES)/patches/openssl/$(TARGET)/*.p` ; do patch -d $(BUILDDIR)/openssl/openssl-$(VERSION_OPENSSL) -p0 <$$p ; done
endif
cd $(BUILDDIR)/openssl/openssl-$(VERSION_OPENSSL) && $(env) ./Configure --prefix=$(GCCSDK_INSTALL_ENV) $(TARGET) no-shared no-asm no-threads
- cd $(BUILDDIR)/openssl/openssl-$(VERSION_OPENSSL) && $(env) make install
+ cd $(BUILDDIR)/openssl/openssl-$(VERSION_OPENSSL) && $(env) make install DIRS="crypto ssl engines apps"
touch $@
$(BUILDSTEPS)/openssl-src.d: $(BUILDSTEPS)/sourcedir.d $(SOURCEDIR)/openssl-$(VERSION_OPENSSL).tar.gz
Hello there,
I thought this patch is maybe worth to be added to sdk buildfiles. It
set's the specific Directories
to be recognized during OpenSSL Installation, and it omits the docs
directory. This results in a faster
install of OpenSSL (AFAIK the documentation takes a good chunk of time
compared to the whole build process).
Greets,
Ole
index f130088..d37288f 100644
--- a/sdk/Makefile
+++ b/sdk/Makefile
@@ -347,7 +347,7 @@ ifneq ($(realpath $(RECIPES)/patches/openssl/$(TARGET)),)
for p in `ls $(RECIPES)/patches/openssl/$(TARGET)/*.p` ; do patch -d $(BUILDDIR)/openssl/openssl-$(VERSION_OPENSSL) -p0 <$$p ; done
endif
cd $(BUILDDIR)/openssl/openssl-$(VERSION_OPENSSL) && $(env) ./Configure --prefix=$(GCCSDK_INSTALL_ENV) $(TARGET) no-shared no-asm no-threads
- cd $(BUILDDIR)/openssl/openssl-$(VERSION_OPENSSL) && $(env) make install
+ cd $(BUILDDIR)/openssl/openssl-$(VERSION_OPENSSL) && $(env) make install DIRS="crypto ssl engines apps"
touch $@
$(BUILDSTEPS)/openssl-src.d: $(BUILDSTEPS)/sourcedir.d $(SOURCEDIR)/openssl-$(VERSION_OPENSSL).tar.gz
Hello there,
I thought this patch is maybe worth to be added to sdk buildfiles. It
set's the specific Directories
to be recognized during OpenSSL Installation, and it omits the docs
directory. This results in a faster
install of OpenSSL (AFAIK the documentation takes a good chunk of time
compared to the whole build process).
Greets,
Ole
Re: [gccsdk] -lOSLlib and -static no go
In message <9cbb089753.Jo@hobbes.bass-software.com>
John Tytgat <John.Tytgat@aaug.net> wrote:
> In message <c01b3c9653.beeb@ron1954.woosh.co.nz>
> Ron <beeb@woosh.co.nz> wrote:
>
> > I think my installation of oslib is OK, I used the softfloat GCC version
> > from the sourceforge site.
>
> Sourceforge site ? Not riscos.info ?
Oh I misread, forget these questions.
John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net
_______________________________________________
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
John Tytgat <John.Tytgat@aaug.net> wrote:
> In message <c01b3c9653.beeb@ron1954.woosh.co.nz>
> Ron <beeb@woosh.co.nz> wrote:
>
> > I think my installation of oslib is OK, I used the softfloat GCC version
> > from the sourceforge site.
>
> Sourceforge site ? Not riscos.info ?
Oh I misread, forget these questions.
John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Porting asasm
In message <op.w4ggmfkcl0n5eg@amoe.local>
"Ben Avison" <bavison@riscosopen.org> wrote:
> On Tue, 30 Apr 2013 23:55:50 +0100, John Tytgat <John.Tytgat@aaug.net> wrote:
> >> ! 0, :STR::CC_ENCODING:"AL"
> >>
> >> should output "E0000000", but outputs "0000000E" instead.
> >
> > Interesting, that's not what I've understood from ARM's assembler manuals
> > but rereading its description I see that's it was not so well specified.
> > Fixed with r6390.
>
> I've just built a new copy of asasm from SVN, and consequently only just
> noticed there's a problem with this fix. Now it's outputting "0E000000" -
> there's a 24 in the sources that should have been a 28. This was masked
> in the project I was using it in by an unrelated bug that meant that the
> code was never being executed, but actually it was causing my macro to
> assemble an undefined instruction. Oh dear...
Oh dear indeed ;-( Apologies for that. Fixed with r6504.
John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net
_______________________________________________
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
"Ben Avison" <bavison@riscosopen.org> wrote:
> On Tue, 30 Apr 2013 23:55:50 +0100, John Tytgat <John.Tytgat@aaug.net> wrote:
> >> ! 0, :STR::CC_ENCODING:"AL"
> >>
> >> should output "E0000000", but outputs "0000000E" instead.
> >
> > Interesting, that's not what I've understood from ARM's assembler manuals
> > but rereading its description I see that's it was not so well specified.
> > Fixed with r6390.
>
> I've just built a new copy of asasm from SVN, and consequently only just
> noticed there's a problem with this fix. Now it's outputting "0E000000" -
> there's a 24 in the sources that should have been a 28. This was masked
> in the project I was using it in by an unrelated bug that meant that the
> code was never being executed, but actually it was causing my macro to
> assemble an undefined instruction. Oh dear...
Oh dear indeed ;-( Apologies for that. Fixed with r6504.
John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] -lOSLlib and -static no go
In message <c01b3c9653.beeb@ron1954.woosh.co.nz>
Ron <beeb@woosh.co.nz> wrote:
> I think my installation of oslib is OK, I used the softfloat GCC version
> from the sourceforge site.
Sourceforge site ? Not riscos.info ?
John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net
_______________________________________________
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
Ron <beeb@woosh.co.nz> wrote:
> I think my installation of oslib is OK, I used the softfloat GCC version
> from the sourceforge site.
Sourceforge site ? Not riscos.info ?
John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] -lOSLlib and -static no go
In message <DUB120-DS14EFBDA43CCA2A66EDD32BF0130@phx.gbl>
"Alan Buckley" <alan_baa@hotmail.com> wrote:
> Ron wrote on Sent: Monday, Oct 07, 2013 1:32 AM:
>
> > I now think that putting a lib such as libOSLib.a in SharedLibs is only
> > appropriate if nonstatic output is required. A better place for added
> > libraries seems to be in !GCC.arm-unknown-riscos.lib and then there is
> > no need for -LOSLib: and setvars at all.
> > A nice touch would be to have a !StaticLibs app (Sprite etc) inside
> > !GCC that simply filer_open 's the dir so there is no future confusion
> > to placement and as a reminder to take them forward when renewing !GCC.
> > I think this was the attraction to use !SharedLibs in the first place,
> > (one familiar place for libraries)
>
> > Libraries are also found in !GCC.libs, but on the same level,
> > !GCC.include is no good for finding oslib/xxx.h so I'm going with
> > !GCC.arm_unknown_riscos.
> > By putting the oslib directory of h/HDR's in
> > !GCC.arm-unknown-riscos.include
> > They are found either with <oslib/xx.h> or "oslib/xx.h" and once again,
> > no setvars required. Some oslib .h files reference other oslib files
> > with "oslib/xxh" so it is necessary for that form to work also, but
> > there wont be an error from using <oslib/xx.h> either so its a win win.
>
> > I'm not saying that the packaged method for installing oslib wont work,
> > I just think what I have described will be simpler across the board
> > and there is less to do/go wrong in the Makefile or gcc commands.
>
> > Cheers Ron M.
>
> The problem with OSLib is that there are several versions for
> different compile options (e.g. module, soft-float etc) and it
> is set up with them all having the same name so the correct
> one does currently need to be selected with an Obey file as
> you can't copy them all into the same directory.
>
> Although I could be convinced otherwise, I do like the way
> RISC OS libraries are set up much like applications with
> the include, library and documentation in the same
> place. I've never found it too much of a problem to ensure
> they are booted, but I can see how that is an extra step.
> One thing about using application directories I have found
> useful is being able to double-click on them so I can select
> a particular version.
>
I see your point,and the setvars/path would allow each version
to be in an identifying directory.
An initially more complex way would be for an app or !confix
frontend to rename the required directory so it is found.
Each oslib directory would have an obey file that could be
run to reverse the process, giving it back an identifying
name.
The dot a files would need a copy with force from their
extended identifying name., As they are not in a directory
and I dont think gcc recurses down a lib directory.
One plus for renaming would be that once configured they
would be solidly in place and stay correct from any entry
point to gcc and after rebooting.
The Obey/setrvars method could use Choices: for permanence as
an alternative as long as it is run each time.
Personally I have more than enough to do just learning to
put oslib to use, without worrying about hardfloat.
Cheers Ron M.
_______________________________________________
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
"Alan Buckley" <alan_baa@hotmail.com> wrote:
> Ron wrote on Sent: Monday, Oct 07, 2013 1:32 AM:
>
> > I now think that putting a lib such as libOSLib.a in SharedLibs is only
> > appropriate if nonstatic output is required. A better place for added
> > libraries seems to be in !GCC.arm-unknown-riscos.lib and then there is
> > no need for -LOSLib: and setvars at all.
> > A nice touch would be to have a !StaticLibs app (Sprite etc) inside
> > !GCC that simply filer_open 's the dir so there is no future confusion
> > to placement and as a reminder to take them forward when renewing !GCC.
> > I think this was the attraction to use !SharedLibs in the first place,
> > (one familiar place for libraries)
>
> > Libraries are also found in !GCC.libs, but on the same level,
> > !GCC.include is no good for finding oslib/xxx.h so I'm going with
> > !GCC.arm_unknown_riscos.
> > By putting the oslib directory of h/HDR's in
> > !GCC.arm-unknown-riscos.include
> > They are found either with <oslib/xx.h> or "oslib/xx.h" and once again,
> > no setvars required. Some oslib .h files reference other oslib files
> > with "oslib/xxh" so it is necessary for that form to work also, but
> > there wont be an error from using <oslib/xx.h> either so its a win win.
>
> > I'm not saying that the packaged method for installing oslib wont work,
> > I just think what I have described will be simpler across the board
> > and there is less to do/go wrong in the Makefile or gcc commands.
>
> > Cheers Ron M.
>
> The problem with OSLib is that there are several versions for
> different compile options (e.g. module, soft-float etc) and it
> is set up with them all having the same name so the correct
> one does currently need to be selected with an Obey file as
> you can't copy them all into the same directory.
>
> Although I could be convinced otherwise, I do like the way
> RISC OS libraries are set up much like applications with
> the include, library and documentation in the same
> place. I've never found it too much of a problem to ensure
> they are booted, but I can see how that is an extra step.
> One thing about using application directories I have found
> useful is being able to double-click on them so I can select
> a particular version.
>
I see your point,and the setvars/path would allow each version
to be in an identifying directory.
An initially more complex way would be for an app or !confix
frontend to rename the required directory so it is found.
Each oslib directory would have an obey file that could be
run to reverse the process, giving it back an identifying
name.
The dot a files would need a copy with force from their
extended identifying name., As they are not in a directory
and I dont think gcc recurses down a lib directory.
One plus for renaming would be that once configured they
would be solidly in place and stay correct from any entry
point to gcc and after rebooting.
The Obey/setrvars method could use Choices: for permanence as
an alternative as long as it is run each time.
Personally I have more than enough to do just learning to
put oslib to use, without worrying about hardfloat.
Cheers Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] -lOSLlib and -static no go
Ron wrote on Sent: Monday, Oct 07, 2013 1:32 AM:
> I now think that putting a lib such as libOSLib.a in SharedLibs is only
> appropriate if nonstatic output is required. A better place for added
> libraries seems to be in !GCC.arm-unknown-riscos.lib and then there is
> no need for -LOSLib: and setvars at all.
> A nice touch would be to have a !StaticLibs app (Sprite etc) inside
> !GCC that simply filer_open 's the dir so there is no future confusion
> to placement and as a reminder to take them forward when renewing !GCC.
> I think this was the attraction to use !SharedLibs in the first place,
> (one familiar place for libraries)
> Libraries are also found in !GCC.libs, but on the same level,
> !GCC.include is no good for finding oslib/xxx.h so I'm going with
> !GCC.arm_unknown_riscos.
> By putting the oslib directory of h/HDR's in
> !GCC.arm-unknown-riscos.include
> They are found either with <oslib/xx.h> or "oslib/xx.h" and once again,
> no setvars required. Some oslib .h files reference other oslib files
> with "oslib/xxh" so it is necessary for that form to work also, but
> there wont be an error from using <oslib/xx.h> either so its a win win.
> I'm not saying that the packaged method for installing oslib wont work,
> I just think what I have described will be simpler across the board
> and there is less to do/go wrong in the Makefile or gcc commands.
> Cheers Ron M.
The problem with OSLib is that there are several versions for
different compile options (e.g. module, soft-float etc) and it
is set up with them all having the same name so the correct
one does currently need to be selected with an Obey file as
you can't copy them all into the same directory.
Although I could be convinced otherwise, I do like the way
RISC OS libraries are set up much like applications with
the include, library and documentation in the same
place. I've never found it too much of a problem to ensure
they are booted, but I can see how that is an extra step.
One thing about using application directories I have found
useful is being able to double-click on them so I can select
a particular version.
Regards,
Alan
(Sorry Ron I posted it just to you instead of the list by
mistake first time).
_______________________________________________
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 now think that putting a lib such as libOSLib.a in SharedLibs is only
> appropriate if nonstatic output is required. A better place for added
> libraries seems to be in !GCC.arm-unknown-riscos.lib and then there is
> no need for -LOSLib: and setvars at all.
> A nice touch would be to have a !StaticLibs app (Sprite etc) inside
> !GCC that simply filer_open 's the dir so there is no future confusion
> to placement and as a reminder to take them forward when renewing !GCC.
> I think this was the attraction to use !SharedLibs in the first place,
> (one familiar place for libraries)
> Libraries are also found in !GCC.libs, but on the same level,
> !GCC.include is no good for finding oslib/xxx.h so I'm going with
> !GCC.arm_unknown_riscos.
> By putting the oslib directory of h/HDR's in
> !GCC.arm-unknown-riscos.include
> They are found either with <oslib/xx.h> or "oslib/xx.h" and once again,
> no setvars required. Some oslib .h files reference other oslib files
> with "oslib/xxh" so it is necessary for that form to work also, but
> there wont be an error from using <oslib/xx.h> either so its a win win.
> I'm not saying that the packaged method for installing oslib wont work,
> I just think what I have described will be simpler across the board
> and there is less to do/go wrong in the Makefile or gcc commands.
> Cheers Ron M.
The problem with OSLib is that there are several versions for
different compile options (e.g. module, soft-float etc) and it
is set up with them all having the same name so the correct
one does currently need to be selected with an Obey file as
you can't copy them all into the same directory.
Although I could be convinced otherwise, I do like the way
RISC OS libraries are set up much like applications with
the include, library and documentation in the same
place. I've never found it too much of a problem to ensure
they are booted, but I can see how that is an extra step.
One thing about using application directories I have found
useful is being able to double-click on them so I can select
a particular version.
Regards,
Alan
(Sorry Ron I posted it just to you instead of the list by
mistake first time).
_______________________________________________
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
Sunday, 6 October 2013
Re: [gccsdk] -lOSLlib and -static no go
In message <6f27929653.beeb@ron1954.woosh.co.nz>
Ron <beeb@woosh.co.nz> wrote:
> Just using plain libOSLib32.a in the command worked fine with a copy
> in the source (CSD) directory, so I new it /would/ work once it could
> be found.
> I followed up the use of -LOSLib:, and found that I had previously
> put the supplied OSLib setvars commands in my !GCC.!Run.
>
> Once I changed the path to
> Set OSLib$Path <SharedLibs$Dir>.lib.
> now
> -LOSLib: -lOSLib32
> works fine with -static
> Yes, -LOSLib: /is/ needed when static linking, I was lazely thinking
> that because non-static was finding the lib then all was well.
> I also started off thinking native gcc defaulted to -static so
> was slow getting here.
>
I now think that putting a lib such as libOSLib.a in SharedLibs is only
appropriate if nonstatic output is required. A better place for added
libraries seems to be in !GCC.arm-unknown-riscos.lib and then there is
no need for -LOSLib: and setvars at all.
A nice touch would be to have a !StaticLibs app (Sprite etc) inside
!GCC that simply filer_open 's the dir so there is no future confusion
to placement and as a reminder to take them forward when renewing !GCC.
I think this was the attraction to use !SharedLibs in the first place,
(one familiar place for libraries)
Libraries are also found in !GCC.libs, but on the same level,
!GCC.include is no good for finding oslib/xxx.h so I'm going with
!GCC.arm_unknown_riscos.
By putting the oslib directory of h/HDR's in
!GCC.arm-unknown-riscos.include
They are found either with <oslib/xx.h> or "oslib/xx.h" and once again,
no setvars required. Some oslib .h files reference other oslib files
with "oslib/xxh" so it is necessary for that form to work also, but
there wont be an error from using <oslib/xx.h> either so its a win win.
I'm not saying that the packaged method for installing oslib wont work,
I just think what I have described will be simpler across the board
and there is less to do/go wrong in the Makefile or gcc commands.
Cheers Ron M.
_______________________________________________
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
Ron <beeb@woosh.co.nz> wrote:
> Just using plain libOSLib32.a in the command worked fine with a copy
> in the source (CSD) directory, so I new it /would/ work once it could
> be found.
> I followed up the use of -LOSLib:, and found that I had previously
> put the supplied OSLib setvars commands in my !GCC.!Run.
>
> Once I changed the path to
> Set OSLib$Path <SharedLibs$Dir>.lib.
> now
> -LOSLib: -lOSLib32
> works fine with -static
> Yes, -LOSLib: /is/ needed when static linking, I was lazely thinking
> that because non-static was finding the lib then all was well.
> I also started off thinking native gcc defaulted to -static so
> was slow getting here.
>
I now think that putting a lib such as libOSLib.a in SharedLibs is only
appropriate if nonstatic output is required. A better place for added
libraries seems to be in !GCC.arm-unknown-riscos.lib and then there is
no need for -LOSLib: and setvars at all.
A nice touch would be to have a !StaticLibs app (Sprite etc) inside
!GCC that simply filer_open 's the dir so there is no future confusion
to placement and as a reminder to take them forward when renewing !GCC.
I think this was the attraction to use !SharedLibs in the first place,
(one familiar place for libraries)
Libraries are also found in !GCC.libs, but on the same level,
!GCC.include is no good for finding oslib/xxx.h so I'm going with
!GCC.arm_unknown_riscos.
By putting the oslib directory of h/HDR's in
!GCC.arm-unknown-riscos.include
They are found either with <oslib/xx.h> or "oslib/xx.h" and once again,
no setvars required. Some oslib .h files reference other oslib files
with "oslib/xxh" so it is necessary for that form to work also, but
there wont be an error from using <oslib/xx.h> either so its a win win.
I'm not saying that the packaged method for installing oslib wont work,
I just think what I have described will be simpler across the board
and there is less to do/go wrong in the Makefile or gcc commands.
Cheers Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: Daily build 1374 - crash on Yahoo
Date: Sun, 06 Oct 2013 02:06:49 +0200
From: Ole <ole@monochrom.net>
Subject: Re: Daily build 1374 - crash on Yahoo
To: <netsurf-users@netsurf-browser.org>
>
> This doesn't happen with my custom builds. So maybe it's caused by
> optimization
> flags or the GCC Version in use... or maybe it was just an lost bit
> ;)
>
> I switched to head again... and now I saw the bug. It even smashed
> aranym.
>
> This probably an bug inside the core of netsurf, introduced in the last
> 10 days.
>
> There were some textarea changes regarding undo/redo.
>
> The problem is: I can not reproduce it all the time.
I noticed that it does seem to depend on which Yahoo sign-in page is used.
Thanks,
Peter
From: Ole <ole@monochrom.net>
Subject: Re: Daily build 1374 - crash on Yahoo
To: <netsurf-users@netsurf-browser.org>
>
> This doesn't happen with my custom builds. So maybe it's caused by
> optimization
> flags or the GCC Version in use... or maybe it was just an lost bit
> ;)
>
> I switched to head again... and now I saw the bug. It even smashed
> aranym.
>
> This probably an bug inside the core of netsurf, introduced in the last
> 10 days.
>
> There were some textarea changes regarding undo/redo.
>
> The problem is: I can not reproduce it all the time.
I noticed that it does seem to depend on which Yahoo sign-in page is used.
Thanks,
Peter
Re: [gccsdk] -lOSLlib and -static no go
In message <525192B8.7000001@sky.com>
Lee Noar <leenoar@sky.com> wrote:
> On 06/10/13 14:59, Ron wrote:
> > In message <52515DB5.3080307@sky.com>
> > Lee Noar <leenoar@sky.com> wrote:
> >
> >> On 06/10/13 07:01, Ron wrote:
> >>> I think my installation of oslib is OK, I used the softfloat GCC version
> >>> from the sourceforge site.
> >>>
> >>> Everything is fine until I try elf2aif on my (working OK) binary.
> >>> It reports non static data is present, and when I try adding -static
> >>> to the gcc commands it then claims -lOSLib cant be found.
> >>> It's as if gcc has worked out libOSLib.a cant be linked staticly.
> >>
> >> Try -lOSLib32. You're correct that you need to use -static when linking
> >> so that elf2aif will work. Why it would find OSLib before -static, but
> >> not after, I don't know, but normally, the OSLib library is called
> >> libOSLib32.a.
> >>
> >> Lee.
> >>
> >
> > Sorry, I posted the wrong lib names there.
> > And it is libOSLib32.a and -lOSLib32 that I am using, the same one
> > that comes with gcc4 softfloat download.
> > Now that you've told me that it /should/ be OK with -static, I will
> > continue looking for the cause.
> > I know that it is linking with -lOSLib32 as I was getting a linking
> > error until I put the libOSLib32a inside !SharedLib.libs.lib
>
> You'll also need to use -LOSLib: to tell GCC where the library is;
> this assumes that you've double clicked the SetVars obey file that comes
> with OSLib.
>
> > I'll have to look closer at my use of -static.
>
> I've tried static linking and elf2aif conversion using both the 4.1.2
> and @trunk cross compilers with no errors. I haven't tried the native
> compilers though.
>
> Lee.
>
Just using plain libOSLib32.a in the command worked fine with a copy
in the source (CSD) directory, so I new it /would/ work once it could
be found.
I followed up the use of -LOSLib:, and found that I had previously
put the supplied OSLib setvars commands in my !GCC.!Run.
Once I changed the path to
Set OSLib$Path <SharedLibs$Dir>.lib.
now
-LOSLib: -lOSLib32
works fine with -static
Yes, -LOSLib: /is/ needed when static linking, I was lazely thinking
that because non-static was finding the lib then all was well.
I also started off thinking native gcc defaulted to -static so
was slow getting here.
Thanks Ron M.
_______________________________________________
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
Lee Noar <leenoar@sky.com> wrote:
> On 06/10/13 14:59, Ron wrote:
> > In message <52515DB5.3080307@sky.com>
> > Lee Noar <leenoar@sky.com> wrote:
> >
> >> On 06/10/13 07:01, Ron wrote:
> >>> I think my installation of oslib is OK, I used the softfloat GCC version
> >>> from the sourceforge site.
> >>>
> >>> Everything is fine until I try elf2aif on my (working OK) binary.
> >>> It reports non static data is present, and when I try adding -static
> >>> to the gcc commands it then claims -lOSLib cant be found.
> >>> It's as if gcc has worked out libOSLib.a cant be linked staticly.
> >>
> >> Try -lOSLib32. You're correct that you need to use -static when linking
> >> so that elf2aif will work. Why it would find OSLib before -static, but
> >> not after, I don't know, but normally, the OSLib library is called
> >> libOSLib32.a.
> >>
> >> Lee.
> >>
> >
> > Sorry, I posted the wrong lib names there.
> > And it is libOSLib32.a and -lOSLib32 that I am using, the same one
> > that comes with gcc4 softfloat download.
> > Now that you've told me that it /should/ be OK with -static, I will
> > continue looking for the cause.
> > I know that it is linking with -lOSLib32 as I was getting a linking
> > error until I put the libOSLib32a inside !SharedLib.libs.lib
>
> You'll also need to use -LOSLib: to tell GCC where the library is;
> this assumes that you've double clicked the SetVars obey file that comes
> with OSLib.
>
> > I'll have to look closer at my use of -static.
>
> I've tried static linking and elf2aif conversion using both the 4.1.2
> and @trunk cross compilers with no errors. I haven't tried the native
> compilers though.
>
> Lee.
>
Just using plain libOSLib32.a in the command worked fine with a copy
in the source (CSD) directory, so I new it /would/ work once it could
be found.
I followed up the use of -LOSLib:, and found that I had previously
put the supplied OSLib setvars commands in my !GCC.!Run.
Once I changed the path to
Set OSLib$Path <SharedLibs$Dir>.lib.
now
-LOSLib: -lOSLib32
works fine with -static
Yes, -LOSLib: /is/ needed when static linking, I was lazely thinking
that because non-static was finding the lib then all was well.
I also started off thinking native gcc defaulted to -static so
was slow getting here.
Thanks Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] -lOSLlib and -static no go
On 06/10/13 14:59, Ron wrote:
> In message <52515DB5.3080307@sky.com>
> Lee Noar <leenoar@sky.com> wrote:
>
>> On 06/10/13 07:01, Ron wrote:
>>> I think my installation of oslib is OK, I used the softfloat GCC version
>>> from the sourceforge site.
>>>
>>> Everything is fine until I try elf2aif on my (working OK) binary.
>>> It reports non static data is present, and when I try adding -static
>>> to the gcc commands it then claims -lOSLib cant be found.
>>> It's as if gcc has worked out libOSLib.a cant be linked staticly.
>>
>> Try -lOSLib32. You're correct that you need to use -static when linking
>> so that elf2aif will work. Why it would find OSLib before -static, but
>> not after, I don't know, but normally, the OSLib library is called
>> libOSLib32.a.
>>
>> Lee.
>>
>
> Sorry, I posted the wrong lib names there.
> And it is libOSLib32.a and -lOSLib32 that I am using, the same one
> that comes with gcc4 softfloat download.
> Now that you've told me that it /should/ be OK with -static, I will
> continue looking for the cause.
> I know that it is linking with -lOSLib32 as I was getting a linking
> error until I put the libOSLib32a inside !SharedLib.libs.lib
You'll also need to use -LOSLib: to tell GCC where the library is;
this assumes that you've double clicked the SetVars obey file that comes
with OSLib.
> I'll have to look closer at my use of -static.
I've tried static linking and elf2aif conversion using both the 4.1.2
and @trunk cross compilers with no errors. I haven't tried the native
compilers though.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> In message <52515DB5.3080307@sky.com>
> Lee Noar <leenoar@sky.com> wrote:
>
>> On 06/10/13 07:01, Ron wrote:
>>> I think my installation of oslib is OK, I used the softfloat GCC version
>>> from the sourceforge site.
>>>
>>> Everything is fine until I try elf2aif on my (working OK) binary.
>>> It reports non static data is present, and when I try adding -static
>>> to the gcc commands it then claims -lOSLib cant be found.
>>> It's as if gcc has worked out libOSLib.a cant be linked staticly.
>>
>> Try -lOSLib32. You're correct that you need to use -static when linking
>> so that elf2aif will work. Why it would find OSLib before -static, but
>> not after, I don't know, but normally, the OSLib library is called
>> libOSLib32.a.
>>
>> Lee.
>>
>
> Sorry, I posted the wrong lib names there.
> And it is libOSLib32.a and -lOSLib32 that I am using, the same one
> that comes with gcc4 softfloat download.
> Now that you've told me that it /should/ be OK with -static, I will
> continue looking for the cause.
> I know that it is linking with -lOSLib32 as I was getting a linking
> error until I put the libOSLib32a inside !SharedLib.libs.lib
You'll also need to use -LOSLib: to tell GCC where the library is;
this assumes that you've double clicked the SetVars obey file that comes
with OSLib.
> I'll have to look closer at my use of -static.
I've tried static linking and elf2aif conversion using both the 4.1.2
and @trunk cross compilers with no errors. I haven't tried the native
compilers though.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] -lOSLlib and -static no go
In message <52515DB5.3080307@sky.com>
Lee Noar <leenoar@sky.com> wrote:
> On 06/10/13 07:01, Ron wrote:
> > I think my installation of oslib is OK, I used the softfloat GCC version
> > from the sourceforge site.
> >
> > Everything is fine until I try elf2aif on my (working OK) binary.
> > It reports non static data is present, and when I try adding -static
> > to the gcc commands it then claims -lOSLib cant be found.
> > It's as if gcc has worked out libOSLib.a cant be linked staticly.
>
> Try -lOSLib32. You're correct that you need to use -static when linking
> so that elf2aif will work. Why it would find OSLib before -static, but
> not after, I don't know, but normally, the OSLib library is called
> libOSLib32.a.
>
> Lee.
>
Sorry, I posted the wrong lib names there.
And it is libOSLib32.a and -lOSLib32 that I am using, the same one
that comes with gcc4 softfloat download.
Now that you've told me that it /should/ be OK with -static, I will
continue looking for the cause.
I know that it is linking with -lOSLib32 as I was getting a linking
error until I put the libOSLib32a inside !SharedLib.libs.lib
I'll have to look closer at my use of -static.
Ron M.
_______________________________________________
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
Lee Noar <leenoar@sky.com> wrote:
> On 06/10/13 07:01, Ron wrote:
> > I think my installation of oslib is OK, I used the softfloat GCC version
> > from the sourceforge site.
> >
> > Everything is fine until I try elf2aif on my (working OK) binary.
> > It reports non static data is present, and when I try adding -static
> > to the gcc commands it then claims -lOSLib cant be found.
> > It's as if gcc has worked out libOSLib.a cant be linked staticly.
>
> Try -lOSLib32. You're correct that you need to use -static when linking
> so that elf2aif will work. Why it would find OSLib before -static, but
> not after, I don't know, but normally, the OSLib library is called
> libOSLib32.a.
>
> Lee.
>
Sorry, I posted the wrong lib names there.
And it is libOSLib32.a and -lOSLib32 that I am using, the same one
that comes with gcc4 softfloat download.
Now that you've told me that it /should/ be OK with -static, I will
continue looking for the cause.
I know that it is linking with -lOSLib32 as I was getting a linking
error until I put the libOSLib32a inside !SharedLib.libs.lib
I'll have to look closer at my use of -static.
Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] -lOSLlib and -static no go
On 06/10/13 07:01, Ron wrote:
> I think my installation of oslib is OK, I used the softfloat GCC version
> from the sourceforge site.
>
> Everything is fine until I try elf2aif on my (working OK) binary.
> It reports non static data is present, and when I try adding -static
> to the gcc commands it then claims -lOSLib cant be found.
> It's as if gcc has worked out libOSLib.a cant be linked staticly.
Try -lOSLib32. You're correct that you need to use -static when linking
so that elf2aif will work. Why it would find OSLib before -static, but
not after, I don't know, but normally, the OSLib library is called
libOSLib32.a.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> I think my installation of oslib is OK, I used the softfloat GCC version
> from the sourceforge site.
>
> Everything is fine until I try elf2aif on my (working OK) binary.
> It reports non static data is present, and when I try adding -static
> to the gcc commands it then claims -lOSLib cant be found.
> It's as if gcc has worked out libOSLib.a cant be linked staticly.
Try -lOSLib32. You're correct that you need to use -static when linking
so that elf2aif will work. Why it would find OSLib before -static, but
not after, I don't know, but normally, the OSLib library is called
libOSLib32.a.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Saturday, 5 October 2013
[gccsdk] -lOSLlib and -static no go
I think my installation of oslib is OK, I used the softfloat GCC version
from the sourceforge site.
Everything is fine until I try elf2aif on my (working OK) binary.
It reports non static data is present, and when I try adding -static
to the gcc commands it then claims -lOSLib cant be found.
It's as if gcc has worked out libOSLib.a cant be linked staticly.
Thanks Ron M.
_______________________________________________
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
from the sourceforge site.
Everything is fine until I try elf2aif on my (working OK) binary.
It reports non static data is present, and when I try adding -static
to the gcc commands it then claims -lOSLib cant be found.
It's as if gcc has worked out libOSLib.a cant be linked staticly.
Thanks Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: Daily build 1374 - crash on Yahoo
Am Samstag, den 05.10.2013, 23:38 +0200 schrieb Ole
<ole@monochrom.net>:
>> However, I logged into Yahoo.co.uk and when I moved the focus to the
>> home page search field, Netsurf crashed out. I repeated the test
>> to be sure.
>
>
> This doesn't happen with my custom builds. So maybe it's caused by
> optimization
> flags or the GCC Version in use... or maybe it was just an lost bit
> ;)
>
I switched to head again... and now I saw the bug. It even smashed
aranym.
This probably an bug inside the core of netsurf, introduced in the last
10 days.
There were some textarea changes regarding undo/redo.
The problem is: I can not reproduce it all the time.
<ole@monochrom.net>:
>> However, I logged into Yahoo.co.uk and when I moved the focus to the
>> home page search field, Netsurf crashed out. I repeated the test
>> to be sure.
>
>
> This doesn't happen with my custom builds. So maybe it's caused by
> optimization
> flags or the GCC Version in use... or maybe it was just an lost bit
> ;)
>
I switched to head again... and now I saw the bug. It even smashed
aranym.
This probably an bug inside the core of netsurf, introduced in the last
10 days.
There were some textarea changes regarding undo/redo.
The problem is: I can not reproduce it all the time.
Atari Treeviews
Hello,
The next autobuild should build with the new TreeView API. This means some
changes to the Treeviews, and maybe some features have been improved, some
maybe not. I also implemented the missing Treeview Windows: Cookies and
SSL Cert Info.
--
Greets,
Ole
The next autobuild should build with the new TreeView API. This means some
changes to the Treeviews, and maybe some features have been improved, some
maybe not. I also implemented the missing Treeview Windows: Cookies and
SSL Cert Info.
--
Greets,
Ole
Re: Daily build 1374 - crash on Yahoo
> However, I logged into Yahoo.co.uk and when I moved the focus to the
> home page search field, Netsurf crashed out. I repeated the test
> to be sure.
This doesn't happen with my custom builds. So maybe it's caused by
optimization
flags or the GCC Version in use... or maybe it was just an lost bit ;)
I will keep an eye on it.
> home page search field, Netsurf crashed out. I repeated the test
> to be sure.
This doesn't happen with my custom builds. So maybe it's caused by
optimization
flags or the GCC Version in use... or maybe it was just an lost bit ;)
I will keep an eye on it.
Daily build 1374 - crash on Yahoo
I am just trying the Atari daily build which is working well again.
However, I logged into Yahoo.co.uk and when I moved the focus to the
home page search field, Netsurf crashed out. I repeated the test
to be sure.
It's several months since I signed in with Netsurf but it did work
previously.
Peter
However, I logged into Yahoo.co.uk and when I moved the focus to the
home page search field, Netsurf crashed out. I repeated the test
to be sure.
It's several months since I signed in with Netsurf but it did work
previously.
Peter
Re: netsurf: branch master updated. release/3.0-583-g2a4fb9e
On Fri, 04 Oct 2013 12:11:44 +0100, Michael Drake wrote:
> In article
> <OUT-524DD209.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
> Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
>
> > I can offer you some raw data...
>
> ...
>
> > Which actually looks like I'd expect it to.
>
> Yeah, that looked fine. I can't think of anything else it might be.
Got it.
48484800 48484800 48484800 48484800 48484800 48484800 65656500 a1a1a100
That's RGBA, so the alpha channel is 00=transparent. I'm now ignoring
the alpha channel properly for opaque bitmaps and they show up
correctly.
However, I'd suggest to set the alpha channel to 0xff for your images
in case anything does an impromptu bitmap_test_opaque.
Chris
> In article
> <OUT-524DD209.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
> Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
>
> > I can offer you some raw data...
>
> ...
>
> > Which actually looks like I'd expect it to.
>
> Yeah, that looked fine. I can't think of anything else it might be.
Got it.
48484800 48484800 48484800 48484800 48484800 48484800 65656500 a1a1a100
That's RGBA, so the alpha channel is 00=transparent. I'm now ignoring
the alpha channel properly for opaque bitmaps and they show up
correctly.
However, I'd suggest to set the alpha channel to 0xff for your images
in case anything does an impromptu bitmap_test_opaque.
Chris
Re: netsurf: branch master updated. release/3.0-583-g2a4fb9e
In article
<OUT-524FF6C1.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
> Got it.
Good. :)
> However, I'd suggest to set the alpha channel to 0xff for your images
> in case anything does an impromptu bitmap_test_opaque.
Done.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
<OUT-524FF6C1.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
> Got it.
Good. :)
> However, I'd suggest to set the alpha channel to 0xff for your images
> in case anything does an impromptu bitmap_test_opaque.
Done.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Friday, 4 October 2013
Re: [gccsdk] Porting asasm
On Tue, 30 Apr 2013 23:55:50 +0100, John Tytgat <John.Tytgat@aaug.net> wrote:
>> ! 0, :STR::CC_ENCODING:"AL"
>>
>> should output "E0000000", but outputs "0000000E" instead.
>
> Interesting, that's not what I've understood from ARM's assembler manuals
> but rereading its description I see that's it was not so well specified.
> Fixed with r6390.
I've just built a new copy of asasm from SVN, and consequently only just
noticed there's a problem with this fix. Now it's outputting "0E000000" -
there's a 24 in the sources that should have been a 28. This was masked
in the project I was using it in by an unrelated bug that meant that the
code was never being executed, but actually it was causing my macro to
assemble an undefined instruction. Oh dear...
Ben
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
>> ! 0, :STR::CC_ENCODING:"AL"
>>
>> should output "E0000000", but outputs "0000000E" instead.
>
> Interesting, that's not what I've understood from ARM's assembler manuals
> but rereading its description I see that's it was not so well specified.
> Fixed with r6390.
I've just built a new copy of asasm from SVN, and consequently only just
noticed there's a problem with this fix. Now it's outputting "0E000000" -
there's a 24 in the sources that should have been a 28. This was masked
in the project I was using it in by an unrelated bug that meant that the
code was never being executed, but actually it was causing my macro to
assemble an undefined instruction. Oh dear...
Ben
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: netsurf: branch master updated. release/3.0-583-g2a4fb9e
In article
<OUT-524DD209.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
> I can offer you some raw data...
...
> Which actually looks like I'd expect it to.
Yeah, that looked fine. I can't think of anything else it might be.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
<OUT-524DD209.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
> I can offer you some raw data...
...
> Which actually looks like I'd expect it to.
Yeah, that looked fine. I can't think of anything else it might be.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Thursday, 3 October 2013
Re: netsurf: branch master updated. release/3.0-583-g2a4fb9e
On Thu, 03 Oct 2013 19:56:06 +0100, Michael Drake wrote:
> In article
> <OUT-524DC9F3.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
> Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
>
> > I'm just getting black squares now.
>
> Sounds like it's creating the bitmaps, but not drawing into them. Could
> you debug it any further?
I can offer you some raw data...
2f 54 54 54 54 54 54 54 54 54 54 54 2c ff00ff00 ff00ff00 ff00ff00
65656500 a1a1a100 c1c1c100 c1c1c100 c1c1c100 c1c1c100 c1c1c100 c1c1c100
48484800 48484800 65656500 a1a1a100 c1c1c100 c1c1c100 c1c1c100 c1c1c100
48484800 48484800 48484800 48484800 65656500 a1a1a100 c1c1c100 c1c1c100
48484800 48484800 48484800 48484800 48484800 48484800 65656500 a1a1a100
48484800 48484800 48484800 48484800 48484800 48484800 65656500 a1a1a100
48484800 48484800 48484800 48484800 65656500 a1a1a100 c1c1c100 c1c1c100
48484800 48484800 65656500 a1a1a100 c1c1c100 c1c1c100 c1c1c100 c1c1c100
65656500 a1a1a100 c1c1c100 c1c1c100 c1c1c100 c1c1c100 c1c1c100 c1c1c100
Which actually looks like I'd expect it to.
Chris
> In article
> <OUT-524DC9F3.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
> Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
>
> > I'm just getting black squares now.
>
> Sounds like it's creating the bitmaps, but not drawing into them. Could
> you debug it any further?
I can offer you some raw data...
2f 54 54 54 54 54 54 54 54 54 54 54 2c ff00ff00 ff00ff00 ff00ff00
65656500 a1a1a100 c1c1c100 c1c1c100 c1c1c100 c1c1c100 c1c1c100 c1c1c100
48484800 48484800 65656500 a1a1a100 c1c1c100 c1c1c100 c1c1c100 c1c1c100
48484800 48484800 48484800 48484800 65656500 a1a1a100 c1c1c100 c1c1c100
48484800 48484800 48484800 48484800 48484800 48484800 65656500 a1a1a100
48484800 48484800 48484800 48484800 48484800 48484800 65656500 a1a1a100
48484800 48484800 48484800 48484800 65656500 a1a1a100 c1c1c100 c1c1c100
48484800 48484800 65656500 a1a1a100 c1c1c100 c1c1c100 c1c1c100 c1c1c100
65656500 a1a1a100 c1c1c100 c1c1c100 c1c1c100 c1c1c100 c1c1c100 c1c1c100
Which actually looks like I'd expect it to.
Chris
Re: netsurf: branch master updated. release/3.0-583-g2a4fb9e
On Wed, 02 Oct 2013 23:36:30 +0100, Commit Mailer wibbled on for an age:
> - Log -----------------------------------------------------------------
> commitdiff http://git.netsurf-browser.org/netsurf.git/commit/?id=2a4fb9ecd1b80cefab5999e5401c339c0973d574
> commit 2a4fb9ecd1b80cefab5999e5401c339c0973d574
> Author: Michael Drake <tlsa@netsurf-browser.org>
> Commit: Michael Drake <tlsa@netsurf-browser.org>
>
> Generate anti-aliased triangles in bitmaps and plot via bitmap plotter. (Without
> anti-aliasing was too ugly to be endured.)
I'm just getting black squares now.
Chris
> - Log -----------------------------------------------------------------
> commitdiff http://git.netsurf-browser.org/netsurf.git/commit/?id=2a4fb9ecd1b80cefab5999e5401c339c0973d574
> commit 2a4fb9ecd1b80cefab5999e5401c339c0973d574
> Author: Michael Drake <tlsa@netsurf-browser.org>
> Commit: Michael Drake <tlsa@netsurf-browser.org>
>
> Generate anti-aliased triangles in bitmaps and plot via bitmap plotter. (Without
> anti-aliasing was too ugly to be endured.)
I'm just getting black squares now.
Chris
Re: netsurf: branch master updated. release/3.0-583-g2a4fb9e
In article
<OUT-524DC9F3.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
> I'm just getting black squares now.
Sounds like it's creating the bitmaps, but not drawing into them. Could
you debug it any further?
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
<OUT-524DC9F3.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
> I'm just getting black squares now.
Sounds like it's creating the bitmaps, but not drawing into them. Could
you debug it any further?
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: Cut to clipboard
In article <5595b59453.pittdj+@iyonix.home>,
David Pitt <pittdj@pittdj.co.uk> wrote:
> Using 1369 as far as I can see F8 and F9 work as expected.
Excellent.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
David Pitt <pittdj@pittdj.co.uk> wrote:
> Using 1369 as far as I can see F8 and F9 work as expected.
Excellent.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: 3.1 (Dev CI #1330)
In article <5394b9c0b6bbailey@argonet.co.uk>,
Brian Bailey <bbailey@argonet.co.uk> wrote:
> Looks just great here. I can now see what is happening.
Good good. Thanks for the feedback eveyone.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Brian Bailey <bbailey@argonet.co.uk> wrote:
> Looks just great here. I can now see what is happening.
Good good. Thanks for the feedback eveyone.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: 3.1 (Dev CI #1330)
> > The latest build uses the polygon plotter to draw the triangles
> > instead. On some platforms, this means the triangles are no longer
> > anti-aliased.
> That looked dreadful, so I've changed it to generate bitmaps of
> anti-aliased triangles of the appropriate size and colours at runtime.
> Is anyone testing this stuff? Also the undo/redo textarea handling.
Looks just great here. I can now see what is happening.
> > instead. On some platforms, this means the triangles are no longer
> > anti-aliased.
> That looked dreadful, so I've changed it to generate bitmaps of
> anti-aliased triangles of the appropriate size and colours at runtime.
> Is anyone testing this stuff? Also the undo/redo textarea handling.
Looks just great here. I can now see what is happening.
Subscribe to:
Posts (Atom)