Re: [go-nuts] Convert a go.mod file into checked out dependencies

2022-01-14 Thread Paul Jolly 
Hi Kevin,

As I replied on Gophers Slack:

go list -m all will give you information about dependencies. Add -json
to give you that in a more easily parsed format.

https://github.com/rogpeppe/gohack can be used to do what you want
with respect to checking out from VCS using the -vcs flag in
combination with the GOHACK env var appropriate set for the module in
question.


Paul

On Wed, 12 Jan 2022 at 18:58, Kevin Burke  wrote:
>
> Hi,
> Sometimes I just want to inspect third party code for a library, and/or edit 
> it.
>
> I'm looking for a tool that will read all of the dependencies in a go.mod 
> file and then check out all of the right versions of all of the source code 
> into the right places in a $GOPATH. Does that exist?
>
> Failing that, is there a tool that will read a go.mod file and give me 
> version information about each dependency? I see packages.Load, but that 
> doesn't seem super targeted for the use case; if it's the best that exists 
> then I'll probably make it work.
>
> Kevin
>
>
> --
> 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/18fca322-5913-4cc8-bbd3-fc84f4f0e673n%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/CACoUkn7R8%3DikgwUL%3DxGaL%3D7_-o6NMPcHK_-a28nO2m1KvrM58g%40mail.gmail.com.

Re: [go-nuts] Trace explicit goroutine function names replaced by synthetic ones 1.18beta1

2022-01-14 Thread Rich Moyse 
Ian:

Appreciate your guidance.  

Created issue #50622 .

Rich
On Friday, January 14, 2022 at 1:12:38 PM UTC-5 Ian Lance Taylor wrote:

> On Fri, Jan 14, 2022 at 10:03 AM Rich Moyse  wrote:
> >
> > When viewing a trace produced by 1.18beta1, the goroutine function names 
> reflect synthetically generated ones typically assigned to 
> anonymous/closure functions.
> >
> > For example, a function explicitly named: "msgSend" in the "main" 
> package appears on the trace "/goroutines" page as: "main.main.func1" 
> instead of "main.msgSend". This issue also occurs when viewing specific 
> goroutine events selected from the trace timeline. In this situation, the 
> event "Title" field again reflects "main.main.func1" instead of 
> "main.msgSend".
> >
> > I noticed this issue when comparing the output of a trace produced by 
> the 1.17 "go tool trace" versus the one generated by 1.18beta1.
> >
> > Has anyone else notice this issue? Am I missing some configuration 
> setting that would configure the "go tool trace" to display explicit names 
> instead of synthetic ones?
> >
> > The following github links provide the mentioned:
> >
> > go source,
> > 1.17 trace file,
> > 1.18beta1 trace file.
>
> That doesn't seem like an intended change. Please open an issue for
> this at http://go.dev/issue. Thanks.
>
> 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/7da8cd8a-8b43-4b60-b55b-beccbb504dd6n%40googlegroups.com.

Re: [go-nuts] Re: Wrong output for (*http.Request).Write with custom io.ReadCloser body

2022-01-14 Thread 'Diego Molina' via golang-nuts 
(*http.Request).Write method overrides ContentLength.

On Friday, January 14, 2022 at 4:26:44 PM UTC-3 Tamás Gulácsi wrote:

> Why not set Request.ContentLength beforehand (you know it)?
>
> dmo...@synack.com a következőt írta (2022. január 14., péntek, 18:56:57 
> UTC+1):
>
>> Sorry to insist, but I think there's also a performance issue with the 
>> current implementation. Given that the service I need to communicate to 
>> requires me to send Content-Length header I am forced to read into memory 
>> potentially large files that I want to send them, buffering them in one of 
>> the three (undocumented!) *structs that are known 
>> (*bytes.Buffer, *bytes.Reader or *strings.Reader) instead of being able to 
>> just pass the *os.File. Thing is, I could analyze the size of each file, 
>> break it down into parts that I can read into memory and make a request for 
>> each part that the service would later join into a single file, but that 
>> sounds like overkill and also sounds like a lot of work and overhead for 
>> something that could be done with a simple io.Reader.
>>
>> I think that the easiest way to overcome this issue and at the same time 
>> not break the promises made would be to do something like:
>>
>> func readerLength(body io.Reader) (int64, error) {
>> if f, _ := body.(fs.File); f != nil {
>> if i, err := f.Stat(); err == nil { // discard error and 
>> try io.Seeker interface later (it's cheaper to stat instead of seeking)
>> return i.Size(), nil
>> }
>> }
>>
>> if s, _ := body.(interface { // covers *bytes.Reader and other
>> Size() int64
>> }); s != nil {
>> return s.Size(), nil
>> }
>>
>> if l, _ := body.(interface { // covers all the three current 
>> undocumented items: *bytes.Buffer, *bytes.Reader and *strings.Reader
>> Len() int
>> }); l != nil {
>> return int64(l.Len()), nil
>> }
>>
>> if s, _ := body.(io.Seeker); s != nil { // covers a lot of other 
>> cases, like multipart.File, errors statting *os.File, etc.
>> cur, err := s.Seek(0, io.SeekCurrent)
>> if err != nil {
>> return -1, fmt.Errorf("error checking current 
>> position: %w", err)
>> }
>>
>> end, err := s.Seek(0, io.SeekEnd)
>> if err != nil {
>> return -1, fmt.Errorf("error seeking end 
>> position: %w", err)
>> }
>>
>> _, err = s.Seek(cur, io.SeekStart)
>> if err != nil {
>> return -1, fmt.Errorf("error going back to 
>> initial position: %w", err)
>> }
>>
>> return end - cur, nil
>> }
>>
>> return -1, errors.New("unknown body, don't send the 
>> Content-Length header")
>> }
>>
>>
>>
>> On Friday, September 17, 2021 at 2:23:50 PM UTC-3 Diego Molina wrote:
>>
>>> Ok, that makes total sense. I'm now using `req.TransferEncoding = 
>>> []string{"identity"}` and this behaviour is suppressed, but of course I 
>>> still don't get the Content-Length, which is fair.
>>>
>>> Thanks all!
>>>
>>> On Fri, Sep 17, 2021 at 2:09 PM Brian Candler  wrote:
>>>
 All chunks must be prefixed by a chunk length - even if that length is 
 zero.

 On Friday, 17 September 2021 at 16:53:07 UTC+1 dmo...@synack.com wrote:

> Oh, thanks for clarifying that. But still, even if transfer encoding 
> will be chunked, I don't see why it would make up a body of "0\r\n\r\n" 
> if 
> the nop body wouldn't give away any bytes at all.
>
> On Friday, September 17, 2021 at 7:56:21 AM UTC-3 seank...@gmail.com 
> wrote:
>
>> This was an intentional change in 1.8 
>> https://github.com/golang/go/issues/20257#issuecomment-299509391
>>
>> On Friday, September 17, 2021 at 6:45:13 AM UTC+2 dmo...@synack.com 
>> wrote:
>>
>>> Hi, when using a custom io.ReadCloser nop as body with method POST, 
>>> PUT, PATCH, TRACE or custom then (*http.Request).Write outputs a body 
>>> of 
>>> the form "0\r\n\r\n" (without the quotes). Proof-of-concept: 
>>> https://play.golang.org/p/Rg2cZ0wihdd
>>>
>>> Besides the fix, I think it would be useful to have body checked if 
>>> it satisfies interface{ Len() int } or something similar (this would 
>>> simplify code too by removing several type assertions, e.g., 
>>> isKnownInMemoryReader func in net/http/trans...@go1.17.1) so that we 
>>> can 
>>> avoid chunked transfer encoding.
>>>
>>> This email may contain material that is confidential for the sole 
>>> use of the intended recipient(s).  Any review, reliance or distribution 
>>> or 
>>> disclosure by others without express permission is strictly prohibited. 
>>>  If 
>>> you are not the intended

Re: [go-nuts] Re: Wrong output for (*http.Request).Write with custom io.ReadCloser body

2022-01-14 Thread Tamás Gulácsi 
Why not set Request.ContentLength beforehand (you know it)?

dmo...@synack.com a következőt írta (2022. január 14., péntek, 18:56:57 
UTC+1):

> Sorry to insist, but I think there's also a performance issue with the 
> current implementation. Given that the service I need to communicate to 
> requires me to send Content-Length header I am forced to read into memory 
> potentially large files that I want to send them, buffering them in one of 
> the three (undocumented!) *structs that are known 
> (*bytes.Buffer, *bytes.Reader or *strings.Reader) instead of being able to 
> just pass the *os.File. Thing is, I could analyze the size of each file, 
> break it down into parts that I can read into memory and make a request for 
> each part that the service would later join into a single file, but that 
> sounds like overkill and also sounds like a lot of work and overhead for 
> something that could be done with a simple io.Reader.
>
> I think that the easiest way to overcome this issue and at the same time 
> not break the promises made would be to do something like:
>
> func readerLength(body io.Reader) (int64, error) {
> if f, _ := body.(fs.File); f != nil {
> if i, err := f.Stat(); err == nil { // discard error and 
> try io.Seeker interface later (it's cheaper to stat instead of seeking)
> return i.Size(), nil
> }
> }
>
> if s, _ := body.(interface { // covers *bytes.Reader and other
> Size() int64
> }); s != nil {
> return s.Size(), nil
> }
>
> if l, _ := body.(interface { // covers all the three current 
> undocumented items: *bytes.Buffer, *bytes.Reader and *strings.Reader
> Len() int
> }); l != nil {
> return int64(l.Len()), nil
> }
>
> if s, _ := body.(io.Seeker); s != nil { // covers a lot of other 
> cases, like multipart.File, errors statting *os.File, etc.
> cur, err := s.Seek(0, io.SeekCurrent)
> if err != nil {
> return -1, fmt.Errorf("error checking current 
> position: %w", err)
> }
>
> end, err := s.Seek(0, io.SeekEnd)
> if err != nil {
> return -1, fmt.Errorf("error seeking end position: 
> %w", err)
> }
>
> _, err = s.Seek(cur, io.SeekStart)
> if err != nil {
> return -1, fmt.Errorf("error going back to initial 
> position: %w", err)
> }
>
> return end - cur, nil
> }
>
> return -1, errors.New("unknown body, don't send the Content-Length 
> header")
> }
>
>
>
> On Friday, September 17, 2021 at 2:23:50 PM UTC-3 Diego Molina wrote:
>
>> Ok, that makes total sense. I'm now using `req.TransferEncoding = 
>> []string{"identity"}` and this behaviour is suppressed, but of course I 
>> still don't get the Content-Length, which is fair.
>>
>> Thanks all!
>>
>> On Fri, Sep 17, 2021 at 2:09 PM Brian Candler  wrote:
>>
>>> All chunks must be prefixed by a chunk length - even if that length is 
>>> zero.
>>>
>>> On Friday, 17 September 2021 at 16:53:07 UTC+1 dmo...@synack.com wrote:
>>>
 Oh, thanks for clarifying that. But still, even if transfer encoding 
 will be chunked, I don't see why it would make up a body of "0\r\n\r\n" if 
 the nop body wouldn't give away any bytes at all.

 On Friday, September 17, 2021 at 7:56:21 AM UTC-3 seank...@gmail.com 
 wrote:

> This was an intentional change in 1.8 
> https://github.com/golang/go/issues/20257#issuecomment-299509391
>
> On Friday, September 17, 2021 at 6:45:13 AM UTC+2 dmo...@synack.com 
> wrote:
>
>> Hi, when using a custom io.ReadCloser nop as body with method POST, 
>> PUT, PATCH, TRACE or custom then (*http.Request).Write outputs a body of 
>> the form "0\r\n\r\n" (without the quotes). Proof-of-concept: 
>> https://play.golang.org/p/Rg2cZ0wihdd
>>
>> Besides the fix, I think it would be useful to have body checked if 
>> it satisfies interface{ Len() int } or something similar (this would 
>> simplify code too by removing several type assertions, e.g., 
>> isKnownInMemoryReader func in net/http/trans...@go1.17.1) so that we can 
>> avoid chunked transfer encoding.
>>
>> This email may contain material that is confidential for the sole use 
>> of the intended recipient(s).  Any review, reliance or distribution or 
>> disclosure by others without express permission is strictly prohibited.  
>> If 
>> you are not the intended recipient, please contact the sender and delete 
>> all copies of this message.
>>
> -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit 
>>>

Re: [go-nuts] about -buildmode c-shared

2022-01-14 Thread Ian Lance Taylor 
On Fri, Jan 14, 2022 at 9:30 AM Sven Anderson  wrote:
>
>
> On Mon, Dec 27, 2021 at 1:17 AM Ian Lance Taylor  wrote:
>>
>> Loading multiple Go DLLs built with -buildmode=c-shared ought to work
>> on ELF based systems like Linux.  I don't know whether it will work on
>> Windows or macOS.
>
>
>  I have a related question on that topic:
>
> How about support for a Go program that can load C modules (with Cgo and 
> dlopen), and this module again is a Go c-shared library?
>
> I would have assumed that does not work, due to conflicting runtimes, and it 
> indeed crashes on my Mac. But after reading your statement here, I wonder if 
> it maybe is supported on ELF based systems?

I think that could work on ELF systems, but I haven't tried it.

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/CAOyqgcUpv0zcRUjuX3henOPaPwRJz_2M2pFAjEaT-GCN9pdA9A%40mail.gmail.com.

Re: [go-nuts] Trace explicit goroutine function names replaced by synthetic ones 1.18beta1

2022-01-14 Thread Ian Lance Taylor 
On Fri, Jan 14, 2022 at 10:03 AM Rich Moyse  wrote:
>
> When viewing a trace produced by 1.18beta1,  the goroutine function names 
> reflect synthetically generated ones typically assigned to anonymous/closure 
> functions.
>
> For example, a function explicitly named:  "msgSend" in the "main" package 
> appears on the trace "/goroutines" page as: "main.main.func1" instead of 
> "main.msgSend".  This issue also occurs when viewing specific goroutine 
> events selected from the trace timeline.  In this situation, the event 
> "Title" field again reflects "main.main.func1" instead of "main.msgSend".
>
> I noticed this issue when comparing the output of a trace produced  by the 
> 1.17 "go tool trace" versus the one generated by 1.18beta1.
>
> Has anyone else notice this issue?  Am I missing some configuration setting 
> that would configure the "go tool trace" to display explicit names instead of 
> synthetic ones?
>
> The following github links provide the mentioned:
>
>  go source,
> 1.17 trace file,
> 1.18beta1 trace file.

That doesn't seem like an intended change.  Please open an issue for
this at http://go.dev/issue.  Thanks.

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/CAOyqgcWYg7Kbz6qGD9BEwLjWZzdEad2EGHvTNMBpfxM8za_Qaw%40mail.gmail.com.

[go-nuts] freetype-go no rasterizing correctly non-latin characters

2022-01-14 Thread Andres Perez 
Go 1.17.6
Windows 11 amd64
github.com/golang/freetype v0.0.0-20170609003504-e2365dfdc4a0

I'm trying to use the library to draw some text in transparent background, 
but it doesn't matter what font I use, it fails to correctly rasterize 
non-latin characters:

[image: out.png]

Here is a screenshot of Notepad using the same font:
[image: 149551692-e9a72e0f-bbba-472b-9244-8a7bf0e91d1f.png]

-- 
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/baaa3830-4394-4a99-95d6-2b71f9cb11a9n%40googlegroups.com.

[go-nuts] Trace explicit goroutine function names replaced by synthetic ones 1.18beta1

2022-01-14 Thread Rich Moyse 
When viewing a trace produced by 1.18beta1,  the goroutine function names 
reflect synthetically generated ones typically assigned to 
anonymous/closure functions.

For example, a function explicitly named:  "*msgSend*" in the "main" 
package appears on the trace "/goroutines" page as: "*main.main.func1*" 
instead of "*main.**msgSend"*.  This issue also occurs when viewing 
specific goroutine events selected from the trace timeline.  In this 
situation, the event "Title" field again reflects "*main.main.func1*" 
instead of "*main.msgSend*".

I noticed this issue when comparing the output of a trace produced  by the 
1.17 "go tool trace" versus the one generated by 1.18beta1.

Has anyone else notice this issue?  Am I missing some configuration setting 
that would configure the "go tool trace" to display explicit names instead 
of synthetic ones?

The following github links provide the mentioned:

   -  go source 
   

   ,
   - 1.17 trace file 
   

   ,
   - 1.18beta1 trace file 
   

   .
   

-- 
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/85b946dc-6afe-4b38-a2a8-4e9a02ff0e5bn%40googlegroups.com.

Re: [go-nuts] Re: Wrong output for (*http.Request).Write with custom io.ReadCloser body

2022-01-14 Thread 'Diego Molina' via golang-nuts 
Sorry to insist, but I think there's also a performance issue with the 
current implementation. Given that the service I need to communicate to 
requires me to send Content-Length header I am forced to read into memory 
potentially large files that I want to send them, buffering them in one of 
the three (undocumented!) *structs that are known 
(*bytes.Buffer, *bytes.Reader or *strings.Reader) instead of being able to 
just pass the *os.File. Thing is, I could analyze the size of each file, 
break it down into parts that I can read into memory and make a request for 
each part that the service would later join into a single file, but that 
sounds like overkill and also sounds like a lot of work and overhead for 
something that could be done with a simple io.Reader.

I think that the easiest way to overcome this issue and at the same time 
not break the promises made would be to do something like:

func readerLength(body io.Reader) (int64, error) {
if f, _ := body.(fs.File); f != nil {
if i, err := f.Stat(); err == nil { // discard error and 
try io.Seeker interface later (it's cheaper to stat instead of seeking)
return i.Size(), nil
}
}

if s, _ := body.(interface { // covers *bytes.Reader and other
Size() int64
}); s != nil {
return s.Size(), nil
}

if l, _ := body.(interface { // covers all the three current 
undocumented items: *bytes.Buffer, *bytes.Reader and *strings.Reader
Len() int
}); l != nil {
return int64(l.Len()), nil
}

if s, _ := body.(io.Seeker); s != nil { // covers a lot of other 
cases, like multipart.File, errors statting *os.File, etc.
cur, err := s.Seek(0, io.SeekCurrent)
if err != nil {
return -1, fmt.Errorf("error checking current 
position: %w", err)
}

end, err := s.Seek(0, io.SeekEnd)
if err != nil {
return -1, fmt.Errorf("error seeking end position: 
%w", err)
}

_, err = s.Seek(cur, io.SeekStart)
if err != nil {
return -1, fmt.Errorf("error going back to initial 
position: %w", err)
}

return end - cur, nil
}

return -1, errors.New("unknown body, don't send the Content-Length 
header")
}



On Friday, September 17, 2021 at 2:23:50 PM UTC-3 Diego Molina wrote:

> Ok, that makes total sense. I'm now using `req.TransferEncoding = 
> []string{"identity"}` and this behaviour is suppressed, but of course I 
> still don't get the Content-Length, which is fair.
>
> Thanks all!
>
> On Fri, Sep 17, 2021 at 2:09 PM Brian Candler  wrote:
>
>> All chunks must be prefixed by a chunk length - even if that length is 
>> zero.
>>
>> On Friday, 17 September 2021 at 16:53:07 UTC+1 dmo...@synack.com wrote:
>>
>>> Oh, thanks for clarifying that. But still, even if transfer encoding 
>>> will be chunked, I don't see why it would make up a body of "0\r\n\r\n" if 
>>> the nop body wouldn't give away any bytes at all.
>>>
>>> On Friday, September 17, 2021 at 7:56:21 AM UTC-3 seank...@gmail.com 
>>> wrote:
>>>
 This was an intentional change in 1.8 
 https://github.com/golang/go/issues/20257#issuecomment-299509391

 On Friday, September 17, 2021 at 6:45:13 AM UTC+2 dmo...@synack.com 
 wrote:

> Hi, when using a custom io.ReadCloser nop as body with method POST, 
> PUT, PATCH, TRACE or custom then (*http.Request).Write outputs a body of 
> the form "0\r\n\r\n" (without the quotes). Proof-of-concept: 
> https://play.golang.org/p/Rg2cZ0wihdd
>
> Besides the fix, I think it would be useful to have body checked if it 
> satisfies interface{ Len() int } or something similar (this would 
> simplify 
> code too by removing several type assertions, e.g., isKnownInMemoryReader 
> func in net/http/trans...@go1.17.1) so that we can avoid chunked transfer 
> encoding.
>
> This email may contain material that is confidential for the sole use 
> of the intended recipient(s).  Any review, reliance or distribution or 
> disclosure by others without express permission is strictly prohibited.  
> If 
> you are not the intended recipient, please contact the sender and delete 
> all copies of this message.
>
 -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/ZlhK8whGwck/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>>

Re: [go-nuts] about -buildmode c-shared

2022-01-14 Thread Sven Anderson 
On Mon, Dec 27, 2021 at 1:17 AM Ian Lance Taylor  wrote:

> Loading multiple Go DLLs built with -buildmode=c-shared ought to work
> on ELF based systems like Linux.  I don't know whether it will work on
> Windows or macOS.


 I have a related question on that topic:

How about support for a Go program that can load C modules (with Cgo and
dlopen), and this module again is a Go c-shared library?

I would have assumed that does not work, due to conflicting runtimes, and
it indeed crashes on my Mac. But after reading your statement here, I
wonder if it maybe is supported on ELF based systems?

Thanks,

Sven

-- 
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/CAFwXxZSHvmjgbvmQZCO%2BKKQYHPkXB-e%3DQ5OeZcr4R6RFKSOngw%40mail.gmail.com.