Friday, 31 August 2012

[gccsdk] [Bug 243] Segfault compiling innocent looking for loop in 4.1.2 r1

http://www.riscos.info/bugzilla3/show_bug.cgi?id=243

info@sprow.co.uk changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|Segfault compiling innocent |Segfault compiling innocent
|looking for loop in 4.1.2 |looking for loop in 4.1.2
|r2 |r1

--
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] [Bug 243] New: Segfault compiling innocent looking for loop in 4.1.2 r2

http://www.riscos.info/bugzilla3/show_bug.cgi?id=243

Summary: Segfault compiling innocent looking for loop in 4.1.2
r2
Product: GCC/GCCSDK
Version: other
Platform: All
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: C compiler
AssignedTo: John.Tytgat@aaug.net
ReportedBy: info@sprow.co.uk
Estimated Hours: 0.0


Created attachment 84
--> http://www.riscos.info/bugzilla3/attachment.cgi?id=84
Output of regex.c with -E switch

Running on RISC OS 4.02 the compiler segfaults on a line with a macro which
expands to a simple for loop. I initially thought this was due to lack of
memory so dialled the wimp slot up to 28MB, but still happened.

Instead I installed on a BeagleBoard (more memory, bigger wimp slot!) but even
with 200MB slot and 200MB free it blew up.
Also tried disabling the optimiser.

The full sources are in the RISC OS Open repository
gpl/RiscOS/Tools/Sources/GNU/libgnu
the preprocessed file in question is attached. Note the repository copy has a
few conflicting definitions in "system.h" so doesn't compile out of the tin
currently.

Any known workarounds?

--
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] cross compiler building errors (under Linux)

On 29/08/12 19:37, Chris Syntichakis wrote:
> Hello,
>
> I am trying to build the crosscompiler, I followed the instructions
> from
> http://www.riscos.info/index.php/Using_GCCSDK#Using_GCCSDK_and_Autobuilder_to_cross-compile_for_RISC_OS
>
> but I am getting some errors, (pls see the attached file
> (build-cross-output.txt))
>
> I am sure I have installed all of the required packages:
>
> gcc 4.6.3 svn 1.6.17 autogen 5.12.0 bison 2.5 flex 2.5.35
>
> plus the other that listed like sed/libtool etc etc..
>
> The platform I am trying to build the CGGSDK is Linux Mint 13 x86_64
> (based on Ubuntu 12.04) I think the error "reference to `yylex'" has
> something to do with bison, but bison is already installed so maybe
> is a bug or something like this.
>
> Thank you in advance for any help/ideas

This has come up before (in fact on 27th June) and John Tytgat gave this
advice:

> Could it be that you don't have bison installed ?
>
> Otherwise, if you have installed flex after having done a failed
> build, I'm not sure whether it will rebuild sufficently as you're
> having a linker error. So do:
>
> $ rm buildstepsdir/cross-gcc-configure
>
> which will rebuild the gcc cross-compiler part from scratch (but
> still reuse your binutils, host native libraries, etc which you've
> built).
>
> John.

I see that you do have flex and bison installed, but if this was done as
a result of a failed build, then you may need to reconfigure GCC as John
says above.

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

Thursday, 30 August 2012

CSS height attribute

I found out how to get the effect I wanted both in NetSurf
and in Firefox by avoiding the "height" attribute. I put
everything inside a containing box and for the left- and
right-hand columns set the attributes "top" and "bottom" to 0.
Then their heights get sucked to that of the middle column.

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

height attribute in CSS

I have come across a difference between the way NetSurf 2.9 (on
an Iyonix) and Firefox 15 (on an XP notebook) treat the CSS
"height" attribute.
The way NetSurf does it gives the display I want, and I am trying
to figure out how to make Firefox do the same.

My webpages are to be in three columns, with the leftside and rightside
columns being narrow vertical graphics (that are links), with the content
in the middle column.

The relevant CSS contains the following:

#leftside, #rightside
{
position: absolute;
top: 0;
width: 70px;
height: 100%;
background-repeat: repeat-y;
background-position: 0% 0%;
text-decoration: none;
}
#leftside
{
left: 0;
background-image: url(images/background/lpage.png);
}
#rightside
{
right: 0;
background-image: url(images/background/rpage.png);
}
.content
{
position: relative;
width: auto;
left: 70px;
right: 70px;
padding-right: 100px;
}

The trouble is that Firefox seems to be interpreting "height: 100%;"
as 100% of the height of the graphics screen, so as soon as you
scroll Firefox's window it becomes apparent that the lefthand and
righthand columns are not extending to the bottom of the middle column.
Am I making an idiotic mistake somewhere and NetSurf is being more
forgiving than Firefox? Has anybody else encountered this?

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

Re: how does buildsystem choose the correct compiler on crosscompile ?

On 30/08/2012 15:39, John-Mark Bell wrote:
> On Thu, Aug 30, 2012 at 02:34:52PM +0100, Bernd Roesch wrote:
>> Hi,
>>
>> I try to compile libwapcaplet with the new buildsystem on cygwin hostet. gcc is default to X86
>> here.
>> If you want compile for 68k m68k-amigaos-gcc is need.
>>
>> make TARGET=amigaos3
>>
>> But there is no m68k-amigaos-gcc compiler use.
>
> The only place the buildsystem will look for a suitable cross compiler
> is /opt/netsurf/<host-triplet>. If you have installed your cross
> compiler somewhere else, it won't find it automatically, so you will
> have to tell it where to look manually.
>
> You can do this, thus:
>
> make TARGET=amigaos3 CC=m68k-amigaos-gcc LD=m68k-amigaos-gcc

IIRC the traditional way for crosscompiling things is to
export CROSSCOMPILE=m68k-amigaos-
we should add support for it if not yet done.

François.

Re: how does buildsystem choose the correct compiler on crosscompile ?

On Thu, Aug 30, 2012 at 02:34:52PM +0100, Bernd Roesch wrote:
> Hi,
>
> I try to compile libwapcaplet with the new buildsystem on cygwin hostet. gcc is default to X86
> here.
> If you want compile for 68k m68k-amigaos-gcc is need.
>
> make TARGET=amigaos3
>
> But there is no m68k-amigaos-gcc compiler use.

The only place the buildsystem will look for a suitable cross compiler
is /opt/netsurf/<host-triplet>. If you have installed your cross
compiler somewhere else, it won't find it automatically, so you will
have to tell it where to look manually.

You can do this, thus:

make TARGET=amigaos3 CC=m68k-amigaos-gcc LD=m68k-amigaos-gcc

> I miss a option to set the compiler file name in makefile.top . is it possible to add an Option ?

Makefile.top is toolchain agnostic. All tooling is set up by
Makefile.tools.


J.

how does buildsystem choose the correct compiler on crosscompile ?

Hi,

I try to compile libwapcaplet with the new buildsystem on cygwin hostet. gcc is default to X86
here.
If you want compile for 68k m68k-amigaos-gcc is need.

make TARGET=amigaos3

But there is no m68k-amigaos-gcc compiler use.

I miss a option to set the compiler file name in makefile.top . is it possible to add an Option ?

Bye

Re: Plaese help us to port NetSurf to Playstation 2

On 30 Aug 2012 as I do recall,
Oleg Petrov wrote:

> I read info on your web-site about NetSurf and was very amazed that it can
> work even on Atari computers. Also I read that it can be ported on older
> platforms and that developers of NetSurf would be happy to contact such
> people.
>
> So I and my friends decided to port NetSurf to PlayStation 2.
>
> We created thread on http://www.psx-scene.com
>
> The address is here:
>
> http://psx-scene.com/forums/f19/open-source-cross-platform-web-browser-ps2-hd-support-lets-make-our-dream-come-true-baby-105626/
>

[snip]

At a quick glance the main thing you're going to have problems with from
that list of requirements is No.8: "Must support at least light version
of Flash in order to show web-pages properly..."

If you can get past that requirement the project sounds promising.

--
Harriet Bazley == Loyaulte me lie ==

It is far better to be deceived than to be undeceived by those we love.

Plaese help us to port NetSurf to Playstation 2

Hello NetSurf Development team.

I read info on your web-site about NetSurf and was very amazed that it can work even on Atari computers. Also I read that it can be ported on older platforms and that developers of NetSurf would be happy to contact such people.

So I and my friends decided to port NetSurf to PlayStation 2.

We created thread on http://www.psx-scene.com

The address is here:

http://psx-scene.com/forums/f19/open-source-cross-platform-web-browser-ps2-hd-support-lets-make-our-dream-come-true-baby-105626/


Would be so nice to have NetSurf on PlayStation 2 as web-browser...


But we need help from your team, can you help us to port NetSurf to PlayStation 2 ?

Can you also help us on ideas and other stuff how it properly done?

Could you get in contact with us? Please help us...

Wednesday, 29 August 2012

[gccsdk] cross compiler building errors (under Linux)

test -d buildstepsdir || mkdir buildstepsdir
make[1]: Entering directory `/home/gccsdk/gcc4'
cd /home/gccsdk/gcc4/builddir/cross-gcc && PATH="/home/gccsdk/gcc4/builddir/installed-buildtools-for-gcc/bin:/home/gccsdk/cross/bin:/usr/games:/home/chris/bin:/home/chris/android-sdks/tools:/home/chris/android-sdks/platform-tools:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games" && make && make install
make[2]: Entering directory `/home/gccsdk/gcc4/builddir/cross-gcc'
make[3]: Entering directory `/home/gccsdk/gcc4/builddir/cross-gcc'
make[4]: Entering directory `/home/gccsdk/gcc4/builddir/cross-gcc/libiberty'
make[5]: Entering directory `/home/gccsdk/gcc4/builddir/cross-gcc/libiberty/testsuite'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/home/gccsdk/gcc4/builddir/cross-gcc/libiberty/testsuite'
make[4]: Leaving directory `/home/gccsdk/gcc4/builddir/cross-gcc/libiberty'
make[4]: Entering directory `/home/gccsdk/gcc4/builddir/cross-gcc/fixincludes'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/home/gccsdk/gcc4/builddir/cross-gcc/fixincludes'
make[4]: Entering directory `/home/gccsdk/gcc4/builddir/cross-gcc/lto-plugin'
make all-am
make[5]: Entering directory `/home/gccsdk/gcc4/builddir/cross-gcc/lto-plugin'
make[5]: Leaving directory `/home/gccsdk/gcc4/builddir/cross-gcc/lto-plugin'
make[4]: Leaving directory `/home/gccsdk/gcc4/builddir/cross-gcc/lto-plugin'
make[4]: Entering directory `/home/gccsdk/gcc4/builddir/cross-gcc/intl'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/home/gccsdk/gcc4/builddir/cross-gcc/intl'
make[4]: Entering directory `/home/gccsdk/gcc4/builddir/cross-gcc/build-x86_64-unknown-linux-gnu/libiberty'
make[5]: Entering directory `/home/gccsdk/gcc4/builddir/cross-gcc/build-x86_64-unknown-linux-gnu/libiberty/testsuite'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/home/gccsdk/gcc4/builddir/cross-gcc/build-x86_64-unknown-linux-gnu/libiberty/testsuite'
make[4]: Leaving directory `/home/gccsdk/gcc4/builddir/cross-gcc/build-x86_64-unknown-linux-gnu/libiberty'
make[4]: Entering directory `/home/gccsdk/gcc4/builddir/cross-gcc/build-x86_64-unknown-linux-gnu/fixincludes'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/home/gccsdk/gcc4/builddir/cross-gcc/build-x86_64-unknown-linux-gnu/fixincludes'
make[4]: Entering directory `/home/gccsdk/gcc4/builddir/cross-gcc/zlib'
true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-size=5000000 --split-size=5000000 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/bash" "EXPECT=expect" "RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/home/gccsdk/cross" "infodir=/home/gccsdk/cross/share/info" "libdir=/home/gccsdk/cross/lib" "prefix=/home/gccsdk/cross" "tooldir=/home/gccsdk/cross/arm-unknown-riscos" "AR=ar" "AS=as" "CC=gcc" "CXX=g++" "LD=ld" "LIBCFLAGS=-g -O2" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all multi-do # make
make[4]: Leaving directory `/home/gccsdk/gcc4/builddir/cross-gcc/zlib'
make[4]: Entering directory `/home/gccsdk/gcc4/builddir/cross-gcc/libcpp'
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[4]: Leaving directory `/home/gccsdk/gcc4/builddir/cross-gcc/libcpp'
make[4]: Entering directory `/home/gccsdk/gcc4/builddir/cross-gcc/libdecnumber'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/home/gccsdk/gcc4/builddir/cross-gcc/libdecnumber'
make[4]: Entering directory `/home/gccsdk/gcc4/builddir/cross-gcc/gcc'
gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gengtype \
build/gengtype.o build/errors.o build/gengtype-lex.o build/gengtype-parse.o build/gengtype-state.o build/version.o ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a
build/gengtype.o: In function `adjust_field_type':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype.c:1279: undefined reference to `lexer_line'
build/gengtype.o: In function `adjust_field_rtx_def':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype.c:989: undefined reference to `lexer_line'
build/gengtype.o: In function `adjust_field_type':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype.c:1294: undefined reference to `lexer_line'
build/gengtype.o: In function `adjust_field_tree_exp':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype.c:1220: undefined reference to `lexer_line'
build/gengtype.o: In function `adjust_field_rtx_def':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype.c:1045: undefined reference to `lexer_line'
build/gengtype.o:/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype.c:1055: more undefined references to `lexer_line' follow
build/gengtype-parse.o: In function `token':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
build/gengtype-parse.o:/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: more undefined references to `yylex' follow
build/gengtype-parse.o: In function `type':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:726: undefined reference to `lexer_line'
build/gengtype-parse.o: In function `token':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
build/gengtype-parse.o: In function `type':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:797: undefined reference to `lexer_line'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:797: undefined reference to `lexer_line'
build/gengtype-parse.o: In function `token':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
build/gengtype-parse.o: In function `type':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:758: undefined reference to `lexer_line'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:758: undefined reference to `lexer_line'
build/gengtype-parse.o: In function `token':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
build/gengtype-parse.o:/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: more undefined references to `yylex' follow
build/gengtype-parse.o: In function `struct_field_seq':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:692: undefined reference to `lexer_line'
build/gengtype-parse.o: In function `token':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
build/gengtype-parse.o: In function `type':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:782: undefined reference to `lexer_line'
build/gengtype-parse.o: In function `token':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
build/gengtype-parse.o:/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: more undefined references to `yylex' follow
build/gengtype-parse.o: In function `parse_file':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:951: undefined reference to `yybegin'
build/gengtype-parse.o: In function `token':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
build/gengtype-parse.o: In function `parse_file':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:986: undefined reference to `lexer_toplevel_done'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:991: undefined reference to `yyend'
build/gengtype-parse.o: In function `extern_or_static':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:892: undefined reference to `lexer_line'
build/gengtype-parse.o: In function `def_vec':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:918: undefined reference to `lexer_line'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:919: undefined reference to `lexer_line'
build/gengtype-parse.o: In function `def_vec_alloc':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:943: undefined reference to `lexer_line'
build/gengtype-parse.o: In function `typedef_decl':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:842: undefined reference to `lexer_line'
build/gengtype-parse.o: In function `token':
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
/home/gccsdk/gcc4/srcdir/gcc/gcc/gengtype-parse.c:53: undefined reference to `yylex'
collect2: ld returned 1 exit status
make[4]: *** [build/gengtype] Error 1
make[4]: Leaving directory `/home/gccsdk/gcc4/builddir/cross-gcc/gcc'
make[3]: *** [all-gcc] Error 2
make[3]: Leaving directory `/home/gccsdk/gcc4/builddir/cross-gcc'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/gccsdk/gcc4/builddir/cross-gcc'
make[1]: *** [cross-gcc-built] Error 2
make[1]: Leaving directory `/home/gccsdk/gcc4'
make: *** [getenv] Error 2
Hello,

I am trying to build the crosscompiler, I followed the instructions
from  http://www.riscos.info/index.php/Using_GCCSDK#Using_GCCSDK_and_Autobuilder_to_cross-compile_for_RISC_OS

but I am getting some errors, (pls see the attached file (build-cross-output.txt))

I am sure I have installed all of the required packages:

gcc  4.6.3
svn 1.6.17
autogen 5.12.0
bison 2.5
flex 2.5.35

plus the other that listed like sed/libtool etc etc..

The platform I am trying to build the CGGSDK is Linux Mint 13 x86_64 (based on Ubuntu 12.04)
I think the error "reference to `yylex'" has something to do with bison, but bison is already installed
so maybe is a bug or something like this.

Thank you in advance for any help/ideas

Chris

zap-technical Digest, Vol 27, Issue 1

Send zap-technical mailing list submissions to
zap-technical@zap.tartarus.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.tartarus.org/mailman/listinfo/zap-technical
or, via email, send a message with subject or body 'help' to
zap-technical-request@zap.tartarus.org

You can reach the person managing the list at
zap-technical-owner@zap.tartarus.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of zap-technical digest..."

Tuesday, 28 August 2012

[gccsdk] Hardware Bitcount

In message <20120828133922.GV22482@chiark.greenend.org.uk> you wrote:

> [Hope you don't mind me keeping this on the mailing list]

No, but this reply only came on email, not the gccsdk list. I'll
try ccing to the list for you.

> Looking it up, it appears x86 has CLZ (count leading zeros) and CTZ (count
> trailing zeros) [1]. ARM has CLZ but not CTZ. If you google 'ctz arm'
> there's a variety of ways of doing this. But you need to be careful what
> version ARM you're running them on, as they don't exist on earlier CPUs. So
> I suspect GCC will use it if you set the ARM arch number high enough.
> http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00467.html
>
> [1] not necessarily called that:
> http://en.wikipedia.org/wiki/Find_first_set
>
> Theo

Thanks, I'll look into it. Curious how the code is compiling and
running without errors though.

I quoted the 64 bit section of code previously.
I have wiped out the unused sections now for clarity.

# define U32 uint32_t
# define S32 int32_t

static inline int LZ4_NbCommonBytes (register U32 val)
{
return (__builtin_ctz(val) >> 3);
// #else
// static const int DeBruijnBytePos[32] = { 0, 0, 3, 0, 3, 1, 3, 0, 3, 2, 2, 1, 3, 2, 0, 1, 3, 3, 1, 2, 2, 2, 2, 0, 3, 1, 2, 0, 1, 0, 1, 1 };
// return DeBruijnBytePos[((U32)((val & -(S32)val) * 0x077CB531U)) >> 27];
}

Thanks, Ron




_______________________________________________
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: Zap and the Raspberry Pi

On 28 Aug 2012, at 17:01, Steve (ROOL) <srevill@riscosopen.org> wrote:

> We at ROOL [1] are preparing disc images for the Raspberry Pi computer [2],
> containing RISC OS and a selection of the best free software available for
> the platform. These will be distributed electronically by the Raspberry Pi
> Foundation (a registered charity) as well as via file-sharing.
>
> We would like to include Zap (et al) in these disc images, and would
> appreciate permission to do so. Please accept my apologies if you have
> already been contacted on this matter by others, but any permission you may
> have given has not been passed on to us.


I think we're generally happy with this kind of thing. Darren / Christian, any objections?

(Has stock Zap been confirmed to run on Raspberry Pi? I know we've had various patches and re-distros floating around for some other RO targets over the last few years.)

J

--
James Aylett
Writing: nsfwcorp.com; film: talktorex.co.uk
Also: devfort.com, spacelog.org, wildlifenearyou.com


--
_______________________________________________
zap-technical maillist - zap-technical@zap.tartarus.org
http://lists.tartarus.org/mailman/listinfo/zap-technical

Zap and the Raspberry Pi

Hi all,

We at ROOL [1] are preparing disc images for the Raspberry Pi computer [2],
containing RISC OS and a selection of the best free software available for
the platform. These will be distributed electronically by the Raspberry Pi
Foundation (a registered charity) as well as via file-sharing.

Additionally, ROOL will be selling copies of this disc image, pre-installed
onto SD cards, for around £10. We recognise that most people consider this
to be a commercial use of the software - for example, royalties on RISC OS
itself are included in this figure.

We are very keen to keep the price down to £10 to remain competitive with
equivalent SD cards that are being produced for Linux, so unfortunately we
are unlikely to be able to accommodate any further requests for royalty
payments - I hope this is not a problem.

We would like to include Zap (et al) in these disc images, and would
appreciate permission to do so. Please accept my apologies if you have
already been contacted on this matter by others, but any permission you may
have given has not been passed on to us.

We're also working on a strict timetable, so it would be very helpful if
you could let us know who we should contact about this as soon as possible!

Many thanks,

Steve

[1] http://www.riscosopen.org/
[2] http://www.raspberrypi.org/

--
Stephen Revill, Director www.riscosopen.org
RISC OS Open Ltd
Sovereign House, 22 Shelley Road,
Worthing, West Sussex, BN11 1TU

--
_______________________________________________
zap-technical maillist - zap-technical@zap.tartarus.org
http://lists.tartarus.org/mailman/listinfo/zap-technical

[GeSHi-devel] Doubts regarding Regular Expressions in GeSHi

Hi,
 
Thanks to Carne's response to my previous question, I was able to understand and work on REGEX for a couple of language files. Now, I am running into new problems. I want to use REGEXPS and highlight the following cases.
 
1. This is related to the mainframe language JCL [Job Control Language]. Here is a brief background. There is a concept called Symbolic variables. They are like regular variables which are substituted at runtime when the Job is submitted. For example, a typical scenario would be as follows
 
//INPUT  DD DSN=&SYSUID.SEQ.FILE,DISP=SHR
 
Here &SYSUID is the symbolic variable and will be substituted with the actual user id (say ABCD123) during execution. I want to highlight all such variables. The rules for the variable are:

- Starts with &
 
- Not more than 8 characters and must start with an alphabet
 
- Variable end denoted by one of the characters , ' ( ) & . blank space
 
My regexp array is defined as 0 => '(&)([a-zA-Z]{1,8}[0-9]{0,})(,|\(|\)|&|\s|.|\n)'
 
All I end up getting highlighted is the &. I tried using the advanced search & replace as documented at http://qbnz.com/highlighter/geshi-doc.html#language-file-regexps. The output turns out &amp; with the amp highlighted.
 
2. A slight twist on the above example, there is another kind of variable whose rules are:
 
- Starts with either &, ? or %
 
- Must be 8 characters or less and must start with an alphabet
 
- Variable end is denoted by either one of the following , / ' ( ) * & && % + - = blank space ?
 
My regexp array is defined as 1 => '(&|\?|%)[a-zA-Z]{1,8}[0-9]{0,}(,|/|\(|\)|\*|&|%|\+|-|=|\s|\?|.|\n)'
 
This gives me an error >> Warning: preg_replace() [function.preg-replace]: Unknown modifier '|'
 
Can someone please point out what I am doing wrong here?
 
Thanks,
Ramesh

Re: [gccsdk] Unaligned data access vs pack(push...

[Hope you don't mind me keeping this on the mailing list]

On Tue, Aug 28, 2012 at 01:04:51PM +1200, Ron wrote:
> I'm not sure at what point the compiled program would switch on the
> feature and if it switches it off, or if it expects the machine to be
> in that mode already. If you are polling/multitasking it would have to
> switch back and forward, which might not be possible either.

If it's a compiler feature, you either get it for the whole program or you
don't get it at all. The compiled program doesn't mess about with the CPU
settings, it expects the mode to be already set (and falls over otherwise).

Setting on a per-process basis has been suggested, but nobody's written
anything to do it. Indeed, the OS is completely unaware of the issue - it
doesn't even provide any means to change the state.

> Possibly, this seems to be the area for software vs hardware bitcounting
>
> #if defined(_MSC_VER) && !defined(LZ4_FORCE_SW_BITCOUNT)
> unsigned long r = 0;
> _BitScanForward64( &r, val );
> return (int)(r>>3);
> #elif defined(__GNUC__) && ((__GNUC__ * 100 + __GNUC_MINOR__) >= 304) && !defined(LZ4_FORCE_SW_BITCOUNT)
> return (__builtin_ctzll(val) >> 3);
> #else
> static const int DeBruijnBytePos[64] = { 0, 0, 0, 0, 0, 1, 1, 2, 0, 3, 1, 3, 1, 4, 2, 7, 0, 2, 3, 6, 1, 5, 3, 5, 1, 3, 4, 4, 2, 5, 6, 7, 7, 0, 1, 2, 3, 3, 4, 6, 2, 6, 5, 5, 3, 4, 5, 6, 7, 1, 2, 4, 6, 4, 4, 5, 7, 2, 6, 5, 7, 6, 7, 7 };
> return DeBruijnBytePos[((U64)((val & -val) * 0x0218A392CDABBD3F)) >> 58];
>

Monday, 27 August 2012

[gccsdk] riscos.info package repository

As anyone who's been watching the SVN commits might have noticed, I've been
doing a bit of work in fixing up a lot of the packaged software on
riscos.info that's broken (not ARMv7 compatible etc). So quite a few
packages now have updates.

In addition to this, because I can't contact Graham, I've merged in the
package index from riscpkg.org to create a unified list of packages. Along
the way various things get blacklisted - for example, things on riscpkg.org
relating to GCC 2.95 - either because they won't work on ARMv7, or they're
just plain confusing. The packages themselves are still there, but not
indexed.

For your RiscPkg/PackMan sources file, the new index is here:
http://www.riscos.info/packages/pkg/raspberrypi

The plan is to ship ROOL's RaspberryPi SD card image with PackMan ready
configured and pointing at this index, so users can install this packaged
software. As much as is possible on the SD image is managed, so updates can
be easily pushed out, and there's a RaspberryPiDistro dummy package to use
to lever future upgrades of other parts of the system.

There are already some binary-only packages I've put into the autobuilder
tree, which the autobuilder makes by downloading zip files of binaries from
the author's website and moving files around. This means anyone running the
autobuilder can rebuild those packages (the idea is they'll be trivial to
update when upgrades are released).

Now I'm starting to get people send me packages to include. At the moment,
I haven't written any infrastructure to cope with this so I'm just
importing them manually.

So, a question: should third-party packages (those which aren't autobuilt)
be included in the riscos.info package repository? At the moment I've set
them up as a separate repository in my riscos.info home directory and then
my merge script joins the indexes together. That means they're hidden from
the normal autobuilder web pages.

In terms of infrastructure for auto updates I haven't really decided, but am
thinking of something simple like a script that always fetches zips from a
fixed URL (ie http://upstream/mypkg.zip not mypkg1.2.3.zip), run from a cron
job or magic cgi location to force an index rebuild. Then maybe also a URL
watcher to email for watching those upstream pages where some autobuilder
poking is required. Am open to ideas.

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

Re: Performance on Debian Linux

On Sun, 26 Aug 2012 18:55:07 +0200, Ole wrote:

> Looks like it is not good to try about:blank. It still has network
> access involved:
>
> >(0.575378) content/fetchers/curl.c fetch_curl_setup 365: fetch
> >0x8cd9458, url 'http://www.google.com/favicon.ico'
>
> Please try about:config.

Unlikely to make any difference; that favicon is fetched due to the
web search provider functionality.

I was meaning to look at caching favicons within URLdb a while back -
I think there may be benefits to that (we can call up favicons for
treeviews for instance). They'd still need to be refreshed of course,
but I don't think the search provider needs to grab the absolute
latest favicon - the last time it was fetched would be fine.

That would solve this issue anyway. A disk cache would also solve it,
but I'm not sure if that would allow us to associate bookmarked or
history URLs with favicons?

Chris

Sunday, 26 August 2012

Re: Performance on Debian Linux

Am Sonntag, den 26.08.2012, 11:05 +0200 schrieb Wendell P
<wendellp@operamail.com>:

> Yea, it's still 6s with about:config. Why should fetching the favicon
> take so long?

DNS, network layer setup, network latency...

At least it's clear that the first/single network access takes that
long.

Thanks for reporting it. I believe you could also try to use a proxy to
cache the network access.

Greets,
Ole

Re: Performance on Debian Linux

On Sun, Aug 26, 2012, at 10:33 AM, Michael Drake wrote:
> In article
> <853f986283b9fd9996daf9e45b2364b5-EhVcX1lFRQVaRwYcDTpQCEFddQZLVF5dQUNBAjBeX15ZVF0WWVhoA1RWMl5cRUMCX1pYQF8=-webmailer2@s,
> Ole <ole@monochrom.net> wrote:
> > >(0.575378) content/fetchers/curl.c fetch_curl_setup 365: fetch
> > >0x8cd9458, url 'http://www.google.com/favicon.ico'
>
> > Please try about:config.
>
> Nope, that fetch is from fetching the favicon in the toolbar search box.
> I don't think it's possible to avoid that. :(

Yea, it's still 6s with about:config. Why should fetching the favicon
take so long?

--
http://www.fastmail.fm - Send your email first class

Re: Performance on Debian Linux

In article
<853f986283b9fd9996daf9e45b2364b5-EhVcX1lFRQVaRwYcDTpQCEFddQZLVF5dQUNBAjBeX15ZVF0WWVhoA1RWMl5cRUMCX1pYQF8=-webmailer2@s,
Ole <ole@monochrom.net> wrote:

> Looks like it is not good to try about:blank. It still has network
> access involved:

> >(0.575378) content/fetchers/curl.c fetch_curl_setup 365: fetch
> >0x8cd9458, url 'http://www.google.com/favicon.ico'

> Please try about:config.

Nope, that fetch is from fetching the favicon in the toolbar search box.
I don't think it's possible to avoid that. :(

--

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

Re: Performance on Debian Linux

Am Sonntag, den 26.08.2012, 09:19 +0200 schrieb Wendell P
<wendellp@operamail.com>:

>
> Tried it several times, still 6s. If it helps, while Firefox and
> Chrome
> are faster, w3m is also very slow on my machine.
>
> Here is "netsurf -v about:blank 2>logfile"

Looks like it is not good to try about:blank. It still has network
access involved:

>(0.575378) content/fetchers/curl.c fetch_curl_setup 365: fetch
>0x8cd9458, url 'http://www.google.com/favicon.ico'

Please try about:config.


Greets,
Ole

Re: Performance on Debian Linux

On Sun, Aug 26, 2012, at 03:48 AM, Michael Drake wrote:
> In article
> <1345913002.695.140661119461833.719C587A@webmail.messagingengine.com>,
> Looks like a 5 second wait for the fetch to start. Perhaps slow DNS.
>
> As Ole said, please try with a local page. You can use NetSurf's
> about:blank or about:about generated pages.


Tried it several times, still 6s. If it helps, while Firefox and Chrome
are faster, w3m is also very slow on my machine.

Here is "netsurf -v about:blank 2>logfile"
-------------------------------------------------------------
(0.1) desktop/netsurf.c netsurf_init 160: version '2.9 (27th Febuary
2012)'
(0.154) desktop/netsurf.c netsurf_init 167: NetSurf on <Linux>, node
<debian>, release <2.6.38-2-686>, version <#1 SMP Thu Apr 7 05:24:21 UTC
2011>, machine <i686>
(0.178) desktop/netsurf.c netsurf_init 169: Using
'/home/base/.netsurf/Choices' for Options file
(0.849) utils/messages.c messages_load 124: Loading Messages from
'/usr/share/netsurf/en/Messages'
(0.8287) image/image_cache.c image_cache_init 380: Image cache
initilised with a limit of 3145728 hysteresis of 629145
(0.9622) content/fetchers/curl.c fetch_curl_register 167: curl_version
libcurl/7.21.4 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.20 libssh2/1.2.6
(0.13025) utils/useragent.c user_agent_build_string 72: Built user agent
"NetSurf/2.9 (Linux; i686)"
(0.13121) content/fetchers/curl.c fetch_curl_register 216:
option_ca_path: '/etc/ssl/certs'
(0.13148) content/fetchers/curl.c fetch_curl_register 228: cURL linked
against openssl
(0.13213) content/fetchers/curl.c fetch_curl_initialise 285: Initialise
cURL fetcher for http
(0.13241) content/fetchers/curl.c fetch_curl_initialise 285: Initialise
cURL fetcher for https
(0.13271) content/fetchers/data.c fetch_data_initialise 65:
fetch_data_initialise called for data
(0.13947) content/llcache.c llcache_initialise 286: llcache initialised
with a limit of 9437184 bytes
(0.14130) gtk/gui.c check_options 294: Using '/usr/share/netsurf/icons'
as Tree icons dir
(0.14170) desktop/tree.c tree_set_icon_dir 179: Tree icon directory set
to /usr/share/netsurf/icons
(0.14264) gtk/gui.c check_options 307: Using
'/home/base//.netsurf//Print' as Print Settings file
(0.14363) gtk/gui.c gui_init 374: Using '/usr/share/netsurf/' for
resource path
(0.66112) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/netsurf.glade' as netsurf glade template file
(0.76949) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/password.glade' as password glade template file
(0.84689) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/login.glade' as login glade template file
(0.92013) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/ssl.glade' as ssl glade template file
(0.97749) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/toolbar.glade' as toolbar glade template file
(0.105698) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/downloads.glade' as downloads glade template file
(0.117777) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/history.glade' as history glade template file
(0.344836) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/options.glade' as options glade template file
(0.355335) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/hotlist.glade' as hotlist glade template file
(0.363624) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/cookies.glade' as cookies glade template file
(0.366708) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/warning.glade' as warning glade template file
(0.373932) gtk/gui.c gui_init 388: Using
'/usr/share/netsurf/SearchEngines' as Search Engines file
(0.374100) gtk/gui.c gui_init 392: Using
'/usr/share/netsurf/default.ico' as default search ico
(0.375649) gtk/gui.c gui_init 407: Using
'/usr/share/netsurf/toolbarIndices' as custom toolbar settings file
(0.381400) content/urldb.c urldb_load 351: Loading URL file
(0.382094) content/urldb.c urldb_load 503: Successfully loaded URL file
(0.382325) gtk/gui.c gui_init 429: Set CSS DPI to 95.976562
(0.391881) gtk/font_pango.c nsfont_pango_check 63: Creating
nsfont_pango_context.
(0.392049) gtk/font_pango.c nsfont_pango_check 68: Creating
nsfont_pango_layout.
(0.490313) gtk/window.c gui_create_browser_window 530: Creating gui
window 0x8c97f70 for browser window 0x8c97e80
(0.490436) gtk/scaffolding.c nsgtk_new_scaffolding 1659: Constructing a
scaffold of 0x8c97bf0 for gui_window 0x8c97f70
(0.497995) gtk/toolbar.c nsgtk_toolbar_customization_load 1048: empty
read toolbar settings
(0.575378) content/fetchers/curl.c fetch_curl_setup 365: fetch
0x8cd9458, url 'http://www.google.com/favicon.ico'
(0.647986) gtk/scaffolding.c nsgtk_new_scaffolding 1944: creation
complete
(0.658030) desktop/browser.c browser_window_go_post 832: bw 0x8c97e80,
url about:blank
(0.658334) desktop/browser.c browser_window_go_post 953: Loading
'about:blank'
(5.807908) content/content.c content__init 85: url about:blank ->
0x8b91c30
(5.808162) content/content.c content_add_user 555: content about:blank
(0x8b91c30), user 0x807c700 0x8d07628
(5.808374) content/content.c content__init 85: url
file:///usr/share/netsurf/icons/directory.png -> 0x8b91f50
(5.808536) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/directory.png (0x8b91f50), user
0x807c700 0x8c976d0
(5.808957) image/png.c info_callback 183: size 17 * 17, rowbytes 68
(5.809170) content/content.c content_convert 278: content
file:///usr/share/netsurf/icons/directory.png (0x8b91f50)
(5.809267) image/image_cache.c image_cache_add 479: centry 0x8c1f4b8,
content 0x8b91f50, bitmap 0x8d0c270
(5.809346) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/directory.png (0x8b91f50), user
0x807c700 0x8c8bf10
(5.809388) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/directory.png (0x8b91f50), user
0x807c700 0x8abc2c8
(5.809425) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/directory.png (0x8b91f50), user
0x807c700 0x8c12e70
(5.810545) content/content.c content_convert 278: content about:blank
(0x8b91c30)
(5.810708) render/hubbub_binding.c create_namespaces 415: Failed
creating namespace xml

(5.810842) content/content.c content__init 85: url
file:///usr/share/netsurf/icons/content.png -> 0x8d1c458
(5.810917) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/content.png (0x8d1c458), user 0x807c700
0x8c97e30
(5.811090) image/png.c info_callback 183: size 17 * 17, rowbytes 68
(5.811316) content/content.c content_convert 278: content
file:///usr/share/netsurf/icons/content.png (0x8d1c458)
(5.811387) image/image_cache.c image_cache_add 479: centry 0x8d1c738,
content 0x8d1c458, bitmap 0x8d1c418
(5.811460) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/content.png (0x8d1c458), user 0x807c700
0x8c8bf20
(5.811503) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/content.png (0x8d1c458), user 0x807c700
0x8c1f920
(5.811539) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/content.png (0x8d1c458), user 0x807c700
0x8c1f8b8
(5.811575) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/content.png (0x8d1c458), user 0x807c700
0x8c1f850
(5.811610) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/content.png (0x8d1c458), user 0x807c700
0x8c1f6a0
(5.811645) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/content.png (0x8d1c458), user 0x807c700
0x8c1f530
(5.812385) content/content.c content__init 85: url
file:///usr/share/netsurf/gtkdefault.css -> 0x8d1dd98
(5.812976) content/content.c content_add_user 555: content
file:///usr/share/netsurf/gtkdefault.css (0x8d1dd98), user 0x807c700
0x8d0dfc8
(5.813915) content/content.c content_convert 278: content
file:///usr/share/netsurf/gtkdefault.css (0x8d1dd98)
(5.814501) content/content.c content__init 85: url
file:///usr/share/netsurf/default.css -> 0x8d3df08
(5.814650) content/content.c content_add_user 555: content
file:///usr/share/netsurf/default.css (0x8d3df08), user 0x807c700
0x8d21200
(5.817495) content/content.c content_convert 278: content
file:///usr/share/netsurf/default.css (0x8d3df08)
(5.817658) render/html.c html_convert_css_callback 1475: got stylesheet
'file:///usr/share/netsurf/gtkdefault.css'
(5.818039) content/content.c content__init 85: url
file:///usr/share/netsurf/quirks.css -> 0x8d47d78
(5.818193) content/content.c content_add_user 555: content
file:///usr/share/netsurf/quirks.css (0x8d47d78), user 0x807c700
0x8d1c258
(5.818347) content/content.c content_convert 278: content
file:///usr/share/netsurf/quirks.css (0x8d47d78)
(5.818419) render/html.c html_convert_css_callback 1475: got stylesheet
'file:///usr/share/netsurf/quirks.css'
(5.818537) render/html.c html_finish_conversion 695: XML to box
(0x8b91c30)
(5.819097) render/html.c html_box_convert_done 718: Done XML to box
(0x8b91c30)
(5.819246) gtk/window.c gui_window_get_dimensions 1024: WINDOW
WIDTH: 1

(5.819283) gtk/window.c gui_window_get_dimensions 1025: WINDOW
HEIGHT: 1

(5.819312) content/content.c content__reformat 357: 0x8b91c30
about:blank
(5.849400) content/content.c content_open 681: content 0x8b91c30
about:blank
(5.852609) desktop/browser.c browser_window_update_favicon 1147:
fetching general favicon from 'resource:favicon.ico'
(5.862547) content/content.c content__init 85: url
file:///usr/share/netsurf/favicon.png -> 0x8d18828
(5.862680) content/content.c content_add_user 555: content
file:///usr/share/netsurf/favicon.png (0x8d18828), user 0x807c700
0x8d1c3b8
(5.863024) image/png.c info_callback 183: size 17 * 17, rowbytes 68
(5.863270) content/content.c content_convert 278: content
file:///usr/share/netsurf/favicon.png (0x8d18828)
(5.863336) image/image_cache.c image_cache_add 479: centry 0x8d48cd8,
content 0x8d18828, bitmap 0x8d48c70
(5.863394) gtk/window.c gui_window_set_icon 723: Using 0x8d48c70 bitmap
(5.976433) content/content.c content__reformat 357: 0x8b91c30
about:blank
(6.86813) content/fetchers/curl.c fetch_curl_process_headers 1171: HTTP
status code 200
(6.87079) content/fetchers/curl.c fetch_curl_done 813: done
http://www.google.com/favicon.ico
(6.87140) content/fetchers/curl.c fetch_curl_stop 695: fetch 0x8cd9458,
url 'http://www.google.com/favicon.ico'
(6.87243) content/content.c content__init 85: url
http://www.google.com/favicon.ico -> 0x8d52800
(6.87317) content/content.c content_add_user 555: content
http://www.google.com/favicon.ico (0x8d52800), user 0x807c700 0x8cd3ab8
(6.87361) content/content.c content_convert 278: content
http://www.google.com/favicon.ico (0x8d52800)
(6.87475) desktop/searchweb.c search_web_ico_callback 294: got favicon
'http://www.google.com/favicon.ico'
(16.808161) gtk/scaffolding.c nsgtk_scaffolding_destroy 310: Being
Destroyed = 0
(16.808295) gtk/scaffolding.c nsgtk_window_close 271: Being Destroyed =
1
(16.809008) desktop/browser.c browser_window_destroy_internal 1898:
Destroying window
(16.809123) gtk/window.c gui_window_destroy 697: Destroying gui_window
0x8c97f70
(16.809154) gtk/window.c gui_window_destroy 700: Scaffolding:
0x8c97bf0
(16.809181) gtk/window.c gui_window_destroy 701: Window name:
(null)
(16.810767) gtk/scaffolding.c nsgtk_scaffolding_destroy 310: Being
Destroyed = 1
(16.811368) content/content.c content_close 698: content 0x8b91c30
about:blank
(16.811465) content/content.c content_remove_user 583: content
about:blank (0x8b91c30), user 0x807c700 0x8d07628
(16.811500) content/content.c content_close 698: content 0x8d18828
file:///usr/share/netsurf/favicon.png
(16.811531) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/favicon.png (0x8d18828), user 0x807c700
0x8d1c3b8
(16.811563) desktop/browser.c browser_window_destroy_internal 1987:
Status text cache match:miss 15:6
(16.811596) desktop/netsurf.c netsurf_exit 262: Closing GUI
(16.812684) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/directory.png (0x8b91f50), user
0x807c700 0x8c8bf10
(16.812752) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/content.png (0x8d1c458), user 0x807c700
0x8c8bf20
(16.816934) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/directory.png (0x8b91f50), user
0x807c700 0x8c12e70
(16.822238) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/directory.png (0x8b91f50), user
0x807c700 0x8c976d0
(16.822325) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/directory.png (0x8b91f50), user
0x807c700 0x8abc2c8
(16.822358) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/content.png (0x8d1c458), user 0x807c700
0x8c1f530
(16.822415) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/content.png (0x8d1c458), user 0x807c700
0x8c1f6a0
(16.822445) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/content.png (0x8d1c458), user 0x807c700
0x8c1f850
(16.822474) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/content.png (0x8d1c458), user 0x807c700
0x8c1f8b8
(16.822502) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/content.png (0x8d1c458), user 0x807c700
0x8c1f920
(16.826961) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/content.png (0x8d1c458), user 0x807c700
0x8c97e30
(16.827238) desktop/netsurf.c netsurf_exit 265: Closing search and
related resources
(16.827270) content/content.c content_remove_user 583: content
http://www.google.com/favicon.ico (0x8d52800), user 0x807c700 0x8cd3ab8
(16.827301) desktop/netsurf.c netsurf_exit 268: Finalising high-level
cache
(16.827331) content/hlcache.c hlcache_finalise 161: 8 contents remain
before cache drain
(16.827360) content/content.c content_destroy 383: content 0x8d52800
http://www.google.com/favicon.ico
(16.827408) content/content.c content_destroy 383: content 0x8d18828
file:///usr/share/netsurf/favicon.png
(16.827448) content/content.c content_destroy 383: content 0x8d1c458
file:///usr/share/netsurf/icons/content.png
(16.827483) content/content.c content_destroy 383: content 0x8b91f50
file:///usr/share/netsurf/icons/directory.png
(16.827518) content/content.c content_destroy 383: content 0x8b91c30
about:blank
(16.827546) render/html.c html_destroy 1997: content 0x8b91c30
(16.827595) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/gtkdefault.css (0x8d1dd98), user 0x807c700
0x8d0dfc8
(16.827628) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/quirks.css (0x8d47d78), user 0x807c700
0x8d1c258
(16.827715) content/content.c content_destroy 383: content 0x8d47d78
file:///usr/share/netsurf/quirks.css
(16.827762) content/content.c content_destroy 383: content 0x8d1dd98
file:///usr/share/netsurf/gtkdefault.css
(16.827793) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/default.css (0x8d3df08), user 0x807c700
0x8d21200
(16.827851) content/content.c content_destroy 383: content 0x8d3df08
file:///usr/share/netsurf/default.css
(16.828132) content/hlcache.c hlcache_finalise 175: 0 contents
remaining:
(16.828184) content/hlcache.c hlcache_finalise 211: hit/miss 9/8
(16.828212) content/hlcache.c hlcache_finalise 216: Finalising low-level
cache
(16.828251) desktop/netsurf.c netsurf_exit 271: Closing fetches
(16.828292) content/fetchers/data.c fetch_data_finalise 74:
fetch_data_finalise called for data
(16.828483) content/fetchers/curl.c fetch_curl_finalise 300: Finalise
cURL fetcher https
(16.828537) content/fetchers/curl.c fetch_curl_finalise 300: Finalise
cURL fetcher http
(16.828565) content/fetchers/curl.c fetch_curl_finalise 304: All cURL
fetchers finalised, closing down cURL
(16.829478) image/image_cache.c image_cache_fini 394: Size at finish 0
(in 0)
(16.829596) image/image_cache.c image_cache_fini 404: Age 10s
(16.829623) image/image_cache.c image_cache_fini 407: Peak size 3468 (in
3)
(16.829650) image/image_cache.c image_cache_fini 410: Peak image count 3
(size 3468)
(16.829677) image/image_cache.c image_cache_fini 426: Cache
total/hit/miss/fail (counts) 1/1/0/0 (100%/100%/0%/0%)
(16.829706) image/image_cache.c image_cache_fini 434: Cache
total/hit/miss/fail (size) 1156/0/1156/0 (100%/0%/0%/0%)
(16.829736) image/image_cache.c image_cache_fini 439: Total images never
rendered: 3 (includes 3 that were converted)
(16.829763) image/image_cache.c image_cache_fini 443: Total number of
excessive conversions: 0 (from 0 images converted more than once)
(16.829790) image/image_cache.c image_cache_fini 447: Bitmap of size
1156 had most (1) conversions
(16.829865) desktop/netsurf.c netsurf_exit 282: Closing utf8
(16.829896) desktop/netsurf.c netsurf_exit 285: Destroying URLdb
(16.830062) desktop/netsurf.c netsurf_exit 288: Destroying System
colours
(16.830108) desktop/netsurf.c netsurf_exit 291: Remaining lwc strings:
(16.830172) desktop/netsurf.c netsurf_exit 294: Exited successfully

--
http://www.fastmail.fm - Or how I learned to stop worrying and
love email again

Re: Performance on Debian Linux

In article
<1345913002.695.140661119461833.719C587A@webmail.messagingengine.com>,
Wendell P <wendellp@operamail.com> wrote:

> (1.119215) content/fetchers/curl.c fetch_curl_setup 365: fetch
> 0x9368948, url 'http://www.google.com/'
> (6.283815) content/content.c content__init 85: url
> file:///usr/share/netsurf/icons/directory.png -> 0x91db6a0

Looks like a 5 second wait for the fetch to start. Perhaps slow DNS.

As Ole said, please try with a local page. You can use NetSurf's
about:blank or about:about generated pages.

e.g.

$ netsurf -v about:blank
or
$ netsurf -v about:about

--

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

Re: Performance on Debian Linux

Am Samstag, den 25.08.2012, 09:43 +0200 schrieb Wendell P
<wendellp@operamail.com>:

>> > On my machine, Chrome and Firefox each take 3s to boot, while
>> Netsurf
>> > takes 6s. Is this typical or do you think there is something
>> wrong?
>>

Hello,

can you please test with an blank or at least simple *local* webpage?

I believe it's about the network layer within netsurf or your network
might be slow.
AFAIK mozilla etc. load a local page at startup - and even if it is
remote - it's probably
cached. Netsurf has no disk cache yet.

Please test it and tell us the results, thanks :) !

Greets,
Ole

Saturday, 25 August 2012

How to test and report instability?

Netsurf 2.9 is very unstable on Debian Wheezy. If I stick to simple
text-only sites, I can usually browse to at least 5 sites before Netsurf
crashes, but going to Amazon crashes it immediately. I have been
watching the log, but all I can say is that Netsurf seems to be going
along fine until it reports "Segmentation fault".

What can I do to generate more useful debugging information?

--
http://www.fastmail.fm - Access your email from home and the web

Re: Performance on Debian Linux

On Fri, Aug 24, 2012, at 12:59 PM, Chris Young wrote:
> On Fri, 24 Aug 2012 12:09:17 -0700, Wendell P wrote:
>
> > Netsurf 2.9 Debian distribution on Debian Wheezy.
> >
> > On my machine, Chrome and Firefox each take 3s to boot, while Netsurf
> > takes 6s. Is this typical or do you think there is something wrong?
>
> To diagnose both these issues a log file will be handy (start NetSurf
> with "nsgtk -v").

Here is the output of "netsurf -v 2>logfile" from a startup-shutdown.
---------------------------------------------------------------------
(0.1) desktop/netsurf.c netsurf_init 160: version '2.9 (27th Febuary
2012)'
(0.161) desktop/netsurf.c netsurf_init 167: NetSurf on <Linux>, node
<debian>, release <2.6.38-2-686>, version <#1 SMP Thu Apr 7 05:24:21 UTC
2011>, machine <i686>
(0.182) desktop/netsurf.c netsurf_init 169: Using
'/home/mine/.netsurf/Choices' for Options file
(0.25655) utils/messages.c messages_load 124: Loading Messages from
'/usr/share/netsurf/en/Messages'
(0.74003) image/image_cache.c image_cache_init 380: Image cache
initilised with a limit of 3145728 hysteresis of 629145
(0.103449) content/fetchers/curl.c fetch_curl_register 167: curl_version
libcurl/7.21.4 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.20 libssh2/1.2.6
(0.107036) utils/useragent.c user_agent_build_string 72: Built user
agent "NetSurf/2.9 (Linux; i686)"
(0.107153) content/fetchers/curl.c fetch_curl_register 216:
option_ca_path: '/etc/ssl/certs'
(0.107182) content/fetchers/curl.c fetch_curl_register 228: cURL linked
against openssl
(0.107243) content/fetchers/curl.c fetch_curl_initialise 285: Initialise
cURL fetcher for http
(0.107270) content/fetchers/curl.c fetch_curl_initialise 285: Initialise
cURL fetcher for https
(0.107297) content/fetchers/data.c fetch_data_initialise 65:
fetch_data_initialise called for data
(0.129922) content/llcache.c llcache_initialise 286: llcache initialised
with a limit of 9437184 bytes
(0.130162) gtk/gui.c check_options 294: Using '/usr/share/netsurf/icons'
as Tree icons dir
(0.130225) desktop/tree.c tree_set_icon_dir 179: Tree icon directory set
to /usr/share/netsurf/icons
(0.130328) gtk/gui.c check_options 307: Using
'/home/mine//.netsurf//Print' as Print Settings file
(0.130444) gtk/gui.c gui_init 374: Using '/usr/share/netsurf/' for
resource path
(0.273779) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/netsurf.glade' as netsurf glade template file
(0.296219) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/password.glade' as password glade template file
(0.306543) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/login.glade' as login glade template file
(0.321653) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/ssl.glade' as ssl glade template file
(0.332633) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/toolbar.glade' as toolbar glade template file
(0.341072) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/downloads.glade' as downloads glade template file
(0.352912) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/history.glade' as history glade template file
(0.705146) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/options.glade' as options glade template file
(0.729210) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/hotlist.glade' as hotlist glade template file
(0.738362) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/cookies.glade' as cookies glade template file
(0.748198) gtk/gui.c nsgtk_new_glade 198: Using
'/usr/share/netsurf/warning.glade' as warning glade template file
(0.756752) gtk/gui.c gui_init 388: Using
'/usr/share/netsurf/SearchEngines' as Search Engines file
(0.756925) gtk/gui.c gui_init 392: Using
'/usr/share/netsurf/default.ico' as default search ico
(0.758956) gtk/gui.c gui_init 407: Using
'/usr/share/netsurf/toolbarIndices' as custom toolbar settings file
(0.782366) content/urldb.c urldb_load 351: Loading URL file
(0.797534) content/urldb.c urldb_load 503: Successfully loaded URL file
(0.798231) gtk/gui.c gui_init 429: Set CSS DPI to 95.976562
(0.807779) gtk/font_pango.c nsfont_pango_check 63: Creating
nsfont_pango_context.
(0.807942) gtk/font_pango.c nsfont_pango_check 68: Creating
nsfont_pango_layout.
(0.915954) gtk/window.c gui_create_browser_window 530: Creating gui
window 0x92f0d28 for browser window 0x92ec228
(0.916076) gtk/scaffolding.c nsgtk_new_scaffolding 1659: Constructing a
scaffold of 0x92ebff0 for gui_window 0x92f0d28
(0.923459) gtk/toolbar.c nsgtk_toolbar_customization_load 1048: empty
read toolbar settings
(1.35985) content/fetchers/curl.c fetch_curl_setup 365: fetch 0x9325580,
url 'http://www.google.com/favicon.ico'
(1.108821) gtk/scaffolding.c nsgtk_new_scaffolding 1944: creation
complete
(1.118766) desktop/browser.c browser_window_go_post 832: bw 0x92ec228,
url www.google.com
(1.119070) desktop/browser.c browser_window_go_post 953: Loading
'http://www.google.com/'
(1.119215) content/fetchers/curl.c fetch_curl_setup 365: fetch
0x9368948, url 'http://www.google.com/'
(6.283815) content/content.c content__init 85: url
file:///usr/share/netsurf/icons/directory.png -> 0x91db6a0
(6.283992) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/directory.png (0x91db6a0), user
0x807c700 0x92e4bc0
(6.284320) image/png.c info_callback 183: size 17 * 17, rowbytes 68
(6.284499) content/content.c content_convert 278: content
file:///usr/share/netsurf/icons/directory.png (0x91db6a0)
(6.284586) image/image_cache.c image_cache_add 479: centry 0x92e6b10,
content 0x91db6a0, bitmap 0x91e7f38
(6.284658) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/directory.png (0x91db6a0), user
0x807c700 0x92d9980
(6.284697) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/directory.png (0x91db6a0), user
0x807c700 0x926d818
(6.284731) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/directory.png (0x91db6a0), user
0x807c700 0x92616c0
(6.285977) content/content.c content__init 85: url
file:///usr/share/netsurf/icons/content.png -> 0x9369d48
(6.286110) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/content.png (0x9369d48), user 0x807c700
0x92ec1d8
(6.286285) image/png.c info_callback 183: size 17 * 17, rowbytes 68
(6.286481) content/content.c content_convert 278: content
file:///usr/share/netsurf/icons/content.png (0x9369d48)
(6.286543) image/image_cache.c image_cache_add 479: centry 0x926d760,
content 0x9369d48, bitmap 0x91c6098
(6.286611) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/content.png (0x9369d48), user 0x807c700
0x92d8920
(6.286651) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/content.png (0x9369d48), user 0x807c700
0x926dbf0
(6.286685) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/content.png (0x9369d48), user 0x807c700
0x926db88
(6.286719) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/content.png (0x9369d48), user 0x807c700
0x926db20
(6.286753) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/content.png (0x9369d48), user 0x807c700
0x926d970
(6.286786) content/content.c content_add_user 555: content
file:///usr/share/netsurf/icons/content.png (0x9369d48), user 0x807c700
0x926d7d8
(6.468665) content/fetchers/curl.c fetch_curl_process_headers 1171: HTTP
status code 200
(6.468904) content/content.c content__init 85: url
http://www.google.com/favicon.ico -> 0x935d5d0
(6.468980) content/content.c content_add_user 555: content
http://www.google.com/favicon.ico (0x935d5d0), user 0x807c700 0x931fcb8
(6.485563) content/fetchers/curl.c fetch_curl_done 813: done
http://www.google.com/favicon.ico
(6.485682) content/fetchers/curl.c fetch_curl_stop 695: fetch 0x9325580,
url 'http://www.google.com/favicon.ico'
(6.485784) content/content.c content_convert 278: content
http://www.google.com/favicon.ico (0x935d5d0)
(6.485943) desktop/searchweb.c search_web_ico_callback 294: got favicon
'http://www.google.com/favicon.ico'
(6.487120) content/fetchers/curl.c fetch_curl_process_headers 1171: HTTP
status code 200
(6.487418) content/content.c content__init 85: url
http://www.google.com/ -> 0x9391290
(6.553350) content/content.c content_add_user 555: content
http://www.google.com/ (0x9391290), user 0x807c700 0x935ec30
(6.554590) render/hubbub_binding.c create_namespaces 415: Failed
creating namespace xml

(6.581777) content/fetchers/curl.c fetch_curl_done 813: done
http://www.google.com/
(6.581892) content/fetchers/curl.c fetch_curl_stop 695: fetch 0x9368948,
url 'http://www.google.com/'
(6.582461) content/content.c content_convert 278: content
http://www.google.com/ (0x9391290)
(6.612902) content/content.c content__init 85: url
file:///usr/share/netsurf/gtkdefault.css -> 0x939d118
(6.624154) content/content.c content_add_user 555: content
file:///usr/share/netsurf/gtkdefault.css (0x939d118), user 0x807c700
0x93a9e90
(6.625050) content/content.c content_convert 278: content
file:///usr/share/netsurf/gtkdefault.css (0x939d118)
(6.642864) content/content.c content__init 85: url
file:///usr/share/netsurf/default.css -> 0x939ff70
(6.643031) content/content.c content_add_user 555: content
file:///usr/share/netsurf/default.css (0x939ff70), user 0x807c700
0x9367108
(6.645802) content/content.c content_convert 278: content
file:///usr/share/netsurf/default.css (0x939ff70)
(6.645961) render/html.c html_convert_css_callback 1475: got stylesheet
'file:///usr/share/netsurf/gtkdefault.css'
(6.646045) render/html.c html_finish_conversion 695: XML to box
(0x9391290)
(6.649194) content/fetchers/curl.c fetch_curl_setup 365: fetch
0x939a4d8, url
'http://www.google.com/intl/en_ALL/images/srpr/logo1w.png'
(6.651497) content/fetchers/curl.c fetch_curl_setup 365: fetch
0x939b0f8, url 'http://www.google.com/images/srpr/nav_logo80.png'
(6.654842) render/html.c html_box_convert_done 718: Done XML to box
(0x9391290)
(6.655032) gtk/window.c gui_window_get_dimensions 1024: WINDOW
WIDTH: 980

(6.655068) gtk/window.c gui_window_get_dimensions 1025: WINDOW
HEIGHT: 576

(6.655094) content/content.c content__reformat 357: 0x9391290
http://www.google.com/
(6.683562) content/content.c content_open 681: content 0x9391290
http://www.google.com/
(6.741430) content/fetchers/curl.c fetch_curl_process_headers 1171: HTTP
status code 200
(6.741781) content/content.c content__init 85: url
http://www.google.com/intl/en_ALL/images/srpr/logo1w.png -> 0x9415688
(6.741898) content/content.c content_add_user 555: content
http://www.google.com/intl/en_ALL/images/srpr/logo1w.png (0x9415688),
user 0x807c700 0x939a388
(6.741935) content/content.c content_open 681: content 0x9415688
http://www.google.com/intl/en_ALL/images/srpr/logo1w.png
(6.802081) content/fetchers/curl.c fetch_curl_process_headers 1171: HTTP
status code 200
(6.802284) content/fetchers/curl.c fetch_curl_done 813: done
http://www.google.com/intl/en_ALL/images/srpr/logo1w.png
(6.802328) content/fetchers/curl.c fetch_curl_stop 695: fetch 0x939a4d8,
url 'http://www.google.com/intl/en_ALL/images/srpr/logo1w.png'
(6.802445) content/content.c content__init 85: url
http://www.google.com/images/srpr/nav_logo80.png -> 0x94358f0
(6.802550) content/content.c content_add_user 555: content
http://www.google.com/images/srpr/nav_logo80.png (0x94358f0), user
0x807c700 0x9398ff8
(6.802587) content/content.c content_open 681: content 0x94358f0
http://www.google.com/images/srpr/nav_logo80.png
(6.802628) content/content.c content_add_user 555: content
http://www.google.com/images/srpr/nav_logo80.png (0x94358f0), user
0x807c700 0x93bf828
(6.802658) content/content.c content_open 681: content 0x94358f0
http://www.google.com/images/srpr/nav_logo80.png
(6.802696) content/content.c content_convert 278: content
http://www.google.com/intl/en_ALL/images/srpr/logo1w.png (0x9415688)
(6.802748) image/image_cache.c image_cache_add 479: centry 0x9435558,
content 0x9415688, bitmap (nil)
(7.18494) content/fetchers/curl.c fetch_curl_done 813: done
http://www.google.com/images/srpr/nav_logo80.png
(7.18615) content/fetchers/curl.c fetch_curl_stop 695: fetch 0x939b0f8,
url 'http://www.google.com/images/srpr/nav_logo80.png'
(7.19172) content/content.c content_convert 278: content
http://www.google.com/images/srpr/nav_logo80.png (0x94358f0)
(7.19274) image/image_cache.c image_cache_add 479: centry 0x939b150,
content 0x94358f0, bitmap (nil)
(7.19334) content/content.c content__reformat 357: 0x9391290
http://www.google.com/
(7.20002) content/content.c content__reformat 357: 0x9391290
http://www.google.com/
(7.21099) desktop/browser.c browser_window_update_favicon 1147: fetching
general favicon from 'http://www.google.com/favicon.ico'
(7.50475) content/content.c content_add_user 555: content
http://www.google.com/favicon.ico (0x935d5d0), user 0x807c700 0x91cf190
(7.50632) gtk/window.c gui_window_set_icon 723: Using 0x9353698 bitmap
(16.605435) gtk/scaffolding.c nsgtk_scaffolding_destroy 310: Being
Destroyed = 0
(16.605624) gtk/scaffolding.c nsgtk_window_close 271: Being Destroyed =
1
(16.606256) desktop/browser.c browser_window_destroy_internal 1898:
Destroying window
(16.606366) gtk/window.c gui_window_destroy 697: Destroying gui_window
0x92f0d28
(16.606393) gtk/window.c gui_window_destroy 700: Scaffolding:
0x92ebff0
(16.606418) gtk/window.c gui_window_destroy 701: Window name:
(null)
(16.608014) gtk/scaffolding.c nsgtk_scaffolding_destroy 310: Being
Destroyed = 1
(16.608614) content/content.c content_close 698: content 0x9391290
http://www.google.com/
(16.608711) content/content.c content_close 698: content 0x94358f0
http://www.google.com/images/srpr/nav_logo80.png
(16.608739) content/content.c content_close 698: content 0x94358f0
http://www.google.com/images/srpr/nav_logo80.png
(16.608766) content/content.c content_close 698: content 0x9415688
http://www.google.com/intl/en_ALL/images/srpr/logo1w.png
(16.608792) content/content.c content_remove_user 583: content
http://www.google.com/ (0x9391290), user 0x807c700 0x935ec30
(16.608823) content/content.c content_close 698: content 0x935d5d0
http://www.google.com/favicon.ico
(16.608849) content/content.c content_remove_user 583: content
http://www.google.com/favicon.ico (0x935d5d0), user 0x807c700 0x91cf190
(16.608879) desktop/browser.c browser_window_destroy_internal 1987:
Status text cache match:miss 203:23
(16.608910) desktop/netsurf.c netsurf_exit 262: Closing GUI
(16.610393) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/directory.png (0x91db6a0), user
0x807c700 0x92d9980
(16.610469) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/content.png (0x9369d48), user 0x807c700
0x92d8920
(16.614608) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/directory.png (0x91db6a0), user
0x807c700 0x92616c0
(16.620117) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/directory.png (0x91db6a0), user
0x807c700 0x92e4bc0
(16.620204) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/directory.png (0x91db6a0), user
0x807c700 0x926d818
(16.620233) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/content.png (0x9369d48), user 0x807c700
0x926d7d8
(16.620262) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/content.png (0x9369d48), user 0x807c700
0x926d970
(16.620288) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/content.png (0x9369d48), user 0x807c700
0x926db20
(16.620315) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/content.png (0x9369d48), user 0x807c700
0x926db88
(16.620341) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/content.png (0x9369d48), user 0x807c700
0x926dbf0
(16.624771) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/icons/content.png (0x9369d48), user 0x807c700
0x92ec1d8
(16.625046) desktop/netsurf.c netsurf_exit 265: Closing search and
related resources
(16.625077) content/content.c content_remove_user 583: content
http://www.google.com/favicon.ico (0x935d5d0), user 0x807c700 0x931fcb8
(16.625105) desktop/netsurf.c netsurf_exit 268: Finalising high-level
cache
(16.625133) content/hlcache.c hlcache_finalise 161: 8 contents remain
before cache drain
(16.625162) content/content.c content_destroy 383: content 0x9391290
http://www.google.com/
(16.625189) render/html.c html_destroy 1997: content 0x9391290
(16.625544) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/gtkdefault.css (0x939d118), user 0x807c700
0x93a9e90
(16.625710) render/html.c html_destroy_objects 2074: object 0x9398ff8
(16.625744) content/content.c content_remove_user 583: content
http://www.google.com/images/srpr/nav_logo80.png (0x94358f0), user
0x807c700 0x9398ff8
(16.625812) render/html.c html_destroy_objects 2074: object 0x93bf828
(16.625839) content/content.c content_remove_user 583: content
http://www.google.com/images/srpr/nav_logo80.png (0x94358f0), user
0x807c700 0x93bf828
(16.625867) render/html.c html_destroy_objects 2074: object 0x939a388
(16.625894) content/content.c content_remove_user 583: content
http://www.google.com/intl/en_ALL/images/srpr/logo1w.png (0x9415688),
user 0x807c700 0x939a388
(16.626114) content/content.c content_destroy 383: content 0x935d5d0
http://www.google.com/favicon.ico
(16.626188) content/content.c content_destroy 383: content 0x9369d48
file:///usr/share/netsurf/icons/content.png
(16.626228) content/content.c content_destroy 383: content 0x91db6a0
file:///usr/share/netsurf/icons/directory.png
(16.626317) content/content.c content_destroy 383: content 0x94358f0
http://www.google.com/images/srpr/nav_logo80.png
(16.626851) content/content.c content_destroy 383: content 0x9415688
http://www.google.com/intl/en_ALL/images/srpr/logo1w.png
(16.626931) content/content.c content_destroy 383: content 0x939d118
file:///usr/share/netsurf/gtkdefault.css
(16.626960) content/content.c content_remove_user 583: content
file:///usr/share/netsurf/default.css (0x939ff70), user 0x807c700
0x9367108
(16.627049) content/content.c content_destroy 383: content 0x939ff70
file:///usr/share/netsurf/default.css
(16.627348) content/hlcache.c hlcache_finalise 175: 0 contents
remaining:
(16.627397) content/hlcache.c hlcache_finalise 211: hit/miss 11/8
(16.627422) content/hlcache.c hlcache_finalise 216: Finalising low-level
cache
(16.627478) desktop/netsurf.c netsurf_exit 271: Closing fetches
(16.627518) content/fetchers/data.c fetch_data_finalise 74:
fetch_data_finalise called for data
(16.627570) content/fetchers/curl.c fetch_curl_finalise 300: Finalise
cURL fetcher https
(16.627602) content/fetchers/curl.c fetch_curl_finalise 300: Finalise
cURL fetcher http
(16.627628) content/fetchers/curl.c fetch_curl_finalise 304: All cURL
fetchers finalised, closing down cURL
(16.628533) image/image_cache.c image_cache_fini 394: Size at finish 0
(in 0)
(16.628642) image/image_cache.c image_cache_fini 404: Age 10s
(16.628668) image/image_cache.c image_cache_fini 407: Peak size 299196
(in 4)
(16.628693) image/image_cache.c image_cache_fini 410: Peak image count 4
(size 299196)
(16.628718) image/image_cache.c image_cache_fini 426: Cache
total/hit/miss/fail (counts) 7/5/2/0 (100%/71%/28%/0%)
(16.628745) image/image_cache.c image_cache_fini 434: Cache
total/hit/miss/fail (size) 1083036/0/786152/0 (100%/296884%/0%/0%)
(16.628773) image/image_cache.c image_cache_fini 439: Total images never
rendered: 2 (includes 2 that were converted)
(16.628798) image/image_cache.c image_cache_fini 443: Total number of
excessive conversions: 0 (from 0 images converted more than once)
(16.628823) image/image_cache.c image_cache_fini 447: Bitmap of size
192384 had most (1) conversions
(16.628898) desktop/netsurf.c netsurf_exit 282: Closing utf8
(16.628929) desktop/netsurf.c netsurf_exit 285: Destroying URLdb
(16.629068) desktop/netsurf.c netsurf_exit 288: Destroying System
colours
(16.629111) desktop/netsurf.c netsurf_exit 291: Remaining lwc strings:
(16.629171) desktop/netsurf.c netsurf_exit 294: Exited successfully

--
http://www.fastmail.fm - Send your email first class

Re: [Rpcemu] Code not working correctly on RPCEmu

Hi Matthew,

I was looking at the RPCEmu repository today to see what changed
since the last official release and noticed that the fix below
did not find its way into the repository.

> -----Message d'origine-----
> De : mhowkins@gmail.com [mailto:mhowkins@gmail.com] De la part de
> Matthew Howkins
> Envoyé : dimanche 26 février 2012 21:05
> À : Timmermans, Andre
> Cc : rpcemu@riscos.info
> Objet : Re: [Rpcemu] Code not working correctly on RPCEmu
>
> > I have included an archive for testing.
> >
> > The BASIC code Filter conrains some assembler code
> > which takes the file IN and produces a file OUT
> > so it is better set te CSD before running it.
> >
> > The non-recompiling version of RPCEmu produces a file identical
> > to OUR_REF (te output on my RPC). The recompling version
> > does not. Since most of the time the filter seems to work fine
> > in the player that uses it (the sound seems OK), I am wondering
> > if the small amplitude of the signed 16-bit input samples
> > combined to the 24-25 bits in size filter parameters
> > puts them right on the 32-bit boundary and I am wondering
> > if it is not the 64bit addition part of the SMLAL which
> > is not emulated correctly (i.e. is the carry transmitted
> > correctly from the addition of the lower 32-bit registers
> > To the upper 32-bits?).
>
> Thanks for the test program - this enabled me to quickly narrow down
> the problem, and confirm that there were no other faults affecting
> this issue.
>
> The problem does indeed lie with SMLAL.
>
> Can you test by changing line 1181 of codegen_x86.c from
>
> addbyte(0x01); addbyte(0xCA); /*ADDL %ecx,%edx*/
>
> to
>
> addbyte(0x11); addbyte(0xCA); /*ADCL %ecx,%edx*/
>
> This works for me - can you confirm it works for you?
>
> Thanks
>
> Matthew

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Friday, 24 August 2012

Re: Performance on Debian Linux

On Fri, 24 Aug 2012 12:09:17 -0700, Wendell P wrote:

> Netsurf 2.9 Debian distribution on Debian Wheezy.
>
> On my machine, Chrome and Firefox each take 3s to boot, while Netsurf
> takes 6s. Is this typical or do you think there is something wrong?

Sounds a bit slow.

> Also, I sometimes get:
>
> "Netsurf in running out of memory.
> Please free some memory and try again."
>
> How do you free some memory?

The usual way? Actually that's a fairly generic error NetSurf throws
up which can be a bit of a red herring. What are you trying to do
when the error appears? Is it reproduceable? In which case, please
provide a test case so we can replicate (or at least see if it is
still an issue on the latest development version).

To diagnose both these issues a log file will be handy (start NetSurf
with "nsgtk -v").

Chris

Performance on Debian Linux

Netsurf 2.9 Debian distribution on Debian Wheezy.

On my machine, Chrome and Firefox each take 3s to boot, while Netsurf
takes 6s. Is this typical or do you think there is something wrong?

Also, I sometimes get:

"Netsurf in running out of memory.
Please free some memory and try again."

How do you free some memory?

--
http://www.fastmail.fm - Same, same, but different...

Thursday, 23 August 2012

Re: [gccsdk] Unaligned data access vs pack(push...

On Fri, Aug 24, 2012 at 01:03:05PM +1200, Ron wrote:
> The ARM_FEATURE_UNALIGNED reportedly will be on the latest gcc and
> can increase the compression speed by 50% on processors that support
> it (arm6 and higher I think)

I've just been writing the alignment exception configuration for Raspberry
Pi (ARMv6). Essentially there are 3 modes, on ARMv6 and ARMv7 controlled
by bit 22 (U) and bit 1 (A) of CP15 register C1.

Consider this code:
ADR r0,label
LDR r1,[r0,#2]
.label
DCD &01234567
DCD &89ABCDEF

1. ARMv2-5 or ARMv6 in rotated load emulation mode (A=0, U=0) return
r1=&45670123 This is not available on ARMv7.

2. ARMv6/ARMv7 with alignment exceptions on (A=1, U=don't care)
Cause an exception, instruction never completes

3. ARMv7 with alignment exceptions off (A=0), ARMv6 with exceptions off and
rotated loads off (A=0, U=1), return &456789AB

[I may have the endian-ness wrong on those]

If you want to use ARM_FEATURE_UNALIGNED, I assume you need to be in A=0,
U=1 mode for it to work. ie it will only work on ARMv6 and ARMv7 with
alignment exceptions off. BeagleBoard defaults to exceptions on.

So, unless you're willing to put in a test of A and U beforehand, your code
may break on new CPUs depending on how they are configured. The intention
is to ship a configure plugin with Raspberry Pi to set the mode, so you
can't assume what it will be.

For really critical things it may be worth including two copies of the key
functions, one with the option on and another with it off, but you'll have
to write something to switch at runtime yourself - it can't be a compiler
option. It could potentially be a switch between two shared libraries.

> I noticed a wiki on Endian with a list of OS's doesn't include
> RISC OS, perhaps someone knowledgible could add something there?

RISC OS is little endian, though that doesn't concern the above situation.
[Well, it does slightly; U=1 in the processor manual mentions something
about mixed endian support. I haven't looked at that]

> > One other config question is wether we support hardware bit counting,
> > in case that means something to anyone?

Well there's CLZ (count leading zeroes) in ARMv5 onwards, if that's what
they mean?

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

Re: [gccsdk] Unaligned data access vs pack(push...

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

> I am attempting to compile LZ4 compression, and the working binary
> doesn't get it's arithmetic right, decompressing declares corruption.
> The warnings
>
> warning: #pragma pack(push[, id], <n>) is not supported on this target
> warning: #pragma pack(pop[, id], <n>) is not supported on this target
>
> can be avoided by using -D__ARM_FEATURE_UNALIGNED but according to
> http://infocenter.arm.com/help/topic/com.arm.doc.dui0472c/BABFDBCJ.html
> this could be a problem for earlier than ARMv6 also.
>
> I'm not keen on starting on C++ stuff, This is a fairly small project,
> but requires manually configuring.
>
> One other config question is wether we support hardware bit counting,
> in case that means something to anyone?
>

I have found an arm patch for an older release (r33) that is working
on my Iyonix. I haven't tested it for speed yet.
It doesn't touch on the requirements that stops the trunk release.


The ARM_FEATURE_UNALIGNED reportedly will be on the latest gcc and
can increase the compression speed by 50% on processors that support
it (arm6 and higher I think)

LZ4 is supposed to be the fastest kid on the block, it is in
new linux kernels and can be enabled with some new file systems.

I noticed a wiki on Endian with a list of OS's doesn't include
RISC OS, perhaps someone knowledgible could add something there?

I found some endian tests. The Iyonix output the same as X86 for
short int but not long int. The test writer's arm (non RISCOS)
was actually different on short int's to the X86 also.
I'm sort of surprised I found a working solution so easily.

Thanks, Ron M.

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