Re: [gccsdk] Is there activity here?

In message <20170630102711.GA25075@chiark.greenend.org.uk>
Theo Markettos <theo@markettos.org.uk> wrote:

>On Thu, Jun 29, 2017 at 09:15:35PM +0100, Dave Higton wrote:
>> ... and, if there is: have I failed to notice it, or did it not
>> arrive in my inbox?
>
>Are you measuring activity by mail, or by programming?

By mail.

It has become clear that I can post to the list - which, since it's
a moderated list, must mean that I'm subscribed to it - but I don't
receive mail from it. This email is only going to the list because
Theo kindly copied me privately.

So how do I get list mail to be sent to me?

Dave

_______________________________________________
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

Page rendering

My buddy sent me the following,

https://dezinfo.net/foto/82952-yentuziast-stroit-samolet-iz-bumagi-na-protyazhenii-9-let.html

I was interested to compare the rendering under NetSurf and FireFox. Pity
the video doesn't display under RISC OS. That isn't a complaint by the
way. I'm just intrigued by the subject matter.

Re: [gccsdk] Is there activity here?

Theo Markettos wrote on 30 June 2017 11:28

[snip]

 

> Are you measuring activity by mail, or by programming?

> In the latter case, I don't have a lot of time these days but various things
> I've been doing:

> 2b. I notice Debian have made a new release, which means some of our
> upstream package versions have shifted and don't build any more.  I'm not
> sure what to do about that.

 

I've noticed that as well, I had to recently change GCCSDK to point at some

old debian lists to be able to build subversion.

 

I think we should strive to update to the new packages and retire the old

ones. Maybe have an archive area in GCCSDK for the old versions that are

no longer updated.

 

I think we should also move things that will no longer build there. But only

after checking there is no way to get them to build again.

 

For myself, I keep trying to bring packages up to date and rebuild them so

they will work on the Raspberry Pi 3. I tend to look at things that are

mentioned on other sites to see what to look at. The problem is I have

very little time and so progress is slow.

 

Regards,

Alan

Re: [gccsdk] Is there activity here?

On Thu, Jun 29, 2017 at 09:15:35PM +0100, Dave Higton wrote:
> ... and, if there is: have I failed to notice it, or did it not
> arrive in my inbox?

Are you measuring activity by mail, or by programming?

In the latter case, I don't have a lot of time these days but various things
I've been doing:

1. Experimenting with converting the riscos.info SVN repos to git, to allow
some resilience and easier staging of patches. For example:
https://github.com/caliston/gccsdk
(that's entirely throwaway for the time being, so please don't rely on it).
There's no intention to deprecate the existing SVN, merely to put in place
some two way bridges so it's possible to use either.

2. Dependent on 1), I have some patches to build bits of GCCSDK with FreeBSD
(and perhaps macOS, etc). I need to check I don't break the existing builds
before committing them to SVN head.

2b. I notice Debian have made a new release, which means some of our
upstream package versions have shifted and don't build any more. I'm not
sure what to do about that.

3. The fast Jenkins build server has been down for a long while due to the
somewhat complex network setup behind the scenes being broken, which I need
to reinstate.

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] pthread shutdown in atexit

I have a mysterious crash in a SDL based program when it attempts to

do a pthread_wait in an atexit handler. The error is:

pthreads: ***fatal error, aborting***

pthread_yield called with context switching disabled.

 

My guess is this means that GCC is shutting down the threads system

before the atexit handler is being called.

 

Is there anything I can do to workaround this problem?

e.g. Is there a function I can call or a variable I can check

to see if threading has been stopped so I can avoid the call?

Or is there a way to detect I'm in an atexit hander?

 

Thanks,

Alan

Re: [gccsdk] Is there activity here?

Hi Dave,

> ... and, if there is: have I failed to notice it, or did it not
> arrive in my inbox?

http://www.riscos.info/pipermail/gcc/2017-May/thread.html

--
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] Is there activity here?

In article <79e0f25356.DaveMeUK@my.inbox.com>,
Dave Higton <dave@davehigton.me.uk> wrote:
> ... and, if there is: have I failed to notice it, or did it not
> arrive in my inbox?

> Dave

Well, I received this posting, I had an issue with gmail not sending my own
post back, they consider it a duplicate/assume you already have it.

I haven't been able to get confirmation of subscription to the Pluto group
since changing to zoho mail.

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

[gccsdk] Is there activity here?

... and, if there is: have I failed to notice it, or did it not
arrive in my inbox?

Dave

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

Netsurf Cache

After an informative thread on how the disc cache is used by Netsurf I
wrote:

On 13 Apr 2016 in article <55705bbd12netsurf@avisoft.f9.co.uk>,
Martin Avison <netsurf@avisoft.f9.co.uk> wrote:
> I have now deleted the whole cache, and reset Netsurf to the default
> values for disc of 1024MB and 28 days, and memory is set to 50MB.

> Time will tell what the effects of this are!

As 14 months have passed, I though I would report back. The current
contents of my RISC OS Netsurf v3.6 disc cache is...

Total Files 5,204 Size 530,576,177
Expired Files 4,773 Size 404,997,322 before 30 May 17
3xExpired Files 3,337 Size 280,195,992 before 07 Mar 17
6xExpired Files 1,692 Size 151,695,867 before 20 Sep 16
Total Directories 19,648 Size 40,245,248 Empty 899

There are nearly 900 directories with no files in them - but that is
quite a small proportion of the 19,000 directories. And I know from the
old thread that these could be deleted without causing any problem. It
does still strike me as silly that the number of directories is nearly 4
times the number of files held in them.

However, I was surprised by the 90% files that were older than the expiry
date - indeed 60% were over 3 times the expiry age, and 30% over 6 times.
After more investigation, I could see that there are files right back to
April 2016 when the cache was initialised.

Are age expired cache files *ever* deleted?
If so, when, or are they only deleted if the size limit is exceeded?

Have any changes since 3.6 affected this?

In an earlier post in that thread I had asked...
> When are cached files deleted to meet the configured size & expiry?

and the reply was ...

On 13 Apr in article <20160413104528.GA24798@kyllikki.org>,
Vincent Sanders <vince@netsurf-browser.org> wrote:
> The cache is pruned only when adding a new entry which causes the
> overall cache usage to exceed the set level. at that point the least
> "valuable" objects are discarded until the size drops below the
> desired size. This process is subject to 10% hysteresis to avoid
> excessive thrashing.

I can understand how this applies to the maximum size, but it does not
seem to cover the age expiry.

Can expired files be manually deleted without causing problems?
I suspect that various cache index files would cause problems as they
would not be updated.

Thanks
Martin

Re: [Rpcemu] Networking error

On 22 Jun 2017, Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> On Wed, Jun 21, 2017 at 04:10:39PM +0000, Tony Moore wrote:

> > I have installed RPCEmu 0.8.15 / RO 6.20 on Windows 7 Pro 64 bit,
> > running on an HP3500 desktop machine. The installation is fine,
> > apart from a lack of networking.
> >
> > I carefully followed the instructions in the RPCEmu Networking
> > Guide, using OpenVPN v2.3.8 to create the TAP driver. Following
> > installation, *ifconfig -a , and *show inet* , return believable
> > results, however *ping shows no connection.
> >
> > From the log, I note that the TAP driver is 32 bit. Could running
> > this on a 64 bit machine lead to the errors?
>
> No, you're using a 64 bit driver on 64 bit windows 'win32' in this
> context is the name of the API we use (which is suitable for both 32
> and 64 bit).

Thank you for the clarification.

> I don't have any specific answer to this error. However one previous
> user who had this error indicated that it was due to not having set up
> the network bridge in windows correctly, recheck that section of the
> instructions.

I'd tried that several times, before posting.

After some time with Google, I found a thread, Another connection
problem', on the RPCEmu mailing list, from a couple of years ago, in
which David Feugey noted the same error messages. The solution then, as
now, was to downgrade OpenVPN to version 2.1.3, which creates Tap-win32
version 9.7.0. This is compatible with Win 7 Pro, whereas at least one
later version seems not to be.

Having changed the TAP driver, the errors have gone, and all is well.

Many thanks for your response.

Tony



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

Re: [Rpcemu] Networking error

On Wed, Jun 21, 2017 at 04:10:39PM +0000, Tony Moore wrote:
> I have installed RPCEmu 0.8.15 / RO 6.20 on Windows 7 Pro 64 bit,
> running on an HP3500 desktop machine. The installation is fine, apart
> from a lack of networking.
>
> I carefully followed the instructions in the RPCEmu Networking Guide,
> using OpenVPN v2.3.8 to create the TAP driver. Following installation,
> *ifconfig -a , and *show inet* , return believable results, however
> *ping shows no connection.
>
> >From the log, I note that the TAP driver is 32 bit. Could running this
> on a 64 bit machine lead to the errors?

No, you're using a 64 bit driver on 64 bit windows 'win32' in this context
is the name of the API we use (which is suitable for both 32 and 64 bit).

I don't have any specific answer to this error. However one previous user
who had this error indicated that it was due to not having set up the
network bridge in windows correctly, recheck that section of the
instructions.

Peter

--
Peter Howkins
peter.howkins@marutan.net

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

[Rpcemu] Networking error

I have installed RPCEmu 0.8.15 / RO 6.20 on Windows 7 Pro 64 bit,
running on an HP3500 desktop machine. The installation is fine, apart
from a lack of networking.

I carefully followed the instructions in the RPCEmu Networking Guide,
using OpenVPN v2.3.8 to create the TAP driver. Following installation,
*ifconfig -a , and *show inet* , return believable results, however
*ping shows no connection.

On booting RPCEmu, there is no error message to indicate connection
failure, however the RPCEmu log, below, contains multiple error
messages, near the end of the file. I should be grateful for advice as
to the cause of these errors, and how to fix them.

From the log, I note that the TAP driver is 32 bit. Could running this
on a 64 bit machine lead to the errors?

Tony

[ log follows ]

RPCEmu 0.8.15 [DYNAREC NO_DEBUG]
Build: 32-bit binary
Compiler: GCC version 4.6.2
OS: Microsoft Windows
OS: PlatformId = 2
OS: MajorVersion = 6
OS: MinorVersion = 1
OS: ProductType = 1
OS: SuiteMask = 0x100
OS: ServicePackMajor = 1
OS: ServicePackMinor = 0
OS: ProcessorArchitecture = 9
OS: SystemMetricsServerR2 = 0
OS: ProductInfoType = 48
Allegro version ID: Allegro 4.4.2, MinGW32
Desktop Resolution: 1920 x 1080
Host Colour Depth: 32
Working Directory: C:\Program Files (x86)\RPCEmu\RPCEmu_815_620
loadconfig: bridgename = "rpcemu"
loadconfig: model = "RPCSA"
loadconfig: mouse_twobutton = "0"
loadconfig: network_type = "ethernetbridging"
loadconfig: mouse_following = "1"
loadconfig: cdrom_type = "0"
loadconfig: cdrom_enabled = "1"
loadconfig: refresh_rate = "60"
loadconfig: stretch_mode = "1"
loadconfig: sound_enabled = "1"
loadconfig: vram_size = "2"
loadconfig: mem_size = "128"
loadconfig: cpu_idle = "1"
romload: Loaded 'Select6i00' 6291456 bytes
romload: Total ROM size 6 MB
initpodulerom: Successfully loaded 'hostfs,ffa' into podulerom
initpodulerom: Successfully loaded 'hostfsfiler,ffa' into podulerom
initpodulerom: Successfully loaded 'SyncClock,ffa' into podulerom
RPCEmu: Machine reset
Tap-Win32: device name: rpcemu
Tap-Win32: device path: \\.\Global\{2CCFC6E6-8B1C-4F45-925C-001E478499A1}.tap
Tap-Win32: File opened
Tap-Win32: version: 9.21.0
Tap-Win32: status set
Tap-Win32: tap_win32_overlapped_init done
Tap-Win32: Thread created
RPCEmu: Machine reset complete
HostFS: Registration request version 3 accepted
Tap-Win32:
ERROR_IO_PENDING - beforeTap-Win32: ERROR_IO_PENDING - afterTap-Win32:
[ the line above is repeated a further 20 times ]
tap_cleanup

[ end of log ]



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

Re: New logging library

On Sun, Jun 11, 2017 at 13:39:40 +0100, Daniel Silverstone wrote:
> I hope to improve these matters in near future, indeed some improvement can be
> expected before the end of today, but I'd appreciate it if some of the devs
> could take a look at it and decide if it looks at all usable.

To follow up a bit, the library is at:

http://source.netsurf-browser.org/libnslog.git/

I wouldn't expect code review at this point, but if you spot any bugs I'd
appreciate a report. I'll be looking to ask for a code review once I've
written documentation in, etc.

D.

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

New logging library

Hi,

As part of this weekend's developer workshop, I have written a new logging
library which supports nested categories of logging and complex filtering to
control what log entries end up rendered.

It is still very new, undocumented, and without significant test coverage.

I hope to improve these matters in near future, indeed some improvement can be
expected before the end of today, but I'd appreciate it if some of the devs
could take a look at it and decide if it looks at all usable.

D.

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

Re: Unable to Fetch document

>Message: 4
>Date: Fri, 02 Jun 2017 23:20:42 +0100
>From: cj <chris@chris-johnson.org.uk>
>Subject: Re: Unable to Fetch document
>To: <netsurf-users@netsurf-browser.org>
>Message-ID: <564616c2aechris@chris-johnson.org.uk>
>In article <56461099babrian.jordan9@btinternet.com>,
> Brian Jordan <brian.jordan9@btinternet.com> wrote:
>> As I have today update NetSurf to #4098 I thought I'd try this. The
>> result is a full download of the page in, according to the message
>> at the foot of the page, 16.4 seconds. "Done (16.4s)"
>
>On an ARMX6 and RISC OS 5.23, with javascript off it takes 1.1 secs,
>and javascript on 4.8 secs.
>
>Page looks to have rendered fine in both cases.
>
>
> Chris Johnson


Thanks for checking.

I'll try to produce a log to see if it sheds any light.

Peter

Re: Unable to Fetch document

In article <56461099babrian.jordan9@btinternet.com>,
Brian Jordan <brian.jordan9@btinternet.com> wrote:
> As I have today update NetSurf to #4098 I thought I'd try this. The
> result is a full download of the page in, according to the message
> at the foot of the page, 16.4 seconds. "Done (16.4s)"

On an ARMX6 and RISC OS 5.23, with javascript off it takes 1.1 secs,
and javascript on 4.8 secs.

Page looks to have rendered fine in both cases.

--
Chris Johnson

Re: Unable to Fetch document

In article <0011707f.01e9b4902688@smtp.freeola.net>,
Peter Slegg <p.slegg@scubadivers.co.uk> wrote:

[Snip]

> I updated to 4095 and that is the same. After 1-2mins:

> Unable to fetch document

> I suspect it is some sort of timing issue but other pages will render
> after 15-20mins.

> Peter

As I have today update NetSurf to #4098 I thought I'd try this. The
result is a full download of the page in, according to the message at the
foot of the page, 16.4 seconds. "Done (16.4s)"

My machine details in my signature.

--
_____________________________________________________________________

Brian Jordan
Virtual RPC-AdjustSA on Windows 10 Pro 64-bit
RISC OS 6.20
_____________________________________________________________________

Re: Unable to Fetch document

> Date: Thu, 01 Jun 2017 20:56:43 +0100
> From: Dave Higton <dave@davehigton.me.uk>
> Subject: Re: Unable to Fetch document
> To: netsurf-users@netsurf-browser.org
> Message-ID: <29be854556.DaveMeUK@my.inbox.com>
> In message <000450a6.01e9b49011c8@smtp.freeola.net>
> Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
>
> >
> >This page always returns "Unable to fetch document" on the
> >Atari 4088 m68k build.
> >
> >https://blog.backyardworlds.org/2017/05/19/thirteen-brown-dwarf-candidates-and-our-sensitivity-limits/
> >
> >Just wondered if other builds behave the same ?
>
> RISC OS CI #4095 fetches it OK. Lots of hourglass starts and stops,
> takes a while, but gets there.
>
> Do you need to know whether there is a problem specifically on
> CI #4088? Was that your question?
>
> Dave


I updated to 4095 and that is the same. After 1-2mins:

Unable to fetch document

I suspect it is some sort of timing issue but other pages will render
after 15-20mins.

Peter

Re: Redraw oddity

On 16/05/17 13:23, Richard Torrens (lists) wrote:

> https://www.quora.com/Where-does-iPhoto-store-photos-locally
>
> At first this displays a blank page. But wipe over it with another
> window...

Please try with CI build #4098 or later.

Cheers,

--
Michael Drake http://www.codethink.co.uk/

Re: Unable to Fetch document

In article <5645bd9c06bbailey@argonet.co.uk>,
Brian <bbailey@argonet.co.uk> wrote:
> In article <56458bcf2dcvjazz@waitrose.com>,
> Chris Newman <cvjazz@waitrose.com> wrote:
> > In article <000450a6.01e9b49011c8@smtp.freeola.net>, Peter Slegg
> > <p.slegg@scubadivers.co.uk> wrote:

> > > This page always returns "Unable to fetch document" on the Atari 4088
> > > m68k build.

https://blog.backyardworlds.org/2017/05/19/thirteen-brown-dwarf-candidates-and-our-sensitivity-limits/

> > > Just wondered if other builds behave the same ?


> > Took aaaages to open on my RiscPC with 3.7 (Dev CI#4095) but got there
> > eventually. Just seemed to be text in monochrome.

> Quite quick-ish here, VRPC RISC OS 4.02 (Dev CI #4097).

Text in monochrome. Graph in colour. Page seems to be complete.

Re: Unable to Fetch document

In article <56458bcf2dcvjazz@waitrose.com>,
Chris Newman <cvjazz@waitrose.com> wrote:
> In article <000450a6.01e9b49011c8@smtp.freeola.net>, Peter Slegg
> <p.slegg@scubadivers.co.uk> wrote:

> > This page always returns "Unable to fetch document" on the Atari 4088
> > m68k build.

https://blog.backyardworlds.org/2017/05/19/thirteen-brown-dwarf-candidates-and-our-sensitivity-limits/

> > Just wondered if other builds behave the same ?


> Took aaaages to open on my RiscPC with 3.7 (Dev CI#4095) but got there
> eventually. Just seemed to be text in monochrome.

Quite quick-ish here, VRPC RISC OS 4.02 (Dev CI #4097).

Re: Page Refresh

In article <9c488b4556.ricp@user.minijem.plus.com>, Richard Porter
<ricp@minijem.plus.com> wrote:

> I had a problem after updating a web page. NetSurf displayed the old
> version so I did a refresh but the first two images which were named
> the same as the previous ones were not reloaded. The third image which
> didn't have a predecessor loaded OK. So I then had to reload the first
> two images separately. Surely this shouldn't be the way it works?

> #4088

Use Adjust on the reload button (and Interactive help!).

--

Tim Hill

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

Re: Unable to Fetch document

In article <000450a6.01e9b49011c8@smtp.freeola.net>, Peter Slegg
<p.slegg@scubadivers.co.uk> wrote:

> This page always returns "Unable to fetch document" on the Atari 4088 m68k
> build.

> https://blog.backyardworlds.org/2017/05/19/thirteen-brown-dwarf-candidates-and-our-sensitivity-limits/

> Just wondered if other builds behave the same ?


Took aaaages to open on my RiscPC with 3.7 (Dev CI#4095) but got there
eventually. Just seemed to be text in monochrome.

--
Chris

Page Refresh

I had a problem after updating a web page. NetSurf displayed the old
version so I did a refresh but the first two images which were named
the same as the previous ones were not reloaded. The third image which
didn't have a predecessor loaded OK. So I then had to reload the first
two images separately. Surely this shouldn't be the way it works?

#4088

--
Richard Porter http://www.minijem.plus.com/
t: @westernexplorer mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.

Re: Unable to Fetch document

In message <000450a6.01e9b49011c8@smtp.freeola.net>
Peter Slegg <p.slegg@scubadivers.co.uk> wrote:

>
>This page always returns "Unable to fetch document" on the
>Atari 4088 m68k build.
>
>https://blog.backyardworlds.org/2017/05/19/thirteen-brown-dwarf-candidates-and-our-sensitivity-limits/
>
>Just wondered if other builds behave the same ?

RISC OS CI #4095 fetches it OK. Lots of hourglass starts and stops,
takes a while, but gets there.

Do you need to know whether there is a problem specifically on
CI #4088? Was that your question?

Dave

Unable to Fetch document

This page always returns "Unable to fetch document" on the
Atari 4088 m68k build.

https://blog.backyardworlds.org/2017/05/19/thirteen-brown-dwarf-candidates-and-our-sensitivity-limits/

Just wondered if other builds behave the same ?


Peter