On 07/31/2012 02:29 PM, John Tytgat wrote:
> In message <20120731002849.GL310@chiark.greenend.org.uk>
> Theo Markettos <theo@markettos.org.uk> wrote:
>
>>
>> What's odd is that config.guess's RISC OS rule hasn't changed since 2005
>> according to its upstream git[1], and our uname has always been like that
>> (created about 2004). Has it really been broken for that long? Am I being
>> stupid somehow?
>>
>> [1] http://git.savannah.gnu.org/gitweb/?p=config.git;a=tree
>
> Oh, I never realized we had an arm-unknown-riscos entry in config.guess.
> Something which Nick apparently did around the time he resigned from the
> GCCSDK project. Nice.
config.guess is only used sometimes, or uses the package's version,
which is why you didn't see it break much/at all. Every package
builds slightly differently.
> I guess 'uname -m' returning armv4l is actually right (can someone ack this
> on real Linux ARM setup ?), so any config.guess needs fixing (perhaps as
> part of ro-config ?). I believe this can be tricky as config.guess is
> not part of the package sources but gets created by the autotools (e.g.
> autoreconfig).
It made sense 10 years ago. Maybe now it should have a different
value. Certainly in some projects (especially those not using
autoconf), it needs to be something else.
>> 2. Any objections if I add HOSTCC=`which gcc` and HOSTCXX=`which g++` in
>> ro-path? (Or some nicer shell incantation) I don't know if this will break
>> other builds that know about cross compiling. The alternative is to make
>> them GCCSDK_HOSTCC etc. The motivation is to allow access to the host build
>> tools for things that need it. Because ro-path splats itself over the
>> system's path, there's no way to get at the host's tools. Hardcoded
>> /usr/bin/gcc can be used, but that's not so friendly to non-Linux systems.
>> Alternatively, perhaps ro-path could retain the system path in a variable.
>
> I like the GCCSDK_HOSTCC etc approach. Feel free to make that change.
> There are several autobuilder patches using /usr/bin/gcc and that can
> be fixed now :-)
I think that's ok, just make certain you really are picking up the host
compiler.
> AFAICS freadahead is a gnulib function and not implemented in glibc so
> if we really are going for a gzip version with freadahead usage, it might
> perhaps be better to port gnulib assuming that's reasonable work.
>
> If freadahead is part of the Debian patches, perhaps consider to undo
> those patches ?
>
> I rather let UnixLib be a collection of standard C runtime functions
> with additional glibc GNU extensions (for useful ones). gnulib
> functions are a step beyond that and that can remain a separate library.
>
> Also any freadahead implementation will make use of internal FILE data
> so that looks unavoidable...
Yes, the gnulib stuff often requires knowledge of Unixlib FILE internals
so can be a bit tricky to get right. Avoid if possible, but putting
in UL if you need to implement them is probably ok.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Tuesday, 31 July 2012
Re: [gccsdk] Porting scripts miscellanea
In message <20120731002849.GL310@chiark.greenend.org.uk>
Theo Markettos <theo@markettos.org.uk> wrote:
> As a result of this evening's hacking, a few questions have arisen...
>
> 1. config.guess is failing to detect the machine because our 'uname -m' is giving
> a hardcoded 'armv4l'. That is what Linux gives, but config.guess has this rule:
> arm:riscos:*:*|arm:RISCOS:*:*)
> echo arm-unknown-riscos
> exit ;;
>
> in other words, the machine type is plain 'arm', not 'arm' with a suffix.
> Linux's rule is more flexible:
> arm*:Linux:*:*)
>
> What's odd is that config.guess's RISC OS rule hasn't changed since 2005
> according to its upstream git[1], and our uname has always been like that
> (created about 2004). Has it really been broken for that long? Am I being
> stupid somehow?
>
> [1] http://git.savannah.gnu.org/gitweb/?p=config.git;a=tree
Oh, I never realized we had an arm-unknown-riscos entry in config.guess.
Something which Nick apparently did around the time he resigned from the
GCCSDK project. Nice.
Note that config.guess is actually only useful for determining the *build*
target name so in principle this entry is irrelevant unless you want to
configure and do the build on RISC OS itself. Proper cross-compiling
is done via passing --host=arm-unknown-riscos to configure.
However our porting tools are actually faking so many things that it,
intentionally, looks like we're doing a native RISC OS build with
autobuilder (but we aren't of course). Hence, all the hacks like having
a gcc softlink to arm-unknown-riscos-gcc etc.
I'm just wondering if it wouldn't be useful to disable most of the
porting-tools hacks on a per-autobuilder-project based basis for those
projects properly supporting cross-compiling...
Anyway, for this particular problem, it looks to me this is a very old
problem (first uname implementation in Feb 2005 already returned armv4l)
so I'm curious to know how did you come this across ?
I guess 'uname -m' returning armv4l is actually right (can someone ack this
on real Linux ARM setup ?), so any config.guess needs fixing (perhaps as
part of ro-config ?). I believe this can be tricky as config.guess is
not part of the package sources but gets created by the autotools (e.g.
autoreconfig).
> 2. Any objections if I add HOSTCC=`which gcc` and HOSTCXX=`which g++` in
> ro-path? (Or some nicer shell incantation) I don't know if this will break
> other builds that know about cross compiling. The alternative is to make
> them GCCSDK_HOSTCC etc. The motivation is to allow access to the host build
> tools for things that need it. Because ro-path splats itself over the
> system's path, there's no way to get at the host's tools. Hardcoded
> /usr/bin/gcc can be used, but that's not so friendly to non-Linux systems.
> Alternatively, perhaps ro-path could retain the system path in a variable.
I like the GCCSDK_HOSTCC etc approach. Feel free to make that change.
There are several autobuilder patches using /usr/bin/gcc and that can
be fixed now :-)
BTW, be convinced that the `which gcc` is always returning the host gcc
during building (i.e. is ro-path always called with a PATH *not* containing
GCCSDK_INSTALL_ENV directory ?). If not, perhaps a better approach is to
do `which gcc` in install-env and substitute a new GCCSDK_xxx variable
during porting tools installation (like GCCSDK_BIN and GCCSDK_BUILD are
substituted).
> 3. gzip now wants freadahead() and won't build without it:
You're sure ? gzip 1.2.4 doesn't mention freadahead. Or is this because
of the Debian patches ?
> /* Assuming the stream STREAM is open for reading:
> Return the number of bytes waiting in the input buffer of STREAM.
> This includes both the bytes that have been read from the underlying input
> source and the bytes that have been pushed back through 'ungetc'.
>
> If this number is 0 and the stream is not currently writing,
> fflush (STREAM) is known to be a no-op.
>
> STREAM must not be wide-character oriented. */
>
> extern size_t freadahead (FILE *stream) _GL_ATTRIBUTE_PURE;
>
> I don't think there's a way to read that information from RISC OS for an
> open file, but it looks like stream->i_cnt will do the trick, but I'm not
> supposed to go poking around in UnixLib's internals. Is it worth
> making a public API for this, and where would it go in the Unixlib
> source/headers? I could always lie, of course, but I suspect this is done
> for performance reasons.
AFAICS freadahead is a gnulib function and not implemented in glibc so
if we really are going for a gzip version with freadahead usage, it might
perhaps be better to port gnulib assuming that's reasonable work.
If freadahead is part of the Debian patches, perhaps consider to undo
those patches ?
I rather let UnixLib be a collection of standard C runtime functions
with additional glibc GNU extensions (for useful ones). gnulib
functions are a step beyond that and that can remain a separate library.
Also any freadahead implementation will make use of internal FILE data
so that looks unavoidable...
John.
--
John Tytgat, in his comfy chair at home BASS
John.Tytgat@aaug.net ARM powered, RISC OS driven
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Theo Markettos <theo@markettos.org.uk> wrote:
> As a result of this evening's hacking, a few questions have arisen...
>
> 1. config.guess is failing to detect the machine because our 'uname -m' is giving
> a hardcoded 'armv4l'. That is what Linux gives, but config.guess has this rule:
> arm:riscos:*:*|arm:RISCOS:*:*)
> echo arm-unknown-riscos
> exit ;;
>
> in other words, the machine type is plain 'arm', not 'arm' with a suffix.
> Linux's rule is more flexible:
> arm*:Linux:*:*)
>
> What's odd is that config.guess's RISC OS rule hasn't changed since 2005
> according to its upstream git[1], and our uname has always been like that
> (created about 2004). Has it really been broken for that long? Am I being
> stupid somehow?
>
> [1] http://git.savannah.gnu.org/gitweb/?p=config.git;a=tree
Oh, I never realized we had an arm-unknown-riscos entry in config.guess.
Something which Nick apparently did around the time he resigned from the
GCCSDK project. Nice.
Note that config.guess is actually only useful for determining the *build*
target name so in principle this entry is irrelevant unless you want to
configure and do the build on RISC OS itself. Proper cross-compiling
is done via passing --host=arm-unknown-riscos to configure.
However our porting tools are actually faking so many things that it,
intentionally, looks like we're doing a native RISC OS build with
autobuilder (but we aren't of course). Hence, all the hacks like having
a gcc softlink to arm-unknown-riscos-gcc etc.
I'm just wondering if it wouldn't be useful to disable most of the
porting-tools hacks on a per-autobuilder-project based basis for those
projects properly supporting cross-compiling...
Anyway, for this particular problem, it looks to me this is a very old
problem (first uname implementation in Feb 2005 already returned armv4l)
so I'm curious to know how did you come this across ?
I guess 'uname -m' returning armv4l is actually right (can someone ack this
on real Linux ARM setup ?), so any config.guess needs fixing (perhaps as
part of ro-config ?). I believe this can be tricky as config.guess is
not part of the package sources but gets created by the autotools (e.g.
autoreconfig).
> 2. Any objections if I add HOSTCC=`which gcc` and HOSTCXX=`which g++` in
> ro-path? (Or some nicer shell incantation) I don't know if this will break
> other builds that know about cross compiling. The alternative is to make
> them GCCSDK_HOSTCC etc. The motivation is to allow access to the host build
> tools for things that need it. Because ro-path splats itself over the
> system's path, there's no way to get at the host's tools. Hardcoded
> /usr/bin/gcc can be used, but that's not so friendly to non-Linux systems.
> Alternatively, perhaps ro-path could retain the system path in a variable.
I like the GCCSDK_HOSTCC etc approach. Feel free to make that change.
There are several autobuilder patches using /usr/bin/gcc and that can
be fixed now :-)
BTW, be convinced that the `which gcc` is always returning the host gcc
during building (i.e. is ro-path always called with a PATH *not* containing
GCCSDK_INSTALL_ENV directory ?). If not, perhaps a better approach is to
do `which gcc` in install-env and substitute a new GCCSDK_xxx variable
during porting tools installation (like GCCSDK_BIN and GCCSDK_BUILD are
substituted).
> 3. gzip now wants freadahead() and won't build without it:
You're sure ? gzip 1.2.4 doesn't mention freadahead. Or is this because
of the Debian patches ?
> /* Assuming the stream STREAM is open for reading:
> Return the number of bytes waiting in the input buffer of STREAM.
> This includes both the bytes that have been read from the underlying input
> source and the bytes that have been pushed back through 'ungetc'.
>
> If this number is 0 and the stream is not currently writing,
> fflush (STREAM) is known to be a no-op.
>
> STREAM must not be wide-character oriented. */
>
> extern size_t freadahead (FILE *stream) _GL_ATTRIBUTE_PURE;
>
> I don't think there's a way to read that information from RISC OS for an
> open file, but it looks like stream->i_cnt will do the trick, but I'm not
> supposed to go poking around in UnixLib's internals. Is it worth
> making a public API for this, and where would it go in the Unixlib
> source/headers? I could always lie, of course, but I suspect this is done
> for performance reasons.
AFAICS freadahead is a gnulib function and not implemented in glibc so
if we really are going for a gzip version with freadahead usage, it might
perhaps be better to port gnulib assuming that's reasonable work.
If freadahead is part of the Debian patches, perhaps consider to undo
those patches ?
I rather let UnixLib be a collection of standard C runtime functions
with additional glibc GNU extensions (for useful ones). gnulib
functions are a step beyond that and that can remain a separate library.
Also any freadahead implementation will make use of internal FILE data
so that looks unavoidable...
John.
--
John Tytgat, in his comfy chair at home BASS
John.Tytgat@aaug.net ARM powered, RISC OS driven
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Monday, 30 July 2012
[gccsdk] Porting scripts miscellanea
As a result of this evening's hacking, a few questions have arisen...
1. config.guess is failing to detect the machine because our 'uname -m' is giving
a hardcoded 'armv4l'. That is what Linux gives, but config.guess has this rule:
arm:riscos:*:*|arm:RISCOS:*:*)
echo arm-unknown-riscos
exit ;;
in other words, the machine type is plain 'arm', not 'arm' with a suffix.
Linux's rule is more flexible:
arm*:Linux:*:*)
What's odd is that config.guess's RISC OS rule hasn't changed since 2005
according to its upstream git[1], and our uname has always been like that
(created about 2004). Has it really been broken for that long? Am I being
stupid somehow?
[1] http://git.savannah.gnu.org/gitweb/?p=config.git;a=tree
2. Any objections if I add HOSTCC=`which gcc` and HOSTCXX=`which g++` in
ro-path? (Or some nicer shell incantation) I don't know if this will break
other builds that know about cross compiling. The alternative is to make
them GCCSDK_HOSTCC etc. The motivation is to allow access to the host build
tools for things that need it. Because ro-path splats itself over the
system's path, there's no way to get at the host's tools. Hardcoded
/usr/bin/gcc can be used, but that's not so friendly to non-Linux systems.
Alternatively, perhaps ro-path could retain the system path in a variable.
3. gzip now wants freadahead() and won't build without it:
/* Assuming the stream STREAM is open for reading:
Return the number of bytes waiting in the input buffer of STREAM.
This includes both the bytes that have been read from the underlying input
source and the bytes that have been pushed back through 'ungetc'.
If this number is 0 and the stream is not currently writing,
fflush (STREAM) is known to be a no-op.
STREAM must not be wide-character oriented. */
extern size_t freadahead (FILE *stream) _GL_ATTRIBUTE_PURE;
I don't think there's a way to read that information from RISC OS for an
open file, but it looks like stream->i_cnt will do the trick, but I'm not
supposed to go poking around in UnixLib's internals. Is it worth
making a public API for this, and where would it go in the Unixlib
source/headers? I could always lie, of course, but I suspect this is done
for performance reasons.
Thanks
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
1. config.guess is failing to detect the machine because our 'uname -m' is giving
a hardcoded 'armv4l'. That is what Linux gives, but config.guess has this rule:
arm:riscos:*:*|arm:RISCOS:*:*)
echo arm-unknown-riscos
exit ;;
in other words, the machine type is plain 'arm', not 'arm' with a suffix.
Linux's rule is more flexible:
arm*:Linux:*:*)
What's odd is that config.guess's RISC OS rule hasn't changed since 2005
according to its upstream git[1], and our uname has always been like that
(created about 2004). Has it really been broken for that long? Am I being
stupid somehow?
[1] http://git.savannah.gnu.org/gitweb/?p=config.git;a=tree
2. Any objections if I add HOSTCC=`which gcc` and HOSTCXX=`which g++` in
ro-path? (Or some nicer shell incantation) I don't know if this will break
other builds that know about cross compiling. The alternative is to make
them GCCSDK_HOSTCC etc. The motivation is to allow access to the host build
tools for things that need it. Because ro-path splats itself over the
system's path, there's no way to get at the host's tools. Hardcoded
/usr/bin/gcc can be used, but that's not so friendly to non-Linux systems.
Alternatively, perhaps ro-path could retain the system path in a variable.
3. gzip now wants freadahead() and won't build without it:
/* Assuming the stream STREAM is open for reading:
Return the number of bytes waiting in the input buffer of STREAM.
This includes both the bytes that have been read from the underlying input
source and the bytes that have been pushed back through 'ungetc'.
If this number is 0 and the stream is not currently writing,
fflush (STREAM) is known to be a no-op.
STREAM must not be wide-character oriented. */
extern size_t freadahead (FILE *stream) _GL_ATTRIBUTE_PURE;
I don't think there's a way to read that information from RISC OS for an
open file, but it looks like stream->i_cnt will do the trick, but I'm not
supposed to go poking around in UnixLib's internals. Is it worth
making a public API for this, and where would it go in the Unixlib
source/headers? I could always lie, of course, but I suspect this is done
for performance reasons.
Thanks
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Sunday, 29 July 2012
Re: libdom: branch master updated. af0e4892995a00aa35f7c288bfba45bdd507dc4c
On Sun, 29 Jul 2012 11:29:20 +0100, Daniel Silverstone wrote:
> Your maintaining of a chris/amiga-hubbub-lib-compat branch is driving a lot of
> us crazy. Firstly because you create a bunch of commit messages for "keeping
> up" with master and secondly because you managed to corrupt master with your
> "compat" change.
>
> I have resynchronised master of libdom with master of hubbub to un-do your change.
Sorry, that was accidental, for some reason when I changed the branch
it pushed to master even though I was working on my branch (I haven't
been on master at all - except to fix it after my retry to ensure it
wasn't me being on the wrong branch).
I think it might be related to the pushing changes you suggested
recently as I haven't changed anything else in Git's config and it was
working previously. I'm not sure what I need to type to undo that
though.
> Why are you maintaining some kind of 'compat' branch at this point? We've
> never made an ABI/API commitment and as such we're shouldn't be trying to
> maintain "compatibility" not least of which because there's no way for a modern
> libhubbub to know that you're not passing a script callback anyway so it'll
> jump off into oblivion given the opportunity.
>
> Unless you have a really *really* good reason for this, I ask that you stop
> maintaining these branches because they're clearly causing you confusion at
> times; and they're definitely causing us confusion/annoyance.
It's basically so I can run 2.9 and 3.0 with the same hubbub, I was
going to ditch it once 3.0 became stable enough to use. I'll fix 2.9
so it works with the new one, probably less hassle anyway.
I daren't delete my branch until I've reverted Git's config and tested
that my commits are going to the right place again.
Chris
> Your maintaining of a chris/amiga-hubbub-lib-compat branch is driving a lot of
> us crazy. Firstly because you create a bunch of commit messages for "keeping
> up" with master and secondly because you managed to corrupt master with your
> "compat" change.
>
> I have resynchronised master of libdom with master of hubbub to un-do your change.
Sorry, that was accidental, for some reason when I changed the branch
it pushed to master even though I was working on my branch (I haven't
been on master at all - except to fix it after my retry to ensure it
wasn't me being on the wrong branch).
I think it might be related to the pushing changes you suggested
recently as I haven't changed anything else in Git's config and it was
working previously. I'm not sure what I need to type to undo that
though.
> Why are you maintaining some kind of 'compat' branch at this point? We've
> never made an ABI/API commitment and as such we're shouldn't be trying to
> maintain "compatibility" not least of which because there's no way for a modern
> libhubbub to know that you're not passing a script callback anyway so it'll
> jump off into oblivion given the opportunity.
>
> Unless you have a really *really* good reason for this, I ask that you stop
> maintaining these branches because they're clearly causing you confusion at
> times; and they're definitely causing us confusion/annoyance.
It's basically so I can run 2.9 and 3.0 with the same hubbub, I was
going to ditch it once 3.0 became stable enough to use. I'll fix 2.9
so it works with the new one, probably less hassle anyway.
I daren't delete my branch until I've reverted Git's config and tested
that my commits are going to the right place again.
Chris
Re: libdom: branch master updated. af0e4892995a00aa35f7c288bfba45bdd507dc4c
On Sat, Jul 28, 2012 at 08:56:27PM +0100, NetSurf Browser Project wrote:
[snip]
> The branch, master has been updated
[snip]
> Commit: Chris Young <chris@unsatisfactorysoftware.co.uk>
>
> Merge branch 'master' of git://git.netsurf-browser.org/libdom into chris/amiga-hubbub-lib-compat
[snip]
Chris,
Your maintaining of a chris/amiga-hubbub-lib-compat branch is driving a lot of
us crazy. Firstly because you create a bunch of commit messages for "keeping
up" with master and secondly because you managed to corrupt master with your
"compat" change.
I have resynchronised master of libdom with master of hubbub to un-do your change.
Why are you maintaining some kind of 'compat' branch at this point? We've
never made an ABI/API commitment and as such we're shouldn't be trying to
maintain "compatibility" not least of which because there's no way for a modern
libhubbub to know that you're not passing a script callback anyway so it'll
jump off into oblivion given the opportunity.
Unless you have a really *really* good reason for this, I ask that you stop
maintaining these branches because they're clearly causing you confusion at
times; and they're definitely causing us confusion/annoyance.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
[snip]
> The branch, master has been updated
[snip]
> Commit: Chris Young <chris@unsatisfactorysoftware.co.uk>
>
> Merge branch 'master' of git://git.netsurf-browser.org/libdom into chris/amiga-hubbub-lib-compat
[snip]
Chris,
Your maintaining of a chris/amiga-hubbub-lib-compat branch is driving a lot of
us crazy. Firstly because you create a bunch of commit messages for "keeping
up" with master and secondly because you managed to corrupt master with your
"compat" change.
I have resynchronised master of libdom with master of hubbub to un-do your change.
Why are you maintaining some kind of 'compat' branch at this point? We've
never made an ABI/API commitment and as such we're shouldn't be trying to
maintain "compatibility" not least of which because there's no way for a modern
libhubbub to know that you're not passing a script callback anyway so it'll
jump off into oblivion given the opportunity.
Unless you have a really *really* good reason for this, I ask that you stop
maintaining these branches because they're clearly causing you confusion at
times; and they're definitely causing us confusion/annoyance.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Wednesday, 25 July 2012
Re: Patch: change atari Makefile.default setup
Am Mittwoch, den 25.07.2012, 14:09 +0200 schrieb Daniel Silverstone
<dsilvers@netsurf-browser.org>:
> For this kind of thing, ensure the patch is on a branch pushed to the
> repository so we can just merge it.
>
> So you should push that to (for example) mono/change-atari-defaults
OK, please merge branch "change-atari-defaults". Thanks.
Greets,
Ole
<dsilvers@netsurf-browser.org>:
> For this kind of thing, ensure the patch is on a branch pushed to the
> repository so we can just merge it.
>
> So you should push that to (for example) mono/change-atari-defaults
OK, please merge branch "change-atari-defaults". Thanks.
Greets,
Ole
Re: Patch: change atari Makefile.default setup
On Wed, Jul 25, 2012 at 02:04:41PM +0200, Ole wrote:
> I recently pushed an change to the Atari Makefile.target that
> requires this change.
> Pleas add the patch, thanks.
For this kind of thing, ensure the patch is on a branch pushed to the
repository so we can just merge it.
So you should push that to (for example) mono/change-atari-defaults
Then I (or jmb, vince, etc) can merge, verify, and push for you.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> I recently pushed an change to the Atari Makefile.target that
> requires this change.
> Pleas add the patch, thanks.
For this kind of thing, ensure the patch is on a branch pushed to the
repository so we can just merge it.
So you should push that to (for example) mono/change-atari-defaults
Then I (or jmb, vince, etc) can merge, verify, and push for you.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Patch: change atari Makefile.default setup
diff --git a/Makefile.defaults b/Makefile.defaults
index 1fdb425..74426d9 100644
--- a/Makefile.defaults
+++ b/Makefile.defaults
@@ -371,10 +371,19 @@ ifeq ($(TARGET),atari)
NETSURF_USE_MNG := NO
- NETSURF_ATARI_USE_FREETYPE := YES
+ # enable true type fonts via freetype2
+ NETSURF_USE_ATARI_FREETYPE_FONT := YES
- # Optimisation levels
- CFLAGS += -m68000 -O2 -Wuninitialized
+ # Enable use of netsurf embedded font
+ NETSURF_USE_ATARI_NETSURF_FONT := YES
+
+ NETSURF_USE_ATARI_8BPP_SUPPORT := NO
+
+ ATARI_ARCH = 68020-60
+
+ # enable optimizations
+ # -O2 is currently broken with m68000 / m68020-60 builds
+ CFLAGS += -O1 -Wuninitialized
WARNFLAGS = -W -Wundef -Wpointer-arith \
-Wcast-align -Wwrite-strings -Wstrict-prototypes \
Hello,
I recently pushed an change to the Atari Makefile.target that requires
this change.
Pleas add the patch, thanks.
Greets,
Ole
index 1fdb425..74426d9 100644
--- a/Makefile.defaults
+++ b/Makefile.defaults
@@ -371,10 +371,19 @@ ifeq ($(TARGET),atari)
NETSURF_USE_MNG := NO
- NETSURF_ATARI_USE_FREETYPE := YES
+ # enable true type fonts via freetype2
+ NETSURF_USE_ATARI_FREETYPE_FONT := YES
- # Optimisation levels
- CFLAGS += -m68000 -O2 -Wuninitialized
+ # Enable use of netsurf embedded font
+ NETSURF_USE_ATARI_NETSURF_FONT := YES
+
+ NETSURF_USE_ATARI_8BPP_SUPPORT := NO
+
+ ATARI_ARCH = 68020-60
+
+ # enable optimizations
+ # -O2 is currently broken with m68000 / m68020-60 builds
+ CFLAGS += -O1 -Wuninitialized
WARNFLAGS = -W -Wundef -Wpointer-arith \
-Wcast-align -Wwrite-strings -Wstrict-prototypes \
Hello,
I recently pushed an change to the Atari Makefile.target that requires
this change.
Pleas add the patch, thanks.
Greets,
Ole
Tuesday, 24 July 2012
Re: DuckDuckgo and NetSurf
[ Repeat of email sent 25 June ]
On Fri, Jun 22, 2012 at 03:20:09PM +0530, Prakash Swaminathan wrote:
> DuckDuckGo is a general search engine with instant answers, less
> spam/clutter and real privacy.
And good results usually :-)
> It looks like we are an option in NetSurf (
> http://source.netsurf-browser.org/trunk/netsurf/!NetSurf/Resources/SearchEngines?view=markup)
> and wanted to explore a revenue share partnership,
That's a very interesting question.
> Who do you recommend we speak with to start this conversation?
For now, you can continue to talk on this list; however if you require a little
more privacy, you could contact either the Netsurf Society Committee
<committee@netsurf-browser.org> or else the treasurer directly John-Mark Bell
<treasurer@netsurf-browser.org>
Thanks for thinking about this.
Daniel
Society Secretary
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
On Fri, Jun 22, 2012 at 03:20:09PM +0530, Prakash Swaminathan wrote:
> DuckDuckGo is a general search engine with instant answers, less
> spam/clutter and real privacy.
And good results usually :-)
> It looks like we are an option in NetSurf (
> http://source.netsurf-browser.org/trunk/netsurf/!NetSurf/Resources/SearchEngines?view=markup)
> and wanted to explore a revenue share partnership,
That's a very interesting question.
> Who do you recommend we speak with to start this conversation?
For now, you can continue to talk on this list; however if you require a little
more privacy, you could contact either the Netsurf Society Committee
<committee@netsurf-browser.org> or else the treasurer directly John-Mark Bell
<treasurer@netsurf-browser.org>
Thanks for thinking about this.
Daniel
Society Secretary
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Re: netsurf: branch master updated. 0bbe65de26180079f70de0d7f4b6ee1eaaf54293
On Tue, Jul 24, 2012 at 08:34:09AM +0100, Chris Young wrote:
> > You can alter it so that an unadorned 'git push' only pushes your current
> > branch towards its upstream by running:
> >
> > git config --global push.default upstream
> >
> > Personally I always set that on my dev machines because it makes more sense to
> > me.
> Excellent, I'll set that, thanks.
> Perhaps this needs to be on the wiki page too?
If it fixes your problem, then put it on the wiki along with a note about what
it solves, so that if others encounter the issue they will be able to find the
solution.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> > You can alter it so that an unadorned 'git push' only pushes your current
> > branch towards its upstream by running:
> >
> > git config --global push.default upstream
> >
> > Personally I always set that on my dev machines because it makes more sense to
> > me.
> Excellent, I'll set that, thanks.
> Perhaps this needs to be on the wiki page too?
If it fixes your problem, then put it on the wiki along with a note about what
it solves, so that if others encounter the issue they will be able to find the
solution.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Re: netsurf: branch master updated. 0bbe65de26180079f70de0d7f4b6ee1eaaf54293
On Tue, 24 Jul 2012 08:28:03 +0100, Daniel Silverstone wrote:
> You can alter it so that an unadorned 'git push' only pushes your current
> branch towards its upstream by running:
>
> git config --global push.default upstream
>
> Personally I always set that on my dev machines because it makes more sense to
> me.
Excellent, I'll set that, thanks.
Perhaps this needs to be on the wiki page too?
Chris
> You can alter it so that an unadorned 'git push' only pushes your current
> branch towards its upstream by running:
>
> git config --global push.default upstream
>
> Personally I always set that on my dev machines because it makes more sense to
> me.
Excellent, I'll set that, thanks.
Perhaps this needs to be on the wiki page too?
Chris
Re: netsurf: branch master updated. 0bbe65de26180079f70de0d7f4b6ee1eaaf54293
On Mon, Jul 23, 2012 at 10:46:53PM +0100, Chris Young wrote:
> Right, I'm officially confused now as it definitely said I didn't have
> permission ("ruleset denied access" and lots of "[rejected]" next to
> the branches - but not master, curiously)
Git's default behaviour when you say 'git push' is to try and push *all* local
branches which match the name an existing remote branch. As such, an unadorned
'git push' will try and push every single branch which might match and you'll
get a [rejected] next to any refs which fail to push (e.g. because they're a
rebase or behind or similar).
You can alter it so that an unadorned 'git push' only pushes your current
branch towards its upstream by running:
git config --global push.default upstream
Personally I always set that on my dev machines because it makes more sense to
me.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> Right, I'm officially confused now as it definitely said I didn't have
> permission ("ruleset denied access" and lots of "[rejected]" next to
> the branches - but not master, curiously)
Git's default behaviour when you say 'git push' is to try and push *all* local
branches which match the name an existing remote branch. As such, an unadorned
'git push' will try and push every single branch which might match and you'll
get a [rejected] next to any refs which fail to push (e.g. because they're a
rebase or behind or similar).
You can alter it so that an unadorned 'git push' only pushes your current
branch towards its upstream by running:
git config --global push.default upstream
Personally I always set that on my dev machines because it makes more sense to
me.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Monday, 23 July 2012
Re: FatMessages update
On 23 Jul 2012 22:38:51 +0100, Chris Young wrote:
> Samir sent through another update to the Italian strings - but I don't
> have access to that area anymore to commit them.
Scratch that - yes I do. Git's error reporting is utterly
incomprehensible (to me, anyway), it gives me false errors when I
merge too.
Chris
> Samir sent through another update to the Italian strings - but I don't
> have access to that area anymore to commit them.
Scratch that - yes I do. Git's error reporting is utterly
incomprehensible (to me, anyway), it gives me false errors when I
merge too.
Chris
Re: netsurf: branch master updated. 0bbe65de26180079f70de0d7f4b6ee1eaaf54293
On 23 Jul 2012 22:46:53 +0100, Chris Young wrote:
> On Mon, 23 Jul 2012 22:31:17 +0100, Commit Mailer wibbled on for an age:
>
> > commitdiff http://git.netsurf-browser.org/netsurf.git/commitdiff/773cbd2aea9e0dd1375f1619d1938b625e00d85b
> > commit 773cbd2aea9e0dd1375f1619d1938b625e00d85b
> > Author: Chris Young <chris@unsatisfactorysoftware.co.uk>
> > Commit: Chris Young <chris@unsatisfactorysoftware.co.uk>
> >
> > Update of Italian strings (credit: Samir Hawamdeh)
> >
> > diff --git a/resources/FatMessages b/resources/FatMessages
>
> Right, I'm officially confused now as it definitely said I didn't have
> permission ("ruleset denied access" and lots of "[rejected]" next to
> the branches - but not master, curiously)
>
> I'm on master branch and it clearly hasn't updated locally. The
> website shows the diffs but the blob still contains "Disegna" instead
> of "Draw", so... *shrug*
Hold on... maybe it did update, there is still a "Disegna" present in
the new file, which I think should be a "Draw". I was looking at the
wrong line.
Not sure why it rejected it for the branches, although it shouldn't
have been applying it to those anyway.
Chris
> On Mon, 23 Jul 2012 22:31:17 +0100, Commit Mailer wibbled on for an age:
>
> > commitdiff http://git.netsurf-browser.org/netsurf.git/commitdiff/773cbd2aea9e0dd1375f1619d1938b625e00d85b
> > commit 773cbd2aea9e0dd1375f1619d1938b625e00d85b
> > Author: Chris Young <chris@unsatisfactorysoftware.co.uk>
> > Commit: Chris Young <chris@unsatisfactorysoftware.co.uk>
> >
> > Update of Italian strings (credit: Samir Hawamdeh)
> >
> > diff --git a/resources/FatMessages b/resources/FatMessages
>
> Right, I'm officially confused now as it definitely said I didn't have
> permission ("ruleset denied access" and lots of "[rejected]" next to
> the branches - but not master, curiously)
>
> I'm on master branch and it clearly hasn't updated locally. The
> website shows the diffs but the blob still contains "Disegna" instead
> of "Draw", so... *shrug*
Hold on... maybe it did update, there is still a "Disegna" present in
the new file, which I think should be a "Draw". I was looking at the
wrong line.
Not sure why it rejected it for the branches, although it shouldn't
have been applying it to those anyway.
Chris
Re: netsurf: branch master updated. 0bbe65de26180079f70de0d7f4b6ee1eaaf54293
On Mon, 23 Jul 2012 22:31:17 +0100, Commit Mailer wibbled on for an age:
> commitdiff http://git.netsurf-browser.org/netsurf.git/commitdiff/773cbd2aea9e0dd1375f1619d1938b625e00d85b
> commit 773cbd2aea9e0dd1375f1619d1938b625e00d85b
> Author: Chris Young <chris@unsatisfactorysoftware.co.uk>
> Commit: Chris Young <chris@unsatisfactorysoftware.co.uk>
>
> Update of Italian strings (credit: Samir Hawamdeh)
>
> diff --git a/resources/FatMessages b/resources/FatMessages
Right, I'm officially confused now as it definitely said I didn't have
permission ("ruleset denied access" and lots of "[rejected]" next to
the branches - but not master, curiously)
I'm on master branch and it clearly hasn't updated locally. The
website shows the diffs but the blob still contains "Disegna" instead
of "Draw", so... *shrug*
Chris
> commitdiff http://git.netsurf-browser.org/netsurf.git/commitdiff/773cbd2aea9e0dd1375f1619d1938b625e00d85b
> commit 773cbd2aea9e0dd1375f1619d1938b625e00d85b
> Author: Chris Young <chris@unsatisfactorysoftware.co.uk>
> Commit: Chris Young <chris@unsatisfactorysoftware.co.uk>
>
> Update of Italian strings (credit: Samir Hawamdeh)
>
> diff --git a/resources/FatMessages b/resources/FatMessages
Right, I'm officially confused now as it definitely said I didn't have
permission ("ruleset denied access" and lots of "[rejected]" next to
the branches - but not master, curiously)
I'm on master branch and it clearly hasn't updated locally. The
website shows the diffs but the blob still contains "Disegna" instead
of "Draw", so... *shrug*
Chris
FatMessages update
Hi
Samir sent through another update to the Italian strings - but I don't
have access to that area anymore to commit them.
It would be useful for me to have access to modify FatMessages as I
have all my GUI strings in there that I often need to add to or edit.
However, I'm happy to tell Samir to send translation updates to
somebody else if that needs to be more controlled.
I've attached the new file.
Regards
Chris
Samir sent through another update to the Italian strings - but I don't
have access to that area anymore to commit them.
It would be useful for me to have access to modify FatMessages as I
have all my GUI strings in there that I often need to add to or edit.
However, I'm happy to tell Samir to send translation updates to
somebody else if that needs to be more controlled.
I've attached the new file.
Regards
Chris
[gccsdk] Building trunk/gcc4
For those who are building trunk/gcc4, if you want to survive r5923 you
need to do a 'make clean' first before you can enjoy the long build time.
I've redefined our multilibs by adding VFPv2 and VFPv3+NEON builds of
libgcc, libstdc++, libunixlib, libscl (app + module).
John.
--
John Tytgat, in his comfy chair at home BASS
John.Tytgat@aaug.net ARM powered, RISC OS driven
_______________________________________________
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
need to do a 'make clean' first before you can enjoy the long build time.
I've redefined our multilibs by adding VFPv2 and VFPv3+NEON builds of
libgcc, libstdc++, libunixlib, libscl (app + module).
John.
--
John Tytgat, in his comfy chair at home BASS
John.Tytgat@aaug.net ARM powered, RISC OS driven
_______________________________________________
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
Sunday, 22 July 2012
Re: DuckDuckgo and NetSurf
Hello,
Who do you recommend we speak with to start this conversation?
Thank you,
Prakash
On Fri, Jun 22, 2012 at 5:50 AM, Prakash Swaminathan
<prakash@duckduckgo.com> wrote:
> Hello,
>
> DuckDuckGo is a general search engine with instant answers, less
> spam/clutter and real privacy.
>
> It looks like we are an option in NetSurf
> (http://source.netsurf-browser.org/trunk/netsurf/!NetSurf/Resources/SearchEngines?view=markup)
> and wanted to explore a revenue share partnership,
>
> Who do you recommend we speak with to start this conversation?
>
> Kind regards,
> Prakash
> --
> Prakash Swaminathan https://duckduckgo.com/
>
--
Prakash Swaminathan https://duckduckgo.com/
503-928-7721 Skype: PrakashSwami
Who do you recommend we speak with to start this conversation?
Thank you,
Prakash
On Fri, Jun 22, 2012 at 5:50 AM, Prakash Swaminathan
<prakash@duckduckgo.com> wrote:
> Hello,
>
> DuckDuckGo is a general search engine with instant answers, less
> spam/clutter and real privacy.
>
> It looks like we are an option in NetSurf
> (http://source.netsurf-browser.org/trunk/netsurf/!NetSurf/Resources/SearchEngines?view=markup)
> and wanted to explore a revenue share partnership,
>
> Who do you recommend we speak with to start this conversation?
>
> Kind regards,
> Prakash
> --
> Prakash Swaminathan https://duckduckgo.com/
>
--
Prakash Swaminathan https://duckduckgo.com/
503-928-7721 Skype: PrakashSwami
Saturday, 21 July 2012
Re: netsurf: branch master updated. 5fc781d715cab48f03fb4d72558d35f65c6528c3
On Sat, 21 Jul 2012 18:55:15 +0100, Michael Drake wrote:
> > > +++ b/!NetSurf/Resources/en/welcome.html,faf
> We still need to sort out how loading the best language variant is going
> to work.
Already does here :)
My resource: locator uses the same code as for Messages, so it
searches through all the language directories in OS preferences order
looking for the welcome page.
Would probably make more sense for it to respect accept-languages
instead though (especially as the Japanese page can currently never be
selected as the OS doesn't provide any Japanese language support)
Chris
> > > +++ b/!NetSurf/Resources/en/welcome.html,faf
> We still need to sort out how loading the best language variant is going
> to work.
Already does here :)
My resource: locator uses the same code as for Messages, so it
searches through all the language directories in OS preferences order
looking for the welcome page.
Would probably make more sense for it to respect accept-languages
instead though (especially as the Japanese page can currently never be
selected as the OS doesn't provide any Japanese language support)
Chris
Re: netsurf: branch master updated. 5fc781d715cab48f03fb4d72558d35f65c6528c3
In article
<OUT-500AEFBA.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
> > +++ b/!NetSurf/Resources/en/welcome.html,faf
> [...]
> > +<link rel="icon" type="image/png" href="/webimages/favicon.png">
> That link doesn't exist locally. I think it might be the same for the
> other languages too (although the German one seems to be pulling
> *everything* from netsurf-browser.org, which I'm not sure is right
> either)
Thanks!
I forgot to remove the favicons when I pulled in the online pages.
Fixed the logo image URL for non-English versions too.
We still need to sort out how loading the best language variant is going
to work.
Cheers,
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
<OUT-500AEFBA.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>,
Chris Young <chris.young@unsatisfactorysoftware.co.uk> wrote:
> > +++ b/!NetSurf/Resources/en/welcome.html,faf
> [...]
> > +<link rel="icon" type="image/png" href="/webimages/favicon.png">
> That link doesn't exist locally. I think it might be the same for the
> other languages too (although the German one seems to be pulling
> *everything* from netsurf-browser.org, which I'm not sure is right
> either)
Thanks!
I forgot to remove the favicons when I pulled in the online pages.
Fixed the logo image URL for non-English versions too.
We still need to sort out how loading the best language variant is going
to work.
Cheers,
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Re: netsurf: branch master updated. 5fc781d715cab48f03fb4d72558d35f65c6528c3
> +++ b/!NetSurf/Resources/en/welcome.html,faf
[...]
> +<link rel="icon" type="image/png" href="/webimages/favicon.png">
That link doesn't exist locally. I think it might be the same for the
other languages too (although the German one seems to be pulling
*everything* from netsurf-browser.org, which I'm not sure is right
either)
Chris
[...]
> +<link rel="icon" type="image/png" href="/webimages/favicon.png">
That link doesn't exist locally. I think it might be the same for the
other languages too (although the German one seems to be pulling
*everything* from netsurf-browser.org, which I'm not sure is right
either)
Chris
Thursday, 19 July 2012
Re: netsurf: branch master updated. 345ea141d0410cf5dbde888659edfbefd838ce02
On Thu, Jul 19, 2012 at 01:06:30PM +0100, NetSurf Browser Project wrote:
> Gitweb links:
>
> ...log http://git.netsurf-browser.org/netsurf.git/shortlog/345ea141d0410cf5dbde888659edfbefd838ce02
> ...commit http://git.netsurf-browser.org/netsurf.git/commit/345ea141d0410cf5dbde888659edfbefd838ce02
> ...tree http://git.netsurf-browser.org/netsurf.git/tree/345ea141d0410cf5dbde888659edfbefd838ce02
> commitdiff http://git.netsurf-browser.org/netsurf.git/commitdiff/345ea141d0410cf5dbde888659edfbefd838ce02
I borked the reponame calculation in the commit mailer script so these links won't work.
Should be fixed now.
Sorry
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> Gitweb links:
>
> ...log http://git.netsurf-browser.org/netsurf.git/shortlog/345ea141d0410cf5dbde888659edfbefd838ce02
> ...commit http://git.netsurf-browser.org/netsurf.git/commit/345ea141d0410cf5dbde888659edfbefd838ce02
> ...tree http://git.netsurf-browser.org/netsurf.git/tree/345ea141d0410cf5dbde888659edfbefd838ce02
> commitdiff http://git.netsurf-browser.org/netsurf.git/commitdiff/345ea141d0410cf5dbde888659edfbefd838ce02
I borked the reponame calculation in the commit mailer script so these links won't work.
Should be fixed now.
Sorry
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Tuesday, 17 July 2012
Re: TTF2F download link incorrect
In article <52ac796f96Paul@sprie.nl>,
Paul Sprangers <Paul@sprie.nl> wrote:
> Anyhow, TTF2f is an extremely valuable tool, but currently it fails when
> used on an Iyonix with very large fonts.
TTF2f is currently in need of a maintainer. If anyone wants to develop
it, please get in touch via the NetSurf developer mailing list.
See the 07 Dec 2011 news item here:
http://www.netsurf-browser.org/about/news
In article <825647ab52.martin@blueyonder.co.uk>,
Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
> Through experimentation, the correct URL appears to be this
Thanks, I've now fixed the TTF2f download link.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Paul Sprangers <Paul@sprie.nl> wrote:
> Anyhow, TTF2f is an extremely valuable tool, but currently it fails when
> used on an Iyonix with very large fonts.
TTF2f is currently in need of a maintainer. If anyone wants to develop
it, please get in touch via the NetSurf developer mailing list.
See the 07 Dec 2011 news item here:
http://www.netsurf-browser.org/about/news
In article <825647ab52.martin@blueyonder.co.uk>,
Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
> Through experimentation, the correct URL appears to be this
Thanks, I've now fixed the TTF2f download link.
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Monday, 16 July 2012
Re: [gccsdk] Something wrong with SOManager?
Lee Noar <leenoar@sky.com> wrote:
> On 08/07/12 13:55, Jan-Jaap van der Geer wrote:
> > This is what I am seeing:
> [Snip]
> > *ADFS::HardDisc4.$.Projects.!SharedLibs
> > *gcc --version
> > Internal error: abort on data transfer at&7F11F46C
> > *help somanager
> > ==> Help on keyword SOManager
> > Module is: Shared Object Manager 2.10 (07 Jul 2012) (c) GCCSDK Developers
> > Commands provided:
> > SOMStatus SOMAddress SOMExpire SOMAllowQuit SOMRun
> > SOMHistory
> > Any ideas what is going on?
> I'm afraid I can't reproduce this. I've updated to r5899
> (actually 5888 was the last revision the compiler was updated)
> and rebuilt everything from scratch. gcc --version works for me
> and I can compile helloworld.
> Are you sure that when you merge, all components have been
> updated? Can you try moving your existing installation, i.e. !GCC
> & !SharedLibs to one side and trying with a completely clean
> install?
Strange. I rebuild the compiler from scratch and all seems well
now. Not sure what happened...
Thanks,
Jan-Jaap
_______________________________________________
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 08/07/12 13:55, Jan-Jaap van der Geer wrote:
> > This is what I am seeing:
> [Snip]
> > *ADFS::HardDisc4.$.Projects.!SharedLibs
> > *gcc --version
> > Internal error: abort on data transfer at&7F11F46C
> > *help somanager
> > ==> Help on keyword SOManager
> > Module is: Shared Object Manager 2.10 (07 Jul 2012) (c) GCCSDK Developers
> > Commands provided:
> > SOMStatus SOMAddress SOMExpire SOMAllowQuit SOMRun
> > SOMHistory
> > Any ideas what is going on?
> I'm afraid I can't reproduce this. I've updated to r5899
> (actually 5888 was the last revision the compiler was updated)
> and rebuilt everything from scratch. gcc --version works for me
> and I can compile helloworld.
> Are you sure that when you merge, all components have been
> updated? Can you try moving your existing installation, i.e. !GCC
> & !SharedLibs to one side and trying with a completely clean
> install?
Strange. I rebuild the compiler from scratch and all seems well
now. Not sure what happened...
Thanks,
Jan-Jaap
_______________________________________________
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
Sunday, 15 July 2012
Re: [Rpcemu] Patch for missing IOMD registers
On 12 July 2012 09:27, Sprow <webpages@sprow.co.uk> wrote:
Thanks for this. I'll ensure it gets incorporated into the codebase.
Matthew
Hi,
The emulation does seem to support software generated FIQs (by the
permanently set bit 7 in the FIQ status reg) but no way to read it back
(returns 0). See patch below,
Sprow.
Thanks for this. I'll ensure it gets incorporated into the codebase.
Matthew
Saturday, 14 July 2012
Access to Docs directory
Hello there,
today I tried the windows build and updated the BUILDING-Windows doc
with latest links to the libs, (Some links were broken).
I would like to pull that change. Also I would like to update the Atari
Docs when I like to do it. So I'm requesting access right
to the netsurf.git/Docs folder. Thanks in advance.
Greets,
Ole
today I tried the windows build and updated the BUILDING-Windows doc
with latest links to the libs, (Some links were broken).
I would like to pull that change. Also I would like to update the Atari
Docs when I like to do it. So I'm requesting access right
to the netsurf.git/Docs folder. Thanks in advance.
Greets,
Ole
Re: [gccsdk] Possible crash with system() call
In message <SNT136-W5279A0B6274CE8B9DF1595F0D60@phx.gbl>
alan buckley <alan_baa@hotmail.com> wrote:
> I've been getting a mysterious crash and think I may have tracked
> it down to the use of a system() call. Unfortunatly I can't be sure
> as it messes up memory completely so the machine isn't in a
> stable state after the crash.
>
> It seems that if my Wimp task claims more memory after
> starting up and then calls:
>
> system("Filer_OpenDir a_directory");
>
> some sort of corruption occurs as after I close my next
> two windows a crash occurs.
>
> This is happening on my Iyonix RISC OS 5.16 128MB consistantly.
> Increasing the Wimp slot seems to fix the problem.
>
> However I can't reproduce it on RISC OS 4.0.2 or RISC OS 5.19
> running on RPCEmu.
>
> I haven't even managed to create a smaller test program to
> reproduce the problem, so it may be something else.
>
> I was hoping someone who is familiar with the system() call
> code could have a look at its code to see if there is some
> edge case I may be hitting.
As long as your program isn't corrupting the memory pool, you shouldn't
get such a crash as you're describing. It looks like if there is not
enough application memory free the system() implementation badly fails.
If that's the case it would be workwhile to get to the bottom of this
but as you can imagine we need a reproducable case because system()
implementation is quite complex.
Are you using the same WimpSlot size for reproducing on RO 4.02 and
RO 5.19 ? Make sure you're using (or not using) DA for reproducing as
well.
> [...]
> P.S. As an aside I'm wondering about using Wimp_StartTask
> instead of a system call and was wondering if anyone knew
> if that is sensible or not.
If your program is already a Wimp task, yes, I think you can use
Wimp_StartTask.
John.
--
John Tytgat, in his comfy chair at home BASS
John.Tytgat@aaug.net ARM powered, RISC OS driven
_______________________________________________
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 been getting a mysterious crash and think I may have tracked
> it down to the use of a system() call. Unfortunatly I can't be sure
> as it messes up memory completely so the machine isn't in a
> stable state after the crash.
>
> It seems that if my Wimp task claims more memory after
> starting up and then calls:
>
> system("Filer_OpenDir a_directory");
>
> some sort of corruption occurs as after I close my next
> two windows a crash occurs.
>
> This is happening on my Iyonix RISC OS 5.16 128MB consistantly.
> Increasing the Wimp slot seems to fix the problem.
>
> However I can't reproduce it on RISC OS 4.0.2 or RISC OS 5.19
> running on RPCEmu.
>
> I haven't even managed to create a smaller test program to
> reproduce the problem, so it may be something else.
>
> I was hoping someone who is familiar with the system() call
> code could have a look at its code to see if there is some
> edge case I may be hitting.
As long as your program isn't corrupting the memory pool, you shouldn't
get such a crash as you're describing. It looks like if there is not
enough application memory free the system() implementation badly fails.
If that's the case it would be workwhile to get to the bottom of this
but as you can imagine we need a reproducable case because system()
implementation is quite complex.
Are you using the same WimpSlot size for reproducing on RO 4.02 and
RO 5.19 ? Make sure you're using (or not using) DA for reproducing as
well.
> [...]
> P.S. As an aside I'm wondering about using Wimp_StartTask
> instead of a system call and was wondering if anyone knew
> if that is sensible or not.
If your program is already a Wimp task, yes, I think you can use
Wimp_StartTask.
John.
--
John Tytgat, in his comfy chair at home BASS
John.Tytgat@aaug.net ARM powered, RISC OS driven
_______________________________________________
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] Possible crash with system() call
I've been getting a mysterious crash and think I may have tracked
it down to the use of a system() call. Unfortunatly I can't be sure
as it messes up memory completely so the machine isn't in a
stable state after the crash.
It seems that if my Wimp task claims more memory after
starting up and then calls:
system("Filer_OpenDir a_directory");
some sort of corruption occurs as after I close my next
two windows a crash occurs.
This is happening on my Iyonix RISC OS 5.16 128MB consistantly.
Increasing the Wimp slot seems to fix the problem.
However I can't reproduce it on RISC OS 4.0.2 or RISC OS 5.19
running on RPCEmu.
I haven't even managed to create a smaller test program to
reproduce the problem, so it may be something else.
I was hoping someone who is familiar with the system() call
code could have a look at its code to see if there is some
edge case I may be hitting.
Thanks,
Alan
P.S. As an aside I'm wondering about using Wimp_StartTask
instead of a system call and was wondering if anyone knew
if that is sensible or not.
it down to the use of a system() call. Unfortunatly I can't be sure
as it messes up memory completely so the machine isn't in a
stable state after the crash.
It seems that if my Wimp task claims more memory after
starting up and then calls:
system("Filer_OpenDir a_directory");
some sort of corruption occurs as after I close my next
two windows a crash occurs.
This is happening on my Iyonix RISC OS 5.16 128MB consistantly.
Increasing the Wimp slot seems to fix the problem.
However I can't reproduce it on RISC OS 4.0.2 or RISC OS 5.19
running on RPCEmu.
I haven't even managed to create a smaller test program to
reproduce the problem, so it may be something else.
I was hoping someone who is familiar with the system() call
code could have a look at its code to see if there is some
edge case I may be hitting.
Thanks,
Alan
P.S. As an aside I'm wondering about using Wimp_StartTask
instead of a system call and was wondering if anyone knew
if that is sensible or not.
Friday, 13 July 2012
Re: [Rpcemu] Host FS and "?" in file names
In message <SNT136-ds179C4F895EB1FDEA21B2F5F0D10@phx.gbl>
on 11 Jul 2012 Alan Buckley wrote:
> I've just noticed that HostFS does not support "?• in file names.
>
> ADFS does, should HostFS as well?
>
> I know Windows does not support the "?• in filenames, so some
> kind of mapping would be required.
DOSFS maps the question mark to hash, so a file called "abc?def" would appear
in the raw DOS directory structure as "abc#def". It would be best to copy
this mapping.
> I spotted this as StrongED uses a filename "?filetype•.
I think CVS also uses question marks in files, which probably explained why I
was unable, a few years ago, to make it work from RISC OS when the repository
was on HostFS.
--
Matthew Phillips
Durham
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
on 11 Jul 2012 Alan Buckley wrote:
> I've just noticed that HostFS does not support "?• in file names.
>
> ADFS does, should HostFS as well?
>
> I know Windows does not support the "?• in filenames, so some
> kind of mapping would be required.
DOSFS maps the question mark to hash, so a file called "abc?def" would appear
in the raw DOS directory structure as "abc#def". It would be best to copy
this mapping.
> I spotted this as StrongED uses a filename "?filetype•.
I think CVS also uses question marks in files, which probably explained why I
was unable, a few years ago, to make it work from RISC OS when the repository
was on HostFS.
--
Matthew Phillips
Durham
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[gccsdk] [Bug 241] Null pointer dereference in __get_dde_prefix()
http://www.riscos.info/bugzilla3/show_bug.cgi?id=241
John Tytgat <John.Tytgat@aaug.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |John.Tytgat@aaug.net
Resolution| |FIXED
--- Comment #1 from John Tytgat <John.Tytgat@aaug.net> 2012-07-13 07:26:26 PDT ---
Should be solved with r5902 on trunk/gcc4 and r5904 on branches/release_4_1_2.
Thanks for the bug report.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
John Tytgat <John.Tytgat@aaug.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |John.Tytgat@aaug.net
Resolution| |FIXED
--- Comment #1 from John Tytgat <John.Tytgat@aaug.net> 2012-07-13 07:26:26 PDT ---
Should be solved with r5902 on trunk/gcc4 and r5904 on branches/release_4_1_2.
Thanks for the bug report.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
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] 'Stable' package repository
I've been testing some riscos.info RiscPkg packages on the Raspberry Pi. It
turns out that some don't work, largely it appears due to alignment
exceptions. These can probably be fixed at the RPi end, but it did raise a
question about shipping packaged software. It would be good if we can ship
PackMan on the RPi default image, so that new software can be advertised to
existing RPi users.
At the moment, riscos.info has a single repository index, 'autobuilt', in
here:
http://www.riscos.info/packages/pkg/
There's also a 'test' image, but that seems to be older than the 'autobuilt'
version. Maybe this already does what I want, I'm unsure.
It would be handy to be able to do wider user-testing on packages before
they're shipped out to the general user community (who most likely have much
less RISC OS experience than most RISC OS users today). At the moment the
package builder does testing and then Alan turns the handle to ship it out
to 'autobuilder'. That means there's no way to do wider user-testing on
that stream before it's published to all users.
Graham's riscpkg.org setup has 'stable' and 'experimental' indices, just
like Debian (But much of Graham's repository isn't ARMv7 safe, or is plain
confusing - eg these days Nettle is the thing to use for SSH, not
NettleSSH).
How about a 'stable' index on riscos.info, which requires a manual OK to
release a version (unlike, I think, 'autobuilt' which is generated by
autobuilder scripts)? A 'manual OK' could simply be a list of approved
packages and version numbers, with the index generated automatically, but
more simply an edit of the existing package file.
Is the rationale behind 'autobuilt' that there would be a future index of
non-autobuilt things?
The other thing we'd have to be careful about is bumping package revision
numbers (ie the -1 suffix in fooapp_2.23-1.zip) so that old archives aren't
overwritten by new ones in the pool
http://www.riscos.info/packages/arm/
I'm hoping that someone in the RPi user community might be willing to
maintain such a list, given there's lots of enthusiasm for testing at the
moment. But at the moment the wish is to have a repository whose URL we can
ship and then allows testing and pushing out more packages after the release
deadline. If nobody is available to maintain the list, the worst that can
happen is that such a URL is a mirror of the 'autobuilt' packages list, but
it would be useful to divorce the two to give the option later.
Thoughts?
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
turns out that some don't work, largely it appears due to alignment
exceptions. These can probably be fixed at the RPi end, but it did raise a
question about shipping packaged software. It would be good if we can ship
PackMan on the RPi default image, so that new software can be advertised to
existing RPi users.
At the moment, riscos.info has a single repository index, 'autobuilt', in
here:
http://www.riscos.info/packages/pkg/
There's also a 'test' image, but that seems to be older than the 'autobuilt'
version. Maybe this already does what I want, I'm unsure.
It would be handy to be able to do wider user-testing on packages before
they're shipped out to the general user community (who most likely have much
less RISC OS experience than most RISC OS users today). At the moment the
package builder does testing and then Alan turns the handle to ship it out
to 'autobuilder'. That means there's no way to do wider user-testing on
that stream before it's published to all users.
Graham's riscpkg.org setup has 'stable' and 'experimental' indices, just
like Debian (But much of Graham's repository isn't ARMv7 safe, or is plain
confusing - eg these days Nettle is the thing to use for SSH, not
NettleSSH).
How about a 'stable' index on riscos.info, which requires a manual OK to
release a version (unlike, I think, 'autobuilt' which is generated by
autobuilder scripts)? A 'manual OK' could simply be a list of approved
packages and version numbers, with the index generated automatically, but
more simply an edit of the existing package file.
Is the rationale behind 'autobuilt' that there would be a future index of
non-autobuilt things?
The other thing we'd have to be careful about is bumping package revision
numbers (ie the -1 suffix in fooapp_2.23-1.zip) so that old archives aren't
overwritten by new ones in the pool
http://www.riscos.info/packages/arm/
I'm hoping that someone in the RPi user community might be willing to
maintain such a list, given there's lots of enthusiasm for testing at the
moment. But at the moment the wish is to have a repository whose URL we can
ship and then allows testing and pushing out more packages after the release
deadline. If nobody is available to maintain the list, the worst that can
happen is that such a URL is a mirror of the 'autobuilt' packages list, but
it would be useful to divorce the two to give the option later.
Thoughts?
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Thursday, 12 July 2012
[Rpcemu] Patch for missing IOMD registers
Hi,
The emulation does seem to support software generated FIQs (by the
permanently set bit 7 in the FIQ status reg) but no way to read it back
(returns 0). See patch below,
Sprow.
--- iomd.c 2012-07-12 08:40:41.0 +0100
+++ iomdpatch.c 2012-07-12 08:40:41.0 +0100
@@ -38,8 +38,8 @@
//#define IOMD_0x02C_STOPMODE 0x02C /* Enter STOP mode (ARM7500/FE) */
-//#define IOMD_0x030_FIQST 0x030 /* FIQ status */
-//#define IOMD_0x034_FIQRQ 0x034 /* FIQ request */
+#define IOMD_0x030_FIQST 0x030 /* FIQ status */
+#define IOMD_0x034_FIQRQ 0x034 /* FIQ request */
#define IOMD_0x038_FIQMSK 0x038 /* FIQ mask */
#define IOMD_0x03C_CLKCTL 0x03C /* Clock divider control (ARM7500/FE) */
@@ -565,6 +565,10 @@
case IOMD_0x028_IRQMSKB: /* IRQB mask */
return iomd.irqb.mask;
+ case IOMD_0x030_FIQST: /* FIQ status */
+ return iomd.fiq.status;
+ case IOMD_0x034_FIQRQ: /* FIQ request */
+ return iomd.fiq.status & iomd.fiq.mask;
case IOMD_0x038_FIQMSK: /* FIQ mask */
return iomd.fiq.mask;
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
The emulation does seem to support software generated FIQs (by the
permanently set bit 7 in the FIQ status reg) but no way to read it back
(returns 0). See patch below,
Sprow.
--- iomd.c 2012-07-12 08:40:41.0 +0100
+++ iomdpatch.c 2012-07-12 08:40:41.0 +0100
@@ -38,8 +38,8 @@
//#define IOMD_0x02C_STOPMODE 0x02C /* Enter STOP mode (ARM7500/FE) */
-//#define IOMD_0x030_FIQST 0x030 /* FIQ status */
-//#define IOMD_0x034_FIQRQ 0x034 /* FIQ request */
+#define IOMD_0x030_FIQST 0x030 /* FIQ status */
+#define IOMD_0x034_FIQRQ 0x034 /* FIQ request */
#define IOMD_0x038_FIQMSK 0x038 /* FIQ mask */
#define IOMD_0x03C_CLKCTL 0x03C /* Clock divider control (ARM7500/FE) */
@@ -565,6 +565,10 @@
case IOMD_0x028_IRQMSKB: /* IRQB mask */
return iomd.irqb.mask;
+ case IOMD_0x030_FIQST: /* FIQ status */
+ return iomd.fiq.status;
+ case IOMD_0x034_FIQRQ: /* FIQ request */
+ return iomd.fiq.status & iomd.fiq.mask;
case IOMD_0x038_FIQMSK: /* FIQ mask */
return iomd.fiq.mask;
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Wednesday, 11 July 2012
[Rpcemu] Host FS and "?" in file names
I've just noticed that HostFS does not support "?" in file names.
ADFS does, should HostFS as well?
I know Windows does not support the "?" in filenames, so some
kind of mapping would be required.
I spotted this as StrongED uses a filename "?filetype".
Interestingly when I tried to save an empty file with this from StrongED
it appeared to save, but nothing happened.
Regards,
Alan
Monday, 9 July 2012
Re: [Rpcemu] RPCEmu freeze when using TW
Hello Jim,
On Sun, 08 Jul 2012 18:37:24 +1000, Jim Lesurf <jcgl@audiomisc.co.uk>
wrote:
[snip]
>> Had another lockup today. This time I was running RPCEmu with debug
>> enabled, but the rpclog.txt doesn't show up anything different to what
>> it says for a good session. Does anyone have any ideas?
>
> What happens to the value for cpu use at the top of the RPCEmu window?
> I'm
> wondering if this is related to the 'freeze' I get at shutdown. There the
> cpu use goes high and stays high even though the emulation seems to
> freeze.
I haven't had another lockup since to be able to check for sure, but my
recollection is that that the cpu value is normal, but simply stops, as
does the real host cpu activity (I monitor host cpus etc with the GKrellM
utility).
I will see what happens next time I have a lockup and try to remember to
report back.
Cheers,
--
Regards,
Terry Duell
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
On Sun, 08 Jul 2012 18:37:24 +1000, Jim Lesurf <jcgl@audiomisc.co.uk>
wrote:
[snip]
>> Had another lockup today. This time I was running RPCEmu with debug
>> enabled, but the rpclog.txt doesn't show up anything different to what
>> it says for a good session. Does anyone have any ideas?
>
> What happens to the value for cpu use at the top of the RPCEmu window?
> I'm
> wondering if this is related to the 'freeze' I get at shutdown. There the
> cpu use goes high and stays high even though the emulation seems to
> freeze.
I haven't had another lockup since to be able to check for sure, but my
recollection is that that the cpu value is normal, but simply stops, as
does the real host cpu activity (I monitor host cpus etc with the GKrellM
utility).
I will see what happens next time I have a lockup and try to remember to
report back.
Cheers,
--
Regards,
Terry Duell
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[gccsdk] [Bug 241] New: Null pointer dereference in __get_dde_prefix()
http://www.riscos.info/bugzilla3/show_bug.cgi?id=241
Summary: Null pointer dereference in __get_dde_prefix()
Product: GCC/GCCSDK
Version: other
Platform: All
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: Unixlib and SharedCLibrary
AssignedTo: peter@chocky.org
ReportedBy: me@phlamethrower.co.uk
Estimated Hours: 0.0
After using __getenv_from_os() to look up <Prefix$Dir>, __get_dde_prefix()
(libunixlib/common/prefix.c) doesn't check if the returned pointer is null
before checking if the string is zero-length.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
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
Summary: Null pointer dereference in __get_dde_prefix()
Product: GCC/GCCSDK
Version: other
Platform: All
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: Unixlib and SharedCLibrary
AssignedTo: peter@chocky.org
ReportedBy: me@phlamethrower.co.uk
Estimated Hours: 0.0
After using __getenv_from_os() to look up <Prefix$Dir>, __get_dde_prefix()
(libunixlib/common/prefix.c) doesn't check if the returned pointer is null
before checking if the string is zero-length.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
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] Something wrong with SOManager?
On 08/07/12 13:55, Jan-Jaap van der Geer wrote:
> I seem to be having trouble with running ELF stuff with a freshly
> build (rev 5888).
>
> I've build the native compiler and merged the system with the newly
> build modules. I've also restarted after that, so it should not be
> any old modules still in memory.
>
> This is what I am seeing:
[Snip]
> *ADFS::HardDisc4.$.Projects.!SharedLibs
> *gcc --version
> Internal error: abort on data transfer at&7F11F46C
> *help somanager
> ==> Help on keyword SOManager
> Module is: Shared Object Manager 2.10 (07 Jul 2012) (c) GCCSDK Developers
>
> Commands provided:
> SOMStatus SOMAddress SOMExpire SOMAllowQuit SOMRun
> SOMHistory
>
> Any ideas what is going on?
I'm afraid I can't reproduce this. I've updated to r5899 (actually 5888
was the last revision the compiler was updated) and rebuilt everything
from scratch. gcc --version works for me and I can compile helloworld.
Are you sure that when you merge, all components have been updated?
Can you try moving your existing installation, i.e. !GCC & !SharedLibs
to one side and trying with a completely clean install?
Lee.
_______________________________________________
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
> I seem to be having trouble with running ELF stuff with a freshly
> build (rev 5888).
>
> I've build the native compiler and merged the system with the newly
> build modules. I've also restarted after that, so it should not be
> any old modules still in memory.
>
> This is what I am seeing:
[Snip]
> *ADFS::HardDisc4.$.Projects.!SharedLibs
> *gcc --version
> Internal error: abort on data transfer at&7F11F46C
> *help somanager
> ==> Help on keyword SOManager
> Module is: Shared Object Manager 2.10 (07 Jul 2012) (c) GCCSDK Developers
>
> Commands provided:
> SOMStatus SOMAddress SOMExpire SOMAllowQuit SOMRun
> SOMHistory
>
> Any ideas what is going on?
I'm afraid I can't reproduce this. I've updated to r5899 (actually 5888
was the last revision the compiler was updated) and rebuilt everything
from scratch. gcc --version works for me and I can compile helloworld.
Are you sure that when you merge, all components have been updated?
Can you try moving your existing installation, i.e. !GCC & !SharedLibs
to one side and trying with a completely clean install?
Lee.
_______________________________________________
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
Forms
Hi,
I spent a fairly heroic time period this weekend hacking on the various form
related elements in libdom and doing a preliminary binding to them in the
libdom_binding.c file in NetSurf.
My work on libdom is now merged to master but the NetSurf work is still sat on
dsilvers/form-work where it will remain until I have at least rudimentary
<textarea> and <select> support.
Once that is up and running, I'll look to merge back to master before
refactoring for cleanliness code-wise.
If anyone wants to play, please feel free to do so. I'm quite pleased with the
number of level1/html tests we now pass and the dsilvers/form-work branch
actually does let me do google searches from the welcome page.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
I spent a fairly heroic time period this weekend hacking on the various form
related elements in libdom and doing a preliminary binding to them in the
libdom_binding.c file in NetSurf.
My work on libdom is now merged to master but the NetSurf work is still sat on
dsilvers/form-work where it will remain until I have at least rudimentary
<textarea> and <select> support.
Once that is up and running, I'll look to merge back to master before
refactoring for cleanliness code-wise.
If anyone wants to play, please feel free to do so. I'm quite pleased with the
number of level1/html tests we now pass and the dsilvers/form-work branch
actually does let me do google searches from the welcome page.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Re: TTF2F download link incorrect
In article <4FFA8903.5090905@druck.org.uk>,
David J. Ruck <druck@druck.org.uk> wrote:
> > Anyhow, bear in mind that the current version of TTF2f will freeze
> > the machine when used with very large fonts on RISC OS 5.16 and
> > beyond.
> It's an excessively long period of single tasking, as opposed to a
> freeze, which to me at least means it doesn't come back again.
No, it's a real freeze.
The same font on my VRPC is processed in minutes, while my considerably
faster Iyonix always freezes at the same point. According to other peoples
experience, I am certainly not the only one.
> I re-discovered this the other week when running up NetSurf after
> cleaning !Scrap as part of performing a backup. My fonts include ArialMS
> and Cyberbit, both of which take about 30 seconds to even display 1%
> complete.
But that's about the compilation of NetSurfs glyphs collection, which is a
completely different matter. NetSurf needs quite some time indeed for
examining large unicode fonts, but as far as I remember (I stopped deleting
that cache for the same reason), it is multi-tasking and it certainly works
on all versions of RISC OS 5.xx until now.
Anyhow, TTF2f is an extremely valuable tool, but currently it fails when
used on an Iyonix with very large fonts.
Kind regards,
Paul Sprangers
David J. Ruck <druck@druck.org.uk> wrote:
> > Anyhow, bear in mind that the current version of TTF2f will freeze
> > the machine when used with very large fonts on RISC OS 5.16 and
> > beyond.
> It's an excessively long period of single tasking, as opposed to a
> freeze, which to me at least means it doesn't come back again.
No, it's a real freeze.
The same font on my VRPC is processed in minutes, while my considerably
faster Iyonix always freezes at the same point. According to other peoples
experience, I am certainly not the only one.
> I re-discovered this the other week when running up NetSurf after
> cleaning !Scrap as part of performing a backup. My fonts include ArialMS
> and Cyberbit, both of which take about 30 seconds to even display 1%
> complete.
But that's about the compilation of NetSurfs glyphs collection, which is a
completely different matter. NetSurf needs quite some time indeed for
examining large unicode fonts, but as far as I remember (I stopped deleting
that cache for the same reason), it is multi-tasking and it certainly works
on all versions of RISC OS 5.xx until now.
Anyhow, TTF2f is an extremely valuable tool, but currently it fails when
used on an Iyonix with very large fonts.
Kind regards,
Paul Sprangers
Re: TTF2F download link incorrect
On 07/07/2012 11:51, Paul Sprangers wrote:
> Anyhow, bear in mind that the current version of TTF2f will freeze
> the machine when used with very large fonts on RISC OS 5.16 and
> beyond. A short e-mail exchange between John-Mark Bell and me, about
> one year ago, hasn't yet led to a solution.
It's an excessively long period of single tasking, as opposed to a
freeze, which to me at least means it doesn't come back again.
I re-discovered this the other week when running up NetSurf after
cleaning !Scrap as part of performing a backup. My fonts include ArialMS
and Cyberbit, both of which take about 30 seconds to even display 1%
complete. I've now locked the cache file to avoid deleting it and having
to undergo the long wait again - which is longer than I actually use the
machine for in most months.
Cheers
--
David J. Ruck
email: druck@druck.org.uk
phone: +44(0)7974 108301
> Anyhow, bear in mind that the current version of TTF2f will freeze
> the machine when used with very large fonts on RISC OS 5.16 and
> beyond. A short e-mail exchange between John-Mark Bell and me, about
> one year ago, hasn't yet led to a solution.
It's an excessively long period of single tasking, as opposed to a
freeze, which to me at least means it doesn't come back again.
I re-discovered this the other week when running up NetSurf after
cleaning !Scrap as part of performing a backup. My fonts include ArialMS
and Cyberbit, both of which take about 30 seconds to even display 1%
complete. I've now locked the cache file to avoid deleting it and having
to undergo the long wait again - which is longer than I actually use the
machine for in most months.
Cheers
--
David J. Ruck
email: druck@druck.org.uk
phone: +44(0)7974 108301
Sunday, 8 July 2012
Re: JavaScript
On 8 Jul 2012 21:06:17 +0100, Chris Young wrote:
> Have I missed something, or is this callback really not getting set?
Oh, I have missed something... sorted now.
Chris
> Have I missed something, or is this callback really not getting set?
Oh, I have missed something... sorted now.
Chris
Re: JavaScript
On 7 Jul 2012 22:31:06 +0100, Chris Young wrote:
> My suspicion is libdom purely because everything was working before
> the libdom binding changes, and that's the only library which has
> changed significantly.
Right, I've figured out why it is crashing - the complete_script
callback is still NULL when hubbub is supposed to call it. As the
binding between libdom and hubbub doesn't pass this callback to
hubbub, and doesn't poke it in manually either (as far as I can see),
I'm not surprised it isn't working (I am however, surprised that
Vince seems to be ok!)
Have I missed something, or is this callback really not getting set?
Chris
> My suspicion is libdom purely because everything was working before
> the libdom binding changes, and that's the only library which has
> changed significantly.
Right, I've figured out why it is crashing - the complete_script
callback is still NULL when hubbub is supposed to call it. As the
binding between libdom and hubbub doesn't pass this callback to
hubbub, and doesn't poke it in manually either (as far as I can see),
I'm not surprised it isn't working (I am however, surprised that
Vince seems to be ok!)
Have I missed something, or is this callback really not getting set?
Chris
Re: [gccsdk] Something wrong with SOManager?
I wrote:
> I seem to be having trouble with running ELF stuff with a freshly
> build (rev 5888).
Sorry, that should be rev 5899. And it was the native compiler I
was referring to...
Cheers,
Jan-Jaap
_______________________________________________
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
> I seem to be having trouble with running ELF stuff with a freshly
> build (rev 5888).
Sorry, that should be rev 5899. And it was the native compiler I
was referring to...
Cheers,
Jan-Jaap
_______________________________________________
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] Something wrong with SOManager?
I seem to be having trouble with running ELF stuff with a freshly
build (rev 5888).
I've build the native compiler and merged the system with the newly
build modules. I've also restarted after that, so it should not be
any old modules still in memory.
This is what I am seeing:
*gcc --version
Internal error: abort on data transfer at &7F11F46C
*rmkill somanager
There are still clients using SOManager.
*somallowquit
*rmkill somanager
*| old version, build 1. May 2012
*ADFS::HardDisc4.$.Projects.Kits.gccsdk-gcc-bin-4/6/4-Rel1dev/zip.!SharedLibs
*gcc --version
gcc (GCCSDK GCC 4.7.2 Release 1 Development) 4.7.2 20120707 (prerelease) [gcc-4_7-branch revision 189349]
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*help somanager
==> Help on keyword SOManager
Module is: Shared Object Manager 2.10 (01 May 2012) (c) GCCSDK Developers
Commands provided:
SOMStatus SOMAddress SOMExpire SOMAllowQuit SOMRun
SOMHistory
*rmkill somanager
*ADFS::HardDisc4.$.Projects.!SharedLibs
*gcc --version
Internal error: abort on data transfer at &7F11F46C
*help somanager
==> Help on keyword SOManager
Module is: Shared Object Manager 2.10 (07 Jul 2012) (c) GCCSDK Developers
Commands provided:
SOMStatus SOMAddress SOMExpire SOMAllowQuit SOMRun
SOMHistory
Any ideas what is going on?
It seems to affect everything with the filetype ELF.
Cheers,
Jan-Jaap
_______________________________________________
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
build (rev 5888).
I've build the native compiler and merged the system with the newly
build modules. I've also restarted after that, so it should not be
any old modules still in memory.
This is what I am seeing:
*gcc --version
Internal error: abort on data transfer at &7F11F46C
*rmkill somanager
There are still clients using SOManager.
*somallowquit
*rmkill somanager
*| old version, build 1. May 2012
*ADFS::HardDisc4.$.Projects.Kits.gccsdk-gcc-bin-4/6/4-Rel1dev/zip.!SharedLibs
*gcc --version
gcc (GCCSDK GCC 4.7.2 Release 1 Development) 4.7.2 20120707 (prerelease) [gcc-4_7-branch revision 189349]
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*help somanager
==> Help on keyword SOManager
Module is: Shared Object Manager 2.10 (01 May 2012) (c) GCCSDK Developers
Commands provided:
SOMStatus SOMAddress SOMExpire SOMAllowQuit SOMRun
SOMHistory
*rmkill somanager
*ADFS::HardDisc4.$.Projects.!SharedLibs
*gcc --version
Internal error: abort on data transfer at &7F11F46C
*help somanager
==> Help on keyword SOManager
Module is: Shared Object Manager 2.10 (07 Jul 2012) (c) GCCSDK Developers
Commands provided:
SOMStatus SOMAddress SOMExpire SOMAllowQuit SOMRun
SOMHistory
Any ideas what is going on?
It seems to affect everything with the filetype ELF.
Cheers,
Jan-Jaap
_______________________________________________
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: [Rpcemu] RPCEmu freeze when using TW
In article <op.wg36jzl8rs0ygh@phenom>, Terry Duell <tduell@iinet.net.au>
wrote:
> On Tue, 03 Jul 2012 11:46:01 +1000, Terry Duell <tduell@iinet.net.au>
> wrote:
> > Hello All, I have experienced some lockup/freeze of RPCEmu just
> > recently, whilst running TechWriter 9.01.
> [snip]
> Had another lockup today. This time I was running RPCEmu with debug
> enabled, but the rpclog.txt doesn't show up anything different to what
> it says for a good session. Does anyone have any ideas?
What happens to the value for cpu use at the top of the RPCEmu window? I'm
wondering if this is related to the 'freeze' I get at shutdown. There the
cpu use goes high and stays high even though the emulation seems to freeze.
Slainte,
Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
wrote:
> On Tue, 03 Jul 2012 11:46:01 +1000, Terry Duell <tduell@iinet.net.au>
> wrote:
> > Hello All, I have experienced some lockup/freeze of RPCEmu just
> > recently, whilst running TechWriter 9.01.
> [snip]
> Had another lockup today. This time I was running RPCEmu with debug
> enabled, but the rpclog.txt doesn't show up anything different to what
> it says for a good session. Does anyone have any ideas?
What happens to the value for cpu use at the top of the RPCEmu window? I'm
wondering if this is related to the 'freeze' I get at shutdown. There the
cpu use goes high and stays high even though the emulation seems to freeze.
Slainte,
Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Saturday, 7 July 2012
Re: [Rpcemu] RPCEmu freeze when using TW
On Tue, 03 Jul 2012 11:46:01 +1000, Terry Duell <tduell@iinet.net.au>
wrote:
> Hello All,
> I have experienced some lockup/freeze of RPCEmu just recently, whilst
> running TechWriter 9.01.
[snip]
Had another lockup today. This time I was running RPCEmu with debug
enabled, but the rpclog.txt doesn't show up anything different to what it
says for a good session.
Does anyone have any ideas?
Cheers,
--
Regards,
Terry Duell
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
wrote:
> Hello All,
> I have experienced some lockup/freeze of RPCEmu just recently, whilst
> running TechWriter 9.01.
[snip]
Had another lockup today. This time I was running RPCEmu with debug
enabled, but the rpclog.txt doesn't show up anything different to what it
says for a good session.
Does anyone have any ideas?
Cheers,
--
Regards,
Terry Duell
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: JavaScript
On Sat, 7 Jul 2012 18:17:12 +0200, m0n0 wrote:
> I have no problems with version 1.7 - no crashes or such.
> Are you using my spidermonkey-1.7 branch? It's not in sync with
> the master so you need pull in commits of the master.
I'm using master with the missing macros in my Spidermonkey jsapi.h.
I've just tried your branch, and although it doesn't crash it is
complaining with this error on my simple test:
(14.417069) javascript/jsapi.c js_reportError 59: <head>:1:ReferenceError: alert is not defined
This was working a while back with 1.50, however as you state, your
branch is out of sync, and libdom has had some changes (which I think
is what is causing my crash and is probably also responsible for
alert() now not working with the older code - although I haven't yet
tried linking back with 1.50)
If I sync to master I think it will start crashing again.
It's definitely something to do with Javascript. If I disable
Javascript in Choices it stops the crash. All my libraries are
up-to-date (I have double and triple checked this and rebuilt them
all). I think the stack trace might be a red herring as it is
following through parse_chunk, which I don't think has changed and I
find it very unlikely this has suddenly decided to attempt to jump to
a NULL address. It's possible that memory is getting corrupted which
is then causing NetSurf to fall over.
My suspicion is libdom purely because everything was working before
the libdom binding changes, and that's the only library which has
changed significantly.
Chris
> I have no problems with version 1.7 - no crashes or such.
> Are you using my spidermonkey-1.7 branch? It's not in sync with
> the master so you need pull in commits of the master.
I'm using master with the missing macros in my Spidermonkey jsapi.h.
I've just tried your branch, and although it doesn't crash it is
complaining with this error on my simple test:
(14.417069) javascript/jsapi.c js_reportError 59: <head>:1:ReferenceError: alert is not defined
This was working a while back with 1.50, however as you state, your
branch is out of sync, and libdom has had some changes (which I think
is what is causing my crash and is probably also responsible for
alert() now not working with the older code - although I haven't yet
tried linking back with 1.50)
If I sync to master I think it will start crashing again.
It's definitely something to do with Javascript. If I disable
Javascript in Choices it stops the crash. All my libraries are
up-to-date (I have double and triple checked this and rebuilt them
all). I think the stack trace might be a red herring as it is
following through parse_chunk, which I don't think has changed and I
find it very unlikely this has suddenly decided to attempt to jump to
a NULL address. It's possible that memory is getting corrupted which
is then causing NetSurf to fall over.
My suspicion is libdom purely because everything was working before
the libdom binding changes, and that's the only library which has
changed significantly.
Chris
Re: JavaScript
On Sat, Jul 07, 2012 at 06:17:12PM +0200, m0n0 wrote:
> This will ease the "maintainers" of the spidermonkey-1.7-support
> tree to track new commits. Otherwise the diffs will get
> larger and larger...
> If there is really now way to integrate the branch "soon",
> then it looks like we have (the need for) an fork,
> and I don't know if I want to care about such fork,
> because it means to pull in master commits into the fork within time.
Criss-Cross merging in git is cheap and easy and I'd suggest you try it. If I
were the spidermonkey-1.7 branch maintainer I would be regularly merging master
into my branch (or rebasing my branch on top of new master) so that I could
test against changes made in master and ensure that my patches apply cleanly.
Otherwise when it comes to merging to master, the maintainer of that section
(Vincent) will find it hard to merge the code and thus will be less likely to
take it.
It is the job of the branch owner to make sure their branch is mergeable with
master if they actively expect it to be merged.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> This will ease the "maintainers" of the spidermonkey-1.7-support
> tree to track new commits. Otherwise the diffs will get
> larger and larger...
> If there is really now way to integrate the branch "soon",
> then it looks like we have (the need for) an fork,
> and I don't know if I want to care about such fork,
> because it means to pull in master commits into the fork within time.
Criss-Cross merging in git is cheap and easy and I'd suggest you try it. If I
were the spidermonkey-1.7 branch maintainer I would be regularly merging master
into my branch (or rebasing my branch on top of new master) so that I could
test against changes made in master and ensure that my patches apply cleanly.
Otherwise when it comes to merging to master, the maintainer of that section
(Vincent) will find it hard to merge the code and thus will be less likely to
take it.
It is the job of the branch owner to make sure their branch is mergeable with
master if they actively expect it to be merged.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Re: JavaScript
>> I have not yet merged any of the pre 1.8.0 version jsapi.h macro
>> changes as I beleive as I continue to add functionality I will be
>> breaking them :-/
I have no problems with version 1.7 - no crashes or such.
Are you using my spidermonkey-1.7 branch? It's not in sync with
the master so you need pull in commits of the master.
AFAIK JS_VERSION isn't defined by any of the jsapi <= 1.7 includes.
spidermonkey >= 1.8 defines JSVERSION_LATEST, which is probably
used to define JS_VERSION.
With spidermonkey <= 1.7 you have to define JS_VERSION in the
OS_CONFIG file. I don't know if these flags are saved in some header
file. I pass JS_VERSION manually to programs that get linked against
libsjs and need the macro.
About the missing merges:
personally I would vote for merging the changes as soon as possible
into master.
This will ease the "maintainers" of the spidermonkey-1.7-support
tree to track new commits. Otherwise the diffs will get
larger and larger...
If there is really now way to integrate the branch "soon",
then it looks like we have (the need for) an fork,
and I don't know if I want to care about such fork,
because it means to pull in master commits into the fork within time.
Personally I don't think it's a good idea that the branches will drift
away from each other....
Greets,
Ole
>> changes as I beleive as I continue to add functionality I will be
>> breaking them :-/
I have no problems with version 1.7 - no crashes or such.
Are you using my spidermonkey-1.7 branch? It's not in sync with
the master so you need pull in commits of the master.
AFAIK JS_VERSION isn't defined by any of the jsapi <= 1.7 includes.
spidermonkey >= 1.8 defines JSVERSION_LATEST, which is probably
used to define JS_VERSION.
With spidermonkey <= 1.7 you have to define JS_VERSION in the
OS_CONFIG file. I don't know if these flags are saved in some header
file. I pass JS_VERSION manually to programs that get linked against
libsjs and need the macro.
About the missing merges:
personally I would vote for merging the changes as soon as possible
into master.
This will ease the "maintainers" of the spidermonkey-1.7-support
tree to track new commits. Otherwise the diffs will get
larger and larger...
If there is really now way to integrate the branch "soon",
then it looks like we have (the need for) an fork,
and I don't know if I want to care about such fork,
because it means to pull in master commits into the fork within time.
Personally I don't think it's a good idea that the branches will drift
away from each other....
Greets,
Ole
Re: JavaScript
On Sat, 7 Jul 2012 10:36:06 +0100, Vincent Sanders wrote:
> From a recent commit looks like you moved up to 1.7.
I had a bit of time and it didn't take anywhere near as long as I was
expecting. This should make things easier with me and Ole using the
same version.
> Just a quick
> query, does 1.7 not include jsversion.h when you pull in mozjs/js.h
> because you seem to be overriding JS_VERSION and if teh library sets
> it for you that would seem counterproductive.
It's there, but when I was using 1.5 I found that it was ignoring the
JS_VERSION <= 180 #ifdefs unless I also put it in manually. I haven't
actually checked whether this is still necessary.
> I have not yet merged any of the pre 1.8.0 version jsapi.h macro
> changes as I beleive as I continue to add functionality I will be
> breaking them :-/
Probably sensible!
The following will need fixing:
JS_THIS_OBJECT calls JS_ComputeThis() which doesn't exist in 1.7. Not
sure what the solution to this is, it might involve passing our
JSObject pointer around in JAPI_NATIVE.
In the same revision, hubbub/libdom/NetSurf (not sure which - hubbub
is the last point on the stack trace, but before I started trying to
fix it I was getting an extra libdom call after it) is running
off into NULL pointer territory if Javascript is enabled (with my
homepage as http://www.google.co.uk). It might just be I've missed
something when updating the libraries and recompiling them (I'm having
to update them manually as I don't have a native Git client - which is
an utter PITA - and cross-compiling the libraries didn't work when I
tried it) or it might be something the script on www.google.co.uk is
doing. I'll try a different start page, forgot to do that before.
> As an observation I do not have easy development
> acess to library version other than 1.8.0 and 1.8.5
Ole seems to be on top of fixing it up to work on 1.7 (and clearly
knows much more about Spidermonkey than me - which isn't hard tbh).
We can both test it so it's not a major problem if you can't.
> Hope some of this helps.
Yes, thanks.
Chris
> From a recent commit looks like you moved up to 1.7.
I had a bit of time and it didn't take anywhere near as long as I was
expecting. This should make things easier with me and Ole using the
same version.
> Just a quick
> query, does 1.7 not include jsversion.h when you pull in mozjs/js.h
> because you seem to be overriding JS_VERSION and if teh library sets
> it for you that would seem counterproductive.
It's there, but when I was using 1.5 I found that it was ignoring the
JS_VERSION <= 180 #ifdefs unless I also put it in manually. I haven't
actually checked whether this is still necessary.
> I have not yet merged any of the pre 1.8.0 version jsapi.h macro
> changes as I beleive as I continue to add functionality I will be
> breaking them :-/
Probably sensible!
The following will need fixing:
JS_THIS_OBJECT calls JS_ComputeThis() which doesn't exist in 1.7. Not
sure what the solution to this is, it might involve passing our
JSObject pointer around in JAPI_NATIVE.
In the same revision, hubbub/libdom/NetSurf (not sure which - hubbub
is the last point on the stack trace, but before I started trying to
fix it I was getting an extra libdom call after it) is running
off into NULL pointer territory if Javascript is enabled (with my
homepage as http://www.google.co.uk). It might just be I've missed
something when updating the libraries and recompiling them (I'm having
to update them manually as I don't have a native Git client - which is
an utter PITA - and cross-compiling the libraries didn't work when I
tried it) or it might be something the script on www.google.co.uk is
doing. I'll try a different start page, forgot to do that before.
> As an observation I do not have easy development
> acess to library version other than 1.8.0 and 1.8.5
Ole seems to be on top of fixing it up to work on 1.7 (and clearly
knows much more about Spidermonkey than me - which isn't hard tbh).
We can both test it so it's not a major problem if you can't.
> Hope some of this helps.
Yes, thanks.
Chris
Re: TTF2F download link incorrect
In article <825647ab52.martin@blueyonder.co.uk>,
Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
> The download link on this page:
> http://www.netsurf-browser.org/projects/ttf2f/
> Leads to this:
> http://download.netsurf-browser.org/other/ttf2f/downloads/ttf2f-004.zip
> Which doesn't exist.
Strange, not here (NS 2.9, RO 5.18)
Anyhow, bear in mind that the current version of TTF2f will freeze the
machine when used with very large fonts on RISC OS 5.16 and beyond.
A short e-mail exchange between John-Mark Bell and me, about one year ago,
hasn't yet led to a solution.
Kind regards,
Paul Sprangers
Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
> The download link on this page:
> http://www.netsurf-browser.org/projects/ttf2f/
> Leads to this:
> http://download.netsurf-browser.org/other/ttf2f/downloads/ttf2f-004.zip
> Which doesn't exist.
Strange, not here (NS 2.9, RO 5.18)
Anyhow, bear in mind that the current version of TTF2f will freeze the
machine when used with very large fonts on RISC OS 5.16 and beyond.
A short e-mail exchange between John-Mark Bell and me, about one year ago,
hasn't yet led to a solution.
Kind regards,
Paul Sprangers
Re: JavaScript
<snip>
> > So, finally I want to suggest that you also try to compile 1.7, it
> > would be better if we both
> > use the same "old" version. 1.7 should be easy to port. At least as
> > easy as 1.5. Then
> > we don't have to figure out difference between 1.5 and 1.7...
>
> I'll give it a try when I get time - might not be for a couple of
> weeks though. Unfortunately it wasn't me who ported 1.5 so I'm not
> exactly wure what was changed to get it to work.
>From a recent commit looks like you moved up to 1.7. Just a quick
query, does 1.7 not include jsversion.h when you pull in mozjs/js.h
because you seem to be overriding JS_VERSION and if teh library sets
it for you that would seem counterproductive.
I have not yet merged any of the pre 1.8.0 version jsapi.h macro
changes as I beleive as I continue to add functionality I will be
breaking them :-/ As an observation I do not have easy development
acess to library version other than 1.8.0 and 1.8.5
And just in case you had not twigged what the mozilla guys were up to,
basically the method calls have been altered 1.7 -> 1.8.0 -> 1.8.5 to
make them consistant in signature with the property callbacks.
To do this they introduced the JS_* macros but certianly in 1.8.0
these appear to not work properly for native calls which is why i
introduced our own JSAPI wrappers which attempt to use macro magic to
make the netsurf jsapi code version agnoisic.
Hope some of this helps.
--
Regards Vincent
http://www.kyllikki.org/
> > So, finally I want to suggest that you also try to compile 1.7, it
> > would be better if we both
> > use the same "old" version. 1.7 should be easy to port. At least as
> > easy as 1.5. Then
> > we don't have to figure out difference between 1.5 and 1.7...
>
> I'll give it a try when I get time - might not be for a couple of
> weeks though. Unfortunately it wasn't me who ported 1.5 so I'm not
> exactly wure what was changed to get it to work.
>From a recent commit looks like you moved up to 1.7. Just a quick
query, does 1.7 not include jsversion.h when you pull in mozjs/js.h
because you seem to be overriding JS_VERSION and if teh library sets
it for you that would seem counterproductive.
I have not yet merged any of the pre 1.8.0 version jsapi.h macro
changes as I beleive as I continue to add functionality I will be
breaking them :-/ As an observation I do not have easy development
acess to library version other than 1.8.0 and 1.8.5
And just in case you had not twigged what the mozilla guys were up to,
basically the method calls have been altered 1.7 -> 1.8.0 -> 1.8.5 to
make them consistant in signature with the property callbacks.
To do this they introduced the JS_* macros but certianly in 1.8.0
these appear to not work properly for native calls which is why i
introduced our own JSAPI wrappers which attempt to use macro magic to
make the netsurf jsapi code version agnoisic.
Hope some of this helps.
--
Regards Vincent
http://www.kyllikki.org/
Friday, 6 July 2012
TTF2F download link incorrect
The download link on this page:
http://www.netsurf-browser.org/projects/ttf2f/
Leads to this:
http://download.netsurf-browser.org/other/ttf2f/downloads/ttf2f-004.zip
Which doesn't exist.
Through experimentation, the correct URL appears to be this:
http://download.netsurf-browser.org/other/ttf2f/ttf2f-004.zip
--
__<^>__
/ _ _ \ You always find something in the last place you look.
( ( |_| ) )
\_> <_/ ======================= Martin Bazley ==========================
http://www.netsurf-browser.org/projects/ttf2f/
Leads to this:
http://download.netsurf-browser.org/other/ttf2f/downloads/ttf2f-004.zip
Which doesn't exist.
Through experimentation, the correct URL appears to be this:
http://download.netsurf-browser.org/other/ttf2f/ttf2f-004.zip
--
__<^>__
/ _ _ \ You always find something in the last place you look.
( ( |_| ) )
\_> <_/ ======================= Martin Bazley ==========================
Thursday, 5 July 2012
Re: [gccsdk] Nettle autobuilder patch
In message <52aa6f87d1chrisg@care4free.net>
Chris Gransden <chrisg@care4free.net> wrote:
> In article <ce136eaa52.beeb@ron1954.woosh.co.nz>,
> Ron <beeb@woosh.co.nz> wrote:
>
> > I am sort of confused, I thought everything was to be built as e1f
> > now.
> > Is it just that EXT_EXE is mistakenly being set to ff8 somewhere?
>
> > I built libcurl3 successfully but it accessed the unfinished bzip2
> > directory source files to do it.
> > It did look for Bzip2 several times.
>
> It could be you haven't got 'AB_ELFBUILD=yes' in your 'build-setvars' file.
>
> Chris.
>
Of course, we changed that to build Nettle some time ago.
It was actually the 'export AB_ELFBUILD=no' that was set in the 'build'
script.
That should fix things, Thanks, I'd forgotten about that.
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
Chris Gransden <chrisg@care4free.net> wrote:
> In article <ce136eaa52.beeb@ron1954.woosh.co.nz>,
> Ron <beeb@woosh.co.nz> wrote:
>
> > I am sort of confused, I thought everything was to be built as e1f
> > now.
> > Is it just that EXT_EXE is mistakenly being set to ff8 somewhere?
>
> > I built libcurl3 successfully but it accessed the unfinished bzip2
> > directory source files to do it.
> > It did look for Bzip2 several times.
>
> It could be you haven't got 'AB_ELFBUILD=yes' in your 'build-setvars' file.
>
> Chris.
>
Of course, we changed that to build Nettle some time ago.
It was actually the 'export AB_ELFBUILD=no' that was set in the 'build'
script.
That should fix things, Thanks, I'd forgotten about that.
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] Nettle autobuilder patch
In article <ce136eaa52.beeb@ron1954.woosh.co.nz>,
Ron <beeb@woosh.co.nz> wrote:
> I am sort of confused, I thought everything was to be built as e1f
> now.
> Is it just that EXT_EXE is mistakenly being set to ff8 somewhere?
> I built libcurl3 successfully but it accessed the unfinished bzip2
> directory source files to do it.
> It did look for Bzip2 several times.
It could be you haven't got 'AB_ELFBUILD=yes' in your 'build-setvars' file.
Chris.
--
Email: chrisg@care4free.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
Ron <beeb@woosh.co.nz> wrote:
> I am sort of confused, I thought everything was to be built as e1f
> now.
> Is it just that EXT_EXE is mistakenly being set to ff8 somewhere?
> I built libcurl3 successfully but it accessed the unfinished bzip2
> directory source files to do it.
> It did look for Bzip2 several times.
It could be you haven't got 'AB_ELFBUILD=yes' in your 'build-setvars' file.
Chris.
--
Email: chrisg@care4free.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] Nettle autobuilder patch
In message <20120703092216.GB310@chiark.greenend.org.uk>
Theo Markettos <theo@markettos.org.uk> wrote:
> On Tue, Jul 03, 2012 at 06:29:38PM +1200, Ron wrote:
> > I have just tryed building the Nettle package a second time, to see
> > if it would put its packages in the correct place, but I get updates
> > then patch errors.
> > I will try to attach the failure to this post
>
> Hi Ron,
>
> Are you running this on a nettle build tree that the autobuilder already
> downloaded (ie used ./build -d where it retains the tree afterwards)? It's
> very important that you delete the tree - autobuilder/nettle - beforehand,
> because otherwise patching will fail (the tree has already been patched).
OK, I just removed all the existing Nettle directories, and did svn update.
Nettle built and installed its packages in the right place, alongside the
Socketwatch packages.
There is one inconsistancy, Now that you are linking zlib, you need to
have zlib1g in the Nettle depends file.
I have found some problems when the autobuilder builds wget.
Bzip2 builds absolute binaries and fails to stat when copying.
Tar1.26 builds e1f binaries but fails with
cannot stat '/home/ron/gccsdk/autobuilder/tar/tar-1.26/src/*,ff8'
I am sort of confused, I thought everything was to be built as e1f
now.
Is it just that EXT_EXE is mistakenly being set to ff8 somewhere?
I built libcurl3 successfully but it accessed the unfinished bzip2
directory source files to do it.
It did look for Bzip2 several times.
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
Theo Markettos <theo@markettos.org.uk> wrote:
> On Tue, Jul 03, 2012 at 06:29:38PM +1200, Ron wrote:
> > I have just tryed building the Nettle package a second time, to see
> > if it would put its packages in the correct place, but I get updates
> > then patch errors.
> > I will try to attach the failure to this post
>
> Hi Ron,
>
> Are you running this on a nettle build tree that the autobuilder already
> downloaded (ie used ./build -d where it retains the tree afterwards)? It's
> very important that you delete the tree - autobuilder/nettle - beforehand,
> because otherwise patching will fail (the tree has already been patched).
OK, I just removed all the existing Nettle directories, and did svn update.
Nettle built and installed its packages in the right place, alongside the
Socketwatch packages.
There is one inconsistancy, Now that you are linking zlib, you need to
have zlib1g in the Nettle depends file.
I have found some problems when the autobuilder builds wget.
Bzip2 builds absolute binaries and fails to stat when copying.
Tar1.26 builds e1f binaries but fails with
cannot stat '/home/ron/gccsdk/autobuilder/tar/tar-1.26/src/*,ff8'
I am sort of confused, I thought everything was to be built as e1f
now.
Is it just that EXT_EXE is mistakenly being set to ff8 somewhere?
I built libcurl3 successfully but it accessed the unfinished bzip2
directory source files to do it.
It did look for Bzip2 several times.
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
Wednesday, 4 July 2012
Re: zero-width dropdown menu on Zamzar site
Michael Drake wrote on 3 Jul:
> Needs JavaScript to present the options:
Ah, thanks. I failed to suspect Javascript was lurking.
Well, I see that Zamzar also offers to receive a file as an email
attachment, for conversion to another format. At least THAT should
work for RiscOS users, albeit max filesize is a megabyte.
--
Jim Nagel www.archivemag.co.uk
>> before emailing large files (>1Mb), please ask me for FTP details
See you at Kenilworth? http://mug.riscos.org/show12 July 7
> Needs JavaScript to present the options:
Ah, thanks. I failed to suspect Javascript was lurking.
Well, I see that Zamzar also offers to receive a file as an email
attachment, for conversion to another format. At least THAT should
work for RiscOS users, albeit max filesize is a megabyte.
--
Jim Nagel www.archivemag.co.uk
>> before emailing large files (>1Mb), please ask me for FTP details
See you at Kenilworth? http://mug.riscos.org/show12 July 7
Re: JavaScript
On Wed, 04 Jul 2012 01:23:04 +0200, Ole wrote:
> The JS_FS_ etc. macros were already in my patch. I guess they didn't
> made it into the repository
> because there wasn't an additional #ifdef JS_VERSION <= 170
>
> So, it's maybe worth a second try.
I'll let you handle that :)
> So, finally I want to suggest that you also try to compile 1.7, it
> would be better if we both
> use the same "old" version. 1.7 should be easy to port. At least as
> easy as 1.5. Then
> we don't have to figure out difference between 1.5 and 1.7...
I'll give it a try when I get time - might not be for a couple of
weeks though. Unfortunately it wasn't me who ported 1.5 so I'm not
exactly wure what was changed to get it to work.
> Is there anyone with big-endian and working spidermonkey 1.8 jsconsole?
> I do not have problems when running
> scripts directly, just when starting up the interactive jsconsole. It
> happens during JS_NewObjectWithPrototype.
I get a crash with my Spidermonkey 1.8.5 library, but I didn't build
the console so I haven't tried that. A newer version is included with
Timberwolf (I'm trying to get hold of the includes, but it has a lot
of dependencies so I'm not sure whether it is a good idea anyway),
that doesn't have the standalone console either, but the library
works.
I think my 1.8.5 problem is because it's trying to use JIT even though
I (tried to) disable it.
Chris
> The JS_FS_ etc. macros were already in my patch. I guess they didn't
> made it into the repository
> because there wasn't an additional #ifdef JS_VERSION <= 170
>
> So, it's maybe worth a second try.
I'll let you handle that :)
> So, finally I want to suggest that you also try to compile 1.7, it
> would be better if we both
> use the same "old" version. 1.7 should be easy to port. At least as
> easy as 1.5. Then
> we don't have to figure out difference between 1.5 and 1.7...
I'll give it a try when I get time - might not be for a couple of
weeks though. Unfortunately it wasn't me who ported 1.5 so I'm not
exactly wure what was changed to get it to work.
> Is there anyone with big-endian and working spidermonkey 1.8 jsconsole?
> I do not have problems when running
> scripts directly, just when starting up the interactive jsconsole. It
> happens during JS_NewObjectWithPrototype.
I get a crash with my Spidermonkey 1.8.5 library, but I didn't build
the console so I haven't tried that. A newer version is included with
Timberwolf (I'm trying to get hold of the includes, but it has a lot
of dependencies so I'm not sure whether it is a good idea anyway),
that doesn't have the standalone console either, but the library
works.
I think my 1.8.5 problem is because it's trying to use JIT even though
I (tried to) disable it.
Chris
Re: JavaScript
On Wed, 04 Jul 2012 01:38:49 +0200, Ole wrote:
> #define JSAPI_FS(name, nargs, flags) \
> - JS_FS(#name, jsapi_native_##name, nargs, flags, 0)
> + JS_FS(#name, jsapi_native_##name, nargs, flags)
>
> That should probably extended into something like that:
>
> #ifdef JS_VERSION <= 150
> JS_FS(#name, jsapi_native_##name, nargs, flags, 0)
> #else
> JS_FS(#name, jsapi_native_##name, nargs, flags)
>
> ( it looks like that 1.5 uses the same number of initial values
> as versions > 1.8.0 )
Actually that's one of the macros that doesn't exist. I copied it
from my 1.8.5 includes, so that'll be why!
Chris
> #define JSAPI_FS(name, nargs, flags) \
> - JS_FS(#name, jsapi_native_##name, nargs, flags, 0)
> + JS_FS(#name, jsapi_native_##name, nargs, flags)
>
> That should probably extended into something like that:
>
> #ifdef JS_VERSION <= 150
> JS_FS(#name, jsapi_native_##name, nargs, flags, 0)
> #else
> JS_FS(#name, jsapi_native_##name, nargs, flags)
>
> ( it looks like that 1.5 uses the same number of initial values
> as versions > 1.8.0 )
Actually that's one of the macros that doesn't exist. I copied it
from my 1.8.5 includes, so that'll be why!
Chris
Re: JavaScript
Am Mittwoch, den 04.07.2012, 13:15 +0200 schrieb Bernd Roesch
<nospamname@gmx.de>:
> Do you think it is big endian problem then ?.maybe you ask and report
> that on spidermonkey ML.
Ok, maybe it's not just big-endian issue, but I believe it's related to
the
architecture. Could also be an alignment problem.
> I find how can compile spidermonkey 1.8 here.it work only with
> autoconf 2.13. Is this with newest
> 1.8 too ?.
> also i did not unterstand what they mean with NSPR. what NSPR is need
> ?.
First: I was talking about 1.8.0 - that's the last version with
"classic" build system.
Also, it doesn't depend on NSPR.
NSPR -> Netscape Portable Runtime. I don't like to have that
dependency. If that
will go away, maybe I get more interested in compiling 1.8.5 or such.
Greets,
Ole
<nospamname@gmx.de>:
> Do you think it is big endian problem then ?.maybe you ask and report
> that on spidermonkey ML.
Ok, maybe it's not just big-endian issue, but I believe it's related to
the
architecture. Could also be an alignment problem.
> I find how can compile spidermonkey 1.8 here.it work only with
> autoconf 2.13. Is this with newest
> 1.8 too ?.
> also i did not unterstand what they mean with NSPR. what NSPR is need
> ?.
First: I was talking about 1.8.0 - that's the last version with
"classic" build system.
Also, it doesn't depend on NSPR.
NSPR -> Netscape Portable Runtime. I don't like to have that
dependency. If that
will go away, maybe I get more interested in compiling 1.8.5 or such.
Greets,
Ole
Re: JavaScript
Hello Ole
On 03.07.12, you wrote:
>
>
> Is there anyone with big-endian and working spidermonkey 1.8 jsconsole?
> I do not have problems when running
> scripts directly, just when starting up the interactive jsconsole. It
> happens during JS_NewObjectWithPrototype.
Do you think it is big endian problem then ?.maybe you ask and report that on spidermonkey ML.
I find how can compile spidermonkey 1.8 here.it work only with autoconf 2.13. Is this with newest
1.8 too ?.
also i did not unterstand what they mean with NSPR. what NSPR is need ?.
"""""
https://developer.mozilla.org/en/Building_only_SpiderMonkey
cd js/src
autoconf-2.13
./configure
make
Note that autoconf version 2.13 is required. No later version will work. The MozillaBuild package
for Windows includes autoconf 2.13.
If this does not work correctly due to NSPR problems, see Troubleshooting NSPR.
""""
>
> Greets,
> Ole
>
>
>
Regards
On 03.07.12, you wrote:
>
>
> Is there anyone with big-endian and working spidermonkey 1.8 jsconsole?
> I do not have problems when running
> scripts directly, just when starting up the interactive jsconsole. It
> happens during JS_NewObjectWithPrototype.
Do you think it is big endian problem then ?.maybe you ask and report that on spidermonkey ML.
I find how can compile spidermonkey 1.8 here.it work only with autoconf 2.13. Is this with newest
1.8 too ?.
also i did not unterstand what they mean with NSPR. what NSPR is need ?.
"""""
https://developer.mozilla.org/en/Building_only_SpiderMonkey
cd js/src
autoconf-2.13
./configure
make
Note that autoconf version 2.13 is required. No later version will work. The MozillaBuild package
for Windows includes autoconf 2.13.
If this does not work correctly due to NSPR problems, see Troubleshooting NSPR.
""""
>
> Greets,
> Ole
>
>
>
Regards
Re: [gccsdk] Nettle autobuilder patch
In message <e29f79a952.beeb@ron1954.woosh.co.nz>
Ron <beeb@woosh.co.nz> wrote:
> In message <20120703092216.GB310@chiark.greenend.org.uk>
> Theo Markettos <theo@markettos.org.uk> wrote:
>
>
> > Probably the autobuilder should handle this better, but I'm not sure how.
> > Perhaps detect that the tree is there and move it out of the way. Or be
> > able to build a pre-patched tree - but IME this often goes wrong in other
> > ways.
> >
> > Theo
I have been thinking further on this, I think a fairly common situation
was for the autobuilder patches to be out of date with the current
downloaded source, things having moved on in the debian world.
To allow for you to edit the file (that didn't patch properly, or in this
recent case, has been previously patched) perhaps you could have a build
option -nopatch.
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
Ron <beeb@woosh.co.nz> wrote:
> In message <20120703092216.GB310@chiark.greenend.org.uk>
> Theo Markettos <theo@markettos.org.uk> wrote:
>
>
> > Probably the autobuilder should handle this better, but I'm not sure how.
> > Perhaps detect that the tree is there and move it out of the way. Or be
> > able to build a pre-patched tree - but IME this often goes wrong in other
> > ways.
> >
> > Theo
I have been thinking further on this, I think a fairly common situation
was for the autobuilder patches to be out of date with the current
downloaded source, things having moved on in the debian world.
To allow for you to edit the file (that didn't patch properly, or in this
recent case, has been previously patched) perhaps you could have a build
option -nopatch.
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
Tuesday, 3 July 2012
Re: [Rpcemu] RPCEmu freeze when using TW
Hello All,
Some more news on the lockup problem.
On Tue, 03 Jul 2012 11:46:01 +1000, Terry Duell <tduell@iinet.net.au>
wrote:
> I think the first thing I will try is to move/copy the files from the
> fedora host dir to a native dir and see how that works...but as there
> hasn't been any trouble until today, that won't necessarily prove much
> unless the problem persists.
I had the lockup occur today whilst working with TW on a file on hd4.
Everything stops.
I ran the Fedora system monitor and it said rpcemu was 'sleeping'.
I'm not sure if this reveals anything useful, but the process properties
said 'Waiting Channel Poll_schedule_timeout'.
Any help in sorting this out will be greatly appreciated. It is now
impinging on useful work.
Cheers,
--
Regards,
Terry Duell
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Some more news on the lockup problem.
On Tue, 03 Jul 2012 11:46:01 +1000, Terry Duell <tduell@iinet.net.au>
wrote:
> I think the first thing I will try is to move/copy the files from the
> fedora host dir to a native dir and see how that works...but as there
> hasn't been any trouble until today, that won't necessarily prove much
> unless the problem persists.
I had the lockup occur today whilst working with TW on a file on hd4.
Everything stops.
I ran the Fedora system monitor and it said rpcemu was 'sleeping'.
I'm not sure if this reveals anything useful, but the process properties
said 'Waiting Channel Poll_schedule_timeout'.
Any help in sorting this out will be greatly appreciated. It is now
impinging on useful work.
Cheers,
--
Regards,
Terry Duell
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: JavaScript
Am Dienstag, den 03.07.2012, 20:16 +0200 schrieb "Chris Young"
<chris.young@unsatisfactorysoftware.co.uk>:
> The others are attached. I'm not sure if my changes break later
> versions, given that I'm still testing on 1.5.
#define JSAPI_FS(name, nargs, flags) \
- JS_FS(#name, jsapi_native_##name, nargs, flags, 0)
+ JS_FS(#name, jsapi_native_##name, nargs, flags)
That should probably extended into something like that:
#ifdef JS_VERSION <= 150
JS_FS(#name, jsapi_native_##name, nargs, flags, 0)
#else
JS_FS(#name, jsapi_native_##name, nargs, flags)
( it looks like that 1.5 uses the same number of initial values
as versions > 1.8.0 )
#define JSString_to_char(injsstring, outchar, outlen) \
- txt = JS_GetStringBytes(u16_txt); \
+ txt = JS_GetStringBytes(injsstring); \
outlen = strlen(txt)
Confirmed, that part is also required for 1.8.0
Greets,
Ole
<chris.young@unsatisfactorysoftware.co.uk>:
> The others are attached. I'm not sure if my changes break later
> versions, given that I'm still testing on 1.5.
#define JSAPI_FS(name, nargs, flags) \
- JS_FS(#name, jsapi_native_##name, nargs, flags, 0)
+ JS_FS(#name, jsapi_native_##name, nargs, flags)
That should probably extended into something like that:
#ifdef JS_VERSION <= 150
JS_FS(#name, jsapi_native_##name, nargs, flags, 0)
#else
JS_FS(#name, jsapi_native_##name, nargs, flags)
( it looks like that 1.5 uses the same number of initial values
as versions > 1.8.0 )
#define JSString_to_char(injsstring, outchar, outlen) \
- txt = JS_GetStringBytes(u16_txt); \
+ txt = JS_GetStringBytes(injsstring); \
outlen = strlen(txt)
Confirmed, that part is also required for 1.8.0
Greets,
Ole
Re: JavaScript
Am Dienstag, den 03.07.2012, 20:16 +0200 schrieb "Chris Young"
<chris.young@unsatisfactorysoftware.co.uk>:
>> Vince has committed a change based on your patch.
>
> There seems to be a couple of minor problems though. One is that the
> JS_FS etc macros aren't in the NetSurf headers (I assume this is
> intentional, and they can be easily added to the Spidermonkey
> includes
> in any case)
The JS_FS_ etc. macros were already in my patch. I guess they didn't
made it into the repository
because there wasn't an additional #ifdef JS_VERSION <= 170
So, it's maybe worth a second try.
However, today I tried to build js-1.8 ( all I had found was an rc ).
1.8 is still the same
build system like 1.7, 1.4 etc. so porting it should be absolutely
straight.
The 1,8 rc js-console sadly crashes with an failing assert - this
doesn't happen when build under linux.
So, I still have to stick to js 1.7, except there is an 1.8 release
version around which fixes the bug.
I had a look at the debian squeeze iceweasel patches, but it contains a
lot of them.
So, finally I want to suggest that you also try to compile 1.7, it
would be better if we both
use the same "old" version. 1.7 should be easy to port. At least as
easy as 1.5. Then
we don't have to figure out difference between 1.5 and 1.7...
Is there anyone with big-endian and working spidermonkey 1.8 jsconsole?
I do not have problems when running
scripts directly, just when starting up the interactive jsconsole. It
happens during JS_NewObjectWithPrototype.
Greets,
Ole
<chris.young@unsatisfactorysoftware.co.uk>:
>> Vince has committed a change based on your patch.
>
> There seems to be a couple of minor problems though. One is that the
> JS_FS etc macros aren't in the NetSurf headers (I assume this is
> intentional, and they can be easily added to the Spidermonkey
> includes
> in any case)
The JS_FS_ etc. macros were already in my patch. I guess they didn't
made it into the repository
because there wasn't an additional #ifdef JS_VERSION <= 170
So, it's maybe worth a second try.
However, today I tried to build js-1.8 ( all I had found was an rc ).
1.8 is still the same
build system like 1.7, 1.4 etc. so porting it should be absolutely
straight.
The 1,8 rc js-console sadly crashes with an failing assert - this
doesn't happen when build under linux.
So, I still have to stick to js 1.7, except there is an 1.8 release
version around which fixes the bug.
I had a look at the debian squeeze iceweasel patches, but it contains a
lot of them.
So, finally I want to suggest that you also try to compile 1.7, it
would be better if we both
use the same "old" version. 1.7 should be easy to port. At least as
easy as 1.5. Then
we don't have to figure out difference between 1.5 and 1.7...
Is there anyone with big-endian and working spidermonkey 1.8 jsconsole?
I do not have problems when running
scripts directly, just when starting up the interactive jsconsole. It
happens during JS_NewObjectWithPrototype.
Greets,
Ole
Re: [Rpcemu] How to recover from bad monitor mode?
Hello Ralph,
On Tue, 03 Jul 2012 19:48:59 +1000, Ralph Corderoy <ralph@inputplus.co.uk>
wrote:
[snip]
>> OK. That puts me in a mode where all I see is what looks like a task
>> window...nothing else, no desktop. If I type 'Desktop' I get told that
>> the desktop is running.
>
> Press Enter again and on the empty line the F12 will end and you'll be
> returned to the suspended Desktop, now in its new mode.
You're absolutely right, that does it.
I don't use RISCOS as often these days and it's amazing how much one
forgets.
Many thanks for your help.
Cheers,
--
Regards,
Terry Duell
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
On Tue, 03 Jul 2012 19:48:59 +1000, Ralph Corderoy <ralph@inputplus.co.uk>
wrote:
[snip]
>> OK. That puts me in a mode where all I see is what looks like a task
>> window...nothing else, no desktop. If I type 'Desktop' I get told that
>> the desktop is running.
>
> Press Enter again and on the empty line the F12 will end and you'll be
> returned to the suspended Desktop, now in its new mode.
You're absolutely right, that does it.
I don't use RISCOS as often these days and it's amazing how much one
forgets.
Many thanks for your help.
Cheers,
--
Regards,
Terry Duell
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: zero-width dropdown menu on Zamzar site
In article <6b238ca952.jim@nails.abbeypress.net>,
Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> Step 2, however, fails. It's a dropdown menu for selecting the output
> format you want. Netsurf 2.9 displays the menu at just about zero
> width and nothing in it is visible.
Needs JavaScript to present the options:
<select name="toExtensionSel" class="bodyBig">
<script language=javascript>
for(var i=0; i<toArray.length; i++) {
if (toArray[i].indexOf ("--") != -1){
document.write("<option class='optionHeader'
value=\""+toArray[i]+"\">"+toArray[i]+"</option>");
} else {
document.write("<option
value=\""+toArray[i]+"\">"+toArray[i]+"</option>");
}
}
</script>
</select>
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> Step 2, however, fails. It's a dropdown menu for selecting the output
> format you want. Netsurf 2.9 displays the menu at just about zero
> width and nothing in it is visible.
Needs JavaScript to present the options:
<select name="toExtensionSel" class="bodyBig">
<script language=javascript>
for(var i=0; i<toArray.length; i++) {
if (toArray[i].indexOf ("--") != -1){
document.write("<option class='optionHeader'
value=\""+toArray[i]+"\">"+toArray[i]+"</option>");
} else {
document.write("<option
value=\""+toArray[i]+"\">"+toArray[i]+"</option>");
}
}
</script>
</select>
--
Michael Drake (tlsa) http://www.netsurf-browser.org/
zero-width dropdown menu on Zamzar site
Somebody has pointed me to www.zamzar.com -- a free online service
that converts files from one format to another. (Based in England.)
Step 1 looks promising: drop your file on the target. It seems to
register the RiscOS file I dropped there (but can't say for sure, of
course, till I get to Submit stage).
Step 2, however, fails. It's a dropdown menu for selecting the output
format you want. Netsurf 2.9 displays the menu at just about zero
width and nothing in it is visible.
Have reported this at bugtracker. Maybe somebody with latest build
could check whether already fixed. (I have Netsurf 2.9 on RO 4.39.)
--
Jim Nagel www.archivemag.co.uk
>> before emailing large files (>1Mb), please ask me for FTP details
See you at Kenilworth? http://mug.riscos.org/show12 July 7
that converts files from one format to another. (Based in England.)
Step 1 looks promising: drop your file on the target. It seems to
register the RiscOS file I dropped there (but can't say for sure, of
course, till I get to Submit stage).
Step 2, however, fails. It's a dropdown menu for selecting the output
format you want. Netsurf 2.9 displays the menu at just about zero
width and nothing in it is visible.
Have reported this at bugtracker. Maybe somebody with latest build
could check whether already fixed. (I have Netsurf 2.9 on RO 4.39.)
--
Jim Nagel www.archivemag.co.uk
>> before emailing large files (>1Mb), please ask me for FTP details
See you at Kenilworth? http://mug.riscos.org/show12 July 7
Merge request: add support for atari to the buildsystem.
Hello,
please merge my branch "mono/atari-support" into the buildsystem.
Weblink:
http://git.netsurf-browser.org/?p=buildsystem.git;a=shortlog;h=refs/heads/mono/atari-support
Thanks!
Greets,
Ole
please merge my branch "mono/atari-support" into the buildsystem.
Weblink:
http://git.netsurf-browser.org/?p=buildsystem.git;a=shortlog;h=refs/heads/mono/atari-support
Thanks!
Greets,
Ole
Re: [gccsdk] Nettle autobuilder patch
In message <20120703092216.GB310@chiark.greenend.org.uk>
Theo Markettos <theo@markettos.org.uk> wrote:
> On Tue, Jul 03, 2012 at 06:29:38PM +1200, Ron wrote:
> > I have just tryed building the Nettle package a second time, to see
> > if it would put its packages in the correct place, but I get updates
> > then patch errors.
> > I will try to attach the failure to this post
>
> Hi Ron,
>
> Are you running this on a nettle build tree that the autobuilder already
> downloaded (ie used ./build -d where it retains the tree afterwards)? It's
> very important that you delete the tree - autobuilder/nettle - beforehand,
> because otherwise patching will fail (the tree has already been patched).
>
Yes that is what is happening, you cant run patch twice on the same file.
I was thinking that (like a compiler) it would keep the original and
then be able to rewrite the output on the next repeat.
I possibly got this impression from rebuilding other Autobuilder projects,
but I can't be certain now.
> Probably the autobuilder should handle this better, but I'm not sure how.
> Perhaps detect that the tree is there and move it out of the way. Or be
> able to build a pre-patched tree - but IME this often goes wrong in other
> ways.
>
> Theo
I'm not well versed with the patch program, but I think generally
the Autobuilder makes it hard to tinker with source to try again,
anyway.
It is easier to get things going just using ro-config and ro-make,
in a separate source directory.
There is a lot of problems just doing that also, there seems to be
some config-guess scripts that can be made to play ball and
others that look similar, dont.
Just another area to tackle and maybe feed-back findings for changes
to ro-config perhaps.
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
Theo Markettos <theo@markettos.org.uk> wrote:
> On Tue, Jul 03, 2012 at 06:29:38PM +1200, Ron wrote:
> > I have just tryed building the Nettle package a second time, to see
> > if it would put its packages in the correct place, but I get updates
> > then patch errors.
> > I will try to attach the failure to this post
>
> Hi Ron,
>
> Are you running this on a nettle build tree that the autobuilder already
> downloaded (ie used ./build -d where it retains the tree afterwards)? It's
> very important that you delete the tree - autobuilder/nettle - beforehand,
> because otherwise patching will fail (the tree has already been patched).
>
Yes that is what is happening, you cant run patch twice on the same file.
I was thinking that (like a compiler) it would keep the original and
then be able to rewrite the output on the next repeat.
I possibly got this impression from rebuilding other Autobuilder projects,
but I can't be certain now.
> Probably the autobuilder should handle this better, but I'm not sure how.
> Perhaps detect that the tree is there and move it out of the way. Or be
> able to build a pre-patched tree - but IME this often goes wrong in other
> ways.
>
> Theo
I'm not well versed with the patch program, but I think generally
the Autobuilder makes it hard to tinker with source to try again,
anyway.
It is easier to get things going just using ro-config and ro-make,
in a separate source directory.
There is a lot of problems just doing that also, there seems to be
some config-guess scripts that can be made to play ball and
others that look similar, dont.
Just another area to tackle and maybe feed-back findings for changes
to ro-config perhaps.
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: [Rpcemu] How to recover from bad monitor mode?
Hi Terry,
> > 2) Wait till you're in the 'desktop' (or best guess when that it).
> > hit F12 and blindtype 'wimpmode 28' (without quotes) and hit enter.
> > This should put you back into 640x480, and then poke around in !Boot
> > to change which mode is used.
>
> OK. That puts me in a mode where all I see is what looks like a task
> window...nothing else, no desktop. If I type 'Desktop' I get told that
> the desktop is running.
Press Enter again and on the empty line the F12 will end and you'll be
returned to the suspended Desktop, now in its new mode.
Cheers, Ralph.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> > 2) Wait till you're in the 'desktop' (or best guess when that it).
> > hit F12 and blindtype 'wimpmode 28' (without quotes) and hit enter.
> > This should put you back into 640x480, and then poke around in !Boot
> > to change which mode is used.
>
> OK. That puts me in a mode where all I see is what looks like a task
> window...nothing else, no desktop. If I type 'Desktop' I get told that
> the desktop is running.
Press Enter again and on the empty line the F12 will end and you'll be
returned to the suspended Desktop, now in its new mode.
Cheers, Ralph.
_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [gccsdk] Nettle autobuilder patch
On Tue, Jul 03, 2012 at 06:29:38PM +1200, Ron wrote:
> I have just tryed building the Nettle package a second time, to see
> if it would put its packages in the correct place, but I get updates
> then patch errors.
> I will try to attach the failure to this post
Hi Ron,
Are you running this on a nettle build tree that the autobuilder already
downloaded (ie used ./build -d where it retains the tree afterwards)? It's
very important that you delete the tree - autobuilder/nettle - beforehand,
because otherwise patching will fail (the tree has already been patched).
Probably the autobuilder should handle this better, but I'm not sure how.
Perhaps detect that the tree is there and move it out of the way. Or be
able to build a pre-patched tree - but IME this often goes wrong in other
ways.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> I have just tryed building the Nettle package a second time, to see
> if it would put its packages in the correct place, but I get updates
> then patch errors.
> I will try to attach the failure to this post
Hi Ron,
Are you running this on a nettle build tree that the autobuilder already
downloaded (ie used ./build -d where it retains the tree afterwards)? It's
very important that you delete the tree - autobuilder/nettle - beforehand,
because otherwise patching will fail (the tree has already been patched).
Probably the autobuilder should handle this better, but I'm not sure how.
Perhaps detect that the tree is there and move it out of the way. Or be
able to build a pre-patched tree - but IME this often goes wrong in other
ways.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Subscribe to:
Posts (Atom)