Tuesday, 27 August 2019

Re: [Rpcemu] RPCEmu 0.9.1 and inexplicably high levels of background CPU activity (fwd)

In message <58a41e76c5d10d6247b9718b590d803d@ascinfo.fr> you wrote:

>> Le 2019-08-26 17:49, George a crit :
>>
>>> I've tried setting 'Reduced CPU Usage' in Settings, which successfully
>>> controls CPU background activity, but also causes desktop icons to
>>> stop reacting to mouse clicks consistently (normal, non-reduced CPU
>>> usage mouse behaviour is exemplarily consistent, by contrast).
>>> Secondly, once set, 'Reduced CPU Usage'is very difficult to unset: you
>>> have to open Settings as RPCEmu loads but before the desktop appears,
>>> otherwise the setting persists.
>>>
>> I confirm this bug. And if you boot in CLI mode (not desktop), it's
>> absolutely impossible to use.
>> It was working great with the previous (non QT) version.
>>
>> Bye, David

Thanks, David.

I should have mentioned in the original post, that auto-repeating
keystrokes are a major problem as well with 'Reduce CPU Usage'
selected: it's not just the mouse! I also tested the behaviour of
0.8.11/5.20 which is also installed here, and you are quite correct,
non QT versions work fine.

--
George
----------- End forwarded message -----------


--
George

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

Re: [Rpcemu] RPCEmu 0.9.1 and inexplicably high levels of background CPU activity

Le 2019-08-26 17:49, George a écrit :

> I've tried setting 'Reduced CPU Usage' in Settings, which successfully
> controls CPU background activity, but also causes desktop icons to
> stop reacting to mouse clicks consistently (normal, non-reduced CPU
> usage mouse behaviour is exemplarily consistent, by contrast).
> Secondly, once set, 'Reduced CPU Usage'is very difficult to unset: you
> have to open Settings as RPCEmu loads but before the desktop appears,
> otherwise the setting persists.
>
I confirm this bug. And if you boot in CLI mode (not desktop), it's
absolutely impossible to use.
It was working great with the previous (non QT) version.

Bye, David

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

Monday, 26 August 2019

[Rpcemu] RPCEmu 0.9.1 and inexplicably high levels of background CPU activity

RPCEmu's background level of CPU activity here is high: it's been
running now for about 4 hours without my using the machine until now,
and the average is 167 mips, about half the maximum achievable on this
laptop. TaskUsage is recording zero activity, by contrast. The
laptop's cooling fan is intermittently cutting in, and its CPU
activity varies between 29-40% according to Windows Task Manager.

I've tried setting 'Reduced CPU Usage' in Settings, which successfully
controls CPU background activity, but also causes desktop icons to
stop reacting to mouse clicks consistently (normal, non-reduced CPU
usage mouse behaviour is exemplarily consistent, by contrast).
Secondly, once set, 'Reduced CPU Usage'is very difficult to unset: you
have to open Settings as RPCEmu loads but before the desktop appears,
otherwise the setting persists.

My setup here is RPCEmu 0.9.1 running RISC OS 5.24 on a Windows 7 Acer
laptop. Network connection is enabled and working. Disconnecting the
network and quitting iconbar apps does not have any noticeable effect
on CPU background activity.

Is this a known bug, or is there another workaround?

--
George

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

Wednesday, 21 August 2019

Bugs 2682 and 2684

Hi guys,

I've had another crash, this time with CI #4835. If I understand the
problem (well, one link in the cause-effect chain) correctly, it's
caused by an attempt to store something at R5 + 36 when R5 = 0.

This looks like a null pointer problem. But how do I go back from
the log to see the source? I see unixlib being mentioned, but is it
an error in unixlib or a call with incorrect parameters? Or have I
failed to understand correctly?

I've added another crash dump to bug 2682, but I'm not sure it tells
us anything we didn't already know.

Is bug 2684 a duplicate of 2682?

David

Tuesday, 20 August 2019

Bugs 2682 and 2684

Hi guys,

I've had another crash, this time with CI #4835. If I understand the
problem (well, one link in the cause-effect chain) correctly, it's
caused by an attempt to store something at R5 + 36 when R5 = 0.

This looks like a null pointer problem. But how do I go back from
the log to see the source? I see unixlib being mentioned, but is it
an error in unixlib or a call with incorrect parameters? Or have I
failed to understand correctly?

I've added another crash dump to bug 2682, but I'm not sure it tells
us anything we didn't already know.

Is bug 2684 a duplicate of 2682?

David

Re: Test

On 20 Aug 2019 David Pitt <pittdj@pittdj.co.uk> wrote:

> In message <914A5569F8797053.e35b579a-0f7d-4ba9-9570-6921c029d203@mail
> .outlook.com>
> miyuki@crashnet.org.uk wrote:

>> Looks fine to me.

> My posts a few days ago bounced. A conversation was started on
> csa.misc. Webmail was resorted to.

> See what happens to this one.

It got here.

Best wishes,

Peter.

--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Re: Test

In message <914A5569F8797053.e35b579a-0f7d-4ba9-9570-6921c029d203@mail
.outlook.com>
miyuki@crashnet.org.uk wrote:

> Looks fine to me.

My posts a few days ago bounced. A conversation was started on
csa.misc. Webmail was resorted to.

See what happens to this one.

--
David Pitt
Titanium

Monday, 19 August 2019

Re: Test

Looks fine to me.

Sent from Huawei phone




On Mon, Aug 19, 2019 at 10:46 PM +0100, "Brian Howlett" <brian.groups@brianhowlett.me.uk> wrote:

On 19 Aug, Peter Young  wrote:    > On 19 Aug 2019  Brian Howlett  wrote:    >> Apologies in advance...    >> Issues sending to this list - using relay.plus.net has been failing, so  >> this is just to test if I can use my hosting provider's SMTP server to  >> do so instead.    > It arrived here, via Orpheus    > Best wishes,    > Peter.    Finally got Hermes figured out, but as not relevant for this list I will   add to the newsgroup thread instead.    At least it's working now!  --   Brian Howlett  ------------------------------------------------  "Fish - visionary genius, or just a big haddie?"    

Re: Test

On 19 Aug, Peter Young wrote:

> On 19 Aug 2019 Brian Howlett <brian.groups@brianhowlett.me.uk> wrote:

>> Apologies in advance...

>> Issues sending to this list - using relay.plus.net has been failing, so
>> this is just to test if I can use my hosting provider's SMTP server to
>> do so instead.

> It arrived here, via Orpheus

> Best wishes,

> Peter.

Finally got Hermes figured out, but as not relevant for this list I will
add to the newsgroup thread instead.

At least it's working now!
--
Brian Howlett
------------------------------------------------
"Fish - visionary genius, or just a big haddie?"

Re: Test

On 19 Aug 2019 Brian Howlett <brian.groups@brianhowlett.me.uk> wrote:

> Apologies in advance...

> Issues sending to this list - using relay.plus.net has been failing, so
> this is just to test if I can use my hosting provider's SMTP server to
> do so instead.

It arrived here, via Orpheus

Best wishes,

Peter.

--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Test

Apologies in advance...

Issues sending to this list - using relay.plus.net has been failing, so
this is just to test if I can use my hosting provider's SMTP server to
do so instead.
--
Brian Howlett
------------------------------------------------
"Fish - visionary genius, or just a big haddie?"

Saturday, 17 August 2019

Re: [gccsdk] gccsdk on arm

In message <57e4fa80cdchrisg@care4free.net>
Chris Gransden <chrisg@care4free.net> wrote:

> In article <f4ba7be457.mickenx@michael.grunditz.gmail.com>,
> Michael Grunditz <michael.grunditz@gmail.com> wrote:
>> Hi

>> I wonder if it is possible to build and use gccsdk on ARM Linux?
>> I would love to do so. My PC does heat up the room :)

> It builds successfully on a Raspberry Pi4 using Debian Buster (aarch32)
> making the below change after the initial build fails,

> Change line 2227 in srcdir.orig/gcc-trunk/gcc/config/arm/arm.h from 'if
> defined(__arm__)' to 'if !defined(__arm__)'.

Ah good. I also consider Pi4.


--
Michael Grunditz

_______________________________________________
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] gccsdk on arm

In article <f4ba7be457.mickenx@michael.grunditz.gmail.com>,
Michael Grunditz <michael.grunditz@gmail.com> wrote:
> Hi

> I wonder if it is possible to build and use gccsdk on ARM Linux?
> I would love to do so. My PC does heat up the room :)

It builds successfully on a Raspberry Pi4 using Debian Buster (aarch32)
making the below change after the initial build fails,

Change line 2227 in srcdir.orig/gcc-trunk/gcc/config/arm/arm.h from 'if
defined(__arm__)' to 'if !defined(__arm__)'.


_______________________________________________
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, 16 August 2019

Google

On RISC OS with NetSurf #4833 with Javascript enabled it takes an age
of hourglasses to get to http:/www.google.co.uk

It is OK without Javascript on RISC OS.

It is also OK with Javascript on on a new build on Ubuntu 18.04.

Cam anyone shed any further light on the scope of the issue.

https://bugs.netsurf-browser.org/mantis/view.php?id=2699

(Sent via webmail as list not accepting (Plusnet) emails.

David Pitt.

[gccsdk] gccsdk on arm

Hi

I wonder if it is possible to build and use gccsdk on ARM Linux?
I would love to do so. My PC does heat up the room :)

--
Michael Grunditz

_______________________________________________
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: RISC OS NetSurf no longer responding to URI files

On 14 Aug 2019 David Higton <dave@davehigton.me.uk> wrote:

> In message <52d17fe357.pnyoung@pnyoung.ormail.co.uk>
> Peter Young <pnyoung@ormail.co.uk> wrote:

>>On 4 Aug 2019 Peter Young <pnyoung@ormail.co.uk> wrote:
>>
>>> I would have reported this on the bug tracker, but I've found it
>>> impossible to access this, even after a change of password.
>>
>>> This is currently with 3.10 (Dev CI#4729) on RISC OS 5.25, RiscOS version
>>> (24 Aug 18).
>>
>>> I have been using URI files stored in Paul Vigay's NeXTBar app to launch
>>> favourite files. I'm lazy, and this is easier than finding them from the
>>> icon bar's Hot List. Fot the last three or so development builds this has
>>> stopped working, and even if I save the location in a RISC OS URI file and
>>> double-click on this it still doesn't work. Also, double-clicking on a URL
>>> in a MPro email doesn't work.
>>
>>Just to report that I can again run NetSurf URLs from NeXTBar and from
>>MPro. Many thanks to whoever fixed this. I've been too busy to access the
>>bug tracker, I'm afraid.

> I'd appreciate knowing whether you can access the bug tracker now,
> Peter, if you can make the time available. I have to say that at
> no time has access to Mantis stopped working for me.

Thanks, David, and after a lot of hair-tearing I can now access the bug
tracker. It wouldn't accept my login details, and if I tried to change my
password it said it had no record of my address! I had to set up a new
account using an alternative email address. All very unfriendly!

Anyway, I have been now able to submit two bug reports.

Best wishes,

Peter.

--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Thursday, 15 August 2019

Re: RISC OS NetSurf no longer responding to URI files

On 14 Aug 2019 David Higton <dave@davehigton.me.uk> wrote:

> In message <52d17fe357.pnyoung@pnyoung.ormail.co.uk>
> Peter Young <pnyoung@ormail.co.uk> wrote:

>>On 4 Aug 2019 Peter Young <pnyoung@ormail.co.uk> wrote:
>>
>>> I would have reported this on the bug tracker, but I've found it
>>> impossible to access this, even after a change of password.
>>
>>> This is currently with 3.10 (Dev CI#4729) on RISC OS 5.25, RiscOS version
>>> (24 Aug 18).
>>
>>> I have been using URI files stored in Paul Vigay's NeXTBar app to launch
>>> favourite files. I'm lazy, and this is easier than finding them from the
>>> icon bar's Hot List. Fot the last three or so development builds this has
>>> stopped working, and even if I save the location in a RISC OS URI file and
>>> double-click on this it still doesn't work. Also, double-clicking on a URL
>>> in a MPro email doesn't work.
>>
>>Just to report that I can again run NetSurf URLs from NeXTBar and from
>>MPro. Many thanks to whoever fixed this. I've been too busy to access the
>>bug tracker, I'm afraid.

> I'd appreciate knowing whether you can access the bug tracker now,
> Peter, if you can make the time available. I have to say that at
> no time has access to Mantis stopped working for me.

I shall try, but at the moment, at age eighty, I'm rather busy and tired.
Watch this space!

Best wishes,

Peter.

--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Re: RISC OS NetSurf no longer responding to URI files

In article <929902e457.pnyoung@pnyoung.ormail.co.uk>, Peter Young
<pnyoung@ormail.co.uk> wrote:
> Many thanks, Tim, for putting me on the right road.

My pleasure.

--

Tim Hill
Webmaster, www.timil.com

websites : php : RISC OS

Re: RISC OS NetSurf no longer responding to URI files

On 15 Aug 2019 Tim Hill <tim@timil.com> wrote:

> In article <be89d2e357.pnyoung@pnyoung.ormail.co.uk>, Peter Young
> <pnyoung@ormail.co.uk> wrote:
>> On 14 Aug 2019 Daniel Silverstone <dsilvers@netsurf-browser.org> wrote:

>>> On Wed, Aug 14, 2019 at 17:39:54 +0100, Peter Young wrote:
>>>> Just to report that I can again run NetSurf URLs from NeXTBar and
>>>> from MPro. Many thanks to whoever fixed this. I've been too busy to
>>>> access the bug tracker, I'm afraid.

>>> Unless I am very much mistaken, we have done literally nothing to
>>> make that be fixed. I imagine it must have been a local hiccough on
>>> your system.

>> I think it must be, and it's now back to not launching URLs from
>> NeXTBar and MPro. However, nothing has changed in my system. It
>> remains a mystery, and I have a work-round anyway.

> AIUI when URI files are run, the URI module sends a wimp message so a
> loaded app can intercept it and do with the file as it wishes or the
> module uses the Open_URI system variables to determine what to do.

> In the case of URL files the filer does something similar. If no app has
> intercepted a wimp message saying the file has been run (perhaps because
> the application is not on the iconbar) the "run type" for that filetype
> is examined and the appropriate action taken from that.

> You can check the current settings in a command window (ctrl+f12); yours
> will likely be slightly different.

[snip lots of interesting stuff.]

> Cure with:
> 1. Trial and error. Try quitting programs and retrying.
> 2. Find out which variable(s) is/are being 'broken' and use !Locate to
> find the culprit obey file which is (un/re)setting it.

I trialled and found the error, but didn't have time to go further with it
till today. Yesterday was a long, busy but excellent day, and in the
evening in spite of being tired I had a strange rush of blood to the
brain. I had a VRPC laptop connected by ShareFS, and found that URLs were
launched through UniServer, so this seemed to be the suspect app. I've
just been experimenting, and if UniServer is quit, NetSurf launches URLs
as it should do, and also used to.

I now have two Obey files which I can launch from StrongMen, one to quite
UniServer and one to run it, so I can switch between launching between
using NetSurf and Chrome on the W10 machine.

Problem more or less solved, but I still don't understand why this should
have suddenly happened a few weeks ago. Something I'll never know.

Many thanks, Tim, for putting me on the right road.

Best wishes,

Peter.

--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Re: RISC OS NetSurf no longer responding to URI files

In article <be89d2e357.pnyoung@pnyoung.ormail.co.uk>, Peter Young
<pnyoung@ormail.co.uk> wrote:
> On 14 Aug 2019 Daniel Silverstone <dsilvers@netsurf-browser.org> wrote:

> > On Wed, Aug 14, 2019 at 17:39:54 +0100, Peter Young wrote:
> >> Just to report that I can again run NetSurf URLs from NeXTBar and
> >> from MPro. Many thanks to whoever fixed this. I've been too busy to
> >> access the bug tracker, I'm afraid.

> > Unless I am very much mistaken, we have done literally nothing to
> > make that be fixed. I imagine it must have been a local hiccough on
> > your system.

> I think it must be, and it's now back to not launching URLs from
> NeXTBar and MPro. However, nothing has changed in my system. It
> remains a mystery, and I have a work-round anyway.

AIUI when URI files are run, the URI module sends a wimp message so a
loaded app can intercept it and do with the file as it wishes or the
module uses the Open_URI system variables to determine what to do.

In the case of URL files the filer does something similar. If no app has
intercepted a wimp message saying the file has been run (perhaps because
the application is not on the iconbar) the "run type" for that filetype
is examined and the appropriate action taken from that.

You can check the current settings in a command window (ctrl+f12); yours
will likely be slightly different.

*show *file*
...
File$Type_B28 : URL
...
File$Type_F91 : URI
...

*show *run*
...
Alias$@RunType_B28 : /SCSI::HardDisc4.$.Apps.!NetSurf.!Run -urlf %*0
...

*show *uri*
Alias$Open_URI_file : /SCSI::HardDisc4.$.Apps.!NetSurf.!Run -nowin
Alias$Open_URI_geo : SCSI::HardDisc4.$.Apps.!RiscOSM.!Run
Alias$Open_URI_http : /SCSI::HardDisc4.$.Apps.!NetSurf.!Run -nowin
Alias$Open_URI_https : /SCSI::HardDisc4.$.Apps.!NetSurf.!Run -nowin
Alias$Open_URI_x-stronghelp : Run SCSI::HardDisc4.$.Apps.!StrongHlp.!Run

(Some apps "wrongly" set a run type for URI files. Apparently that's not
the way they should be handled)

If the system isn't working there are two possible problems.
1. something loaded is discarding the wimp messages, or
2. something which may not be loaded has (un-)set the system variables

Cure with:
1. Trial and error. Try quitting programs and retrying.
2. Find out which variable(s) is/are being 'broken' and use !Locate to
find the culprit obey file which is (un/re)setting it.

HTH

--
Tim Hill
--------
Find an event to attend at:
http://timil.com/riscos/calendar/
Mimemap and other stuff:
http://timil.com/riscos/

Re: RISC OS NetSurf no longer responding to URI files

On 14 Aug 2019 Daniel Silverstone <dsilvers@netsurf-browser.org> wrote:

> On Wed, Aug 14, 2019 at 17:39:54 +0100, Peter Young wrote:
>> Just to report that I can again run NetSurf URLs from NeXTBar and from
>> MPro. Many thanks to whoever fixed this. I've been too busy to access the
>> bug tracker, I'm afraid.

> Unless I am very much mistaken, we have done literally nothing to make that
> be fixed. I imagine it must have been a local hiccough on your system.

I think it must be, and it's now back to not launching URLs from NeXTBar
and MPro. However, nothing has changed in my system. It remains a mystery,
and I have a work-round anyway.

Best wishes,

Peter.

--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

New SSL alert and Login features [Help Wanted]

Hi all,

As those of you who follow every CI release may have noticed, in the past week
or so, the Login dialog, and the SSL issue alerts have changed to be
in-browser. This was done to simplify the frontend APIs a little, and to unify
the functionality into the core so that it is easier to amend/extend for all
fronends at once.

In addition, we have added code to tell you the basic reason why a certificate
was not acceptable to the browser and done our best to make the dialogs look
fairly obvious to work with.

There are some known issues with the dialogs right now.

First and foremost, the dialogs are not in necessarily in their final form in
terms of visuals. Secondly they currently make no use of JavaScript and so
will work even if JS is off; but in future we may *add* functionality by JS so
it may become necessary for all but the most basic features. Finally (for now)
there is no way outside of the content to know for sure that the page was
generated by NetSurf itself. We will be adding an indicator which will show this
among other status information in the near future. This will likely take the
form of the 'padlock' feature you see on most modern browsers.

That said, we need your help to get these features nailed down as they are, so that
a future release can include them...

We need translations for the various messages used in those dialogs. The login
dialog is pretty much translated already, but the new SSL dialog needs a number
of strings translating. Those of you who are able to translate messages, you can
find the current set of messages at:
https://git.netsurf-browser.org/netsurf.git/tree/resources/FatMessages

The specific messages for the SSL dialog are around line 1070 in the "Privacy
error interface" section of the file. Translations for the certificate failure
reasons are most critical at this time. We may tweak the english text from
time to time, as we optimise how the dialog feels, and it goes with the
"PrivacyDescription" text which also needs translating for each supported
language.

The "%s" in PrivacyDescription is for the server's hostname, so any translation
should take that into account and include such a marker where the server name
should go.

We are also anxious that if you encounter problems with the new login or privacy
problem interfaces, that you report them to our bug tracker. I would appreciate
such issues being raised because this is all using very new internal features
in the browser which we hope to use for other functionality in the future and so
we need it well tested.

Further discussion on the topic of these two dialogs may come in time.

Thank you all,

Daniel.

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

Wednesday, 14 August 2019

Re: RISC OS NetSurf no longer responding to URI files

On Wed, Aug 14, 2019 at 17:39:54 +0100, Peter Young wrote:
> Just to report that I can again run NetSurf URLs from NeXTBar and from
> MPro. Many thanks to whoever fixed this. I've been too busy to access the
> bug tracker, I'm afraid.

Unless I am very much mistaken, we have done literally nothing to make that
be fixed. I imagine it must have been a local hiccough on your system.

D.

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

Re: RISC OS NetSurf no longer responding to URI files

In message <52d17fe357.pnyoung@pnyoung.ormail.co.uk>
Peter Young <pnyoung@ormail.co.uk> wrote:

>On 4 Aug 2019 Peter Young <pnyoung@ormail.co.uk> wrote:
>
>> I would have reported this on the bug tracker, but I've found it
>> impossible to access this, even after a change of password.
>
>> This is currently with 3.10 (Dev CI#4729) on RISC OS 5.25, RiscOS version
>> (24 Aug 18).
>
>> I have been using URI files stored in Paul Vigay's NeXTBar app to launch
>> favourite files. I'm lazy, and this is easier than finding them from the
>> icon bar's Hot List. Fot the last three or so development builds this has
>> stopped working, and even if I save the location in a RISC OS URI file and
>> double-click on this it still doesn't work. Also, double-clicking on a URL
>> in a MPro email doesn't work.
>
>Just to report that I can again run NetSurf URLs from NeXTBar and from
>MPro. Many thanks to whoever fixed this. I've been too busy to access the
>bug tracker, I'm afraid.

I'd appreciate knowing whether you can access the bug tracker now,
Peter, if you can make the time available. I have to say that at
no time has access to Mantis stopped working for me.

David

Re: RISC OS NetSurf no longer responding to URI files

On 4 Aug 2019 Peter Young <pnyoung@ormail.co.uk> wrote:

> I would have reported this on the bug tracker, but I've found it
> impossible to access this, even after a change of password.

> This is currently with 3.10 (Dev CI#4729) on RISC OS 5.25, RiscOS version
> (24 Aug 18).

> I have been using URI files stored in Paul Vigay's NeXTBar app to launch
> favourite files. I'm lazy, and this is easier than finding them from the
> icon bar's Hot List. Fot the last three or so development builds this has
> stopped working, and even if I save the location in a RISC OS URI file and
> double-click on this it still doesn't work. Also, double-clicking on a URL
> in a MPro email doesn't work.

Just to report that I can again run NetSurf URLs from NeXTBar and from
MPro. Many thanks to whoever fixed this. I've been too busy to access the
bug tracker, I'm afraid.

Best wishes,

Peter.

--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Tuesday, 13 August 2019

Re: [gccsdk] Fontconfig conf file

On 13/08/2019 09:13, Michael Grunditz wrote:
> Any ideas what it might be with the null in fsclose?

I'm not sure what you mean, fsclose doesn't deal with filenames?

> Can it be pathnames translations?

No, the filenames below look OK to me and are similar to what I have.
If fsopen returns a valid fd (i.e., not -1), then you know it opened
the file successfully.

Is it still crashing in fc_Patternreference? I would check the incoming
arguments to make sure they're valid and if not trace back the call
chain to see what provided the invalid argument.

I assume you're using shared libraries? You can use *SOMAddress to find
the offset in the fontconfig library of the crash and then load it into
!Zap to look at the disassembler and find the rogue instruction. Cross
reference that with registers from *showregs and you should see a reason
for the crash. It may be something obvious like a NULL value on entry.

> On Sun, 11 Aug 2019 at 16:12, Michael Grunditz
> <michael.grunditz@gmail.com> wrote:
>>
>> In message <CAAqgp_Rzki8WaKbG01qx7qgyckjzKKiRAFzoZvFPSAVtVArb0g@mail.gmail
>> .com> you wrote:
>>
>>> On Sun, 11 Aug 2019 at 13:02, Alex Macfarlane Smith
>>> <alex@archifishal.co.uk> wrote:
>>>>
>>>>> In message <c2905dba-6c1b-90ce-a4b6-6b411f58c0ba@sky.com>
>>>>> Lee Noar <leenoar@sky.com> wrote:
>>>>>
>>>>>> On 08/08/2019 22:19, Michael Grunditz wrote:
>>>>>>> In message <b38eba9f-d632-fc7a-60a0-b68a1ea5f643@sky.com>
>>>>>
>>>>>
>>>>>> If you are able to recompile UnixLib, it can be useful to put some
>>>>>> debug info in __fsopen and __fsstat to see what files are being
>>>>>> accessed.
>>>>>
>>>>>> Lee.
>>>>>
>>>>> More printouts :
>>>>>
>>>>> It expands paths for fsstat , are they too long?
>>>>>
>>>>> open: <UnixFC$Dir>.fonts.fonts/conf
>>>>> open: UnixFont:truetype
>>>>> open: UnixFC:cache.8c8c87c04bac0d8a276f876f0ed7af16-arm-riscos/cache-4
>>>>> fstat: ADFS::Backup.$.!UnixFC.cache.8c8c87c04bac0d8a276f876f0ed7af16-arm-r
>>>>> iscos/cache-4
>>>>> open: UnixFont:truetype.ttf-bitstream-vera
>>>>> open: UnixFC:cache.9ca7ddc6a18fafa713ae4595326c1c67-arm-riscos/cache-4
>>>>> fstat: ADFS::Backup.$.!UnixFC.cache.9ca7ddc6a18fafa713ae4595326c1c67-arm-r
>>>>> iscos/cache-4
>>>>> font error 1:
>>
>> fsclose always ends up with null in filename ..
>
> _______________________________________________
> 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 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] Fontconfig conf file

Any ideas what it might be with the null in fsclose?
Can it be pathnames translations?

On Sun, 11 Aug 2019 at 16:12, Michael Grunditz
<michael.grunditz@gmail.com> wrote:
>
> In message <CAAqgp_Rzki8WaKbG01qx7qgyckjzKKiRAFzoZvFPSAVtVArb0g@mail.gmail
> .com> you wrote:
>
> > On Sun, 11 Aug 2019 at 13:02, Alex Macfarlane Smith
> > <alex@archifishal.co.uk> wrote:
> >>
> >>> In message <c2905dba-6c1b-90ce-a4b6-6b411f58c0ba@sky.com>
> >>> Lee Noar <leenoar@sky.com> wrote:
> >>>
> >>>> On 08/08/2019 22:19, Michael Grunditz wrote:
> >>>>> In message <b38eba9f-d632-fc7a-60a0-b68a1ea5f643@sky.com>
> >>>
> >>>
> >>>> If you are able to recompile UnixLib, it can be useful to put some
> >>>> debug info in __fsopen and __fsstat to see what files are being
> >>>> accessed.
> >>>
> >>>> Lee.
> >>>
> >>> More printouts :
> >>>
> >>> It expands paths for fsstat , are they too long?
> >>>
> >>> open: <UnixFC$Dir>.fonts.fonts/conf
> >>> open: UnixFont:truetype
> >>> open: UnixFC:cache.8c8c87c04bac0d8a276f876f0ed7af16-arm-riscos/cache-4
> >>> fstat: ADFS::Backup.$.!UnixFC.cache.8c8c87c04bac0d8a276f876f0ed7af16-arm-r
> >>> iscos/cache-4
> >>> open: UnixFont:truetype.ttf-bitstream-vera
> >>> open: UnixFC:cache.9ca7ddc6a18fafa713ae4595326c1c67-arm-riscos/cache-4
> >>> fstat: ADFS::Backup.$.!UnixFC.cache.9ca7ddc6a18fafa713ae4595326c1c67-arm-r
> >>> iscos/cache-4
> >>> font error 1:
>
> fsclose always ends up with null in filename ..

_______________________________________________
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, 11 August 2019

Re: [gccsdk] Fontconfig conf file

In message <CAAqgp_Rzki8WaKbG01qx7qgyckjzKKiRAFzoZvFPSAVtVArb0g@mail.gmail
.com> you wrote:

> On Sun, 11 Aug 2019 at 13:02, Alex Macfarlane Smith
> <alex@archifishal.co.uk> wrote:
>>
>>> In message <c2905dba-6c1b-90ce-a4b6-6b411f58c0ba@sky.com>
>>> Lee Noar <leenoar@sky.com> wrote:
>>>
>>>> On 08/08/2019 22:19, Michael Grunditz wrote:
>>>>> In message <b38eba9f-d632-fc7a-60a0-b68a1ea5f643@sky.com>
>>>
>>>
>>>> If you are able to recompile UnixLib, it can be useful to put some
>>>> debug info in __fsopen and __fsstat to see what files are being
>>>> accessed.
>>>
>>>> Lee.
>>>
>>> More printouts :
>>>
>>> It expands paths for fsstat , are they too long?
>>>
>>> open: <UnixFC$Dir>.fonts.fonts/conf
>>> open: UnixFont:truetype
>>> open: UnixFC:cache.8c8c87c04bac0d8a276f876f0ed7af16-arm-riscos/cache-4
>>> fstat: ADFS::Backup.$.!UnixFC.cache.8c8c87c04bac0d8a276f876f0ed7af16-arm-r
>>> iscos/cache-4
>>> open: UnixFont:truetype.ttf-bitstream-vera
>>> open: UnixFC:cache.9ca7ddc6a18fafa713ae4595326c1c67-arm-riscos/cache-4
>>> fstat: ADFS::Backup.$.!UnixFC.cache.9ca7ddc6a18fafa713ae4595326c1c67-arm-r
>>> iscos/cache-4
>>> font error 1:

fsclose always ends up with null in filename ..

_______________________________________________
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] Fontconfig conf file

In message <CAAqgp_Rzki8WaKbG01qx7qgyckjzKKiRAFzoZvFPSAVtVArb0g@mail.gmail
.com>
Michael Grunditz <michael.grunditz@gmail.com> wrote:

> On Sun, 11 Aug 2019 at 13:02, Alex Macfarlane Smith
> <alex@archifishal.co.uk> wrote:
>>
>>> In message <c2905dba-6c1b-90ce-a4b6-6b411f58c0ba@sky.com>
>>> Lee Noar <leenoar@sky.com> wrote:
>>>
>>>> On 08/08/2019 22:19, Michael Grunditz wrote:
>>>>> In message <b38eba9f-d632-fc7a-60a0-b68a1ea5f643@sky.com>
>>>
>>>
>>>> If you are able to recompile UnixLib, it can be useful to put some
>>>> debug info in __fsopen and __fsstat to see what files are being
>>>> accessed.
>>>
>>>> Lee.
>>>
>>> More printouts :
>>>
>>> It expands paths for fsstat , are they too long?
>>>
>>> open: <UnixFC$Dir>.fonts.fonts/conf
>>> open: UnixFont:truetype
>>> open: UnixFC:cache.8c8c87c04bac0d8a276f876f0ed7af16-arm-riscos/cache-4
>>> fstat: ADFS::Backup.$.!UnixFC.cache.8c8c87c04bac0d8a276f876f0ed7af16-arm-r
>>> iscos/cache-4
>>> open: UnixFont:truetype.ttf-bitstream-vera
>>> open: UnixFC:cache.9ca7ddc6a18fafa713ae4595326c1c67-arm-riscos/cache-4
>>> fstat: ADFS::Backup.$.!UnixFC.cache.9ca7ddc6a18fafa713ae4595326c1c67-arm-r
>>> iscos/cache-4
>>> font error 1:
>>> : No such file or directory
>>>
>>
>> Is that a mixup between . and / ? (should the /cache-4 at the end be
>> .cache-4 ? )
>>
> It ends in /cache-4. Maybe mail displays wrong.

Quite interesting .. In my build all close calls fails with no such file.

All confused , all paths and files looks ok.
--
Michael Grunditz

_______________________________________________
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] Fontconfig conf file

On Sun, 11 Aug 2019 at 13:02, Alex Macfarlane Smith
<alex@archifishal.co.uk> wrote:
>
> > In message <c2905dba-6c1b-90ce-a4b6-6b411f58c0ba@sky.com>
> > Lee Noar <leenoar@sky.com> wrote:
> >
> >> On 08/08/2019 22:19, Michael Grunditz wrote:
> >>> In message <b38eba9f-d632-fc7a-60a0-b68a1ea5f643@sky.com>
> >
> >
> >> If you are able to recompile UnixLib, it can be useful to put some
> >> debug info in __fsopen and __fsstat to see what files are being
> >> accessed.
> >
> >> Lee.
> >
> > More printouts :
> >
> > It expands paths for fsstat , are they too long?
> >
> > open: <UnixFC$Dir>.fonts.fonts/conf
> > open: UnixFont:truetype
> > open: UnixFC:cache.8c8c87c04bac0d8a276f876f0ed7af16-arm-riscos/cache-4
> > fstat: ADFS::Backup.$.!UnixFC.cache.8c8c87c04bac0d8a276f876f0ed7af16-arm-r
> > iscos/cache-4
> > open: UnixFont:truetype.ttf-bitstream-vera
> > open: UnixFC:cache.9ca7ddc6a18fafa713ae4595326c1c67-arm-riscos/cache-4
> > fstat: ADFS::Backup.$.!UnixFC.cache.9ca7ddc6a18fafa713ae4595326c1c67-arm-r
> > iscos/cache-4
> > font error 1:
> > : No such file or directory
> >
>
> Is that a mixup between . and / ? (should the /cache-4 at the end be
> .cache-4 ? )
>
It ends in /cache-4. Maybe mail displays wrong.

_______________________________________________
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] Fontconfig conf file

> In message <c2905dba-6c1b-90ce-a4b6-6b411f58c0ba@sky.com>
> Lee Noar <leenoar@sky.com> wrote:
>
>> On 08/08/2019 22:19, Michael Grunditz wrote:
>>> In message <b38eba9f-d632-fc7a-60a0-b68a1ea5f643@sky.com>
>
>
>> If you are able to recompile UnixLib, it can be useful to put some
>> debug info in __fsopen and __fsstat to see what files are being
>> accessed.
>
>> Lee.
>
> More printouts :
>
> It expands paths for fsstat , are they too long?
>
> open: <UnixFC$Dir>.fonts.fonts/conf
> open: UnixFont:truetype
> open: UnixFC:cache.8c8c87c04bac0d8a276f876f0ed7af16-arm-riscos/cache-4
> fstat: ADFS::Backup.$.!UnixFC.cache.8c8c87c04bac0d8a276f876f0ed7af16-arm-r
> iscos/cache-4
> open: UnixFont:truetype.ttf-bitstream-vera
> open: UnixFC:cache.9ca7ddc6a18fafa713ae4595326c1c67-arm-riscos/cache-4
> fstat: ADFS::Backup.$.!UnixFC.cache.9ca7ddc6a18fafa713ae4595326c1c67-arm-r
> iscos/cache-4
> font error 1:
> : No such file or directory
>

Is that a mixup between . and / ? (should the /cache-4 at the end be
.cache-4 ? )


_______________________________________________
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] Fontconfig conf file

In message <c2905dba-6c1b-90ce-a4b6-6b411f58c0ba@sky.com>
Lee Noar <leenoar@sky.com> wrote:

> On 08/08/2019 22:19, Michael Grunditz wrote:
>> In message <b38eba9f-d632-fc7a-60a0-b68a1ea5f643@sky.com>


> If you are able to recompile UnixLib, it can be useful to put some
> debug info in __fsopen and __fsstat to see what files are being
> accessed.

> Lee.

More printouts :

It expands paths for fsstat , are they too long?

open: <UnixFC$Dir>.fonts.fonts/conf
open: UnixFont:truetype
open: UnixFC:cache.8c8c87c04bac0d8a276f876f0ed7af16-arm-riscos/cache-4
fstat: ADFS::Backup.$.!UnixFC.cache.8c8c87c04bac0d8a276f876f0ed7af16-arm-r
iscos/cache-4
open: UnixFont:truetype.ttf-bitstream-vera
open: UnixFC:cache.9ca7ddc6a18fafa713ae4595326c1c67-arm-riscos/cache-4
fstat: ADFS::Backup.$.!UnixFC.cache.9ca7ddc6a18fafa713ae4595326c1c67-arm-r
iscos/cache-4
font error 1:
: No such file or directory

_______________________________________________
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, 9 August 2019

Re: [gccsdk] Fontconfig conf file

In message <c2905dba-6c1b-90ce-a4b6-6b411f58c0ba@sky.com>



Also .. added perror right before pattern ref:

No such file or directory.. But as far as I can see the fc cache is there
with the filename requested.

--
Michael Grunditz

_______________________________________________
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] Fontconfig conf file

In message <c2905dba-6c1b-90ce-a4b6-6b411f58c0ba@sky.com>
Lee Noar <leenoar@sky.com> wrote:

> On 08/08/2019 22:19, Michael Grunditz wrote:
>> In message <b38eba9f-d632-fc7a-60a0-b68a1ea5f643@sky.com>
>> Lee Noar <leenoar@sky.com> wrote:
>>
>>> need to have been seen by the filer in order for the files to be found.
>>
>>> setvars adds --with-baseconfigdir=/<UnixFC$Dir>/fonts to configure so
>>> that fontconfig knows where its config files are.
>>
>> Hello again,
>>
>> Just added a perror().. Gave me too many open files!
>> What is the limit? ( this is why the file couldnt be opened) But with
>> precompiled fontconfig I don't get that far at all.

> The limit is 256, set by the SUL module.

> If you are able to recompile UnixLib, it can be useful to put some
> debug info in __fsopen and __fsstat to see what files are being
> accessed.



I get this:

(precompiled fontconfig)

<UnixFC$Dir>.fonts.fonts/conf
UnixFont:truetype
UnixFC:cache.8c8c87c04bac0d8a276f876f0ed7af16-arm-riscos/cache-4
UnixFont:truetype.dejavu
UnixFC:cache.931beb3be3e34464057f94cc0a77e9f5-arm-riscos/cache-4
UnixFont:truetype.ttf-bitstream-vera
UnixFC:cache.9ca7ddc6a18fafa713ae4595326c1c67-arm-riscos/cache-4


I dunno .. Browser looks for serif , or sans serif.. Both families are
present. It crashes in :

(101a9e7c) pc: 5a6f8abc lr: 568bdf5c sp: 101a9e80
IA__FcPatternReference()

Which means that "select" didn't get anything usefull from fontcache.

_______________________________________________
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] Fontconfig conf file

On 08/08/2019 22:19, Michael Grunditz wrote:
> In message <b38eba9f-d632-fc7a-60a0-b68a1ea5f643@sky.com>
> Lee Noar <leenoar@sky.com> wrote:
>
>> need to have been seen by the filer in order for the files to be found.
>
>> setvars adds --with-baseconfigdir=/<UnixFC$Dir>/fonts to configure so
>> that fontconfig knows where its config files are.
>
> Hello again,
>
> Just added a perror().. Gave me too many open files!
> What is the limit? ( this is why the file couldnt be opened) But with
> precompiled fontconfig I don't get that far at all.

The limit is 256, set by the SUL module.

If you are able to recompile UnixLib, it can be useful to put some
debug info in __fsopen and __fsstat to see what files are being
accessed.

Lee.

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

Thursday, 8 August 2019

Re: [gccsdk] Fontconfig conf file

In message <b38eba9f-d632-fc7a-60a0-b68a1ea5f643@sky.com>
Lee Noar <leenoar@sky.com> wrote:

> need to have been seen by the filer in order for the files to be found.

> setvars adds --with-baseconfigdir=/<UnixFC$Dir>/fonts to configure so
> that fontconfig knows where its config files are.

Hello again,

Just added a perror().. Gave me too many open files!
What is the limit? ( this is why the file couldnt be opened) But with
precompiled fontconfig I don't get that far at all.

_______________________________________________
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] Fontconfig conf file

In message <b38eba9f-d632-fc7a-60a0-b68a1ea5f643@sky.com>
Lee Noar <leenoar@sky.com> wrote:

> --with-baseconfigdir=/<UnixFC$Dir>/fonts

Yes I have seen that .. Fontconfig doesn't build for me and taking
prebuilt bombs at fc_Patternreference that with my own build is equal to
cannot open conf file.

If it isn't the config file , what can it be?

--
Michael Grunditz

_______________________________________________
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] Fontconfig conf file

On 07/08/2019 21:40, Michael Grunditz wrote:
> Hi
>
> I wonder how fontconfig from autobuilder finds its config file?
>
> I never managed to get that part to work. Right now I run with a hacked
> version that looks after the file relative to see.
>
> However, in my browser there are pages that doesn't take no as an answer
> when requesting fonts.?? Fontconfig crash after a while.
>
> Is there a env variable I can set?

The config files are stored in !UnixFC and the fonts in !UnixFont. These
need to have been seen by the filer in order for the files to be found.

setvars adds --with-baseconfigdir=/<UnixFC$Dir>/fonts to configure so
that fontconfig knows where its config files are.

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

Wednesday, 7 August 2019

[gccsdk] Fontconfig conf file

Hi

I wonder how fontconfig from autobuilder finds its config file?

I never managed to get that part to work. Right now I run with a hacked version that looks after the file relative to see.

However, in my browser there are pages that doesn't take no as an answer when requesting fonts.  Fontconfig crash after a while.

Is there a env variable I can set?

Michael 

[gccsdk] Patch to correctly set _XOPEN_SOURCE when _POSIX_C_SOURCE is defined

Index: recipe/files/gcc/libunixlib/include/features.h
===================================================================
--- recipe/files/gcc/libunixlib/include/features.h (revision 7208)
+++ recipe/files/gcc/libunixlib/include/features.h (working copy)
@@ -235,13 +235,13 @@
#endif

#if (_POSIX_C_SOURCE - 0) >= 200112L
-# define __USE_XOPEN2K 1
-# undef __USE_ISOC99
-# define __USE_ISOC99 1
+# undef _XOPEN_SOURCE
+# define _XOPEN_SOURCE 600
#endif

#if (_POSIX_C_SOURCE - 0) >= 200809L
-# define __USE_XOPEN2K8 1
+# undef _XOPEN_SOURCE
+# define _XOPEN_SOURCE 700
# undef _ATFILE_SOURCE
# define _ATFILE_SOURCE 1
#endif
Hi

This patch ensures that _XOPEN_SOURCE is set correctly when _POSIX_C_SOURCE is greater than or equal to 200112L. Previously, defining _POSIX_C_SOURCE to 200112L would enable XPG6 functions, but not functions for earlier XPG versions.


Regards
Cameron

Monday, 5 August 2019

Re: RISC OS NetSurf no longer responding to URI files

On Sun, Aug 04, 2019 at 02:17:36PM +0100, Peter Young wrote:
> I would have reported this on the bug tracker, but I've found it
> impossible to access this, even after a change of password.

I just tried this myself from RISC OS build and I can log into mantis

>
> This is currently with 3.10 (Dev CI#4729) on RISC OS 5.25, RiscOS version
> (24 Aug 18).
>

This build is no longer available to us in the CI. please can you
navigate to about:testament and report the big hex number shown there

> I have been using URI files so=red in Paul Vigay's NeXTBar app to launch
> favourite files. I'm lazy, and this is easier than finding them from the
> icon bar's Hot List. Fot the last three or so development builds this has
> stopped working, and even if I save the location in a RISC OS URI file and
> double-click on this it still doesn't work. Also, double-clicking on a URL
> in a MPro email doesn't work.

We have not changed handling of such files in the RISC OS version of
NetSurf only improvements to (scale) zoom handling (if you notice any
issues there I probbaly made a mistake.)

Perhaps you have another application responding to URI files and
preventing NetSurf from handling them. Apologies I cannot be of more
assistance here as RISC OS is not a platform I use often.

>
> I've just discovered that if I save a location as an ANT URL file and
> double-click on this, it does work. However, this is the format NeXTBar
> uses to store URLs, so I am not totally puzzled.
>
> Does anyone know why this should happen?
>
> Best wishes,
>
> Peter.
>
> --
> Peter Young (zfc Hg) and family
> Prestbury, Cheltenham, Glos. GL52, England
> http://pnyoung.orpheusweb.co.uk
> pnyoung@ormail.co.uk
>
>

--
Regards Vincent
http://www.kyllikki.org/

Sunday, 4 August 2019

Re: Local history update

On 4 Aug 2019 Michael Drake <tlsa@netsurf-browser.org> wrote:

> Hi all,

> The local history window has had a few updates.

> * It will now open scrolled to show the current entry.
> * It can now be navigated with the keyboard. (Cursor
> Left, Right, Up, Down, and Return.)
> * Thumbnails are now slightly larger, and their dimensions
> take account of the screen DPI.

> Cheers,

Looks good, thank-you to the developers.

Best wishes,

Peter.

--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Local history update

Hi all,

The local history window has had a few updates.

* It will now open scrolled to show the current entry.
* It can now be navigated with the keyboard. (Cursor
Left, Right, Up, Down, and Return.)
* Thumbnails are now slightly larger, and their dimensions
take account of the screen DPI.

Cheers,

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

RISC OS NetSurf no longer responding to URI files

I would have reported this on the bug tracker, but I've found it
impossible to access this, even after a change of password.

This is currently with 3.10 (Dev CI#4729) on RISC OS 5.25, RiscOS version
(24 Aug 18).

I have been using URI files so=red in Paul Vigay's NeXTBar app to launch
favourite files. I'm lazy, and this is easier than finding them from the
icon bar's Hot List. Fot the last three or so development builds this has
stopped working, and even if I save the location in a RISC OS URI file and
double-click on this it still doesn't work. Also, double-clicking on a URL
in a MPro email doesn't work.

I've just discovered that if I save a location as an ANT URL file and
double-click on this, it does work. However, this is the format NeXTBar
uses to store URLs, so I am not totally puzzled.

Does anyone know why this should happen?

Best wishes,

Peter.

--
Peter Young (zfc Hg) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk