In article <mpro.n3koc90bs5f2o01q0.lists@stevefryatt.org.uk>,
Steve Fryatt <lists@stevefryatt.org.uk> wrote:
> > On 7 Feb, Brian Jordan wrote in message
> > <53d648f824brian.jordan9@btinternet.com>:
> >
> > > In article <53d64596f0Lists@Torrens.org.uk>, Richard Torrens
> > > (lists) <Lists@Torrens.org.uk> wrote:
> > >
> > > > It's definitely MoussAxess related. I now do RMKill Moussaxess
> > > > before surfing - if I remember!
> > >
> > > I reported this at 13:59. I received a confirmatory email at 14:16
> > > saying the issue has been referred to Steve Fryatt. Apparently the
> > > problem is:
> > >
> > > "Caused by failed assertion in RISC OS mouse handling:
> I've put an attempt at a fix into CI#1781.
> I don't /think/ there will be any unintended consequences, but it would
> be good if people could try and break it nonetheless. That's not just
> MouseAxess users -- the affected code is called whenever the mouse
> passes over a NetSurf window on RISC OS.
Steve
This seems a good news, good news story. First, I have spent some time
trying to crash the latest Netsurf with the MousAxess menu scrolling
method and failed. Second, nothing else appears to been affected by the
fix.
Many thanks
--
_____________________________________________________________________
Brian Jordan
Virtual RPC-AdjustSA on Windows 8.1 Pro
RISC OS 6.20
_____________________________________________________________________
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Sunday, 6 April 2014
follow links from keyboard?
Is there a way to follow hyperlinks from the keyboard (without clicking
with mouse), or is it a planned feature?
Like "follow hints" in vimperator, dwb, midori xxxterm/xomberro etc.
Hope this is OK to ask here....I can't find the answer in the netsurf
documentation or website.
Thanks! --Fritz
with mouse), or is it a planned feature?
Like "follow hints" in vimperator, dwb, midori xxxterm/xomberro etc.
Hope this is OK to ask here....I can't find the answer in the netsurf
documentation or website.
Thanks! --Fritz
Re: MousAxess
In message <mpro.n3koc90bs5f2o01q0.lists@stevefryatt.org.uk>
Steve Fryatt <lists@stevefryatt.org.uk> wrote:
>> On 7 Feb, Brian Jordan wrote in message
>> <53d648f824brian.jordan9@btinternet.com>:
>>
>> > In article <53d64596f0Lists@Torrens.org.uk>,
>> > Richard Torrens (lists) <Lists@Torrens.org.uk> wrote:
>> >
>> > > It's definitely MoussAxess related. I now do RMKill Moussaxess before
>> > > surfing - if I remember!
>> >
>> > I reported this at 13:59. I received a confirmatory email at 14:16
>> > saying the issue has been referred to Steve Fryatt. Apparently the
>> > problem is:
>> >
>> > "Caused by failed assertion in RISC OS mouse handling:
>
>I've put an attempt at a fix into CI#1781.
>
>I don't /think/ there will be any unintended consequences, but it would be
>good if people could try and break it nonetheless. That's not just
>MouseAxess users -- the affected code is called whenever the mouse passes
>over a NetSurf window on RISC OS.
I missed 1781, but I don't notice anything untoward - in fact no
difference - in 1782 from previous. I don't use MouseAxess.
Iyonix, RO 5.20.
Dave
____________________________________________________________
Publish your photos in seconds for FREE
TRY IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if4
Steve Fryatt <lists@stevefryatt.org.uk> wrote:
>> On 7 Feb, Brian Jordan wrote in message
>> <53d648f824brian.jordan9@btinternet.com>:
>>
>> > In article <53d64596f0Lists@Torrens.org.uk>,
>> > Richard Torrens (lists) <Lists@Torrens.org.uk> wrote:
>> >
>> > > It's definitely MoussAxess related. I now do RMKill Moussaxess before
>> > > surfing - if I remember!
>> >
>> > I reported this at 13:59. I received a confirmatory email at 14:16
>> > saying the issue has been referred to Steve Fryatt. Apparently the
>> > problem is:
>> >
>> > "Caused by failed assertion in RISC OS mouse handling:
>
>I've put an attempt at a fix into CI#1781.
>
>I don't /think/ there will be any unintended consequences, but it would be
>good if people could try and break it nonetheless. That's not just
>MouseAxess users -- the affected code is called whenever the mouse passes
>over a NetSurf window on RISC OS.
I missed 1781, but I don't notice anything untoward - in fact no
difference - in 1782 from previous. I don't use MouseAxess.
Iyonix, RO 5.20.
Dave
____________________________________________________________
Publish your photos in seconds for FREE
TRY IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if4
Saturday, 5 April 2014
Re: [gccsdk] Diffutils no longer compiles
In message <DUB120-DS147F359571A432C002CD1DF06C0@phx.gbl>
"Alan Buckley" <alan_baa@hotmail.com> wrote:
> I’ve just tried compiling the latest diffutils with the GCCSDK
> version 4.1.2 and 4.7 are both the same and it comes up with
> the error:
>
> CC gettime.o
> In file included from ./sys/time.h:30,
> from gettime.c:24:
> /home/riscos/cross/lib/gcc/arm-unknown-riscos/4.1.2/../../../../arm-unknown-riscos/include/sys/time.h:75: error: conflicting types for 'rpl_gettimeofday'
> ./sys/time.h:401: error: previous declaration of 'rpl_gettimeofday' was here
> make[2]: *** [gettime.o] Error 1
> make[2]: Leaving directory `/home/alanb/build/diffutils/diffutils-3.3/lib'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/alanb/build/diffutils/diffutils-3.3/lib'
> make: *** [all-recursive] Error 1
>
> I’ve tried to untangle what’s going on and it seems like <sys/time.h> is
> including the local sys/time.h rather than the system one. But I may
> be wrong?
>
> Can someone have a look at it and see how to fix it please?
It's a bit nasty. Basically there are a lot of configure tests being
done in order to figure out if the used runtime routines adhere to the
standard(s). A couple of those tests concern gettimeofday(). The last
one wants to check if gettimeofday() and localtime() share a static
buffer (apparently a MacOS X issue). This test can only be done by
running a small test program but as we're cross-compiling the result is
'guessing yes' instead. Which means that a replacement 'rpl_gettimeofday'
code piece is being used instead of the system gettimeofday() routine.
And that code gets compiled with an error on systems where the second
parameter type is non-void.
All very messy. I've worked around by basically enforcing the last
test to 'no' (UnixLib's gettimeofday() and localtime() do not share
a static buffer) with r6638 so diffutils can now be built.
Will you upload a new diffutils port ?
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
"Alan Buckley" <alan_baa@hotmail.com> wrote:
> I’ve just tried compiling the latest diffutils with the GCCSDK
> version 4.1.2 and 4.7 are both the same and it comes up with
> the error:
>
> CC gettime.o
> In file included from ./sys/time.h:30,
> from gettime.c:24:
> /home/riscos/cross/lib/gcc/arm-unknown-riscos/4.1.2/../../../../arm-unknown-riscos/include/sys/time.h:75: error: conflicting types for 'rpl_gettimeofday'
> ./sys/time.h:401: error: previous declaration of 'rpl_gettimeofday' was here
> make[2]: *** [gettime.o] Error 1
> make[2]: Leaving directory `/home/alanb/build/diffutils/diffutils-3.3/lib'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/alanb/build/diffutils/diffutils-3.3/lib'
> make: *** [all-recursive] Error 1
>
> I’ve tried to untangle what’s going on and it seems like <sys/time.h> is
> including the local sys/time.h rather than the system one. But I may
> be wrong?
>
> Can someone have a look at it and see how to fix it please?
It's a bit nasty. Basically there are a lot of configure tests being
done in order to figure out if the used runtime routines adhere to the
standard(s). A couple of those tests concern gettimeofday(). The last
one wants to check if gettimeofday() and localtime() share a static
buffer (apparently a MacOS X issue). This test can only be done by
running a small test program but as we're cross-compiling the result is
'guessing yes' instead. Which means that a replacement 'rpl_gettimeofday'
code piece is being used instead of the system gettimeofday() routine.
And that code gets compiled with an error on systems where the second
parameter type is non-void.
All very messy. I've worked around by basically enforcing the last
test to 'no' (UnixLib's gettimeofday() and localtime() do not share
a static buffer) with r6638 so diffutils can now be built.
Will you upload a new diffutils port ?
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: MousAxess
> On 7 Feb, Brian Jordan wrote in message
> <53d648f824brian.jordan9@btinternet.com>:
>
> > In article <53d64596f0Lists@Torrens.org.uk>,
> > Richard Torrens (lists) <Lists@Torrens.org.uk> wrote:
> >
> > > It's definitely MoussAxess related. I now do RMKill Moussaxess before
> > > surfing - if I remember!
> >
> > I reported this at 13:59. I received a confirmatory email at 14:16
> > saying the issue has been referred to Steve Fryatt. Apparently the
> > problem is:
> >
> > "Caused by failed assertion in RISC OS mouse handling:
I've put an attempt at a fix into CI#1781.
I don't /think/ there will be any unintended consequences, but it would be
good if people could try and break it nonetheless. That's not just
MouseAxess users -- the affected code is called whenever the mouse passes
over a NetSurf window on RISC OS.
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 26 April 2014
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
> <53d648f824brian.jordan9@btinternet.com>:
>
> > In article <53d64596f0Lists@Torrens.org.uk>,
> > Richard Torrens (lists) <Lists@Torrens.org.uk> wrote:
> >
> > > It's definitely MoussAxess related. I now do RMKill Moussaxess before
> > > surfing - if I remember!
> >
> > I reported this at 13:59. I received a confirmatory email at 14:16
> > saying the issue has been referred to Steve Fryatt. Apparently the
> > problem is:
> >
> > "Caused by failed assertion in RISC OS mouse handling:
I've put an attempt at a fix into CI#1781.
I don't /think/ there will be any unintended consequences, but it would be
good if people could try and break it nonetheless. That's not just
MouseAxess users -- the affected code is called whenever the mouse passes
over a NetSurf window on RISC OS.
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 26 April 2014
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
Re: [gccsdk] GCC and GNUTLS - compiling problems
In message <36d6dcf253.Alex@bavariasound.chiemgau-net.de> you wrote:
> Hi all,
>
> I tried to include code from !LibGNUTLS using the commands
>
> gcc cert5.c -o cert5 -LLibGNUTLS: -lgnutls
>
> but it ends with
>
> LibGNUTLS:/libgnutls.a(gnutls_errors.o): In function `gnutls_perror':
> gnutls_errors.c:(.text+0xd8): undefined reference to `libintl_dgettext'
> gnutls_errors.c:(.text+0xf8): undefined reference to `libintl_dgettext'
>
> [a HUGE snip]
>
> LibGNUTLS:/libgnutls.a(sign.o): In function `_gnutls_x509_pkix_sign':
> sign.c:(.text+0x1a4): undefined reference to `asn1_copy_node'
> sign.c:(.text+0x294): undefined reference to `asn1_write_value'
> collect2: ld returned 1 exit status
> *
>
> At the moment I don't know what's going wrong. Any help is appreciated.
> Thanks.
The "LibGNUTLS:/libgnutls.a(..,)" tells you that the libgnutls.a library
is being used to find unresolved symbols. The second thing it tells
you that the object file between the round brackets (i.e. gnutls_errors.o
and sign.o in the quoted piece above) results in additional unresolved
symbols. You probably need to throw in more libraries on which libgnutls.a
is depending on. Didn't the LibGNUTLS package come with more than one
library ? If so, you might need to specify more -l options for each of
those. Library order is important, the search for unresolved symbols
happens according to the library order you're specifying.
I believe the libntl_dgettext unresolved symbol needs the gettext
(LibGetText-Dev) library but I don't know the other ones.
I see that Chris Gransden has packaged the libgnutls library so probably
he can help you further. Chris ?
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
> Hi all,
>
> I tried to include code from !LibGNUTLS using the commands
>
> gcc cert5.c -o cert5 -LLibGNUTLS: -lgnutls
>
> but it ends with
>
> LibGNUTLS:/libgnutls.a(gnutls_errors.o): In function `gnutls_perror':
> gnutls_errors.c:(.text+0xd8): undefined reference to `libintl_dgettext'
> gnutls_errors.c:(.text+0xf8): undefined reference to `libintl_dgettext'
>
> [a HUGE snip]
>
> LibGNUTLS:/libgnutls.a(sign.o): In function `_gnutls_x509_pkix_sign':
> sign.c:(.text+0x1a4): undefined reference to `asn1_copy_node'
> sign.c:(.text+0x294): undefined reference to `asn1_write_value'
> collect2: ld returned 1 exit status
> *
>
> At the moment I don't know what's going wrong. Any help is appreciated.
> Thanks.
The "LibGNUTLS:/libgnutls.a(..,)" tells you that the libgnutls.a library
is being used to find unresolved symbols. The second thing it tells
you that the object file between the round brackets (i.e. gnutls_errors.o
and sign.o in the quoted piece above) results in additional unresolved
symbols. You probably need to throw in more libraries on which libgnutls.a
is depending on. Didn't the LibGNUTLS package come with more than one
library ? If so, you might need to specify more -l options for each of
those. Library order is important, the search for unresolved symbols
happens according to the library order you're specifying.
I believe the libntl_dgettext unresolved symbol needs the gettext
(LibGetText-Dev) library but I don't know the other ones.
I see that Chris Gransden has packaged the libgnutls library so probably
he can help you further. Chris ?
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
NetSurf 3.1 last call
Last call for the 3.1 release. If you have any fixes or updates that
ought to go in this release now is the time.
I will be tagging the release and start generating release tarballs
for libraries and NetSurf during the weekend 12th and 13th April.
The CI system will be used to build release binaries which will be
tested during the following week.
If there are critical problems with the proposed release it will be
redone the next weekend (19th and 20th April).
The general release to public will be done on the 26th April.
--
Regards Vincent
http://www.kyllikki.org/
ought to go in this release now is the time.
I will be tagging the release and start generating release tarballs
for libraries and NetSurf during the weekend 12th and 13th April.
The CI system will be used to build release binaries which will be
tested during the following week.
If there are critical problems with the proposed release it will be
redone the next weekend (19th and 20th April).
The general release to public will be done on the 26th April.
--
Regards Vincent
http://www.kyllikki.org/
Subscribe to:
Posts (Atom)