plan9

[dharmatech]

Hey y'all 🙋‍♂️

Here's what I'm getting when I run lg main.lg on plan9:

Just wondering if you have any suggestions before I dig into this.

Setup

Testing this on the plan9 fork called agent9:

https://github.com/Alino/agent9

They have ported alacritty to plan9 so I wanted to see how xsofy renders in that.

Here's my go and lg versions:

cpu% go version
go version go1.26.0 plan9/amd64
cpu% lg --version
lg 1.11.1 (79b96e5)

I installed go on agent9 using their package manager:

pac9 install go

For let-go, I downloaded the binary package for plan9 here:

https://github.com/nooga/let-go/releases/download/v1.11.1/let-go_1.11.1_plan9_amd64.tar.gz

Any suggestions welcome!

CC: @Alino

[dharmatech]

As another experiment, I started a stock 9front image where I had installed let-go and xsofy from a while back.

I installed alacritty9 there.

And xsofy runs there:

It renders OK in alacritty9, but the game is extremely slow.

[dharmatech]

On that same stock 9front system (not agent9) I downloaded let-go_1.11.1_plan9_amd64.tar.gz and checked out xsofy from git.

I'm able to reproduce the original issue there (see below).

So it doesn't look like anything specific to the agent9 fork.

When I got it to run, maybe I just happened to be using a version combination of let-go and xsofy that worked OK together on plan9.

cpu% ../let-go/lg main.lg
error: failed to load xsofy/ui.lg: CompileError: compiling def value
	caused by CompileError: compiling fn body
	caused by CompileError: compiling arguments term/key-pending?
	caused by CompileError: Can't resolve term/key-pending? in this context
error: failed to load xsofy/title.lg: CompileError: compiling def value
	caused by CompileError: compiling fn body
	caused by CompileError: compiling let body
	caused by CompileError: compiling function position
	caused by CompileError: Can't resolve ui/run-loop in this context
error: failed to load xsofy/world.lg: CompileError: compiling def value
	caused by CompileError: compiling fn body
	caused by CompileError: compiling let body
	caused by CompileError: compiling if else branch
	caused by CompileError: compiling do member
	caused by CompileError: compiling function position
	caused by CompileError: Can't resolve title/show-descending-screen in this context
error: failed to load xsofy/dispatch.lg: CompileError: compiling def value
	caused by CompileError: compiling fn body
	caused by CompileError: compiling if else branch
	caused by CompileError: compiling if then branch
	caused by CompileError: compiling let binding
	caused by CompileError: compiling function position
	caused by CompileError: Can't resolve world/update-world in this context
error: failed to load xsofy/play.lg: CompileError: compiling def value
	caused by CompileError: compiling fn body
	caused by CompileError: compiling function position
	caused by CompileError: Can't resolve ui/run-loop in this context
error: Can't resolve world/inscribe-runes-on-item in this context
  --> main.lg:157:17
     |
 157 |               w (world/inscribe-runes-on-item world item-id runes)]
     |                 ^^^

[Alino]

might be slow because alacritty is depending on opengl, and my opengl port has only software based support (no HW support).
But also drawterm might be poor communication protocol for too many real time changes

[dharmatech]

Hey @Alino 🙋‍♂️

might be slow because alacritty is depending on opengl, and my opengl port has only software based support (no HW support). But also drawterm might be poor communication protocol for too many real time changes

I ran an experiment back in May where I connected to 9front via drawterm in Windows Terminal (using -G for no graphical output) and ran xsofy in that terminal. It also rendered well there, but was slow.

Since it is slow in Windows Terminal and alacritty9, I'm suspecting something else at this point.

https://x.com/dharmatrade/status/2055223176570011845

[mparrett]

Hi @dharmatech and @Alino - I've been doing some adjacent work to run let-go and xsofy in resource constrained environments, and this might benefit the performance aspect. Nothing published yet, but likely coming soon. There's also some I/O plumbing to handle for plan9 before xsofy could be playable. Would either of you be able to test some candidate builds, if I'm able to make time to look at this?

[dharmatech]

Hi @dharmatech and @Alino - I've been doing some adjacent work to run let-go and xsofy in resource constrained environments, and this might benefit the performance aspect. Nothing published yet, but likely coming soon. There's also some I/O plumbing to handle for plan9 before xsofy could be playable. Would either of you be able to test some candidate builds, if I'm able to make time to look at this?

Hey @mparrett 🙋‍♂️

Yup, happy to test when you're ready. 👍

[dharmatech]

I've updated drawterm for Windows so that it handles let-go TUI applications much better now.

xsofy running in Windows terminal connected to plan9:

While a little sluggish, it's more playable now.

Drawterm fork available here:

https://github.com/dharmatech/drawterm

Pull-request for let-go to help with the resizing:

nooga/let-go#743