This is really more of an OS question than a Go language question.
Writing single characters is going to be expensive in any language because
you pay the considerable overhead of a system call/user-mode to kernel mode
context switch
overhead for each character. That is why the C stdio library buf
I too was puzzled by the term signed and unsigned URL.
But I have come across signed and unsigned integers.
An unsigned integer (such as uint64) can only take positive values and
zero, whereas a signed integer can also hold negative values.
So presumably an unsigned URL can only point to positive
On Tue, Dec 22, 2020 at 3:49 AM zilto karamazov wrote:
>
>
> Hello,
>
> I'm wondering if it is ok to do this ?
>
>
> package main
>
> import (
> "context"
> "fmt"
> "log"
> "net/http"
>
> "github.com/gorilla/mux"
> )
>
> func main() {
> addr :=
that is not a google url:
https://example.com/
?
On Monday, December 21, 2020 at 3:53:37 PM UTC-8 Uli Kunitz wrote:
> It is the Google Cloud Storage package. Documentation is here:
> https://pkg.go.dev/cloud.google.com/go/storage
>
> Signed URLs are URLs that allow access to an object in the
It is the Google Cloud Storage package. Documentation is here:
https://pkg.go.dev/cloud.google.com/go/storage
Signed URLs are URLs that allow access to an object in the cloud storage
without any other authentication mechanism:
https://cloud.google.com/storage/docs/access-control/signed-urls
Go
It should be
r = r.WithContext(context.WithValue(r.Context(), key, &s))
Using the address of a key was a typo.
On Tuesday, December 22, 2020 at 12:17:01 AM UTC+1 Uli Kunitz wrote:
> I don't think this is a good idea.
>
> I would do something like this.
>
> type mykey struct{}
> var key mykey
>
I don't think this is a good idea.
I would do something like this.
type mykey struct{}
var key mykey
r.Use(func(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r
*http.Request) {
var s string
r
On Mon, Dec 21, 2020 at 2:55 PM Alexander Mills
wrote:
> this is a little irritating lol, i can get a signed url via:
>
> bucket := "bnk-photos"
> filename := "mypic3.json"
> method := "PUT"
> expires := time.Now().Add(time.Minute * 10)
>
> url, err := storage.SignedURL(bucket, filename, &storage
this is a little irritating lol, i can get a signed url via:
bucket := "bnk-photos"
filename := "mypic3.json"
method := "PUT"
expires := time.Now().Add(time.Minute * 10)
url, err := storage.SignedURL(bucket, filename, &storage.SignedURLOptions{
GoogleAccessID: cfg.Email,
PrivateKey: cfg.PrivateKe
Nice! Do you have any benchmarks on how much faster the "scalar" version is
than the non-scalar?
On Tuesday, December 22, 2020 at 12:58:19 AM UTC+13 arn...@gmail.com wrote:
> Just an update (in case anyone is interested!). I went for the approach
> described below of having a Value type holdin
> @Ben interesting, I did something similar and also ended up with a 64KB
buffer (seemed like the default of 4KB didn't work very well in my
context). How did you decide of the buffer size?
I forget how I ended up with 64KB. I think I was doing performance testing
and a buffer larger than the 4KB
On Mon, Dec 21, 2020 at 8:30 PM K. Alex Mills wrote:
> I think that it would be best to keep our discussion of the proposed change
> part of the relevant GitHub tracker to ensure the conversation can happen in
> context of prior discussions.
Unfortunately, that's not going to happen, and I am
On Sun, Dec 20, 2020, 2:01 PM Jan Mercl <0xj...@gmail.com> wrote:
>
> I expressed my concerns at the issue tracker in 2017 when I still had
> a Github account. That's no more the case, so I'll take the
> opportunity to make a comment here. I still believe that the intent to
> change the behavior t
A fork is a bad choice. Better to just not use them and/or prohibit them by
policy in your org. A fork will die a slow painful death - this is a personal
opinion only.
> On Dec 21, 2020, at 11:50 AM, L Godioleskky wrote:
>
> Hopefully, the Go team will encapsulate all generics in a separate
Hopefully, the Go team will encapsulate all generics in a separate
module(s), so that those of us who want to ignore them can easily do so
On Monday, December 21, 2020 at 7:26:02 AM UTC-5 Space A. wrote:
> Unfortunately it was expected that creators of the language will not
> resist forever be
Hello,
I'm wondering if it is ok to do this ?
package main
import (
"context"
"fmt"
"log"
"net/http"
"github.com/gorilla/mux"
)
func main() {
addr := "127.0.0.1:8080"
r := mux.NewRouter()
r.HandleFunc("/", func(w http.Respo
I have just suggested the same thing @Space A, before I read your message and I
agree fully!
https://github.com/golang/go/issues/15292#issuecomment-749032046
I strongly believe we need to fork Go if generics gets added and then let the
toy people have their new shiny things in Go while we renam
Although i am also against generics, as i didn't even know it existed
before i started to see people complaining that Go didn't have it, i don't
think it will be that bad. It probably won't be overused for the same
reason interface{} isn't overused, the cases where it really makes sense
and is idio
Not sure I agree with you.
Let's see others' thoughts on it.
On Monday, December 21, 2020 at 1:38:54 AM UTC+6 Martin Hanson wrote:
> I think people who want generics added to Go should go and program in Java
> or C++.
>
> Adding generics to Go will ruin the beautiful simplicity of the language
On 12/21/20 12:26 PM, Space A. wrote:
> Unfortunately it was expected that creators of the language will not resist
> forever being under the pressure of masses
Whilst I don't agree with the language of these mails.
I have worries and struggle to see much benefit also.
Mostly I feel the time cou
This has been discussed in the proposal issue:
https://github.com/golang/go/issues/41190#issuecomment-722342397
I'm not sure this will give you a satisfactory answer, but at least it
proves the team is aware :)
On Mon, Dec 21, 2020 at 4:14 PM diegoaugu...@gmail.com <
diegoaugustomol...@gmail.com>
Hi,
I was reading https://tip.golang.org/pkg/io/fs/#File and noticed that
interface File is not embedding io.ReadCloser. Even though the signature of
the methods are identical, It would probably be a good idea to embed
io.ReadCloser (or both io.Reader and io.Closer) to state the intention of
ma
I asked a similar question recently, but have decided to approach a
different way.
I'm looking for a way to do something similar to a standard sound record
app that shows a graph line chart of the input from a mic. That's it,
nothing fancy doesn't need to record and save or anything.
Has anyone
We don't have a CGO in our project. We want libc and we value it because
it's a gold standard which makes things stable and predictive. After all,
container must just work, so we focus on our services other that testing
and troubleshooting some side technology.
For issues you can take a look at
Unfortunately it was expected that creators of the language will not resist
forever being under the pressure of masses most which do not even code in
Go, or not use Go as the main language and just following patterns and
shitty idioms they took elsewhere. Generics are bullshit crap in its
essen
Just an update (in case anyone is interested!). I went for the approach
described below of having a Value type holding a scalar for quick access to
values that fit in 64 bits (ints, floats, bools) and an interface fo for
the rest.
type Value struct {
scalar uint64
iface int
I agree that it's very sensible this way! My confusion stemmed for a
combination of blind spots in both Go and C (in fact it was somewhere in my
head that the File API provided unbuffered access, just not accessible at
that time!). Thanks all for clarifying.
Arnaud
On Monday, 21 December 202
@Ben interesting, I did something similar and also ended up with a 64KB
buffer (seemed like the default of 4KB didn't work very well in my
context). How did you decide of the buffer size?
Also, there is something that I don't understand. The default buffer size
works really well for a toy exa
28 matches
Mail list logo
