[Rpcemu] (no subject)

In article <583460704frinfo@avisoft.f9.co.uk>,
Martin <rinfo@avisoft.f9.co.uk> wrote:

> See http://www.marutan.net/rpcemu/manual/net-ro-nat.html

> Martin

Thanks for the reminder Martin, that's where I originally read it though
I'd forgotten the source. :-)

Is there any way at all of getting stuff out of a RPCEmu install?

Aside from *sending* the data out as an email to myself and picking it up
on another machine... Really!

Or...

In my VRPC-DL install I have a Mount on the Icon bar that connects to a
Directory (Moving stuff) inside the RPCEmu HostFS, so that's a sort of get
around the ShareFS problem... Really!

I really have to ask this question..

Aside from myself, is there anyone out there using this version of RPCEmu,
if there is, Why?

Dave

--

Dave Triffid

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

Re: [Rpcemu] (no subject)

On 18 Jan in article <583459cdf9dave@triffid.co.uk>,
Dave <dave@triffid.co.uk> wrote:
> G'day...
> I have RPCEmu 0.9.2 running on a Win 10 Pro PC.

> It is running RISC OS 5.27 and is Network enabled... I can browse
> okay with Netsurf etc.

> I have a vague recollection that it cannot connect with ShareFS,
> which is why it doesn't see other RISC OS on the LAN here.

> Am I correct in that vague notion?

> LanMan98 version 2.06 will also not connect to the LAN and thus
> other computers etc on the Local network, is there any particular
> reason why this should be so?

> Does anybody have a RPCEmu 0.9.2 running RISC OS 5.27 which does
> network connect using LM98?

> Thanks Dave

> FWIW. A VRPC-DL install RISC OS 6.20 on the same Win 10 PC does
> connect to the LAN okay.

See http://www.marutan.net/rpcemu/manual/net-ro-nat.html

Martin

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

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

Re: [Rpcemu] (no subject)

Think I replied directly rather than the list .. try again :)

I am pretty sure that you are correct in that notion. I believe the virtual RiscPC is behind a NAT and so can't be seen by other machines on the network. Hence connecting to things works, but incoming connections don't. ShareFS needs both.

Cheers

Chris 

Sent from my iPhone

On 18 Jan 2020, at 16:42, Dave <dave@triffid.co.uk> wrote:

G'day...
I have RPCEmu 0.9.2 running on a Win 10 Pro PC.

It is running RISC OS 5.27 and is Network enabled... I can browse okay
with Netsurf etc.

I have a vague recollection that it cannot connect with ShareFS, which is
why it doesn't see other RISC OS on the LAN here.

Am I correct in that vague notion?

LanMan98 version 2.06 will also not connect to the LAN and thus other
computers etc on the Local network, is there any particular reason why
this should be so?

Does anybody have a RPCEmu 0.9.2 running RISC OS 5.27 which does network
connect using LM98?

Thanks
Dave

FWIW. A VRPC-DL install RISC OS 6.20 on the same Win 10 PC does connect to
the LAN okay.

?

D.

--

Dave Triffid

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

[Rpcemu] (no subject)

G'day...
I have RPCEmu 0.9.2 running on a Win 10 Pro PC.

It is running RISC OS 5.27 and is Network enabled... I can browse okay
with Netsurf etc.

I have a vague recollection that it cannot connect with ShareFS, which is
why it doesn't see other RISC OS on the LAN here.

Am I correct in that vague notion?

LanMan98 version 2.06 will also not connect to the LAN and thus other
computers etc on the Local network, is there any particular reason why
this should be so?

Does anybody have a RPCEmu 0.9.2 running RISC OS 5.27 which does network
connect using LM98?

Thanks
Dave

FWIW. A VRPC-DL install RISC OS 6.20 on the same Win 10 PC does connect to
the LAN okay.

?

D.

--

Dave Triffid

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

Re: Port of Netsurf 3.9 to Plan 9

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:
http://git.netsurf-browser.org/buildsystem.git/

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:
http://miniserve.defence-force.org/svn/users/mmu_man/sdk-makefile-engine/make/

> 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:
https://hub.packtpub.com/introducing-git-fs-a-native-git-client-for-plan-9/

It might also be possible to build some simple client like this one
using libgit2:
https://github.com/sba1/simplegit


François.

Port of Netsurf 3.9 to Plan 9

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.

I have got to the point where it is possible to run the browser, load local pages from the file system, click on buttons and links. Several components requiring external libraries are still missing, like image support, fetching pages from the network etc.

Plan 9 could be considered a "Unix like" OS, especially as it originally was written by much the same authors as did write Unix. It is, however, in it self not Posix compliant at the system-call level. My port uses the Posix emulation layer APE (http://doc.cat-v.org/plan_9/4th_edition/papers/ape) in order to compile the Netsurf sources. APE does not provide complete Posix support, especially not features added in recent years, but given the size of the source code of Netsurf (which is big compared to most Plan 9 software) things have gone surprisingly well, which is indeed a testament to the 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.

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. 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 community would rather prefer something that will compile on the platform itself (as is with the current port beginning). Even though plan 9 is a bit of a minimalistic OS with modest hardware requirements, it runs on contemporary hardware (32-bit and 64-bit PC:s as well as Raspberry PI:s), so a middle layer between the source and the system API is not that of a big burden, especially as Netsurf is a lightweight browser, compared to the giants. In the Plan 9 world, simplicity and clarity is praised over premature optimisation, and it is my impression that the same holds for the Netsurf project to a large extent.

Anyhow, there is quite an excitement in the 9front crowd about the possibility to have modern, yet well written and non-bloated, web browser available on the platform. The existing browsers: Mothra (http://man.9front.org/1/mothra) and Abaco (https://9p.io/sources/contrib/fgb/abaco.pdf) are usable for many things, but does not support CSS and other modern features of the web. The browsers present do however support 'https' trough the use of plan 9's own web content fetcher: Webfs (http://man.9front.org/4/webfs). The plan 9 user base almost entirely consists of programmers who uses plan 9 as their preferred development platform, mostly as a personal and hobby system.

So far the port resides on my plan 9 file server at home, and I upload it here (http://webbkurs.ei.hv.se/~imjam/plan9/). Now when I managed to get it going, I am thinking of hosting it in a repository for easier collaboration. Of course, it would be really cool if the Plan 9 port in the future would be part of the official Netsurf project in some way, which also would make it easier to keep up with new releases.

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 the future. Some of auto-generated files (e.g. by perl scripts) are copied over from Linux build directory, to reduce the number of external tools used during the compilation (and Plan 9 does not have all of them).

I am interested in all kinds of feedback on the project, especially regarding what you think about the the not so standard build system, and if/how you would think merging into the official repository could be done in the future.

I've recorded a 14 minutes long video showing how I compile and run netsurf on 9front. Be aware that the GUI is very slow, which is most likely because my framebuffer driver copies the whole window bitmap for every change, and that the window output is sent to my Mac where I use Quicktime to record. Running the browser directly on a 9front computer is much snappier. Also, I expect remoteing the window to another computer to work much better with a native frontend.

Streaming version of the video: (https://hvplay.hv.se/media/t/0_6uyp5hck)

Just the .mov file (168MB) (https://webbkurs.ei.hv.se/~imjam/plan9/netsurf_on_plan9.mov)

All the best, thank you for making Netsurf, and happy new year!

Jonas Amoson

Mantis bug 2724

I can confirm that I no longer see the bug in build CI#4962, so I agree
that is is resolved.

Thank you!

David