Netsurf 3.9 for Plan 9 (work in progress)

Netsurf 3.9 for Plan 9 (work in progress)

[jamos]

Hello everyone,

As some of you know from the 9fans discord channels, I am trying to port 
the web browser Netsurf to Plan9 (9front).
My port is still very much work in progress, but I wanted to publish a 
first version for the ones that might find it interesting to compile and 
run. I started out with the prior work of Jens Staal and AAP that I 
found in different contrib directories, but my port is based on the 
latest stable version.

My port so far uses the 'framebuffer' driver, which means that the 
browser draws in a memory bitmap, than then is copied to a Plan 9 Image 
using loadimage(). It does not work to snarf or paste. If I get good 
success with the framebuffer frontend, I will try to write a native 
frontend for Plan 9 there is already ones for amiga, atari, beos, gtk, 
riscos and windows present.

There is a lot of functionality lacking currently, but it is possible to 
load local web pages, even if they don't display so nicely. There are 
many things to figure out. I have not given fonts any thoughts. It is 
little endian (as I commented out the code that checked for endianess). 
In reality not so much works, but it compiles and something shows... :-) 
There is a lot of README files though, and I am open to all kinds of 
input.

You can the source code here: 
https://webbkurs.ei.hv.se/~imjam/plan9/netsurf-3.9-2020-01-01.tgz

//Jonas Amoson

Ps. Oh, and the port relies heavily on APE-shit, and being a browser it 
also supports a lot of WEB-shit ;-)

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

[-- Attachment #1: Type: text/plain, Size: 1893 bytes --]

> Hello everyone,
> 
> As some of you know from the 9fans discord channels, I am trying to port 
> the web browser Netsurf to Plan9 (9front).
> My port is still very much work in progress, but I wanted to publish a 
> first version for the ones that might find it interesting to compile and 
> run. I started out with the prior work of Jens Staal and AAP that I 
> found in different contrib directories, but my port is based on the 
> latest stable version.
>
> My port so far uses the 'framebuffer' driver, which means that the 
> browser draws in a memory bitmap, than then is copied to a Plan 9 Image 
> using loadimage(). It does not work to snarf or paste. If I get good 
> success with the framebuffer frontend, I will try to write a native 
> frontend for Plan 9 there is already ones for amiga, atari, beos, gtk, 
> riscos and windows present.

Well, that's definitely progress -- and I'm definitely interested
in enough browser to get me past captive portals and such.

For me, though -- it builds, and it runs, but the image that 
Well, it builds, at least. But when I try to run it, I get a garbled
image (see attached).

The garbled image doesn't change with respect to window size.

 
> There is a lot of functionality lacking currently, but it is possible to 
> load local web pages, even if they don't display so nicely. There are 
> many things to figure out. I have not given fonts any thoughts. It is 
> little endian (as I commented out the code that checked for endianess). 
> In reality not so much works, but it compiles and something shows... :-) 
> There is a lot of README files though, and I am open to all kinds of 
> input.
> 
> You can the source code here: 
> https://webbkurs.ei.hv.se/~imjam/plan9/netsurf-3.9-2020-01-01.tgz
> 
> //Jonas Amoson
> 
> Ps. Oh, and the port relies heavily on APE-shit, and being a browser it 
> also supports a lot of WEB-shit ;-)

[-- Attachment #2: Type: image/png, Size: 8438 bytes --]

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[jamos]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

On 2020-01-02 00:57, ori@eigenstate.org wrote:

> I get a garbled image (see attached).

This is the most common display, alas.
It is possible to tweak a web page in
order for it to display slightly more
beutifully, that is the file 9html/full.html.

https://webbkurs.ei.hv.se/~imjam/plan9/full_html.png

This is how full.html looks for me.
As soon as the bars does not span the whole
screen, the picture comes out of sync. As
an interesting note, the test programs for
the framebuffer driver works as expected
(e.g. bitmap/plottest/etc.)

> The garbled image doesn't change with
> respect to window size.

Yes, the framebuffer size is set at
initialisation, it is set to 800x600.

Jonas

[-- Attachment #2: full_html.png --]
[-- Type: image/png, Size: 60737 bytes --]

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> On 2020-01-02 00:57, ori@eigenstate.org wrote:
> 
>> I get a garbled image (see attached).
> 
> This is the most common display, alas.
> It is possible to tweak a web page in
> order for it to display slightly more
> beutifully, that is the file 9html/full.html.
> 
> https://webbkurs.ei.hv.se/~imjam/plan9/full_html.png
> 
> This is how full.html looks for me.
> As soon as the bars does not span the whole
> screen, the picture comes out of sync. As
> an interesting note, the test programs for
> the framebuffer driver works as expected
> (e.g. bitmap/plottest/etc.)

I see the problem:

	loaded = loadimage(drawstate->srvimage, r, drawstate->localimage,
			drawstate->imagebytes);

The rectangle here is just the portion of the screen that's changed,
so, eg, a 30x30 icon or something. But drawstate->localimage is the
full view. So, you're uploading the first bunch of pixels of the image
instead of the region you want to draw.

Changing the code to create a rectangle representing the whole local
image and uploading it ungarbles it:

	all.min.x = 0;
	all.min.y = 0;
	all.max.x = 800;
	all.max.y = 600;
	loaded = loadimage(drawstate->srvimage, all, drawstate->localimage,
			drawstate->imagebytes);

For efficiency, we would really want a strided load image, but if there's
a native plan 9 gui, that becoems a moot point.

Other comments:

	box->x0, box->y0, box->x1 - box->x0, box->y1 - box->y0

box is just a 'Rectangle', so you can convert once and just pass the
resulting 'r' around:

	r.min.x = box->x0;
	r.min.y = box->y0;
	r.max.x = box->x1;
	r.max.y = box->y1;
	update_and_redraw_srvimage(drawstate, r);

>> The garbled image doesn't change with
>> respect to window size.
> 
> Yes, the framebuffer size is set at
> initialisation, it is set to 800x600.
> 
> Jonas

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

Forgive me for any duplicates. I mistakenly sent a copy of this mail with HTML.

This work is neat!

With Ori's changes I see the interface rendered.

I think the mouse handling is using absolute coordinates, because the address bar only works if I position the window in the upper left corner of my screen.

I can't get the program to actually render anything, even file:/// resources, but I can see them getting fetched.

I get CSSBase displayed at the bottom of the screen, seeming to correspond to the NSERROR_CSS_BASE error, but I can't figure out why that's happening. I'm guessing that's why nothing is rendered, but that may be a faulty assumption.

The fetcher interface looks pretty straightforward and I think it shouldn't be too difficult to write a webfs fetcher. I think I will try that in my spare time.

On January 2, 2020 10:45:47 AM CST, ori@eigenstate.org wrote:
>> On 2020-01-02 00:57, ori@eigenstate.org wrote:
>> 
>>> I get a garbled image (see attached).
>> 
>> This is the most common display, alas.
>> It is possible to tweak a web page in
>> order for it to display slightly more
>> beutifully, that is the file 9html/full.html.
>> 
>> https://webbkurs.ei.hv.se/~imjam/plan9/full_html.png
>> 
>> This is how full.html looks for me.
>> As soon as the bars does not span the whole
>> screen, the picture comes out of sync. As
>> an interesting note, the test programs for
>> the framebuffer driver works as expected
>> (e.g. bitmap/plottest/etc.)
>
>I see the problem:
>
>	loaded = loadimage(drawstate->srvimage, r, drawstate->localimage,
>			drawstate->imagebytes);
>
>The rectangle here is just the portion of the screen that's changed,
>so, eg, a 30x30 icon or something. But drawstate->localimage is the
>full view. So, you're uploading the first bunch of pixels of the image
>instead of the region you want to draw.
>
>Changing the code to create a rectangle representing the whole local
>image and uploading it ungarbles it:
>
>	all.min.x = 0;
>	all.min.y = 0;
>	all.max.x = 800;
>	all.max.y = 600;
>	loaded = loadimage(drawstate->srvimage, all, drawstate->localimage,
>			drawstate->imagebytes);
>
>For efficiency, we would really want a strided load image, but if
>there's
>a native plan 9 gui, that becoems a moot point.
>
>Other comments:
>
>	box->x0, box->y0, box->x1 - box->x0, box->y1 - box->y0
>
>box is just a 'Rectangle', so you can convert once and just pass the
>resulting 'r' around:
>
>	r.min.x = box->x0;
>	r.min.y = box->y0;
>	r.max.x = box->x1;
>	r.max.y = box->y1;
>	update_and_redraw_srvimage(drawstate, r);
>
>>> The garbled image doesn't change with
>>> respect to window size.
>> 
>> Yes, the framebuffer size is set at
>> initialisation, it is set to 800x600.
>> 
>> Jonas

-- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> Forgive me for any duplicates.  I mistakenly sent a copy of this
> mail with HTML.
> 
> This work is neat!
> 
> With Ori's changes I see the interface rendered.
> 
> I think the mouse handling is using absolute coordinates, because
> the address bar only works if I position the window in the upper left
> corner of my screen.
> 
> I can't get the program to actually render anything, even file:///
> resources, but I can see them getting fetched.
> 
> I get CSSBase displayed at the bottom of the screen, seeming to
> correspond to the NSERROR_CSS_BASE error, but I can't figure out why
> that's happening.  I'm guessing that's why nothing is rendered, but
> that may be a faulty assumption.

I also haven't seen them render, but I got it to show the ui before
I had to run out the door, so I didn't try very hard. 

> The fetcher interface looks pretty straightforward and I think it
> shouldn't be too difficult to write a webfs fetcher.  I think I will
> try that in my spare time.
> 

Cool.

If we're going to have multiple people hacking on this, it
probably makes sense to set up a git repository.

It'd be best to use upstream and fork a plan9 branch, so we can
merge their changes and start upstreaming our local diffs more
easily.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

A shared repo would be nice. 

My attempt at using webfs has hit a snag, which is that webfs does not expose the http response header in any way, as far as I can tell. 
I have it partially working in that it is getting and returning webpage data, but netsurf wants the full response header. 

I think webfs is not the right solution for this. It is not the general-purpose http service I thought it was. For this purpose, it has several issues. It provides no access to the raw header bytes. We could still use it as a hacky solution if we could reassemble the http header, but webfs mangles header names when creating the header files and leaves out cookies. 

However, since netsurf seems to do all the parsing of the response except separating header from body, and delivers the request URL and post data in pre-packaged form, I think it's probably easier to just use a raw /net/tcp connection.


On January 2, 2020 9:30:50 PM CST, ori@eigenstate.org wrote:
>> Forgive me for any duplicates.  I mistakenly sent a copy of this
>> mail with HTML.
>> 
>> This work is neat!
>> 
>> With Ori's changes I see the interface rendered.
>> 
>> I think the mouse handling is using absolute coordinates, because
>> the address bar only works if I position the window in the upper left
>> corner of my screen.
>> 
>> I can't get the program to actually render anything, even file:///
>> resources, but I can see them getting fetched.
>> 
>> I get CSSBase displayed at the bottom of the screen, seeming to
>> correspond to the NSERROR_CSS_BASE error, but I can't figure out why
>> that's happening.  I'm guessing that's why nothing is rendered, but
>> that may be a faulty assumption.
>
>I also haven't seen them render, but I got it to show the ui before
>I had to run out the door, so I didn't try very hard. 
>
>> The fetcher interface looks pretty straightforward and I think it
>> shouldn't be too difficult to write a webfs fetcher.  I think I will
>> try that in my spare time.
>> 
>
>Cool.
>
>If we're going to have multiple people hacking on this, it
>probably makes sense to set up a git repository.
>
>It'd be best to use upstream and fork a plan9 branch, so we can
>merge their changes and start upstreaming our local diffs more
>easily.

-- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> A shared repo would be nice. 
> 
> My attempt at using webfs has hit a snag, which is that webfs
> does not expose the http response header in any way, as far
> as I can tell. I have it partially working in that it is
> getting and returning webpage data, but netsurf wants the
> full response header. 
> 
> I think webfs is not the right solution for this. It is not
> the general-purpose http service I thought it was. For this
> purpose, it has several issues. It provides no access to the
> raw header bytes. We could still use it as a hacky solution
> if we could reassemble the http header, but webfs mangles
> header names when creating the header files and leaves out
> cookies. 

If we want it to handle cookies uniformly, integrate with factotum,
use devtls, and generally fit into 9front, we definitely want
to use webfs. It should be sufficiently general purpose for
our needs.

Is there a reason that tearing out the header parsing code in
netsurf and pointing it to webfs and webcookies wouldn't work?

I'd resist it, but if it's absolutely needed, we can also probably
add a 'rawheader' file to webfs.

> However, since netsurf seems to do all the parsing of the
> response except separating header from body, and delivers
> the request URL and post data in pre-packaged form, I think
> it's probably easier to just use a raw /net/tcp connection.
> 

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

On January 3, 2020 3:01:30 PM CST, ori@eigenstate.org wrote:
>> A shared repo would be nice. 
>> 
>> My attempt at using webfs has hit a snag, which is that webfs
>> does not expose the http response header in any way, as far
>> as I can tell. I have it partially working in that it is
>> getting and returning webpage data, but netsurf wants the
>> full response header. 
>> 
>> I think webfs is not the right solution for this. It is not
>> the general-purpose http service I thought it was. For this
>> purpose, it has several issues. It provides no access to the
>> raw header bytes. We could still use it as a hacky solution
>> if we could reassemble the http header, but webfs mangles
>> header names when creating the header files and leaves out
>> cookies. 
>
>If we want it to handle cookies uniformly, integrate with factotum,
>use devtls, and generally fit into 9front, we definitely want
>to use webfs. It should be sufficiently general purpose for
>our needs.
>
>Is there a reason that tearing out the header parsing code in
>netsurf and pointing it to webfs and webcookies wouldn't work?

I would imagine that should work. However, I haven't dug into the netsurf internals. The fetcher interface seems to be provided for adding ways to pull web pages. Circumventing that is probably necessary for good integration into 9front, but I'm not sure how much work that is. I'll try and see how fetcher is used and see if it can be replaced. I'm not sure what upstream would think of it. Upstream accepting our code is obviously not totally necessary, but it would be nice.

>I'd resist it, but if it's absolutely needed, we can also probably
>add a 'rawheader' file to webfs.

I considered this, but it feels like going the wrong direction. I don't think I want to suggest mucking up our clean interfaces because a port doesn't play nicely with them.

>> However, since netsurf seems to do all the parsing of the
>> response except separating header from body, and delivers
>> the request URL and post data in pre-packaged form, I think
>> it's probably easier to just use a raw /net/tcp connection.
>> 

I think for now I'm going to try and use the fetcher interface with a tcp socket, just to get something working. That might allow us to use http at least and work on other parts of the browser while we look at replacing the fetcher with webfs.
-- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[hiro]

if you don't want to integrate it properly with 9front, why not stop
porting it to 9front.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Steve Simon]

hi,

the response header fields are exposed as psudo-files in webfs, i cannot remember the path just now, but its the per connection directory.

cookies are handled by  webfs when and a file server (cookiejar?) which should “just work”, it should hopefully be just a matter of removing cookie support from netsurf.

it would be exciting to have netsurf running on plan9, especially if the changes where merged back into the mainline.

-Steve




> On 3 Jan 2020, at 8:15 pm, Kyle Nusbaum <knusbaum@sdf.org> wrote:
> 
> A shared repo would be nice. 
> 
> My attempt at using webfs has hit a snag, which is that webfs does not expose the http response header in any way, as far as I can tell. 
> I have it partially working in that it is getting and returning webpage data, but netsurf wants the full response header. 
> 
> I think webfs is not the right solution for this. It is not the general-purpose http service I thought it was. For this purpose, it has several issues. It provides no access to the raw header bytes. We could still use it as a hacky solution if we could reassemble the http header, but webfs mangles header names when creating the header files and leaves out cookies. 
> 
> However, since netsurf seems to do all the parsing of the response except separating header from body, and delivers the request URL and post data in pre-packaged form, I think it's probably easier to just use a raw /net/tcp connection.
> 
> 
> On January 2, 2020 9:30:50 PM CST, ori@eigenstate.org wrote:
>>> Forgive me for any duplicates.  I mistakenly sent a copy of this
>>> mail with HTML.
>>> 
>>> This work is neat!
>>> 
>>> With Ori's changes I see the interface rendered.
>>> 
>>> I think the mouse handling is using absolute coordinates, because
>>> the address bar only works if I position the window in the upper left
>>> corner of my screen.
>>> 
>>> I can't get the program to actually render anything, even file:///
>>> resources, but I can see them getting fetched.
>>> 
>>> I get CSSBase displayed at the bottom of the screen, seeming to
>>> correspond to the NSERROR_CSS_BASE error, but I can't figure out why
>>> that's happening.  I'm guessing that's why nothing is rendered, but
>>> that may be a faulty assumption.
>> 
>> I also haven't seen them render, but I got it to show the ui before
>> I had to run out the door, so I didn't try very hard. 
>> 
>>> The fetcher interface looks pretty straightforward and I think it
>>> shouldn't be too difficult to write a webfs fetcher.  I think I will
>>> try that in my spare time.
>>> 
>> 
>> Cool.
>> 
>> If we're going to have multiple people hacking on this, it
>> probably makes sense to set up a git repository.
>> 
>> It'd be best to use upstream and fork a plan9 branch, so we can
>> merge their changes and start upstreaming our local diffs more
>> easily.
> 
> -- Kyle

No rendering of pages (Re: [9front] Netsurf 3.9 for Plan 9 (work in progress))

[jamos]

On 2020-01-03 05:12, Kyle Nusbaum wrote:

> 
> I can't get the program to actually render anything,
> even file:/// resources, but I can see them getting fetched.
> 
> I get CSSBase displayed at the bottom of the screen, seeming
> to correspond to the NSERROR_CSS_BASE error, but I can't figure
> out why that's happening. I'm guessing that's why nothing is
> rendered, but that may be a faulty assumption.

I moved to a completely different 9front installation, and found
out that I hardcode the  path to the resources: NETSURF_FB_RESPATH
in the mkfile for the browser. If you have another installation
path than me (likely) you (right now) have to change that path to
correspond to where the 'res' directory is. At least things started
to render on my other installation when I changed this!

/Jonas

Re: No rendering of pages (Re: [9front] Netsurf 3.9 for Plan 9 (work in progress))

[ori]

> On 2020-01-03 05:12, Kyle Nusbaum wrote:
> 
> I moved to a completely different 9front installation, and found
> out that I hardcode the  path to the resources: NETSURF_FB_RESPATH
> in the mkfile for the browser. If you have another installation
> path than me (likely) you (right now) have to change that path to
> correspond to where the 'res' directory is. At least things started
> to render on my other installation when I changed this!
> 
> /Jonas

Makes sense. I think the right place place to put it is in /sys/lib/netsurf.
For development, you can just 'bind $src/netsurf/frontends/framebuffer/res'
over that directory.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[jamos]

Thank you all for all your feedback, and especially Ori for finding the 
drawing bug! I wonder whether the coordinates that are sent to the 
plan9_update() function is to be able only to redraw the "damaged" or 
updated area of browser window, which might result in better drawing 
performance. I assume that is what you mean with "strided" image? I 
agree that optimisation of the framebuffer driver might not be 
worth-while, if the goal is to implement a native frontend in the end.

Also thanks for noticing the race in the mk file. I don't feel I have a 
good enough understanding on them, and if someone with more mkfile 
experience would like to overhaul them, that would be welcome. The tests 
for the libnsfb was where I started the project and at that time I 
didn't cross-compile, so the clean target is also too stupid and easily 
leaves debris (thus the leftover arm binaries).

Kyle, I will look into the mouse coordinate issue. It's very possible 
that the other framebuffer surfaces that I looked at uses coordinates 
relative to the window. I think that the rio way of handling coordinates 
is a bit unique. I didn't focus much on user input so far.

For fetching web pages from the network there might be, as many of you 
have started to discuss, many different possibilities. One solution 
would be to make 'curl' work, as it is the method used by mainline 
Netsurf, and as it already ported to 9front, at least it is in 
/sys/ports. But it has a lot of dependencies, and I think that the 
option to use 'webfs' definitely is more elegant, if it can be made. My 
port does right now only use standard APE, and not libgnu in ports, 
which I think is good thing (the header files of libgnu are really a 
scary GNU spaghetti).

I fully agree that hosting the project on a git/hg repository would be 
great, and make it easier to work on togehter. Merging with the official 
Netsurf tree would also be a very nice thing, as keeping up-to-date 
would be much easier. But in the current port, I don't at all use their 
build system, which might be unpopular with the maintainers, or hard to 
keep in sync generally. I am subscribed to the netsurf mailing lists, 
and will write them about the existence of the new Plan 9 port. It is 
extra nice now that it not only runs, but also renders webpages!

I'll shortly update the tar-file with the driver-fix and the better 
mkfile for framebuffer test. For repository, maybe I should make myself 
a github or bitbucket account and put it there to start with?

Thank you all, for debugging, comments and discussion!

Jonas Amoson

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> I fully agree that hosting the project on a git/hg repository would be 
> great, and make it easier to work on togehter. Merging with the official 
> Netsurf tree would also be a very nice thing, as keeping up-to-date 
> would be much easier. But in the current port, I don't at all use their 
> build system, which might be unpopular with the maintainers, or hard to 
> keep in sync generally. I am subscribed to the netsurf mailing lists, 
> and will write them about the existence of the new Plan 9 port. It is 
> extra nice now that it not only runs, but also renders webpages!

What I'd do is clone the upstream netsurf repos onto any git host
that you feel like (except gitlab -- git9 triggers a bug in their
backend, and I haven't had time to find a workaround), and then
branch off a 'plan9' branch that we can work on, and commit the
current state.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[jamos]

On 2020-01-04 19:14, ori@eigenstate.org wrote:

> 
> What I'd do is clone the upstream netsurf repos onto any git host
> that you feel like (except gitlab -- git9 triggers a bug in their
> backend, and I haven't had time to find a workaround), and then
> branch off a 'plan9' branch that we can work on, and commit the
> current state.

That sounds like a cool way, but I am kind of a git rookie. I assume 
that the reason to clone the main repository is that it will be easier 
to merge them together eventually? Or even to keep the plan 9 branch up 
to date with new versions of the mainline? I have based my port on the 
stable release 3.9 while the core team is happily hacking away on what 
even will be the next release (usually one version per year).

The official site has many git repositories 
(https://source.netsurf-browser.org) - from which I actually downloaded 
every support library separately. Each repository has a tag for each 
release. There are also a number of branches (especially for the main 
netsurf repository: 
https://source.netsurf-browser.org/netsurf.git/refs/heads) that looks 
like experiments.

I might be inclined to keep it simple to begin with, but if there are 
very compelling reasons for a more elaborate way, I might be open to 
that, in order to avoid lots of work later on.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

I gave up trying talking directly on /net/tcp. It is a pointless exercise and would need to be replaced right away anyway. 

I have something partially working with webfs. I replaced the llcache implementation with one that uses webfs. We still need the old version to handle objects like "resources:quirks.css" etc.

I'll keep working on it when I get time.
I'm attaching a screenshot of the thing partially rendering the netsurf website.


On January 4, 2020 3:33:48 PM CST, jamos@oboj.net wrote:
>On 2020-01-04 19:14, ori@eigenstate.org wrote:
>
>> 
>> What I'd do is clone the upstream netsurf repos onto any git host
>> that you feel like (except gitlab -- git9 triggers a bug in their
>> backend, and I haven't had time to find a workaround), and then
>> branch off a 'plan9' branch that we can work on, and commit the
>> current state.
>
>That sounds like a cool way, but I am kind of a git rookie. I assume 
>that the reason to clone the main repository is that it will be easier 
>to merge them together eventually? Or even to keep the plan 9 branch up
>
>to date with new versions of the mainline? I have based my port on the 
>stable release 3.9 while the core team is happily hacking away on what 
>even will be the next release (usually one version per year).
>
>The official site has many git repositories 
>(https://source.netsurf-browser.org) - from which I actually downloaded
>
>every support library separately. Each repository has a tag for each 
>release. There are also a number of branches (especially for the main 
>netsurf repository: 
>https://source.netsurf-browser.org/netsurf.git/refs/heads) that looks 
>like experiments.
>
>I might be inclined to keep it simple to begin with, but if there are 
>very compelling reasons for a more elaborate way, I might be open to 
>that, in order to avoid lots of work later on.

-- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]

Attachment didn't take. My mistake.



On January 7, 2020 10:23:40 PM CST, Kyle Nusbaum <knusbaum@sdf.org> wrote:
>I gave up trying talking directly on /net/tcp. It is a pointless
>exercise and would need to be replaced right away anyway. 
>
>I have something partially working with webfs. I replaced the llcache
>implementation with one that uses webfs. We still need the old version
>to handle objects like "resources:quirks.css" etc.
>
>I'll keep working on it when I get time.
>I'm attaching a screenshot of the thing partially rendering the netsurf
>website.
>
>
>On January 4, 2020 3:33:48 PM CST, jamos@oboj.net wrote:
>>On 2020-01-04 19:14, ori@eigenstate.org wrote:
>>
>>> 
>>> What I'd do is clone the upstream netsurf repos onto any git host
>>> that you feel like (except gitlab -- git9 triggers a bug in their
>>> backend, and I haven't had time to find a workaround), and then
>>> branch off a 'plan9' branch that we can work on, and commit the
>>> current state.
>>
>>That sounds like a cool way, but I am kind of a git rookie. I assume 
>>that the reason to clone the main repository is that it will be easier
>
>>to merge them together eventually? Or even to keep the plan 9 branch
>up
>>
>>to date with new versions of the mainline? I have based my port on the
>
>>stable release 3.9 while the core team is happily hacking away on what
>
>>even will be the next release (usually one version per year).
>>
>>The official site has many git repositories 
>>(https://source.netsurf-browser.org) - from which I actually
>downloaded
>>
>>every support library separately. Each repository has a tag for each 
>>release. There are also a number of branches (especially for the main 
>>netsurf repository: 
>>https://source.netsurf-browser.org/netsurf.git/refs/heads) that looks 
>>like experiments.
>>
>>I might be inclined to keep it simple to begin with, but if there are 
>>very compelling reasons for a more elaborate way, I might be open to 
>>that, in order to avoid lots of work later on.
>
>-- Kyle

-- Kyle

[-- Attachment #2: 85.png --]
[-- Type: image/png, Size: 17754 bytes --]

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Eli Cohen]

bump. did anyone ever put repositories of this up yet? don't let them
shout you down

On Tue, Jan 7, 2020 at 8:26 PM Kyle Nusbaum <knusbaum@sdf.org> wrote:
>
> Attachment didn't take. My mistake.
>
>
>
> On January 7, 2020 10:23:40 PM CST, Kyle Nusbaum <knusbaum@sdf.org> wrote:
> >I gave up trying talking directly on /net/tcp. It is a pointless
> >exercise and would need to be replaced right away anyway.
> >
> >I have something partially working with webfs. I replaced the llcache
> >implementation with one that uses webfs. We still need the old version
> >to handle objects like "resources:quirks.css" etc.
> >
> >I'll keep working on it when I get time.
> >I'm attaching a screenshot of the thing partially rendering the netsurf
> >website.
> >
> >
> >On January 4, 2020 3:33:48 PM CST, jamos@oboj.net wrote:
> >>On 2020-01-04 19:14, ori@eigenstate.org wrote:
> >>
> >>>
> >>> What I'd do is clone the upstream netsurf repos onto any git host
> >>> that you feel like (except gitlab -- git9 triggers a bug in their
> >>> backend, and I haven't had time to find a workaround), and then
> >>> branch off a 'plan9' branch that we can work on, and commit the
> >>> current state.
> >>
> >>That sounds like a cool way, but I am kind of a git rookie. I assume
> >>that the reason to clone the main repository is that it will be easier
> >
> >>to merge them together eventually? Or even to keep the plan 9 branch
> >up
> >>
> >>to date with new versions of the mainline? I have based my port on the
> >
> >>stable release 3.9 while the core team is happily hacking away on what
> >
> >>even will be the next release (usually one version per year).
> >>
> >>The official site has many git repositories
> >>(https://source.netsurf-browser.org) - from which I actually
> >downloaded
> >>
> >>every support library separately. Each repository has a tag for each
> >>release. There are also a number of branches (especially for the main
> >>netsurf repository:
> >>https://source.netsurf-browser.org/netsurf.git/refs/heads) that looks
> >>like experiments.
> >>
> >>I might be inclined to keep it simple to begin with, but if there are
> >>very compelling reasons for a more elaborate way, I might be open to
> >>that, in order to avoid lots of work later on.
> >
> >-- Kyle
>
> -- Kyle



-- 
http://echoline.org

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[hiro]

they are busy and have to close some of the tabs first.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

I am away from home for the next week and didn't bring the code with me.

I have been hacking on it in my spare time and made some progress. It's not pretty yet, but it's actually minimally useful (to me at least). I will try to get some repos set up on GitHub when I get back if someone wants to look at what I've done.

On January 24, 2020 3:09:57 AM EST, Eli Cohen <echoline@gmail.com> wrote:
>bump. did anyone ever put repositories of this up yet? don't let them
>shout you down
>
>On Tue, Jan 7, 2020 at 8:26 PM Kyle Nusbaum <knusbaum@sdf.org> wrote:
>>
>> Attachment didn't take. My mistake.
>>
>>
>>
>> On January 7, 2020 10:23:40 PM CST, Kyle Nusbaum <knusbaum@sdf.org>
>wrote:
>> >I gave up trying talking directly on /net/tcp. It is a pointless
>> >exercise and would need to be replaced right away anyway.
>> >
>> >I have something partially working with webfs. I replaced the
>llcache
>> >implementation with one that uses webfs. We still need the old
>version
>> >to handle objects like "resources:quirks.css" etc.
>> >
>> >I'll keep working on it when I get time.
>> >I'm attaching a screenshot of the thing partially rendering the
>netsurf
>> >website.
>> >
>> >
>> >On January 4, 2020 3:33:48 PM CST, jamos@oboj.net wrote:
>> >>On 2020-01-04 19:14, ori@eigenstate.org wrote:
>> >>
>> >>>
>> >>> What I'd do is clone the upstream netsurf repos onto any git host
>> >>> that you feel like (except gitlab -- git9 triggers a bug in their
>> >>> backend, and I haven't had time to find a workaround), and then
>> >>> branch off a 'plan9' branch that we can work on, and commit the
>> >>> current state.
>> >>
>> >>That sounds like a cool way, but I am kind of a git rookie. I
>assume
>> >>that the reason to clone the main repository is that it will be
>easier
>> >
>> >>to merge them together eventually? Or even to keep the plan 9
>branch
>> >up
>> >>
>> >>to date with new versions of the mainline? I have based my port on
>the
>> >
>> >>stable release 3.9 while the core team is happily hacking away on
>what
>> >
>> >>even will be the next release (usually one version per year).
>> >>
>> >>The official site has many git repositories
>> >>(https://source.netsurf-browser.org) - from which I actually
>> >downloaded
>> >>
>> >>every support library separately. Each repository has a tag for
>each
>> >>release. There are also a number of branches (especially for the
>main
>> >>netsurf repository:
>> >>https://source.netsurf-browser.org/netsurf.git/refs/heads) that
>looks
>> >>like experiments.
>> >>
>> >>I might be inclined to keep it simple to begin with, but if there
>are
>> >>very compelling reasons for a more elaborate way, I might be open
>to
>> >>that, in order to avoid lots of work later on.
>> >
>> >-- Kyle
>>
>> -- Kyle

-- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[jamos]

I just committed the first changes to the git repo that Ori kindly set 
up for the Plan 9 port of Netsurf. I have checked in the files for the 
smallest and simplest library (libwapcaplet) as a test, using git9 by 
Ori. I will continue with the other libraries, and the browser itself. 
Each library is in it's own repo on Github. I'll write again when I 
managed to commit the rest.

For the curious, you can help me to see if I did everything correctly, 
by checking out and compiling the 'libwapcaplet' library. This is my 
first real Git experience :-)

git/clone git://github.com/netsurf-plan9/libwapcaplet.git

Kyle> I have something partially working with webfs

This is super cool! If you feel for it, it would be interesting to read 
about your efforts and the
problems you encountered.

/Jonas


On 2020-01-24 20:16, Kyle Nusbaum wrote:

> I am away from home for the next week and didn't bring the code with 
> me.
> 
> I have been hacking on it in my spare time and made some progress. It's 
> not pretty yet, but it's actually minimally useful (to me at least). I 
> will try to get some repos set up on GitHub when I get back if someone 
> wants to look at what I've done.
> 
> On January 24, 2020 3:09:57 AM EST, Eli Cohen <echoline@gmail.com> 
> wrote: bump. did anyone ever put repositories of this up yet? don't let 
> them
> shout you down
> 
> On Tue, Jan 7, 2020 at 8:26 PM Kyle Nusbaum <knusbaum@sdf.org> wrote:
> Attachment didn't take. My mistake.
> 
> On January 7, 2020 10:23:40 PM CST, Kyle Nusbaum <knusbaum@sdf.org> 
> wrote: I gave up trying talking directly on /net/tcp. It is a pointless
> exercise and would need to be replaced right away anyway.
> 
> I have something partially working with webfs. I replaced the
  llcache

>> implementation with one that uses webfs. We still need the old
  version

>> to handle objects like "resources:quirks.css" etc.
>> 
>> I'll keep working on it when I get time.
>> I'm attaching a screenshot of the thing partially rendering the
  netsurf

> website.
> 
> On January 4, 2020 3:33:48 PM CST, jamos@oboj.net wrote: On 2020-01-04 
> 19:14, ori@eigenstate.org wrote:
> 
> What I'd do is clone the upstream netsurf repos onto any git host
> that you feel like (except gitlab -- git9 triggers a bug in their
> backend, and I haven't had time to find a workaround), and then
> branch off a 'plan9' branch that we can work on, and commit the
> current state.
> That sounds like a cool way, but I am kind of a git rookie. I
  assume

> that the reason to clone the main repository is that it will be
  easier

> to merge them together eventually? Or even to keep the plan 9
  branch

> up
> to date with new versions of the mainline? I have based my port on
  the

> stable release 3.9 while the core team is happily hacking away on
  what

> even will be the next release (usually one version per year).
> 
> The official site has many git repositories
> (https://source.netsurf-browser.org) - from which I actually downloaded
> every support library separately. Each repository has a tag for
  each

> release. There are also a number of branches (especially for the
  main

> netsurf repository:
> https://source.netsurf-browser.org/netsurf.git/refs/heads) that
  looks

> like experiments.
> 
> I might be inclined to keep it simple to begin with, but if there
  are

> very compelling reasons for a more elaborate way, I might be open
  to

> that, in order to avoid lots of work later on.
> -- Kyle

-- Kyle
-- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Eli Cohen]

I'm having all kinds of problems checking this out.

nsport/fetch clone fails with:
ssh: auth: no key matches proto=rsa service=ssh role=client

I have verified there is a key in factotum

On Fri, Jan 24, 2020 at 10:41 AM <jamos@oboj.net> wrote:
>
> I just committed the first changes to the git repo that Ori kindly set
> up for the Plan 9 port of Netsurf. I have checked in the files for the
> smallest and simplest library (libwapcaplet) as a test, using git9 by
> Ori. I will continue with the other libraries, and the browser itself.
> Each library is in it's own repo on Github. I'll write again when I
> managed to commit the rest.
>
> For the curious, you can help me to see if I did everything correctly,
> by checking out and compiling the 'libwapcaplet' library. This is my
> first real Git experience :-)
>
> git/clone git://github.com/netsurf-plan9/libwapcaplet.git
>
> Kyle> I have something partially working with webfs
>
> This is super cool! If you feel for it, it would be interesting to read
> about your efforts and the
> problems you encountered.
>
> /Jonas
>
>
> On 2020-01-24 20:16, Kyle Nusbaum wrote:
>
> > I am away from home for the next week and didn't bring the code with
> > me.
> >
> > I have been hacking on it in my spare time and made some progress. It's
> > not pretty yet, but it's actually minimally useful (to me at least). I
> > will try to get some repos set up on GitHub when I get back if someone
> > wants to look at what I've done.
> >
> > On January 24, 2020 3:09:57 AM EST, Eli Cohen <echoline@gmail.com>
> > wrote: bump. did anyone ever put repositories of this up yet? don't let
> > them
> > shout you down
> >
> > On Tue, Jan 7, 2020 at 8:26 PM Kyle Nusbaum <knusbaum@sdf.org> wrote:
> > Attachment didn't take. My mistake.
> >
> > On January 7, 2020 10:23:40 PM CST, Kyle Nusbaum <knusbaum@sdf.org>
> > wrote: I gave up trying talking directly on /net/tcp. It is a pointless
> > exercise and would need to be replaced right away anyway.
> >
> > I have something partially working with webfs. I replaced the
>   llcache
>
> >> implementation with one that uses webfs. We still need the old
>   version
>
> >> to handle objects like "resources:quirks.css" etc.
> >>
> >> I'll keep working on it when I get time.
> >> I'm attaching a screenshot of the thing partially rendering the
>   netsurf
>
> > website.
> >
> > On January 4, 2020 3:33:48 PM CST, jamos@oboj.net wrote: On 2020-01-04
> > 19:14, ori@eigenstate.org wrote:
> >
> > What I'd do is clone the upstream netsurf repos onto any git host
> > that you feel like (except gitlab -- git9 triggers a bug in their
> > backend, and I haven't had time to find a workaround), and then
> > branch off a 'plan9' branch that we can work on, and commit the
> > current state.
> > That sounds like a cool way, but I am kind of a git rookie. I
>   assume
>
> > that the reason to clone the main repository is that it will be
>   easier
>
> > to merge them together eventually? Or even to keep the plan 9
>   branch
>
> > up
> > to date with new versions of the mainline? I have based my port on
>   the
>
> > stable release 3.9 while the core team is happily hacking away on
>   what
>
> > even will be the next release (usually one version per year).
> >
> > The official site has many git repositories
> > (https://source.netsurf-browser.org) - from which I actually downloaded
> > every support library separately. Each repository has a tag for
>   each
>
> > release. There are also a number of branches (especially for the
>   main
>
> > netsurf repository:
> > https://source.netsurf-browser.org/netsurf.git/refs/heads) that
>   looks
>
> > like experiments.
> >
> > I might be inclined to keep it simple to begin with, but if there
>   are
>
> > very compelling reasons for a more elaborate way, I might be open
>   to
>
> > that, in order to avoid lots of work later on.
> > -- Kyle
>
> -- Kyle
> -- Kyle



-- 
http://echoline.org

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[jamos]

Hi Eli,

The new Github repos by Ori are not yet completely up to date with my 
changes. I am new to Git which makes things slower. For the impatient 
there is still my old tar-ball, updated with a slightly more efficient 
redrawing:

https://webbkurs.ei.hv.se/~imjam/plan9/netsurf-3.9-2020-01-24.tgz

Also, I've compiled a list of changes that I had to make to the source 
in order to make it compile on 9front. People here might have ideas on 
how to solve these issues more elegantly than I do now.

https://webbkurs.ei.hv.se/~imjam/plan9/port_ns39.txt

Now, to your problem. I think you should be able to clone with git:// 
without having any key, and that is how you got the nsport repo.

A learnt that a good way of testing if your ssh-key works properly, is 
to run a 'ssh git@github.com' If it works, it would greet you something 
like:

"Hi <yourgithubname>! You've successfully authenticated, but GitHub does 
not provide shell access."

If it doesn't work you would instead get a message that is very similar 
to the error you describe. Does the key in your factotum work to ssh 
into other Unix machines?

I made my key pair using the instructions in section 8.4.6.3.1 in the 
FQA. Then I uploaded the file 'key.pub' to my Github account, and copied 
the file 'key' (the private key) to my factotum.

/Jonas


On 2020-01-25 17:11, Eli Cohen wrote:

> I'm having all kinds of problems checking this out.
> 
> nsport/fetch clone fails with:
> ssh: auth: no key matches proto=rsa service=ssh role=client
> 
> I have verified there is a key in factotum
> 
> On Fri, Jan 24, 2020 at 10:41 AM <jamos@oboj.net> wrote:
> I just committed the first changes to the git repo that Ori kindly set
> up for the Plan 9 port of Netsurf. I have checked in the files for the
> smallest and simplest library (libwapcaplet) as a test, using git9 by
> Ori. I will continue with the other libraries, and the browser itself.
> Each library is in it's own repo on Github. I'll write again when I
> managed to commit the rest.
> 
> For the curious, you can help me to see if I did everything correctly,
> by checking out and compiling the 'libwapcaplet' library. This is my
> first real Git experience :-)
> 
> git/clone git://github.com/netsurf-plan9/libwapcaplet.git
> 
> Kyle> I have something partially working with webfs
> 
> This is super cool! If you feel for it, it would be interesting to read
> about your efforts and the
> problems you encountered.
> 
> /Jonas
> 
> On 2020-01-24 20:16, Kyle Nusbaum wrote:
> 
> I am away from home for the next week and didn't bring the code with
> me.
> 
> I have been hacking on it in my spare time and made some progress. It's
> not pretty yet, but it's actually minimally useful (to me at least). I
> will try to get some repos set up on GitHub when I get back if someone
> wants to look at what I've done.
> 
> On January 24, 2020 3:09:57 AM EST, Eli Cohen <echoline@gmail.com>
> wrote: bump. did anyone ever put repositories of this up yet? don't let
> them
> shout you down
> 
> On Tue, Jan 7, 2020 at 8:26 PM Kyle Nusbaum <knusbaum@sdf.org> wrote:
> Attachment didn't take. My mistake.
> 
> On January 7, 2020 10:23:40 PM CST, Kyle Nusbaum <knusbaum@sdf.org>
> wrote: I gave up trying talking directly on /net/tcp. It is a pointless
> exercise and would need to be replaced right away anyway.
> 
> I have something partially working with webfs. I replaced the   llcache
> 
> implementation with one that uses webfs. We still need the old
    version

>> to handle objects like "resources:quirks.css" etc.
>> 
>> I'll keep working on it when I get time.
>> I'm attaching a screenshot of the thing partially rendering the
    netsurf

> website.
> 
> On January 4, 2020 3:33:48 PM CST, jamos@oboj.net wrote: On 2020-01-04
> 19:14, ori@eigenstate.org wrote:
> 
> What I'd do is clone the upstream netsurf repos onto any git host
> that you feel like (except gitlab -- git9 triggers a bug in their
> backend, and I haven't had time to find a workaround), and then
> branch off a 'plan9' branch that we can work on, and commit the
> current state.
> That sounds like a cool way, but I am kind of a git rookie. I
    assume

> that the reason to clone the main repository is that it will be
    easier

> to merge them together eventually? Or even to keep the plan 9
    branch

> up
> to date with new versions of the mainline? I have based my port on
    the

> stable release 3.9 while the core team is happily hacking away on
    what

> even will be the next release (usually one version per year).
> 
> The official site has many git repositories
> (https://source.netsurf-browser.org) - from which I actually downloaded
> every support library separately. Each repository has a tag for
    each

> release. There are also a number of branches (especially for the
    main

> netsurf repository:
> https://source.netsurf-browser.org/netsurf.git/refs/heads) that
    looks

> like experiments.
> 
> I might be inclined to keep it simple to begin with, but if there
    are

> very compelling reasons for a more elaborate way, I might be open
    to

> that, in order to avoid lots of work later on.
> -- Kyle

-- Kyle
-- Kyle

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Ori Bernstein]

On Sun, 26 Jan 2020 23:10:50 +0200, jamos@oboj.net wrote:

> Hi Eli,
> 
> The new Github repos by Ori are not yet completely up to date with my 
> changes. 

I spent some time on this, and it works for me now:

	https://github.com/netsurf-plan9/

Make sure you update your git9: I fixed a couple of bugs
that this was triggering.

Since there's a lot of repositories, we've got a repo
with management scripts. To get this, assuming you've
got a github account set up:

	# get it
	git/clone git+ssh://git@github.com/netsurf-plan9/nsport
	cd nsport
	fetch clone
	mk

	# use it (local html only so far)
	netsurf/6.nsfb

So, I think it's open season for patches.

-- 
    Ori Bernstein

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> I am away from home for the next week and didn't bring the code with me.
> 
> I have been hacking on it in my spare time and made some progress. It's not pretty yet, but it's actually minimally useful (to me at least). I will try to get some repos set up on GitHub when I get back if someone wants to look at what I've done.

If you've got something working, I'm very interested to see.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

[-- Attachment #1: Type: text/plain, Size: 212 bytes --]

I'm just back. I'll pull your repositories and start trying to integrate my changes. 
Would you prefer to look at changes through github and pull requests, or is
there another way everyone prefers to share them?

[-- Attachment #2: Type: message/rfc822, Size: 1298 bytes --]

From: ori@eigenstate.org
To: knusbaum@sdf.org, 9front@9front.org, echoline@gmail.com
Subject: Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)
Date: Mon, 3 Feb 2020 08:00:33 -0800
Message-ID: <7D13682ADB20BC9EADBE417621FC875F@eigenstate.org>

> I am away from home for the next week and didn't bring the code with me.
> 
> I have been hacking on it in my spare time and made some progress. It's not pretty yet, but it's actually minimally useful (to me at least). I will try to get some repos set up on GitHub when I get back if someone wants to look at what I've done.

If you've got something working, I'm very interested to see.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

> I'm just back. I'll pull your repositories and start trying to integrate my changes. 
> Would you prefer to look at changes through github and pull requests, or is
> there another way everyone prefers to share them?

Personal preference is just diffs on mailing lists, especially
since I'll be applying them from 9front.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Kyle Nusbaum]

[-- Attachment #1: Type: text/plain, Size: 104 bytes --]

That works for me. I've not sumbitted patches this way before so correct me if my diffs are not usable.

[-- Attachment #2: Type: message/rfc822, Size: 1429 bytes --]

From: ori@eigenstate.org
To: knusbaum@sdf.org, ori@eigenstate.org, 9front@9front.org, echoline@gmail.com
Subject: Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)
Date: Tue, 4 Feb 2020 12:11:33 -0800
Message-ID: <067F42E005153D356A4360DC0CB0EC53@eigenstate.org>

> I'm just back. I'll pull your repositories and start trying to integrate my changes. 
> Would you prefer to look at changes through github and pull requests, or is
> there another way everyone prefers to share them?

Personal preference is just diffs on mailing lists, especially
since I'll be applying them from 9front.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[telephil9]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

Hi,

For me, it does not even build. I get surprising errors from pcc:
	??none??: nsglobe.8: opcode out of range 25710
		probably not a .8 file
	pcc: 8l: 8l 182088: error
	mk: pcc -I ../include ...  : exit status=rc 182050: pcc 182059: 8l: 8l 182088: error
	??none??: nsglobe.8: opcode out of range 25710
		probably not a .8 file
	pcc: 8l: 8l 182089: error
	??none??: nsglobe.8: opcode out of range 25710
		probably not a .8 file
	pcc: 8l: 8l 182090: error
	??none??: nsglobe.8: opcode out of range 25710
		probably not a .8 file
	pcc: 8l: 8l 182091: error

My 9front install is fairly up to date if that matters.

Regards,
Philippe

[-- Attachment #2: Type: message/rfc822, Size: 5155 bytes --]

From: jamos@oboj.net
To: 9front@9front.org
Subject: [9front] Netsurf 3.9 for Plan 9 (work in progress)
Date: Thu, 02 Jan 2020 00:02:20 +0200
Message-ID: <30b184ac47ef349337078b6caee9c0c4@oboj.net>

Hello everyone,

As some of you know from the 9fans discord channels, I am trying to port 
the web browser Netsurf to Plan9 (9front).
My port is still very much work in progress, but I wanted to publish a 
first version for the ones that might find it interesting to compile and 
run. I started out with the prior work of Jens Staal and AAP that I 
found in different contrib directories, but my port is based on the 
latest stable version.

My port so far uses the 'framebuffer' driver, which means that the 
browser draws in a memory bitmap, than then is copied to a Plan 9 Image 
using loadimage(). It does not work to snarf or paste. If I get good 
success with the framebuffer frontend, I will try to write a native 
frontend for Plan 9 there is already ones for amiga, atari, beos, gtk, 
riscos and windows present.

There is a lot of functionality lacking currently, but it is possible to 
load local web pages, even if they don't display so nicely. There are 
many things to figure out. I have not given fonts any thoughts. It is 
little endian (as I commented out the code that checked for endianess). 
In reality not so much works, but it compiles and something shows... :-) 
There is a lot of README files though, and I am open to all kinds of 
input.

You can the source code here: 
https://webbkurs.ei.hv.se/~imjam/plan9/netsurf-3.9-2020-01-01.tgz

//Jonas Amoson

Ps. Oh, and the port relies heavily on APE-shit, and being a browser it 
also supports a lot of WEB-shit ;-)

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[telephil9]

> Hi,
> 
> For me, it does not even build. I get surprising errors from pcc:
> 	??none??: nsglobe.8: opcode out of range 25710
> 		probably not a .8 file
> 	pcc: 8l: 8l 182088: error
> 	mk: pcc -I ../include ...  : exit status=rc 182050: pcc 182059: 8l: 8l 182088: error
> 	??none??: nsglobe.8: opcode out of range 25710
> 		probably not a .8 file
> 	pcc: 8l: 8l 182089: error
> 	??none??: nsglobe.8: opcode out of range 25710
> 		probably not a .8 file
> 	pcc: 8l: 8l 182090: error
> 	??none??: nsglobe.8: opcode out of range 25710
> 		probably not a .8 file
> 	pcc: 8l: 8l 182091: error
> 
> My 9front install is fairly up to date if that matters.
> 
> Regards,
> Philippe

Forgot to mention the error is in libnsfb tests.
When I skip this step, I got the browser building and running.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[ori]

>> Hi,
>> 
>> For me, it does not even build. I get surprising errors from pcc:
>> 	??none??: nsglobe.8: opcode out of range 25710
>> 		probably not a .8 file
>> 	pcc: 8l: 8l 182088: error
>> 	mk: pcc -I ../include ...  : exit status=rc 182050: pcc 182059: 8l: 8l 182088: error
>> 	??none??: nsglobe.8: opcode out of range 25710
>> 		probably not a .8 file
>> 	pcc: 8l: 8l 182089: error
>> 	??none??: nsglobe.8: opcode out of range 25710
>> 		probably not a .8 file
>> 	pcc: 8l: 8l 182090: error
>> 	??none??: nsglobe.8: opcode out of range 25710
>> 		probably not a .8 file
>> 	pcc: 8l: 8l 182091: error
>> 
>> My 9front install is fairly up to date if that matters.
>> 
>> Regards,
>> Philippe
> 
> Forgot to mention the error is in libnsfb tests.
> When I skip this step, I got the browser building and running.

Race condition in the mkfile: multiple rules try to output to
nslglobe.6 when the build is run in parallel, which works poorly.

Try this version of the mkfile:

	</$objtype/mkfile
	
	CC=pcc
	DST=$O.frontend $O.polygon $O.polystar $O.plottest $O.text-speed $O.bitmap $O.path $O.rgb
	
	HFILES=\
		../include/libnsfb.h ../include/libnsfb_cursor.h ../include/libnsfb_event.h \
		../include/libnsfb_plot.h ../include/libnsfb_plot_util.h
	
	
	CFLAGS=-I ../include -I . -I ../../posix/include \
		-D_POSIX_SOURCE -D_RESEARCH_SOURCE
	
	LIB=../src/libnsfb.$O.a
	
	
	all:V:	$DST	
	
	$O.%:	%.$O nsglobe.$O $HFILES $LIB
		$CC -o $target $CFLAGS $stem.$O nsglobe.$O $LIB
	
	%.$O:	$HFILES		# don't combine with following %.$O rules
	
	%.$O:	%.c
		$CC -c $CFLAGS $stem.c
	
	clean:V:
		rm -f $DST frontend.$O polygon.$O polystar.$O plottest.$O text-speed.$O rgb.$O \
		bitmap.$O globe.$O nsglobe.$O path.$O

The mkfiles should really be converted to use a common mk include for these patterns.
If not /sys/src/cmd/mkmany, then at least ../../ns{lib,many}.

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[telephil9]

>>> Hi,
>>> 
>>> For me, it does not even build. I get surprising errors from pcc:
>>> 	??none??: nsglobe.8: opcode out of range 25710
>>> 		probably not a .8 file
>>> 	pcc: 8l: 8l 182088: error
>>> 	mk: pcc -I ../include ...  : exit status=rc 182050: pcc 182059: 8l: 8l 182088: error
>>> 	??none??: nsglobe.8: opcode out of range 25710
>>> 		probably not a .8 file
>>> 	pcc: 8l: 8l 182089: error
>>> 	??none??: nsglobe.8: opcode out of range 25710
>>> 		probably not a .8 file
>>> 	pcc: 8l: 8l 182090: error
>>> 	??none??: nsglobe.8: opcode out of range 25710
>>> 		probably not a .8 file
>>> 	pcc: 8l: 8l 182091: error
>>> 
>>> My 9front install is fairly up to date if that matters.
>>> 
>>> Regards,
>>> Philippe
>> 
>> Forgot to mention the error is in libnsfb tests.
>> When I skip this step, I got the browser building and running.
> 
> Race condition in the mkfile: multiple rules try to output to
> nslglobe.6 when the build is run in parallel, which works poorly.
> 
> Try this version of the mkfile:
> 
> 	</$objtype/mkfile
> 	
> 	CC=pcc
> 	DST=$O.frontend $O.polygon $O.polystar $O.plottest $O.text-speed $O.bitmap $O.path $O.rgb
> 	
> 	HFILES=\
> 		../include/libnsfb.h ../include/libnsfb_cursor.h ../include/libnsfb_event.h \
> 		../include/libnsfb_plot.h ../include/libnsfb_plot_util.h
> 	
> 	
> 	CFLAGS=-I ../include -I . -I ../../posix/include \
> 		-D_POSIX_SOURCE -D_RESEARCH_SOURCE
> 	
> 	LIB=../src/libnsfb.$O.a
> 	
> 	
> 	all:V:	$DST	
> 	
> 	$O.%:	%.$O nsglobe.$O $HFILES $LIB
> 		$CC -o $target $CFLAGS $stem.$O nsglobe.$O $LIB
> 	
> 	%.$O:	$HFILES		# don't combine with following %.$O rules
> 	
> 	%.$O:	%.c
> 		$CC -c $CFLAGS $stem.c
> 	
> 	clean:V:
> 		rm -f $DST frontend.$O polygon.$O polystar.$O plottest.$O text-speed.$O rgb.$O \
> 		bitmap.$O globe.$O nsglobe.$O path.$O
> 
> The mkfiles should really be converted to use a common mk include for these patterns.
> If not /sys/src/cmd/mkmany, then at least ../../ns{lib,many}.

That was it!

Thanks Ori

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[Steve Simon]

is the mkfile cast in terms of .8 or .5 object files rather than using .$O ?

-Steve


> On 3 Jan 2020, at 10:39 am, telephil9@gmail.com wrote:
> 
> 
> Hi,
> 
> For me, it does not even build. I get surprising errors from pcc:
>    ??none??: nsglobe.8: opcode out of range 25710
>        probably not a .8 file
>    pcc: 8l: 8l 182088: error
>    mk: pcc -I ../include ...  : exit status=rc 182050: pcc 182059: 8l: 8l 182088: error
>    ??none??: nsglobe.8: opcode out of range 25710
>        probably not a .8 file
>    pcc: 8l: 8l 182089: error
>    ??none??: nsglobe.8: opcode out of range 25710
>        probably not a .8 file
>    pcc: 8l: 8l 182090: error
>    ??none??: nsglobe.8: opcode out of range 25710
>        probably not a .8 file
>    pcc: 8l: 8l 182091: error
> 
> My 9front install is fairly up to date if that matters.
> 
> Regards,
> Philippe
> 
> <mime-attachment>

Re: [9front] Netsurf 3.9 for Plan 9 (work in progress)

[telephil9]

> is the mkfile cast in terms of .8 or .5 object files rather than using .$O ?

No, and even if that was the case I'm building on x86 so using .8 should be ok.

Philippe


> 
> -Steve
> 
> 
>> On 3 Jan 2020, at 10:39 am, telephil9@gmail.com wrote:
>> 
>> 
>> Hi,
>> 
>> For me, it does not even build. I get surprising errors from pcc:
>>    ??none??: nsglobe.8: opcode out of range 25710
>>        probably not a .8 file
>>    pcc: 8l: 8l 182088: error
>>    mk: pcc -I ../include ...  : exit status=rc 182050: pcc 182059: 8l: 8l 182088: error
>>    ??none??: nsglobe.8: opcode out of range 25710
>>        probably not a .8 file
>>    pcc: 8l: 8l 182089: error
>>    ??none??: nsglobe.8: opcode out of range 25710
>>        probably not a .8 file
>>    pcc: 8l: 8l 182090: error
>>    ??none??: nsglobe.8: opcode out of range 25710
>>        probably not a .8 file
>>    pcc: 8l: 8l 182091: error
>> 
>> My 9front install is fairly up to date if that matters.
>> 
>> Regards,
>> Philippe
>> 
>> <mime-attachment>