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:
> 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
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
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
> 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
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
>
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?
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
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
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
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
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
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
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
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
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
So, for what it's worth:
https://karthikkaranth.me/blog/functions-implementing-interfaces-in-go/
Otherwise, yeah. I'd love to be able to define interfaces with extra
methods for implementors, but if you arrange your code around "traits",
microstructs intended to present a possibly unergonomic
Uh, you should check the code:
github.com/jackc/pgtype/blob/master/float8.go If you know what you have and
what you're dealing with, and if you actually check the error result, you
do get safety. If you don't know what you've got, or if you're iterating
through the values, then you end up
18 matches
Mail list logo
