Re: [go-nuts] var errors stdlib
On Fri, 2024-05-10 at 04:24 -0700, Sebastian Bogan wrote:
> Hello Everyone,
>
> I was wondering, what was / is the reason for exposing errors as
> public vars - rather than constants? Doesn't that impose some risk?
>
> For example:
>
> fs.ErrNotExist = errors.New("foo")
> _, err = os.ReadFile("./invalid")
> if !errors.Is(err, fs.ErrNotExist) {
> fmt.Println("is NOT fs.ErrNotExist")
> }
>
> Would something like the following work (and be less risky)?:
>
> type ConstError string
> func (e ConstError) Error() string {
> return string(e)
> }
> const ErrNotExist = ConstError("file does not exist")
>
Interface values cannot be consts per the spec. But to address the
concern, if some malicious or misguided package in your imports
reassigns a value to an exported error var, the example you show would
still work since the value is still common to all users of the var. If
the check were against the string returned by the Error method there
would be a problem, but that is advised against already. It could
potentially be a source of race conditions if the import made the
change after init and the read were happening in goroutine.
There are issues in the tracker that discuss const values,
https://go.dev/issue/6386 is probably a good place to start.
--
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/c6794b216ee037e870621e650467fc0c6cb03437.camel%40kortschak.io.
Re: [go-nuts] Re: couldn't print numbers ordered with goroutine
On Sun, 2024-04-21 at 15:06 +1200, Justin Israel wrote: > And really I wasn't even commenting on the nature of the channel. > Only the scheduling of the goroutines. Buffered or not, they would > still be random order right? Absolutely. Your answer was spot on. The issue is the ordering of the goroutines' execution, not the behaviour of channels. I just wanted to clarify the comment that responsed to that. -- 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/7d71acf0bcf19fbf2ddb5264485f328e08f323fa.camel%40kortschak.io.
Re: [go-nuts] Re: couldn't print numbers ordered with goroutine
On Sat, 2024-04-20 at 18:55 -0700, Robert Solomon wrote: > channels are not queues, as Justin said They can be; buffered channels are queues. >From https://go.dev/ref/spec#Channel_types > Channels act as first-in-first-out queues. For example, if one > goroutine sends values on a channel and a second goroutine receives > them, the values are received in the order sent. -- 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/05501e4c795fdcb4b91ffa3c35f95984772c9cde.camel%40kortschak.io.
Re: [go-nuts] why math.Pow gives different results depending on exp type
On Fri, 2024-04-19 at 22:51 -0700, DrGo wrote:
> ```
> package main
>
> import (
> "fmt"
> "math"
> )
>
> func main() {
> fmt.Printf("%g\n", 1-(math.Pow(0.6, 1/13))) //result=0
> fmt.Printf("%g\n", 1-(math.Pow(0.6, 1.0/13))) //
> result=0.038532272011602364
> }
> ```
1/13 is 0 since both parts of the expression are int, and so it
truncates. After this, it is converted to 0.0. So you have 0.6^0 which
is 1.
https://go.dev/play/p/tq2VAPIWXCy
--
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/57f6740ba2d3e8df8fd4e30402eabb241a6af81b.camel%40kortschak.io.
Re: [go-nuts] Re: Trying to understand aversion to main package
On Wed, 2024-02-14 at 15:31 -0800, Jeremy French wrote: > I really think the testability issue is the biggest one. Generally, > testing the main package iscumbersome at least. So it's > reasonable to say, "I'm not going to test the main package, but I > will keep it so simple that it is impossible for a bug to exist in > there." Then everything else in your application can be easily and > thoroughly tested with the built-in testing tools. It's stronger than this. With a Main() int, you can use e.g. https://pkg.go.dev/github.com/rogpeppe/go-internal/testscript for testing complete application behaviour. -- 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/9cab6b0ce8791aed8c85afb0458c007e401ec257.camel%40kortschak.io.
Re: [go-nuts] big int panic on text conversion
On Wed, 2024-02-14 at 12:24 +0100, Jan Mercl wrote: > On Wed, Feb 14, 2024 at 12:14 PM 'Dan Kortschak' via golang-nuts > wrote: > > > Given that this can happen without a race or unsafe modifications > > it > > might be worth filing a issue for. > > I think this is expected. Quoting from the big.Int docs > https://pkg.go.dev/math/big#Int > > > To "copy" an Int value, an existing (or newly allocated) Int must be > set to a new value using the Int.Set method; shallow copies of Ints > are not supported and may lead to errors. > > > But OP's 'b := *a' is creating a shallow copy. You are absolutely right. I looked for this kind of warning, but obviously not hard enough. -- 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/0935c8c90863d3144ea225ea78d233ad89bbdc9b.camel%40kortschak.io.
Re: [go-nuts] Trying to understand aversion to main package
On Wed, 2024-02-14 at 03:12 -0800, Jerry Londergaard wrote:
> I see quite a few modules out there where they seem to be putting in
> as little into the main package as possible. Literally they will
> sometimes be a few lines:
> ```
> import foobar
> func main() {
> os.Exit(foobar.Run())
> }
> ```
> Yet then go on to do all the things I would've thought are the domain
> of a main package, in the foobar package, like arg parsing, pulling
> in config items from env vars, setting up deps etc, and then running
> the actual thing.
>
> Why not just put that code into the actual main package? Sure, maybe
> not all into the main *function* itself, but in the main package at
> least.
>
> I understand that you don't want to be putting any real business
> logic into that main package, but I'm just talking about entry point
> type specific stuff. People might say they want to keep main 'light',
> but sometimes it feels like it's a competition to have the fewest
> lines as possible in the main package.
>
> kube-proxy[1] is an example of this. Maybe this starts to make more
> sense when the amount of code you would be putting into main become a
> lot, kube-proxy may qualify for this, but I see other cases where I
> don't understand the reasoning.
>
> Certainly not all are like that[2], but in some circles that I travel
> it seems to be a common way of thinking.
>
> Am I missing something ?
>
This can be used for testing the complete application.
--
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/0f07a7e73982c48ed8f77cf6b5d2b32c71e807d2.camel%40kortschak.io.
Re: [go-nuts] big int panic on text conversion
On Wed, 2024-02-14 at 02:07 -0800, Poonai wrote:
> Thanks all,
>
> figured out the issue:
>
> func main() {
> a := big.NewInt(1)
> b := *a
> c := *a
> c.Sub(, big.NewInt(1))
> fmt.Println(b.String())
> fmt.Println(c.String())
> fmt.Println(a.String())
> }
>
>
> reproducible code. don't know what causing it tho :(
Minimised: https://go.dev/play/p/oL17vkcjaEl
This is happening because the sum in a doesn't result in a
normalisation of b, https://go.dev/play/p/cIBDbRXFnAT (in this
situation where the abs field represents a zero, it should be zero
length).
Given that this can happen without a race or unsafe modifications it
might be worth filing a issue for.
--
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/6823242c8654f406db5dfc2bb04d1ca0efa51139.camel%40kortschak.io.
Re: [go-nuts] big int panic on text conversion
On Tue, 2024-02-13 at 21:35 -0800, Poonai wrote:
> big int panics during text conversion randomly
>
> stack trace:
>
> panic: runtime error: index out of range [1] with length 1
>
> goroutine 2088184 [running]:
> math/big.nat.itoa({0xc01db71500, 0x1, 0x199?}, 0x0, 0xa)
> /usr/local/go/src/math/big/natconv.go:340 +0x3d2
> math/big.(*Int).Text(...)
> /usr/local/go/src/math/big/intconv.go:25
> math/big.(*Int).String(...)
> /usr/local/go/src/math/big/intconv.go:40
>
> It shows up randomly, help me debug
I think you have probably ended up with a zero big.Int with a non-zero
length abs field. This is likely either from unsafe manipulation or a
race.
The crash can be replicated thus https://go.dev/play/p/WV78xvsbn4m
--
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/887305154dab7b435f14d8e5e1278742aa62deb7.camel%40kortschak.io.
Re: [go-nuts] Re: need a package to read/write shell history flat file database
On Sat, 2024-02-10 at 21:01 -0800, Kurtis Rader wrote: > The only solution I can find that gets close to my requirements is > https://github.com/ergochat/readline, but AFAICT it does not handle > updates to the on-disk history file by concurrently executing > processes. There is also https://pkg.go.dev/github.com/peterh/liner, which also does not handle history persistence, but which makes it relatively easy to add. -- 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/e37a98a811c8e1cccfef8feffafef5260e7e5e56.camel%40kortschak.io.
Re: [go-nuts] Incorrect "missing return" error for an edge case
On Mon, 2024-01-08 at 06:21 +0100, 'Axel Wagner' via golang-nuts wrote:
> The "missing return" error is defined in the spec, by requiring a
> function to end in a terminating statement:
> https://go.dev/ref/spec#Terminating_statements
> The list is necessarily not complete. So it is necessarily more
> advisory than anything else. What things to put in is mainly limited
> by how much complexity it would be to specify it and how important we
> deem it. Specifying this case seems pretty hard to specify (note that
> `i` could be modified in the loop body, so this always terminating
> requires some pretty complex statements about what is or is not in
> the loop body - in particular, if you want to do it on a purely
> syntactical level).
> It also also can be replaced by `func TestMethod() int { return 0 }`,
> which is strictly better, more readable code, so I wouldn't even
> necessarily agree that it's a false-positive error message: You
> *should* fix that.
>
>
>
> On Mon, Jan 8, 2024 at 5:32 AM burak serdar
> wrote:
> > This question came up on Stack Overflow today:
> >
> > The following code is giving a "missing return" error where it
> > shouldn't:
> >
> > func TestMethod() int {
> > for i := 0; i < 10; i++ {
> > return 0
> > }
> > }
> >
> > Looks like an overlooked case in control flow analysis.
> >
The case here is covered by point 5 of the terminating statements
definition. It is a for loop with a loop condition, so it is not a
terminating 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/dc021e72298ce84c5a979b6d974cf72abd482c6c.camel%40kortschak.io.
Re: [go-nuts] Re: How to get net.Conn in rpc function in net/rpc
On Thu, 2023-12-28 at 13:14 -0800, 'Christian Stewart' via golang-nuts wrote: > I agree with what Brian said and would like to suggest the following > two way RPC library with multiplexing over a single connection of any > type: > > https://github.com/aperturerobotics/starpc > There is also https://pkg.go.dev/golang.org/x/tools/internal/jsonrpc2_v2 which is unfortunately internal, but is extracted mechanically to https://pkg.go.dev/github.com/kortschak/jsonrpc2 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/c0496d19a42b644cc99f4d890051b591db66162a.camel%40kortschak.io.
Re: [go-nuts] Need help running "go get" on self hosted git server
On Sun, 2023-12-17 at 07:06 -0800, Brijesh Wawdhane wrote: > I added a go-import meta tag to my git server's website on the repo > page and it looks like > > https://brijesh.dev/kairos.git;> > > but when I try running "go get brijesh.dev/kairos" I get an error > saying 'go: unrecognized import path "brijesh.dev/kairos": reading > https://brijesh.dev/kairos?go-get=1: 404 Not Found' > > it is probably because it is looking at > https://brijesh.dev/kairos?go-get=1(which is invalid) and not > https://brijesh.dev/kairos.git?go-get=1(the correct address) even > though it the url is with .git in the go-import tag If you go to the page for the repo[1] with a browser and attempt to follow the link for the commit[2], it gives a 404, so the server seems sick. [1]https://brijesh.dev/kairos.git [2]https://brijesh.dev/kairos/commit/fa700f82d14a5a319cb6267a7dbde994683067ca -- 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/5106cb1b23fdd2547486156e05c6910122ce9e0a.camel%40kortschak.io.
Re: [go-nuts] Re: Is "When in doubt, use a pointer receiver" misleading advice?
On Mon, 2023-11-13 at 19:38 -0800, Mike Schinkel wrote: > I have been wondering for a while why the advice against mixing > pointer and value receivers, which GoLang so often flags me for > doing. https://dave.cheney.net/2015/11/18/wednesday-pop-quiz-spot-the-race -- 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/3cc8112142c151ffea7fe640a2e7150fafcf202d.camel%40kortschak.io.
Re: [go-nuts] Re: Clace: Secure web application development platform using Starlark
On Tue, 2023-10-31 at 02:50 -0700, Jason E. Aten wrote: > > > On Tuesday, October 31, 2023 at 3:12:13 AM UTC Dan Kortschak wrote: > > The Mozilla FAQ https://www.mozilla.org/en-US/MPL/2.0/FAQ/ appears > > to > > think it's OK. > > > > > Q13: May I combine MPL-licensed code and BSD-licensed code in the > > > same executable program? What about Apache? > > > > > > Yes to both. Mozilla currently does this with BSD-licensed code. > > > For > > > example, libvpx, which is used in Firefox to decode WebM video, > > > is > > > under a BSD license. > > > That is the other way around, not the situation under discussion. > i.e. There is a difference > between Apache input1 + MPL input2 -> MPL (for the combined output > work), versus > Apache input1 + MPL input2 -> Apache licensed combination. The > wikipedia article > https://en.wikipedia.org/wiki/Mozilla_Public_License is fairly clear > that even > if you put the output under Apache, it is not really under Apache, > because the MPL > files have to still be under MPL. All you've really done at that > point is to mislead the developer who > uses your stuff into thinking that they have fewer compliance > requirements than > they actually do. > > "Recipients can combine licensed source code with other files under a > different, even proprietary license, thereby forming a "larger work" > which can be distributed under any terms, but again the MPL-covered > source files must be made freely available.[7]" > > where the footnote is: > [7] https://www.mozilla.org/en-US/MPL/2.0/FAQ/ > > Anyway. People divide into two camps on this. If you are working on > open source software, > you don't care. You can afford to be sloppy with the licensing. > Nobody is going to come after > you because you work is open source in the end. > > Commercial developers just avoid MPL and any uncertainty, and get on > with their work. Nobody > bothers to talk about it because it an issue just best avoided by not > using MPLed software at all. > Fair enough. Thanks for clarifying. -- 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/a176f1799556f3af47259c380a798eb5120826ca.camel%40kortschak.io.
Re: [go-nuts] Re: Clace: Secure web application development platform using Starlark
On Mon, 2023-10-30 at 23:29 -0700, TheDiveO wrote: > Unfortunatelly, "okay" hasn't been tested in court yet and especially > with HashiCorp breaking bad you surely have the deep pockets to see > this through? This is not really my problem, I was just pointing out that the authors of the license have publicly stated that they think they are compatible. -- 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/c5de2e3218adda68821e8d54fe57867ac0ec1e8b.camel%40kortschak.io.
Re: [go-nuts] Re: Clace: Secure web application development platform using Starlark
On Mon, 2023-10-30 at 18:43 -0700, Jason E. Aten wrote: > I'm surprised by that claim. I seriously doubt, from reading the > licenses, that you can legally use the Apache2 license, since > it removes the MPL requirements; which the MPL forbids you from > doing. > The Mozilla FAQ https://www.mozilla.org/en-US/MPL/2.0/FAQ/ appears to think it's OK. > Q13: May I combine MPL-licensed code and BSD-licensed code in the > same executable program? What about Apache? > > Yes to both. Mozilla currently does this with BSD-licensed code. For > example, libvpx, which is used in Firefox to decode WebM video, is > under a BSD license. -- 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/3b85733a7f1f495abf00b54ef4a33e4d65113d3d.camel%40kortschak.io.
Re: [go-nuts] Can Generics match implementers of an interface?
On Sat, 2023-10-21 at 11:58 -0700, Mike Schinkel wrote:
> Recently I was trying to write a func using generics where I wanted
> to use a slice of an interface that would contain implementers of
> that interface and then pass those types to a generic function, but I
> ran into this error:
>
> type MyStruct of MySlice{} does not match inferred type MyInterface
> for T
>
> My code is complex so I wrote the simplest example for this email and
> here is part of that code:
>
> type Suiter interface {
> Suit()
> }
> func Append[T any](s []T, i T) []T {
> return append(s, i)
> }
> func main() {
> var s []Suiter
>
> //CAN GENERICS SUPPORT THIS?
> //s = Append(s, Clubs{})
> //s = Append(s, Hearts{})
> //s = Append(s, Diamonds{})
> //s = Append(s, Spades{})
>
> //VERSUS HAVING TO DO THIS?
> s = Append(s, Suiter(Clubs{}))
> s = Append(s, Suiter(Hearts{}))
> s = Append(s, Suiter(Diamonds{}))
> s = Append(s, Suiter(Spades{}))
>
> for _, suit := range s {
> fmt.Printf("Suit: %s\n", suitName(suit))
> }
> }
> The full code is here in a playground.
>
> Note: My example func Append() makes no sense in real use, I only use
> it as it should be an easily understood example to show the syntax I
> am trying to illustrate.
>
> Question: Is there a way to write Append() such that I can call
> Append(s, Clubs{}) instead of having to write Append(s,
> Suiter(Clubs{}))?
>
> And if no, is there a chance that in the future Go generics will be
> able to support that level of type inference?
>
The pre-generics language handles this case:
https://go.dev/play/p/jaJF7LTSVYe
Is there something about your real case that makes this not acceptable?
--
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/9aab12f4935edebe2067bbae3c00faa5b50c79d8.camel%40kortschak.io.
Re: [go-nuts] Can we not invoke methods on types referring to generics?
On Fri, 2023-10-20 at 11:56 +0700, Nurahmadie Nurahmadie wrote:
> why is there no, type coercion, as you said, that allow the new type
> to be acknowledged as its underlying type? which will not be a
> question if otherwise Go has mechanism to allow methods to be
> attached to foreign types.
There is something like this, if you accept the use of interfaces
instead of concrete types (simplifying here).
You can make a `type T2 struct { T1 }` that has all the methods of T1
and whatever methods you add to T2 (note: Here be dragons!). This is
type embedding.
--
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/91ba59cc036ea8c86c8eb8befdc5ba66a6e4f47a.camel%40kortschak.io.
Re: [go-nuts] Dynamic template data from yaml
On Sat, 2023-10-14 at 13:15 -0700, Tong Sun wrote: > Hmm... somehow I had the impression that only the exported fields can > be used in template as variables. > > Is that a wrong impression or things have changed? You are indexing into a map so so the notion of fields is not relevant. -- 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/bd1e225259450e2d0cfb10c132045fe7e32faa4c.camel%40kortschak.io.
Re: [go-nuts] Dynamic template data from yaml
On Sat, 2023-10-14 at 09:33 -0700, Tong Sun wrote:
> Please take a look at
> https://go.dev/play/p/dTDR50dtHB0
>
> I want to
>
> - define my template data dynamically from yaml
> - and export the yaml data if they are unexported
>
> I.e., for the following code:
>
> t := template.New("")
> t, err = t.Parse("It's {{.A}} {{.B.C}}!\n")
> if err != nil {
> log.Fatalf("error: %v", err)
> }
> t.Execute(os.Stdout, m)
>
> The input is `map[A:Easy! B:map[C:2 D:[3 4]]]`.
> But why the template was not able to produce any output for the
> dynamic fields?
It is trying to match a string to a main.MyKey. If the only reason you
are using that type is to change the case of the key strings, I'd just
index into the lowercase, https://go.dev/play/p/wi9KICK1zmW.
--
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/fee9f5570d0c9370b4ecf3c667df98b4f6a6f0b7.camel%40kortschak.io.
[go-nuts] semantics of panic stack traces
I'm trying to get my head around a panic stack trace from a user
report[1].
The parameter value make very little sense to me based on what they
should be from following the program logic. For example the {0x0?, 0x0,
0x1?} (a slice header len=0) in
github.com/elastic/beats/v7/winlogbeat/sys/wineventlog.evtFormatMessage(0xc0003f62d0?,
0x23?, 0x0?, {0x0?, 0x0, 0x1?}, 0x1?)
github.com/elastic/beats/v7/winlogbeat/sys/wineventlog/format_message.go:81
+0xa5 fp=0xc00034ae88 sp=0xc00034ad98 pc=0x176f645
means that (from program logic) the 4th (length) and 5th (pointer)
parameters in
github.com/elastic/beats/v7/winlogbeat/sys/wineventlog._EvtFormatMessage(0x23?,
0x3600700?, 0x0, 0x0, 0xc000d5e978?, 0x1, 0x0, 0x0?, 0x0?)
github.com/elastic/beats/v7/winlogbeat/sys/wineventlog/zsyscall_windows.go:132
+0xf2 fp=0xc00034ad98 sp=0xc00034acf0 pc=0x177f152
should be 0 and 0 AFAICS. But this is not the case; the 5th is
0xc000d5e978?.
What am I failing to understand here?
thanks
Dan
[1]https://discuss.elastic.co/t/winlogbeat-unable-to-start-due-to-error/343190
--
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/5a004367451c0450661efa5ba814230cb9a52a2c.camel%40kortschak.io.
Re: [go-nuts] how to write methods for a generic Matrix[float64 constrained by Addable]?
On Sat, 2023-09-09 at 15:39 -0700, Jason E. Aten wrote:
> New to generics... how can I write a method for a Matrix[float64]
> that uses a math function that expects a float64? I get:
>
> ./slurp1.go:936:18: cannot use m.At(i, j) (value of type float64
> constrained by Addable) as float64 value in argument to math.IsNaN
>
> Casting it to float64() does not change this error(!)
>
> here is the essentials:
>
> type Addable interface {
> ~complex128 | ~complex64 | ~float64 | ~float32 |
> ~byte | ~uint16 | ~uint32 | ~uint64 |
> ~int8 | ~int16 | ~int32 | ~int64 | ~int
> }
>
> type Matrix[T Addable] struct {
> Nrow int
> Ncol int
> Dat []T
> }
> ...
> func (m *Matrix[float64]) NanToZero() {
> for i := 0; i < m.Nrow; i++ {
> for j := 0; j < m.Ncol; j++ {
>
> if math.IsNaN(m.At(i, j)) { // line 936, where the error
> is; ./slurp1.go:936:18: cannot use m.At(i, j) (value of type float64
> constrained by Addable) as float64 value in argument to math.IsNaN
>
> m.Set(i, j, 0)
> }
> }
> }
> }
>
> go version go1.20.6 linux/amd64
You will probably need to type assert.
--
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/666e12c82257dd5dc9e207767061eaa65d2ffa13.camel%40kortschak.io.
Re: [go-nuts] does gonum insist on row-major?
On Sat, 2023-08-26 at 07:28 -0700, Brian Candler wrote: > Could you explain the comment "all of Go is cm"? > https://go.dev/play/p/tDJiSTqsiSC > Sorry, that was a typo, should read "all of Go is rm" (what is there is inconsistent with everything else I wrote). -- 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/69b7647f39877c994878c657eb45e7960b48d99f.camel%40kortschak.io.
Re: [go-nuts] does gonum insist on row-major?
On Sat, 2023-08-26 at 13:45 +0100, Jason E. Aten wrote: > ah... there is documentation, it is just buried... > > https://pkg.go.dev/gonum.org/v1/gonum/mat#section-readme > > "All matrices are stored in row-major format and users should > consider this when expressing matrix arithmetic to ensure optimal > performance." > > Seems odd not to allow both; since this is usually very important for > perf. The original Cgo code did allow both. The maintenance burden or providing both for the Go implementation would have been far too onerous, so the column-major implementation option was remove from the Cgo wrapper for parity. I don't think the docs are buried; that is the first place people will look in general. FWIW The choice between rm and cm is difficult; all of Go is cm. All of Fortran is cm (also any GPU code). We've had this discussion internally and probably if we did it again, we might have chosen cm, but then we'd get people complaining that they can't represent matrices in source easily. 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/db555a3daa5d92c268e6c9bcb9d9e043ba371935.camel%40kortschak.io.
Re: [go-nuts] weird "index out of range" in strconv.formatBits
On Thu, 2023-08-17 at 23:32 -0700, metronome wrote: > > > Have you built with CGO_ENABLED=0? > Building with CGO_ENABLED=0 succeeded, does that mean the binary's > runtime behavior has nothing to do with CGO, deploying > a CGO_ENABLED=0 binary online is not an option as well, for now (We > are trying, but not sure if we can make it happen). Do you get the same behaviour with CGO_ENABLED=0? -- 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/35aff4ec8fd97582dcfec804f1d8714c4e55c26c.camel%40kortschak.io.
Re: [go-nuts] Why is foo in my go.sum file?
On Fri, 2023-08-18 at 16:49 +1000, Nigel Tao wrote: > The go.sum file in the golang.org/x/image repo has a line that is not > another golang.org.x/* module: > > github.com/yuin/goldmark v1.4.13/go.mod > h1:6yULJ656Px+3vBD8DxQVa3kxgyrAnzto9xy5taEt/CY= > > https://github.com/golang/image/blob/2b687b56714d59d061135c735913a64fe2b70778/go.sum#L1 > > That line was added in a go...@golang.org authored commit last > October: > https://github.com/golang/image/commit/ffcb3fe7d1bf4ed2e01a95a552bb3b7f5dab24d1 > > I'm just curious why goldmark is considered a dependency. "go mod > why" > and plain old "grep" doesn't give me any leads. > > --- > $ git checkout ffcb3fe7d1bf4ed2e01a95a552bb3b7f5dab24d1 > HEAD is now at ffcb3fe go.mod: update golang.org/x dependencies > > $ go mod why github.com/yuin/goldmark > # github.com/yuin/goldmark > (main module does not need package github.com/yuin/goldmark) > > $ grep goldmark -R . > ./go.sum:github.com/yuin/goldmark v1.4.13/go.mod > h1:6yULJ656Px+3vBD8DxQVa3kxgyrAnzto9xy5taEt/CY= > --- > > Am I holding "go mod why" wrong? What else can I try? > My guess is the go.mod in x/tools. https://github.com/golang/tools/blob/master/go.mod -- 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/0b42133f457f308f976203fcdcf9b4042c513d49.camel%40kortschak.io.
Re: [go-nuts] keyword= support for function calls
On Thu, 2023-08-17 at 11:34 +0200, Peter Herth wrote: > I think the omission of keyword parameters in Go is a weakness. In > many cases, keyword parameters are a simple way of creating APIs, > which depend on a lot of possible parameters, of which most are not > necessarily specified. Their omission is especially ironic, as there > is a strong push to initialize structs only via using the keyword > parameter syntax. And the reasons for that are very good. So when we > have a nice system - which essentially is just syntactic sugar at the > call site - for structs, why can't we have the same system for > functions? Like with structs, it should be mostly a syntax for > calling functions. They should probably be able to specify which > parameters are positional and which can be specified by keyword > parameters. > Of course you can do the common "trick" via generating a struct which > allows the keyword syntax for creation, but I think it would be a > good addition to not need that indirection. A significant problem with additions like this is that people would use it. kwargs-rich functions enable overly complex APIs. I'm very glad Go doesn't have them. -- 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/3a3163c2d6827bb2c40a850c2d24b39dced1285c.camel%40kortschak.io.
Re: [go-nuts] weird "index out of range" in strconv.formatBits
On Wed, 2023-08-16 at 23:43 -0700, metronome wrote:
> Thanks for commenting, a few supplements.
>
> # 1. Version of Go?
> We observed the issue with both go1.20.5 and go1.18.10 on linux/amd64
> (centos)
>
> # 2. Context?
> All panics we observed so far are from either
> strconv.FormatInt -> strconv.formatBits chain, or
> strconv.FormatUint -> strconv.formatBits chain
> where the base is always 10.
>
> // typical call site, toId is an "*int64".
> if com_count > 1 {
> com_string = anchor + "," + strconv.FormatInt(*toId, 10)
> }
>
> # 3. If your program using pure Go (statically linked) or Cgo?
> Binary was built with CGO_ENABLED=1 and -buildmode=exe.
> All panic call sites we observed so far are "pure go", that is, no C
> calling go path.
>
> # 4. panic stack trace
> panic: runtime error: index out of range [18446744073708732603] with
> length 200
>
> goroutine 1 [running]:
> strconv.formatBits({0x0?, 0x0?, 0x0?}, 0xc09e00b750?, 0x1?, 0x1?,
> 0x0?)
> /usr/lib/go-1.20/src/strconv/itoa.go:140 +0x4b9
> strconv.FormatInt(0x0?, 0xc07393df80?)
> /usr/lib/go-1.20/src/strconv/itoa.go:29 +0xa5
> ...
Have you eliminated the possibility of races? Have you built with
CGO_ENABLED=0?
--
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/79322d9278fab127f2a75f51986cc784a8c8666c.camel%40kortschak.io.
Re: [go-nuts] weird "index out of range" in strconv.formatBits
On Wed, 2023-08-16 at 20:31 -0700, metronome wrote: > Hi, > > We ran into a weird out of range issue of strconv.formatBits, hope > someone can shed a light on what could be the root cause, any comment > is highly appreciated. > > problem description: > random out of range at code, most of the time the indexing is a > huge int but we observed at least one exception (#2). > #1: runtime error: index out of range [18446744073709449339] > with length 200 > #2: runtime error: index out of range [102511] with length 200 > > Wild guesses: > 1. The machine code seems to suggest it's unlikely a data race or > memory corruption? But perhaps > relevant registers, like R10, had been saved and restored, then it > might be due to stack corruption? > Given that R12 is scratch reg, is it possible that R12 is clobbered > somehow, say, by signal handling? > > === > 0x00495b0a<+810>:mov %rdi,%r10 > 0x00495b0d<+813>:shr %rdi > 0x00495b10<+816>:mov %rax,%rsi > 0x00495b13<+819>:movabs $0xa3d70a3d70a3d70b,%rax > 0x00495b1d<+829>:mov %rdx,%r11 > 0x00495b20<+832>:mul %rdi > 0x00495b23<+835>:shr $0x5,%rdx > 0x00495b27<+839>:imul $0x64,%rdx,%r12 > 0x00495b2b<+843>:sub %r12,%r10 > 0x00495b2e<+846>:lea (%r10,%r10,1),%rax > 0x00495b32<+850>:lea 0x1(%rax),%rax > 0x00495b36<+854>:nopw 0x0(%rax,%rax,1) > 0x00495b3f<+863>:nop > 0x00495b40<+864>:cmp $0xc8,%rax > 0x00495b46<+870>:jae 0x495c8f > Go version? Function invocation context? -- 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/c888ef0205e12ec6ef15a50ffc7a26d89313636c.camel%40kortschak.io.
Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling
On Sun, 2023-07-02 at 10:41 -0700, Jeremy French wrote:
> Scrolling in code is bad - a necessary evil, obviously, but evil
> nonetheless. Vertical scrolling is bad because it causes what we
> were looking at to move and our eyes have to track and/or reacquire
> what we were looking at. It's obviously possible, but on the micro-
> scale it's expensive when you have to do it 1000 times per day of
> coding. Horizontal scrolling is even worse because not only is it
> harder to track visually, but we don't have nearly the same ease of
> use on our mouse to horizontally scroll as we do to vertically
> scroll. Just reacquiring where you were in the code takes up a
> miniscule amount of time and brain power that could be used for
> better purposes. Again, it doesn't seem like much, and you may
> dismiss me as being melodramatic, but this discussion is a recurring
> one for a reason. It's enough of a problem to bug people and want it
> to be different.
>
> So to speak to Dan's point, trading vertical scrolling for horizontal
> scrolling would be a move in the wrong direction. But if you can
> reduce three lines to one WITHOUT causing horizontal scrolling, that
> benefits everyone, or at least everyone who uses a scroll wheel.
Scrolling is part of it, eye tracking is a less-obvious but more
significant issue; there is a reason newspaper columns are narrow — it
eases reading. Another part is burying semantics in a line, for
example, I find the common practice of `if err := f(); err != nil {...`
to be significantly less readable than the equivalent where the f call
is outside the if, and reject code in review with this unless it's
needed for scoping reasons. I sort of wish that this feature did not
exist, though — even though the exact same semantics are possible in
the language without it with the use of block scopes — I can see why it
exists.
In general I agree, with what you're saying though as a problem
statement. The problem is tuning the gofmt heuristics (if a single-line
if handling were adopted). This has been discussed in numerous issues
and rejected (for a variety of reasons), so it's unlikely to be
changed.
--
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/ecc70f6c0d3facd0f74763f95711ebb25c789e5f.camel%40kortschak.io.
Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling
On Sat, 2023-07-01 at 22:34 -0700, Mike Schinkel wrote:
> > What is the difference to if err != nil { goto } ?
>
> Thanks you for asking.
>
> If you run go fmt on a file that contains the formatting you ask
> about the line will be expanded to the 3 lines, which brings us back
> to status quo:
>
> if err != nil {
> goto
> }
>
Why is there a bias towards favouring horizontal code over vertical
code?
In my experience, it's much easier to read and digest vertical code
compared to horizontal; Java (horribly horizontal in general) cf Go
(generally quite vertical).
--
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/5ea3976b6a1d665da1a0ee67a6ef2341568dbc08.camel%40kortschak.io.
Re: [go-nuts] fmt.Printf Go-syntax formated representation of the value
On Thu, 2023-04-27 at 23:02 -0700, Jérôme LAFORGE wrote:
> Hello,
> In my unit tests when expected is not the actual result, I like
> display actual value with Go-syntax. For example:
> if got != expected {
> t.Errorf(" %#v", got) // []string{"blah','blah"}
> }
>
> But it want to know if there is elegant way to display as formatted
> on multi-lines (a kind of indented json but with gofmt rules)?
>
> Thanks in advance,
There are a bunch of pretty printers. I use github.com/kortschak/utter
which renders as Go syntax where possible. Another that attempts to do
the same thing with slightly different priorities is
github.com/jba/printsrc.
--
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/1ba9e0e56ab9d926ea8932ffb67a9edfece6a48b.camel%40kortschak.io.
Re: [go-nuts] Short Variable Declarations Are Oversold
On Sat, 2023-04-22 at 15:31 -0700, jlfo...@berkeley.edu wrote: > What type should I use to declare “file” in the parameter list for > myfunc()? As a new Go programmer I have to admit that I haven’t > memorized all the types used in the Go standard library. So, I have > to break off working on myfunc() to look up the type returned by > os.Open(). This isn’t a huge deal, but it’s a distraction and can > waste time. I suppose that as I gain experience with Go, I’ll have to > do this less and less. LSP will let you know, but to provide a counterpoint... The type that the function should take may not be the concrete type, func myfunc(file ...) might be func myfunc(f *os.File) or func myfunc(r io.Reader) or any of a number of other interfaces that *os.File satisfies. The choice here is not necessarily defined by the type, but more by the intention of the programmer. -- 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/b85e9896c999255152fc6759a4caa8cd4713e3d3.camel%40kortschak.io.
Re: [go-nuts] Is there a gofmt flag to avoid reformatting comments?
On Wed, 2023-04-19 at 14:30 -0700, Ian Lance Taylor wrote: > > If you give us more details perhaps there is some common ground > available. In particular, a sequence of lines where each line is > indented will be treated as a code block, and not reformatted. Related, I'd like to reiterate the concerns with quote rewriting (filed here https://go.dev/issue/54312) which is an accessibility issue. -- 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/d1168d086d222fae56704b580977c204b42a05bd.camel%40kortschak.io.
Re: [go-nuts] Avoid forcing my module users' to carry dependencies from code that live under the same repo just as examples/ debugging purposes.
On Fri, 2023-04-14 at 14:01 +0800, Jim Idle wrote: > You might start with this repo: > > https://github.com/golang-standards/project-layout > > This is not an 'official' standard, though it does encapsulate the > things that are standard go such as the internal directory. > > Personally I avoid its recommendation to use a directory 'pkg' to > store your module code as it makes the import path quite strange. But > for a main you can look at the cmd directory or the internal > directory. You will not go too far wrong by following this guide. > > Jim It's worth noting this issue in that repo: https://github.com/golang-standards/project-layout/issues/117 -- 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/c66f416360824816fa1c9415126c78969beaad9b.camel%40kortschak.io.
Re: [go-nuts] Interesting "select" examples
On Mon, 2023-04-03 at 14:59 -0700, Skip Tavakkolian wrote: > Nice pause/resume. I'll need to remember this. > > On Mon, Apr 3, 2023 at 3:14 AM Rob Pike wrote: > > > > Here's an excerpt from a piece of concurrent code I like, an > > unpublished interactive game of life. The select near the bottom > > has only two cases but it is perhaps instructive. I leave its > > analysis to the reader. > > > > -rob I needed something just like this recently for pausing/un-pausing graphic animation to swap out animated graphics while keeping frame position, and allowing cancellation. It doesn't use a single channel of events to drive the pause behaviour because pause is not a toggle in this system (for safety), so it's less elegant in that sense, but it does require the consideration of the hold, release and the context.Done chans. https://go.dev/play/p/uyuP94Tvi50 -- 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/a61d6a9201ef9750bc1287e2122a654e67dc3272.camel%40kortschak.io.
Re: [go-nuts] How to generalize parameters for a function
On Wed, 2023-03-15 at 12:55 -0400, Frank Juedes wrote: > > > Hi Dan, > Thank you very much for your answer, so that's the data structure > behind maps, very interesting. > I had actually thought about using unsafe pointers and then type- > casting, but that is how i would have done it in the C-dekades, not > with Go. The source for this is here https://cs.opensource.google/go/go/+/refs/tags/go1.20.2:src/runtime/map.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/794a286af50a58c9ac1e38fec6f7f10ce5d4f4a9.camel%40kortschak.io.
Re: [go-nuts] How to generalize parameters for a function
On Tue, 2023-03-14 at 19:56 -0700, Kurtis Rader wrote: > Maps are a special-case. You can't pass them "by value" in the sense > you mean because a "map" value is a very tiny structure that contains > a pointer to the actual map. The passed value is a pointer to the header, otherwise changes to maps would require the altered map to be returned as with slices and append. https://go.dev/play/p/avBBkNwVZRY -- 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/4af2d37285e3b6d2a7594342c18f5c4160b7b86f.camel%40kortschak.io.
Re: [go-nuts] overriding image.Decode image type detection
On Mon, 2023-03-06 at 14:38 +1100, Nigel Tao wrote: > On Sun, Feb 26, 2023 at 12:43 PM 'Dan Kortschak' via golang-nuts > wrote: > > The alternative is to > > replicate the image.Decode functionality, including registration > > which > > seems ugly. > > It may seem ugly but that is what I'd recommend. > https://go.dev/src/image/format.go is only 110 lines of code. Yeah, this is what I went with. > > Would a change to > > image.RegisterFormat that did a replacement of existing > registrations > > that are identical to a new registration rather than an append be > > entertained (I can see good reasons for a no here)? > > I'd be unlikely to entertain it, due to https://www.hyrumslaw.com/ Indeed. I think there are foot guns in the approach as well. Though it's been the way it is for years, it may be worth have a comment that registration for a type will only be effective once. 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/fae84889ed3a44f0f0e9c0fac3dd9a931305c354.camel%40kortschak.io.
[go-nuts] overriding image.Decode image type detection
I'm implementing a image renderer on an external device and want to include GIF animation support. So far this is working fine, but I've found a difficulty that comes from for image.Decode's file type detection is registered. What I have is shim type that wraps *gif.GIF but also implements image.Image. Registering the decoder for this for "GIF8?a" does not work because the registration function, image.RegisterFormat appends the registration details to the existing registered formats. Since my code depends on "image/gif", the package registration has already happened during init and I don't see a way to ever beat the "image/gif" registration call during init. The workaround is to seek to the start of the file if image.Decode finds a gif, which is inefficient and will not handle the case of a non-seekable io.Reader. The alternative is to replicate the image.Decode functionality, including registration which seems ugly. The existing behaviour is somewhat surprising since there is no indication in the docs that a new registration of the same magic bytes will not work. Is there a commonly used work-around for this? Would a change to image.RegisterFormat that did a replacement of existing registrations that are identical to a new registration rather than an append be entertained (I can see good reasons for a no here)? 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/63152ea80145ea3076f68772e3d03156ba23f680.camel%40kortschak.io.
Re: [go-nuts] %v display of nil map
On Wed, 2023-01-25 at 07:21 -0800, Andrew Athan wrote:
> I'm sure I'm not the first to say this, but here's my +1:
>
> It seems wrong to me that golang displays nil-valued reference types
> as an empty instance of the type with no indication that the
> reference is nil.
>
> E.g.
> ```
> var m map[string]string
> fmt.Printf("%+v",m)
> ```
>
> displays as "map[]"
>
> I think it would be better to display something like "map[]",
> don't you?
>
> Motivation: While the nil map does act like a map[] for reads, it
> does not act like one for writes, and debugging via prints can
> therefore be confusing for new users.
>
For debugging, use %#v. https://go.dev/play/p/UlvaFg5Z_lB
--
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/6e278c5a183432315bb86e19b4c4f7794c9b56ab.camel%40kortschak.io.
Re: [go-nuts] Which tool provide's the Go playground's import handling...
On Fri, 2023-01-06 at 00:13 -0800, 'Mark' via golang-nuts wrote:
> If I visit the Go playground and change the body of `main()` to, say,
> `fmt.Println("hello", math.Abs(-5))` and then click Run, the `import
> "fmt"` line is _automatically_ corrected to be `import
> (\n\t"fmt"\n\t"math"\n)`. I'd like to be able to use this
> functionality so that I can set my editor to do "fiximports" and then
> "gofmt" rather than just "gofmt" as now. But I don't know what the
> tool is that does this?
https://pkg.go.dev/golang.org/x/tools/cmd/goimports
--
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/e22cea931c01b89503d46af6db7a2a2c48e11445.camel%40kortschak.io.
Re: [go-nuts] More details regarding changes to time.Time JSON marshalling/unmarshalling in 1.20?
On Tue, 2023-01-03 at 20:50 -0800, 'Ben Brcan' via golang-nuts wrote: > Hi, I noticed this in the draft release notes for 1.20: > > The Time.MarshalJSON and Time.UnmarshalJSON methods are now more > strict about adherence to RFC 3339. > > Can we get some further details about this? Are there things that > were OK before that will no longer be valid? > > Thank you > > Ben I'd say it's this: https://github.com/golang/go/commit/72c58fb77192f7d17d87663c943360a48aae11dc -- 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/4f94fa7af4c6b15797f3d273e52d4eb1c60bee4b.camel%40kortschak.io.
Re: [go-nuts] MATLAB filtfilt --> GOLANG
On Sun, 2023-01-01 at 12:24 -0800, 이석태 wrote: > Hello, Golang Team, > > I want to convert MATLAB ' filtfilt ' command to Golang. > Actually, MATLAB 'filtfilt' command was 'filter' command as a > one dimensional signal filter. > > I am using 6 * 1 matrix coefficienct for 'filter' command. > > Is there a any recommendation for > GOLANG one dimensional signal filter with 6 * 1 matrix coefficient ? > > [ filter kernal coeffecient ] > B = [0.9243 -4.6182 9.2332 -9.2332 4.6182 -0.9243] -> 6 * 1 > matrix > A = [1.000 -4.8392 9.3727 -9.0822 4.4029 -0.8543 ] -> 6 * 1 > matrix > > I've searched a lot but it's so hard to find. > In Golang, DSP is too hard. > > If anyone have reference page or example case, Kindly share plz. > Thank you. > Following the links here may be helpful. https://www.mathworks.com/matlabcentral/answers/353172-implementation-of-the-matlab-function-filtfilt-in-c-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/799301b9a422275ba67eed52dcb209ef6c4b260c.camel%40kortschak.io.
Re: [go-nuts] How to expoert DWARF and symbol table in a in separate file when build?
On Wed, 2022-12-28 at 18:14 -0800, 庞子元 wrote: > Hi All, > > For security reasons, our go cannot be compiled with information like > DWARF and symbol tables. > > Is there a way to put this information in a separate file so that we > can link to it when we need it? > > Any tips are greatly appreciated! Not exactly what you are asking for, but probably something that should work for you is garble. https://github.com/burrowers/garble -- 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/9103be6b77fa74ecf1ba1e2381bb78ebca52f366.camel%40kortschak.io.
Re: [go-nuts] Linting
On Sat, 2022-12-10 at 14:44 +0100, Marcello H wrote: > golangci_lint ... > > Op za 10 dec. 2022 om 13:17 schreef Brian Candler > : > > The question remains, which linter(s) are you using? golangci_lint is not really an answer to this question since it's just a collection of linters, many of which have arguable utility/value. -- 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/9827b253f9d8cc8c821874675adad2130612060e.camel%40kortschak.io.
Re: [go-nuts] Re: Looking Backend Dev Learning Resources
On Mon, 2022-12-05 at 14:54 -0600, Robert Engels wrote: > Can you elaborate on that reference? At first review, it means you > are putting in lots of effort making lots of progress (anti red > queen) but that would mean the progress made did not invalidate any > of effective Go (which seems not possible given the addition of > generics). I’m doubting you implied little effort was put in over 10 > years so little progress has been made :) The Red Queen was the definition of churn. She never made any progress. -- 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/dc76e280f6529cc12703bc77323547167b64e22f.camel%40kortschak.io.
Re: [go-nuts] Re: Looking Backend Dev Learning Resources
On Mon, 2022-12-05 at 09:27 -0800, Tsvetomir Lazarov wrote: > How relevant is Effective Go actually, given the January 2022 update > that this document has not been updated significantly since 2009? Still relevant. This is one of the virtues of having a language that is not built on the Red Queen model of progress[1]. [1]https://en.wikipedia.org/wiki/Red_Queen%27s_race -- 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/0af2089eb4f34cd5f8e67f1c9b1cad62c1b76e57.camel%40kortschak.io.
Re: [go-nuts] Re: go install of forked repo
On Sun, 2022-12-04 at 23:47 -0800, 'Christian Stewart' via golang-nuts wrote: > I definitely fork things and use "replace" quite frequently. It *can* be used, but it is not the solution in the general case as Volker said. A replace in a library's go.mod file has no effect on consumers of that library. https://go.dev/ref/mod#go-mod-file-replace: > replace directives only apply in the main module’s go.mod file and are ignored in other modules. See Minimal version selection for details. -- 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/57399c8014247d4c72a8e830b326e8674ad18247.camel%40kortschak.io.
Re: [go-nuts] cgo C.uint64_t compatiblity on multiple platforms?
On Sat, 2022-12-03 at 10:51 -0800, David Stainton wrote: > Greetings, > > I think my question is something like: "how to make my usage of > C.uint64_t work on all platforms?" or "Is there something obviously > wrong with my cgo bindings that is causing this not to build on all > platforms?" > > I wrote this cgo binding for the reference implementation of Sphincs+ > (it's a hash based post quantum signature scheme): > > https://github.com/katzenpost/katzenpost/blob/main/sphincsplus/ref/binding.go > > Recently we noticed it fails to build on MacOS and Windows: > > https://github.com/katzenpost/katzen/actions/runs/3609590801/jobs/6082872618 > > So I "fixed" it by changing the typecast to use C.uint64_t instead of > C.ulong: > > https://github.com/katzenpost/katzenpost/pull/110/files > > However that causes the build to fail using Go1.19.3 on MacOS, > although it works on Windows: > > https://github.com/katzenpost/katzen/actions/runs/3609771045/jobs/6083165054 > > > Sincerely, > David Stainton The header file definition for crypto_sign_signature uses size_t for the parameters that are passed as ulong in the calls that are causing the issue. These types are not always the same size, so perhaps in e.g. https://github.com/katzenpost/katzenpost/blob/a165cb2a13e40f3a15dd1fa296a7763d8b638ae0/sphincsplus/ref/binding.go#L120-L125 making the ulong params be size_t would 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/0dff332833277c47b106d5417a159981d6e4d6bd.camel%40kortschak.io.
Re: [go-nuts] How to fix an awful marshal reflection hack
On Thu, 2022-12-01 at 00:33 -0800, 'Mark' via golang-nuts wrote:
> Thanks. I've now tried that as follows:
>
> fmt.Printf("@@: %T %v\n", field, field)
> kind = field.Type().Elem().Kind()
> fmt.Printf("##: %T %v\n", field, field)
>
> In every case the output for kind before and after was identical.
> (Naturally, I tried without the print statements too.) And, of course
> the tests fail. So I'm _still_ using the awful hack!
>
Doesn't this do what you want?
https://go.dev/play/p/7jUw_iW8B_8
--
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/65c1c5450a2bb0530d4ffad0571cc32b2397d12f.camel%40kortschak.io.
Re: [go-nuts] clarifying Go FAQ: Is Go an object-oriented language?
On Tue, 2022-11-22 at 10:16 -0800, Ian Lance Taylor wrote: > On Tue, Nov 22, 2022 at 10:11 AM Robert Engels > wrote: > > > > I do not know why the mailing list is set up as the sender is the > > user. Is should always have the sender be the list email and the > > name be the user, or the sender details included elsewhere. I don’t > > have this problem in any other lists. Robert, this has been an ongoing problem with mail from your address for years for me, and I think that I have raised it in the past. It breaks thread chains and drops messages. To illustrate, I'm reply to the message from Ian because your message never made it to my inbox, and his message is the only one that contains this text in my inbox. Worse, his message is a thread-orphan. Interestingly, this does not happen all the time, so I suspect that either your mail client is flakey with regard to the References: header or you are using more than one client. I don't recall seeing this behaviour from any other sender's client on the list. 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/31dce71be5156464b437ab421ae01519bd9409f4.camel%40kortschak.io.
Re: [go-nuts] where is GOROOT set?
On Thu, 2022-11-17 at 21:20 -0800, pat2...@gmail.com wrote: > pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$ > go test treesort_test.go This is not how go test should be invoked. You just need to do go test in the directory that you package lives in. See https://pkg.go.dev/cmd/go#hdr-Test_packages -- 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/b90053253a8db89fd84e5bedc477fe306d361380.camel%40kortschak.io.
Re: [go-nuts] BUGFIX-66: Algorithmic Puzzles in Go
On Sun, 2022-11-13 at 14:43 -0800, Lawrence Ryan wrote: > So you're suggesting that a user could write code containing a race, > have that code produce, say, a slice with the wrong length (by > interleaving the pointer and length/capacity writes), and then use > that "mixed" slice to compromise the system. I see what you're > saying. > > If the site is running on a single CPU core, we would have to have > the go runtime switch goroutines in the middle of a slice (ptr, len, > cap) slice write. I'll have to see if that's possible. > > Thanks! You may want to read this: https://research.swtch.com/gorace 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/ce8cea479e8d72eec5231b1470ec46aefd9a99aa.camel%40kortschak.io.
Re: [go-nuts] Re: Unicode variable name error
On Tue, 2022-11-08 at 09:17 -0800, TheDiveO wrote: > I've always wondered how to deal with exported versus unexported > identifiers in scripts like Chinese? There is an issue for this https://go.dev/issue/22188 which discusses the approaches that are currently used with a view to making it easier. It also links to previous issues about 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/665360ff854b4abc823a5882f6f1584fdfb6ba5f.camel%40kortschak.io.
Re: [go-nuts] Parsing comments that don't start with a space
On Sun, 2022-11-06 at 11:55 -0800, 'Christian Stewart' via golang-nuts wrote: > - Why does the comment not appear unless I put a space before? (in > ast CommentMap) This is explained here https://pkg.go.dev/go/ast#CommentGroup.Text > Comment directives like "//line" and "//go:noinline" are also removed. > - What's the best way to detect these comments? You can interact directly with the data in the CommentGroup struct List field. -- 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/55814b2a4d8c562b0b995f8b64118bf3fa65b1ae.camel%40kortschak.io.
Re: [go-nuts] Re: go:embed question
On Fri, 2022-10-14 at 00:17 -0700, esimov wrote: > . Now, that's not the case when you are running a package using the > following command: "go run github.com/user/package@latest" for > example Can you give an example of a real package where this doesn't work? -- 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/2af5f60f43a9c2f169ab5d888f20ac96d18ea826.camel%40kortschak.io.
Re: [go-nuts] Go routine context
On Mon, 2022-10-03 at 00:46 +0200, Sven Anderson wrote: > As it happens, I wrote a small package, that does that „almost“ > legally: > https://pkg.go.dev/github.com/ansiwen/gctx There is also github.com/kortschak/goroutine for getting goroutine IDs, which can be used as the primitive for constructing your own personalised foot gun. -- 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/912630d021fb1fcedd90a0467ed19914693ce601.camel%40kortschak.io.
Re: [go-nuts] Go routine context
On Sun, 2022-10-02 at 06:15 -0500, Robert Engels wrote: > Again, I would like a link to the source of statement to evaluate it > in context. https://manningbooks.medium.com/interview-with-brian-goetz-7d6c47d05d63 -- 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/3d6ff1822f402e745cdc51776fcf6bfd0a112d75.camel%40kortschak.io.
Re: [go-nuts] understanding interface conversions
On Thu, 2022-09-22 at 20:01 -0500, Robert Engels wrote: > The world figured out long ago that OO and it’s principles are a > better way to go. This is a very strong assertion (pun not intended). I heartily disagree with the claim, particularly when it comes to how OO is implemented by class-based languages. They take the world, which is messy and attempt to fit it into a clean hierarchical taxonomy. We've had a couple of hundred years to learn that this kind of taxonomic approach is insufficiently powerful to properly describe the world in the general case. -- 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/0e066f19f52b598b87e0786232b7d9a5b6c97541.camel%40kortschak.io.
Re: [go-nuts] cannot convert fs.FS zip file to io.ReadSeeker (missing Seek)
On Wed, 2022-09-21 at 19:30 -0500, robert engels wrote: > Others have suggested passing a ByteBuffer - I don’t think that will > work because you will be missing other methods that are probably > needed (FileInfo to get the name, etc) The function that was pointed to takes an ~io.ReadSeeker (oddly a pointer to the interface) and doesn't look like it expects to conditionally use other methods. The other details can always be obtained from the original value. -- 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/f6d47a3fe5ae4425b51f978d8a5cda71aaa55cf3.camel%40kortschak.io.
Re: [go-nuts] cannot convert fs.FS zip file to io.ReadSeeker (missing Seek)
On Thu, 2022-09-22 at 00:58 +0100, Rory Campbell-Lange wrote:
> interface conversion: *zip.checksumReader is not io.ReadSeeker:
> missing method Seek
>
> Advice on how to rectify this would be gratefully received.
Would it be acceptable to conditionally copy the reader's contents into
a buffer that implements io.ReadSeeker?
if rs, ok := r.(io.ReadSeeker); ok {
useReadSeeker(rs)
} else {
b, err := io.ReadAll(r)
// handle err
useReadSeeker(bytes.NewReader(b))
}
--
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/691c030d0e345f34ba45b0676223dbd6fdc8d055.camel%40kortschak.io.
Re: [go-nuts] How to resolve error Cannot use 'struct{ width, height float64 }{2.0, 3.0}' (type struct {...}) as the type struct {...}
On Tue, 2022-08-30 at 07:46 -0700, Richard Whatever wrote:
> I'm developing a mvc Golang server.
> The model file is as follows:
> type Object struct { ... TargetSize struct{ width, height float64 }
> `json:"targetSize"` ... }
> The controller file is as follows:
> func (c *GetObject) Get() []models.Object { return []models.Object{
> {... struct{ width, height float64 }{2.0, 3.0}, ... },
> I keep on getting the error of "Cannot use 'struct{ width, height
> float64 }{2.0, 3.0}' (type struct {...}) as the type struct {...}"
> and I don't know how to resolve this.
You'll benefit from defining the type struct{ width, height float64 }
if you need to use it elsewhere. Also, for JSON de/serialisation, the
fields will need to be exported. This will also fix you compile.
--
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/1caf865a134ec3d0173fdf946b484db2cd500e3a.camel%40kortschak.io.
Re: [go-nuts] Is Go a security malware risk?
On Thu, 2022-08-25 at 01:47 -0700, Holloway Kean Ho wrote: > What exactly you're trying to achieve by taking a very elaborated, > crystal-clear, good-willed security-related article way out of its > context with your thread title here and agitate some of the Go > maintainers here? I don't think that's what the OP was doing. Bill Kennedy suggested they ask here, and I think that they have enough information/ideas to take back to their security team to address the misconceptions that they have. -- 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/59a3def81d6d35ed3ab790226318cdf4189c68ab.camel%40kortschak.io.
Re: [go-nuts] time.Truncate unexpected results in non-hour aligned timezones
On Tue, 2022-08-23 at 23:07 -0700, Mine GO BOOM wrote: > Our system recently experienced a bug because of the surprise that > sits (documented) inside of time.Truncate(): > > """ > Truncate operates on the time as an absolute duration since the zero > time; it does not operate on the presentation form of the time. Thus, > Truncate(Hour) may return a time with a non-zero minute, depending on > the time's Location. > """ > > Example of this surprise: https://go.dev/play/p/hZEHhj8QTZs > currentTime: 2021-07-28 06:03:00 +0545 +0545 > truncated to one hour: 2021-07-28 05:45:00 +0545 +0545 > truncateTimezoneSensitive: 2021-07-28 06:00:00 +0545 +0545 > > I see that time: could use a "truncate in timezone" feature was > closed a long time ago with the comment: "The vast majority of > truncation/rounding of times happens on units of 1 hour or smaller, > and those are typically not sensitive to time zone." I do agree that > most rounding/truncating does work on one hour or less (we sure do), > but I'd say that it should be sensitive to time zones. The over a > billion people in India (GMT +5:30) would agree with that, as they > are the ones that reported the bug in our system. > > I would like to suggest this for an addition to the Go says > WAT? collection. > > Can someone re-open the bug for further discussion? I would recommend that you open a new issue rather than requesting the old one be reopened. If you do, you should provide any new information that is not discussed in the old issue that supports the need of the feature. -- 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/bfd86b65f35b94e4cc49bf67f788cb2d00f5ba55.camel%40kortschak.io.
Re: [go-nuts] Is Go a security malware risk?
On Mon, 2022-08-22 at 06:15 -0700, 'Gopher-Insane' via golang-nuts wrote: > Hi > > So our security team has raised a concern with Go and malware. The > link that was sent to me > was https://securityboulevard.com/2021/09/behavior-based-detection-ca > n-stop-exotic-malware/. > I reached out to Bill Kennedy on Twitter who disagreed that Go was a > problem. Said it was worth posting here to hear people's thoughts. > > Thanks! That's a particularly weird take that they have. Apart from the apparent suggestion that somehow because Go is used in writing some malware that Go should not be used, it leaves no actual action to be taken unless your company is the origin of the malware that is targetting it, in which case there are other issues. The point of the article is not that novel compilation patterns are dangerous, but rather that using compilation patterns for detection is not a generally safe strategy for preventing malware. This is the point that they seem to have 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/a2d107fb0167c79988578bdee70af895b75e11f2.camel%40kortschak.io.
Re: [go-nuts] Library for printing a struct as a compiler recognized version
On Mon, 2022-08-15 at 21:23 -0700, John wrote: > Thank you everyone who responded. Gave utter a look and its pretty > decent. I found litter a bit more developed around the circular > reference area. But both were great suggestions and just what I was > looking for. I would be careful with litter, it does not properly handle unexported types or types in interface contexts. https://go.dev/play/p/QM6zLUz0sx- https://go.dev/play/p/hnazQoef1qP I'd also be interested to know what you think utter is lacking in handling circular references. 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/9442090daecb9362bf38ee7dbcfdcf39430e13bf.camel%40kortschak.io.
Re: [go-nuts] Library for printing a struct as a compiler recognized version
On Mon, 2022-08-15 at 07:26 -0700, John wrote:
> I know we have plenty of pretty printing out there, but i'm looking
> for a package that can print the Go representation of a Struct out to
> screen.
>
> So given:
>
> var x := {
> A: "hello"
> }
>
> someLib.Print(x)
>
> I get:
>
> {
> A: "hello"
> }
>
> I'm sure someone has used reflection to do this and figured out how
> they want to deal with recursive pointers, so don't want to go
> recreate the wheel here.
>
> Thanks.
github.com/kortschak/utter will do this for most values (there are
cases that are not possible due to requiring programmatic construction
— pointers to strings, ints etc, and filled channels being examples).
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/ed0ddac2db3db8fdccfedb252bdc66ef29685c80.camel%40kortschak.io.
Re: [go-nuts] Preemptive interfaces in Go
On Wed, 2022-08-10 at 11:17 -0700, Mike Schinkel wrote: > In my experience having control over the implementation is not a > black-and-white thing, unless you are the sole developer on a > project. This also brings in the consideration of that if you have complete control over the implementation, why do you need to enforce this kind of encapsulation so strictly? The other question is why does that encapsulation need to happen at the boundary of the producer of the data rather than at the boundary of the consumer of the data? In my experience, functions that return interfaces egregiously (they are doing it for this kind of encapsulation) generally make my work harder when I am debugging, and make code comprehension significantly harder. 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/7649a414b3dc3f7ac3f7252b03ec9f92d8e5aaac.camel%40kortschak.io.
Re: [go-nuts] Methods of reflect pkg use mostly panic instead of return error. Why so?
On Wed, 2022-07-20 at 22:51 +0200, 'Axel Wagner' via golang-nuts wrote: > The reason reflect uses panic, is for convenience. It would be > inconvenient having to check an error at every reflect call. The other reason is that a panic in reflect is as close as you can get in runtime to a compile error, which is what the non-reflect based equivalents would generally give you for the errors that panic in reflect. 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/db3c17c326f72d37e975c64337e4dd6cd2640b5c.camel%40kortschak.io.
Re: [go-nuts] Re: duration^2
On Tue, 2022-07-19 at 09:24 -0700, Amnon wrote: > > time.NewTicker( time.Duration(n) * time.Second ) ok : duration > > * duration [s^2] square-seconds ? > > Yes, this bothers the inner Physicist in me too. > But you can only multiply numbers if they are of the same type... With a small amount of gymnastics a reasonable comfort can be found; types aren't units, but can be used to decorate them as such. This means they underly the notion of a unit. (Tangentially, there are packages that do dimensional operations, for example https://pkg.go.dev/gonum.org/v1/gonum/unit). -- 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/00d2056025ad04d744082a72eb5249694e7b9e5d.camel%40kortschak.io.
Re: [go-nuts] Is this a compilation optimization bug ?
On Tue, 2022-06-28 at 09:40 -0700, Ian Lance Taylor wrote: > Please open an issue. Thanks. Filed https://go.dev/issue/53600. 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/979812a0eaa99be314465dca721fc2426a2f8009.camel%40kortschak.io.
Re: [go-nuts] Is this a compilation optimization bug ?
On Mon, 2022-06-27 at 23:32 -0700, iori yamada wrote: > Running the code in the link below times out, is this a bug? > Looking at the assembly, it seems that the instructions corresponding > to the if statement have been removed due to optimization. > > https://go.dev/play/p/CZX4mbyrp37 > > The following is a description of how I thought it was a bug. > > In the first loop, the value of i is 9223372036854775807 (the maximum > value of type int), which is incremented and overflows. Then it > becomes -9223372036854775808 (minimum value of type int) and I > thought the condition in the if statement exits from the true > neighbor loop. > > I couldn't figure out where the bug was happening, so I decided to > look at an assembly of the same code as above, built it locally, and > checked it with objdump. > Perhaps, the CMP instruction that compares the conditions of the if > statement has been removed due to optimization. > > ``` > ... > TEXT main.main(SB) Path/main.go > main.go:3 0x100051550 92f0 MOVD $9223372036854775807, R0 > main.go:4 0x100051554 1402 JMP 2(PC) > main.go:4 0x100051558 91000400 ADD $1, R0, R0 > main.go:4 0x10005155c 92f0001b MOVD $9223372036854775807, R27 > main.go:4 0x100051560 eb1b001f CMP R27, R0 > main.go:4 0x100051564 54ad BLE -3(PC) > main.go:9 0x100051568 d65f03c0 RET > main.go:9 0x10005156c ? > ``` > > So I compiled it without optimization (go build -gcflags '-N -l') and > the program terminated immediately as intended. > > I may have misunderstood something, may I ask anyone to check once? Yes, I see the same behaviour when I run this locally (also tried with an old version go1.14.9). Also, the assembly generated at godbolt shows that no code is generated for the terminating branch https://godbolt.org/z/9jW1GaKfv unless optimisation is turned off https://godbolt.org/z/o7o6x3bzd. 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/ac0efc0fc8bb57ec2e3fb12b9f69774f28c16e84.camel%40kortschak.io.
Re: [go-nuts] unrecognized import path "code.google.com/p/go.crypto/openpgp"
On Thu, 2022-06-09 at 14:21 -0700, Peter Sjolin wrote: > I attempted to use "code.google.com/p/go.crypto/openpgp" in my > project and got the following error: > $ go get code.google.com/p/go.crypto/openpgp > go: unrecognized import path "code.google.com/p/go.crypto/openpgp": > parse https://code.google.com/p/go.crypto/openpgp?go-get=1: no go- > import meta tags (meta tag github.com/golang/go did not match import > path code.google.com/p/go.crypto/openpgp) > > Is there an update to this? > > Peter This now lives here golang.org/x/crypto/openpgp (code.google.com closed down years ago). 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/1039ac47088072ae6a877aabf101d4f7984de35d.camel%40kortschak.io.
Re: [go-nuts] How to prevent default sorting of map
On Mon, 2022-05-30 at 08:23 -0700, Vejju Deepesh wrote: > I want know the method of preventing sorting by default and maintain > the map in the order of insertion If you want ordered return of elements and O(1) look-up, use a slice and an index map. Insertion becomes and appends and a map insertion with the length of the slice after append (if the element is not already in the map - no-op otherwise), look-up is an index map query and then slice access, and container dump is an iteration over the slice. -- 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/0e521de4259d1f69a6d5126d7f01366211fa5a79.camel%40kortschak.io.
Re: [go-nuts] Which is the most efficient way to read STDIN lines 100s of MB long and tens of MB info is passed to it
On Sat, 2022-05-07 at 16:16 -0700, Const V wrote:
> The question is will scanner.Scan handle a line of 100s MB?
No, at least not by default (https://pkg.go.dev/bufio#Scanner.Buffer).
But that that point you want to start questioning why you're doing what
you're doing.
Your invocation of grep can be a lot simpler
```
func grep(match string, r io.Reader, stdout, stderr io.Writer) error {
cmd := exec.Command("fgrep", match)
cmd.Stdin = r
cmd.Stdout = stdout
cmd.Stderr = stderr
return cmd.Run()
}
```
You can then do whatever you want with the buffered output and stderr.
You can also make this use a pipe with minor changes if you expect the
output to be long and that stream processing of that would be sensible
(use cmd.Start instead of Run and look into StdoutPipe).
--
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/407bcc70f772fa7e7980469c2098c8b8b481ecf1.camel%40kortschak.io.
Re: [go-nuts] Which is the most efficient way to read STDIN lines 100s of MB long and tens of MB info is passed to it
On Sat, 2022-05-07 at 15:18 -0700, Amnon wrote: > The other interesting question is what algorithm we use to find the > pattern in each line. > Generally bytes.Contains uses Rabin-Karp. But as the pattern is the > word "test" which is only 4 bytes long, > a brute force search is used, using SSE type instructions where > available. > So the naive Go approach will give you a very fast execution. The > main thing is to set up your scanner with a large buffer, to minimize > the number > of file system reads, and to avoid the newbie error of working with > strings rather than []byte, and forcing the code to do vast numbers > of > unnecessary and expensive allocations. There is an interesting post from the author of grep that goes over some of these details https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.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/27eef405ac38a8e32488f15ee7726c3478866ede.camel%40kortschak.io.
Re: [go-nuts] how is xml.Decoder.CharsetReader supposed to be held?
On Fri, 2022-05-06 at 15:55 -0700, Ian Lance Taylor wrote: > On Fri, May 6, 2022 at 3:07 AM 'Dan Kortschak' via golang-nuts > wrote: > > > > On Fri, 2022-05-06 at 11:22 +0200, Diego Joss wrote: > > > Does this work for you? > > > > > > https://go.dev/play/p/xLRawVhcRtF > > > > > > > Thanks. No, the documents are in UTF-16, and the procinst will be > > too. > > So it looks more like this https://go.dev/play/p/4IcXNI3yd2M. If I > > pull > > the proc inst out of the UTF-16, then I can get it to work; > > https://go.dev/play/p/kHwkVWtxbNO. But this leads to the issue > > where at > > that point I could just decode the whole message and pass it > > through. > > So I don't really see the point of using CharsetReader (at least > > not > > with UTF-16). > > Yeah, that's not the kind of thing that CharsetReader can help with. > You'll need a plain io.Reader that converts from UTF-16 to UTF-8. > > CharsetReader only works if the character set name is available in > plain ASCII in the first XML definitions, but the data doesn't use > UTF-8. It can be used with the kinds of encodings found in the > subdirectories of https://pkg.go.dev/golang.org/x/text/encoding. > > Ian > Thanks, Ian. It might be moot, because it looks like the encoding declaration in the XML that I have is lying. But in general the solution would need to sniff the first line and then try for finding the encoding declaration. I suspect that this is what other languages do in this situation. 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/3277068af53ec326a6b3163e4f6d0242b96aa81a.camel%40kortschak.io.
Re: [go-nuts] how is xml.Decoder.CharsetReader supposed to be held?
On Fri, 2022-05-06 at 11:22 +0200, Diego Joss wrote: > Does this work for you? > > https://go.dev/play/p/xLRawVhcRtF > Thanks. No, the documents are in UTF-16, and the procinst will be too. So it looks more like this https://go.dev/play/p/4IcXNI3yd2M. If I pull the proc inst out of the UTF-16, then I can get it to work; https://go.dev/play/p/kHwkVWtxbNO. But this leads to the issue where at that point I could just decode the whole message and pass it through. So I don't really see the point of using CharsetReader (at least not with UTF-16). 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/b3554811bb056f6741c4b2f484abd2fb7e801f6f.camel%40kortschak.io.
[go-nuts] how is xml.Decoder.CharsetReader supposed to be held?
I'm in the situation of needing to provide cross-platform xml decoding. So I thought that xml.Decoder.CharsetReader would be the right approach in conjunction with golag.org/x/text/encoding. However, the xml decoder needs to be able to understand the text in order to be able to read the proc inst to get the charset out to hand to CharsetReader. So it seems that we need to get the proc inst out from the io.Reader input, deduce the charset and convert it to UTF-8 and then reinject it into the io.Reader so that the charset can then be passed to CharsetReader. This can't be the right way to do things. I'm wondering what is the use of CharsetReader if it can't be used to determine the charset without already having determined the charset. How should it be used? 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/b682b574be51ed8cf1f4c1f02b4170e0560b2f6b.camel%40kortschak.io.
Re: [go-nuts] go fails to detect a point-time race condition
On Sat, 2022-04-30 at 22:49 -0700, Zhaoxun Yan wrote: > I am sure it did not detect race immediately at least in my > project, which has similar global variable race conditions, but in a > more subtle way . > > For example, the checking of one global variable is from an > incoming message from a remote host, while the changing of the global > variable is from a crontask. They have a possibility to collide, but > my race build did not crash because of it yet. You have not confirmed that you are running the executable that was built with the race detector. However, yes it is entirely possible that the race detector can fail to detect a potential race condition (see "How it works" in the Go blog post that introduced it https://go.dev/blog/race-detector). This is because it is not a static analysis tool. If your race is infrequent it is possible for the sequence of concurrent reads and writes to not happen during an execution. If you are confident that there is a potential race condition in your code, you can either fix it or attempt to increase the frequency of the raciness and make yourself satisfied that it is there with the race detector and then fix it. 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/b184c33cf13db45eddfae8d04060d91d3c438d45.camel%40kortschak.io.
Re: [go-nuts] go fails to detect a point-time race condition
On Fri, 2022-04-29 at 23:29 -0700, Zhaoxun Yan wrote: > Hi Dan! > > I did as you told, but go build -race still not functions: > zxun@zxun-virtual:~/src/race2$ go build > zxun@zxun-virtual:~/src/race2$ ls > race2 race.go > zxun@zxun-virtual:~/src/race2$ go build -race race2 > zxun@zxun-virtual:~/src/race2$ go run -race race.go Try this: ./race2 -- 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/f77bc42928d875b64fafa76da8874e63a4c52d1b.camel%40kortschak.io.
Re: [go-nuts] go fails to detect a point-time race condition
On Fri, 2022-04-29 at 23:18 -0700, Zhaoxun Yan wrote: > And then in that folder you run: > # go build -race > Nothing happens, at least in my go1.15 The race detector needs to run to detect data races; it's not a static analysis tool. So if you execute the binary that you built with `go build -race` you should see the race report. 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/cd0f1261a31406e92affdabb66dcdba0348bb4ce.camel%40kortschak.io.
Re: [go-nuts] Possible fuzz testing issue on Windows
On Mon, 2022-04-25 at 05:39 +, 'Dan Kortschak' via golang-nuts wrote: > > I suspect that this is from GitHub checking out the code on windows > with autocrlf and so converting perfectly sensible \n to \r\n, which > is > then not properly handled by this > https://github.com/golang/go/blob/96c8cc7fea94dca8c9e23d9653157e960f2ff472/src/internal/fuzz/encoding.go#L105 > . > > It would be worth filing an issue for this. I have sent https://go-review.googlesource.com/c/go/+/402074 to address 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/546f0e51c913fc9a393ef08ab2f8bd8e31e99150.camel%40kortschak.io.
Re: [go-nuts] Possible fuzz testing issue on Windows
On Sun, 2022-04-24 at 05:21 -0700, Tiago Katcipis wrote: > Hi, > > I was playing around with Go's fuzz support on a pet project of mine > and as the fuzzer found some offending inputs it created the corpus > entries on the file system. I fixed the issues but then something > interesting happened on my CI pipeline, go test was failing only on > windows and it was failing with a panic inside the call to f.Fuzz. > > The code doing the fuzzing can be found here: > https://github.com/madlambda/jtoh/blob/b2da122b83d791f0b1c2e81adb05c698d8772220/jtoh_fuzz_test.go#L111 > > Details on the error can be seen here: > https://github.com/madlambda/jtoh/runs/5963485864?check_suite_focus=true#step:5:6 > > The panic message: "unmarshal: unknown encoding version: go test fuzz > v1". > > Following that I created a minimal project reproducing the issue: > > https://github.com/katcipis/go-fuzz-win-issue/pull/1 > > The problem persists, nothing is done on the fuzz function: > > https://github.com/katcipis/go-fuzz-win-issue/blob/main/fuzz_test.go > > It works both on macos and linux (ubuntu 20.04), but it fails on both > windows-2019/windows-2022 as can be seen here: > > https://github.com/katcipis/go-fuzz-win-issue/runs/6085678496?check_suite_focus=true > > The go version is show on the CI: > > https://github.com/katcipis/go-fuzz-win-issue/runs/6085678496?check_suite_focus=true#step:3:6 > > > Am I missing something obvious here or is there something wrong with > fuzzing on Windows targets ? > I suspect that this is from GitHub checking out the code on windows with autocrlf and so converting perfectly sensible \n to \r\n, which is then not properly handled by this https://github.com/golang/go/blob/96c8cc7fea94dca8c9e23d9653157e960f2ff472/src/internal/fuzz/encoding.go#L105 . It would be worth filing an issue for 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/6abba1ffe8319896031af36399bf65286bbe1660.camel%40kortschak.io.
Re: [go-nuts] Go 1.18: reflect implicit type conversion
On Fri, 2022-04-15 at 18:33 -0700, Dave Keck wrote:
> Hi all,
>
> In this code, the SetMapIndex line panics in Go <1.18, but it no
> longer panics in Go 1.18:
>
> type CustomString string
> m := reflect.ValueOf(map[CustomString]int{})
> m.SetMapIndex(reflect.ValueOf("key"), reflect.ValueOf(0))
>
> The panic ("value of type string is not assignable to type
> CustomString") appears to be prevented in Go 1.18 because reflect
> implicitly converts string -> CustomString, which Go <1.18 doesn't
> do.
>
> I had 2 questions:
>
> - Is it possible to get this implicit conversion behavior in
> earlier versions of Go? Specifically, I'm using Go 1.16 + the
> firestore package, and I'd like to use custom string types as map
> keys.
>
> - Is this change discussed anywhere?
>
> Thanks!
>
> David
This is not mentioned in the release notes. I think it is a bug in
1.18; he docs still say that "As in Go, key's elem must be assignable
to the map's key type". This is not the case here.
Bisected to 23832ba2e2fb396cda1dacf3e8afcb38ec36dcba which touches
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/c0795806d084d61fc36bf4b8843a098023c781b7.camel%40kortschak.io.
Re: [go-nuts] Tool to check binaries for vulnerabilities
On Thu, 2022-04-14 at 03:05 -0700, Michel Casabianca wrote: > Any comment and contribution welcome. Can I suggest that you use golang.org/x/sys/execabs rather than os/exec in ExecCommand? -- 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/23893aa067930681ed084b09fee6b14a9e1a14b4.camel%40kortschak.io.
Re: [go-nuts] evaluation of range expression in for-range loop
On Fri, 2022-03-18 at 04:43 -0700, Jochen Voss wrote:
> Dear all,
>
> The spec at https://go.dev/ref/spec#For_range says
>
> "The range expression x is evaluated once before beginning the loop,
> with one exception: if at most one iteration variable is present
> and len(x) is constant, the range expression is not evaluated."
>
> What does the second half of this sentence mean?
>
> My guess was that this says that in "for i := range [3]int{1, 2, f()}
> ..." the function f is not called, but I quick experiment shows that
> this guess is wrong, see https://go.dev/play/p/MXqH_C7mllx .
>
> All the best,
> Jochen
If you have `a := [5]int{1,2,3,4,5}` and something like `for i := range
a {` then the range expression `a` is not evaluated since the length of
the array is a constant and the only information that is needed if the
the length. Similarly, if it were `for _, v := a {` the expression does
not need to be evaluated since the element values can't be mutated
during the iteration. Same for `for range a {`.
On the other hand, if you have `for i, v := range a {` then the
expression *is* evaluated before the start of the loop.
The evaluation of a function in an array is a separate issue.
--
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/53b40e26bf5b0deb52219bb5e7f964469d5d1a5e.camel%40kortschak.io.
Re: [go-nuts] Constrain a type to be either a slice or a map
On Thu, 2022-03-17 at 18:47 -0700, RussellLuo wrote:
> Is there any way to write a constraint, say, SliceOrMap, to support
> either a slice or a map?
>
> With the help of SliceOrMap, then I can write a more generic version
> `LenBetween` like this:
>
> ```go
> func MapLenBetween[T SliceOrMap](s T, min, max int) bool {
> return len(s) >= min && len(s) <= max
> }
> ```
Not yet AFAICS, but see https://github.com/golang/go/issues/51338. If
something like that is adopted, then you could write
https://go.dev/play/p/4RyDr_u1WAM.
--
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/5e35af34528d0490243dd64e5110c7f600587eb6.camel%40kortschak.io.
[go-nuts] workspaces tutorial query
I was just taking a look at the workspaces tutorial and saw that while the doc says that adding the local example module will result in go 1.18 use ( ./hello ./example ) what actually results is go 1.18 use ( ./hello example ) The behaviour is otherwise as expected, but this may confuse some readers given that leading dots are important in other paths used by the build system. Should the doc be updated or is the tool's behaviour unexpected here? 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/d760e618722b1549d0fa83df71980c8c5db11e45.camel%40kortschak.io.
Re: [go-nuts] Pointer to a pointer
On Wed, 2022-03-09 at 18:58 -0800, shan...@gmail.com wrote:
> This morning someone asked about dereferincing a pointer to a pointer
> to a pointer
>
> At first nobody had ever thought about, let alone knew the answer,
> but some example code was shown, and sure enough ***val is possible
> ```
> package main
>
> import "fmt"
>
> func main() {
> a := 0
> b :=
> c :=
> UltimatePointOne()
> fmt.Println(a)
> }
>
> func UltimatePointOne(n ***int) {
> ***n = 1
> }
> ```
>
>
> On a lark a go playground example was tried to find what the maximum
> * is in Go
>
> https://go.dev/play/p/YhibY3p7TSD
>
> There's 28 there, but it's not the limit
>
> Does anyone know what the upper bound on this could be?
>
> 256 * ?
>
> 32k * ?
I think aspects of this thread are sad. None of us know the background
of the OP and this kind of thinking illustrates a joyful level of
curiosity that could have been answered in a way that helps the
questioner and build a positive community (for Shane, Rob did answer it
and in way that is really quite deep, and thinking about how he
answered it will teach you something that is worth learning).
Calling a question "silly" demeans the questioner without understanding
where they are coming from.
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/2ca392b4dd00815102200177bde7186d11e8e9ba.camel%40kortschak.io.
Re: [go-nuts] Example of printing in go.dev
On Wed, 2022-03-09 at 19:16 -0800, Nikhilesh Susarla wrote:
> In https://go.dev/doc/effective_go#printing
> I saw an example for printing our custom string output for the type.
> The code below is from docs.
> func (t *T) String() string {
> return fmt.Sprintf("%d/%g/%q", t.a, t.b, t.c)
> }
> fmt.Printf("%v\n", t)
>
>
> But rather the statement should be this right? fmt.Printf("%v\n",
> t.String())
> Am I missing something?
>
When the %v (or %s, %q and others[1]) verbs are used the `String()
string` is used to construct the printed value.
You can see the logic here[2].
[1]
https://github.com/golang/go/blob/00535b839841227ba60c2de78fbf767088f865bc/src/fmt/print.go#L611
[2]
https://github.com/golang/go/blob/00535b839841227ba60c2de78fbf767088f865bc/src/fmt/print.go#L623-L628
--
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/6fabecec501d706ee876483cba1f5cefecf55df5.camel%40kortschak.io.
Re: [go-nuts] Possible float64 precision problem
On Wed, 2022-03-09 at 03:37 -0800, christoph...@gmail.com wrote: > I'm translating a scientific C program into Go that is doing some > 64bit floating point operations. > > In this process I check that the same input yields the same output. > Unfortunately they don't yield the same result, though the > computation is simple. It is as follow. I receive a 64bit integer > value. > > This value is converted to float64/double, and divided by 2^64. > The resulting number is multiplied by 1e8. > > With C I get 41 6E 84 FD 00 09 90 D7, with Go I get 41 6E 84 FD 00 09 > E6 8E. The last 15bits are different. The computation is performed > with the same computer. > > Could it be that the C program is performing the computation with > long double (80 bit) precision and that Go is doing it with 64bit > precision ? > > Is there something I could do about it because that might be a red > flag for replacing the C program with a Go program. This is not very surprising depending on the algorithms that are being used/the problem that is being solved. Some problems are fundamentally difficult to solve exactly and the nature of floating point makes them sensitive to the precise set of operations used, intermediate rounding and the order of operations (even for operations that are commutative in theory). As Robert said, knowing the C compiler will be important, and I'd go further, knowing which platform you are building the Go program on can be important due to differences in how floating point operations are rendered into machine code by the compiler, or even how the processor orders apparently commutative operations. Assuming the values that you've pasted above are big endian, then the Go value is within a 1e12th of the value calculate by C ( https://go.dev/play/p/dn7G2LI75RC). This is not terrible, and maybe that level of precision is all that can be promised by the algorithm (and believing digits smaller that 1e-12 is dangerous). Alternatively there is no fundamental limit at this point and there is a better more stable algorithm that you can use (though you are only four orders of magnitude from the machine epsilon https://en.wikipedia.org/wiki/Machine_epsilon, so be aware). Floats are tricky beasts and can easily trip people up. I would suggest that you read https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html (and the more friendly https://floating-point-gui.de/). -- 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/ee58b6e5ad163014b256d249e21c875307fecddb.camel%40kortschak.io.
Re: [go-nuts] Improving on unit test styles
On Thu, 2022-03-03 at 05:50 -0800, twp...@gmail.com wrote:
> For debugging an individual test case, just skip over all but the
> failing test case:
>
> for i, testCase := range testCases {
> if i != 5 { // 5 is the index of the failing test, remove if
> statement before committing
> continue
> }
> t.Run(strconv.Itoa(i), func(t *testing.T) {
> // ...
>
> It's a quick cheap hack, but occasionally useful.
This can be done with `go test -run ^TestTheTest/5$`. Meaningful names
make it even better.
--
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/92defab99276c7729c8181a285dc260357f651db.camel%40kortschak.io.
Re: [go-nuts] Improving on unit test styles
On Fri, 2022-02-25 at 09:26 -0800, 'Markus Zimmermann' via golang-nuts wrote: > Would appreciate your feedback on the style and extension. Would be > also interesting to hear other approaches and conventions that could > help others to write better tests. I'm struggling to understand how you capture stack traces that are meaningful to the tested code in any general kind of way — ignoring for a moment the reduced utility of stack traces in concurrent code. Surely you get stack traces for the assertion, by which time the interesting code has passed. Are you doing more than that? -- 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/fa6bdd0efd62787d01b2776916f2c4ea8c5d6554.camel%40kortschak.io.
Re: [go-nuts] Re: DataRace with slice, should i fix it or ignore it?
On Thu, 2022-02-10 at 09:15 -0800, jake...@gmail.com wrote: > > On Wednesday, February 9, 2022 at 9:14:52 AM UTC-5 peterGo wrote: > > Pelen Li, > > > > Always fix your data races. You should consider the results of data > > races as undefined. > > > > Dmitry Vyukov, who implemented the Go race detector, once wrote an > > interesting article with the title: "Benign data races: what could > > possibly go wrong?" > > > > https://twitter.com/dvyukov/status/288858957827682304 > > This article by Dmitry Vyukov was an "oldie but goodie". I have used > it as reference in these kinds of discussions before. Unfortunately, > AFAICT, the article is no longer available on Intel's site. I have > been unable to locate an alternate location. If anyone knows where I > can find it, I would appreciate the info. > It is on the way back machine https://web.archive.org/web/20150604005924/http://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong -- 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/6e4094beb85981541b805c3635224990a8128c01.camel%40kortschak.io.
Re: [go-nuts] Is Go good choice for porting graph based app?
On Thu, 2022-02-03 at 14:26 -0800, Kamil Ziemian wrote: > Hello, > > I was handed proof-of-concept app written in Python. It seems > underdeveloped, buggy and running it first time is a pain, because of > dependencies. Basically it need to read some graphs stored in JSON > files and manipulated them accordingly and write them to JSON files > again. > > It seems that porting it now to more suitable language is worth a > gain at this stage and I wonder if Go is a good choice? I read and > watch many Ian Lance Taylor presentations about generics, so I know > that only that generic graph (tree) data structure is something that > can be a pain, but in this case it would be were small issue. It > seems that we have only few data types to be stored in graph, mostly > strings and ints. > > I'm not true gopher, so I don't know if Go is proper choice for this > task. I don't believe that Python is any better, but maybe I should > check another language. > > Also, if someone know better thing to sore graphs than JSON, I would > appreciate it any suggestion. > > I don't write anymore about this app, since I don't know if company > allows for it. > I have had success writing graph handling code in Go. The answer to your question though lies in the details of what it is that you want to do. -- 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/de7029aad39c310a4b74eab497fd6fd774a9731b.camel%40kortschak.io.
Re: [go-nuts] Why Go allow function with unused arguments?
On Sun, 2022-01-30 at 13:47 -0800, Sean Liao wrote:
> By enforcing blanks, you'd lose the chance to name them something
> useful to tell the reader why they're ignored.
> eg:
> // why are the last 2 args ignored??
> handleX = func(foo, bar, _, _ string) string { return foo + bar }
>
Probably more significantly at this stage, it's a breaking change to
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/4de73f825a36057e56400544ebd3600afe66f216.camel%40kortschak.io.
Re: [go-nuts] Why Go allow function with unused arguments?
On Sun, 2022-01-30 at 12:01 -0800, Kamil Ziemian wrote:
> Hello,
>
> This is a question from ignorant in the meters of compilers and
> mediocre Go users at best, so it may be stupid.
>
> I really like that in Go unused variable or import is compiler time
> error. As such I wonder why function like
> > func funTest(x int) int {
> > return 3
> > }
> is allowed? I would guess that it is possible to check if function
> argument is used in function body or not, so it seem plausible to
> forbid it.
>
> Again, it maybe a stupid question from ignorant person. I have a lot
> things to learn about Go, but I'm stuck in learning about Unicode and
> UFT-8, so I guess it will be a long time before I can go back to
> learning proper Go. I read FAQ and I didn't remember answer to this
> question from it. This is my excuse for asking this question.
>
> Best regards,
> Kamil Ziemian
It is necessary for methods to sometimes have parameters that are not
used in order for the type to satisfy an interface. Similarly, if
function values are being passed around the signatures will need to
match even if the parameters are not being used.
It is possible to use the blank identifier in these cases to signal
that a parameter is not being used and that can be linted for.
See https://github.com/golang/go/issues/39118 for discussion on a
proposal relating to 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/78c6d5db02f0f35230b60b8324189eb367cee209.camel%40kortschak.io.
