Thursday, 31 August 2017

Re: [gccsdk] wget 1.19.1 tries to write a logfile

Ralph Corderoy, on 30 Aug, wrote:

> Hi Theo,
>
> > It is still worth commenting on upstream bug trackers - they won't
> > know what RISC OS is, but if the bug is not a RISC OS specific one
> > then the bug report is still relevant.
>
> It might be that RISC OS triggers it in a similar way to the odd set up
> on that bug report.
>
> src/log.c:
> 955 static void
> 956 check_redirect_output (void)
> 957 {
> 958 #ifndef WINDOWS
> 959 /* If it was redirected already to log file by SIGHUP, SIGUSR1
or -o parameter,
> 960 * it was permanent.
> 961 * If there was no SIGHUP or SIGUSR1 and shell is interactive
> 962 * we check if process is fg or bg before every line is
printed.*/
> 963 if (!redirect_request_signal_name && shell_is_interactive &&
!opt.lfilename)
> 964 {
> → 965 if (tcgetpgrp (STDIN_FILENO) != getpgrp ())
> 966 {
> 967 /* Process backgrounded */
> → 968 redirect_output (true,NULL);
> 969 }
>
> I haven't run this code, but I wonder if 965 is true. If Kevin is happy
> to modify the source and re-build then he might be able to tell that 968
> executes.

Perhaps this :-

https://fossies.org/diffs/wget/1.18_vs_1.19/ChangeLog-diff.html

2016-10-21 losgrandes <pwajda@gmail.net.pl>

Fixes #45790: wget prints it's progress even when background
* src/log.c: Use tcgetpgrp(STDIN_FILENO) != getpgrp() to determine when
to print to STD* or logfile.
Deprecate log_request_redirect_output function.
Use different file handles for STD* and logfile, to easily switch betwe en
them when changing fg/bg.
* src/log.h: Make redirect_output function externally linked.
* src/main.c: Don't use deprecated log_request_redirect_output function.
Use redirect_output instead.
* src/mswindows.c: Don't use deprecated log_request_redirect_output
function. Use redirect_output instead.
--
David Pitt

_______________________________________________
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] wget 1.19.1 tries to write a logfile

Kevin Wells, on 28 Aug, wrote:

> Hi
>
> When using wget 1.19.1 with the quiet option selected I get the
> following message:
>
> Redirecting output to 'wget-log.##'
>
> The ## is a number that increases each time.
>
> The file is a log of the connection details of wget.
>
> Previous versions did not display this.

Having done further tests I am seeing the apparently spurious
'wget-log' both with and without the '-q' flag. This is both with the
currency command line example given and a simple wget from my site.

*wget --version
GNU Wget 1.19.1 built on riscos.

*wget http://www.pittdj.co.uk/temp/temp.htm

Redirecting output to 'wget-log'.
*
*wget http://www.pittdj.co.uk/temp/temp.htm -q

Redirecting output to 'wget-log.1'.
*

The '-q' flag results in an empty 'wget-log' file.


Using wget 1.18, home built here with autobuilder revision 7118, the log
output defaults to the screen as expected with no redrection.

wget 1.19.1-3ubuntu1 on Ubuntu 17.10 (development branch) does not redirect
either.

FWIW HTH
--
David Pitt

_______________________________________________
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, 30 August 2017

Re: [gccsdk] wget 1.19.1 tries to write a logfile

Hi Theo,

> It is still worth commenting on upstream bug trackers - they won't
> know what RISC OS is, but if the bug is not a RISC OS specific one
> then the bug report is still relevant.

It might be that RISC OS triggers it in a similar way to the odd set up
on that bug report.

src/log.c:
955 static void
956 check_redirect_output (void)
957 {
958 #ifndef WINDOWS
959 /* If it was redirected already to log file by SIGHUP, SIGUSR1 or -o parameter,
960 * it was permanent.
961 * If there was no SIGHUP or SIGUSR1 and shell is interactive
962 * we check if process is fg or bg before every line is printed.*/
963 if (!redirect_request_signal_name && shell_is_interactive && !opt.lfilename)
964 {
→ 965 if (tcgetpgrp (STDIN_FILENO) != getpgrp ())
966 {
967 /* Process backgrounded */
→ 968 redirect_output (true,NULL);
969 }

I haven't run this code, but I wonder if 965 is true. If Kevin is happy
to modify the source and re-build then he might be able to tell that 968
executes.

--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

_______________________________________________
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] wget 1.19.1 tries to write a logfile

On 2017-08-29 18:23, Kevin Wells wrote:
> In message <mpro.ovgbl40050dql02nh.pittdj@pittdj.co.uk>
> David Pitt <pittdj@pittdj.co.uk> wrote:

>> Adding -o null: to the command line stops the unwanted wget-log
>> appearing.

> Thanks for that, so I guess the fix wil have to come from the upstream?
>
> I don't want to have to update about half a dozen of my applications if
> I don;t have to.

Would, say, renaming the binary to 'wget2' and defining an alias for
wget so
that it executes wget2 with the "-o null:" bit added get around that for
the
moment?

--
Jeremy Nicoll - my opinions are my own

_______________________________________________
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] wget 1.19.1 tries to write a logfile

On Tue, Aug 29, 2017 at 06:23:02PM +0100, Kevin Wells wrote:
> Thanks for that, so I guess the fix wil have to come from the upstream?

Yes. We don't generally have the manpower to curate patches that diverge
from upstream, apart from anything necessary to make it build on RISC OS.
We should be able, however, to turn around a new upstream build fairly
rapidly - so at such time that a new version is released we can produce a
new RISC OS build rapidly (though testing it is rather more difficult).

It is still worth commenting on upstream bug trackers - they won't know what
RISC OS is, but if the bug is not a RISC OS specific one then the bug report
is still relevant. Though it seems there has been no activity on this one
since it was reported in June.

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

Fwd: Re: Wy netsurf can render on amiga version from chris only if all is load. on windows show page earlier and later load images or other parts

in the amigaos includes dir in your inline dir, you need the new macros.h file (change jsr a6@(%1.w) to jsr -%1(a6)).work too on older gcc,because ggc use now motorola ASM output, thats standard on amiga.also gcc main source dont generate correct code when not use motorola output.



compile of the attached 4.3.2 sources.I test on cygwin with 3.4 compilers:



important do cd to objdir and objdir should be diffrent to source dir or build/gencodes.exe miss error come.

and the vars should set with

export OBJDIR=......

export SRCDIR=......



to your source and object dir.



now type



cd $OBJDIR

$SRCDIR/configure --target=m68k-amigaos --with-cpu=m68040 --prefix=/usr/local/amiga



when its done type



make



when its done



make install DESTDIR=xxxx



best use DESTDIR to a temporary dir, so you see what files are create.

create files are in xxxx/usr/local/amiga



thats all.



************************************************************ steps to build a amigaos GCC from sources from www.gcc.org ************************



Because 68k amiga OS is the only amiga target that is in ggc main source, it is easy to build every version you like.This steps are need



add in gcc-x.x.x/gcc/config.gcc



(search for m68k)



m68k-*-amigaos*)

tmake_file=m68k/t-amigaos

tm_file="${tm_file} m68k/amigaos.h"

tm_p_file="${tm_p_file} m68k/amigaos-protos.h"

tm_defines="TARGET_AMIGAOS TARGET_DEFAULT=0" # 68040

extra_objs=amigaos.o

gnu_ld=yes

;;





in gcc-x.x.x/gcc/config/m68k dir add files (from the 4.3.2 source)



amigaos.h

amigaos.c

t-amigaos

x-amigaos

xm-amigaos.h

amigaos-protos.h

host-amigaos.c



in dir gcc-x.x.x//gcc add file

amigacollect2.c



thats enough to build the gcc.more steps are need, to build the libs, libgcc libstdc++ when you want new



to build libgcc: add in libgcc/config.host 68k cpu and later amigaos.see file from 4.3.2 or use same.





the dir amigaos must add in libstdc++-v3/config (see 4.3.2 source)

now you can compile all.



when you get assembler error in atomicity.h change line with the cas so that, the \n is last char.

"cas.l %0 , %1 , %2 \n"



for build libstdc++ with the crosscompilers you need do this steps too



in libstdc++/configure



after (search for "GLIBCXX_IS_NATIVE=true")



""""

if test $hostos = $targetos -o $targetos = darwin ; then

GLIBCXX_IS_NATIVE=true

fi

;;

""""

add this lines



"""

*-*-amigaos*)

LDFLAGS="${LDFLAGS-ld} -noixemul"

;;

""""

search for "Base decisions on target environment"



""""

# Base decisions on target environment.

case "${host}" in

""""

add this lines

"""

m68k-*-amigaos*)

#os_include_dir="usr/local/amiga/m68k-amigaos/include"

;;

"""

in gccx.x.x/libiberty/configure



after this lines



""""

Use these variables to override the choices made by `configure' or to help

it to find libraries and programs with nonstandard names/locations.



_ACEOF

fi

""""

add this line



LDFLAGS="${LDFLAGS-ld} -noixemul"









if you want build without debug(-g ) type make "CFLAGS=-O2" "LIBCFLAGS=-O2" "LIBCXXFLAGS=-O2" (but dont work i find out)



if you dont like that the whole debug symbols are in the libs, then use strip -g dir(older gcc are build without complete symbols)

also you can choose in amidev in linker options that your program have no debug symbols.





*************************** build 68k to 68k gcc *************************************************************************************+

If you want build a GCC that run on 68k ( MOS OS4 Versions seem too possible, when you have installed the OS4 MOS crosscompilers on cygwin and you choose

---host- mos or OS4 identify)

you need this steps.



Add in file config.host this



m68k-*-amigaos*)

host_xm_file=m68k/xm-amigaos.h

host_xmake_file="${host_xmake_file} m68k/x-amigaos"

//host_xmake_file=m68k/x-amigaos

out_host_hook_obj=host-amigaos.o

;;



prefix /gg use older amiga build for geek gadget, so i use that too

make sure the new libnix is in dir libm020/libnix for best speed

$SRCDIR/configure --host=m68k-amigaos --target=m68k-amigaos --with-cpu=m68040 --prefix=/gg --disable-nls

copy file host-amigaos.c to gccxx/gcc/config/m68k



then type make.



when compile stop with auto-build.h not found, use the file auto-host.h as auto-build.h.thats ok for the 68k compiler build, but to compile full 68k files, use above files



To build gmp and mpfr library under crosscompiler for gcc that run on 68k(normaly not need, use 68k files in lib dir)



go to the dir



type

./configure --host=m68k-amigaos



now type make and look if the the right compiler is used (show 68k m68k-amigaos-gcc -D....)



*************************** binutil build **********************************************************



the binutil files (as,ld) come in usr/local/amiga/m68k-amigaos/bin



copy after this in file bfd/config.bfd



m68*-



this



m68k-*-amigaos)

targ_defvec=amiga_vec

targ_selvecs=aout_amiga_vec

;;



add this lines in file bfd/targets.c



extern const bfd_target amiga_vec;

extern const bfd_target aout_amiga_vec;



in file bfd/configure add after



for vec in $selvecs do

target_size=32

case "$vec" in



this lines.



amiga_vec) tb="$tb amigaos.o amigaoslink.o" ;;

aout_amiga_vec) tb="$tb aout-amiga.o aout32.o stab-syms.o";;



copy files from old binutil



amigaos.c

amigaoslink.c

aout-amiga.c

libamiga.h



to dir bfd



copy file amigaos.h to bfd/hosts



not work because of too old amiga files, to be continue....





every help/report is welcome, you can mail to me at nospamname@web.de-------- Original Message --------
From: Bernd R <nospamname@web.de>
Sent: 30 August 2017 10:00:38 BST
To: Chris Young <chris.young@unsatisfactorysoftware.co.uk>
Subject: Re: Wy netsurf can render on amiga version from chris only if all is load. on windows show page earlier and later load images or other parts

Hello Chris

the paths can change with compiler or linker options in makefile. i did not know what change your build have. My gcc port is too very simular to gcc build of other platforms and in the page i give you link, is instruction how can build easy.see attached files. on newer gcc the libs can not compile. there are no programs that need the new libs i know so far. teh build stop with error, after the important thing(the compilers is compile). many ports are done with the GCC 4.5 with full optimize, so it know as stable. but intresting to see if GCC 7.2 give more speed

maybe this build can work with netsurf too. i try to compile 7.2 and let you know. see how easy should possible to build a new version. work with 4.3.2 and 4.5. lets see if can work with 7.2 too



On 29.08.17, you wrote:

> On Tue, 29 Aug 2017 17:28:55 +0200, Bernd R wrote:
>
>> seem the mailing list not work
>> when it show earlier the page but flicker is better, because wait until all is load is boring. so how is it done in windows version ?
>>
>> > A patch to upgrade the toolchain to GCC 4.5 would be greatly
>> > appreciated.
>>
>> GCC 4.5 and 4.3.2 68k for cygwin host in windows you can download here
>>
>> https://sourceforge.net/projects/amiga/files/Compilers/
>>
>> on what system do you compile ?. I have done the 68k ports years
>> ago, and now i have install a vmware ubuntu 7 X64. If this is
>> usefull, i can try to compile gcc this for ubuntu 7.or can try to
>> run cygwin under wine on linux
>
> 64-bit Debian.
>
> GCC needs to be integrated into the toolchain:
> http://git.netsurf-browser.org/toolchains.git/tree/m68k-unknown-amigaos
>
> A "standalone" build of GCC is not helpful as the paths are different.
> When I upgraded to 3.4 I managed to mostly copy across the patches
> from https://github.com/cahirwpz/amigaos-cross-toolchain
> Most of the other ports I've seen for 68k (including a fork of that
> one for gcc6) are an entire repository with the changes integrated.
>
> Whilst that can theoretically be cloned and built within the
> toolchain, it's a pain to have to change everything to accomodate it
> only to have to switch everything around again when the next gcc port
> comes along by somebody else with different ideas on how it should be
> maintained.
>
> My preference would be to go as new as possible so it doesn't have to
> be done again for a long time.
> gcc6 is here: https://github.com/bebbo/gcc
>
> Chris
>
>
> ---
> Diese E-Mail wurde von AVG auf Viren geprüft.
> http://www.avg.com
>
Regards

Tuesday, 29 August 2017

Re: Wy netsurf can render on amiga version from chris only if all is load. on windows show page earlier and later load images or other parts

On Tue, 29 Aug 2017 17:28:55 +0200, Bernd R wrote:

> seem the mailing list not work
> when it show earlier the page but flicker is better, because wait until all is load is boring. so how is it done in windows version ?
>
> > A patch to upgrade the toolchain to GCC 4.5 would be greatly
> > appreciated.
>
> GCC 4.5 and 4.3.2 68k for cygwin host in windows you can download here
>
> https://sourceforge.net/projects/amiga/files/Compilers/
>
> on what system do you compile ?. I have done the 68k ports years
> ago, and now i have install a vmware ubuntu 7 X64. If this is
> usefull, i can try to compile gcc this for ubuntu 7.or can try to
> run cygwin under wine on linux

64-bit Debian.

GCC needs to be integrated into the toolchain:
http://git.netsurf-browser.org/toolchains.git/tree/m68k-unknown-amigaos

A "standalone" build of GCC is not helpful as the paths are different.
When I upgraded to 3.4 I managed to mostly copy across the patches
from https://github.com/cahirwpz/amigaos-cross-toolchain
Most of the other ports I've seen for 68k (including a fork of that
one for gcc6) are an entire repository with the changes integrated.

Whilst that can theoretically be cloned and built within the
toolchain, it's a pain to have to change everything to accomodate it
only to have to switch everything around again when the next gcc port
comes along by somebody else with different ideas on how it should be
maintained.

My preference would be to go as new as possible so it doesn't have to
be done again for a long time.
gcc6 is here: https://github.com/bebbo/gcc

Chris

Re: [gccsdk] wget 1.19.1 tries to write a logfile

In message <mpro.ovgbl40050dql02nh.pittdj@pittdj.co.uk>
David Pitt <pittdj@pittdj.co.uk> wrote:

>Kevin Wells, on 29 Aug, wrote:
>
>> In message <20170828221529.GK14778@chiark.greenend.org.uk> you wrote:
>>
>> >On Mon, Aug 28, 2017 at 09:25:44PM +0100, Kevin Wells wrote:
>> >> Hi
>> >>
>> >> When using wget 1.19.1 with the quiet option selected I get the
>> >> following message:
>> >>
>> >> Redirecting output to 'wget-log.##'
>> >>
>> >> The ## is a number that increases each time.
>> >>
>> >> The file is a log of the connection details of wget.
>> >>
>> >> Previous versions did not display this.
>> >
>> >What command line are you using?
>>
>*wget http://free.currencyconverterapi.com/api/v3/convert?q=GBP_GIP&compact=ultra-q -O RAM::RamDisc0.$.rate
>
>[snip]
>
>A quick Google might indicate this is a bug :-
>
>https://lists.gnu.org/archive/html/bug-wget/2017-06/msg00014.html
>
>or maybe a feature even :-
>
>https://www.makemkv.com/forum2/viewtopic.php?f=3&t=15885
>
>Adding -o null: to the command line stops the unwanted wget-log appearing.
>

Thanks for that, so I guess the fix wil have to come from the upstream?

I don't want to have to update about half a dozen of my applications if
I don;t have to.


--
Kev Wells
http://kevsoft.co.uk/
They sent me to the gallery or round the music-'alls,

_______________________________________________
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] wget 1.19.1 tries to write a logfile

Kevin Wells, on 29 Aug, wrote:

> In message <20170828221529.GK14778@chiark.greenend.org.uk> you wrote:
>
> >On Mon, Aug 28, 2017 at 09:25:44PM +0100, Kevin Wells wrote:
> >> Hi
> >>
> >> When using wget 1.19.1 with the quiet option selected I get the
> >> following message:
> >>
> >> Redirecting output to 'wget-log.##'
> >>
> >> The ## is a number that increases each time.
> >>
> >> The file is a log of the connection details of wget.
> >>
> >> Previous versions did not display this.
> >
> >What command line are you using?
>
*wget http://free.currencyconverterapi.com/api/v3/convert?q=GBP_GIP&compact=ultra-q -O RAM::RamDisc0.$.rate

[snip]

A quick Google might indicate this is a bug :-

https://lists.gnu.org/archive/html/bug-wget/2017-06/msg00014.html

or maybe a feature even :-

https://www.makemkv.com/forum2/viewtopic.php?f=3&t=15885

Adding -o null: to the command line stops the unwanted wget-log appearing.

--
David Pitt

_______________________________________________
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] wget 1.19.1 tries to write a logfile

In message <20170828221529.GK14778@chiark.greenend.org.uk> you wrote:

>On Mon, Aug 28, 2017 at 09:25:44PM +0100, Kevin Wells wrote:
>> Hi
>>
>> When using wget 1.19.1 with the quiet option selected I get the
>> following message:
>>
>> Redirecting output to 'wget-log.##'
>>
>> The ## is a number that increases each time.
>>
>> The file is a log of the connection details of wget.
>>
>> Previous versions did not display this.
>
>What command line are you using?

<*wget
http://free.currencyconverterapi.com/api/v3/convert?q=GBP_GIP&compact=ultra
-q
-O RAM::RamDisc0.$.rate>

The same error also appears on BASIC WIMP apps as well.

>
>What previous version do you have that had a different behaviour?

I used the package manager to update wget and forget the previous
version installed, but I think it was 1.17 something.

>
>I don't think anything has changed from the RISC OS perspective, so I
>suspect an upstream change. If we know some details we can have a look what
>happened.
>
>Theo


--
Kev Wells
http://kevsoft.co.uk/
Q: How do you make a dog drink? A: Put it in a liquidizer.

_______________________________________________
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, 28 August 2017

Re: [gccsdk] wget 1.19.1 tries to write a logfile

On Mon, Aug 28, 2017 at 09:25:44PM +0100, Kevin Wells wrote:
> Hi
>
> When using wget 1.19.1 with the quiet option selected I get the
> following message:
>
> Redirecting output to 'wget-log.##'
>
> The ## is a number that increases each time.
>
> The file is a log of the connection details of wget.
>
> Previous versions did not display this.

What command line are you using?

What previous version do you have that had a different behaviour?

I don't think anything has changed from the RISC OS perspective, so I
suspect an upstream change. If we know some details we can have a look what
happened.

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

[gccsdk] wget 1.19.1 tries to write a logfile

Hi

When using wget 1.19.1 with the quiet option selected I get the
following message:

Redirecting output to 'wget-log.##'

The ## is a number that increases each time.

The file is a log of the connection details of wget.

Previous versions did not display this.

Thanks.

--
Kev Wells
http://kevsoft.co.uk/
I went into a theatre as sober as could be,

_______________________________________________
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, 23 August 2017

Re: Form submission timeouts

On 15 Aug 2017 as I do recall,
Harriet Bazley wrote:

> On 11 Aug 2017 as I do recall,
> Dave Higton wrote:
>
> > The numbers and the symptoms fit with it being an MTU problem. I
> > had something like it a few years ago - unfortunately too long ago
> > for me to remember much about it or its solution.

[snip]

> It doesn't (mercifully) seem to affect Netsurf's form submission on any
> other sites (e.g. I can still post blog entries). Just pages on that one
> server/set of servers.
>
In fact, I'm still able to upload data of any length onto this same site
using the 'Drop file here' box (input type="file") - it's very specifically
the submission of form data via a multi-line text area in Netsurf that is
timing out.

--
Harriet Bazley == Loyaulte me lie ==

My opinions may have changed, but not the fact that I am right.

Tuesday, 22 August 2017

Re: Wy netsurf can render on amiga version from chris only if all is load. on windows show page earlier and later load images or other parts

On Tue, 22 Aug 2017 16:41:46 +0200, Bernd R wrote:

> I test netsurf windows 3.6 version and amiga os 68k on winuae
> version with the register page(link in netsurf default page)
> the text of the page is much earlier show and 4-5 sec later is show
> the top image. on the amiga version, the page is only show, when all
> images are load. I see no setting to change this

I'd be interested to know why this difference too. The GTK verson
appears to do the same as the Amiga one, and the Windows version is
very flickery when loading the page so it looks like it's redrawing
during load or something?

> BTW: the amiga version crash often, seem compile with GCC 3.4. GCC
> 3.4 is very buggy in C++. netsurf is no c++, but when a lib maybe
> use C++ code it can do random memtrash.use of GCC 4.5 on cygwin give
> good results.

A patch to upgrade the toolchain to GCC 4.5 would be greatly
appreciated.

Chris

Wy netsurf can render on amiga version from chris only if all is load. on windows show page earlier and later load images or other parts

Hi,

I test netsurf windows 3.6 version and amiga os 68k on winuae version with the register page(link in netsurf default page)
the text of the page is much earlier show and 4-5 sec later is show the top image. on the amiga version, the page is only show, when all images are load. I see no setting to change this

BTW: the amiga version crash often, seem compile with GCC 3.4. GCC 3.4 is very buggy in C++. netsurf is no c++, but when a lib maybe use C++ code it can do random memtrash.use of GCC 4.5 on cygwin give good results.



Bye

Wednesday, 16 August 2017

Re: [Rpcemu] rpcemu v01.5 - segmentationfault...

Ralph Corderoy <ralph@inputplus.co.uk> wrote:

> Hi David,
> > > > zed@zed-pc:~$ cd /home/zed/rpcemu-0.8.15/src CFLAGS=-no-pie
> > > > ./configure --enable-dynarec
> > >
> > > You've glued two separate commands together here.
> > >
> > > First do this: cd /home/zed/rpcemu-0.8.15/src
> > >
> > > Then do this: CFLAGS=-no-pie ./configure --enable-dynarec
> >
> > Thanks for your response. By now my email of 13 August will have
> > reached the rpcemu mailing list and you will see that David Pitt's
> > suggestion worked.
>
> Yes, but we're trying to explain what you did wrong so you know for next
> time. Especially as you didn't merge the two commands when you
> initially successfully got it to configure before asking the list for
> help so it seems odd to merge them afterwards.
>
> You were doing the equivalent of
>
> *Dir $.home.zed.rpcemu-0.8.15.src
> *Run configure
>
> as
>
> *Dir $.home.zed.rpcemu-0.8.15.src Run configure

Thanks for the explanation. I hope I do better if I ever need to install
rpcemu again. Certainly this exchange of emails has been saved and will
be available for guidance if a reinstallation is ever necessary. Thank
goodness.

I do appreciate that you, David Pitt and David Glover-Aoki were willing to
give you time to help me and, as a result I have a working rpcemu.

Regards from Waipapa, New Zealand on a rainy and windy Wednesday evening.

David




--
zed
Divorce, n. The past tense of marriage


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

Tuesday, 15 August 2017

Re: Form submission timeouts

On 11 Aug 2017 as I do recall,
Rob Kendrick wrote:

[snip]


> Something that has bitten be before is where automatic path MTU
> discovery does not work (and I suspect it doesn't on RISC OS), and your
> ISP does not support end-to-end 1500 byte MTUs (many do not).
>
> The solution is to set your whole LAN's MTU to 1400 or similar, although
> setting it only on the RISC OS machines may be sufficient (and not
> needed on VirtualAcorn because that proxies Windows's IP stack which is
> full-featured and conforming) assuming the problem is only sending large
> packets, not receiving them.
>

I wouldn't know where to configure that, I'm afraid; the network consists
of Ethernet cables emerging from our Virgin Hub and plugging into the RISC
OS computers and the printer.


--
Harriet Bazley == Loyaulte me lie ==

I like work; it fascinates me; I can sit and look at it for hours.

Re: Form submission timeouts

On 11 Aug 2017 as I do recall,
Dave Higton wrote:

[snip]

> I apologies that my response here won't be as useful as I want it to
> be.
>
> The numbers and the symptoms fit with it being an MTU problem. I
> had something like it a few years ago - unfortunately too long ago
> for me to remember much about it or its solution.
>
> Has anything changed recently about your internet provision (e.g. a
> new router, or service from a new provider), or something about the
> platform from which you're sending?

Nothing whatsoever has changed at this end. And that one specific site just
stopped working overnight, with no announcement of any changes and no new
features appearing.

It doesn't (mercifully) seem to affect Netsurf's form submission on any
other sites (e.g. I can still post blog entries). Just pages on that one
server/set of servers.


--
Harriet Bazley == Loyaulte me lie ==

Cole's Law: Thinly sliced cabbage.

Monday, 14 August 2017

Re: [Rpcemu] rpcemu v01.5 - segmentationfault...

Hi David,
> > > zed@zed-pc:~$ cd /home/zed/rpcemu-0.8.15/src CFLAGS=-no-pie
> > > ./configure --enable-dynarec
> >
> > You've glued two separate commands together here.
> >
> > First do this: cd /home/zed/rpcemu-0.8.15/src
> >
> > Then do this: CFLAGS=-no-pie ./configure --enable-dynarec
>
> Thanks for your response. By now my email of 13 August will have reached
> the rpcemu mailing list and you will see that David Pitt's suggestion
> worked.

Yes, but we're trying to explain what you did wrong so you know for next
time. Especially as you didn't merge the two commands when you
initially successfully got it to configure before asking the list for
help so it seems odd to merge them afterwards.

You were doing the equivalent of

*Dir $.home.zed.rpcemu-0.8.15.src
*Run configure

as

*Dir $.home.zed.rpcemu-0.8.15.src Run configure

--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

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

Sunday, 13 August 2017

Re: [Rpcemu] rpcemu v01.5 - segmentationfault...

Hi David


David Glover-Aoki <me@davidglover.org> wrote:

> On Aug 12, 2017, at 8:25 PM, zed <zed@zed.net.nz> wrote:
> >
> > zed@zed-pc:~$ cd /home/zed/rpcemu-0.8.15/src CFLAGS=-no-pie
> > ./configure --enable-dynarec
>
> You've glued two separate commands together here.
>
> First do this: cd /home/zed/rpcemu-0.8.15/src
>
> Then do this: CFLAGS=-no-pie ./configure --enable-dynarec
>

Thanks for your response. By now my email of 13 August will have reached
the rpcemu mailing list and you will see that David Pitt's suggestion
worked.

David
--
zed
Despite the high cost of living, it remains popular


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

Re: [Rpcemu] rpcemu v01.5 - segmentationfault...

On Aug 12, 2017, at 8:25 PM, zed <zed@zed.net.nz> wrote:
>
> zed@zed-pc:~$ cd /home/zed/rpcemu-0.8.15/src CFLAGS=-no-pie ./configure
> --enable-dynarec

You've glued two separate commands together here.

First do this:
cd /home/zed/rpcemu-0.8.15/src

Then do this:
CFLAGS=-no-pie ./configure --enable-dynarec

--
David Glover-Aoki
https://david.gloveraoki.net/contact


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

Saturday, 12 August 2017

Re: [Rpcemu] rpcemu v01.5 - segmentationfault...

Ralph Corderoy <ralph@inputplus.co.uk> wrote:

[snip]
> > Went to the website suggested and did as suggested (CFLAGS=-no-pie
> > ./configure --enable-dynarec --enable-debug) and got a response too
> > many arguments but unfortunately did not save the output.
>
> That response doesn't make a lot of sense, unless you're using some
> weird shell. Does `echo $BASH_VERSION' display a useful
> version-number-ish value?

zed@zed-pc:~$ echo $BASH_VERSION
4.4.12(1)-release
zed@zed-pc:~$

and then

zed@zed-pc:~$ cd /home/zed/rpcemu-0.8.15/src CFLAGS=-no-pie ./configure
--enable-dynarec
bash: cd: too many arguments
zed@zed-pc:~$

So, again, I'mlost!

> > I then tried without the configuration options (i.e. just the
> > CFLAGS=-no-pie)
>
> That would just set a variable in your shell. Not an error, but no
> desired effect.

Glad that it didn't result in something which would bite me later.

> > zed@zed-pc:~$ cd /home/zed/rpcemu-0.8.15 zed@zed-pc:~/rpcemu-0.8.15$
> > CFLAGS=-no-pie ./configure --enable-dynarec --enable-debug bash:
> > ./configure: No such file or directory
>
> Yes, start again. You said at
> http://www.riscos.info/pipermail/rpcemu/2017-August/002526.html that you
> configured it just fine. You need to repeat that, but with
> `CFLAGS=-no-pie' as a word before the ./configure.

I did that and got the

bash: cd: too many arguments yet again

I then deleted the copy of rpcemu-0.8.15 and made another from my
Downloads Directory to /home/zed

Decided to try David's option

zed@zed-pc:~$ cd /home/zed/Desktop/rpcemu-0.8.15/src
zed@zed-pc:~/Desktop/rpcemu-0.8.15/src$ ./configure CFLAGS=-no-pie
--enable-dynarec

zed@zed-pc:~/Desktop/rpcemu-0.8.15/src$ cd ..
zed@zed-pc:~/Desktop/rpcemu-0.8.15$ ./rpcemu
zed@zed-pc:~/Desktop/rpcemu-0.8.15$

and I have a working rpcemu.

Thank you Roy, for putting up with my "fumblings" and David for suggesting
I enter the source directory and enter ./configure before the CFLAGS
option which worked. Obviously the originasl suggestion on the Maratun
website must work for others but just did not on Sparky Linux on my
computer, for some reason. Whatever, I am grateful to both of you for
leading me to a successful conclusion.

The most pressing question, at present, is: Is there any way to run rpcemu
other than through the terminal?

There will be many other questions from me in my attempt to re-learn RISC
OS (like how to enlarge the window which opens. How to change the screen
resolution, etc. etc but for the present, I'm like a "dog with two tails -
both wagging furiously"!

David

--
zed
Bigamy: Too many wives. Monogamy: Same thing.


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

Re: [Rpcemu] rpcemu v01.5 - segmentationfault...

Hi David,

> > https://marutan.net/rpcemu/linuxcompile.html has a note at the start
> > about Ubuntu 16.10 needing CFLAGS=-no-pie. I suspect this may now be
> > true of Debian also. So try that, going back to the configure stage.
>
> Went to the website suggested and did as suggested (CFLAGS=-no-pie
> ./configure --enable-dynarec --enable-debug) and got a response
> too many arguments
> but unfortunately did not save the output.

That response doesn't make a lot of sense, unless you're using some
weird shell. Does `echo $BASH_VERSION' display a useful
version-number-ish value?

> I then tried without the configuration options (i.e. just the
> CFLAGS=-no-pie)

That would just set a variable in your shell. Not an error, but no
desired effect.

> I then started again and got the following output
>
> zed@zed-pc:~$ cd /home/zed/rpcemu-0.8.15
> zed@zed-pc:~/rpcemu-0.8.15$ CFLAGS=-no-pie ./configure --enable-dynarec --enable-debug
> bash: ./configure: No such file or directory

Yes, start again. You said at
http://www.riscos.info/pipermail/rpcemu/2017-August/002526.html that you
configured it just fine. You need to repeat that, but with
`CFLAGS=-no-pie' as a word before the ./configure.

When you're entering `./configure' you are asking to run the file
configure in the current directory, `.'. So a plain `ls' should show
the current directory's contents, including configure.

--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

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

Re: [Rpcemu] rpcemu v01.5 - segmentationfault...

zed, on 12 Aug, wrote:

[snip]

> All suggestions welcome.

A google suggested this syntax, which did produce a working build on Ubuntu
17.04.

cd src
./configure CFLAGS=-no-pie --enable-dynarec
make
cd ..
./rpcemu

No errors, RISC OS running.

HTH.
--
David Pitt

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

Friday, 11 August 2017

Re: [Rpcemu] rpcemu v01.5 - segmentationfault...

Hi Ralph


Ralph Corderoy <ralph@inputplus.co.uk> wrote:

> Hi David,
>
> >
https://wiki.archlinux.org/index.php/Step-by-step_debugging_guide#Segmentation_faults
> >
> > and read about rdb and then ran the command. Here is the result of my
> > attempt to do something correctly!
>
> Yep, you did it right.

Thank goodness for that!

[snip]
> > Thread 1 "rpcemu" received signal SIGSEGV, Segmentation fault.
> > 0x00005555570becba in rcodeblock () (gdb) bt full #0
> > 0x00005555570becba in rcodeblock () No symbol table info available. #1
> > 0x00007fffffffdf70 in ?? () No symbol table info available. #2
> > 0x0000000000000000 in ?? () No symbol table info available. (gdb)
>
> I think this is saying the fault occurs in the generated-on-the-fly
> machine code to emulate some ARM instructions, so I wouldn't expect that
> next section on "more detail" to help.
>
> https://marutan.net/rpcemu/linuxcompile.html has a note at the start
> about Ubuntu 16.10 needing CFLAGS=-no-pie. I suspect this may now be
> true of Debian also. So try that, going back to the configure stage.

Went to the website suggested and did as suggested (CFLAGS=-no-pie
./configure --enable-dynarec --enable-debug)and got a response

too many arguments

but unfortunately did not save the output.

I then tried without the configuration options (i.e. just the
CFLAGS=-no-pie) and was returned to

zed@zed-pc:~/rpcemu-0.8.15$ CFLAGS=-no-pie

I then started again and got the following output

zed@zed-pc:~$ cd /home/zed/rpcemu-0.8.15
zed@zed-pc:~/rpcemu-0.8.15$ CFLAGS=-no-pie ./configure --enable-dynarec
--enable-debug
bash: ./configure: No such file or directory
zed@zed-pc:~/rpcemu-0.8.15$ ./configure --enable-dynarec --enable-debug
bash: ./configure: No such file or directory
zed@zed-pc:~/rpcemu-0.8.15$

Would the fact that I did

zed@zed-pc:~/rpcemu-0.8.15$ CFLAGS=-no-pie

have led to the output of No such file or directory?

I have checked and found that doing a cd <directory path> works on every
other Directory I've tried, other than /rpcemu-0.8.15 one.

As an aside, I have Linux Mint v18.2 Mate installed in another partition.
I booted into this and had no difficulty in installing rpcemu-0.8.15,
other than that the window which opened was very small and I could not
adjust it and there was only one screen resolution available. I was able
to run !Draw and Paint! without problem, but could not open a floppy disc
containing !Drawfiles. Just got an error asking whether the disc was
formatted! That could be because when I upgraded this desktop a few years
ago, I've never checked whether the floppy disc drive was connected.

Again, thank you for staying with this. All suggestions welcome.

Regards

David


--
zed
A friendly" program doesn't have a 600 page manual!


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

Re: Form submission timeouts

In article <20170811163021.GK7481@platypus.pepperfish.net>, Rob Kendrick
<rjek@netsurf-browser.org> wrote:
> On Fri, Aug 11, 2017 at 05:16:09PM +0100, Dave Higton wrote:
> >
> > If anyone reading this thread can shed any light on MTU issues, how
> > to diagnose them and how to fix them, it would be very helpful.

> Something that has bitten be before is where automatic path MTU
> discovery does not work (and I suspect it doesn't on RISC OS), and your
> ISP does not support end-to-end 1500 byte MTUs (many do not).

> The solution is to set your whole LAN's MTU to 1400 or similar,
> although setting it only on the RISC OS machines may be sufficient (and
> not needed on VirtualAcorn because that proxies Windows's IP stack
> which is full-featured and conforming) assuming the problem is only
> sending large packets, not receiving them.

I find it fascinating that my ISP's web support MTU is variously 1454,
1458, 1492 and 1500. This is dependent on hardware - the last one being a
generic setting for 'none of the above routers'.

Funny how the original 'net developers opted for and MTU of around 1500.
Anyone who's had a computer for more than a few weeks ought to wonder why
it's not 1024.

--

Tim Hill

timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk

Re: Form submission timeouts

On Fri, Aug 11, 2017 at 05:16:09PM +0100, Dave Higton wrote:
>
> If anyone reading this thread can shed any light on MTU issues,
> how to diagnose them and how to fix them, it would be very
> helpful.

Something that has bitten be before is where automatic path MTU
discovery does not work (and I suspect it doesn't on RISC OS), and your
ISP does not support end-to-end 1500 byte MTUs (many do not).

The solution is to set your whole LAN's MTU to 1400 or similar, although
setting it only on the RISC OS machines may be sufficient (and not
needed on VirtualAcorn because that proxies Windows's IP stack which is
full-featured and conforming) assuming the problem is only sending large
packets, not receiving them.

B.

Re: Form submission timeouts

In message <9ceaa96956.harriet@blueyonder.co.uk>
Harriet Bazley <lists@bazleyfamily.co.uk> wrote:

>On 9 Aug 2017 as I do recall,
> Harriet Bazley wrote:
>
>> Currently I just get a time-out error after about twenty seconds if I
>> attempt to send messages of over 1,485 characters via a PM or a post of
>> more than 1,343 characters to a forum.
>
>I've since discovered that the site's document-editing feature is timing out
>as well. Previously it was possible to do basic editing on the raw HTML of
>a previously submitted document via Netsurf - now you can edit but can't
>save the result. I haven't bothered testing to see what the triggering
>length on this feature is since an HTML page of under 1K in total length is
>never going to be of much use in practice...
>
>So it looks as if all multi-line text icons are being affected.

I apologies that my response here won't be as useful as I want it to
be.

The numbers and the symptoms fit with it being an MTU problem. I
had something like it a few years ago - unfortunately too long ago
for me to remember much about it or its solution.

Has anything changed recently about your internet provision (e.g. a
new router, or service from a new provider), or something about the
platform from which you're sending?

I used to think that the MTU had no practical effect - above this
value, packets would be automatically fragmented and equally
automatically re-assembled. But my lesson was that it doesn't
work like I thought.

You might try looking at the various interfaces along the network
to see if the MTU of any of them can be altered.

If anyone reading this thread can shed any light on MTU issues,
how to diagnose them and how to fix them, it would be very
helpful.

Dave

Re: [Rpcemu] rpcemu v01.5 - segmentationfault...

Hi David,

> https://wiki.archlinux.org/index.php/Step-by-step_debugging_guide#Segmentation_faults
>
> and read about rdb and then ran the command. Here is the result of my
> attempt to do something correctly!

Yep, you did it right.

> (gdb) r
> Starting program: /home/zed/rpcemu-0.8.15/rpcemu
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7ffff4afc700 (LWP 21629)]
> [New Thread 0x7ffff41ed700 (LWP 21630)]
> [New Thread 0x7ffff28be700 (LWP 21631)]
> [New Thread 0x7ffff20bd700 (LWP 21632)]
> [New Thread 0x7fffe59ea700 (LWP 21633)]
> [Thread 0x7fffe59ea700 (LWP 21633) exited]
> [New Thread 0x7fffe59ea700 (LWP 21634)]
> [New Thread 0x7fffe4fe3700 (LWP 21635)]
>
> Thread 1 "rpcemu" received signal SIGSEGV, Segmentation fault.
> 0x00005555570becba in rcodeblock ()
> (gdb) bt full
> #0 0x00005555570becba in rcodeblock ()
> No symbol table info available.
> #1 0x00007fffffffdf70 in ?? ()
> No symbol table info available.
> #2 0x0000000000000000 in ?? ()
> No symbol table info available.
> (gdb)

I think this is saying the fault occurs in the generated-on-the-fly
machine code to emulate some ARM instructions, so I wouldn't expect that
next section on "more detail" to help.

https://marutan.net/rpcemu/linuxcompile.html has a note at the start
about Ubuntu 16.10 needing CFLAGS=-no-pie. I suspect this may now be
true of Debian also. So try that, going back to the configure stage.

--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

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

Thursday, 10 August 2017

Re: Form submission timeouts

On 9 Aug 2017 as I do recall,
Harriet Bazley wrote:

> Currently I just get a time-out error after about twenty seconds if I
> attempt to send messages of over 1,485 characters via a PM or a post of
> more than 1,343 characters to a forum.

I've since discovered that the site's document-editing feature is timing out
as well. Previously it was possible to do basic editing on the raw HTML of
a previously submitted document via Netsurf - now you can edit but can't
save the result. I haven't bothered testing to see what the triggering
length on this feature is since an HTML page of under 1K in total length is
never going to be of much use in practice...

So it looks as if all multi-line text icons are being affected.

--
Harriet Bazley == Loyaulte me lie ==

"An American is a man with two arms and four wheels".

Re: [Rpcemu] rpcemu v01.5 - segmentationfault...

Ralph Corderoy <ralph@inputplus.co.uk> wrote:

> Hi David,
>
> > $ ./rpcemu Shutting down Allegro due to signal #11 Segmentation fault
> > $
>
>
https://wiki.archlinux.org/index.php/Step-by-step_debugging_guide#Segmentation_faults
> shows how to `bt full' since it seems you're not used to gdb(1). That
> gives us the first clue what might be going on.

Hi Ralph

Thank you for your very prompt reply.

I visited
https://wiki.archlinux.org/index.php/Step-by-step_debugging_guide#Segmentation_faults

and read about rdb and then ran the command. Here is the result of my
attempt to do something correctly!
------------------------------------------------------------------------------------------------
Terminal output

zed@zed-pc:~$ cd /home/zed/rpcemu-0.8.15
zed@zed-pc:~/rpcemu-0.8.15$ gdb ./rpcemu
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./rpcemu...done.
(gdb) r
Starting program: /home/zed/rpcemu-0.8.15/rpcemu
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff4afc700 (LWP 21629)]
[New Thread 0x7ffff41ed700 (LWP 21630)]
[New Thread 0x7ffff28be700 (LWP 21631)]
[New Thread 0x7ffff20bd700 (LWP 21632)]
[New Thread 0x7fffe59ea700 (LWP 21633)]
[Thread 0x7fffe59ea700 (LWP 21633) exited]
[New Thread 0x7fffe59ea700 (LWP 21634)]
[New Thread 0x7fffe4fe3700 (LWP 21635)]

Thread 1 "rpcemu" received signal SIGSEGV, Segmentation fault.
0x00005555570becba in rcodeblock ()
(gdb) bt full
#0 0x00005555570becba in rcodeblock ()
No symbol table info available.
#1 0x00007fffffffdf70 in ?? ()
No symbol table info available.
#2 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb)
---------------------------------------------------------------------
which means nothing whatsoever to me - way beyond my paygrade!

Neither did I understand the instructions which followed "Improved gdb
output" on the website, so seek your further assistance, please?

I have three allegro packages installed:
libjpgallwegro4.4 v2.2.2.2-10
liballegro4-dev v2.4.4.2-10
liballegro4.4 v2.4.4.2-10

David

--
zed
CURSOR: An expert in four-letter words.


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

Re: [Rpcemu] rpcemu v01.5 - segmentationfault...

Hi David,

> $ ./rpcemu
> Shutting down Allegro due to signal #11
> Segmentation fault
> $

https://wiki.archlinux.org/index.php/Step-by-step_debugging_guide#Segmentation_faults
shows how to `bt full' since it seems you're not used to gdb(1). That
gives us the first clue what might be going on.

--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

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

Wednesday, 9 August 2017

[Rpcemu] rpcemu v01.5 - segmentationfault...

rpcemu v0.15 on SparkyLinux v5.0 (Debian Testing)

rpcemu extracted and configured with --enable-dynarec --enable-debug.
make went through the process with no errors.

First run, as expected, as no ROMS installed. Installed 4.02roms in the
roms Directory and RO4disc,ff8 in the Directory hostfs and then:

zed@zed-pc:~$ cd /home/zed/rpcemu-0.8.15
zed@zed-pc:~/rpcemu-0.8.15$ ./rpcemu
Shutting down Allegro due to signal #11
Segmentation fault
zed@zed-pc:~/rpcemu-0.8.15$

Your advice is sought, please?

David
--
zed
Smoking kills. If you're killed, you've lost a very important part of your
life.


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

Re: Form submission timeouts

On 10 Aug 2017 as I do recall,
Harriet Bazley wrote:

[snip]


> (12.430000) desktop/browser.c:2105 browser_window_navigate: Loading 'https://www.fanfiction.net/pm2/post.php?rid=218867318'
> (12.430000) content/fetchers/curl.c:324 fetch_curl_setup: fetch 0x749465b0, url 'https://www.fanfiction.net/pm2/post.php?rid=218867318'
> (20.060000) content/content.c:382 content_destroy: content 0x748be850 https://www.fanfiction.net/static/images/favicon_2010_site.ico
> (44.200000) content/fetchers/curl.c:867 fetch_curl_process_headers: HTTP status code 200
> (44.220000) content/fetchers/curl.c:1040 fetch_curl_done: done https://www.fanfiction.net/pm2/post.php?rid=218867318
> (44.220000) content/fetchers/curl.c:799 fetch_curl_stop: fetch 0x749465b0, url 'https://www.fanfiction.net/pm2/post.php?rid=218867318'
> (44.230000) content/content.c:76 content__init: url https://www.fanfiction.net/pm2/post.php?rid=218867318 -> 0x747c9b40
>
> The first 8 seconds are me dropping my pre-prepared message into the reply
> form; the next 24 seconds are the browser waiting for curl to fetch; after
> that, it's busy rendering the error page. :-(
>
Here's the equivalent section of log after truncating the message and
posting it successfully:

(16.660000) desktop/browser.c:2006 browser_window_navigate: bw 0x7473dc80, url https://www.fanfiction.net/pm2/post.php?rid=218867318
(16.670000) desktop/browser.c:2105 browser_window_navigate: Loading 'https://www.fanfiction.net/pm2/post.php?rid=218867318'
(16.670000) content/fetchers/curl.c:324 fetch_curl_setup: fetch 0x74cc62d8, url 'https://www.fanfiction.net/pm2/post.php?rid=218867318'
(17.140000) content/fetchers/curl.c:867 fetch_curl_process_headers: HTTP status code 200
(17.140000) content/content.c:76 content__init: url https://www.fanfiction.net/pm2/post.php?rid=218867318 -> 0x748bc830


--
Harriet Bazley == Loyaulte me lie ==

Questions are a burden to others, but answers are a prison for oneself.

Re: Form submission timeouts

On 9 Aug 2017 as I do recall,
Chris Young wrote:

> On 09/08/2017 17:21, Harriet Bazley wrote:
> > Over the last couple of days, Netsurf has unexpectedly started timing-out
> > when you attempt to send messages of more than a certain length via the
> > www.fanfiction.net website, either via the user forums or the PM system.

[snip]

> > I've looked at Netsurf's logs, but the failed attempts aren't showing any
> > error messages other than a 20-second gap. There were site-wide problems
> > with the forums recently, but this particular issue doesn't seem to be
> > affecting anybody else.
> >
> > Do these specific byte lengths suggest anything to anyone?
> >
> >
> Maybe similar to http://bugs.netsurf-browser.org/mantis/view.php?id=2252 ?
> Set suppress_curl_debug:0 in Choices and have another look at the log file.
>
It does sound a bit similar, but the only effect of setting
suppress_curl_debug:0 appears to have been to lengthen the timeout period:

(12.430000) desktop/browser.c:2105 browser_window_navigate: Loading 'https://www.fanfiction.net/pm2/post.php?rid=218867318'
(12.430000) content/fetchers/curl.c:324 fetch_curl_setup: fetch 0x749465b0, url 'https://www.fanfiction.net/pm2/post.php?rid=218867318'
(20.060000) content/content.c:382 content_destroy: content 0x748be850 https://www.fanfiction.net/static/images/favicon_2010_site.ico
(44.200000) content/fetchers/curl.c:867 fetch_curl_process_headers: HTTP status code 200
(44.220000) content/fetchers/curl.c:1040 fetch_curl_done: done https://www.fanfiction.net/pm2/post.php?rid=218867318
(44.220000) content/fetchers/curl.c:799 fetch_curl_stop: fetch 0x749465b0, url 'https://www.fanfiction.net/pm2/post.php?rid=218867318'
(44.230000) content/content.c:76 content__init: url https://www.fanfiction.net/pm2/post.php?rid=218867318 -> 0x747c9b40

The first 8 seconds are me dropping my pre-prepared message into the reply
form; the next 24 seconds are the browser waiting for curl to fetch; after
that, it's busy rendering the error page. :-(

--
Harriet Bazley == Loyaulte me lie ==

Radioactive cats have 18 half-lives.

Re: Form submission timeouts

In article <99b0fa6856.harriet@blueyonder.co.uk>, Harriet Bazley
<lists@bazleyfamily.co.uk> wrote:
> Do these specific byte lengths suggest anything to anyone?

MTU. Though how can that...?

--

Tim Hill

timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk

Re: Form submission timeouts

On 09/08/2017 17:21, Harriet Bazley wrote:
> Over the last couple of days, Netsurf has unexpectedly started timing-out
> when you attempt to send messages of more than a certain length via the
> www.fanfiction.net website, either via the user forums or the PM system.
> PMs have an official site limit of 8000 characters (and I've successfully
> sent messages of up to this length before) and so far as I recall the forum
> post size limit is 9,999 characters.
>
> Currently I just get a time-out error after about twenty seconds if I
> attempt to send messages of over 1,485 characters via a PM or a post of
> more than 1,343 characters to a forum. This is quite limiting when
> attempting to reply to other users -- especially as the site rules prohibit
> sending more than one post in succession!
>
> ----------------------------------------------------------------------------
> Request Timeout
>
> This request took too long to process, it has been timed out by the server.
> If it should not be timed out, please contact the administrator of the
> website to increase the 'Connection Timeout' time allotted.
> ----------------------------------------------------------------------------
>
> I've looked at Netsurf's logs, but the failed attempts aren't showing any
> error messages other than a 20-second gap. There were site-wide problems
> with the forums recently, but this particular issue doesn't seem to be
> affecting anybody else.
>
> Do these specific byte lengths suggest anything to anyone?
>
>
Maybe similar to http://bugs.netsurf-browser.org/mantis/view.php?id=2252 ?
Set suppress_curl_debug:0 in Choices and have another look at the log file.

Chris

Form submission timeouts

Over the last couple of days, Netsurf has unexpectedly started timing-out
when you attempt to send messages of more than a certain length via the
www.fanfiction.net website, either via the user forums or the PM system.
PMs have an official site limit of 8000 characters (and I've successfully
sent messages of up to this length before) and so far as I recall the forum
post size limit is 9,999 characters.

Currently I just get a time-out error after about twenty seconds if I
attempt to send messages of over 1,485 characters via a PM or a post of
more than 1,343 characters to a forum. This is quite limiting when
attempting to reply to other users -- especially as the site rules prohibit
sending more than one post in succession!

----------------------------------------------------------------------------
Request Timeout

This request took too long to process, it has been timed out by the server.
If it should not be timed out, please contact the administrator of the
website to increase the 'Connection Timeout' time allotted.
----------------------------------------------------------------------------

I've looked at Netsurf's logs, but the failed attempts aren't showing any
error messages other than a 20-second gap. There were site-wide problems
with the forums recently, but this particular issue doesn't seem to be
affecting anybody else.

Do these specific byte lengths suggest anything to anyone?


--
Harriet Bazley == Loyaulte me lie ==

"An American is a man with two arms and four wheels".

Tuesday, 1 August 2017

Re: Browser ID/User Agent

On Tue, Aug 01, 2017 at 09:40:57PM +0100, John Williams wrote:
>
> I've been doing some stuff recently with browser ID strings, and find that
> it is quite complicated!
>
> There is stuff called Mozilla compatibility, platform, platform details,
> specific enhancements etcetera! All very difficult to untangle!
>
> But NetSurf (RISC OS) resolutely reports itself as:
>
> NetSurf/3.7 (RISC OS)
>
> which isn't terribly helpful/compatible with the likes of, for instance:
>
> Mozilla/5.0 (Linux; Android 6.0.1; SAMSUNG SM-T550 Build/MMB29M)
> AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/4.0
> Chrome/44.0.2403.133 Safari/537.36
>
> Observations, please!

http://git.netsurf-browser.org/netsurf.git/tree/Makefile.defaults#n79

All the accreted nonsense in the UA string you site from your phone is
because websites used UA sniffing to decide what to serve, and then web
browsers needed to lie in order to be compatible. It was an endless
cycle.

B.

Re: Browser ID/User Agent

On Tue, Aug 01, 2017 at 21:40:57 +0100, John Williams wrote:
>
> I've been doing some stuff recently with browser ID strings, and find that
> it is quite complicated!
>
> There is stuff called Mozilla compatibility, platform, platform details,
> specific enhancements etcetera! All very difficult to untangle!
>
> But NetSurf (RISC OS) resolutely reports itself as:
>
> NetSurf/3.7 (RISC OS)
>
> which isn't terribly helpful/compatible with the likes of, for instance:
>
> Mozilla/5.0 (Linux; Android 6.0.1; SAMSUNG SM-T550 Build/MMB29M)
> AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/4.0
> Chrome/44.0.2403.133 Safari/537.36
>
> Observations, please!

NetSurf is not telling lies. In addition, browser name sniffing is considered
harmful because of how many extensions exist which allow you to change it.
Basically just "no".

D.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

Browser ID/User Agent

I've been doing some stuff recently with browser ID strings, and find that
it is quite complicated!

There is stuff called Mozilla compatibility, platform, platform details,
specific enhancements etcetera! All very difficult to untangle!

But NetSurf (RISC OS) resolutely reports itself as:

NetSurf/3.7 (RISC OS)

which isn't terribly helpful/compatible with the likes of, for instance:

Mozilla/5.0 (Linux; Android 6.0.1; SAMSUNG SM-T550 Build/MMB29M)
AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/4.0
Chrome/44.0.2403.133 Safari/537.36

Observations, please!

John

--
| John Williams
| johnrw@ukgateway.net

Literary allusions are often magical - the art of the allusionist *