Re: [go-nuts] why p's local run queue size is 256?

On Sun, Jan 26, 2020 at 5:48 PM jin wang wrote: > > Thank you very much, it's a fact that he change was 6 years ago, it's a pity > can't get that benchmark code. You can get the benchmark code; the benchmarks are in runtime/proc_test.go. Ian > 在 2020年1月26日星期日 UTC+8下午11:55:01，Ian Lance

[go-nuts] Problem running tour on local machine (Program exited: signal: killed)

Running on macOS Catalina version 10.15.2 When I attempt to run programs in the go tour on my local machine, most of the time the output in the browser is: Program exited: signal: killed The first program in the tour, hello.go, runs to completion some times, but most of the time it exits with

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

IMHO, golang didn't make a dent on key areas to become a language of choice like big data (analytics, complex event processing, etc.) and consequently, hot topics like artificial intelligence. Exactly areas where python excels today. -- You received this message because you are subscribed to

Re: [go-nuts] Experience report on a large Python-to-Go translation

Didn’t mean to imply anything negative - you accomplished what you set out to do. I “think in Java” and a lot of my initial problems with Go revolved around that, but even after doing some serious Go development - in the Go style - I can agree with many of your points. I will admit my bias

[go-nuts] Re: why p's local run queue size is 256?

256 run queue size is designed for the work-steal scheduler to prevent false sharing. 128 run queue size exactly fits one cache line. Since the run queue can be stolen half of the run queue from the tail by other Ps, 256 run queue size prevents false sharing when the work-steal happens on

[go-nuts] Re: Experience report on a large Python-to-Go translation

On Sunday, January 26, 2020 at 7:14:50 PM UTC-5, pboam...@gmail.com wrote: > > log.Fatal and os.Exit have the same problem. They are not "terminating > statements", so if you want them at the bottom of a function with result > parameters you have to add a panic("unreachable"). > Excellent

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

On Sunday, January 26, 2020 at 9:06:47 PM UTC-5, Robert Engels wrote: > > I think trying to write Python in Go is problematic. > Of course it is. If I were starting a Go program from scratch I certainly wouldn't try to code as though the language were Python. The real burden of my experience

Re: [go-nuts] Re: Experience report on a large Python-to-Go translation

I think trying to write Python in Go is problematic. You say you intentional did and didn’t worry about “improving” the code. Using interfaces and Go design patterns is not improving - it’s writing proper Go imo. > On Jan 26, 2020, at 6:14 PM, pboampo...@gmail.com wrote: > >  > > ===

Re: [go-nuts] why p's local run queue size is 256?

Thank you very much, it's a fact that he change was 6 years ago, it's a pity can't get that benchmark code. 在 2020年1月26日星期日 UTC+8下午11:55:01，Ian Lance Taylor写道： > > On Sun, Jan 26, 2020 at 2:31 AM jin wang > wrote: > > > > why p's local run queue size is 256, not 128 or 512? > > Well, it has

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

Dnia 2020-01-26, o godz. 14:51:00 Liam napisał(a): > Google Trends is commonly used to discern public interest in topics, No, in the IT industry GT service is used to the exact opposite. An "interest" in a programming language (or in tech) expressed as a search about it is a viable indicator

[go-nuts] Re: Experience report on a large Python-to-Go translation

> === Catchable exceptions require silly contortions === I think the community is aware of the problem but still trying to find a more Go-like solution. Take a look at some of the proposals if you haven't: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

Maybe Go is too stable and boring. Perhaps we should add wacky new features in each release, remove old features, and change the way everything else works in surprising and undocumented ways. This way all our users will be forced to google like crazy to figure out how to port their code to

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

Google Trends is commonly used to discern public interest in topics, especially emerging ones. That's not equivalent to usage, but note my title: "Go mindshare is..." For example, I've seen this chart of Python, Ruby, and Node.js posted elsewhere. It seems to reflect interest accurately.

[go-nuts] Re: Experience report on a large Python-to-Go translation

I spotted a typo: On Saturday, January 25, 2020 at 3:46:19 AM UTC-5, Eric Raymond wrote: > > The Go translation of reposurgeon is better - more maintainable - code > than the Python original, not just faster. And this is because I > rewrote or refactored as I went; as I've explained, I tried

[go-nuts] Re: Printing *go/ast.CommentGroup

On Sunday, January 26, 2020 at 1:49:15 PM UTC+11, Shane H wrote: > > Hi all, I'm trying to learn how to write a linter (because long weekend, > etc) > > I looked at Fatih's very fine blog post ( > https://arslan.io/2019/06/13/using-go-analysis-to-write-a-custom-linter/) > as well as the one

[go-nuts] Re: Experience report on a large Python-to-Go translation

Really interesting post, thank you. On iterators without leaking goroutines, have a look at the standard library's bufio.Scanner and database/sql.Rows. These provide easy iteration over arbitrary sequences in a compact idiomatic form. -- You received this message because you are subscribed to

[go-nuts] pprof "disasm" command not working?

This is perhaps due to some silly thing I am doing, but I at least have a minimal test case so I figured I'd reach out for help at this point: I cannot get "disasm" in "go tool pprof" working. "list" works correctly afaict (and weblist too), but "disasm" only prints out the total time, not the

Re: [go-nuts] Re: keep just 2 decimal places in a float64

Which is exactly what github.com/robaho/fixed and many others do! > On Jan 26, 2020, at 10:34 AM, Michael Jones wrote: > >  > ...thus the virtue of scaled integers. scaling by 100 makes cents whole, > scaling by 1*100 gives four decimal places beyond that. There is nothing > bad about

Re: [go-nuts] Re: keep just 2 decimal places in a float64

...thus the virtue of scaled integers. scaling by 100 makes cents whole, scaling by 1*100 gives four decimal places beyond that. There is nothing bad about floating point despite the reputation, it's just not the number system from algebra; nor is binary floating point the same as decimal

Re: [go-nuts] Re: keep just 2 decimal places in a float64

And from Wikipedia on the Vancouver Stock Exchange. "The history of the exchange's index provides a standard case example of large errors arising from seemingly innocuous floating point calculations. In January 1982 the index was initialized at 1000

Re: [go-nuts] Re: keep just 2 decimal places in a float64

Just an FYI, often that is not correct. Many financial systems require fractional pennies due to the volume of transactions. Think about taxing stock exchanges the pennies add up quickly at any tax rate, so they use fractional pennies to reduce the size of the error bucket. > On Jan 26,

Re: [go-nuts] why p's local run queue size is 256?

On Sun, Jan 26, 2020 at 2:31 AM jin wang wrote: > > why p's local run queue size is 256, not 128 or 512? Well, it has to be something. The choice of 256 was made when the local run queue was changed to not use mutexes, in https://golang.org/cl/46170044. Benchmarking showed that the change was

[go-nuts] Re: keep just 2 decimal places in a float64

never use floating point if you are trying to represent money, say dollars and cents or decimal values of the euro. Store the money as integer number of pennies. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and

[go-nuts] why p's local run queue size is 256?

why p's local run queue size is 256, not 128 or 512? -- 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