These programs compile and work according to my reading of the spec, but I
found them surprising.
https://go.dev/play/p/EUZ_28jge1N
https://go.dev/play/p/NMhR1Nq1COw
According to the spec it seems like it is legal to shadow a type with a
variable, even a builtin type.
Is there any specific ration
Hey Mariappan,
>From my experience, there are several possible options:
I believe you can use GOTRACEBACK=crash env variable (or its equivalent in
the runtime/debug package in the std) to get a coredump on the crash. See
this old post from JBD [1], that explored this.
If you clearly observe, t
The rationale, I understand, is that it helps with the Go compatibility
promise: when new types / constants / functions are added to the language,
they don't break existing code.
On Friday, 13 January 2023 at 10:22:46 UTC paurea wrote:
> These programs compile and work according to my reading o
Hi,
I'm having same or similar issue here.
Did anyone get to the root cause ot the problem here?
I'm using exec.Command to start external process. On Windows 10 and 11 it
runs quickly (under 1 second), but on Windows 7 (without SP1) it takes
about 9 seconds to start external exe or script. It
I haven't made a bootstrapped Go toolchain so I can't help with that but I
can provide the following information:
ESXi knows how to run ELF binaries, the interesting part then becomes what
architecture of CPU do you have the ESXi server installed on. If it's x86
or any other architecture that t
> On Jan 13, 2023, at 1:32 AM, Anthony Brown wrote:
>
> I haven't made a bootstrapped Go toolchain so I can't help with that but I
> can provide the following information:
>
> ESXi knows how to run ELF binaries, the interesting part then becomes what
> architecture of CPU do you have the ESXi
func main() {
fs := FileServerWith404(http.Dir("my_static_files"))
http.Handle("/", http.StripPrefix("/", fs))
http.ListenAndServe(":3000")
}
func FileServerWith404(root http.FileSystem) http.Handler {
fs := http.FileServer(root)
return http.HandlerFunc(func(w http.ResponseWrit
I think the difference is that I didn't actually do the compilation on the
ESXi host itself, I just ran the binary there.
'go run hello.go' on the ESXi host will, attempt, to both compile and
execute the compiled binary; I'm guessing the ESXi host itself though
doesn't have some of the same sh
