Re: [go-nuts] no direct write to a complex types components?

https://go.dev/play/p/_uLHdBIRLBv - sean On Sat, Nov 9, 2024, 00:25 'simon place' via golang-nuts < golang-nuts@googlegroups.com> wrote: > {please tell me if i am missing something here} > > 1. seems common to want to change a component of a complex number. > > 2. seems common to manipulate comp

[go-nuts] no direct write to a complex types components?

{please tell me if i am missing something here} 1. seems common to want to change a component of a complex number. 2. seems common to manipulate complex numbers in a tight loop (simulation) but whereas you can read a component... real com.:=Real(cmplx) imaginary com.:=Imag(cmplx) i can't see a

Re: [go-nuts] cmd.ExtraFiles == nil, yet process inherits FDs?

On Fri, Nov 8, 2024 at 2:18 AM Peter Galbavy wrote: > > I have a command line manager tool that builds the starting environment for a > process and calls cmd.Start(). > > The code sets (doesn't need to as it starts as nil, but does to be extra > explicit) cmd.ExtraFiles = nil, but even then I se

Re: [go-nuts] LLM development toolkit.

You might like this dev.to/pullreview/creating-a-remote-git-hub-for-your-companywithout-github-1fdb On Friday, November 8, 2024 at 8:34:55 AM UTC-8 Dimas Prawira wrote: > It is not uncommon to shared go either library or application through git > with zip file, the common way is share the code i

Re: [go-nuts] Re: ANN: gocov, a Go coverage testing tool

On Fri, Nov 8, 2024 at 9:13 AM 'N Hess' via golang-nuts wrote: > > gocov 1.2.1 has a bug that makes it report lower module coverages - we had to > revert to 1.1.0. Too bad the repo is closed and read-only now. > > I can provide a way to reproduce if needed. N You are replying to a message that i

[go-nuts] Re: ANN: gocov, a Go coverage testing tool

gocov 1.2.1 has a bug that makes it report lower module coverages - we had to revert to 1.1.0. Too bad the repo is closed and read-only now. I can provide a way to reproduce if needed. N On Saturday, July 7, 2012 at 5:42:43 AM UTC-7 Andrew Wilkins wrote: > Hi all, > > I had a scratch to itch, t

Re: [go-nuts] LLM development toolkit.

It is not uncommon to shared go either library or application through git with zip file, the common way is share the code itself and then put information how to use it (if an app) or import it (if it is a library) in the readme. regards On Fri, Nov 8, 2024 at 3:43 PM alex-coder wrote: > Hi All

Re: [go-nuts] LLM development toolkit.

Why not share the files themselves instead of a zip file? Why would anyone trust a zip file from some random nut ? On Fri, Nov 8, 2024 at 3:43 AM alex-coder wrote: > Hi All ! > > I recently finished coding the initial version of the llm development > toolkit. You may touch the toolkit there: Git

Re: [go-nuts] atomic variables?

Relaxed atomics can be significantly easier to misuse than they first appear. If this is something you’ll be working with, I’d highly recommend watching Herb Sutter’s ~3hr workshop on atomics - it will cover many of the things you seem interested in (overhead of atomics vs regular loads/stores on v

Re: [go-nuts] atomic variables?

Thanks for the resource Scott https://bartoszmilewski.com/2008/12/01/c-atomics-and-memory-ordering/ On Thu, Nov 7, 2024 at 7:25 PM scott beeker wrote: > *True* > *However, it's important to note that in some cases, multiple loads might > be necessary for correctness, such as in certain lock-free

Re: [go-nuts] Golang career

Hey, in terms if it's worth or not, it's a rather personal question. How much you like Go and wanna work with it or do you just wanna add another skill to enhance your employability. I pretty much learnt Go reading the Effective Go (https://go.dev/doc/effective_go). If you are an experienced s

[go-nuts] Re: cmd.ExtraFiles == nil, yet process inherits FDs?

(yes, the above code is dumb and I have squashed it, to just keep the max fd without a slice ... it just started out with something else) On Friday 8 November 2024 at 10:39:12 UTC Peter Galbavy wrote: > Having added this, the child process now does not inherit those FDs: > > // mark all non

[go-nuts] Re: cmd.ExtraFiles == nil, yet process inherits FDs?

Having added this, the child process now does not inherit those FDs: // mark all non-std fds unshared cmd.ExtraFiles = []*os.File{} // un-inherit all FDs explicitly fds, err := os.ReadDir("/proc/self/fd") if err != nil { return } var intfds []int for _, f :

[go-nuts] cmd.ExtraFiles == nil, yet process inherits FDs?

I have a command line manager tool that builds the starting environment for a process and calls cmd.Start(). The code sets (doesn't need to as it starts as nil, but does to be extra explicit) cmd.ExtraFiles = nil, but even then I seem to inherit a bunch of FDs from the CLI - I noticed because t

[go-nuts] LLM development toolkit.

Hi All ! I recently finished coding the initial version of the llm development toolkit. You may touch the toolkit there: GitHub - gussev/llm: large language model Thank you. -- You received this message because you are subscribed to the Google Groups "golang-n