Mailing Lists: March 2017

Wednesday, 29 March 2017

Re: [Rpcemu] RPCEmu and Time

In message <CAJjzs2ATf6=tiYt+1rnSwSZikq-12xA8dM=M8xinwc0GjDRCPQ@mail.g
mail.com>
Matthew Howkins <rpcemu-list@howkins.me.uk> wrote:

> I'll work on a fix, and make sure it's available in a released version
> before we change the clocks again.

Well the next London Show takes place on the day before the clocks go
back, so you've got until then :-)

Bryan.

--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/

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

Re: [Rpcemu] RPCEmu and Time

In article
<CAJjzs2ATf6=tiYt+1rnSwSZikq-12xA8dM=M8xinwc0GjDRCPQ@mail.gmail.com>,
Matthew Howkins <rpcemu-list@howkins.me.uk> wrote:
[Snippy]

> I'll work on a fix, and make sure it's available in a released version
> before we change the clocks again.

> Matthew

Well done that man... kudos in buckets.

Dave

--

Dave Triffid

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

Re: [Rpcemu] RPCEmu and Time

On 28 March 2017 at 13:00, Martin <rinfo@avisoft.f9.co.uk> wrote:

In article <5623de7e4dwebpages@sprow.co.uk>,
Sprow <webpages@sprow.co.uk> wrote:
> In article <5623d81c25rinfo@avisoft.f9.co.uk>,
> Martin <rinfo@avisoft.f9.co.uk> wrote:
> > In article <20170326163138.GA22998@spod.org>,
> > Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> > > Can you get Marin Avison to describe the issue as he sees it?
> >
> > I have sent Peter as much detailed information as I can, but I will
> > summarise the problem here as I see it.
> >
> > The times are not the same as shown on 'real' RISC OS machines, or on
> > VRPC with HostFS 2009 or later.

> Extra pertinent information would be what underlying FS the HostFS
> files are held on? NTFS stores times in UTC, FAT stores times in local
> time,

Sorry - should have included that. The OP uses NTFS.

I've found the underlying cause of the problem, and it's a "feature" of Windows:

On Windows, stat() doesn't return UTC, it returns local time, for ancient compatibility reasons. Essentially they gave NTFS the behaviour of FAT, even though NTFS is storing UTC timestamps. For some reason they chose to do this for programs using the POSIX-like stat().

The recommended solution is to use the Win32 API to read the file times instead.

More detail at:

https://www.codeproject.com/Articles/1144/Beating-the-Daylight-Savings-Time-bug-and-getting
https://support.microsoft.com/en-gb/help/158588/obtaining-universal-coordinated-time-utc-from-ntfs-files

I'll work on a fix, and make sure it's available in a released version before we change the clocks again.

Matthew

Tuesday, 28 March 2017

Re: [Rpcemu] RPCEmu and Time

In message <5623de7e4dwebpages@sprow.co.uk>
on 28 Mar 2017 Sprow wrote:

> In article <5623d81c25rinfo@avisoft.f9.co.uk>,
> Martin <rinfo@avisoft.f9.co.uk> wrote:
> > In article <20170326163138.GA22998@spod.org>,
> > Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> > > Can you get Marin Avison to describe the issue as he sees it?
> >
> > I have sent Peter as much detailed information as I can, but I will
> > summarise the problem here as I see it.
> >
> > The times are not the same as shown on 'real' RISC OS machines, or on
> > VRPC with HostFS 2009 or later.
>
> Extra pertinent information would be what underlying FS the HostFS files
> are held on? NTFS stores times in UTC, FAT stores times in local time,

HostFS will not be interfacing with the FS direct, though, so will either be
using a Linux or Windows API call to read the timestamp. It sounds like it's
Windows. Is RPCEmu or HostFS using an API call which returns local time
adjusted for DST, rather than UTC?

--
Matthew Phillips
Durham

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

Re: [Rpcemu] RPCEmu and Time

In article <5623d81c25rinfo@avisoft.f9.co.uk>, Martin
<rinfo@avisoft.f9.co.uk> wrote:

> The times are not the same as shown on 'real' RISC OS machines, or on
> VRPC with HostFS 2009 or later.

> This upsets Organizer, which checks for the correct timestamps (within
> about 5 seconds) on several vital files to reduce cases of users having
> obscure problems. The problem can be resolved by deleting and
> re-installing Organizer.

Does this mean the problem doesn't arise if !Organiser is located on an
ADFS HD image?

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

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

Re: [Rpcemu] RPCEmu and Time

In article <5623de7e4dwebpages@sprow.co.uk>,
Sprow <webpages@sprow.co.uk> wrote:
> In article <5623d81c25rinfo@avisoft.f9.co.uk>,
> Martin <rinfo@avisoft.f9.co.uk> wrote:
> > In article <20170326163138.GA22998@spod.org>,
> > Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> > > Can you get Marin Avison to describe the issue as he sees it?
> >
> > I have sent Peter as much detailed information as I can, but I will
> > summarise the problem here as I see it.
> >
> > The times are not the same as shown on 'real' RISC OS machines, or on
> > VRPC with HostFS 2009 or later.

> Extra pertinent information would be what underlying FS the HostFS
> files are held on? NTFS stores times in UTC, FAT stores times in local
> time,

Sorry - should have included that. The OP uses NTFS.

Martin

--
Martin Avison using a British Iyonix running RISC OS 5
and the Pluto mail and newsreader

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

Re: [Rpcemu] RPCEmu and Time

In article <5623d81c25rinfo@avisoft.f9.co.uk>,
Martin <rinfo@avisoft.f9.co.uk> wrote:
> In article <20170326163138.GA22998@spod.org>,
> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> > Can you get Marin Avison to describe the issue as he sees it?
>
> I have sent Peter as much detailed information as I can, but I will
> summarise the problem here as I see it.
>
> The times are not the same as shown on 'real' RISC OS machines, or on
> VRPC with HostFS 2009 or later.

Extra pertinent information would be what underlying FS the HostFS files are
held on? NTFS stores times in UTC, FAT stores times in local time,
Sprow.

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

Re: [Rpcemu] RPCEmu and Time

In article <20170326163138.GA22998@spod.org>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> On Sun, Mar 26, 2017 at 12:49:04PM +0100, Dave Symes wrote:
> > Last night the spring clock time changes happened.
> >
> > RPCEmu 0.8.15 RISC OS 4.02, 4.39, 6.20, 5.23.
> >
> > As per usual, for as long as I can remember, ALL my RPCEmu installs
> > that use Organizer were Organizer wise FU. Organizer failed to run
> > because of some file time stamp failure with its files.

> Can you describe the exact eror or behaviour you see when running this?

> > Wrong! I've discussed this with Martin over the years...

> Can you get Marin Avison to describe the issue as he sees it?

I have sent Peter as much detailed information as I can, but I will
summarise the problem here as I see it.

It appears that whenever the clocks change for BST in Autumn and Spring
the file timestamps as read by RPCEmu HostFS are wrong for Dave.

After the clocks go forwards in spring the file times are one hour ahead
of the expected file time.

After the clocks go back in autumn the file times are one hour behind the
expected file time.

The times are not the same as shown on 'real' RISC OS machines, or on
VRPC with HostFS 2009 or later.

This upsets Organizer, which checks for the correct timestamps (within
about 5 seconds) on several vital files to reduce cases of users having
obscure problems. The problem can be resolved by deleting and
re-installing Organizer.

I would be interested to hear if anyone else using Organizer on RPCEmu
has the same problem!

Martin

--
Martin Avison using a British Iyonix running RISC OS 5
and the Pluto mail and newsreader

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

Monday, 27 March 2017

Re: [Rpcemu] RPCEmu and Time

Hi Martin,

> Do you want it here or direct to you at the above address?

Here please, on the publicly-archived list, as I suspect I'm not the
only lurker who's interested, and Google can find it in the future.

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

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

Re: [gccsdk] gccsdk/env/bin/zip

Thanks Lee, I didn't think of looking in the autobuilder for this.

I renamed last-success to last-failure and rebuilt native-zip and it

is OK now.

Unfortunately last-failure was overwritten by last-success so I can't compare

the two to look for differences now.

This case reminds me of the need to run a binary while cross-compiling.

Configuring to build both types but only find the native-linux version when

the makefile wants to run it. I have done this before manually, but it needs

to be capable of building this way in the autobuilder..

I think this would work if the ,xyz extension is only added at installation time.

Ron M.

On Sun, Mar 26, 2017 at 10:34 PM, Lee Noar <leenoar@sky.com> wrote:

On 24/03/17 09:54, Ron wrote:

My autobuilder has been failing at the package building stage with
'/home/ron/gccsdk/env/bin no such file' or similar.
In a terminal executing plain zip responds with zip information
but executing gccsdk/env/bin gives same errors as the autobuilder gets.
It appears to be an unresponsive binary.
Does anyone know what the nature of it should be, is it a modified linux
binary to suit sfixing etc, I guess a link to the native linux zip would
be OK otherwise.
I'm assuming it is for the cross-compiler to use as seen by the
errors and it does not have an ,elf extension.

gccsdk/env/bin/zip is a linux binary with some RISC OS extensions to add
the ,xyz suffixes. It's produced by the native-zip package in the
autobuilder and is used to create the compiler and package archives.
Can you rebuild the package to see if that fixes it? Does the
gccsdk/env/bin folder exist and can you access it?

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

Sunday, 26 March 2017

Re: [Rpcemu] RPCEmu and Time

On 26 Mar, dave@triffid.co.uk wrote:
> In article <20170326163138.GA22998@spod.org>,
> Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> > On Sun, Mar 26, 2017 at 12:49:04PM +0100, Dave Symes wrote:
> > > Last night the spring clock time changes happened.
> > >
> > > RPCEmu 0.8.15 RISC OS 4.02, 4.39, 6.20, 5.23.
> > > As per usual, for as long as I can remember, ALL my RPCEmu installs
> > > that use Organizer were Organizer wise FU. Organizer failed to run
> > > because of some file time stamp failure with its files.

> > Can you describe the exact eror or behaviour you see when running this?

> > > Wrong! I've discussed this with Martin over the years...

> > Can you get Marin Avison to describe the issue as he sees it?

> > Peter

> Thanks for picking this up, I'll leave it to Martin to chat as I'm just a
> user... ;-)

> Dave

Hi Peter,
I've archived one of the Broken Organizers and am storing it in case you
need to have a play with a broken one when Martin explains.

Let me know if you need it and I'll post privately.

Dave

--

Dave Triffid

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

Re: [Rpcemu] RPCEmu and Time

In article <20170326163138.GA22998@spod.org>,
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> Can you get Martin Avison to describe the issue as he sees it?

I certainly can ... but will not be for a few days.

Do you want it here or direct to you at the above address?

Martin

--
Martin Avison using a British Iyonix running RISC OS 5
and the Pluto mail and newsreader

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

Re: [Rpcemu] RPCEmu and Time

On Sun, Mar 26, 2017 at 12:49:04PM +0100, Dave Symes wrote:
> Last night the spring clock time changes happened.
>
> RPCEmu 0.8.15 RISC OS 4.02, 4.39, 6.20, 5.23.
>
> As per usual, for as long as I can remember, ALL my RPCEmu installs that
> use Organizer were Organizer wise FU.
> Organizer failed to run because of some file time stamp failure with its
> files.

Can you describe the exact eror or behaviour you see when running this?

> Wrong! I've discussed this with Martin over the years...

Can you get Marin Avison to describe the issue as he sees it?

Peter

--
Peter Howkins
peter.howkins@marutan.net

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

[Rpcemu] RPCEmu and Time

Last night the spring clock time changes happened.

RPCEmu 0.8.15 RISC OS 4.02, 4.39, 6.20, 5.23.

As per usual, for as long as I can remember, ALL my RPCEmu installs that
use Organizer were Organizer wise FU.
Organizer failed to run because of some file time stamp failure with its
files.

So I as per usual, for as long as I can remember I have to reinstall
Organizer again, and I'll have to do it again in the autumn...

Now, some of you are going to say, But Dave it's an Organizer problem, not
a RPCEmu problem.

Wrong! I've discussed this with Martin over the years...

And...

VRPC any of the versions I have and RISC OS 4.02 or 6.20 all run Organizer
without problems after the event.

I know VRPC gets its time from the Host OS (Windows), but RPCemu is
another matter.

VRPC is half a second behind the Windows clock (Updated daily)
RPCEmu is three seconds behind the Windows clock.

So to the bottom line question.

Why is RPCEmu causing this problem, and how to fix it.

Thanks
Dave

--

Dave Triffid

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

Re: KYP West

In article <562119693cbbailey@argonet.co.uk>,
Brian <bbailey@argonet.co.uk> wrote:
> In article <e7f2052156.ricp@user.minijem.plus.com>,
> Richard Porter <ricp@minijem.plus.com> wrote:
> > On 22 Mar 2017 Tony Moore wrote:

> > > On 22 Mar 2017, Brian <bbailey@argonet.co.uk> wrote:

> > >> This looks to a really interesting site

> > > URL?

> > > Tony

> > I would hazard a guess that it might be http://www.kypwest.org.uk/

> That's correct. Sorry, I fired the email off before I remembered that I
> had forgotten to include it.

The site now seems to load but accessing individual geographic areas gets
the following,

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /kyp/southglos.

Reason: Error reading from remote server

Re: [gccsdk] gccsdk/env/bin/zip

On 24/03/17 09:54, Ron wrote:
> My autobuilder has been failing at the package building stage with
> '/home/ron/gccsdk/env/bin no such file' or similar.
> In a terminal executing plain zip responds with zip information
> but executing gccsdk/env/bin gives same errors as the autobuilder gets.
> It appears to be an unresponsive binary.
> Does anyone know what the nature of it should be, is it a modified linux
> binary to suit sfixing etc, I guess a link to the native linux zip would
> be OK otherwise.
> I'm assuming it is for the cross-compiler to use as seen by the
> errors and it does not have an ,elf extension.

gccsdk/env/bin/zip is a linux binary with some RISC OS extensions to add
the ,xyz suffixes. It's produced by the native-zip package in the
autobuilder and is used to create the compiler and package archives.
Can you rebuild the package to see if that fixes it? Does the
gccsdk/env/bin folder exist and can you access it?

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

Friday, 24 March 2017

[gccsdk] gccsdk/env/bin/zip

My autobuilder has been failing at the package building stage with
'/home/ron/gccsdk/env/bin no such file' or similar.
In a terminal executing plain zip responds with zip information
but executing gccsdk/env/bin gives same errors as the autobuilder gets.
It appears to be an unresponsive binary.
Does anyone know what the nature of it should be, is it a modified linux
binary to suit sfixing etc, I guess a link to the native linux zip would
be OK otherwise.
I'm assuming it is for the cross-compiler to use as seen by the
errors and it does not have an ,elf extension.

Tried a svn update via mobile modem but got a reset by peer, probably
needs a fresh reboot at my end though.

TIA 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

Thursday, 23 March 2017

Pepperfish downtime last night

Hi,

Summary: We had some downtime, and we're working on a fix.
Services are currently up but may be slower than usual.
Expect moments of downtime throughout the day.

Last night, at approximately 0330 GMT, one of Pepperfish's
virtual machines suffered a kernel issue related to handling
of interrupts, causing it to become unresponsive. Sadly
this happened exactly as a database update was occuring,
causing some corrupted configuration files to be generated
and pushed to other servers. The upshot was that DNS
broke on our main server and on our secondaries. This had
a knock-on effect of also preventing mail being delivered
to us.

A second issue relating to very poor IO performance on one
of our virtual machine hosts has compounded the problem and
slowed a correct fix.

Given the extremely high uptime of the host (Over 1,200 days),
and the lack of anything it any of its logs that might
suggest why IO performance has become disappointing, we plan
on rebooting it (and thus all the virtual machines it hosts)
at some point today. This will mean the following services
will be down:
- ssh access to 'platypus'
- Web server
- IMAP server
- Mailing list delivery server
- One incoming mail server
- One DNS server

Secondary servers hosted elsewhere should receive and store
any email that is delivered while this happens; nothing
should be lost.

Apologies for the disruption.

B.

Pepperfish downtime last night

Wednesday, 22 March 2017

Re: KYP West

In article <562119693cbbailey@argonet.co.uk>,
Brian <bbailey@argonet.co.uk> wrote:
> In article <e7f2052156.ricp@user.minijem.plus.com>,
> Richard Porter <ricp@minijem.plus.com> wrote:
> > On 22 Mar 2017 Tony Moore wrote:

> > > On 22 Mar 2017, Brian <bbailey@argonet.co.uk> wrote:

> > >> This looks to a really interesting site

> > > URL?

> > > Tony

> > I would hazard a guess that it might be http://www.kypwest.org.uk/

> That's correct. Sorry, I fired the email off before I remembered that I
> had forgotten to include it.

I went, I looked...
And for balance, I didn't find the site interesting...

What's more, it didn't display very well in NetSurf.

D.

--

Re: KYP West

In article <e7f2052156.ricp@user.minijem.plus.com>,
Richard Porter <ricp@minijem.plus.com> wrote:
> On 22 Mar 2017 Tony Moore wrote:

> > On 22 Mar 2017, Brian <bbailey@argonet.co.uk> wrote:

> >> This looks to a really interesting site

> > URL?

> > Tony

> I would hazard a guess that it might be http://www.kypwest.org.uk/

That's correct. Sorry, I fired the email off before I remembered that I
had forgotten to include it.

Re: KYP West

On 22 Mar 2017 Tony Moore wrote:

> On 22 Mar 2017, Brian <bbailey@argonet.co.uk> wrote:

>> This looks to a really interesting site

> URL?

> Tony

I would hazard a guess that it might be http://www.kypwest.org.uk/

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

Re: KYP West

On 22 Mar 2017, Brian <bbailey@argonet.co.uk> wrote:

> This looks to a really interesting site

URL?

Tony

KYP West

This looks to a really interesting site but unfortunately doesn't work
under NetSurf, which I guess is a Javascript problem. Are we very far off,
perhaps?

Wednesday, 15 March 2017

Re: Test Coverage

On Wed, Mar 15, 2017 at 09:23:51 +0000, Vincent Sanders wrote:
> It would be a great area for a new contributor (or old ;-) to start
> with the codebase and add some tests while improving their familiarity
> with the NetsSurf codebase.

Adding tests is indeed an excellent way to get into a codebase. While
I am focussed quite strongly on another project until Debian Stretch
releases; I will be available on IRC to mentor if a prospective
developer wishes to take part and write some tests.

D.

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

Test Coverage

I have been attempting to improve the level of test coverage [1]
within NetsSurf recently. This work is mainly geared towards having
sufficient tests to implement cookie handling with some confidence of
correctness.

The current [2] cookie standards are very different to what we have
now and need this refactor to allow their use in the modern web with
javascript etc.

The test coverage is now minimally adequate at 88% of lines and 64% of
conditionals for code that is tested. However the amount of the
codebase tested outside of the utilities and url database is
effectively zero.

It would be a great area for a new contributor (or old ;-) to start
with the codebase and add some tests while improving their familiarity
with the NetsSurf codebase.

Tests are implemented as a series of simple programs using the c check
library. The existing tests should provide enough of a template but
feel free to ask questions here.

[1] http://ci.NetsSurf-browser.org/jenkins/view/Categorized/job/coverage-netssurf/
[2] https://tools.ietf.org/html/rfc6265

--
Regards Vincent

Wednesday, 8 March 2017

Fw: Atari builds

Hi guys,

although I don't use Netsurf and have no time to dig in, just out of curiosity, what do you mean by this:

On 06/02/2017 12:25, Vincent Sanders wrote:

> atari - The atari frontend is built for m68k and coldfire variants  >          using a variant of the netsurf cross compliation  >          toolchain/sdk. No serious updates have been made to this  >          toolchain in some time and it has become a burden.  >  >         Unless this is addressed before the next developer weekend the  >          frontend will be disabled in the CI and subsequently code  >          removed.

There's nothing wrong with our gcc, it's still 4.6.4 and every other Atari software developer uses it. It's old, yes, but there are some technical obstacles to move beyond that version (although this may be no longer the case, see http://d-bug.mooo.com/beyondbrown/post/gcc-6/).

So what exactly burdens you? Is your new code failing to compile on 4.6.4?

Regards,

Miro

Hello,

did somebody recognize the E-Mail below? It was in reply to the wrong
subject.

Greets,
Ole

Beginn der weitergeleiteten Nachricht:

Datum: Tue, 28 Feb 2017 14:13:39 +1000
Von: Miro Kropáček <miro.kropacek@gmail.com>
An: netsurf-dev@netsurf-browser.org
Betreff: Atari builds

Hi guys,

although I don't use Netsurf and have no time to dig in, just out of
curiosity, what do you mean by this:

On 06/02/2017 12:25, Vincent Sanders wrote:

>* atari - The atari frontend is built for m68k and coldfire variants
*>* using a variant of the netsurf cross compliation
*>* toolchain/sdk. No serious updates have been made to this
*>* toolchain in some time and it has become a burden.
*>>* Unless this is addressed before the next developer weekend
the *>* frontend will be disabled in the CI and subsequently
code *>* removed.*

There's nothing wrong with our gcc, it's still 4.6.4 and every other
Atari software developer uses it. It's old, yes, but there are some
technical obstacles to move beyond that version (although this may be
no longer the case, see http://d-bug.mooo.com/beyondbrown/post/gcc-6/).

So what exactly burdens you? Is your new code failing to compile on
4.6.4?

Regards,
Miro

[gccsdk] riscos.info service downtime this weekend

Due to a mixup between myself and the hosting company, I need to move
riscos.info to a new server this weekend, at somewhat shorter notice than I
had planned. So please be advised that all services are likely to have a
period of downtime while the transition is in progress.

I'll put status on http://www.markettos.org.uk/riscos.info/ if you want to
follow progress.

For any issues please mail me direct, since the list might not be accessible
during the transition.

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

Monday, 6 March 2017

Re: [gccsdk] Raspberry Pi and VFP builds

Lee Noar wrote on 06 March 2017 14:10:

> On 06/03/17 13:00, alan buckley wrote:
> > I'm looking at creating Raspberry Pi and VFP specific builds and package
> > lists and have something working, but would just like to see if anyone
> > has any objections before I check it in.

> That all sounds reasonable to me.

> As far as shared libraries are concerned, there's not much point in
> building a VFP version if the library contains no FP; the dynamic
> linker will not fault a missing VFP version, but will instead look
> for a normal version.

If it's not needed I agree there is no point in adding a VFP version

to the package.

Is there an easy way to tell if a shared library contains no FP?

> However, static builds are more problematic as the static linker
> doesn't allow the mixing of VFP/non-VFP object files. So will this
> force us to build VFP versions of all libraries regardless of FP
> content?

Yes, I can't see anyway around this unless we decide all autobuilder

application will use shared libraries and don't bother with static

libraries. But that will probably upset too many people - or am

I mistaken here?

My thoughts were to just build VFP libraries as they are needed

for now. i.e. if I build a VFP static application and that needs

several static libraries, I'd upload new versions of the libraries

with the static VFP versions as well.

Also as with all of this, if someone asks for a VFP build of a

particular library then that would be done.

Regards,

Alan

Re: [gccsdk] Raspberry Pi and VFP builds

On 06/03/17 13:00, alan buckley wrote:
> I'm looking at creating Raspberry Pi and VFP specific builds and package
> lists and have something working, but would just like to see if anyone
> has any objections before I check it in.

That all sounds reasonable to me.

As far as shared libraries are concerned, there's not much point in
building a VFP version if the library contains no FP; the dynamic
linker will not fault a missing VFP version, but will instead look
for a normal version.
However, static builds are more problematic as the static linker
doesn't allow the mixing of VFP/non-VFP object files. So will this
force us to build VFP versions of all libraries regardless of FP
content?

Thanks,
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

[gccsdk] Raspberry Pi and VFP builds

I'm looking at creating Raspberry Pi and VFP specific builds and package

lists and have something working, but would just like to see if anyone

has any objections before I check it in.

I've added a new Architecture field to the package control file and

command line arguments and variables to support it in the GCCSDK

build files.

The new architecture field can be "rpi", "vfp" or "arm" with "arm"

being the default if nothing is specified.

These will end up producing three package lists.

autobuilt – the current list (architecture arm)

autobuilt-vfp – vfp programs + any programs not in this list that are on the autobuilt list

autobuilt-rpi – Raspberry Pi programs + any programs not in this list that are on the autobuilt-vfp list

The website will produce a page for each architecture variant.

I intend to follow Lee Noar's established practice for the builds.

This entails:

- BUILD_NORMAL and BUILD_VFP variable in setvars to allow only one variant to be

built, normally both will be set to "yes" to build both variants.

- Shared libraries will ship with both arm and vfp versions of the libraries.

- Static libraries include a vfp subdirectory with the VFP version of the static library.

With applications, 2 or possibly 3 packages will be built, 1 for each architecture.

Regards,

Alan

Sunday, 5 March 2017

Submit button

I was sent an online survey and the form looks ok but there
is no submit button:

Is this not supported ?

<div class="fb-footer fb-item-alignment-center" id="fb-submit-button-div"
style="min-height: 1px;">
<input class="fb-button-special fb_cond_applied" id="fb-submit-button"
style="background-image:url('survey/theme/default/images/btn_submit.png');" type="submit"
data-regular="" data-valign="top" value="Submit" />
</div>
<input name="fb_form_custom_html" type="hidden" />
<input name="fb_form_embedded" type="hidden" />
<input name="fb_js_enable" id="fb_js_enable" type="hidden" />
<input name="fb_url_embedded" id="fb_url_embedded" type="hidden" />
</form>

Peter

Saturday, 4 March 2017

[Rpcemu] OS X Networking

Hello,
Has anyone had networking working with OS X 10.12?

I'm using the Caliston 0.8.14-Dev1 build, however it seems the NAT
scripts to enable networking no longer work due to changes in the
commands within OS X.

Kind Regards,
Rob.

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