>> (any idea when [ARMv6 opcodes are] likely to appear?).
>
> This is all done out of love, personal interest and in free spare time.
> I'm unable to give any deadlines.
I didn't mean to pressure - after all I'd have to answer the same way if
anyone asked when Objasm was getting Thumb 2 support, or even ELF output :)
I had to ask though, there was a chance that you might have had some
additional opcodes waiting to go into SVN...
> 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.
Thanks (and for r6391 as well).
> Pity I don't have access to the latest objasm as this would have been
> noticed otherwise ;-)
<plug type=obligatory> It's included in the NutPi pack if you want an even
cheaper way to buy it. </plug> Alternatively, limited-time trial versions of
armasm are also available from ARM.
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
Tuesday, 30 April 2013
Re: [gccsdk] Porting asasm
In message <op.wwbtkfn9l0n5eg@amoe.local>
"Ben Avison" <bavison@riscosopen.org> wrote:
> I've been running into a few other troubles, starting with the fact that
> quite a lot of the ARMv6 opcodes don't seem to have been implemented yet
> (any idea when they're likely to appear?).
This is all done out of love, personal interest and in free spare time.
I'm unable to give any deadlines.
Currently I'm in the middle of adding DWARF debug support in asasm's ELF
output.
> I thought I'd work around it by
> defining the ones I needed as macros, but then I find that :CC_ENCODING: has
> been implemented inconsistently with armasm and objasm, so for example:
>
> ! 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.
Pity I don't have access to the latest objasm as this would have been
noticed otherwise ;-)
> I thought I'd update to the head of subversion to see if either of those had
> been addressed, but instead I found that the EABI hack had stopped working,
> I now get:
>
> output.c:592:19: error: ‘EF_ARM_EABI_VER5’ undeclared
>
> when building asasm (with ELF_EABI defined). Is there a way to get this back
> please?
Sure, fixed with r6391. Apologies for that, it was a fallout after
switching to the elftoolchain library for writing ELF files instead of
our own code.
Thanks for the feedback,
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:
> I've been running into a few other troubles, starting with the fact that
> quite a lot of the ARMv6 opcodes don't seem to have been implemented yet
> (any idea when they're likely to appear?).
This is all done out of love, personal interest and in free spare time.
I'm unable to give any deadlines.
Currently I'm in the middle of adding DWARF debug support in asasm's ELF
output.
> I thought I'd work around it by
> defining the ones I needed as macros, but then I find that :CC_ENCODING: has
> been implemented inconsistently with armasm and objasm, so for example:
>
> ! 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.
Pity I don't have access to the latest objasm as this would have been
noticed otherwise ;-)
> I thought I'd update to the head of subversion to see if either of those had
> been addressed, but instead I found that the EABI hack had stopped working,
> I now get:
>
> output.c:592:19: error: ‘EF_ARM_EABI_VER5’ undeclared
>
> when building asasm (with ELF_EABI defined). Is there a way to get this back
> please?
Sure, fixed with r6391. Apologies for that, it was a fallout after
switching to the elftoolchain library for writing ELF files instead of
our own code.
Thanks for the feedback,
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
Monday, 29 April 2013
Re: [gccsdk] Porting asasm
On Tue, 12 Mar 2013 21:19:43 -0000, John Tytgat <John.Tytgat@aaug.net> wrote:
>> /usr/bin/ld: error: Source object asm.o has EABI version 0, but target
>> program has EABI version 5
>
> Asasm is not yet fully EABI compliant and this is high on my todo list.
> You can do a temporary hack by defining ELF_EABI (see src/output.c) and
> see how far you get with this in your project.
>> /usr/bin/ld: error: Source object asm.o has EABI version 0, but target
>> program has EABI version 5
>
> Asasm is not yet fully EABI compliant and this is high on my todo list.
> You can do a temporary hack by defining ELF_EABI (see src/output.c) and
> see how far you get with this in your project.
I've been running into a few other troubles, starting with the fact that
quite a lot of the ARMv6 opcodes don't seem to have been implemented yet
(any idea when they're likely to appear?). I thought I'd work around it by
defining the ones I needed as macros, but then I find that :CC_ENCODING: has
been implemented inconsistently with armasm and objasm, so for example:
! 0, :STR::CC_ENCODING:"AL"
should output "E0000000", but outputs "0000000E" instead.
I thought I'd update to the head of subversion to see if either of those had
been addressed, but instead I found that the EABI hack had stopped working,
I now get:
output.c:592:19: error: 'EF_ARM_EABI_VER5' undeclared
when building asasm (with ELF_EABI defined). Is there a way to get this back
please?
Thanks,
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: Default LANG?
On Wed, Apr 24, 2013 at 01:57:49AM -0600, Anthony J. Bentley wrote:
> Hi,
>
> After upgrading to 3.0 on my system, NetSurf-GTK looks like this:
> http://i.imgur.com/BUr5Tj4.png
>
> It turns out this is because LANG is unset in my environment (although
> LC_CTYPE=en_US.UTF8). If I run "LANG=en netsurf", everything is peachy.
> Would it be possible to default to "en" if LANG is unset and/or LANG=C?
Fixed by ensuring the C "language" resources are available (linked to
the en language by default) which g_get_language_names() always
returns as the least desirable result.
>
> --
> Anthony J. Bentley
>
>
--
Regards Vincent
http://www.kyllikki.org/
> Hi,
>
> After upgrading to 3.0 on my system, NetSurf-GTK looks like this:
> http://i.imgur.com/BUr5Tj4.png
>
> It turns out this is because LANG is unset in my environment (although
> LC_CTYPE=en_US.UTF8). If I run "LANG=en netsurf", everything is peachy.
> Would it be possible to default to "en" if LANG is unset and/or LANG=C?
Fixed by ensuring the C "language" resources are available (linked to
the en language by default) which g_get_language_names() always
returns as the least desirable result.
>
> --
> Anthony J. Bentley
>
>
--
Regards Vincent
http://www.kyllikki.org/
Sunday, 28 April 2013
Saturday, 27 April 2013
Re: Tests rely on alloca()
On Fri, Apr 26, 2013 at 09:24:59PM -0600, Anthony J. Bentley wrote:
> "Anthony J. Bentley" writes:
> > Hi,
> >
> > Several tests use alloca() to allocate memory. But alloca() is not part of
> > C99, and on OpenBSD this leads to linking errors since the NetSurf build
> > system specifies -std=c99:
> >
> > LINK: build-OpenBSD-OpenBSD-release-lib-shared/test_parser
> > cc -o build-OpenBSD-OpenBSD-release-lib-shared/test_parser build-OpenBSD-Open
> > BSD-release-lib-shared/test_parser.o -Lbuild-OpenBSD-OpenBSD-release-lib-shar
> > ed/ -lhubbub -g -L/usr/local/lib -liconv -L/usr/local/lib -ljson-c
> > build-OpenBSD-OpenBSD-release-lib-shared/test_parser.o(.text+0x578): In funct
> > ion `run_test':
> > test/parser.c:28: undefined reference to `alloca'
> > collect2: ld returned 1 exit status
>
> I've replaced these with calls to malloc():
>
> https://github.com/bentley/libcss/
> https://github.com/bentley/libhubbub/
> https://github.com/bentley/libparserutils/
Reviewed and applied, thanks for your work on this
>
> If these could be pulled into the main repositories that would be great.
>
> --
> Anthony J. Bentley
>
>
--
Regards Vincent
http://www.kyllikki.org/
> "Anthony J. Bentley" writes:
> > Hi,
> >
> > Several tests use alloca() to allocate memory. But alloca() is not part of
> > C99, and on OpenBSD this leads to linking errors since the NetSurf build
> > system specifies -std=c99:
> >
> > LINK: build-OpenBSD-OpenBSD-release-lib-shared/test_parser
> > cc -o build-OpenBSD-OpenBSD-release-lib-shared/test_parser build-OpenBSD-Open
> > BSD-release-lib-shared/test_parser.o -Lbuild-OpenBSD-OpenBSD-release-lib-shar
> > ed/ -lhubbub -g -L/usr/local/lib -liconv -L/usr/local/lib -ljson-c
> > build-OpenBSD-OpenBSD-release-lib-shared/test_parser.o(.text+0x578): In funct
> > ion `run_test':
> > test/parser.c:28: undefined reference to `alloca'
> > collect2: ld returned 1 exit status
>
> I've replaced these with calls to malloc():
>
> https://github.com/bentley/libcss/
> https://github.com/bentley/libhubbub/
> https://github.com/bentley/libparserutils/
Reviewed and applied, thanks for your work on this
>
> If these could be pulled into the main repositories that would be great.
>
> --
> Anthony J. Bentley
>
>
--
Regards Vincent
http://www.kyllikki.org/
Friday, 26 April 2013
Re: Tests rely on alloca()
"Anthony J. Bentley" writes:
> Hi,
>
> Several tests use alloca() to allocate memory. But alloca() is not part of
> C99, and on OpenBSD this leads to linking errors since the NetSurf build
> system specifies -std=c99:
>
> LINK: build-OpenBSD-OpenBSD-release-lib-shared/test_parser
> cc -o build-OpenBSD-OpenBSD-release-lib-shared/test_parser build-OpenBSD-Open
> BSD-release-lib-shared/test_parser.o -Lbuild-OpenBSD-OpenBSD-release-lib-shar
> ed/ -lhubbub -g -L/usr/local/lib -liconv -L/usr/local/lib -ljson-c
> build-OpenBSD-OpenBSD-release-lib-shared/test_parser.o(.text+0x578): In funct
> ion `run_test':
> test/parser.c:28: undefined reference to `alloca'
> collect2: ld returned 1 exit status
I've replaced these with calls to malloc():
https://github.com/bentley/libcss/
https://github.com/bentley/libhubbub/
https://github.com/bentley/libparserutils/
If these could be pulled into the main repositories that would be great.
--
Anthony J. Bentley
> Hi,
>
> Several tests use alloca() to allocate memory. But alloca() is not part of
> C99, and on OpenBSD this leads to linking errors since the NetSurf build
> system specifies -std=c99:
>
> LINK: build-OpenBSD-OpenBSD-release-lib-shared/test_parser
> cc -o build-OpenBSD-OpenBSD-release-lib-shared/test_parser build-OpenBSD-Open
> BSD-release-lib-shared/test_parser.o -Lbuild-OpenBSD-OpenBSD-release-lib-shar
> ed/ -lhubbub -g -L/usr/local/lib -liconv -L/usr/local/lib -ljson-c
> build-OpenBSD-OpenBSD-release-lib-shared/test_parser.o(.text+0x578): In funct
> ion `run_test':
> test/parser.c:28: undefined reference to `alloca'
> collect2: ld returned 1 exit status
I've replaced these with calls to malloc():
https://github.com/bentley/libcss/
https://github.com/bentley/libhubbub/
https://github.com/bentley/libparserutils/
If these could be pulled into the main repositories that would be great.
--
Anthony J. Bentley
Thursday, 25 April 2013
Re: new Dutch translation
On Thu, Apr 25, 2013 at 07:19:04PM +0200, Simon Voortman wrote:
> Hi list,
>
> Where should I submit new Dutch translations?
That would be great to have. The mailing list is the best place for
translations currently.
A diff against the FatMessages file is easiest to integrate but I can
merge by hand if thats not possible.
>
> TIA,
> Simon Voortman.
>
>
--
Regards Vincent
http://www.kyllikki.org/
> Hi list,
>
> Where should I submit new Dutch translations?
That would be great to have. The mailing list is the best place for
translations currently.
A diff against the FatMessages file is easiest to integrate but I can
merge by hand if thats not possible.
>
> TIA,
> Simon Voortman.
>
>
--
Regards Vincent
http://www.kyllikki.org/
Clang warning fixes
I've pushed a handful of branches containing some clang warning fixes.
libnsfb/rjek/clang-warnings
libcss/rjek/clang-warnings
nsjsgenbind/rjek/clang-warnings
netsurf/rjek/clang-warnings
B.
libnsfb/rjek/clang-warnings
libcss/rjek/clang-warnings
nsjsgenbind/rjek/clang-warnings
netsurf/rjek/clang-warnings
B.
Wednesday, 24 April 2013
Re: [Rpcemu] 5.19 doesn't retain monitor settings
On 24 Apr 2013, george greenfield <george.greenfield@tiscali.co.uk>
wrote:
> In message <2d901d4153.old_coaster@old_coaster.yahoo.co.uk>
> Tony Moore <old_coaster@yahoo.co.uk> wrote:
[snip]
> > I've now updated my installation here to RO 5.19 (22-Apr-2013) and
> > !Boot dated 6 Feb 2013 (as link above) without problem.
>
> And so have I :-). Thanks for the advice, Tony:
Good news!
[snip]
> BTW, 5.19 seems to run even faster than 5.17, according to !Firebench;
> I shall re-do the Romark benchmarks one of these days.
And RPCEmu 0.8.10 runs slightly faster than 0.8.9.
> Is networking operational?
Yes.
> HardDisc4?
IDE harddiscs are still not available in RPCEmu 0.8.10 / RO5.19.
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
wrote:
> In message <2d901d4153.old_coaster@old_coaster.yahoo.co.uk>
> Tony Moore <old_coaster@yahoo.co.uk> wrote:
[snip]
> > I've now updated my installation here to RO 5.19 (22-Apr-2013) and
> > !Boot dated 6 Feb 2013 (as link above) without problem.
>
> And so have I :-). Thanks for the advice, Tony:
Good news!
[snip]
> BTW, 5.19 seems to run even faster than 5.17, according to !Firebench;
> I shall re-do the Romark benchmarks one of these days.
And RPCEmu 0.8.10 runs slightly faster than 0.8.9.
> Is networking operational?
Yes.
> HardDisc4?
IDE harddiscs are still not available in RPCEmu 0.8.10 / RO5.19.
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] 0.8.10 and 5.19 / 5.18 versus 4.02
In article <20130424101100.GA29866@spod.org>, Peter Howkins
<rpcemu.howkins@marutan.net> wrote:
> On Wed, Apr 24, 2013 at 10:18:07AM +0100, Jim Lesurf wrote:
> > First the minor ones:
> For these issues can you post your rpclog.txt file please.
OK. I've just got my new ARMiniX to play with. But once I've managed to
overcome the urge to experiment with that I'll do so...
> > 1) The only (minor) snags I have with 0.8.9 / 4.02 are that the mouse
> > pointer seems to be 'on skates' and seems to have some inertial effect
> > that causes it to go on sliding across the window for a while after I
> > stop moving the mouse.
> Unfortuanately I've not seen this before.
> > 2) The other snag is that shutdown 'freezes' the RPCEmu window. Is
> > this fixed?
> Unfortuanately I've not seen this before.
Erm... I've reported both before (in more than email here). See for example
emails from 27, 28, 30 Mar 2012 and 2 Apr 2012. So I guess they have been
forgotten. But I'll summarise again below...
> Can you describe the method you're using to shutdown please? Is it in
> RISC OS, clicking the close button on the emulator window, picking exit
> from the emulator menu?
Choosing the shutdown on the switcher menu. This pops up the usual choice
with a shutdown button. Clicking on this makes the icon go to the
'depressed' state. Then nothing else happens. No shutdown.
The CPU use goes to 100 percent and stays there.
I then close down the Xfce desktop window by clicking on its close icon.
So far as I can see (and from the discussions we had back when) this is
quite safe. Just odd.
> Can you describe the 'freeze', what does it look like, what does it
> behave like?
As above. The RPEmu 'screen' shows the shutdown icon in the depressed
(shaded) state but then no progress.
I have a vague recollection that I once did a screengrab to show what the
RPC 'screen' looked like when frozen and put it on the web. If I get a
chance I'll do that again to show what I get.
The roller skates effect is hard to describe in detail. But the behaviour
means that if I move the mouse and then stop it, the pointer keeps rolling
for a while as it glides to a halt. Its as if moving the mouse whizzed up
some spinning 'inertia wheels' inside the mouse that keep things moving as
they run down when I stop the mouse. Bit like trying to walk on ice.
> > 3) shuft-F12 doesn't open a taskwindow. But I think my Xubuntu desktop
> > is the cause and it is trapping the keys for something else.
> Yes, Shift-F12 works fine ... it also works fine in Xubuntu, so there's
> some specific app you're running that is capturing those keys.
OK. Again this isn't really a problem. I just mentioned it for completeness
here.
Of the above, the roller skating effect is the most bother as I have to
move the mouse around with particular care. But not exactly a serious
problem, more of an oddity I have to keep in mind. However I'd have to
video the desktop to show what it is like!
> > The more serious question is:
> >
> > Is there any particular reason I should also try switching to 5.18 or
> > 5.19 rather than 4.02?
> 5.x runs the OS in 32-bit mode (just like iyonix/pi/beagleboard) as such
> will require Aemulor to run 26-bit apps. Stick to 3.x/4.x/6.x if 26-bit
> is a requirement.
OK. Thanks. That's what I suspected. But wondered if there was a particular
advantage for 5.1x. I'll stick with 4.02.
I'll try 0.8.10 with 4.02 once I've got the ARMiniX sorted. Then report
again to say if I get the above quirks or they vanish.
Cheers,
Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<rpcemu.howkins@marutan.net> wrote:
> On Wed, Apr 24, 2013 at 10:18:07AM +0100, Jim Lesurf wrote:
> > First the minor ones:
> For these issues can you post your rpclog.txt file please.
OK. I've just got my new ARMiniX to play with. But once I've managed to
overcome the urge to experiment with that I'll do so...
> > 1) The only (minor) snags I have with 0.8.9 / 4.02 are that the mouse
> > pointer seems to be 'on skates' and seems to have some inertial effect
> > that causes it to go on sliding across the window for a while after I
> > stop moving the mouse.
> Unfortuanately I've not seen this before.
> > 2) The other snag is that shutdown 'freezes' the RPCEmu window. Is
> > this fixed?
> Unfortuanately I've not seen this before.
Erm... I've reported both before (in more than email here). See for example
emails from 27, 28, 30 Mar 2012 and 2 Apr 2012. So I guess they have been
forgotten. But I'll summarise again below...
> Can you describe the method you're using to shutdown please? Is it in
> RISC OS, clicking the close button on the emulator window, picking exit
> from the emulator menu?
Choosing the shutdown on the switcher menu. This pops up the usual choice
with a shutdown button. Clicking on this makes the icon go to the
'depressed' state. Then nothing else happens. No shutdown.
The CPU use goes to 100 percent and stays there.
I then close down the Xfce desktop window by clicking on its close icon.
So far as I can see (and from the discussions we had back when) this is
quite safe. Just odd.
> Can you describe the 'freeze', what does it look like, what does it
> behave like?
As above. The RPEmu 'screen' shows the shutdown icon in the depressed
(shaded) state but then no progress.
I have a vague recollection that I once did a screengrab to show what the
RPC 'screen' looked like when frozen and put it on the web. If I get a
chance I'll do that again to show what I get.
The roller skates effect is hard to describe in detail. But the behaviour
means that if I move the mouse and then stop it, the pointer keeps rolling
for a while as it glides to a halt. Its as if moving the mouse whizzed up
some spinning 'inertia wheels' inside the mouse that keep things moving as
they run down when I stop the mouse. Bit like trying to walk on ice.
> > 3) shuft-F12 doesn't open a taskwindow. But I think my Xubuntu desktop
> > is the cause and it is trapping the keys for something else.
> Yes, Shift-F12 works fine ... it also works fine in Xubuntu, so there's
> some specific app you're running that is capturing those keys.
OK. Again this isn't really a problem. I just mentioned it for completeness
here.
Of the above, the roller skating effect is the most bother as I have to
move the mouse around with particular care. But not exactly a serious
problem, more of an oddity I have to keep in mind. However I'd have to
video the desktop to show what it is like!
> > The more serious question is:
> >
> > Is there any particular reason I should also try switching to 5.18 or
> > 5.19 rather than 4.02?
> 5.x runs the OS in 32-bit mode (just like iyonix/pi/beagleboard) as such
> will require Aemulor to run 26-bit apps. Stick to 3.x/4.x/6.x if 26-bit
> is a requirement.
OK. Thanks. That's what I suspected. But wondered if there was a particular
advantage for 5.1x. I'll stick with 4.02.
I'll try 0.8.10 with 4.02 once I've got the ARMiniX sorted. Then report
again to say if I get the above quirks or they vanish.
Cheers,
Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] 0.8.10 and 5.19 / 5.18 versus 4.02
On Wed, Apr 24, 2013 at 10:18:07AM +0100, Jim Lesurf wrote:
> First the minor ones:
For these issues can you post your rpclog.txt file please.
> 1) The only (minor) snags I have with 0.8.9 / 4.02 are that the mouse
> pointer seems to be 'on skates' and seems to have some inertial effect that
> causes it to go on sliding across the window for a while after I stop
> moving the mouse.
Unfortuanately I've not seen this before.
> 2) The other snag is that shutdown 'freezes' the RPCEmu window. Is this
> fixed?
Unfortuanately I've not seen this before.
Can you describe the method you're using to shutdown please? Is it in
RISC OS, clicking the close button on the emulator window, picking exit
from the emulator menu?
Can you describe the 'freeze', what does it look like, what does it behave
like?
> 3) shuft-F12 doesn't open a taskwindow. But I think my Xubuntu desktop is
> the cause and it is trapping the keys for something else.
Yes, Shift-F12 works fine ... it also works fine in Xubuntu, so there's
some specific app you're running that is capturing those keys.
> I can live happily enough with the above, but are (1) or (2) fixed in
> 0.8.10?
No, mainly because I've not been able to reproduce them. I don't know if
they're common and people arn't reporting them, or that you have some
specific configuration that is causing complications.
> The more serious question is:
>
> Is there any particular reason I should also try switching to 5.18 or 5.19
> rather than 4.02?
5.x runs the OS in 32-bit mode (just like iyonix/pi/beagleboard) as such
will require Aemulor to run 26-bit apps. Stick to 3.x/4.x/6.x if 26-bit is
a requirement.
> BTW Am I correct in assuming that installing 0.8.10 is the same process as
> for earlier versions and that I can copy across my files from 0.8.9?
In general yes, HostFS yes, hard/floppy disc images yes. But do not copy
over the contents of poduleroms or any of the program binaries/config
files.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> First the minor ones:
For these issues can you post your rpclog.txt file please.
> 1) The only (minor) snags I have with 0.8.9 / 4.02 are that the mouse
> pointer seems to be 'on skates' and seems to have some inertial effect that
> causes it to go on sliding across the window for a while after I stop
> moving the mouse.
Unfortuanately I've not seen this before.
> 2) The other snag is that shutdown 'freezes' the RPCEmu window. Is this
> fixed?
Unfortuanately I've not seen this before.
Can you describe the method you're using to shutdown please? Is it in
RISC OS, clicking the close button on the emulator window, picking exit
from the emulator menu?
Can you describe the 'freeze', what does it look like, what does it behave
like?
> 3) shuft-F12 doesn't open a taskwindow. But I think my Xubuntu desktop is
> the cause and it is trapping the keys for something else.
Yes, Shift-F12 works fine ... it also works fine in Xubuntu, so there's
some specific app you're running that is capturing those keys.
> I can live happily enough with the above, but are (1) or (2) fixed in
> 0.8.10?
No, mainly because I've not been able to reproduce them. I don't know if
they're common and people arn't reporting them, or that you have some
specific configuration that is causing complications.
> The more serious question is:
>
> Is there any particular reason I should also try switching to 5.18 or 5.19
> rather than 4.02?
5.x runs the OS in 32-bit mode (just like iyonix/pi/beagleboard) as such
will require Aemulor to run 26-bit apps. Stick to 3.x/4.x/6.x if 26-bit is
a requirement.
> BTW Am I correct in assuming that installing 0.8.10 is the same process as
> for earlier versions and that I can copy across my files from 0.8.9?
In general yes, HostFS yes, hard/floppy disc images yes. But do not copy
over the contents of poduleroms or any of the program binaries/config
files.
Peter
--
Peter Howkins
peter.howkins@marutan.net
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] 0.8.10 and 5.19 / 5.18 versus 4.02
For some time I've been using RO4.02 on RPCEmu 0.8.9. Overall, this works
fine on my Xubuntu boxes.
All being well, I should shortly get an ARMiniX to start using. That may
lead to a 'cascade' of changes and there are aspects I'd like to ask for
comments about here...
*If* the ARMiniX works as nicely as I hope I may decide to retire my
Iyonix. (Currently running RO 5.18.)
That, in turn, means I may decide to use RPCEmu to run RO software that
would need Aemulor on the ARMiniX. That may be simpler and more reliable.
In conjunction with that, I am planning sometime soon to install 0.8.10 and
use that instead of 0.8.9. Which prompts me to ask about the following
points...
First the minor ones:
1) The only (minor) snags I have with 0.8.9 / 4.02 are that the mouse
pointer seems to be 'on skates' and seems to have some inertial effect that
causes it to go on sliding across the window for a while after I stop
moving the mouse.
2) The other snag is that shutdown 'freezes' the RPCEmu window. Is this
fixed?
3) shuft-F12 doesn't open a taskwindow. But I think my Xubuntu desktop is
the cause and it is trapping the keys for something else.
I can live happily enough with the above, but are (1) or (2) fixed in
0.8.10?
The more serious question is:
Is there any particular reason I should also try switching to 5.18 or 5.19
rather than 4.02? The context is that I'm using RPCEmu purely for
convenience as a way to do some processing using my own existing progs in
conjunction with Linux ones, and will be adding to that using it as a
preferred alternative to Aemulor.
BTW Am I correct in assuming that installing 0.8.10 is the same process as
for earlier versions and that I can copy across my files from 0.8.9?
Cheers,
Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
fine on my Xubuntu boxes.
All being well, I should shortly get an ARMiniX to start using. That may
lead to a 'cascade' of changes and there are aspects I'd like to ask for
comments about here...
*If* the ARMiniX works as nicely as I hope I may decide to retire my
Iyonix. (Currently running RO 5.18.)
That, in turn, means I may decide to use RPCEmu to run RO software that
would need Aemulor on the ARMiniX. That may be simpler and more reliable.
In conjunction with that, I am planning sometime soon to install 0.8.10 and
use that instead of 0.8.9. Which prompts me to ask about the following
points...
First the minor ones:
1) The only (minor) snags I have with 0.8.9 / 4.02 are that the mouse
pointer seems to be 'on skates' and seems to have some inertial effect that
causes it to go on sliding across the window for a while after I stop
moving the mouse.
2) The other snag is that shutdown 'freezes' the RPCEmu window. Is this
fixed?
3) shuft-F12 doesn't open a taskwindow. But I think my Xubuntu desktop is
the cause and it is trapping the keys for something else.
I can live happily enough with the above, but are (1) or (2) fixed in
0.8.10?
The more serious question is:
Is there any particular reason I should also try switching to 5.18 or 5.19
rather than 4.02? The context is that I'm using RPCEmu purely for
convenience as a way to do some processing using my own existing progs in
conjunction with Linux ones, and will be adding to that using it as a
preferred alternative to Aemulor.
BTW Am I correct in assuming that installing 0.8.10 is the same process as
for earlier versions and that I can copy across my files from 0.8.9?
Cheers,
Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: Upper character truncation - CSS handling
On 24 Apr, JohnRW@ukgateway.net wrote:
> I see this hasn't been corrected,
Whoops - a quick refresh and it magically has - was I looking at a cached
page or what?
Congratulations all round!
John
> I see this hasn't been corrected,
Whoops - a quick refresh and it magically has - was I looking at a cached
page or what?
Congratulations all round!
John
Re: Upper character truncation - CSS handling
In article <mpro.mlc3ut004g9yd015i.pittdj@pittdj.co.uk>,
David Pitt <pittdj@pittdj.co.uk> wrote:
> Is this the earlier instance:-
> http://sourceforge.net/tracker/index.php?func=detail&aid=3288883&group_id=51719&atid=464312
That's it - and sorry, it was you and not another David!
I see this hasn't been corrected, but am delighted to see that the similar
effect on the Google page links to the right of the search box /has/ been
fixed.
A much better impression for all our RPi new users!
John
David Pitt <pittdj@pittdj.co.uk> wrote:
> Is this the earlier instance:-
> http://sourceforge.net/tracker/index.php?func=detail&aid=3288883&group_id=51719&atid=464312
That's it - and sorry, it was you and not another David!
I see this hasn't been corrected, but am delighted to see that the similar
effect on the Google page links to the right of the search box /has/ been
fixed.
A much better impression for all our RPi new users!
John
Re: [Rpcemu] 5.19 doesn't retain monitor settings
In message <2d901d4153.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 23 Apr 2013, george greenfield <george.greenfield@tiscali.co.uk>
> wrote:
>> In message <59c7074153.old_coaster@old_coaster.yahoo.co.uk>
>> Tony Moore <old_coaster@yahoo.co.uk> wrote:
>> > On 23 Apr 2013, george greenfield <george.greenfield@tiscali.co.uk>
>> > wrote:
[snip]
>
> It seems that parts of your !Boot are missing. I would suggest that you
> re-instate your 5.17 !Boot, then update it, using the file from the link
> above, _and_ using the Boot-Install dialogue.
>
> I've now updated my installation here to RO 5.19 (22-Apr-2013) and !Boot
> dated 6 Feb 2013 (as link above) without problem.
And so have I :-). Thanks for the advice, Tony: it appears I'd mangled
both 5.19 !Boot and roms in my extraction process. I boot-merged your
zipped !Boot, re-extracted the rom from the zipped IOMDHaldev ROOL
download using !SparkFS and copied it into RPCEMu089/519's roms
folder, and hey presto!
BTW, 5.19 seems to run even faster than 5.17, according to !Firebench;
I shall re-do the Romark benchmarks one of these days. Is networking
operational? HardDisc4? Thanks again,
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 23 Apr 2013, george greenfield <george.greenfield@tiscali.co.uk>
> wrote:
>> In message <59c7074153.old_coaster@old_coaster.yahoo.co.uk>
>> Tony Moore <old_coaster@yahoo.co.uk> wrote:
>> > On 23 Apr 2013, george greenfield <george.greenfield@tiscali.co.uk>
>> > wrote:
[snip]
>
> It seems that parts of your !Boot are missing. I would suggest that you
> re-instate your 5.17 !Boot, then update it, using the file from the link
> above, _and_ using the Boot-Install dialogue.
>
> I've now updated my installation here to RO 5.19 (22-Apr-2013) and !Boot
> dated 6 Feb 2013 (as link above) without problem.
And so have I :-). Thanks for the advice, Tony: it appears I'd mangled
both 5.19 !Boot and roms in my extraction process. I boot-merged your
zipped !Boot, re-extracted the rom from the zipped IOMDHaldev ROOL
download using !SparkFS and copied it into RPCEMu089/519's roms
folder, and hey presto!
BTW, 5.19 seems to run even faster than 5.17, according to !Firebench;
I shall re-do the Romark benchmarks one of these days. Is networking
operational? HardDisc4? Thanks again,
George
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Javascript feature details
Would it be possible to list the progress on individual Javascript
features, in the same way as the CSS features? That way, those of
us who are interested can play with features, learn Javascript,
and test the features.
Or will implementation be an all-or-nothing event - suddenly one
day all of Javascript will work?
Dave
____________________________________________________________
GET FREE SMILEYS FOR YOUR IM & EMAIL - Learn more at http://www.inbox.com/smileys
Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and most webmails
features, in the same way as the CSS features? That way, those of
us who are interested can play with features, learn Javascript,
and test the features.
Or will implementation be an all-or-nothing event - suddenly one
day all of Javascript will work?
Dave
____________________________________________________________
GET FREE SMILEYS FOR YOUR IM & EMAIL - Learn more at http://www.inbox.com/smileys
Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and most webmails
Default LANG?
Hi,
After upgrading to 3.0 on my system, NetSurf-GTK looks like this:
http://i.imgur.com/BUr5Tj4.png
It turns out this is because LANG is unset in my environment (although
LC_CTYPE=en_US.UTF8). If I run "LANG=en netsurf", everything is peachy.
Would it be possible to default to "en" if LANG is unset and/or LANG=C?
--
Anthony J. Bentley
After upgrading to 3.0 on my system, NetSurf-GTK looks like this:
http://i.imgur.com/BUr5Tj4.png
It turns out this is because LANG is unset in my environment (although
LC_CTYPE=en_US.UTF8). If I run "LANG=en netsurf", everything is peachy.
Would it be possible to default to "en" if LANG is unset and/or LANG=C?
--
Anthony J. Bentley
Tests rely on alloca()
Hi,
Several tests use alloca() to allocate memory. But alloca() is not part of
C99, and on OpenBSD this leads to linking errors since the NetSurf build
system specifies -std=c99:
LINK: build-OpenBSD-OpenBSD-release-lib-shared/test_parser
cc -o build-OpenBSD-OpenBSD-release-lib-shared/test_parser build-OpenBSD-OpenBSD-release-lib-shared/test_parser.o -Lbuild-OpenBSD-OpenBSD-release-lib-shared/ -lhubbub -g -L/usr/local/lib -liconv -L/usr/local/lib -ljson-c
build-OpenBSD-OpenBSD-release-lib-shared/test_parser.o(.text+0x578): In function `run_test':
test/parser.c:28: undefined reference to `alloca'
collect2: ld returned 1 exit status
These are the files that use alloca():
libhubbub:
test/parser.c
test/tokeniser2.c
test/tokeniser3.c
test/tree.c
libcss:
test/css21.c
test/parse-auto.c
libparserutils:
test/cscodec-8859.c
test/cscodec-ext8.c
test/cscodec-utf8.c
test/cscodec-utf16.c
Several tests use alloca() to allocate memory. But alloca() is not part of
C99, and on OpenBSD this leads to linking errors since the NetSurf build
system specifies -std=c99:
LINK: build-OpenBSD-OpenBSD-release-lib-shared/test_parser
cc -o build-OpenBSD-OpenBSD-release-lib-shared/test_parser build-OpenBSD-OpenBSD-release-lib-shared/test_parser.o -Lbuild-OpenBSD-OpenBSD-release-lib-shared/ -lhubbub -g -L/usr/local/lib -liconv -L/usr/local/lib -ljson-c
build-OpenBSD-OpenBSD-release-lib-shared/test_parser.o(.text+0x578): In function `run_test':
test/parser.c:28: undefined reference to `alloca'
collect2: ld returned 1 exit status
These are the files that use alloca():
libhubbub:
test/parser.c
test/tokeniser2.c
test/tokeniser3.c
test/tree.c
libcss:
test/css21.c
test/parse-auto.c
libparserutils:
test/cscodec-8859.c
test/cscodec-ext8.c
test/cscodec-utf8.c
test/cscodec-utf16.c
Tuesday, 23 April 2013
Re: [Rpcemu] 5.19 doesn't retain monitor settings
On 23 Apr 2013, george greenfield <george.greenfield@tiscali.co.uk>
wrote:
> In message <59c7074153.old_coaster@old_coaster.yahoo.co.uk>
> Tony Moore <old_coaster@yahoo.co.uk> wrote:
> > On 23 Apr 2013, george greenfield <george.greenfield@tiscali.co.uk>
> > wrote:
> >
> > [snip]
> >
> > > So I'm stuck. Maybe it's best to revert to 5.17; at least it
> > > worked! Unless you have a barebones !Boot from said HardDisc4
> > > which you could send me (suitably zipped: that at least works
> > > here)?
> >
> > I'm using Boot dated 27 Nov 2012 which may not work with the current
> > ROM so try https://dl.dropbox.com/u/77062274/ro519_boot_20130206.zip
> > [8MB] which is contained in the current HardDisc4 download
> > (2013-04-03). I haven't tried it myself yet.
>
> Many thanks responding so quickly and comprehensively, Tony!
You're welcome.
> I'm holding your !Boot file in reserve: I managed to decompress the
> current ROOL .tar version using WinZip on the dark side,
Received wisdom is that archives should not be decompressed in a Windows
environment, because RO filetypes will be screwed-up.
> and have copied it into Hostfs in place of the 5.17 !Boot
I'm surprised that it works!
> (NOT using the Boot-Install dialogue however - dragging the new !Boot
> into the Merge field didn't work). I still have only two display
> options in Configure-Screen: 'Auto' and the Acer AL2416W MDF which is
> one of the supplied ones. All the other supplied MDFs are unavailable
> - God knows why. ISTR with my Iyo that simply dragging a new MDF into
> !Boot.Resources.Configure.Monitors made it available for selection.
It seems that parts of your !Boot are missing. I would suggest that you
re-instate your 5.17 !Boot, then update it, using the file from the link
above, _and_ using the Boot-Install dialogue.
I've now updated my installation here to RO 5.19 (22-Apr-2013) and !Boot
dated 6 Feb 2013 (as link above) without problem.
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
wrote:
> In message <59c7074153.old_coaster@old_coaster.yahoo.co.uk>
> Tony Moore <old_coaster@yahoo.co.uk> wrote:
> > On 23 Apr 2013, george greenfield <george.greenfield@tiscali.co.uk>
> > wrote:
> >
> > [snip]
> >
> > > So I'm stuck. Maybe it's best to revert to 5.17; at least it
> > > worked! Unless you have a barebones !Boot from said HardDisc4
> > > which you could send me (suitably zipped: that at least works
> > > here)?
> >
> > I'm using Boot dated 27 Nov 2012 which may not work with the current
> > ROM so try https://dl.dropbox.com/u/77062274/ro519_boot_20130206.zip
> > [8MB] which is contained in the current HardDisc4 download
> > (2013-04-03). I haven't tried it myself yet.
>
> Many thanks responding so quickly and comprehensively, Tony!
You're welcome.
> I'm holding your !Boot file in reserve: I managed to decompress the
> current ROOL .tar version using WinZip on the dark side,
Received wisdom is that archives should not be decompressed in a Windows
environment, because RO filetypes will be screwed-up.
> and have copied it into Hostfs in place of the 5.17 !Boot
I'm surprised that it works!
> (NOT using the Boot-Install dialogue however - dragging the new !Boot
> into the Merge field didn't work). I still have only two display
> options in Configure-Screen: 'Auto' and the Acer AL2416W MDF which is
> one of the supplied ones. All the other supplied MDFs are unavailable
> - God knows why. ISTR with my Iyo that simply dragging a new MDF into
> !Boot.Resources.Configure.Monitors made it available for selection.
It seems that parts of your !Boot are missing. I would suggest that you
re-instate your 5.17 !Boot, then update it, using the file from the link
above, _and_ using the Boot-Install dialogue.
I've now updated my installation here to RO 5.19 (22-Apr-2013) and !Boot
dated 6 Feb 2013 (as link above) without problem.
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] 5.19 doesn't retain monitor settings
In message <59c7074153.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 23 Apr 2013, george greenfield <george.greenfield@tiscali.co.uk> wrote:
>
> [snip]
>
>> So I'm stuck. Maybe it's best to revert to 5.17; at least it worked!
>> Unless you have a barebones !Boot from said HardDisc4 which you could
>> send me (suitably zipped: that at least works here)?
>
> I'm using Boot dated 27 Nov 2012 which may not work with the current ROM
> so try https://dl.dropbox.com/u/77062274/ro519_boot_20130206.zip [8MB]
> which is contained in the current HardDisc4 download (2013-04-03). I
> haven't tried it myself yet.
>
Many thanks responding so quickly and comprehensively, Tony!
I'm holding your !Boot file in reserve: I managed to decompress the
current ROOL .tar version using WinZip on the dark side, and have
copied it into Hostfs in place of the 5.17 !Boot (NOT using the
Boot-Install dialogue however - dragging the new !Boot into the Merge
field didn't work). I still have only two display options in
Configure-Screen: 'Auto' and the Acer AL2416W MDF which is one of the
supplied ones. All the other supplied MDFs are unavailable - God knows
why. ISTR with my Iyo that simply dragging a new MDF into
!Boot.Resources.Configure.Monitors made it available for selection.
On the bright side, the display configuration is now retained over
reboots, so all I have to do is work out how to make Configure-Screen
aware of my preferred MDF. Once again, thanks for your help and
support.
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 23 Apr 2013, george greenfield <george.greenfield@tiscali.co.uk> wrote:
>
> [snip]
>
>> So I'm stuck. Maybe it's best to revert to 5.17; at least it worked!
>> Unless you have a barebones !Boot from said HardDisc4 which you could
>> send me (suitably zipped: that at least works here)?
>
> I'm using Boot dated 27 Nov 2012 which may not work with the current ROM
> so try https://dl.dropbox.com/u/77062274/ro519_boot_20130206.zip [8MB]
> which is contained in the current HardDisc4 download (2013-04-03). I
> haven't tried it myself yet.
>
Many thanks responding so quickly and comprehensively, Tony!
I'm holding your !Boot file in reserve: I managed to decompress the
current ROOL .tar version using WinZip on the dark side, and have
copied it into Hostfs in place of the 5.17 !Boot (NOT using the
Boot-Install dialogue however - dragging the new !Boot into the Merge
field didn't work). I still have only two display options in
Configure-Screen: 'Auto' and the Acer AL2416W MDF which is one of the
supplied ones. All the other supplied MDFs are unavailable - God knows
why. ISTR with my Iyo that simply dragging a new MDF into
!Boot.Resources.Configure.Monitors made it available for selection.
On the bright side, the display configuration is now retained over
reboots, so all I have to do is work out how to make Configure-Screen
aware of my preferred MDF. Once again, thanks for your help and
support.
George
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] 5.19 doesn't retain monitor settings
On 23 Apr 2013, george greenfield <george.greenfield@tiscali.co.uk> wrote:
[snip]
> So I'm stuck. Maybe it's best to revert to 5.17; at least it worked!
> Unless you have a barebones !Boot from said HardDisc4 which you could
> send me (suitably zipped: that at least works here)?
I'm using Boot dated 27 Nov 2012 which may not work with the current ROM
so try https://dl.dropbox.com/u/77062274/ro519_boot_20130206.zip [8MB]
which is contained in the current HardDisc4 download (2013-04-03). I
haven't tried it myself yet.
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[snip]
> So I'm stuck. Maybe it's best to revert to 5.17; at least it worked!
> Unless you have a barebones !Boot from said HardDisc4 which you could
> send me (suitably zipped: that at least works here)?
I'm using Boot dated 27 Nov 2012 which may not work with the current ROM
so try https://dl.dropbox.com/u/77062274/ro519_boot_20130206.zip [8MB]
which is contained in the current HardDisc4 download (2013-04-03). I
haven't tried it myself yet.
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: New releases: NetSurf, LibCSS, Hubbub, etc
Is Jenkins supposed to be building (binary) releases now, or is it
still a manual process?
Chris
still a manual process?
Chris
Re: [Rpcemu] 5.19 doesn't retain monitor settings
In message <8825e54053.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 23 Apr 2013, george greenfield <george.greenfield@tiscali.co.uk>
> wrote:
>
>> I've just upgraded my 089/517 installation to 089/519, by replacing
>> the 517 rom with the 519 ditto in the RPCEmu-roms folder.
>>
>> The new installation starts with the usual black screen and more very
>> fast message scrolling than usual, but then displays at X640 Y480 C256
>> F (unknown). The previous (i.e. 517) !Boot file is still there
>
> I think that the problem is likely to be caused by the previous !Boot
> being incompatible with the current ROM. Try updating !Boot from
> HardDisc4 at http://www.riscosopen.org/content/downloads/other-zipfiles
>
> When I last did this I found that Configure... > Boot > Install fixed
> the installation, without hassle.
Thanks, Tony. TBH, I'm beginning to lose the will to live; I've tried
both the self-extracting and tarball versions of HardDisc4 with equal
lack of success; both extraction operations (carried out on my RPCEmu
089/402 installation) result in directory checksum errors when running
UnTarBZ2 (tarball) or 'Application may have gone wrong' error
messages (Utility filetype). Maybe RPCEmu is the issue. My Iyonix is
safely packed away in the loft. So I'm stuck. Maybe it's best to
revert to 5.17; at least it worked! Unless you have a barebones !Boot
from said HardDisc4 which you could send me (suitably zipped: that at
least works here)?
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 23 Apr 2013, george greenfield <george.greenfield@tiscali.co.uk>
> wrote:
>
>> I've just upgraded my 089/517 installation to 089/519, by replacing
>> the 517 rom with the 519 ditto in the RPCEmu-roms folder.
>>
>> The new installation starts with the usual black screen and more very
>> fast message scrolling than usual, but then displays at X640 Y480 C256
>> F (unknown). The previous (i.e. 517) !Boot file is still there
>
> I think that the problem is likely to be caused by the previous !Boot
> being incompatible with the current ROM. Try updating !Boot from
> HardDisc4 at http://www.riscosopen.org/content/downloads/other-zipfiles
>
> When I last did this I found that Configure... > Boot > Install fixed
> the installation, without hassle.
Thanks, Tony. TBH, I'm beginning to lose the will to live; I've tried
both the self-extracting and tarball versions of HardDisc4 with equal
lack of success; both extraction operations (carried out on my RPCEmu
089/402 installation) result in directory checksum errors when running
UnTarBZ2 (tarball) or 'Application may have gone wrong' error
messages (Utility filetype). Maybe RPCEmu is the issue. My Iyonix is
safely packed away in the loft. So I'm stuck. Maybe it's best to
revert to 5.17; at least it worked! Unless you have a barebones !Boot
from said HardDisc4 which you could send me (suitably zipped: that at
least works here)?
George
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Failed rendering of background image
The changes to NetSurf making it no longer abort the redraw if one of
the images within the rectangle fails to render have brought a
significant improvement in usability, but they don't seem to cover all
cases.
In particular, the old symptoms of white trails left by windows dragged
across the page in a certain direction are very visible on this page:
http://raphazlab.wordpress.com/
The offending image is the banner, which for some reason is inserted
into the CSS like so:
background: url('http://raphazlab.files.wordpress.com/2012/09/banner2012.jpg') no-repeat;
This appears to cause NetSurf to fail to implement its workaround, and
fall back on the old behaviour of aborting redraw.
Not really sure if that counts as a bug or not. It may well be
intentional. What would a suitable alternative behaviour for background
images be?
--
__<^>__
/ _ _ \ You always find something in the last place you look.
( ( |_| ) )
\_> <_/ ======================= Martin Bazley ==========================
the images within the rectangle fails to render have brought a
significant improvement in usability, but they don't seem to cover all
cases.
In particular, the old symptoms of white trails left by windows dragged
across the page in a certain direction are very visible on this page:
http://raphazlab.wordpress.com/
The offending image is the banner, which for some reason is inserted
into the CSS like so:
background: url('http://raphazlab.files.wordpress.com/2012/09/banner2012.jpg') no-repeat;
This appears to cause NetSurf to fail to implement its workaround, and
fall back on the old behaviour of aborting redraw.
Not really sure if that counts as a bug or not. It may well be
intentional. What would a suitable alternative behaviour for background
images be?
--
__<^>__
/ _ _ \ You always find something in the last place you look.
( ( |_| ) )
\_> <_/ ======================= Martin Bazley ==========================
New releases: NetSurf, LibCSS, Hubbub, etc
New releases have been made for the libraries:
LibCSS 0.2.0
LibDOM 0.0.1
LibHubbub 0.2.0
LibNSBMP 0.1.0
LibNSGIF 0.1.0
LibNSFB 0.1.0
LibParserUtils 0.1.2
LibPencil 0.0.2
LibROSprite 0.1.0
LibRUfl 0.0.2
LibSVGTiny 0.1.0
LibWapcaplet 0.2.0
http://download.netsurf-browser.org/libs/releases/
The new buildsystem used by all the libraries has been released:
Buildsystem 1.0
http://download.netsurf-browser.org/libs/releases/
The JavaScript to DOM binding generator has been released:
NSGenJSBind 0.0.1
http://download.netsurf-browser.org/libs/releases/
NetSurf 3.0 source release:
http://download.netsurf-browser.org/netsurf/releases/source/
NetSurf 3.0 full source release (inc. our libraries):
http://download.netsurf-browser.org/netsurf/releases/source-full/
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
LibCSS 0.2.0
LibDOM 0.0.1
LibHubbub 0.2.0
LibNSBMP 0.1.0
LibNSGIF 0.1.0
LibNSFB 0.1.0
LibParserUtils 0.1.2
LibPencil 0.0.2
LibROSprite 0.1.0
LibRUfl 0.0.2
LibSVGTiny 0.1.0
LibWapcaplet 0.2.0
http://download.netsurf-browser.org/libs/releases/
The new buildsystem used by all the libraries has been released:
Buildsystem 1.0
http://download.netsurf-browser.org/libs/releases/
The JavaScript to DOM binding generator has been released:
NSGenJSBind 0.0.1
http://download.netsurf-browser.org/libs/releases/
NetSurf 3.0 source release:
http://download.netsurf-browser.org/netsurf/releases/source/
NetSurf 3.0 full source release (inc. our libraries):
http://download.netsurf-browser.org/netsurf/releases/source-full/
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: [Rpcemu] 5.19 doesn't retain monitor settings
On 23 Apr 2013, george greenfield <george.greenfield@tiscali.co.uk>
wrote:
> I've just upgraded my 089/517 installation to 089/519, by replacing
> the 517 rom with the 519 ditto in the RPCEmu-roms folder.
>
> The new installation starts with the usual black screen and more very
> fast message scrolling than usual, but then displays at X640 Y480 C256
> F (unknown). The previous (i.e. 517) !Boot file is still there
I think that the problem is likely to be caused by the previous !Boot
being incompatible with the current ROM. Try updating !Boot from
HardDisc4 at http://www.riscosopen.org/content/downloads/other-zipfiles
When I last did this I found that Configure... > Boot > Install fixed
the installation, without hassle.
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
wrote:
> I've just upgraded my 089/517 installation to 089/519, by replacing
> the 517 rom with the 519 ditto in the RPCEmu-roms folder.
>
> The new installation starts with the usual black screen and more very
> fast message scrolling than usual, but then displays at X640 Y480 C256
> F (unknown). The previous (i.e. 517) !Boot file is still there
I think that the problem is likely to be caused by the previous !Boot
being incompatible with the current ROM. Try updating !Boot from
HardDisc4 at http://www.riscosopen.org/content/downloads/other-zipfiles
When I last did this I found that Configure... > Boot > Install fixed
the installation, without hassle.
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] 5.19 doesn't retain monitor settings - PS
PS: I should add that an error message 'Can't save screen mode because
resolution or colours is unknown' appears when attempting to save a
selected new display size.
Also, the error message 'File '<PCAResources$Dir>.!Sprites' not found'
appears after the grey desktop but before the screen backdrop
displays; clicking on OK allows booting to complete.
---------- Begin forwarded message ----------
Date: Tue, 23 Apr 2013 12:08:01 +0100
From: george greenfield <george.greenfield@tiscali.co.uk>
To: rpcemu@riscos.info
Subject: 5.19 doesn't retain monitor settings
I've just upgraded my 089/517 installation to 089/519, by replacing
the 517 rom with the 519 ditto in the RPCEmu-roms folder.
The new installation starts with the usual black screen and more very
fast message scrolling than usual, but then displays at X640 Y480 C256
F (unknown). The previous (i.e. 517) !Boot file is still there, and
this has x1824 Y1026 C16M F58 in
Boot.Choices.Boot.Predesk.Configure.Monitor; RO500Hook has X800 Y600
C256 (AKF60) in the same location, and RO510Hook has the same X and Y
values with C16M (ROOL Generic), but the starting display conforms to
none of these values.
If I select the Configure-Screen dialogue by menu-ing over the RISC OS
5 icon some (but not all) of the MDFs listed in
Boot.Resources.Configure.Monitor are shown, and I can select (for
example) X1280 Y1024 C16M and the display size changes, but it is not
retained after a reset: the display reverts to X640 Y480 C256.
I have done F12 *configure filesystem hostfs and *configure boot.
Apps etc all seem to load and function OK, so it is just this problem
preventing me from getting a usable system. Any advice would be most
welcome as I'm not sure what to try next! TIA,
George
--
george greenfield
----------- End forwarded message -----------
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
resolution or colours is unknown' appears when attempting to save a
selected new display size.
Also, the error message 'File '<PCAResources$Dir>.!Sprites' not found'
appears after the grey desktop but before the screen backdrop
displays; clicking on OK allows booting to complete.
---------- Begin forwarded message ----------
Date: Tue, 23 Apr 2013 12:08:01 +0100
From: george greenfield <george.greenfield@tiscali.co.uk>
To: rpcemu@riscos.info
Subject: 5.19 doesn't retain monitor settings
I've just upgraded my 089/517 installation to 089/519, by replacing
the 517 rom with the 519 ditto in the RPCEmu-roms folder.
The new installation starts with the usual black screen and more very
fast message scrolling than usual, but then displays at X640 Y480 C256
F (unknown). The previous (i.e. 517) !Boot file is still there, and
this has x1824 Y1026 C16M F58 in
Boot.Choices.Boot.Predesk.Configure.Monitor; RO500Hook has X800 Y600
C256 (AKF60) in the same location, and RO510Hook has the same X and Y
values with C16M (ROOL Generic), but the starting display conforms to
none of these values.
If I select the Configure-Screen dialogue by menu-ing over the RISC OS
5 icon some (but not all) of the MDFs listed in
Boot.Resources.Configure.Monitor are shown, and I can select (for
example) X1280 Y1024 C16M and the display size changes, but it is not
retained after a reset: the display reverts to X640 Y480 C256.
I have done F12 *configure filesystem hostfs and *configure boot.
Apps etc all seem to load and function OK, so it is just this problem
preventing me from getting a usable system. Any advice would be most
welcome as I'm not sure what to try next! TIA,
George
--
george greenfield
----------- End forwarded message -----------
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] 5.19 doesn't retain monitor settings
I've just upgraded my 089/517 installation to 089/519, by replacing
the 517 rom with the 519 ditto in the RPCEmu-roms folder.
The new installation starts with the usual black screen and more very
fast message scrolling than usual, but then displays at X640 Y480 C256
F (unknown). The previous (i.e. 517) !Boot file is still there, and
this has x1824 Y1026 C16M F58 in
Boot.Choices.Boot.Predesk.Configure.Monitor; RO500Hook has X800 Y600
C256 (AKF60) in the same location, and RO510Hook has the same X and Y
values with C16M (ROOL Generic), but the starting display conforms to
none of these values.
If I select the Configure-Screen dialogue by menu-ing over the RISC OS
5 icon some (but not all) of the MDFs listed in
Boot.Resources.Configure.Monitor are shown, and I can select (for
example) X1280 Y1024 C16M and the display size changes, but it is not
retained after a reset: the display reverts to X640 Y480 C256.
I have done F12 *configure filesystem hostfs and *configure boot.
Apps etc all seem to load and function OK, so it is just this problem
preventing me from getting a usable system. Any advice would be most
welcome as I'm not sure what to try next! TIA,
George
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
the 517 rom with the 519 ditto in the RPCEmu-roms folder.
The new installation starts with the usual black screen and more very
fast message scrolling than usual, but then displays at X640 Y480 C256
F (unknown). The previous (i.e. 517) !Boot file is still there, and
this has x1824 Y1026 C16M F58 in
Boot.Choices.Boot.Predesk.Configure.Monitor; RO500Hook has X800 Y600
C256 (AKF60) in the same location, and RO510Hook has the same X and Y
values with C16M (ROOL Generic), but the starting display conforms to
none of these values.
If I select the Configure-Screen dialogue by menu-ing over the RISC OS
5 icon some (but not all) of the MDFs listed in
Boot.Resources.Configure.Monitor are shown, and I can select (for
example) X1280 Y1024 C16M and the display size changes, but it is not
retained after a reset: the display reverts to X640 Y480 C256.
I have done F12 *configure filesystem hostfs and *configure boot.
Apps etc all seem to load and function OK, so it is just this problem
preventing me from getting a usable system. Any advice would be most
welcome as I'm not sure what to try next! TIA,
George
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: downloading older development versions
On 23 Apr 2013, Vincent Sanders <vince@netsurf-browser.org> wrote:
> On Mon, Apr 22, 2013 at 01:12:08PM +0000, Tony Moore wrote:
[snip]
> > I would like to determine the version in which the problem first
> > occurs but I cannot find any way of downloading versions prior to
> > those listed at http://ci.netsurf-browser.org/builds/riscos/
> >
> > Could someone please suggest how this may be done?
>
> It cannot, the CI service only keeps the last 25 builds
>
> However:
[snip]
> git log 38a9c374a4685c6b06625e63c3e305101e531d81..61a2b8ddc452b915925793f4f538dbb2ca9b5ba5
>
> shows all changes between them
>
> I have added teh list to the bug
Many thanks for the response, and for the log. Unfortunately, I'm none
the wiser since none of the log descriptions suggests - to me, a user -
that it might be responsible for the problem.
I wonder if anyone else, who uses Yahoo Mail, can replicate this:
On the log-in screen, enter ID and Password, click 'Sign In'
This leads to a screen which says
If you are seeing this page, your browser settings prevent you from
automatically redirecting to a new URL.
Please click here to continue.
Notwithstanding the warning, older versions of NetSurf _do_ redirect,
and display the webmail page, as expected. The current version (#1083
json, or jsoff) displays a 'Warning from NetSurf' saying 'BadType',
and no redirection.
For me this is a nuisance, rather than a show-stopper, since I normally
use pop/smtp, but I need to remember to load #417, to access the Spam
folder, etc.
Tony
> On Mon, Apr 22, 2013 at 01:12:08PM +0000, Tony Moore wrote:
[snip]
> > I would like to determine the version in which the problem first
> > occurs but I cannot find any way of downloading versions prior to
> > those listed at http://ci.netsurf-browser.org/builds/riscos/
> >
> > Could someone please suggest how this may be done?
>
> It cannot, the CI service only keeps the last 25 builds
>
> However:
[snip]
> git log 38a9c374a4685c6b06625e63c3e305101e531d81..61a2b8ddc452b915925793f4f538dbb2ca9b5ba5
>
> shows all changes between them
>
> I have added teh list to the bug
Many thanks for the response, and for the log. Unfortunately, I'm none
the wiser since none of the log descriptions suggests - to me, a user -
that it might be responsible for the problem.
I wonder if anyone else, who uses Yahoo Mail, can replicate this:
On the log-in screen, enter ID and Password, click 'Sign In'
This leads to a screen which says
If you are seeing this page, your browser settings prevent you from
automatically redirecting to a new URL.
Please click here to continue.
Notwithstanding the warning, older versions of NetSurf _do_ redirect,
and display the webmail page, as expected. The current version (#1083
json, or jsoff) displays a 'Warning from NetSurf' saying 'BadType',
and no redirection.
For me this is a nuisance, rather than a show-stopper, since I normally
use pop/smtp, but I need to remember to load #417, to access the Spam
folder, etc.
Tony
Re: downloading older development versions
On Mon, Apr 22, 2013 at 01:12:08PM +0000, Tony Moore wrote:
> Between NetSurf #417 (9 Oct 2012) and #461 (13 Oct 2012), it became
> impossilbe to log-in to Yahoo webmail because, apparently, redirection
> failed. I reported the problem
> https://sourceforge.net/tracker/?func=detail&aid=3579166&group_id=51719&atid=464312
> but it persists, as of today, in #1083.
>
> I would like to determine the version in which the problem first occurs
> but I cannot find any way of downloading versions prior to those listed
> at http://ci.netsurf-browser.org/builds/riscos/
>
> Could someone please suggest how this may be done?
It cannot, the CI service only keeps the last 25 builds
However:
build #417 was at commit 38a9c374a4685c6b06625e63c3e305101e531d81
build #461 was at commit 61a2b8ddc452b915925793f4f538dbb2ca9b5ba5
and
git log 38a9c374a4685c6b06625e63c3e305101e531d81..61a2b8ddc452b915925793f4f538dbb2ca9b5ba5
shows all changes between them
I have added teh list to the bug
>
> Tony
>
>
>
>
>
--
Regards Vincent
http://www.kyllikki.org/
> Between NetSurf #417 (9 Oct 2012) and #461 (13 Oct 2012), it became
> impossilbe to log-in to Yahoo webmail because, apparently, redirection
> failed. I reported the problem
> https://sourceforge.net/tracker/?func=detail&aid=3579166&group_id=51719&atid=464312
> but it persists, as of today, in #1083.
>
> I would like to determine the version in which the problem first occurs
> but I cannot find any way of downloading versions prior to those listed
> at http://ci.netsurf-browser.org/builds/riscos/
>
> Could someone please suggest how this may be done?
It cannot, the CI service only keeps the last 25 builds
However:
build #417 was at commit 38a9c374a4685c6b06625e63c3e305101e531d81
build #461 was at commit 61a2b8ddc452b915925793f4f538dbb2ca9b5ba5
and
git log 38a9c374a4685c6b06625e63c3e305101e531d81..61a2b8ddc452b915925793f4f538dbb2ca9b5ba5
shows all changes between them
I have added teh list to the bug
>
> Tony
>
>
>
>
>
--
Regards Vincent
http://www.kyllikki.org/
Monday, 22 April 2013
Re: Squashed image problem
On 22 Apr 2013 Tim Hill wrote:
>> I have reported this to
>> the council but I won't hold my breath for a correction.
> Seems okay two days later, Monday.
Yes, I've now had a message to say they've resized the images.
>> The problem is that as soon as these images hove into view the page
>> becomes incredibly slow and clunky to move around. ... Would it be
>> possible to resize the images once when they are downloaded and then
>> hold them at the required display size?
> I tend to agree but what if the page is zoomed?
In that case the whole page is scaled up or down, not just specific
images, but I don't know what approach is taken to that problem.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
>> I have reported this to
>> the council but I won't hold my breath for a correction.
> Seems okay two days later, Monday.
Yes, I've now had a message to say they've resized the images.
>> The problem is that as soon as these images hove into view the page
>> becomes incredibly slow and clunky to move around. ... Would it be
>> possible to resize the images once when they are downloaded and then
>> hold them at the required display size?
> I tend to agree but what if the page is zoomed?
In that case the whole page is scaled up or down, not just specific
images, but I don't know what approach is taken to that problem.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
downloading older development versions
Between NetSurf #417 (9 Oct 2012) and #461 (13 Oct 2012), it became
impossilbe to log-in to Yahoo webmail because, apparently, redirection
failed. I reported the problem
https://sourceforge.net/tracker/?func=detail&aid=3579166&group_id=51719&atid=464312
but it persists, as of today, in #1083.
I would like to determine the version in which the problem first occurs
but I cannot find any way of downloading versions prior to those listed
at http://ci.netsurf-browser.org/builds/riscos/
Could someone please suggest how this may be done?
Tony
impossilbe to log-in to Yahoo webmail because, apparently, redirection
failed. I reported the problem
https://sourceforge.net/tracker/?func=detail&aid=3579166&group_id=51719&atid=464312
but it persists, as of today, in #1083.
I would like to determine the version in which the problem first occurs
but I cannot find any way of downloading versions prior to those listed
at http://ci.netsurf-browser.org/builds/riscos/
Could someone please suggest how this may be done?
Tony
Re: Squashed image problem
In article <b30c843f53.ricp@user.minijem.plus.com>, Richard Porter
<ricp@minijem.plus.com> wrote:
> I've encountered a minor irritation caused by a stupid web authoring
> mistake. The RBWM Recycling page at
> http://www.rbwm.gov.uk/web/wm_recycling.htm contains two images which
> are delivered at 2440 x 1479 px and displayed at 122 x 89 px - the
> files are 340 times the size they need to be!
LOL. I used to be sent word files like that. Tens of pages in a document
with the same massive corporate logo image on every page. "We must" I was
told.
> I have reported this to
> the council but I won't hold my breath for a correction.
Seems okay two days later, Monday.
> The problem is that as soon as these images hove into view the page
> becomes incredibly slow and clunky to move around. I would hazard a
> guess that NS is continually struggling to resize the images as it
> tries to move them around. Would it be possible to resize the images
> once when they are downloaded and then hold them at the required
> display size?
I tend to agree but what if the page is zoomed?
<ricp@minijem.plus.com> wrote:
> I've encountered a minor irritation caused by a stupid web authoring
> mistake. The RBWM Recycling page at
> http://www.rbwm.gov.uk/web/wm_recycling.htm contains two images which
> are delivered at 2440 x 1479 px and displayed at 122 x 89 px - the
> files are 340 times the size they need to be!
LOL. I used to be sent word files like that. Tens of pages in a document
with the same massive corporate logo image on every page. "We must" I was
told.
> I have reported this to
> the council but I won't hold my breath for a correction.
Seems okay two days later, Monday.
> The problem is that as soon as these images hove into view the page
> becomes incredibly slow and clunky to move around. I would hazard a
> guess that NS is continually struggling to resize the images as it
> tries to move them around. Would it be possible to resize the images
> once when they are downloaded and then hold them at the required
> display size?
I tend to agree but what if the page is zoomed?
Sunday, 21 April 2013
Re: [Bulk] Squashed image problem
On 21 Apr 2013 Rob Kendrick wrote:
> On Sun, Apr 21, 2013 at 10:06:49AM +0100, Richard Porter wrote:
>> I don't think there's anything I can do other than that. I was
>> wondering whether there's a design reason why NS doesn't keep a copy
>> of the resized image in its cache, which would save a lot of
>> processing time in such circumstances.
> Choices -> Cache -> Enter suitably large number. Shoving 40MB in here
> makes the page scroll smoothly where with the default value it did not.
I've tried 40MB but it doesn't make any difference. I did quit and
restart NS in case that mattered, but as soon as I hit the large image
files it was like scrolling through treacle.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
> On Sun, Apr 21, 2013 at 10:06:49AM +0100, Richard Porter wrote:
>> I don't think there's anything I can do other than that. I was
>> wondering whether there's a design reason why NS doesn't keep a copy
>> of the resized image in its cache, which would save a lot of
>> processing time in such circumstances.
> Choices -> Cache -> Enter suitably large number. Shoving 40MB in here
> makes the page scroll smoothly where with the default value it did not.
I've tried 40MB but it doesn't make any difference. I did quit and
restart NS in case that mattered, but as soon as I hit the large image
files it was like scrolling through treacle.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Re: [Bulk] Squashed image problem
On Sun, Apr 21, 2013 at 10:06:49AM +0100, Richard Porter wrote:
> I don't think there's anything I can do other than that. I was
> wondering whether there's a design reason why NS doesn't keep a copy
> of the resized image in its cache, which would save a lot of
> processing time in such circumstances.
Choices -> Cache -> Enter suitably large number. Shoving 40MB in here
makes the page scroll smoothly where with the default value it did not.
B.
> I don't think there's anything I can do other than that. I was
> wondering whether there's a design reason why NS doesn't keep a copy
> of the resized image in its cache, which would save a lot of
> processing time in such circumstances.
Choices -> Cache -> Enter suitably large number. Shoving 40MB in here
makes the page scroll smoothly where with the default value it did not.
B.
Re: [Bulk] Squashed image problem
On 21 Apr 2013 Brian Jordan wrote:
> In article <b30c843f53.ricp@user.minijem.plus.com>,
> Richard Porter <ricp@minijem.plus.com> wrote:
> [Snip]
>> The problem is that as soon as these images hove into view the page
>> becomes incredibly slow and clunky to move around. I would hazard a
>> guess that NS is continually struggling to resize the images as it
>> tries to move them around.
> Almost certainly you hazard correctly. I have just done a Full save of
> the page and resized the offending images. On reloading, the page moves
> around and scrolls very smoothly.
>> Would it be possible to resize the images once when they are downloaded
>> and then hold them at the required display size?
> Apart from using Full save I can't think of another way and that's
> probably not what you want.
I don't think there's anything I can do other than that. I was
wondering whether there's a design reason why NS doesn't keep a copy
of the resized image in its cache, which would save a lot of
processing time in such circumstances.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
> In article <b30c843f53.ricp@user.minijem.plus.com>,
> Richard Porter <ricp@minijem.plus.com> wrote:
> [Snip]
>> The problem is that as soon as these images hove into view the page
>> becomes incredibly slow and clunky to move around. I would hazard a
>> guess that NS is continually struggling to resize the images as it
>> tries to move them around.
> Almost certainly you hazard correctly. I have just done a Full save of
> the page and resized the offending images. On reloading, the page moves
> around and scrolls very smoothly.
>> Would it be possible to resize the images once when they are downloaded
>> and then hold them at the required display size?
> Apart from using Full save I can't think of another way and that's
> probably not what you want.
I don't think there's anything I can do other than that. I was
wondering whether there's a design reason why NS doesn't keep a copy
of the resized image in its cache, which would save a lot of
processing time in such circumstances.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Saturday, 20 April 2013
Re: [Bulk] Squashed image problem
In article <b30c843f53.ricp@user.minijem.plus.com>,
Richard Porter <ricp@minijem.plus.com> wrote:
[Snip]
> The problem is that as soon as these images hove into view the page
> becomes incredibly slow and clunky to move around. I would hazard a
> guess that NS is continually struggling to resize the images as it
> tries to move them around.
Almost certainly you hazard correctly. I have just done a Full save of
the page and resized the offending images. On reloading, the page moves
around and scrolls very smoothly.
> Would it be possible to resize the images once when they are downloaded
> and then hold them at the required display size?
Apart from using Full save I can't think of another way and that's
probably not what you want.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA
RISC OS 6.20
_____________________________________________________________________
Richard Porter <ricp@minijem.plus.com> wrote:
[Snip]
> The problem is that as soon as these images hove into view the page
> becomes incredibly slow and clunky to move around. I would hazard a
> guess that NS is continually struggling to resize the images as it
> tries to move them around.
Almost certainly you hazard correctly. I have just done a Full save of
the page and resized the offending images. On reloading, the page moves
around and scrolls very smoothly.
> Would it be possible to resize the images once when they are downloaded
> and then hold them at the required display size?
Apart from using Full save I can't think of another way and that's
probably not what you want.
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA
RISC OS 6.20
_____________________________________________________________________
Squashed image problem
I've encountered a minor irritation caused by a stupid web authoring
mistake. The RBWM Recycling page at
http://www.rbwm.gov.uk/web/wm_recycling.htm
contains two images which are delivered at 2440 x 1479 px and
displayed at 122 x 89 px - the files are 340 times the size they need
to be! I have reported this to the council but I won't hold my breath
for a correction.
The problem is that as soon as these images hove into view the page
becomes incredibly slow and clunky to move around. I would hazard a
guess that NS is continually struggling to resize the images as it
tries to move them around. Would it be possible to resize the images
once when they are downloaded and then hold them at the required
display size?
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
mistake. The RBWM Recycling page at
http://www.rbwm.gov.uk/web/wm_recycling.htm
contains two images which are delivered at 2440 x 1479 px and
displayed at 122 x 89 px - the files are 340 times the size they need
to be! I have reported this to the council but I won't hold my breath
for a correction.
The problem is that as soon as these images hove into view the page
becomes incredibly slow and clunky to move around. I would hazard a
guess that NS is continually struggling to resize the images as it
tries to move them around. Would it be possible to resize the images
once when they are downloaded and then hold them at the required
display size?
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Thursday, 18 April 2013
Fwd: Oops very sorry!
Anyone have objections?
J
Begin forwarded message:
> From: Chris Evans <chris@cjemicros.co.uk>
> Subject: Oops very sorry!
> Date: 17 April 2013 11:15:56 BST
> To: webmaster@zap.tartarus.org
> Cc: ds@zap.tartarus.org
>
>
> I hope I made you laugh with my mistake in the last email.
>
> I blame it on still suffering the after effects of the flu.
>
> Subject: Permission to include ZAP on a commercial product
>
> We (CJE Micro's / 4D) are offering/planning to offer 'commercial' products
> including systems based on The Raspberry Pi & Pandaboard.
>
> We would like to include Zap and its related components on the 'Disc Image'.
> Can we have your permission to do so?
>
>
> Chris Evans
>
> --
> CJE Micro's / 4D 'RISC OS Specialists'
> Telephone: 01903 523222 Fax: 01903 523679
> chris@cjemicros.co.uk http://www.cjemicros.co.uk/
> 78 Brighton Road, Worthing, West Sussex, BN11 2EN
> The most beautiful thing anyone can wear, is a smile!
>
>
--
James Aylett
Writing: nsfwcorp.com; film: talktorex.co.uk
Also: devfort.com, spacelog.org, xapian.org
--
_______________________________________________
zap-technical maillist - zap-technical@zap.tartarus.org
http://lists.tartarus.org/mailman/listinfo/zap-technical
J
Begin forwarded message:
> From: Chris Evans <chris@cjemicros.co.uk>
> Subject: Oops very sorry!
> Date: 17 April 2013 11:15:56 BST
> To: webmaster@zap.tartarus.org
> Cc: ds@zap.tartarus.org
>
>
> I hope I made you laugh with my mistake in the last email.
>
> I blame it on still suffering the after effects of the flu.
>
> Subject: Permission to include ZAP on a commercial product
>
> We (CJE Micro's / 4D) are offering/planning to offer 'commercial' products
> including systems based on The Raspberry Pi & Pandaboard.
>
> We would like to include Zap and its related components on the 'Disc Image'.
> Can we have your permission to do so?
>
>
> Chris Evans
>
> --
> CJE Micro's / 4D 'RISC OS Specialists'
> Telephone: 01903 523222 Fax: 01903 523679
> chris@cjemicros.co.uk http://www.cjemicros.co.uk/
> 78 Brighton Road, Worthing, West Sussex, BN11 2EN
> The most beautiful thing anyone can wear, is a smile!
>
>
--
James Aylett
Writing: nsfwcorp.com; film: talktorex.co.uk
Also: devfort.com, spacelog.org, xapian.org
--
_______________________________________________
zap-technical maillist - zap-technical@zap.tartarus.org
http://lists.tartarus.org/mailman/listinfo/zap-technical
Wednesday, 17 April 2013
Re: Line wrap
On 17 Apr 2013 Richard Torrens (lists) wrote:
> Might it help if we users made a list of places where line-wrap can
> occur?
> Clearly at any white space.
Which means any combination of Space, HT, LF, CR.
> Hyphens?
Yes, except a hyphen immediately preceding a number i.e. a minus sign.
A hyphenated word can be split after the hyphen, not before.
> Any other place?
None that I can think of.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
> Might it help if we users made a list of places where line-wrap can
> occur?
> Clearly at any white space.
Which means any combination of Space, HT, LF, CR.
> Hyphens?
Yes, except a hyphen immediately preceding a number i.e. a minus sign.
A hyphenated word can be split after the hyphen, not before.
> Any other place?
None that I can think of.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Re: [gccsdk] RISC_OSLib in GCC?
In article <4103f43d53.Jo@hobbes.bass-software.com>,
John Tytgat <John.Tytgat@aaug.net> wrote:
> In message <533de90ec6chrisg@care4free.net>
> Chris Gransden <chrisg@care4free.net> wrote:
> > I've built and used successfuly a hard-float ELF version of RISC_OSLib with
> > GCC 4.1.2.
> That's using SCL then, right ?
That's right. I did try to link pluto with unixlib but there's a dependency
on SCL with flex in RISC_OSLib and some fp state saving assembler to do
wimp_poll and wimp_pollidle.
> > I haven't finished creating a recipe for the autobuilder yet. Shouldn't be
> > too much longer hopefully.
> > I tested it by building the recently released source for !Pluto. Seems to
> > be working ok so far.
> Nice. And I assume you've used asasm for the assembler code in Pluto ?
asasm worked fine with the assembler code in Pluto.
Chris.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
John Tytgat <John.Tytgat@aaug.net> wrote:
> In message <533de90ec6chrisg@care4free.net>
> Chris Gransden <chrisg@care4free.net> wrote:
> > I've built and used successfuly a hard-float ELF version of RISC_OSLib with
> > GCC 4.1.2.
> That's using SCL then, right ?
That's right. I did try to link pluto with unixlib but there's a dependency
on SCL with flex in RISC_OSLib and some fp state saving assembler to do
wimp_poll and wimp_pollidle.
> > I haven't finished creating a recipe for the autobuilder yet. Shouldn't be
> > too much longer hopefully.
> > I tested it by building the recently released source for !Pluto. Seems to
> > be working ok so far.
> Nice. And I assume you've used asasm for the assembler code in Pluto ?
asasm worked fine with the assembler code in Pluto.
Chris.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] RISC_OSLib in GCC?
In message <533de90ec6chrisg@care4free.net>
Chris Gransden <chrisg@care4free.net> wrote:
> I've built and used successfuly a hard-float ELF version of RISC_OSLib with
> GCC 4.1.2.
That's using SCL then, right ?
> I haven't finished creating a recipe for the autobuilder yet. Shouldn't be
> too much longer hopefully.
> I tested it by building the recently released source for !Pluto. Seems to
> be working ok so far.
Nice. And I assume you've used asasm for the assembler code in Pluto ?
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
Chris Gransden <chrisg@care4free.net> wrote:
> I've built and used successfuly a hard-float ELF version of RISC_OSLib with
> GCC 4.1.2.
That's using SCL then, right ?
> I haven't finished creating a recipe for the autobuilder yet. Shouldn't be
> too much longer hopefully.
> I tested it by building the recently released source for !Pluto. Seems to
> be working ok so far.
Nice. And I assume you've used asasm for the assembler code in Pluto ?
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] RISC_OSLib in GCC?
In article <20130416225306.GL28627@chiark.greenend.org.uk>,
Theo Markettos <theo@markettos.org.uk> wrote:
> Has anyone succeeded in using RISC_OSLib with GCC? I thought there was an
> autobuilder package, but it appears not.
> 'Used' can mean several things:
> 1. Linking the supplied AOF binaries with GCC AOF output
> 2. The same with ELF output
> 3. Building RISC_OSLib with GCC on RISC OS
> 4. The same but building with GCCSDK
> My interest is mostly 4 but I'll accept 2 if I can pull the binaries into
> the autobuilder.
I've built and used successfuly a hard-float ELF version of RISC_OSLib with
GCC 4.1.2.
I haven't finished creating a recipe for the autobuilder yet. Shouldn't be
too much longer hopefully.
I tested it by building the recently released source for !Pluto. Seems to
be working ok so far.
Which version of RISC_OSLib did you want, hard-float or soft-float?
Chris.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Theo Markettos <theo@markettos.org.uk> wrote:
> Has anyone succeeded in using RISC_OSLib with GCC? I thought there was an
> autobuilder package, but it appears not.
> 'Used' can mean several things:
> 1. Linking the supplied AOF binaries with GCC AOF output
> 2. The same with ELF output
> 3. Building RISC_OSLib with GCC on RISC OS
> 4. The same but building with GCCSDK
> My interest is mostly 4 but I'll accept 2 if I can pull the binaries into
> the autobuilder.
I've built and used successfuly a hard-float ELF version of RISC_OSLib with
GCC 4.1.2.
I haven't finished creating a recipe for the autobuilder yet. Shouldn't be
too much longer hopefully.
I tested it by building the recently released source for !Pluto. Seems to
be working ok so far.
Which version of RISC_OSLib did you want, hard-float or soft-float?
Chris.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Line wrap
Might it help if we users made a list of places where line-wrap can
occur?
Clearly at any white space.
Hyphens?
Any other place?
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
occur?
Clearly at any white space.
Hyphens?
Any other place?
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
Re: Line wrap
On 17 Apr 2013 Dave Higton wrote:
>> I've had a bug report out on this for years. It's always been a
>> problem for as long as I can remember. NS will wrap lines at any tag
>> or escaped character or possibly any non-alphanumeric character where
>> there is no white space and no hyphen.
> I put in a bug report a few days ago because it will wrap at
> apostrophes.
My report was no. 1458451 raised on 25-03-2006.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
>> I've had a bug report out on this for years. It's always been a
>> problem for as long as I can remember. NS will wrap lines at any tag
>> or escaped character or possibly any non-alphanumeric character where
>> there is no white space and no hyphen.
> I put in a bug report a few days ago because it will wrap at
> apostrophes.
My report was no. 1458451 raised on 25-03-2006.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Re: Line wrap
On 17 Apr 2013 Richard Torrens (lists) wrote:
> On 17 Apr 2013 Richard Torrens (lists) wrote:
>
>> I'm using 1048.
>
>> The line wrapping is a little odd. For instance on a www page I have
>> includes:
>> "The MOSFETs we are using in 2012 have a <b>maximum</b>
>> R<sub>ds(on)</sub> of around 6 milliohms."
>
>> If width is such, Netsurf will break the line before the <sub> -
>> effectively in the middle of a word.
>
> I've had a bug report out on this for years. It's always been a
> problem for as long as I can remember. NS will wrap lines at any tag
> or escaped character or possibly any non-alphanumeric character where
> there is no white space and no hyphen.
I put in a bug report a few days ago because it will wrap at
apostrophes.
Dave
____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!
> On 17 Apr 2013 Richard Torrens (lists) wrote:
>
>> I'm using 1048.
>
>> The line wrapping is a little odd. For instance on a www page I have
>> includes:
>> "The MOSFETs we are using in 2012 have a <b>maximum</b>
>> R<sub>ds(on)</sub> of around 6 milliohms."
>
>> If width is such, Netsurf will break the line before the <sub> -
>> effectively in the middle of a word.
>
> I've had a bug report out on this for years. It's always been a
> problem for as long as I can remember. NS will wrap lines at any tag
> or escaped character or possibly any non-alphanumeric character where
> there is no white space and no hyphen.
I put in a bug report a few days ago because it will wrap at
apostrophes.
Dave
____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!
Re: Line wrap
On 17 Apr 2013 Richard Torrens (lists) wrote:
> I'm using 1048.
> The line wrapping is a little odd. For instance on a www page I have
> includes:
> "The MOSFETs we are using in 2012 have a <b>maximum</b>
> R<sub>ds(on)</sub> of around 6 milliohms."
> If width is such, Netsurf will break the line before the <sub> -
> effectively in the middle of a word.
I've had a bug report out on this for years. It's always been a
problem for as long as I can remember. NS will wrap lines at any tag
or escaped character or possibly any non-alphanumeric character where
there is no white space and no hyphen.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
> I'm using 1048.
> The line wrapping is a little odd. For instance on a www page I have
> includes:
> "The MOSFETs we are using in 2012 have a <b>maximum</b>
> R<sub>ds(on)</sub> of around 6 milliohms."
> If width is such, Netsurf will break the line before the <sub> -
> effectively in the middle of a word.
I've had a bug report out on this for years. It's always been a
problem for as long as I can remember. NS will wrap lines at any tag
or escaped character or possibly any non-alphanumeric character where
there is no white space and no hyphen.
--
Richard Porter http://www.minijem.plus.com/
mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Line wrap
I'm using 1048.
The line wrapping is a little odd. For instance on a www page I have
includes:
"The MOSFETs we are using in 2012 have a <b>maximum</b>
R<sub>ds(on)</sub> of around 6 milliohms."
If width is such, Netsurf will break the line before the <sub> -
effectively in the middle of a word.
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
The line wrapping is a little odd. For instance on a www page I have
includes:
"The MOSFETs we are using in 2012 have a <b>maximum</b>
R<sub>ds(on)</sub> of around 6 milliohms."
If width is such, Netsurf will break the line before the <sub> -
effectively in the middle of a word.
--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!
Tuesday, 16 April 2013
[gccsdk] RISC_OSLib in GCC?
Has anyone succeeded in using RISC_OSLib with GCC? I thought there was an
autobuilder package, but it appears not.
'Used' can mean several things:
1. Linking the supplied AOF binaries with GCC AOF output
2. The same with ELF output
3. Building RISC_OSLib with GCC on RISC OS
4. The same but building with GCCSDK
My interest is mostly 4 but I'll accept 2 if I can pull the binaries into
the autobuilder.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
autobuilder package, but it appears not.
'Used' can mean several things:
1. Linking the supplied AOF binaries with GCC AOF output
2. The same with ELF output
3. Building RISC_OSLib with GCC on RISC OS
4. The same but building with GCCSDK
My interest is mostly 4 but I'll accept 2 if I can pull the binaries into
the autobuilder.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: NetSurf on Virtual Acorn
In message <533d3d5a8btlsa@netsurf-browser.org> Michael Drake wrote:
> In article <op.wrhukyovif396l@alansall>,
> Alan & Sally <jared.r@xtra.co.nz> wrote:
>> NetSurf 2.9 runs nicely on this set up but I have had no luck with any
>> of the later development versions. I have just downloaded 3.0 Dev #833
>> with the same result.
> It seems that since NetSurf 2.9 DNS doesn't work when running on
> VirtualRPC. It works on real hardware and, I believe, on RPCEmu (can
> anyone confirm?).
I use recent dev builds on VRPC-SA and VRPC-SE and DNS
is fine. The only issue I have is that when I connect to
the company VPN (Cisco software) the DNS breaks and
nothing will resolve. As soon as I disconnect the VPN it
works again.
When NS DNS lookups fail, the Windows7 apps like Firefox
seem to do DNS lookups OK. Since the resolver addresses
are as far as I can see identical in both Windows side
and RISC OS I don't know how it breaks. Other networking
such as connection to mail server and NFS mounts all
continue working and its only DNS that seems to be broken.
> None of the NetSurf developers have VirtualRPC so we aren't in a position
> to investigate this. Perhaps you could contact the VirtualRPC developers,
> if it's still being maintained?
If you want to try anything, pass it my way. I'm using
VRPC and NS all day every day at home and at work.
Mike
> In article <op.wrhukyovif396l@alansall>,
> Alan & Sally <jared.r@xtra.co.nz> wrote:
>> NetSurf 2.9 runs nicely on this set up but I have had no luck with any
>> of the later development versions. I have just downloaded 3.0 Dev #833
>> with the same result.
> It seems that since NetSurf 2.9 DNS doesn't work when running on
> VirtualRPC. It works on real hardware and, I believe, on RPCEmu (can
> anyone confirm?).
I use recent dev builds on VRPC-SA and VRPC-SE and DNS
is fine. The only issue I have is that when I connect to
the company VPN (Cisco software) the DNS breaks and
nothing will resolve. As soon as I disconnect the VPN it
works again.
When NS DNS lookups fail, the Windows7 apps like Firefox
seem to do DNS lookups OK. Since the resolver addresses
are as far as I can see identical in both Windows side
and RISC OS I don't know how it breaks. Other networking
such as connection to mail server and NFS mounts all
continue working and its only DNS that seems to be broken.
> None of the NetSurf developers have VirtualRPC so we aren't in a position
> to investigate this. Perhaps you could contact the VirtualRPC developers,
> if it's still being maintained?
If you want to try anything, pass it my way. I'm using
VRPC and NS all day every day at home and at work.
Mike
Re: NetSurf on Virtual Acorn
In article <mpro.mlci0m00alw3701n5.pittdj@pittdj.co.uk>,
David Pitt <pittdj@pittdj.co.uk> wrote:
> I can confirm that the current NetSurf 3.0 test builds do resolve on
> RPCEmu v0.8.9 on Mac OS X 10.8.3.
> The i686-darwin10 builds also resolve running natively on the Mac.
> (This conflict with VirtualRPC only applies to VRPC on the Mac, the
> NetSurf 3.0 test builds are fine with VirtualRPC on Windows 7.)
Thanks for that info. So it's a problem with VirtualRPC on the Mac only.
Cheers,
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
David Pitt <pittdj@pittdj.co.uk> wrote:
> I can confirm that the current NetSurf 3.0 test builds do resolve on
> RPCEmu v0.8.9 on Mac OS X 10.8.3.
> The i686-darwin10 builds also resolve running natively on the Mac.
> (This conflict with VirtualRPC only applies to VRPC on the Mac, the
> NetSurf 3.0 test builds are fine with VirtualRPC on Windows 7.)
Thanks for that info. So it's a problem with VirtualRPC on the Mac only.
Cheers,
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: NetSurf on Virtual Acorn
Michael Drake, on 16 Apr, wrote:
> In article <op.wrhukyovif396l@alansall>,
> Alan & Sally <jared.r@xtra.co.nz> wrote:
>
> > NetSurf 2.9 runs nicely on this set up but I have had no luck with any
> > of the later development versions. I have just downloaded 3.0 Dev #833
> > with the same result.
>
> It seems that since NetSurf 2.9 DNS doesn't work when running on
> VirtualRPC. It works on real hardware and, I believe, on RPCEmu (can
> anyone confirm?).
I can confirm that the current NetSurf 3.0 test builds do resolve on RPCEmu
v0.8.9 on Mac OS X 10.8.3.
The i686-darwin10 builds also resolve running natively on the Mac.
(This conflict with VirtualRPC only applies to VRPC on the Mac, the NetSurf
3.0 test builds are fine with VirtualRPC on Windows 7.)
>
> None of the NetSurf developers have VirtualRPC so we aren't in a position
> to investigate this. Perhaps you could contact the VirtualRPC developers,
> if it's still being maintained?
>
> Cheers,
>
--
David Pitt
> In article <op.wrhukyovif396l@alansall>,
> Alan & Sally <jared.r@xtra.co.nz> wrote:
>
> > NetSurf 2.9 runs nicely on this set up but I have had no luck with any
> > of the later development versions. I have just downloaded 3.0 Dev #833
> > with the same result.
>
> It seems that since NetSurf 2.9 DNS doesn't work when running on
> VirtualRPC. It works on real hardware and, I believe, on RPCEmu (can
> anyone confirm?).
I can confirm that the current NetSurf 3.0 test builds do resolve on RPCEmu
v0.8.9 on Mac OS X 10.8.3.
The i686-darwin10 builds also resolve running natively on the Mac.
(This conflict with VirtualRPC only applies to VRPC on the Mac, the NetSurf
3.0 test builds are fine with VirtualRPC on Windows 7.)
>
> None of the NetSurf developers have VirtualRPC so we aren't in a position
> to investigate this. Perhaps you could contact the VirtualRPC developers,
> if it's still being maintained?
>
> Cheers,
>
--
David Pitt
Re: NetSurf on Virtual Acorn
In message <533d3d5a8btlsa@netsurf-browser.org>
Michael Drake <tlsa@netsurf-browser.org> wrote:
> In article <op.wrhukyovif396l@alansall>,
> Alan & Sally <jared.r@xtra.co.nz> wrote:
>> NetSurf 2.9 runs nicely on this set up but I have had no luck with any
>> of the later development versions. I have just downloaded 3.0 Dev #833
>> with the same result.
> It seems that since NetSurf 2.9 DNS doesn't work when running on
> VirtualRPC. It works on real hardware and, I believe, on RPCEmu (can
> anyone confirm?).
> None of the NetSurf developers have VirtualRPC so we aren't in a position
> to investigate this. Perhaps you could contact the VirtualRPC developers,
> if it's still being maintained?
FWIW I have run a great number of development versions of NetSurf
(currently 3.0 (Dev CI #1054)) on this VA - details in sig. I have had
no problems connecting to the Internet at all. I note the OP is using
VA on a Mac, perhaps this is relevant?
--
Brian Jordan
Virtual RPC-AdjustSA on Windows 8
RISC OS 6.20
Michael Drake <tlsa@netsurf-browser.org> wrote:
> In article <op.wrhukyovif396l@alansall>,
> Alan & Sally <jared.r@xtra.co.nz> wrote:
>> NetSurf 2.9 runs nicely on this set up but I have had no luck with any
>> of the later development versions. I have just downloaded 3.0 Dev #833
>> with the same result.
> It seems that since NetSurf 2.9 DNS doesn't work when running on
> VirtualRPC. It works on real hardware and, I believe, on RPCEmu (can
> anyone confirm?).
> None of the NetSurf developers have VirtualRPC so we aren't in a position
> to investigate this. Perhaps you could contact the VirtualRPC developers,
> if it's still being maintained?
FWIW I have run a great number of development versions of NetSurf
(currently 3.0 (Dev CI #1054)) on this VA - details in sig. I have had
no problems connecting to the Internet at all. I note the OP is using
VA on a Mac, perhaps this is relevant?
--
Brian Jordan
Virtual RPC-AdjustSA on Windows 8
RISC OS 6.20
Re: NetSurf on Virtual Acorn
In article <op.wrhukyovif396l@alansall>,
Alan & Sally <jared.r@xtra.co.nz> wrote:
> NetSurf 2.9 runs nicely on this set up but I have had no luck with any
> of the later development versions. I have just downloaded 3.0 Dev #833
> with the same result.
It seems that since NetSurf 2.9 DNS doesn't work when running on
VirtualRPC. It works on real hardware and, I believe, on RPCEmu (can
anyone confirm?).
None of the NetSurf developers have VirtualRPC so we aren't in a position
to investigate this. Perhaps you could contact the VirtualRPC developers,
if it's still being maintained?
Cheers,
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Alan & Sally <jared.r@xtra.co.nz> wrote:
> NetSurf 2.9 runs nicely on this set up but I have had no luck with any
> of the later development versions. I have just downloaded 3.0 Dev #833
> with the same result.
It seems that since NetSurf 2.9 DNS doesn't work when running on
VirtualRPC. It works on real hardware and, I believe, on RPCEmu (can
anyone confirm?).
None of the NetSurf developers have VirtualRPC so we aren't in a position
to investigate this. Perhaps you could contact the VirtualRPC developers,
if it's still being maintained?
Cheers,
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Monday, 15 April 2013
Re: Upper character truncation - CSS handling
John Williams, on 15 Apr, wrote:
> In article <20130415072710.GA30789@kyllikki.org>,
> Vincent Sanders <vince@netsurf-browser.org> wrote:
>
> > If you want this fixed please submit it to our issue tracker, otherwise
> > it is liable to be ignored.
>
> > Some brief analysis shows this is due to the css rule:
>
> > .curvedboxcontainer h1 { font-family: Passion One, Helvetica, san-serif;
> > font-size: 36px; color: #b66222; line-height: 90%; }
>
> > It appears the bounding box height is scaled by 90% but not the text
> > itself. I also note NetSurf falls back to the sans-serif font choice
> > which should not be a factors
>
> If it is the same issue I reported some years ago - without result ...
Is this the earlier instance:-
http://sourceforge.net/tracker/index.php?func=detail&aid=3288883&group_id=51719&atid=464312
--
David Pitt
> In article <20130415072710.GA30789@kyllikki.org>,
> Vincent Sanders <vince@netsurf-browser.org> wrote:
>
> > If you want this fixed please submit it to our issue tracker, otherwise
> > it is liable to be ignored.
>
> > Some brief analysis shows this is due to the css rule:
>
> > .curvedboxcontainer h1 { font-family: Passion One, Helvetica, san-serif;
> > font-size: 36px; color: #b66222; line-height: 90%; }
>
> > It appears the bounding box height is scaled by 90% but not the text
> > itself. I also note NetSurf falls back to the sans-serif font choice
> > which should not be a factors
>
> If it is the same issue I reported some years ago - without result ...
Is this the earlier instance:-
http://sourceforge.net/tracker/index.php?func=detail&aid=3288883&group_id=51719&atid=464312
--
David Pitt
Re: Fetch polling change branch
On Tue, 16 Apr 2013 00:01:03 +0100, John-Mark Bell wrote:
> On Mon, 2013-04-15 at 23:38 +0100, Chris Young wrote:
> > Although I have just realised I can put my change at the top of
> > gui_poll without touching the core, so I'm going to do that.
> >
> > It's worth considering stopping the core poll-looping during fetches
> > by default though.
>
> There's a preprocessor define in content/fetchers/curl.c to enable this
> for fetches performed through curl. It's disabled, as it currently
> breaks things on a number of platforms.
A-ha, that seems to work well here, thanks.
Chris
> On Mon, 2013-04-15 at 23:38 +0100, Chris Young wrote:
> > Although I have just realised I can put my change at the top of
> > gui_poll without touching the core, so I'm going to do that.
> >
> > It's worth considering stopping the core poll-looping during fetches
> > by default though.
>
> There's a preprocessor define in content/fetchers/curl.c to enable this
> for fetches performed through curl. It's disabled, as it currently
> breaks things on a number of platforms.
A-ha, that seems to work well here, thanks.
Chris
Re: Fetch polling change branch
On Mon, 2013-04-15 at 23:38 +0100, Chris Young wrote:
> Although I have just realised I can put my change at the top of
> gui_poll without touching the core, so I'm going to do that.
>
> It's worth considering stopping the core poll-looping during fetches
> by default though.
There's a preprocessor define in content/fetchers/curl.c to enable this
for fetches performed through curl. It's disabled, as it currently
breaks things on a number of platforms.
J.
> Although I have just realised I can put my change at the top of
> gui_poll without touching the core, so I'm going to do that.
>
> It's worth considering stopping the core poll-looping during fetches
> by default though.
There's a preprocessor define in content/fetchers/curl.c to enable this
for fetches performed through curl. It's disabled, as it currently
breaks things on a number of platforms.
J.
Re: Upper character truncation - CSS handling
On Mon, 2013-04-15 at 21:59 +0100, John Williams wrote:
> It needs sorting!
Patches are always welcome.
J.
> It needs sorting!
Patches are always welcome.
J.
Re: Fetch polling change branch
Although I have just realised I can put my change at the top of
gui_poll without touching the core, so I'm going to do that.
It's worth considering stopping the core poll-looping during fetches
by default though.
Chris
gui_poll without touching the core, so I'm going to do that.
It's worth considering stopping the core poll-looping during fetches
by default though.
Chris
NetSurf Build System / Atari support
Hello,
It looks like the current netsurf buildsystem isn't able to compile
correct executables for the atari target, this is especially bad when
running
on coldfire, where the build failure results in illegal instructions
(when m68k CPU emulation is turned off).
(the sdk build maybe suffers the same problem, but that's another
story)
On my local box I use Verbose mode of make, to see the actual compiler
commands.
Let's have a look at the atari support within the netsurf buildsystem:
--- snip ---
# FreeMiNT / atari
ifeq ($(TARGET),atari)
ifeq ($(HOST),atari)
# Building on FreeMiNT
# Nothing to do, as we assume the default tooling works
else
# Cross compiling for FreeMiNT
ATARIARCH ?= 68020-60
GCCSDK_INSTALL_ENV ?= /opt/netsurf/m68k-atari-mint
GCCSDK_INSTALL_CROSSBIN ?= /opt/netsurf/m68k-atari-mint/cross/bin
CC__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-gcc
CXX__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-g++
AR__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-ar
ifeq ($(ATARIARCH),68000)
ARCHFLAGS :=
ARCHDIR :=
endif
ifeq ($(ATARIARCH),68020-60)
ARCHFLAGS := -m$(ATARIARCH)
ARCHDIR := /$(ATARIARCH)
endif
ifeq ($(ATARIARCH),v4e)
ARCHFLAGS := -mcpu=5475
ARCHDIR := /m5475
endif
CFLAGS := $(CFLAGS) -U__STRICT_ANSI__
-I$(GCCSDK_INSTALL_ENV)/include $(ARCHFLAGS)
CXXFLAGS := $(CXXFLAGS) -U__STRICT_ANSI__
-I$(GCCSDK_INSTALL_ENV)/include $(ARCHFLAGS)
LDFLAGS := $(LDFLAGS) -L$(GCCSDK_INSTALL_ENV)/lib$(ARCHDIR)
PREFIX ?= $(GCCSDK_INSTALL_ENV)
endif
endif
--- snip ---
First thing to notice is the fact that it assumes you do pass the
environment variable ATARIARCH
to specify the CPU type. If you do not specify this variable, the cpu
defaults to 68020-60, which
is definitly wrong for coldfire compilation.
I'm assuming that the netsurf build system does not set ATARIARCH.
I'm open for suggestions, how to specify and resolve the CPU type
differently, of course.
Also look at the output of libcss build:
http://ci.netsurf-browser.org/jenkins/job/libcss/TARGET=m5475-atari-mint,label=other/86/consoleText
You can not see which compiler was used. You can not see which
CFLAGS/LDFLAGS where used.
Second thing to notice is the fact that it assumes the m68k-atari-mint
toolchain to be used:
CC__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-gcc
CXX__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-g++
AR__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-ar
When compiling for coldfire (the way it was meant to be: by setting
ATARIARCH) it will fail to find the compiler
because the m68k-atari-mint compiler is not located in the coldfire sdk
dirs.
Of course the script could be adjusted like this:
ifeq ($(ATARIARCH),v4e)
ARCHFLAGS := -mcpu=5475
ARCHDIR := /m5475
CC__ := $(GCCSDK_INSTALL_CROSSBIN)/m5475-atari-mint-gcc
CXX__ := $(GCCSDK_INSTALL_CROSSBIN)/m5475-atari-mint-g++
AR__ := $(GCCSDK_INSTALL_CROSSBIN)/m5475-atari-mint-ar
endif
But that would mean, that the average buildsystem user is not able to
compile netsurf
on his own box, when he doesn't want to use the m5475-atari-mint-xxx
provided by the netsurf sdk build.
As an example, just take this simple make command and see how it fails:
/media/src/netsurf.git/libnsgif$
GCCSDK_INSTALL_CROSSBIN=/opt/netsurf/m5475-atari-mint/cross/bin
GCCSDK_INSTALL_ENV=/opt/netsurf/m5475-atari-mint make TARGET=atari
ATARIARCH=v4e
/bin/sh: /opt/netsurf/m5475-atari-mint/cross/bin/m68k-atari-mint-gcc:
not found
/bin/sh: /opt/netsurf/m5475-atari-mint/cross/bin/m68k-atari-mint-gcc:
not found
/opt/netsurf/m5475-atari-mint/share/netsurf-buildsystem/makefiles/Makefile.tools:466:
*** Unable to detect toolchain. Schluss.
Using m68k-atari-mint-gcc to compile atari coldfire software is de
facto standard and
I don't want to explain people that things are different with netsurf
;)
However, if this is the only way to implement clean coldfire support in
the netsurf
buildsystem, I'm happy to take that pill.
Can we add the ATARIARCH environment variable, like it is done for the
netsurf build?
Valid values:
ATARIARCH=68020-60
ATARIARCH=v4e
The coldfire build will be broken then (look at the example above),
because it won't be able to find the toolchain (except it is explicitly
set), however, when that happens, I probably already fixed the toolchain
names for coldfire within the makefile.
It looks like the current netsurf buildsystem isn't able to compile
correct executables for the atari target, this is especially bad when
running
on coldfire, where the build failure results in illegal instructions
(when m68k CPU emulation is turned off).
(the sdk build maybe suffers the same problem, but that's another
story)
On my local box I use Verbose mode of make, to see the actual compiler
commands.
Let's have a look at the atari support within the netsurf buildsystem:
--- snip ---
# FreeMiNT / atari
ifeq ($(TARGET),atari)
ifeq ($(HOST),atari)
# Building on FreeMiNT
# Nothing to do, as we assume the default tooling works
else
# Cross compiling for FreeMiNT
ATARIARCH ?= 68020-60
GCCSDK_INSTALL_ENV ?= /opt/netsurf/m68k-atari-mint
GCCSDK_INSTALL_CROSSBIN ?= /opt/netsurf/m68k-atari-mint/cross/bin
CC__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-gcc
CXX__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-g++
AR__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-ar
ifeq ($(ATARIARCH),68000)
ARCHFLAGS :=
ARCHDIR :=
endif
ifeq ($(ATARIARCH),68020-60)
ARCHFLAGS := -m$(ATARIARCH)
ARCHDIR := /$(ATARIARCH)
endif
ifeq ($(ATARIARCH),v4e)
ARCHFLAGS := -mcpu=5475
ARCHDIR := /m5475
endif
CFLAGS := $(CFLAGS) -U__STRICT_ANSI__
-I$(GCCSDK_INSTALL_ENV)/include $(ARCHFLAGS)
CXXFLAGS := $(CXXFLAGS) -U__STRICT_ANSI__
-I$(GCCSDK_INSTALL_ENV)/include $(ARCHFLAGS)
LDFLAGS := $(LDFLAGS) -L$(GCCSDK_INSTALL_ENV)/lib$(ARCHDIR)
PREFIX ?= $(GCCSDK_INSTALL_ENV)
endif
endif
--- snip ---
First thing to notice is the fact that it assumes you do pass the
environment variable ATARIARCH
to specify the CPU type. If you do not specify this variable, the cpu
defaults to 68020-60, which
is definitly wrong for coldfire compilation.
I'm assuming that the netsurf build system does not set ATARIARCH.
I'm open for suggestions, how to specify and resolve the CPU type
differently, of course.
Also look at the output of libcss build:
http://ci.netsurf-browser.org/jenkins/job/libcss/TARGET=m5475-atari-mint,label=other/86/consoleText
You can not see which compiler was used. You can not see which
CFLAGS/LDFLAGS where used.
Second thing to notice is the fact that it assumes the m68k-atari-mint
toolchain to be used:
CC__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-gcc
CXX__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-g++
AR__ := $(GCCSDK_INSTALL_CROSSBIN)/m68k-atari-mint-ar
When compiling for coldfire (the way it was meant to be: by setting
ATARIARCH) it will fail to find the compiler
because the m68k-atari-mint compiler is not located in the coldfire sdk
dirs.
Of course the script could be adjusted like this:
ifeq ($(ATARIARCH),v4e)
ARCHFLAGS := -mcpu=5475
ARCHDIR := /m5475
CC__ := $(GCCSDK_INSTALL_CROSSBIN)/m5475-atari-mint-gcc
CXX__ := $(GCCSDK_INSTALL_CROSSBIN)/m5475-atari-mint-g++
AR__ := $(GCCSDK_INSTALL_CROSSBIN)/m5475-atari-mint-ar
endif
But that would mean, that the average buildsystem user is not able to
compile netsurf
on his own box, when he doesn't want to use the m5475-atari-mint-xxx
provided by the netsurf sdk build.
As an example, just take this simple make command and see how it fails:
/media/src/netsurf.git/libnsgif$
GCCSDK_INSTALL_CROSSBIN=/opt/netsurf/m5475-atari-mint/cross/bin
GCCSDK_INSTALL_ENV=/opt/netsurf/m5475-atari-mint make TARGET=atari
ATARIARCH=v4e
/bin/sh: /opt/netsurf/m5475-atari-mint/cross/bin/m68k-atari-mint-gcc:
not found
/bin/sh: /opt/netsurf/m5475-atari-mint/cross/bin/m68k-atari-mint-gcc:
not found
/opt/netsurf/m5475-atari-mint/share/netsurf-buildsystem/makefiles/Makefile.tools:466:
*** Unable to detect toolchain. Schluss.
Using m68k-atari-mint-gcc to compile atari coldfire software is de
facto standard and
I don't want to explain people that things are different with netsurf
;)
However, if this is the only way to implement clean coldfire support in
the netsurf
buildsystem, I'm happy to take that pill.
Can we add the ATARIARCH environment variable, like it is done for the
netsurf build?
Valid values:
ATARIARCH=68020-60
ATARIARCH=v4e
The coldfire build will be broken then (look at the example above),
because it won't be able to find the toolchain (except it is explicitly
set), however, when that happens, I probably already fixed the toolchain
names for coldfire within the makefile.
Re: Upper character truncation - CSS handling
In article <20130415072710.GA30789@kyllikki.org>,
Vincent Sanders <vince@netsurf-browser.org> wrote:
> If you want this fixed please submit it to our issue tracker,
> otherwise it is liable to be ignored.
> Some brief analysis shows this is due to the css rule:
> .curvedboxcontainer h1 {
> font-family: Passion One, Helvetica, san-serif;
> font-size: 36px;
> color: #b66222;
> line-height: 90%;
> }
> It appears the bounding box height is scaled by 90% but not the text
> itself. I also note NetSurf falls back to the sans-serif font choice
> which should not be a factors
If it is the same issue I reported some years ago - without result ...
> On Mon, 15 Apr 2013 08:27:10 +0100, Vincent Sanders wrote:
> > I also note NetSurf falls back to the sans-serif font choice
> > which should not be a factor.
> That should probably be on the request tracker too, if it isn't
> already. I remember some discussion about implementing usage of
> specific fonts quite some years ago.
What concerns me is that the Google home page also displays a similar
problem with the 'Advanced Search' and 'Language Tools' links to the riht
of the search box - which may confuse/discourage our new RPi users!
It needs sorting!
John
Vincent Sanders <vince@netsurf-browser.org> wrote:
> If you want this fixed please submit it to our issue tracker,
> otherwise it is liable to be ignored.
> Some brief analysis shows this is due to the css rule:
> .curvedboxcontainer h1 {
> font-family: Passion One, Helvetica, san-serif;
> font-size: 36px;
> color: #b66222;
> line-height: 90%;
> }
> It appears the bounding box height is scaled by 90% but not the text
> itself. I also note NetSurf falls back to the sans-serif font choice
> which should not be a factors
If it is the same issue I reported some years ago - without result ...
> On Mon, 15 Apr 2013 08:27:10 +0100, Vincent Sanders wrote:
> > I also note NetSurf falls back to the sans-serif font choice
> > which should not be a factor.
> That should probably be on the request tracker too, if it isn't
> already. I remember some discussion about implementing usage of
> specific fonts quite some years ago.
What concerns me is that the Google home page also displays a similar
problem with the 'Advanced Search' and 'Language Tools' links to the riht
of the search box - which may confuse/discourage our new RPi users!
It needs sorting!
John
[Rpcemu] RPCEmu 0.8.10 and RO 6.20
Okay, I've found the problem... Tiz me.
In the Filer configuration, as well as ticking "Enable keyboard shortcuts"
I had failed to also tick "Claim input focus automatically"
Now done and the shortcuts works on all emulated RO 6.20
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
In the Filer configuration, as well as ticking "Enable keyboard shortcuts"
I had failed to also tick "Claim input focus automatically"
Now done and the shortcuts works on all emulated RO 6.20
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.8.10 and RO 6.20
In article <533ce4fc06dave@triffid.co.uk>,
Dave Symes <dave@triffid.co.uk> wrote:
> On 15 Apr, dave@triffid.co.uk wrote:
> [Snippy]
> > PS: I have a RPCEmu 0.8.10 RO 6.20 on another computer, later I'll run
> > that and see what happens with that.
> > D.
> Nope! tried on a Win 7 32 bit, no difference.
> Dave
And I've now tried it on a VRPC-AdjustSA RO 6.20 install (Win 7 Pro 64bit)
and the key shortcuts don't work on that either.
(Yes I do have it ticked in Configure).
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Dave Symes <dave@triffid.co.uk> wrote:
> On 15 Apr, dave@triffid.co.uk wrote:
> [Snippy]
> > PS: I have a RPCEmu 0.8.10 RO 6.20 on another computer, later I'll run
> > that and see what happens with that.
> > D.
> Nope! tried on a Win 7 32 bit, no difference.
> Dave
And I've now tried it on a VRPC-AdjustSA RO 6.20 install (Win 7 Pro 64bit)
and the key shortcuts don't work on that either.
(Yes I do have it ticked in Configure).
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Fetch polling change branch
All
I've just created a branch chris/scheduled-fetches because currently
when downloading, NetSurf runs in a busy loop fetching data. This
really slows down the whole system ounder AmigaOS because NetSurf ends
up hogging most of the processor time.
In the branch I've changed the main loop so it schedules itself
to do an immediate hlcache_poll, rather than directly calling
hlcache_poll itself. This means that operating systems with something
like Wait(), which will wait for an event to come in, eg. for one
of NetSurf's scheduled tasks, will be able to use Wait() rather than
dropping out of gui_poll and letting NetSurf busy-loop, and be a bit
more multi-tasking friendly. It is certainly working well here, with
a minor change to ignore gui_poll's "active" flag.
I'm not sure what implications this has for other platforms we target.
I don't see that it would cause any problems, as the only real change
is that schedule() calls hlcache_poll() rather than the main loop
doing it - unless there are some hidden reasons why that is a bad
idea?
Ideally I'd like to see this in 3.0 if possible, as it has solved
something that has been bugging me for ages!
Thoughts?
Chris
I've just created a branch chris/scheduled-fetches because currently
when downloading, NetSurf runs in a busy loop fetching data. This
really slows down the whole system ounder AmigaOS because NetSurf ends
up hogging most of the processor time.
In the branch I've changed the main loop so it schedules itself
to do an immediate hlcache_poll, rather than directly calling
hlcache_poll itself. This means that operating systems with something
like Wait(), which will wait for an event to come in, eg. for one
of NetSurf's scheduled tasks, will be able to use Wait() rather than
dropping out of gui_poll and letting NetSurf busy-loop, and be a bit
more multi-tasking friendly. It is certainly working well here, with
a minor change to ignore gui_poll's "active" flag.
I'm not sure what implications this has for other platforms we target.
I don't see that it would cause any problems, as the only real change
is that schedule() calls hlcache_poll() rather than the main loop
doing it - unless there are some hidden reasons why that is a bad
idea?
Ideally I'd like to see this in 3.0 if possible, as it has solved
something that has been bugging me for ages!
Thoughts?
Chris
Re: [Rpcemu] RPCEmu 0.8.10 and RO 6.20
On 15 Apr, dave@triffid.co.uk wrote:
[Snippy]
> PS: I have a RPCEmu 0.8.10 RO 6.20 on another computer, later I'll run
> that and see what happens with that.
> D.
Nope! tried on a Win 7 32 bit, no difference.
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Snippy]
> PS: I have a RPCEmu 0.8.10 RO 6.20 on another computer, later I'll run
> that and see what happens with that.
> D.
Nope! tried on a Win 7 32 bit, no difference.
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] RPCEmu 0.8.10 and RO 6.20
In article <4138bb3c53.old_coaster@old_coaster.yahoo.co.uk>,
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 14 Apr 2013, Dave Symes <dave@triffid.co.uk> wrote:
> > Can anyone else using RO 6.20 on the RPCEmu install, confirm that
> > filer keyboard shortcuts don't work (BTW. They do on a real SARPC).
> >
> > I do have Filer configuration, Enable keynoard shortcuts ticked ON.
> >
> > But Filer keyboard shortcuts don't work.
> >
> > For example...
> > Shift+F3 should rename.
> > Delete key should Delete
> >
> > But they don't
> Using RO 6.20 / RPCEmu 0.8.10 / Win7 32bit:
> Here, the keyboard shortcuts which you list, both work. So too do f3
> (copy), and Insert (new directory). I haven't tried all the others.
> No idea why yours don't work. Could it have anything to do with the
> Windows keyboard configuration?
> Tony
Mmnnn! I wonder if it's anything to do with my Win 7 being 64 bit?
Both Win and RPCEmu are keyboard set to UK, and the only change I have
made with the Win keyboard is MouseKeys active, but I'd already wondered
about that and tried with MouseKeys swiched off... No change.
Any thoughts on what I might be missing?
Thanks
Dave
PS: I have a RPCEmu 0.8.10 RO 6.20 on another computer, later I'll run
that and see what happens with that.
D.
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 14 Apr 2013, Dave Symes <dave@triffid.co.uk> wrote:
> > Can anyone else using RO 6.20 on the RPCEmu install, confirm that
> > filer keyboard shortcuts don't work (BTW. They do on a real SARPC).
> >
> > I do have Filer configuration, Enable keynoard shortcuts ticked ON.
> >
> > But Filer keyboard shortcuts don't work.
> >
> > For example...
> > Shift+F3 should rename.
> > Delete key should Delete
> >
> > But they don't
> Using RO 6.20 / RPCEmu 0.8.10 / Win7 32bit:
> Here, the keyboard shortcuts which you list, both work. So too do f3
> (copy), and Insert (new directory). I haven't tried all the others.
> No idea why yours don't work. Could it have anything to do with the
> Windows keyboard configuration?
> Tony
Mmnnn! I wonder if it's anything to do with my Win 7 being 64 bit?
Both Win and RPCEmu are keyboard set to UK, and the only change I have
made with the Win keyboard is MouseKeys active, but I'd already wondered
about that and tried with MouseKeys swiched off... No change.
Any thoughts on what I might be missing?
Thanks
Dave
PS: I have a RPCEmu 0.8.10 RO 6.20 on another computer, later I'll run
that and see what happens with that.
D.
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: Upper character truncation - CSS handling
On Mon, 15 Apr 2013 08:27:10 +0100, Vincent Sanders wrote:
> I also note NetSurf falls back to the sans-serif font choice
> which should not be a factor.
That should probably be on the request tracker too, if it isn't
already. I remember some discussion about implementing usage of
specific fonts quite some years ago.
Chris
> I also note NetSurf falls back to the sans-serif font choice
> which should not be a factor.
That should probably be on the request tracker too, if it isn't
already. I remember some discussion about implementing usage of
specific fonts quite some years ago.
Chris
Re: display issue on lacoop26-07.fr
On Mon, 15 Apr 2013 15:31:00 +0200, RnJhbsOnb2lzIFJldm9s wrote:
> I noticed a display issue on:
> http://www.lacoop26-07.fr/
>
> (both GTK and Haiku)
>
> The main text block (the 2 photos and the text below) seems to disappear
> when scrolling up, and reappears when scrolling down.
> It seems scrolling the page totally on the left makes it visible when
> scrolling up/down, at least on Haiku.
That page is behaving very strangely, I had to resize the window to
get it to show anything at all, and even then the window scrollbars
weren't indicating I could scroll. Drag scrolling caused the
"loading" anim GIF to move around but not much else.
Something similar happens on http://www.thespace.org, where it doesn't
show anything until the page is scrolled.
Probably one for the bug tracker.
Chris
> I noticed a display issue on:
> http://www.lacoop26-07.fr/
>
> (both GTK and Haiku)
>
> The main text block (the 2 photos and the text below) seems to disappear
> when scrolling up, and reappears when scrolling down.
> It seems scrolling the page totally on the left makes it visible when
> scrolling up/down, at least on Haiku.
That page is behaving very strangely, I had to resize the window to
get it to show anything at all, and even then the window scrollbars
weren't indicating I could scroll. Drag scrolling caused the
"loading" anim GIF to move around but not much else.
Something similar happens on http://www.thespace.org, where it doesn't
show anything until the page is scrolled.
Probably one for the bug tracker.
Chris
display issue on lacoop26-07.fr
I noticed a display issue on:
http://www.lacoop26-07.fr/
(both GTK and Haiku)
The main text block (the 2 photos and the text below) seems to disappear
when scrolling up, and reappears when scrolling down.
It seems scrolling the page totally on the left makes it visible when
scrolling up/down, at least on Haiku.
François.
http://www.lacoop26-07.fr/
(both GTK and Haiku)
The main text block (the 2 photos and the text below) seems to disappear
when scrolling up, and reappears when scrolling down.
It seems scrolling the page totally on the left makes it visible when
scrolling up/down, at least on Haiku.
François.
Re: [Rpcemu] RPCEmu 0.8.10 and RO 6.20
On 14 Apr 2013, Dave Symes <dave@triffid.co.uk> wrote:
> Can anyone else using RO 6.20 on the RPCEmu install, confirm that
> filer keyboard shortcuts don't work (BTW. They do on a real SARPC).
>
> I do have Filer configuration, Enable keynoard shortcuts ticked ON.
>
> But Filer keyboard shortcuts don't work.
>
> For example...
> Shift+F3 should rename.
> Delete key should Delete
>
> But they don't
Using RO 6.20 / RPCEmu 0.8.10 / Win7 32bit:
Here, the keyboard shortcuts which you list, both work. So too do f3
(copy), and Insert (new directory). I haven't tried all the others.
No idea why yours don't work. Could it have anything to do with the
Windows keyboard configuration?
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Can anyone else using RO 6.20 on the RPCEmu install, confirm that
> filer keyboard shortcuts don't work (BTW. They do on a real SARPC).
>
> I do have Filer configuration, Enable keynoard shortcuts ticked ON.
>
> But Filer keyboard shortcuts don't work.
>
> For example...
> Shift+F3 should rename.
> Delete key should Delete
>
> But they don't
Using RO 6.20 / RPCEmu 0.8.10 / Win7 32bit:
Here, the keyboard shortcuts which you list, both work. So too do f3
(copy), and Insert (new directory). I haven't tried all the others.
No idea why yours don't work. Could it have anything to do with the
Windows keyboard configuration?
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: Upper character truncation - CSS handling
On Sun, Apr 14, 2013 at 10:04:10PM +0100, John Williams wrote:
>
> I see at:
>
> http://www.pets4homes.co.uk/sale/dogs/bedlington-terrier/wakefield/
>
> an illustration of the subject line which may be related to the problem
> (which I have lost track of) reported by me, and, I think, Dave Higton some
> years ago which was not actioned.
>
> The problem is that the top few lines of the characters in the headines are
> not displayed.
>
If you want this fixed please submit it to our issue tracker,
otherwise it is liable to be ignored.
Some brief analysis shows this is due to the css rule:
.curvedboxcontainer h1 {
font-family: Passion One, Helvetica, san-serif;
font-size: 36px;
color: #b66222;
line-height: 90%;
}
It appears the bounding box height is scaled by 90% but not the text
itself. I also note NetSurf falls back to the sans-serif font choice
which should not be a factor.
--
Regards Vincent
http://www.kyllikki.org/
>
> I see at:
>
> http://www.pets4homes.co.uk/sale/dogs/bedlington-terrier/wakefield/
>
> an illustration of the subject line which may be related to the problem
> (which I have lost track of) reported by me, and, I think, Dave Higton some
> years ago which was not actioned.
>
> The problem is that the top few lines of the characters in the headines are
> not displayed.
>
If you want this fixed please submit it to our issue tracker,
otherwise it is liable to be ignored.
Some brief analysis shows this is due to the css rule:
.curvedboxcontainer h1 {
font-family: Passion One, Helvetica, san-serif;
font-size: 36px;
color: #b66222;
line-height: 90%;
}
It appears the bounding box height is scaled by 90% but not the text
itself. I also note NetSurf falls back to the sans-serif font choice
which should not be a factor.
--
Regards Vincent
http://www.kyllikki.org/
Sunday, 14 April 2013
Upper character truncation - CSS handling
I see at:
http://www.pets4homes.co.uk/sale/dogs/bedlington-terrier/wakefield/
an illustration of the subject line which may be related to the problem
(which I have lost track of) reported by me, and, I think, Dave Higton some
years ago which was not actioned.
The problem is that the top few lines of the characters in the headines are
not displayed.
John
http://www.pets4homes.co.uk/sale/dogs/bedlington-terrier/wakefield/
an illustration of the subject line which may be related to the problem
(which I have lost track of) reported by me, and, I think, Dave Higton some
years ago which was not actioned.
The problem is that the top few lines of the characters in the headines are
not displayed.
John
[Rpcemu] RPCEmu 0.8.10 and RO 6.20
Can anyone else using RO 6.20 on the RPCEmu install, confirm that filer
keyboard shortcuts don't work (BTW. They do on a real SARPC).
I do have Filer configuration, Enable keynoard shortcuts ticked ON.
But Filer keyboard shortcuts don't work.
For example...
Shift+F3 should rename.
Delete key should Delete
But they don't
Any thoughts?
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
keyboard shortcuts don't work (BTW. They do on a real SARPC).
I do have Filer configuration, Enable keynoard shortcuts ticked ON.
But Filer keyboard shortcuts don't work.
For example...
Shift+F3 should rename.
Delete key should Delete
But they don't
Any thoughts?
Dave
--
Dave Triffid
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Thursday, 11 April 2013
Re: Kickstarter
On 11 Apr 2013 19:21:24 +0100, Chris Young wrote:
> Is anybody else getting dark green text on the same colour background,
> on all Kickstart project details?
>
> For example, this random one off the front page:
> http://www.kickstarter.com/projects/andyfei/mini-microsd-reader-for-android-smartphones-and-ta?ref=home_popular
>
> Another couple I looked at have the same problem (so I assume they
> all do). I'm sure it has been working in the past.
Just noticed this is already on the bugtracker and have confirmed here
using the GTK build too.
Chris
> Is anybody else getting dark green text on the same colour background,
> on all Kickstart project details?
>
> For example, this random one off the front page:
> http://www.kickstarter.com/projects/andyfei/mini-microsd-reader-for-android-smartphones-and-ta?ref=home_popular
>
> Another couple I looked at have the same problem (so I assume they
> all do). I'm sure it has been working in the past.
Just noticed this is already on the bugtracker and have confirmed here
using the GTK build too.
Chris
Kickstarter
Is anybody else getting dark green text on the same colour background,
on all Kickstart project details?
For example, this random one off the front page:
http://www.kickstarter.com/projects/andyfei/mini-microsd-reader-for-android-smartphones-and-ta?ref=home_popular
Another couple I looked at have the same problem (so I assume they
all do). I'm sure it has been working in the past.
Chris
on all Kickstart project details?
For example, this random one off the front page:
http://www.kickstarter.com/projects/andyfei/mini-microsd-reader-for-android-smartphones-and-ta?ref=home_popular
Another couple I looked at have the same problem (so I assume they
all do). I'm sure it has been working in the past.
Chris
Wednesday, 10 April 2013
Re: Text area refresh
Am Mittwoch, den 10.04.2013, 22:11 +0200 schrieb Peter Slegg
<p.slegg@scubadivers.co.uk>:
> I don't know if it related but the Page Up key does a page-down
> action.
Not related, but should be fixed in the next auto-build.
<p.slegg@scubadivers.co.uk>:
> I don't know if it related but the Page Up key does a page-down
> action.
Not related, but should be fixed in the next auto-build.
Re: Text area refresh
> Date: Mon, 08 Apr 2013 19:54:52 +0100
> Subject: Re: Text area refresh
> In article
> <OUT-51631B25.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
> Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
>
> > The core handling of Ctrl-V (and any other similar shortcuts) probably
> > needs to be tracked down and obliterated.
>
> The core handling of Ctrl-V is the only supported way of pasting.
>
> When you select "Paste" in a menu, the front end should be implementing it
> by passing Ctrl-V to the core.
>
> When the core gets a Ctrl-V it passes it on internally to whatever has
> input focus. If there is a textarea with focus, the textarea handles the
> keypress (by calling gui_get_clipboard, in the case of Ctrl-V).
>
The double paste problem has gone. Thanks.
I don't know if it related but the Page Up key does a page-down action.
Peter
Netsurf Port : Atari
Machine : Milan 68060
> Subject: Re: Text area refresh
> In article
> <OUT-51631B25.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
> Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
>
> > The core handling of Ctrl-V (and any other similar shortcuts) probably
> > needs to be tracked down and obliterated.
>
> The core handling of Ctrl-V is the only supported way of pasting.
>
> When you select "Paste" in a menu, the front end should be implementing it
> by passing Ctrl-V to the core.
>
> When the core gets a Ctrl-V it passes it on internally to whatever has
> input focus. If there is a textarea with focus, the textarea handles the
> keypress (by calling gui_get_clipboard, in the case of Ctrl-V).
>
The double paste problem has gone. Thanks.
I don't know if it related but the Page Up key does a page-down action.
Peter
Netsurf Port : Atari
Machine : Milan 68060
Tuesday, 9 April 2013
dv #1028 jpeg rendering
Just a small glitch.
Fetching http://en.wikipedia.org/wiki/Dzogchen a JPEG rendered OK but a
PNG didn't, initially. A second attempt at fetching and a re-load, all
JPEG's and PNG's appeared to render successfully.
Fetching http://en.wikipedia.org/wiki/Dzogchen a JPEG rendered OK but a
PNG didn't, initially. A second attempt at fetching and a re-load, all
JPEG's and PNG's appeared to render successfully.
Monday, 8 April 2013
Re: Text area refresh
Am Montag, den 08.04.2013, 23:52 +0200 schrieb Ole <ole@monochrom.net>:
> Am Montag, den 08.04.2013, 21:53 +0200 schrieb "Chris Young"
> I have to think about how to solve it...:
> 1. I would still like to process menu events before
> browser_window events.
> 2. catching ctrl+v and not passing it to the core is maybe
> incorrect(??).
>
> What looks best suited to me is to drop events which are handled by
> the menu area (should be done already,
> so this is an bug in the frontend), however, that solution maybe
> conflicts with policy number 2 (see above).
I was wrong, browser_window_key_input is called before the deskmenu
shortcut processing,
so now I'm ignoring inputs which are handled by
browser_window_key_input.
The problem should be fixed in the next build, I hope this doesn't
introduce any side-effects :)
Greets,
Ole
> Am Montag, den 08.04.2013, 21:53 +0200 schrieb "Chris Young"
> I have to think about how to solve it...:
> 1. I would still like to process menu events before
> browser_window events.
> 2. catching ctrl+v and not passing it to the core is maybe
> incorrect(??).
>
> What looks best suited to me is to drop events which are handled by
> the menu area (should be done already,
> so this is an bug in the frontend), however, that solution maybe
> conflicts with policy number 2 (see above).
I was wrong, browser_window_key_input is called before the deskmenu
shortcut processing,
so now I'm ignoring inputs which are handled by
browser_window_key_input.
The problem should be fixed in the next build, I hope this doesn't
introduce any side-effects :)
Greets,
Ole
Subscribe to:
Posts (Atom)