~whereswaldon

North Carolina

https://waldon.blog

Interested in Linux, decentralization, cryptography, golang/rust/c, and communication.

I spend most of my free time on:

  • Arbor, a tree-based, decentralizable chat platform
  • Gio, an immediate-mode UI framework for Go
  • Gio-Extras, my collection of libraries to extend Gio

If you get value out of my work, please consider sponsoring me on Liberapay or GitHub.

Trackers

~whereswaldon/arbor-dev

Last active 18 hours ago

~whereswaldon/gio-extras

Last active 4 months ago

~whereswaldon/pointstar

Last active 11 months ago

~whereswaldon/github-action-replication-testing

Last active 1 year, 5 months ago

~whereswaldon/Capital-Letters

Last active 1 year, 5 months ago

~whereswaldon/trellis

Last active 2 years ago

#155 Write a spec for the twig extensions defined in forest-ex 18 hours ago

Comment by ~whereswaldon on ~whereswaldon/arbor-dev

I've made some minor edits. Thanks for working on this!

#215 cannot use nil as type _Ctype_EGLConfig in return argument a day ago

Comment by ~whereswaldon on ~eliasnaur/gio

For what it's worth, I've had gopls erroneously import this ancient version of gio as well.

#214 Compute renderer hangs X11 NVIDIA desktop 2 days ago

Comment by ~whereswaldon on ~eliasnaur/gio

On the compute branch at gioui.org v0.0.0-20210412203452-8c59aa82afca, I get:

panic: glGetError: 0x505

goroutine 6 [running, locked to thread]:
gioui.org/gpu.buildPath(0x6a1050, 0xc00007a270, 0xc0003de486, 0x140, 0x2b7a, 0x0, 0x0, 0x0)
	/home/chris/Code/go/pkg/mod/gioui.org@v0.0.0-20210412203452-8c59aa82afca/gpu/path.go:307 +0xb9
gioui.org/gpu.(*drawOps).collect(0xc0003fe040, 0x6a1050, 0xc00007a270, 0xc000012580, 0xc000136410, 0x320, 0x2bc)
	/home/chris/Code/go/pkg/mod/gioui.org@v0.0.0-20210412203452-8c59aa82afca/gpu/gpu.go:810 +0x31b
gioui.org/gpu.(*compute).Collect(0xc0003fe000, 0x320, 0x2bc, 0xc000136410)
	/home/chris/Code/go/pkg/mod/gioui.org@v0.0.0-20210412203452-8c59aa82afca/gpu/compute.go:265 +0xfa
gioui.org/app.(*renderLoop).renderLoop.func1(0xc00006c7e0, 0x6a01f8, 0xc000012550, 0xc0000204e0)
	/home/chris/Code/go/pkg/mod/gioui.org@v0.0.0-20210412203452-8c59aa82afca/app/loop.go:91 +0x30f
created by gioui.org/app.(*renderLoop).renderLoop
	/home/chris/Code/go/pkg/mod/gioui.org@v0.0.0-20210412203452-8c59aa82afca/app/loop.go:61 +0x7f
exit status 2

I realized that the above was accidentally 1 commit behind compute's HEAD, so I tried at gioui.org v0.0.0-20210412203657-60209f97d31d and got:

2021/04/13 09:24:52 MapBufferRange: error 0x505
exit status 1

#214 Compute renderer hangs X11 NVIDIA desktop 2 days ago

Comment by ~whereswaldon on ~eliasnaur/gio

I can resolve that URL, but I can't find that commit in the actual git history at all. I tested against main at gioui.org v0.0.0-20210412115641-3a94f7bf7088 and it still hangs. Here's the error:

panic: glGetError: 0x505

goroutine 19 [running, locked to thread]:
gioui.org/gpu.buildPath(0x69e930, 0xc0001861a0, 0xc000412486, 0x140, 0x2b7a, 0x0, 0x0, 0x0)
	/home/chris/Code/go/pkg/mod/gioui.org@v0.0.0-20210412115641-3a94f7bf7088/gpu/path.go:307 +0xb9
gioui.org/gpu.(*drawOps).collect(0xc00044c040, 0x69e930, 0xc0001861a0, 0xc000194560, 0xc000076460, 0x320, 0x2bc)
	/home/chris/Code/go/pkg/mod/gioui.org@v0.0.0-20210412115641-3a94f7bf7088/gpu/gpu.go:811 +0x31b
gioui.org/gpu.(*compute).Collect(0xc00044c000, 0x320, 0x2bc, 0xc000076460)
	/home/chris/Code/go/pkg/mod/gioui.org@v0.0.0-20210412115641-3a94f7bf7088/gpu/compute.go:263 +0xfa
gioui.org/app.(*renderLoop).renderLoop.func1(0xc0001a0780, 0x69dad8, 0xc000194530, 0xc00022a420)
	/home/chris/Code/go/pkg/mod/gioui.org@v0.0.0-20210412115641-3a94f7bf7088/app/loop.go:91 +0x30f
created by gioui.org/app.(*renderLoop).renderLoop
	/home/chris/Code/go/pkg/mod/gioui.org@v0.0.0-20210412115641-3a94f7bf7088/app/loop.go:61 +0x7f
exit status 2

EDIT: I think this error may have been emitted on stderr the whole time, but after my desktop froze so I couldn't see it. Thank goodness for 2>&1 > file

#214 Compute renderer hangs X11 NVIDIA desktop 4 days ago

Ticket created by ~whereswaldon on ~eliasnaur/gio

Launching programs with GIORENDERER=forcecompute on my X11 NVIDIA GNOME desktop causes the entire desktop to hang. Based on what little I can glean in this state by VT switching, it appears that the Xorg server is using 100% of a CPU. It does occasionally draw new frames (perhaps once per 10 seconds or so), so I can eventually kill the program. When I kill the Gio application, performance returns to normal.

Here I have uploaded the output of glxinfo on this system, in the hope that it can help you understand what may or may not be missing here.

I do not get any errors from Gio, and I'm having trouble filtering through various system logs for relevant data. I did find what appears to be an NVIDIA driver crash in dmesg, and I've provided the output here.

Naturally, I'm happy to provide any relevant diagnostic data; just let me know what would be helpful.

My test application is the Gio kitchen example with Gio version gioui.org v0.0.0-20210410094005-495c69018772.

#155 Write a spec for the twig extensions defined in forest-ex 7 days ago

Comment by ~whereswaldon on ~whereswaldon/arbor-dev

Absolutely link to the spec! Link to it from everywhere! But yes, we should keep the spec separate so that other implementations don't need to dig through our golang codebase to find them.

#70 Improve filesystem layout of the Grove type to make Store operations faster 7 days ago

Comment by ~whereswaldon on ~whereswaldon/arbor-dev

I'm going to close this as effectively a duplicate of #174

REPORTED RESOLVED DUPLICATE

#155 Write a spec for the twig extensions defined in forest-ex 7 days ago

Comment by ~whereswaldon on ~whereswaldon/arbor-dev

I think this formatting looks good, but these should go in this directory (or a subdirectory).

#177 Add an indicator to messages for whether or not the message has been sent 7 days ago

Comment by ~whereswaldon on ~whereswaldon/arbor-dev

I'm thinking an indicator for "unsent" would be a nice, clear way to express this, and it would be friendly for people composing messages offline (to be sent later).

Implementing this primarily requires extending sprig's plumbing to create some local index of sent/unsent messages. Whenever we compose a message, we add it to this list. Whenever we send it (and get an ack from the relay), we remove it from the list. The list needs to be saved to and loaded from disk across application restarts. Once we can actually track this state, exposing it in the GUI is probably trivial.

#155 Write a spec for the twig extensions defined in forest-ex 10 days ago

Comment by ~whereswaldon on ~whereswaldon/arbor-dev

I see this as a multilayered problem. There's a set of metadata with very specific semantics (invisible, expiry, etc), and a set of conventions for how clients should combine these attributes to accomplish useful things.

I have no objection to using a structured text format for the various specs, though I'm not yet certain what we get beyond standardization from that. Perhaps we could generate code from that in the future? Anyway, TOML seems like a fine approach there.

Thanks for posting, as your questions helped me clarify my thinking on this. I'd like to see two things:

  • a structured text document describing each metadata field
  • a markdown document (or set of documents) describing conventions for their use. For instance, one of these would be "User activity indicators", and would describe using the expiry, invisible, and active-status metadatas together to announce the {on,off}line status of a user, as well as recommendations for when such messages should be created.

~athorp96 does that make sense to you?