[go-nuts] Re: Why does Go transform os.Args[] with colons in this way (win32/x64)

Ah, bad form posting before I tried it in a plain CMD.EXE context. The args are not transformed running from the vanilla command environment. Guess it's a nasty interaction with MSYS. -Russ On Thu, 11 Jun 2020 at 20:03, Russtopia wrote: > On windows, Go 1.14 running in my case under MSYS64 >

[go-nuts] Why does Go transform os.Args[] with colons in this way (win32/x64)

On windows, Go 1.14 running in my case under MSYS64 -- > package main > import ( > "fmt" > "os" > ) > func main() { > for idx, a := range os.Args { > fmt.Printf("arg[%d]: %s\n", idx, a) > } > } $ go run argtest.go foo foo:bar foo:/bar/baz arg[0]:

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

I’ve filed an issue: https://github.com/golang/go/issues/39542 > On Jun 11, 2020, at 6:08 PM, Ray Pereda wrote: > > > I think that regexp/syntax.patchlist.append refers to line 42 here > https://golang.org/src/regexp/syntax/compile.go > > >

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

I think that regexp/syntax.patchlist.append refers to line 42 here https://golang.org/src/regexp/syntax/compile.go Using a singly linked list with a pointer to the tail pointer would give constant time append Ray On Thu, Jun 11, 2020 at 5:40 PM Andy Balholm wrote: > Right. That’s why I left

Re: [go-nuts] Re: GO on multi-processor systems

Yes, of course they have internet connections, but I don't run virtualization software. It's my understanding that most of these bugs have to do with information leaking from one process or VM to another or with a process trying to escape from it's user process into a higher privileged one.

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

Right. That’s why I left the double bar in my example. Basically all the time is spent appending to a linked list in regexp/syntax.patchlist.append. Which makes sense, because appending to a linked list when you only have a head pointer is O(n) in the length of the list. So building the whole

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

On Thu, Jun 11, 2020 at 2:57 PM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > The Graph is clearly not linear. Another way to see this is to print out > the ratio of time taken and i. If the cost is linear, you'd expect that > ratio to be constant. When I run this code >

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

The Graph is clearly not linear. Another way to see this is to print out the ratio of time taken and i. If the cost is linear, you'd expect that ratio to be constant. When I run this code https://play.golang.org/p/v1JVQkOXnEH on my machine I get 1000 6.821361ms 6821.361 2000 27.229439ms

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

Oops, I screwed up the plot in google sheets. I was only plotting the regexp length values. I fixed the plot, and only plotted the y values, runtime. The x-values are linearly spaced. There is a curve. It doesn't look linear. I think Andy is right. I did a quadratic curve fit with

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

It’s more than linear. 1 repetitions take 73 times the time of 1000 repetitions. Andy > On Jun 11, 2020, at 2:11 PM, Ray Pereda wrote: > > On my laptop, I compiled Andy's code from here: > https://play.golang.org/p/82UBmyfyqV- > I imported the

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

On my laptop, I compiled Andy's code from here: https://play.golang.org/p/82UBmyfyqV- I imported the output into google sheets and plotted it with a bar chart. https://docs.google.com/spreadsheets/d/1Pp8FBfHXgdMU54v6STutzDbb7SITGscFd84sUuJQ_gk/edit#gid=0 The runtime strongly looks linear. Still,

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

Here is a simpler reproducer: https://play.golang.org/p/82UBmyfyqV- (Running it on the playground isn’t much use because of the playground’s fake time, though.) It just repeats the string “D||” (with two vertical bars) to make the regex. The runtime is

[go-nuts] Go 1.15 Beta 1 is released

Hello gophers, We have just released go1.15beta1, a beta version of Go 1.15. It is cut from the master branch at the revision tagged go1.15beta1. Please try your production load tests and unit tests with the new version. Your help testing these pre-release versions is invaluable. Report any

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

Obviously any reasonable input validation or length limit would disallow it. The time requirement is only quadratic, not exponential, so it takes ridiculously long inputs to cause a problem. Andy > On Jun 11, 2020, at 12:26 PM, Robert Engels wrote: > > Why would you ever allow that regex? >

Re: [go-nuts] what is the complexity of regexp.MustCompile()?

Why would you ever allow that regex? > On Jun 11, 2020, at 11:01 AM, Andy Balholm wrote: > > It’s apparently quadratic in some cases. Yesterday fuzzing on > github.com/andybalholm/cascadia found an input that triggered a timeout. The > time was being spent compiling a 180-KB regex (which I’m

[go-nuts] Re: For a .net developer,how long it takes to learn go completely?

I'd say the more C-like languages you know, the easier it is to become fluent in Go. If you've already gotten used to switching between the likes of C, C++, C#, Java and more, you're likely to have fewer wrong assumptions about Go. Getting over the error handling verbosity is the major first

[go-nuts] Re: For a .net developer,how long it takes to learn go completely?

Depends on what you mean by completely. I was writing production Go code within 6 months after moving on from .NET. There are fundamental programming differences I found in the way you approach solutions. There is a lot to Go. I'm still learning after three years. I will never go back to .NET

Re: [go-nuts] For a .net developer,how long it takes to learn go completely?

On Thu, Jun 11, 2020 at 7:24 PM P Walizada wrote: > > For a .net developer,how long it takes to learn go completely? IMO Go can be learned in a day. Getting fluent and comfortable with it takes longer, but that depends on how much code one writes. The other question is, how long it takes in

Re: [go-nuts] bytes.NewBuffer(make([]byte, 0, )) allocates 4096 bytes buffer

On Thu, Jun 11, 2020 at 6:50 PM Gautam Saha wrote: > > Trying to allocate an in-memory buff of small size (few bytes) using > bytes.NewBuffer(make([]byte, 0, )) > The allocated buffer has size 4096 bytes i.e. > than what I requested for. > Why is this so? Nowhere the docs say one can control

[go-nuts] For a .net developer,how long it takes to learn go completely?

For a .net developer,how long it takes to learn go completely? -- 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

[go-nuts] Re: bytes.NewBuffer(make([]byte, 0, )) allocates 4096 bytes buffer

Can you show how you came to that conclusion? It seems to work as expected for me: https://play.golang.org/p/wPBC1VBvkde 4096 bytes is typically a page, so maybe something is going on to do with allocation on page boundaries, but need to see your code. -- You received this message because

Re: [go-nuts] Compiler error when using an interface type in a list

On Thu, Jun 11, 2020 at 10:50 AM John Sturdy wrote: > > I've defined an interface type, and a concrete type that I think implements > that interface, but when I use it in a list, I get an error from the compiler > that makes it look like it doesn't. > > Here's my interface type, in

[go-nuts] Implement package level logging

hi, logging Frameworks like log4j (for java) we can configure log levels for specific packages. My go project I am using *logrus* ( https://github.com/sirupsen/logrus) framework for logging. It doesn't support direct package level log enable disable support. I want to know few basic things

[go-nuts] bytes.NewBuffer(make([]byte, 0, )) allocates 4096 bytes buffer

Trying to allocate an in-memory buff of small size (few bytes) using bytes.NewBuffer(make([]byte, 0, )) The allocated buffer has size 4096 bytes i.e. > than what I requested for. Why is this so? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group.

Re: [go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?

The wiki page has some neat details on this https://en.m.wikipedia.org/wiki/Mac_68k_emulator > On Jun 10, 2020, at 9:49 PM, Robert Engels wrote: > > Yep. My timeline/memory was wrong. It was the 68k to PowerPC. Intel required > dual binaries. Thanks for the correction. > >> On Jun 10,

Re: [go-nuts] Re: GO on multi-processor systems

>Actually, I'd like to turn off all the cpu bug fixes (e.g. row hammer). > >It's my understanding that there is a significant performance penalty >and I >don't share my machines >with anyone else, so I'm not concerned with information leaking between > It is likely more dangerous, than you

Re: [go-nuts] Re: GO on multi-processor systems

On Thursday, 11 June 2020 01:45:53 UTC+1, joe mcguckin wrote: > > Actually, I'd like to turn off all the cpu bug fixes (e.g. row hammer). > It's my understanding that there is a significant performance penalty and I > don't share my machines > with anyone else, so I'm not concerned with

Re: [go-nuts] compress/bzip2：Why is there only a decompression function, no compression function.

My goodness, it is a great honor to get your detailed explanation. It seems that this is a fairly complicated algorithm. If I have time and can solve this problem, I try to solve it. Thank you. 在 2020年6月11日星期四 UTC+8下午12:37:30，Joe Tsai写道： > > > Why has this code called Joe Tsai never been

Re: [go-nuts] multiple-line 'expression' of if-statement not supported?

Thanks a lot, Ian, it works now. On Thursday, June 11, 2020 at 2:17:23 PM UTC+8, Ian Lance Taylor wrote: > > On Wed, Jun 10, 2020 at 11:05 PM xiang...@gmail.com > > wrote: > > > > Wondering if the 'expression' part of an if-statement should be in one > line only, given the following case,

Re: [go-nuts] multiple-line 'expression' of if-statement not supported?

On Wed, Jun 10, 2020 at 11:05 PM xiangdong...@gmail.com wrote: > > Wondering if the 'expression' part of an if-statement should be in one line > only, given the following case, 'go tool compile' will report a syntax error > > Enter code here... > package p > > func cf1() int { > return 0

[go-nuts] multiple-line 'expression' of if-statement not supported?

Hi all, Wondering if the 'expression' part of an if-statement should be in one line only, given the following case, 'go tool compile' will report a syntax error Enter code here... package p func cf1() int { return 0 } func cf2() int { return 10 } func f() { *if cf2()