Re: [Rpcemu] Big Sur on Mac and RPCEmu?

Thanks for this reply. It is setting in motion a careful process that starts with 'Make a Bootable backup on the portable test machine' so that I can exit gracefully if any pear shaped objects appear.

Tim

--
Tim Powys-Lybbe tim@powys.org
for a miscellany of bygones: http://powys.org/

> On 28 Nov 2020, at 1:20 pm, David Pitt <pittdj@pittdj.co.uk> wrote:
>
> Tim Powys-Lybbe, on 28 Nov, wrote:
>
>> I have been faithfully following other instructions not to load Big Sur
>> onto my Macs. But those instructions are slowly withering away and RPCEmu
>> has raised itself to my horizon.
>>
>> Has anyone tried to run RPCEmu within Mac's Big Sur? And what happened?
>
> The builds below work as before on Big Sur on an Intel Mac.
>
> https://github.com/Septercius/rpcemu-dev/releases
>
> --
> David Pitt
>
> _______________________________________________
> RPCEmu mailing list
> RPCEmu@riscos.info
> http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

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

Re: Dragging from URL icon

On 29 Nov, lists@bazleyfamily.co.uk typed:

> Thanks for confirming. It's probably an unintentional loss of
> functionality and worth reporting.
> https://bugs.netsurf-browser.org/mantis/view.php?id=2799

Thank you, Harriet.

--
Bernard
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Dragging from URL icon

On 26 Nov 2020 as I do recall,
Bernard Boase wrote:

> On 25 Nov, lists@bazleyfamily.co.uk typed:
>
> > I upgraded to v5223 and have just noticed that dragging a URL from the URL
> > icon no longer produces any result - you have to go via Page->Save
> > location->Text, or try to select, copy and paste.
>
> I can confirm that that drag functionality is lost here too on both
> ARMX6 OS 5.27 and Iyonix OS 5.28 with Netsurf #5223.
>
> And that it continues to work on the Iyonix OS 5.28 if I revert to an
> earlier Netsurf (#5216 was to hand).
>
> Rather annoying.Good if it can be reinstated.
>
Thanks for confirming. It's probably an unintentional loss of
functionality and worth reporting.
https://bugs.netsurf-browser.org/mantis/view.php?id=2799


--
Harriet Bazley == Loyaulte me lie ==

Cloning is the sincerest form of flattery.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: [Rpcemu] Big Sur on Mac and RPCEmu?

Tim Powys-Lybbe, on 28 Nov, wrote:

> I have been faithfully following other instructions not to load Big Sur
> onto my Macs. But those instructions are slowly withering away and RPCEmu
> has raised itself to my horizon.
>
> Has anyone tried to run RPCEmu within Mac's Big Sur? And what happened?

The builds below work as before on Big Sur on an Intel Mac.

https://github.com/Septercius/rpcemu-dev/releases

--
David Pitt

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

Re: [Rpcemu] Big Sur on Mac and RPCEmu?

In article <691239B7-41C6-48D4-A689-304BDE8D0EA1@powys.org>,
Tim Powys-Lybbe <tim@powys.org> wrote:
> I have been faithfully following other instructions not to load Big Sur onto my Macs. But those instructions are slowly withering away and RPCEmu has raised itself to my horizon.

> Has anyone tried to run RPCEmu within Mac's Big Sur? And what happened?

Only on Apple Silicon.
It runs OK on Apple Silicon. The dynamic recompiler version is unusable
using Rosetta 2. The interpreter version runs OK but slower than a real SA
Risc PC.
Running natively runs about 30% faster. A bit faster than a real SA Risc
PC. There's no arm64 dynamic recompiler so only the interpreter version
runs.


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

[Rpcemu] Big Sur on Mac and RPCEmu?

I have been faithfully following other instructions not to load Big Sur onto my Macs. But those instructions are slowly withering away and RPCEmu has raised itself to my horizon.

Has anyone tried to run RPCEmu within Mac's Big Sur? And what happened?

regards,

Tim

--
Tim Powys-Lybbe tim@powys.org
for a miscellany of bygones: http://powys.org/

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

Re: Dragging from URL icon

In article <7df807d558.harriet@bazleyfamily.co.uk>,
Harriet Bazley <lists@bazleyfamily.co.uk> wrote:
> I upgraded to v5223 and have just noticed that dragging a URL from the
> URL icon no longer produces any result - you have to go via Page->Save
> location->Text, or try to select, copy and paste.

> Is this an intentional change?

I'm not sure what you are complaing about Harriet but Copy and Paste
hasn't worked properly in NetSurf for ages.

--
Stuart Winsor

Tools With A Mission
sending tools across the world
http://www.twam.co.uk/
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Dragging from URL icon

Michael Drake, on 25 Nov, wrote:

> Hi,
>
> On 25/11/2020 16:51, Harriet Bazley wrote:
> > I upgraded to v5223 and have just noticed that dragging a URL from the
> > URL icon no longer produces any result - you have to go via Page->Save
> > location->Text, or try to select, copy and paste.

As tested on OS5.28 and later the URL drag and drop stops working with
#5220.

> > Is this an intentional change?

> Not completely. Ideally if you're on a version of the OS that
> supports text selection in writable icons, a URL drag should
> select text.

Checked with OS5.28 and later the text in the URL bar cannot be selected.

The URL text can be selected fron the Open URL tool and then dragged out
with OS5's drag and drop.

> It needs a RISC OS developer to make any sense of it, however.


--
David Pitt
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Dragging from URL icon

On 25 Nov, lists@bazleyfamily.co.uk typed:

> I upgraded to v5223 and have just noticed that dragging a URL from the URL
> icon no longer produces any result - you have to go via Page->Save
> location->Text, or try to select, copy and paste.

I can confirm that that drag functionality is lost here too on both
ARMX6 OS 5.27 and Iyonix OS 5.28 with Netsurf #5223.

And that it continues to work on the Iyonix OS 5.28 if I revert to an
earlier Netsurf (#5216 was to hand).

Rather annoying.Good if it can be reinstated.

--
Bernard
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Dragging from URL icon

Hi,

On 25/11/2020 16:51, Harriet Bazley wrote:
> I upgraded to v5223 and have just noticed that dragging a URL from the
> URL icon no longer produces any result - you have to go via Page->Save
> location->Text, or try to select, copy and paste.

> Is this an intentional change?

Not completely. Ideally if you're on a version of the OS that
supports text selection in writable icons, a URL drag should
select text.

It needs a RISC OS developer to make any sense of it, however.

Contributions welcome!

Cheers,

--
Michael Drake
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Dragging from URL icon

On 25 Nov 2020 Harriet Bazley <lists@bazleyfamily.co.uk> wrote:

> I upgraded to v5223 and have just noticed that dragging a URL from the
> URL icon no longer produces any result - you have to go via Page->Save
> location->Text, or try to select, copy and paste.

Seems to work here, if I've understood what you wrote.

ARMX6, RISC OS 5.27, RiscOS version 5.27 (30-Sep-20) FWIW.

Best wishes,

Peter.

--
Peter Young (zfc Tl) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Dragging from URL icon

I upgraded to v5223 and have just noticed that dragging a URL from the
URL icon no longer produces any result - you have to go via Page->Save
location->Text, or try to select, copy and paste.

Is this an intentional change?

--
Harriet Bazley == Loyaulte me lie ==

ObChocolate: Nice!
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: [gccsdk] malloc

> The reason for all this is , malloc fails for me , so I decided to roll my own.
> In that I wanted to make sure that the mem and addresses are the same as
> expected from malloc.
>
Got my malloc engine to work! No more memory crashes.

_______________________________________________
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] malloc

> Sorry, I think we might have our wires crossed :-) It's the address
> returned by malloc that needs to be 8 byte aligned rather than the
> number of bytes returned.
Yes I understand this.. But isn't malloc (unix) using padding ?

> The problem is, some instructions, for example LDRD, require an 8
> byte aligned base address. If we use malloc to allocate a structure
> that starts with an 8 byte type that the compiler might use LDRD to
> load and malloc returns a 4 byte (but not 8) aligned address, then it
> will probably abort.

I have been testing with mallocs , and the addresses returned seems to
be 8 byte aligned. I guess gcc has the answer.

> In fact, I fell foul of something similar in the dynamic linker
> when porting GCC 8/10; I had to ensure that the library data segments
> retained the original alignment that the compiler/linker gave them to
> prevent LDRD from aborting.
> I suspect that newer versions (than 4.7) of GCC will expect malloc'ed
> memory to be 8 byte aligned and pad structures accordingly.
> Unfortunately, we're a bit behind there, and I think it is something we
> need to look at.
OK

The reason for all this is , malloc fails for me , so I decided to roll my own.
In that I wanted to make sure that the mem and addresses are the same as
expected from malloc.

Michael

_______________________________________________
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] malloc

On 24/11/2020 16:08, Michael Grunditz wrote:
>>> Odd but when 8 mmap areas created malloc doesn't use heap, but produces
>>> a crash.
>
> Checked now.. there is no mmap call. But the problem might be something else.
> If I hardcode a insane amount of stack , the mallocs uses heap , to a
> much higher extent.
>
>> No, n is the number of bytes you require. We do have memalign(),
>> although I'm not sure if it's exported in the headers.
>> I believe, off the top of my head that, malloc should return an address
>> aligned to the host machine's pointer size, so 4 byte alignment for
>> 32bits and 8 byte alignment for 64bits. Having said that, that doesn't
>> account for double word loads that may require 8 byte alignment. It's
>> quite possible that our malloc should be returning 8 byte aligned
>> addresses to account for new processor requirements, I should probably
>> look into that.
>>
>
> I did a unscientific test. Malloc 12 bytes , fill with 16 bytes, which
> worked , so malloc is 8 byte aligned.
> Maybe just lucky shot .. filling with 18 bytes , gives me bad mem at the end.

Sorry, I think we might have our wires crossed :-) It's the address
returned by malloc that needs to be 8 byte aligned rather than the
number of bytes returned.
The problem is, some instructions, for example LDRD, require an 8
byte aligned base address. If we use malloc to allocate a structure
that starts with an 8 byte type that the compiler might use LDRD to
load and malloc returns a 4 byte (but not 8) aligned address, then it
will probably abort.
In fact, I fell foul of something similar in the dynamic linker
when porting GCC 8/10; I had to ensure that the library data segments
retained the original alignment that the compiler/linker gave them to
prevent LDRD from aborting.
I suspect that newer versions (than 4.7) of GCC will expect malloc'ed
memory to be 8 byte aligned and pad structures accordingly.
Unfortunately, we're a bit behind there, and I think it is something we
need to look at.

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

Re: [gccsdk] Various GNU tools - RISC OS system freeze (completelock-up)

Theo Markettos wrote on 24 November 2020 12:13

> Alan, I thought your recent PackMan changes were supposed to filter incompatible packages? I'm surprised these ones are making it through.

 

The package filter requires an environment setting in the control file (which is copied to the index). To stop everything disappearing while waiting for updates, Packman shows the packages with an icon beside them as a warning if the environment setting is not there. It filters for your machine once the environment has been set.

 

Regards,

Alan

 

Re: [gccsdk] malloc

> > Odd but when 8 mmap areas created malloc doesn't use heap, but produces
> > a crash.

Checked now.. there is no mmap call. But the problem might be something else.
If I hardcode a insane amount of stack , the mallocs uses heap , to a
much higher extent.

> No, n is the number of bytes you require. We do have memalign(),
> although I'm not sure if it's exported in the headers.
> I believe, off the top of my head that, malloc should return an address
> aligned to the host machine's pointer size, so 4 byte alignment for
> 32bits and 8 byte alignment for 64bits. Having said that, that doesn't
> account for double word loads that may require 8 byte alignment. It's
> quite possible that our malloc should be returning 8 byte aligned
> addresses to account for new processor requirements, I should probably
> look into that.
>

I did a unscientific test. Malloc 12 bytes , fill with 16 bytes, which
worked , so malloc is 8 byte aligned.
Maybe just lucky shot .. filling with 18 bytes , gives me bad mem at the end.

_______________________________________________
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] Various GNU tools - RISC OS system freeze (completelock-up)

Another package Fileutils (4.1-1) works on the whole as expected, but "ls"

is problematic, it causes a stack trace.

I can't even find that on the autobuilder!

I think some of these (perhaps the ones with capital letters in the names - eg DiffUtils rather than diffutils) are inherited from the RiscPkg archive which is 10-15 years old and originally built for ARMv5. Graham had his own build system that wasn't part of the autobuilder - I think popular packages have a parallel project in the autobuilder but not all of them do. 

It seems Graham's sources are still available: http://source.riscpkg.org/

but whether there's anything of worth there compared with freshly porting the current versions is another question.

Alan, I thought your recent PackMan changes were supposed to filter incompatible packages? I'm surprised these ones are making it through.

Theo

Re: [gccsdk] Various GNU tools - RISC OS system freeze (completelock-up)

alan buckley, on 23 Nov, wrote:

> It would be nice if we could rebuild the autobuilder versions of these so
> they work. I've not time to do it myself at the moment. But if someone
> else could check they build and work OK, I could then do a rebuild here
> and upload the new versions.


[snip]

Andrew McCarthy wrote:

> The following utilities cause RISC OS a major issue, complete system
> freeze on the closure of the task window:

> * Grep 2.18-1

grep failed to build :-

fpending.c: In function '__fpending':
fpending.c:59:3: error: #error "Please port gnulib fpending.c to your
platform!"
Makefile:1960: recipe for target 'fpending.o' failed

The file is present at :-

/home/djp/gccsdk/autobuilder/grep/grep-3.3/lib/fpending.c

> * FindUtils 4.4.2-3

The autobuilder tries to build a later version but the first patch fails.
Throttle back the the original version and that does build. In setvars :-

AB_URL=https://ftp.gnu.org/pub/gnu/findutils/findutils-4.4.2.tar.gz

> * Diffutils 3.3-1
> The packages were obtained from the package manager, and I'm running RISC
OS 5.29 (22-NOV-20) on a Raspberry Pi 4.

diffutils did build

Both builds are at :-

https://homepages.plus.net/pittdj/gccsdk/

Not much tested but they can report their versions on the RPi4, and diff
diff'd, find found.

> Another package Fileutils (4.1-1) works on the whole as expected, but "ls"
> is problematic, it causes a stack trace.

I can't even find that on the autobuilder!
--
David Pitt

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

Re: [gccsdk] Various GNU tools - RISC OS system freeze (complete lock-up)

It would be nice if we could rebuild the autobuilder versions of these so they work. I've not time to do it myself at the moment. But if someone else could check they build and work OK, I could then do a rebuild here and upload the new versions.

 

This is generally true of anything that's having problems like this from the autobuilder. I currently am not getting the time to fix the builds and test them, but if someone else does the "grunt" work. I can turn the handle here, rebuild them and upload the new versions.

 

Regards,

Alan

 

From: Chris Johns
Sent: 23 November 2020 12:29
To: gcc@gccsdk.riscos.info
Subject: Re: [gccsdk] Various GNU tools - RISC OS system freeze (complete lock-up)

 

You might need to use PatchSWP (from http://www.tellima.nl/riscos/ )  on them. I've had to do that in the past.

Cheers

Chris

On 23/11/2020 11:57, Andrew McCarthy wrote:

Hello,

 

The following utilities cause RISC OS a major issue, complete system freeze on the closure of the task window:

• Grep 2.18-1
• FindUtils 4.4.2-3
• Diffutils 3.3-1

The packages were obtained from the package manager, and I'm running RISC OS 5.29 (22-NOV-20) on a Raspberry Pi 4.

 

Another package Fileutils (4.1-1) works on the whole as expected, but "ls" is problematic, it causes a stack trace.

 

I trust this helps and happy to provide further information.

 

Andrew

_______________________________________________

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] malloc

On 23/11/2020 13:49, Michael Grunditz wrote:
>
>
>
> Den sön 22 nov. 2020 12:25Lee Noar <lee.noar@sky.com
> <mailto:lee.noar@sky.com>> skrev:
>
> On 21/11/2020 22:40, Michael Grunditz wrote:
> > Hi
> >
> > Is there any way to not get MMap areas from malloc()?
>
> Currently, no, malloc is compiled to use mmap for allocation requests of
> 256KB (I think) or more, but Unixlib only allows 8 mmap areas to be in
> use at one time. If there are already 8 mmap areas in use, then malloc
> will use the heap.
>
>
> Odd but when 8 mmap areas created malloc doesn't use heap, but produces
> a crash.

Are you sure that mmap isn't being called directly somewhere else after
all 8 areas have been used? Just checked the code for malloc, and
it does check what's returned by mmap and continues on with app space
allocation if it's NULL.
If you see a crash in malloc after 8 mmap areas are created, can you
reduce it to a small test case?

> Not a gccsdk question ( I think) but is malloc(n) supposed to return
> address aligned to n?

No, n is the number of bytes you require. We do have memalign(),
although I'm not sure if it's exported in the headers.
I believe, off the top of my head that, malloc should return an address
aligned to the host machine's pointer size, so 4 byte alignment for
32bits and 8 byte alignment for 64bits. Having said that, that doesn't
account for double word loads that may require 8 byte alignment. It's
quite possible that our malloc should be returning 8 byte aligned
addresses to account for new processor requirements, I should probably
look into that.

Thanks,
Lee.

(PS. Apparently, x86 64bit uses 16byte alignment for malloc).

_______________________________________________
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] malloc

Den sön 22 nov. 2020 12:25Lee Noar <lee.noar@sky.com> skrev:

On 21/11/2020 22:40, Michael Grunditz wrote:
> Hi
>
> Is there any way to not get MMap areas from malloc()?

Currently, no, malloc is compiled to use mmap for allocation requests of
256KB (I think) or more, but Unixlib only allows 8 mmap areas to be in
use at one time. If there are already 8 mmap areas in use, then malloc
will use the heap.

Odd but when 8 mmap areas created malloc doesn't use heap, but produces a crash.

Not a gccsdk question ( I think) but is malloc(n) supposed to return address aligned to n?

Re: [gccsdk] Various GNU tools - RISC OS system freeze (complete lock-up)

You might need to use PatchSWP (from http://www.tellima.nl/riscos/ )  on them. I've had to do that in the past.

Cheers

Chris

On 23/11/2020 11:57, Andrew McCarthy wrote:

Hello,

The following utilities cause RISC OS a major issue, complete system freeze on the closure of the task window:

• Grep 2.18-1
• FindUtils 4.4.2-3
• Diffutils 3.3-1

The packages were obtained from the package manager, and I'm running RISC OS 5.29 (22-NOV-20) on a Raspberry Pi 4.

Another package Fileutils (4.1-1) works on the whole as expected, but "ls" is problematic, it causes a stack trace.

I trust this helps and happy to provide further information.

Andrew

_______________________________________________  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] Various GNU tools - RISC OS system freeze (complete lock-up)

Hello,

The following utilities cause RISC OS a major issue, complete system freeze on the closure of the task window:

• Grep 2.18-1
• FindUtils 4.4.2-3
• Diffutils 3.3-1

The packages were obtained from the package manager, and I'm running RISC OS 5.29 (22-NOV-20) on a Raspberry Pi 4.

Another package Fileutils (4.1-1) works on the whole as expected, but "ls" is problematic, it causes a stack trace.

I trust this helps and happy to provide further information.

Andrew

Re: [gccsdk] malloc

On 21/11/2020 22:40, Michael Grunditz wrote:
> Hi
>
> Is there any way to not get MMap areas from malloc()?

Currently, no, malloc is compiled to use mmap for allocation requests of
256KB (I think) or more, but Unixlib only allows 8 mmap areas to be in
use at one time. If there are already 8 mmap areas in use, then malloc
will use the heap.
I believe that this behaviour was originally intended for 26bit systems
with limited app space, but now I wonder if we should change it so that
malloc always uses the heap (in application space). Any program
specifically needing mmap type allocation can use it directly or its own
implementation (as mmap will fail if there already 8 areas in use).

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] malloc

Hi

Is there any way to not get MMap areas from malloc()?

Michael

_______________________________________________
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: [Rpcemu] Problem with ROM decompression

On 21 Nov, Zbig wrote in message
<20201121010324.GA32695@Gigacyan.localnet>:

> That's why I raised my question: "uncompress is telling me this" - while
> description on web-page says something opposite. Thanks.

It doesn't, as it says "RISC OS *Select* ROM image files". RISC OS Select is
a specific series of RISC OS development, and its ROM images were always
intended for soft-loading and always compressed when distributed. Other ROM
images, especially those ripped from real ROMs, generally aren't.

Whether it could be made clearer for those not familiar with the complex
history of the OS (not to mention the confusing marketing names used on
occasion), without making it too much to read, is another question.

:-)

> Now for the other problems:
>
> managed to run version 0.8.15, since Slackware has Qt4, not Qt5. It seems
> to be working, but I'm unable to find a menu, which are mentioned in
> manual:
>
> "RPCEmu contains a menu to access most of the configurable aspects of the
> program."
>
> Where is this menu?

Along the top of the *host* window, usually; not part of RISC OS. See the
details here:

http://www.marutan.net/rpcemu/manual/#menu

You may need to uncapture the mouse from RISC OS to use it, however
(Ctrl-End).

> In the manual there are multiple remarks about a need to configure "this
> and that" from the command prompt. How can I get to command prompt? "Apps"
> don't contain any kind of shell

Press F12, and it will appear at the foot of the screen (the prompt is a
'*', which explains the other name of "star prompt" which you might see in
documents). Press Return on a new, empty, line to return to the desktop
again.

You can also use Ctrl-F12 to get a multitasking prompt which is good for a
lot of stuff. It does have some limitations, though, so plain F12 is always
useful to remember as the last resort.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

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

Re: [Rpcemu] Problem with ROM decompression

On Fri, Nov 20, 2020 at 12:19:21AM +0000, Steve Fryatt wrote:

> > #v+ Note: RISC OS Select ROM image files are not usable directly as they
> > are compressed. To use them please boot them and use the 'Extract from a
> > running RISC OS machine' instructions below. Alternative if you have a
> > linux machine, use this method to decompress them.
> >
> >
> > bash> tail -c +21 Select.rom > Select.Z bash> uncompress Select.Z #v-
> >
> > So I downloaded ROM 3.71, but it doesn't work as described on the page:
> >
> > $ tail -c +21 risocs-3.71.rom > Select.Z $ uncompress Select.Z Select.Z:
> > not in compressed format
> >
> > Not sure - did I do anything wrong, or that description on the page is
> > faulty?
>
> 3.71 isn't Select, so the ROM isn't compressed to start with.
>
> Select was the soft-loaded versions of RISC OS 4.mumble (4.2x or so onwards,
> IIRC), which were a file on disc that was softloaded into RAM on boot. That
> file was compressed, so you either need to load it into a machine and grab
> the image from RAM, or decompress the file contents yourself.
>
> That doesn't apply to the RISC OS 3 ROMs (or the 4.02 images sold by 3QD),
> because they're not compressed. Uncompress is just telling you this!

That's why I raised my question: "uncompress is telling me this" - while
description on web-page says something opposite. Thanks.

Now for the other problems:

managed to run version 0.8.15, since Slackware has Qt4, not Qt5. It seems to
be working, but I'm unable to find a menu, which are mentioned in manual:

"RPCEmu contains a menu to access most of the configurable aspects of the program."

Where is this menu? The only menu I was able to open is "Pinboard" menu,
which can be recalled with middle MB. How about that more important one?

In the manual there are multiple remarks about a need to configure "this and
that" from the command prompt. How can I get to command prompt?
"Apps" don't contain any kind of shell
--
regards,
Zbigniew

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

Re: [Rpcemu] Problem with ROM decompression

On 19 Nov, Zbig wrote in message
<20201119234354.GA32553@Gigacyan.localnet>:

> #v+ Note: RISC OS Select ROM image files are not usable directly as they
> are compressed. To use them please boot them and use the 'Extract from a
> running RISC OS machine' instructions below. Alternative if you have a
> linux machine, use this method to decompress them.
>
>
> bash> tail -c +21 Select.rom > Select.Z bash> uncompress Select.Z #v-
>
> So I downloaded ROM 3.71, but it doesn't work as described on the page:
>
> $ tail -c +21 risocs-3.71.rom > Select.Z $ uncompress Select.Z Select.Z:
> not in compressed format
>
> Not sure - did I do anything wrong, or that description on the page is
> faulty?

3.71 isn't Select, so the ROM isn't compressed to start with.

Select was the soft-loaded versions of RISC OS 4.mumble (4.2x or so onwards,
IIRC), which were a file on disc that was softloaded into RAM on boot. That
file was compressed, so you either need to load it into a machine and grab
the image from RAM, or decompress the file contents yourself.

That doesn't apply to the RISC OS 3 ROMs (or the 4.02 images sold by 3QD),
because they're not compressed. Uncompress is just telling you this!

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

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

[Rpcemu] Problem with ROM decompression

Guys,

on the page http://www.marutan.net/rpcemu/manual/romimage.html there is
remark:

#v+
Note: RISC OS Select ROM image files are not usable directly as they are
compressed. To use them please boot them and use the 'Extract from a running
RISC OS machine' instructions below. Alternative if you have a linux machine,
use this method to decompress them.


bash> tail -c +21 Select.rom > Select.Z
bash> uncompress Select.Z
#v-

So I downloaded ROM 3.71, but it doesn't work as described on the page:

$ tail -c +21 risocs-3.71.rom > Select.Z
$ uncompress Select.Z
Select.Z: not in compressed format

Not sure - did I do anything wrong, or that description on the page is faulty?
--
regards,
Zbigniew

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

Re: [gccsdk] Gnuplot/LibPNG12-0

Done! :)

Regards,
Jan-Jaap

Quoting Mark Beerling <beerling@online.de>:

Hallo All,

I recently got ROS 5.28 running on the RPi4 and found that GNUPLOT didn't run on the new hardware (Illegal Instruction). So I decided to recompile with the latest compiler. The compilation failed because dependency LibPNG12-0 didn't compile. After failing to get GNUPLOT to compile with LibPNG16-16  I took a look at LibPNG12-0.

In the file "setvars" from LibPNG12-0 I added at line 1:

AB_URL=https://downloads.sourceforge.net/project/libpng/libpng12/older-releases/1.2.54/libpng-1.2.54.tar.bz2

This was enough to compile the library and then GNUPLOT which now works on the RPi4 hardware.

Perhaps someone can update the "setvars" file for LibPNG12-0.

Regards

Mark Beerling


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

-------------------------------------------------
This free account was provided by VFEmail.net - report spam to abuse@vfemail.net
 
ONLY AT VFEmail! - Use our Metadata Mitigator™ to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
No Bandwidth Quotas!   15GB disk space!
Commercial and Bulk Mail Options!

[gccsdk] Gnuplot/LibPNG12-0

Hallo All,

I recently got ROS 5.28 running on the RPi4 and found that GNUPLOT
didn't run on the new hardware (Illegal Instruction). So I decided to
recompile with the latest compiler. The compilation failed because
dependency LibPNG12-0 didn't compile. After failing to get GNUPLOT to
compile with LibPNG16-16  I took a look at LibPNG12-0.

In the file "setvars" from LibPNG12-0 I added at line 1:

AB_URL=https://downloads.sourceforge.net/project/libpng/libpng12/older-releases/1.2.54/libpng-1.2.54.tar.bz2

This was enough to compile the library and then GNUPLOT which now works
on the RPi4 hardware.

Perhaps someone can update the "setvars" file for LibPNG12-0.

Regards

Mark Beerling

_______________________________________________
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: I would like to help

On 15/11/2020 11:31, Rob Kendrick wrote:
> On Sat, Nov 14, 2020 at 05:53:46PM +0000, Lorenzo Miguel Tareszkiewicz Rezende wrote:
>>> We have our own infrastructure that works well for us. It is, however,
>>> public: anyone can access it. We'd rather not outsource our downtime to
>>> another organisation.
>> It's just a suggestion, gitlab offers a self hosted platform. if you go to <https://gitlab.gnome.org/> you can see an example. As a person who search through your source code and documentation I find it really confusing.
>> Would it be asking a lot if you change the repository to a SelfHosted solution? if you do not have anyone to work on it i would be happy to offer my work.
>
> Yes. We are happy with what we have, we have no plans to move to
> something else. There's simply no advantage and lots of disadvantages,
> from our point of view. If anything, GitLab isn't usable from NetSurf.
> But there is also the resource usage, the time spent administering it,
> the security vulnerabilities that need to be kept on top of, and the
> fact it doesn't actually provide anything we want or need.

As Rob says, replacing the entirety of the existing infrastructure
(which works well, is open, and publicly accessible) is not something we
have any plans to do.

Perhaps it would be helpful if you could expand on what you are having
difficulty with when it comes to understanding our documentation and
source code layout. Replacing everything with gitlab/hub is not going to
fix those problems for you.


J.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: I would like to help

On Sat, Nov 14, 2020 at 05:53:46PM +0000, Lorenzo Miguel Tareszkiewicz Rezende wrote:
> > We have our own infrastructure that works well for us. It is, however,
> > public: anyone can access it. We'd rather not outsource our downtime to
> > another organisation.
> It's just a suggestion, gitlab offers a self hosted platform. if you go to <https://gitlab.gnome.org/> you can see an example. As a person who search through your source code and documentation I find it really confusing.
> Would it be asking a lot if you change the repository to a SelfHosted solution? if you do not have anyone to work on it i would be happy to offer my work.

Yes. We are happy with what we have, we have no plans to move to
something else. There's simply no advantage and lots of disadvantages,
from our point of view. If anything, GitLab isn't usable from NetSurf.
But there is also the resource usage, the time spent administering it,
the security vulnerabilities that need to be kept on top of, and the
fact it doesn't actually provide anything we want or need.

> I think that switching to this type of infrastructure can add a lot to things like:
> -> Divide the source code into smaller repositories to divide the work

We already do this and this is not a feature unique to GitLab/Hub.

> -> Create teams and separate everyone's work

We already do this and this is not a feature unique to GitLab/Hub.

> -> Use forks to increase the productivity of the team's work

We already do this and this is not a feature unique to GitLab/Hub.

> -> WebIDE

We don't want to do this.

> -> several free resources

What we're using already uses free resources.

> etc.
>
> More information about it here https://about.gitlab.com/blog/2018/04/20/gitlab-tiers/#gitlab-self-hosted
>
> As I don't know how you work, I don't know if it would be an advantage for you to make this exchange, but I am confident that it would be great for new contributors like me, who are easily lost by the documentation.

There are lots of projects that do not use GitLab or GitHub and are
wildly successful. For example, Linux. We like the way we currently
work.

> If you already host your sites and repositories, it would be a small change to switch to gitlab self-hosted.

It really isn't a simple change, I can say this as somebody who has set
up GitLab in the past and knows how our current infrastructure works.

> I can give you a demonstration of what it would look like if you give me permission.
>
> [https://about.gitlab.com/images/tweets/gitlab-tiers.png]<https://about.gitlab.com/blog/2018/04/20/gitlab-tiers/#gitlab-self-hosted>
> New names for GitLab self-hosted pricing tiers | GitLab<https://about.gitlab.com/blog/2018/04/20/gitlab-tiers/#gitlab-self-hosted>
> At GitLab, iteration is one of our core values. We've recently iterated on the names of our self-hosted pricing tiers, so Marcia and I got together and wrote this post to catch you up on the current options. We'll explain each tier, and share how to figure out which features your subscription gives you access to.
> about.gitlab.com
>
> [https://gitlab.gnome.org/assets/gitlab_logo-7ae504fe4f68fdebb3c2034e36621930cd36ea87924c11ff65dbcb8ed50dca58.png]<https://gitlab.gnome.org/>
> Groups · Explore<https://gitlab.gnome.org/>
> Welcome to GNOME's integrated development platform, powered by GitLab
> gitlab.gnome.org

B.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: I would like to help

On Sat, Nov 14, 2020 at 05:20:24AM +0000, Lorenzo Miguel Tareszkiewicz Rezende wrote:
> First, I would like to know somethings:
>
> * Why is netsurf not hosted on a source public code repo like github, gitlab (OpenSource) or Bitbucker?

We have our own infrastructure that works well for us. It is, however,
public: anyone can access it. We'd rather not outsource our downtime to
another organisation.

> * Does you guys want help on webassembly implementation and javascript?

Yes! We use Duktape as the interpreter, but the bindings to our DOM are
still incomplete.

> * Does Netsurf provide a api like CEF or WPE Webkit?

I think these are APIs for embedding a browser in another app? This has
been on our TODO list for a very long time but it's a bit more involved
that it first sounds due to having to turn the whole event processing
system up-side-down.

B.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: I would like to help

On Sat, Nov 14, 2020 at 05:20:24 +0000, Lorenzo Miguel Tareszkiewicz Rezende wrote:
> First, I would like to know somethings:
>
> * Why is netsurf not hosted on a source public code repo like github, gitlab (OpenSource) or Bitbucker?

Because back when we started, such services didn't offer the kind of access
control which we need in order to support third party frontend contributors.
Indeed most still don't unless you pay them money.

> * Does you guys want help on webassembly implementation and javascript?

Implementing the JS/DOM bindings, and supporting stuff like that would be very
welcome. It's a tough job because of keeping track of ownership/permissions
and in that we often have to improve our DOM implementation for each feature.

WebAssembly is probably a long long way off as yet.

> * Does Netsurf provide a api like CEF or WPE Webkit?

We do not, though it might be nice to produce a 'frontend' which is such.

D.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

I would like to help

First, I would like to know somethings:

• Why is netsurf not hosted on a source public code repo like github, gitlab (OpenSource) or Bitbucker?
• Does you guys want help on webassembly implementation and javascript?
• Does Netsurf provide a api like CEF or WPE Webkit?

Re: [gccsdk] Cross-compiling header issues

On 10/11/2020 14:49, Dominic Hamon wrote:
>
>
> On October 30, 2020, Dominic Hamon <dma@hey.com> wrote:
>
>
>
> On October 29, 2020, Lee Noar <lee.noar@sky.com> wrote:

> It does sound like regex.h should be including sys/types.h. If
> you make
> this change locally in your environment, does the project build?
> If so,
> then I will commit it.
>
>
> Would you like me to prepare a patch?

Sorry, I may have slightly forgot there, but sorted now :-) Thanks for
that.

> There are some other oddities I'm finding in the crosslib headers
> around things like definitions of strtoul not being in the std
> namespace, but i wonder if that's related to it not fully supporting
> C++11?

I've thought for a while that our headers have probably aged a bit
compared to what you might find with a more up to date compiler.
Having said that, they are really meant to compliment our GCC4.7.4 and
so probably match its capabilities better. The port of GCC 10 uses the
same headers because it was the easy option, but whether it would
benefit from a header update, I don't know.

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

Re: [gccsdk] Cross-compiling header issues

On October 30, 2020, Dominic Hamon <dma@hey.com> wrote:

On October 29, 2020, Lee Noar <lee.noar@sky.com> wrote:

On 26/10/2020 13:13, Dominic Hamon wrote:
> Hello
> 
> I'm embarking on my first attempt to cross-compile something for riscos. 
> I have the environment all set up and figured out how to make the 
> project, but i'm not sure what the appropriate fix is for an issue:
> 
> The project in question (https://github.com/google/benchmark) runs a 
> check at build time to see which regex engine is available (std::regix, 
> posix regex, or gnu posix regex). It does this by compiling some test 
> programs and seeing which succeeds. The issue is that none do for riscos 
> (yet).
> 
> The closest I get is with the posix regex version, which includes 
> `regex.h`. This fails with the error:
> 
> $ $CXX posix_regex.cpp
> In file included from posix_regex.cpp:1:0:
> /home/dominic/gccsdk/cross/lib/gcc/arm-unknown-riscos/4.7.4/../../../../arm-unknown-riscos/include/regex.h:56:2: 
> error: 'size_t' does not name a type
> 
> I believe I could fix this by including <sys/types.h> in the crosslib's 
> regex.h (linux does this 
> https://code.woboq.org/linux/include/regex.h.html#23) but is this 
> appropriate? It seems like the right fix to me as regex.h shouldn't be 
> using types that haven't been declared.
> 
> Would this change be acceptable?

It does sound like regex.h should be including sys/types.h. If you make
this change locally in your environment, does the project build? If so,
then I will commit it.

Would you like me to prepare a patch?

It does, yes.

There are some other oddities I'm finding in the crosslib headers around things like definitions of strtoul not being in the std namespace, but i wonder if that's related to it not fully supporting C++11?

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] paths.h

Hi

The attached patch adds the paths.h header. This header is common on Unix systems, and contains defines for common system paths. While the contents don't appear to be standardised, the patch adds a reduced set of defines from other platforms that are relevant to UnixLib.

Sources:

https://docs.oracle.com/cd/E36784_01/html/E36873/paths.h-3head.html

https://code.woboq.org/userspace/glibc/sysdeps/unix/sysv/linux/paths.h.html  

https://chromium.googlesource.com/native_client/nacl-newlib/+/master/newlib/libc/include/paths.h

Regards

Cameron

[gccsdk] Patch to add missing 64-bit atomic functions

Hi

Attached is a patch to provide a number of missing 64-bit atomic functions. These are needed for the c89atomic library (https://github.com/mackron/c89atomic), and have been tested with the test program provided with it.

Note that due to a bug in c89atomic, the code path for GCC 4.6 and earlier is being used with GCC 4.7, which fails due to the lack of __sync_lock_test_and_set_1, which appears to be more complicated to fix. This is worked around in https://github.com/mackron/c89atomic/pull/1 , however it is something to look out for in the future.

Regards

Cameron