Re: [go-nuts] Why isn't there "number plus" postfix syntax for more than or equal?
I look forward to the addition of the definition of "in a handwavy
sense" to the spec.
On Thu, 2020-04-23 at 11:41 -0700, Michael Jones wrote:
> You could extend the notation:
>
> If r 13+- {
> // if r is close to 13, in a handwavy sense
> :
> }
>
> On Thu, Apr 23, 2020 at 9:43 AM Ian Lance Taylor
> wrote:
> > On Thu, Apr 23, 2020 at 8:48 AM anon notmyfault64 <
> > bagasdo...@gmail.com> wrote:
> > >
> > > Many times outside programming we use "number plus" postfix
> > syntax to denote more than or equal, for example:
> > >
> > > a 99+
> > >
> > > But why isn't there such syntax above in all programming
> > languages, including Go? That is, why does following code not
> > compile with invalid syntax error?
> > >
> > > var r int = 18
> > >
> > > if r 13+ {
> > > fmt.Println("Hooray! We are teen! We can do anything!")
> > > } else {
> > > fmt.Println("Oh No! We are still child, so we need parental
> > control!")
> > > }
> >
> > I don't see the advantage over writing r >= 13.
> >
> > It's not useful for a programming language to have multiple ways of
> > writing the exact same thing. Of course, any language does have
> > multiple ways of doing some things, but there is should always be a
> > reason for it. I don't see a reason for this one.
> >
> > For what it's worth, I'm not familiar with the "a 99+" notation. I
> > would not know what that meant without an explanation.
> >
> > Ian
> >
--
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
https://groups.google.com/d/msgid/golang-nuts/dd0eb4cfb15efb25b2ea374ace24a3268df2ebc5.camel%40kortschak.io.
Re: [go-nuts] Should an assignment from int to a type based on int succeed?
In https://golang.org/ref/spec#Types a Type is defined in terms of a
TypeName a TypeLit or a (Type). A TypeName is what makes a type a named
type. This is defined as either an identifier or a qualified
identifier. For the discussion here we can ignore the latter. An
identifier contains letters and unicode digits and must start with a
letter. From this we can see that an, e.g., int is a named type. The
alternative is a TypeLit, which is marked with a variety of keywords or
type punctuation (*, [] and [n]), these are unnamed types.
On Sat, 2020-05-09 at 12:51 +0200, 'Axel Wagner' via golang-nuts wrote:
> > Every name that represents a type and does not stand for a type
> > alias
> > is a defined, formerly named type. The essence is in the existence
> > of
> > the name for the type. If it's declared in user code of magically
> > by
> > the compiler does not matter.
>
>
> Can you tell me where the spec says any of this? This thread isn't
> "please help me understand how the language works", it's "does the
> spec accurately and unambiguously define how the language works". So
> what you say may very well be true, but unless you can show how it
> arises from the spec, I don't really see what it's contributing.
>
> And, FTR, the essence is certainly not the existence of the name -
> otherwise you wouldn't have to explicitly exclude type aliases. Just
> to show that waving hands at the question isn't really useful.
>
> > I suspect what has happened here is that it formerly said "named
> > type" in which case it would have been much clearer.
> > […]
> > Again, when it said "named types", that problem would not have
> > existed: it's clear that the type "int" has the name "int".
>
> To re-iterate: Before type-aliases, this was true. But today, the
> current discussion is created by an ambiguity between "a defined
> type" and "a type which has a definition" and replacing that with the
> ambiguity between "a named type" and "a type which has a name" isn't
> clearer - a type alias is a name for a type.
>
> > I don't think that implies there is a specific class of type which
> > is a "predeclared type",
>
> The spec does have the specific notion of a predeclared identifier,
> and `error` is one of them. This doesn't contradict anything you say,
> I just wanted to point out that I don't think the use of "the
> predeclared type" is ambiguous in its meaning here - "predeclared" as
> an adjective has a language-level meaning. "defined" as an adjective
> has 1. a colloquial meaning and 2. a language-level meaning, but only
> when preceding "type".
>
> > Therefore, I don't think this contradicts the earlier definition of
> > "defined type", and by that definition, I conclude that "error" is
> > a "defined type".
>
> I don't understand this argument. The question is if it *matches* a
> definition, not if it specifically contradicts it. If you want to
> know if ℤ is a Ring, you don't say "nothing about the definition of ℤ
> says it's not a Ring, therefore I conclude it is a Ring" - you look
> up the definition for being a Ring and prove that ℤ matches it.
>
> > I suppose it could instead say "The predefined type error...", but
> > that would also be confusing because it's not the fact that it's a
> > "defined type" that matters, it's the fact that it has been
> > declared and is available in all scopes.
>
> No, it is specifically not. What matters is if it is a "defined type"
> - which is a specific term in the spec used to ascribe special
> behavior to some types but not others. That's also why it wouldn't
> help if it said "predefined type" - this is not the term used in the
> spec to determine (for example) type identity and assignability.
>
> To take a page out of Hilbert's book: We should be able to say
> "Chair" instead of "type-definition" and "Bierseidel" instead of
> "defined type" and still get a perfectly consistent spec. It's just a
> name. That would then remove any ambiguity when using the word
> "define" in a sentence and it would prevent any confusion of semantic
> overlap with "predeclared". And for the most part, you *can* do this
> replacement. You can then ask if error was a Bierseidel under this
> replacement. It can be argued it would be, at the end of the day,
> because the section would read "The predeclared type error is defined
> as `type error interface { Error() string }`" - so its definition
> would still be a Chair, which definitionally creates Bierseidels. I
> still feel it might be cleaner, to not rely on this argument and just
> explicitly add "`error` is a Bierseidel" as well.
>
> Of course, the last paragraph reads ridiculously - at the end of the
> day, names matter, so we absolutely should use speaking names with
> intuitive understanding such as "defined type" and "type-definition".
> But once you *can* do the replacement without loss of information,
> you have at least avoided all confusion between the colloquial verb
> "define" and the specific language-level construct
Re: [go-nuts] Should an assignment from int to a type based on int succeed?
Yes, sorry. Eight years of habit is hard to break. I think I agree with you; a small bit of text in https://golang.org/ref/spec#Type_definitions linking to https://golang.org/ref/spec#Predeclared_identifiers and saying that there exist already defined types may ease this, or the suggestion you have of making the word "defined" linked to defined types in https://golang.org/ref/spec#Errors (or both). On Sat, 2020-05-09 at 18:49 +0200, 'Axel Wagner' via golang-nuts wrote: > I don't know why you are talking about "named type". The nomenclature > is outdated and obsoleted by "defined type". The only reason I see to > still use it is so you can make an argument that "it has a name" > means "it's a defined type" - which isn't even a correct argument > anymore since type aliases can give non-defined types names. That's > the entire reason the term was abandoned. > The section you point to *is* however still relevant - that's why I > quoted it myself in my first message. It *does* contain one > definition of what a "defined type" is, by saying that a type > definition creates one. -- 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 https://groups.google.com/d/msgid/golang-nuts/c6a3e2fecd9487dbde0bb75b92841a756e7c5c8d.camel%40kortschak.io.
Re: [go-nuts] Nondeterministic Behavior of for Loop Ranging Over a map
On Tue, 2020-05-26 at 16:26 +1000, Jesse McNelis wrote: > On Tue, May 26, 2020 at 3:37 PM Paul Jolly wrote: > > > Why the output of this code is nondeterministic? > > > > See https://golang.org/ref/spec#For_statements, specifically the > > "For > > statements with range clause" subheading, specifically this bullet: > > > > > 3. The iteration order over maps is not specified and is not > > guaranteed to be the same from one iteration to the next. If a map > > entry that has not yet been reached is removed during iteration, > > the corresponding iteration value will not be produced. If a map > > entry is created during iteration, that entry may be produced > > during the iteration or may be skipped. The choice may vary for > > each entry created and from one iteration to the next. If the map > > is nil, the number of iterations is 0. > > The implementation actually intentionally makes the iteration order > more varied to avoid people relying on any particular ordering. So > much so that some people started relying on the order to be > random > Also to prevent algorithmic complexity attacks like this http://ocert.org/advisories/ocert-2011-003.html -- 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 https://groups.google.com/d/msgid/golang-nuts/8f413dc6a93c6ab50c1c6be9da00668400fde6a1.camel%40kortschak.io.
Re: [go-nuts] net.go ok function's c != nil check right ?
It's perfectly valid to call a method on a nil receiver, so long at the
nil receiver is not dereferenced.
https://play.golang.org/p/Z-zXlj0-eVy
On Wed, 2020-06-03 at 00:03 -0700, apmat...@gmail.com wrote:
> Read function at net.go is like this:
>
> func (c *conn) Read(b []byte) (int, error) {
> if !c.ok() {
>
> the ok checks that c is non nil:
> func (c *conn) ok() bool { return c != nil && c.fd != nil }
>
> how can c ever be nil ? if it would c.ok() call would crash.
--
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
https://groups.google.com/d/msgid/golang-nuts/8b5522ffb67d8c50863f0c80582935a053be9bd1.camel%40kortschak.io.
Re: [go-nuts] compress/bzip2：Why is there only a decompression function, no compression function.
Also see https://godoc.org/github.com/dsnet/compress/bzip2 and https://github.com/dsnet/compress/issues/58 On Mon, 2020-06-08 at 13:14 -0400, Sam Whited wrote: > See: https://github.com/golang/go/issues/4828 > > On Mon, Jun 8, 2020, at 05:09, lziqia...@gmail.com wrote: > > Why is there no bzip2 compression algorithm, what is the reason? Do > > you > > need to add it? > > —Sam > > -- > 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 > https://groups.google.com/d/msgid/golang-nuts/4e2007ea-0215-41d3-afdc-1f77330dbdbd%40www.fastmail.com > . -- 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 https://groups.google.com/d/msgid/golang-nuts/5a1ffa8d857867b33da30dc7fca426e4712d2fcc.camel%40kortschak.io.
Re: [go-nuts] compress/bzip2：Why is there only a decompression function, no compression function.
bzip2 compression is not trivial so making sure the review catches any issues will take time. Finding people with the relevant expertise and the time to do the review is not necessarily easy. Note that you can use the dsnet package. On Mon, 2020-06-08 at 18:55 -0700, lziqia...@gmail.com wrote: > > It seems that this issue was discussed long ago, but why is it not > compressed because of the lack of reviewers? Why has this code called > Joe Tsai never been merged? Does anyone have an official explanation? > I don't understand too much. > 在 2020年6月9日星期二 UTC+8上午5:30:34，kortschak写道： > > Also see https://godoc.org/github.com/dsnet/compress/bzip2 and > > https://github.com/dsnet/compress/issues/58 > > > > On Mon, 2020-06-08 at 13:14 -0400, Sam Whited wrote: > > > See: https://github.com/golang/go/issues/4828 > > > > > > On Mon, Jun 8, 2020, at 05:09, lziq...@gmail.com wrote: > > > > Why is there no bzip2 compression algorithm, what is the > > reason? Do > > > > you > > > > need to add it? > > > > > > —Sam > > > > > > -- > > > 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 golan...@googlegroups.com. > > > To view this discussion on the web visit > > > > > https://groups.google.com/d/msgid/golang-nuts/4e2007ea-0215-41d3-afdc-1f77330dbdbd%40www.fastmail.com > > > > > . > > > > > > -- > 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 > https://groups.google.com/d/msgid/golang-nuts/d1ee336c-5ba7-4a60-9dc3-48f9d3141704o%40googlegroups.com > . -- 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 https://groups.google.com/d/msgid/golang-nuts/9d35d55b58ac5b5c77e8290a2ad7319144535034.camel%40kortschak.io.
Re: [go-nuts] political fundraising on golang.org!
In the context of a sufficiently large collection of people all actions are political to some degree, *including inaction and non-comment*. Where the boundary is for the degree on what constitutes a political action and what doesn't varies between people. On Sun, 2020-06-14 at 16:44 -0400, Eric S. Raymond wrote: > Sam Whited : > > This is not a simple political issue, it is a personal human issue. > > It > > is a social issue. It is a justice issue. > > It is the injection of politics into a list where politics does not > belong. > > Kindly perform your virtue signalling elsewhere. -- 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 https://groups.google.com/d/msgid/golang-nuts/d396661a24dd31c0f97842cd69dd939437bf2e4c.camel%40kortschak.io.
Re: [go-nuts] Re: pure-go implementation of sqlite
This is at https://modernc.org/sqlite now, along with the rest of Jan's amazing things, https://gitlab.com/cznic. On Tue, 2020-06-16 at 12:27 -0700, Mandolyte wrote: > SQLite3 support is the stated goal of > https://github.com/elliotchance/c2go > > Also, I believe I tested this one a long time ago... but have lost > track of it after they moved away from Github: > https://github.com/cznic/sqlite > > > > On Monday, June 15, 2020 at 12:57:54 PM UTC-4, Douglas Manley wrote: > > No, unfortunately this just replaces the need for gcc for SQLite3 > > with the need for gcc for Sqinn. My goal is to have a SQL database > > for use in Go that is 100% pure Go with zero outside dependencies. > > My primary use case is for unit-testing large applications that > > rely on SQL databases such that no one on the project has to do > > anything other than install Go to build and test them. > > > > On Monday, June 15, 2020 at 12:31:07 PM UTC-4 cvilsmeier wrote: > > > Maybe Sqinn-Go can help you: > > > https://github.com/cvilsmeier/sqinn-go > > > (I'm the author of it) > > > > > -- > 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 > https://groups.google.com/d/msgid/golang-nuts/2c533170-33b5-4eb5-9f58-25c88f34710fo%40googlegroups.com > . > -- 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 https://groups.google.com/d/msgid/golang-nuts/8feafd170a2269c12535927bc09f52fb51af66d5.camel%40kortschak.io.
[go-nuts] generics and absence of ability to specify correlated types
Since this has come up again in [1], I would like to re-raise the issue of being able to correlate float and complex types so that a func(float32) complex64/func(float64) complex128-like function can be written generically. This issue was raised in [2] in the last round of generics discussions with the example now in [3] and [4]. This wasn't addressed last time, and it does not appear to be addressed in the current document, although the Point method section comes sort of close[5] by doing essentially the same kind of conversion/constraint but with pointers, also the `ComplexAbs(type T Complex) T` type, however this does not handle both the cases below and achieves what it does in a heavier way. Dan [1] https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md [2]https://groups.google.com/d/msg/golang-dev/nug_hZnGQog/et4aKG6_DAAJ [3]https://go2goplay.golang.org/p/gdJNbVmLy8u [4]https://go2goplay.golang.org/p/Ak6q0CfUT7d [5] https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#pointer-methods -- 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 https://groups.google.com/d/msgid/golang-nuts/59e4349d3c0811462c153c4b5905d884b37e442e.camel%40kortschak.io.
Re: [go-nuts] generics and absence of ability to specify correlated types
With the multitude of answers for use of alternative syntaxes for specifying type parameter lists, is there a chance that this concern could be addressed? thanks Dan On Wed, 2020-06-17 at 11:24 +, 'Dan Kortschak' via golang-nuts wrote: > Since this has come up again in [1], I would like to re-raise the > issue > of being able to correlate float and complex types so that a > func(float32) complex64/func(float64) complex128-like function can be > written generically. This issue was raised in [2] in the last round > of > generics discussions with the example now in [3] and [4]. > > This wasn't addressed last time, and it does not appear to be > addressed > in the current document, although the Point method section comes sort > of close[5] by doing essentially the same kind of > conversion/constraint > but with pointers, also the `ComplexAbs(type T Complex) T` type, > however this does not handle both the cases below and achieves what > it > does in a heavier way. > > Dan > > [1] > https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md > [2] > https://groups.google.com/d/msg/golang-dev/nug_hZnGQog/et4aKG6_DAAJ > [3]https://go2goplay.golang.org/p/gdJNbVmLy8u > [4]https://go2goplay.golang.org/p/Ak6q0CfUT7d > [5] > https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#pointer-methods > > > -- > 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 > https://groups.google.com/d/msgid/golang-nuts/59e4349d3c0811462c153c4b5905d884b37e442e.camel%40kortschak.io > . -- 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 https://groups.google.com/d/msgid/golang-nuts/10381f7fa1b2aefe88ccf447a70eee17d6cc13bd.camel%40kortschak.io.
[go-nuts] go get with vanity import path and 404: fails
Yesterday we replaced the old gonum.org site with a new hugo build. This appears to have broken go get for clients that do not use proxy.golang.org or some other proxy that already has gonum.org/... cached (this includes gddo). ``` $ GOPROXY=direct go get gonum.org/v1/gonum go get gonum.org/v1/gonum: unrecognized import path "gonum.org/v1/gonum": reading https://gonum.org/v1/gonum?go-get=1: 404 Not Found ``` It was my understanding that go get should examine go get meta tags even if the page returns a 404 (though looking at our old site there is a static 404 page included to work around this it seems). Is this not correct? If it's not correct, what is the appropriate technique to provide this information to go get for pages that are not serving anything other than go get metadata? thanks Dan ref:https://github.com/gonum/website/issues/9 -- 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 https://groups.google.com/d/msgid/golang-nuts/8960443feccfbc8aac08fdb996263db7b9c2e426.camel%40kortschak.io.
Re: [go-nuts] Re: go get with vanity import path and 404: fails
Thanks to Tim and Eric Bajumpaa on slack. The issue was due to an error in minification where the quotes around the name attribute value are stripped. Turning off minification is an interim workaround while that is broken. Dan On Sat, 2020-06-20 at 18:10 -0700, Tim Heckman wrote: > Closing the loop on this. They reached out in the Gopher Slack and we > pieced it together: > > - https://gophers.slack.com/archives/C029RQSEE/p1592699134083700 > > It has to do with this section of code: > > - > https://github.com/golang/go/blob/60f78765022a59725121d3b800268adffe78bde3/src/cmd/go/internal/get/vcs.go#L804-L810 > > This chooses to swallow parsing errors if the HTTP response looks to > be invalid (bad status code), which is what's happening here. Another > user managed to find that the meta tags on the page look malformed: > > https://github.com/gonum/exp";>; > > Notice that go-import is missing quotes around it. I think fixing > those up should solve the issue here. There is a larger question as > to whether this code should return both, as it's hard to know which > is correct and in this case it shared the wrong context. > > Cheers! > -Tim > -- 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 https://groups.google.com/d/msgid/golang-nuts/1af04671fe537cc9faef5a642dc9d3945d5ce938.camel%40kortschak.io.
Re: [go-nuts] Re: go get with vanity import path and 404: fails
As a follow-up to the follow-up, I have filed golang.org/issue/39748; the error is apparently not in minification, but in the go command's handling of html. The workaround remains the same. On Sun, 2020-06-21 at 03:23 +, Dan Kortschak wrote: > Thanks to Tim and Eric Bajumpaa on slack. > > The issue was due to an error in minification where the quotes around > the name attribute value are stripped. Turning off minification is an > interim workaround while that is broken. > > Dan > > On Sat, 2020-06-20 at 18:10 -0700, Tim Heckman wrote: > > Closing the loop on this. They reached out in the Gopher Slack and > > we > > pieced it together: > > > > - https://gophers.slack.com/archives/C029RQSEE/p1592699134083700 > > > > It has to do with this section of code: > > > > - > > https://github.com/golang/go/blob/60f78765022a59725121d3b800268adffe78bde3/src/cmd/go/internal/get/vcs.go#L804-L810 > > > > This chooses to swallow parsing errors if the HTTP response looks > > to > > be invalid (bad status code), which is what's happening here. > > Another > > user managed to find that the meta tags on the page look malformed: > > > > https://github.com/gonum/exp";>;; > > > > Notice that go-import is missing quotes around it. I think fixing > > those up should solve the issue here. There is a larger question as > > to whether this code should return both, as it's hard to know which > > is correct and in this case it shared the wrong context. > > > > Cheers! > > -Tim > > > > -- 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 https://groups.google.com/d/msgid/golang-nuts/22ed6b3a00d994d154b2188c5d239072d17e08a6.camel%40kortschak.io.
Re: [go-nuts] Bitstring package?
Probably math/big.Int will do what you want. Dan On Mon, 2020-06-29 at 18:58 -0700, hardconnect@gmail.com wrote: > I'm looking for a package that implements arbitrary length bit > strings and > supports set all, clear all, set and reading back of arbitrary bits > and setting and clearing the next set or unset bit. > > I've seen a couple of packages that come close. Does anyone know of a > package that meets all my needs? > > Is there a centralized search/lookup site for GO packages? > > Thanks, > > Joe > -- > 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 > https://groups.google.com/d/msgid/golang-nuts/4a423427-186d-43df-8316-b62963fe5e1ao%40googlegroups.com > . -- 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 https://groups.google.com/d/msgid/golang-nuts/18b4e347d928bf039fa23eeb1b52f6223580b05f.camel%40kortschak.io.
[go-nuts] retaining mapiterkey return values in *reflect.MapIter
Is there a reason not to retain the returned value from `mapiterkey` on
line 1243 of reflect/value.go[1] for use on line 1249[2].
```
// Key returns the key of the iterator's current map entry.
func (it *MapIter) Key() Value {
if it.it == nil {
panic("MapIter.Key called before Next")
}
if mapiterkey(it.it) == nil { //L1243
panic("MapIter.Key called on exhausted iterator")
}
t := (*mapType)(unsafe.Pointer(it.m.typ))
ktype := t.key
return copyVal(ktype, it.m.flag.ro()|flag(ktype.Kind()),
mapiterkey(it.it)) // L1249
}
```
The same question applies to `*MapIter.Value` method just below `Key`.
thanks
Dan
[1]
https://github.com/golang/go/blob/96e83664378918980bd8f60822c4bc39befcb668/src/reflect/value.go#L1243
[2]
https://github.com/golang/go/blob/96e83664378918980bd8f60822c4bc39befcb668/src/reflect/value.go#L1249
--
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
https://groups.google.com/d/msgid/golang-nuts/c9e63667e67228e2486460d1e79aa01568b633d3.camel%40kortschak.io.
Re: [go-nuts] retaining mapiterkey return values in *reflect.MapIter
Looking again, the second part of my question was wrong (it is a call
to `mapiterkey` and then `mapiterelem` in `Value`).
The code for Key and Value are almost identical, so the question
whether to send a change boils down whether the similarity between the
two is a benefit or a cost. I'm actually leaning towards the similarity
being a benefit and one that would be broken by retaining the value.
Dan
On Tue, 2020-06-30 at 19:24 -0700, Ian Lance Taylor wrote:
> On Tue, Jun 30, 2020 at 6:39 PM 'Dan Kortschak' via golang-nuts
> wrote:
> >
> > Is there a reason not to retain the returned value from
> > `mapiterkey` on
> > line 1243 of reflect/value.go[1] for use on line 1249[2].
> >
> > ```
> > // Key returns the key of the iterator's current map entry.
> > func (it *MapIter) Key() Value {
> > if it.it == nil {
> > panic("MapIter.Key called before Next")
> > }
> > if mapiterkey(it.it) == nil { //L1243
> > panic("MapIter.Key called on exhausted iterator")
> > }
> >
> > t := (*mapType)(unsafe.Pointer(it.m.typ))
> > ktype := t.key
> > return copyVal(ktype, it.m.flag.ro()|flag(ktype.Kind()),
> > mapiterkey(it.it)) // L1249
> > }
> > ```
> >
> > The same question applies to `*MapIter.Value` method just below
> > `Key`.
>
> I don't think there is any reason to call the function twice. The
> value could be retained.
>
> I think the functionswill be inlined, so it probably won't make any
> performance difference, but it might be a little clearer.
>
> Ian
--
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
https://groups.google.com/d/msgid/golang-nuts/6a06fb0b70927f05ed2680e11953e28af50f5a16.camel%40kortschak.io.
Re: [go-nuts] Generics and parentheses
On Tue, 2020-07-14 at 23:05 -0700, Bakul Shah wrote:
> I don't much like square brackets or angle brackets or guillemets.
> But here is a different way
> of reducing the need for parentheses at least for the common case:
>
> A proposal for fewer irritating parentheses!
>
> One thing to note is that generic functions & types are *different*
> from
> existing things like const, func, type, var. As such they should have
> their
> own declaration marker. For example
>
> gen T type pair struct { a, b T } // contrast with type
> pair(type T) ...
> gen T,U type W struct { a T; b U } // contrast with type
> W(type T, U) ...
> gen T func Print(s []T) {...} // print a slice of T
>
> These function/type/method generics are used by *prepending* the
> type:
>
> var x int pair // a pair of ints
> var y (int, int pair) W // here we have to use parentheses
> int Print([]int{1,2,3}) // print a slice of ints
> qq := int pair pair{{1,2},{3,4}} // a pair of a pair of ints
> ww := (int, int) W pair{{1,2},{3,4}}
>
> This use may seem weird if you are used to C/C++. I find it more
> readable
> than having to deal with extra parentheses. "int pair" clearly says a
> pair of ints and so on. What is more, if in future types are allowed
> to be
> *inferred* for generic function calls, you can simply drop the type
> prefix.
>
> If there is still a parsing ambiguity, I'd suggest adding a - as in
> int-pair.
>
> Additional type syntax rule:
>
> type: ... | type generic-type| (type-list) generic-type
>
> or
>
> type: ... | type "-" generic-type | (type-list) "-" generic-
> type
>
> FWIW I thought of this four weeks ago (June 16).
>
How do these deal with non-type determined uses. Say you have (by any
spelling)
gen F,I func PowN(a F, b I) F {...}
How do you specify the type of F or I when say you have untyped
constants. This still requires parens or other markings to indicate the
actual types of F and I. It seems many of the comments here complaining
about brackets and such are ignoring this aspect of the current
proposal.
--
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
https://groups.google.com/d/msgid/golang-nuts/f71c554665750d8dcc3a8d3dd69ec7e2f996b896.camel%40kortschak.io.
Re: [go-nuts] Generics and parentheses
On Tue, 2020-07-14 at 23:53 -0700, Randall O'Reilly wrote: > So, essentially, this puts the onus back on the parser programmers to > definitively *rule out* the use of < > -- is it really that difficult > / costly to do a bit of look-ahead and disambiguate the different use > cases? The absence of arbitrary look-ahead was from memory one of the early design intentions of the language. -- 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 https://groups.google.com/d/msgid/golang-nuts/877ac181f9325169b145e156b2a04df0c7866559.camel%40kortschak.io.
Re: [go-nuts] Generics and parentheses
On Wed, 2020-07-15 at 14:36 -0700, Randall O'Reilly wrote: > And the use of [ ] in map is more semantically associated with its > conventional use as an element accessor in arrays / slices, not with > some more general kind of type parameter. The [] syntax can be viewed as an indexing operation perfectly well in the context of generics; a generic function or type is a map of implementations or types and so the [] syntax is a type index into that map, just as map[T1]T2 is a type index into the builtin generic map type. This is not mental stretch. -- 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 https://groups.google.com/d/msgid/golang-nuts/abe84ff5abefe2815137bea9cb83eb9e8d5fdafb.camel%40kortschak.io.
Re: [go-nuts] Generics and parentheses
On Wed, 2020-07-15 at 17:10 -0500, Seebs wrote: > That said, if people don't like square brackets, I'm totally prepared > to make worse suggestions until they give up and say square brackets > aren't that bad. > Let's bring back the special five keywords! func despiteallobjections F insofaras type T thetruthofthematter (x T) (T, error) There is no parsing ambiguity, the syntax is already familiar to Gophers and it clearly indicates the intention and the difficulty of coming up with a sensible generics declaration syntax. This is win win win! -- 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 https://groups.google.com/d/msgid/golang-nuts/be9188522d342abe5a94c0660f03e7bfa453cc9f.camel%40kortschak.io.
Re: [go-nuts] Generics and parentheses
On Wed, 2020-07-15 at 15:27 -0700, Bakul Shah wrote: > The second issue is the usage for generic functions. Contrast > > (float64, int)PowN(1.2, 3) > with > PowN[float64, int](1.2, 3) > or currently > PowN(float64, int)(1.2, 3) > > I find the alternate syntax easier because conceptually the concrete > types used to select a specific concrete function is a different > activity than passing arguments to a function at runtime so IMHO they > should be visually different. It is almost like C style cast. Think > of it as casting a generic function (or type) to a concrete function > or type! This is going to be a fairly individual thing though, I find PowN[float64, int](1.2, 3) much easier to read. -- 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 https://groups.google.com/d/msgid/golang-nuts/d04805fe0f4341fd7542fb435c729424c4271758.camel%40kortschak.io.
Re: [go-nuts] Generics and parentheses
On Wed, 2020-07-15 at 18:09 -0700, lotus.developer.mas...@gmail.com wrote: > Personally think this way is easier to read. In this way, I wrote a > few examples, which may be different from the creator Please post in unstyled plain text. It is almost impossible to read the code examples you have there in dark text on a black background. -- 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 https://groups.google.com/d/msgid/golang-nuts/b521941b8058037dd60bc25ffddcc0d9e5a614c5.camel%40kortschak.io.
Re: [go-nuts] Re: Generics and parentheses
On Thu, 2020-07-16 at 13:44 -0700, jpap wrote: > Notwithstanding a concise unambiguous alternative, I would rather > type parameters "stick out" so they are easily identified when > visually scanning through code. func ᕙ(⇀ X ↼‶)ᕗ GenericFunction(x X) ... -- 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 https://groups.google.com/d/msgid/golang-nuts/3f04f4b68e24397dd6471e5ad603b48a745af2f4.camel%40kortschak.io.
Re: [go-nuts] Re: Generics and parentheses
On Fri, 2020-07-17 at 15:56 -0700, Jay Kay wrote:
> How about a "-generics" compile flag that lets you select one pair
> from a character set of [ ( { < « .
This hits two of the things that Go doesn't do:
1. proliferation of compiler option flags
2. enabling dialect spliting
--
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
https://groups.google.com/d/msgid/golang-nuts/cf05661f1c6db838b8ab8c6719a6bf4f9f6f.camel%40kortschak.io.
Re: [go-nuts] A question about copying
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 address of the thing that is pointed to by p". This is p. If you assign the value of *p to another variable and take the address of that, then you'll get the outcome you were wanting. -- 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 https://groups.google.com/d/msgid/golang-nuts/715c99a366a243ff9768a22f96c5a1dc147ace01.camel%40kortschak.io.
Re: [go-nuts] A few thoughts on type parameters
On Mon, 2020-08-03 at 10:45 -0700, Ian Lance Taylor wrote:
> Another possibility is constraints.Any, although that is no shorter
> than interface{}. I'm not sure _ is best; currently _ fairly
> consistently means "ignore this value," but in this usage it would
> mean something different.
Another possibility would be `...` which at least in the context of
arrays means "fill this in with the information you have elsewhere";
`var a [...]int{1,2,3,4}`. There is no other use of the ellipsis
operator in the type parameters, so this should work.
Dan
--
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
https://groups.google.com/d/msgid/golang-nuts/9918b7c7fe023f40f56874e2de1b42eb67297041.camel%40kortschak.io.
[go-nuts] gophers analysing genomes
The genome of the New Zealand 'lizard', the tuatara[1], has just been sequenced and published in Nature[2,3]. The analysis of the genome included an examination of the repetitive sequences within the genome. The engine for finding novel repeats for this analysis is written in Go. Gophers analyse reptiles' genomes. [1]https://en.wikipedia.org/wiki/Tuatara [2]https://www.nature.com/articles/s41586-020-2561-9 [3]https://www.nature.com/articles/d41586-020-02063-4 -- 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 https://groups.google.com/d/msgid/golang-nuts/bbe91a12ef2cab42a5ff9f2adc4338396fbc0217.camel%40kortschak.io.
Re: [go-nuts] gophers analysing genomes
On Thu, 2020-08-06 at 07:41 +, Sebastien Binet wrote: > ‐‐‐ Original Message ‐‐‐ > On Thursday, August 6, 2020 9:16 AM, 'Dan Kortschak' via golang-nuts > wrote: > > > The genome of the New Zealand 'lizard', the tuatara[1], has just > > been > > sequenced and published in Nature[2,3]. > > > > The analysis of the genome included an examination of the > > repetitive > > sequences within the genome. The engine for finding novel repeats > > for > > this analysis is written in Go. > > Nice work! > > Was this done with (parts of?) biogo or with a set of ad hoc Go > packages? > > -s The code that did the repeat identification was actually the motivation for writing bíogo and was the reason I started working in Go. Dan -- 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 https://groups.google.com/d/msgid/golang-nuts/af4b307e53e0987c4155e52f723f9a0131d89cbb.camel%40kortschak.io.
Re: [go-nuts] How to print arrays with commas and brackets
On Wed, 2019-10-09 at 06:02 -0700, Nalin Pushpakumara wrote:
> Hi,
> I tried to print array with brackets and commas in golang. I want to
> get
> array like this.
> ["record1", "record2". "record3"]
>
> Does anyone know how to do it?
>
> Thank you
>
Not the most efficient, but simple and clear.
func printSlice(a []string) string {
q := make([]string, len(a))
for i, s := range a {
q[i] = fmt.Sprintf("%q", s)
}
return fmt.Sprintf("[%s]", strings.Join(q, ", "))
}
https://play.golang.org/p/cn9EaL0x-2v
--
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
https://groups.google.com/d/msgid/golang-nuts/42f2c00adc67d6100724122d93e8467513ecee12.camel%40kortschak.io.
[go-nuts] obtaining the original type from a named alias type with go/types?
I would like to be able to obtain the original type for an alias given a source input. I can see in "go/types" that it's possible to know whether a named type is an alias by `typ.Obj().IsAlias()`, but I cannot see how to obtain the actual original type unless it is an alias for a basic type. Can someone point me to a way to get this information? From the source it looks something like `typ.Obj().Type().(*types.Named).Obj().Type()`. Is this correct assuming that the original type is a named type? thanks Dan -- 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 https://groups.google.com/d/msgid/golang-nuts/163019fbad545cd7f97d6c85fc2445bee5b1d9c7.camel%40kortschak.io.
Re: [go-nuts] obtaining the original type from a named alias type with go/types?
On Sat, 2020-08-15 at 21:44 -0700, Ian Lance Taylor wrote: > On Sat, Aug 15, 2020 at 3:45 PM 'Dan Kortschak' via golang-nuts > wrote: > > > > I would like to be able to obtain the original type for an alias > > given > > a source input. I can see in "go/types" that it's possible to know > > whether a named type is an alias by `typ.Obj().IsAlias()`, but I > > cannot > > see how to obtain the actual original type unless it is an alias > > for a > > basic type. > > > > Can someone point me to a way to get this information? From the > > source > > it looks something like > > `typ.Obj().Type().(*types.Named).Obj().Type()`. > > Is this correct assuming that the original type is a named type? > > I haven't tested it but I *think* you can just write > typ.Underlying(). > > Ian Thanks, Ian. No that doesn't work. For example with type byte, you get back the byte name. https://play.golang.org/p/PPjHBotsIsw Dan -- 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 https://groups.google.com/d/msgid/golang-nuts/d3f6c5b7a76f7ea2db93f34fa87917651dcc7ad5.camel%40kortschak.io.
Re: [go-nuts] obtaining the original type from a named alias type with go/types?
On Sat, 2020-08-22 at 06:00 +0100, Paul Jolly wrote: > I think you were unlucky with your choice of type to experiment with. > My understanding is that byte is special cased, despite being an > alias: > > https://github.com/golang/go/blob/13e41bcde8c788224f4896503b56d42614e0bf97/src/go/types/universe.go#L25 > > Consider instead https://play.golang.org/p/MHjgBvbOG__G Thanks, Paul. Not so much unlucky as attempting to find the worst case so that all others work as well when it's solved. That snippet is helpful, but given https://golang.org/issue/40965 I'm concerned user defined aliases will suffer the same issue when it's resolved. Dan -- 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 https://groups.google.com/d/msgid/golang-nuts/b9a91d449fcf89275c8310615b1f3199a2e51336.camel%40kortschak.io.
Re: [go-nuts] obtaining the original type from a named alias type with go/types?
On Fri, 2020-08-21 at 21:51 -0700, Ian Lance Taylor wrote:
>
> > Thanks, Ian.
> >
> > No that doesn't work. For example with type byte, you get back the
> > byte
> > name.
> >
> > https://play.golang.org/p/PPjHBotsIsw
>
> The underlying type of byte is indeed byte. What are you hoping for?
>
> Ian
I'm hoping for a resolution of the type to its base unaliased type. The
types.Type of a "byte" is &types.Basic{kind: types.Uint8, info:
types.IsInteger|types.IsUnsigned, name: "byte"} while the type for
"uint8" (obtained either from syntax or from types.Typ[types.Uint8], or
types.Typ[types.Byte]) is the same, but with name = "uint8". The same
situation is true for rune/int32.
https://play.golang.org/p/cbbU7-qzwxQ
I would like to resolve all types that are aliases to a single string
representation.
Paul's code at https://play.golang.org/p/MHjgBvbOG__G shows that for
other cases .Underlying() is not needed, it resolves to the original
type.
It it's just uint8/byte and int32/rune, I can special case them and do
a looking into types.Typ with the type's Kind.
Dan
--
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
https://groups.google.com/d/msgid/golang-nuts/090030433605a38cbec52370113674d32218797a.camel%40kortschak.io.
Re: [go-nuts] [ANN] CGo-free sqlite database/sql driver 1.4.0 for linux/amd64 released
On Wed, 2020-08-26 at 23:50 +0200, Jan Mercl wrote: > From the change log ( > https://godoc.org/modernc.org/sqlite#hdr-Changelog) > > 2020-08-26 v1.4.0: > > First stable release for linux/amd64. The database/sql driver and its > tests are CGo free. Tests of the translated sqlite3.c library still > require CGo. > > $ make full > > ... > > SQLite 2020-08-14 13:23:32 > fca8dc8b578f215a969cd899336378966156154710873e68b3d9ac5881b0ff3f > 0 errors out of 928271 tests on 3900x Linux 64-bit little-endian > WARNING: Multi-threaded tests skipped: Linked against a non- > threadsafe Tcl build > All memory allocations freed - no leaks > Maximum memory usage: 9156360 bytes > Current memory usage: 0 bytes > Number of malloc() : -1 calls > --- PASS: TestTclTest (1785.04s) > PASS > ok modernc.org/sqlite 1785.041s > $ > This is just what I have been looking for for a little toy I'm writing. -- 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 https://groups.google.com/d/msgid/golang-nuts/99c1e8c1aeb3c3253b63461befec3d887de2c559.camel%40kortschak.io.
[go-nuts] cgo godefs questions
I am working on some C/Go interop code that includes this horror on the
C side (TYPE_BITS is 5 and NAMED_BITS is 16):
```
struct sxpinfo_struct {
SEXPTYPE type : TYPE_BITS;
/* ==> (FUNSXP == 99) %% 2^5 == 3 == CLOSXP
* -> warning: `type' is narrower than values
* of its type
* when SEXPTYPE was an enum */
unsigned int scalar: 1;
unsigned int obj : 1;
unsigned int alt : 1;
unsigned int gp: 16;
unsigned int mark : 1;
unsigned int debug : 1;
unsigned int trace : 1; /* functions and memory tracing */
unsigned int spare : 1; /* used on closures and when REFCNT is defined */
unsigned int gcgen : 1; /* old generation number */
unsigned int gccls : 3; /* node class */
unsigned int named : NAMED_BITS;
unsigned int extra : 32 - NAMED_BITS; /* used for immediate bindings */
}; /* Tot: 64 */
```
This gets converted to this Go struct:
```
type sxpinfo struct {
Gpuint16
Pad_cgo_0 [2]byte
Named uint16
Pad_cgo_1 [2]byte
}
```
I don't expect that Cgo will cope with the bitfields, but I am
surprised that it makes any effort at all beyond getting to alignment.
In particular the Go sxpinfo gives misleading field, Gp that although
the correct size, is not aligned at all with the bits in the C gp field
(one byte too far forward).
Is this behaviour expected? Would it not be more sensible to do with
bitfields what Cgo does with unions, and just give back a struct {
[8]byte }?
The second question is whether `#cgo pkg-config:` is expected to work
with -I flags?
I can generate the Go definitions with
```
go tool cgo -godefs -- $(pkg-config --cflags libR) generate.go
```
but including `#cgo pkg-config: R` or `#cgo pkg-config: libR` fails to
find the R headers.
thanks
Dan
--
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
https://groups.google.com/d/msgid/golang-nuts/11d52d7756bdd1efb08d4d55b0a8c32939769d69.camel%40kortschak.io.
Re: [go-nuts] cgo godefs questions
On Tue, 2020-09-01 at 17:03 -0700, Ian Lance Taylor wrote: > > This is a bug. Sent https://golang.org/cl/252378. > > I think that currently cgo -godefs ignores #cgo lines. This was > recently reported at https://golang.org/issue/41072. > > Ian Thanks, Ian for both of those. Dan -- 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 https://groups.google.com/d/msgid/golang-nuts/3b5245288718a4bf774cd842e558339398daeb54.camel%40kortschak.io.
Re: [go-nuts] linux/arm struct alignment seems wrong
On Wed, 2020-09-09 at 12:19 +0200, Jan Mercl wrote:
> Observation:
>
> pi@raspberrypi:~/src/tmp.tmp $ go version
> go version go1.15.1 linux/arm
> pi@raspberrypi:~/src/tmp.tmp $ cat main.go
> package main
>
> /*
>
> struct s {
> long long i;
> } x;
>
> size_t align() {
> return _Alignof(struct s);
> }
>
> */
> import "C"
>
> import (
> "fmt"
> "unsafe"
> )
>
> type S struct {
> i int64
> }
>
> func main() {
> fmt.Printf(" C alignof struct s: %v\n", C.align())
> fmt.Printf("Go alignof struct s: %v\n",
> unsafe.Alignof(C.struct_s{}))
> fmt.Printf("Go alignofS: %v\n", unsafe.Alignof(S{}))
> }
> pi@raspberrypi:~/src/tmp.tmp $ go run main.go
> C alignof struct s: 8
> Go alignof struct s: 4
> Go alignofS: 4
> pi@raspberrypi:~/src/tmp.tmp $ uname -a
> Linux raspberrypi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019
> armv7l GNU/Linux
> pi@raspberrypi:~/src/tmp.tmp $
>
> My code relies on all the numbers being the same, ie. that Go will
> report the same as C for both C.struct_s{} and S{}.
> AFAICT Go and C agree on struct layout on linux/{amd64,386} perfectly
> in all cases I've tested (thousands probably).
>
> Is this a bug or are my expectations ill founded?
>
> Thanks in advance for any insights.
>
I get the following
```
C alignof struct s: 8
Go alignof struct s: 8
Go alignofS: 8
~/cznic $ go version
go version go1.15.1 linux/arm64
~/cznic $ uname -a
Linux bildr 4.19.0-10-arm64 #1 SMP Debian 4.19.132-1 (2020-07-24)
aarch64 GNU/Linux
```
I have an arm64 linux running on my pi, maybe the armv7l behaviour is
different.
Dan
--
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
https://groups.google.com/d/msgid/golang-nuts/da8da3f14f311a23ab0191d7e8ba130a068c73b8.camel%40kortschak.io.
Re: [go-nuts] linux/arm struct alignment seems wrong
On Wed, 2020-09-09 at 12:50 +0200, Jan Mercl wrote:
> On Wed, Sep 9, 2020 at 12:41 PM Dan Kortschak
> wrote:
>
> > I get the following
> >
> > ```
> > C alignof struct s: 8
> > Go alignof struct s: 8
> > Go alignofS: 8
> > ~/cznic $ go version
> > go version go1.15.1 linux/arm64
> > ~/cznic $ uname -a
> > Linux bildr 4.19.0-10-arm64 #1 SMP Debian 4.19.132-1 (2020-07-24)
> > aarch64 GNU/Linux
> > ```
> >
> > I have an arm64 linux running on my pi, maybe the armv7l behaviour
> > is
> > different.
>
> Seems to be the case as armv7l is AFAIK a 32 bit only CPU. And arm64
> is next on the list of my targets so thank you for the information.
>
> But the question is still the same. Is it a bug or is my assumption
> about Go and C agreeing on alignments/offsets invalid? I realizethe
> specs say nothing in this regard.
What does cgo -godefs give you? On my amd64 and arm64 I get this:
```
~/cznic $ cat main.go
package main
/*
struct s {
long long i;
} x;
*/
import "C"
type S struct {
i int64
}
type C_s C.struct_s
~/cznic $ go tool cgo -godefs main.go
// Code generated by cmd/cgo -godefs; DO NOT EDIT.
// cgo -godefs main.go
package main
type S struct {
i int64
}
type C_s struct {
I int64
}
```
--
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
https://groups.google.com/d/msgid/golang-nuts/bf4ba2bfde7a4a0c2d858e5ae1af8c118694b541.camel%40kortschak.io.
Re: [go-nuts] linux/arm struct alignment seems wrong
On Wed, 2020-09-09 at 13:21 +0200, Jan Mercl wrote:
>
>
> On Wed, Sep 9, 2020 at 1:09 PM 'Dan Kortschak' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> > What does cgo -godefs give you? On my amd64 and arm64 I get this:
> >
> > ```
> > ~/cznic $ cat main.go
> > package main
> >
> > /*
> > struct s {
> > long long i;
> > } x;
> > */
> > import "C"
> >
> > type S struct {
> > i int64
> > }
> >
> > type C_s C.struct_s
> >
> > ~/cznic $ go tool cgo -godefs main.go
> > // Code generated by cmd/cgo -godefs; DO NOT EDIT.
> > // cgo -godefs main.go
> >
> > package main
> >
> > type S struct {
> > i int64
> > }
> >
> > type C_s struct {
> > I int64
> > }
> > ```
>
> amd64
> =
>
>
> jnml@e5-1650:~/tmp$ go version
> go version go1.15.1 linux/amd64
> jnml@e5-1650:~/tmp$ cat main.go
> package main
>
> /*
> struct s {
> long long i;
> } x;
> */
> import "C"
>
> type S struct {
> i int64
> }
>
> type C_s C.struct_s
> jnml@e5-1650:~/tmp$ go tool cgo -godefs main.go
> // Code generated by cmd/cgo -godefs; DO NOT EDIT.
> // cgo -godefs main.go
>
> package main
>
> type S struct {
> i int64
> }
>
> type C_s struct {
> I int64
> }
> jnml@e5-1650:~/tmp$
>
> arm
> =
> ==
>
> pi@raspberrypi:~/src/tmp.tmp $ go version
> go version go1.15.1 linux/arm
> pi@raspberrypi:~/src/tmp.tmp $ cat main.go
> package main
>
> /*
> struct s {
> long long i;
> } x;
> */
> import "C"
>
> type S struct {
> i int64
> }
>
> type C_s C.struct_s
> pi@raspberrypi:~/src/tmp.tmp $ go tool cgo -godefs main.go
> // Code generated by cmd/cgo -godefs; DO NOT EDIT.
> // cgo -godefs main.go
>
> package main
>
> type S struct {
> i int64
> }
>
> type C_s struct {
> I int64
> }
> pi@raspberrypi:~/src/tmp.tmp $
>
> No difference between the outputs AFAICT. Seems good to me.
>
>
I think it comes down to these lines in src/cmd/internal/sys/arch.go
[1]
```
var ArchARM = &Arch{
Name: "arm",
Family:ARM,
ByteOrder: binary.LittleEndian,
PtrSize: 4,
RegSize: 4,
MinLC: 4,
}
var ArchARM64 = &Arch{
Name: "arm64",
Family:ARM64,
ByteOrder: binary.LittleEndian,
PtrSize: 8,
RegSize: 8,
MinLC: 4,
}
```
this line in src/cmd/compile/internal/gc/main.go [2]
```
Widthreg = thearch.LinkArch.RegSize
```
and these lines in src/cmd/compile/internal/gc/align.go [3]
```
case TINT64, TUINT64, TFLOAT64:
w = 8
t.Align = uint8(Widthreg)
```
[1]https://golang.org/src/cmd/internal/sys/arch.go
[2]https://golang.org/src/cmd/compile/internal/gc/main.go
[3]https://golang.org/src/cmd/compile/internal/gc/align.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
https://groups.google.com/d/msgid/golang-nuts/9faee5b3868886c3c7415ecc1c2469f2e008abe2.camel%40kortschak.io.
Re: [go-nuts] Re: method resolution order
Yes, it's sort of like asking what the best way to translate "This
sentence is not Spanish." into Spanish; you can do it, but it doesn't
make a lot of sense.
On Wed, 2020-09-16 at 02:13 -0700, Volker Dobler wrote:
> On Wednesday, 16 September 2020 at 10:51:27 UTC+2
> stephan...@gmail.com wrote:
> > Assume a public interface I with two methods NotInS and M whereas
> > NotInS
> > is calling M. An implementation i of I which implements NotInS and
> > M as
> > well as a specialization s of i which only implements M. Finally a
> > constructor whose return-type is I returns a pointer to an instance
> > of
> > s. Calling on this return-value NotInS will execute i.M() as the
> > following test shows. I would like it to call s.M(). How would I
> > do
> > this in a goish way? Thanks for any help!
>
> Well, start of by not using Java/C#/C++ terminology as Go is
> different
> and in Go you simply cannot have a "specialization s of i" as there
> are
> no "specialization" as there is no inheritance. Also let's rewrite
> the code
> to be a bit more Go'ish:
>
> package main
>
> import "fmt"
>
> type I interface {
> NotInS()
> M()
> }
>
> type T struct{}
> func (t *T) NotInS() { t.M() }
> func (t *T) M() { fmt.Println("T.M") }
>
> type S struct{ *T }
> func (s *S) M() { fmt.Println("S.M") }
>
> func main() {
> x := &S{&T{}}
> x.NotInS()
> }
>
> You see S has no method NotInS defined and all calls to
> NotInS are automatically directed to implicit field T of
> S. Remember that embedding a *T in an S has nothing to
> do with inheritance or specialisation. It is just some tiny
> syntactic sugar for an implicit field and automatic method
> forwarding to that field. Spelling it out your code is
> equivalent to:
> type S struct{ T *T }
> func (s *S) NotInS() { s.T.M() }
>
> The embedded T doesn't know it is a field of S and you
> call T's M method and it is simply impossible to have
> S's M method called like this.
>
> You must redesign. Embedding is not inheritance and
> you cannot modle inheritance based design with embedding
> no matter how hard you try.
>
> V.
>
> --
> 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
> https://groups.google.com/d/msgid/golang-nuts/27f6fcb8-2040-491a-8309-85629d02406bn%40googlegroups.com
> .
--
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
https://groups.google.com/d/msgid/golang-nuts/7304cd1474813aa9da3fe0b27ee39fc8bf8d0f8c.camel%40kortschak.io.
Re: [go-nuts] Licence details of github.com/golang/sync
On Thu, 2020-10-29 at 22:54 -0700, Ian Lance Taylor wrote: > On Thu, Oct 29, 2020, 10:48 PM Denis Cheremisov < > denis.cheremi...@gmail.com> wrote: > > Well, as usual I wrote something in the way, not the real thing. > > > > The case is: > > > > - At my company we are using errgroup from that sync repo in one > > project, > > sync/errgroup in fact mostly. > > - It proved to be error prone with its context shadowing on > > errgroup.WithContext > > so we took the original and adds context in the group itself via > > eg.Ctx() + > > a couple of additional functionality. > > > > Yesterday our attorney wrote us "we can't use sync because of this > > patents > > note" as it works like a virus, and can't use our modification too > > for the same > > reason. It turned out the stdlib is under the same note too, so we > > will have > > fun times :) > > > That makes no sense to me. And I'm not aware of any other company > that sees any problem at all with the patent grant. > > But I am not a lawyer, and you will have to make your own decisions. > > Ian Maybe they are worried about this, "This grant does not include claims that would be infringed only as a consequence of further modification of this implementation." (that's what it sounds like from the previous response). If they are, I think they are misreading it (though I am not a lawyer). -- 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 https://groups.google.com/d/msgid/golang-nuts/2e49ef8893e064727347932cfaa79a71050f419f.camel%40kortschak.io.
Re: [go-nuts] Running "go test" modifies go.mod & go.sum
You're using go test, with -mod=readonly, but it's running your code with go run, without -mod=readonly. Either you'll need to unconditionally pass -mod=readonly to go run in the regression_test.go file, or find wether it's been passed to go test and then conditionally pass it to go run. On Sun, 2020-11-01 at 01:09 -0700, Miki Tebeka wrote: > I *do* use "go test", see > https://github.com/tebeka/recheck/blob/master/regression_test.go > > On Sunday, November 1, 2020 at 8:43:33 AM UTC+2 amits...@gmail.com > wrote: > > > > On Sun, 1 Nov 2020, 4:07 pm Miki Tebeka, > > wrote: > > > Hi, > > > > > > I wrote a regexp linter (https://github.com/tebeka/recheck) > > > that's using golang.org/x/tools/go/analysis. > > > > > > To test the tool, I run "go run ./cmd/recheck testdata/ok.go" > > > (using os/exec). The problem is that after the test, go.mod & > > > go.sum are modified since there are some external imports in the > > > go files under testdata. > > > > > > I've tried using -mod=readonly, building & then running, moving > > > the test file to /tmp - all of them didn't work, the mod files > > > are still changed after the test. > > > > > > Any idea how can I prevent the test from modifing the mod files? > > > > Your example above suggests you are not using go test to execute > > your tests? > > > > > Thanks, > > > Miki -- 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 https://groups.google.com/d/msgid/golang-nuts/80699bdc8a81f300b2b769ae7c8a40dbdead6d7d.camel%40kortschak.io.
Re: [go-nuts] Running "go test" modifies go.mod & go.sum
Ah, it just clicked. You're indirectly using go/packages, which will (unless configured not to), cause changes to the go.mod and go.sum file. This configuration happens for this by adding "-mod=readonly" to packages.Config.BuildFlags (I think). But this isn't exposed via the go/analysis API (the config is populated here[1] where the user can't access it). This can be confirmed by seeing that building your checker, resetting the changes to go.mod and go.sum and then manually running the binary on your test cases. I'm not sure what to do about this. [1] https://github.com/golang/tools/blob/582c62ec74d06936c88d4b760c63cbc2925e69c7/go/analysis/internal/checker/checker.go#L152-L155 On Sun, 2020-11-01 at 04:52 -0800, Miki Tebeka wrote: > I try to change the "go run" command to use "-mod=readonly", didn't > help. > > On Sunday, November 1, 2020 at 10:23:07 AM UTC+2 kortschak wrote: > > You're using go test, with -mod=readonly, but it's running your > > code > > with go run, without -mod=readonly. > > > > Either you'll need to unconditionally pass -mod=readonly to go run > > in > > the regression_test.go file, or find wether it's been passed to go > > test > > and then conditionally pass it to go run. > > > > > > On Sun, 2020-11-01 at 01:09 -0700, Miki Tebeka wrote: > > > I *do* use "go test", see > > > https://github.com/tebeka/recheck/blob/master/regression_test.go > > > > > > On Sunday, November 1, 2020 at 8:43:33 AM UTC+2 > > amits...@gmail.com > > > wrote: > > > > > > > > On Sun, 1 Nov 2020, 4:07 pm Miki Tebeka, > > > > wrote: > > > > > Hi, > > > > > > > > > > I wrote a regexp linter (https://github.com/tebeka/recheck) > > > > > that's using golang.org/x/tools/go/analysis. > > > > > > > > > > To test the tool, I run "go run ./cmd/recheck > > testdata/ok.go" > > > > > (using os/exec). The problem is that after the test, go.mod > > & > > > > > go.sum are modified since there are some external imports in > > the > > > > > go files under testdata. > > > > > > > > > > I've tried using -mod=readonly, building & then running, > > moving > > > > > the test file to /tmp - all of them didn't work, the mod > > files > > > > > are still changed after the test. > > > > > > > > > > Any idea how can I prevent the test from modifing the mod > > files? > > > > > > > > Your example above suggests you are not using go test to > > execute > > > > your tests? > > > > > > > > > Thanks, > > > > > Miki > > > > > > -- > 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 > https://groups.google.com/d/msgid/golang-nuts/354542dc-0648-4383-98af-63ff4f7dabcfn%40googlegroups.com > . -- 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 https://groups.google.com/d/msgid/golang-nuts/8311ca8d52158493a088d88bef33ee93f82c6e7a.camel%40kortschak.io.
Re: [go-nuts] Syntactic Sugar Idea for Go 2.0: until/unless, and postfix conditionals
My first professional programming language was Perl, decades later I
still wake up in a sweat thinking about post-fix conditionals and the
'unless' conditional.
Please no.
On Mon, 2020-11-02 at 14:26 -0800, Jeffrey Paul wrote:
> Hello Gophers,
>
> There's two tiny pieces of syntactic sugar I really miss from a few
> other languages that I think would add a nice bit of ergonomics and
> convenience to Go (which I now play as my main) without increasing
> any magic or spooky action at a distance.
>
> They are:
>
> - postfix conditionals
>
> and
>
> - until (while!) and unless (if!) (which probably also means adding
> `while`)
>
> This allows for lovely expressions such as the following examples:
>
>i.NotifySomeone() if j.HasExpiredItems()
>
>time.Sleep(1 * time.Second) until thing.IsReady()
>
>b.ReportActivity(e) unless u.HasOptedOut()
>
>q.ProcessItem() while server.Active()
>
>until(time.Now().After(notAfter)) {
> // do something while we still can
>}
>
>p.processEvents() until p.shutdownRequested
>
> and, my favorite:
>
>panic("can't even") if err != nil
>
> There are, of course, various ways of doing some of this sort of
> synchronization stuff in these contrived examples using
> channels/goroutines/timers, but this sort of syntax is quite useful
> for simple straight-line synchronous code, and, in my view, increases
> readability without sacrificing anything.
>
> I know that `while` isn't a distinct thing in Go, and for
> consistency's sake, this might necessitate adding such a construct as
> well (if you can use it as a postfix conditional, you should probably
> be able to use it as `while(cond) {}` too).
>
> What do you think? I really miss this syntax from other
> languages. It's been in Perl and Ruby for ages, and, more recently,
> CoffeeScript had it for a moment, but it didn't make it over into ES
> with the other notable features from it. I think it's a lovely
> convenience without changing the operation of the language itself.
>
> Best,
> -sneak
>
--
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
https://groups.google.com/d/msgid/golang-nuts/99896e4fcd832c0003bb5e23ffd1a72837ea49bd.camel%40kortschak.io.
Re: [go-nuts] Syntactic Sugar Idea for Go 2.0: until/unless, and postfix conditionals
There are two parts. The worse part is the negative conditional (unless), which has the problem that humans are bad at negations; nearly always when there is a complex condition with an "unless", it needs to be mentally refactored into an "if !" (when working through other people's bugs, I invariably — at least temporarily — inverted the condition and replaced the "unless" with an "if"). The post-fix conditional syntax says a whole heap of stuff that's going to happen, and only when you get to the end of the line do you see that it might not. Putting a single positively oriented syntax, at the front of conditional blocks greatly simplifies the thinking about what is going to happen in a section of code. On Mon, 2020-11-02 at 21:22 -0800, Tyler Compton wrote: > I don't think I'm personally sold on this proposal either, but I'm > curious what bad experiences you've had with post-fix conditionals. I > haven't personally used a language with post-fix conditionals and it > sounds like that might be to my benefit :) -- 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 https://groups.google.com/d/msgid/golang-nuts/81c874ec04cea0e9e8f73d251cccf01cfa9b9e19.camel%40kortschak.io.
Re: [go-nuts] strconv.ParseFloat panic
The full panic would help, but somehow you have a string with a nil pointer that is 4 bytes long. Where is the string generated? Are you using Cgo? Have you run with the race detector? Also, what version of Go are you using? On Fri, 2020-11-06 at 00:00 -0800, blade...@gmail.com wrote: > i check my code, and strconv.ParseFloat(s, 64), s is a string, it is > correct, but after run my program for a while, it's panic and report > some output info. i cant't find why , anyone can help me > > > output infor: > panic: runtime error: invalid memory address or nil pointer > dereference > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 > pc=0x4a2654] > > goroutine 2948735 [running]: > strconv.special(0x0, 0x4, 0x0, 0x3ff2e147ae147ae1, 0x1) > strconv/atof.go:48 +0x34 > strconv.atof64(0x0, 0x4, 0x41421d, 0xc05323c380, 0xc05dd95ab0, 0xa) > strconv/atof.go:612 +0x50 > strconv.parseFloatPrefix(0x0, 0x4, 0x40, 0x3, 0xc078741b48, > 0xc05dd95ab0, 0xc078741b40) > strconv/atof.go:695 +0x95 > strconv.ParseFloat(0x0, 0x4, 0x40, 0xa, 0xc078741bc8, 0xc05dd95a01) > strconv/atof.go:683 +0x45 > xx/api.handleDPriceRange(0xc01777c820) > xx/api/PriceCalendar.go:1008 +0x212 > xx/api.priceCalendarItemExpand(0xc016e34a80, 0xc96, 0xc96) > xx/api/PriceCalendar.go:1104 +0xb9b > xx/api.FlightlineRT(0xc001bd9d98, 0xc0002294f0, 0x1306020, > 0xc04f1415c0, 0xc05e653a70, 0x1c000229518, 0xc05193dc00) > xx/api/external_api.go:146 +0x108 > xx/api.aaa.func2(0xc04f1456b0, 0xc04f102340, 0xc05d23aa68, 0x3, > 0xc05465c230, 0x63, 0xc04f13c301, 0x7, 0x0, 0x0, ...) > xx/api/external_api.go:343 +0x25b > created by xx/api.AppMainpage > xx/api/external_api.go:330 +0x57e > -- > 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 > https://groups.google.com/d/msgid/golang-nuts/9c672d72-7daa-4fe1-9f84-136c2eaa2065n%40googlegroups.com > . -- 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 https://groups.google.com/d/msgid/golang-nuts/a0ebd55eb6be63355c1e44f9717a5710f78ca5a0.camel%40kortschak.io.
Re: [go-nuts] strconv.ParseFloat panic
OK, so you're not using Cgo, that leaves some other unsafe use, a data race or unlikely some weird compiler bug. I'd start looking in api.handleDPriceRange to see where the string input to strconv.ParseFloat is being constructed. On Fri, 2020-11-06 at 01:10 -0800, blade...@gmail.com wrote: > go version is 1.15 , cross compile on darwin and run on linux, i > will try to run with race deector > > > > 在2020年11月6日星期五 UTC+8 下午4:34:21 写道： > > The full panic would help, but somehow you have a string with a > > nil > > pointer that is 4 bytes long. Where is the string generated? Are > > you > > using Cgo? Have you run with the race detector? Also, what version > > of > > Go are you using? > > -- 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 https://groups.google.com/d/msgid/golang-nuts/dc04cd21bb00f2e520f9791fdad6c1731c85a8a2.camel%40kortschak.io.
Re: [go-nuts] go list "go:generate" files
//go:generate is not limited to dependency on Go source files, so this is not possible in the general case. On Tue, 2020-11-10 at 01:05 -0800, gta wrote: > Thanks for the reply, > yes I know I can grep for those files, but I was hoping that go list > could give me the files in the reverse dependency order like go list > -deps. > I was hoping to shave some time from our generation step. > I guess bash is my friend in this. -- 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 https://groups.google.com/d/msgid/golang-nuts/2107e93634c3abf31f52e14f91e0fa35f8a0cbee.camel%40kortschak.io.
Re: [go-nuts] Re: use same for/range code on a hash map but it has different result
On Tue, 2020-11-10 at 19:08 -0800, 'Kilos' via golang-nuts wrote: > Thanks for reply, but I want to know the underlying reason about it, > I think the reason is in how the runtime functions works. The direct cause is that the hash function used for the map implementation is seeded from the system clock. The reason for doing this was largely to avoid time complexity attacks against servers that use maps for passing arguments in URIs. -- 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 https://groups.google.com/d/msgid/golang-nuts/45e34abf38b3e484a79f0f9e8bd22ba77786deef.camel%40kortschak.io.
Re: [go-nuts] Re: use same for/range code on a hash map but it has different result
On Tue, 2020-11-10 at 20:28 -0800, 'Kilos' via golang-nuts wrote: > You cannot safely mutate a Go map while iterating over it with the > `range` operator. This is not true, depending on your definition of "safely". See https://golang.org/ref/spec#For_statements "For statements with range clause" ``` 3. The iteration order over maps is not specified and is not guaranteed to be the same from one iteration to the next. If a map entry that has not yet been reached is removed during iteration, the corresponding iteration value will not be produced. If a map entry is created during iteration, that entry may be produced during the iteration or may be skipped. The choice may vary for each entry created and from one iteration to the next. If the map is nil, the number of iterations is 0. ``` So long as you take into account these caveats, mutating a map during a range will not corrupt the map or other data structure, and will cause your application to crash. -- 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 https://groups.google.com/d/msgid/golang-nuts/b30864fe883e12005a71e656d40c3439cb695185.camel%40kortschak.io.
Re: [go-nuts] Re: use same for/range code on a hash map but it has different result
On Wed, 2020-11-11 at 06:02 +, 'Dan Kortschak' via golang-nuts wrote: > So long as you take into account these caveats, mutating a map during > a range will not corrupt the map or other data structure, and will > cause your application to crash. s/will cause/will not cause/ -- 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 https://groups.google.com/d/msgid/golang-nuts/a8ebd61d3dde809f3c955f8c0cb65e4632769d7d.camel%40kortschak.io.
Re: [go-nuts] Re: use same for/range code on a hash map but it has different result
On Tue, 2020-11-10 at 22:17 -0800, Kurtis Rader wrote: > Jeebus. H. Christ! Yes, you can "safely" mutate a map while iterating > over it. In as much as doing so will not result in a panic; although, > I'm not convinced that is true. The point of the O.P. is that they > expect the map mutation to always be visible. Yes, this is why I said it depends on how you define safely. As far as whether is is actually panic-safe, it's specified to be and so is a bug if it's now. Over the time I've been writing in Go, I have never seen a map mutation cause a panic unless due to a raced mutation. -- 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 https://groups.google.com/d/msgid/golang-nuts/f165b875506d79492d22045d7cdc7fdd428b8af8.camel%40kortschak.io.
Re: [go-nuts] detecting cyclic references
Or github.com/kortschak/utter . This package does an arguably better job at dealing with self- referencing structures. On Sat, 2020-11-14 at 03:52 -0800, twp...@gmail.com wrote: > > My use case is that I want to pretty print in-memory objects for > debug purposes during testing, and one of the features would be to > point out such cycles as this. > > Consider using an existing library for this, for example: > https://github.com/sanity-io/litter > https://github.com/davecgh/go-spew -- 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 https://groups.google.com/d/msgid/golang-nuts/e4c5f7bbc6a6390c004bf20fcef77db816cf4215.camel%40kortschak.io.
Re: [go-nuts] Let Go also support manual memory management, a good or bad idea?
This can already be done using C.malloc and C.free. You won't have access to map types using a Cgo allocator, but then you wouldn't if you had to allocate using built-ins either. On Sun, 2020-11-15 at 17:37 -0800, tapi...@gmail.com wrote: > For example, by adding two new built-in functions: alloc and free, > garbage collector will ignore the memory allocated by alloc. The > memory allocated by alloc must be freed by calling the free function > manually. > > This would relieve the burden of GC for some Go programs (such as > games). -- 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 https://groups.google.com/d/msgid/golang-nuts/f24b2a031553e63231cfb156ad6ee43fd86c7687.camel%40kortschak.io.
Re: [go-nuts] Go modules in gihub repos
You should tag the version with the path to the module root: for example path/from/root/v1.2.3 On Thu, 2020-11-19 at 18:58 -0800, Victor Denisov wrote: > Hi, > > I've recently encountered an interesting behavior of go modules. > I have a library in a repository on github. The go.mod file for this > library is not in the root directory of the repo. I create a signed > tag in the repo, say v1.2.3. > However when I try referring the full path to the module in the > go.mod of my application that uses this library I can't do it because > go build complains that ref v1.2.3 is not found. > > The line that I specify in my go.mod looks as follows: > github.com/username/reponame/path/from/root v1.2.3 > > However when I don't specify anything in the go.mod of my > application, go build successfully finds the module however it uses > absolute version reference in go.mod > github.com/username/reponame/path/from/root v0.0.0-date-commitid > > Can someone comment on this topic? I'm trying to understand whether > it's ok to have go.mod not in the root directory. Is this behavior > intentional or just a coincidence. > > Thanks in advance, > Victor. > > -- > 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 > https://groups.google.com/d/msgid/golang-nuts/65736f44-901b-435a-990f-7f6ee9dde588n%40googlegroups.com > . -- 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 https://groups.google.com/d/msgid/golang-nuts/3c1c0d314bc2bd519a06035d940ae4c8ba5ab8c1.camel%40kortschak.io.
Re: [go-nuts] Go modules in gihub repos
Reference: https://golang.org/ref/mod#vcs-version > If a module is defined in a subdirectory within the repository, that > is, the module subdirectory portion of the module path is not empty, > then each tag name must be prefixed with the module subdirectory, > followed by a slash. For example, the module golang.org/x/tools/gopls > is defined in the gopls subdirectory of the repository with root path > golang.org/x/tools. The version v0.4.0 of that module must have the > tag named gopls/v0.4.0 in that repository. On Thu, 2020-11-19 at 19:28 -0800, Victor Denisov wrote: > Interesting. Thanks, I'll give it a try. > -- 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 https://groups.google.com/d/msgid/golang-nuts/79bc923dbe22db64eca54e2445c97049825d109e.camel%40kortschak.io.
Re: [go-nuts] Online service to run Go code with Go modules support
It does, but it depends on how big of a dependency set is imported due to timeout. The example below does work. https://play.golang.org/p/WL-OhWYsx68 On Fri, 2020-11-20 at 22:45 +, Paul Jolly wrote: > Hi, > > > Hi go devs. I am thinking about brining up a service that would > > execute Go code with support of third party modules, so that both > > Go modules developers and users could play with a code and get > > immediate results without having any Go environment, through a > > browser. > > I've noticed that there are some similar services in the scene > > right now, including goplay.space and play.golang.org but they > > seems do not support third party modules usage. > > play.golang.org does support third party modules, at least importing > them: https://play.golang.org/p/2dHQwOa7_gn > > On a related note, last week we released https://play-with-go.dev/ > which is designed to provide people with an interactive introduction > to the tooling required to work with the Go programming language. The > authentication is required because each guide instance is connected > to > a remote container which effectively gives you a full blown > development environment in the browser alongside the guide (there is > even the option for us to serve VSCode in a similar way, allowing the > user to edit files in the remote session). But as > https://play-with-go.dev/go-fundamentals_go115_en/ demonstrates, not > only does it provide you with a complete development environment, but > guides are automatically provisioned with remote source code > repositories as required. So you interactively follow the publishing > of a real module, that is then resolved via the proxy. > > > PS Additionally there might my different OS support ( Linuxes > > distros ) so that code would be executed on respected dockers with > > targeted OS internally, for people doing arch dependent > > applications. > > With play-with-go.dev we have also explored the possibility of the > user choosing the platform on which the guide should run, which would > also vary the commands needed to run the guide as necessary. > > If play-with-go.dev is of any interest I'd be happy to talk about > that > more (it's an open source project, supported by sponsorship) > > > Paul > > -- > 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 > https://groups.google.com/d/msgid/golang-nuts/CACoUkn6pdz228J7s0%3D8sd-tTYNjhTVUmPG%2BH23YyPaA4C_Y9Dg%40mail.gmail.com > . -- 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 https://groups.google.com/d/msgid/golang-nuts/daaa3c453224985db3ad63c4cbe4c172bfa3cae5.camel%40kortschak.io.
Re: [go-nuts] Online service to run Go code with Go modules support
That's not an error. https://github.com/rsc/quote/blob/754f68430672776c84704e2d10209a6ec700cd64/quote.go#L22-L24 On Fri, 2020-11-20 at 17:49 -0800, Alexey Melezhik wrote: > Thanks. I receive " Don't communicate by sharing memory, share memory > by communicating. " error (?) when run the example > -- 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 https://groups.google.com/d/msgid/golang-nuts/e8d28674d78984e3142bb9f31bf7f872f2588655.camel%40kortschak.io.
[go-nuts] using the xml package with data with complex name spacing
I'm needing to consume some XML which has a namespace identifier reused. http://purl.obolibrary.org/obo/go/subsets/goslim_yeast.owl#"; xml:base="http://purl.obolibrary.org/obo/go/subsets/goslim_yeast.owl"; xmlns:go="http://purl.obolibrary.org/obo/go#"; xmlns:obo="http://purl.obolibrary.org/obo/"; xmlns:owl="http://www.w3.org/2002/07/owl#"; xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; xmlns:xml="http://www.w3.org/XML/1998/namespace"; xmlns:xsd="http://www.w3.org/2001/XMLSchema#"; xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"; xmlns:terms="http://www.geneontology.org/formats/oboInOwl#http://purl.org/dc/terms/"; xmlns:oboInOwl="http://www.geneontology.org/formats/oboInOwl#";>; http://purl.obolibrary.org/obo/go/subsets/goslim_yeast.owl";>; http://purl.obolibrary.org/obo/go/2020-12-08/subsets/goslim_yeast.owl"/>; I'm wondering if I can do this with out directly interacting with a token stream. https://play.golang.org/p/5y0LGh-MbGE thanks -- 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 https://groups.google.com/d/msgid/golang-nuts/c260a95b4229b48d4fce89c84f3c094079229caf.camel%40kortschak.io.
Re: [go-nuts] using the xml package with data with complex name spacing
On Mon, 2020-12-14 at 13:53 +, Sam Whited wrote: > In the example you provided it is working as expected. The element > you're unmarshaling is in the " > http://www.w3.org/1999/02/22-rdf-syntax-ns#"; namespace (it has an > "rdf" > prefix) but the thing you're unmarshaling it into expects > "http://purl.obolibrary.org/obo/go/subsets/goslim_yeast.owl#"; because > you > put that in the tag. > > If you change the namespace in the struct to the correct one > everything will work. > > —Sam Thanks, Sam. I figured it would be something simple like that. I ended up skirting the issue; I do start with parsing the token stream and then using the Decoder.DecodeElement on specific start elements (for reasons entirely unrelated to the original questions). Dan -- 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 https://groups.google.com/d/msgid/golang-nuts/6f77aef8da7260a47cbb8e428b0bfb074100403a.camel%40kortschak.io.
Re: [go-nuts] printing an empty slice with fmt.Printf()
I think that's the question. Here's a simpler example,
https://play.golang.org/p/9Kv3PhlM-OF
That is, is 00 an expected %02x representation of a zero-length byte
slice?
The answer to that is yes; the 02 forces leading zeros. The %x verb
essentially renders bit strings as hex, so a zero-length bit string
with mandated two leading zeros is 00.
If you leave out the 02, you get the expected empty string.
https://play.golang.org/p/uVFt3lecKxf
On Fri, 2020-12-18 at 15:38 -0800, Marcin Romaszewicz wrote:
> It's expected behavior.
>
> Your for loop runs once for l=0, since your condition is <=0 because
> len([]byte{}) is 0.
>
> -- Marcin
--
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
https://groups.google.com/d/msgid/golang-nuts/f2ca98609ca0992e0a734022584cb5a95e605175.camel%40kortschak.io.
Re: [go-nuts] Generics - please provide real life problems
I agree. A lot of Gonum code would be greatly simplified with the availability of generics, particularly the linear algebra part. The graph packages would be richer and we could do more things with tensor-like operations. On Wed, 2020-12-23 at 23:54 -0800, Marcin Romaszewicz wrote: > Those are simple examples of real world problems. I've been writing > Go since the very beginning, having worked at Google when it was > released and since I enjoy the language so much, I try to write all > the backend server code in Go that I can. In these years, I've had to > write many code generators to make my life a little easier, and they > tend to be for data structures or API models. > > Generics would allow for writing less code, and re-using it more. As > long as it doesn't complicate the base language, why not? You don't > have to use them :) > > On Wed, Dec 23, 2020 at 11:18 PM Martin Hanson < > greencopperm...@yandex.com> wrote: > > I'm sorry, but this is not real life problems. This is exactly the > > problem with this proposal. It's based on nothing but small > > theoretical examples. > > -- 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 https://groups.google.com/d/msgid/golang-nuts/06457ed1f86e399d7d00e3c7605d32130c96641c.camel%40kortschak.io.
Re: [go-nuts] Obtaining an efficient hash for Go values
You can also use the internal map implementation and make us of the
runtime's map iterator. This is relatively straightforward at the cost
of vigilance for changes in the runtime.
Here is an example (note that yo need a .S file as well to get the
go:linkname magic to work).
https://github.com/gonum/gonum/blob/master/graph/iterator/map.go
(we back this with a reflect equivalent that it provided by
https://golang.org/pkg/reflect/#MapIter.
Dan
On Thu, 2020-12-24 at 02:18 -0800, Arnaud Delobelle wrote:
> Hi there!
>
> In my continued efforts to improve the performance of my Go Lua
> implementation [1], I have reached a bottleneck which causes me a
> quandary.
>
> Lua has a data structure which is called 'table', which is
> essentially a hashmap. So far I have implemented it as a Go map,
> which works OK. However there is significant overhead coming from
> the fact that Lua has a `next` function that allows getting the
> "next" key-value pair in a table after a given one: `next(t, key)`.
> As far as I can tell Go doesn't allow this so if I want to use a Go
> map, I also have to keep track of the next key for each key, which
> doubles the memory requirement, necessitates more accounting in the
> code and makes iteration via `next` slower.
>
> So I am looking at not using the builtin Go map and making my own
> hashtable implementation. However, because the keys are still made
> of Go values, I would like to benefit from the quick hashing that
> maps use. After some poking around in the implementation of map (and
> discovering the //go:linkname compiler directive), I think that I can
> do this:
>
>
> // This is the Lua Value type. The scalar part contains the payload
> of int64, float64 or bool for quicker access and minimising
> allocations.
> type Value struct {
> scalar uint64
> iface interface{}
> }
>
>
> //go:linkname goRuntimeInt64Hash runtime.int64Hash
> //go:noescape
> func goRuntimeInt64Hash(i uint64, seed uintptr) uintptr
>
> //go:linkname goRuntimeEfaceHash runtime.efaceHash
> //go:noescape
> func goRuntimeEfaceHash(i interface{}, seed uintptr) uintptr
>
> // Hash returns a hash for the value.
> func (v Value) Hash() uintptr {
> if v.scalar != 0 {
> return goRuntimeInt64Hash(v.scalar, 0)
> }
> return goRuntimeEfaceHash(v.iface, 0)
> }
>
> Does that sound like a sensible approach? I.e. is it safe enough to
> use the go:linkname directive, and do those seem like the right
> functions to call to obtain a good hash?
>
> TIA
>
> --
> Arnaud
> --
> 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
> https://groups.google.com/d/msgid/golang-nuts/79e3f124-037c-4c10-a7b6-42f496bd26b6n%40googlegroups.com
> .
--
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
https://groups.google.com/d/msgid/golang-nuts/d2d742dcbb9ddf7d495255c9efdef2ec01e35096.camel%40kortschak.io.
Re: [go-nuts] Re: Generics - please provide real life problems
On Fri, 2020-12-25 at 18:11 +0100, Martin Hanson wrote: > > What are you on about!? This is my second post on this list, and even > though both are about > generics, they are adequately different to be kept about otherwise it > becomes a big mess. Some mailers do not properly handle headers necessary for list threading (providing a References: header to referred-to message). This appears to be the case with the mailer(s) you are using; the two theads that you are writing into appear as 5 on my mailer (this most recent reply being it's own thread for example - it provided no references to previous messages but should have referred to < 20201225130054.wlctldlfxjf3hmuv@feather.localdomain>). -- 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 https://groups.google.com/d/msgid/golang-nuts/8dd9176b7104ac876aa1d3e331ec063358b6944b.camel%40kortschak.io.
Re: [go-nuts] Generics syntax suggestion
On Tue, 2021-01-19 at 20:01 +, Kevin Chadwick wrote:
> I was inquiring about the possibility of no identifiers or
> abstraction but simply like Gos non generic functions (possibly
> reversed if needed). Using type OR type.
>
> func (String | []byte firstInput, myType | publicKey
> secondInput) {
>
> firstInput[0]
> firstInput[[]byte]
> }
How does this encode the desire that parameter types match?
--
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
https://groups.google.com/d/msgid/golang-nuts/e8a2cd7d31c89f7aa3eced33f1ce9c43ef944dfe.camel%40kortschak.io.
Re: [go-nuts] Generics syntax suggestion
On Tue, 2021-01-19 at 21:09 +, Kevin Chadwick wrote:
> On January 19, 2021 8:22:01 PM UTC, 'Dan Kortschak' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
> > On Tue, 2021-01-19 at 20:01 +, Kevin Chadwick wrote:
> > > I was inquiring about the possibility of no identifiers or
> > > abstraction but simply like Gos non generic functions (possibly
> > > reversed if needed). Using type OR type.
> > >
> > > func (String | []byte firstInput, myType | publicKey
> > > secondInput) {
> > >
> > > firstInput[0]
> > > firstInput[[]byte]
> > > }
> >
> >
> > How does this encode the desire that parameter types match?
>
> These are the parameters. dynamic var firstInput must be a String or
> byte slice.
Yeah, that doesn't answer the question.
How do you make sure that types match where you have more than one
parameter where the types must match?
func find(s, pattern string | []byte) (string | []byte)
If find is looking for pattern in s and then returning it, how do you
indicate to the compiler that typeof(s) == typeof(pattern) and how do
you indicate what the return type is?
--
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
https://groups.google.com/d/msgid/golang-nuts/cf8b268b57abec5c45879dbcce70c80838206489.camel%40kortschak.io.
Re: [go-nuts] package is not in goroot
On Tue, 2021-01-19 at 13:54 -0800, Alexander Mills wrote: > i am getting this weird error message: > > package twitch/go-scripts/dynamo-creators-to-s3/lib is not in GOROOT > (/usr/local/Cellar/go/1.15.6/libexec/src/twitch/go-scripts/dynamo- > creators-to-s3/lib) > > my GOPATH=$PWD/scripts/go > > so there is only 1 GOPATH Packages that are not in GOROOT must have a dot in the first path element. Your import path doesn't; it's "twitch". -- 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 https://groups.google.com/d/msgid/golang-nuts/3e1a5f86d1cb6724deeb48cdc4017b3a94f459ef.camel%40kortschak.io.
Re: [go-nuts] Generics syntax suggestion
On Tue, 2021-01-19 at 22:44 +, Kevin Chadwick wrote: > On January 19, 2021 9:13:55 PM UTC, Levieux Michel < > mlevieu...@gmail.com> wrote: > > I think the question was: "given your proposal here, I can write > > func > > (string | []byte in1, string | []byte in2) which enforces that in1 > > and > > in2 > > must be either of type string or type []byte, but how do I tell the > > compiler that in1 and in2 must be of the *same type* (whether it is > > string > > or []byte) ? " > > > > You could always use a well placed &. That isn't the point. 😉 What? How does that help? -- 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 https://groups.google.com/d/msgid/golang-nuts/ca069c336bf0dd981b1a7ee1306d5f47e39f40df.camel%40kortschak.io.
Re: [go-nuts] package is not in goroot
On Tue, 2021-01-19 at 16:08 -0800, Alexander Mills wrote: > I have never seen the dot needed, I have used plenty of packages that > are in GOPATH but not GOROOT https://go.googlesource.com/go/+/go1.15.6/src/cmd/go/internal/search/search.go#542 This is why it is saying that it's expecting it to be in GOROOT. Why it can't find it? I don't know, but you haven't said what the error was in response to. -- 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 https://groups.google.com/d/msgid/golang-nuts/90e329865ddd24c1f50f0ca2fede17ff2ee37d2e.camel%40kortschak.io.
Re: [go-nuts] Interface arguments to generic functions
On Tue, 2021-01-19 at 19:38 -0800, Ian Lance Taylor wrote:
> On Tue, Jan 19, 2021 at 7:06 PM burak serdar
> wrote:
> >
> > In the following program, it is valid to pass an interface to
> > function P:
> >
> > func P[T fmt.Stringer](x T) {
> > fmt.Println(x)
> > }
> >
> > func main() {
> > var v fmt.Stringer
> > P(v)
> > }
> >
> > However, there is no way for P to check if x is nil. This does not
> > compile:
> >
> > func P[T fmt.Stringer](x T) {
> > if x!=nil {
> > fmt.Println(x)
> > }
> > }
> >
> > Is it possible to write a generic function that can test if its
> > argument with a constraint is nil?
>
> For an interface type the value "nil" is the zero value of the type,
> so this is the general zero value issue mentioned at
>
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#the-zero-value
>
> You can write
>
> func P[T fmt.Stringer](x T) {
> var zero T
> if x!=zero {
> fmt.Println(x)
> }
> }
>
> Ian
Would that work for non-comparable types? Say the T has an underlying
[]int type, then the comparison is not against nil and you end up with
a panic.
--
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
https://groups.google.com/d/msgid/golang-nuts/39dcaaa172cd6850c7d55b3e7330585c6060bc87.camel%40kortschak.io.
Re: [go-nuts] Interface arguments to generic functions
On Tue, 2021-01-19 at 21:38 -0800, Ian Lance Taylor wrote: > On Tue, Jan 19, 2021 at 8:41 PM Dan Kortschak > wrote: > > > > Would that work for non-comparable types? Say the T has an > > underlying > > []int type, then the comparison is not against nil and you end up > > with > > a panic. > > > Fair point. But I'm not sure what the goal is here. Perhaps if we > can define that we can figure out how to make it work. > > Ian I can see value in it; we use the pattern sometimes of allocating a slice for a nil destination and returning it or otherwise checking that lengths match. That pattern would not be possible with this issue. The use case would be single or double precision float slices. The same thing happens with maps sometimes too. -- 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 https://groups.google.com/d/msgid/golang-nuts/0cb8abb6dc49bab6743e4817fcef8b1ac0fb1fcc.camel%40kortschak.io.
Re: [go-nuts] How to improve the parallelism of go routine？
On Mon, 2021-02-01 at 23:48 -0800, 颜文泽 wrote: > This is my code: > 2021-02-02 15-45-01 的屏幕截图.png Please don't post code as images. -- 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 https://groups.google.com/d/msgid/golang-nuts/47e0791d802d01e56ac1526b226420a09047970a.camel%40kortschak.io.
Re: [go-nuts] R.I.P. Michael Jones
On Fri, 2021-02-05 at 00:12 +0100, Jan Mercl wrote: > https://www.geospatialworld.net/blogs/goodbye-michael-jones-the-man-who-gave-the-power-of-maps-in-our-hands/ Thank you for letting us know, Jan. He will be missed. -- 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 https://groups.google.com/d/msgid/golang-nuts/00a36c66d98982a36783d7cf3d29e877600a344d.camel%40kortschak.io.
Re: [go-nuts] Code style in golang compiler
On Mon, 2021-02-08 at 19:09 -0800, messi...@gmail.com wrote: > Hi, > > I'm reading the go compiler source code and found the following code > style in several places: > > > > Is there some special reasons to group n,m,p to a local struct? > > Why don't we just init n the following way: Maybe because the Node, Name and Param will all be allocated in a single contiguous allocation in the form that exists in the current tree. BTW Please don't post images for source code. -- 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 https://groups.google.com/d/msgid/golang-nuts/1c0b756066218868c4d4d095d21166be3ad9b604.camel%40kortschak.io.
Re: [go-nuts] big.Float.Cmp does not work as expected
On Sun, 2021-02-14 at 13:19 -0800, Santhosh Kumar T wrote: > When I print both values, they print exactly same. so I am assuming > no precision lost for this specific example 123.4. > but still Cmp returns non-zero. This is not a good assumption to make, and is refuted by the result of Cmp. https://play.golang.org/p/ROr6cHMzWIf -- 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 https://groups.google.com/d/msgid/golang-nuts/5635a54d86152c7617fdb05c9fe8b94b2040c9e0.camel%40kortschak.io.
Re: [go-nuts] big.Float.Cmp does not work as expected
You can set your precision arbitrarily high, but you will still find a point at which there are non-zero decimal digits. https://play.golang.org/p/JYcAvXQPfeO 123.4 cannot be represented in binary with a finite number of bits. On Sun, 2021-02-14 at 13:33 -0800, Santhosh Kumar T wrote: > now I understand it. why they are not same > > but why f2 printed as 123.4139 > f2 is constructed using SetString method, so it should be accurate > and printed as 123.4000. -- 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 https://groups.google.com/d/msgid/golang-nuts/7e80e8d2a324824f0c987ecc8fe0441cc70877d7.camel%40kortschak.io.
Re: [go-nuts] big.Float.Cmp does not work as expected
On Wed, 2021-02-17 at 02:33 +0530, Santhosh T wrote: > is there java's BigDecimal equivalent in golang ? There is, for example https://github.com/shopspring/decimal. But you should ask yourself why you need this. -- 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 https://groups.google.com/d/msgid/golang-nuts/9ec3d92f53e72009f0b5cbae61e8766a22522eff.camel%40kortschak.io.
Re: [go-nuts] Contrary to popular opinion...
On Sun, 2021-02-28 at 08:40 +0100, Jan Mercl wrote: > Actually Go has that problem as well, just a thousand times smaller. I'm curious where the meaningful whitespace is in Go (for amounts differences in number greater than 1). > FTR, I also think Python's approach to white space is a failure. But > its popularity seems to prove people think otherwise. The problem with python's approach is that it operated on the basis that error correcting redundancy in source code is not valuable. It is. Dan -- 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 https://groups.google.com/d/msgid/golang-nuts/baa6db5212f6c2d71e6d011faec073a558b02adb.camel%40kortschak.io.
Re: [go-nuts] Contrary to popular opinion...
On Sun, 2021-02-28 at 09:23 +0100, Jan Mercl wrote: > I meant, for example, in regexp notation, ` *` vs `\n *` between a > function signature and the opening brace of the function body. Ah, yes. > This assumes newline is a whitespace. Most programming languages > agree, but humans may not. With semicolon insertion, they're not. While they are white, they're qualitatively difference to horizontal white. Dan -- 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 https://groups.google.com/d/msgid/golang-nuts/070aa073f9c5c9d78a7d68bf9534fa37d701d384.camel%40kortschak.io.
Re: [go-nuts] Contrary to popular opinion...
On Sun, 2021-02-28 at 10:11 -0800, Bob Alexander wrote: > I never have understood the *serious* hatred of Python's "indentation > as syntax" approach. I've used lots of bracketed and begin/end > languages (C/C++, Algol & relatives, Ruby, and most other programming > languages), and when I write code in those languages I usually indent > as I write. Obviously, indenting makes it much easier for a human to > understand the program structure. It never occurred to me to code C, > for example, without indenting. Of course, the compiler doesn't mind > -- for the computer the brackets are easier to understand, but not > for humans. Indenting is better for humans and paired stack operations are better for machines. Having both is helpful. -- 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 https://groups.google.com/d/msgid/golang-nuts/4daf048d4292ac80a23ebd39ee13fdd16df0ff80.camel%40kortschak.io.
Re: [go-nuts] go install, replace directive any ongoing discussions?
On Sun, 2021-03-07 at 07:57 +, Paul Jolly wrote: > Erroring on replace directives is an intentional decision for now: > https://github.com/golang/go/issues/40276#issue-659471259 > > But might be relaxed in the future: > > > Parts of this proposal are more strict than is technically > > necessary (for > > example, requiring one module, forbidding replace directives). We > > could relax > > these restrictions without breaking compatibility in the future if > > it seems > > expedient. It would be much harder to add restrictions later. > > If you think this is a valid case for requiring non-directory replace > directives to be applied, then I suggest raising an issue with some > details. At the very least the documentation explaining the error in https://golang.org/cmd/go could be improved; the rationale for the error on that page is very opaque (and contradictory). -- 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 https://groups.google.com/d/msgid/golang-nuts/45def257cd9d0c7c345e8ad0a4bf1c8444bcf531.camel%40kortschak.io.
Re: [go-nuts] What does `go install path/to/main.go` do with GO111MODULE=on?
On Wed, 2021-03-10 at 15:20 -0800, Matt Mueller wrote: > I'm assuming this is by design, but it feels to me like go install > ./cmd/app/main.go silently failing is a bug. > > Is this worth opening an issue for? If it's a bug it's an error reporting bug. The go install command is documented to take only package paths, not file paths. ``` - Arguments must be package paths or package patterns (with "..." wildcards). They must not be standard packages (like fmt), meta-patterns (std, cmd, all), or relative or absolute file paths. ``` -- 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 https://groups.google.com/d/msgid/golang-nuts/576afdf00e604bb58633deabe2ca47cb5c3ae51a.camel%40kortschak.io.
Re: [go-nuts] [ANN] MQTT🤖
On Sun, 2021-03-14 at 10:41 -0700, Pascal de Kloe wrote: > New MQTT client library + command line tool available. > > https://github.com/pascaldekloe/mqtt > > Comments are welcome. Did you consider using context.Context rather than quit channels? -- 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 https://groups.google.com/d/msgid/golang-nuts/0ea2a07f2c5dc9ae17137bfff2f869e41e4da907.camel%40kortschak.io.
[go-nuts] addressing the issue of correlating built in structured types in generic code: float/complex
Now that a proposal for an approach to generics has been approved[1],
it seems like a good time to again[2] raise the issue of how to be able
to write code that has correlated types where types are structured but
built-in, and so fields are not available to examine. The only case of
this in the language is the relationship between float and their
corresponding complex types. So for example in the case of wanting to
write a simple generic Eigen Decomposition functions we would have
type Real interface {
type float32, float64
}
func Eigen[T Real](m, n int, data []T) (left, values, right []?, ok bool) { ...
but, there is currently no way to specify that []? is a slice of
complex(T, T).
Having a syntax for this is obvious; being able to write []complex(T,
T) in this place is entirely consistent with doing the same thing with
structs where the types of struct fields are visible to the language
user. Indeed, in the current generics proposal, the Gonum quaternion,
dual, hyperdual and dual quaternion number types are easier to
integrate into a generics system than the built in complex number types
because they are based on structs.
Similarly, general utility functions that would be useful in DSP to
interconvert between complex and real would be
func AsComplex[T Real](v T) ? /* a complex(T, T) */ { ...
type Complex interface {
type complex64, complex128
}
func Abs[T Complex](v T) ? /* a float of the correct size */ { ...
Where in the latter being able to write real(T) to specify the type of
the return value.
Dan
[1]https://blog.golang.org/generics-proposal
[2]https://groups.google.com/g/golang-nuts/c/dZIdMJTO5ws/m/nQbBk7NrBgAJ
--
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
https://groups.google.com/d/msgid/golang-nuts/f0234521fc7b4127244ae87dd9086ff7310f3dff.camel%40kortschak.io.
Re: [go-nuts] [ANN] MQTT🤖
On Sun, 2021-03-14 at 15:08 -0700, Pascal de Kloe wrote:
> > Did you consider using context.Context rather than quit channels?
>
> Applying a context.Context pretty much implies using a quit channel.
> Done is the only way to receive an expiry signal.
>
> I just don't want to lock code into using the context package. The
> context setup is quite viral. For example, there is no simple way to
> construct a context from a quit channel (for some reason).
>
> The mqtt package distinguishes between cancelation before and after
> submission. It is easy to flatten the error back into the context
> format. The explicitness may even help with understanding the
> consequences more clearly.
>
> err := Publish(ctx.Done(), []byte("Hello"), "demo/+")
> switch {
> …
> case errors.Is(err, mqtt.ErrCanceled), errors.Is(err,
> mqtt.ErrAbandoned):
> return ctx.Err()
> …
> }
Thanks. That's a yes.
Dan
--
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
https://groups.google.com/d/msgid/golang-nuts/e6677061f0e8e834fc55f913d4347ec6b54a66c7.camel%40kortschak.io.
Re: [go-nuts] Re: [ANN] New german translations
On Tue, 2021-03-16 at 03:10 -0700, Haddock wrote: > Anyhow, if I hear how young people are talking nowadays, it makes me > sick. Die Funktion wurde "gecalled" und die Exception "gethrown". > Sometimes I fear the next generation will not have learned to watch > what their mind is doing. I might be wrong. I hope so. It sounds like life imitating art. https://upload.wikimedia.org/wikipedia/commons/8/83/Blinkenlights-original.png -- 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 https://groups.google.com/d/msgid/golang-nuts/c321fe7d015e4d185c8a44cfe6ce4461baf914a7.camel%40kortschak.io.
Re: [go-nuts] Thanks
On Wed, 2021-03-24 at 22:09 +, alex breadman wrote: > Let's keep divisive political BS away from this lovely project. > > Glad to see the political header removed from the website, at least > on mobile. > > All lives matter. This too is a political statement. -- 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 https://groups.google.com/d/msgid/golang-nuts/9f652ac597da3b0fce061d1090f364af4795de31.camel%40kortschak.io.
Re: [go-nuts] Oopses in standard-library documentation
On Wed, 2021-03-24 at 18:31 -0700, Scott Pakin wrote: > I just noticed that some of the package comments in the standard > library are coming from the wrong source file. Here are two examples > from a golang.org/pkg/ screenshot: > > > In the case of the former, src/os/exec/read3.go appears to be missing > a newline between the package comment and package, and in the case of > the latter, src/runtime/mkduff.go appears to be the file at fault. > > Do I need to file a bug report, or is this a simple enough issue that > one of the developers can just make a quick pass through the source > code, adding the missing blank lines? > > — Scott Some of them appear to be due to godoc ignoring +build directives. For example, the crypto/x509 package has "Generates root_ios.go." which it's getting from here https://golang.org/src/crypto/x509/root_ios_gen.go. go/doc has a similar problem from https://golang.org/src/go/doc/headscan.go, and go/types from https://golang.org/src/go/types/gotype.go... In fact all of the ones I looked at appear to be due to this. Dan -- 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 https://groups.google.com/d/msgid/golang-nuts/bbcc80c6fb04a0f371dbfe3144a4c33a322a7dbe.camel%40kortschak.io.
Re: [go-nuts] Re: Parallel Matrix Multiplication
On Thu, 2021-03-25 at 14:20 -0400, jasm...@gmail.com wrote: > Blast from the past so it's hard to be sure, but I think that was how > many rows or columns to pick for parallel sub matrices to multiply. > > On Thu, Mar 25, 2021, 1:17 PM Gabriel Pcklub < > gabrielpckl...@gmail.com> wrote: > > Hello, what is Threshold constant in code for? I wanted to try your > > code, but with Threshold 1 it take all of 16GB RAM I have and crash > > on sigkill. When I use Threshold 8 it seems ok, but when I use 64, > > it again take a lot of RAM... I thought it's count of Threads that > > program will use, while running on CPU. But it does give unexpected > > or strange results. Yeah, it's essentially the minimum block size for parallel execution. At 1, it's attempting to work parallel the whole way down. This thread is almost as old as the language though. Dan -- 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 https://groups.google.com/d/msgid/golang-nuts/a0e439a53dfd0f91528073f8f7917ba53484b1b2.camel%40kortschak.io.
Re: [go-nuts] go text://protocol client?
On Fri, 2021-04-09 at 17:01 +0200, 'Petite Abeille' via golang-nuts wrote: > [1] https://textprotocol.org That's an extraordinarily and unnecessarily obtuse document. -- 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 https://groups.google.com/d/msgid/golang-nuts/e574b0fe6263008fed5f2da60b19282b0b6d14e3.camel%40kortschak.io.
[go-nuts] help with the Google Pub/Sub Go client API
I am trying to set up a toy to understand Google's Pub/Sub service Go
client API. I have had no trouble with publishing and have a local
emulator for the Google Scheduler service to build against, but I am
having a lot of trouble getting subscriptions to work.
I am able get a subscription to work with messages received if I first
create the topic using the Python example code.
This is the python from[1]:
```
from google.cloud import pubsub_v1
publisher = pubsub_v1.PublisherClient()
subscriber = pubsub_v1.SubscriberClient()
topic_path = publisher.topic_path(project, topic)
subscription_path = subscriber.subscription_path(project, subID)
# Wrap the subscriber in a 'with' block to automatically call close()
to
# close the underlying gRPC channel when done.
with subscriber:
subscription = subscriber.create_subscription(
request={"name": subscription_path, "topic": topic_path}
)
```
However, when I do what I understand to be the equivalent Go code, I am
unable to receive any messages.
This is what I take to be the equivalent Go code.
```
client, err := pubsub.NewClient(ctx, project)
if err != nil {
log.Fatalf("failed to create pubsub client: %v", err)
}
t, err := client.CreateTopic(ctx, topic)
if err != nil {
log.Fatalf("failed to create topic %q: %v", topic, err)
}
s, err := client.CreateSubscription(ctx, subID,
pubsub.SubscriptionConfig{Topic: t})
if err != nil {
log.Fatalf("failed to create subscription %q %q: %v", topic,
subID, err)
}
```
In both cases the message receiver code is as follows, though in the
case where python sets up the topic, this is prefaced with `s :=
client.Subscription(subID)` in place of the Go code above.
```
err = s.Receive(ctx, func(ctx context.Context, m *pubsub.Message) {
log.Printf("received: %#v", m)
m.Ack()
})
```
The complete code of the working toy (requiring python to set it up) is
here [2] and the non-working version is here [3].
thanks
Dan
[1]
https://github.com/googleapis/python-pubsub/blob/b8352f91c63e0cb7d64c4d0e557651248cd301b5/samples/snippets/subscriber.py#L66-L89
[2]https://play.golang.org/p/0kXLN8H-rCG
[3]https://play.golang.org/p/Fva4BYrtDXE
--
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
https://groups.google.com/d/msgid/golang-nuts/aa4b92bcd9138eb95ebe73cdb7483eea912649bf.camel%40kortschak.io.
Re: [go-nuts] Re: help with the Google Pub/Sub Go client API
On Mon, 2021-04-19 at 10:37 -0700, 'hong...@google.com' via golang-nuts wrote: > Is it possible for you to paste your yaml config file? At first > glance, nothing seems to be out of the ordinary, but I'd like to try > with the same configuration that you have to see if I missed > anything. Thanks, Alex. I resolved the issue. There were two parts: 1. As you surmise there was an typo in the config. 2. The topic was obtained in the subscriber using new topic creation `client.CreateTopic(ctx, topic)` rather than getting a topic reference `client.Topic(topic)` which I see now is incorrect (thought which is poorly explained in the documentation). The typo meant that when I did stumble onto the correct solution in the code, it still didn't work and the paradoxical behaviour of the python creation working for Go but not the other way around left me bewildered. I solved the issue by porting the pubsub cmdline[1] example that exists in v0.1.0 to the current release, v1.10.2, and seeing how it is done there. Some of the features appear to have been removed, but it is largely intact here[2]. By way of comment on the documentation examples, in the Go client code they are fragments without context, which makes them pretty poor learning material; having something like the cmdline example ties things together, so it's odd that it was dropped. I'm happy to donate the port back if you feel it's helpful to have. Dan [1]https://pkg.go.dev/google.golang.org/cloud/examples/pubsub/cmdline [2]https://github.com/kortschak/pubsub -- 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 https://groups.google.com/d/msgid/golang-nuts/ebb300d3797bed0663858d34c385744fef510234.camel%40kortschak.io.
Re: [go-nuts] Re: help with the Google Pub/Sub Go client API
Comments in-line.
On Mon, 2021-04-19 at 15:08 -0700, 'hong...@google.com' via golang-nuts
wrote:
> Ah, glad your issue was resolved. I did want to point out one thing:
>
> > 2. The topic was obtained in the subscriber using new topic
> creation
> > `client.CreateTopic(ctx, topic)` rather than getting a topic
> reference
> > `client.Topic(topic)` which I see now is incorrect (thought which
> is
> > poorly explained in the documentation).
>
> Getting the topic via `create.CreateTopic` or `client.Topic` should
> work
> for subscriber creation. Both return `pubsub.Topic` struct[1], which
> can
> be used to call `topic.Publish` and pass to subscription config.
> I quickly tested this to confirm, code here[2].
If I make this change to github.com/kortschak/scheduler
```
index 6f62da8..8f3fb87 100644
--- a/listener/main.go
+++ b/listener/main.go
@@ -133,7 +133,11 @@ topics should be subscribed to using the default
subscription config.
log.Printf("using default config: %v",
cfg.DefaultConfig)
subConfig = cfg.DefaultConfig
}
- subConfig.Topic = client.Topic(sub.Topic)
+ t, err := client.CreateTopic(ctx, sub.Topic)
+ if err != nil {
+ log.Fatalf("failed to create topic %q: %v", sub.Topic,
err)
+ }
+ subConfig.Topic = t
s, err := client.CreateSubscription(ctx, sub.ID, subConfig)
if err != nil {
if grpc.Code(err) == codes.AlreadyExists {
```
I see this error when I run scheduler and listener.
```
2021/04/20 08:02:58 available topics:
2021/04/20 08:02:58 projects/testing/topics/cron-job
2021/04/20 08:02:58 projects/testing/topics/cron-job-again
2021/04/20 08:02:58 subscribing to "cron-job" as "test-0"
2021/04/20 08:02:58 failed to create topic "cron-job": rpc error: code
= AlreadyExists desc = Topic already exists
exit status 1
```
The issue here is that the topic has already been created by the
publisher. This is where greater contextual information in the docs
would be helpful. My reading of the docs for *Client.Topic, "Topic
creates a reference to a topic in the client's project", was that there
would already have to be a *pubsub.Topic and that that would be *local*
(this last bit is not true — it was influenced by notions of file
references). Unfortunately the terseness of the docs don't help here.
> Lastly, with regards to the cmdline examples, I'm guessing this was
> removed because we had the official gcloud sdk `gcloud pubsub ...`.
> Although the gcloud sdk doesn't use the Go client, I think we didn't
> think it would be necessary to support two API surfaces.
My suggestion was not for use as a client, but as an integrated
example.
> We do keep our code samples in our golang-samples[3] repo,
> and I'm not sure if it was these samples that you found were
> hard to navigate,
It's not that they are hard to navigate, the docs in
https://cloud.google.com/pubsub/docs/samples is very navigable, it's
just that the scale of the context for them is not very useful being
only slightly larger scale than a reader would get from the godoc. The
context could be improved either by reducing the terseness of the godoc
(for example saying for *Client.CreateTopic that *Client.Topic should
be used if the *Topic has already been created), or by providing actual
runnable examples in the form of example tests, which pkg.go.dev does a
reasonably good job of turning into main packages.
> but if so, we're very much open to feedback. I think I can sort of
> see your point of how the cmdline example is easier to read (with it
> being all in one file), but it's part of the repo's style to keep
> code samples in separate files.
It's not so much that they are separate files, but rather that there is
little contextual information showing how they should be composed.
> For learning, I'll work on adding a more comprehensive end-to-end
> guide that lives in the package docs instead.
Yes, I think this would be a good way to go. It doesn't need to be
extensive, just hitting a reasonable set of common compositions and
uses.
thanks
Dan
> [1] https://pkg.go.dev/cloud.google.com/go/pubsub#Topic
> [2] https://play.golang.org/p/Vpe6RxP6Db3
> [3]
> https://github.com/GoogleCloudPlatform/golang-samples/tree/master/pubsub
--
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
https://groups.google.com/d/msgid/golang-nuts/b610b7eb25b43bc572a8f67162ada4b0c8cef73e.camel%40kortschak.io.
[go-nuts] rationale for math.Max(1, math.NaN()) => math.NaN()?
This is not something that I've thought about before, but the behaviour
of math.Max when only one of its arguments is NaN does not agree with
the C convention or the IEEE-754 standard behaviour for max (5.3.1 p19
"maxNum(x, y) is the canonicalized number y if x
#include
void main() {
printf("%f\n", fmax(1, nan("")));
}
~ $ gcc -o a.out n.c
~ $ ./a.out
1.00
and in Go
~ $ cat n.go
package main
import (
"fmt"
"math"
)
func main() {
fmt.Println(math.Max(1, math.NaN()))
}
~ $ go run n.go
NaN
--
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
https://groups.google.com/d/msgid/golang-nuts/847aef7e13affb06ad098f1aafbd6b4ad1be7ae3.camel%40kortschak.io.
Re: [go-nuts] rationale for math.Max(1, math.NaN()) => math.NaN()?
On Mon, 2021-04-26 at 23:28 -0700, christoph...@gmail.com wrote: > It seam that C is wrong on this one and Go is right. The rationale is > that a NaN must propagate through operations so that we can detect > problems (avoid silent NaNs). See https://en.wikipedia.org/wiki/NaN > > Thus any operation involving a NaN must return an NaN and this > includes Max and Min. This is not what the IEEE 754 spec says for the behaviour of minNum and maxNum. Whether a language decides to implement their min and max functions according to the IEEE 754 spec is up to them. Note that Go uses non-signalling NaN's and claims to use IEEE 754 floating point numbers (https://golang.org/ref/spec#Numeric_types). So we'd expect it to have the behaviour specified in the 754 spec. This is why I asked the question. Jesper's answer highlighted subtlety that is worth considering. -- 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 https://groups.google.com/d/msgid/golang-nuts/7bbb6c9daf86ae6010a273d603cb9e4c9dae743b.camel%40kortschak.io.
Re: [go-nuts] How can I check error types of gRPC calls?
On Sat, 2021-05-15 at 04:47 -0700, cpu...@gmail.com wrote:
> In my local code, I'm using things like
>
> if errors.Is(err, api.ErrMustRetry) { ... }
>
> How would I achieve the same on errors returned by the gRCP
> interface? I've noticed these are wrapped:
>
> rpc error: code = Unknown desc = must retry rpc error: code = Unknown
> desc = must retry
>
> I assume the errors package won't work here as type information is
> not carried across gRPC: What is the best practice here: unwrap the
> root error from the RPC result (how) and perform string comparison?
>
There is the status package which provides tools for examining the gRPC
errors, https://pkg.go.dev/google.golang.org/grpc/status.
--
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
https://groups.google.com/d/msgid/golang-nuts/1ab47e32ab024c2637e199d85b49601b35e54c52.camel%40kortschak.io.
Re: [go-nuts] SetMapIndex() equivalent for slice/array
On Fri, 2021-06-04 at 20:29 -0700, Deiter wrote: > The reflect package provides the SetMapIndex method for updating > elements in a map that are represented by a reflect.Value type, but I > don’t see an equivalent for array/slice. > The sample app (link provided below) includes an example of map > that’s been made accessible through a a reflect.Value type variable. > One of the elements in the map is updated using SetMapIndex. > The sample app also includes an example of a slice containing exactly > the same data as the map. As far as I can tell, the only way to > update an element of the slice through a reflect.Value type variable > is to introduce unsafe package > Is there a better way that I’m missing that doesn’t require the use > of the unsafe package > SetMapIndex() equivalent for slice/array You can call Set on the reflect.Value returned by Index of a slice or array. slice: https://play.golang.org/p/b1NscgQ7UC5 array: https://play.golang.org/p/xCAGuTL5Wbl -- 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 https://groups.google.com/d/msgid/golang-nuts/094a3f661bdf02b629dd204eb2bec0e5bcb8135a.camel%40kortschak.io.
Re: [go-nuts] Why the limit on regex repeat is 1000?
On Sun, 2021-06-06 at 18:14 +1000, Rob Pike wrote: > You are using a steamroller to press a shirt. Tomi Ungerer has already published this approach. https://kotonoha-books.ocnk.net/data/kotonoha-books/product/20160619_70ddf5.JPG -- 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 https://groups.google.com/d/msgid/golang-nuts/6d839ad594ef4430a56c936443e28ab9dc71eeea.camel%40kortschak.io.
Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?
On Sun, 2021-06-06 at 03:17 -0700, Brian Candler wrote: > When you assign a regular (non-pointer) value to an interface > variable, it does take a copy of that value: > https://play.golang.org/p/XyBREDL4BGw It depends on whether it's safe to leave uncopied or not. You can see this here https://play.golang.org/p/q1729cX09BQ -- 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 https://groups.google.com/d/msgid/golang-nuts/e77e2a94d0c16514e74340a891f02e118e185d59.camel%40kortschak.io.
