Re: [go-nuts] How to cross-compile Go 1.19 compiler for Solaris 11 on Linux

[Shane]

I was finally able to compile the bootstrap on Linux (I had to install the 
missing libc).

However, after copying the .tbz file onto my Solaris 11u4 AMD64 machine to 
build the final Go tools, building fails:

$ GOROOT_BOOTSTRAP=/tmp/bootstap-goroot CGO_ENABLED=1 ./all.bash
Building Go cmd/dist using /tmp/bootstap-goroot. (go1.19 solaris/amd64)
dist: Cannot find /lib64/ld-linux-x86-64.so.2

Why does the bootstrap go expect /lib64/ld-linux-x86-64.so.2? Shouldn't it 
only be looking for Solaris libs?
On Saturday, August 27, 2022 at 3:18:42 PM UTC-4 Ian Lance Taylor wrote:

> On Sat, Aug 27, 2022 at 12:15 PM Shane  wrote:
> >
> > My understanding then is that cmd/dist first builds for the host here 
> (in my case, for Linux) and then builds for the target starting here. Since 
> there is always a build for the host first, then since my host OS is Linux, 
> the linux_syscall.c is always part of the compilation (since I do not 
> disable cgo). If anything is incorrect with my understanding, please 
> correct me.
> >
> > I believe then I need to have both Linux system headers and Solaris 
> system headers available on my build machine for the cross-compile, if I 
> want to build Go for Solaris with cgo support.
> >
> > Is it possible for there to be two header files with the same name but 
> different OS have the same #include path in the cgo source code? If so, 
> could the C compiler get the correct header for the target of the cgo? For 
> example, how could the C compiler know to use the Linux unistd.h header for 
> the Linux build, and later use the Solaris unistd.h header for the Solaris 
> build?
>
> I'm not sure whether this answers your question, but normally a system
> will have a native compiler that will look for header files in
> /usr/include. It can also have a cross-compiler that looks for header
> files in some other location. A cross-compiler should never look in
> /usr/include, it should only look at the cross-compilation header
> files.
>
> 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/6dd9a30f-d4be-45ff-a80c-499a71933259n%40googlegroups.com.

[go-nuts] [security] Go 1.19.1 and Go 1.18.6 pre-announcement

[announce]

Hello gophers,

We plan to issue Go 1.19.1 and Go 1.18.6 on Tuesday, September 6.

These minor releases include PRIVATE security fixes to the standard library.

Following our security policy, this is the pre-announcement of those releases.

Thanks,
Damien for the Go team

-- 
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/Wo9tHe9GRii01H0nuRpd4g%40geopod-ismtpd-1-6.

Re: [go-nuts] How long does it take to import packages?

[Wojciech S. Czarnecki]

Dnia 2022-08-31, o godz. 00:00:41
ag9920  napisał(a):

If you are in windows ecosystem exclude your development areas, including
go installation and gocache from antivirus "heuristics". While at last most of 
AV
vendors "discovered" that Go exists and it has its own linker, some dutifully 
sends
out home binary artifacts of anything you compile "for heuristic analysis".
(Second culprit for "dozens of seconds") can be a misconfigured corporate
(or state-wide) proxy.

> Hi, recently I've been trying to make my unit test faster. It seems too 
> much time were spent on initialization. After removing all init() function 
> in relevant packages. The speed was still very slow.It even takes dozens of 
> seconds before entering my real unit test function.

hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20220831200300.45bcd96a%40xmint.

[go-nuts] Gothon Library to simulate useful Python methods

[Andres Fernando Baron]

Hi !
A few days ago I wrote about a library that will use the power of generics 
in go ˆ1.18 to emulate the most common and practical Python methods, such 
as handling lists, dictionaries, heaps, etc. I put forward a bit of code 
for the slices and recreate in a generic way the handling of lists that we 
have with python. 
Some next steps are to recreate the Heapify library 
https://docs.python.org/3/library/heapq.html , dictionary methods and 
support set operations (w3schools.com/python/python_sets.asp).
If anyone would be interested in joining with code or feedback, you all are 
more than welcome.
Link to repo is : https://github.com/abaron10/Gothon
Thanks!
-- 
*CONFIDENTIALITY NOTICE: *The contents of this email message and any 
attachments are intended solely for the addressee(s) and may contain 
confidential and/or privileged information and are legally protected from 
disclosure. If you are not the intended recipient of this message or their 
agent, or if this message has been addressed to you in error, please 
immediately alert the sender by replying to this email and then delete this 
message and any attachments. If you are not the intended recipient, you are 
hereby notified that any use, dissemination, copying, or storage of this 
message or its attachments without authorization is strictly prohibited.

-- 
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/3ca99584-05f9-4454-b3c0-28ada7b8ce27n%40googlegroups.com.

[go-nuts] structured, leveled logging

['Jonathan Amsterdam' via golang-nuts]

If you're interested in logging, you may want to check out the discussion 
about a potential new standard library package for structured logging. 

https://github.com/golang/go/discussions/54763

-- 
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/3c744c08-8341-44c6-b059-431feb5e99fbn%40googlegroups.com.

Re: [go-nuts] Struct with Interfaces fields as key in maps

[antonio.o...@gmail.com]

> This works in general, but your example is flawed.

oh, my bad, thanks for the clarification

> you'll receive a runtime panic instead of a compile error.

yeah, I've received the same feedback offline from one colleague some 
minutes ago ... it is a bad idea

Thanks

On Wednesday, 31 August 2022 at 16:23:57 UTC+2 bse...@computer.org wrote:

> On Wed, Aug 31, 2022 at 7:28 AM antonio.o...@gmail.com <
> antonio.o...@gmail.com> wrote:
>
>> Hi,
>>
>> Based on the documentation:
>>
>> "The map key can be any type that is comparable."
>> "Struct values are comparable if all their fields are comparable. Two 
>> struct values are equal if their corresponding non-blank fields are equal."
>> "Interface values are comparable. Two interface values are equal if they 
>> have identical dynamic types and equal dynamic values or if both have value 
>> nil."
>>
>> My understanding is that I can use an structure like this as a key for a 
>> map
>>
>> type dialer interface {
>> dial()
>> }
>>
>> type key struct {
>> id string
>> number int
>> dialer  dialer
>> }
>>
>> It also seems to work fine https://go.dev/play/p/hKQfx-JH5WP
>>
>
> This works in general, but your example is flawed. In your example, you 
> have
>
> f1 := {}
> f2 := {}
>
> and then use f1 anf f2 as keys. These are pointers to structs, so the 
> comparison will be pointer comparison, not field-by-field comparison. 
>
> If you do:
>
> f1 := fakedialer{}
> f2 := fakedialer2{}
>
> and replace the pointer receivers with value receivers, and then use these 
> as map keys, it will work. But this time, if you pass a struct that cannot 
> be used as a key, you'll receive a runtime panic instead of a compile error.
>  
>
>> But I'm wondering if I'm missing something or are there some corner cases 
>> I should take into account before doing this ...  or if this is not 
>> recommended at all
>>
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/97b7368e-d276-40ab-afa3-f8a7868fd9ean%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/92b3ba9a-99bf-45b4-a697-a61de3ab8717n%40googlegroups.com.

Re: [go-nuts] How long does it take to import packages?

['Michael Pratt' via golang-nuts]

Setting GODEBUG=inittrace=1 will log a trace of init function execution,
which you can use to determine if init is slow, and if so which packages.

e.g., `GODEBUG=inittrace=1 go version` ends with "init main @9.5 ms",
indicating that it look 9.5ms to run all init functions.

The format is described at
https://pkg.go.dev/runtime#hdr-Environment_Variables.

On Wed, Aug 31, 2022 at 3:00 AM ag9920  wrote:

> Hi, recently I've been trying to make my unit test faster. It seems too
> much time were spent on initialization. After removing all init() function
> in relevant packages. The speed was still very slow.It even takes dozens of
> seconds before entering my real unit test function.
>
> So I take a look at all the possible factors that might slow down the
> testing. The only possible reason I can think of is the time cost on
> import. Golang needs to import all packages recursively. And in my
> scenario, that's roughly dozens of packages.Maybe initializing const, var
> takes too much time.
>
> Is there any solution that could help me figured out the reason? I didn't
> find any tools that could tell me the time cost on import several packages.
>
> And if that's the case,  import a package does take much time, is it still
> possible for me to speed up my unit test?
>
>
> --
> 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/cd58955e-0c4b-4d56-afd7-1153d7be06dcn%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/CALoThU9aog7qArW8%3DfHQ6QL5gA%3DAV1136Mib0d3EOeJsfXv3oQ%40mail.gmail.com.

Re: [go-nuts] Struct with Interfaces fields as key in maps

[burak serdar]

On Wed, Aug 31, 2022 at 7:28 AM antonio.o...@gmail.com <
antonio.ojea.gar...@gmail.com> wrote:

> Hi,
>
> Based on the documentation:
>
> "The map key can be any type that is comparable."
> "Struct values are comparable if all their fields are comparable. Two
> struct values are equal if their corresponding non-blank fields are equal."
> "Interface values are comparable. Two interface values are equal if they
> have identical dynamic types and equal dynamic values or if both have value
> nil."
>
> My understanding is that I can use an structure like this as a key for a
> map
>
> type dialer interface {
> dial()
> }
>
> type key struct {
> id string
> number int
> dialer  dialer
> }
>
> It also seems to work fine https://go.dev/play/p/hKQfx-JH5WP
>

This works in general, but your example is flawed. In your example, you have

f1 := {}
f2 := {}

and then use f1 anf f2 as keys. These are pointers to structs, so the
comparison will be pointer comparison, not field-by-field comparison.

If you do:

f1 := fakedialer{}
f2 := fakedialer2{}

and replace the pointer receivers with value receivers, and then use these
as map keys, it will work. But this time, if you pass a struct that cannot
be used as a key, you'll receive a runtime panic instead of a compile error.


> But I'm wondering if I'm missing something or are there some corner cases
> I should take into account before doing this ...  or if this is not
> recommended at all
>
> 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/97b7368e-d276-40ab-afa3-f8a7868fd9ean%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/CAMV2Rqq4qLv6eaBcRJ7r%3DOn3D%2B9YxLeaVSnfme-F187md%3DR7LA%40mail.gmail.com.

[go-nuts] Struct with Interfaces fields as key in maps

[antonio.o...@gmail.com]

Hi,

Based on the documentation:

"The map key can be any type that is comparable."
"Struct values are comparable if all their fields are comparable. Two 
struct values are equal if their corresponding non-blank fields are equal."
"Interface values are comparable. Two interface values are equal if they 
have identical dynamic types and equal dynamic values or if both have value 
nil."

My understanding is that I can use an structure like this as a key for a map

type dialer interface {
dial()
}

type key struct {
id string
number int
dialer  dialer
}

It also seems to work fine https://go.dev/play/p/hKQfx-JH5WP

But I'm wondering if I'm missing something or are there some corner cases I 
should take into account before doing this ...  or if this is not 
recommended at all

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/97b7368e-d276-40ab-afa3-f8a7868fd9ean%40googlegroups.com.

[go-nuts] Re: How long does it take to import packages?

[Brian Candler]

"import" and const calculations are compile-time activities, whereas init() 
and global var assignment are run-time activities.

How does the time to compile your code to an executable, compare to running 
the tests? If compiling the code is fast but running the tests is slow, 
that rules out any problems with "import".

If it takes "dozens of seconds" to compile your code, that doesn't sound 
right unless either your codebase is huge, or you're running in a very slow 
environment (e.g. virtualization without hardware support like VT-x).

If it takes "dozens of seconds" to start your test suite, that doesn't 
sound right unless you're accidentally compiling and testing all your 
dependent libraries as well as your own code.  Or it could be that your 
test *is* starting quickly, but the first test runs very slowly - maybe 
it's opening network connections or doing DNS resolutions which time out, 
or something like that.

One thing you can try is to use strace to see system calls:

strace -f -s128 go test ...etc...

This might give you some clues, especially if you see a long pause in the 
strace output (what system call did it do just before the pause?)

Another idea is to do a binary chop.  First, make a copy of your project 
and remove all the tests except for one "hello world" test; see if it's 
fast.  If it is, that shows that it's either building or running your own 
test code which is slow, not the importing of third-party libraries.  Then 
do the same but cut out only the first half of the tests, then repeat 
cutting out only the second half of the tests.  When you've found which 
half is slow, cut that in half again - and so on.

On Wednesday, 31 August 2022 at 08:00:41 UTC+1 ag9920 wrote:

> Hi, recently I've been trying to make my unit test faster. It seems too 
> much time were spent on initialization. After removing all init() function 
> in relevant packages. The speed was still very slow.It even takes dozens of 
> seconds before entering my real unit test function.
>
> So I take a look at all the possible factors that might slow down the 
> testing. The only possible reason I can think of is the time cost on 
> import. Golang needs to import all packages recursively. And in my 
> scenario, that's roughly dozens of packages.Maybe initializing const, var 
> takes too much time. 
>
> Is there any solution that could help me figured out the reason? I didn't 
> find any tools that could tell me the time cost on import several packages.
>
> And if that's the case,  import a package does take much time, is it still 
> possible for me to speed up my unit test? 
>  
>

-- 
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/b0ad7306-7c2f-40e6-a631-cb7ee9a4cb6en%40googlegroups.com.

Re: [go-nuts] How long does it take to import packages?

[Jan Mercl]

On Wed, Aug 31, 2022 at 9:00 AM ag9920  wrote:

> Hi, recently I've been trying to make my unit test faster. It seems too much 
> time were spent on initialization.

The "seems" part is a guess or a measurement? How much is "too much time"?

> After removing all init() function in relevant packages. The speed was still 
> very slow.It even takes dozens of seconds before entering my real unit test 
> function.

What operating system and what command line arguments are you using to
run the package tests? Latest Go version or not? Can you share the
go.mod file of the package? Do you use any variant of the 'go clean'
command, or something similar, before running the tests?

-- 
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/CAA40n-XsnJONGtn8yVLj6LPpyP%3DOxEbYxjRiaFDrrQO%3DBXTDRQ%40mail.gmail.com.

Re: [go-nuts] How long does it take to import packages?

['Axel Wagner' via golang-nuts]

On Wed, Aug 31, 2022 at 9:01 AM ag9920  wrote:

> Hi, recently I've been trying to make my unit test faster. It seems too
> much time were spent on initialization. After removing all init() function
> in relevant packages. The speed was still very slow.It even takes dozens of
> seconds before entering my real unit test function.
>
> So I take a look at all the possible factors that might slow down the
> testing. The only possible reason I can think of is the time cost on
> import. Golang needs to import all packages recursively. And in my
> scenario, that's roughly dozens of packages.Maybe initializing const, var
> takes too much time.
>

"dozens of packages" is not a lot. It's very few, actually. It seems
extremely unlikely to me, that if you observe dozens of seconds of startup
time it has anything to do with importing those packages by themselves. IMO
that is only really explainable by something waiting on I/O or sleeping or
something like that in the initialization path.


> Is there any solution that could help me figured out the reason? I didn't
> find any tools that could tell me the time cost on import several packages.
>

You could probably just do a CPU profile. If you exit immediately from your
test functions, then anything appearing in the profile would necessarily be
where the initialization is spent.
You can also try out tracing your test program
.
Personally, I found that a bit harder to set up and interpret, but it
should give you an exact answer.


> And if that's the case,  import a package does take much time, is it still
> possible for me to speed up my unit test?
>
>
> --
> 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/cd58955e-0c4b-4d56-afd7-1153d7be06dcn%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/CAEkBMfE%3D1NiYauCtrORRm2hqy3fKC65Ab4%2BuqMBv4EsruGVDCQ%40mail.gmail.com.

[go-nuts] How long does it take to import packages?

[ag9920]

Hi, recently I've been trying to make my unit test faster. It seems too 
much time were spent on initialization. After removing all init() function 
in relevant packages. The speed was still very slow.It even takes dozens of 
seconds before entering my real unit test function.

So I take a look at all the possible factors that might slow down the 
testing. The only possible reason I can think of is the time cost on 
import. Golang needs to import all packages recursively. And in my 
scenario, that's roughly dozens of packages.Maybe initializing const, var 
takes too much time. 

Is there any solution that could help me figured out the reason? I didn't 
find any tools that could tell me the time cost on import several packages.

And if that's the case,  import a package does take much time, is it still 
possible for me to speed up my unit test? 
 

-- 
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/cd58955e-0c4b-4d56-afd7-1153d7be06dcn%40googlegroups.com.