Hey Drew,

I've been working on BARE implementation [0] and been using the test
cases from go-bare as a reference point. I've noticed the Department
enum in the example/schema.bare file has a "u8" after the name [1]. I
assume this refers to the underlying datatype for the enum, but this
conflicts with the spec defined at baremessages.org, which states the
underlying datatype for enums is always a uint. If this has changed, the
site should be updated to reflect that, which I'm happy to send patches
for when I get the time.

Thanks,

--Noah

---
 index.html | 1 +
 1 file changed, 1 insertion(+)

diff --git a/index.html b/index.html
index 06fd6cd..e06be2c 100644
--- a/index.html
+++ b/index.html
@@ -141,6 +141,7 @@ type Address {
   <dd><a href="https://git.sr.ht/~tdeo/serde_bare">serde_bare</a></dd>
   <dt>Python</dt>
   <dd><a href="https://sr.ht/~martijnbraam/bare-py/">bare-py</a></dd>
+  <dd><a href="https://sr.ht/~chiefnoah/pybare/">pybare</a></dd>
   <dt>JavaScript</dt>
[message trimmed]

When using bare.UnmarshalReader the interal bufio.Reader may overzealously read
more bytes than is necessary to decode the message. By dropping the
buffered reader from bufio in favor of a single byte buffered reader, we can
minimize the number of bytes read from the input io.Reader.
By doing this, we can call bare.UnmarshalReader multiple times on the
same stream to decode multiple messages.

See example/stream/stream.go for a reference on how this may be done.

Includes a basic test.

Also moves the existing example into a subfolder and creates a new
folder for the stream test so both can be run using `go run`.
[message trimmed]

From: Noah Pederson <noah.pederson@coldquanta.com>

When using bare.UnmarshalReader the interal bufio.Reader may overzealously read
more bytes than is necessary to decode the message. By dropping the
buffered reader from bufio in favor of a single byte buffered reader, we can
minimize the number of bytes read from the input io.Reader.
By doing this, we can call bare.UnmarshalReader multiple times on the
same stream to decode multiple messages.

See example/stream/stream.go for a reference on how this may be done.

Includes a basic test.

Also moves the existing example into a subfolder and creates a new
[message trimmed]

> One could argue that you're not editing it "directly",
> as it's not through the website / through the same interface
> that you use to read it.

This is my understanding too. I believe part of the point of a 'wiki', back
when the idea was first created was to allow for quick, direct edits to the
page. By that definition, man.sr.ht doesn't meet the definition, but
GitHub's wiki pages do.

I feel like that would add more coupling between git.sr.ht and
builds.sr.ht than isn't strictly necessary for this functionality. I'm
personally happy with the existing method, even though it does present
some minor annoyances when rehosting projects on other forges.

--Noah

On Wed Mar 4, 2020 at 5:39 PM PST, Victor Goff wrote:
> ... perhaps delete the key and submit it (or a new one) with only the
> information you would like to share publicly?

This is probably the easiest way to handle it. You don't have to do
anything special, just delete the last part of the public key when you
paste it into meta.sr.ht.

> > Also, I did a bit of digging around, and the "A list of your public ..."
> > message near the "Add key" button is quite recent [1] as I did not
> > remember reading such a comment before today.
>
> I only signed up a couple of weeks ago, so I do not remember it not
> being there.

On Fri Feb 14, 2020 at 12:56 PM, Jonas Platte wrote:
> I'm looking forward to user groups on sourcehut!
>
> One minor note though: using ^ as the sigil to denote might cause some
> unnecessary confusion for zsh users when using the url to a user group
> or one of its repositories / lists /... on the command line as zsh
> interprets unquoted strings containing a ^ as some kind of glob.
>
> Maybe a different sigil like + could be used?

As a zsh user, I think just escaping the ^ would be sufficient.
That being said, according to RFC 3986 (https://tools.ietf.org/html/rfc3986#section-3.3)
the only valid characters in a URI are:

Try adding `export` in front of the ENV.

I'm not sure exactly what you're doing, but the cases where I've
had issues connecting to the internet from within containers,
it was a botched install (missing iptables rules) or the
ipv4/ipv6 forwarding config not set on the host.

This link should help:
https://linuxconfig.org/how-to-turn-on-off-ip-forwarding-in-linux