Re: [go-nuts] Interactive input and "go test"

[Amit Saha]

On Fri, Nov 5, 2021 at 11:24 PM Amit Saha  wrote:
>
>
>
> On Fri, 5 Nov 2021, 11:08 pm Axel Wagner,  
> wrote:
>>
>> First, to point out the obvious: It is a bad idea to have a test read from 
>> stdin. You should pass a separate io.Reader and use that.
>>
>> Next: exec.Cmd.{Stdin,Stdout,Stderr} are all set to os.DevNull by default, 
>> meaning you don't get any input or output. I assume
>>
>> - `go test` does not modify Cmd.Stdin (leaving it at os.DevNull) of the 
>> sub-process it launches and redirects Cmd.{Stdout,Stderr} to buffers.
>> - Your test (if you use `exec.Command(…).Run()`) also does not modify any of 
>> them, so they stay at os.DevNull
>> - Other languages have them default to stdin/stdout/stderr of the parent 
>> process, so they try to read from stdin, which is a line-buffered terminal, 
>> so it blocks until you input a line.
>>
>> Again, the solution here should be to not rely on os.Stdin at all, but 
>> instead test a function which uses a general io.Reader.
>
>
> Great thank you for clarifying that.
>
> I ran into this as I was writing a test for an interactive input function and 
> I expected the test to hang but it didn't. So bit of an accidental find and 
> glad I found this.

I posted this as a blog post: https://echorand.me/posts/go-test-stdin/
- in case someone else finds it useful.

Thanks again for your help, Axel.

Best Regards,
Amit.

>
>
>>
>> On Fri, Nov 5, 2021 at 12:48 PM Amit Saha  wrote:
>>>
>>>
>>>
>>> > On 5 Nov 2021, at 10:27 pm, Amit Saha  wrote:
>>> >
>>> > I have this test function:
>>> >
>>> > package main
>>> >
>>> > import (
>>> > "bufio"
>>> > "fmt"
>>> > "os"
>>> > "testing"
>>> > )
>>> >
>>> > func TestInput(t *testing.T) {
>>> > scanner := bufio.NewScanner(os.Stdin)
>>> > msg := "Your name please? Press the Enter key when done"
>>> > fmt.Fprintln(os.Stdout, msg)
>>> >
>>> > scanner.Scan()
>>> > if err := scanner.Err(); err != nil {
>>> > t.Fatal(err)
>>> > }
>>> > name := scanner.Text()
>>> > if len(name) == 0 {
>>> > t.Log("empty input")
>>> > }
>>> > t.Log(name)
>>> >
>>> > }
>>> >
>>> > When i run it via go test -v, this is what i get (TLDR; terminates 
>>> > without waiting for the interactive input):
>>> >
>>> > % go test -v
>>> >
>>> > === RUN   TestInput
>>> >
>>> > Your name please? Press the Enter key when done
>>> >
>>> > stdin_test.go:21: empty input
>>> >
>>> > stdin_test.go:23:
>>> >
>>> > --- PASS: TestInput (0.00s)
>>> >
>>> > PASS
>>> >
>>> > ok  test 0.370s
>>> >
>>> >
>>> >
>>> > However, when i compile the test and then run the binary, it waits for me 
>>> > to enter the input:
>>> >
>>> >
>>> >
>>> > % go test -c
>>> >
>>> > % ./test.test
>>> >
>>> > Your name please? Press the Enter key when done
>>> >
>>> >
>>> >
>>> >
>>> > The latter behavior is more inline with what i was expecting in the first 
>>> > case as well.
>>> >
>>> > I thought may be it has something to do with the fact that go test is 
>>> > executing the binary (i think) after compiling, and started looking at: 
>>> > https://github.com/golang/go/blob/c7f2f51fed15b410dea5f608420858b401887d0a/src/cmd/go/internal/test/test.go
>>> >  , but can't see anything obvious.
>>> >
>>> > Wondering if anyone of you folks have an answer?
>>> >
>>>
>>> Did a bit more of experimentation, and it seems like, that’s just how 
>>> exec.Command(“mycmd").Run() works.
>>>
>>> I tried with exec.Command("wc").Run() and it returns immediately as well. 
>>> (Running the Unix “word count” program).
>>>
>>> I suppose I am surprised since in another language I am familiar with 
>>> (Python), a command waiting for an interactive input when executed via 
>>> os/exec would “hang”, for example:
>>>
>>> % python3
>>> Python 3.8.2 (default, Apr  8 2021, 23:19:18)
>>> [Clang 12.0.5 (clang-1205.0.22.9)] on darwin
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import subprocess
>>> >>> subprocess.check_output(["wc”])
>>>
>>> This will hang
>>>
>>> >
>>> >
>>> > Thanks,
>>> >
>>> > Amit.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > 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/24pL7iQbx64/unsubscribe.
>>> > To unsubscribe from this group and all its topics, 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/0f48fc8d-7e21-46a6-b736-90ea2f0bcbe6n%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 

Re: [go-nuts] Golang JPEG2000 implementation / Gauging community interest in supporting it?

[Adam Koszek]

We're trying to do the same - when we encounter a JPEG2000 encoded
file, we convert it. Yet we don't want to keep a converted copy
because often people want to see the data in the original form.

So right now we got a commercial DICOM codec with the capability of
reading / compressing JPEG2000 DICOMs, but it's a hack. We're fork a
process and read converted bytes from STDIN.

Go implementation would be much, much nicer.


On Fri, Nov 5, 2021 at 3:43 AM Nick  wrote:
>
> Hi Wojciech,
>
> Quoth Adam Koszek:
> > I know it's rather a rare format, yet it's "the standard". I wonder if there
> > are any other users interested in getting JPEG 2000 supported natively in 
> > Go?
> > Or maybe someone out there has its implementation written, and would need 
> > hand
> > open-sourcing it?
> >
> > I was thinking that maybe there are companies that would benefit from it, 
> > and
> > we could co-sponsor someone to whip a nice implementation for us. We could
> > probably help with organizing this, pitch in some $$$ too, and manage the 
> > work.
> > In case you're a domain expert in search of a cool project, feel free to 
> > reply
> > to this post.
>
> Yeah, in my work on OCR of historical books for rescribe.xyz we come
> across JPEG 2000 scans every so often, and having native support in
> Go for it would potentially be handy. That said, massive lossless
> images are not useful for the use case anyway, so at the moment just
> converting them to regular JPEGs using ImageMagick before processing
> works just fine.
>
> So consider me an interested party, but not to the extent of being
> able to offer much in the way of developer time to the endeavour.
> Cheerleading and testing, though, that much I can happily offer :)
>
> Nick
>
> --
> 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/YYUKu/V5p4pHZKiy%40hammerhead.lan.



--
W. Adam Koszek
CTO and Cofounder, Segmed Inc.
wkos...@segmed.ai

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

Re: [go-nuts] Golang JPEG2000 implementation / Gauging community interest in supporting it?

[Robert Engels]

There are several open source Java encoder/decoder libraries. These can be 
translated pretty easily to Go. 

> On Nov 5, 2021, at 3:19 PM, 'Dan Kortschak' via golang-nuts 
>  wrote:
> 
> On Wed, 2021-11-03 at 18:50 -0700, Adam Koszek wrote:
>> Hello,
>> 
>> We (Segmed.ai) are processing a lot of medical imaging data. It comes
>> to us in the form of PNG/JPG/DICOM files. 90% of it is uncompressed
>> or using a normal JPEG encoding, but around ~7% of it is encoded with
>> lossless JPEG 2000 format.
>> 
>> We use Suyash Kumar's library: https://github.com/suyashkumar/dicom
>> which depends on the Golang "image/jpeg" library. We'd love to get 
>> "image/jpeg" to support JPEG 2000 lossless encoding format.
>> 
>> I know it's rather a rare format, yet it's "the standard". I wonder
>> if there are any other users interested in getting JPEG 2000
>> supported natively in Go? Or maybe someone out there has its
>> implementation written, and would need hand open-sourcing it?
>> 
>> I was thinking that maybe there are companies that would benefit from
>> it, and we could co-sponsor someone to whip a nice implementation for
>> us. We could probably help with organizing this, pitch in some $$$
>> too, and manage the work. In case you're a domain expert in search of
>> a cool project, feel free to reply to this post.
>> 
>> Thanks,
>> 
>> Wojciech Adam Koszek
>> 
> 
> 
> Part of the issue here is the availability of the spec. The ITU are
> unpleasantly closed (at least for free copies) with spec documents
> which reduces the likelihood of open source project implementations.
> 
> (Not putting myself forward in the case that a spec is provided).
> 
> Dan
> 
> 
> -- 
> 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/69f9b44981f8fd9134d9e1ceb3e19f4a6486b75d.camel%40kortschak.io.

-- 
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/DB5DC230-8336-4C5E-AD76-C50797A826B0%40ix.netcom.com.

Re: [go-nuts] Golang JPEG2000 implementation / Gauging community interest in supporting it?

['Dan Kortschak' via golang-nuts]

On Wed, 2021-11-03 at 18:50 -0700, Adam Koszek wrote:
> Hello,
>
> We (Segmed.ai) are processing a lot of medical imaging data. It comes
> to us in the form of PNG/JPG/DICOM files. 90% of it is uncompressed
> or using a normal JPEG encoding, but around ~7% of it is encoded with
> lossless JPEG 2000 format.
>
> We use Suyash Kumar's library: https://github.com/suyashkumar/dicom
> which depends on the Golang "image/jpeg" library. We'd love to get 
> "image/jpeg" to support JPEG 2000 lossless encoding format.
>
> I know it's rather a rare format, yet it's "the standard". I wonder
> if there are any other users interested in getting JPEG 2000
> supported natively in Go? Or maybe someone out there has its
> implementation written, and would need hand open-sourcing it?
>
> I was thinking that maybe there are companies that would benefit from
> it, and we could co-sponsor someone to whip a nice implementation for
> us. We could probably help with organizing this, pitch in some $$$
> too, and manage the work. In case you're a domain expert in search of
> a cool project, feel free to reply to this post.
>
> Thanks,
>
> Wojciech Adam Koszek
>


Part of the issue here is the availability of the spec. The ITU are
unpleasantly closed (at least for free copies) with spec documents
which reduces the likelihood of open source project implementations.

(Not putting myself forward in the case that a spec is provided).

Dan


-- 
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/69f9b44981f8fd9134d9e1ceb3e19f4a6486b75d.camel%40kortschak.io.

Re: [go-nuts] cmd/link: why golang linker only save parts of relocations into go.o in external linking mode?

[Ian Lance Taylor]

On Fri, Nov 5, 2021 at 9:36 AM 'LUO Hailing' via golang-nuts
 wrote:
>
> I'm new of golang linker, and I have a simple question about golang linker.
>
> PATH: go\src\cmd\link\internal\arm64\asm.go
> function:
> func elfreloc1(ctxt *ld.Link, out *ld.OutBuf, ldr *loader.Loader, s 
> loader.Sym, r loader.ExtReloc, ri int, sectoff int64) bool {
> ...
> }
>
> In this function, it only emits some types of relocations into go.o as the 
> following description. why?
> There still exist some other types of relocations.
>
> objabi.R_ADDR, objabi.R_DWARFSECREF -> elf.R_AARCH64_ABS32/elf.R_AARCH64_ABS64
> objabi.R_ADDRARM64 -> elf.R_AARCH64_ADR_PREL_PG_HI21 and 
> elf.R_AARCH64_ADD_ABS_LO12_NC
> objabi.R_ARM64_TLS_LE -> elf.R_AARCH64_TLSLE_MOVW_TPREL_G0
> objabi.R_ARM64_TLS_IE -> elf.R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 and 
> elf.R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC
> objabi.R_ARM64_GOTPCREL -> elf.R_AARCH64_ADR_GOT_PAGE and 
> elf.R_AARCH64_LD64_GOT_LO12_NC
> objabi.R_CALLARM64 -> elf.R_AARCH64_CALL26

What other relocation types actually occur in Go code?

If any do show up, the function will return false, and the call in
elfrelocsect will return an error.

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/CAOyqgcWrFORakt0tv9F%2B0ht03mXmaRm1ZdVT_z%3D6Xe%3DtthVYQA%40mail.gmail.com.

[go-nuts] Re: Mocking requests in Go

[Roman Kuprov]

Hah! I just had a question about this come up at a job interview! The 
Baader-Meinhoff is strong with this one!

On Friday, November 5, 2021 at 11:17:23 AM UTC-6 Amnon wrote:

> Nice post. Good advice.
>
> On Friday, 5 November 2021 at 17:08:25 UTC bke...@zushealth.com wrote:
>
>> Sharing an interesting post by Zus  technologist 
>> Sonya Huang on mocking requests in Go:
>>
>> https://www.linkedin.com/feed/update/urn:li:activity:6862376852103798784/
>>
>

-- 
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/2f46f100-0101-4afd-b86f-b1996365ecean%40googlegroups.com.

[go-nuts] Re: Mocking requests in Go

[Amnon]

Nice post. Good advice.

On Friday, 5 November 2021 at 17:08:25 UTC bke...@zushealth.com wrote:

> Sharing an interesting post by Zus  technologist 
> Sonya Huang on mocking requests in Go:
>
> https://www.linkedin.com/feed/update/urn:li:activity:6862376852103798784/
>

-- 
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/ced672ee-5aa4-42e8-8a39-0336767a7539n%40googlegroups.com.

[go-nuts] Mocking requests in Go

[Brendan Keeler]

Sharing an interesting post by Zus  technologist 
Sonya Huang on mocking requests in Go:

https://www.linkedin.com/feed/update/urn:li:activity:6862376852103798784/

-- 
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/8685b2aa-ee1f-467d-b9ed-f53ea5af060cn%40googlegroups.com.

Re: [go-nuts] Limit the number of goroutine while using errgroup

['Sebastien Binet' via golang-nuts]

One can use errgroup.Group in conjunction with x/sync/semaphore.

-s

Nov 5, 2021 17:36:56 Reach John :

> How to control the number of goroutines when using errgroup? Is there a best 
> practice?
> -- 
> 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/3920c043-787e-439b-b92a-fdbf2971n%40googlegroups.com[https://groups.google.com/d/msgid/golang-nuts/3920c043-787e-439b-b92a-fdbf2971n%40googlegroups.com?utm_medium=email_source=footer].

-- 
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/692ff3c9-8731-48e2-8939-4b3f90f493a7%40sbinet.org.

[go-nuts] cmd/link: why golang linker only save parts of relocations into go.o in external linking mode?

['LUO Hailing' via golang-nuts]

Hi all,

I'm new of golang linker, and I have a simple question about golang linker.



PATH: go\src\cmd\link\internal\arm64\asm.go
function:
func elfreloc1(ctxt *ld.Link, out *ld.OutBuf, ldr *loader.Loader, s loader.Sym, 
r loader.ExtReloc, ri int, sectoff int64) bool {
...
}

In this function, it only emits some types of relocations into go.o as the 
following description. why?
There still exist some other types of relocations.

objabi.R_ADDR, objabi.R_DWARFSECREF - 
elf.R_AARCH64_ABS32/elf.R_AARCH64_ABS64
objabi.R_ADDRARM64 - elf.R_AARCH64_ADR_PREL_PG_HI21 and 
elf.R_AARCH64_ADD_ABS_LO12_NC
objabi.R_ARM64_TLS_LE - elf.R_AARCH64_TLSLE_MOVW_TPREL_G0
objabi.R_ARM64_TLS_IE - elf.R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 and 
elf.R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC
objabi.R_ARM64_GOTPCREL - elf.R_AARCH64_ADR_GOT_PAGE and 
elf.R_AARCH64_LD64_GOT_LO12_NC
objabi.R_CALLARM64 - elf.R_AARCH64_CALL26

-- 
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/tencent_2E721E5B5D2D5B409937CAE6AAE9DB3D3C05%40qq.com.

[go-nuts] Limit the number of goroutine while using errgroup

[Reach John]

How to control the number of goroutines when using errgroup? Is there a 
best practice?

-- 
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/3920c043-787e-439b-b92a-fdbf2971n%40googlegroups.com.

Re: [go-nuts] Go build speed dependent on time after source modification

[Mark Fletcher]

On Fri, Nov 5, 2021 at 5:10 AM Alberto Donizetti 
wrote:

> Could be due to https://github.com/golang/go/issues/48496
> Should be fixed on tip, but 1.17 is affected.
>
>
Thanks for this pointer. I just tested this and it made a huge difference.
For a change to a single file, compiling on 1.17.2 takes ~14 seconds. On
tip, it takes ~5 seconds.

Mark

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

Re: [go-nuts] Interactive input and "go test"

[Amit Saha]

On Fri, 5 Nov 2021, 11:08 pm Axel Wagner, 
wrote:

> First, to point out the obvious: It is a bad idea to have a test read from
> stdin. You should pass a separate io.Reader and use that.
>
> Next: exec.Cmd.{Stdin,Stdout,Stderr} are all set to os.DevNull by default,
> meaning you don't get any input or output. I assume
>
> - `go test` does not modify Cmd.Stdin (leaving it at os.DevNull) of the
> sub-process it launches and redirects Cmd.{Stdout,Stderr} to buffers.
> - Your test (if you use `exec.Command(…).Run()`) also does not modify any
> of them, so they stay at os.DevNull
> - Other languages have them default to stdin/stdout/stderr of the parent
> process, so they try to read from stdin, which is a line-buffered terminal,
> so it blocks until you input a line.
>
> Again, the solution here should be to not rely on os.Stdin at all, but
> instead test a function which uses a general io.Reader.
>

Great thank you for clarifying that.

I ran into this as I was writing a test for an interactive input function
and I expected the test to hang but it didn't. So bit of an accidental find
and glad I found this.



> On Fri, Nov 5, 2021 at 12:48 PM Amit Saha  wrote:
>
>>
>>
>> > On 5 Nov 2021, at 10:27 pm, Amit Saha  wrote:
>> >
>> > I have this test function:
>> >
>> > package main
>> >
>> > import (
>> > "bufio"
>> > "fmt"
>> > "os"
>> > "testing"
>> > )
>> >
>> > func TestInput(t *testing.T) {
>> > scanner := bufio.NewScanner(os.Stdin)
>> > msg := "Your name please? Press the Enter key when done"
>> > fmt.Fprintln(os.Stdout, msg)
>> >
>> > scanner.Scan()
>> > if err := scanner.Err(); err != nil {
>> > t.Fatal(err)
>> > }
>> > name := scanner.Text()
>> > if len(name) == 0 {
>> > t.Log("empty input")
>> > }
>> > t.Log(name)
>> >
>> > }
>> >
>> > When i run it via go test -v, this is what i get (TLDR; terminates
>> without waiting for the interactive input):
>> >
>> > % go test -v
>> >
>> > === RUN   TestInput
>> >
>> > Your name please? Press the Enter key when done
>> >
>> > stdin_test.go:21: empty input
>> >
>> > stdin_test.go:23:
>> >
>> > --- PASS: TestInput (0.00s)
>> >
>> > PASS
>> >
>> > ok  test 0.370s
>> >
>> >
>> >
>> > However, when i compile the test and then run the binary, it waits for
>> me to enter the input:
>> >
>> >
>> >
>> > % go test -c
>> >
>> > % ./test.test
>> >
>> > Your name please? Press the Enter key when done
>> >
>> >
>> >
>> >
>> > The latter behavior is more inline with what i was expecting in the
>> first case as well.
>> >
>> > I thought may be it has something to do with the fact that go test is
>> executing the binary (i think) after compiling, and started looking at:
>> https://github.com/golang/go/blob/c7f2f51fed15b410dea5f608420858b401887d0a/src/cmd/go/internal/test/test.go
>> , but can't see anything obvious.
>> >
>> > Wondering if anyone of you folks have an answer?
>> >
>>
>> Did a bit more of experimentation, and it seems like, that’s just how
>> exec.Command(“mycmd").Run() works.
>>
>> I tried with exec.Command("wc").Run() and it returns immediately as well.
>> (Running the Unix “word count” program).
>>
>> I suppose I am surprised since in another language I am familiar with
>> (Python), a command waiting for an interactive input when executed via
>> os/exec would “hang”, for example:
>>
>> % python3
>> Python 3.8.2 (default, Apr  8 2021, 23:19:18)
>> [Clang 12.0.5 (clang-1205.0.22.9)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import subprocess
>> >>> subprocess.check_output(["wc”])
>>
>> This will hang
>>
>> >
>> >
>> > Thanks,
>> >
>> > Amit.
>> >
>> >
>> >
>> >
>> >
>> > --
>> > 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/24pL7iQbx64/unsubscribe.
>> > To unsubscribe from this group and all its topics, 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/0f48fc8d-7e21-46a6-b736-90ea2f0bcbe6n%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/25A4D3EA-F228-447C-A19E-8BE062840E20%40gmail.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 

Re: [go-nuts] Go build speed dependent on time after source modification

[Alberto Donizetti]

Could be due to https://github.com/golang/go/issues/48496
Should be fixed on tip, but 1.17 is affected.

Alberto

On Thursday, 4 November 2021 at 18:44:01 UTC+1 Mark Fletcher wrote:

> On Thu, Nov 4, 2021 at 10:25 AM Brian Hatfield  wrote:
>
>> This seems a little like you might have a background compilation process 
>> occurring which is populating the build cache. What editor environment are 
>> you using? Is it possible it is effectively running compilations on your 
>> code, whether via IDE support, indirectly via linters, or other on-save 
>> actions?
>>
>>>
>>>
> Hmm, well I think you're right. I use VSCode, which runs gopls. It never 
> occured to me that gopls would run a compile, but I guess in hindsight it 
> makes sense. If I shut down VSCode and instead edit the file using vi, I 
> get consistent 16 second compile times regardless of how long I wait. So, 
> thanks for the suggestion. I still don't understand why my compile times 
> are the same between the i9 and M1 Max, but I guess I need to do some more 
> research.
>
> Thanks,
> Mark
>

-- 
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/924f99e0-9cb0-4614-bd71-4d4fbfd263adn%40googlegroups.com.

Re: [go-nuts] Interactive input and "go test"

['Axel Wagner' via golang-nuts]

First, to point out the obvious: It is a bad idea to have a test read from
stdin. You should pass a separate io.Reader and use that.

Next: exec.Cmd.{Stdin,Stdout,Stderr} are all set to os.DevNull by default,
meaning you don't get any input or output. I assume

- `go test` does not modify Cmd.Stdin (leaving it at os.DevNull) of the
sub-process it launches and redirects Cmd.{Stdout,Stderr} to buffers.
- Your test (if you use `exec.Command(…).Run()`) also does not modify any
of them, so they stay at os.DevNull
- Other languages have them default to stdin/stdout/stderr of the parent
process, so they try to read from stdin, which is a line-buffered terminal,
so it blocks until you input a line.

Again, the solution here should be to not rely on os.Stdin at all, but
instead test a function which uses a general io.Reader.

On Fri, Nov 5, 2021 at 12:48 PM Amit Saha  wrote:

>
>
> > On 5 Nov 2021, at 10:27 pm, Amit Saha  wrote:
> >
> > I have this test function:
> >
> > package main
> >
> > import (
> > "bufio"
> > "fmt"
> > "os"
> > "testing"
> > )
> >
> > func TestInput(t *testing.T) {
> > scanner := bufio.NewScanner(os.Stdin)
> > msg := "Your name please? Press the Enter key when done"
> > fmt.Fprintln(os.Stdout, msg)
> >
> > scanner.Scan()
> > if err := scanner.Err(); err != nil {
> > t.Fatal(err)
> > }
> > name := scanner.Text()
> > if len(name) == 0 {
> > t.Log("empty input")
> > }
> > t.Log(name)
> >
> > }
> >
> > When i run it via go test -v, this is what i get (TLDR; terminates
> without waiting for the interactive input):
> >
> > % go test -v
> >
> > === RUN   TestInput
> >
> > Your name please? Press the Enter key when done
> >
> > stdin_test.go:21: empty input
> >
> > stdin_test.go:23:
> >
> > --- PASS: TestInput (0.00s)
> >
> > PASS
> >
> > ok  test 0.370s
> >
> >
> >
> > However, when i compile the test and then run the binary, it waits for
> me to enter the input:
> >
> >
> >
> > % go test -c
> >
> > % ./test.test
> >
> > Your name please? Press the Enter key when done
> >
> >
> >
> >
> > The latter behavior is more inline with what i was expecting in the
> first case as well.
> >
> > I thought may be it has something to do with the fact that go test is
> executing the binary (i think) after compiling, and started looking at:
> https://github.com/golang/go/blob/c7f2f51fed15b410dea5f608420858b401887d0a/src/cmd/go/internal/test/test.go
> , but can't see anything obvious.
> >
> > Wondering if anyone of you folks have an answer?
> >
>
> Did a bit more of experimentation, and it seems like, that’s just how
> exec.Command(“mycmd").Run() works.
>
> I tried with exec.Command("wc").Run() and it returns immediately as well.
> (Running the Unix “word count” program).
>
> I suppose I am surprised since in another language I am familiar with
> (Python), a command waiting for an interactive input when executed via
> os/exec would “hang”, for example:
>
> % python3
> Python 3.8.2 (default, Apr  8 2021, 23:19:18)
> [Clang 12.0.5 (clang-1205.0.22.9)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import subprocess
> >>> subprocess.check_output(["wc”])
>
> This will hang
>
> >
> >
> > Thanks,
> >
> > Amit.
> >
> >
> >
> >
> >
> > --
> > 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/24pL7iQbx64/unsubscribe.
> > To unsubscribe from this group and all its topics, 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/0f48fc8d-7e21-46a6-b736-90ea2f0bcbe6n%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/25A4D3EA-F228-447C-A19E-8BE062840E20%40gmail.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/CAEkBMfFd3O9HpBpng%2B0%3Dnten2NbwnmwmTZvabnv%2B4Y4WDonk5Q%40mail.gmail.com.

Re: [go-nuts] cgo error I don't understand

[rob]

That was it.  It's working now.

Thank you very much.

--rob solomon


On 11/4/21 11:00 PM, Roland Müller wrote:

Hello,

the entry in the path for mingwin is wrong: it should be either start 
with C:\ or another drive letter or in case it's an absolute path with 
double backslash.


Br
Roland

Am Freitag, 5. November 2021 schrieb Robert Solomon 
mailto:drrob...@gmail.com>>:

> The full error is:
> # github.com/go-gl/glfw/v3.3/glfw 

> cgo: exec gcc: gcc resolves to executable relative to current 
directory (.\\msys64\mingw64\bin\gcc.exe)
> # github.com/go-gl/gl/v3.2-core/gl 

> cgo: exec gcc: gcc resolves to executable relative to current 
directory (.\\msys64\mingw64\bin\gcc.exe)

>
>
> echo %path is:
> C:\Program 
Files\git\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program 
Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\NVIDIA 
Corporation\NVIDIA NvDLISR;C:\Program Files (x86)\gnupg\bin;C:\Program 
Files\Go\bin;C:\Program Files\Git\cmd;C:\Program 
Files\Git\mingw64\bin;C:\Program 
Files\Git\usr\bin;C:\Users\Owner\AppData\Local\Microsoft\WindowsApps;C:\Users\Owner\go\bin;C:\Users\Owner;C:\Program 
Files\go\bin;\msys64\mingw64\bin

>
>
> On Thursday, November 4, 2021 at 7:54:14 PM UTC-4 Ian Lance Taylor 
wrote:

>>
>> On Thu, Nov 4, 2021 at 4:41 PM Robert Solomon > wrote:

>> >
>> > The results of go env are below. If I'm reading this correctly, 
CC=gcc.

>> >
>> > set GO111MODULE=auto
>> > set GOARCH=amd64
>> > set GOBIN=
>> > set GOCACHE=C:\Users\Owner\AppData\Local\go-build
>> > set GOENV=C:\Users\Owner\AppData\Roaming\go\env
>> > set GOEXE=.exe
>> > set GOEXPERIMENT=
>> > set GOFLAGS=
>> > set GOHOSTARCH=amd64
>> > set GOHOSTOS=windows
>> > set GOINSECURE=
>> > set GOMODCACHE=C:\Users\Owner\go\pkg\mod
>> > set GONOPROXY=
>> > set GONOSUMDB=
>> > set GOOS=windows
>> > set GOPATH=C:\Users\Owner\go
>> > set GOPRIVATE=
>> > set GOPROXY=https://proxy.golang.org 
,direct

>> > set GOROOT=C:\Program Files\Go
>> > set GOSUMDB=sum.golang.org 
>> > set GOTMPDIR=
>> > set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
>> > set GOVCS=
>> > set GOVERSION=go1.17.2
>> > set GCCGO=gccgo
>> > set AR=ar
>> > set CC=gcc
>> > set CXX=g++
>> > set CGO_ENABLED=1
>> > set GOMOD=C:\Users\Owner\go\src\go.mod
>> > set CGO_CFLAGS=-g -O2
>> > set CGO_CPPFLAGS=
>> > set CGO_CXXFLAGS=-g -O2
>> > set CGO_FFLAGS=-g -O2
>> > set CGO_LDFLAGS=-g -O2
>> > set PKG_CONFIG=pkg-config
>> > set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics 
-Qunused-arguments -fmessage-length=0 
-fdebug-prefix-map=C:\Users\Owner\AppData\Local\Temp\go-build4162893276=/tmp/go-build 
-gno-record-gcc-switches

>>
>> Hmmm. What is the path environment variable?
>>
>> Ian
>>
>>
>> > On Thursday, November 4, 2021 at 6:20:10 PM UTC-4 Ian Lance 
Taylor wrote:

>> >>
>> >> On Wed, Nov 3, 2021 at 5:40 PM Robert Solomon > wrote:

>> >> >
>> >> > I'm setting up a new Windows10 computer. I installed Go 1.17.2 
and mingw64 for cgo. When I tried to compile a project that uses cgo, 
I got this error:

>> >> >
>> >> > cgo: exec gcc: gcc resolves to executable relative to current 
directory (.\\msys64\mingw64\bin\gcc.exe)

>> >> >
>> >> > This is a program that compiles fine on my older win10 computer.
>> >> >
>> >> > I don't think this matters, but I'm compiling a program of 
mine that uses fyne, which uses cgo.

>> >>
>> >> This suggests that the CC environment variable is set to
>> >> ".\\msys64\mingw64\bin\gcc.exe" with a leading dot. That is not an
>> >> absolute path. That is not permitted for the reasons given at
>> >> https://golang.org/issue/43783 .
>> >>
>> >> 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...@googlegroups.com 
.
>> > To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e60e5b03-92d4-4f01-a516-1fca7e2905bdn%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/306f2cba-ae3b-4e77-94d1-6064f53bba1bn%40googlegroups.com 
.
> 


--
You received 

Re: [go-nuts] Interactive input and "go test"

[Amit Saha]

> On 5 Nov 2021, at 10:27 pm, Amit Saha  wrote:
> 
> I have this test function:
> 
> package main
> 
> import (
> "bufio"
> "fmt"
> "os"
> "testing"
> )
> 
> func TestInput(t *testing.T) {
> scanner := bufio.NewScanner(os.Stdin)
> msg := "Your name please? Press the Enter key when done"
> fmt.Fprintln(os.Stdout, msg)
> 
> scanner.Scan()
> if err := scanner.Err(); err != nil {
> t.Fatal(err)
> }
> name := scanner.Text()
> if len(name) == 0 {
> t.Log("empty input")
> }
> t.Log(name)
> 
> }
> 
> When i run it via go test -v, this is what i get (TLDR; terminates without 
> waiting for the interactive input):
> 
> % go test -v
> 
> === RUN   TestInput
> 
> Your name please? Press the Enter key when done
> 
> stdin_test.go:21: empty input
> 
> stdin_test.go:23: 
> 
> --- PASS: TestInput (0.00s)
> 
> PASS
> 
> ok  test 0.370s
> 
> 
> 
> However, when i compile the test and then run the binary, it waits for me to 
> enter the input:
> 
> 
> 
> % go test -c
> 
> % ./test.test 
> 
> Your name please? Press the Enter key when done
> 
> 
> 
> 
> The latter behavior is more inline with what i was expecting in the first 
> case as well. 
> 
> I thought may be it has something to do with the fact that go test is 
> executing the binary (i think) after compiling, and started looking at: 
> https://github.com/golang/go/blob/c7f2f51fed15b410dea5f608420858b401887d0a/src/cmd/go/internal/test/test.go
>  , but can't see anything obvious.
> 
> Wondering if anyone of you folks have an answer?
> 

Did a bit more of experimentation, and it seems like, that’s just how 
exec.Command(“mycmd").Run() works. 

I tried with exec.Command("wc").Run() and it returns immediately as well. 
(Running the Unix “word count” program).

I suppose I am surprised since in another language I am familiar with (Python), 
a command waiting for an interactive input when executed via os/exec would 
“hang”, for example:

% python3
Python 3.8.2 (default, Apr  8 2021, 23:19:18) 
[Clang 12.0.5 (clang-1205.0.22.9)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.check_output(["wc”])

This will hang

> 
> 
> Thanks,
> 
> Amit.
> 
> 
> 
> 
> 
> -- 
> 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/24pL7iQbx64/unsubscribe.
> To unsubscribe from this group and all its topics, 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/0f48fc8d-7e21-46a6-b736-90ea2f0bcbe6n%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/25A4D3EA-F228-447C-A19E-8BE062840E20%40gmail.com.

[go-nuts] Interactive input and "go test"

[Amit Saha]

I have this test function:

package main

import (
"bufio"
"fmt"
"os"
"testing"
)

func TestInput(t *testing.T) {
scanner := bufio.NewScanner(os.Stdin)
msg := "Your name please? Press the Enter key when done"
fmt.Fprintln(os.Stdout, msg)

scanner.Scan()
if err := scanner.Err(); err != nil {
t.Fatal(err)
}
name := scanner.Text()
if len(name) == 0 {
t.Log("empty input")
}
t.Log(name)

}

When i run it via go test -v, this is what i get (TLDR; terminates without 
waiting for the interactive input):

% go test -v

=== RUN   TestInput

Your name please? Press the Enter key when done

stdin_test.go:21: empty input

stdin_test.go:23: 

--- PASS: TestInput (0.00s)

PASS

ok  test 0.370s


However, when i compile the test and then run the binary, it waits for me 
to enter the input:


% go test -c

% ./test.test 

Your name please? Press the Enter key when done


The latter behavior is more inline with what i was expecting in the first 
case as well. 

I thought may be it has something to do with the fact that go test is 
executing the binary (i think) after compiling, and started looking 
at: 
https://github.com/golang/go/blob/c7f2f51fed15b410dea5f608420858b401887d0a/src/cmd/go/internal/test/test.go
 
, but can't see anything obvious.

Wondering if anyone of you folks have an answer?


Thanks,

Amit.



-- 
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/0f48fc8d-7e21-46a6-b736-90ea2f0bcbe6n%40googlegroups.com.

Re: [go-nuts] Golang JPEG2000 implementation / Gauging community interest in supporting it?

[Nick]

Hi Wojciech,

Quoth Adam Koszek:
> I know it's rather a rare format, yet it's "the standard". I wonder if there
> are any other users interested in getting JPEG 2000 supported natively in Go?
> Or maybe someone out there has its implementation written, and would need hand
> open-sourcing it?
> 
> I was thinking that maybe there are companies that would benefit from it, and
> we could co-sponsor someone to whip a nice implementation for us. We could
> probably help with organizing this, pitch in some $$$ too, and manage the 
> work.
> In case you're a domain expert in search of a cool project, feel free to reply
> to this post.

Yeah, in my work on OCR of historical books for rescribe.xyz we come 
across JPEG 2000 scans every so often, and having native support in 
Go for it would potentially be handy. That said, massive lossless 
images are not useful for the use case anyway, so at the moment just 
converting them to regular JPEGs using ImageMagick before processing 
works just fine.

So consider me an interested party, but not to the extent of being 
able to offer much in the way of developer time to the endeavour.  
Cheerleading and testing, though, that much I can happily offer :)

Nick

-- 
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/YYUKu/V5p4pHZKiy%40hammerhead.lan.