Oh wait, looks like it's public: https://github.com/golang/playground
On Wednesday, April 6, 2022 at 3:32:11 PM UTC+12 ben...@gmail.com wrote:
> Sure, report an issue against the playground. I honestly have no idea
>> how difficult this would be to fix.
>>
>
> Thanks, done: https://github.com/g
> Sure, report an issue against the playground. I honestly have no idea
> how difficult this would be to fix.
>
Thanks, done: https://github.com/golang/go/issues/52176
The source for the Playground is private, correct?
-Ben
--
You received this message because you are subscribed to the Goo
On Tue, Apr 5, 2022 at 6:50 PM ben...@gmail.com wrote:
>
>> The playground isn't intended to be an exact replica of running a
>> program on a real machine. If the program uses too many resources it
>> will simply be stopped.
>
>
> Both fair enough. But surely the runner can distinguish when the pr
On Tue, Apr 5, 2022 at 6:18 PM ben...@gmail.com wrote:
> Normally the Go Playground gives errors when a runtime panic or other
> error occurs, including "timeout running program" for programs that run too
> long. I'm wondering why the Playground doesn't show a stack overflow error
> (or any error
> The playground isn't intended to be an exact replica of running a
> program on a real machine. If the program uses too many resources it
> will simply be stopped.
>
Both fair enough. But surely the runner can distinguish when the program
ran successfully to completion versus when it was st
On Tue, Apr 5, 2022 at 6:18 PM ben...@gmail.com wrote:
>
> Normally the Go Playground gives errors when a runtime panic or other error
> occurs, including "timeout running program" for programs that run too long.
> I'm wondering why the Playground doesn't show a stack overflow error (or any
> e
Normally the Go Playground gives errors when a runtime panic or other error
occurs, including "timeout running program" for programs that run too long.
I'm wondering why the Playground doesn't show a stack overflow error (or
any error) for this infinitely-recursing program?
https://go.dev/play/
On Tue, Apr 5, 2022 at 5:05 PM c.maglie wrote:
>
> Il 05/04/22 19:09, Ian Lance Taylor ha scritto:
> > It works fine for me either way, on Linux kernel 5.15.15. What system
> > are you running on? What version of Go? What version of
> > golang.org/x/sys/unix?
>
> Well, I tried it only on the pl
I get what you're saying, and for what it's worth, you're absolutely
correct. Something like above is a set of tradeoffs, and I guess all I can
assert is that it works for me. I do think it's a good design, given Go's
lack of a None type to enforce well-defined behavior on a nil pointer
derefer
Il 05/04/22 19:09, Ian Lance Taylor ha scritto:
> It works fine for me either way, on Linux kernel 5.15.15. What system
> are you running on? What version of Go? What version of
> golang.org/x/sys/unix?
Well, I tried it only on the playgound because it seems to reproduce the
bug there, so I di
On Tue, Apr 5, 2022 at 11:05 AM Amit Lavon wrote:
>
> When we use an interface as a type parameter, does it mean that calls to that
> interface will be replaced with calls to the concrete type?
>
> To demonstrate, consider https://go.dev/play/p/j4N8G_n-3uG .
> Will the compiler create a static ca
Hi gophers,
When we use an interface as a type parameter, does it mean that calls to
that interface will be replaced with calls to the concrete type?
To demonstrate, consider https://go.dev/play/p/j4N8G_n-3uG .
Will the compiler create a static call to MyDoer.Do instead of a virtual
call to Doe
On Tue, Apr 5, 2022 at 10:00 AM c.maglie wrote:
>
> I'm facing an issue that looks like a deadlock, but that I can't
> actually figure out. After some investigation I can reproduce a similar
> problem with the following code:
>
> https://go.dev/play/p/ZB05nweJJX_9
>
> Running the example above as-
Hi,
I'm facing an issue that looks like a deadlock, but that I can't
actually figure out. After some investigation I can reproduce a similar
problem with the following code:
https://go.dev/play/p/ZB05nweJJX_9
Running the example above as-is will show the expected output, but after
uncomment
I did look at the code briefly. The main thing I noticed was that the
return type of float8.Get() was an interface{} - so it's up to the caller
to check at runtime whether the value is nil, a float64, or a Status.
So you're right, it's not that they are compile-time unsafe, but rather
that you
Hi,
I have a local package Z under X/Y folder
So, to use the local package Z, I changed in the go.mod of the other
package which wants to use it.
replace X/Y/Z => ../Z
After that if I run go mod tidy.
This should ideally create an entry in requires with X/Y/Z
v0.0.0-0001010100-000
16 matches
Mail list logo
