Re: [go-nuts] [generics] type list should not pass newtypes

2020-06-27 Thread Ian Lance Taylor
On Sat, Jun 27, 2020 at 3:06 PM tdakkota  wrote:
>
> I think, if I want int/[]int, I should use int/[]int or just declare a domain 
> specific alias.
> MyInt/[]MyInt should implement Lesser/Min/etc interface. It can declare 
> specific comparison rules.
>
> Min implementation can be like: https://go2goplay.golang.org/p/Fgo2fJAlKXD 
> (this code does not compile, I don't know why)
>
> My point is that this decision is not Go1-like and can cause unexpected 
> runtime errors.

If we don't match on underlying types, then we can't use the <
operator on elements of a value of type []MyInt.  Requiring people to
explicitly declare a Less method on an integer type seems like
unnecessary boilerplate that should be avoided.  If we're going to do
that, why have type lists at all?  Why not always require people to
declare a method?

Your example doesn't compile because Go doesn't have any conversion
from a slice of one type to a slice of a different type.

Go today has nothing like type lists.  I don't agree that having type
lists match underlying types is not Go1-like, because I don't think
current Go has anything to say about type lists.

Ian


> суббота, 27 июня 2020 г. в 23:03:25 UTC+3, Ian Lance Taylor:
>>
>> On Sat, Jun 27, 2020 at 12:35 PM a b  wrote:
>> >
>> > Newtype is a expression like
>> > type MyInt int
>> >
>> > It's not the same type as int, so why it's permitted?
>> > In Go1 you must perform explicit conversion.
>>
>> Because if you have a []MyInt, it would be nice to be able to pass
>> that to a function like slices.Min. Note that you can't directly
>> convert []MyInt to []int.
>>
>> Ian
>
> --
> 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/5b246c09-e64b-47ff-b2ef-1c4f9ea7ea94n%40googlegroups.com.

-- 
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/CAOyqgcUphBzHJE-%2BA%3DtV6_Ni6Nta1HWo1W5Ph3mppvv4USTD5g%40mail.gmail.com.


[go-nuts] Re: go.pkg.dev missing golang packages

2020-06-27 Thread Jonathan Amsterdam
You can open an issue on the Go issue tracker. Use this 
link: https://golang.org/s/discovery-feedback.

I filed https://golang.org/issue/39894.

On Saturday, June 27, 2020 at 1:20:15 PM UTC-4, Steve Roth wrote:
>
> I understand that some Go package documentation is not documented on 
> go.pkg.dev for licensing reasons.  However, I would not have expected 
> that packages maintained by the Go team itself would have such problems.  
> Yesterday I discovered, for example, that the documentation for 
> github.com/golang/freetype is not shown on go.pkg.dev.
>
> Is it a reasonable expectation that anything under github.com/golang 
> should be documented on go.pkg.dev?  And if so, what is the proper path 
> to report this issue?
>
> Regards,
> Steve
>
>

-- 
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/a63e12b7-2633-4c00-acc8-8a5aa36aea57o%40googlegroups.com.


Re: [go-nuts] [generics] type list should not pass newtypes

2020-06-27 Thread tdakkota
I think, if I want int/[]int, I should use int/[]int or just declare a 
domain specific alias.
MyInt/[]MyInt should implement Lesser/Min/etc interface. It can declare 
specific comparison rules.

Min implementation can be like: https://go2goplay.golang.org/p/Fgo2fJAlKXD 
(this code does not compile, I don't know why)

My point is that this decision is not Go1-like and can cause unexpected 
runtime errors.

суббота, 27 июня 2020 г. в 23:03:25 UTC+3, Ian Lance Taylor: 

> On Sat, Jun 27, 2020 at 12:35 PM a b  wrote:
> >
> > Newtype is a expression like
> > type MyInt int
> >
> > It's not the same type as int, so why it's permitted?
> > In Go1 you must perform explicit conversion.
>
> Because if you have a []MyInt, it would be nice to be able to pass
> that to a function like slices.Min. Note that you can't directly
> convert []MyInt to []int.
>
> Ian
>

-- 
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/5b246c09-e64b-47ff-b2ef-1c4f9ea7ea94n%40googlegroups.com.


Re: [go-nuts] [generics] type list should not pass newtypes

2020-06-27 Thread Ian Lance Taylor
On Sat, Jun 27, 2020 at 12:35 PM a b  wrote:
>
> Newtype is a expression like
> type MyInt int
>
> It's not the same type as int, so why it's permitted?
> In Go1 you must perform explicit conversion.

Because if you have a []MyInt, it would be nice to be able to pass
that to a function like slices.Min.  Note that you can't directly
convert []MyInt to []int.

Ian

-- 
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/CAOyqgcUzF41ifiDHN6mrLpiHxz%2BhnkZKzCpTX8SAB_PHHJhJ-Q%40mail.gmail.com.


Re: [go-nuts] [generics] Syntax feedback

2020-06-27 Thread Ian Lance Taylor
On Sat, Jun 27, 2020 at 10:46 AM Tyler Compton  wrote:
>
> This topic has been discussed many times on this list, so it's probably best 
> to look at and post in one of those threads. Let me take this chance to 
> collect as much information about this issue as I can in a single post.
> Unfortunately, discoverability can sometimes be hard on mailing lists so I 
> don't blame you for not seeing all these.
>
> Responses on the subject:
> Design draft talking about alternative syntax: 
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java
> Ian's justification for taking a wait-and-see approach to this syntax issue: 
> https://groups.google.com/g/golang-nuts/c/Rumm5HFhg_Q
>
> Threads:
> Use "<>": https://groups.google.com/g/golang-nuts/c/LvkOBA2D_Bk
> Use "<>": https://groups.google.com/g/golang-nuts/c/B1Q1dsLa5rk
> Use "::" and other suggestions: 
> https://groups.google.com/g/golang-nuts/c/b0GydCIn7T0
> Use "(<>)": https://groups.google.com/g/golang-nuts/c/tYwWeiMztiI
> Use "<>" before the name of the type being defined: 
> https://groups.google.com/g/golang-nuts/c/TJWGbrx2o34
> Put type parameters in the regular arguments list with a ":type" suffix: 
> https://groups.google.com/g/golang-nuts/c/K7s-5MeXuzM
> Use "<>", with some kind of additional syntax to make parsing easier: 
> https://groups.google.com/g/golang-nuts/c/SaDkSQdgF9g
> Use "<>": https://groups.google.com/g/golang-nuts/c/coi7YS0KPgQ
> Use "<>": https://groups.google.com/g/golang-nuts/c/ydySSqZqi-0
> Use ":[]": https://groups.google.com/g/golang-nuts/c/zGQq_I5r2jg
> No specific suggestion: https://groups.google.com/g/golang-nuts/c/mY_36VU5ij8

Thanks for collecting that list.

Ian

-- 
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/CAOyqgcU7Rck4s7WWnG6Jn2%3DqpLsG_xMXkROU1XeLm%3DOZLK0thQ%40mail.gmail.com.


Re: [go-nuts] [generics] Syntax feedback

2020-06-27 Thread t hepudds
Hi Tyler,

I just wanted to say a quick thank you for pulling those references together 
and your thoughtful response in this thread. 

Hopefully the time you spent doing that will help additional gophers as the 
generics discussion continues on this list.

Regards,
thepudds

-- 
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/e2c1cb6a-06e7-48ad-9dce-145513ac0b61o%40googlegroups.com.


Re: [go-nuts] Re: Graphic Go Algorithms: Graphically learn data structures and algorithms better than before

2020-06-27 Thread tim Hu
German user please try this link:

https://www.amazon.de/dp/B08BFXNTFF

Have a nice day.

在 2020年6月26日星期五 UTC+6上午11:42:47,Christian Staffa写道:
>
> it seems not to be available for germany users 郎
>
> Sent from my iPhone
>
> On 25. Jun 2020, at 21:20, Yesudeep Mangalapilly  > wrote:
>
> 
> Hey, thanks for this. It looks good!
>
> On Wednesday, June 24, 2020 at 7:58:49 PM UTC-7, huya...@gmail.com wrote:
>>
>> free book just 5 day left
>>
>> https://www.amazon.com/gp/product/B08BFXNTFF
>>
>> [image: Graphic Go Algorithms: Graphically learn data structures and 
>> algorithms better than before by [yang hu]]
>>
>> Discover how graph algorithms can help you leverage the relationships 
>> within your data to develop more intelligent solutions and enhance your 
>> algorithms. You’ll learn how graph analytics are uniquely suited to unfold 
>> complex structures and reveal difficult-to-find patterns lurking in your 
>> data. this book illustrates how graph algorithms deliver data structure and 
>> algorithms
>>
>> This practical book walks you through hands-on examples of how to use 
>> graph algorithms in Go.
>> Learn how graph analytics vary from conventional algorithms analysis
>> Understand how classic graph algorithms work, and how they are applied
>> Explore algorithm examples with working code and sample dada.
>>
>> The complexity of life, because they do not understand to simplify the 
>> complex, simple is the beginning of wisdom. From the essence of 
>> practice,this book to briefly explain the concept and vividly cultivate 
>> programming interest, you will learn it easy, fast and well.
>>
> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/bea4241c-2d0c-449c-81b5-9892892c93f3o%40googlegroups.com
>  
> 
> .
>
>

-- 
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/26b95ce1-e4b4-4abd-8883-9153ce58ceceo%40googlegroups.com.


[go-nuts] [generics] type list should not pass newtypes

2020-06-27 Thread a b
Newtype is a expression like
type MyInt int

It's not the same type as int, so why it's permitted?
In Go1 you must perform explicit conversion. 

For example,

type Float interface {
type float32, float64
}

func NewtonSqrt(type T Float)(v T) T {
var iterations int
switch (interface{})(v).(type) {
case float32:
iterations = 4
case float64:
iterations = 5
default:
panic("unreachable") // float cannot be nil, any other types are prohibited 
by type checker
}
// Code omitted.
}

type MyFloat float32

var myFloatValue MyFloat = MyFloat(64)
var G = NewtonSqrt(float32(myFloatValue)) // MyFloat is converted to 
float32 explicitly 

-- 
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/f1dbb9dc-0620-48e4-94e4-240b84f00caen%40googlegroups.com.


Re: [go-nuts] [generics] Syntax feedback

2020-06-27 Thread Tyler Compton
Hi Rob,

This topic has been discussed many times on this list, so it's probably
best to look at and post in one of those threads. Let me take this chance
to collect as much information about this issue as I can in a single post.
Unfortunately, discoverability can sometimes be hard on mailing lists so I
don't blame you for not seeing all these.

Responses on the subject:
Design draft talking about alternative syntax:
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java
Ian's justification for taking a wait-and-see approach to this syntax
issue: https://groups.google.com/g/golang-nuts/c/Rumm5HFhg_Q

Threads:
Use "<>": https://groups.google.com/g/golang-nuts/c/LvkOBA2D_Bk
Use "<>": https://groups.google.com/g/golang-nuts/c/B1Q1dsLa5rk
Use "::" and other suggestions:
https://groups.google.com/g/golang-nuts/c/b0GydCIn7T0
Use "(<>)": https://groups.google.com/g/golang-nuts/c/tYwWeiMztiI
Use "<>" before the name of the type being defined:
https://groups.google.com/g/golang-nuts/c/TJWGbrx2o34
Put type parameters in the regular arguments list with a ":type" suffix:
https://groups.google.com/g/golang-nuts/c/K7s-5MeXuzM
Use "<>", with some kind of additional syntax to make parsing easier:
https://groups.google.com/g/golang-nuts/c/SaDkSQdgF9g
Use "<>": https://groups.google.com/g/golang-nuts/c/coi7YS0KPgQ
Use "<>": https://groups.google.com/g/golang-nuts/c/ydySSqZqi-0
Use ":[]": https://groups.google.com/g/golang-nuts/c/zGQq_I5r2jg
No specific suggestion:
https://groups.google.com/g/golang-nuts/c/mY_36VU5ij8


On Sat, Jun 27, 2020, 05:38 Rob Reid  wrote:

> Hi team,
>
> I wanted to provide some feedback on the syntax used in the generics
> proposal.
>
> When I first opened the Go 2 playground, it took me a while to realise
> that (type T) was a generic parameter and not a function parameter and that
> (s []T) was a function parameter and not a return parameter):
>
> func Print*(type T)(s []T)* {
> for _, v := range s {
> fmt.Print(v)
> }
> }
>
> I think this would start to look more confusing when there are return
> values (either single or multiple):
>
> func Something*(type T)(s []T) (T, T)*
>
> I think another character would server to improve the readability of the
> Print function in this example and hopefully prevent the time required to
> grok a generic function to someone who has not seen one in Go before:
>
> func Print*(s []T)* {
> for _, v := range s {
> fmt.Print(v)
> }
> }
>
> func Print*[type T](s []T)* {
> for _, v := range s {
> fmt.Print(v)
> }
> }
>
>
> Cheers,
>
> Rob
>
> --
> 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/CA%2Bcy9cUuJqOWWwi4m-MSp6gxKLGC4oFNn6y1zYJgN0Aac31sFg%40mail.gmail.com
> 
> .
>

-- 
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/CAA%3DXfu2VxFv9DeBhpX1F6urHHTQLxka82P4JAZuQWuRQCsDfRA%40mail.gmail.com.


[go-nuts] go.pkg.dev missing golang packages

2020-06-27 Thread Steve Roth
I understand that some Go package documentation is not documented on
go.pkg.dev for licensing reasons.  However, I would not have expected that
packages maintained by the Go team itself would have such problems.
Yesterday I discovered, for example, that the documentation for
github.com/golang/freetype is not shown on go.pkg.dev.

Is it a reasonable expectation that anything under github.com/golang should
be documented on go.pkg.dev?  And if so, what is the proper path to report
this issue?

Regards,
Steve

-- 
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/CAAnpqKHdm8DYeZ-43HKMekyJ--ypCE_gdG7Er0T95SZSS1OSUw%40mail.gmail.com.


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

2020-06-27 Thread David Riley
On Jun 27, 2020, at 8:30 AM, Robert Engels  wrote:
> 
> Just because the bulk of the time is in the decode doesn’t mean the decode is 
> inefficient or can be improved upon. It might be the most expensive stage in 
> the process regardless of the implementation. 

This is I think the most important point; image decoding is an expensive 
operation, and it makes sense that the bulk of your time decoding is spent on 
it.  The question is how it stacks up to other decoders; if you're able to 
write a quick C proof-of-concept to test how fast libpng does it (or libspng) 
and run the same benchmarks, you'll get your answer there.

Depending on how regular your images are (size-wise, especially), you may be 
able to get some additional mileage out of pooling your receiving buffers and 
reusing them after your operations are complete. There doesn't appear to be a 
handle for that in the current image/png library like there is for encoding, 
though; you'd have to do some surgery on decoder.readImagePass to do something 
like that.


- Dave

-- 
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/5F296DCC-1521-4D04-9D93-9BCEB6B5B537%40gmail.com.


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

2020-06-27 Thread Michael Jones
An easy "comfort" exercise:

save 1000 images to a directory in png form.
decode with go and with several tools such as imagemagick
compare times

for format in jpeg, tiff, ...
convert all images to that format; do the test above anew

the result will be a comparison chart of Go existing image decoders vs X in
various image formats for your images.

if it is within a few percent, you can be comfortable
if it is much slower, be uncomfortable and report a performance bug.
if it is faster, be happy.

michael

On Sat, Jun 27, 2020 at 5:31 AM Robert Engels  wrote:

> Just because the bulk of the time is in the decode doesn’t mean the decode
> is inefficient or can be improved upon. It might be the most expensive
> stage in the process regardless of the implementation.
>
> On Jun 27, 2020, at 12:15 AM, Lee Armstrong  wrote:
>
> 
> 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 able to reuse decoders at all and even if that would
> help!
>
>
> On Sat, 27 Jun 2020 at 01:30, Rob Pike  wrote:
>
>> 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 problems like this, the more information you
>> can provide, the better.
>>
>> -rob
>>
>>
>> On Fri, Jun 26, 2020 at 10:59 PM Lee Armstrong  wrote:
>>
>>> 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 Jun 26, 2020, at 7:51 AM, howar...@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 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 package. It is a CGO interface to libvips, which is an experimental
 branch of libspng, which is a performance focused alternative to libpng.

 Howard

 --
 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...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/golang-nuts/9f8d3086-75f4-47e1-b49a-4dce057258cco%40googlegroups.com
 
 .

 --
>>> 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/d694c7d7-8438-4d7c-93ab-46cccaf09b65n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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/CAC5LoL_yWxgfDUCs5UwStep-dOMoWovpF_RK0K_MuPNzsG6Unw%40mail.gmail.com
> 
> .
>
> --
> 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/D4EB5766-01C2-4025-898E-0768A302C8DF%40ix.netcom.com
> 
> .
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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] [generics] Syntax feedback

2020-06-27 Thread Rob Reid
Hi team,

I wanted to provide some feedback on the syntax used in the generics
proposal.

When I first opened the Go 2 playground, it took me a while to realise that
(type T) was a generic parameter and not a function parameter and that (s
[]T) was a function parameter and not a return parameter):

func Print*(type T)(s []T)* {
for _, v := range s {
fmt.Print(v)
}
}

I think this would start to look more confusing when there are return
values (either single or multiple):

func Something*(type T)(s []T) (T, T)*

I think another character would server to improve the readability of the
Print function in this example and hopefully prevent the time required to
grok a generic function to someone who has not seen one in Go before:

func Print*(s []T)* {
for _, v := range s {
fmt.Print(v)
}
}

func Print*[type T](s []T)* {
for _, v := range s {
fmt.Print(v)
}
}


Cheers,

Rob

-- 
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/CA%2Bcy9cUuJqOWWwi4m-MSp6gxKLGC4oFNn6y1zYJgN0Aac31sFg%40mail.gmail.com.


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

2020-06-27 Thread Robert Engels
Just because the bulk of the time is in the decode doesn’t mean the decode is 
inefficient or can be improved upon. It might be the most expensive stage in 
the process regardless of the implementation. 

> On Jun 27, 2020, at 12:15 AM, Lee Armstrong  wrote:
> 
> 
> 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 able to reuse decoders at all and even if that would help!
> 
> 
> 
>> On Sat, 27 Jun 2020 at 01:30, Rob Pike  wrote:
>> 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 problems like this, the more information you can 
>> provide, the better.
>> 
>> -rob
>> 
>> 
 On Fri, Jun 26, 2020 at 10:59 PM Lee Armstrong  wrote:
 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 Jun 26, 2020, at 7:51 AM, howar...@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 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 package. It is a CGO interface to libvips, which is an 
>> experimental branch of libspng, which is a performance focused 
>> alternative to libpng.
>> 
>> Howard
> 
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/9f8d3086-75f4-47e1-b49a-4dce057258cco%40googlegroups.com.
 
 -- 
 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/d694c7d7-8438-4d7c-93ab-46cccaf09b65n%40googlegroups.com.
> 
> -- 
> 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/CAC5LoL_yWxgfDUCs5UwStep-dOMoWovpF_RK0K_MuPNzsG6Unw%40mail.gmail.com.

-- 
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/D4EB5766-01C2-4025-898E-0768A302C8DF%40ix.netcom.com.


[go-nuts] Re: [generics] I think it's better have higher perfomance than lower compiling time

2020-06-27 Thread Viktor Kojouharov
I seem to recall that the compilation time of C (and C++) programs is 
directly proportional to the number of includes your program has. I'm sure 
that monomorphisation in C++ exacts some kind of cost to the compilation 
time, but perhaps it's not as much as people seem to think.


On Friday, June 19, 2020 at 9:14:20 PM UTC+3, howar...@gmail.com wrote:
>
> I think in general this is not the attitude of the Go developers, nor the 
> Go community - fast compilation was an explicit design goal of the original 
> creation of Go (as a reaction to slow compile times with C++), and has 
> remained a concern.
>
> From the FAQ, https://golang.org/doc/faq#creating_a_new_language , 
> " Finally, working with Go is intended to be fast: it should take at most a 
> few seconds to build a large executable on a single computer."
>
> It is certainly not their only concern or focus, they also mention "One 
> had to choose either efficient compilation, efficient execution, or ease of 
> programming; all three were not available in the same mainstream language."
>
> We have seen performance decreases in some language versions, but we have 
> also seen performance increases. Efficient execution is a project goal, but 
> efficient compilation is as well, so I would not recommend hoping for or 
> expecting that performance issues in execution would be resolved via 
> additional passes in or excessive time added to compilation.
>
> However, if you do see any major performance regression in a new version, 
> do report it - they have historically paid attention to these reports and 
> often resolved issues in subsequent updates; see 
> https://github.com/golang/go/issues/19096 , 
> https://github.com/golang/go/issues/16407 , and 
> https://go-review.googlesource.com/c/go/+/30163/
>
> Consider also these headlines:
>
> Go 1.7 to Improve Compilation Speed and Generate Faster Code
> Google's Go language takes on compilation speed (about Go 1.8)
> Faster builds in Docker with Go 1.11
>
> Howard
>
> On Friday, June 19, 2020 at 12:23:46 PM UTC-5, Ronald Davilla wrote:
>>
>> Just if perfomance will decrease with every release/version, it'd be not 
>> really good, and it's might be necessary to pay more attention 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/6bb30384-aa83-4a7d-9b51-3e825fe9790do%40googlegroups.com.


[go-nuts] Go, git and github questions

2020-06-27 Thread Joe McGuckin
1). When I use ‘go get’ to download some source code from github, is the 
src directory a regular ‘git’ directory?

2).i want to download some go code from github and make a bunch of local 
changes. Just ‘go get’ and start editing? Nothing else I need to do?

Thanks

-- 
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/25657915-2398-4f5b-b512-4a19d7821eaco%40googlegroups.com.


[go-nuts] for learn GoCV, I make simple RPA tool.

2020-06-27 Thread 加藤泰隆
for learn GoCV, I make simple RPA tool.
Probably, As far as I know, This is the one single file RPA tool.

https://github.com/yasutakatou/rabbitRPA

I would like to know if you have any ideas about the following.

1. for create one file, used statik.(https://github.com/rakyll/statik)
Therefore, when run all file extract required. Another, smart idea exists?

2. When use GoCV(opencv) image capture function, too large size compared to 
the same function of robotgo(https://github.com/go-vgo/robotgo). 
But, robotgo cant't convert image to monochrome color. Better idea exists?

3. Don't want to make same capture. Therefore calcurate capture checksum.
But save capture once, then calcurate checksum. Because can't calcurate 
binary variable checksum on Golang.
Aren't you have a better idea?

-- 
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/62f5f128-c6c1-4d5f-ae6f-6748f42147f8o%40googlegroups.com.


[go-nuts] Re: defer func() { _ = resp.Body.Close() }()

2020-06-27 Thread Amnon
Apologies for replying to an old post.
But I am sometimes a bit slow in reading my messages.

I too think that errcheck's is a bit severe in its treatment of deferred 
calls to Close().

So I forked the code and changed the behaviour to be more permissive.
https://github.com/amnonbc/errcheck

Feel free to use it.

- amnon

On Wednesday, 16 August 2017 13:05:39 UTC+1, Gert wrote:
>
> To pass errcheck I need to do something like
>
> defer func() { _ = resp.Body.Close() }()
>
> instead of 
>
> defer resp.Body.Close()
>
> Is this something the errcheck tool can figure out to mark as valid 
> instead or does the errcheck tool need help from the compiler so the second 
> case is also ok?
>
>

-- 
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/0bcd5c8f-6b9a-4690-80c4-5cb5f71d3427o%40googlegroups.com.