Re: [go-nuts] GoImports version

[Jan Mercl]

On Fri, Oct 18, 2024 at 9:17 AM 'Axel Wagner' via golang-nuts
 wrote:

> I tried it out and the format parsed by debug.ParseBuildInfo is almost 
> exactly what is output by go version -m:
> https://go.dev/play/p/L-MNzr0EnjV
> (and yes, my goimports version is old)

And https://go.dev/play/p/bgeGr2hVCsb

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UhwrBUVg52a5MG0Ez1yje9nqEUWE_2Ow7z_RCkanCT4Q%40mail.gmail.com.

Re: [go-nuts] [ANN] tk9.0: The CGo-free, cross platform GUI toolkit for Go

[Jan Mercl]

On Mon, Oct 14, 2024 at 9:28 PM robert engels  wrote:

> This what it look like… it transpiles the libX library (on linux and osx 
> anyway), in order to bind to the X Window system.

darwin/macOS is supported by the purego project and on that target
Tcl/Tk uses Aqua, not XQuartz(X11) for the GUI.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-Vji1N8ep-rdvJcnSR_dJhr2VACyxj-U05Qohw8-YJV9w%40mail.gmail.com.

Re: [go-nuts] Re: [ANN] tk9.0: The CGo-free, cross platform GUI toolkit for Go

[Jan Mercl]

On Mon, Oct 14, 2024 at 9:16 PM 'Brian Candler' via golang-nuts
 wrote:

> Or it could be like https://pkg.go.dev/modernc.org/sqlite, which took the 
> Sqlite C source code and transpiled it into pure Go.

It's both, depending on target. The targets supported by
ebitengine/purego[0] link dynamically to the C libs at runtime. The C
dynamic libs are embedded in the executable.

The remaining ones are transpilled to pure Go and are doing syscalls.

  [0]: 
https://github.com/ebitengine/purego?tab=readme-ov-file#supported-platforms

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-X4Zsy4bfgSL-vTgwdXUwCt7rpqM956PmhqbEqKeX-Pxw%40mail.gmail.com.

Re: [go-nuts] Alignment guarantees of heap allocations

[Jan Mercl]

On Thu, Oct 10, 2024 at 2:23 PM 'Timo Beckers' via golang-nuts
 wrote:

> I've been searching around for some info or existing conversations around 
> this topic, but that hasn't turned up anything useful so far. I had a 
> question around some implicit behaviour of Go's heap allocator.

>From the specs point of view, there's no heap and no allocator. The
language specification covers allocation at
https://go.dev/ref/spec#Allocation, but the allocator is an
implementation detail with no particular guarantees.

> I'm working on implementing BPF map operations through direct shared memory 
> access (without going through syscalls). To make the API somewhat ergonomic, 
> I've settled on mmapping BPF map (kernel) memory over a part of the Go heap 
> using MAP_FIXED. Feel free to tell me how bad of an idea this is, I can 
> elaborate if needed.

I'm not sure what exactly do you mean by "over" as there is more than
one possibility I can think of. Go managed memory and manually mmaped
memory can intermix under certain conditions. One of them is that the
runtime must know which is which, ie. be able to distinguish pointers
to memory allocated by itself from memory allocated by something else
- manually mmaped, C allocated etc.

> In order for this to work and to minimize allocations, I need a heap 
> allocation that starts on a page boundary. Initially, I experimented with 
> //go:linkname'ing mallocgc(), but I figured allocating a regular slice the 
> size of a page has basically the same effect. Here's a playground link: 
> https://go.dev/play/p/ua2NJ-rEIlC. As long as the slice/backing array is a 
> multiple of the architecture's page size, it seems to start on a page 
> boundary. I've tried allocating a bunch of ballast, forcing GCs, etc. and it 
> hasn't failed once.

Those are guarantees possibly provided by the kernel. No promises from Go.

> Here's my question: which property of the Go allocator is this banking on? 
> Intuitively, this makes sense to me. An 8-byte alloc needs to be 8-byte 
> aligned in case it's a pointer. Does a 4k allocation need to be 4k-aligned as 
> well (e.g. in case it's a struct), since a compiler would align members to 
> the start of the struct? I'm reading larger (> 8 or 16 bytes depending on 
> arch?) allocs have an alignment of 1 byte, and unsafe.Alignof([4096]byte) 
> tells me the same, but that's not the behaviour exhibited by the allocator.

Implementation details that can change. You cannot rely on it. You
have to code it manually and look for platform details to work out.

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-Vot0daq2w0eCLUEU1gvJP3J32n-E86tkDwxMGT8YBMSQ%40mail.gmail.com.

Re: [go-nuts] Re: [ANN] tk9.0: The CGo-free, cross platform GUI toolkit for Go

[Jan Mercl]

On Wed, Oct 2, 2024 at 3:07 PM Mandolyte  wrote:

> What did I do wrong?

Copying the go.mod file effectively declares the code in hello.go to be in
package modernc.org/tk9.0.
That's the package hello.go imports, hence the import cycle. This works
here:

jnml@t3610:~/tmp$ mkdir tk
jnml@t3610:~/tmp$ cd tk
/home/jnml/tmp/tk
jnml@t3610:~/tmp/tk$ ls -la
total 8
drwxr-xr-x  2 jnml jnml 4096 Oct  2 15:15 .
drwxr-xr-x 17 jnml jnml 4096 Oct  2 15:15 ..
jnml@t3610:~/tmp/tk$ cp ~/src/modernc.org/tk9.0/_examples/hello.go .
jnml@t3610:~/tmp/tk$ go mod init example.com/hello
go: creating new go.mod: module example.com/hello
go: to add module requirements and sums:
go mod tidy
jnml@t3610:~/tmp/tk$ go mod tidy
go: finding module for package modernc.org/tk9.0
go: found modernc.org/tk9.0 in modernc.org/tk9.0 v0.29.1
jnml@t3610:~/tmp/tk$ CGO_ENABLED=0 go run hello.go
jnml@t3610:~/tmp/tk$

Hope this helps.

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-Xn2N5gWOZt%3DgEa%3DgHieh-MU7ZhC68Hsgd8QusfrYsObg%40mail.gmail.com.

Re: [go-nuts] [ANN] tk9.0: The CGo-free, cross platform GUI toolkit for Go

[Jan Mercl]

On Sat, Sep 28, 2024 at 10:09 PM 'Brian Candler' via golang-nuts
 wrote:

> Aside: on front page: "Viewing this on go.pkg.dev?"
>
> Actually I was viewing it on pkg.go.dev :-)

Thanks to D. Honnef on Slack for revealing to me the [invisible to me]
difference between go.pkg.dev and pkg.go.dev. Fix coming.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XfpC5AVFtTKq15qq9yKPBV0B2jia%3DEjvbee_6aZJGQbQ%40mail.gmail.com.

Re: [go-nuts] [ANN] tk9.0: The CGo-free, cross platform GUI toolkit for Go

[Jan Mercl]

On Sat, Sep 28, 2024 at 10:09 PM 'Brian Candler' via golang-nuts
 wrote:

> Aside: on front page: "Viewing this on go.pkg.dev?"
>
> Actually I was viewing it on pkg.go.dev :-)

The text in the picture tries to nudge you into expanding the
README.md section on go.pkg.dev, where it is collapsed by default. I
think it's a good introduction to the package to see some short demo
codes alongside the screenshots, but that opportunity can be easily
missed if one dives, head first, into the godocs.

The README.md is however also visible, not collapsed, at
https://gitlab.com/cznic/tk9.0, where the "click this" does not really
apply, hence the condition.

Compromises all the way down ;-)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-W0LTa%3D4Bak4EE%3D-W6%2B49mDwqGoR-Md43suiqc7itXE7A%40mail.gmail.com.

[go-nuts] [ANN] tk9.0: The CGo-free, cross platform GUI toolkit for Go

[Jan Mercl]

http://modernc.org/tk9.0

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XU3EHEks%2B9fgVGaPk4ZdnmWNQCiHFwYLpKNn1Th4Bfmw%40mail.gmail.com.

Re: [go-nuts] Perplexing error

[Jan Mercl]

On Mon, Sep 9, 2024 at 9:24 PM P Padil  wrote:

> Can someone please explain to me why the following doesn’t work:
>
> slices.SortFunc(ilps, func(u, w *big.Int) int { return u.Cmp(w) })
>
> I get:
> slices.SortFunc(ilps, (func(u, w *big.Int) int literal)) (no value) used as 
> value

Providing a complete, self-contained, runnable code help others to help you.

Without that I can only guess: you have used the non-value, as
indicated by the error message, as a RHS in an assignment. But its
signature shows it does not return any value:
https://pkg.go.dev/slices#SortFunc

tl;dr: SortFunc sorts the underlying array of the argument slice but
it does not return the slice.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UQfpTW_g8L3AFz3tu3whrQmGUWA44Q42adMsxb8y5Q2A%40mail.gmail.com.

Re: [go-nuts] Suppress GoFmt-generated error with/tools.go?

[Jan Mercl]

On Sat, Aug 31, 2024 at 2:22 PM Mike Schinkel  wrote:

> go fmt ./tools.go

'go fmt' is not gofmt. The OP talks about gofmt. I haven't tried
anything but you may try if using gofmt instead of 'go fmt' makes a
difference.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-Wz7YYvoF6Tb1PN4w6EbHkqALDgYnN%2BrtyPqW524VOmSQ%40mail.gmail.com.

Re: [go-nuts] Imitating tuple in golang

[Jan Mercl]

On Thu, Aug 8, 2024 at 9:35 PM 'lijh8' via golang-nuts
 wrote:

> I try to use slice of any to imitate the tuple type,
> and use this function to compare two slices: a, b.
>
> How can I improve it?

Take a look at https://pkg.go.dev/slices#Compare if it can fit your use 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/CAA40n-WNuMfS1auXeSQVwVBuftg_gwdP0orQ8Rwf3v7XS4TtWg%40mail.gmail.com.

Re: [go-nuts] this code sometimes hangs

[Jan Mercl]

On Thu, Jul 18, 2024 at 4:24 PM Lammie Jonson  wrote:
>   goroutineRunning.Done()

Should be

defer goroutineRunning.Done()

(not tested)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XpOke74VyM9Lk8ym0ntjDcG65nZ0hO2gq0_dCDT3NW5w%40mail.gmail.com.

Re: [go-nuts] Importing non-module based code

[Jan Mercl]

On Tue, Jul 16, 2024 at 3:57 PM Robert Engels  wrote:

> Yes, I just added that tag and pushed it, but @latest wouldn’t pick it up for 
> some reason, needed to specify the release exactly using @v0.3.1

@latest is the "latest" known to the proxy server. It has some varying
delay to update.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-Xa%3DdOAuRMfp6KbvN6%2Bry0eW%3DwwNVeS8WHkU0tAAOYYcw%40mail.gmail.com.

Re: [go-nuts] Importing non-module based code

[Jan Mercl]

On Tue, Jul 16, 2024 at 3:50 PM Robert Engels  wrote:
>
> Weird, even after I added the tag, using @latest did not pull the latest 
> code, I needed to specify the tag specifically @v0.3.1


I think I see the exported identifiers you need in v0.3.1, published
2018: https://pkg.go.dev/github.com/robaho/gocui@v0.3.1

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-X%3DX6bQY37FTOzjQiMW42VAPy0YryUECzoE1JLb16874Q%40mail.gmail.com.

Re: [go-nuts] Importing non-module based code

[Jan Mercl]

On Tue, Jul 16, 2024 at 3:41 PM 'Robert Engels' via golang-nuts
 wrote:

> The go get works, and the code is there, but it isn’t seeing my code - it 
> seems like it is using the original gocui which has since added module 
> support.
>
> cmd/client/main.go:43:7: gui.Update undefined (type *gocui.Gui has no field 
> or method Update)

>
> but these methods are defined in the robaho fork of gocui

Those methods are not defined:
https://pkg.go.dev/github.com/jroimartin/gocui@v0.3.0

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-W0Gef2KDJvwcePcy%2Bv-YQewj%3D84RT3eBfJRUEd48XsAQ%40mail.gmail.com.

Re: [go-nuts] Benchmark "overall" operation

[Jan Mercl]

On Mon, Jul 8, 2024 at 10:36 PM Robert Engels  wrote:

> Is there anyway to do what I want?

The usual way is to factor out any parts that can skew the results
before the benchmark loop and call b.ResetTimer() just before entering
the 'for i := 0; i < b.N; i++ {' loop.

> If not, maybe a useful addition, see 
> https://javadoc.io/doc/org.openjdk.jmh/jmh-core/latest/org/openjdk/jmh/annotations/OperationsPerInvocation.html
>  for a similar Java api.

I don't think it's useful. The testing package does IMO the right
thing. The task of the benchmark loop is to always do the same
unit/amount of work b.N times. Only then it all together makes sense
and can produce meaningful data about the unit/amount. It follows that
measuring O(b.N^2) algorithms cannot work very well. But you can often
measure b.N times a O(K^2) work using a constant K.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-X9ZC%3D9KczP%3D49QUKxyRcSkGL1RSScxd%3Dr02PEEuUtCgw%40mail.gmail.com.

Re: [go-nuts] Benchmark "overall" operation

[Jan Mercl]

On Mon, Jul 8, 2024 at 10:08 PM 'Robert Engels' via golang-nuts
 wrote:

> Given this code (which I know is not “correct”):

Setting b.N in the benchmark code has no specified behavior. The
actual behavior at the moment ignores such changes.

The algorithm used by the testing package adjusts b.N in an attempt to
stabilize the results under certain conditions. Ignoring this guidance
makes all attempts of that algorithm futile. And as it assumes the
benchmark body was executed b.N times anyway, it computes garbage.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UK65F%3DNp%2BkS59w_y-G%2BSQeFoh5V9b8Ezgt9TkGuzx-7g%40mail.gmail.com.

Re: [go-nuts] Does data race with only multiple goroutine parallel i=1 have an impact on the execution results?

[Jan Mercl]

On Sat, Jul 6, 2024 at 5:21 PM Robert Engels  wrote:

> That is not a data race. The wait group is a synchronization barrier.

Multiple concurrent, uncoordinated writers are a perfect data race.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-V4tRcSTjUFcuOKimukSMvHN%2BvMOE5sr16Eb-gjJa%3Dhww%40mail.gmail.com.

Re: [go-nuts] Comparison of pointers to distinct zero-sized variables

[Jan Mercl]

On Thu, Jun 20, 2024 at 1:26 PM 'Axel Wagner' via golang-nuts
 wrote:

> (apologies for the abundance of grammatical and spelling errors that occurred 
> during editing and of course only became visible after hitting "send")

(Send collapses the wave function  ;-)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-VMr0y%3D842etNGux4Xubc6B3dkhHxxrWtpSocpJsGxBfg%40mail.gmail.com.

Re: [go-nuts] Comparison of pointers to distinct zero-sized variables

[Jan Mercl]

On Thu, Jun 20, 2024 at 1:16 PM Oliver Eikemeier
 wrote:

> • Pointer types are comparable. Two pointer values are equal if they point to 
> the same variable or if both have value nil. Pointers to distinct zero-size 
> variables may or may not be equal.

Compare to (made up) "NaNs always compare non-equal". It talks both
about '3.14 == NaN' and 'NaN == NaN'. The plural in our context means
"any, all and every". It does not specify only the last case of two
NaNs.

My 2c.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-W%3D9EX5BFgVWibHF1nz5xDgX3Z3v6ptyD%2BeSwJLeBtSEg%40mail.gmail.com.

Re: [go-nuts] Comparison of pointers to distinct zero-sized variables

[Jan Mercl]

On Thu, Jun 20, 2024 at 12:28 PM Oliver Eikemeier
 wrote:

> It mentions “pointers” (plural) to zero-sized variables, but for this 
> behavior it is sufficient when only one pointer derives from a pointer to a 
> zero-sized variable, as demonstrated in the example below.

The plural is there because the specification discusses all such
pointers, not a particular case.

The wording is IMO correct and clear. All/any pointers (plural) to
zero sized objects may produce any/unpredictable result in comparison
operations. Relying on the outcome is a bug, because the specs
explicitly say otherwise.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-W8sYn56qRwX9ijEe9eK5bBxKCf_M2tX4_pxPMrWgi2hQ%40mail.gmail.com.

Re: [go-nuts] Symbol of const string are not exported by compiler

[Jan Mercl]

On Thu, May 30, 2024 at 10:34 AM Benoît Marguerie  wrote:

> I discovered a "strange" behavior doing a simple operation.
> I defined 2 const : one integer and one string. With delve (or other 
> debugger), I'm able to consult the const integer value but not the const 
> string value. Delve team explained me that the go compiler doesn't export 
> symbol of const string.
>
> Sorry for the newbee's question but is there anybody knowing why the symbol 
> can be exported for an integer but not for a string ?

Please include a code example that you're investigating using delve.
I, for one, cannot infer enough information from your post to be sure
what exactly is the problem and hence if the observed is - or is not -
an expected outcome.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-V0CAVBGHo-E1DgyA2cJaX8QjKRYNCgcGNu%2BkNL0Cg%3D0w%40mail.gmail.com.

Re: [go-nuts] encoding/asn1 I can't Marshal a struct with pointer members

[Jan Mercl]

On Sun, Apr 28, 2024, 03:03 J Liu <8859210...@gmail.com> wrote:

> My program is like this:
>
> type Girl struct {
>  Name string
>  Age  int
>  }
>
>  type Person struct {
>  girl *Girl
>  job string
>  }
>
>
> What should I do to Marshal 'Person'?
>


I think you need to export the fields, the same way like the Girl struct
have them exported, ie. by making the first character of the names upper
case.

hth

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-W72jqdGZSKvNvkj0V1DDuJLe3GczjeOZAKAEQGU6hD2A%40mail.gmail.com.

Re: [go-nuts] Is golang.org/x/text/message's Printer thread safe?

[Jan Mercl]

On Mon, Apr 22, 2024 at 11:23 AM Xiangrong Fang  wrote:

> Is golang.org/x/text/message's *message.Printer safe to use in goroutines?

I don't know, but usually things are safe for concurrent use by
multiple goroutines only when explicitly documented as such.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-X%2B88yorR_bnRLkzb6Ys_Ne3nA-aw_PvdNrR_U10YC_oA%40mail.gmail.com.

Re: [go-nuts] Nillable basic types?

[Jan Mercl]

On Mon, Mar 18, 2024 at 4:41 AM Daniel Lepage  wrote:

> This change would be entirely backward-compatible ...

Let's consider, for example, the type uint8, aka byte. A variable of
type byte is specified* to occupy 8 bits of memory and has 256
possible values. To represent all those values and the new possibility
of the value being nil, we need 257 distinct values. But that does not
fit 8 in bits anymore. However, changing the size and/or the bit
representation of such a variable is observable, making it not
backwards-compatible.


*: From https://go.dev/ref/spec#Numeric_types:


The value of an n-bit integer is n bits wide and represented using
two's complement arithmetic.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XCMSmhEDGL04NfhOVpexG3GCDA0Vj2dq138pWJVSBnwA%40mail.gmail.com.

Re: [go-nuts] GO111MODULE=off go get deprecated?

[Jan Mercl]

On Sun, Mar 3, 2024 at 10:25 PM Jeffery Carr  wrote:

> Has this been deprecated or maybe it is broken in debian sid, but:
>
> bash$ GO111MODULE=off go get -v go.wit.com/apps/test
> go: modules disabled by GO111MODULE=off; see 'go help modules'
> basj$ go version
> go version go1.22.0 linux/amd64
>
> this doesn't work anymore. Also, 'go help modules' is less than helpful.
>
> Is there some other way to download the actual sourcecode into
~/go/src/mything/ anymore?

One can get a somehow similar effect using 'auto' instead of 'off':

jnml@e5-1650:~/tmp/get$ ls -la
total 8
drwxr-xr-x 2 jnml jnml 4096 Mar  7 11:18 .
drwxr-xr-x 6 jnml jnml 4096 Mar  7 11:18 ..
jnml@e5-1650:~/tmp/get$ GOPATH=$(pwd) GO111MODULE=off go get -v
modernc.org/sqlite
go: modules disabled by GO111MODULE=off; see 'go help modules'
jnml@e5-1650:~/tmp/get$ GOPATH=$(pwd) GO111MODULE=auto go get -v
modernc.org/sqlite
go: downloading modernc.org/sqlite v1.29.2
go: downloading modernc.org/gc/v3 v3.0.0-20240107210532-573471604cb6
go: downloading golang.org/x/sys v0.16.0
go: downloading modernc.org/libc v1.41.0
go: downloading modernc.org/token v1.1.0
go: downloading modernc.org/mathutil v1.6.0
go: downloading github.com/dustin/go-humanize v1.0.1
go: downloading github.com/hashicorp/golang-lru/v2 v2.0.7
go: downloading modernc.org/strutil v1.2.0
go: downloading github.com/remyoudompheng/bigfft
v0.0.0-20230129092748-24d4a6f8daec
go: downloading github.com/google/uuid v1.3.0
go: downloading github.com/ncruces/go-strftime v0.1.9
go: downloading github.com/mattn/go-isatty v0.0.16
go: downloading modernc.org/memory v1.7.2
jnml@e5-1650:~/tmp/get$ ls pkg/mod/
cache  github.com  golang.org  modernc.org
jnml@e5-1650:~/tmp/get$  go version
go version go1.22.0 linux/amd64
jnml@e5-1650:~/tmp/get$

HTH

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UxFxrbrgZ%3Dn-hXYrrODjwDVX9uq995BWWLkjSf3G0XsQ%40mail.gmail.com.

Re: [go-nuts] Enums, Go1 and proposals

[Jan Mercl]

On Mon, Mar 4, 2024 at 6:19 PM Jeremy French  wrote:

> More, to prevent PrintMonth(14), which the function would have to check for 
> and either return an error or panic, since there is no meaningful output.  In 
> fact, it's fairly easy to see, even in this case, where the PrintMonth 
> signature would have to return an error, when that is pretty much the only 
> case where it would need to.  With an enum as an input parameter, the 
> PrintMonth() function would not need to have the error return value.  It's 
> the same type of philosophy around interfaces.  If you accept as an input 
> parameter an interface that has a PrintMonth() function, then you don't have 
> to double check that the passed struct/object has a PrintMonth() function. 
> You can just use it.

The static type of an interface can be verified at compile time. The
value of a variable of an enum type (or a Pascal-like subrange) type,
cannot be verified at compile time in the general case. You would have
to add features Go does not have (like variable immutability) and/or
restrict some features for enum types that Go does have (like taking
address and using unsafe). Neither looks to me very probable, at least
in a short time.

Those values can be however checked at runtime, similarly to
array/slice index bounds checking. For subrange-like enums it's rather
cheap and can be often eliminated. General, sparse-valued enums are
commonly too expensive to check at runtime for the compiler. to insert
them automatically.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-X3B8je11%3DmZ98UBwWLAVkmOB-LweJCd_QU5xVqd%3Duiqg%40mail.gmail.com.

Re: [go-nuts] Enums, Go1 and proposals

[Jan Mercl]

On Mon, Mar 4, 2024 at 4:19 PM Jeremy French  wrote:

> It's checked at compile-time rather than run time.

That requires immutability of variables of enum type. Go does not
support immutable variables.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-VuzKbH%2BztAMGqS867a0KqpE-v7t58dWMCJBdt1PDZ0Zg%40mail.gmail.com.

Re: [go-nuts] Equality of interface of an empty struct - why?

[Jan Mercl]

On Tue, Feb 27, 2024 at 6:20 AM tapi...@gmail.com  wrote:

> From common sense, this is an obvious bug. But the spec is indeed not clear 
> enough.
> It doesn't state whether or not comparisons of pointers to two distinct 
> zero-size variables should be consistent in a run session.
> Though, from common sense, it should.

"Pointers to distinct zero-size variables may or may not be equal."

The outcome is specified to be not predictable. Expecting consistency
means the outcome should be, or eventually become, predictable. That's
the opposite of what the specs say.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XN-U8JrVJ0uJqbftk2fNSiHEoDu7qsOde-FwHc5voSVg%40mail.gmail.com.

Re: [go-nuts] Unhappy with the official generics tutorial

[Jan Mercl]

On Thu, Feb 22, 2024 at 10:06 AM 'Carla Pfaff' via golang-nuts
 wrote:

> This omission is notable considering "any" is among the most frequently used 
> constraints in writing generic code.

Interesting to know, I'd naively guess the opposite. Can you please
share the source data set? 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/CAA40n-W2%3DBysk7OHi_OqV%3DM3EO_67JMyy5DjhBEpW7Gaa8FeKw%40mail.gmail.com.

Re: [go-nuts] Ghost/indirect dependency on a custom package

[Jan Mercl]

On Tue, Feb 20, 2024 at 11:07 AM Peter Bočan  wrote:

> Is there a way to debug this? Is there a way to step over the initialisation 
> order?

I try to get help from '$ go mod graph' in similar investigations.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-X8cnxAWpAJY%2BLq%3D4kvRtMi%2Badv6ahQ9G5z4_0A0SnctA%40mail.gmail.com.

Re: [go-nuts] big int panic on text conversion

[Jan Mercl]

On Wed, Feb 14, 2024 at 12:14 PM 'Dan Kortschak' via golang-nuts
 wrote:

> Given that this can happen without a race or unsafe modifications it
> might be worth filing a issue for.

I think this is expected. Quoting from the big.Int docs
https://pkg.go.dev/math/big#Int


To "copy" an Int value, an existing (or newly allocated) Int must be
set to a new value using the Int.Set method; shallow copies of Ints
are not supported and may lead to errors.


But OP's 'b := *a' is creating a shallow copy.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XGCwJHgqj7nMnkoF_sJcrdA3DsbM8OuVmmPNgqg7ZBXg%40mail.gmail.com.

Re: [go-nuts] How could we emulate condition variables using Go channels only?

[Jan Mercl]

On Fri, Jan 12, 2024 at 7:57 PM Rochus Keller  wrote:

> Here is the full question with examples (though meanwhile closed as usual in 
> recent times on stackoverflow, so answer here please): 
> https://stackoverflow.com/questions/77802102/mutex-and-condition-variables-in-go-without-using-the-sync-package
>
> This is a conceptual question based on the duality of monitors and message 
> passing. My goal is to see and be able to experiment with a correct and 
> complete example of a mutex with condition variables in Go which only use Go 
> channels for implementation, as a proof of concept. Only then we can discuss 
> how far it makes sense from an engineering standpoint.
>

Something like this? https://go.dev/play/p/_H3kFjprAGG

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UWgi%3D8OvAvs1gR3kudxxQFNfnFgDNLb3OUq-8iLAGrXw%40mail.gmail.com.

Re: [go-nuts] Re: Rendering fonts in Go

[Jan Mercl]

On Fri, Jan 12, 2024 at 12:34 PM 'Brian Candler' via golang-nuts
 wrote:

> At worst, it may possible to compile C into Go. It sounds mad, but I believe 
> SQLite has been ported to pure Go this way.

Challenge accepted: https://pkg.go.dev/modernc.org/libfreetype

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-URgHjw%3DarU1NZAo9XfQ%3DJ0qDwMiFZHPE-94NDuhQx%2B%2Bw%40mail.gmail.com.

Re: [go-nuts] Re: A global panic handler for crash reporting

[Jan Mercl]

On Tue, Dec 26, 2023 at 9:12 AM Gergely Brautigam  wrote:

> If you have a top level recover in you main, it doesn't matter where the 
> panic happens, you'll capture it. Even in third party library.

Iff the panic occurs in the same goroutine where the defer is. Every
go statement starts a new goroutine that is not affected by defer
statement(s) in other goroutines.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-V3eEVdouxr-uLiTvQSqNxmBSTCdpofUJ9rfFpDKB7Gpw%40mail.gmail.com.

Re: [go-nuts] circular package dependency between golang.org/x/mod and golang.org/x/tools

[Jan Mercl]

On Tue, Dec 19, 2023 at 9:37 PM Nathan Lacey  wrote:

> I noticed that we have a circular dependency between golang.org/x/mod and 
> golang.org/x/tools
>
>  golang.org/x/mod  zip/zip_test.go includes golang.org/x/tools
> I think we could get rid of the circular package dependency by changing that 
> unit test to remove the dependency to tools/txtar .

But why? What's the motivation to remove the cycle?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-URNGfDo34j4Ui-wvCiYjQysfMoJii%2B1m3CP_U85c0ezA%40mail.gmail.com.

Re: [go-nuts] Need help running "go get" on self hosted git server

[Jan Mercl]

On Mon, Dec 18, 2023 at 2:19 PM Brijesh Wawdhane 
wrote:

> I added a go-import meta tag to my git server's website on the repo page
and it looks like
>
> https://brijesh.dev/kairos.git";>
>
> but when I try running "go get brijesh.dev/kairos" I get an error saying
'go: unrecognized import path "brijesh.dev/kairos": reading
https://brijesh.dev/kairos?go-get=1: 404 Not Found'
>
> it is probably because it is looking at
https://brijesh.dev/kairos?go-get=1(which is invalid) and not
https://brijesh.dev/kairos.git?go-get=1(the correct address) even though it
the url is with .git in the go-import tag

I'm not sure what is correct, but FTR this redirector service reports the
redirected URL without the .git suffix and it works as intended:


jnml@3900x:~/tmp$ wget modernc.org/sqlite
--2023-12-18 14:57:40--  http://modernc.org/sqlite
Resolving modernc.org (modernc.org)... 216.239.34.21, 216.239.32.21,
216.239.38.21, ...
Connecting to modernc.org (modernc.org)|216.239.34.21|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://modernc.org/sqlite [following]
--2023-12-18 14:57:40--  https://modernc.org/sqlite
Connecting to modernc.org (modernc.org)|216.239.34.21|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 577 [text/html]
Saving to: 'sqlite'

sqlite
 
100%[=>]
577  --.-KB/sin 0s

2023-12-18 14:57:41 (20.6 MB/s) - 'sqlite' saved [577/577]

jnml@3900x:~/tmp$ cat sqlite




https://gitlab.com/cznic/sqlite";>
https://gitlab.com/cznic/sqlite/blob/master{/dir}
https://gitlab.com/cznic/sqlite/blob/master{/dir}/{file}#L{line}";>
https://godoc.org/modernc.org/sqlite";>


Redirecting to docs at https://godoc.org/modernc.org/sqlite";>
godoc.org/modernc.org/sqlite...


jnml@3900x:~/tmp$


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-We%3D%3Dsm812yorAgKgH8hZmM2Akm3P%2BpzpJR9dLD%2BfNV6w%40mail.gmail.com.

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

[Jan Mercl]

On Sun, Dec 10, 2023 at 8:34 PM Jason E. Aten  wrote:

> I noticed that the binary log was not growing, and its update timestamp was 
> not changing.

I think the file was still growing as intended. It was only no more
associated with the _new_ entry/name in the directory. I'm pointing it
out because it means no data is being lost until the FD of the
no-more-linked file is closed.

IOW, I think observing the file "no more growing" and "its time stamp
not updating" is now observing a different file than the one you're
writing the log to. That also means os.Stat("some_name") cannot help.
The "truth" is available at (*os.File).Stat().

HTH

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-X-PkBNARpYS6aXMMh7CCE5-U_T48fOtPR4EU77t0s8Cg%40mail.gmail.com.

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

[Jan Mercl]

On Sun, Dec 10, 2023 at 5:41 PM Jason E. Aten  wrote:

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

It is effective and [most] operations on the file continue to work as
usual. "Removing" a file, like in `os.Remove` is just removing one
reference to it. Only when the reference count drops to zero is the
file deleted.

This is, AFAIK, how nixes work and it's IMO actually a neat feature.
It enables, for example, updating files without disrupting processes
that have those files opened. Less advanced operating systems, to
achieve the same effect, have to reboot etc.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-VZDOdwMOqqmAc-RgpGyNkOi0LvyFR%2BKbzem4PqNNwrYQ%40mail.gmail.com.

Re: [go-nuts] Go ARM

[Jan Mercl]

On Wed, Nov 15, 2023 at 9:59 PM Stephen Illingworth
 wrote:
>
> That works better although not perfectly for my purposes. More work required 
> from me.
>
> I'm curious though, about the -marm flag. How can I remove it from the 
> GOGCCFLAGS variable? Or are we saying we can't use the aarch64 compiler in 
> conjunction with cgo?

Please share the output of '$ go version' and the output of '$ gcc
-dumpmachine'.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XALZibTeEh9erHvN74Wa_rwF%3Dqwb9Jgz15HadK_8hsxQ%40mail.gmail.com.

Re: [go-nuts] Go ARM

[Jan Mercl]

On Wed, Nov 15, 2023 at 8:30 PM Stephen Illingworth <
stephen.illingwo...@gmail.com> wrote:
> I'm trying to build a project on the Raspberry Pi, natively.
>
> Using "go env" I can see that Go has the following value for GOGCCFLAGS
>
> GOGCCFLAGS='-fPIC -marm -Wl,--no-gc-sections -fmessage-length=0
-ffile-prefix-map=/tmp/go-build745518569=/tmp/go-build
-gno-record-gcc-switches'
>
> However, the native compiler (gcc 12.2) does not have the -marm flag. The
compilation of the project fails.

>From the above I guess you might be running gcc for aarch64 as the arm
version accepts the -marm flag here:

jnml@pi32:~/tmp/gcc$ go version
go version go1.21.4 linux/arm
jnml@pi32:~/tmp/gcc$ cat main.c
#include 

int main() {
printf("Hello, world!\n");
}
jnml@pi32:~/tmp/gcc$ rm -f a.out ; gcc -marm main.c && ./a.out && echo ok
Hello, world!
ok
jnml@pi32:~/tmp/gcc$ gcc --version
gcc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

jnml@pi32:~/tmp/gcc$

I tried the solution from
https://jensd.be/1126/linux/cross-compiling-for-arm-or-aarch64-on-debian-or-ubuntu
and it seems to work fine:

jnml@pi64:~/tmp/gcc$ jnml@pi64:~/tmp/gcc$ go version
go version go1.21.4 linux/arm64
jnml@pi64:~/tmp/gcc$ cat main.c
#include 

int main() {
printf("Hello, world!\n");
}
jnml@pi64:~/tmp/gcc$ rm -f a.out ; gcc main.c && ./a.out && echo ok
Hello, world!
ok
jnml@pi64:~/tmp/gcc$ rm -f a.out ; gcc -marm main.c && ./a.out && echo ok
gcc: error: unrecognized command-line option ‘-marm’
jnml@pi64:~/tmp/gcc$ sudo apt install gcc-arm-linux-gnueabi
binutils-arm-linux-gnueabi
...
jnml@pi64:~/tmp/gcc$ rm -f a.out ; arm-linux-gnueabi-gcc -marm main.c &&
file a.out
a.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically
linked, interpreter /lib/ld-linux.so.3,
BuildID[sha1]=2191a16290d46b039bfae26fd5918106dff99749, for GNU/Linux
3.2.0, not stripped
jnml@pi64:~/tmp/gcc$

HTH

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UeuRqwty-w8Z%3D1%2B3rEt1xJqKYc%3DELCWK4DjUOzjuCRvw%40mail.gmail.com.

[go-nuts] Re: Why golang's garbage collector didn't free obj when an finalizer is associate with it？

[Jan]

That makes sense that if you have only one finalizer in the cycle, the 
ordering could be respected, thanks for pointing it out!

Now I still don't understand your explanation. The fact that the cycles can 
be arbitrarily deep is the same for normal GC, and it works without an 
issue. But I don't know how the GC works in Go -- last I read about GC was 
mark&sweep :) Any pointers to somewhere I could read about it ? 

I just re-read A Guide to the Go Garbage Collector 
<https://tip.golang.org/doc/gc-guide>, but it doesn't cover our topic -- 
also I find it odd that it talks about CPU costs, as opposed to memory 
bandwidth costs, since (I imaging) the mark phase time must be dominated by 
memory bandwidth due to the random access (as opposed to the sweep that I 
assume is sequential).

cheers

ps.: I also asked Bard and ChatGPT, but neither provided a good explanation.


On Tuesday, November 7, 2023 at 3:51:51 PM UTC+1 Michael Knyszek wrote:

> On Tuesday, November 7, 2023 at 2:32:28 AM UTC-5 Jan wrote:
>
> Btw, I don't follow the sentence:
>
> "the GC necessarily has to keep referents of the object-to-be-finalized 
> live even if the object isn't referenced anymore"
>
> That is true for objects not in cycles that need to be finalized as well. 
> I'm not sure I follow the reasoning here ...
>
> That fact alone isn't enough. When you couple that fact with the fact that 
> cycles can be arbitrarily deep, then you have a problem.
>
> Sorry, this is perhaps a weird framing since it's based on the 
> implementation details. Where I'm starting from is the example at the top 
> of this post, which is a cycle that has only a single finalizer. The point 
> I'm trying to make is that even having just a single finalizer in a cycle 
> is a problem. AFAICT, the dependency rules that both the Go GC and the 
> Boehm GC state could still be respected if each strongly connected 
> component of objects had just a single finalizer, since that entire 
> component could be finalized and freed before the next, and the ordering of 
> finalizers is preserved. (If I'm wrong about this point, disregard me. I'm 
> pretty sure but not certain that one could design a GC that did this.) But 
> having to identify such connected components would be a significant 
> performance limitation.
>
>
> Asking about it in Bard <http://bard.google.com>, it explains:
>
> " 
> In Go, objects that are in a cyclic structure and that are marked with a 
> finalizer (with SetFinalizer) don't get garbage collected when there are no 
> more live pointers to the cyclic structure because the garbage collector 
> cannot determine a safe order to run the finalizers.
> "
>
> Which seems to match the  Boehm collector 
> <https://www.hboehm.info/gc/finalization.html> explanation, described 
> under "Topologically Ordered Finalization".
>
> That is also true, but AFAICT only really applies to cycles containing 
> more than one finalizer. If a cycle (and I think more specifically, a 
> strongly connected component of objects) has just one finalizer, one could 
> argue such an ordering problem doesn't exist (unless I'm missing something 
> of course). Nonetheless, the cycle still isn't collected.
>
>
> On Tuesday, November 7, 2023 at 3:51:58 AM UTC+1 Michael Knyszek wrote:
>
> Yes, cycles containing a finalizer aren't guaranteed to be freed. As 
> others have pointed out, this is documented. SetFinalizer is really 
> designed for a narrow set of use-cases, so concessions were made for 
> overall GC performance. This case is one of them.
>
> IIUC, the core problem is a combination of the fact that the cycle can be 
> arbitrarily deep and the GC necessarily has to keep referents of the 
> object-to-be-finalized live even if the object isn't referenced anymore. 
> The GC must follow the pointers in an object's referents, and eventually it 
> may come upon the almost-dead object it started from. But at that point it 
> likely has no knowledge of where it came from. It's just a pointer on a 
> queue. A GC could be implemented that keeps track of where the pointers it 
> follows came from, but such an implementation would be substantially less 
> performant.
>
> Other GCs make the same choice. See the Boehm collector 
> <https://www.hboehm.info/gc/finalization.html>, for example.
> On Monday, November 6, 2023 at 10:20:39 AM UTC-5 Harish Ganesan wrote:
>
> Does this behaviour mean that, those memory will never be freed and keep 
> piling on ? That can be disastrous.
>
> On Monday, November 6, 2023 at 3:39:50 PM UTC+5:30 Jan wrote:
>
> For what it's worth, a bit of "memory management&quo

Re: [go-nuts] ldflags -X

[Jan Mercl]

On Wed, Nov 8, 2023 at 4:01 PM Stephen Illingworth
 wrote:

> I would have expected the "main.A" string to require the same form. But 
> either way, that's the correct solution.

It is the correct form. Package main cannot be imported and has a
special import path. Though I don't know where it is documented.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XswSrWE%2BwdEMy9PdVazFBKm2%2Bt8CGw1z9Z5UAMCDoUNw%40mail.gmail.com.

Re: [go-nuts] ldflags -X

[Jan Mercl]

On Wed, Nov 8, 2023 at 1:35 PM Stephen Illingworth <
stephen.illingwo...@gmail.com> wrote:
>
> Hello,
>
> I'm trying to use the -X ldflag to set a string at compile time. I can do
this successfully if the string is in the main package but it does not work
if the string is in a subpackage.
>
> For illustration purposes, I have prepared a simple test project
>
> https://github.com/JetSetIlly/ldflags_X_test
>
> The build.sh file contains the build string. It contains one useful line,
which I'll repeat it here:
>
> go build -ldflags "-X 'main.A=foo' -X 'sub.B=bar'"
>
> When built, the main function will print out the A string correctly but
the B string is unset.
>
> What am I doing wrong?

The second -X flag does not have the documented form, see
https://pkg.go.dev/cmd/link.

jnml@3900x:~/src/x/ldflags_X_test$ ls -l
total 16
-rwxr-xr-x 1 jnml jnml  101 Nov  8 13:47 build.sh
-rw-r--r-- 1 jnml jnml   55 Nov  8 13:47 go.mod
-rw-r--r-- 1 jnml jnml  144 Nov  8 13:47 main.go
drwxr-xr-x 2 jnml jnml 4096 Nov  8 13:47 sub
jnml@3900x:~/src/x/ldflags_X_test$ git diff
diff --git a/build.sh b/build.sh
index db86e35..0185e5e 100755
--- a/build.sh
+++ b/build.sh
@@ -1,3 +1,3 @@
 #!/bin/bash

-go build -ldflags "-X 'main.A=foo' -X 'sub.B=bar'"
+go build -ldflags "-X 'main.A=foo' -X '
github.com/JetSetIlly/ldflags_X_test/sub.B=bar'"
jnml@3900x:~/src/x/ldflags_X_test$ ./build.sh && ./ldflags_X_test
foo
bar
jnml@3900x:~/src/x/ldflags_X_test$

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XP7%2BiTS_aCR88%2Buuzi5Xo7ypHJeNDkczvHJUtzpjrE3Q%40mail.gmail.com.

[go-nuts] Re: Why golang's garbage collector didn't free obj when an finalizer is associate with it？

[Jan]

Btw, I don't follow the sentence:

"the GC necessarily has to keep referents of the object-to-be-finalized 
live even if the object isn't referenced anymore"

That is true for objects not in cycles that need to be finalized as well. 
I'm not sure I follow the reasoning here ...

Asking about it in Bard <http://bard.google.com>, it explains:

" 
In Go, objects that are in a cyclic structure and that are marked with a 
finalizer (with SetFinalizer) don't get garbage collected when there are no 
more live pointers to the cyclic structure because the garbage collector 
cannot determine a safe order to run the finalizers.
"

Which seems to match the  Boehm collector 
<https://www.hboehm.info/gc/finalization.html> explanation, described 
under "Topologically Ordered Finalization".

On Tuesday, November 7, 2023 at 3:51:58 AM UTC+1 Michael Knyszek wrote:

> Yes, cycles containing a finalizer aren't guaranteed to be freed. As 
> others have pointed out, this is documented. SetFinalizer is really 
> designed for a narrow set of use-cases, so concessions were made for 
> overall GC performance. This case is one of them.
>
> IIUC, the core problem is a combination of the fact that the cycle can be 
> arbitrarily deep and the GC necessarily has to keep referents of the 
> object-to-be-finalized live even if the object isn't referenced anymore. 
> The GC must follow the pointers in an object's referents, and eventually it 
> may come upon the almost-dead object it started from. But at that point it 
> likely has no knowledge of where it came from. It's just a pointer on a 
> queue. A GC could be implemented that keeps track of where the pointers it 
> follows came from, but such an implementation would be substantially less 
> performant.
>
> Other GCs make the same choice. See the Boehm collector 
> <https://www.hboehm.info/gc/finalization.html>, for example.
> On Monday, November 6, 2023 at 10:20:39 AM UTC-5 Harish Ganesan wrote:
>
>> Does this behaviour mean that, those memory will never be freed and keep 
>> piling on ? That can be disastrous.
>>
>> On Monday, November 6, 2023 at 3:39:50 PM UTC+5:30 Jan wrote:
>>
>>> For what it's worth, a bit of "memory management" on structures in many 
>>> cases is very ok (not sure if in your case). So for your cyclic structure 
>>> with finalizers, requiring the user of your code to call some "Finalize()" 
>>> method (some destructor method you define) that manually breaks the cycle, 
>>> often is an ok solution. Fundamentally, it's the same as requiring someone 
>>> to call Close() on an opened file (or any other resource, like sockets, db 
>>> connections, etc).
>>>
>>> As an anecdote, previously when I was doing C++ I was a big fan of 
>>> referenced counted smart pointers (`shred_ptr<>`), which gets most of the 
>>> benefit of GC, but with a much lower cost. They required manually breaking 
>>> cycles, which I didn't find to be an issue at all in the great majority of 
>>> the cases.
>>>
>>> On Monday, November 6, 2023 at 11:01:04 AM UTC+1 Jan wrote:
>>>
>>>> I was very surprised by this behavior of SetFinalizer: and indeed if 
>>>> you remove the SetFinalizer one can see that s1 is freed, because the 
>>>> memory reported by `m.HeapAlloc` goes back down.
>>>>
>>>> I think you already have the answer: the block that has the cycle (s1 
>>>> and s2) have a SetFinalizer set, and it will never run, per documentation 
>>>> (I had never paid attention to this).
>>>>
>>>> A suggestion to work around would be to move the stuff that needs a 
>>>> "Finalizer" to a leaf node, as in:
>>>>
>>>> https://go.dev/play/p/WMMTdAza6aZ
>>>>
>>>> But I understand this is not a solution if the finalizer needs to 
>>>> access the S1 (so, if the finalizer function needs any information that is 
>>>> not self-contained in `S1Data` in my example).
>>>> On Sunday, November 5, 2023 at 4:01:14 PM UTC+1 Soren Yang wrote:
>>>>
>>>>> As shown in the following code:
>>>>>
>>>>> cyclic structure with finalizer <https://go.dev/play/p/Fn_h08y-L6b>
>>>>>
>>>>> The s1 & s2 didn't been free, and finalizer didn't run. But when 
>>>>> enable the line which have been commented, all run as expected（s1 & s2 
>>>>> been 
>>>>> free）。
>>>>>
>>>>> I have seen the comment in runtime.SetFinalizer： If a cyclic 
>>>>> structure includes a block with a finalizer, that cycle is not guaranteed 
>>>>> to be garbage collected and the finalizer is not guaranteed to run, 
>>>>> because 
>>>>> there is no ordering that respects the dependencies.
>>>>>
>>>>> But why it haven't been free in first 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/2ce38690-5d75-45df-ab7f-0106a686e194n%40googlegroups.com.

[go-nuts] Re: Why golang's garbage collector didn't free obj when an finalizer is associate with it？

[Jan]

For what it's worth, a bit of "memory management" on structures in many 
cases is very ok (not sure if in your case). So for your cyclic structure 
with finalizers, requiring the user of your code to call some "Finalize()" 
method (some destructor method you define) that manually breaks the cycle, 
often is an ok solution. Fundamentally, it's the same as requiring someone 
to call Close() on an opened file (or any other resource, like sockets, db 
connections, etc).

As an anecdote, previously when I was doing C++ I was a big fan of 
referenced counted smart pointers (`shred_ptr<>`), which gets most of the 
benefit of GC, but with a much lower cost. They required manually breaking 
cycles, which I didn't find to be an issue at all in the great majority of 
the cases.

On Monday, November 6, 2023 at 11:01:04 AM UTC+1 Jan wrote:

> I was very surprised by this behavior of SetFinalizer: and indeed if you 
> remove the SetFinalizer one can see that s1 is freed, because the memory 
> reported by `m.HeapAlloc` goes back down.
>
> I think you already have the answer: the block that has the cycle (s1 and 
> s2) have a SetFinalizer set, and it will never run, per documentation (I 
> had never paid attention to this).
>
> A suggestion to work around would be to move the stuff that needs a 
> "Finalizer" to a leaf node, as in:
>
> https://go.dev/play/p/WMMTdAza6aZ
>
> But I understand this is not a solution if the finalizer needs to access 
> the S1 (so, if the finalizer function needs any information that is not 
> self-contained in `S1Data` in my example).
> On Sunday, November 5, 2023 at 4:01:14 PM UTC+1 Soren Yang wrote:
>
>> As shown in the following code:
>>
>> cyclic structure with finalizer <https://go.dev/play/p/Fn_h08y-L6b>
>>
>> The s1 & s2 didn't been free, and finalizer didn't run. But when enable 
>> the line which have been commented, all run as expected（s1 & s2 been free）。
>>
>> I have seen the comment in runtime.SetFinalizer： If a cyclic structure 
>> includes a block with a finalizer, that cycle is not guaranteed to be 
>> garbage collected and the finalizer is not guaranteed to run, because there 
>> is no ordering that respects the dependencies.
>>
>> But why it haven't been free in first 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/8caf932b-d9b4-45ae-b195-a8f323456665n%40googlegroups.com.

[go-nuts] Re: Why golang's garbage collector didn't free obj when an finalizer is associate with it？

[Jan]

I was very surprised by this behavior of SetFinalizer: and indeed if you 
remove the SetFinalizer one can see that s1 is freed, because the memory 
reported by `m.HeapAlloc` goes back down.

I think you already have the answer: the block that has the cycle (s1 and 
s2) have a SetFinalizer set, and it will never run, per documentation (I 
had never paid attention to this).

A suggestion to work around would be to move the stuff that needs a 
"Finalizer" to a leaf node, as in:

https://go.dev/play/p/WMMTdAza6aZ

But I understand this is not a solution if the finalizer needs to access 
the S1 (so, if the finalizer function needs any information that is not 
self-contained in `S1Data` in my example).
On Sunday, November 5, 2023 at 4:01:14 PM UTC+1 Soren Yang wrote:

> As shown in the following code:
>
> cyclic structure with finalizer 
>
> The s1 & s2 didn't been free, and finalizer didn't run. But when enable 
> the line which have been commented, all run as expected（s1 & s2 been free）。
>
> I have seen the comment in runtime.SetFinalizer： If a cyclic structure 
> includes a block with a finalizer, that cycle is not guaranteed to be 
> garbage collected and the finalizer is not guaranteed to run, because there 
> is no ordering that respects the dependencies.
>
> But why it haven't been free in first 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/ed3f71ce-33c8-4711-8a98-ae2409a33764n%40googlegroups.com.

Re: [go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Jan]

That works if what I'm doing is a end product (a server or something). But 
what I'm doing is in itself a library. Imagine if every library offers a 
docker/VM image, how is the end-user supposed to merge those docker images 
? The docker is also not a viable/ergonomic solution in my case. I mean ... 
actually I do offer a docker for one of my projects 
<https://hub.docker.com/r/janpfeifer/gomlx_jupyterlab>, along with Jupyter, 
a Tutorial and demo. But generically, it is a library, and I would like it 
to be easily `go get`able. Or at most with one simple/standard step.

Yes, I hear you with respect to unnecessary extra dependencies (X11) -- at 
least make them optional, right ? But In my case the dependencies are 
essential, and the docker doesn't really solve the problem...  But also I'm 
running out of hope that there would be anything to solve it, I'm almost 
thinking I should write something myself.


On Thursday, November 2, 2023 at 11:54:01 PM UTC+1 Jason E. Aten wrote:

> What I would do for that case would be to deliver the users a either a VM 
> image (heavy), or a docker container (lighter) with batteries included 
> inside. 
>
> There is often little need to write a docker file unless you really want. 
> Just get everything working inside docker and "docker commit" it to an 
> image. I do this often for projects that need python/R + 100s of 
> libraries.  Its really the only sane way to deliver sprawling dependencies 
> that assume they can write all over the filesystem.  
>
> One hint: I recently did this for code that wanted to output graphics, and 
> that needed X11 (or Xvfb), and that wanted systemd, which is available in 
> docker but used to be discouraged so is not available in many base images. 
> So I would recommend starting an docker image that already supports systemd 
> and X11, if graphics (or x11vnc, say) is ever going to be desired. Its a 
> pain to add after the fact. Podman claims to be useful for this, but I 
> found in immature and not really production ready when trying to run it on 
> blah standard Ubuntu 22.
>
> On Wednesday, November 1, 2023 at 9:08:51 PM UTC Jan wrote:
>
>> Thanks @Jason, but the point was exactly not need to do anything extra: 
>> no manual unzipping of a file, or manual Makefile/Magefile.
>>
>> Let's say project in Go links some 30 external modules, 5 of them have 
>> their own specific steps that need to be read, understood and and run to 
>> install them ... very quickly the user just gives up from 
>> installing/compiling the thing, with good reason ... 
>>
>> The Go toolset solves that beautifully for Go only projects. But at least 
>> in my line of work, that's not feasible, I need to interface with libraries 
>> that in turn require other libraries in C++ (OpenXLA/llvm for JIT), Rust 
>> (HuggingFace Tokenizer), C (Gtk), etc.
>>
>> cheers
>>
>>
>>
>>
>> On Monday, October 30, 2023 at 7:42:19 PM UTC+1 Jason E. Aten wrote:
>>
>>> > including the `.a` (static libraries) in the Github just got to its 
>>> limit (100Mb)
>>>
>>> I have used bzip2 to compress libraries that are too big for Github. If 
>>> that gets them under the limit, then great. 
>>> Just provide installation instructions or a Makefile target that 
>>> decompresses them once checked out.
>>>
>>> (Or xz? Apparently it can compress more than bzip2; but I have no 
>>> experience with it. https://en.wikipedia.org/wiki/XZ_Utils )
>>>
>>

-- 
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/58a7156a-94e8-4084-b82a-a7269d785089n%40googlegroups.com.

Re: [go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Jan]

Thanks @Jason, but the point was exactly not need to do anything extra: no 
manual unzipping of a file, or manual Makefile/Magefile.

Let's say project in Go links some 30 external modules, 5 of them have 
their own specific steps that need to be read, understood and and run to 
install them ... very quickly the user just gives up from 
installing/compiling the thing, with good reason ... 

The Go toolset solves that beautifully for Go only projects. But at least 
in my line of work, that's not feasible, I need to interface with libraries 
that in turn require other libraries in C++ (OpenXLA/llvm for JIT), Rust 
(HuggingFace Tokenizer), C (Gtk), etc.

cheers




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

> > including the `.a` (static libraries) in the Github just got to its 
> limit (100Mb)
>
> I have used bzip2 to compress libraries that are too big for Github. If 
> that gets them under the limit, then great. 
> Just provide installation instructions or a Makefile target that 
> decompresses them once checked out.
>
> (Or xz? Apparently it can compress more than bzip2; but I have no 
> experience with it. https://en.wikipedia.org/wiki/XZ_Utils )
>

-- 
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/096e5389-d183-4b2a-bb6b-b136398dc5acn%40googlegroups.com.

Re: [go-nuts] Re: recommended statistics package? Requirements: ANOVA, Brown-Forsythe

[Jan]

So cool!
On Monday, October 23, 2023 at 5:44:29 PM UTC+2 Martin Schnabel wrote:

> Hi,
>
> I attempted to translate the linked JS implementation for fun. Maybe 
> someone can use it as a starting point and correct or verify its 
> correctness.
>
> https://go.dev/play/p/Wrw2yDRof0z
>
> Have fun!
>
> On 10/23/23 07:38, Jan wrote:
> > hi, I did a quick search and I didn't find anything in Go. But looking 
> > at the definition and at one implementation in JS 
> > <
> https://github.com/lukem512/brown-forsythe-test/blob/master/src/brown-forsythe.js>,
>  
> it sounds something relatively easy to write and share :)  You can use the 
> R implementation to create some test datasets. Maybe gonum/stat <
> https://godocs.io/gonum.org/v1/gonum/stat> would be a potential home for 
> such a function ? What do you think ?
> > 
> > cheers
> > On Friday, October 20, 2023 at 10:54:55 AM UTC+2 王富民awaw wrote:
> > 
> > Hi follow Gophers
> > 
> > I wonder is there a canonical, verifiably correct Go package for
> > statistics?
> > In particular, Go code that does the Brown-Forsythe test of equal
> > variance.
> > Ideally in pure Go, but linking with CGo is OK.
> > 
> > A search on Google and pkg.go.dev <http://pkg.go.dev> does not
> > return helpful results.
> > I wonder is there anything that the community could share?
> > 
> > -- 
> > 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 
> > <mailto:golang-nuts...@googlegroups.com>.
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/golang-nuts/7ee10c0f-8af6-4b31-baaf-ce2ccb9c0211n%40googlegroups.com
>  
> <
> https://groups.google.com/d/msgid/golang-nuts/7ee10c0f-8af6-4b31-baaf-ce2ccb9c0211n%40googlegroups.com?utm_medium=email&utm_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/0b10338e-2fe8-4e55-b6c6-a7c2870df382n%40googlegroups.com.

[go-nuts] Re: recommended statistics package? Requirements: ANOVA, Brown-Forsythe

[Jan]

hi, I did a quick search and I didn't find anything in Go. But looking at 
the definition and at one implementation in JS 
,
 
it sounds something relatively easy to write and share :)  You can use the 
R implementation to create some test datasets. Maybe gonum/stat 
 would be a potential home for 
such a function ? What do you think ?

cheers 
On Friday, October 20, 2023 at 10:54:55 AM UTC+2 王富民awaw wrote:

> Hi follow Gophers
>
> I wonder is there a canonical, verifiably correct Go package for 
> statistics?
> In particular, Go code that does the Brown-Forsythe test of equal variance.
> Ideally in pure Go, but linking with CGo is OK.
>
> A search on Google and pkg.go.dev does not return helpful results.
> I wonder is there anything that the community could share?
>

-- 
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/7ee10c0f-8af6-4b31-baaf-ce2ccb9c0211n%40googlegroups.com.

Re: [go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Jan]

Thanks for all the replies. 

Unfortunately, as I found out today, including the `.a` (static libraries) 
in the Github just got to its limit (100Mb), so I don't think this is an 
option anymore :( I'm going to investigate the Gihtub LFS (Large File 
Storage), not sure how well it will integrate with `go get` though -- I've 
never used it before.

 Interesting to know that an empty Go package file is no longer needed to 
fetch a directory with binary dependencies (handy also for go:embed in 
cases where the binary files are on a separate directory).

Still for my Go library with a `.so` dependency I'm not sure yet what is 
the answer. I'm thinking about creating another tool that goes over all the 
dependencies of module, and automatically downloads release files to a 
configured directory ... so at least all one needs to do is execute one 
command and get all dependencies of all libraries installed. Any thoughts ?

@Mike Schinkel: the go:embed is used in a different context (when embedding 
blobs of binary). We need prebuilt binary libraries that will be 
linked with the Go code during compilation. Preferably something that will 
transparently work with `go get` / `go build` / `go install`.

cheers

On Tuesday, October 17, 2023 at 8:46:01 PM UTC+2 Justin Israel wrote:

> On Wednesday, October 18, 2023 at 3:12:29 AM UTC+13 Marc-Antoine Ruel 
> wrote:
>
> Sorry I wasn't clear. The static libraries are in a subdirectory because 
> the user should not care and these libraries are effectively third party 
> code.
>
>
> Actually, you were totally clear. Sorry if my comment didn't make sense. I 
> get that the user doesn't need to worry about the third_party directory 
> with the header and pre-built static libraries. And I saw how you arrange 
> to pick up the right ones in the code. My point was that from previous 
> experience, "go get" would prune away directories that do not contain go 
> source code, after it performs the clone from the remote, into the module 
> cache. So I would have expected that when someone uses your library as a 
> dependency, it would have omitted the needed third_party directory, for not 
> having any Go source files in it. But when I tested it just now, it does 
> seem to retain the subdirectory and link correctly. Maybe this was improved 
> as of recent Go releases. 
> In earlier versions of the Go tool, I would have either included a dummy 
> Go source file in the subdirectory, or just kept the non-go files in the 
> root with the rest of the Go source.
> Maybe someone else can clarify if this workflow has been improved?
>
>
> This declares the generic code available everywhere:
> https://github.com/periph/d2xx/blob/main/d2xx.go
>
> One set of files declare the import that is OS and CPU arch appropriate, 
> e.g. 
> https://github.com/periph/d2xx/blob/main/d2xx_linux_amd64.go
>
> Then another set of two files defines the OS specific code. In practice, 
> POSIX and windows;
> https://github.com/periph/d2xx/blob/main/d2xx_posix.go
> https://github.com/periph/d2xx/blob/main/d2xx_windows.go
>
> A CGO_ENABLED=0 build gets instead redirected to
> https://github.com/periph/d2xx/blob/main/d2xx_posix_no_cgo.go
> but not on windows because this package uses dynamic linking on windows. 
> Adapt as appropriate in your use case.
>
> I hope this helps.
>
> M-A
>
>
> Le lun. 16 oct. 2023, 21 h 13, Justin Israel  a 
> écrit :
>
>
>
> On Tuesday, October 17, 2023 at 10:40:33 AM UTC+13 Marc-Antoine Ruel wrote:
>
> I second Richard's suggestion. I used the same trick for 
> https://github.com/periph/d2xx. This git repository contains a minimalist 
> shim for the .a libraries and nothing else. It's designed to compile on any 
> platform. It falls back to a scaffolding if the corresponding .a library is 
> not present for the OS-arch combination or if CGO is disabled. It makes 
> testing easier.
>
> Then a proper package under https://github.com/periph/host/tree/main/ftdi 
> exposes a higher level abstraction for the user.
>
>
> With only headers and static libs in the thirdparty directory, is this 
> package "go-gettable"? 
> Will go make the subdirectory available in that case? It usually ignores 
> if there is no Go source files. 
>  
>
> M-A
>
> Le lun. 16 oct. 2023, à 14 h 48, Mike Schinkel  a 
> écrit :
>
> Hi Jan,
>
> I'm going to go out on a limb here and suggest looking at using Go's 
> `embed` feature?
>
> https://blog.jetbrains.com/go/2021/06/09/how-to-use-go-embed-in-go-1-16/
>
> I have not tried it with C libraries so there may be numerous reasons why 
> it may not work for your needs. For example, I do not know what is required 
> to *"install&

[go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Jan]

Thanks Tamas, this is useful information. 

One of my libraries is using a `.a` library -- as opposed to `.so`, which 
is another level of complexity, since the library has to be available in 
runtime, not only in compile time -- and I'm going to follow your 
"incantation" suggestion.


On Sunday, October 15, 2023 at 7:55:55 AM UTC+2 Tamás Gulácsi wrote:

> Neither I see a convenient way.
> BUT if you add a .go file into the directories where your precompiled 
> libraries live,
> then "go get" will download them too (and only those dirs that have .go 
> files in it).
>
> So your next mission is to prepare the right #cgo CFLAGS LDFLAGS 
> incantations to use those libraries.
>
> Jan a következőt írta (2023. október 14., szombat, 8:37:48 UTC+2):
>
>> Thanks Tamás, I may not be understanding correctly, but after taking a 
>> look at github.com/godror/godror, and the odpi subdirectory,
>> I see it is including all the `.c` files on the fly 
>> <https://github.com/godror/godror/blob/main/odpi/embed/dpi.c>.
>>
>> A couple of reasons immediately come to mind, that make this not a 
>> generically valid option:
>>
>> * ODPI library is all C code (see src 
>> <https://github.com/godror/godror/tree/main/odpi/src>) so it works 
>> including in Go: my dependencies are C++/Rust code, for which I write a 
>> small C wrapper (or for Rust just `extern "C"`). Also architecture 
>> dependent compilation is different in C++/C/Rust code ...
>> * The C++ libraries I'm including have sub-dependencies of themselves 
>> (one of which is llvm). It uses Bazel to organize it, and to manually move 
>> all the required C++ files to a directory would be years of work :) Plus 
>> would require me to slave to maintain things in sync. 
>> * The C++ libraries take hours to compile ... I don't want to impose this 
>> to users of my libraries.
>>
>> I think the only way to work this out is distributing the pre-compiled 
>> C++/Rust libraries, so the Go simply refer to them (and we get the fast 
>> compilation times from Go). But then, how to best distribute them in an 
>> automatic fashion, so that users don't need to one by one figure out how to 
>> install them (and clean up them later if they are no longer using...) ?
>>
>> Or maybe there is another convenient way I'm not seeing ?
>>
>>
>> On Thursday, October 12, 2023 at 6:39:34 PM UTC+2 Tamás Gulácsi wrote:
>>
>>> Can't you build (make go build for you) those libraries?
>>> For example, see github.com/godror/godror just includes the sources of 
>>> that third party library in an "odpi" subdir, and with
>>> ```
>>> /*
>>> #cgo CFLAGS: -I./odpi/include -I./odpi/src -I./odpi/embed
>>>
>>> #include "dpi.c"
>>>
>>> */
>>> import "C"
>>> ```
>>> it is compiled automatically.
>>>
>>>
>>> Caveat: for "go get" to download a directory, it must include a sth.go 
>>> file ("require.go" in the odpi/* subdirs).
>>> But it may work that your precompiled libs in a subdir, with a mock .go 
>>> file gets downloaded.
>>> But how will it found by your lib/app ?
>>>
>>> Tamás
>>>
>>>
>>> Jan a következőt írta (2023. október 12., csütörtök, 8:14:41 UTC+2):
>>>
>>>> Thanks Richard. Indeed, as you pointed out the downside is the bloating 
>>>> of the git repo, but it makes sense.
>>>>
>>>> But does the user have to manually clone the repository and move the 
>>>> `.a` file to, let's say, /usr/local/lib, or does a simple `go get` 
>>>> magically does everything ?
>>>>
>>>>
>>>> On Thursday, October 12, 2023 at 2:29:21 AM UTC+2 Richard Wilkes wrote:
>>>>
>>>>> It isn't a great solution, but I currently include the built library 
>>>>> files and necessary headers in the git repo alongside the Go code. You 
>>>>> can 
>>>>> see an example here 
>>>>> https://github.com/richardwilkes/unison/tree/main/internal/skia where 
>>>>> I include the skia library I built for use in my UI framework, unison.
>>>>>
>>>>> The main downside of this is bloating the git repo with the binary .a 
>>>>> and .dll files... but I've not found a better way to handle it. glfw, 
>>>>> which 
>>>>> unison also depends upon, does something very similar.
>>>>>
>>&g

[go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Jan]

Thanks Tamás, I may not be understanding correctly, but after taking a look 
at github.com/godror/godror, and the odpi subdirectory,
I see it is including all the `.c` files on the fly 
<https://github.com/godror/godror/blob/main/odpi/embed/dpi.c>.

A couple of reasons immediately come to mind, that make this not a 
generically valid option:

* ODPI library is all C code (see src 
<https://github.com/godror/godror/tree/main/odpi/src>) so it works 
including in Go: my dependencies are C++/Rust code, for which I write a 
small C wrapper (or for Rust just `extern "C"`). Also architecture 
dependent compilation is different in C++/C/Rust code ...
* The C++ libraries I'm including have sub-dependencies of themselves (one 
of which is llvm). It uses Bazel to organize it, and to manually move all 
the required C++ files to a directory would be years of work :) Plus would 
require me to slave to maintain things in sync. 
* The C++ libraries take hours to compile ... I don't want to impose this 
to users of my libraries.

I think the only way to work this out is distributing the pre-compiled 
C++/Rust libraries, so the Go simply refer to them (and we get the fast 
compilation times from Go). But then, how to best distribute them in an 
automatic fashion, so that users don't need to one by one figure out how to 
install them (and clean up them later if they are no longer using...) ?

Or maybe there is another convenient way I'm not seeing ?


On Thursday, October 12, 2023 at 6:39:34 PM UTC+2 Tamás Gulácsi wrote:

> Can't you build (make go build for you) those libraries?
> For example, see github.com/godror/godror just includes the sources of 
> that third party library in an "odpi" subdir, and with
> ```
> /*
> #cgo CFLAGS: -I./odpi/include -I./odpi/src -I./odpi/embed
>
> #include "dpi.c"
>
> */
> import "C"
> ```
> it is compiled automatically.
>
>
> Caveat: for "go get" to download a directory, it must include a sth.go 
> file ("require.go" in the odpi/* subdirs).
> But it may work that your precompiled libs in a subdir, with a mock .go 
> file gets downloaded.
> But how will it found by your lib/app ?
>
> Tamás
>
>
> Jan a következőt írta (2023. október 12., csütörtök, 8:14:41 UTC+2):
>
>> Thanks Richard. Indeed, as you pointed out the downside is the bloating 
>> of the git repo, but it makes sense.
>>
>> But does the user have to manually clone the repository and move the `.a` 
>> file to, let's say, /usr/local/lib, or does a simple `go get` magically 
>> does everything ?
>>
>>
>> On Thursday, October 12, 2023 at 2:29:21 AM UTC+2 Richard Wilkes wrote:
>>
>>> It isn't a great solution, but I currently include the built library 
>>> files and necessary headers in the git repo alongside the Go code. You can 
>>> see an example here 
>>> https://github.com/richardwilkes/unison/tree/main/internal/skia where I 
>>> include the skia library I built for use in my UI framework, unison.
>>>
>>> The main downside of this is bloating the git repo with the binary .a 
>>> and .dll files... but I've not found a better way to handle it. glfw, which 
>>> unison also depends upon, does something very similar.
>>>
>>> - Rich
>>>
>>> On Wednesday, October 11, 2023 at 2:58:23 AM UTC-7 Jan wrote:
>>>
>>>> hi,
>>>>
>>>> I'm developing a couple of ML framework/libraries for Go that depend on 
>>>> C/C++ code. Once C-libraries dependencies are installed, the CGO 
>>>> integration work great.
>>>>
>>>> Now, for end-users that just want to use these Go libraries, having to 
>>>> figure out how to manually build and install those C/C++/Rust dependencies 
>>>> is a hassle -- sadly each one with a different type of build system.
>>>>
>>>> I offer pre-built `.tgz` files (for a limited set of architectures) 
>>>> with the required `.h` and `.a/.so` files along the releases, which 
>>>> facilitates. But it's still a hassle to install -- and no auto-uninstall 
>>>> if 
>>>> someone is no longer using the Go module.
>>>>
>>>> I was wondering if others have figured out how to handle this in a 
>>>> nicer way.  Is there a recommended way to distribute prebuilt CGO 
>>>> dependencies ?
>>>>
>>>> I like how Python wheels (`.whl` files) solve the issue, by including 
>>>> the pre-built libraries in a sub-directory of the python library 
>>>> installation. I was hoping there would be a similar wa

Re: [go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Jan]

Thanks Tim, but my goal is to make things transparent and easy to the users 
of my libraries. So I don't want to force them to run Makefiles (in my case 
large Bazel builds for one project, Makefile for the other), install 
C++/Rust build tools, deal with dockers, etc. Ideally, `go get` would just 
take care of everything. If that is not possible, I'm wondering what is the 
easiest next thing.

The reasoning is that a largish project often depends on dozens of 
libraries, if we need to do this kind of stuff for every library, its too 
much friction. Go tools are awesome ('go get' works so well for me) when 
there are no CGO dependencies ... alas, not everything is implemented in Go.

Indeed, pre-built binaries is platform dependent -- and requires separate 
files/tgz per architecture, as you point out. How to have these 
dependencies installed, and picked up by go compiler automatically (setting 
up of CGO's CFLAG, LDFLAG LD_LIBRARY_PATH, etc), and be removed if no 
longer used ? With minimum user headache/work...

cheers
Jan

On Thursday, October 12, 2023 at 3:16:58 AM UTC+2 Tim Casey wrote:

>
>
> I would put down Makefile includes for the supported targets and build 
> each target at a time, as cross compiled shared libraries.  This is easier 
> for linux, harder for windows.
> But, you can build/export from docker containers as part of the overall 
> build process to allow simulated build environments.   At some point, you 
> may come to a dependency in which you have to build the included C code for 
> it to run in platform dependent libraries.  At this point, you probably 
> will want to build on the environment as you go.  You can cross target *.o, 
> but build the *.so on the specific target.
>
> You could have separate repos and distribute the C code from a dependency 
> point of view.  This would be a tgz of 'shared/$ARCH/$COMPILED_LIB", or 
> some such.
>
> On Wed, Oct 11, 2023 at 5:29 PM Richard Wilkes  
> wrote:
>
>> It isn't a great solution, but I currently include the built library 
>> files and necessary headers in the git repo alongside the Go code. You can 
>> see an example here 
>> https://github.com/richardwilkes/unison/tree/main/internal/skia where I 
>> include the skia library I built for use in my UI framework, unison.
>>
>> The main downside of this is bloating the git repo with the binary .a and 
>> .dll files... but I've not found a better way to handle it. glfw, which 
>> unison also depends upon, does something very similar.
>>
>> - Rich
>>
>> On Wednesday, October 11, 2023 at 2:58:23 AM UTC-7 Jan wrote:
>>
>>> hi,
>>>
>>> I'm developing a couple of ML framework/libraries for Go that depend on 
>>> C/C++ code. Once C-libraries dependencies are installed, the CGO 
>>> integration work great.
>>>
>>> Now, for end-users that just want to use these Go libraries, having to 
>>> figure out how to manually build and install those C/C++/Rust dependencies 
>>> is a hassle -- sadly each one with a different type of build system.
>>>
>>> I offer pre-built `.tgz` files (for a limited set of architectures) with 
>>> the required `.h` and `.a/.so` files along the releases, which facilitates. 
>>> But it's still a hassle to install -- and no auto-uninstall if someone is 
>>> no longer using the Go module.
>>>
>>> I was wondering if others have figured out how to handle this in a nicer 
>>> way.  Is there a recommended way to distribute prebuilt CGO dependencies ?
>>>
>>> I like how Python wheels (`.whl` files) solve the issue, by including 
>>> the pre-built libraries in a sub-directory of the python library 
>>> installation. I was hoping there would be a similar way (maybe with a 
>>> separate tool) to integrate with `go.mod`. 
>>>
>>> Any pointers, thoughts or suggestions are very appreciated.
>>>
>>> Thanks!
>>> Jan
>>>
>>> ps: While searching I saw similar questions, but none that exactly 
>>> answered this aspect of distribution. Just in case, apologies if it's a 
>>> duplicate question.
>>>
>> -- 
>> 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/3b03b9e1-655e-452a-9b97-e9471b9b9dc1n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/3b03b9e1-655e-452a-9b97-e9471b9b9dc1n%40googlegroups.com?utm_medium=email&utm_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/a5feedde-9a18-4b29-92a0-6f76d96f01c4n%40googlegroups.com.

[go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Jan]

Thanks Richard. Indeed, as you pointed out the downside is the bloating of 
the git repo, but it makes sense.

But does the user have to manually clone the repository and move the `.a` 
file to, let's say, /usr/local/lib, or does a simple `go get` magically 
does everything ?


On Thursday, October 12, 2023 at 2:29:21 AM UTC+2 Richard Wilkes wrote:

> It isn't a great solution, but I currently include the built library files 
> and necessary headers in the git repo alongside the Go code. You can see an 
> example here 
> https://github.com/richardwilkes/unison/tree/main/internal/skia where I 
> include the skia library I built for use in my UI framework, unison.
>
> The main downside of this is bloating the git repo with the binary .a and 
> .dll files... but I've not found a better way to handle it. glfw, which 
> unison also depends upon, does something very similar.
>
> - Rich
>
> On Wednesday, October 11, 2023 at 2:58:23 AM UTC-7 Jan wrote:
>
>> hi,
>>
>> I'm developing a couple of ML framework/libraries for Go that depend on 
>> C/C++ code. Once C-libraries dependencies are installed, the CGO 
>> integration work great.
>>
>> Now, for end-users that just want to use these Go libraries, having to 
>> figure out how to manually build and install those C/C++/Rust dependencies 
>> is a hassle -- sadly each one with a different type of build system.
>>
>> I offer pre-built `.tgz` files (for a limited set of architectures) with 
>> the required `.h` and `.a/.so` files along the releases, which facilitates. 
>> But it's still a hassle to install -- and no auto-uninstall if someone is 
>> no longer using the Go module.
>>
>> I was wondering if others have figured out how to handle this in a nicer 
>> way.  Is there a recommended way to distribute prebuilt CGO dependencies ?
>>
>> I like how Python wheels (`.whl` files) solve the issue, by including the 
>> pre-built libraries in a sub-directory of the python library installation. 
>> I was hoping there would be a similar way (maybe with a separate tool) to 
>> integrate with `go.mod`. 
>>
>> Any pointers, thoughts or suggestions are very appreciated.
>>
>> Thanks!
>> Jan
>>
>> ps: While searching I saw similar questions, but none that exactly 
>> answered this aspect of distribution. Just in case, apologies if it's a 
>> duplicate question.
>>
>

-- 
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/4e84cdbf-15c4-42bf-a6f3-67aec78a5dc1n%40googlegroups.com.

Re: [go-nuts] Re: Why causes []any trouble in type equations?

[Jan Mercl]

On Wed, Oct 11, 2023 at 8:11 PM Torsten Bronger
 wrote:

> Then, all boils down to the fact that you can’t pass []float64 as an
> []any.  To be honest, I still don’t fully understand why this is
> forbidden, so I just accept that the language does not allow it.

It's the same reason why one cannot pass, say []byte as an []int. The
backing arrays of the two slices have incompatible memory layouts. To
make it work the compiler would have to inject code like
(schematically)

var tmp []int
for i, v := range byteSlice {
   tmp = append(tmp, v)
}
   callTheFuntion(tmp)

It is doable but it has a cost which the language designers preferred
not to hide.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-Vp%2B22PhXxxYBwvj77G3zFVEStSzr1%3DTsCuALYZS-%2BHQg%40mail.gmail.com.

[go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Jan]

Yep, I want a solution on how to distribute C-dependencies of libraries 
that use CGO, so end users don't have to manually sort out dependencies of 
various libraries.

Thanks for trying though.

On Wednesday, October 11, 2023 at 1:10:12 PM UTC+2 Peter Galbavy wrote:

> Hang on - I missed your original statement that you are building 
> *libraries* yourself. I am building executables. Sorry for the confusion 
> and my too-fast scan reading!
>
> On Wednesday, 11 October 2023 at 12:08:53 UTC+1 Peter Galbavy wrote:
>
>> If you link statically, e.g. from my Dockerfile:
>>
>>   go build -tags netgo,osusergo --ldflags '-s -w -linkmode external 
>> -extldflags=-static'
>>
>> then the libraries are in the single binary. I also then use "upx" to 
>> compress the resulting binaries to save a little space. The build tags are 
>> there to not require GLIBC for user and dns lookups.
>>
>>
>>
>> On Wednesday, 11 October 2023 at 11:43:20 UTC+1 Jan wrote:
>>
>>> Edit: ...so folks using your library don't need to install them manually 
>>> ? What about uninstalling ?
>>> On Wednesday, October 11, 2023 at 12:41:40 PM UTC+2 Jan wrote:
>>>
>>>> Thanks Peter, but I don't follow ... I also use docker to build the 
>>>> pre-built binaries.
>>>>
>>>> But how do you distribute them, so folks using your library don't think 
>>>> to install them ?
>>>>
>>>> On Wednesday, October 11, 2023 at 12:32:57 PM UTC+2 Peter Galbavy wrote:
>>>>
>>>>> I use a docker container (golang:bullseye seems the most compatible) 
>>>>> and build static binaries. This is feasible as long as your dependencies 
>>>>> do 
>>>>> not require dynamic loading of dependencies.
>>>>>
>>>>> Poor (my Dockerfile skills) example here: 
>>>>> https://github.com/ITRS-Group/cordial/blob/main/Dockerfile
>>>>>
>>>>> Peter
>>>>>
>>>>> On Wednesday, 11 October 2023 at 10:58:23 UTC+1 Jan wrote:
>>>>>
>>>>>> hi,
>>>>>>
>>>>>> I'm developing a couple of ML framework/libraries for Go that depend 
>>>>>> on C/C++ code. Once C-libraries dependencies are installed, the CGO 
>>>>>> integration work great.
>>>>>>
>>>>>> Now, for end-users that just want to use these Go libraries, having 
>>>>>> to figure out how to manually build and install those C/C++/Rust 
>>>>>> dependencies is a hassle -- sadly each one with a different type of 
>>>>>> build 
>>>>>> system.
>>>>>>
>>>>>> I offer pre-built `.tgz` files (for a limited set of architectures) 
>>>>>> with the required `.h` and `.a/.so` files along the releases, which 
>>>>>> facilitates. But it's still a hassle to install -- and no auto-uninstall 
>>>>>> if 
>>>>>> someone is no longer using the Go module.
>>>>>>
>>>>>> I was wondering if others have figured out how to handle this in a 
>>>>>> nicer way.  Is there a recommended way to distribute prebuilt CGO 
>>>>>> dependencies ?
>>>>>>
>>>>>> I like how Python wheels (`.whl` files) solve the issue, by including 
>>>>>> the pre-built libraries in a sub-directory of the python library 
>>>>>> installation. I was hoping there would be a similar way (maybe with a 
>>>>>> separate tool) to integrate with `go.mod`. 
>>>>>>
>>>>>> Any pointers, thoughts or suggestions are very appreciated.
>>>>>>
>>>>>> Thanks!
>>>>>> Jan
>>>>>>
>>>>>> ps: While searching I saw similar questions, but none that exactly 
>>>>>> answered this aspect of distribution. Just in case, apologies if it's a 
>>>>>> duplicate question.
>>>>>>
>>>>>

-- 
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/52054323-ac00-4b15-92f7-7c95cb84b1a1n%40googlegroups.com.

[go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Jan]

Edit: ...so folks using your library don't need to install them manually ? 
What about uninstalling ?
On Wednesday, October 11, 2023 at 12:41:40 PM UTC+2 Jan wrote:

> Thanks Peter, but I don't follow ... I also use docker to build the 
> pre-built binaries.
>
> But how do you distribute them, so folks using your library don't think to 
> install them ?
>
> On Wednesday, October 11, 2023 at 12:32:57 PM UTC+2 Peter Galbavy wrote:
>
>> I use a docker container (golang:bullseye seems the most compatible) and 
>> build static binaries. This is feasible as long as your dependencies do not 
>> require dynamic loading of dependencies.
>>
>> Poor (my Dockerfile skills) example here: 
>> https://github.com/ITRS-Group/cordial/blob/main/Dockerfile
>>
>> Peter
>>
>> On Wednesday, 11 October 2023 at 10:58:23 UTC+1 Jan wrote:
>>
>>> hi,
>>>
>>> I'm developing a couple of ML framework/libraries for Go that depend on 
>>> C/C++ code. Once C-libraries dependencies are installed, the CGO 
>>> integration work great.
>>>
>>> Now, for end-users that just want to use these Go libraries, having to 
>>> figure out how to manually build and install those C/C++/Rust dependencies 
>>> is a hassle -- sadly each one with a different type of build system.
>>>
>>> I offer pre-built `.tgz` files (for a limited set of architectures) with 
>>> the required `.h` and `.a/.so` files along the releases, which facilitates. 
>>> But it's still a hassle to install -- and no auto-uninstall if someone is 
>>> no longer using the Go module.
>>>
>>> I was wondering if others have figured out how to handle this in a nicer 
>>> way.  Is there a recommended way to distribute prebuilt CGO dependencies ?
>>>
>>> I like how Python wheels (`.whl` files) solve the issue, by including 
>>> the pre-built libraries in a sub-directory of the python library 
>>> installation. I was hoping there would be a similar way (maybe with a 
>>> separate tool) to integrate with `go.mod`. 
>>>
>>> Any pointers, thoughts or suggestions are very appreciated.
>>>
>>> Thanks!
>>> Jan
>>>
>>> ps: While searching I saw similar questions, but none that exactly 
>>> answered this aspect of distribution. Just in case, apologies if it's a 
>>> duplicate question.
>>>
>>

-- 
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/715a15ae-119f-457c-b581-525e72d2518cn%40googlegroups.com.

[go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Jan]

Thanks Peter, but I don't follow ... I also use docker to build the 
pre-built binaries.

But how do you distribute them, so folks using your library don't think to 
install them ?

On Wednesday, October 11, 2023 at 12:32:57 PM UTC+2 Peter Galbavy wrote:

> I use a docker container (golang:bullseye seems the most compatible) and 
> build static binaries. This is feasible as long as your dependencies do not 
> require dynamic loading of dependencies.
>
> Poor (my Dockerfile skills) example here: 
> https://github.com/ITRS-Group/cordial/blob/main/Dockerfile
>
> Peter
>
> On Wednesday, 11 October 2023 at 10:58:23 UTC+1 Jan wrote:
>
>> hi,
>>
>> I'm developing a couple of ML framework/libraries for Go that depend on 
>> C/C++ code. Once C-libraries dependencies are installed, the CGO 
>> integration work great.
>>
>> Now, for end-users that just want to use these Go libraries, having to 
>> figure out how to manually build and install those C/C++/Rust dependencies 
>> is a hassle -- sadly each one with a different type of build system.
>>
>> I offer pre-built `.tgz` files (for a limited set of architectures) with 
>> the required `.h` and `.a/.so` files along the releases, which facilitates. 
>> But it's still a hassle to install -- and no auto-uninstall if someone is 
>> no longer using the Go module.
>>
>> I was wondering if others have figured out how to handle this in a nicer 
>> way.  Is there a recommended way to distribute prebuilt CGO dependencies ?
>>
>> I like how Python wheels (`.whl` files) solve the issue, by including the 
>> pre-built libraries in a sub-directory of the python library installation. 
>> I was hoping there would be a similar way (maybe with a separate tool) to 
>> integrate with `go.mod`. 
>>
>> Any pointers, thoughts or suggestions are very appreciated.
>>
>> Thanks!
>> Jan
>>
>> ps: While searching I saw similar questions, but none that exactly 
>> answered this aspect of distribution. Just in case, apologies if it's a 
>> duplicate question.
>>
>

-- 
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/53d67347-9184-4f21-b66a-2f07a178dd09n%40googlegroups.com.

[go-nuts] Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Jan]

hi,

I'm developing a couple of ML framework/libraries for Go that depend on 
C/C++ code. Once C-libraries dependencies are installed, the CGO 
integration work great.

Now, for end-users that just want to use these Go libraries, having to 
figure out how to manually build and install those C/C++/Rust dependencies 
is a hassle -- sadly each one with a different type of build system.

I offer pre-built `.tgz` files (for a limited set of architectures) with 
the required `.h` and `.a/.so` files along the releases, which facilitates. 
But it's still a hassle to install -- and no auto-uninstall if someone is 
no longer using the Go module.

I was wondering if others have figured out how to handle this in a nicer 
way.  Is there a recommended way to distribute prebuilt CGO dependencies ?

I like how Python wheels (`.whl` files) solve the issue, by including the 
pre-built libraries in a sub-directory of the python library installation. 
I was hoping there would be a similar way (maybe with a separate tool) to 
integrate with `go.mod`. 

Any pointers, thoughts or suggestions are very appreciated.

Thanks!
Jan

ps: While searching I saw similar questions, but none that exactly answered 
this aspect of distribution. Just in case, apologies if it's a duplicate 
question.

-- 
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/040654df-b5b0-4a17-a663-0fdf90c691d5n%40googlegroups.com.

Re: [go-nuts] how do you compie and link a go main with an assembly code file?

[Jan Mercl]

On Mon, Oct 9, 2023 at 6:02 PM Peter Riemenschneider  wrote:

Just '$ go build' as usual, but one must declare the asm function:
https://go.dev/play/p/KySqFvCVz_T

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UEhabq5%3DQs5oxYZeL4RW%2BLDfbBap1tzhh5fwTdba7EJA%40mail.gmail.com.

Re: [go-nuts] The docs for secretbox seem very wrong

[Jan Mercl]

On Mon, Oct 9, 2023 at 3:46 PM Dean Schulze  wrote:

> If the docs are correct, how do you append to nil?

https://go.dev/play/p/WY0Bycj-_Tn

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-WtCRNSp8eLQxDfhjhKBhR4UPdciNPNaS9Oj7v1EdBD-Q%40mail.gmail.com.

Re: [go-nuts] Help understanding slices, variable arguments, and passing slices to functions

[Jan Mercl]

On Mon, Sep 25, 2023 at 1:57 PM Andrew Pillar  wrote:

A nice discussion of slices can be found for example here:
https://research.swtch.com/godata

tl;dr: Yes, slices are passed by value (everything in Go is passed by
value), but a slice does not contain the backing array, only a pointer
to it.

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XOM_j8wOoK_2k3LQmA23AyX23fMZB3yx48eAGe9pNGGQ%40mail.gmail.com.

Re: [go-nuts] Re: Weird error when trying to fetch a module.

[Jan Mercl]

On Fri, Sep 15, 2023 at 10:31 AM 'Jim Idle' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> The go.mod at the root was one thing that might work, but it will cause
the entire repo to be pulled in so the tag will still have to be sec/go/
etc.

tl;dr: Putting a go.mod in the repository root has no additional costs for
the repo users.

I was curious if the entire repo would be pulled, that would surprise me.
Turns out that's not the case.


0:jnml@e5-1650:/tmp/mod$ ls -la
total 500
drwxr-xr-x   2 jnml jnml   4096 Sep 15 10:47 .
drwxrwxrwt 164 root root 487424 Sep 15 10:49 ..
-rw-r--r--   1 jnml jnml937 Sep 15 10:45 go.mod
-rw-r--r--   1 jnml jnml   5461 Sep 15 10:45 go.sum
-rw-r--r--   1 jnml jnml 83 Sep 15 10:45 main.go
0:jnml@e5-1650:/tmp/mod$ cat go.mod
module example.com/mod

go 1.21.1

require modernc.org/ccgo/v4 v4.0.0

require (
github.com/dustin/go-humanize v1.0.1 // indirect
github.com/google/uuid v1.3.0 // indirect
github.com/kballard/go-shellquote
v0.0.0-20180428030007-95032a82bc51 // indirect
github.com/mattn/go-isatty v0.0.16 // indirect
github.com/remyoudompheng/bigfft v0.0.0-20230129092748-24d4a6f8daec
// indirect
golang.org/x/mod v0.11.0 // indirect
golang.org/x/sys v0.9.0 // indirect
golang.org/x/tools v0.10.0 // indirect
lukechampine.com/uint128 v1.2.0 // indirect
modernc.org/cc/v3 v3.41.0 // indirect
modernc.org/cc/v4 v4.14.2 // indirect
modernc.org/ccgo/v3 v3.16.15 // indirect
modernc.org/gc/v2 v2.3.0 // indirect
modernc.org/libc v1.24.1 // indirect
modernc.org/mathutil v1.6.0 // indirect
modernc.org/memory v1.7.0 // indirect
modernc.org/opt v0.1.3 // indirect
modernc.org/strutil v1.2.0 // indirect
modernc.org/token v1.1.0 // indirect
)
0:jnml@e5-1650:/tmp/mod$ cat main.go
package main

import "modernc.org/ccgo/v4"

func main() {
println(&ccgo.Task{})
}
0:jnml@e5-1650:/tmp/mod$ go clean -cache -modcache -testcache ; sudo rm -rf
~/pkg ~/.cache/go-build/
0:jnml@e5-1650:/tmp/mod$ go build -v -x |& grep 'ccgo.*\.zip'
# get https://proxy.golang.org/modernc.org/ccgo/v4/@v/v4.0.0.zip
# get https://proxy.golang.org/modernc.org/ccgo/v4/@v/v4.0.0.zip: 200 OK
(0.111s)
# get https://proxy.golang.org/modernc.org/ccgo/v3/@v/v3.16.15.zip
# get https://proxy.golang.org/modernc.org/ccgo/v3/@v/v3.16.15.zip: 200 OK
(0.032s)
0:jnml@e5-1650:/tmp/mod$


Note: ccgo/v4 depends on ccgo/v3 but that's not relevant to this experiment.

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UbYxMCJ8T6QMApV1xme9C9JNR3EjRjh_CT0xoyoU1Wew%40mail.gmail.com.

Re: [go-nuts] How ignore a subdirectory

[Jan Mercl]

On Wed, Sep 13, 2023 at 12:25 PM John Souvestre  wrote:
> I did try that also.  I get this error message:
>
> CreateFile *.go: The filename, directory name, or volume label syntax
is incorrect.

Sorry, I'm not familiar with Windows and only TIL cmd.exe does not expand
globs. I suggest to install WSL and try something like

C:\>bash -c 'gofmt *.go'

HTH

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-WiqO8BsKxi3wB%2Bg6L8GgZQSqCirT-3pHS%2BVND2%2BXw1kQ%40mail.gmail.com.

Re: [go-nuts] How ignore a subdirectory

[Jan Mercl]

On Wed, Sep 13, 2023 at 5:47 AM 'John Souvestre' via golang-nuts
 wrote:

> I’m trying to run gofmt on all of the .go files in a directory, but not any 
> subdirectories.

$ gofmt *.go

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-WiBpBdhHrb2t%3Duf0Ooajk%2BfALeWQEYfj%3D2rEADTOh8jw%40mail.gmail.com.

Re: [go-nuts] How to constrain an integral type's values

[Jan Mercl]

On Fri, Sep 8, 2023 at 9:24 AM 'Mark' via golang-nuts
 wrote:

> Is there a compile-time solution for this that I've missed?

No. Go does not have enum types.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-Xt4awDMhsKvL_EQZzN_B7O1pzss95PZC6xaufssQuoYA%40mail.gmail.com.

[go-nuts] Re: does gonum insist on row-major?

[Jan]

Not exactly what you asked, but something that you may consider: GoMLX 
. It's an accelerated ML and Math library 
that uses XLA  --> it just-in-time compiles 
a computation graph to CPU/GPU (and hopefully soon TPU). It powers 
Jax/Tensorflow and is really fast (after the first execution).

Now, while pretty rich set of functionality, it's not a super-set of Gonum 
(it has some stuff not available in Gonum also). If anything is missing, 
but is supported by XLA , 
I would be happy to add. Plus it's well documented (see tutorial 
). 
Storage is row-major for 2d-tensors by default -- but internally it may 
reshuffle storage depending on optimization.

ps.: It's a biased suggestion (plus a bit of advertisement) because I 
created the project.

On Saturday, August 26, 2023 at 2:14:22 PM UTC+2 Jason E. Aten wrote:

> I do alot of stats/numerical stuff but I haven't tried gonum until now.
>
> Yesterday I went to port a bunch of C code that uses BLAS/LAPACK
> into Go, and thought I'd try it (Gonum) out.  Now the logic is the original
> code is very hairy, and does delicate operations like a bunch
> of QR decompositions... in short, I don't want to mess with the
> algorithm at all, I just want to port it to Go. The C original code runs 
> fine against
> OpenBLAS. Of course, being numeric code, it all assumes column-major
> Fortran style matrices.
>
> But when I tried to run the same logic on Gonum, I was hitting issues
> left and right. At first I thought they were bugs in Gonum. But then
> I realized, by default Gonum is assuming that your matrices will
> be row-major (C-style).
>
> There's almost zero documentation for gonum of these kinds of
>  assumptions and even less about how to use
> Gonum Like how do you switch between the Go and C BLAS implementation?
> Not documented; that I can find. You would think this would be front and 
> center. Ugh.
>
> Anyway: somebody here probably knows-- does Gonum also support column-major
> matrices?  In the Go BLAS, or in a cgo binding to OpenBLAS?
>
> With Bewildered 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/3b21ad7c-6bf2-4806-8d16-e5967a7bbe0fn%40googlegroups.com.

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

[Jan Mercl]

On Sat, Aug 26, 2023 at 2:33 PM Jason E. Aten  wrote:
>
> Is there any IDE that allows you to jump through a stack trace like emacs 
> does?

I think many code editors can do that, for example vim:
https://vim.fandom.com/wiki/Open_file_under_cursor

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-VY54WdM2bC8ev-SWdXSpAJPpXyadea81xsmUJEuqcvxQ%40mail.gmail.com.

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

[Jan]

Notice that if you don't assign to `tok`, multiple alternatives in `case` 
works.

But the issue is that in Go there are no "duck typing" for data, only for 
methods (interfaces).  `xml.StartElement` and `xmlEndElement` not being the 
same type, the assignment ('tok.name.Local = "types"`) won't work.

Would converting to a method,  something like this 
, work for you  ? It could be changed by 
making the interface "Named" the type to match in the `switch` clause. 
There are many alternatives, the key point is when you are trying to share 
functionality (or data) across different types, it is usually done using 
common interfaces.


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/d2c96949-155a-43e5-9fc3-1a294f59e31cn%40googlegroups.com.

[go-nuts] Re: custom coverage report

[Jan]

hey Vasiliy, I'm not sure I understood your requirements, but let me take a 
stab at it.

By handlers of the protobuf I imagine you refer to those stubs generated by 
`protoc`, for the gRPCs. Is it correct ? 

They have well defined names/packages that can easily be filtered (grep?) 
from the the usual function coverage report you get from `go tool covdata 
func ...`. 
After this filtering, you could take an average, in whichever way you feel 
appropriate. Would this work for your need ?

Btw, I don't know of a golang package to output cover files ... would the 
command line tools work ? (`go tool covdata` or for instance `go tool cover 
--to=HTML`)

cheers!

ps.: Just in case it helps:

* To write the coverage information in text format, I suppose the original 
blog post  still works (it's from 2013) *for 
unit tests*.
* *For integration tests* (e.g: when the test executes the program for 
which you want coverage) + unit tests together, here is one example: 
https://github.com/janpfeifer/gonb/blob/main/run_coverage.sh 







On Thursday, August 24, 2023 at 11:13:32 AM UTC+2 Vasiliy Tolstov wrote:

> Anybody knows golang package that can write cover files in desired format?
>
> вс, 20 авг. 2023 г. в 17:28, Vasiliy Tolstov :
> >
> > Hi. I have service centric tests - so i want to test not each function
> > inside application, but only it handlers (defined via protobuf)
> > Also i have custom framework that runs each test like - start grpc
> > server, and call it via predefined json based files, and compare
> > results.
> > I want to measure coverage , but don't understand how to do that?
> > Is that possible to have another way to measure handlers coverage in
> > case of service defined via protobuf?
> >
> > --
> > Vasiliy Tolstov,
> > e-mail: v.to...@selfip.ru
>
>
>
> -- 
> Vasiliy Tolstov,
> e-mail: v.to...@selfip.ru
>

-- 
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/4349a17b-1993-4491-a642-7d156a774d9fn%40googlegroups.com.

Re: [go-nuts] Re: [ANN] go-zeromq/zmq4: pure-Go implementation of ZeroMQ

[Jan]

Btw, I should add to it that GoNB , a 
successor to gophernotes also uses github.com/go-zeromq/zmq4 to communicate 
with Jupyter -- it's been  working flawlessly for that use case.



On Thursday, August 24, 2023 at 3:20:49 PM UTC+2 Sebastien Binet wrote:

> Hi there, 
>
> (Apologies for the belated answer, I am on holidays with patchy network 
> coverage) 
>
> I had worked on this pure Go library to make the installation of 
> Gophernotes (an IPython kernel for Go) easier (just go-get-able). 
> It was also part of PoC for an IPC-based data acquisition system at CERN. 
> (That didn't pan out: they weren't so inclined to have Go in their stack) 
>
> Go-zeromq is robust enough for Gophernotes but is probably in need for 
> some maintenance and development. 
> I personally don't have time for that (but I can give the keys of the 
> castle to motivated people). 
>
> Cheers, 
> Sebastien. 
>

-- 
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/46562be4-a70d-49c5-9cf1-1c63fd2e1a01n%40googlegroups.com.

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

[Jan Mercl]

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+unsubscr...@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.

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

[Jan Mercl]

On Sat, Aug 19, 2023 at 9:42 PM Robert Engels  wrote:

> I guarantee that two developers of equal competence - the one with a powerful 
> IDE will outperform the other using a text editor with syntax highlighting 
> (but come on that is a crutch a real developer doesn’t need) by 2-10x 
> depending on the task.

Guarantee. You keep saying that word, but ...

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XMxfExZsS8ih9vireQjefpUqWZ36NrZ6-3mfX_9Vehgw%40mail.gmail.com.

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

[Jan Mercl]

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

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

[Jan]

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&oq=golang+%22-test.gocoverdir%22&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIHCAEQABiiBNIBCTEyODgzajBqN6gCALACAA&sourceid=chrome&ie=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 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

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

[Jan]

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 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/38d1228d-26d3-4fc5-ad89-4eddc335cfe4n%40googlegroups.com.

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

[Jan]

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/ad934700-1b96-40d3-8b7e-d174d420d16dn%40googlegroups.com.

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

[Jan]

hi all, 

After reading the documentation 
, 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/94710cf6-fa5a-4178-82fb-5cbbf8e6207dn%40googlegroups.com.

Re: [go-nuts] Re: Go 1.21.0 is released

[Jan Mercl]

On Wed, Aug 9, 2023, 09:12 Marcello H  wrote:

> https://go.dev/dl/go1.21.0.windows-arm64.zip
>
> It is found when you click on "Other Ports"


Thanks. I may have a false memory of always finding the windows/arm64 port
beside the windows/amd64 one in the same section.

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-VJY1UABea%3D%3D9yTC9o3PPgnQtXQsP4F%2BLdBaMvT9g2Umg%40mail.gmail.com.

[go-nuts] Re: Go 1.21.0 is released

[Jan Mercl]

On Tue, Aug 8, 2023 at 5:24 PM  wrote:

> We have just released Go 1.21.0.
>
> To find out what has changed in Go 1.21, read the release notes:
> https://go.dev/doc/go1.21
>
> You can download binary and source distributions from our download page:
> https://go.dev/dl/#go1.21.0

It looks like the download page is missing Go 1.21.0 for windows/arm64.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UF3JUeVNv9qhWqgjpyLqBDpn%2BDqkLnZKD01YNFkvf_WA%40mail.gmail.com.

Re: [go-nuts] Re: How to convert an svg to a png (or gif) image?

[Jan Mercl]

On Fri, Aug 4, 2023 at 1:22 PM Brian Candler  wrote:

> Also there's a project which compiles C code to Go - ISTR it was used to 
> build a pure Go version of Sqlite.  Presumably the same approach could be 
> applied to an image processing library.
>
> https://twitter.com/bradfitz/status/855271867162083329?lang=en
> https://groups.google.com/g/golang-nuts/c/QDEczMhlQBU/m/4lCn2kP0AwAJ
> https://github.com/elliotchance/c2go

ccgo/v3 is being slowly phased out. ccgo/v4 is not yet released, but
maybe it can already transpile a C SVG to PNG code base and I'd like
to try that to at least know where it fails.

A quick search found no such C code, but that might be my fault. Does
anyone know about a pure C SVG to PNG lib/program?

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-WLtSqLRmsYvCX1UtdnxhtPJEdDR0T%3DoSg8EXZUkPHDVw%40mail.gmail.com.

Re: [go-nuts] Re: Error handling

[Jan Mercl]

On Tue, Aug 1, 2023 at 1:47 AM DrGo  wrote:

> The verbosity of error handling is the number one concern for Go developers 
> in the most recent survey.

That says something about those developers, about their preferences,
opinions, taste etc and that it differs from what the Original
Language Designers (OLD™) preferred.

It has close to zero bits of information which preferences are the
better ones. It's a subjective category anyway.

> So there is a need for doing something about it..

And here's IMO the mistake. You may feel the need, Joe and Mary may
not. It's ok to have preferences. It's ok for preferences to be
different. It does not mean there's a need to change anything. Of
course, you can decide that following the preferences of a majority of
developers is a rational move.

I claim it a fallacy. A big one. Let me not joke about billion flies,
but the fact is - language designers are few and far between while
developers come in heaps. And let's be honest. Most developers write
horrible code, me included. Maybe you're the rare exception, congrats
then. But the majority of us are just the ordinary, average coders for
hire. There are deadlines to meet, bills to pay, project mis-managers
getting into the way etc. We have all experienced that, didn't we?

I, for one learned to pay much more attention to what language
designers do and say. Sometimes I agree, sometime I don't. But I
believe one can, in essence, ignore what the majority of developers
thinks about it. Actually, I think the majority of developers is wrong
more often than the, most of the time silent, minority.

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UNPFRR55YYJgWs34jh38p1zf61PpZaWFGiH2_khv1kbg%40mail.gmail.com.

Re: [go-nuts] [go test] pure Test Classes.

[Jan Mercl]

On Wed, Jul 26, 2023 at 9:44 AM sumith s  wrote:

> Currently, we do not have pure Test Classes defined by us. We are using 
> Golang specific Test Class structure. Each FILENAME_test.go will have its own 
> test class under "Golang Test".
> I'm trying to define a  pure Test Classes. how can do that?

(Go does not have classes. Go has types and types may have methods attached.)

Anyway, please explain what you mean by "pure" in "pure Test Classes".

The go tool, when invoked like "go test" looks for functions in files
matching '.*_test.go', with name matching 'Test.*' and the signature
func(t *testing.T), "testing" being the stdlib package. Such functions
will be then executed automatically during the test.

It is of course possible to write any other kind of tests and invoke
them independently of the "go test" facility, using any preferred
method of doing so.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-W4PGv00tUGs7SjmDrxecDdJJDNMwhCkdFbFWO5EYNzzA%40mail.gmail.com.

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

[Jan Mercl]

On Wed, Jul 26, 2023 at 12:32 AM Bravo Moua  wrote:

> For a fact, bytes, fmt, and packages in those category are from Satoshi 
> Nakamoto and myself.

Extraordinary claims require extraordinary evidence.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-Xna5Zg-RRygLRquchVC4Z3945kjpE-Z69YBbskB-z0wg%40mail.gmail.com.

Re: [go-nuts] no way to pause `Listen` on net connections

[Jan Mercl]

On Mon, Jul 24, 2023 at 9:26 AM David N  wrote:

> Yup, this makes sense and should work, but I'm still surprised this can't be 
> entirely done in Golang.

Who says it's not possible? I'm not aware of a reason why the required
parts cannot be implemented in pure Go (+ syscalls + right permission
bits): https://git.netfilter.org/iptables/

Alternatively, if CGo is not a problem, libiptables is a thing.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XDMCHtzu2Hb4pV_rWapNozO4xmktODZZzqNk4M-gfHrw%40mail.gmail.com.

Re: [go-nuts] no way to pause `Listen` on net connections

[Jan Mercl]

On Mon, Jul 24, 2023 at 9:14 AM David N  wrote:

On Linux you may try fiddling with iptables, limitations apply:
https://stackoverflow.com/questions/44464617/stop-accepting-new-tcp-connections-without-dropping-any-existing-ones/44509993#44509993

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XA8RtHBvhw9oE2S%3Dhfve%2BUOTwRr8w0zEJs6-9_YKSoVw%40mail.gmail.com.

Re: [go-nuts] testing whether two maps are the same object

[Jan Mercl]

On Tue, Jul 18, 2023 at 4:35 PM Jochen Voss  wrote:

> Is there a better way?

I have never been here and please don't do this:
https://go.dev/play/p/x4QYJubXMnQ

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-Vy94Z%3D2LxbtTYqKzsNetBFcK66nHg28SP3zO9QK6xV9A%40mail.gmail.com.

Re: [go-nuts] map type conversion

[Jan Mercl]

On Sun, Jul 16, 2023 at 6:02 PM Leonard Mittmann
 wrote:

> Hi everyone, I am wondering if there is efficient way to do the following 
> type conversion (without looping over the map):
>
> var m = map[uint]uint{ /*...*/ }
> type uintXXX uint
> // this does not work
> var m2 map[uintXXX]uintXXX = (map[uintXXX]uintXXX)(m)

Yes, AFAICT, the language specification does not allow such
conversion. The underlying types of uintXXX and uint are the same, so
a conversion between uintXXX and uint is allowed in certain
situations. However, the underlying types of map[uintXXX]uintXXX and
map[uint]uint and are different and thus the conversion is not
possible. Exact details available at
https://go.dev/ref/spec#Conversions.

A different question is - could the specs allow this particular
conversion? I guess probably yes. If you can think of a backwards
compatible specs change that relaxes the conversion rules and allows
this and does not have any bad side effects, it might be a good idea
to fill a proposal at the issue tracker. It will be considered, if not
already rejected before.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-Wit7zW7QUDNJR%2BrujhokRxJ0e74xRFTGXX%2BtoNspVB8Q%40mail.gmail.com.

[go-nuts] Re: `go get` and workspaces (`go.work`)

[Jan]

Yes, I read through the thread -- but it seemed different (go work sync / 
go mod tidy). I'll follow up there then.

thanks!


On Friday, July 14, 2023 at 7:10:53 PM UTC+2 Howard C. Shaw III wrote:

> Such an issue is what I linked you to earlier in the thread. So I do not 
> think you need to create a new issue - however, in the comments in that 
> issue one of the devs asks for use cases where go work sync is not 
> sufficient, so you might want to reply to that with your example where go 
> work sync has not been sufficient.
>
> https://github.com/golang/go/issues/50750
>
> Well, it is actually about go mod tidy, but the discussion mentions go get 
> as well, and is generally about why the other tools ignore go.work and 
> whether this should be changed. So I think it is the appropriate forum for 
> that discussion.
>

-- 
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/a128fc26-e19f-4c68-8688-3054d01129ban%40googlegroups.com.

[go-nuts] Re: `go get` and workspaces (`go.work`)

[Jan]

Still on the topic, if I have to use `go.mod` replace clauses, what is the 
point of `go.work` ? Notice replace in `go.work` doesn't work.

Any thoughts if it would be appropriate to create an issue to add workspace 
support for `go get` ?

cheers
On Wednesday, July 12, 2023 at 12:48:57 AM UTC+2 Howard C. Shaw III wrote:

> Okay, yeah, got home and tried it out, and go work sync is not doing what 
> I thought it was. I had to do 
>
> go get github.com/janpfeifer/gonb/gonbui
>
> in a to get it to build and run.
>
> So yeah, if you want to use a bare go get, you have to do replace 
> directives. Blech.
>

-- 
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/bbc72a4a-0bfb-471a-a351-10dc53187d9fn%40googlegroups.com.

[go-nuts] Re: `go get` and workspaces (`go.work`)

[Jan]

I tried exactly that, it doesn't do that ... Am I doing something wrong ?

Notice in the example below the dependency to 
`github.com/janpfeifer/gonb/gonbui`. The command `go work sync` doesn't do 
anything. And `go get` still fails with the same error:

```
$ cat main.go
package main
import (
"fmt"
"github.com/joe/b"
"github.com/janpfeifer/gonb/gonbui"
)

func main() {
fmt.Printf("Hello from joe/a!\n")
b.Message()
fmt.Printf("IsNotebook: %v\n", gonbui.IsNotebook)
}
$ cat go.mod
module github.com/joe/a

go 1.20
$ go work sync
$ cat go.mod
module github.com/joe/a

go 1.20
$ cat go.work
go 1.20

use (
.
/home/janpf/work/b
)
$ go get
github.com/joe/a imports
github.com/joe/b: cannot find module providing package 
github.com/joe/b
```

cheers
On Tuesday, July 11, 2023 at 11:54:56 PM UTC+2 Howard C. Shaw III wrote:

> I'm not suggesting that it would fix go get, but that it replaces it. Add 
> your extra third party reference, then do go work sync and it should 
> download that dependency.

-- 
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/641bb2fc-75b4-4049-a88d-5ec666220666n%40googlegroups.com.

[go-nuts] Re: `go get` and workspaces (`go.work`)

[Jan]

Thanks, yes, I had checked out `go work sync`. I still don't understand 
what it means with "update the modules withing a workspace" though, or what 
this command does. I wish the documentation was more concrete (which files 
it changes, who uses those files, or maybe an example). `go help work sync` 
has a longer description, but I still don't know what it means by 
"workspace's build list". But I don't use workspaces often, so I may be 
missing something obvious.

Anyway I tried `go work sync`, and it doesn't seem to do anything in my 
scenario -- I didn't notice any files changed by it: 

```
$ cd work/a
$ go work sync
$ cat go.work
go 1.20

use (
.
/home/janpf/work/b
)
$ cat go.mod
module github.com/joe/a

go 1.20
$ go get
github.com/joe/a imports
github.com/joe/b: cannot find module providing package 
github.com/joe/b
$ go version
go version go1.20.5 linux/amd64
```

ps.: ToTK seems dangerous! :)
On Tuesday, July 11, 2023 at 10:45:21 PM UTC+2 Howard C. Shaw III wrote:

> Also did you call go work sync? I think that might be what I actually use 
> in place of go mod tidy. Sorry, ToTK has been absorbing my free time, so it 
> has been a while since I worked on the audio project where I used 
> workspaces.
>
> https://github.com/golang/go/issues/50750
>
> "*bcmills  *commented on Jul 25, 2022 
> 
>
> go mod tidy is intended to update the module's self-contained 
> dependencies. It doesn't use the workspace because in general one may work 
> on multiple independently-maintained modules in the same workspace, and if 
> you're preparing an upstream commit you definitely don't want that commit 
> to rely on unpublished local modifications.
>
> go work sync is intended to update the modules within a workspace to 
> reflect the dependencies selected in that workspace. That is probably what 
> you want if you are working on a set of modules that are all maintained as 
> a single unit."
> It seems like currently you are basically forced to use 'go work sync' to 
> update dependencies when using workspaces, and not use 'go mod tidy' or a 
> bare 'go get'.
>

-- 
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/d90a22be-913c-433b-8fc6-6efb17f0f2f4n%40googlegroups.com.

[go-nuts] Re: `go get` and workspaces (`go.work`)

[Jan]

Thanks for the reply, but I'm not sure what exactly what you mean.

In my example it's not that I need to `go get` anything for my locally 
stored packages (so I don't need to get `github.com/joe/b`). Rather, I need 
`go get` for other packages. But it (`go get`) fails on the local stored 
packages (`github.com/joe/b` in the example), it doesn't fetch the other 
packages either. Does it make sense ?

Would you mind clarifying ?

Btw, I tried `go mod tidy` in the `~/work/a` directory, in the example I 
created and I get:

```
$ go mod tidy
go: finding module for package github.com/joe/b
github.com/joe/a imports
github.com/joe/b: cannot find module providing package 
github.com/joe/b: module github.com/joe/b: git ls-remote -q origin in 
/home/janpf/src/go/pkg/mod/cache/vcs/ec7e851af7fd4aeb2a38ed2f81b738f5af4402954d5c2f4c363f5fb9f1b4583c:
 
exit status 128:
fatal: could not read Username for 'https://github.com': terminal 
prompts disabled
Confirm the import path was entered correctly.
If this is a private repository, see https://golang.org/doc/faq#git_https 
for additional information.
```

In my case let's assume I modify my program `~/work/a/main.go` to use an 
external library:

```
$ cat ~/work/a/main.go
package main
import (
"fmt"
"github.com/joe/b"
"github.com/janpfeifer/gonb/gonbui"
)

func main() {
fmt.Printf("Hello from joe/a!\n")
b.Message()
fmt.Printf("IsNotebook: %v\n", gonbui.IsNotebook)
}
```

Now I want `go get` to fetch me the `gonbui` package:

```
$ go get
github.com/joe/a imports
github.com/joe/b: cannot find module providing package 
github.com/joe/b
```

It fails, and hence my program doesn't run. Same with `go mod tidy`, which 
also fails.

Any ideas ?






On Tuesday, July 11, 2023 at 2:46:11 PM UTC+2 Howard C. Shaw III wrote:

> I don't think you need to run go get there at all - just run go mod tidy, 
> and then when you go build, if it needs something it will get it. If you 
> need to download without building, go mod download will do that.
>
> Howard
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c052e39d-109b-4d8c-9ac9-94a5b19d4b8fn%40googlegroups.com.

[go-nuts] `go get` and workspaces (`go.work`)

[Jan]

hi all,

When using a `go get` in a project (module) that has a `go work` 
configured, I'm getting errors "cannot find module providing package ...", 
for the packages that are located on `go work use ...` locations. Meaning, 
`go get` seems to ignore (?) `go.work` file.

Likely this is deliberate and I'm missing some point, but ... for my use 
case, I would love to have `go get` ignore the packages that are imported 
from directories in `go.work`, and just "get" the other ones.

Is there a way to have that ? (I couldn't find any flag in `go get`). Or 
any other ideas ?

many thanks!
Jan

ps.: Here how to reproduce the issue:

Director "~/work/a/"

$ go mod init "github.com/joe/a"
$ cat > main.go
package main
import (
"fmt"
"github.com/joe/b"
)

func main() {
fmt.Printf("Hello from joe/a!\n")
b.Message()
}
$ go work init ; go work use .  ~/work/b

In directory "~/work/b":

$ go mod init "github.com/joe/b"
$ cat > b.go
package b
import "fmt"
func Message() {
fmt.Printf("Hello from joe/b!\n")
}

Back to directory "~/work/a":

$ go run .
Hello from joe/a!
Hello from joe/b!

*$ go get*

*github.com/joe/a importsgithub.com/joe/b: cannot find module 
providing package github.com/joe/b*

A bit more context, in case it matters: I don't need to `go get` to get 
anything for the packages in `go.work`, but I (think) need it to get any 
potential missing other packages. I run `go get` (without specifying the 
packages) each time before executing a Jupyter notebook cell (in GoNB a 
jupyter notebook kernel), because I don't know ahead of time which new 
packages need to be fetched. 

Also curiously, if I use a `replace` directive in `go.mod` then `go get` 
works fine, it seems to ignore the replaced package. In my example:

$ go mod edit --replace github.com/job/b=/home/janpf/work/b

But a `replace` directive in `go.work` doesn't seem parsed by `go get`:

$ go work edit --replace github.com/job/b=/home/janpf/work/b

-- 
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/200cdca3-2dfd-41b1-a407-c30071803520n%40googlegroups.com.

Re: [go-nuts] Why not return after calling http.Error()

[Jan Mercl]

On Tue, Jul 4, 2023 at 5:38 PM Gurunandan Bhat  wrote:

> Every example of http Handler that I have seen so far looks like this:
>
> func handleSomeRequest(w http.ResponseWriter, r *http.Request) {
>
> // do something that returns an error
> if err != nil {
> http.Error(w, "Something bad happened", http.SomeAppropriateStatus)
> }
>
> // do other things if there was no error above and finally
> w.Write(someBytes)
> }
>
> My question is: Assuming there is no point carrying on after "Something bad 
> happened" why don't we just return (after writing someBytes to w inside the 
> if error != nil if that is what is expected). I have never seen any code that 
> returns after calling Error(), and I wonder why.

>From the docs at https://pkg.go.dev/net/http#Error


It does not otherwise end the request; the caller should ensure no
further writes are done to w.


AFAICT you're right, correct handler code should return after calling
http.Error.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-V3mw2S2hY%3DpnAG3axfE_PTV%2BC0CQPT8uF2dWBQw%2BQt%2Bg%40mail.gmail.com.

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

[Jan]

Thanks for the pointer Sven!

I think I was once told not to use panic/defer/recover to implement generic 
exceptions in Go, and never reconsidered it. I think I'm taking up on your 
suggestion for my library.


On Wednesday, June 28, 2023 at 7:30:41 PM UTC+2 Sven Anderson wrote:

> I think for what you want to do you don't need any language extension. You 
> can implement all that within the current language. Look at this example: 
> https://go.dev/play/p/aqjwzknrArH
>
> If you want to catch errors also in nested functions, you can also skip 
> the ErrorChecker type and do it like this: 
> https://go.dev/play/p/3Fk-82zxtUJ
>
> If you don't like the named return parameter, you can use a wrapper 
> function:
> https://go.dev/play/p/C54vQThPUnq
>
> I thought about putting something like that in a package on github. But it 
> is such a small code, that I think copy and paste is just fine. :-)
>
> Cheers
>
>
> On Sun, Jun 4, 2023 at 6:17 PM Shulhan  wrote:
>
>> Dear gophers,
>>
>> I have been reading several proposals about error handling couple of
>> months ago and today a light bulb come upon me, and then I write as much
>> as I can think.  I am not sure if its good or bad idea or even possible
>> to implement.
>>
>> In this post, I will try as concise as possible.
>> The full and up to date proposal is available at
>> https://kilabit.info/journal/2023/go2_error_handling/ .
>>
>> Any feedback are welcome so I can see if this can move forward.
>> Thanks in advance.
>>
>> ==  Background
>>
>> This proposal is based on "go2draft Error Handling".
>>
>> My critics to "go2draft Error Handling" is the missing correlation
>> between handle and check.
>> If we see one of the first code in the design,
>>
>> 
>> ...
>> handle err {
>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>> }
>>
>> r := check os.Open(src)
>> ...
>> 
>>
>> There is no explicit link between check keyword and how it will trigger
>> handle err later.
>> It is also break the contract between the signature of os.Open, that
>> return an error in the second parameter, and the code that call it.
>>
>> This proposal try to make the link between them clear and keep the code
>> flow explicit and readable.
>>
>> The goals is not to reduce number of lines but to minimize repetitive
>> error handling.
>>
>>
>> == Proposal
>>
>> This proposal introduces two new keywords and one new syntax for
>> statement.
>>
>> The two new keywords are “WHEN” and “HANDLE”.
>>
>> 
>> When = "when" NonZeroValueStmt HandleCallStmt .
>> NonZeroValueStmt = ExpressionStmt
>>  ; I am not quite sure how to express non-zero value
>>  ; expression here, so I will describe it below.
>>
>> HandleCallStmt   = "handle" ( HandleName | "{" SimpleStmt "}" ) .
>> HandleName   = identifier .
>> 
>>
>> The HandleCallStmt will be executed if only if the statement in
>> NonZeroValueStmt returned non-zero value of its type.
>> For example, given the following variable declarations,
>>
>> 
>> var (
>> err   = errors.New(`error`)
>> slice = make([]byte, 1)
>> no1   = 1
>>
>> no2 int
>> ok  bool
>> )
>> 
>>
>> The result of when evaluation are below,
>>
>> 
>> when err // true, non-zero value of type error.
>> when len(slice) == 0 // true, non-zero value of type bool.
>> when no1 // true, non-zero value of type int.
>> when no2 // false, zero value of int.
>> when ok  // false, zero value of bool.
>> 
>>
>> The HandleCallStmt can jump to handle by passing handle name or provide
>> simple statement directly.
>> If its simple statement, there should be no variable shadowing happen
>> inside them.
>>
>> Example of calling handle by name,
>>
>> 
>> ...
>> when err handle myErrorHandle
>>
>> :myErrorHandle:
>> return err
>> 
>>
>> Example of calling handle using simple statement,
>>
>> 
>> ...
>> when err handle { return err }
>> 
>>
>> The new syntax for statement is to declare label for handle and its body,
>>
>> 
>> HandleStmt  = ":" HandleName ":" [SimpleStmt] [ReturnStmt | 
>> HandleCallStmt] .
>> 
>>
>> Each of `HandleStmt` MUST be declared at the bottom of function block.
>> An `HandleStmt` can call other `HandleStmt` as long as the handle is 
>> above the
>> current handle and it is not itself.
>> Any statements below `HandleCallStmt` MUST not be executed.
>>
>> Unlike goto, each `HandleStmt` is independent on each other, one 
>> `HandleStmt`
>> end on itself, either by calling `return` or `handle`, or by other
>> `HandleStmt` and does not fallthrough below it.
>>
>> Given the list of handle below,
>>
>> 
>> :handle1:
>> S0
>> S1
>> :handle2:
>> handle handle1
>> S3
>> 
>>
>> A `handle1` cannot call `handle2` because its below it.
>> A `handle2` cannot call `handle2`, because its the same handle.
>> A 

Re: [go-nuts] Re: [RFC] Yet another proposal for Go2 error handling

[Jan]

Thanks for the clarification Robert.

In many cases, when building ML models, panicking is fine. But in some, it 
is not, specially if running some type of server, that will handle 
different models, or with various shapes of inputs (e.g. images in 
different sizes and formats, some may lead to unexpected invalid 
combinations, that cannot crash a server).

Now using a DSL and go generate seems not ergonomic ? I understand it 
wouldn't play well with IDEs (auto-complete, info about the parameters of 
function one is calling, etc.), and other various checks we get for 
granted. Or am I missing something? Care to give a small example of what 
you envision ? 

Notice these math functions are inter-spaced with normal Go code. Some 
recent example code here 
<https://github.com/gomlx/gomlx/blob/main/examples/oxfordflowers102/diffusion/diffusion.go>
 (an 
example diffusion model, that generates flower images 
<https://github.com/gomlx/gomlx/blob/main/examples/oxfordflowers102/OxfordFlowers102_Diffusion.ipynb>)
  for 
those curious.


On Monday, June 19, 2023 at 6:36:28 AM UTC+2 Robert Engels wrote:

> What I was suggesting was a far narrower scope. I can see how go’s error 
> handling makes writing composable math functions more difficult (although I 
> would think these would panic not return an error - so then it is trivial). 
>
> If they do need to return errors then using a DSL for the equations and go 
> generate you don’t really care how much boilerplate code there is - you 
> don’t read or edit it. 
>
> On Jun 18, 2023, at 3:10 PM, Jan Pfeifer  wrote:
>
> 
>
> A DSL + code generator is a longer discussion. But I'm not sure I'm 
> getting the scope of your suggestion right:
>
> If you refer to having a full ML language DSL and a 
> generator/AOT(ahead-of-time) compiler: folks have tried it before -- see 
> the Swift ML effort by Chris Lattner, now leading Mojo in Modular AI. I 
> don't know the detailed story there, but I thought hard about this (having 
> a separate ML language and generator) before I started the GoMLX project. 
> But from what I can imagine some of the shapes (and hyperparameters) that 
> need checking often are only known at runtime. Also for development and 
> debugging it complicates things: it's super nice to have a full language 
> (Go) in parallel to constructing the graph. 
>
> If you are referring to a DSL and code generator for error handling only: 
> I'm not sure it would work well because it requires an extra step when 
> developing ... it is just not as convenient / portable -- for instance for 
> IDEs; also I'm often coding in a Jupyter Notebook using GoNB 
> <https://github.com/janpfeifer/gonb>, which would also need 
> modifications. Better if there was some form of support for the language. 
> I'm hoping some error handling proposal would cover this use case.
>
>
> On Sun, Jun 18, 2023 at 5:11 PM Robert Engels  
> wrote:
>
>> Seems  the easiest way to address that is with a DSL and a code 
>> generator. 
>>
>> On Jun 18, 2023, at 9:47 AM, Jan Pfeifer  wrote:
>>
>> 
>> hi Shulhan, I see your points, thanks for the reply. Let me comment on 
>> them below:
>>
>> On Sat, Jun 17, 2023 at 9:21 AM Shulhan  wrote:
>>
>>> Hi Jan, thanks for response.
>>>
>>> On Mon, 5 Jun 2023 01:06:37 -0700 (PDT)
>>> Jan  wrote:
>>>
>>> > Repeating Justin's consideration: one of my (and from colleagues I
>>> > discuss the topic with) major issues with current error handling is
>>> > the repetition of identical code. Your proposal still requires `when
>>> > err handle ...` at every statement.
>>>
>>> Yes, correct.
>>> The idea is not to minimise repetition on error handling statement, the
>>> "if err != nil", but to minimise repetitive error handling body by
>>> grouping it into single handle based on the context of error.
>>>
>>
>> Oh, I see. I have to say I wish one didn't need to do the `if err != nil` 
>> all the time either, when the handling is the same :) But if that is your 
>> proposal it makes sense.
>>
>> > It also doesn't allow for nested
>>> > call of functions that return errors -- e.g: `f(g(h(x)))`, where `h`,
>>> > `g`, and `f` can return errors (all presumably handled the same way).
>>> > 
>>>
>>> I am not sure I understand this, but should not each function handle it
>>> on its own?
>>> Or should not `f` being called if `g` return an error?
>>> If its later, yes, it does not allow for nested handling of error.
>>>
>>
>> Sorry I was not cle

Re: [go-nuts] delve crashes in presence of a circular reference variable

[Jan Mercl]

On Fri, Jun 23, 2023 at 10:38 AM christoph...@gmail.com
 wrote:
>
> Here is the minimal example code causing delve 1.20.2 to crash with a stack 
> overflow
>
> func TestExample(t *testing.T)  {
> type pptr *pptr
> var p pptr
> p = &p
> t.Error("hello")
> }
>
> Here is the stack trace

I guess you may get better feedback by issuing the report at
https://github.com/go-delve/delve/issues.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XYw2TN-QZOcBakTyRiQLmB5JsLthdQCEL%2BME45yP3HeQ%40mail.gmail.com.