Re: [go-nuts] Maddy - composable all-in-one mail server
Thanks for plugging this. Out of curiosity, what does "composable" mean in this case? On Thu, 21 May 2020 at 06:14, wrote: > > Hello, > > I would like to introduce a project that, in my opinion, needs more attention > as it has a great potential. It is a secure-by-default MTA and MDA > implementation in a single server called Maddy, which works similarly to > Caddy web server. > From what I witness, it is already working pretty well, despite being quite > alpha-quality software. > > You can read more about it on a GitHub page: > https://github.com/foxcpp/maddy > > Cheers. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/002d5e0d-2469-4f15-8eb0-e8bdc67419f8%40googlegroups.com. -- Adrian Ratnapala -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAN%2BHj7j81-8JjZpxsBbef9SApv%2BDG%2BiCqrtEK9Rquz73UyvU7A%40mail.gmail.com.
Re: [go-nuts] weird sighup
I'd have expected that to work, because syntactically the slice is assigned to only after the new, smaller slice is fully constructed -- including all the data copying. But it still make me twitchy about the possibility that the runtime shortens the slice before reading all the data, resulting in an out-of-bounds read. As defensive programming, you can first make an explicit slice variable for the tail and then do the append. tail := s[i+1:] s = append(s[:i], tail...) // tail is still in scope ... so maybe that makes a differences? I'd be interested to see if this changes anything. Because if it works, it smells like a bug in the runtime. On Wed, 20 May 2020 at 10:09, Ian Lance Taylor wrote: > > On Tue, May 19, 2020 at 9:53 AM wrote: > > > > I am using go-1.14.1. I am using this code to remove i-th element from the > > slice. > > > > s = append(s[:i], s[i+1:]...) > > > > It works on my machine but gives panic on docker-container with error > > "range out of bound" when it has just 1 element left. > > > > I want to check if this is an unsafe code and how can I improve this? > > It's hard to tell with only a code fragment. The line you show will > crash if i >= len(s). > > Ian > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUdMiJLvdfYe9%2B7fzjeuwJtu6uGxmW3UE-%3D%2BZ2DQLU%3D1Q%40mail.gmail.com. -- Adrian Ratnapala -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAN%2BHj7jvdfx74d6gKctQNN-2jLKstoSpWnKauckLvGoEo23YDQ%40mail.gmail.com.
Re: [go-nuts] Re: Bencharking issue with b.StartTimer and b.StopTimer. Was: Benchmark using b.StopTimer and b.StartTimer has unexpected behaviour - to me at least
; results are a surprise, at least to me. Here are the results when Count = 8: >> >> Benchmark1-4 2706196 442 ns/op >> Benchmark2-4 1357482 873 ns/op >> Benchmark3-4 840729 1387 ns/op >> PASS >> ok bar.com/benchmarks 23.547s >> >> The ratio of timings for Benchmark1 and Benchmark2 are roughly in line with >> expectations but I was surprised to see that the timings for Benchmark3 are >> now larger than those for Benchmark2. >> >> Can anyone explain this? >> >> TIA >> Orson > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/feda7e38-5d1f-43cf-b0cd-98db0a94d3c9%40googlegroups.com. -- Adrian Ratnapala -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAN%2BHj7jEvkOBejV6bZbBmQEcapKafUvBAJKmAhoVGg%2BC7PwEEg%40mail.gmail.com.
Re: [go-nuts] If in doubt prefer to wrap errors with %v, not %w?
On Mon, 23 Mar 2020 at 11:22, Axel Wagner wrote: > • A function takes an io.Reader to parse the stream into some data structure > (think a json-parser). It obviously uses no other input or abstraction or > state. It makes sense to wrap the error - this allows you to provide > structured extra information (like offsets) to the user of the library and > better error messages, while maintaining your users ability to switch on what > actually went wrong. That's a good point, and I suppose it generalises. Whenever you receive an interace from client code, then you have no compiler-enforced way to predict which errors you'll get from calls to that interface; but your client might. Therefore you should either pass the error up directly or else user wrapping. (Microsoft has/had the problem that many Windows APIs let clients implement abstract classes for OS middleware to call. The MSDN page for each method would list which error codes were allowed for the method, but they had no way to enforce this, so the middleware had to try and handle all possible errors). > That latter part, BTW, is IMO a blessing and a curse. It's a blessing, > because it can reduce coupling from details in the wrapping case. ... I think this is the classic dynamic vs. static typing trade-off. Go has always been a mostly static language but happy to sprinkle in dynamic typing stategically through interfaces and reflection. By standardising on the `error` interface, Go chose error handling as one of those dynamic sprinkles. > Sorry if this message is a bit chaotic and stream-of-consciousnes-y :) I > haven't quite figured out how to talk about all of this yet :) > I guess the tl;dr is, that I tend to agree - don't just use %w without > thinking. Make a deliberate choice if you want to commit to this API detail. > And as usually in API design: If in doubt, prefer to start out with less > commitment, flexibility and surface. So to turn this discussion into something actionable: should this advice be added into the documentation? And if so, where (in package fmt or errors)? Lots of programers will assume that because %w is new, then it must be the Go team's recommended "best practice". I think I was unconciously thinking that until I read the blog post. -- Adrian Ratnapala -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAN%2BHj7gvJru-ZoLUcdcCNde3iJgK5j6aoCbipksCRMYSMznjfw%40mail.gmail.com.
[go-nuts] If in doubt prefer to wrap errors with %v, not %w?
Part of the culture of Go is that we are careful to promise as little
as possible in APIs, as we will be stuck with those promises long into
the future.
Now with Go 1.13 we can do `fmt.Errorf("It broken: %w")` which means
the same thing as `fmt.Errorf("It broken: %v")` except callers get
better ways to inspect the result. But as the Go blog says, this
means the use of "%w" becomes a way to expose an API:
> In other words, wrapping an error makes that error part of your API. If you
> don't want to commit to supporting that error as part of your API in the
> future, you shouldn't wrap the error.
Given the preference for *not* introducing APIs, doesn't that mean
authors should stick to "%v" until they have clear reasons for using
"%w". After all, it's always possible to switch to "%w" later.
--
Adrian Ratnapala
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAN%2BHj7jgoMSoyTpcOL%3Da2Rd51MvO%2Bgp0XRzTHjtNZcqPdK8zOg%40mail.gmail.com.
Re: [go-nuts] SFTPGo: a Golang performance story and some questions
BTW: Thanks for all this investigation and writeups, they are interesting, and I look forward to your test results. Desipte my question, I think using a custom allocator is perfectly reasonable. go/issues/23199 is showing us that sync.Pool's interface isn't great for allocating byte-bufffers (it'd be better to explicitly ask for objects of a given size). In that sense, a custom allocator with an appropriate interface is more future-proof. > what I understand reading that issue is that sync.Pool is not the best > choice to store variable-length buffers and my first allocator I think the problem is that the total memory usage of the pool ends up O(size of large objects * total numer of objects kept). This is very wasteful if you need lots of small objects and only a few large ones. > implementation accepts buffers of any size, each received packet can > have different sizes (between 20 and 262144 bytes). So every 20 byte object will pin down ~100kiB of actual memory, which sounds pretty wasteful, but might be acceptable. > in general and currently, in my not yet public branch, I only allocate > packets of 2 different sizes and so sync.Pool could be appropriate, I'll You could have two separate pools, one for each size. This is basically a bucketed-allocator, but simpler because you already know the structure of your buckets. -- Adrian Ratnapala -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAN%2BHj7jeDGUj%3DT8-n7RMuv2i_soHMJ78M8bWOpkVq_-g3n7v5g%40mail.gmail.com.
Re: [go-nuts] SFTPGo: a Golang performance story and some questions
> > > > Any particular reason you avoided something like sync.Pool ? It could be useful in your case, allocation pattern depending. > > > Hi, > > I initially evaluated the sync.Pool then I read this article: > > https://dzone.com/articles/memory-pooling-in-go-where-why-and-how > > and this issue: > > https://github.com/golang/go/issues/23199 So If I understand go/issues/23199 correctly, the problem is that large allocations from the past hang around in the pool (and apparently this is made worse by small allocations somehow pinning them). I can see how this can be a problem, but is it a problem *for you*? You say that the allocations in question are for packets -- which I would assume all count as small. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAN%2BHj7hWu7OH%2BhSm8KLX7o8au4Y%2BEpxpSmTYeuLHeQQ%2BMepGhg%40mail.gmail.com.
