Hi all,
writing a stress test case for one of my apps I noticed a very strange
thing: my test case works well on go 1.14 but it doesn't work on go 1.13.
I wrote a minimal reproducer
https://play.golang.org/p/uHkKMINncUB
to make it work on go 1.13 I have to add the sleep at line 41. In Go
play
2.6.23, for most architectures, as far as I know.
On Sat, Jul 25, 2020 at 8:31 AM xie cui wrote:
> what is the minimum version of linux kernel that can run golang?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this
When running this program:
package main
import (
"fmt"
)
type Foo struct {
i int
}
func main() {
var f1 = &Foo{i: 0}
var f2 = &(*f1)
f2.i = 1
fmt.Println(f1, f2)
}
it yields:
&{1} &{1}
(https://play.golang.org/p/qKtURokUCEW)
I (naively) assumed that the expression
&(*f1)
would, first, c
On Sat, 2020-07-25 at 01:09 -0700, chri...@surlykke.dk wrote:
> &(*f1)
>
> would, first, create a copy of *f1, and then a pointer to that copy,
> but evidently f2 becomes a pointer to the same struct as f1. Is this
> something I should have deduced from the language spec?
&(*p) says "give me the
You are probably thinking about code like this:
var f2 = *f1
Which will make a copy, although not because `f1` is dereferenced, but
because `=` was called on a value.
Dereferencing a pointer gives a reference to the same value, taking
address of the same value will produce a pointer to the same
On Sat, Jul 25, 2020 at 10:09 AM chri...@surlykke.dk
wrote:
> Is this something I should have deduced from the language spec?
https://golang.org/ref/spec#Address_operators
For an operand x of type T, the address operation &x generates a
pointer of type *T to x. The operand must be addressa
I am not certain but the reason probably is the change to go-routine
preemption in 1.14. From https://golang.org/doc/go1.14#runtime
…
Goroutines are now asynchronously preemptible. As a result, loops
without function calls no longer potentially deadlock the scheduler or
significantly delay gar
This is probably due to improvements in preemption.
Garbage collectors often need some linearizable checkpoint (or an atomic
commit point) where every CPU core agrees on a state. For instance,
enabling a write barrier on the heap.
Back in the day, this was achieved on communication via channels,
What's in your "main.go" ?
--
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...@googlegroups.com.
To view this discussion on the web visit
htt
Cool.
go1.15rc1 gives a 8% speedup on my tests.
On Friday, 24 July 2020 20:21:50 UTC+1, Alexander Rakoczy wrote:
>
> Hello gophers,
>
> We have just released go1.15rc1, a release candidate version of Go 1.15.
> It is cut from release-branch.go1.15 at the revision tagged go1.15rc1.
>
> Please tr
Hi,
I need to consume a stream of json objects.
But unfortunately the json objects are separated by commas.
Is there any simple way I can convince the json.Decorder to skip the comma
after each successful call to decode?
My code looks like
for {
var a st
err := dec.Decode(&a)
if err == io.EOF
Aha, I see. Thanks for explaining.
br. Chr.
lørdag den 25. juli 2020 kl. 10.56.35 UTC+2 skrev Jan Mercl:
> On Sat, Jul 25, 2020 at 10:09 AM chri...@surlykke.dk
> wrote:
>
> > Is this something I should have deduced from the language spec?
>
> https://golang.org/ref/spec#Address_operators
>
> ""
On Friday, July 24, 2020 at 1:08:06 PM UTC-4, Tong Sun wrote:
>
> Hi,
>
> How to get around the following, go module @latest found but does not
> contain package?
>
> $ cd /tmp/015-file
>
> $ GO111MODULE=on
>
> $ go mod init github.com/mkideal/cli/015-file
> go: creating new go.mod: module git
On Sat, Jul 25, 2020 at 6:09 AM Amnon wrote:
>
> Hi,
>
> I need to consume a stream of json objects.
> But unfortunately the json objects are separated by commas.
>
> Is there any simple way I can convince the json.Decorder to skip the comma
> after each successful call to decode?
You have to re
Awesome, thanks!
On Sat, Jul 25, 2020 at 3:50 PM burak serdar wrote:
> On Sat, Jul 25, 2020 at 6:09 AM Amnon wrote:
> >
> > Hi,
> >
> > I need to consume a stream of json objects.
> > But unfortunately the json objects are separated by commas.
> >
> > Is there any simple way I can convince the
Presumably the instantiation of generic types and functions will be a lot
more common than the declarations. How does your proposal handle those?
(FWIW, I'm fine with square brackets, or really anything other than parens.)
On Monday, July 20, 2020 at 12:42:13 PM UTC-4 Geoff Speicher wrote:
> Th
Works fine for me. Inside an empty directory:
$ wget
https://raw.githubusercontent.com/mkideal/cli/master/_examples/015-file/main.go
$ go mod init github.com/mkideal/cli/015-file
go: creating new go.mod: module github.com/mkideal/cli/015-file
$ go build
go: finding module for package github.com/
See the list in https://golang.org/doc/install
On Saturday, July 25, 2020 at 1:31:07 AM UTC-4 cuiw...@gmail.com wrote:
> what is the minimum version of linux kernel that can run golang?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubsc
Thanks a lot Brian!
I upgraded to go version go1.14.3 linux/amd64 in Ubuntu 20.04 LTS and now
the problem is gone. thx!
On Saturday, July 25, 2020 at 12:25:15 PM UTC-4, Brian Candler wrote:
>
> Works fine for me. Inside an empty directory:
>
> $ wget
> https://raw.githubusercontent.com/mkideal
I just discovered the experiment to make the "type" keyword optional in
certain cases on the dev.go2go branch. The commit message says:
---
Experiment: Make "type" keyword optional in generic type declarations
when
it is clear that we can't have an array type declaration. This is the
ca
To expand on my post:
It would be very consistent with the structure of regular parameter lists.
Just like every parameter in a regular parameter list must have a type
(with the exception of multiple consecutive parameters having the same
type), every type parameter in a type parameter list must
I have own issue my whole project follow relative schema (./db) , but I
want like this .
import (
github.com/username/projecr-name,package-name).
How ???
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To un
On Sat, Jul 25, 2020 at 11:47 AM 'Carla Pfaff' via golang-nuts
wrote:
>
> To expand on my post:
> It would be very consistent with the structure of regular parameter lists.
> Just like every parameter in a regular parameter list must have a type (with
> the exception of multiple consecutive para
I know it's common to have no constraints, but "[Elem any]" is even one
character shorter than "[type Elem]". I rewrote the function signatures
from slices.go2 in this way, and it doesn't feel painful. This already
works on the go2go playground: https://go2goplay.golang.org/p/IQV5LTAIuDr
On Sat
There's already a precedent of a builtin type alias in Go with "type rune =
int32" https://golang.org/pkg/builtin/#rune and "any" would make many
regular parameter lists shorter as well.
On Saturday, 25 July 2020 at 22:37:39 UTC+2 Carla Pfaff wrote:
> I know it's common to have no constraints,
I like it!
BTW, I don't understand the meaning of this comment in the commit log:
> >> Experiment: Make "type" keyword optional in generic type declarations when
> >> it is clear that we can't have an array type declaration.
It is talking about defining generic arrays, where one parameter may b
On Saturday, 25 July 2020 at 22:22:24 UTC+2 Ian Lance Taylor wrote:
> Note that in this way constraints on type parameters are different
> from types of regular parameters. It makes no sense to speak of a
> regular parameter with no type.
>
In regular parameter lists interface{} has this role,
I look at what Carla did write and it feels ... good. I don't know, it may
be not for everyone, but for me [T any] looks cleaner than [type T].
Probably I see `[` and understand this is generic params, then `T` and I
immediately understand this is how the generic type denoted. A final touch,
I
Great catch! I would say I really like it!
суббота, 25 июля 2020 г. в 23:37:39 UTC+3, Carla Pfaff:
> I know it's common to have no constraints, but "[Elem any]" is even one
> character shorter than "[type Elem]". I rewrote the function signatures
> from slices.go2 in this way, and it doesn't f
Btw, it `any` suffix can be a part of grammar, I mean something like
*GenericParam = Lit [',' Lit]* 'any' | Lit [',' Lit]* Ident*
where *any* can be replaced with an actual *any* if there's one in a scope.
воскресенье, 26 июля 2020 г. в 00:47:17 UTC+3, Denis Cheremisov:
> Great catch! I would
I too think that T any is more readable than the overloaded type in type T
especially if it means that I won’t have to remember when it’s Ok to drop
type and when it’s not
On Saturday, July 25, 2020 at 4:47:17 PM UTC-5 Denis Cheremisov wrote:
> Great catch! I would say I really like it!
>
> суб
I don't see why it should be in the grammar. Just a regular type alias for
interface{} in the builtin scope, a regular predeclared identifier. It
wouldn't break anyone's code. If someone already has an 'any' type or
variable in their package their version shadows the builtin one, and they
can s
Hi folks. I was unable to find a good answer online already. The closest
I found was
https://stackoverflow.com/questions/14323872/using-forked-package-import-in-go
which
suggests using the replace directive in go.mod.
I am using Go 1.14, with all projects located outside of GOPATH.
My exact
As soon as I understand you can just keep their module name in `go.mod` and
that's it.
воскресенье, 26 июля 2020 г. в 03:46:15 UTC+3, brad.be...@gmail.com:
> Hi folks. I was unable to find a good answer online already. The closest
> I found was
> https://stackoverflow.com/questions/14323872
I actually mean something different. The bad with *any* in builtins is
there will be questions "why you use interface{}" if there's builtin *any?*",
etc. I mean these will be different AST nodes, there will be
*type GenericAny struct {*
*Name *ast.Lit*
*}*
and
*type Generic struct {*
*
Thank you very much! I have no idea why I thought I needed to change
go.mod.
I did run into some strange effects changing my local version back to
"sclevine" though - I also needed to remove the cached versions in *go/pkg*.
Thanks again!
Brad
On Sunday, 26 July 2020 at 13:03:22 UTC+12 Denis
On Sunday, 26 July 2020 at 03:13:30 UTC+2 Denis Cheremisov wrote:
> The bad with *any* in builtins is there will be questions "why you use
> interface{}" if there's builtin *any?*", etc.
If Go has generics I expect that people will use "interface{}"/"any" a lot
less outside of type parameter l
On Sunday, 26 July 2020 at 07:06:16 UTC+2 Carla Pfaff wrote:
> Maybe gofmt could rewrite "interface{}" to "any", so there won't even be
> such a question for new code.
>
When I think about it, that's probably not possible for gofmt to do in a
safe way.
--
You received this message because yo
38 matches
Mail list logo
