In message <6d72a5e352.old_coaster@old_coaster.yahoo.co.uk>
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 24 Oct 2012, george greenfield <george.greenfield@tiscali.co.uk> wrote:
>
> [snip speed tests]
>
>> At the moment 4.02 is my primary RPCEmu setup; it has networking, a
>> HardDisc4 (necessary for Photodesk to run)
>
> I know nothing about Photodesk, but why does it need HardDisc4? Is that
> path 'hard-wired' into the application?
Possibly (I don't know anything about the programme's internal
workings): what I do know is that any attempt to run !Photodesk from
HostFS brings up the error message 'Filing system does not support
this operation'. A pity really; RPCEmu/5.XX running on a fast PC/Mac
would be ideal for !Photodesk, given the memory and disk access
performance.
[snip]
> Moreover, if it
> becomes corrupted, RPCEmu hd4 can cause a major problem, since it cannot
> then be accessed via RPCEmu, and the only way out is to delete it.
You can install !Disknight on HostFS, and it will fix HD4 disk
corruption problems - I've done so several times and would recommend
it.
>
>> I tend to use 5.17 for graphics-intensive stuff (just done a 24-page
>> calendar using OvPro which produced an 82MB file). Given these
>> results, I can see benefit in shifting activity further towards 5.XX,
>> but the lack of HD4 is a bit of a showstopper.
>
> Why? Here, RPCEmu089/519 (16-Jul-12) works perfectly well, using HostFS
> for boot, and storage. BTW it also has networking.
>
Indeed: that's good. But as it seems HD4 is essential to run
!Photodesk, which is my photo-retouching/image manipulation app of
choice, it's a drawback for me.
George
--
george greenfield
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Wednesday, 24 October 2012
Re: libhubbub parse error on google homepage
I see, thanks for the tip. I'm only using it for the tokeniser as I don't have use for a dom tree. All I did was perform this when I saw a script tag:
hubbub_tokeniser_optparams params;
params.content_model.model = HUBBUB_CONTENT_MODEL_CDATA;
hubbub_tokeniser_setopt(tok_, HUBBUB_TOKENISER_CONTENT_MODEL, ¶ms);
Then revert it back when I see the end of the script tag. It seemed like that was what in_head.c was doing with parse_generic_rcdata().
On Wed, Oct 24, 2012 at 3:27 AM, John-Mark Bell <jmb@netsurf-browser.org> wrote:
On Wed, Oct 24, 2012 at 02:54:49AM -0700, Dean Mao wrote:Yes. This behaviour you're seeing is expected. The HTML5 tokeniser has a
> Here's a more compact test:
>
> <script>for(var i=0;i<n;i++);</script>
>
> Outputs:
>
> START TAG: 'script'
> CHARACTERS: 'for(var i=0;i'
> START TAG: 'n;i++);<' attributes:
> 'script' = ''
>
> Essentially everything inside a <script> tag should be treated as
> characters until a </script> tag is seen.
number of modes, which are selected by the token handler callback
provided by the client. The trivial token handler in test/tokeniser.c
does not manipulate the tokeniser mode, thus it does not handle the
contents of script (and other, similar) elements in the expected fashion.
The treebuilder implementation in Hubbub does manipulate the tokeniser
mode in the correct way. In most cases, you'll want to use the built-in
treebuilder, as it handles all the complexity of coping with junk input
for you. See examples/libxml.c for a demonstration of how to use the
built-in treebuilder.
If you do only wish to use the tokeniser, then you need to ensure that
your token handler changes the tokeniser mode in the same way that an
HTML5 treebuilder would.
J.
Re: [Rpcemu] RISC OS 5.17 benchmarked against 4.02
On 24 Oct 2012, george greenfield <george.greenfield@tiscali.co.uk> wrote:
[snip speed tests]
> At the moment 4.02 is my primary RPCEmu setup; it has networking, a
> HardDisc4 (necessary for Photodesk to run)
I know nothing about Photodesk, but why does it need HardDisc4? Is that
path 'hard-wired' into the application?
> and can run all the legacy stuff I use (Eureka, Rhapsody).
As far as I can see, RPCEmu089/439 runs all the applications which
formerly ran on SARPC/439. The hard disc of my SARPC/620 (excepting
!Boot) is mirrored to the HostFS of RPCEmu089/439 so that, if the SARPC
is unwell, I can switch to RPCEmu. This needs about 20GB of storage,
which greatly exceeds the 1GB available in RPCEmu hd4. Moreover, if it
becomes corrupted, RPCEmu hd4 can cause a major problem, since it cannot
then be accessed via RPCEmu, and the only way out is to delete it. On
the other hand, HostFS can be accessed via Windows, allowing it to be
modified, without using RPCEmu.
> I tend to use 5.17 for graphics-intensive stuff (just done a 24-page
> calendar using OvPro which produced an 82MB file). Given these
> results, I can see benefit in shifting activity further towards 5.XX,
> but the lack of HD4 is a bit of a showstopper.
Why? Here, RPCEmu089/519 (16-Jul-12) works perfectly well, using HostFS
for boot, and storage. BTW it also has networking.
> Do you know if the memory-leak problem which prevented HD4
> installation on 5.17 has been sorted by 5.19?
I wouldn't know, but the version here (16-Jul-12) does not have hd4.
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[snip speed tests]
> At the moment 4.02 is my primary RPCEmu setup; it has networking, a
> HardDisc4 (necessary for Photodesk to run)
I know nothing about Photodesk, but why does it need HardDisc4? Is that
path 'hard-wired' into the application?
> and can run all the legacy stuff I use (Eureka, Rhapsody).
As far as I can see, RPCEmu089/439 runs all the applications which
formerly ran on SARPC/439. The hard disc of my SARPC/620 (excepting
!Boot) is mirrored to the HostFS of RPCEmu089/439 so that, if the SARPC
is unwell, I can switch to RPCEmu. This needs about 20GB of storage,
which greatly exceeds the 1GB available in RPCEmu hd4. Moreover, if it
becomes corrupted, RPCEmu hd4 can cause a major problem, since it cannot
then be accessed via RPCEmu, and the only way out is to delete it. On
the other hand, HostFS can be accessed via Windows, allowing it to be
modified, without using RPCEmu.
> I tend to use 5.17 for graphics-intensive stuff (just done a 24-page
> calendar using OvPro which produced an 82MB file). Given these
> results, I can see benefit in shifting activity further towards 5.XX,
> but the lack of HD4 is a bit of a showstopper.
Why? Here, RPCEmu089/519 (16-Jul-12) works perfectly well, using HostFS
for boot, and storage. BTW it also has networking.
> Do you know if the memory-leak problem which prevented HD4
> installation on 5.17 has been sorted by 5.19?
I wouldn't know, but the version here (16-Jul-12) does not have hd4.
Tony
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: libhubbub parse error on google homepage
On Wed, Oct 24, 2012 at 02:54:49AM -0700, Dean Mao wrote:
> Here's a more compact test:
>
> <script>for(var i=0;i<n;i++);</script>
>
> Outputs:
>
> START TAG: 'script'
> CHARACTERS: 'for(var i=0;i'
> START TAG: 'n;i++);<' attributes:
> 'script' = ''
>
> Essentially everything inside a <script> tag should be treated as
> characters until a </script> tag is seen.
Yes. This behaviour you're seeing is expected. The HTML5 tokeniser has a
number of modes, which are selected by the token handler callback
provided by the client. The trivial token handler in test/tokeniser.c
does not manipulate the tokeniser mode, thus it does not handle the
contents of script (and other, similar) elements in the expected fashion.
The treebuilder implementation in Hubbub does manipulate the tokeniser
mode in the correct way. In most cases, you'll want to use the built-in
treebuilder, as it handles all the complexity of coping with junk input
for you. See examples/libxml.c for a demonstration of how to use the
built-in treebuilder.
If you do only wish to use the tokeniser, then you need to ensure that
your token handler changes the tokeniser mode in the same way that an
HTML5 treebuilder would.
J.
> Here's a more compact test:
>
> <script>for(var i=0;i<n;i++);</script>
>
> Outputs:
>
> START TAG: 'script'
> CHARACTERS: 'for(var i=0;i'
> START TAG: 'n;i++);<' attributes:
> 'script' = ''
>
> Essentially everything inside a <script> tag should be treated as
> characters until a </script> tag is seen.
Yes. This behaviour you're seeing is expected. The HTML5 tokeniser has a
number of modes, which are selected by the token handler callback
provided by the client. The trivial token handler in test/tokeniser.c
does not manipulate the tokeniser mode, thus it does not handle the
contents of script (and other, similar) elements in the expected fashion.
The treebuilder implementation in Hubbub does manipulate the tokeniser
mode in the correct way. In most cases, you'll want to use the built-in
treebuilder, as it handles all the complexity of coping with junk input
for you. See examples/libxml.c for a demonstration of how to use the
built-in treebuilder.
If you do only wish to use the tokeniser, then you need to ensure that
your token handler changes the tokeniser mode in the same way that an
HTML5 treebuilder would.
J.
Re: Google + -Your Browser is no longer supported
In message <ee9d9ee352.iyojohn@rickman.argonet.co.uk>
John Rickman Iyonix <rickman@argonet.co.uk> wrote:
> A web page with the subject message appears when I try to access
> Google+ from NetSurf.
> https://plus.google.com/
> Clicking on learn more the next page says:
> Google+ is supported in the following browsers:
> Windows: Chrome, Firefox 3.6 and beyond, Internet Explorer 8 ...
> Linux: Chrome, Firefox 3.6 and beyond
> Mac: Chrome, Firefox 3.6 and beyond, Safari 4 and beyond
> Is this a good case for faking the User-Agent string?
There is a "Tell us how we're doing" feedback button - very quick to
complete, though I don't know how much notice they will take...
--
Allan Bennett
John Rickman Iyonix <rickman@argonet.co.uk> wrote:
> A web page with the subject message appears when I try to access
> Google+ from NetSurf.
> https://plus.google.com/
> Clicking on learn more the next page says:
> Google+ is supported in the following browsers:
> Windows: Chrome, Firefox 3.6 and beyond, Internet Explorer 8 ...
> Linux: Chrome, Firefox 3.6 and beyond
> Mac: Chrome, Firefox 3.6 and beyond, Safari 4 and beyond
> Is this a good case for faking the User-Agent string?
There is a "Tell us how we're doing" feedback button - very quick to
complete, though I don't know how much notice they will take...
--
Allan Bennett
Re: Google + -Your Browser is no longer supported
On Wed, Oct 24, 2012 at 10:56:54AM +0100, John Rickman Iyonix wrote:
> A web page with the subject message appears when I try to access
> Google+ from NetSurf.
> https://plus.google.com/
> Clicking on learn more the next page says:
>
> Google+ is supported in the following browsers:
> Windows: Chrome, Firefox 3.6 and beyond, Internet Explorer 8 ...
> Linux: Chrome, Firefox 3.6 and beyond
> Mac: Chrome, Firefox 3.6 and beyond, Safari 4 and beyond
>
> Is this a good case for faking the User-Agent string?
Frankly, given the vast quantity of JavaScript and other DOM faffery which G+
does, I'm amazed it ever worked at all. There's nothing we can do until such
time as we have our JS and DOM linked up, and a dynamic render engine sorted.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> A web page with the subject message appears when I try to access
> Google+ from NetSurf.
> https://plus.google.com/
> Clicking on learn more the next page says:
>
> Google+ is supported in the following browsers:
> Windows: Chrome, Firefox 3.6 and beyond, Internet Explorer 8 ...
> Linux: Chrome, Firefox 3.6 and beyond
> Mac: Chrome, Firefox 3.6 and beyond, Safari 4 and beyond
>
> Is this a good case for faking the User-Agent string?
Frankly, given the vast quantity of JavaScript and other DOM faffery which G+
does, I'm amazed it ever worked at all. There's nothing we can do until such
time as we have our JS and DOM linked up, and a dynamic render engine sorted.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Google + -Your Browser is no longer supported
A web page with the subject message appears when I try to access
Google+ from NetSurf.
https://plus.google.com/
Clicking on learn more the next page says:
Google+ is supported in the following browsers:
Windows: Chrome, Firefox 3.6 and beyond, Internet Explorer 8 ...
Linux: Chrome, Firefox 3.6 and beyond
Mac: Chrome, Firefox 3.6 and beyond, Safari 4 and beyond
Is this a good case for faking the User-Agent string?
--
John - http://mug.riscos.org/
Google+ from NetSurf.
https://plus.google.com/
Clicking on learn more the next page says:
Google+ is supported in the following browsers:
Windows: Chrome, Firefox 3.6 and beyond, Internet Explorer 8 ...
Linux: Chrome, Firefox 3.6 and beyond
Mac: Chrome, Firefox 3.6 and beyond, Safari 4 and beyond
Is this a good case for faking the User-Agent string?
--
John - http://mug.riscos.org/
Subscribe to:
Posts (Atom)