~whereswaldon

North Carolina

https://waldon.blog

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

Working on Arbor Chat.

Trackers

~whereswaldon/arbor-dev

Last active 2 days ago

~whereswaldon/pointstar

Last active 2 months ago

~whereswaldon/github-action-replication-testing

Last active 7 months ago

~whereswaldon/Capital-Letters

Last active 7 months ago

~whereswaldon/trellis

Last active 1 year, 3 months ago

#112 Better button placement 2 days ago

feature added by ~whereswaldon on ~whereswaldon/arbor-dev

#112 Better button placement 2 days ago

sprig added by ~whereswaldon on ~whereswaldon/arbor-dev

#113 Notification storm on first connection from a machine 2 days ago

discussion added by ~whereswaldon on ~whereswaldon/arbor-dev

#113 Notification storm on first connection from a machine 2 days ago

feature added by ~whereswaldon on ~whereswaldon/arbor-dev

#113 Notification storm on first connection from a machine 2 days ago

sprig added by ~whereswaldon on ~whereswaldon/arbor-dev

#113 Notification storm on first connection from a machine 2 days ago

Ticket created by ~whereswaldon on ~whereswaldon/arbor-dev

The current notification policy sends a notification when a new node is added to local storage that meets the following criteria:

  • the node was not authored by the local Identity
  • the node is either a reply to a node authored by the local identity or a new conversation

Unfortunately, this means that a user connecting for the very first time from a new device gets notified of every new conversation from the past.

The question is, what's the right policy to suppress this? I think that a sane choice would be to limit notifications for new conversations back to a particular point in time, but which point? 24 hours? What if you just don't open the app for 2 days? Do we care that you miss conversations that occurred a day ago?

We could also try recording the last time you had the app running and notify only for conversations since that point in time. If that point is undefined, then we don't notify at all. This seems compelling, but it may have some downside that I haven't seen yet.

Thoughts?

#144 Nondeterminism in rendertests with NVIDIA 2 days ago

Comment by ~whereswaldon on ~eliasnaur/gio

I am also unable to reproduce this now. Thanks for the quick fix!

#121 X11 crash on start 3 days ago

Comment by ~whereswaldon on ~eliasnaur/gio

Up until today, I'd not been able to trigger this bug on the version of Go's master branch prior to your CL, but it finally happened. The version of Go with your CL applied did run the same code successfully. I know that this issue is closed, but I wanted to share that we now have stronger positive confirmation that the fix was correct.

#144 Nondeterminism in rendertests with NVIDIA 3 days ago

Ticket created by ~whereswaldon on ~eliasnaur/gio

I accidentally discovered today that the internal/rendertest package appears to have nondeterministic results when run on X11 with an NVIDIA GPU.

Here are the results of running the tests ten times consecutively.

This was done with NVIDIA Driver 440.82 on a GeForce GTX 960.

Nothing trips the race detector, so I assume that whatever is happening is likely in the CGO, maybe within NVIDIA's GL implementation?

#112 Better button placement 17 days ago

Comment by ~whereswaldon on ~whereswaldon/arbor-dev

I see your point. Perhaps long-pressing the message should filter? The button could then serve as a backup for people who don't like that kind of implicit action.

Fanning the buttons is possible, but it's complex. Generally we only want the primary action to be a floating button on the bottom, and I don't know that filtering is the primary action. It bears thinking about...