[go-nuts] fast exif delete library

Hi, i made a small fast exif delete library, need your contributions. https://github.com/xis/go-dexif -- 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

[go-nuts] Re: annoing: runtime error: cgo argument has Go pointer to Go pointer

No, because this is a *printf *like feature and the *callSig* is the format and the *option[] *are the arguments, which support many different types… Am Donnerstag, 30. Januar 2020 06:15:28 UTC+1 schrieb Tamás Gulácsi: > > What does "argv" hold? > > Can it be a concrete type, not an interface ?

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

Perhaps I'm doing something wrong or using the library outside of its intended purpose, but I found that this library doesn't handle Muller's Recurrence correctly. For those not familiar, Muller's Recurrence is 108 - (815-1500/z)/y https://play.golang.org/p/sePTgjZzHeY See

[go-nuts] Re: fast exif delete library

2020. február 1., szombat 15:41:52 UTC+1 időpontban Enes Furkan Olcay a következőt írta: > > Hi, i made a small fast exif delete library, need your contributions. > https://github.com/xis/go-dexif > Please implement error checking. As is, this is a very dangerous code! And slow. -- You

[go-nuts] Any chance of not deprecating GOPATH ?

Apologies for being really slow on the uptake here, but I’m just now realizing that the master plan is to actually get rid of the GOPATH mode! Is there any chance of possibly retaining it? Is it too much work to maintain both modules and GOPATH modes? I have absolutely no qualms with the

[go-nuts] Any chance of not deprecating GOPATH ?

See the "replace" directive of go.mod. replace my/pkg => ../../my/other/pkg Will use that other pkg instead of my/pkg. -- 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

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

I miss named function arguments too. The closest replacement I've discovered in Go is pass a struct literal, or pointer to such, which can then document or leave out arguments as desired. e.g. type temperature struct { fahrenheit float64 celciusfloat64 } // define func set(t

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

forgot the code...final test is what generates the report above. float128.go: https://play.golang.org/p/2MzjllLC3qT float128_test.go: https://play.golang.org/p/ZQwsFh0_Apt On Sat, Feb 1, 2020 at 7:32 PM Michael Jones wrote: > As promised, some careful results from one of the tests in my >

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

fixed only supports 8 decimals places - fixed. Without digging into the algorithm I’m sure that is the source of your issue. > On Feb 1, 2020, at 4:03 PM, craterm...@gmail.com wrote: > >  > Perhaps I'm doing something wrong or using the library outside of its > intended purpose, but I found

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

Even if fixed supports 7 decimal places, those 7 decimal places should have the same value (after rounding) as the result provided by math.Big. I suspect the precision loss is in the Div method: https://github.com/robaho/fixed/blob/master/fixed.go#L232 Manlio Perillo On Sunday, February 2,

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

I appreciate the sophisticated and math conscious discussion here. For those reading this thread in the future, I note the state of the art in Go at the moment seems to be this arbitrary precision decimal library created by the CockroachDB guys for APD standard/postgresql conformance. Note that

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

I miss named function arguments too. The closest replacement I've discovered in Go is pass a struct literal, or pointer to such, which can then document or leave out arguments as desired. e.g. type temperature struct { fahrenheit float64 celciusfloat64 } func set(temperature{celcius:

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

As promised, some careful results from one of the tests in my doubled-precision library. Rows are iteration's of Jean-Michel Muller's roundoff-intolerant Œ() function: http://perso.ens-lyon.fr/jean-michel.muller/ Columns are 32-bit floating point,64-bit floating point, my fast 128-bit library,

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

Your expectations are wrong in the sense of being overly optimistic. This is a chaotic attractor, under any form of rounding or precision it will “fail” in the way you mean (and “succeed” in proving the power of a strong attractor!) I have this as a test at home that does each step in 32, 64,

Re: [go-nuts] Any chance of not deprecating GOPATH ?

Thanks for the tip — that led me to these other relevant discussions: * https://groups.google.com/forum/#!searchin/golang-nuts/gohack$20replace$20modules * https://www.reddit.com/r/golang/comments/cvapcu/go_mod_how_to_get_it_to_find_packagesmodules_in/ * And now I understand the point of this

[go-nuts] Re: [Proposal] Change how gofmt formats struct fields

The indent man page (for formatting C code) has dozens of options to allow the user to tweak the output format. The greatest thing about gofmt great thing about gofmt is that it has no such options. No style options. No new vs old mode. Gofmt just produces a

Re: [go-nuts] [Proposal] Change how gofmt formats struct fields

On Saturday, February 1, 2020 at 12:45:23 AM UTC+1, David Riley wrote: > > On Jan 30, 2020, at 8:46 AM, Manlio Perillo > wrote: > > > > Yes. > > > > In fact I wrote that alignment should be done by the editor, not gofmt. > > In this scenario, the editor needs to understand Go formatting and