Saturday, 29 February 2020

Atari build 5032: cache folder

I have just installed the Atari test build 5032 and it throws an error.

NetSurf failed to initialise


I switched the binary back to a previous build but that failed as
well. Investigation showed that the cache folder had gone.

I re-created it and the older version runs again but 5032 deletes it.


Peter
Posted by at No comments:

Friday, 28 February 2020

Re: [Rpcemu] EtherRPCEm network interface is disabled/greyed-out?

On 28 Feb 2020, at 19:40, David Pitt <pittdj@pittdj.co.uk> wrote:
>
> In message <CAHLLvsfJ1axCB-r+PbzBVLJxZxONCWBoYnaHWd77JN+Swsr8NQ@mail.g
> mail.com>
> Matt Sephton <matt.sephton@gmail.com> wrote:
>
>> Hi All,
>
>> Background:
>> * I'm trying the new release RPCEmu 0.9.2 with Networking on macOS
>> 10.14.6 Mojave.
>> * By following the Networking guide at:
>> http://www.marutan.net/rpcemu/manual/network.html
>> * I merged the !Boot and !System from the EtherRPCEm folder
>
> That is not required in 0.9.2 NAT networking.
>
>> * It says: "In 'Interfaces' make sure EtherRPCEm is selected and click
>> the Configure... button."
>
>> Problem:
>> * I see the EtherRPCEm network interface, BUT it is
>> disabled/greyed-out? (attached screenshot)
>
> On the Mac move EtherRPCEm,ffa from netroms to poduleroms.
>
> I will clarify this in the notes on my site.
> --
> David Pitt
> Titanium
>
> _______________________________________________
> RPCEmu mailing list
> RPCEmu@riscos.info
> http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu


(Sending to the list this time, not just to David.)

I've just noticed this in trying to work out a response to Matt. This is a bug/something I missed
when I created the Mac patches originally - it's not prefixing the path of the folder that you select
when you first run the emulator on to 'netroms/EtherRPCEm,ffa'.

I'll see if I can roll out a revised patch sometime this weekend to fix this.

Tim
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Posted by at No comments:

Re: [Rpcemu] EtherRPCEm network interface is disabled/greyed-out?

Hi Matt,

> Matt Sephton <matt.sephton@gmail.com> wrote:
>
> Problem:
> * I see the EtherRPCEm network interface, BUT it is
> disabled/greyed-out? (attached screenshot)

Make sure that networking is enabled in RPCEmu's main menu.

On Windows, this is in
Settings -> Networking...

HTH
hubersn

--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/

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

Posted by at No comments:

Re: [Rpcemu] EtherRPCEm network interface is disabled/greyed-out?

In message <CAHLLvsfJ1axCB-r+PbzBVLJxZxONCWBoYnaHWd77JN+Swsr8NQ@mail.g
mail.com>
Matt Sephton <matt.sephton@gmail.com> wrote:

> Hi All,

> Background:
> * I'm trying the new release RPCEmu 0.9.2 with Networking on macOS
> 10.14.6 Mojave.
> * By following the Networking guide at:
> http://www.marutan.net/rpcemu/manual/network.html
> * I merged the !Boot and !System from the EtherRPCEm folder

That is not required in 0.9.2 NAT networking.

> * It says: "In 'Interfaces' make sure EtherRPCEm is selected and click
> the Configure... button."

> Problem:
> * I see the EtherRPCEm network interface, BUT it is
> disabled/greyed-out? (attached screenshot)

On the Mac move EtherRPCEm,ffa from netroms to poduleroms.

I will clarify this in the notes on my site.
--
David Pitt
Titanium

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Posted by at No comments:

[Rpcemu] EtherRPCEm network interface is disabled/greyed-out?

Hi All,

Background:
* I'm trying the new release RPCEmu 0.9.2 with Networking on macOS
10.14.6 Mojave.
* By following the Networking guide at:
http://www.marutan.net/rpcemu/manual/network.html
* I merged the !Boot and !System from the EtherRPCEm folder
* It says: "In 'Interfaces' make sure EtherRPCEm is selected and click
the Configure... button."

Problem:
* I see the EtherRPCEm network interface, BUT it is
disabled/greyed-out? (attached screenshot)

Note: I've never before used Networking on RISC OS before, so please
assume I know nothing.

Any help appreciated!

Thanks,
matt
Posted by at No comments:

Wednesday, 26 February 2020

[Rpcemu] RPCEmu for macOS

Hi,

Here is a macOS build of RPCEmu 0.9.2 for appraisal. It is 64bit, runs
on Catalina and Mojave but not has not been tested on anything
earlier.

Networking works. ShareFS doesn't.

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

The download is only the app. The Linux Source code must be downloaded
from the RPCEmu site for the RPCEmu Data Directory that will contain
the ROM and disc image, just download it unpack it and don't build it.
On first run the app will ask for its location.

http://www.marutan.net/rpcemu/index.php#downloads

A ROM and disc image are also required, for OS5 these are on ROOL's
site.

https://www.riscosopen.org/content/downloads

Setup documents are on the RPCEmu site.

http://www.marutan.net/rpcemu/index.php

Please report any issues to this list.
--
David Pitt
Titanium

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Posted by at No comments:

Re: Port of Netsurf 3.9 to Plan 9

Thank you for your feedback, François. We have now put the port in Git (https://github.com/netsurf-plan9) and our changes should all be in the branch 'plan9'. We are next about to rebase our branches onto 'head' instead.

> Does it require C89 style (like, variables declared at beginning of block)?

The compilers in 9front has partial C99 support, including support for variable declaration anywhere in the block, and we'd consider adding needed features for better compliance, if needed.

If to merge the Plan 9 port into the upstream later, maybe a solution would be to have a 'mkfile' fragment that lists sources, one per line. That could be included by both gmake and mk:

-- mkfile --

OFILES=`{<files grep '\.c$' | sed 's/c$/$O/g'}

-- gmake --

DIR_SOURCES=$(shell cat files)

The main things we had to do to compile:

* libwapcaplet has macros that uses GNU extensions, that would require 'statement expression' support in the compiler. Maybe these functions could be made 'static inline' instead, as is used in other places.

* copied a number of auto generated files from a Linux build, generated by Perl, Python, Flex & Bison. We'll need to update 'ports' (our imported tools and libraries) if we want a fully native build, that's on us. Haven't tried the available ports of Perl & Python in Plan 9, but the .l and .y didn't work with the original Lex and Yacc.

* we need C99 macro varargs, (...) and __VA_ARGS__, instead of the non-standard GCC macro varargs (...args).

* our compiler currently doesn't support bitfields in static initialisers. We'd like to fix this eventually, but for now we just changed bitfields to shorts and integers.

* we don't have support for variable length arrays (VLA) on the stack (e.g. widths[][] and heights[][] in netsurf/desktop/frames.c)

Lastly, here is a video clip showing how downloading and running looks now: https://hvplay.hv.se/media/t/0_xbq4r8ed (7 min)

Jonas

On 8 January 2020 at 17:52:07 +02:00, François Revol <revol@free.fr> wrote:
Hi Jonas,

Le 06/01/2020 à 16:38, Jonas a écrit :
Dear Netsurf developers,

I have started a port of Netsurf 3.9 to the operating system Plan 9
(http://9front.org, https://9p.io/plan9). It uses the framebuffer
frontend for now, but I plan to continue with a native frontend, also
possibly with help from other developers.

Wow, nice to see NS ported to yet another platform :-)

quality of the Netsurf source. Another obstacle is that most larger GNU
development tools aren't available for Plan 9, no GCC for example. Plan
9 has its own C compiler (https://9p.io/sys/doc/compiler.html) that
sometimes does things in different ways, and typically doesn't support
GCC extensions and newer features added to the language lately.

Does it require C89 style (like, variables declared at beginning of block)?

For the Haiku ports I tried to maintain C89 code for a while for GCC
2.95, and if another platform requires it that'd be an incentive to fix
replicant support so we could put NS as a widget on the desktop…

In the absence of GCC/Autotools/GNUmake and friends, I have written my
own build system using Plan 9 'mk' (using 'mkfile'). I am aware that
this makes a possible upstream integration of the port harder.

Well we don't use autotools anyway, we have custom makefiles used as a
buildsystem for all libraries:

Maybe it's possible to isolate the incompatible parts from it and
reimplement them for other make engines?

I once managed to write a simple makefile engine for both GNU make and
MS Nmake that accepted unchanged makefiles with only declarative stuff:

Alternative routes would have been making GCC work on plan 9---some work
has been done on this (https://harvey-os.org), or to try to generate
plan 9 binaries from Linux using cross compilation. Both ways would be a
lot of compiler development work, and I am quite sure that the plan 9

Well for continuous integration we might want to do that anyway. But if
you went this far without changing code it can probably be fixed.

I started with the source tree of Netsurf 3.9, downloading all all
support libraries separately (that is why they have version numbers in
the directories). I have not deleted any files, only added files and
changed files. All files 'xxx.y' that I changed are backed up as
'orig_xxx.y' making it easier to 'diff' against the original. I got the
tip that it might be a good idea to make a clone of the official Git
repository and applying the diffs against it, in which case the 'orig_'
files won't be necessary, and a possible merger maybe easier to do in


Indeed, it's usually better to work on the HEAD. And with git you can
rebase your changes from time to time, with git resolving most of the
conflicts itself.

I believe you should already have a git client:

It might also be possible to build some simple client like this one
using libgit2:


François.

Posted by at No comments:
Subscribe to: Posts (Atom)