On 27 Apr, cj wrote in message
<56ef67beabchris@chris-johnson.org.uk>:
> In article <9e0265ef56.jim@6.abbeypress.net>,
> Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> > Anybody concur with me?
>
> Yes - this has been present since the dark ages. I thought it had been
> reported many years ago.
I'm fairly sure (without going to check) that it's both known about and has
been stated that it is being ignored until the component responsible is
replaced as part of the road to Javascript. I'm guessing the layout engine,
but I could easily be wrong on that -- as Chris says, it has been many
years.
--
Steve Fryatt - Leeds, England
http://www.stevefryatt.org.uk/
Friday, 27 April 2018
Re: bad linebreaks
On 27 Apr 2018 Jim Nagel wrote:
> Anybody concur with me?
Yes I've raised bug reports about it in the past.
--
Richard Porter http://www.minijem.plus.com/
t: @westernexplorer mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
> Anybody concur with me?
Yes I've raised bug reports about it in the past.
--
Richard Porter http://www.minijem.plus.com/
t: @westernexplorer mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
Re: bad linebreaks
In article <9e0265ef56.jim@6.abbeypress.net>,
Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> Anybody concur with me?
Yes - this has been present since the dark ages. I thought it had
been reported many years ago.
--
Chris Johnson
Edinburgh
Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> Anybody concur with me?
Yes - this has been present since the dark ages. I thought it had
been reported many years ago.
--
Chris Johnson
Edinburgh
bad linebreaks
I raised a report on the bug-tracker about really bad linebreaks that
Netsurf sometimes commits.
This isn't a new thing. I'm using #4316 but fault has existed since
many many versions ago and as far as I know has never been reported.
My theory is that the Netsurf code thinks it's OK to start a new line
when text reaches nearly the edge of the frame and that it can perform
the break not only at a wordspace but also at an HTML tag, i.e. at "<"
or ">" or "&xxx;". (Hmm, what about ?)
You too often see a word like "John’s" with the apostrophe-s or
just the -s on the next line. Or a split in the middle of something
like "<i>x</i><sup>2</sup>=4<i>y</i>". Or "(<a href=...> blabla</a>)"
can leave the opening or closing parenthesis on a different line. Or
worse.
It obviously depends on the width of the window, so you might have to
drag the width to see it happen (presuming of course that it's not a
fixed-width page). Try a news page from http://theregister.co.uk as
an example.
Anybody concur with me?
--
Jim Nagel www.archivemag.co.uk
Netsurf sometimes commits.
This isn't a new thing. I'm using #4316 but fault has existed since
many many versions ago and as far as I know has never been reported.
My theory is that the Netsurf code thinks it's OK to start a new line
when text reaches nearly the edge of the frame and that it can perform
the break not only at a wordspace but also at an HTML tag, i.e. at "<"
or ">" or "&xxx;". (Hmm, what about ?)
You too often see a word like "John’s" with the apostrophe-s or
just the -s on the next line. Or a split in the middle of something
like "<i>x</i><sup>2</sup>=4<i>y</i>". Or "(<a href=...> blabla</a>)"
can leave the opening or closing parenthesis on a different line. Or
worse.
It obviously depends on the width of the window, so you might have to
drag the width to see it happen (presuming of course that it's not a
fixed-width page). Try a news page from http://theregister.co.uk as
an example.
Anybody concur with me?
--
Jim Nagel www.archivemag.co.uk
Re: Netsurf Disc Cache
In article <56ef43aa6dnetsurf@avisoft.f9.co.uk>,
Martin Avison <netsurf@avisoft.f9.co.uk> wrote:
> If anyone wants to try my small program which produces file and directory
> statistics for the disc cache, plus an obey file which if run will delete
> all empty directories, please email me.
Yes please.
I have, on a few occasions, simply deleted <Cache$Dir>.Netsurf and
released several GB of space. Deleting the whole cache causes no
noticeable problem.
--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!
Martin Avison <netsurf@avisoft.f9.co.uk> wrote:
> If anyone wants to try my small program which produces file and directory
> statistics for the disc cache, plus an obey file which if run will delete
> all empty directories, please email me.
Yes please.
I have, on a few occasions, simply deleted <Cache$Dir>.Netsurf and
released several GB of space. Deleting the whole cache causes no
noticeable problem.
--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!
Netsurf Disc Cache
I know from previous posts that using the Netsurf v3.7 disc cache on my
Iyonix running RISC OS is probably not improving performance, depending
on how low my internet speed is. I am using it to gain experience in the
hope that newer, faster hardware will bring some performance benefits.
After running with a Disc cache of 500MB and expiry of 30 days for about
2 years it was holding around 6,000 files using about 580MB. Old unused
files are being deleted, so these numbers seem stable and acceptable.
But it was using 45,000 directories ... 23,000 of which were empty (or
just contained other empty directories) occupying 45MB of disc space. I
realise these figures are small on today's large discs, but I am still
concerned that there is no 'clean up' process for unused empty
directories, so they will just grow and grow.
Earlier this month I deleted all empty directories, with no problems.
If anyone wants to try my small program which produces file and directory
statistics for the disc cache, plus an obey file which if run will delete
all empty directories, please email me.
Martin
Iyonix running RISC OS is probably not improving performance, depending
on how low my internet speed is. I am using it to gain experience in the
hope that newer, faster hardware will bring some performance benefits.
After running with a Disc cache of 500MB and expiry of 30 days for about
2 years it was holding around 6,000 files using about 580MB. Old unused
files are being deleted, so these numbers seem stable and acceptable.
But it was using 45,000 directories ... 23,000 of which were empty (or
just contained other empty directories) occupying 45MB of disc space. I
realise these figures are small on today's large discs, but I am still
concerned that there is no 'clean up' process for unused empty
directories, so they will just grow and grow.
Earlier this month I deleted all empty directories, with no problems.
If anyone wants to try my small program which produces file and directory
statistics for the disc cache, plus an obey file which if run will delete
all empty directories, please email me.
Martin
Sunday, 22 April 2018
Re: [gccsdk] Absolute binaries giving incorrect __riscosify_control
On 20/04/2018 17:00, Lee Noar wrote:
> On 19/04/18 12:51, Theo Markettos wrote:
>> On Wed, Apr 18, 2018 at 01:44:45PM +0100, Duncan Moore wrote:
>>> I have ELF and Absolute binaries getting different values of
>>> __riscosify_control from UnixEnv$progname$nonametrans. It's the Absolute
>>> binary that is giving the wrong result, and it only seems to happen when the
>>> binary is run via a RISC OS variable containing the full pathname of the
>>> binary.
>> Hmm... I'm not familiar with that code, but I'm puzzled. As far as I can
>> see elf2aif is simply slapping a pre-baked header on the ELF which does
>> zero-initialisation and then jumps to the ELF's entry point. Beyond a
>> handful of instructions they're identical.
>>
>> __riscosify_control is a weak symbol so there *could* be something different
>> in linking, but here the linked binary is static and the difference is shown
>> with the same linked binary, with and without header.
>>
>> So my guess is either that the header has some subtle side effect on the OS
>> that causes it to do different things, or that SOManager is changing things
>> when a statically linked ELF is run directly.
>>
>> Lee, do you have any thoughts?
> Yes, in the last AIF one, the code that constructs the system variable
> name in Unixlib takes the program name as <Test$pathname>, so it's
> looking for a variable called UnixEnv$<Test$pathname>$nonametrans which
> obviously fails.
Shouldn't Unixlib really be expanding <Test$pathname> to the full
pathname, getting the leafname, and then looking for a variable called
UnixEnv$leafname$nonametrans?
_______________________________________________
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
> On 19/04/18 12:51, Theo Markettos wrote:
>> On Wed, Apr 18, 2018 at 01:44:45PM +0100, Duncan Moore wrote:
>>> I have ELF and Absolute binaries getting different values of
>>> __riscosify_control from UnixEnv$progname$nonametrans. It's the Absolute
>>> binary that is giving the wrong result, and it only seems to happen when the
>>> binary is run via a RISC OS variable containing the full pathname of the
>>> binary.
>> Hmm... I'm not familiar with that code, but I'm puzzled. As far as I can
>> see elf2aif is simply slapping a pre-baked header on the ELF which does
>> zero-initialisation and then jumps to the ELF's entry point. Beyond a
>> handful of instructions they're identical.
>>
>> __riscosify_control is a weak symbol so there *could* be something different
>> in linking, but here the linked binary is static and the difference is shown
>> with the same linked binary, with and without header.
>>
>> So my guess is either that the header has some subtle side effect on the OS
>> that causes it to do different things, or that SOManager is changing things
>> when a statically linked ELF is run directly.
>>
>> Lee, do you have any thoughts?
> Yes, in the last AIF one, the code that constructs the system variable
> name in Unixlib takes the program name as <Test$pathname>, so it's
> looking for a variable called UnixEnv$<Test$pathname>$nonametrans which
> obviously fails.
Shouldn't Unixlib really be expanding <Test$pathname> to the full
pathname, getting the leafname, and then looking for a variable called
UnixEnv$leafname$nonametrans?
_______________________________________________
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
Subscribe to:
Posts (Atom)