Re: Hotlist on RISCOS

In article <de43c10653.old_coaster@old_coaster.yahoo.co.uk>,
Tony Moore <old_coaster@yahoo.co.uk> wrote:
> On 31 Dec 2012, "Gerald Dodson" <gerald.dodson@argonet.co.uk> wrote:

> > I often have trouble re-arranging the Hotlist. In particular grouping
> > items into a directory. At the moment I have a new directory into
> > which I have been trying to place a number of items not currently in a
> > directory.

> Drag the selected items to the _lower_ half of the directory icon.

> Tony

And you'll be lucky if you hit the spot (Once in a blue moon).
The receptive bit for the D&D must be about one or two pixels in size, and
don't ever bother if the Directory is at the bottom of the window, you'll
never get it in.

Yes I know, drag it (Directory) up the window...

Dave

--

Dave Triffid

Re: Hotlist on RISCOS

On 31 Dec 2012, "Gerald Dodson" <gerald.dodson@argonet.co.uk> wrote:

> I often have trouble re-arranging the Hotlist. In particular grouping
> items into a directory. At the moment I have a new directory into
> which I have been trying to place a number of items not currently in a
> directory.

Drag the selected items to the _lower_ half of the directory icon.

Tony

Hotlist on RISCOS

I often have trouble re-arranging the Hotlist. In particular grouping
items into a directory. At the moment I have a new directory into which I
have been trying to place a number of items not currently in a directory.

Gerald

Re: [gccsdk] Help with gas

On 12/31/2012 06:55 AM, John Tytgat wrote:
> In message <20121230165053.5732A27C7C@orac.inputplus.co.uk>
> Ralph Corderoy <ralph@inputplus.co.uk> wrote:
>
>> Without -c for `compile only' the C compiler kicks off the
>> linker/loader, the `ld' in the output, to produce a finished executable.
>> ld observes the C runtime tries to call main() but no main() is defined.
>
> Indeed. For further better understanding what's going on, you can use
> gcc's -v option. That will show all executing subprocesses : preprocessing,
> compiling, assmebling and/or linking.

Full:

http://www.riscos.info/index.php/GCC_tutorial

_______________________________________________
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] Help with gas

In message <20121230165053.5732A27C7C@orac.inputplus.co.uk>
Ralph Corderoy <ralph@inputplus.co.uk> wrote:

> Without -c for `compile only' the C compiler kicks off the
> linker/loader, the `ld' in the output, to produce a finished executable.
> ld observes the C runtime tries to call main() but no main() is defined.

Indeed. For further better understanding what's going on, you can use
gcc's -v option. That will show all executing subprocesses : preprocessing,
compiling, assmebling and/or linking.

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

Save hotlist bug fixed.

RISC OS build #755. The bug which truncated saves of the hotlist and
global history has been fixed. Many thanks to jmb.

My full hotlist has been restored from a backup, and has been
successfully added to.

With best wishes,

Peter.

--
Peter Young (zfc Ta) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Re: [gccsdk] Help with gas

In message <20121230165053.5732A27C7C@orac.inputplus.co.uk> you wrote:

> Try one of
>
> gcc -c sys.s
> gcc -c -o sys.o sys.s

> Without -c for `compile only' the C compiler kicks off the
> linker/loader, the `ld' in the output, to produce a finished executable.
> ld observes the C runtime tries to call main() but no main() is defined.

Brilliant! That did it.

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
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] Help with gas

Hi Gavin,

> I am making a serious effort (again) to get to grips with gcc4_1_2r2.
> I am trying to assemble a short piece of ARM code with
> gcc -o sys.o sys.s

Try one of

gcc -c sys.s
gcc -c -o sys.o sys.s

> I keep getting an error:
> ....: In function 'crt1_data':
> crt0.S:(.data+0x14): undefined reference to 'main'
> collect2: ld returned 1 exit status
> make: *** [sys.o] Error 1

Without -c for `compile only' the C compiler kicks off the
linker/loader, the `ld' in the output, to produce a finished executable.
ld observes the C runtime tries to call main() but no main() is defined.

Cheers, Ralph.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

[gccsdk] Help with gas

I am making a serious effort (again) to get to grips with gcc4_1_2r2.
I am trying to assemble a short piece of ARM code with
gcc -o sys.o sys.s
I keep getting an error:
....: In function 'crt1_data':
crt0.S:(.data+0x14): undefined reference to 'main'
collect2: ld returned 1 exit status
make: *** [sys.o] Error 1

I have no idea what any of this means. The code used to assemble without
fuss for objasm. I changed ; to @, EXPORT to .global, put colons
after the label declarations, changed the AREA directive to .text
and removed the END statement.

Can anybody with experience see what I have left undone or done wrong?
There are no data areas, no internal references, only relocatable code.
The only constants are immediate ones in instructions. There are no
PC-relative loads or stores. I suspect that I have not told gas something
that it wants to know, but it is not too clever at telling me what.

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
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: Bug tracker misbehaving.

In article <6199da0553.pnyoung@pnyoung.ormail.co.uk>, Peter Young
<pnyoung@ormail.co.uk> wrote:

[Snip]

> Thanks for reminding me. I still have 2.9 here; now, how do I remember
> to use it for reporting bugs?

Put a copy of 2.9 in a folder called "netsurf.reporting bugs".

What's a rhetorical question?

--
Tim Hill
..............................................................
www.timil.com

Re: Bug tracker misbehaving.

On 29 Dec 2012 Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:

> The following bytes were arranged on 28 Dec 2012 by Peter Young :

>> The attempt to upload the report produced an obscure error message in
>> a NetSurf page, and I regret I forgot to record this.

> Luckily, you were not so neglectful the last time you made exactly the
> same complaint on this very list:

> http://vlists.pepperfish.net/pipermail/netsurf-users-netsurf-browser.o
> rg/2012-November/011272.html

> Data submission in general appears to have been seriously broken in the
> test builds. 2.9 doesn't have these problems.

Thanks for reminding me. I still have 2.9 here; now, how do I remember
to use it for reporting bugs?

With best wishes,

Peter.

--
Peter Young (zfc Ta) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Re: Bug tracker misbehaving.

The following bytes were arranged on 28 Dec 2012 by Peter Young :

> The attempt to upload the report produced an obscure error message in
> a NetSurf page, and I regret I forgot to record this.

Luckily, you were not so neglectful the last time you made exactly the
same complaint on this very list:

http://vlists.pepperfish.net/pipermail/netsurf-users-netsurf-browser.org/2012-November/011272.html

Data submission in general appears to have been seriously broken in the
test builds. 2.9 doesn't have these problems.

--
__<^>__ Red sky in the morning: Shepherd's warning
/ _ _ \ Red sky at night: Shepherd's delight
( ( |_| ) ) Mince and potatoes: Shepherd's pie
\_> <_/ ======================= Martin Bazley ==========================

Bug tracker misbehaving.

I've just wasted quite a bit of time trying and failing to report a
bug using RISC OS NetSurf #749; yes, I did remember to disable
JavaScript! The attempt to upload the report produced an obscure error
message in a NetSurf page, and I regret I forgot to record this. The
report has duly been sent via Windows Firefox.

A happy New Year to the developers, whose efforts are greatly
appreciated.

With best wishes,

Peter.

--
Peter Young (zfc Ta) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Re: [gccsdk] stderr 2 file advantage

In message <20121223124205.46E522522B@orac.inputplus.co.uk>
Ralph Corderoy <ralph@inputplus.co.uk> wrote:

> Hi Ron,
>
> > I can get this to error (foo.tar is in CSD in RAM:)
> > ADFS::HardDisc4.$.!TarCtrl.Files.Bin.tar vxf foo.tar but moving the
> > tar binary to the same directory and all is OK. tar vxf foo.tar
>
> Could it be a memory corruption issue and changing the command line is
> altering whether real data as opposed to padding it being trampled?
> Perhaps ensure ADFS::HardDisc4.$.!TarCtrl.Files.Bin.tar still fails then
> rename the path to be shorter, character by character, and see if
> there's a pattern to when it works.
>
> Cheers, Ralph.
>

Possible memory corruption is another complication, and rebooting with
different approaches is necessary now and again to stop drawing wrong
conclusions.
It is possible to get the error to toggle just around the changing of
one character, for example I tried something similar to your
suggestion and it appeared to work without the ! in the path.
A reboot dispelled that theory and for 'good measure' worked as expected
not erroring as in the initially described way either.

I am (quietly) confident that the space before tarfile is the actual
culprit because:
1. I went down a similar road getting the multipart activity to work.
When multiparting, a filename is included in the command and I resolved
it by removing the space. eg -Ffoo instead of -F foo

2. I haven't seen tar vx -file=foo.tar fail in any situation yet.
I cant just remove the space by doing tar vxffoo.tar but --file=foo.tar
does allow not having a preceding space before the filename.

ADFS::HardDisc4.$.!TarCtrl.Files.Bin.tar vxf RAM::RamDisc0.$/ptp-gadget.tar
will error unless I set the CSD to the RAM directory, which also means the
full RAM path isn't necessary anyway.

However the full path works without setting CSD if I use --file=RAM::RA...
form.

I'll try applying this later finding to another ELF binary to see if
I can replicate the later illustration.

Thanks, Ron M.



_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: Branch mono/interactive-about_config

On Sat, Dec 22, 2012 at 12:33:46PM +0000, Chris Young wrote:
> 2. I'm not sure if there are any options that are dangerous to change
> during run-time, but if so there should be the possibility of making
> these read-only.

The proxy settings.

B.

Re: [gccsdk] stderr 2 file advantage

Hi Ron,

> I can get this to error (foo.tar is in CSD in RAM:)
> ADFS::HardDisc4.$.!TarCtrl.Files.Bin.tar vxf foo.tar but moving the
> tar binary to the same directory and all is OK. tar vxf foo.tar

Could it be a memory corruption issue and changing the command line is
altering whether real data as opposed to padding it being trampled?
Perhaps ensure ADFS::HardDisc4.$.!TarCtrl.Files.Bin.tar still fails then
rename the path to be shorter, character by character, and see if
there's a pattern to when it works.

Cheers, Ralph.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] stderr 2 file advantage

In message <20121220224639.08723243FB@orac.inputplus.co.uk>
Ralph Corderoy <ralph@inputplus.co.uk> wrote:

> John wrote:
> > > Very bizar, looks like a real bug somewhere but someone needs to dig
> > > into this as I don't think we can just guess it based on above facts
> > > only.
>
> Perhaps there's something up with stderr, file descriptor 2, and that
> causes the first signal the handling of which wobbles because it would
> like to use stderr?
>
> Is there something on RISC OS like strace(1) now? On Linux, one can see
> tar doing things like GET_FD on FD 2 early on, with, for example, an
> opening of /dev/null if it's a bad file descriptor.
>
> tar -xvf foo.tar 2>&-
>
> Cheers, Ralph.

The tough thing about this instability, is that it is almost a moving
target.
Since the above occurrence, I haven't been automatically getting the
SIGSEV error, and when I do get it, the stderr direction now doesn't
help at all.
So stderr is looking like a red herring now.
Other command modifying can get it to work.
The --format=pax addition seems to always make it work but
I am beginning to see that it is to do with changing the 'weight' of
the command rather than it being needed.
Using the form -vx --file=foo.tar seems to be a fix also, but time will
tell, as I think that varying command content can change the behaviour.

To add to the changes brought about by tar command changes, I have
also found that the RISC OS path to the tar binary can affect it.

I can get this to error (foo.tar is in CSD in RAM:)
ADFS::HardDisc4.$.!TarCtrl.Files.Bin.tar vxf foo.tar
but moving the tar binary to the same directory and all is OK.
tar vxf foo.tar

The few times I have tried the older tar package with tar 1.22
it has coped with the same situation that stops my later 4x port
of 1.26 also, so I'm assuming this command instability is from
either our modern cross compiler or the newer tar 1.26.

The fact that the variation of the RISC OS path to the binary
can alter the behaviour might suggest that the instability is
brought about at an early SharedLibs stage -perhaps.
Or maybe CSD related, I think I /did/ update my crosscompiler
after noticing some recent changes in that area though.

Thanks, Ron M.






_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: Branch mono/interactive-about_config

Ole <ole@monochrom.net> wrote:

> I do not agree on the idea that the treeview doesn't look "native".
> That's mostly because of it's background colour ;)

The background colour is meant to be set by the front end.

See the gui_system_colour_* stuff.

--

Michael Drake (tlsa) http://www.netsurf-browser.org/

Re: Branch mono/interactive-about_config

Am Samstag, den 22.12.2012, 13:33 +0100 schrieb "Chris Young"
<chris.young@unsatisfactorysoftware.co.uk>:

> I'm not sure the reasoning behind implementation is the correct one,
> but I do like the concept, especially for power users and developers
> who need to change advanced options during run-time.

Right. I also think that way.

But this was discussed on IRC and John Mark Bell is against such
features
int the "core".

I understand JMB's reasons but I do not agree with it. Personally I
think
that more features in the core is better than less features. But JMB
wants the core to be feature rich on HTML rendering, not option
editing.

He also dislikes the treeview idea... but that makes porting much
more comfortable... I do not agree on the idea that the treeview
doesn't
look "native". That's mostly because of it's background colour ;)
During treeview redraw you can use an font for plotting which fits your
system font,... and also the treeview icons can be made customized for
your frontend.

Greets,
Ole

--
---

Re: Branch mono/interactive-about_config

On Sat, 2012-12-22 at 12:33 +0000, Chris Young wrote:
> On Fri, 21 Dec 2012 14:20:21 +0100, Ole wrote:
>
> > I have created a branch where you can interactively edit the Choices by
> > going to "about:config" URL.
> >
> > The reason:
> > I had to re-implement the atari settings dialog but I was to lazy to do
> > all that.
>
> I'm not sure the reasoning behind implementation is the correct one,
> but I do like the concept, especially for power users and developers
> who need to change advanced options during run-time.

The problem with this is two-fold:

1) Within NetSurf, we've always taken the view that configurable
options should be kept to a minimum, with sensible default
behaviour. Where options are necessary, they should be presented
in a proper manner to all users (i.e. in a way that's in keeping
with the platform the software is being run on). This means that
the concept of "advanced options" should never occur.

2) Implementing any UI in HTML sets an unpleasant precedent. It's the
start of a slippery slope towards using it for everything, and
ceasing to care about differences between platform UI conventions.
Great effort has been spent ensuring that we do integrate properly
with the platforms that we run on. Where we do not, it's a bug and
should be fixed.

Making it easy to add options without having to provide proper
configuration UI for them can only result in a worse user experience --
as your list of usability issues suggests.


J.

Re: Branch mono/interactive-about_config

On Fri, 21 Dec 2012 14:20:21 +0100, Ole wrote:

> I have created a branch where you can interactively edit the Choices by
> going to "about:config" URL.
>
> The reason:
> I had to re-implement the atari settings dialog but I was to lazy to do
> all that.

I'm not sure the reasoning behind implementation is the correct one,
but I do like the concept, especially for power users and developers
who need to change advanced options during run-time.

I have a couple of comments:

1. It would be nice if the options that have particular effects for
integer values, were a drop-down choice rather than an integer gadget
(this stop sthe users selecting out-of-range values and makes it clear
what the choice is going to do). eg. http_proxy_auth would show the
options "No proxy", "NTLM authentication".

1b. As above but for fields expecting filenames, paths and colours
should show something appropriate to make the choice easier and avoid
errorneous input, although these might be tricky to implement given
the constraints of HTML.

2. I'm not sure if there are any options that are dangerous to change
during run-time, but if so there should be the possibility of making
these read-only.

Chris

Re: Serious error

On 21 Dec 2012 Dave Higton <dave@davehigton.me.uk> wrote:

> In message <5301b9730dbbailey@argonet.co.uk>
> Brian Bailey <bbailey@argonet.co.uk> wrote:

>> Serious error and crash,
>>
>> http://lightroomkillertips.com/2010/presets-the-trick-to-getting-good-
>> prints/
>>
>> RISC OS 4.02 NetSurf #749

> OK for me, #749, with Javascript enabled or not. Iyonix, 5.18, 512 MiB.

Bug report submitted. Here, ARMini, RISC OS 5.19, crashes with
JavaScript enabled, OK with it disabled.

With best wishes,

Peter.

--
Peter Young (zfc Ta) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Re: Serious error

In message <5301b9730dbbailey@argonet.co.uk>
Brian Bailey <bbailey@argonet.co.uk> wrote:

> Serious error and crash,
>
> http://lightroomkillertips.com/2010/presets-the-trick-to-getting-good-prints/
>
> RISC OS 4.02 NetSurf #749

OK for me, #749, with Javascript enabled or not. Iyonix, 5.18, 512 MiB.

Dave

____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth

Re: Serious error

On 21 Dec 2012 Brian Bailey wrote:

> Serious error and crash,


> http://lightroomkillertips.com/2010/presets-the-trick-to-getting-good-prints/

> RISC OS 4.02 NetSurf #749


OK with #739 OS6

--
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.

Serious error

Serious error and crash,


http://lightroomkillertips.com/2010/presets-the-trick-to-getting-good-prints/

RISC OS 4.02 NetSurf #749

Re: Branch mono/interactive-about_config

On 21/12/2012 14:20, Ole wrote:
> Hello,
>
> I have created a branch where you can interactively edit the Choices by
> going to "about:config" URL.
>
> The reason:
> I had to re-implement the atari settings dialog but I was to lazy to do
> all that.
> At least the framebuffer version can also benefit by this branch.

Indeed, and the BeOS/Haiku port too, that would save me some time to
work on other areas as well.

> It still requires to be secured. I though about an "random" token which
> get's generated on each
> delivery of about:config - the token on submit must match the last
> generated token.

I suppose it would work, I thought about that for another scheme I was
thinking about, as that would have saved some dialog boxes too.

>
> A screen-shot is attached for those who can not imagine what I'm talking
> about.

Looks nice to me.
I suppose it could take the Messages file into account to generate the
labels.
Also, booleans would probably be better with radio buttons.

François.

Branch mono/interactive-about_config

Hello,

I have created a branch where you can interactively edit the Choices by
going to "about:config" URL.

The reason:
I had to re-implement the atari settings dialog but I was to lazy to do
all that.
At least the framebuffer version can also benefit by this branch.

It still requires to be secured. I though about an "random" token which
get's generated on each
delivery of about:config - the token on submit must match the last
generated token.

A screen-shot is attached for those who can not imagine what I'm
talking about.

Is there any chance to have it merged into master when it is secured?

Greets,
Ole

Re: [gccsdk] stderr 2 file advantage

John wrote:
> > Very bizar, looks like a real bug somewhere but someone needs to dig
> > into this as I don't think we can just guess it based on above facts
> > only.

Perhaps there's something up with stderr, file descriptor 2, and that
causes the first signal the handling of which wobbles because it would
like to use stderr?

Is there something on RISC OS like strace(1) now? On Linux, one can see
tar doing things like GET_FD on FD 2 early on, with, for example, an
opening of /dev/null if it's a bad file descriptor.

tar -xvf foo.tar 2>&-

Cheers, Ralph.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] stderr 2 file advantage

In message <1ad80b0153.Jo@hobbes.bass-software.com>
John Tytgat <John.Tytgat@aaug.net> wrote:

> In message <5b44d00053.beeb@ron1954.woosh.co.nz>
> Ron <beeb@woosh.co.nz> wrote:
>
> > In message <6cddca0053.Jo@hobbes.bass-software.com>
> > John Tytgat <John.Tytgat@aaug.net> wrote:
> >
> > > In message <f2d8c70053.beeb@ron1954.woosh.co.nz>
> > > Ron <beeb@woosh.co.nz> wrote:
> > >
> > > > I'm not using the very latest crosscompiler, but I think this will be
> > > > unchanged.
> > > > Using my port of tar
> > > >
> > > > tar -xvf ztmp.tar
> > > >
> > > > stops with "UnixLib detected recursion of signal SIGSEGV. Exiting."
> > > > when I encounter a pax format tar, (unless I specify --format=pax)
> > > >
> > > > I set about trapping the error (in an obey file way) by using
> > > >
> > > > tar -xvf ztmp.tar 2> errlog
> > > >
> > > > so I could check a file for an error.
> > > >
> > > > But when I do this, the program /does/ create the file errlog,
> > > > but it remains empty, and tar now continues on and extracts the
> > > > pax format tar perfectly as if --format=pax has been used!
> > > >
> > > > A good result, but it raises the question why, and does stderr
> > > > always need to be directed somewhere for better behaviour?
> > >
> > > Are you launching tar straight from CLI ? Or is this in a fork()/exec()
> > > /system() done ?
> >
> > Either from an Obey file or from the CLI in a taskwindow, same result.
> > From memory,fork() is only used for the multipart tar activity.
> >
> > Directing stderr to stdout works equally as well.
> >
> > tar -xvf ztmp.tar 2>&1
>
> Very bizar, looks like a real bug somewhere but someone needs to dig into
> this as I don't think we can just guess it based on above facts only.
>
> John.

Ok, looking out for the same result from a port other than tar would at
least confirm it as a unixlib bug.
The only major change I make to tar is setting the constant for ,xyz
filetyping.
There is a clash with gettimeofday, and I use the unixlib version,
but it worked using the one in the source also.
I have been changing fork() for vfork() for multipart tars, but the
similar error I was encountering there may not be an issue now.

Thanks, Ron M.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] stderr 2 file advantage

In message <5b44d00053.beeb@ron1954.woosh.co.nz>
Ron <beeb@woosh.co.nz> wrote:

> In message <6cddca0053.Jo@hobbes.bass-software.com>
> John Tytgat <John.Tytgat@aaug.net> wrote:
>
> > In message <f2d8c70053.beeb@ron1954.woosh.co.nz>
> > Ron <beeb@woosh.co.nz> wrote:
> >
> > > I'm not using the very latest crosscompiler, but I think this will be
> > > unchanged.
> > > Using my port of tar
> > >
> > > tar -xvf ztmp.tar
> > >
> > > stops with "UnixLib detected recursion of signal SIGSEGV. Exiting."
> > > when I encounter a pax format tar, (unless I specify --format=pax)
> > >
> > > I set about trapping the error (in an obey file way) by using
> > >
> > > tar -xvf ztmp.tar 2> errlog
> > >
> > > so I could check a file for an error.
> > >
> > > But when I do this, the program /does/ create the file errlog,
> > > but it remains empty, and tar now continues on and extracts the
> > > pax format tar perfectly as if --format=pax has been used!
> > >
> > > A good result, but it raises the question why, and does stderr
> > > always need to be directed somewhere for better behaviour?
> >
> > Are you launching tar straight from CLI ? Or is this in a fork()/exec()
> > /system() done ?
>
> Either from an Obey file or from the CLI in a taskwindow, same result.
> From memory,fork() is only used for the multipart tar activity.
>
> Directing stderr to stdout works equally as well.
>
> tar -xvf ztmp.tar 2>&1

Very bizar, looks like a real bug somewhere but someone needs to dig into
this as I don't think we can just guess it based on above facts only.

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] stderr 2 file advantage

In message <6cddca0053.Jo@hobbes.bass-software.com>
John Tytgat <John.Tytgat@aaug.net> wrote:

> In message <f2d8c70053.beeb@ron1954.woosh.co.nz>
> Ron <beeb@woosh.co.nz> wrote:
>
> > I'm not using the very latest crosscompiler, but I think this will be
> > unchanged.
> > Using my port of tar
> >
> > tar -xvf ztmp.tar
> >
> > stops with "UnixLib detected recursion of signal SIGSEGV. Exiting."
> > when I encounter a pax format tar, (unless I specify --format=pax)
> >
> > I set about trapping the error (in an obey file way) by using
> >
> > tar -xvf ztmp.tar 2> errlog
> >
> > so I could check a file for an error.
> >
> > But when I do this, the program /does/ create the file errlog,
> > but it remains empty, and tar now continues on and extracts the
> > pax format tar perfectly as if --format=pax has been used!
> >
> > A good result, but it raises the question why, and does stderr
> > always need to be directed somewhere for better behaviour?
>
> Are you launching tar straight from CLI ? Or is this in a fork()/exec()
> /system() done ?
>
> John.

Either from an Obey file or from the CLI in a taskwindow, same result.
From memory,fork() is only used for the multipart tar activity.

Directing stderr to stdout works equally as well.

tar -xvf ztmp.tar 2>&1

Ron M.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] stderr 2 file advantage

In message <f2d8c70053.beeb@ron1954.woosh.co.nz>
Ron <beeb@woosh.co.nz> wrote:

> I'm not using the very latest crosscompiler, but I think this will be
> unchanged.
> Using my port of tar
>
> tar -xvf ztmp.tar
>
> stops with "UnixLib detected recursion of signal SIGSEGV. Exiting."
> when I encounter a pax format tar, (unless I specify --format=pax)
>
> I set about trapping the error (in an obey file way) by using
>
> tar -xvf ztmp.tar 2> errlog
>
> so I could check a file for an error.
>
> But when I do this, the program /does/ create the file errlog,
> but it remains empty, and tar now continues on and extracts the
> pax format tar perfectly as if --format=pax has been used!
>
> A good result, but it raises the question why, and does stderr
> always need to be directed somewhere for better behaviour?

Are you launching tar straight from CLI ? Or is this in a fork()/exec()
/system() done ?

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

[gccsdk] stderr 2 file advantage

I'm not using the very latest crosscompiler, but I think this will be
unchanged.
Using my port of tar

tar -xvf ztmp.tar

stops with "UnixLib detected recursion of signal SIGSEGV. Exiting."
when I encounter a pax format tar, (unless I specify --format=pax)

I set about trapping the error (in an obey file way) by using

tar -xvf ztmp.tar 2> errlog

so I could check a file for an error.

But when I do this, the program /does/ create the file errlog,
but it remains empty, and tar now continues on and extracts the
pax format tar perfectly as if --format=pax has been used!

A good result, but it raises the question why, and does stderr
always need to be directed somewhere for better behaviour?

Ron M.



_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

RE: Thetrainline.com crashes CI #744

> -----Original Message-----
> From: george.greenfield@tiscali.co.uk
> Sent: Tue, 18 Dec 2012 16:22:05 GMT
> To: netsurf-users@netsurf-browser.org
> Subject: RE: Thetrainline.com crashes CI #744
>
> In message <AE9C0B0201F.00000E9Fdave@davehigton.me.uk>
> Dave Higton <dave@davehigton.me.uk> wrote:
>
>>> -----Original Message-----
>>> From: george.greenfield@tiscali.co.uk
>>> Sent: Tue, 18 Dec 2012 09:20:59 GMT
>>> To: netsurf-users@netsurf-browser.org
>>> Subject: Thetrainline.com crashes CI #744
>>>
>>> Made three consecutive attempts to access Thetrainline.com using NS CI
>>> #744 with javascript enabled, each resulting in a NS crash and exit.
>>> Attempting to access the bug tracker and file a bug report crashed
>>> #744 again! Back to 2.9 for the bug report....
>>
>> I found that disabling Javascript on 744 enabled me to submit my
>> bug report (with file), which is easier than uninstalling etc.
>>
>> The quick smoke tests I've done with 744 with JS disabled don't show
>> any worse stability than versions prior to JS.
>>
>> There are also non-JS CI builds, if you prefer.
>
> Don't get me wrong: I intended no criticism of JS-enabled NetSurf, in
> fact I think it's splendid, and to be supported in every way,
> including the submission of bug reports where appropriate. It was just
> a bit ironic that the bug tracker itself was amongst the casualties!

Absolutely, and I'm sure you've seen my message of heartfelt
congratulations to everybody who contributed.

All I was doing was pointing out that, if you're testing a JS build
of NS, you shouldn't have to revert to 2.9 to report the bug; simply
disabling JS may well be enough. It's easier for you, and to continue
with a CI build would give it that bit more testing.

Dave

____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!

RE: Thetrainline.com crashes CI #744

In message <AE9C0B0201F.00000E9Fdave@davehigton.me.uk>
Dave Higton <dave@davehigton.me.uk> wrote:

>> -----Original Message-----
>> From: george.greenfield@tiscali.co.uk
>> Sent: Tue, 18 Dec 2012 09:20:59 GMT
>> To: netsurf-users@netsurf-browser.org
>> Subject: Thetrainline.com crashes CI #744
>>
>> Made three consecutive attempts to access Thetrainline.com using NS CI
>> #744 with javascript enabled, each resulting in a NS crash and exit.
>> Attempting to access the bug tracker and file a bug report crashed
>> #744 again! Back to 2.9 for the bug report....
>
> I found that disabling Javascript on 744 enabled me to submit my
> bug report (with file), which is easier than uninstalling etc.
>
> The quick smoke tests I've done with 744 with JS disabled don't show
> any worse stability than versions prior to JS.
>
> There are also non-JS CI builds, if you prefer.

Don't get me wrong: I intended no criticism of JS-enabled NetSurf, in
fact I think it's splendid, and to be supported in every way,
including the submission of bug reports where appropriate. It was just
a bit ironic that the bug tracker itself was amongst the casualties!

George

--
george greenfield

Re: Unicode on local pages

In message <3e10b8ff52.martin@blueyonder.co.uk> you wrote:

> The following bytes were arranged on 16 Dec 2012 by Gavin Wraith :
>
> > With NetSurf #739. If I browse
> > http://www.perseus.tufts.edu/hopper/text?doc=Perseus%3Atext%3A1999.01.0173%3Atext%3DSym.
> > it displays OK. If I save or do a full save of the page, and then browse
> > the resulting local page the Greek text displays as garbage. Why is there
> > a difference?
>
> This question's come up before. It's probably because, when you fetch
> the file over HTTP, the server knows it's in UTF-8 and tells NetSurf so,
> but when you load a local file, RISC OS doesn't tell NetSurf what
> encoding it's in and so NetSurf is reduced to guesswork. Presumably
> whatever encoding it defaults to is not the correct one in your case.

Thanks. I will have a look at the header and if necessary stick in the
right cantrap.

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

RE: Thetrainline.com crashes CI #744

> -----Original Message-----
> From: george.greenfield@tiscali.co.uk
> Sent: Tue, 18 Dec 2012 09:20:59 GMT
> To: netsurf-users@netsurf-browser.org
> Subject: Thetrainline.com crashes CI #744
>
> Made three consecutive attempts to access Thetrainline.com using NS CI
> #744 with javascript enabled, each resulting in a NS crash and exit.
> Attempting to access the bug tracker and file a bug report crashed
> #744 again! Back to 2.9 for the bug report....

I found that disabling Javascript on 744 enabled me to submit my
bug report (with file), which is easier than uninstalling etc.

The quick smoke tests I've done with 744 with JS disabled don't show
any worse stability than versions prior to JS.

There are also non-JS CI builds, if you prefer.

Dave

____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth

Thetrainline.com crashes CI #744

Made three consecutive attempts to access Thetrainline.com using NS CI
#744 with javascript enabled, each resulting in a NS crash and exit.
Attempting to access the bug tracker and file a bug report crashed
#744 again! Back to 2.9 for the bug report....

System details: RPCEmu089/402 Recompiler mode with 256MB running on
Win7 (64-bit).

George

--
george greenfield

Re: Cross-Compiler Build Instructions

On Mon, Dec 17, 2012 at 10:24:59PM +0000, Steve Fryatt wrote:
> On 16 Dec, Steve Fryatt wrote in message
> <mpro.mf5blp0je6log01jz.lists@stevefryatt.org.uk>:
>
> > I've just recreated my cross-compilation setup for NetSurf (currently on
> > Ubuntu 10.04, although that's likely to be changing soon), and have been
> > reading the BUILDING-ROcross documentation supplied in the Docs folder of
> > the source. I'd like to update that [...]
>
> I've had a further think about this, and come up with the attached revision
> to the document (I've not done a patch, as it's basically a complete
> re-write of what was there before). It now refers to the new build system,
> and reflects the migration to Git.
>
> It's written with the assumption that readers won't be trying to use the
> same source to build for other targets at the same time (and that if they
> are, they will know what to do to make it work correctly). I'm open to
> suggestions as to how to make it seamlessly multi-target without adding lots
> of complexity, however.
>
> Comments, suggestions, criticisms, etc welcome. I can't commit it myself as
> I can't write to Docs/, but if anyone else thinks it's ready for that, feel
> free.
>

looks pretty complete, will have to wait on the others for a review
though as my english is notoriously bad

> --
> Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
> Saturday 20 April 2013
> http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
>

sorry I did not reply earlier, day job got in the way.

You are obviously unaware that we have put together a toolchain build
system [1], its what the CI system uses for all its toolchains

The readme covers it too but:

$ apt-get install build-essential autoconf automake autogen flex bison libtool texinfo help2man subversion cvs
$ git clone git://git.netsurf-browser.org/toolchains.git
$ make -C arm-unknown-riscos
$ GCCSDK_INSTALL_CROSSBIN=/opt/netsurf/arm-unknown-riscos/cross/bin GCCSDK_INSTALL_ENV=/opt/netsurf/arm-unknown-riscos/env make -C sdk

will get you a fully working toolchan and libs. Alternatively you can
just download the precompiled toolchains from the ci system

[1] http://git.netsurf-browser.org/toolchains.git/

--
Regards Vincent
http://www.kyllikki.org/

Re: Unicode on local pages

The following bytes were arranged on 16 Dec 2012 by Gavin Wraith :

> With NetSurf #739. If I browse
> http://www.perseus.tufts.edu/hopper/text?doc=Perseus%3Atext%3A1999.01.0173%3Atext%3DSym.
> it displays OK. If I save or do a full save of the page, and then browse
> the resulting local page the Greek text displays as garbage. Why is there
> a difference?

This question's come up before. It's probably because, when you fetch
the file over HTTP, the server knows it's in UTF-8 and tells NetSurf so,
but when you load a local file, RISC OS doesn't tell NetSurf what
encoding it's in and so NetSurf is reduced to guesswork. Presumably
whatever encoding it defaults to is not the correct one in your case.

--
__<^>__ === RISC OS is a work of art. Some people adore it, ===
/ _ _ \ === others can't see the point of it, and it's really ===
( ( |_| ) ) === expensive. ===
\_> <_/ ======================= Martin Bazley ===================

Re: Cross-Compiler Build Instructions

On 16 Dec, Steve Fryatt wrote in message
<mpro.mf5blp0je6log01jz.lists@stevefryatt.org.uk>:

> I've just recreated my cross-compilation setup for NetSurf (currently on
> Ubuntu 10.04, although that's likely to be changing soon), and have been
> reading the BUILDING-ROcross documentation supplied in the Docs folder of
> the source. I'd like to update that [...]

I've had a further think about this, and come up with the attached revision
to the document (I've not done a patch, as it's basically a complete
re-write of what was there before). It now refers to the new build system,
and reflects the migration to Git.

It's written with the assumption that readers won't be trying to use the
same source to build for other targets at the same time (and that if they
are, they will know what to do to make it work correctly). I'm open to
suggestions as to how to make it seamlessly multi-target without adding lots
of complexity, however.

Comments, suggestions, criticisms, etc welcome. I can't commit it myself as
I can't write to Docs/, but if anyone else thinks it's ready for that, feel
free.

--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 20 April 2013
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/

Re: RISC OS Javascript support

In message <20121216210011.GN15360@kyllikki.org>
Vincent Sanders <vince@netsurf-browser.org> wrote:

> ok last try for now, ci #744 is built with spidermonkey 1.7.0 maybe it
> works maybe it doesn't.
>
> Please also remember to use the json tagged downloads if you want to try
> with javascript as the jsoff ones do not even have teh interpreter linked.

NS 746 json crashes when JS is enabled, on Slashdot, also on the
Sourceforge bug tracker "submit bug" link. Works fine when JS
is disabled.

I've submitted a bug report and log for Slashdot. You don't need
me to submit a log for SF as you know where that is and it's
entirely repeatable.

My heartfelt congratulations to everybody for getting this far!

Dave

____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop!
Check it out at http://www.inbox.com/marineaquarium

Re: RISC OS Javascript support

On Mon, 17 December, 2012 4:41 am, Michael Bell wrote:
> This is all *far* beyond my technical understanding and abilities, but
> let me say I am *very* grateful for all this work which makes RISC OS
> so much more useful.
>
> Merry Christmas!
>
> Michael Bell
>
Seconded with gratitude. I look forward to a stable (if limited) release
of Netsurf with JS. Huge thanks to developers and testers.

John Hurley

Re: RISC OS Javascript support

On 13 Dec, Vincent Sanders <vince@netsurf-browser.org> wrote:
> Thanks to Rob Kendrik, Chris Gransden and myself we now have NSPR and
> Spidermonkey libraries building in the NetSurf toolchain[1]. The CI
> system[1] has built the toolchain successfully and a copy of NetSurf
> for RISC OS with Javascript enabled[3].

Fantastic news, this looks like the start of a very long road, of course,
but many thanks guys!

Ta,

Steve

--
Steve @ PlusNet

Fetching NetSurf

Last October, John Williams created Fetch_NS, a tool to check for and
fetch the latest development build of NetSurf for RISC OS. I added a
couple of features and put it on my website (with John's consent), but I
seem to have forgotten to announce it...

As the development builds of NetSurf now come in two versions - with or
without JavaScript support - I added functionality to choose between the
two (no fancy GUI or anything like that - just setting a variable in an
Obey script). Go to http://aconet.org/tools#fetchns to download.

Please do not respond to this message on this list!
===================================================

This is just an announcement for the benefit of NetSurf users who want
an easy way to check for, download and install the latest development
version. Discussions about Fetch_NS should be held elsewhere. Please use
comp.sys.acorn.apps or archive-online for that.

Regards,
Frank

Re: RISC OS Javascript support

On 16 Dec 2012, Steve Fryatt <lists@stevefryatt.org.uk> wrote:
> On 16 Dec, Dave Higton wrote in message
> <f77c24ff52.DaveMeUK@my.inbox.com>:

[snip]

> > It does have a "Disable Javascript" item - but the effect doesn't
> > appear to be stored; the item always comes up as disabled when NS
> > starts.
>
> Are you using a build which contains JS? It works fine in a "json"
> build, but in a "jsoff" version it gets saved (look in the Choices)
> file, then lost on loading. However, I suspect that it's getting
> loaded and then overwritten to false by the dummy js_initialise() in
> javascript/none.c (which presumably isn't an issue in a build that
> actually contains JavaScript).

Running #744 (json) on RO 6.20, I see the problem described by Dave.
NetSurf's config file contains enable_javascript:1 but, when loaded,
NetSurf Choices... > Content shows 'Disable JavaScript' ticked, and
http://javatester.org/javascript.html reports that 'JavaScript IS NOT
WORKING in your web browser'. After unticking 'Disable JavaScript', the
'not working' warning at http://javatester.org/javascript.html has gone
so, presumably, JavaScript is then working - not that this is apparent,
on other websites.

Tony

Re: RISC OS Javascript support

In article <52ff29f39bdhwild@talktalk.net>,
David H Wild <dhwild@talktalk.net> wrote:
> I have come across three oddities in connection with JavaScript.

> (i) If you look at Flickr Having JS off brings a message about JS being off
> but gives the picture. With JS on there is no message, but the picture
> doesn't appear although the little strip of pictures is there.

> (ii) In Yahoo groups having JS on means that the navigation buttons don't
> appear.

> (iii) On today's Guardian website has, with JS off, a grid of squares
> saying "Link to slideshow 1". clicking on this produces the picture that
> should have been there.. With JS on the grid of links doesn't appear and
> there is a blank space on the page.

> This is with 740 on a rPC.

Similar effect with Streetmap.co.uk

This will probably be because only some JS is working as of yet - enough
that the site recognises JS to be present, but not enough to do the job
required.

I'm sure it will all get sorted in time, until then we must be patient -
and thankful that it is happening at all. Adding JavaScript must be a
herculean task!

Thanks to all the team.

--
Richard Torrens.
http://www.Torrens.org.uk for genealogy, natural history, wild food, walks, cats
and more!

Re: RISC OS Javascript support

On Mon, Dec 17, 2012 at 08:20:23AM +0000, Tim Hill wrote:
> In article <4d072bff52.iyojohn@rickman.argonet.co.uk>, John Rickman
> Iyonix <rickman@argonet.co.uk> wrote:
> > Vincent Sanders wrote
>
> > > ok last try for now, ci #744 is built with spidermonkey 1.7.0 maybe
> > > it works maybe it doesn't.
>
> [Snip]
>
> Iyonix RISC OS 5.19 & #744
>
> My results are similar to Vincent's.
>
>
> This works:
> <script type="text/javascript">
> document.write("Hello World . . .") ;
> document.write("<span><i>"+Date()+"<\/i><\/span>") ;
> </script>
>
> This doesn't:
> ..
> <head>
> ..
> <script type="text/javascript">
> function displayDate()
> {
> document.getElementById("demo").innerHTML=Date();
> }
> </script>
> </head><body>
> ..
> <span id="demo">Click button to test Javascript.</span>
> <button type="button" onclick="displayDate()">Display Date</button>
> ..
>
> (these are included on this page on this machine here: http://42.tjrh.eu/)
>
> To have anything working is BRILLIANT! Well done. A christmas present to
> us all. :-)
>

just fyi events set in the *javascript* will work i.e. if you set an
id on the button and did document.getElementById("buttonid").onclick

However innerHTML and outerHTML are not implemented and nor is dynamic
layout so changing teh DOM post page load is currently not
shown. There are examples of working tests in the source [1] and
specifically event-onclick.html would be relevant here.

[1] http://git.netsurf-browser.org/netsurf.git/tree/test/js


--
Regards Vincent
http://www.kyllikki.org/

Re: RISC OS Javascript support

In message <20121216210011.GN15360@kyllikki.org>
Vincent Sanders <vince@netsurf-browser.org> wrote:

> ok last try for now, ci #744 is built with spidermonkey 1.7.0 maybe it
> works maybe it doesn't.

> Please also remember to use the json tagged downloads if you want to
> try with javascript as the jsoff ones do not even have teh interpreter
> linked.

Recently, somewhere in the CI#5xx builds it became possible to use
HSBC Internet banking with NetSurf. The site warns about javascript
being off but nontheless it goes to a non-javascript area and is
entirely useable.

With javascript versions of the browser, with javascript turned on,
the warnings are no longer present but some links don't work,
specifically those which attempt to follow "javascript:void(0);:<my
account details>". Sorry I can't be more specific and many thanks for
this leap forward.



--

Brian Jordan
Virtual RPC-AdjustSA on Windows 7
RISC OS 6.20

Re: RISC OS Javascript support

In article <4d072bff52.iyojohn@rickman.argonet.co.uk>, John Rickman
Iyonix <rickman@argonet.co.uk> wrote:
> Vincent Sanders wrote

> > ok last try for now, ci #744 is built with spidermonkey 1.7.0 maybe
> > it works maybe it doesn't.

[Snip]

Iyonix RISC OS 5.19 & #744

My results are similar to Vincent's.


This works:
<script type="text/javascript">
document.write("Hello World . . .") ;
document.write("<span><i>"+Date()+"<\/i><\/span>") ;
</script>

This doesn't:
..
<head>
..
<script type="text/javascript">
function displayDate()
{
document.getElementById("demo").innerHTML=Date();
}
</script>
</head><body>
..
<span id="demo">Click button to test Javascript.</span>
<button type="button" onclick="displayDate()">Display Date</button>
..

(these are included on this page on this machine here: http://42.tjrh.eu/)

To have anything working is BRILLIANT! Well done. A christmas present to
us all. :-)

T

--
Tim Hill
..............................................................
www.timil.com

Re: RISC OS Javascript support

This is all *far* beyond my technical understanding and abilities, but
let me say I am *very* grateful for all this work which makes RISC OS
so much more useful.

Merry Christmas!

Michael Bell


--

Re: RISC OS Javascript support

In message <OUT-50CE32DF.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>
"Chris Young" <chris.young@unsatisfactorysoftware.co.uk> wrote:

>On Sun, 16 Dec 2012 20:36:36 GMT, Dave Higton wrote:
>
>> Is there any simple bit of HTML+JS that we can use to verify that JS
>> is working to /any/ extent?
>
>Try this: http://javatester.org/javascript.html
>
>It will clearly say whether JavaScript is enabled, and if it is
>working you'll see the user agent string underneath (NetSurf/3.0 etc)
>
>Chris

Thanks for that link, on my Raspberry Pi I get your web browser supports
JavaScript 2.2
>


--
Kev Wells http://riscos.kevsoft.co.uk/
http://kevsoft.co.uk/ http://kevsoft.co.uk/AleQuest/
ICQ 238580561
O it's " Thin red line of 'eroes, " when the drums begin to roll.

Cross-Compiler Build Instructions

I've just recreated my cross-compilation setup for NetSurf (currently on
Ubuntu 10.04, although that's likely to be changing soon), and have been
reading the BUILDING-ROcross documentation supplied in the Docs folder of
the source. I'd like to update that, having had a read of the more generic
build method given in

http://wiki.netsurf-browser.org/Documentation/GettingCoding

but am a little concerned that I've missed the point of one of the steps.
The Wiki page advises setting up the $PREFIX as follows

export PREFIX=${HOME}/netsurf/workspace/inst

Is there any specific reason for doing it this way in a cross-compilation
environment, which I've missed? Given that I then had to manually install
the libraries from workspace/inst into the GCCSDK structure, could that be
replaced by

export PREFIX=$GCCSDK_INSTALL_ENV

or would doing so break some other aspect of the new build structure that
expects the files to also be in workspace/inst?

--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 20 April 2013
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/

Re: Unicode on local pages

On 16 Dec 2012 John Rickman Iyonix <rickman@argonet.co.uk> wrote:

> Brian Howlett wrote

>> On 16 Dec, Gavin Wraith wrote:

>>> With NetSurf #739. If I browse
>>> http://www.perseus.tufts.edu/hopper/text?doc=Perseus%3Atext%3A1999.01.
>>> 0173%3Atext%3DSym. it displays OK. If I save or do a full save of the
>>> page, and then browse the resulting local page the Greek text displays
>>> as garbage. Why is there a difference?

>> All I get from that page after the header is "We're sorry, but we were
>> unable to find a document matching your query."
>> Iyonix, RISC OS 5.18 and NS #743.

> Brian - the link is split over two lines in the Messenger mail editor.
> I copied it out to StrongED and clicked on it as one line ok.

Only if you include the full stop at the end of that URL. I originally
got the "We're sorry..." message, as I assumed that a URL didn't
usually have a full stop at the end of it!

With best wishes,

Peter.

--
Peter Young (zfc Ta) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Greek Text

At last I have got a decent display of Greek text in NetSurf,
I did it by TTF2Fing the DejaVuSans/ttf font that I found in
!Boot.Resources.!UnixFont.truetype.ttf-dejavu on my Iyonix
and putting it in !Boot.Resources.!Fonts. To get a decent display
on the Raspberry Pi I had also to remove from !Fonts the fonts
Cabin, Exo, Fanwood, FanwoodText, Roboto and RobotoCond.
I know that Exo has a slightly broken Greek font and it may be that
the others are OK, but for the moment I shall take a rest from
testing.

It would be nice to have a tool to split up big unicode fonts into
smaller fonts, so that a mistake in one glyph or glyph-encoding
does not mean having to jettison all the rest. I must confess that I
find the whole font business very Heath-Robinson. No doubt there are
good historical reasons for that.

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

Re: Unicode on local pages

Brian Howlett wrote

> On 16 Dec, Gavin Wraith wrote:

>> With NetSurf #739. If I browse
>> http://www.perseus.tufts.edu/hopper/text?doc=Perseus%3Atext%3A1999.01.
>> 0173%3Atext%3DSym. it displays OK. If I save or do a full save of the
>> page, and then browse the resulting local page the Greek text displays
>> as garbage. Why is there a difference?

> All I get from that page after the header is "We're sorry, but we were
> unable to find a document matching your query."
> Iyonix, RISC OS 5.18 and NS #743.

Brian - the link is split over two lines in the Messenger mail editor.
I copied it out to StrongED and clicked on it as one line ok.



--
John Rickman- http://mug.riscos.org/

Re: RISC OS Javascript support

Vincent Sanders wrote

> ok last try for now, ci #744 is built with spidermonkey 1.7.0 maybe it
> works maybe it doesn't.

> Please also remember to use the json tagged downloads if you want to
> try with javascript as the jsoff ones do not even have teh interpreter
> linked.

I confirm that
#744 works on Iyonix 5.18,
#744 works on Raspberry Pi 5.19.

The JavaScript Tester http://javatester.org/javascript.html shows:-

"JavaScript   IS WORKING   in your web browser"  
" Your web browser supports JavaScript version 2.2 "


Using my own test script which tests a minimal set of output methods
http://rickman.orpheusweb.co.uk/temp/test4.html

window.confirm, window.alert, window.prompt and document.write work
after a fashion.

window.open appears not to work.

Great Job!! thanks.

--
John Rickman - http://mug.riscos.org/

Re: RISC OS Javascript support

On 16 Dec, Dave Higton wrote in message
<f77c24ff52.DaveMeUK@my.inbox.com>:

> In message <20121216154023.GL15360@kyllikki.org>
> Vincent Sanders <vince@netsurf-browser.org> wrote:
>
> > OK, the CI system just built #740 with a spidermonkey 1.8.5 library with
> > the JIT disabled as suggested by Chris Gransden. Can this be tried by
> > someone with access to RISC OS? and please be aware this may well behave
> > very badly indeed.
> >
> > If this fails I have now successfully built 1.7.0 for RISC OS (though
> > not run tested) so the possibility of using an older known working
> > version exists.
> >
> > Please remember to enable javascript via the nice shiny new
> > configuration interface Steve Fryatt has provided.
>
> The configuration interface in my 740 is different from the shiny new one
> in Steve's picture.

It will do: that wasn't my picture. Chris G did the version in the picture,
but then never submitted his changes to the source. I did my version
separately, but didn't commit it until after the screenshot was posted
(because I was still wrestling with Git). The sense of our switches is
different, too, as I went for the "disable" logic of the rest of the
"Content Blocking" box but Chris went for "enable".

> It does have a "Disable Javascript" item - but the effect doesn't appear
> to be stored; the item always comes up as disabled when NS starts.

Are you using a build which contains JS? It works fine in a "json" build,
but in a "jsoff" version it gets saved (look in the Choices) file, then lost
on loading. However, I suspect that it's getting loaded and then overwritten
to false by the dummy js_initialise() in javascript/none.c (which presumably
isn't an issue in a build that actually contains JavaScript).

You can see what choices are getting loaded underneath the RISC OS GUI by
browsing to about:config and looking at the settings. As an aside, string
display on that screen probably wants to entity-ise any <'s and >'s (and
possibly other stuff too): it doesn't handle "<Choices$Write>.WWW..." in the
RISC OS settings very cleverly at the moment!

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

RISC OS Javascript support

I have come across three oddities in connection with JavaScript.

(i) If you look at Flickr Having JS off brings a message about JS being off
but gives the picture. With JS on there is no message, but the picture
doesn't appear although the little strip of pictures is there.

(ii) In Yahoo groups having JS on means that the navigation buttons don't
appear.

(iii) On today's Guardian website has, with JS off, a grid of squares
saying "Link to slideshow 1". clicking on this produces the picture that
should have been there.. With JS on the grid of links doesn't appear and
there is a blank space on the page.

This is with 740 on a rPC.

--
David Wild using RISC OS on broadband
www.davidhwild.me.uk

Re: RISC OS Javascript support

ok last try for now, ci #744 is built with spidermonkey 1.7.0 maybe it
works maybe it doesn't.

Please also remember to use the json tagged downloads if you want to
try with javascript as the jsoff ones do not even have teh interpreter
linked.

--
Regards Vincent
http://www.kyllikki.org/

Re: Unicode on local pages

On 16 Dec, Gavin Wraith wrote:

> With NetSurf #739. If I browse
> http://www.perseus.tufts.edu/hopper/text?doc=Perseus%3Atext%3A1999.01.
> 0173%3Atext%3DSym. it displays OK. If I save or do a full save of the
> page, and then browse the resulting local page the Greek text displays
> as garbage. Why is there a difference?

All I get from that page after the header is "We're sorry, but we were
unable to find a document matching your query."

Iyonix, RISC OS 5.18 and NS #743.
--
Brian Howlett
----------------------------------------------------------------------
"Are you the Prime Minister?" "No, but I've often been mistaken."
"What, for the Prime Minister?" "No. I've just often been mistaken..."

Invoices in eBay

And another little bit of functionality ebbs from eBay....

The 'send invoice to buyer' page has stopped working, presumably due to
JavaScript issues, although the actual form appears exactly as it did
before and the links (Send invoice/Preview invoice) still work; the
difference is that attempting to click on either from Netsurf now
invariably results in a 'Page not responding' error :-(

So far as I can see all that the actual JavaScript here is doing is
stuff like checking the number of remaining characters (the function
that tends to make typing anything into Firefox forms like swimming
through treacle...) or adding an optional extra row to the table, but
evidently I'm missing something.

It's very annoying when people break things that were working quite
happily before. :-( (Especially as doing it via Firefox is
*painful*.)

--
Harriet Bazley == Loyaulte me lie ==

A chicken is an egg's way of producing more eggs.

Re: RISC OS Javascript support

On Sun, 16 Dec 2012 20:36:36 GMT, Dave Higton wrote:

> Is there any simple bit of HTML+JS that we can use to verify that JS
> is working to /any/ extent?

Try this: http://javatester.org/javascript.html

It will clearly say whether JavaScript is enabled, and if it is
working you'll see the user agent string underneath (NetSurf/3.0 etc)

Chris

Re: RISC OS Javascript support

In message <20121216154023.GL15360@kyllikki.org>
Vincent Sanders <vince@netsurf-browser.org> wrote:

> OK, the CI system just built #740 with a spidermonkey 1.8.5 library with
> the JIT disabled as suggested by Chris Gransden. Can this be tried by
> someone with access to RISC OS? and please be aware this may well behave
> very badly indeed.
>
> If this fails I have now successfully built 1.7.0 for RISC OS (though not
> run tested) so the possibility of using an older known working version
> exists.
>
> Please remember to enable javascript via the nice shiny new configuration
> interface Steve Fryatt has provided.

The configuration interface in my 740 is different from the shiny new
one in Steve's picture. It does have a "Disable Javascript" item -
but the effect doesn't appear to be stored; the item always comes up
as disabled when NS starts.

Is there any simple bit of HTML+JS that we can use to verify that JS
is working to /any/ extent?

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

Re: RISC OS Javascript support

In message <52ff11edd1john@jaharrison.me.uk>
John Harrison <john@jaharrison.me.uk> wrote:

>
> > > OK, the CI system just built #740
>
> > Bad news - loops on Iyonix, needs alt-break to stop.
>
> That's odd. 740 has been happily running here in Iyonix (5.18) since I
> downloaded it earlier.

Yes, for me too.

Dave

____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!

Re: [gccsdk] GCC Cross Compiler build failing at asasm

On 15 Dec, John Tytgat wrote in message
<d63976fe52.Jo@hobbes.bass-software.com>:

> Was this all built from a fresh checkout ? Or an older checkout which you
> updated with 'svn update' ? If the latter, did you do a 'make clean'
> before building ? I'm just trying to get a better context on this problem.

It was an update of an existing setup, which I'd tried to build, then made
clean and tried again.

[snip]

> The directory structure of asasm sources has changed some time ago and my
> guess is that you've still old autotool related files there which are
> outdated (i.e. not suited for the current directory structure) and not
> re-generated. Instead of advocating a good 'make clean' + ./build-world
> again, you might get away with:
>
> $ cd riscos/asasm
> $ svn status --no-ignore | grep ^I | cut -b 9- | xargs rm -rf
>
> And redo the ./build-world

That didn't seem to work as intended: the errors went, but the build then
completed with "nothing to do" (and no asasm or anything later).

Anyway, I've just checked out a clean copy of 4.1.2 and that seems to have
built correctly. I'll need to transfer all of my non-standard libraries
across before testing it on some code, though.

Thanks for the help in the right direction.

--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 20 April 2013
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/

_______________________________________________
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: RISC OS Javascript support

In article <20121216161324.GM15360@kyllikki.org>,
Vincent Sanders <vince@netsurf-browser.org> wrote:
> On Sun, Dec 16, 2012 at 04:07:25PM +0000, Chris Gransden wrote:
> > In article <20121216154023.GL15360@kyllikki.org>,
> > Vincent Sanders <vince@netsurf-browser.org> wrote:
> > > OK, the CI system just built #740 with a spidermonkey 1.8.5 library
> > > with the JIT disabled as suggested by Chris Gransden. Can this be
> > > tried by someone with access to RISC OS? and please be aware this may
> > > well behave very badly indeed.
> >
> > It get stuck in a infinite loop as soon as a web page is opened. Alt-break
> > is the only way to quit.
> >

> bother, oh well. any posibility of a log to maybe debug it? anyway I
> will sort out switching to the 1.7.0 build for now.

I've been doing all my testing on a pandaboard which it locks up with. I
tried it on a Raspberry Pi and it seems to be running stable so far. The
NetSurf JavaScript tests all seem to be working as before.

I ran the jsapi-tests program on the Raspberry Pi. Here's the output in
case its useful. This locks up on the Pandaboard.
*jsapi-tests
selfTest_globalHasNoParent
TEST-PASS | selfTest_globalHasNoParent | ok
selfTest_NaNsAreSame
TEST-PASS | selfTest_NaNsAreSame | ok
testBug604087
TEST-PASS | testBug604087 | ok
testClassGetter_isCalled
TEST-PASS | testClassGetter_isCalled | ok
test_cloneScript
TEST-PASS | test_cloneScript | ok
testDerivedValues
testConservativeGC.cpp:77:CHECK failed: !memcmp(ch, expected,
sizeof(expected))
TEST-UNEXPECTED-FAIL | testDerivedValues | CHECK failed: !memcmp(ch,
expected, sizeof(expected))
testConservativeGC

Chris.

Re: Unicode on local pages

NetSurf 3 #739

Altering fonts using the Fonts dialog in Choices.. from the iconbar
seems to have no effect on unicode text.

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

Unicode on local pages

With NetSurf #739. If I browse
http://www.perseus.tufts.edu/hopper/text?doc=Perseus%3Atext%3A1999.01.0173%3Atext%3DSym.
it displays OK. If I save or do a full save of the page, and then browse
the resulting local page the Greek text displays as garbage. Why is there
a difference?

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

Re: RISC OS Javascript support

On 16 Dec 2012 John Harrison <john@jaharrison.me.uk> wrote:


>>> OK, the CI system just built #740

>> Bad news - loops on Iyonix, needs alt-break to stop.

> That's odd. 740 has been happily running here in Iyonix (5.18) since I
> downloaded it earlier.

Presumably it matters which home page one is using. I use
http:/m.bbc.co.uk/home/desktop as suggested elsethread. I've certainly
seen the failure to load that people report on google groups, but that
doesn't lock the machine. ARMini, RISC OS 5.19

With best wishes,

Peter.

--
Peter Young (zfc Ta) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Re: Javascript and Fonts

In article <9c2713ff52.wra1th@wra1th.plus.com>,
Gavin Wraith <gavin@wra1th.plus.com> wrote:
> bold /mu problem. Can I take it that this has to be a fault with the
> fonts Corpus, Homerton and Trinity in Resources:$.Fonts somewhere? I must
> say, I did not know that these had been extended to unicode. Pity about
> the wrong style /mu if this is in the official Rpi distro.
>

You can change the defauilt font faces in the NetSurf configuration. Then
you can try different fonts easily.

Chris.

Re: Javascript and Fonts

In message <44d50eff52.wra1th@wra1th.plus.com> you wrote:

> In message <550806ff52.pnyoung@pnyoung.ormail.co.uk> you wrote:
>
> > > What font are you using?
>
> Experimentation has indicated that it is the Exo font on the Rpi
> which is causing overheavy /Delta and /pi glyphs. My only
> problem now is getting rid of the overheavy /mu. Apart from that
> Greek text is rendered quite elegantly, diacritics and all, but
> finding which fonts are responsible will need further work.
> I am getting the same display on Rpi and Iyonix, which have different
> fonts installed, so I can probably rule out the fonts that do not
> appear on both.

I have now removed _all_ the fonts from
SDFS::RISCOSpi.$.!Boot.Resources.!Fonts
apart from System, but the page
http://www.perseus.tufts.edu/hopper/text?doc=Perseus%3Atext%3A1999.01.0173%3Atext%3DSym.
is still rendered OK by NetSurf with all the Greek text fine apart for the
bold /mu problem. Can I take it that this has to be a fault with the
fonts Corpus, Homerton and Trinity in Resources:$.Fonts somewhere? I must
say, I did not know that these had been extended to unicode. Pity about
the wrong style /mu if this is in the official Rpi distro.

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

Re: RISC OS Javascript support

> > OK, the CI system just built #740

> Bad news - loops on Iyonix, needs alt-break to stop.

That's odd. 740 has been happily running here in Iyonix (5.18) since I
downloaded it earlier.

--
John Harrison
Website http://jaharrison.me.uk

Re: RISC OS Javascript support

John Rickman Iyonix wrote

> Vincent Sanders wrote

>> OK, the CI system just built #740 with a spidermonkey 1.8.5 library
>> with the JIT disabled as suggested by Chris Gransden. Can this be
>> tried by someone with access to RISC OS? and please be aware this may
>> well behave very badly indeed.

> Bad news - loops on Iyonix, needs alt-break to stop.
> Good news - runs on Raspberry Pi with mixed results:

> document.write - yes
> window.confirm - yes

> window.prompt - no
> window.alert - no
> window.open - no

> <script type="text/javascript">
> document.write("hello world");
> x = window.prompt( "prompt for a number", "" );
> window.alert( "This is an alert message to the user" );
> window.confirm( "This is a confirm message to the user" );
> window.open("")
> </script>


window.prompt and window.alert do appear towork but their message
windows are being automatically dismissed by subsequent commands. So
only the window.confirm popup remains.

window.open does not seem to do anything.


--
John - http://mug.riscos.org/

Re: RISC OS Javascript support

Vincent Sanders wrote

> OK, the CI system just built #740 with a spidermonkey 1.8.5 library
> with the JIT disabled as suggested by Chris Gransden. Can this be
> tried by someone with access to RISC OS? and please be aware this may
> well behave very badly indeed.

Bad news - loops on Iyonix, needs alt-break to stop.

Good news - runs on Raspberry Pi with mixed results:

document.write - yes
window.confirm - yes

window.prompt - no
window.alert - no
window.open - no


<script type="text/javascript">
document.write("hello world");
x = window.prompt( "prompt for a number", "" );
window.alert( "This is an alert message to the user" );
window.confirm( "This is a confirm message to the user" );
window.open("")
</script>


above code copied from
http://rickman.orpheusweb.co.uk/temp/test4.html

JR

--
John - http://mug.riscos.org/

Re: Javascript and Fonts

In message <550806ff52.pnyoung@pnyoung.ormail.co.uk> you wrote:

> > What font are you using?

Experimentation has indicated that it is the Exo font on the Rpi
which is causing overheavy /Delta and /pi glyphs. My only
problem now is getting rid of the overheavy /mu. Apart from that
Greek text is rendered quite elegantly, diacritics and all, but
finding which fonts are responsible will need further work.
I am getting the same display on Rpi and Iyonix, which have different
fonts installed, so I can probably rule out the fonts that do not
appear on both.

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

Re: RISC OS Javascript support

Chris Gransden wrote

> In article <20121216154023.GL15360@kyllikki.org>,
> Vincent Sanders <vince@netsurf-browser.org> wrote:
>> OK, the CI system just built #740 with a spidermonkey 1.8.5 library
>> with the JIT disabled as suggested by Chris Gransden. Can this be
>> tried by someone with access to RISC OS? and please be aware this may
>> well behave very badly indeed.

> It get stuck in a infinite loop as soon as a web page is opened. Alt-break
> is the only way to quit.

Similar results on Iyonix 5.19. Does get as far as putting icon on
icon bar.


--
John - http://mug.riscos.org/

Re: RISC OS Javascript support

On 16 Dec 2012 Vincent Sanders <vince@netsurf-browser.org> wrote:

> OK, the CI system just built #740 with a spidermonkey 1.8.5 library
> with the JIT disabled as suggested by Chris Gransden. Can this be
> tried by someone with access to RISC OS? and please be aware this may
> well behave very badly indeed.

> If this fails I have now successfully built 1.7.0 for RISC OS (though
> not run tested) so the possibility of using an older known working
> version exists.

> Please remember to enable javascript via the nice shiny new
> configuration interface Steve Fryatt has provided.

Just downloaded this build; ARMini, RISC OS 5.19, (16 May 2012).

Mixed results, but not helped much because I don't really know what
I'm looking for!. All my usual pages seem to work OK:

www.groups.google.com/ looks as if it's repeatedly trying to load and failing; this worked with previous builds.

http://www.mssociety.org.uk/near-me/branches/cheltenham-and-north-cotswold-branch
(sorry, should be all one line) still doesn't format as it does in
Windows Firefox; the "About us" and "Contact" should be two separate
tabs; no idea if this is a JavaScript thing.

http://www.metcheck.com/UK/today.asp?zipcode=GL52%203DS

is still missing a lot of detail compared with Firefox, and the "Conf"
icons down the right hand side deliver only a part of their content.

Like many others I'm very grateful that JavaScript is being worked on,
but I think there's still a way to go. If testing by an ignoramus is
worth it, please suggest to me some other sites to try.

With best wishes,

Peter.

--
Peter Young (zfc Ta) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk