Re: [go-nuts] Re: Speed up png.Decode

2020-06-26 Thread Lee Armstrong
Thanks, I am already maxing out some servers but wondered if it could be sped up. I will give the bimg package a go! On Friday, June 26, 2020 at 1:55:40 PM UTC+1 ren...@ix.netcom.com wrote: > Just parallelize in the cloud. At a minimum parallelize locally with > multiple Go routines. > > On

[go-nuts] Re: Speed up png.Decode

2020-06-26 Thread howardcshaw
I don't know if the CGo transitions for 16 million images will completely swamp the speed gains, or how much post-processing you need to do to these images, but you might try https://github.com/h2non/bimg and see if it gives you any wins. It claims 'typically 4x faster' then the Go Image

Re: [go-nuts] Slices and inconsistency

2020-06-26 Thread David Riley
On Jun 25, 2020, at 8:49 PM, chandrak13...@gmail.com wrote: > > Essentially based on the existing capacity, the assignment of one slice > effects other slices. These are stemming from the underlying pointer > arithmetic and seems inconsistent. Looks like programmer needs to know the > history

Re: [go-nuts] Slices and inconsistency

2020-06-26 Thread Robert Engels
That is not quite true. Once is it extended beyond the current capacity you will have a new backing array and the slices will diverge. > On Jun 26, 2020, at 8:23 AM, David Riley wrote: > > On Jun 25, 2020, at 8:49 PM, chandrak13...@gmail.com wrote: >> >> Essentially based on the existing

Re: [go-nuts] Re: Speed up png.Decode

2020-06-26 Thread Robert Engels
Just parallelize in the cloud. At a minimum parallelize locally with multiple Go routines. > On Jun 26, 2020, at 7:51 AM, howardcs...@gmail.com wrote: > >  > I don't know if the CGo transitions for 16 million images will completely > swamp the speed gains, or how much post-processing you

Re: [go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Sebastien Rosset
Did you reply to the wrong thread? On Friday, June 26, 2020 at 3:09:42 PM UTC-7, Robert Engels wrote: > > What about an option to disable the signal on the thread as it crosses the > CGo boundary? This seems better than disabling the async preemption > entirely? > > On Jun 26, 2020, at 4:45 PM,

Re: [go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Robert Engels
Yes I did. Sorry all. > On Jun 26, 2020, at 7:42 PM, Sebastien Rosset wrote: > >  > Did you reply to the wrong thread? > >> On Friday, June 26, 2020 at 3:09:42 PM UTC-7, Robert Engels wrote: >> What about an option to disable the signal on the thread as it crosses the >> CGo boundary? This

Re: [go-nuts] Re: Speed up png.Decode

2020-06-26 Thread Lee Armstrong
Thanks Rob, Yes you are right these images are small. <100kb each with an example below. And as I mentioned I have millions of these. I am able to max the CPUs out with a worker pool but that is when I noticed a lot of the work was actually decoding the PNG images which made we wonder if if was

Re: [go-nuts] Slices and inconsistency

2020-06-26 Thread Robert Engels
I don’t think “how it works” is the confusion, more of “how to use it properly” My opinion is that if RTFM is required more than once for a core concept there may be a design problem. It clearly bites a lot of people. Slices are a higher level struct, as the underlying array is the same as

[go-nuts] How to do "frame" based profiling in GO?

2020-06-26 Thread michael . nischt
Hello, I'm trying to figure out how to do "frame" based profiling in GO and was redirect to this mailing--list from the `r/golang` sub (topic ). Would be amazing if anyone here can help. In short: I

Re: [go-nuts] Slices and inconsistency

2020-06-26 Thread Tyler Compton
On Fri, Jun 26, 2020 at 10:52 AM David Riley wrote: > Also, to this specific point: this exact approach, as with much of Go, > embodies the Bell Labs approach to design (for better or for worse, and > with good reason). Sometimes we have to live with the artifacts of > evolution. > One

Re: [go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Sebastien Rosset
Below are the publicly exposed asn1.ObjectIdentifier fields in the golang/go repo. It has fairly limited exposure, but I'm sure some people will argue it's too much (maybe ok in go 2.x but not 1.x?). 1. encoding/asn1: 1. My guess is this would be primarily used by SNMP applications

Re: [go-nuts] Slices and inconsistency

2020-06-26 Thread David Riley
> On Jun 26, 2020, at 2:52 PM, Tyler Compton wrote: > > On Fri, Jun 26, 2020 at 10:52 AM David Riley wrote: >> Also, to this specific point: this exact approach, as with much of Go, >> embodies the Bell Labs approach to design (for better or for worse, and with >> good reason). Sometimes

Re: [go-nuts] Slices and inconsistency

2020-06-26 Thread David Riley
On Jun 26, 2020, at 2:59 PM, Ian Lance Taylor wrote: > > I honestly don't think that append is an example of worse-is-better. > I think it's an example of preferring to pass and return values rather > than pointers. The language could easily have made append take a > pointer to a slice as its

Re: [go-nuts] Re: Speed up png.Decode

2020-06-26 Thread Rob Pike
Without information about the particular images - the data set you're working with - it's hard to provide any accurate advice. If the images are small, maybe it's all overhead. If the images are of a particular form of PNG, maybe a fast path is missing. And so on. To get meaningful help for

Re: [go-nuts] Re: accessibility of module version information in executable

2020-06-26 Thread Marvin Renich
* seank...@gmail.com [200626 12:31]: > go version -m $binary > > runtime/debug.BuildInfo Thanks much! I looked through runtime, but did not think to look at runtime/debug. I was completely unaware of the -m option to go version. ...Marvin -- You received this message because you are

Re: [go-nuts] Slices and inconsistency

2020-06-26 Thread David Riley
On Jun 26, 2020, at 1:41 PM, Robert Engels wrote: > > My opinion is that if RTFM is required more than once for a core concept > there may be a design problem. It clearly bites a lot of people. Slices are a > higher level struct, as the underlying array is the same as Java, but Java > doesn’t

Re: [go-nuts] How to do "frame" based profiling in GO?

2020-06-26 Thread Robert Engels
You want to use pprof “labels” and mark the frames. > On Jun 26, 2020, at 1:35 PM, michael.nis...@gmail.com wrote: > >  > Hello, > > I'm trying to figure out how to do "frame" based profiling in GO and was > redirect to this mailing--list from the `r/golang` sub (topic). Would be > amazing

Re: [go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Sebastien Rosset
sure, thank you. I will go through the PR review process for asn1 and x509, maybe some good ideas will come up. Sebastien On Friday, June 26, 2020 at 11:51:05 AM UTC-7, Ian Lance Taylor wrote: > > On Fri, Jun 26, 2020 at 11:03 AM Sebastien Rosset > wrote: > > > > @ianlancetaylor , thank you

[go-nuts] go.pkg.dev: blitznote.com/src/semver doesn't show up

2020-06-26 Thread Mark Kubacki
Hi, I've noticed my package, blitznote.com/src/semver, doesn't show up in pkg.go.dev despite having been licensed under one of the blessed licenses, being some months old, and having been pulled several times using the default proxy. Specifically, searching for “semver” won't produce it, even

Re: [go-nuts] Slices and inconsistency

2020-06-26 Thread David Riley
On Jun 26, 2020, at 1:41 PM, Robert Engels wrote: > > I don’t think “how it works” is the confusion, more of “how to use it > properly” > > My opinion is that if RTFM is required more than once for a core concept > there may be a design problem. It clearly bites a lot of people. Slices are a

[go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Sebastien Rosset
@ianlancetaylor , thank you for the quick reply. The reason I was asking is because potentially this could have been used to fix `type ObjectIdentifier []int` in the `encoding/asn1` package and the `crypto/x509` package. Currently these package are not fully compliant with the ASN.1

Re: [go-nuts] Slices and inconsistency

2020-06-26 Thread Ian Lance Taylor
On Fri, Jun 26, 2020 at 11:52 AM Tyler Compton wrote: > > On Fri, Jun 26, 2020 at 10:52 AM David Riley wrote: >> >> Also, to this specific point: this exact approach, as with much of Go, >> embodies the Bell Labs approach to design (for better or for worse, and with >> good reason). Sometimes

[go-nuts] Re: go.pkg.dev: blitznote.com/src/semver doesn't show up

2020-06-26 Thread 'Carla Pfaff' via golang-nuts
For me it is in the search results. Currently on page 5, fifth entry: https://pkg.go.dev/search?page=5=semver On Friday, 26 June 2020 at 21:47:30 UTC+2 Mark Kubacki wrote: > Hi, > > I've noticed my package, blitznote.com/src/semver, doesn't show up in > pkg.go.dev despite having been licensed

Re: [go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Sebastien Rosset
As an aside, the most common use of the encoding/asn1 package is most likely crypto/x509. x509. Certificate exposes public fields that use the asn1.ObjectIdentifier, so asn1 ends up being exposed in a lot of applications, such as for TLS connection management. On Friday, June 26, 2020 at

Re: [go-nuts] How to do "frame" based profiling in GO?

2020-06-26 Thread Michael Nischt
Hi, thanks for the quick reply. I tried that but I fear I don't really understand the API/tools for that. What I did was wrapping the update function called every frame like that: func profUpdate(update func(time.Duration), frame *uint64) func(time.Duration) { return func(time.Duration) {

Re: [go-nuts] Slices and inconsistency

2020-06-26 Thread howardcshaw
"If the capacity of s is not large enough to fit the additional values, append allocates a new, sufficiently large underlying array that fits both the existing slice elements and the additional values. Otherwise, append re-uses the underlying array." That seems pretty explicit to me? That's

[go-nuts] [generics] default type parameter

2020-06-26 Thread Sebastien Rosset
First apologies for initially bringing up the topic as a github issue rather than golang-nuts. I am copy-pasting my question here with @ianlancetaylor response. A default type value can be specified in C++ templates. I was asking if a similar construct been considered for go generic type

Re: [go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Ian Lance Taylor
On Fri, Jun 26, 2020 at 11:03 AM Sebastien Rosset wrote: > > @ianlancetaylor , thank you for the quick reply. The reason I was asking is > because potentially this could have been used to fix `type ObjectIdentifier > []int` in the `encoding/asn1` package and the `crypto/x509` package. >

Re: [go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Ian Lance Taylor
On Fri, Jun 26, 2020 at 12:54 PM Sebastien Rosset wrote: > > As an aside, the most common use of the encoding/asn1 package is most likely > crypto/x509. x509. Certificate exposes public fields that use the > asn1.ObjectIdentifier, so asn1 ends up being exposed in a lot of > applications, such

Re: [go-nuts] Re: [generics] default type parameter

2020-06-26 Thread Robert Engels
What about an option to disable the signal on the thread as it crosses the CGo boundary? This seems better than disabling the async preemption entirely? > On Jun 26, 2020, at 4:45 PM, Sebastien Rosset wrote: > >  > > Below are the publicly exposed asn1.ObjectIdentifier fields in the

Re: [go-nuts] Slices and inconsistency

2020-06-26 Thread David Riley
> On Jun 26, 2020, at 9:28 AM, Robert Engels wrote: > >> On Jun 26, 2020, at 8:23 AM, David Riley wrote: >> >> You are correct, the programmer needs to read the manual. Slices are >> "windows" into their underlying array, therefore assigning data into slices >> tied to a given array changes

[go-nuts] accessibility of module version information in executable

2020-06-26 Thread Marvin Renich
When building a command with go build that imports modules, does the resulting executable contain information about which modules are included as well as their versions? If so, is there a tool available to extract that information from the executable? Can the information be retrieved from within

[go-nuts] Re: accessibility of module version information in executable

2020-06-26 Thread seank...@gmail.com
go version -m $binary runtime/debug.BuildInfo On Friday, June 26, 2020 at 6:13:56 PM UTC+2 Marvin Renich wrote: > When building a command with go build that imports modules, does the > resulting executable contain information about which modules are > included as well as their versions? > > If