On Mon, Mar 29, 2021 at 12:15 PM Reto wrote:
>
> On Mon, Mar 29, 2021 at 11:18:28AM +1100, Amit Saha wrote:
> > "Module-aware mode is enabled by default, regardless of whether a
> > go.mod file is present in the current working directory or a parent
> > directory. More precisely, the GO111MODULE
On Mon, Mar 29, 2021 at 11:18:28AM +1100, Amit Saha wrote:
> "Module-aware mode is enabled by default, regardless of whether a
> go.mod file is present in the current working directory or a parent
> directory. More precisely, the GO111MODULE environment variable now
> defaults to on. To switch to
Hi Folks,
I just realized that with Go 1.16, you must create a module via go mod
init, even if you are writing a simple hello world program.
The most surprising aspect to me was that I can only know that's the
case if I don't have a go.mod file anywhere in the parent directory
chain. It becomes
I've tried this suggestion and although its certainly a bit more
refactoring then I expected - the outcome looks to be exactly as you
described here.
Thank you so much for the suggestion, take a bow!
- Greg
On Sunday, March 28, 2021 at 12:15:34 PM UTC-7 Brian Candler wrote:
> No, it's even
The interesting thing furthermore is that it seems like the
pkg/go/parser/parser.go has been around since Go 1.0 whereas the
cmd/compile/internal was introduced in 1.6 when they translated the yacc
parser to handwritten Go.
https://go-review.googlesource.com/c/go/+/16665/
On Saturday, March
No, it's even simpler than that:
* The first call to decoder.Decode() will return the first object in the
stream.
* The second call to decoder.Decode() will return the second object in the
stream.
* And so on...
By "object" I mean top-level object: everything between the opening "{" and
its
The inner blob is expecting an io.Reader. But, perhaps I can change that
to pass a Decoder based on what you are saying. For some reason I hadn't
grokked that is how Decoder was working. Just to re-iterate what I think
you are saying (and in case anyone stumbles across this thread later),
On Sun, Mar 28, 2021 at 9:28 AM 张嘉熙 wrote:
>
> For s2-geojson, I meet:
> ```
> # github.com/pantrif/s2-geojson/cmd/s2-geojson
> /home/jx/.cache/go-build/6b/6bd003c99eb0a9e7c6ea6d372307b292ec615c75c28f9b1f696896ae2fb4272b-d(_go_.o):gomodule:function
>
I made a issue at github, and the details are as followed:
### What version of Go are you using (`go version`)?
$ go version
go version go1.16 gollvm LLVM 13.0.0git linux/amd64
### Does this issue reproduce with the latest release?
yes
### What operating system and processor architecture
Thank you! I completely missed the memo on fstest :)
On Sunday, March 28, 2021 at 6:31:24 AM UTC-4 manlio@gmail.com wrote:
> For a project I wrote a simplified MapFS, where only the file data needs
> to be specified, as a string:
>
Assuming a recent enough version of `godoc`, running it from within a
module should include the documentation for the standard library (standard
library section), that module, and all its dependencies (third party
section)
Expected output should be similar to:
$ godoc
using module mode;
jerome - not sure that the code you provided fully answers the OP's
problem. I think you'd need to craft an http request and get a response to
really KNOW that the server is indeed responding. If you do that as a
replacement for where you have the "select {}" then I think you've got it.
Clarification. As mentioned earlier, $GOPATH is supposed to go away in the
(possibly near) future so one of my main goals is to get it working outside
the $GOPATH tree. At present my solution has been to copy my source tree
(about 4 GB) to a "non-module-aware" go ecosystem on a different
I found you had to cd to each directory with a .mod file and run it there.
A global option would be nice to know about.
--
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
For a project I wrote a simplified MapFS, where only the file data needs to
be specified, as a string:
https://gist.github.com/perillo/45dfe7eb1c87e2d436574cab0d11221c
Manlio
Il giorno domenica 28 marzo 2021 alle 10:06:21 UTC+2 seank...@gmail.com ha
scritto:
>
> This works, but the downside is that each {...} of bytes has to be pulled
into memory. And the functions that is called is already designed to
receive an io.Reader and parse the VERY large inner blob in an efficient
manner.
Is the inner blob decoder actually using a json.Decoder, as shown
https://pkg.go.dev/testing/fstest ?
On Sunday, March 28, 2021 at 5:09:12 AM UTC+2 aind...@gmail.com wrote:
> For testing library functions that accept fs.FS, I've been creating mock
> FS implementations. However, I'm surprised by the amount of code I've had
> to write for something like an FS
17 matches
Mail list logo
