Hi, all.
In my not painless transition from GOPATH to modules, I would like to
understand why import paths without a version are not equal to 'latest',
which is what happens in many other contexts: no version specified, use
latest. There is kind of a discontinuity now, where the namespace without
Brilliant!! Thanks Tamas, that worked perfectly.
On Tuesday, March 2, 2021 at 4:14:10 PM UTC-5 Tamás Gulácsi wrote:
> If I understand correctly, you receive "bodyBytes", store it in a file,
> and later want to serve it.
> Then a `w.Write(b)` would suffice.
> Or without reading the whole file int
Ah, I saw that thread, but I did not realize that it was the same issue.
Thank you.
On Tuesday, March 2, 2021 at 6:45:53 PM UTC-6 Ian Lance Taylor wrote:
> On Tue, Mar 2, 2021 at 4:43 PM Brett Kail wrote:
> >
> > It appears that the https://groups.google.com/g/golang-codereviews
> group is no
On Tue, Mar 2, 2021 at 4:43 PM Brett Kail wrote:
>
> It appears that the https://groups.google.com/g/golang-codereviews group is
> no longer being updated. Is that deliberate, or is something wrong?
Something is wrong: Gerrit is broken. See the thread at
https://groups.google.com/g/golang-dev/
It appears that the https://groups.google.com/g/golang-codereviews group is
no longer being updated. Is that deliberate, or is something wrong?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving em
If I understand correctly, you receive "bodyBytes", store it in a file, and
later want to serve it.
Then a `w.Write(b)` would suffice.
Or without reading the whole file into memory: `io.Copy(w, file)`.
hugh@gmail.com a következőt írta (2021. március 2., kedd, 14:12:22
UTC+1):
> Here is what
On Tue, Mar 2, 2021 at 9:37 AM Jad wrote:
>
> I'm new to Go and I would like to understand why the compilation process,
> both the compiler and linker, does raise an error for a declared but not used
> variable at funcs level in order to ensure clean code while the linker does
> not raise this
Many packages expose useful variables that are not being used themselves,
like useful defaults for example. I guess this would be an argument in
favor of limiting this kind of behaviour to inside the functions.
A good example is image/color/pallete.
Also, there is some shenanigans on estimating t
On Tue, Mar 2, 2021 at 5:49 AM Yan Titarenko
wrote:
>
> On Friday, February 26, 2021 at 5:50:44 PM UTC+2 Ian Lance Taylor wrote:
>>
>>
>> OK, but the reflect package generally does not allocate, so what is
>> the advantage of reflect2? Are there benchmarks showing where
>> reflect2 is significantl
Hi,
I'm new to Go and I would like to understand why the compilation process,
both the compiler and linker, does raise an error for a declared but not
used variable at funcs level in order to ensure clean code while the linker
does not raise this error during the build process for declared but
On Friday, February 26, 2021 at 5:50:44 PM UTC+2 Ian Lance Taylor wrote:
>
> OK, but the reflect package generally does not allocate, so what is
> the advantage of reflect2? Are there benchmarks showing where
> reflect2 is significantly faster?
The problem is in the fact that benchmarking of
sorry, the 4th setup reports "//go:embed only allowed in Go files that
import "embed"".
On Tuesday, March 2, 2021 at 8:38:05 AM UTC-5 tapi...@gmail.com wrote:
> > Maybe it shouldn't.
>
> By my knowledge, the version specified in go.mod doesn't prevent APIs
> newer than the version to be used. T
> Maybe it shouldn't.
By my knowledge, the version specified in go.mod doesn't prevent APIs newer
than the version to be used. This is design.
=
OK. It looks a Go project with version declared as 1.15 in go.mod and
importing "embed" also compiles okay with Go toolchain 1.16
So the key dist
Maybe it shouldn't.
FWIW, there is one significant difference, which is that `//go:embed` needs
support from the go tool and compiler to work. That is, the files need to
be read and we need to emit initialization code for the variables holding
the embedded files. So, a go toolchain that is not awa
What is the difference between "embed" and "io/fs"?
A Go project with version declared as 1.15 in go.mod and using "io/fs"
compiles okay with Go toolchain 1.16.
On Tuesday, March 2, 2021 at 7:50:15 AM UTC-5 axel.wa...@googlemail.com
wrote:
> Okay, sorry for the multiple, quick mails, but:
> I w
Here is what I have tried.
type product struct {
IDint `json:"id"`
Description string `json:"description"`
Price float64 `json:"price"`
Bin string `json:"bin"`
Qoh int `json:"qoh"`
}
// * function to save data to a file *//
func saveBackup(w http.ResponseWriter, r *h
Okay, sorry for the multiple, quick mails, but:
I would even say it *has* to be done the way it is. Because otherwise
compilation will *not* fail, if you declare a wrong go version to use. That
is, if you use `//go:embed`, declare your used version as go 1.15 and test
it yourself using go 1.16, you
Sorry, I have to walk that back - my test code was wrong, you are correct,
compilation fails.
The point still stands - they require 1.16, so they set that, not 1.15.
Either way - compilation will fail, why does it matter if it fails because
`embed` doesn't exist before 1.16, or whether it fails bec
There would be no advantage to that - all features are either available, or
not available, depending on which version you use. There is no "go 1.16
without `embed`". It also needs to be set in `go.mod`, because you might
compile modules written for different go versions into one binary - so
which l
BTW, I think the embedding functionality introduced in Go 1.16 should not
be viewed as a feature.
It should be viewed as an API change instead.
Now Go projects using embedding and setting go directive verison as v1.15
in go.mod fail to compile with Go toolchain 1.16.
IMO, this is unnecessary, for
Would be better to use compile flags to control each language features
individually?
--
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...@goog
21 matches
Mail list logo
