[go-nuts] Re: Upgrading to last version of dependency without upgrading toolchain?

['TheDiveO' via golang-nuts]

For the archeologists, underlying issue has been acknowledged 
https://github.com/golang/go/issues/67574; sadly, this forum kept schtumm.

On Monday, May 6, 2024 at 1:46:17 PM UTC+2 TheDiveO wrote:

> As I cannot edit the title anymore: it's about upgrading to the last 
> version that can be used without toolchain change, which is not necessarily 
> the "latest" version of a dependency.
>
> On Monday, May 6, 2024 at 10:42:17 AM UTC+2 TheDiveO wrote:
>
>> FYI, go-mod-upgrade runs the following command under its hood:
>>
>> go list -u -mod=readonly -f '{{if (and (not (or .Main .Indirect)) 
>> .Update)}}{{.Path}}: {{.Version}} -> {{.Update.Version}}{{end}}' -m all
>>
>> On Monday, May 6, 2024 at 10:36:08 AM UTC+2 TheDiveO wrote:
>>
>>> Up front, I have to admit that I'm struggling with the newly introduced 
>>> download-your-go-toolchain-on-the-fly when it comes to:
>>>
>>>1. having reproducible builds in a CI/CD pipeline without getting 
>>>downloaded a different toolchain as installed at the stage start,
>>>2. being a module maintained as opposed to being a "leaf" app 
>>>maintainer without downstream users, while maintaining the N,N-1 go 
>>> (minor) 
>>>version guarantee.
>>>
>>> Over the years, I've found https://github.com/oligot/go-mod-upgrade to 
>>> be very useful to me in maintaining my (intermediate) module dependencies. 
>>> Unfortunately, this tool now breaks down and the author of go-mod-upgrade 
>>> at this time considers the situation to be a go toolchain upstream problem (
>>> https://github.com/oligot/go-mod-upgrade/issues/52#issuecomment-2093537300
>>> ).
>>>
>>> What happens is when I'm on a go 1.21.x toolchain in order to ensure the 
>>> N,N-1 guarantee, a go-mod-upgrade on a module with a k8s.io/api  
>>> "crashes" with the following error, caused by the go command used from 
>>> go-mod-upgrade under its hood:
>>>
>>>
>>> *Error running go command to discover modules: exit status 1 stderr=go: 
>>> loading module retractions for k8s.io/a...@v0.26.2 
>>> <http://k8s.io/api@v0.26.2>: module k8s.io/a...@v0.30.0 
>>> <http://k8s.io/api@v0.30.0> requires go >= 1.22.0 (running go 1.21.7; 
>>> GOTOOLCHAIN=local)*
>>>
>>> Is there a way in the go command to upgrade to the "latest" dependency 
>>> that doesn't trigger this error? Manually 
>>> <https://pkg.go.dev/k8s.io/api?tab=versions>, I can see that there is a 
>>> 0.29.4 available. Unfortunately, even a single dependency like this causes 
>>> go-mod-upgrade to fail completely, so it's back for me to maintaining each 
>>> and ever of my many deps individually ... which absolutely sucks from the 
>>> UX perspective as I'm sure you can follow along with. Remember, I simply 
>>> cannot switch toolchains on a whim, not least due to CI/CD policies.
>>>
>>> How to deal with this situation? Is there a way to use the go tool so 
>>> that it would return only upgrades without toolchain changes? How might the 
>>> go-mod-upgrade tool work around this situation?
>>>
>>>

-- 
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/5032c3c3-74cc-4272-bd97-3d99c55bd4a7n%40googlegroups.com.

[go-nuts] Re: Upgrading to last version of dependency without upgrading toolchain?

['TheDiveO' via golang-nuts]

As I cannot edit the title anymore: it's about upgrading to the last 
version that can be used without toolchain change, which is not necessarily 
the "latest" version of a dependency.

On Monday, May 6, 2024 at 10:42:17 AM UTC+2 TheDiveO wrote:

> FYI, go-mod-upgrade runs the following command under its hood:
>
> go list -u -mod=readonly -f '{{if (and (not (or .Main .Indirect)) 
> .Update)}}{{.Path}}: {{.Version}} -> {{.Update.Version}}{{end}}' -m all
>
> On Monday, May 6, 2024 at 10:36:08 AM UTC+2 TheDiveO wrote:
>
>> Up front, I have to admit that I'm struggling with the newly introduced 
>> download-your-go-toolchain-on-the-fly when it comes to:
>>
>>1. having reproducible builds in a CI/CD pipeline without getting 
>>downloaded a different toolchain as installed at the stage start,
>>2. being a module maintained as opposed to being a "leaf" app 
>>maintainer without downstream users, while maintaining the N,N-1 go 
>> (minor) 
>>version guarantee.
>>
>> Over the years, I've found https://github.com/oligot/go-mod-upgrade to 
>> be very useful to me in maintaining my (intermediate) module dependencies. 
>> Unfortunately, this tool now breaks down and the author of go-mod-upgrade 
>> at this time considers the situation to be a go toolchain upstream problem (
>> https://github.com/oligot/go-mod-upgrade/issues/52#issuecomment-2093537300
>> ).
>>
>> What happens is when I'm on a go 1.21.x toolchain in order to ensure the 
>> N,N-1 guarantee, a go-mod-upgrade on a module with a k8s.io/api  
>> "crashes" with the following error, caused by the go command used from 
>> go-mod-upgrade under its hood:
>>
>>
>> *Error running go command to discover modules: exit status 1 stderr=go: 
>> loading module retractions for k8s.io/a...@v0.26.2 
>> <http://k8s.io/api@v0.26.2>: module k8s.io/a...@v0.30.0 
>> <http://k8s.io/api@v0.30.0> requires go >= 1.22.0 (running go 1.21.7; 
>> GOTOOLCHAIN=local)*
>>
>> Is there a way in the go command to upgrade to the "latest" dependency 
>> that doesn't trigger this error? Manually 
>> <https://pkg.go.dev/k8s.io/api?tab=versions>, I can see that there is a 
>> 0.29.4 available. Unfortunately, even a single dependency like this causes 
>> go-mod-upgrade to fail completely, so it's back for me to maintaining each 
>> and ever of my many deps individually ... which absolutely sucks from the 
>> UX perspective as I'm sure you can follow along with. Remember, I simply 
>> cannot switch toolchains on a whim, not least due to CI/CD policies.
>>
>> How to deal with this situation? Is there a way to use the go tool so 
>> that it would return only upgrades without toolchain changes? How might the 
>> go-mod-upgrade tool work around this situation?
>>
>>

-- 
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/07810048-2b9d-47f2-8694-5cc741e09884n%40googlegroups.com.

[go-nuts] Re: Upgrading to last version of dependency without upgrading toolchain?

['TheDiveO' via golang-nuts]

FYI, go-mod-upgrade runs the following command under its hood:

go list -u -mod=readonly -f '{{if (and (not (or .Main .Indirect)) 
.Update)}}{{.Path}}: {{.Version}} -> {{.Update.Version}}{{end}}' -m all

On Monday, May 6, 2024 at 10:36:08 AM UTC+2 TheDiveO wrote:

> Up front, I have to admit that I'm struggling with the newly introduced 
> download-your-go-toolchain-on-the-fly when it comes to:
>
>1. having reproducible builds in a CI/CD pipeline without getting 
>downloaded a different toolchain as installed at the stage start,
>2. being a module maintained as opposed to being a "leaf" app 
>maintainer without downstream users, while maintaining the N,N-1 go 
> (minor) 
>version guarantee.
>
> Over the years, I've found https://github.com/oligot/go-mod-upgrade to be 
> very useful to me in maintaining my (intermediate) module dependencies. 
> Unfortunately, this tool now breaks down and the author of go-mod-upgrade 
> at this time considers the situation to be a go toolchain upstream problem (
> https://github.com/oligot/go-mod-upgrade/issues/52#issuecomment-2093537300
> ).
>
> What happens is when I'm on a go 1.21.x toolchain in order to ensure the 
> N,N-1 guarantee, a go-mod-upgrade on a module with a k8s.io/api  
> "crashes" with the following error, caused by the go command used from 
> go-mod-upgrade under its hood:
>
>
> *Error running go command to discover modules: exit status 1 stderr=go: 
> loading module retractions for k8s.io/a...@v0.26.2 
> <http://k8s.io/api@v0.26.2>: module k8s.io/a...@v0.30.0 
> <http://k8s.io/api@v0.30.0> requires go >= 1.22.0 (running go 1.21.7; 
> GOTOOLCHAIN=local)*
>
> Is there a way in the go command to upgrade to the "latest" dependency 
> that doesn't trigger this error? Manually 
> <https://pkg.go.dev/k8s.io/api?tab=versions>, I can see that there is a 
> 0.29.4 available. Unfortunately, even a single dependency like this causes 
> go-mod-upgrade to fail completely, so it's back for me to maintaining each 
> and ever of my many deps individually ... which absolutely sucks from the 
> UX perspective as I'm sure you can follow along with. Remember, I simply 
> cannot switch toolchains on a whim, not least due to CI/CD policies.
>
> How to deal with this situation? Is there a way to use the go tool so that 
> it would return only upgrades without toolchain changes? How might the 
> go-mod-upgrade tool work around this situation?
>
>

-- 
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/35dcd7f7-ef73-41d8-9f04-b36aa04fc94en%40googlegroups.com.

[go-nuts] Upgrading to last version of dependency without upgrading toolchain?

['TheDiveO' via golang-nuts]

Up front, I have to admit that I'm struggling with the newly introduced 
download-your-go-toolchain-on-the-fly when it comes to:

   1. having reproducible builds in a CI/CD pipeline without getting 
   downloaded a different toolchain as installed at the stage start,
   2. being a module maintained as opposed to being a "leaf" app maintainer 
   without downstream users, while maintaining the N,N-1 go (minor) version 
   guarantee.

Over the years, I've found https://github.com/oligot/go-mod-upgrade to be 
very useful to me in maintaining my (intermediate) module dependencies. 
Unfortunately, this tool now breaks down and the author of go-mod-upgrade 
at this time considers the situation to be a go toolchain upstream problem 
(https://github.com/oligot/go-mod-upgrade/issues/52#issuecomment-2093537300).

What happens is when I'm on a go 1.21.x toolchain in order to ensure the 
N,N-1 guarantee, a go-mod-upgrade on a module with a k8s.io/api  "crashes" 
with the following error, caused by the go command used from go-mod-upgrade 
under its hood:


*Error running go command to discover modules: exit status 1 stderr=go: 
loading module retractions for k8s.io/api@v0.26.2: module 
k8s.io/api@v0.30.0 requires go >= 1.22.0 (running go 1.21.7; 
GOTOOLCHAIN=local)*

Is there a way in the go command to upgrade to the "latest" dependency that 
doesn't trigger this error? Manually 
, I can see that there is a 
0.29.4 available. Unfortunately, even a single dependency like this causes 
go-mod-upgrade to fail completely, so it's back for me to maintaining each 
and ever of my many deps individually ... which absolutely sucks from the 
UX perspective as I'm sure you can follow along with. Remember, I simply 
cannot switch toolchains on a whim, not least due to CI/CD policies.

How to deal with this situation? Is there a way to use the go tool so that 
it would return only upgrades without toolchain changes? How might the 
go-mod-upgrade tool work around this situation?

-- 
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/b7ec48e6-4f74-4c9e-8fb9-1442aed2178bn%40googlegroups.com.

[go-nuts] Re: Is json.Marshal deterministic?

['TheDiveO' via golang-nuts]

They are distinct indeed.

An "if sl == nil ..." will not match an empty slice. It is len(sl) that 
returns 0 for both nil and empty slices, and range working along the same 
idea.

playground example: https://goplay.tools/snippet/df0bG6YXfJZ
https://goplay.tools/snippet/df0bG6YXf
https://goplay.tools/snippet/df0bG6YXfJZ

On Thursday, April 11, 2024 at 12:42:21 PM UTC+2 Juliusz Chroboczek wrote:

> > I don't know if JSON serialization is deterministic, but I know a couple
> > of cases when it is not.
>
> > If the type or some type inside it has a custom JSON marshaller (method
> > MarshalJSON), then if that function's output is not deterministic, the
> > whole JSON for the type is not deterministic.
>
> Obviously.
>
> > Another common pitfall with JSON: nil vs empty slice. E.g. []string{} is
> > encoded as "[]", while []string(nil) is encoded as "null", while they 
> both
> > mean an empty slice in Go
>
> I'm not sure I follow. I was under the impression that the empty array
> and nil are distinct values in Go, even though many functions treat them
> the same.
>
> -- Juliusz
>
>

-- 
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/9d28bdda-27dd-45a5-9863-b259cad2a088n%40googlegroups.com.

Re: [go-nuts] user process instruction pointer symbol lookup

['TheDiveO' via golang-nuts]

Thank you Ian!

Not sure yet if I found something useful related to the real process 
addresses/offsets, but at least the "bcc" sources have one 
"bcc_elf_get_text_scn_info()" that returns the address and offset of the 
".text" section.

On Tuesday, April 2, 2024 at 8:01:11 PM UTC+2 Ian Lance Taylor wrote:

> On Tue, Apr 2, 2024 at 2:35 AM 'TheDiveO' via golang-nuts
>  wrote:
> >
> > On Linux, given an arbitrary binary executable with symbol information 
> in the executable, how can I lookup an instruction pointer address to get 
> the corresponding symbol name?
> >
> > The binary (and its process) isn't a Go binary, but any arbitrary 
> executable. The stack unwinding has already been done, so I'm presented 
> with a list of instruction pointer addresses (return addresses) which I 
> need to convert to more useful symbol names.
> >
> > I've seen the stdlib's debug/elf package, but I lack the ELF knowledge 
> to press the elf package's knobs in the right order. Any examples of how to 
> use debug/elf, and is it even the right package to use in this case?
>
> debug/elf is the package to use. You'll want to call the Symbols
> method and look through the Symbols for one whose Value is <= the PC
> you want while Value+Size is > the PC you want.
>
> If you are looking at runtime PC's from a stack trace, be aware that
> on most systems these days programs are position-independent, so there
> will be an offset between the addresses in the binary and the
> addresses from the stack trace. I don't know offhand of a standard
> way to figure out that offset.
>
> 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/7076c963-9cad-4c24-b00f-dcf9d88ede8fn%40googlegroups.com.

[go-nuts] user process instruction pointer symbol lookup

['TheDiveO' via golang-nuts]

On Linux, given an arbitrary binary executable with symbol information in 
the executable, how can I lookup an instruction pointer address to get the 
corresponding symbol name?

The binary (and its process) isn't a Go binary, but any arbitrary 
executable. The stack unwinding has already been done, so I'm presented 
with a list of instruction pointer addresses (return addresses) which I 
need to convert to more useful symbol names.

I've seen the stdlib's debug/elf package, but I lack the ELF knowledge to 
press the elf package's knobs in the right order. Any examples of how to 
use debug/elf, and is it even the right package to use in this case?

-- 
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/b1140454-fe04-4d90-85a6-24def72803c5n%40googlegroups.com.

[go-nuts] Re: go test -coverpkg=$LIST ... failing with exit code

['TheDiveO' via golang-nuts]

Looking and looking again, at least I spotted a lonely "open 
/tmp/go-build/covmeta: no such file or directory" error message. 
This now finally matches https://github.com/golang/go/issues/65653 and 
using gotip finally succeeds correctly.

-- 
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/75d9c016-5e43-4202-bd8b-54fb560e8d95n%40googlegroups.com.

[go-nuts] go test -coverpkg=$LIST ... failing with exit code

['TheDiveO' via golang-nuts]

Dear Gophers,

I'm struggling with "go test -coverpkg=XXX ... ./... -args 
-test.gocoverdir" returning non-zero exit codes, albeit all tests are 
passing. It might well be that I'm not really yet understanding how "go 
test -coverpkg=" is supposed to work. As illustrated below, I don't want to 
-coverpkg *all* packages "./..." in my module, but instead all *but one*.

First, I'm using go version go1.22.1 linux/amd64. The same happens for 
go1.22.0, too.

Now, my repo in a minimized example might look like the following -- 
unfortunately, I don't see how I can make a useful playground example with 
the required specific "go test" invocation.

   - github.com/example/foo
  - bar -- contains tests
  - baz -- contains tests
  - foobaz -- no tests
   
Following is preparing the list of packages to cover, with the exclusion(s):

GOCOVERTMPDIR="$(mktemp -d)"
trap 'rm -rf -- "$GOCOVERTMPDIR"' EXIT
IGNORE_PKGS=("github.com/example/foobaz")
FILTER_PATTERN="$(printf '^%s$|' "${IGNORE_PKGS[@]}" | sed 's/|$//')"
PACKAGE_LIST=$(go list ./... | grep -v -E "${FILTER_PATTERN}" | tr '\n' ',' 
| sed 's/,$//')
go test -coverpkg="${PACKAGE_LIST}" -v -tags=matchers -p=1 -count=1 -race \
./... -args -test.gocoverdir="$GOCOVERTMPDIR"

This runs all available tests including testable examples with success, but 
exits with code 1.

Running the same tests with -coverpkg=./... succeeds.

What am I doing wrong? Or might this be an issue?

*Nota bene:* *why do I want to exclude a package from the coverage? Because 
that is a trimmed-down package (as permitted by its license) following 
CalVer(!) and having no go.mod, with otherwise large number of unnecessary 
dependencies in my particular case. It changes the coverage considerably, 
distracting from the coverage of my own code.*

-- 
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/541ca662-f052-4a99-aa2b-b4b8d6924ffbn%40googlegroups.com.

[go-nuts] Re: c-shared library for Aix

['TheDiveO' via golang-nuts]

llvm/clang? I've ditched gcc because of its many unfixable problems. After 
loosing quite some time, trying to cross-compile Go using gcc, I've 
switched to clang IIRC and this works beautifully, especially 
cross-building for Alpine/musl. However my AIX time with RS6000 was decades 
ago, and I was the one constantly turning up new kernel bugs from user 
space.

On Saturday, March 2, 2024 at 6:42:56 PM UTC+1 Anshuman Mor wrote:

> I have written multiple c-shared libraries code in golang for Windows, 
> Linux, MacOS . I am using GCC cross compiler for the same. This code is 
> running fine in production without any issue since last 3 years.
>
> But, we have recently got a requirement to compile the same thing for 
> AIX/PowerPC but I am afraid that go compiler doesn't support this out of 
> the box, I tried many approaches but none worked like - 
>
> 1. Using gccgo compiler but this errors out with "Thread Local Storage" 
> error.
> 2. Using c-archive and then convert to shared using gcc compiler, this 
> also errors out with something or other.
>
> Has anyone done similar type of work for Aix? Any help would be greatly 
> appreciated.
>

-- 
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/46aae3da-4197-4dc1-b35c-985f5998226fn%40googlegroups.com.

[go-nuts] coverage seems to show code as not covered, but code is actually executed

['TheDiveO' via golang-nuts]

I've noticed what looks at its surface that some code that is covered 
doesn't show up in the cover profile data. Unfortunately, I don't have a 
minimal example as I have no idea how to drill down. So please bear with my 
explanations and hopefully it's a problem between VT100 and chair, I just 
don't see it yet.

I see the same behavior with go 1.22.0 as well as 1.21.7.

This is the repository where I see the seemingly odd 
profile: https://github.com/thediveo/notwork (sic!)

I run all tests as follows with coverage, see 
also https://github.com/thediveo/notwork/blob/master/scripts/cov.sh, but 
this is the gist:

GOCOVERTMPDIR="$(mktemp -d)"
trap 'rm -rf -- "$GOCOVERTMPDIR"' EXIT
go test -cover -v -race -exec sudo -tags ${BUILDTAGS} -p=1 \
  -count=1 ./... -args -test.gocoverdir="$GOCOVERTMPDIR"
go tool covdata textfmt -i="$GOCOVERTMPDIR" -o=coverage.out
go tool cover -html=coverage.out -o=coverage.html

The problem now is 
in 
https://github.com/thediveo/notwork/blob/14cb6bc6ffc51704df84f95b88fdd0097c62bad6/link/link.go#L81,
 
where the if branch is shown as uncovered:

if veth, ok := link.(*netlink.Veth); ok {
Expect(rand.Read(randbytes)).Error().NotTo(HaveOccurred())
peername := prefix + hex.EncodeToString(randbytes)
veth.PeerName = peername
}

This branch is covered, as can be seen by putting a panic into it. This 
test 
https://github.com/thediveo/notwork/blob/14cb6bc6ffc51704df84f95b88fdd0097c62bad6/veth/veth_test.go#L36
 
here causes this branch to be taken, 
via 
https://github.com/thediveo/notwork/blob/14cb6bc6ffc51704df84f95b88fdd0097c62bad6/veth/veth.go#L38.

This coverage behavior should be hopefully reprodroducable by cloning the 
repository and running "make coverage" in its top-level directory.

So what am I doing wrong here?

-- 
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/45fc1f9f-d331-4013-aafe-b597f9ebb81en%40googlegroups.com.

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

['TheDiveO' via golang-nuts]

Forgive me if I missed that, but what if I have multiple context vars, 
because I need to pass different (derived) contexts into different 
functions/receivers? Take unit tests as real-world examples.

On Wednesday, February 21, 2024 at 1:37:05 AM UTC+1 Sam Vilain wrote:

> Alright, well thanks for your input.
>
> I do think these questions can be answered; exploring the use cases in a 
> proposal format should hopefully show that the impact of closures would not 
> normally be an issue.  Possibly the worst case is if you had a library to 
> some external service, and at some low layer you're using a closure, well 
> you might need to refactor that if you wanted to add cross–service tracing 
> support.  But to be honest, it's probably better that the state you're 
> depending on is captured in a struct instead of being scattered about 
> loosely in a scope as with a closure.  And the common practice in Go is to 
> return types that satisfy interfaces, not function references that you 
> blind call.
>
> I think I will submit a proposal, but please don't take that to imply that 
> I think you're "wrong, or mistaken".  Your concerns are legitimate and the 
> proposal should answer them cleanly.  In the proposal format, hopefully the 
> "litigation", or more exploration of possible uses and abuses of the 
> system, along with performance concerns, can be addressed.  I don't want to 
> be dismissive of them, I just want to understand them.
>
> I had a brief look on the Golang issues in Github and could not find any 
> prior proposals along this line using "context" and "dynamic scope" as 
> search terms, so I'll submit this as a "new" proposal for now.
>
> Thanks again, and truly—thanks for responding, >100% better than people 
> who just rolled eyes and marked thread as read.
>
> Cheers,
> Sam
> On 2/20/24 3:35 PM, Axel Wagner wrote:
>
> If I may quote myself:
>
> > And no matter which choice you make for the language - it means that if 
> the programmers wanted the other, they'd have to jump through annoying 
> hoops and get confusing and hard to debug problems.
>
> Having a mechanism to get one or the other semantic doesn't change the 
> fact that it's easy to choose wrongly by accident, as long as the effect is 
> implicit. In fact, the mechanism you propose (AIUI) seems extra confusing: 
> Having a function value sometimes create a new dynamic scope and sometimes 
> not, is weird and seems like a recipe for frustration.
>
> But really, convincing me isn't really the point, which is why I'm not 
> super invested in litigating this (otherwise I might try to come up with 
> realistic examples, for instance. Or explain further why I'm still not sure 
> that this can be implemented efficiently). I'm just re-stating what, in the 
> past, where the reasons why things like this have been rejected. In order 
> to predict what I would consider a likely outcome of a proposal like this.
>
> If you think I am wrong or misunderstanding you, you can always file a 
> proposal to get a more official response.
>
> On Tue, Feb 20, 2024 at 8:18 PM Sam Vilain  wrote:
>
>> On 2/17/24 1:32 AM, Axel Wagner wrote:
>>
>> On Sat, Feb 17, 2024 at 2:09 AM Sam Vilain  wrote:
>>
>>> I would argue that the matter can be simply decided by choosing the 
>>> *calling* stack, not the destination stack.
>>>
>>  
>> I agree that this is *one choice*. But the point is, that *sometimes* 
>> you'd want one and *sometimes* the other. And no matter which choice you 
>> make for the language - it means that if the programmers wanted the other, 
>> they'd have to jump through annoying hoops and get confusing and hard to 
>> debug problems. So if you want to justify either choice, you have to make 
>> an argument that it is so overwhelmingly more common what people would 
>> want, that the cost of running into these problems is small enough to be 
>> justified by the benefit.
>>
>> I think that's a hard case to make.
>>
>> Alex, I agree that there are cases where you might prefer one versus the 
>> other.  However, you cut out the part of my reply where I pointed out it 
>> was possible to choose semantics by either returning a closure (context is 
>> the source stack) or a bound method (context is the destination stack).  
>> Both of these values can be used interchangeably, as they have the same 
>> type, func ..., and so the caller does not need to care whether the 
>> function they are calling uses the calling context or the original 
>> context.  Were you not convinced by the argument?
>>
>> Sam
>>
> -- 
> Sam
>
>

-- 
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/98dc6699-2b2e-48a8-bc4c-fc70406940e5n%40googlegroups.com.

[go-nuts] Re: go mod download fails on docker for 1.20 (but not for 1.18)

['TheDiveO' via golang-nuts]

carrier-grade NAT?

On Friday, February 2, 2024 at 7:05:42 PM UTC+1 sprynger wrote:

> In my case it might be an ISP problem, since this only happens to me when 
> I work from home. At work, the exact same project builds all at once 
> without any issues.
>
> A quinta-feira, 1 de fevereiro de 2024 à(s) 21:07:03 UTC, TheDiveO 
> escreveu:
>
>> Are you still using Debian 11 and the outdated Debian docker.io package 
>> with Docker 18? What happens when you use a recent Docker, either 24.x or 
>> hot-off-the-press 25.0.1? And then build using a Go-Alpine base image? Do 
>> you still use Debian's broken Docker seccomp profile...?
>>
>> I'm on an IPv6 uplink and in all these years never seen this issue. I'm 
>> not using Debian due to its totally outdated cloud/container packages, but 
>> instead a *ubuntu host with docker-ce packages, using alpine base images 
>> for building ... and never such an issue. So my bet would be on Debian 
>> and/or your ISP. From my bad experience with many nightmarish late hour 
>> diagnosis sessions with oversees my bet is on Debian, especially the LTS 
>> long-term-broken variants.
>>
>> On Thursday, February 1, 2024 at 8:48:42 PM UTC+1 Sebastiaan van der 
>> Meulen wrote:
>>
>>> Same issue here without solution. Hoping anyone finds one
>>>
>>> Op zondag 14 januari 2024 om 22:53:54 UTC+1 schreef Dmitry Anderson 
>>> (4nd3rs0n):
>>>
>>>> I'm having the same problem. For now I just vendor modules to a project 
>>>> modules and run without installing anything from the container, but also 
>>>> would like to find a fix.
>>>> On Monday, May 22, 2023 at 2:29:08 AM UTC+2 Joao Miguel Ferreira wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> My docker build is ok with FROM golang:1.18-alpine, FROM 
>>>>> golang:1.18-buster and FROM golang:1.18-bullseye images. The 
>>>>> application works. All is fine on the 3 cases.
>>>>>
>>>>> But the docker build fails with FROM golang:1.20-alpine, FROM 
>>>>> golang:1.20-buster and FROM golang:1.20-bullseye images.
>>>>>
>>>>> This is the error message I get:
>>>>>
>>>>> go: github.com/davecgh/go-...@v1.1.1 
>>>>> <http://github.com/davecgh/go-spew@v1.1.1>: Get "
>>>>> https://proxy.golang.org/github.com/davecgh/go-spew/@v/v1.1.1.mod": 
>>>>> dial tcp [2a00:1450:4003:801::2011]:443: connect: cannot assign requested 
>>>>> address
>>>>>
>>>>> It happens during go mod download. It happens when building on 
>>>>> Debian11, Debian12 and Ubuntu22 hosts.
>>>>>
>>>>> I have tried many things including going inside the container and 
>>>>> downloading the module with wget. It works fine. Maybe something changed 
>>>>> from 1.18 to 1.20 related to ipv6.
>>>>>
>>>>> I would like to be able to do the build with one golang 1.20 image. 
>>>>> But I can not understand what is wrong. Can you help clarify that error 
>>>>> and 
>>>>> how to overcome it?
>>>>>
>>>>>
>>>>>

-- 
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/7f892f6a-50bc-4b4b-9679-3cab77693152n%40googlegroups.com.

[go-nuts] morbyd: a thin layer to easily build and run throw-away test containers, etc. in tests

['TheDiveO' via golang-nuts]

https://github.com/thediveo/morbyd is a thin layer on top of the standard 
Docker Go client to easily build and run throw-away test Docker images and 
containers, and running commands inside them. It features a function option 
API to keep the slightly excessive Docker API option parameters at bay. 
(And large test coverage FWIW).

You might ask: why, when there's ory/dockertest/v3?

Because their Ory's proprietary Docker client (predating the canonical one) 
is incompatible with the Docker daemon's 100 CONTINUE header when streaming 
container and command stdout/stderr. I've reported this, but did not got 
any response at all, so I finally cut my losses and wrote "morbyd" to be 
able to move on. The proper Docker client allows me to easily dump and 
analyse build and container output when tests go south.

Below is how morbyd feels, compared to ory/dockertest/v3, to give you an 
idea which API design might be better suited for you (or not):

dockertest (using Gomega for assertions):

Expect(pool.Client.BuildImage(docker.BuildImageOptions{
Name:   img.Name,
ContextDir: "./test/_kindisch", // sorry, couldn't resist the pun.
Dockerfile: "Dockerfile",
BuildArgs: []docker.BuildArg{
{Name: "KINDEST_BASE_TAG", Value: test.KindestBaseImageTag},
},
OutputStream: io.Discard,
})).To(Succeed())
providerCntr := Successful(pool.RunWithOptions(
{
Name:   kindischName,
Repository: img.Name,
Privileged: true,
Mounts: []string{
"/var", // well, this actually is an unnamed volume
"/dev/mapper:/dev/mapper",
"/lib/modules:/lib/modules:ro",
},
Tty: true,
}, func(hc *docker.HostConfig) {
hc.Init = false
hc.Tmpfs = map[string]string{
"/tmp": "",
"/run": "",
}
hc.Devices = []docker.Device{
{PathOnHost: "/dev/fuse"},
}
}))

morbyd (also using Gomega for assertions):

Expect(sess.BuildImage(ctx, "./test/_kindisch",
build.WithTag(img.Name),
build.WithBuildArg("KINDEST_BASE_TAG="+test.KindestBaseImageTag),
build.WithOutput(timestamper.New(GinkgoWriter.
Error().NotTo(HaveOccurred())
providerCntr := Successful(sess.Run(ctx, img.Name,
run.WithName(kindischName),
run.WithAutoRemove(),
run.WithPrivileged(),
run.WithSecurityOpt("label=disable"),
run.WithCgroupnsMode("private"),
run.WithVolume("/var"),
run.WithVolume("/dev/mapper:/dev/mapper"),
run.WithVolume("/lib/modules:/lib/modules:ro"),
run.WithTmpfs("/tmp"),
run.WithTmpfs("/run"),
run.WithDevice("/dev/fuse"),
run.WithCombinedOutput(timestamper.New(GinkgoWriter

Some of these options are not simply writing their arg in the same-name 
struct field, but instead are parsing things, preferably in the same way as 
the Docker CLI does. So the transition from CLI args to unit test args 
should be much smoother without having to dig deep into the Docker API 
parameter details.

While I tried to strive for more option completeness than just my own 
minimal viable proof, there surely a bits and pieces missing. In case 
morbyd might be interesting for you, I would be glad to hear from you and 
also missing pieces; and preferably a PR if you would be so kind.



-- 
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/34643167-7222-4e7a-a1a8-79d757c2c8fen%40googlegroups.com.

[go-nuts] Re: go mod download fails on docker for 1.20 (but not for 1.18)

['TheDiveO' via golang-nuts]

Are you still using Debian 11 and the outdated Debian docker.io package 
with Docker 18? What happens when you use a recent Docker, either 24.x or 
hot-off-the-press 25.0.1? And then build using a Go-Alpine base image? Do 
you still use Debian's broken Docker seccomp profile...?

I'm on an IPv6 uplink and in all these years never seen this issue. I'm not 
using Debian due to its totally outdated cloud/container packages, but 
instead a *ubuntu host with docker-ce packages, using alpine base images 
for building ... and never such an issue. So my bet would be on Debian 
and/or your ISP. From my bad experience with many nightmarish late hour 
diagnosis sessions with oversees my bet is on Debian, especially the LTS 
long-term-broken variants.

On Thursday, February 1, 2024 at 8:48:42 PM UTC+1 Sebastiaan van der Meulen 
wrote:

> Same issue here without solution. Hoping anyone finds one
>
> Op zondag 14 januari 2024 om 22:53:54 UTC+1 schreef Dmitry Anderson 
> (4nd3rs0n):
>
>> I'm having the same problem. For now I just vendor modules to a project 
>> modules and run without installing anything from the container, but also 
>> would like to find a fix.
>> On Monday, May 22, 2023 at 2:29:08 AM UTC+2 Joao Miguel Ferreira wrote:
>>
>>> Hello all,
>>>
>>> My docker build is ok with FROM golang:1.18-alpine, FROM 
>>> golang:1.18-buster and FROM golang:1.18-bullseye images. The 
>>> application works. All is fine on the 3 cases.
>>>
>>> But the docker build fails with FROM golang:1.20-alpine, FROM 
>>> golang:1.20-buster and FROM golang:1.20-bullseye images.
>>>
>>> This is the error message I get:
>>>
>>> go: github.com/davecgh/go-...@v1.1.1 
>>> : Get "
>>> https://proxy.golang.org/github.com/davecgh/go-spew/@v/v1.1.1.mod": 
>>> dial tcp [2a00:1450:4003:801::2011]:443: connect: cannot assign requested 
>>> address
>>>
>>> It happens during go mod download. It happens when building on 
>>> Debian11, Debian12 and Ubuntu22 hosts.
>>>
>>> I have tried many things including going inside the container and 
>>> downloading the module with wget. It works fine. Maybe something changed 
>>> from 1.18 to 1.20 related to ipv6.
>>>
>>> I would like to be able to do the build with one golang 1.20 image. But 
>>> I can not understand what is wrong. Can you help clarify that error and how 
>>> to overcome it?
>>>
>>>
>>>

-- 
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/9a169570-e108-4a44-9941-5f8d119f4663n%40googlegroups.com.

[go-nuts] Re: Blog Article: Go Generics (and also mocking)

['TheDiveO' via golang-nuts]

On Tuesday, January 9, 2024 at 2:28:08 AM UTC+1 Corin Lawson wrote:

On Tuesday 9 January 2024 at 1:12:00 am UTC+11 TheDiveO wrote:

One thing I notice is that your design assumes to specify the expected call 
sequence upon creation, or do I get this wrong? My expectation would be to 
specify this only at the assertion site.


That's correct, there is mock.Expect and mock.ExpectInOrder, that is used 
when you setup the test and only one mock.AssertExpectedCalls.  It would be 
feasible to introduce functions, say mock.AssertExpectedCallsInOrder and 
mock.AssertExpectedCallsInAnyOrder, 
which would change the meaning of mock.Expect (currently it assumes that 
the calls may occur in any order) and a explicit version could be 
introduced, say mock.ExpectInAnyOrder.  I think it's simpler to have a 
single mock.AssertExpectedCalls function, and making mock.Expect implicitly 
do one thing in one test and a different thing in another test is asking 
for trouble. The mock.AssertExpectedCalls function is designed to be used 
in a table driven testing pattern and individual tests in the table can 
provide a mock that is correctly configured, while the main body of the 
test simply calls mock.AssertExpectedCalls without needing to know anything 
else about the test.  But I would like to know more about your point of 
view, I haven't seen other mocking libraries make this determination at the 
assertion site.  Can you show me what you mean?


Basically Python's unittest.mock -- hopefully I'm not considered a heretic 
now :D -- https://docs.python.org/3/library/unittest.mock.html; now I 
understand that Python (or Lua FWIW) allow very convenient mocking due to 
their dynamic meta-model runtime...

from unittest.mock import MagicMock
thing = ProductionClass()
thing.method = MagicMock(return_value=3)
thing.method(3, 4, 5, key='value')
3
thing.method.assert_called_with(3, 4, 5, key='value')

Somehow that would be my expectation (literally coming from the Gomega 
background) that I can more flexibly do complex sequences on the mock 
without having to tell the mock the complete sequence beforehand. I 
personally like this unittest.mock style because it allows me to do a 
step-wise assertion/expectation approach that gives me more fine-grained 
reporting in case of assertion failure. Otherwise, it's a big mess and I 
need to sort out where exactly it started to go south.

Now this is probably more specific to my field of Go work, but I regularly 
have more complex unit tests that cannot really be sensibly spread into 
many individual -- to use Ginkgo terminology -- "It" leaf test nodes.


Since starting with Go I've been in love with Ginkgo/Gomega, as this is 
more on the level what I was working with in Python, compared to 
bare-footed Go testing ... is there a way to have the assertion of call 
sequence being independent of testing, such as returning what was expected 
and what it got? That is, something that allows it being used (with a 
wrapper) as a Gomega matcher...?


Gomega is very nice, I think it needs a certain level of buy-in, but once 
you make that choice there's some cool features... I'll have to have a 
closer look at gomega matchers...


Coming from the Python ecosystem and starting seriously with Go 1.11/Go 
1.12 when modules finally landed, I personally found the std testing to be 
very bare bones (which is fine considering the Go mantra here). So I looked 
what the really huge projects do, and this was in my case k8s :D -- I liked 
immediately what they used, as it was a comparably logical transition from 
Python expectation packages to Gomega and Ginkgo.

Disclaimer: I contributed the Go routine leak checker to Gomega after 
coming to the conclusion that the incredibly useful Uber go routine leak 
checker was too deeply intertwined with testing and couldn't be 
conveniently reused in Gomega. 

-- 
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/c1283f0a-0380-4fe7-aa45-b57baa34b9abn%40googlegroups.com.

[go-nuts] Re: Blog Article: Go Generics (and also mocking)

['TheDiveO' via golang-nuts]

  a quick first lock looks promising to me: I like the blog post, as it 
does IMHO a gentle introduction to your angle of attack. Having used 
mocking (or one of its twins/cousins/... for those who insist on this not 
being mocking, alas) on Python I've up to now found the Go mock packages to 
be difficult and with rather unwelcoming documentation.   As for the 
naming: kudos for naming it what it is, clear and concise, imagination be 
reserved to where it applies, not just here. 
On Monday, January 8, 2024 at 3:39:31 AM UTC+1 Corin Lawson wrote:

> I recently published a blog post about Go generics.  I've found that 
> there's lots of very good technical information about generics in Go, but I 
> felt that they are lacking some gritty experience reports.
>
>
> https://medium.com/versent-tech-blog/go-generics-tips-tricks-and-pitfalls-4342b82f9eeb
>
> The blog also introduces a new approach to generating mock objects in Go.
>
> https://github.com/Versent/go-mock
>
> I'm seeking feedback (as an inexperienced blogger) and also thoughts on 
> the mock lib (apologies for the lack of naming creativity),
>
> Thanks for your time.
>

-- 
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/9b791784-cb6d-4bbb-af67-3489701a4f84n%40googlegroups.com.

[go-nuts] Re: How to develop with Go source code change?

['TheDiveO' via golang-nuts]

Maybe your output is interfering with the way the go code base does some of 
it's checks; based on the fail in cmd/vet maybe this could be involved: 
https://github.com/golang/go/blob/b25f5558c69140deb652337afaab5c1186cd0ff1/src/cmd/vet/vet_test.go#L197?

On Tuesday, January 2, 2024 at 5:45:12 PM UTC+1 Rulin Tang wrote:

> Hey, I'm trying to do some Go source code development. But I'm confused 
> about how to do the development.
>
> The Go source code is cloned from https://github.com/golang/go master 
> branch. Originally, I run `cd src &^ ./all.bash` to build the latest Go 
> 1.22 version. It works fine.
>
> Then I'm trying to do some source code development. For example, I'm 
> looking at this issue https://github.com/golang/go/issues/64824. It's 
> something about devirtualize.go. So I added two debug lines like  `// 
> fmt.Printf("rulin DevirtualizeAndInlineFunc is called\n")` to 
> `src/compile/internal/interleaved/interleaved.go`.
>
> Then I tried to build an updated Go version with the updated Go source 
> code `./all.bash`. It failed with
> ```
>
> rulin DevirtualizeAndInlineFunc is called
>
> rulin DevirtualizeAndInlineFunc is called
>
> rulin DevirtualizeAndInlineFunc is called
>
> rulin DevirtualizeAndInlineFunc is called
>
> rulin DevirtualizeAndInlineFunc is called
>
> FAIL
>
> FAIL cmd/vet 20.524s
>
> FAIL
>
> go tool dist: Failed: exit status 1
>
> ```
>
> My original development plan is to add the debug line, build the updated 
> Go version, run test code with the updated Go version, and check the debug 
> output message at Go source code. Somehow this doesn't work. At least, it 
> stops at the first step to build an updated Go version with debug message.
>
> So here're two questions: 1. What did I do wrong in above steps? 2. Do I 
> have to rebuild Go version every time I make changes to Go source code? and 
> then use the updated Go version to test other existing Go code.
>
> 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/efa298d3-5385-423a-93bd-f492caf15574n%40googlegroups.com.

Re: [go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

['TheDiveO' via golang-nuts]

The issue is also reproducible using Python3 on macOS, whereas it works as 
expected once again on Linux; just for reference here's the corresponding SO 
question 
<https://stackoverflow.com/questions/77700314/detecting-named-pipe-reader-disconnect-using-select-poll-fails-on-macos-works-o>.
 
To a large extend, this now excludes potential Go and/or 
Ginkgo/Gomega-related effects, yet is consistent with my original 
observation and question here.

On Sunday, December 17, 2023 at 6:02:17 AM UTC+1 Kurtis Rader wrote:

On Sat, Dec 16, 2023 at 7:54 AM 'TheDiveO' via golang-nuts <
golan...@googlegroups.com> wrote:

[...] 

I only glanced at your unit test but the sleeps and goroutines without any 
explicit synchronization (e.g., using a sync.WaitGroup) look to me like a 
source of non-deterministic behavior.

[...] 

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/a7fe0e6e-d6b0-4881-a02c-61516684caf9n%40googlegroups.com.

Re: [go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

['TheDiveO' via golang-nuts]

It actually *does *work (again, there's a unit test as well as working code 
for five years now), but good to know that it is actually useless, so this 
is something to remove as part of the usual maintenance chores.

On Sunday, December 17, 2023 at 6:43:51 AM UTC+1 Kurtis Rader wrote:

On Fri, Dec 15, 2023 at 7:13 AM 'TheDiveO' via golang-nuts <
golan...@googlegroups.com> wrote:

I'm opening both named pipe ends as follows (in different processes):

os.OpenFile(fifoname, os.O_WRONLY, os.ModeNamedPipe)
os.OpenFile(fifoname, os.O_RDONLY, os.ModeNamedPipe)


Passing  os.ModeNamedPipe to os.OpenFile doesn't make any sense unless the 
open is creating the named pipe by also including os.O_CREATE and it's not 
clear doing so is even valid (I haven't tested whether it works). You can't 
force a file to behave like a named pipe by passing that value to the 
os.OpenFile function and that flag isn't needed to open an existing named 
pipe. The os.ModeNamedPipe constant is meant to be used when testing the 
file mode returned by os.Stat. You would normally use the unix.Mkfifo 
function to create a named pipe.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/dea55bb6-c962-4614-8ebe-21220ff8efc9n%40googlegroups.com.

Re: [go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

['TheDiveO' via golang-nuts]

Please note that the unit test I linked to tests on the "writing end" of 
the pipe. In fact, I wrote in the OP right in my first sentence:

> *Hi, I need to detect on the producer side (writing end) of a named pipe 
when the consumer (reading end) has disconnect/closed. *

I'm afraid, but you are not reproducing the situation I was asking for and 
provided a unit test for.

On Sunday, December 17, 2023 at 6:16:45 AM UTC+1 Kurtis Rader wrote:

I should probably clarify that my copy of TheDiveO code simply added the 
following function and replaced the use of github.com/sirupsen/logrus with 
println.

func main() {
f, err := os.OpenFile("p", os.O_RDONLY, 0)
if err != nil {
println("open p", err.Error())
os.Exit(1)
}
println("fifo opened")
WaitTillBreak(f)
}


-- 
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/badca3c7-f532-4bf2-8f0d-3085eeb77aa4n%40googlegroups.com.

Re: [go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

['TheDiveO' via golang-nuts]

   
   - implementation using unix.Select (btw, I explicitly mentioned 
   unix.Select in my OP): 
   
https://github.com/siemens/cshargextcap/blob/2f45f96748e835f0fef4cf429ca27f92a6c60a33/pipe/checker_notwin.go
   - unit test producing this behavior, differing between Linux and macos: 
   
https://github.com/siemens/cshargextcap/blob/2f45f96748e835f0fef4cf429ca27f92a6c60a33/pipe/checker_notwin_test.go

That should suffice as a minimal example. "go test -v ./pipe -ginkgo.v" 
gives details as the test progresses.

On Saturday, December 16, 2023 at 6:40:01 AM UTC+1 Kurtis Rader wrote:

> Do not make us guess what your code looks like and which packages you are 
> using. I'm guessing you are using 
> https://pkg.go.dev/golang.org/x/sys/unix#Select but I shouldn't have to 
> do so. You should be able to show us a minimal reproducible example of code 
> that illustrates a problem of this nature.
>
> On Fri, Dec 15, 2023 at 7:13 AM 'TheDiveO' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> Hi, I need to detect on the producer side (writing end) of a named pipe 
>> when the consumer (reading end) has disconnect/closed. This detection needs 
>> to work "quickly" even if the producer doesn't produce anything; thus, 
>> SIGPIPE wouldn't help.
>>
>> On Linux, when using unix.Select() on the fd of the producer's writing 
>> end of the named pipe, the fd becomes readable only upon the consumer 
>> disconnecting.
>>
>> On macos, unix.Select indicates that the writing end fd becomes readable 
>> as soon as the producer writes(!) data. But it never reports the fd 
>> becoming readable upon the consumer disconnecting.
>>
>> I'm opening both named pipe ends as follows (in different processes):
>>
>> os.OpenFile(fifoname, os.O_WRONLY, os.ModeNamedPipe)
>> os.OpenFile(fifoname, os.O_RDONLY, os.ModeNamedPipe)
>>
>>- is there something to know of in Go's runtime/stdlib (and 
>>especially the poller) that might interfere with my usage of unix.Select 
>> on 
>>an ordinary *os.File?
>>- how can I detect the consumer disconnecting on macos?
>>
>> -- 
>> 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/3f8df371-4fda-44e2-8acb-b0743fb6b27en%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/3f8df371-4fda-44e2-8acb-b0743fb6b27en%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/dbcb1746-8984-406e-8211-ec60ce56d748n%40googlegroups.com.

[go-nuts] unix.Select with fd gotten from named pipe on macos behaves differently compared to linux

['TheDiveO' via golang-nuts]

Hi, I need to detect on the producer side (writing end) of a named pipe 
when the consumer (reading end) has disconnect/closed. This detection needs 
to work "quickly" even if the producer doesn't produce anything; thus, 
SIGPIPE wouldn't help.

On Linux, when using unix.Select() on the fd of the producer's writing end 
of the named pipe, the fd becomes readable only upon the consumer 
disconnecting.

On macos, unix.Select indicates that the writing end fd becomes readable as 
soon as the producer writes(!) data. But it never reports the fd becoming 
readable upon the consumer disconnecting.

I'm opening both named pipe ends as follows (in different processes):

os.OpenFile(fifoname, os.O_WRONLY, os.ModeNamedPipe)
os.OpenFile(fifoname, os.O_RDONLY, os.ModeNamedPipe)

   - is there something to know of in Go's runtime/stdlib (and especially 
   the poller) that might interfere with my usage of unix.Select on an 
   ordinary *os.File?
   - how can I detect the consumer disconnecting on macos?

-- 
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/3f8df371-4fda-44e2-8acb-b0743fb6b27en%40googlegroups.com.

[go-nuts] Re: go build at most 37x slower in 1.21.5 vs 1.19.3

['TheDiveO' via golang-nuts]

IIRC the stdlib isn't delivered precompiled anymore since 1.20. You should 
make sure to have layer caching in place in case you want to tune your 
pipelines. You can do a "go build std" IIRC.

On Wednesday, December 13, 2023 at 4:40:21 PM UTC+1 Lib Martinito wrote:

>
> [image: Screenshot 2023-12-13 at 8.05.38 PM.png][image: Screenshot 
> 2023-12-13 at 8.13.47 PM.png]
>
> It's 37x slower on go 1.21.5 to build the first time. Do anyone of you 
> know why that is? Should I raise a bug instead?
>
> What I compiled was only a simple "hello world!" using println. The 
> environments are docker images - go-1.19:alpine and go-1.21:alpine 
> respectively.
>
> It would be appreciated if anyone could shed some light around 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/735e807c-2fad-4dd8-893e-14428e7e28fen%40googlegroups.com.

[go-nuts] Re: detecting deleted file that is still open and appending without error in Go?

['TheDiveO' via golang-nuts]

You basically already showed how to do it on Linux: inside your Go prog, 
you know the file descriptor number (f.Fd()). Then do an 
os.Readlink(fmt.Sprintf("/proc/self/fd/%d", f.Fd()) and check the result 
(if no error) with strings.HasSuffix(link, "(deleted)").

On Sunday, December 10, 2023 at 5:41:00 PM UTC+1 Jason E. Aten wrote:

> I'm debugging a weird situation where my open binary log file
> has been deleted and replaced by an
> identical copy by my doing a git commit (and maybe git rebase)
> on it.  The Go process is still running, still has the origional
> file handle open, and is still "writing" to the 
> deleted log file to no effect (no further appends are happening).
>
> The /proc listing shows the Go process's file handle to the file as 
> (deleted). See below.
>
> My question is: is there a way to have the Go process detect if the file 
> it is writing to has been deleted by another process (git in this case) so 
> that attempting to append to the file is no longer effective?  This example 
> is on Linux on xfs filesystem; Ubuntu 18.04.  I suppose I could Sync then 
> Stat the file before and after and if it is not growing by the appropriate 
> number of bytes, take corrective action... but I wonder if there is a more 
> elegant way?
>
> go version go1.21.2 linux/amd64
>
>   Fortunately I noticed this before too much had gone missing to the 
> binary log, and was able to confirm that it was going missing by comparing 
> to a textual version of the log that I also keep.
>
> I would be happy to check the file descriptor on each append operation, to 
> ensure that the logging will be effective. But writes are succeeding to the 
> deleted file: I am checking the error returned by the os.File.Write() 
> operation, and it is always nil indicating no error on the Write.
>
> ~~~
>
> myuser*@*host* /proc/94913/fd $* *ls -al*
>
> total 0
>
> dr-x-- 2 myuser myuser  0 Dec 10 10:02 *.*
>
> dr-xr-xr-x 9 myuser myuser  0 Dec 10 10:02 *..*
>
> lrwx-- 1 myuser myuser 64 Dec 10 10:02 *0* -> /dev/pts/8
>
> lrwx-- 1 myuser myuser 64 Dec 10 10:02 *1* -> /dev/pts/8
>
> lrwx-- 1 myuser myuser 64 Dec 10 10:02 *10* -> 
> 'anon_inode:[eventpoll]'
>
> ...
>
> lrwx-- 1 myuser myuser 64 Dec 10 10:02 *8* -> 
> '/mnt/b/data/logs/my.binarylog.host (deleted)' ## << how to detect this?
>
> ...
>
> myuser*@*host* /proc/94913/fd $* *mount|grep mnt/b*
>
> /dev/sdb on /*mnt/b* type xfs 
> (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
>
> myuser*@*host* /proc/94913/fd $* *uname -a*
>
> Linux host 5.4.0-126-generic #142~18.04.1-Ubuntu SMP Thu Sep 1 16:25:16 
> UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
>
> myuser*@*host* /proc/94913/fd $* *cat /etc/lsb-release *
>
> DISTRIB_ID=Ubuntu
>
> DISTRIB_RELEASE=18.04
>
> DISTRIB_CODENAME=bionic
>
> DISTRIB_DESCRIPTION="Ubuntu 18.04.5 LTS"
>
> myuser*@*host* /proc/94913/fd $*
>
> ~~~
>

-- 
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/ff3512f0-8282-4249-91be-b45cacaf73f0n%40googlegroups.com.

Re: [go-nuts] Re: Clace: Secure web application development platform using Starlark

[TheDiveO]

Unfortunatelly, "okay" hasn't been tested in court yet and especially with 
HashiCorp breaking bad you surely have the deep pockets to see this through?

On Tuesday, October 31, 2023 at 4:12:13 AM UTC+1 Dan Kortschak wrote:

> On Mon, 2023-10-30 at 18:43 -0700, Jason E. Aten wrote:
> > I'm surprised by that claim. I seriously doubt, from reading the
> > licenses, that you can legally use the Apache2 license, since
> > it removes the MPL requirements; which the MPL forbids you from
> > doing.  
> > 
>
> The Mozilla FAQ https://www.mozilla.org/en-US/MPL/2.0/FAQ/ appears to
> think it's OK.
>
> > Q13: May I combine MPL-licensed code and BSD-licensed code in the
> > same executable program? What about Apache?
> >
> > Yes to both. Mozilla currently does this with BSD-licensed code. For
> > example, libvpx, which is used in Firefox to decode WebM video, is
> > under a BSD license.
>
>

-- 
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/c2e1d2a4-e0c4-4b8b-baea-d78132db2972n%40googlegroups.com.

[go-nuts] Re: Clace: Secure web application development platform using Starlark

[TheDiveO]

sadly, OpenDoufu(*) is the epitaph of HashiCorp breaking bad. So that 
go-plugin package is a no-go now (pun intended).

(*) I can't get myself using the British Empire misspelling of Standard 
Chinese (putonghua). And don't call that Ma... either.

On Monday, October 30, 2023 at 7:54:50 PM UTC+1 Jason E. Aten wrote:

> I would just be aware that using software that is MPL licensed,
>
> https://github.com/hashicorp/go-plugin/blob/main/LICENSE
>
> means that nobody with commercial aspirations will touch your stuff. In 
> practice, that means relatively little adoption.

-- 
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/742c67bd-53f7-4df4-abb3-0e1583553a1cn%40googlegroups.com.

[go-nuts] Re: URL variables with net/http

[TheDiveO]

stdlib only with upcoming 1.22 which isn't yet released, see 
https://eli.thegreenplace.net/2023/better-http-server-routing-in-go-122/

gorilla mux is another 3rd party muxer with variable support 
https://github.com/gorilla/mux

the "best" way using only stdlib mux is to parse the path and extract the 
variable yourself. otherwise, wait for 1.22. or use an existing 3rd party 
module.

On Thursday, October 19, 2023 at 1:27:59 PM UTC+2 Dejan Duh wrote:

> Hi everyone. I'm building an api with net/http and I'm having trouble 
> with url variables. How can I get the url variables form the url in the 
> REST way. Example, if I have a url like "http:/localhost:3000/users/:id". 
> I want to get the user with the id given from the url. What is the best 
> way to get the id using only the standart lib? 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/9b1030a6-1bc3-4b60-8e99-d98cd760beddn%40googlegroups.com.

[go-nuts] Re: go list fails, how do I clear "-mod=readonly"

[TheDiveO]

looks like 
https://stackoverflow.com/questions/76495283/go-list-command-prints-hint-i-dont-understand

On Monday, October 16, 2023 at 7:25:46 PM UTC+2 Pat Farrell wrote:

> On Monday, October 16, 2023 at 1:22:42 PM UTC-4 TheDiveO wrote:
>
> go mod tidy
>
>
> I've done that, and while it just executes quietly, I don't see how that 
> addresses the
> issue that 'go list' fails to show me modules that have been updated.
>
> thanks
> pat
>

-- 
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/2007397c-16f4-48fc-9d28-8bec15b78956n%40googlegroups.com.

[go-nuts] Re: go list fails, how do I clear "-mod=readonly"

[TheDiveO]

go mod tidy

On Monday, October 16, 2023 at 7:20:13 PM UTC+2 Pat Farrell wrote:

> i'm running
> go version go1.20.5 linux/amd64 
>
> when I attempt to run 'go list' to find any updated to dependant
> modules, it fails.
>
> go list -m -u all
> go: updates to go.sum needed, disabled by -mod=readonly
>
> I've checked, and my go.mod and go.sum files are 777
>
> -rwxrwxrwx 1 pfarrell pfarrell  408 Oct  1 10:37 go.mod*
> -rwxrwxrwx 1 pfarrell pfarrell 3025 Oct  1 10:37 go.sum*
>
> What am I doing wrong?
> How do I get a list of updated modules?
>
> thanks
> pat
>

-- 
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/8e6acbd0-f758-4a2a-9614-bbce80b6aea3n%40googlegroups.com.

Re: [go-nuts] the environment variable GOROOT doesn't load for work with go

[TheDiveO]

please simply follow the official installation instructions here, 
https://go.dev/doc/install, and select the Windows tab. This will set up 
everything correctly, avoiding the trouble you might have gotten into by 
installing individual bits and pieces into directories there they do not 
belong to (windows system, etc). Please note that there are multiple 
binaries required for a working toolchain.

On Saturday, October 7, 2023 at 4:24:54 PM UTC+2 Dorian ROSSE wrote:

> hello,
>
>
>
> on system windows there are both kind of installing to set up and put : 
>
> 1) download and install the go exe for install in the default folder 
> c:/programs
> 2) download and install the sources files of go for put it in 
> c:/windows/system32 for the GOROOT
> 3) download and install the sources files of go for put it in the current 
> folder of the user so for my install this is the following : 
> c/:users/ghisl/ thus this is GOPATH
> 4) copy and paste go.exe and gofmt.exe from c:/programs/go/bin/ for create 
> the folder /bin in both sources files GOROOT and GOPATH
> 5) finally my GOROOT is c:/windows/system32/go/bin/go.exe and my GOPATH is 
> c/:users/ghisl/go/bin/go.exe
>
> after this explaining i wait a real help for my problem therefore thanks 
> you in advance to help myself fully use my GOROOT and my GOPATH,
>
> Regards.
>
>
> Dorian ROSSE.
> Le 06/10/2023 à 20:41, Roland Müller a écrit :
>
> Hello,
>
> the path of the go.exe binary is quite suspicious. C:\Windows is the 
> windows system folder and system32 - as far as I know - contains some 
> partly legacy stuff.
>
> Valid locatios for programs are "C:\Program Files" or "C:\Program 
> Files(32)" (out of my memory - since I am sitting in front of a Linux box 
> @moment)
>
> To what locations do your GOROOT and GOPATH put?
>
> BR,
>
> Roland 
> On 10/6/23 18:05, Dorian ROSSE wrote:
>
> hello, 
>
>
> *the environment variable GOROOT doesn't load* for work with go so i 
> can't use any go thus the environment set and put in 
> *c:/windows/system32/go/bin/go.exe** doesn't work,*
>
> *thanks you in advance to brig to myself the fully using of my variable 
> envirnments GOROOT and GOPATH,*
>
> regards.
>
>
> Dorian ROSSE.
> -- 
> 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/ca6c5b7a-b4c8-46cf-b955-f51bceb746a6n%40googlegroups.com
>  
> 
> .
>
> -- 
>
> 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/QQLKTkp-gqk/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 
> https://groups.google.com/d/msgid/golang-nuts/bf68319f-b104-3c97-57c2-9c97fd4ac1b3%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/b37f8abb-9164-46df-b8bf-3af38467b1c1n%40googlegroups.com.

Re: [go-nuts] Re: Is it expected that signal.NotifyContext() changes the execution thread?

[TheDiveO]

  Weeell, I had unit tests running without hiccup on a wide range of 
devices, and only a year later some of them started to fail with a 
seemingly "leaked" (non-restored) namespace. The question here and the 
suggested issue then introduced me to the "wedged"  M0 thread.  It works 
until it doesn't.   
On Sunday, October 1, 2023 at 8:37:08 AM UTC+2 Kurtis Rader wrote:

> On Sat, Sep 30, 2023 at 12:23 AM TheDiveO  wrote:
>
>> Did you explicitly lock the initial OS thread, aka M0, to the 
>> main/initial go routine by calling runtime.LockOSThread() from main or an 
>> init func? I suspect you were lucky in the past, but I might be wrong.
>>
>
> No, I did not explicitly lock the initial thread using 
> runtime.LockOSThread(). However, I have run the program hundreds of 
> times, and for tens of hours, while working on it and not once, before 
> introducing signal.NotifyContext()did I see an instance of the gocv 
> package complaining about the thread it was running on not being the main 
> thread. It is certainly possible I have simply been lucky but that seems 
> unlikely since it fails every single time I run it when using 
> signal.NotifyContext().
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/43bd9897-222a-4c7e-8431-bf015b7ed5a9n%40googlegroups.com.

Re: [go-nuts] About variables have per-iteration scope instead of per-loop scope

[TheDiveO]

actually, language changes happen all the time. In German, there is quite 
some "misuse" esp. by journos that change or follow change in German, not 
necessarily improving clearness. In Go, so far changes were for the better 
and I'm glad to change my learning if it benefits the mass of my fellow 
developers.   
On Saturday, September 30, 2023 at 11:59:36 PM UTC+2 Victor Giordano wrote:

> *Alex*, your second reply was even more powerful in terms of feelings and 
> ideas to work with in order to embrace the change. Probably I'm 
> struggling with an unexpected change... and let's see with time how it goes.
>
> *DiveO*, thanks you very mucho for your insight... I see your point. For 
> me... the matter would be like ¿ what happens if a given language you know 
> well suddenly changes the rules for implicit or tacit subject? Where the 
> subject would be the variable and the rules for implicit or tacit subject 
> would be the scope. People may wonder. Again... I guess time will answer us 
> all.
>
> Greetings
>
> El sábado, 30 de septiembre de 2023 a las 16:55:24 UTC-3, TheDiveO 
> escribió:
>
>> Switching between human languages, such as for me, German and English, 
>> required me to learn English at a level that I think in it. Even with their 
>> shared ancestry, I don't expect these languages to use the same structure 
>> and concepts, like loop variable scoping. Admittedly, Go doesn't allow me 
>> to switch in and out into a different language mid sentence, which in human 
>> languages sometimes causes quite some hilarious reactions with my 
>> colleagues. 
>>
>> On Saturday, September 30, 2023 at 6:35:54 PM UTC+2 Victor Giordano wrote:
>>
>>> Thanks Alex, your insight was very helpful.
>>>
>>> Allow me to share the feeling I have => I still struggle a little in my 
>>> mind... I craft web fronts in javascript, and back in golang (and scala or 
>>> java). With this change I will have two different scoping rules... and I 
>>> feel I don't need it (because I learn how to use it well) nor ask for 
>>> them... but it is okay.. changes work that way. The bottom line is: I was 
>>> already comfortable with the language scope rules.
>>>
>>> El sáb, 30 sept 2023 a las 12:37, Axel Wagner (<
>>> axel.wa...@googlemail.com>) escribió:
>>>
>>>> This has come up during the discussion already. I don't know enough 
>>>> about other languages to speak with confidence, but apparently there 
>>>> already is precedent for this and/or some languages are at least 
>>>> considering making a similar change.
>>>>
>>>> Note that scoping rules already vary between languages - in some cases, 
>>>> pretty widely. For example, Python is not block scoped - this works:
>>>> def f():
>>>> if True:
>>>> x = 42
>>>> print(x)
>>>> And Perl has dynamic scoping, where variables can be scoped to a call 
>>>> stack, instead of any lexical element of the source code. Javascript, as 
>>>> far as I know, is pretty notorious for having extremely idiosyncratic 
>>>> scoping rules (e.g. it is a common confusion how `this` is scoped in 
>>>> different contexts) and also has several different kinds of declarations 
>>>> with AFAIK slightly different scoping rules.
>>>> In C, a symbol is only scoped to a single file (as far as the processor 
>>>> is concerned) and in there, only from its declaration onwards, while in 
>>>> Go, 
>>>> a package-scoped definition can appear in any file of any package. And 
>>>> speaking of C, it doesn't have closures at all, so the scoping rules of 
>>>> loop variables are *already* very different.
>>>>
>>>> So I think the case that you *currently* don't have to be aware of how 
>>>> a language is using scoping is pretty vastly overstated. What's more, the 
>>>> majority of programs won't actually be affected by this - and for those 
>>>> that are, it seems that empirically, the new rules will align more closely 
>>>> with what people expect subconsciously.
>>>>
>>>> I don't think you should worry too much. Run your tests with the new 
>>>> loop variable semantics in Go 1.21 to see if everything still works. Most 
>>>> likely, it will - or you will discover a bug in your current code.
>>>>
>>>> On Sat, Sep 30, 2023 at 4:58 PM Victor Giordano  
>>>> wrote:
>>>>
>>>>> Hi gophers! How you doing?
>>>>>
>&g

Re: [go-nuts] About variables have per-iteration scope instead of per-loop scope

[TheDiveO]

Switching between human languages, such as for me, German and English, 
required me to learn English at a level that I think in it. Even with their 
shared ancestry, I don't expect these languages to use the same structure 
and concepts, like loop variable scoping. Admittedly, Go doesn't allow me 
to switch in and out into a different language mid sentence, which in human 
languages sometimes causes quite some hilarious reactions with my 
colleagues. 

On Saturday, September 30, 2023 at 6:35:54 PM UTC+2 Victor Giordano wrote:

> Thanks Alex, your insight was very helpful.
>
> Allow me to share the feeling I have => I still struggle a little in my 
> mind... I craft web fronts in javascript, and back in golang (and scala or 
> java). With this change I will have two different scoping rules... and I 
> feel I don't need it (because I learn how to use it well) nor ask for 
> them... but it is okay.. changes work that way. The bottom line is: I was 
> already comfortable with the language scope rules.
>
> El sáb, 30 sept 2023 a las 12:37, Axel Wagner () 
> escribió:
>
>> This has come up during the discussion already. I don't know enough about 
>> other languages to speak with confidence, but apparently there already is 
>> precedent for this and/or some languages are at least considering making a 
>> similar change.
>>
>> Note that scoping rules already vary between languages - in some cases, 
>> pretty widely. For example, Python is not block scoped - this works:
>> def f():
>> if True:
>> x = 42
>> print(x)
>> And Perl has dynamic scoping, where variables can be scoped to a call 
>> stack, instead of any lexical element of the source code. Javascript, as 
>> far as I know, is pretty notorious for having extremely idiosyncratic 
>> scoping rules (e.g. it is a common confusion how `this` is scoped in 
>> different contexts) and also has several different kinds of declarations 
>> with AFAIK slightly different scoping rules.
>> In C, a symbol is only scoped to a single file (as far as the processor 
>> is concerned) and in there, only from its declaration onwards, while in Go, 
>> a package-scoped definition can appear in any file of any package. And 
>> speaking of C, it doesn't have closures at all, so the scoping rules of 
>> loop variables are *already* very different.
>>
>> So I think the case that you *currently* don't have to be aware of how a 
>> language is using scoping is pretty vastly overstated. What's more, the 
>> majority of programs won't actually be affected by this - and for those 
>> that are, it seems that empirically, the new rules will align more closely 
>> with what people expect subconsciously.
>>
>> I don't think you should worry too much. Run your tests with the new loop 
>> variable semantics in Go 1.21 to see if everything still works. Most 
>> likely, it will - or you will discover a bug in your current code.
>>
>> On Sat, Sep 30, 2023 at 4:58 PM Victor Giordano  
>> wrote:
>>
>>> Hi gophers! How you doing?
>>>
>>> In my work we recently discuss with a buddy about this article 
>>> . I need to talk about this
>>>
>>> I appreaciate that golang makes a lot of effort on this. Working with 
>>> clousures cames with perils and the go vet tool emiting a warning is a 
>>> great thing.
>>>
>>> Althought I do not think that chaning language semantics is something 
>>> 100% good,  see my point: As long I use several languages for making a 
>>> system this "scope rule" will mismatch with other languajes, for example, 
>>> javascript.
>>>
>>> So from now onwards I shall be aware that for loops have variables 
>>> scopes in one fashion in Golang and in other fashion in another 
>>> languages... so at the end of the day, I feel like is adding some burden. 
>>> If for development we can use a single and sole language (Sauron don't read 
>>> this :P !) I would think this change is good, but that is not the case in 
>>> now-a-days. I try to think that with time, perhaps other languages evolves 
>>> it this way... but.. ¿what if I wanna have my "for loop" with legacy scope 
>>> (block scope, not per iteration scope)? 
>>>
>>> So... I expect to the readers to talk with me, showing what they see and 
>>> feel. Is not my intention to generate hard feelings at all. I'm a person 
>>> that work crafting system in group with others.. I have had terrible 
>>> nightmares working with Scala where implicits and invoking methods as they 
>>> were feilds were terrible ideas for working in group (perhaps not if you 
>>> work solo). And this feature recalls me those feelings.
>>>
>>> Greetings
>>> Víctor.
>>>
>>> -- 
>>> 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 
>>> 

[go-nuts] Re: Is it expected that signal.NotifyContext() changes the execution thread?

[TheDiveO]

Did you explicitly lock the initial OS thread, aka M0, to the main/initial 
go routine by calling runtime.LockOSThread() from main or an init func? I 
suspect you were lucky in the past, but I might be wrong. 

On Saturday, September 30, 2023 at 5:20:47 AM UTC+2 Kurtis Rader wrote:

> I was rewriting a program I originally wrote in Python many years ago that 
> uses OpenCV. I wanted to make it possible to cleanly terminate the Go 
> version when SIGINT was sent to the process; e.g., by pressing Ctrl-C. So I 
> changed how the context was created from this in the main() function:
>
> ctx, cancel := context.WithCancel(context.Background())
>
> to this:
>
> ctx, cancel := signal.NotifyContext(context.Background(), syscall.SIGINT)
>
> However, that appeared to change the thread that subsequent statements in 
> main() 
> ran on. I say this because the gocv.NewWindow() function (from package 
> gocv.io/x/gocv and also executed in main()) started complaining that it 
> was no longer running on the main thread. The signal package documentation 
> makes no mention of this side-effect. Am I missing something obvious? 
> Should I open an issue suggesting this side-effect be explicitly 
> documented? Or, is this side-effect a bug?
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/f3653447-baff-4afc-8747-9d47bc332befn%40googlegroups.com.

Re: [go-nuts] Re: Help with WASM performance

[TheDiveO]

The cynic in me notes the use of "aims".

IIRC is single-threaded, do you know if your code is single- threaded too, 
or does it use several core for decoding? 

On Saturday, September 23, 2023 at 7:37:13 AM UTC+2 Stephen Illingworth 
wrote:

> Comparison to native speeds is the key attraction of WASM. From the go.org 
> blog published 10 days ago: https://go.dev/blog/wasi
>
> "WebAssembly (Wasm)  is a binary instruction 
> format originally designed for the web. It represents a standard that 
> allows developers to run high-performance, low-level code directly in web 
> browsers at near-native speeds."
>
> And from the front page of webassembly.org
>
> "The Wasm stack machine  is 
> designed to be encoded in a size- and load-time-efficient binary format 
> . WebAssembly aims to 
> execute at native speed by taking advantage of common hardware 
> capabilities 
> 
>  
> available on a wide range of platforms."
>
>
> On Saturday, 23 September 2023 at 01:18:26 UTC+1 Robert Engels wrote:
>
>> Typically WASM performance is compared to JavaScript - ie. faster than 
>> JavaScript usually 1.5-10x. 
>>
>> People don’t usually compare WASM with native apps. 
>>
>> On Sep 22, 2023, at 7:04 PM, Robert Engels  wrote:
>>
>> 
>>
>> WASM goes through the browser - so it is very different. Are you using 
>> OpenGL or similar?
>>
>> On Sep 22, 2023, at 3:44 PM, Stephen Illingworth  
>> wrote:
>>
>> 
>> I'm comparing the results of a program compiled for AMD64 and WASM 
>> architectures. The code is the same except for the change of architecture. 
>> The size of the difference in performance is unexpected to me but maybe 
>> it's normal.
>>
>> On Friday, 22 September 2023 at 20:16:20 UTC+1 Robert Engels wrote:
>>
>>> When you say negative performance are you talking about a native app 
>>> running directly on the hardware what are you referring to exactly
>>>
>>> On Sep 22, 2023, at 1:03 PM, Stephen Illingworth  
>>> wrote:
>>>
>>> 
>>>
>>> I've been thinking some more about this problem this week. I found the 
>>> performance profiler in Chrome and can see that the each frame is taking 
>>> longer than the required 16.7ms to create. The duration for each frame is 
>>> more like 100ms. The native performance meanwhile can reach about 7ms. I 
>>> expected a drop in performance but not that much.
>>>
>>> If anyone can offer any insight or if these figures seem wrong then I'd 
>>> love to take some advice.
>>>
>>> Regards
>>> Stephen
>>>
>>> On Saturday, 16 September 2023 at 09:02:34 UTC+1 Stephen Illingworth 
>>> wrote:
>>>
 I have tried running it in Firefox and Chromium. The webserve.sh script 
 in the ebiten_test folder runs a small httpd server to serve up the binary 
 to the browser.



 On Saturday, 16 September 2023 at 08:45:52 UTC+1 Brian Candler wrote:

> What WASM runtime are you using to execute the code?

 -- 
>>> 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/d8926ffb-9ca3-48ac-aabc-76a8a43947dan%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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/1123a2da-3862-4da8-baf5-bc67dd2b7e6en%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/50986e53-e17e-4a84-a1d5-d3b30789767cn%40googlegroups.com.

Re: [go-nuts] x/mobile: avoid to catch sigabort signal

[TheDiveO]

CMAC_resume might be something from here, IIRC Darwin's OpenBSD 
anchestry: https://man.openbsd.org/CMAC_Init.3

On Monday, September 11, 2023 at 8:17:44 AM UTC+2 Kurtis Rader wrote:

> On Sun, Sep 10, 2023 at 10:41 PM Danilo bestbug  
> wrote:
>
>> Hey Robert,
>> The problem is not reproducible in our test env but it occours on final 
>> user. To make thing thougher is not even an application we develop directly 
>> but is from one of our reseller, so we don't have direct access to the rest 
>> of the codebase. Again I want to stress the main point of my request of 
>> help: if this behavior is caused by some corner case to have a GO runtime 
>> as third party dependencies instead of be a complete executable I would 
>> like to understand if we can do something better to avoid to have this 
>> stacktrace that are meaningless to us. Otherwise if this is a correct 
>> behavior from GO runtime, I think we still have a problem because usually 
>> the GO stacktrace are pretty clear about what is happening (and hence what 
>> to do to fix it) but not in this case.
>>
>
> When you say "instead of be a complete executable" that suggests to me 
> that a plugin is being used. I realize that English is not your native 
> language but precision is important for this type of issue. Even if a 
> plugin is not being used everything you have written suggests the problem 
> is with your FFI code. In particular, issue 
> https://github.com/golang/go/issues/61632 implies that a FFI function 
> named `CMAC_resume` is calling Go code that detects its stack has been 
> corrupted. That causes the Go runtime to raise SIGABRT to crash the 
> program. So what does `CMAC_resume` do? Also, in this type of situation if 
> you can't arrange for a core dump to be generated it is going to be very 
> difficult to do a root cause analysis. Especially if you can't instrument 
> the Cgo code that is causing the problem with debugging logging statements.
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/07e97b35-1bf2-4fe6-b739-7f97ce2fd87fn%40googlegroups.com.

Re: [go-nuts] x/mobile: avoid to catch sigabort signal

[TheDiveO]

Maybe this SO Q with A might also help with further details: 
https://stackoverflow.com/questions/47869988/how-does-cgo-handle-signals

On Friday, September 8, 2023 at 11:38:38 PM UTC+2 Danilo bestbug wrote:

> Ehy Ian, thanks for the response. Apology if I was not clear, I try to 
> explain in a different way but it's hard for me too since I'm not 100% 
> confident about what it's happening here exactly, I'm tring to follow the 
> trace but any feedback is more than welcome.
> The problem I'm facing is the following: I've a small utility written in 
> GO and integrated in an app iOS as SDK. At the moment if I've undestood 
> correctly from the thread I've linked the GO runtime are cacthing a 
> sigabort signal that are not from the GO stack but it's generated from 
> another thread with the result that it's look like the GO runtime is 
> crashing from the apple report.
>
> If this behavior of the GO runtime is legittime when GO is an executable 
> in my context is a problem since the developer follow the GO stack instead 
> of the other thread stack.
>
> Now what I'm try to understand if this behavior can be somehow change, and 
> if so how should I do?
> Il giorno venerdì 8 settembre 2023 alle 22:34:07 UTC+2 Ian Lance Taylor ha 
> scritto:
>
>> On Thu, Sep 7, 2023 at 11:41 PM Danilo bestbug 
>>  wrote: 
>> > 
>> > Some weeks ago I've opened a possible bug on github and the only 
>> response I received is a reference to 
>> > "This looks like the program (the Go runtime, or not) intentionally 
>> crashing when it is already in a bad condition, like receiving an unhandled 
>> signal on a non-Go thread." 
>> > 
>> > I would like to stop the GO system to do this kind of behaviour 
>> (intercepting unhandled signal) otherwise the team who work on the crash 
>> keep searching the problem on the GO thread crashed instead of elsewhere. 
>> This for us is a big problem and I love if someone can help me to address 
>> this matter! 
>>
>> I'm sorry, I don't really understand what you are asking. What I can 
>> tell you is that signal handling in Go programs is managed via the 
>> os/signal package. See https://pkg.go.dev/os/signal. 
>>
>> 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/a417062f-ddac-4e64-bbf5-037fcdf64ab6n%40googlegroups.com.

Re: [go-nuts] x/mobile: avoid to catch sigabort signal

[TheDiveO]

You seem to be barking up the wrong tree, at least for the moment. Maybe 
your team may want to learn more about cgo and by sheer coincidence there's 
a blog post  https://shane.ai/posts/cgo-performance-in-go1.21/ that might 
serve as a starting point, with one or two pointers to go further.  I also 
don't understand why you are so keen on the SIGABRT catch, when there is 
probably a much deeper problem in your code or the libs you use, s others 
already told you.  Trying to hide the signal under the carpet isn't the 
best strategy to my limited understanding, as your app is already in such a 
bad state that the runtime has to fail.   
On Friday, September 8, 2023 at 11:38:38 PM UTC+2 Danilo bestbug wrote:

> Ehy Ian, thanks for the response. Apology if I was not clear, I try to 
> explain in a different way but it's hard for me too since I'm not 100% 
> confident about what it's happening here exactly, I'm tring to follow the 
> trace but any feedback is more than welcome.
> The problem I'm facing is the following: I've a small utility written in 
> GO and integrated in an app iOS as SDK. At the moment if I've undestood 
> correctly from the thread I've linked the GO runtime are cacthing a 
> sigabort signal that are not from the GO stack but it's generated from 
> another thread with the result that it's look like the GO runtime is 
> crashing from the apple report.
>
> If this behavior of the GO runtime is legittime when GO is an executable 
> in my context is a problem since the developer follow the GO stack instead 
> of the other thread stack.
>
> Now what I'm try to understand if this behavior can be somehow change, and 
> if so how should I do?
> Il giorno venerdì 8 settembre 2023 alle 22:34:07 UTC+2 Ian Lance Taylor ha 
> scritto:
>
>> On Thu, Sep 7, 2023 at 11:41 PM Danilo bestbug 
>>  wrote: 
>> > 
>> > Some weeks ago I've opened a possible bug on github and the only 
>> response I received is a reference to 
>> > "This looks like the program (the Go runtime, or not) intentionally 
>> crashing when it is already in a bad condition, like receiving an unhandled 
>> signal on a non-Go thread." 
>> > 
>> > I would like to stop the GO system to do this kind of behaviour 
>> (intercepting unhandled signal) otherwise the team who work on the crash 
>> keep searching the problem on the GO thread crashed instead of elsewhere. 
>> This for us is a big problem and I love if someone can help me to address 
>> this matter! 
>>
>> I'm sorry, I don't really understand what you are asking. What I can 
>> tell you is that signal handling in Go programs is managed via the 
>> os/signal package. See https://pkg.go.dev/os/signal. 
>>
>> 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/4305ee4c-664a-43ff-b1d8-8e0439f74b91n%40googlegroups.com.

[go-nuts] Re: Would it be possible to make this work in the future?

[TheDiveO]

==?

On Friday, August 25, 2023 at 4:44:02 PM UTC+2 محمد بومنذر wrote:

> Greetings everyone,
>
> I'm writing a parser based on Go's `encoding/xml`, I tried to use the 
> following pattern but it was deemed invalid:
>
> ```
> switch tok := p.tok.(type) {
> case xml.StartElement, xml.EndElement:
> tok.Name.Local == "types"
> }
>
>
> ```
> To me, it'd make sense if it was allowed since both types are structs and 
> both of them share the field `Name` with the subsequent field `Local`.
>

-- 
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/cc07ee40-c590-40e1-a254-88a920451cdfn%40googlegroups.com.

Re: [go-nuts] How to be a good slog module?

[TheDiveO]

While my modules can be used in HTTP handlers, they are also often used 
outside such use cases in other tools. Some modules spawn long-running 
background go routines, others do complex system scanning operations, 
finally returning a complex cyclic information model. What I would like to 
avoid is having to check at every logging call site whether there's a 
logger present or not. Is there some best practice/pattern as to how create 
a default slogger that "does nothing", avoiding having to guard all logging 
call sites? I would like my module consumers to be able to disable logging 
for this module.

On Wednesday, August 23, 2023 at 9:29:31 PM UTC+2 Sean Liao wrote:

> If your modules are mostly structs with lifecycle methods,
> do it like http.Server where the logger is a field (or option passed into 
> the constructor).
>
> Else if your modules take contexts, you could consider having your own 
> WithLogger / FromContext funcs to pass a logger in a context.
> An  advantage of this over a (declined in slog) global context key 
> is that this allows your consumers to target your module with a specific 
> logger.
>
> Finally, you can do the same as log / slog are doing with Default() 
> SetDefault()
> possibly guarded with an RWMutex, or just document that it's unsafe to 
> change after start.
>
> Personal preference is for 1,
> and whether you take a Logger vs Handler 
> would just be if you have a preference for a different frontend.
>
> - sean
>
>
> On Wed, Aug 23, 2023 at 7:09 PM TheDiveO  wrote:
>
>> Up front, I admit my sin of arrogance in giving structured logging the 
>> slip these past years and misusing logrus just as a text logger with 
>> multiple log levels. This question is kind of my atoning...
>>
>> For preparation, I've read through (today's?) Go slog blog post, as well 
>> as some comparably recent 3rd party blog posts about Golangs new slog.
>>
>> What I haven't found (or maybe stubbornly refused to see) is: as I want 
>> to convert my existing consumable modules to slog, how am I going to be a 
>> good citizen, so other modules can easily consume my modules with proper 
>> control over logging? How am I giving my module "customers" control over 
>> per-module (but not necessarily per-package) logging? Are there already 
>> best practises and what are they?
>>
>> While ponding these questions, I would suspect, that creating a 
>> per-module default "slogger" when none has been set in a module's init() 
>> would be a bad idea: due to the order of module initialization, all my 
>> module customers/consumers would end up with the default slogger that 
>> mostly would not fit their needs.
>>
>> Simply exposing a public variable would be either suffering the init 
>> problem, or alternatively, I would create default sloggers that then have 
>> to be garbage collected anyway.
>>
>> And now, Ladies and Gentlemens, show me your consumable slogging please! 
>> I want to learn!
>>
>> -- 
>> 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/cc4f2bcb-4972-4966-b2ff-341f29339d67n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/cc4f2bcb-4972-4966-b2ff-341f29339d67n%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/b68709d2-08ca-40c1-b120-27d0abf10f77n%40googlegroups.com.

[go-nuts] How to be a good slog module?

[TheDiveO]

Up front, I admit my sin of arrogance in giving structured logging the slip 
these past years and misusing logrus just as a text logger with multiple 
log levels. This question is kind of my atoning...

For preparation, I've read through (today's?) Go slog blog post, as well as 
some comparably recent 3rd party blog posts about Golangs new slog.

What I haven't found (or maybe stubbornly refused to see) is: as I want to 
convert my existing consumable modules to slog, how am I going to be a good 
citizen, so other modules can easily consume my modules with proper control 
over logging? How am I giving my module "customers" control over per-module 
(but not necessarily per-package) logging? Are there already best practises 
and what are they?

While ponding these questions, I would suspect, that creating a per-module 
default "slogger" when none has been set in a module's init() would be a 
bad idea: due to the order of module initialization, all my module 
customers/consumers would end up with the default slogger that mostly would 
not fit their needs.

Simply exposing a public variable would be either suffering the init 
problem, or alternatively, I would create default sloggers that then have 
to be garbage collected anyway.

And now, Ladies and Gentlemens, show me your consumable slogging please! I 
want to learn!

-- 
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/cc4f2bcb-4972-4966-b2ff-341f29339d67n%40googlegroups.com.

Re: [go-nuts] Best IDE for GO ?

[TheDiveO]

"That education place" considers thermodynamics to be a cultural issue, see 
their waterseer disaster where MIT even doubled down on not understanding 
physics and thermodynamics at all.

On Sunday, August 20, 2023 at 1:57:22 PM UTC+2 Robert Engels wrote:

> MIT = “that education place” is pretty funny. But you’re spot on. 
>
> On Aug 20, 2023, at 2:51 AM, TheDiveO  wrote:
>
> That education place has never talked to any employer, that's what their 
> list suggests. It's not about the items on this list. It won't ever 
> correct. But it is basically saying that with one or a few more classes 
> you're ready for your job. That's marketing selling. Depending on the job 
> there's need for cheap code producers, or in other jobs for people going 
> where there is no prior art. Totally different coders. But both don't need 
> coders with many classes, either because it's making them expensive or they 
> have gone through the classes to just accumulate useless knowledge they 
> still cannot transfer to new challenges.
>
>
>
> On Saturday, August 19, 2023 at 8:54:38 PM UTC+2 Andrew Harris wrote:
>
>> The kinds of skills and knowledge covered by 
>> https://missing.csail.mit.edu are important and hard to gain from an 
>> IDE. I think that's the badge of competence earned here.
>>
>> On Saturday, August 19, 2023 at 11:21:44 AM UTC-7 Robert Engels wrote:
>>
>> The power of IDEs is the ease of refactoring and integration with other 
>> build tools (git, lint, github/gerrit). If you’d added all of these plugins 
>> to vim - you’ve created your own ide - and it probably pales in comparison 
>> to a real IDE.
>>
>> Using plain vim as a badge of competence was disproven long ago.
>>
>> -- 
>
> 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/78b49e14-d8e4-43eb-a4e0-803ed48d3669n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/78b49e14-d8e4-43eb-a4e0-803ed48d3669n%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/6afd29fb-4215-4942-b104-a96e7a181ca7n%40googlegroups.com.

Re: [go-nuts] Best IDE for GO ?

[TheDiveO]

well, our "(major) engineering orgs" leave the choice of IDE to our devs. 
Devs have different styles, so as long as they meed the demand, who cares.

On Saturday, August 19, 2023 at 11:17:35 PM UTC+2 Robert Engels wrote:

> Reread what I wrote. Vim with autocomplete, etc is not a simple text 
> editor with syntax coloring. 
>
> Still every major software engineering org in the world uses an ide (or 
> multiple). I guess they don’t know what they are doing. 
>
> Btw, Googles current IDE is based on VSCode. 
>
> > On Aug 19, 2023, at 3:24 PM, Jan Mercl <0xj...@gmail.com> wrote:
> > 
> > On Sat, Aug 19, 2023 at 10:06 PM Christian Stewart
> >  wrote:
> > 
> >> Autocomplete and a go language server (gopls) add a ton of speed 
> because you don't need to look up the docs for function and variable names. 
> And go to definition improves speed navigating code significantly.
> > 
> > - Using autocomplete and go-to-definiton does not require VSCode or
> > any other IDE.
> > - I do use autocomplete and go-to-definition. When I said I use no
> > IDE, that does not mean I don't use those features.
> > - The speed of typing/inputting code is overally a rather negligible
> > factor of the total time cost of developing/debugging and maintaining
> > any non-toy project. IOW, it's not a significant metric of
> > productivity.
> > 
> >> But vim-go can do both, so why not just use it?
> > 
> > Because I use govim? ;-)
> > 
> > (But not for my large projects, gopls chokes on them still too often
> > to tolerate it.)
> > 
> > -- 
> > 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/CAA40n-XusymW6gb5OnDa_7QWAWPFSkwKYQMYUm-d7419EZ%2BGkQ%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/8d5b52de-ddee-461a-9ed5-9b0968382d17n%40googlegroups.com.

Re: [go-nuts] Best IDE for GO ?

[TheDiveO]

That education place has never talked to any employer, that's what their 
list suggests. It's not about the items on this list. It won't ever 
correct. But it is basically saying that with one or a few more classes 
you're ready for your job. That's marketing selling. Depending on the job 
there's need for cheap code producers, or in other jobs for people going 
where there is no prior art. Totally different coders. But both don't need 
coders with many classes, either because it's making them expensive or they 
have gone through the classes to just accumulate useless knowledge they 
still cannot transfer to new challenges.

On Saturday, August 19, 2023 at 8:54:38 PM UTC+2 Andrew Harris wrote:

> The kinds of skills and knowledge covered by https://missing.csail.mit.edu 
> are important and hard to gain from an IDE. I think that's the badge of 
> competence earned here.
>
> On Saturday, August 19, 2023 at 11:21:44 AM UTC-7 Robert Engels wrote:
>
> The power of IDEs is the ease of refactoring and integration with other 
> build tools (git, lint, github/gerrit). If you’d added all of these plugins 
> to vim - you’ve created your own ide - and it probably pales in comparison 
> to a real IDE.
>
> Using plain vim as a badge of competence was disproven long ago.
>
>

-- 
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/78b49e14-d8e4-43eb-a4e0-803ed48d3669n%40googlegroups.com.

[go-nuts] Re: Best IDE for GO ?

[TheDiveO]

 Well, the title about something "best" is probably making most skip it. 
Best is highly subjective. Also your list seems to include IDEs that to my 
knowledge don't have Go support at all, but I might be mislead here.  I 
don't understand what seems to be yourreal question at the end,  do you 
want some graphics dependency management? What are you looking for?   
On Saturday, August 19, 2023 at 11:27:34 AM UTC+2 alex-coder wrote:

> Hi All !
> Gophers, there is at least 10 years as GO on a market, Good job !
>
> I found a list of the best IDE and Plugins there:
> https://github.com/golang/go/wiki/IDEsAndTextEditorPlugins
>
> As I remember Java came around 1995 and within 3-4 years several companies 
> developed really great IDEs successful or less to develop commercial 
> project 
> on Java. Here is a list of but I may miss somewhat, sorry, 
> it was relatively a long time ago:
>
> Forte for Java ( Praga, Czech republic)
> VisualCafe (Symantec)
> VisuailAge (IBM)
> JBuilder (Borland)
> Together Control Center (TogetherSoft, Germany)
> Eclipse, and set of commercial IDE on a base on: RSA,RSD,WID and so on 
> (IBM)
>
> appear later:
>
> VS Code ( Microsoft)
> IDEA (JetBrain)
>
> What I'm looking for is the ability to manage dependencies not only in 
> code, 
> but entirely in a project from requirements to deployment.
> The feature should be inbuild into IDE or at least it would be possible 
> to write plugin to implement it.
>
> It is quite possible that I'm missing somewhat here.
> Gophers, may be there is another place where I should look for IDE for GO ?
>
> Thank you.
>

-- 
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/c5a0c843-ad5e-4b1f-9a1a-cfc8f7dbb826n%40googlegroups.com.

Re: [go-nuts] Best IDE for GO ?

[TheDiveO]

Nothing better than an IBM card puncher as my IDE!  
On Saturday, August 19, 2023 at 11:38:33 AM UTC+2 Jan Mercl wrote:

> On Sat, Aug 19, 2023 at 11:27 AM alex-coder  wrote:
>
> > Gophers, may be there is another place where I should look for IDE for 
> GO ?
>
> Unix is my IDE and vim is its prophet.
>
> IME IDEs make programmers write low quality code while enjoying the
> illusion of being "more productive".
>

-- 
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/8c6f75be-1909-4314-83a1-5288f7a6a18an%40googlegroups.com.

Re: [go-nuts] Why is foo in my go.sum file?

[TheDiveO]

test case?

On Friday, August 18, 2023 at 9:18:05 AM UTC+2 Dan Kortschak wrote:

> On Fri, 2023-08-18 at 16:49 +1000, Nigel Tao wrote:
> > The go.sum file in the golang.org/x/image repo has a line that is not
> > another golang.org.x/* module:
> > 
> > github.com/yuin/goldmark v1.4.13/go.mod
> > h1:6yULJ656Px+3vBD8DxQVa3kxgyrAnzto9xy5taEt/CY=
> > 
> > 
> https://github.com/golang/image/blob/2b687b56714d59d061135c735913a64fe2b70778/go.sum#L1
> > 
> > That line was added in a go...@golang.org authored commit last
> > October:
> > 
> https://github.com/golang/image/commit/ffcb3fe7d1bf4ed2e01a95a552bb3b7f5dab24d1
> > 
> > I'm just curious why goldmark is considered a dependency. "go mod
> > why"
> > and plain old "grep" doesn't give me any leads.
> > 
> > ---
> > $ git checkout ffcb3fe7d1bf4ed2e01a95a552bb3b7f5dab24d1
> > HEAD is now at ffcb3fe go.mod: update golang.org/x dependencies
> > 
> > $ go mod why github.com/yuin/goldmark
> > # github.com/yuin/goldmark
> > (main module does not need package github.com/yuin/goldmark)
> > 
> > $ grep goldmark -R .
> > ./go.sum:github.com/yuin/goldmark v1.4.13/go.mod
> > h1:6yULJ656Px+3vBD8DxQVa3kxgyrAnzto9xy5taEt/CY=
> > ---
> > 
> > Am I holding "go mod why" wrong? What else can I try?
> > 
>
> My guess is the go.mod in x/tools.
>
> https://github.com/golang/tools/blob/master/go.mod
>
>

-- 
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/cc9f4f90-1b39-436f-99eb-4dfcf8dad6ddn%40googlegroups.com.

[go-nuts] Re: Test coverage: joint unit test and integration test coverage

[TheDiveO]

The only "documentation" is this issue comment 
https://github.com/golang/go/issues/51430#issuecomment-1344711300 and the 
reply to my question about the "official 
status" https://github.com/golang/go/issues/51430#issuecomment-1485320781

On Thursday, August 17, 2023 at 9:51:12 AM UTC+2 Jan wrote:

> I tried to use the `-test.gocoverdir` (*) and while the test(s) being 
> executed use the given directory, unfortunately it still sets `GOCOVERDIR` 
> to some newly created temporary directory. 
>
> Since my integration tests are executed from a *_test.go  
> <https://github.com/janpfeifer/gonb/blob/main/nbtests/nbtests_test.go#L32>test
>  
> (it's a test after all), in the end the `-test.gocoverdir` flag contents 
> are discarded (or not passed along in GOCOVERDIR). If the flag is set, 
> shouldn't it be used for `GOCOVERDIR` as well ?
>
> cheers
>
> (*) Btw, I can't find documentation on -test.gocoverdir in Google 
> <https://www.google.com/search?q=golang+%22-test.gocoverdir%22=golang+%22-test.gocoverdir%22_lcrp=EgZjaHJvbWUyBggAEEUYOTIHCAEQABiiBNIBCTEyODgzajBqN6gCALACAA=chrome=UTF-8#ip=1>,
>  
> except the insides of code. Also `go help testflag | grep gocoverdir` 
> doesn't return anything -- in go1.21.0.
>
> On Thursday, August 17, 2023 at 8:08:51 AM UTC+2 Jan wrote:
>
>> Oh yes, it's true that the new mechanism is more general, and allows 
>> integration tests, it's a huge improvement for cases like this! Thanks for 
>> the design btw!
>>
>> Now the ergonomics of the case of unit tests + integration tests could be 
>> made easier/more ergonomic -- I would assume it is the common case for 
>> projects with integration tests (because everyone has also unit tests). And 
>> a suggestion of maybe a mention / an example in the 
>> integration-test-coverage 
>> blog <https://go.dev/blog/integration-test-coverage> ?
>>
>> On Wednesday, August 16, 2023 at 10:03:55 PM UTC+2 TheDiveO wrote:
>>
>>> Hmm, my previous response got deleted for no reason. So here we go: the 
>>> new mechanism is more general, and as you can see in my example I actually 
>>> run the "same" unit tests twice. The reason is because some code paths 
>>> might be only exercised when not being run as root, especially error 
>>> handling. So there is some value in the new mechanism even "just" for unit 
>>> tests. Admittedly, not all will need that in their unit tests.
>>>
>>> On Wednesday, August 16, 2023 at 8:53:56 PM UTC+2 Jan wrote:
>>>
>>>> Thanks, that's very helpful! 
>>>>
>>>> I was doing something similar 
>>>> <https://github.com/janpfeifer/gonb/blob/main/docs/development.md#generate-coverage>,
>>>>  
>>>> but I was extracting the temporary coverage directory created by Go 
>>>> because 
>>>> I didn't know about the --test.gocoverdir flag. 
>>>>
>>>> Still it feels wrong one has to do the trick of creating a temporary 
>>>> directory (or extract it from the go tool) , where for unit tests only 
>>>> it's 
>>>> not needed ... I wonder if this is done deliberately, or just a bug ?
>>>>
>>>> cheers
>>>>
>>>> On Wednesday, August 16, 2023 at 8:33:23 PM UTC+2 TheDiveO wrote:
>>>>
>>>>> Maybe similar to this? 
>>>>> https://github.com/thediveo/lxkns/blob/cef5a31d7517cb126378f81628f51672cb793527/scripts/cov.sh#L28
>>>>>
>>>>> On Wednesday, August 16, 2023 at 1:54:48 PM UTC+2 Jan wrote:
>>>>>
>>>>>> hi all, 
>>>>>>
>>>>>> After reading the documentation 
>>>>>> <https://go.dev/blog/integration-test-coverage>, I managed to set up 
>>>>>> a process in which I compile and run my integration tests, and get 
>>>>>> coverage 
>>>>>> from them in the `$GOCOVERDIR` subdirectory.
>>>>>>
>>>>>> Now I would like to have a combined unit tests + integration tests 
>>>>>> report, all in one go, and I'm not sure how to get that.
>>>>>>
>>>>>> I was expecting that, if I go to my modules root directory, and I do:
>>>>>>
>>>>>> ```
>>>>>> go test --cover --coverpkg=./... 
>>>>>> --coverprofile=/tmp/cover_profile.out ./...
>>>>>> go tool cover -func /tmp/cover_profile.out > /tmp/cover_func.out
>>>>>> ```
>>>>>>
>>>>>> I  would get

[go-nuts] Re: Test coverage: joint unit test and integration test coverage

[TheDiveO]

Hmm, my previous response got deleted for no reason. So here we go: the new 
mechanism is more general, and as you can see in my example I actually run 
the "same" unit tests twice. The reason is because some code paths might be 
only exercised when not being run as root, especially error handling. So 
there is some value in the new mechanism even "just" for unit tests. 
Admittedly, not all will need that in their unit tests.

On Wednesday, August 16, 2023 at 8:53:56 PM UTC+2 Jan wrote:

> Thanks, that's very helpful! 
>
> I was doing something similar 
> <https://github.com/janpfeifer/gonb/blob/main/docs/development.md#generate-coverage>,
>  
> but I was extracting the temporary coverage directory created by Go because 
> I didn't know about the --test.gocoverdir flag. 
>
> Still it feels wrong one has to do the trick of creating a temporary 
> directory (or extract it from the go tool) , where for unit tests only it's 
> not needed ... I wonder if this is done deliberately, or just a bug ?
>
> cheers
>
> On Wednesday, August 16, 2023 at 8:33:23 PM UTC+2 TheDiveO wrote:
>
>> Maybe similar to this? 
>> https://github.com/thediveo/lxkns/blob/cef5a31d7517cb126378f81628f51672cb793527/scripts/cov.sh#L28
>>
>> On Wednesday, August 16, 2023 at 1:54:48 PM UTC+2 Jan wrote:
>>
>>> hi all, 
>>>
>>> After reading the documentation 
>>> <https://go.dev/blog/integration-test-coverage>, I managed to set up a 
>>> process in which I compile and run my integration tests, and get coverage 
>>> from them in the `$GOCOVERDIR` subdirectory.
>>>
>>> Now I would like to have a combined unit tests + integration tests 
>>> report, all in one go, and I'm not sure how to get that.
>>>
>>> I was expecting that, if I go to my modules root directory, and I do:
>>>
>>> ```
>>> go test --cover --coverpkg=./... --coverprofile=/tmp/cover_profile.out 
>>> ./...
>>> go tool cover -func /tmp/cover_profile.out > /tmp/cover_func.out
>>> ```
>>>
>>> I  would get all the results, including integration tests (since they 
>>> are called with GOCOVERDIR set). But instead I only see the coverage of the 
>>> unit tests, and the information from the integration tests seems to be 
>>> ignored, even though it is generated.
>>>
>>> I'm sure it is generated because if I run the command above with 
>>> `--work` (preserve the temporary files), and log the value of $GOCOVERDIR I 
>>> can see where the test stores the coverage data files. And if I manually do:
>>>
>>> ```
>>> go tool covdata func -i /tmp/go-build287472875/b001/gocoverdir
>>> ```
>>> (where /tmp/go-build/gocoverdir is the temporary directory reported 
>>> for GOCOVERDIR)
>>>
>>> I see the results I expected (some of my functions that I want to make 
>>> sure are covered) are there. But they are not reported in 
>>> `/tmp/cover_func.out` above.
>>>
>>> Any ideas why ? 
>>>
>>> Or any other suggestions on how to merge the report from unit tests 
>>> (`/tmp/cover_profile.out` in my example) and integration tests ? 
>>>
>>> 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/65058e99-0502-4b2d-bcd3-1639853672bbn%40googlegroups.com.

[go-nuts] Re: Test coverage: joint unit test and integration test coverage

[TheDiveO]

Maybe similar to this? 
https://github.com/thediveo/lxkns/blob/cef5a31d7517cb126378f81628f51672cb793527/scripts/cov.sh#L28

On Wednesday, August 16, 2023 at 1:54:48 PM UTC+2 Jan wrote:

> hi all, 
>
> After reading the documentation 
> <https://go.dev/blog/integration-test-coverage>, I managed to set up a 
> process in which I compile and run my integration tests, and get coverage 
> from them in the `$GOCOVERDIR` subdirectory.
>
> Now I would like to have a combined unit tests + integration tests report, 
> all in one go, and I'm not sure how to get that.
>
> I was expecting that, if I go to my modules root directory, and I do:
>
> ```
> go test --cover --coverpkg=./... --coverprofile=/tmp/cover_profile.out 
> ./...
> go tool cover -func /tmp/cover_profile.out > /tmp/cover_func.out
> ```
>
> I  would get all the results, including integration tests (since they are 
> called with GOCOVERDIR set). But instead I only see the coverage of the 
> unit tests, and the information from the integration tests seems to be 
> ignored, even though it is generated.
>
> I'm sure it is generated because if I run the command above with `--work` 
> (preserve the temporary files), and log the value of $GOCOVERDIR I can see 
> where the test stores the coverage data files. And if I manually do:
>
> ```
> go tool covdata func -i /tmp/go-build287472875/b001/gocoverdir
> ```
> (where /tmp/go-build/gocoverdir is the temporary directory reported 
> for GOCOVERDIR)
>
> I see the results I expected (some of my functions that I want to make 
> sure are covered) are there. But they are not reported in 
> `/tmp/cover_func.out` above.
>
> Any ideas why ? 
>
> Or any other suggestions on how to merge the report from unit tests 
> (`/tmp/cover_profile.out` in my example) and integration tests ? 
>
> 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/ceb7dc45-cedc-4453-b35a-e81f067412d7n%40googlegroups.com.

Re: [go-nuts] What does "shallow clone" mean?

[TheDiveO]

Personally, I find the source 
https://cs.opensource.google/go/x/exp/+/352e893a:maps/maps.go;l=65 to be 
helpful in quickly answering such questions.

On Friday, August 11, 2023 at 4:36:50 PM UTC+2 Ian Lance Taylor wrote:

> On Fri, Aug 11, 2023, 7:28 AM shinya sakae  wrote:
>
>> maps package was released with Go 1.21.
>> Clone() comment says "This is a shallow clone".
>> I often hear the term `shallow copy', but I don't know what `shallow 
>> clone` means.
>> What is the state of a `shallow cloned` map?
>> Do you mean that the cloned map values are shallow copied?
>
>
> Yes.
>
> 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/8e90a1d9-e9bd-44f1-90dc-f9f3d7555c15n%40googlegroups.com.

Re: [go-nuts] binary.ByteOrder

[TheDiveO]

https://github.com/google/nftables/blob/main/binaryutil/binaryutil.go ... 
could give you some bad ideas; we need it for Linux nftables that encodes 
stuff in host endianess.

On Thursday, August 10, 2023 at 3:27:49 PM UTC+2 Stephen Illingworth wrote:

> Thanks. Although I'm not worried about the native byte order of my machine
>
> I'm writing an ARM emulator. The endianness of the ARM I'm taking to be 
> whatever the endianess is in the ELF file from which I'm loading the 
> program. I'm using the debug/elf package in the standard library which in 
> turn uses the binary package
>
> Generally, the specifics of the byte order is irrelevant - I can just use 
> Uint32(), PutUint32() etc. but in some specific instructions it's easier to 
> handle the byte order manually and for that I need to know what the 
> endianness is.
>
> I can work around it but I just thought I might be missing something.
>
>
> Regards
> Stephen
> On Thursday, 10 August 2023 at 14:16:53 UTC+1 Rob Pike wrote:
>
>> First read 
>> https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html
>>
>> then see
>>
>> https://go.dev/play/p/4ESm6nOwgtY
>>
>> -rob
>>
>>
>>
>>
>>
>>
>> On Thu, Aug 10, 2023 at 8:46 PM Stephen Illingworth <
>> stephen.i...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I want to detect the implementation of binary.ByteOrder. ie. whether it 
>>> is Little Endian or Big Endian.
>>>
>>> Normally, you would do this with a type assertion or a type switch but 
>>> in the case of the binary package the little/big endian implementations are 
>>> not exported.
>>>
>>> The only way that I can see to distinguish between the implementations 
>>> is to test the value returned by String(). Am I missing something here or 
>>> should I continue to use String()?
>>>
>>> Regards
>>> Stephen
>>>
>>> -- 
>>> 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/67469c8a-b1aa-4976-8f4a-2b4458d28214n%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/7218dc7e-e136-47aa-b59b-a4f98f2dedd2n%40googlegroups.com.

Re: [go-nuts] Bets approach for test helper packages within same project

[TheDiveO]

https://stackoverflow.com/a/54734212

On Monday, August 7, 2023 at 8:48:24 AM UTC+2 josvazg wrote:

> Interesting! Thanks!
>
> I was assuming wrongly the module was the unit of compilation.
>
> If any package not imported by production code is not included, then that 
> also means that build tags are not necessary for the integration and end to 
> end test folders. Correct?
>
> Any pointers on where can I read more about this?
>
> Jose
>
> El sábado, 5 de agosto de 2023 a las 4:05:52 UTC+2, Nagaev Boris escribió:
>
>> Hi, 
>>
>> You can put test helpers to a separate package (directory), say 
>> testhelper/ without a build tag. Code in that directory will use 
>> regular code and it will have its own unit tests in testhelper/ 
>> directory. When you build your production binary, it won't include 
>> such code, because it is not imported by any production code (directly 
>> or indirectly). At the same time, you can import the "testhelper" 
>> package from your integration tests as usual. 
>>
>> On Fri, Aug 4, 2023 at 11:01 AM josvazg  wrote: 
>> > 
>> > We are working on a project that requires some test helpers and mocks 
>> that, ideally, should: 
>> > 
>> > - Helpers should be accessible by all testing code, unit tests, 
>> integration or e2e. 
>> > - Note unit tests live along side normal code in their *_test.go files. 
>> > - The rest of tests will be on a separated test/ folder using a built 
>> tag to avoid to be compiled in with regular code. 
>> > 
>> > - Helpers should not be part of the default exported module code. 
>> > 
>> > - Helpers do not need to be accessible by the regular code, just the 
>> test code. 
>> > 
>> > - Helpers might need tests themselves. 
>> > 
>> > How can we achieve that in the simplest or cleanest way? We do not want 
>> to create yet another project for just that, as it is only to be used 
>> within this project. 
>> > 
>> > I was thinking about a build tag for such code and just put it on a 
>> regular folder, such as testsupport/. But that would break unit tests that 
>> need that unless you setup the build tag, which feels weird. 
>> > 
>> > Another option is to place the test support and the test that use them 
>> under the same build tag and folder as test/. And run them separately with 
>> the build tag. That creates a special category of unit tests, when they are 
>> not integration or e2e but need supporting code from those test/support/ 
>> packages. 
>> > 
>> > Maybe use a module at testsupport/ separate from the rest of the code 
>> and use it as a library from test code? 
>> > 
>> > Any better options? 
>> > Or maybe there is a good known solution for this I should know about. 
>> > 
>> > Jose 
>> > 
>> > -- 
>> > 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/ca983d85-b5f5-423d-b949-71fa41b414ccn%40googlegroups.com.
>>  
>>
>>
>>
>>
>> -- 
>> Best regards, 
>> Boris Nagaev 
>>
>

-- 
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/95c10c49-762f-4f98-93d7-4b8c076a6024n%40googlegroups.com.

Re: [go-nuts] Realpath?

[TheDiveO]

Also, your function (as well as the one you seem to have copied and 
modified, did I get that right from your documentation?) will most probably 
not work correctly if there are symlinks "inside" the path and not just at 
the beginning of the given path. There's a reason to my limited 
understanding why the stdlib EvalSymlinks function has to iterate, in order 
to cover finding multiple symlinks along the path, and a previous symlink 
will influence later symlinks.

Some time ago, I had to get deeper into stdlib's EvalSymlinks in order to 
come up with a modified one that allows the path to be interpreted relative 
to an arbitrary other "root" path, even if the path to be resolved is 
seemingly absolute. It's a special use case when using Linux and doing 
funny mount namespace-related VFS accesses through Linux' process 
filesystem, and its "root" elements in particular. In case someone wants to 
know more, here we are: https://github.com/thediveo/procfsroot ... I'm 
using this to access the VFS view of containers without needing to spawn 
new processes, switching them into container mount namespaces, and then all 
the hassles of shuttling commands and responses forth and back. Instead, I 
resolve a path that is "absolute" to another mount namespace as relative to 
a suitable process filesystem entry and then can access the 
file/directory/etc. directly by the "resolved" path, using normal VFS 
syscalls from any arbitrary Go routine (and OS-level thread/task).
On Friday, August 4, 2023 at 10:14:18 AM UTC+2 TheDiveO wrote:

> As I couldn't figure this out from the repo's documentation: what's the 
> difference and what's the benefit compared to stdlib 
> https://pkg.go.dev/path/filepath#EvalSymlinks?
>
> On Thursday, August 3, 2023 at 8:57:08 PM UTC+2 Carlos Henrique Guardão 
> Gandarez wrote:
>
>> Hey there!
>>
>> I created a new lib to return a real path in Go.
>> https://github.com/gandarez/go-realpath
>>
>> Thanks.
>>
>> On Thursday, January 18, 2018 at 4:28:09 PM UTC-2 rgo...@redhat.com 
>> wrote:
>>
>>>
>>>
>>> On Monday, 16 July 2012 13:55:53 UTC+3, Rémy Oudompheng wrote:
>>>>
>>>> Did you have a look at filepath.EvalSymlinks? 
>>>>
>>>> Rémy. 
>>>>
>>>
>>> Confirmed to be working. Thanks Remy. 
>>>
>>

-- 
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/4131ed67-d9cb-4755-90a6-96099d56f3d0n%40googlegroups.com.

Re: [go-nuts] Realpath?

[TheDiveO]

As I couldn't figure this out from the repo's documentation: what's the 
difference and what's the benefit compared to stdlib 
https://pkg.go.dev/path/filepath#EvalSymlinks?

On Thursday, August 3, 2023 at 8:57:08 PM UTC+2 Carlos Henrique Guardão 
Gandarez wrote:

> Hey there!
>
> I created a new lib to return a real path in Go.
> https://github.com/gandarez/go-realpath
>
> Thanks.
>
> On Thursday, January 18, 2018 at 4:28:09 PM UTC-2 rgo...@redhat.com wrote:
>
>>
>>
>> On Monday, 16 July 2012 13:55:53 UTC+3, Rémy Oudompheng wrote:
>>>
>>> Did you have a look at filepath.EvalSymlinks? 
>>>
>>> Rémy. 
>>>
>>
>> Confirmed to be working. Thanks Remy. 
>>
>

-- 
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/961d926b-62f8-42dc-9a97-13b5ae7b764dn%40googlegroups.com.

Re: [go-nuts] Error handling

[TheDiveO]

Sorry to f'up on myself, but I would like to add regarding #1: at least my 
personal impression is that for #1 it looks very difficult to improve this 
in any meaningful way. It looks to me as if #2 is actually where the 
improvements would bear large fruit as it makes Go more welcoming and 
productive to those types of devs and/or types of Go modules, that is, 
applications.

On Wednesday, August 2, 2023 at 9:27:23 PM UTC+2 TheDiveO wrote:

>
> Ben Hoyt's blog post Scripting with Go: a 400-line Git client that... 
> <https://benhoyt.com/writings/gogit/> mentions error handling from a 
> perspective that made me clear for the first time why I'm always in two 
> minds when it comes to Go's error handling:
>
>1. the perspective of a prod-code package writer that will be used in 
>larger contexts: "[Go's error handling is] *simple and explicit [...] 
>It's not a big deal when writing production code, because then you want 
>more control over error handling anyway -- nicely-wrapped errors, or 
>human-readable messages [...]*"
>2. from a "script" developer perspective, where "*all the error 
>handling you need is to show a message, print a stack trace, and exit the 
>program*".
>
> There might be more angles to it, but Ben's sentiment rings a bell with my 
> own "customer" experience.
>
> So we can at least expect to have two "camps of judges" when it comes to 
> error handling improvement proposals. Some of the judges might be acutely 
> aware of the at least two different angles, but some of the comments not 
> least in this thread ("language designers" as kind of gods who must ignore 
> their customers, seriously?) seem to indicate that this isn't always the 
> case. Not least, I also fall into the less desirable category of the 
> ignoramus.
>
> So, maybe we should in the future always ask when it comes to a proposal: 
> which of the two perspectives does the proposal tackle? I'm under the 
> assumption that it might have been #2 in most of the proposals. The often 
> vivid negative responses should then be classified as belonging to #1 
> and/or #2. If the proposal is about #2, then #1 proponents don't 
> contribute, but simply make life hard for the #2 customers of the Go 
> language. Same for the opposite combination.
>
> On Wednesday, August 2, 2023 at 6:11:01 PM UTC+2 DrGo wrote:
>
>> Fair enough … I understand that people have different styles 
>>
>> On Wednesday, August 2, 2023 at 12:54:20 AM UTC-6 Brian Candler wrote:
>>
>>> FWIW, I'm in the "I like how it is now better than any other proposal so 
>>> far" camp; I think this happens as you get used to the Go way. Go is Go.
>>>
>>> The only thing I would consider is making *interface* types (only) 
>>> implicitly usable in a boolean context, e.g.
>>>
>>> if err { ... }
>>>
>>> However, I suppose people would ask "why not pointers? why not 
>>> channels?" etc.  I'm not suggesting it should become like Python where 
>>> every non-zero value is treated as "true".  Interface values are special, 
>>> and there's very little you can do with a nil interface (whereas for 
>>> example, a nil pointer can still have methods called on it).  But this does 
>>> add a special case, and Go already has its share of surprises you have to 
>>> learn.
>>>
>>> On Tuesday, 1 August 2023 at 22:41:38 UTC+1 DrGo wrote:
>>>
>>>> Yes. Go is no longer the simple language it was. I suspect because of 
>>>> internal pressures within Google as evidenced by multiple innovations that 
>>>> seem to come from nowhere eg dir embedding and associated fs package that 
>>>> duplicated perfectly good ways of doing things. The module system while 
>>>> useful is quite complex. Generics and all the associated packages inflated 
>>>> the mental burden of learning and reading Go code significantly. And 
>>>> having 
>>>> the go 1 compatibility guarantee means that old stuff remains valid code 
>>>> and must be learned too. 
>>>>
>>>> On Tuesday, August 1, 2023 at 2:59:07 PM UTC-6 Victor Giordano wrote:
>>>>
>>>>> Yeah.. I mean, the "idiom" `err != nil return` err is something of the 
>>>>> language. I complain about the boilerplate that idiom produces and that 
>>>>> is 
>>>>> fact fact (no one can deny it).
>>>>>
>>>>> You know, your approach implies making the language a little more 
>>>>> complicated as new ways to dea

Re: [go-nuts] Error handling

[TheDiveO]

Ben Hoyt's blog post Scripting with Go: a 400-line Git client that... 
 mentions error handling from a 
perspective that made me clear for the first time why I'm always in two 
minds when it comes to Go's error handling:

   1. the perspective of a prod-code package writer that will be used in 
   larger contexts: "[Go's error handling is] *simple and explicit [...] 
   It's not a big deal when writing production code, because then you want 
   more control over error handling anyway -- nicely-wrapped errors, or 
   human-readable messages [...]*"
   2. from a "script" developer perspective, where "*all the error handling 
   you need is to show a message, print a stack trace, and exit the program*
   ".

There might be more angles to it, but Ben's sentiment rings a bell with my 
own "customer" experience.

So we can at least expect to have two "camps of judges" when it comes to 
error handling improvement proposals. Some of the judges might be acutely 
aware of the at least two different angles, but some of the comments not 
least in this thread ("language designers" as kind of gods who must ignore 
their customers, seriously?) seem to indicate that this isn't always the 
case. Not least, I also fall into the less desirable category of the 
ignoramus.

So, maybe we should in the future always ask when it comes to a proposal: 
which of the two perspectives does the proposal tackle? I'm under the 
assumption that it might have been #2 in most of the proposals. The often 
vivid negative responses should then be classified as belonging to #1 
and/or #2. If the proposal is about #2, then #1 proponents don't 
contribute, but simply make life hard for the #2 customers of the Go 
language. Same for the opposite combination.

On Wednesday, August 2, 2023 at 6:11:01 PM UTC+2 DrGo wrote:

> Fair enough … I understand that people have different styles 
>
> On Wednesday, August 2, 2023 at 12:54:20 AM UTC-6 Brian Candler wrote:
>
>> FWIW, I'm in the "I like how it is now better than any other proposal so 
>> far" camp; I think this happens as you get used to the Go way. Go is Go.
>>
>> The only thing I would consider is making *interface* types (only) 
>> implicitly usable in a boolean context, e.g.
>>
>> if err { ... }
>>
>> However, I suppose people would ask "why not pointers? why not channels?" 
>> etc.  I'm not suggesting it should become like Python where every non-zero 
>> value is treated as "true".  Interface values are special, and there's very 
>> little you can do with a nil interface (whereas for example, a nil pointer 
>> can still have methods called on it).  But this does add a special case, 
>> and Go already has its share of surprises you have to learn.
>>
>> On Tuesday, 1 August 2023 at 22:41:38 UTC+1 DrGo wrote:
>>
>>> Yes. Go is no longer the simple language it was. I suspect because of 
>>> internal pressures within Google as evidenced by multiple innovations that 
>>> seem to come from nowhere eg dir embedding and associated fs package that 
>>> duplicated perfectly good ways of doing things. The module system while 
>>> useful is quite complex. Generics and all the associated packages inflated 
>>> the mental burden of learning and reading Go code significantly. And having 
>>> the go 1 compatibility guarantee means that old stuff remains valid code 
>>> and must be learned too. 
>>>
>>> On Tuesday, August 1, 2023 at 2:59:07 PM UTC-6 Victor Giordano wrote:
>>>
 Yeah.. I mean, the "idiom" `err != nil return` err is something of the 
 language. I complain about the boilerplate that idiom produces and that is 
 fact fact (no one can deny it).

 You know, your approach implies making the language a little more 
 complicated as new ways to deal with errors appear. I do understand that 
 some folks provide some push back on the idea simply because there is 
 nothing wrong with the language right now regarding error handling. 

 As I see things, the language was simple in their origins, but from 
 time to time they complicated a little more some things, for example "what 
 about generics?"  (are they really necessary?, I mean... I think using 
 interfaces provides all the genericity you may need). So I guess there is 
 room to make some changes and make the language easier. I would say that 
 both ways of handling errors are valid, the most important is to be as 
 simple as possible so you ensure that other people understand it. Like 
 Generics, you don't have to use them. So I would praise it for adding 
 another way, less repetitive.

 Also like to see how people react and what their opinions are. So far 
 what I read is just personal taste.


 El mar, 1 ago 2023 a las 16:04, 'Luke Crook' via golang-nuts (<
 golan...@googlegroups.com>) escribió:

> And of course I forgot the "if" at the beginning of all those 
> conditional. *sigh*
>
> -- 

[go-nuts] Re: Any option to substitute plug-in package ?

[TheDiveO]

It really depends on what you want to achieve...

   1. dynamically discovering *out-of-process* RPC plugins ... Hashicorp's 
   might be the most famous one.
   2. dynamically discovering and loading *shared lib *plugins ... this 
   needs some plumbing above the pure stdlib plugin functionality. Personally, 
   I find the shared libs to be finicky and haven't yet done a real project 
   that needed this variant (but I wrote a go-plugger 
   <https://github.com/thediveo/go-plugger> module as an example).
   3. statically binary-builtin plugins: this actually is what I tend to 
   use in several of my own projects, where there is no need for dynamically 
   extending but instead to easily maintain and use a fixed set of "plugins" 
   and that set of plugins tends to slowly grow. The plugin mechanism might 
   help organizing, such as my own go-plugger 
   <https://github.com/thediveo/go-plugger> supporting type-safe plugin 
   APIs and ordering and iterating plugins at runtime. For instance, I use 
   this mechanism to simplify adding new types to factories, or to "decorate" 
   containers with additional labels, such as in Docker compose contexts, or 
   k8s contexts, or ...
   

On Wednesday, August 2, 2023 at 12:14:15 PM UTC+2 alex-coder wrote:

> Hi All !
> Plug-in package is very interesting, but in case the development under 
> windows it does not work,
> So, any hint to use some option instead will be highly appreciated.
>
> Thank you.
>

-- 
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/01ffc6c2-962d-497d-abad-5940ff11da48n%40googlegroups.com.

[go-nuts] Re: I made a CLI tool, and I'm curious about your ideas

[TheDiveO]

Fresh from the Go project itself. *Experimenting with project templates:* 
https://go.dev/blog/gonew 


On Friday, July 14, 2023 at 10:05:34 AM UTC+2 Marcello H wrote:

> No matter what other people say, as a first project, I think it is great 
> because it gives you the opportunity to practise how a project is made.
> I doubt if I would use it since it is done by hand almost at the same 
> speed.
> Also, I don't like the idea that it forces me into a certain layout.
> So the idea I have, would be: if there's a configuration that will tell 
> the application how the structure is created.
> (Let's say, like some template which the user can adjust.)
>
> Just my two cents, and please don't be bothered by my "negative" comments.
> Op donderdag 13 juli 2023 om 22:35:16 UTC+2 schreef Sandesh Gade:
>
>> Hi, 
>>
>> I am curious to know if you've evaluated whether there is any benefit to 
>> your tool rather than just running  `go mod init projectName`?
>> I don't see any improvements that the `gnt` tool brings to the table 
>> other than an unnecessary wrapper/opinionated project layout/structure on 
>> top of `go mod init`. 
>>
>> I am reminded of a Jeff Goldblum quote from the movie Jurassic Park, *"Your 
>> Scientists Were So Preoccupied With Whether Or Not They Could, They Didn’t 
>> Stop To Think If They Should"*
>>
>> On Thursday, July 6, 2023 at 12:13:31 PM UTC-4 Alper Akca wrote:
>>
>>>
>>>
>>> [image: gnt.png]
>>> I am a beginner in Golang. I made a cli tool for creating a Go project. 
>>> You can easily create a new Go project using the 'gnt create projectName' 
>>> command. This command creates a 'bin', 'cmd/projectName/main.go' 
>>> directories and the go module file. Those who are good at golang can give 
>>> me ideas. GitHub repository link below:
>>> https://github.com/lnxwizard/gnt
>>>
>>>

-- 
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/ea418f79-726c-4221-a331-feb1d0178208n%40googlegroups.com.

Re: [go-nuts] go package dating back to 2009

[TheDiveO]

just a wild guess: search for prior art?

On Tuesday, July 25, 2023 at 1:21:22 AM UTC+2 Ian Lance Taylor wrote:

> On Mon, Jul 24, 2023 at 3:08 PM Bravo Moua  wrote:
> >
> > How can one search for packages dating back to Jan 2009
>
> Well, Go was only publicly released in November, 2009, so there are no
> public Go packages as old as January, 2009.
>
> I assume you know that you can search for Go packages today at
> https://pkg.go.dev/.
>
> Perhaps if you clarify what you are looking for we can provide a more
> useful answer.
>
> 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/1b57ce2c-d4f5-4e3c-a0c6-711a909d327fn%40googlegroups.com.

[go-nuts] Re: RPI

[TheDiveO]

The download page offers ARM 64bit and v6(l) architecture tar balls. v6l is 
probably the 32bit architecture. You don't mention your OS and architecture 
(lsb_release -a), but armv7l sounds like an old rpi 2 with only 32bit 
support. So you might give the v6l version a try. Otherwise, you'll need 
for Raspian to catch up via upstream Debian and that might take a long time.

On Thursday, July 20, 2023 at 5:48:25 PM UTC+2 Dejan Duh wrote:

> Hello
>
> My question is why isn't the latest version of golang avalible for 
> raspberry pi(armv7l)?
>
> 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/fa3d2c08-9dda-4347-86c6-0a1af6334c1dn%40googlegroups.com.

[go-nuts] Re: Package structure & testing

[TheDiveO]

Maybe not the best way either, but the POD part might benefit from slight 
refactoring and you already in part hinted at it.

   - gopher/api -- some PODs here
   - gopher/model -- don't repeat gopher as in gophermodel; some PODs here

It won't ever perfect, so YMMV. But at the same time it allows your module 
to grow.

On Monday, June 19, 2023 at 7:04:24 AM UTC+2 Salvatore Domenick Desiano 
wrote:

> I've been using Go for almost a decade and I still don't have a library 
> package structure I like. I'm hoping I can post what I want here and 
> someone can tell me either (a) what the idiomatic way of doing this is, or 
> (a) how to break the dependency cycle.
>
> Let's imagine we're building the fancy Gopher Client library. What I want 
> is:
>
>- *gopher*: public POD (plain old data) types, public interfaces, func 
>NewClient(), struct clientImpl
>- *gopher/testing*: func NewFakeClient(), struct fakeClientImpl, all 
>testing-specific code (*not* gopher _test files... just code for 
>*other* libraries that want a fake of this one)
>- *gopher/internal*: internal types, implementation details shared 
>between gopher and gopher/testing.
>
> This doesn't work. Having POD types in gopher means that everything else 
> has to depend on it. This means that NewClient() can't be in gopher because 
> it would depend on gopher/internal (shared implementation details) and 
> gopher/internal depends on gopher (PODs).
>
> At various points I've tried:
>
>- Collapse gopher and gopher/internal. This works, but requires 
>private types to be available to gopher/testing.
>- Collapse all three. This works but I really don't like having Fake 
>code in the same package as real code.
>- Create gopher/gophermodel for the PODs and interfaces. This works, 
>but it's really ugly to have to refer to the PODS as (for example) 
>gophermodel.Response.
>- Create gopher/gopherclient for NewClient() and clientImpl. This is 
>probably the least ugly but it still feel strange to call 
>gopherclient.New() and have the PODs in gopher.
>
> What am I missing?
>
> Thank you!
>
> -- Salvatore
> smile.
>
>

-- 
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/f13a05db-49de-4f84-9169-5f39477a4e87n%40googlegroups.com.

Re: [go-nuts] No DNS TTL information in net.LookupSRV()

[TheDiveO]

would https://pkg.go.dev/github.com/miekg/dns be an option instead of the 
std lib?

On Friday, May 26, 2023 at 9:45:37 PM UTC+2 Varun Ahluwalia wrote:

> Is there a TTL support in GoLang DNS, or if it was implemented in a later 
> release, please suggest.
> Thanks,
>
> On Saturday, October 8, 2016 at 9:45:17 AM UTC-4 sandro@gmail.com 
> wrote:
>
>>
>>
>> Il giorno mercoledì 13 aprile 2016 22:45:48 UTC+2, Ian Lance Taylor ha 
>> scritto:
>>>
>>> On Wed, Apr 13, 2016 at 12:31 PM, fyodor  wrote: 
>>> > Is there a way to obtain TTL information from through the DNS lookup 
>>> methods 
>>> > in the net package? 
>>>
>>> Not at present. 
>>>
>>> > I'm implementing a component that uses SRV records from a DNS server 
>>> and i 
>>> > noticed TTL number aren't returned with the net.LookupSRV function. 
>>> > 
>>> > 
>>> https://github.com/golang/go/blob/0104a31b8fbcbe52728a08867b26415d282c35d2/src/net/dnsclient.go#L187
>>>  
>>> > 
>>> > The TTL information is in the DNS header returned in the response but 
>>> i 
>>> > can't see a way just getting the header. 
>>> > 
>>> > https://github.com/golang/go/blob/master/src/net/dnsmsg.go#L126 
>>> > 
>>> > Would it be worth my while to implement something for this and submit 
>>> this 
>>> > for inclusion in a forthcoming release of Go? 
>>>
>>> It seems reasonable to me.  You should your API proposal to golang-dev 
>>> before you much time into it. 
>>>
>>
>> Did anything move on this front ? I've the same problem, in look for a 
>> TTL value for my lookups...
>>
>> --strk;
>>
>

-- 
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/79627cb3-faa5-4025-a6ac-3d7e3b872de4n%40googlegroups.com.

Re: [go-nuts] Re: go mod download fails on docker for 1.20 (but not for 1.18)

[TheDiveO]

The thing that finally caught my eye is the "connect: cannot assign  
requested address" part in the error message. You can search for it in 
combination with golang. I'm not exactly clear but this could be related to 
running out of socket or port resources, maybe in combination with changes 
in how many parallel HTTP requests are fired off by go mod tidy and go mod 
download. The overall communication/socket "load" of your system might also 
be a factor to look at.
On Monday, May 22, 2023 at 12:04:01 PM UTC+2 Joao Miguel Ferreira wrote:

> Hello Jim and Harald,
>
> please find below the answers to your questions. if anything else could 
> help, please let me know
>
> about the container configuration for ipv6, it seems that there is no such 
> configuration for containers running from the base images (1.18, 1.20, 
> bullseye seems to not have the ip command installed)
>
> $ docker run -it golang:1.18-buster sh -c "ip -6 addr show dev eth0; ip -6 
> route show"
> $ docker run -it golang:1.18-bullseye sh -c "ip -6 addr show dev eth0; ip 
> -6 route show"
> sh: 1: ip: not found
> sh: 1: ip: not found
> $ docker run -it golang:1.18-alpine sh -c "ip -6 addr show dev eth0; ip -6 
> route show"
> $ docker run -it golang:1.20-buster sh -c "ip -6 addr show dev eth0; ip -6 
> route show"
> $ docker run -it golang:1.20-bullseye sh -c "ip -6 addr show dev eth0; ip 
> -6 route show"
> sh: 1: ip: not found
> sh: 1: ip: not found
> $ docker run -it golang:1.20-alpine sh -c "ip -6 addr show dev eth0; ip -6 
> route show"
>
> I add here a sample of the same command for ipv4 just to clarify:
>
> $ docker run -it golang:1.20-buster sh -c "ip -4 addr show dev eth0; ip -4 
> route show"
> 52: eth0@if53:  mtu 1500 qdisc noqueue 
> state UP group default  link-netnsid 0
> inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
>valid_lft forever preferred_lft forever
> default via 172.17.0.1 dev eth0
> 172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2
>  
> On Mon, May 22, 2023 at 7:55 AM TheDiveO  wrote:
>
>> ? base system distribution?
>> ? do you have IPv6 connectivity at all?
>> ? which docker version?
>>
>
> b) about my host and docker version and connectivity
> I am using Debian11 with apt provided docker; docker version is 20.10.5. I 
> am also using 2 VMs with Debian 12 and Ubuntu 22 and I have the same 
> problem there.
> I have an ipv6 address on the host network interface and I can ping6 to 
> localhost and to google, also. Please find more details below:
>
> jmf@deb11tp:~$ ping6 -c 3 localhost
> PING localhost(localhost (::1)) 56 data bytes
> 64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.043 ms
> 64 bytes from localhost (::1): icmp_seq=2 ttl=64 time=0.035 ms
> 64 bytes from localhost (::1): icmp_seq=3 ttl=64 time=0.054 ms
>
> jmf@deb11tp:~$ ping6 -c 3 www.google.com
> PING www.google.com(mad41s13-in-x04.1e100.net (2a00:1450:4003:80e::2004)) 
> 56 data bytes
> 64 bytes from mad41s13-in-x04.1e100.net (2a00:1450:4003:80e::2004): 
> icmp_seq=1 ttl=58 time=16.6 ms
> 64 bytes from mad41s13-in-x04.1e100.net (2a00:1450:4003:80e::2004): 
> icmp_seq=2 ttl=58 time=16.9 ms
> 64 bytes from mad41s13-in-x04.1e100.net (2a00:1450:4003:80e::2004): 
> icmp_seq=3 ttl=58 time=16.4 ms
>
> jmf@deb11tp:~$ ip addr show dev wlp5s0
> 3: wlp5s0:  mtu 1500 qdisc noqueue state 
> UP group default qlen 1000
> link/ether 18:56:80:2f:33:48 brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.65/24 brd 192.168.1.255 scope global dynamic 
> noprefixroute wlp5s0
>valid_lft 1832sec preferred_lft 1832sec
> inet6 2001:8a0:ffa9:9800:a681:184e:ee1b:1800/64 scope global dynamic 
> noprefixroute
>valid_lft 89765sec preferred_lft 89765sec
> inet6 fe80::d3e8:44e:9bfa:c6f8/64 scope link noprefixroute
>valid_lft forever preferred_lft forever
>
> I try to be clear: this happens during "docker build", on the "go mod 
> download" and in some cases also on the "go mod tidy". it does not happen 
> on any of the 1.18 base images, whatever host I use. It happens on all 1.20 
> base images. 
>
> Thank you for your attention
> João
>  
>
>>
>> On Monday, May 22, 2023 at 2:29:08 AM UTC+2 Joao Miguel Ferreira wrote:
>>
>>> Hello all,
>>>
>>> My docker build is ok with FROM golang:1.18-alpine, FROM 
>>> golang:1.18-buster and FROM golang:1.18-bullseye images. The 
>>> application works. All is fine on the 3 cases.
>>>
>>> But the docker build fails with FROM golang:1.20-alpine, FROM 
>>> golang:1.20-buster and FROM golang:1

[go-nuts] Re: go mod download fails on docker for 1.20 (but not for 1.18)

[TheDiveO]

? base system distribution?
? do you have IPv6 connectivity at all?
? which docker version?

On Monday, May 22, 2023 at 2:29:08 AM UTC+2 Joao Miguel Ferreira wrote:

> Hello all,
>
> My docker build is ok with FROM golang:1.18-alpine, FROM 
> golang:1.18-buster and FROM golang:1.18-bullseye images. The application 
> works. All is fine on the 3 cases.
>
> But the docker build fails with FROM golang:1.20-alpine, FROM 
> golang:1.20-buster and FROM golang:1.20-bullseye images.
>
> This is the error message I get:
>
> go: github.com/davecgh/go-...@v1.1.1 
> : Get "
> https://proxy.golang.org/github.com/davecgh/go-spew/@v/v1.1.1.mod": dial 
> tcp [2a00:1450:4003:801::2011]:443: connect: cannot assign requested address
>
> It happens during go mod download. It happens when building on Debian11, 
> Debian12 and Ubuntu22 hosts.
>
> I have tried many things including going inside the container and 
> downloading the module with wget. It works fine. Maybe something changed 
> from 1.18 to 1.20 related to ipv6.
>
> I would like to be able to do the build with one golang 1.20 image. But I 
> can not understand what is wrong. Can you help clarify that error and how 
> to overcome it?
>
>
>

-- 
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/31dcfd80-fc3a-444b-879f-8b0ca75a3a54n%40googlegroups.com.

[go-nuts] Re: Adding extra files to an already compiled binary using embed.FS

[TheDiveO]

What about merging two io.FS instance? A quick search positively surprises 
me, as there's https://pkg.go.dev/github.com/yalue/merged_fs for this 
already existing. So you could benefit from the build cache and yet add 
something later by merging/fusing multiple io.FS instances at runtime, from 
different packages. Deal...?

On Thursday, May 11, 2023 at 7:09:59 PM UTC+2 Pablo Caballero wrote:

> Hi folks! I tried to do my homework and I think that the response is "No." 
> I'm just looking for confirmation (maybe I missed something).
>
> We are using embed.FS to create "bundles" with a LOT of extra files 
> embedded into the executable. So far so good until we hit a use case where 
> we should be adding an extra tiny file depending on some user interaction 
> to already-built bundles. We:
> * would love to have this extra file in the embedded FS (We want to avoid 
> delivering it as an extra file)
> * would love not to have to recompile
>
> Is there any way to achieve that?
>
> Thank you for any help you can provide!
>
> Best
>

-- 
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/782798f0-404d-4546-a72d-b6a01faa9a7bn%40googlegroups.com.

[go-nuts] How To: use your local workspace in staged container image build...

[TheDiveO]

This probably fits in very well with the "nuts" part of the golang-nuts 
group, so here we go: in some of my projects I typically build and deploy 
locally in a container to see that the service work correctly at least 
locally. Now, these projects tend to depend on several of my own separate 
Go modules. Unit testing locally is easy, but in several cases my services 
depend on more stuff that is unwieldy to build so I prefer having this all 
done in a staged container image build.

Can I get my workspace "somehow" into my multi-stage build...?

Well, looks like it is doable, albeit with some limitations due to the 
Dockerfile syntax. So, here we are and I would like to ask kindly for kind 
feedback ... also available as a gist 
<https://gist.github.com/thediveo/0d8b6ae7f88918c2571890e508468b23>.

The illustrative example assumes a filesystem setup as follows:

   - foobar-ws/
  - bar/
 - bar.go
 - go.mod
  - foo/
 - foo.go
 - go.mod
  - foobar/
 - deployments/foobar/
- *Dockerfile*
 - go.mod
 - go.sum
 - main.go
 - *Makefile*
  
The Makefile:
MAINUSE:=./foobar
EMPTYCONTEXT:=.emptyctx NUMCONTEXTS:=9 SHELL:=/bin/bash build: @# find out 
if we are in workspace mode -- and it we are, then the list of @# modules 
actually used. @mkdir -p $(EMPTYCONTEXT); \ trap 'rm -rf -- 
"$(EMPTYCONTEXT)"' EXIT; \ contexts=(); \ workspace_details=$$(go work edit 
--json); \ if [[ $${workspace_details} ]]; then \ goworkdir=$$(dirname 
$$(go env GOWORK)); \ echo "found workspace" $${goworkdir}; \ 
diskpaths=$$(echo $${workspace_details} | jq --raw-output '.Use | .[]? | 
.DiskPath'); \ echo "modules used in workspace:" $${diskpaths}; \ while 
IFS= read -r module; do \ if [[ "$${module}" == "$(MAINUSE)" ]]; then \ 
echo " " $${module}; \ else \ relcontext=$$(realpath --relative-to="." 
$${goworkdir}/$${module}); \ contexts+=( $${relcontext} ); \ echo " 里" 
$${module} "» " $${relcontext}; \ fi \ done <<< $${diskpaths}; \ else \ 
diskpaths="$(MAINUSE)"; \ fi; \ buildctxargs=(); \ buildargs=(); \ ctxno=1; 
\ for ctx in "$${contexts[@]}"; do \ buildctxargs+=( 
"--build-context=bctx$${ctxno}=$${ctx}" ); \ buildargs+=( 
"--build-arg=MOD$${ctxno}=./$$(basename ./$${ctx})/" ); \ 
((ctxno=ctxno+1)); \ done; \ for ((;ctxno<=$(NUMCONTEXTS);ctxno++)); do \ 
buildctxargs+=( "--build-context=bctx$${ctxno}=$(EMPTYCONTEXT)" ); \ done; 
\ echo "args:" $${buildctxargs[*]} $${buildargs[*]}; \ echo "build inside:" 
$${CWD}; \ docker build \ -f ./deployments/foobar/Dockerfile \ 
$${buildargs[@]} \ $${buildctxargs[@]} \ --build-arg=WSDISKPATHS="$$(echo 
$${diskpaths})" \ .

The Dockerfile:
FROM golang:1.20-alpine AS builder ARG WSDISKPATHS ARG MOD1=./ ARG MOD2=./ 
ARG MOD3=./ ARG MOD4=./ ARG MOD5=./ ARG MOD6=./ ARG MOD7=./ ARG MOD8=./ ARG 
MOD9=./ WORKDIR /ws # Copy the additionally used modules into the 
soon-to-be workspace. COPY --from=bctx1 . ${MOD1} COPY --from=bctx2 . 
${MOD2} COPY --from=bctx3 . ${MOD3} COPY --from=bctx4 . ${MOD4} COPY 
--from=bctx5 . ${MOD5} COPY --from=bctx6 . ${MOD6} COPY --from=bctx7 . 
${MOD7} COPY --from=bctx8 . ${MOD8} COPY --from=bctx9 . ${MOD9} # Finally 
copy in the main module containing a main package to be build. WORKDIR 
/ws/foobar COPY go.mod go.sum ./ RUN go mod download COPY *.go ./ # 
Establish the Go workspace WORKDIR /ws RUN go work init ${WSDISKPATHS} RUN 
go build -v -o /foobar ./foobar

A "make" inside foobar-ws/foobar will take over the current local workspace 
"use" configuration and then build the "main" application.


-- 
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/e6c8064b-2373-44e8-b439-1f4c71f150f3n%40googlegroups.com.

Re: [go-nuts] FATAL: ThreadSanitizer: unsupported VMA range FATAL: Found 39 - Supported 48 / go: added github.com/docker/docker v23.0.4+incompatible

[TheDiveO]

Watch out for the difference between the -- in my experience often terrible 
and "stable" yet outdated -- docker.io packages and the 
docker-ce packages, see also https://docs.docker.com/engine/install/ubuntu/ 
There’s also a license difference regarding the no-redistribution unless 
you build the packages yourself. Usually not a concern unless you 
distribute your own devices with your own distro on top of Debian, Ubuntu, 
...

Now, throwing in Nvidia into the mix isn't exactly helping things, as it 
seems to be totally unclear as to how they are wrapping things in order to 
allow GPU access from Docker contains. From the few things I've seen it 
appears to be a container *runtime* shim (as opposed to a container 
engine!) that wraps runc with some Nvidia "magic". But there might be other 
things going on, but this is almost impossible to diagnose with Nvidia's 
stance regarding OpenSource. But the Nvidia support should be able to help 
you with their own Hardware and recommended SW setup.
On Tuesday, April 25, 2023 at 10:05:57 PM UTC+2 Mario Marietto wrote:

> I've just discovered something that I find interesting. When I have 
> removed and purged docker with the following command :
>
> sudo apt-get purge -y docker.io
>
> It told me if I wanted to remove these packages :
>
> docker.io* nvidia-docker2*
>
> Look at the package called "nvidia-docker2" ; it may mean that there 
> exists a customized version of docker created by nvidia ? 
> Also look at the versions of the docker packages installed on the jetson 
> nano :
>
> # dpkg -l | grep -i docker
>  
> ii  docker1.5-2 
>   all   transitional package 
> ii  docker.io
> 20.10.21-0ubuntu1~22.04.2   arm64 Linux container runtime 
> ii  nvidia-docker2   2.8.0-1 
> all   nvidia-docker CLI 
> wrapper 
> ii  wmdocker  1.5-2
> arm64System tray for KDE3/GNOME2
>
> docker --version 
> Docker version 20.10.21, build 20.10.21-0ubuntu1~22.04.2
>
> Do you see something unusual ? maybe you will help me to understand if I 
> should refer to nvidia to fix the problem (anyway I can't do that,because 
> they don't support ubuntu 22.04 on the jetson nano).
>  
>
> On Tue, Apr 25, 2023 at 9:55 PM Mario Marietto  
> wrote:
>
>> Hello.
>>
>> I've got this file :
>>
>> https://github.com/moby/moby/archive/refs/tags/v23.0.4.tar.gz
>>
>> from the moby repository : https://github.com/moby/moby
>>
>> but I don't know what to do next. I don't see the instructions there. Can 
>> you point me to the right tutorial ? thanks.
>>
>> On Tue, Apr 25, 2023 at 9:18 PM TheDiveO  wrote:
>>
>>> Please do not install Docker as a snap, as this fundamentally breaks 
>>> several parts of Docker. This is a well known limitation of snap. Simply 
>>> install from the Docker repository, instructions are on the Docker website.
>>>
>>> Building Docker is complicated, as it predates Go modules and still has 
>>> no fully working mod (there's actually a vendoring mog that somehow gets 
>>> swapped in). If anything, build from moby/moby as this is now the official 
>>> source repo for building Moby (Docker). This is complicated and the 
>>> documentation warns any ambitious adventurer to expect a very bumpy ride. 
>>> Well, they phrase it differently.
>>>
>>> The pseudo version tag you're seeing is fine, at least in principle. I 
>>> see it also finally now when building Docker plugins.
>>>
>>> On Tuesday, April 25, 2023 at 7:47:44 PM UTC+2 Mario Marietto wrote:
>>>
>>>> ---> If you want to bring that tutorial up to date, I guess the best 
>>>> person to work with would be the author of the tutorial.
>>>>
>>>> I emailed him,but he didn't respond. There is no guarantee that the 
>>>> author of an old tutorial will reply to email messages. Rarely happens if 
>>>> the tutorials are old.
>>>>
>>>> ---> If your objective is to build Docker on a new platform, then maybe 
>>>> you should engage with the Docker project.
>>>>
>>>> What's a new platform ? Is the Jetson nano a new platform ? Anyway,the 
>>>> point is that I don't know where the error is. If it comes from the go 
>>>> modules (as it seems to me,according to what you are explaining),you are 
>>>> the 
>>>> predestined and at the docker forum wil

Re: [go-nuts] FATAL: ThreadSanitizer: unsupported VMA range FATAL: Found 39 - Supported 48 / go: added github.com/docker/docker v23.0.4+incompatible

[TheDiveO]

Please do not install Docker as a snap, as this fundamentally breaks 
several parts of Docker. This is a well known limitation of snap. Simply 
install from the Docker repository, instructions are on the Docker website.

Building Docker is complicated, as it predates Go modules and still has no 
fully working mod (there's actually a vendoring mog that somehow gets 
swapped in). If anything, build from moby/moby as this is now the official 
source repo for building Moby (Docker). This is complicated and the 
documentation warns any ambitious adventurer to expect a very bumpy ride. 
Well, they phrase it differently.

The pseudo version tag you're seeing is fine, at least in principle. I see 
it also finally now when building Docker plugins.

On Tuesday, April 25, 2023 at 7:47:44 PM UTC+2 Mario Marietto wrote:

> ---> If you want to bring that tutorial up to date, I guess the best 
> person to work with would be the author of the tutorial.
>
> I emailed him,but he didn't respond. There is no guarantee that the author 
> of an old tutorial will reply to email messages. Rarely happens if the 
> tutorials are old.
>
> ---> If your objective is to build Docker on a new platform, then maybe 
> you should engage with the Docker project.
>
> What's a new platform ? Is the Jetson nano a new platform ? Anyway,the 
> point is that I don't know where the error is. If it comes from the go 
> modules (as it seems to me,according to what you are explaining),you are the 
> predestined and at the docker forum will tell me that I should come exactly 
> where I am. 
>
> ---> Have you tried reporting *specifically* what problem you see, to 
> wherever you got the snap from? That would be Ubuntu Launchpad if it's a 
> snap package from Canonical's default snap store.  
>
> I suspect that the Ubuntu Launchpad developers will jump me to the nvidia 
> forum,since the error happens on ubuntu 22.04 which runs on their board. 
> And here is where the monkey falls. Yes because nVidia supports only the 
> old Ubuntu 18.04 and they will give no help with the 22.04.
>
> ---> It's possibly some sort of kernel-level or cgroup incompatibility, in 
> which case rebuilding Docker itself isn't going to help.
>
> I have already checked this. I've installed Ubuntu 20.04 on the Jetson 
> nano using the same kernel that I'm using on the 22.04 and docker worked. 
> So,it's not a kernel fault. Based on my (little) experience the error is 
> due to some component in the Ubuntu 22.04 userland,maybe tied with the GPU 
> drivers used by nVidia for Ubuntu 18.04. 
>
> On Tue, Apr 25, 2023 at 7:13 PM Brian Candler  wrote:
>
>> Like I said, those instructions are woefully out of date. Whilst the Go 
>> language has a compatibility guarantee for code written in Go, this does 
>> not apply to the tooling, which is subject to change over time.  One of the 
>> major changes was the introduction of Go modules 
>> .
>>
>> If you want to bring that tutorial up to date, I guess the best person to 
>> work with would be the author of the tutorial. If your objective is to 
>> build Docker on a new platform, then maybe you should engage with the 
>> Docker project - who presumably already have suitable up-to-date recipes 
>> for building Docker (which could also be used to update the tutorial). If 
>> you want to learn how the Go tooling works, then starting from a broken and 
>> out-of-date tutorial is definitely a baptism of fire :-)
>>
>> If I understand you correctly, you say that the snap package of docker 
>> works on your Arm/Linux host under Ubuntu 18.04 and 20.04 but not 22.04. 
>> Have you tried reporting *specifically* what problem you see, to wherever 
>> you got the snap from? That would be Ubuntu Launchpad if it's a snap 
>> package from Canonical's default snap store.  It's possibly some sort of 
>> kernel-level or cgroup incompatibility, in which case rebuilding Docker 
>> itself isn't going to help.
>>
>> One other thought: Go has a very good story around cross-compilation. You 
>> should be able to compile Arm binaries on an x86_64 machine, i.e. you don't 
>> need to run the compiler on the target itself. Whether Docker's build 
>> system (e.g. Makefiles) make use of that, I don't know.
>>
>> On Tuesday, 25 April 2023 at 17:47:30 UTC+1 Mario Marietto wrote:
>>
>>> I don't understand where the real error is. According with the tutorial 
>>> I should have this path :
>>>  
>>>
>>> ~/docker_build/src/github.com/docker/docker/hack/dockerfile/install
>>>
>>>
>>> instead,I have this one :
>>>
>>> ~/docker_build/pkg/mod/
>>> github.com/docker/doc...@v23.0.4+incompatible/hack/dockerfile/install 
>>> 
>>>
>>>
>>> I don't know if it is good or not,since I read "
>>> doc...@v23.0.4+incompatible".
>>>
>>> On Tue, Apr 25, 2023 at 6:29 PM Mario Marietto  
>>> wrote:
>>>
 Ok. So,the real error is not with godoc / go doc,but with the next 
 

[go-nuts] Re: Reduce memory usage via reduced padding?

[TheDiveO]

...would immediately *negatively affect* workhorses...

On Tuesday, April 18, 2023 at 8:26:27 PM UTC+2 TheDiveO wrote:

> The standard libraries in several parts define and also use structs where 
> the field ordering and padding is crucial as they are shared with operating 
> system functions. Trying to rearrange fields in 3rd party apllications 
> would immediately workhorses like Docker container engine, with associated 
> as well as independent modules for low-level networking configuration and 
> communication, communication with netfilter system functions on freebsd, 
> linux, and many more things.
>
> To rephrase a well-meant warning from a manager: there are better ways to 
> become prominent.
>
> On Tuesday, April 18, 2023 at 7:54:17 PM UTC+2 Def Ceb wrote:
>
>> Hello.
>> This is a request for comments on an idea I had.
>>
>> While working on a personal project, I noticed that quite a few structs 
>> in the standard library, exported or otherwise, could have their memory 
>> footprint reduced by simply reordering their members so that padding 
>> required for alignment is reduced or even eliminated.
>> This can be in exported and unexported structs, and in both exported and 
>> unexported fields.
>> Examples as of Go 1.20.3, on an amd64 host:
>>
>>- moving the member h of the unexported struct crypto/sha1.digest to 
>>the end would remove 4 bytes of padding between x and nx
>>
>>
>>- moving the unexported minInputLen field of the regexp.Regexp struct 
>>to right after matchcap will remove 6 bytes of padding
>>- The Typeflag member of archive/tar.Header could be moved to the end 
>>of the struct, removing 7 bytes of padding
>>
>> Instances similar to the first two examples should be fairly 
>> frictionless, only affecting code that makes unsafe assumptions about 
>> standard library internals.
>> Examples of the third would, at the very least, break unkeyed struct 
>> literals, either at compile-time or silently at run-time, depending on the 
>> types in use and whether the instantiation uses a compatible literal.
>> While implementing the third example does not seem to go against the Go 1 
>> compatibility promise, it would seem like a fairly unpopular change if it 
>> caused large swathes of code utilizing unkeyed struct literals to stop 
>> compiling or, worse, break silently, and unless using them is prohibited at 
>> some point (at least for non-locally-defined structs), it'll probably be 
>> avoided. As far as I can tell, the status is similar for Go assembly.
>>
>> As a benefit, this would lead to some small reductions in memory usage 
>> per instance of many structs, potentially leading to reduced need to grow 
>> the stack of threads. Though there are arguments that could be made against 
>> this as well, such as that some structs may contain multiple "groups" of 
>> data (which are not split up into multiple structs, for whatever reason) 
>> which shouldn't be split up, or that it could cause too much churn for too 
>> little benefit (I have not implemented nor benchmarked this at the moment), 
>> or that this is good, but it should be handled in the compiler instead.
>>
>> I already made something to automatically generate a list of structs in 
>> the standard library which have padding, based on my project.
>>
>>1. Would a pull request with struct reordering to reduce padding be 
>>welcomed?
>>2. Is there any chance of a policy of "try to avoid padding, if 
>>practical" being put in place for future additions to the standard 
>> library?
>>3. What about the gc compiler reordering struct member ordering at 
>>compile-time for the same effect, and in third-party code as 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bd28cd16-aa9d-4aa9-b93b-64acfa965ed3n%40googlegroups.com.

[go-nuts] Re: Reduce memory usage via reduced padding?

[TheDiveO]

The standard libraries in several parts define and also use structs where 
the field ordering and padding is crucial as they are shared with operating 
system functions. Trying to rearrange fields in 3rd party apllications 
would immediately workhorses like Docker container engine, with associated 
as well as independent modules for low-level networking configuration and 
communication, communication with netfilter system functions on freebsd, 
linux, and many more things.

To rephrase a well-meant warning from a manager: there are better ways to 
become prominent.

On Tuesday, April 18, 2023 at 7:54:17 PM UTC+2 Def Ceb wrote:

> Hello.
> This is a request for comments on an idea I had.
>
> While working on a personal project, I noticed that quite a few structs in 
> the standard library, exported or otherwise, could have their memory 
> footprint reduced by simply reordering their members so that padding 
> required for alignment is reduced or even eliminated.
> This can be in exported and unexported structs, and in both exported and 
> unexported fields.
> Examples as of Go 1.20.3, on an amd64 host:
>
>- moving the member h of the unexported struct crypto/sha1.digest to 
>the end would remove 4 bytes of padding between x and nx
>
>
>- moving the unexported minInputLen field of the regexp.Regexp struct 
>to right after matchcap will remove 6 bytes of padding
>- The Typeflag member of archive/tar.Header could be moved to the end 
>of the struct, removing 7 bytes of padding
>
> Instances similar to the first two examples should be fairly frictionless, 
> only affecting code that makes unsafe assumptions about standard library 
> internals.
> Examples of the third would, at the very least, break unkeyed struct 
> literals, either at compile-time or silently at run-time, depending on the 
> types in use and whether the instantiation uses a compatible literal.
> While implementing the third example does not seem to go against the Go 1 
> compatibility promise, it would seem like a fairly unpopular change if it 
> caused large swathes of code utilizing unkeyed struct literals to stop 
> compiling or, worse, break silently, and unless using them is prohibited at 
> some point (at least for non-locally-defined structs), it'll probably be 
> avoided. As far as I can tell, the status is similar for Go assembly.
>
> As a benefit, this would lead to some small reductions in memory usage per 
> instance of many structs, potentially leading to reduced need to grow the 
> stack of threads. Though there are arguments that could be made against 
> this as well, such as that some structs may contain multiple "groups" of 
> data (which are not split up into multiple structs, for whatever reason) 
> which shouldn't be split up, or that it could cause too much churn for too 
> little benefit (I have not implemented nor benchmarked this at the moment), 
> or that this is good, but it should be handled in the compiler instead.
>
> I already made something to automatically generate a list of structs in 
> the standard library which have padding, based on my project.
>
>1. Would a pull request with struct reordering to reduce padding be 
>welcomed?
>2. Is there any chance of a policy of "try to avoid padding, if 
>practical" being put in place for future additions to the standard library?
>3. What about the gc compiler reordering struct member ordering at 
>compile-time for the same effect, and in third-party code as 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bc9c3759-0a7a-441b-a1a1-e762a738ce34n%40googlegroups.com.

[go-nuts] httptest.ResponseRecorder and superfluous WriteHeader calls

[TheDiveO]

While maintaining my Go spaserve <https://github.com/thediveo/spaserve> 
module for serving single-page applications with client-side DOM routing 
and on different routes simultaneously I noticed different logging behavior 
between http.timeoutWriter.WriteHeader 
<https://cs.opensource.google/go/go/+/master:src/net/http/server.go;drc=457fd1d52d17fc8e73d4890150eadab3128de64d;l=3478>
 
and httptest.ResponseRecorder.WriteHeader 
<https://cs.opensource.google/go/go/+/master:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=143>
.

While the "production" response writer explicitly logs and thus warns of 
superfluous WriteHeader calls, the testing response recorder doesn't and 
stays silent. I would have expected that an httptest response recorder 
would at least also log any superfluous calls, or better, somehow report 
such superfluous calls in a way that tests can check and fail where 
necessary.

Would it make sense to create a feature request issue for httptest?

What would be a good design to make httptest detect and preferably 
immediately report superfluous calls to WriteHeader in order immediately 
detect the "offending" call site? I recon that calling panic would be 
rather rude. Would an additional (new) "SuperfluousWriteHeader func()" 
struct field in ResponseRecorder be an acceptable proposal? 
SuperfluousWriteHeader would be called if non-nil and would be used by 
tests to wire into their particular testing harness.

Other ideas and suggestions?

Note bene: at the moment, I'm wrapping httptest's ResponseRecorder in my 
own WrappedResponseRecorder 
<https://github.com/thediveo/spaserve/blob/0ce0b260904d187f0dda2989bac2cafee228ad34/test/httptest/recorder.go#L30>.
 
Maybe there's a better way to do 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/61c0dd07-e6d1-4008-936c-9a4c25be2fd2n%40googlegroups.com.

[go-nuts] Re: How to constraint type parameter not pointer

[TheDiveO]

How could I forget https://github.com/samber/mo...?

On Saturday, March 18, 2023 at 7:00:03 PM UTC+1 TheDiveO wrote:

> Maybe (no pun intended) implementations like 
> https://github.com/OlegStotsky/go-monads and 
> https://github.com/TeaEntityLab/fpGo can shed some more light on your 
> question and implementation designs?
>
> On Saturday, March 18, 2023 at 11:37:59 AM UTC+1 李晓辉 wrote:
>
>> When I want to implement a Maybe[T any] type, the T can't be nil, but I 
>> can't find way to constraint this, can anyone give helps.
>
>

-- 
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/d7496478-3a2a-4473-b51e-e0f841df23a4n%40googlegroups.com.

[go-nuts] Re: How to constraint type parameter not pointer

[TheDiveO]

Maybe (no pun intended) implementations like 
https://github.com/OlegStotsky/go-monads and 
https://github.com/TeaEntityLab/fpGo can shed some more light on your 
question and implementation designs?

On Saturday, March 18, 2023 at 11:37:59 AM UTC+1 李晓辉 wrote:

> When I want to implement a Maybe[T any] type, the T can't be nil, but I 
> can't find way to constraint this, can anyone give helps.

-- 
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/5a9fc678-fae8-440a-ac74-d21abdb60fe6n%40googlegroups.com.

[go-nuts] Re: alignment of stack-allocated variables?

[TheDiveO]

Keith made me aware of the fact that my benchmark is using the 
binary.BigEndian interface instead of "unrolling" the interface to use the 
specific type at runtime.  

cpu: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
BenchmarkUnsafe-8   10   5.991 ns/op   0 
B/op  0 allocs/op
BenchmarkEnc-8  10   6.327 ns/op   0 
B/op  0 allocs/op

This now gets within 6% of the unsafe method.
On Saturday, March 4, 2023 at 3:53:42 PM UTC+1 TheDiveO wrote:

> Keith, thank you very much for your feedback, it is highly appreciated!
>
> With this in mind, it's time for lies, more lies, and statistics, 
> benchmarking the three different implementations below:
>
> func (r *Reader) Uint32() uint32 {
> if r.err != nil {
> return 0
>
> }
> var s struct {
> _ [0]uint32
> b [4]byte
> }
> _, r.err = r.buff.Read(s.b[:])
> if r.err != nil {
> return 0
> }
> return *(*uint32)(unsafe.Pointer([0]))
> }
>
> func (r *Reader) Uint32X() uint32 {
> if r.err != nil {
> return 0
> }
> var v uint32
> _, r.err = r.buff.Read((*[4]byte)(unsafe.Pointer())[:])
> if r.err != nil {
> return 0
> }
> return v
> }
>
> func (r *Reader) Uint32N() uint32 {
> if r.err != nil {
> return 0
>
> }
> b := make([]byte, 4)
> _, r.err = r.buff.Read(b)
> if r.err != nil {
> return 0
> }
> return hostnative.Uint32(b)
> }
>
> The benchmarking results using "go test -bench=. -benchtime=60s -benchmem 
> .":
>
> cpu: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
> BenchmarkReadUint32
> BenchmarkReadUint32-8   10   5.974 ns/op   
> 0 B/op  0 allocs/op
> BenchmarkReadUint32X
> BenchmarkReadUint32X-8  10   5.977 ns/op   
> 0 B/op  0 allocs/op
> BenchmarkReadUint32N
> BenchmarkReadUint32N-8  10  20.81 ns/op   
>  4 B/op  1 allocs/op
>
> The two "unsafe" contenders are absolutely neck-to-neck, so in terms of 
> better readability and maintainability your proposed variant wins for me. 
> And as I was somehow suspecting, encoding/binary takes almost 4 times as 
> much as the first two implementations, and throwing a needless heap 
> allocation into the bargain. 
>
> On Saturday, March 4, 2023 at 1:20:01 AM UTC+1 Keith Randall wrote:
>
>> If you're using unsafe anyway, I'd go the other direction, casting from 
>> the larger alignment to the smaller one. That avoids any alignment concerns.
>>
>> var x uint32
>> b := (*[4]byte)(unsafe.Pointer())[:]
>> r.buff.Read(b)
>> return x
>>
>> I would encourage you to use encoding/binary though. It all works out 
>> just as well without unsafe, with a bit of trickiness around making sure 
>> that calls can be resolved and inlined.
>>
>> b := make([]byte, 4)
>> buf.Read(b)
>> if little { // some global variable (or constant) you set
>>return binary.LittleEndian.Uint32(b)
>> }
>> return binary.BigEndian.Uint32(b)
>> On Friday, March 3, 2023 at 12:30:37 PM UTC-8 TheDiveO wrote:
>>
>>> In dealing with Linux netlink messages I need to decode and encode 
>>> uint16, uint32, and uint64 numbers that are in an arbitrary aligned byte 
>>> buffer in an arbitrary position. In any case, these numbers are in native 
>>> endianess, so I would like to avoid having to go through encoding/binary.
>>>
>>> buff := bytes.NewBuffer(/* some data */)
>>>
>>> // ...
>>>
>>> func foo() uint32 {
>>> var s struct {
>>> _ [0]uint32
>>> b [4]byte
>>> }
>>> r.buff.Read(s.b[:])
>>> return *(*uint32)(unsafe.Pointer([0]))
>>> }
>>>
>>> Will the go compiler (1.19+) allocate on the stack with the correct 
>>> alignment for its element b, so that the unsafe.Pointer operation correctly 
>>> works on different CPU architectures?
>>>
>>> Or is this inefficient anyway in a subtle way that my attempt to avoid 
>>> non-stack allocations is moot anyway?
>>>
>>

-- 
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/3e632724-a13d-42bc-a3ef-9c3bf2d88a26n%40googlegroups.com.

[go-nuts] Re: alignment of stack-allocated variables?

[TheDiveO]

Keith, thank you very much for your feedback, it is highly appreciated!

With this in mind, it's time for lies, more lies, and statistics, 
benchmarking the three different implementations below:

func (r *Reader) Uint32() uint32 {
if r.err != nil {
return 0
}
var s struct {
_ [0]uint32
b [4]byte
}
_, r.err = r.buff.Read(s.b[:])
if r.err != nil {
return 0
}
return *(*uint32)(unsafe.Pointer([0]))
}

func (r *Reader) Uint32X() uint32 {
if r.err != nil {
return 0
}
var v uint32
_, r.err = r.buff.Read((*[4]byte)(unsafe.Pointer())[:])
if r.err != nil {
return 0
}
return v
}

func (r *Reader) Uint32N() uint32 {
if r.err != nil {
return 0
}
b := make([]byte, 4)
_, r.err = r.buff.Read(b)
if r.err != nil {
return 0
}
return hostnative.Uint32(b)
}

The benchmarking results using "go test -bench=. -benchtime=60s -benchmem .
":

cpu: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
BenchmarkReadUint32
BenchmarkReadUint32-8   10   5.974 ns/op   
0 B/op  0 allocs/op
BenchmarkReadUint32X
BenchmarkReadUint32X-8  10   5.977 ns/op   
0 B/op  0 allocs/op
BenchmarkReadUint32N
BenchmarkReadUint32N-8  10  20.81 ns/op 
   4 B/op  1 allocs/op

The two "unsafe" contenders are absolutely neck-to-neck, so in terms of 
better readability and maintainability your proposed variant wins for me. 
And as I was somehow suspecting, encoding/binary takes almost 4 times as 
much as the first two implementations, and throwing a needless heap 
allocation into the bargain. 

On Saturday, March 4, 2023 at 1:20:01 AM UTC+1 Keith Randall wrote:

> If you're using unsafe anyway, I'd go the other direction, casting from 
> the larger alignment to the smaller one. That avoids any alignment concerns.
>
> var x uint32
> b := (*[4]byte)(unsafe.Pointer())[:]
> r.buff.Read(b)
> return x
>
> I would encourage you to use encoding/binary though. It all works out just 
> as well without unsafe, with a bit of trickiness around making sure that 
> calls can be resolved and inlined.
>
> b := make([]byte, 4)
> buf.Read(b)
> if little { // some global variable (or constant) you set
>return binary.LittleEndian.Uint32(b)
> }
> return binary.BigEndian.Uint32(b)
> On Friday, March 3, 2023 at 12:30:37 PM UTC-8 TheDiveO wrote:
>
>> In dealing with Linux netlink messages I need to decode and encode 
>> uint16, uint32, and uint64 numbers that are in an arbitrary aligned byte 
>> buffer in an arbitrary position. In any case, these numbers are in native 
>> endianess, so I would like to avoid having to go through encoding/binary.
>>
>> buff := bytes.NewBuffer(/* some data */)
>>
>> // ...
>>
>> func foo() uint32 {
>> var s struct {
>> _ [0]uint32
>> b [4]byte
>> }
>> r.buff.Read(s.b[:])
>> return *(*uint32)(unsafe.Pointer([0]))
>> }
>>
>> Will the go compiler (1.19+) allocate on the stack with the correct 
>> alignment for its element b, so that the unsafe.Pointer operation correctly 
>> works on different CPU architectures?
>>
>> Or is this inefficient anyway in a subtle way that my attempt to avoid 
>> non-stack allocations is moot anyway?
>>
>

-- 
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/c87b6661-2ba6-4aa5-863b-4391cbb6f6c8n%40googlegroups.com.

[go-nuts] alignment of stack-allocated variables?

[TheDiveO]

In dealing with Linux netlink messages I need to decode and encode uint16, 
uint32, and uint64 numbers that are in an arbitrary aligned byte buffer in 
an arbitrary position. In any case, these numbers are in native endianess, 
so I would like to avoid having to go through encoding/binary.

buff := bytes.NewBuffer(/* some data */)

// ...

func foo() uint32 {
var s struct {
_ [0]uint32
b [4]byte
}
r.buff.Read(s.b[:])
return *(*uint32)(unsafe.Pointer([0]))
}

Will the go compiler (1.19+) allocate on the stack with the correct 
alignment for its element b, so that the unsafe.Pointer operation correctly 
works on different CPU architectures?

Or is this inefficient anyway in a subtle way that my attempt to avoid 
non-stack allocations is moot anyway?

-- 
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/ea8e7801-6caf-466b-8543-cfccfc76dd02n%40googlegroups.com.

Re: [go-nuts] Go 1.20 "cold start" slows down CI pipeline stages due to first building stdlib

[TheDiveO]

Many 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/c4e6eb0c-72c1-442c-bb77-3fa66e1491c4n%40googlegroups.com.

[go-nuts] Go 1.20 "cold start" slows down CI pipeline stages due to first building stdlib

[TheDiveO]

As Go 1.20 doesn't ship anymore with prebuild stlib packages, the first 
build after installation will take longer. Obviously, in a full Kubernetes 
build this is negligible (if not outward laughable). But for many small CI 
Go build stages this probably eats considerably into CPU time and energy 
consumption.

For instance, a small 
module https://github.com/thediveo/caps/actions/runs/4197604787 takes 
around 36s for Go 1.19 versus Go 1.20 with 63s (times for "go test" phase 
only).

Now I'm curious: is there some way to "preheat" Go 1.20 in order to cache 
the locally built Go stdlib?

-- 
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/e300c706-da67-4cb9-8a37-bf15bd041e7dn%40googlegroups.com.

Re: [go-nuts] Creating and Linking to Shared Library Version of Go Runtime? (with possible solution)

[TheDiveO]

If I read the 1.20 release notes correctly, there has been a change with 
how the compiled std lib not only is delivered (not anymore) and cached, so 
that it now ends up in the module cache. Maybe you can retry your 
experiments with 1.20 if this now works without the slightly ugly 
workarounds?

-- 
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/7eaa1e9a-04b9-4f8e-8f61-59bf350a02d3n%40googlegroups.com.

Re: [go-nuts] Creating and Linking to Shared Library Version of Go Runtime? (with possible solution)

[TheDiveO]

> So, the solution to problem #1 is to make sure a normal user can create
/usr/local/go/pkg/linux_amd64_dynlink and files in and underneath it.

While this is fine as a proof of concept and to diagnose the situation, I 
don't think that it can be called good advice to make /usr/local writeable 
to even one ordinary user ... or am I mistaking here something?
On Tuesday, January 31, 2023 at 3:37:39 AM UTC+1 jlfo...@berkeley.edu wrote:

> Thanks for the comments. I had to do it as root because running
>
> go install -buildmode=shared std
>
> as me results in
>
> go install internal/goarch: mkdir /usr/local/go/pkg/linux_amd64_dynlink: 
> permission denied
>
> As root, changing the ownership of /usr/local/go/pkg/linux_amd64_dynlink 
> to me, and then, as me, running
>
> go install -buildmode=shared std 
>
> ran to completion. So, the solution to problem #1 is to make sure a normal 
> user can create
> /usr/local/go/pkg/linux_amd64_dynlink and files in and underneath it.
>
> (I did all this after reinstalling go from scratch).
>
> However, none of this changed the possible creation of an possibly 
> unnecessary  shared lib, and the
> resulting build time penalty, e.g
>
> % time go build -linkshared t.go
> go build -linkshared t.go  1.22s user 0.29s system 103% cpu 1.455 total
> % time go build t.go
> go build t.go  0.10s user 0.04s system 132% cpu 0.102 total
>
> In looking at the commands executed by go build, I still see what looks 
> like a lot
> of extra work being done, but I'm not 100% sure. That's what I'm hoping a 
> Go
> expert can comment on. (I'd be happy to send the list of commands being 
> executed
> to anybody who wants it. )
>
> I agree it wouldn't make any sense for a shared library to be created that 
> only contains
> the code that my program needs. I was expecting for a shared library to be 
> created that
> contains the entire go runtime.
>
>  Jon
>
>
>
>

-- 
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/11ada17c-c62c-4e19-9c9d-3a71947afc7an%40googlegroups.com.

Re: [go-nuts] Creating and Linking to Shared Library Version of Go Runtime?

[TheDiveO]

Are the std/runtime .so's even versioned? How do you manage that?

Every time I'm feeling like finally being in $PARADISE out of the .so 
dependency $VERYVERYHOTPLACE there comes along the demand to go back. Sigh. 
;) 

On Sunday, January 29, 2023 at 9:26:51 PM UTC+1 bobj...@gmail.com wrote:

> I'm glad to see this issue getting some discussion. I have 100+ smallish 
> utility programs written in Go, and each one consumes about 1.5 MB (precise 
> average: 1,867,844 bytes); my bin directory contains 100+ copies of the Go 
> runtime. Sadly, I mainly use Windows, and there seems to be no way to use 
> linked libraries in Go for Windows.
>
> My solution has been to rewrite many of my smallish Go programs in Python 
> (except those that really need Go's speed)  -- 10K each vs. 1.5M each disk 
> storage. For these  manually invoked utilities, the speed difference is 
> often not noticeable. And the number of source lines and overall program 
> complexity is reduced by roughly 30%. (Added benefit: the Python programs 
> are always properly indented, even without a "pyfmt" program :-)
>
> I *am* a Go fan, and I understand that Go's mission is for writing big 
> server programs, but it's too bad that the size of a small Go program 
> executable is *many* times larger than a small C program.
> On Sunday, January 29, 2023 at 9:49:17 AM UTC-8 jlfo...@berkeley.edu 
> wrote:
>
>> The discussion of SSD wear and tear is going way off my original 
>> question. I'm sorry I even mentioned it.
>> Can we drop it?
>>
>> I'm still interested in the answer to the original question, which we've 
>> made some progress in answering.
>> As of now the answer is yes, subject to some permission and performance 
>> problems. I hope the experts
>> can shed some light on these. 
>>
>> Cordially,
>> Jon Forrest
>>
>>

-- 
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/d8f98822-c541-4508-b24c-c4a5596b160an%40googlegroups.com.

Re: [go-nuts] Go routine as realtime thread without preemption?

[TheDiveO]

> On Sunday, January 22, 2023 at 12:18:34 AM UTC+1 Ian Lance Taylor wrote: 
> Using runtime.LockOSThread does not exempt the goroutine from GOMAXPROCS. 

I was asking to elaborate more on this previous answer of yours, as I 
don'tunderstand yet how GOMAXPROCS relates to (preemptive?) go routine 
scheduling.

Cheers,
TheDiveO 

-- 
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/28f47dfb-f272-4c54-949f-72eb706798b6n%40googlegroups.com.

Re: [go-nuts] Go routine as realtime thread without preemption?

[TheDiveO]

On Sunday, January 22, 2023 at 12:18:34 AM UTC+1 Ian Lance Taylor wrote:
Using runtime.LockOSThread does not exempt the goroutine from GOMAXPROCS.

Hi Ian, thank you very much for your answer! I'm afraid that I do not yet 
understand (due to my limited runtime knowledge)  how to conclude from 
GOMAXPROCS that LockOSThread does not exclude locked go routine. Yet I'm 
intrigued to learn more, so can you please elaborate more?

Thank you very much!
TheDiveO

-- 
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/771c915d-1491-4f2d-845c-b33cff81e167n%40googlegroups.com.

[go-nuts] Go routine as realtime thread without preemption?

[TheDiveO]

When a go routine gets locked to an OS thread, does the Go runtime 
scheduler then stops interrupting this Go routine, so when this Go routine 
(or rather the thread) gets pinned to an exclusive CPU core can make use of 
real time priorities?

-- 
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/9637b72e-0747-4029-a18f-486d3d41525an%40googlegroups.com.

Re: [go-nuts] How can I use go with Modules

[TheDiveO]

My 2cents here. One of the most terrible examples of pre-mod repos I've 
encountered are Docker's engine repos, subsuming also the repos moved into 
the moby realm: they mostly lack module information and they break upon 
checking them out on master or go getting them and trying to build, even on 
a specific release tag. Trying to use them as a dependency is also a pain 
because you need to check the vendoring of the moby main repo in order to 
pin the precise dependencies you'll need. The only exception is the Docker 
API client ... it is a proper mod.

I only started working with Go in a serious and professional manner in my 
paid company work after modules were finally to settle at 1.12/1.13. 
Without modules I weren't using Go even to toy programming. Paint me a 
happy Gopher, more so as workspaces finally make working on multiple 
modules in lock step possible.

On Thursday, December 1, 2022 at 7:33:49 PM UTC+1 chri...@aperture.us wrote:

> Hi Jason,
>
> Your sentiment is understandable and was shared by many of us when modules 
> were first announced.
>
>  ..however..
>
> The points you're making here have been proven to be moot with modules in 
> the meantime. here's why;
>
> You can still clone a go repository anywhere you want and run the examples 
> / edit them. If you want to override dependencies you can use a go.work 
> file in the parent directory of the git repositories and clone the other 
> dependencies you want to override to that directory.
>
> So there's no reason to hate on go modules anymore and almost all projects 
> use it today.
>
> Please explain why you find downloading a fork of a repo more time 
> consuming with this approach and we will help explain how to do it quickly.
>
> Best regards,
> Christian
>
> On Thu, Dec 1, 2022, 9:12 AM Jason Bramsden  
> wrote:
>
>> BLUF: Is there any way to use the latest version of Go without Modules? 
>> Some flag or environment setting where I can disable it?
>>
>> I've been developing on Go since 2011, and I find Modules so frustrating! 
>> Life was so much easier without Modules, I could download packages from a 
>> git repo using go get, and they would be accessible in the go/src 
>> directory. I could then easily run the examples code and make changes all 
>> in a nice directory structure.  I don't care about what version the code is 
>> at, which makes Modules pointless for the way that I develop.
>>
>> With Modules, if I'm downloading a fork of a git repo, then it is so much 
>> more time-consuming, especially if the 3rd party fork code has issues. 
>>
>> I could go back to an earlier version of the Go or I could switch to 
>> another compiler like TinyGo. 
>>
>> -- 
>> 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/23540c6b-f0fe-4bed-9bc4-713965306257n%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/603b278e-898b-4a97-893b-caf04a36c8fdn%40googlegroups.com.

[go-nuts] Re: [ANN] new linter for "mixed pointer and value receivers"

[TheDiveO]

IMHO it might be of broader use to lint the cases where a value receiver is 
used and there are assignments to it or its fields ... or is this already 
caught by ineffassign? The recommendation leads to slightly "ugly" 
situations on a regular basis to enforce a pointer receiver on the Stringer 
method just for the sake of symmetry. Or am I misunderstanding this?

On Thursday, December 1, 2022 at 11:33:50 AM UTC+1 nikolay.d...@gmail.com 
wrote:

> *what?*
>
> New go vet compatible linter that detects mixing pointer and value method 
> receivers for the same type.
>
> https://github.com/nikolaydubina/smrcptr
>
> *why?*
>
> It is recommended in Go wiki and in Google Go style guide. It is very 
> common principle to keep code clean in practice and code reviews. Yet, 
> there is no open source linter for this.
>
> Thank you! ‍♂️
>
> -- Nikolay
>

-- 
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/8b0b2aa2-eb9e-4795-b9b6-d9605486d2f2n%40googlegroups.com.

[go-nuts] Re: Problems with array slicing reliability?

[TheDiveO]

On Wednesday, November 23, 2022 at 10:57:03 PM UTC+1 loji...@gmail.com 
wrote:

> [...] I am using an AMG64 computer with Windows 10, and *Go version 
> 0.36.0.* [*emphasis mine*]
>
 
Go version 0.36.0? Really?

-- 
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/965f9f48-2ee0-41fa-a6d3-ab2ecb3a9bcfn%40googlegroups.com.

Re: [go-nuts] Re: clarifying Go FAQ: Is Go an object-oriented language?

[TheDiveO]

Reading the "yes and no" part as a newcomer to Go actually made me snigger 
and I though that this kind of answer shows a thorough and differentiated 
thinking not shy of dealing with complexity as it is without trying to flee 
into simple and useless label simplification. IMHO the problem is not 
seeing concepts like OO as a fad, but instead the people struggling with 
complex topics and fleeing into blissful simplification. Maybe I should 
throw in here "embedding" so we might save on house heating this time of 
year.
On Thursday, November 24, 2022 at 12:49:27 PM UTC+1 kziem...@gmail.com 
wrote:

> "Saying "yes or no" is a non-answer. :)"
> From people new to coding, I guess so. For people with good background, 
> this is a good answer, since rest of the FAQ entry explain enough that they 
> can say "Ok. I think I'm getting it.". BTW in FAQ it is "Yes and no.".
>
> So true question is: who is asking and how detailed answer he or she needs?
>
> Best regards,
> Kamil
> czwartek, 24 listopada 2022 o 12:44:56 UTC+1 Kamil Ziemian napisał(a):
>
>> I will start with cautionary tell. At one of his public talks Bjarne 
>> Stroustrup in some way, admited that he made a very bad job when teaching 
>> people C++ and now we must live with many bad practices being a norm and 
>> even adviced as good practices. In Stroustrup words
>> "I didn't care about "Let them hear your message", "Show them the 
>> vision". I was thinking, that it just a rabbish. It is not.".
>>
>> I would classify all questions like "Is Go OOP language?" in the 
>> category  "Let them hear your message". People like Rob Pike, Robert 
>> Griesemer and Ian Lance Taylor probably don't need any labels like that, 
>> since, at the end of the day, these labels answer very little important 
>> questions and they can just go to the heart of the matter. But, let face 
>> it, very few people is on thier level, especiall among newcommers.
>>
>> We know how much hot topic was "generics in Go" (one of the less know 
>> part of the language in may case), when Robert Griesemer can just say in 
>> his talks about adding them to Go "Generics are just glorified (type 
>> checked) macros" (GopherCon 2020). For me it is one of the signs of how 
>> good people like Griesemer are: for them the many hottest topics are just 
>> "no big deal".
>>
>> Previously, rightly, it was observed that 1990s OOP was a huge fad. 
>> Unfortunetly, it is still big fad in many places. I'm from Poland, where 
>> the most popular book, which I read myself as the beginner, in the last 30 
>> years on C++ is written with this OOP fad spirit. And from many reasons, 
>> people in Poland in the age span 15-25 still today starts they programming 
>> journej with this book. People raised in such enviroment, when comming to 
>> any other language will be asking "Is it OOP?". Languages for which answer 
>> is "Yes" will be classified as "cool" and these for which answer is "No" as 
>> "Uncool, outdated and passe". Which is rabbish, but new people just don't 
>> know better.
>>
>> If this discussion about "Is X OOP language?" was just about which labels 
>> applies where, I would probably shrug and go do more important things. But, 
>> I consider it a case of "Let them hear you message" to use this slogan, and 
>> I happy to spend some of my time expleining people who ask what I 
>> understand about Go. For the same reason, I consider spending time in this 
>> thread, a things that can lead to something valuable.
>>
>> Best regards,
>> Kamil
>> czwartek, 24 listopada 2022 o 11:40:45 UTC+1 Kamil Ziemian napisał(a):
>>
>>> " Let me ask, because I'm genuinely curious: Why does it matter? The 
>>> labels we apply to things do not affect their function. Perhaps it affects 
>>> how we think about them. Is that it?"
>>> My point of view is that. In the moment when you learn the flow of 
>>> language X, it doesn't matter. But, it is not a thing that you get without 
>>> some work and many mistakes done along the way.
>>>
>>> Before that labels are important on at least two levels.
>>> 1) As promotion/marketing tool. If someone think that OOP is cool, he 
>>> would here that language X is OOP he would think "O, new language doing OOP 
>>> in new cool way. Maybe I should learn it? You know, OOP is cool".
>>> 2) As a guide for the people what to think and how to use about language 
>>> X. In the original post was already mention, that C++ and Java programers 
>>> have problem with writting good code in Go. My feeling is that, they try 
>>> write C++/Java code in Go, "they all OOP languages", which is missing the 
>>> point.
>>>
>>> Hard truth is that for most people, me included, our ways of thinking 
>>> (about everything) and of coding ossified and stiffen after a time and we 
>>> need to put quite a work to make them fresh and flexible again. To use 
>>> somewhat radicolous example, if you put label "bike" on washing machine 
>>> some people will try to ride to work on it and they will complaine, that is 

Re: [go-nuts] Re: Unicode variable name error

[TheDiveO]

I've always wondered how to deal with exported versus unexported 
identifiers in scripts like Chinese?

On Sunday, November 6, 2022 at 3:08:59 PM UTC+1 ba...@iitbombay.org wrote:

> In Indic scripts in certain contexts you have to use a vowel sign for the 
> typography to make sense; you can’t use a vowel letter in its place. So for 
> example the middle “ku” in my name has to be written as ક+ુ — which will be 
> rendered as કુ — even though it is equivalent to ક+્+ઉ. Also, “halant” (્), 
> is not a letter! 
>
> I would strongly urge Nikhilesh and other people wanting to use any Indic 
> script to **avoid* * it (even if Go implements TR31 as in Swift) and 
> instead use the lossless transliteration scheme of IAST if the program 
> calls for an Indian word as a Go object name.   
> https://en.wikipedia.org/wiki/International_Alphabet_of_Sanskrit_Transliteration
>   
> 
>
>
> On Nov 6, 2022, at 4:02 AM, Rob Pike  wrote:
>
> 
>
> % unicode -d పే
>
> U+0C2A 'ప' telugu letter pa
>
> U+0C47 'ే' telugu vowel sign ee
>
> % unicode -U C2A C47
>
> U+0C2A 'ప' TELUGU LETTER PA
>
> category: Lo
>
> canonical combining classes: 0
>
> bidirectional category: L
>
> mirrored: N
>
> U+0C47 'ే' TELUGU VOWEL SIGN EE
>
> category: Mn
>
> canonical combining classes: 0
>
> bidirectional category: NSM
>
> mirrored: N
>
> %
>
>
> The problem is the second code point, U+0C47, Telugu vowel sign EE. It is 
> not in the letter class. If I change your program to use just the first 
> code point, it works: https://play.golang.com/p/eNvuZH33s65
>
>
> The rules for identifiers in Go were chosen because they are easy to 
> implement, but they do have the problem that they do not treat all 
> languages equally. They may expand one day, but at the moment this is the 
> situation.
>
>
> There are a number of open issues around this. Start with 
> https://github.com/golang/go/issues/20706 if you want to read more.
>
>
> -rob
>
>
>
>
> On Sun, Nov 6, 2022 at 9:52 PM Konstantin Khomoutov  
> wrote:
>
>> On Sun, Nov 06, 2022 at 01:45:53PM +0530, Nikhilesh Susarla wrote:
>>
>> >> Per the Go spec[1], an identifier consists of a Unicode letter 
>> followed by
>> >> zero or more Unicode letters or digits. The character పే is in the 
>> Unicode
>> >> category nonspacing mark rather than the category letter.
>> [...]
>> > So, if the unicode letters are there in the nonspacing mark as you
>> > mentioned they can't be used right ?
>>
>> I sense the source of your misunderstanding might be rooted in your lack 
>> of
>> certain basics about Unicode. You seem to call "a letter" anything which 
>> may
>> appear in a text document (a Go source code file is a text document) but 
>> this
>> it not true. Maybe that's just a terminological problem, but still the 
>> fact
>> is, the Unicode standard calls "letters" a very particular group of things
>> among those the Unicode standard describes. To give a very simplified 
>> example,
>> in the text string "foo bar" there are six letters (five distinct) and one
>> space character which is not a letter. The charcter being discussed is 
>> not a
>> letter in Unicode, either.
>>
>> -- 
>> 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/20221106105154.xkoemtt6tx25flam%40carbon
>> .
>>
> -- 
> 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/CAOXNBZS085qwY5tXj%3Di5MeBguXeemHYBmSzjZks--MNmALohcg%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/f2f8e29a-9a71-441a-84ea-b7f9e3a82d8en%40googlegroups.com.

[go-nuts] Re: Why not sync.Mutex is designed as an interface

[TheDiveO]

>From my limited experience, I notice two things:

   1. I've rarely ever seen the need arise in my limited own experience to 
   copy objects that would like to share their mutex. I would rather consider 
   this to be most of the time a design issue, but I will be happy to stand 
   corrected. The rationale to me in these cases is that the mutex is 
   protecting a set of information closely "locked" to the lock it is 
   protecting it. When do you even copy the information? Surely not while you 
   don't have the lock, but then you end up with a locked copy. Now, if the 
   copies reference the same lock, what does that really mean? You have two 
   copies of the information, yet a single lock? Why then not having a single 
   source of information with a single lock or two sets of information that 
   can develop independently and have their own locks?
   2. Due to the way Interfaces work in Go you can define your own Mutex 
   interface and then sync.Mutex will be one implementation of it. (I hope 
   that I didn't miss something here, but that is what immediately came to my 
   mind.)


On Tuesday, November 8, 2022 at 4:55:13 PM UTC+1 xieyu...@gmail.com wrote:

> I checked with the issue about how to refer no-copy and the check of 
> cmd/vet. After checking, I'm curious that why not define mutex as an 
> interface, as interface always copy like a reference, which means users 
> don't worry to copy by value and cause an error.
>
> Design by the interface can always copy like a reference and no need to 
> mark it as cannot copy. However, we need to provide a default 
> implementation of the mutex and the construction of mutex is not short and 
> clean anymore.
>
> Would like to see how do you think about this confusion. 
>
> Regrads
>

-- 
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/1294c600-2078-46d3-bbad-50e0c80a3a28n%40googlegroups.com.

[go-nuts] Re: about upstream?

[TheDiveO]

I've seen both usages depending on the writers' perspectives. For that 
reason I avoid the terms upstream and downstream in this context (services) 
like the plague and always ask people for clarification without using these 
two words. It's always fun to see this then sparking totally surprised 
reaction in others taking part in those conversations.

The OP is perfectly right to ask this usinthe term "up/downstream" in the 
context of services, as I've seen and heard this often times for REST-based 
APIs, both from native as well as non-native speakers.

On Wednesday, November 2, 2022 at 10:15:51 AM UTC+1 cuiw...@gmail.com wrote:

> there are two micro service writen in go, let's call them A and B. A will 
> call B. In this scene we will call B is the upstream of A. or A is the 
> upstream of B? which one is correct way?

-- 
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/80af4dc5-3c18-4f2a-a52b-026a93d0dac8n%40googlegroups.com.

Re: [go-nuts] Go generics: type constraint for function or (non-type constraint) interface?

[TheDiveO]

Thank you! I was already expecting a twin no, but wanted to ensure that I 
didn't had overlooked something.

On Wednesday, September 28, 2022 at 9:12:16 PM UTC+2 
axel.wa...@googlemail.com wrote:

> No and no.
>
> On Wed, Sep 28, 2022 at 9:05 PM TheDiveO  wrote:
>
>> Is there currently a way in Go generics to express a type constraint to 
>> allow only
>> - any function
>> - any interface that isn't a type constraint, such as ~int
>> ?
>>
>> -- 
>> 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/16b6413d-fd37-4f37-8c42-7665764a465bn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/16b6413d-fd37-4f37-8c42-7665764a465bn%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/34e01742-0324-4d86-9c26-4000a8e876acn%40googlegroups.com.

[go-nuts] Go generics: type constraint for function or (non-type constraint) interface?

[TheDiveO]

Is there currently a way in Go generics to express a type constraint to 
allow only
- any function
- any interface that isn't a type constraint, such as ~int
?

-- 
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/16b6413d-fd37-4f37-8c42-7665764a465bn%40googlegroups.com.

Re: [go-nuts] importing Go is static linking or dynamic linking?

[TheDiveO]

Actually, it depends on which std libs are used. 
https://www.arp242.net/static-go.html is a concise introduction. net and 
os/user normally prevent a static binary, unless build tags netgo and 
osusergo are used.

On Monday, September 26, 2022 at 4:37:00 PM UTC+2 Ian Lance Taylor wrote:

> On Mon, Sep 26, 2022 at 7:22 AM Jessica Park
>  wrote:
> >
> > When java...
> > can import .jar ... in this case, we call dynamic link..
> >
> > How about golang?
> >
> > Is it dynamic linking or static linking?
>
> A pure Go program that does not use cgo will use static linking on
> most operating systems.
>
> A mixed Go/C program that does use cgo will use dynamic linking on
> most operating systems.
>
> > I need clear information.
>
> A more precise answer will require more details as to exactly what you
> are doing and what operating system you are using.
>
> 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/4323a623-8bfe-459c-b662-392e89642fe6n%40googlegroups.com.

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

[TheDiveO]

small note here about the package naming -- to be taken with a larger grain 
of salt, as usual: you repeat and thus "stutter" on "Gothon/gothonSlice". 
I've looked into some existing slice generics examples that now pop up like 
mushrooms after a warm shower. They tend to simply stick with "slice" or 
"slices", even if this is deemed a **cough** generic name (*pun might be 
intended*).

Otherwise, as Jason White already said: don't expect too much interest in 
your work, but see it as an experiment. Of course, we might be proven wrong 
and then you'll see interest in those kind of helpers. However, be aware 
that you can easily considerable performance and then the main benefit 
would be to be more welcoming to Pythonistas at first, before having to 
refactor code to become more "native" to Go.

When I was coming from Python some years ago (and I still like Python!) I 
came with the explicit idea of "don't look back", dive into the Go 
ecosystem and learn their patterns first. Only with good experience, start 
to bring in things where Go might benefit from Python, but don't try to 
emulate P on G (or any other X on Y), unless you somehow need to 
lift-and-shift old code. Which rarely is a good idea, unless you have 
significant monetary investment and gain in doing so.

On Wednesday, August 31, 2022 at 5:43:59 PM UTC+2 andres...@rappi.com wrote:

> 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!

-- 
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/97789fa6-e940-4b34-bc7e-a2951e30cf1dn%40googlegroups.com.

[go-nuts] Re: Detachable context.Context?

[TheDiveO]

I'm wondering what the "sometimes" really is. More so as I had just this 
week to deal with the podman <http://podman.io>REST API client misuse of 
context. The still widely v3 client only carries private variables that 
point to the client object. It completely ignored deadlines and 
cancelations by using the background context for each request.

To be able to later upgrade to v4 I'm using a context mix in using 
github.com/thediveo/wye.

So what would be the sometimes use cases, are tunesischen due to arcane 
upstream API design or is there a good reason to pass value that really 
don't belong into a context? 

On Saturday, September 3, 2022 at 5:56:19 PM UTC+2 Alex Besogonov wrote:

> Hi!
>
> Let me give you some context. context.Context in Go serves two main 
> purposes:
> 1. Cancellation and timeout support.
> 2. A carrier of values, as a de-facto replacement for thread-local 
> variables.
>
> I have a problem with the first item. Cancellation and timeouts 
> automatically propagate to child contexts, which is usually a good thing. 
> However, sometimes it would be nice to be able to create child contexts 
> that share only values but not the timeout/cancellation.
>
> Typically it's needed if the code wants to start a background goroutine to 
> do some work. E.g. in pseudocode:
>
> func StartConnection(ctx context.Context, addr string) (err error) {
>   conn, err = net.DialWithContext(ctx, addr)
>   if err != nil { return err; }
>   go heartbeatFunc(ctx, conn);
> ...
> }
>
> Right now it's not possible to do that cleanly. The only way is to create 
> a brand new context and copy all the needed values. Which requires the code 
> to know which values might be needed.
>
> Is there an interest in proposal to add this functionality? It can look 
> like another method: `context.Detached(ctx context.Context)` that simply 
> does not add it to the parent cancellation tree.
>

-- 
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/439f2b53-6e9a-4e99-b085-7e64565234bfn%40googlegroups.com.

Re: [go-nuts] Is Go a security malware risk?

[TheDiveO]

On Tuesday, August 23, 2022 at 8:47:11 PM UTC+2 Ian Lance Taylor wrote:

> On Tue, Aug 23, 2022 at 9:29 AM Robert Engels  
> wrote: 
> > 
> > I did not read the analysis - just the thread here and earlier threads 
> on this subject. My understanding that even though Go is statically linked 
> the loader does relocations that confuse virus scanners. 
>
> I'm not sure precisely what you mean, but I don't think that's 
> accurate. There is no Go loader. The statically linked binary 
> produced for a pure Go executable has no run-time relocations at all. 
>
> My assumption--and it is just an assumption--is roughly the reverse: 
> because pure Go programs are statically linked, and because the symbol 
> table does not use the same names as a default C symbol table, a virus 
> scanner has a harder time seeing which system calls are being used. 
> Of course the same would be true for a statically linked C program, 
> but perhaps malware writers tend to steer clear of those. 
>
> Obviously anything that Go is doing can also be done in C, but the 
> malware authors do have to work a bit harder to do that. 
>
> Ian 
>
> That's why you need to follow the defense in depth strategy. That's the 
reason for having things like seccomp (for syscall filtering), LSMs like 
AppArmor and SELinux (MACs), ... however, these are no silver bullets and 
actually either cause a false sense of security (especially AppArmor when 
it comes to not only Linux container technology using mount namespaces) or 
can easily grind your system to a total halt, like messing up your SELinux 
labels, preferably by your favorite long-term (in)stable Linux distribution 
not understanding the importance of certain file system tools in correctly 
handling extended file attributes containing SELinux labels. You need a 
great deal of deep understanding to operate them correctly and to achieve 
more than just to superfluous token security that your vendor delivers.

When an InfoSec starts to argue about Go (C, C++, JavaScript, ...) being 
unsafe, that enterprise has the worst enemy it can get: its own InfoSec. 
They have drunken deep from the well of Security Vendor cool aid.

-- 
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/61ccd71b-31bf-4fd8-849a-48359a9c3defn%40googlegroups.com.

[go-nuts] Re: Go multiplexers

[TheDiveO]

Looks like a TCP proxy or forwarder to me. For full duplex communicating 
you need two go routines per connection/session. And yes, needs something 
like a wait group for synchronization in order to handle half- closed 
connections properly, for client and server variants. 

On Sunday, August 21, 2022 at 2:15:21 PM UTC+2 Brian Candler wrote:

> "conn" is just a value, you can pass it around.  However, if you're 
> sharing it between multiple goroutines you need to be careful, i.e. you 
> need to synchronize properly. The synchronization solutions are very 
> specific to your application: e.g. you could wait for that goroutine to 
> finish with a sync.WaitGroup, or the goroutine could send you a message on 
> a channel when it's done.
>
> I don't know why you want to use multiple goroutines on the *same* 
> connection though.  (If you have multiple clients, they will open their own 
> TCP connections, which will be different "conn" objects).
>
> What you're now describing sounds very unlike "multiplexing", which I 
> would normally understand to be sending multiple independent sessions down 
> a single connection.
>
> On Sunday, 21 August 2022 at 12:32:27 UTC+1 ramki...@hotmail.com wrote:
>
>> My original issue is when using splice with  io.Copy (example below), for 
>> me to regain access to conn, In a different go routine, I use 
>> remote.Close() which ends the one of io.Copy commands but, the second 
>> io.Copy ends when conn sends a new packet. The error  use of closed network 
>> connection ends the io.Copy and every new packet conn sends, I can get with 
>> conn.Read() but the previous one is lost. 
>> I thought may be a multiplexer may help if I hope multiple streams for 
>> conn, I can end the splice while still reading all data with conn.Read() 
>> with a different stream.  
>>
>> io.Copy(conn, remote) 
>> go io.Copy(remote, conn)
>>
>>
>>
>> On Sunday, August 21, 2022 at 5:17:37 AM UTC-4 harald@gmx.net wrote:
>>
>>> do you even need a multiplexer? The common patten is to run Accept in a 
>>> loop that simply starts a new Go routine for every new accepted connection. 
>>> You only need a multiplexer of your application protocol needs multiplexing 
>>> inside an established TCP connection, either because there are multiple 
>>> destinations or multiple streams inside a single connection. 
>>>
>>>
>>> On Saturday, August 20, 2022 at 10:31:34 PM UTC+2 ramki...@hotmail.com 
>>> wrote:
>>>
 Has anyone ever used a multiplexer ? 
 When creating a TCP server using multiplexer, I get an error [ERR] yamux: 
 Invalid protocol version: 102 when using Telnet to connect to the server.

 package main

 import (
 "fmt"
 "net"

 "github.com/hashicorp/yamux"
 )

 func main() {
 server()
 }

 func server() {

 listener, _ := net.Listen("tcp", "0.0.0.0:1113")
 for {

 // Accept a TCP connection
 conn, err := listener.Accept()
 if err != nil {
 panic(err)
 }

 // Setup server side of smux
 session, err := yamux.Server(conn, nil)
 if err != nil {
 panic(err)
 }

 // Accept a stream
 stream, err := session.Accept()
 if err != nil {
 panic(err)
 }
 fmt.Println("DPOO")

 // Listen for a message
 buf := make([]byte, 4)
 stream.Read(buf)
 stream.Close()
 session.Close()
 }
 }



-- 
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/cef8cf40-fdfe-43ba-8a0a-5aefd6f16689n%40googlegroups.com.