[go-nuts] Re: Compiler treatment of infinite loops

Another way to look at it. The Go Programming Language Specification https://golang.org/ref/spec For statements For statements with for clause ForClause = [ InitStmt ] ";" [ Condition ] ";" [ PostStmt ] . Any element of the ForClause may be empty but the semicolons are required unless there i

[go-nuts] Compiler treatment of infinite loops

The Go compiler (I'm using go1.16 linux/amd64) correctly infers that function with an infinite for { … } loop that conditionally returns a value from within the loop does not also need to return a value at the end of the function: - https://play.golang.org/p/07ZjFx2uJlx However, changing th

Re: [go-nuts] Modules and internal packages

Just to close the loop, I've got a solution that's working well enough for my personal use. It takes advantage of GitHub's Template repo feature and the gh CLI tool to simplify the process of creating a new repository with a clone of the skeleton and a local copy thereof. Using Axel's sugges

Re: [go-nuts] how can I solve it 2 decimal places float32 with fmt.Println()

If the problem is that you want to have a newline at the end of your answer you can just put "\n" at the end of your string. If you want to do the same using fmt.Println, you can check fmt.Sprintf :) Otherwise indeed your issue is not that clear to me. Le jeu. 4 mars 2021 à 17:31, Tareq Ibna a é

Re: [go-nuts] Issuing a blocking system call

On Wed, Mar 3, 2021 at 2:00 PM Florian Weimer wrote: > > Do I have to tell the runtime that a system call is blocking? For > example, I use this code snippet to perform a blocking ioctl: > > conn, err := file.SyscallConn() > if err != nil { > return > } >

[go-nuts] Re: Golang mentioned on Penn and Teller: Fool Us?

https://www.bell-labs.com/usr/dmr/www/labscam.html Cheers, Anthony -- 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

Re: [go-nuts] Type name format in dwarf

On Thu, Mar 4, 2021 at 9:52 AM 'Dmitry Neverov' via golang-nuts wrote: > > Please help me understand the type name format generated in debug info. > > Mostly they seem to be in the . format, but sometimes > _test is appended to import path. Also it seems like some parts of import > path are url-

[go-nuts] Type name format in dwarf

Please help me understand the type name format generated in debug info. Mostly they seem to be in the . format, but sometimes _test is appended to import path. Also it seems like some parts of import path are url-encoded: type T defined in package pkg of the go module github.com/my/pkg.v2 gets

Re: [go-nuts] Golang mentioned on Penn and Teller: Fool Us?

Rob Pike actually participated in their show in 1989: https://youtu.be/UbqUgIrO7xM?t=184 On Thu, 4 Mar 2021, 14:09 Tom Limoncelli, wrote: > No. Not really. > > However, on the most recent episode of Penn and Teller: Fool Us > ( > https://www.cwtv.com/shows/penn-teller-fool-us/back-to-the-future/

[go-nuts] Golang mentioned on Penn and Teller: Fool Us?

No. Not really. However, on the most recent episode of Penn and Teller: Fool Us (https://www.cwtv.com/shows/penn-teller-fool-us/back-to-the-future/?play=0956383f-3701-4908-8263-a3778e3d2ead) someone drew a picture of Penn. While talking about it, Penn mentioned that Rene French once drew a portra

[go-nuts] Re: how can I solve it 2 decimal places float32 with fmt.Println()

Can you tell us what the problem is that you want to solve? The code3 seems to run just fine. On Thursday, March 4, 2021 at 11:31:57 AM UTC-5 Tareq Ibna wrote: > package main > import "fmt" > > func main(){ > > //I want to solve this peoblen with fmt.Println() please help. > > > var a,

Re: [go-nuts] should I pass functions as parameter of a go routine?

Thank you for your quick answer, it is of a great help. have a nice day. On Thursday, March 4, 2021 at 5:11:40 PM UTC+1 axel.wa...@googlemail.com wrote: > Interesting question. I think the code is fine. From the spec > : > > > The function value and p

Re: [go-nuts] Modules and internal packages

On Thursday, March 4, 2021 at 11:01:06 AM UTC-5 axel.wa...@googlemail.com wrote: > On Thu, Mar 4, 2021 at 4:51 PM Michael Ellis wrote: > >> My bad. I should have tested before writing that. Thanks for checking. >> Good to know the tools are enforcing the distinction. Still, the import >>

[go-nuts] how can I solve it 2 decimal places float32 with fmt.Println()

package main import "fmt" func main(){ //I want to solve this peoblen with fmt.Println() please help. var a, b ,c float32 fmt.Println(" Enter 1st number:" ) fmt.Scan( &a) fmt.Println(" Enter 2nd number:" ) fmt.Scan( &b) c= a/b fmt.Printf(" %.2f", c) } -- You received t

Re: [go-nuts] Modules and internal packages

On Thursday, March 4, 2021 at 10:06:01 AM UTC-5 Bryan C. Mills wrote: > > I would argue that the “hack” in this case is the approach of defining the > API in terms of copying in an entire tree of packages, rather than having > users of the API make function calls into a specific set of (unmodi

Re: [go-nuts] should I pass functions as parameter of a go routine?

Interesting question. I think the code is fine. From the spec : > The function value and parameters are evaluated as usual in the calling goroutine, but unlike with a regular call, program execution does not wait for the invoked function to complete. Thi

Re: [go-nuts] Modules and internal packages

On Thu, Mar 4, 2021 at 4:51 PM Michael Ellis wrote: > My bad. I should have tested before writing that. Thanks for checking. > Good to know the tools are enforcing the distinction. Still, the import > path requirement does get in the way of being able to create a new > application by cloning an

[go-nuts] should I pass functions as parameter of a go routine?

Hello, In the following example: https://play.golang.org/p/yz_ifHC-Hut for _, onedoer := range d { go onedoer.do(&wg) } Should I pass the function onedoer.do as a parameter of the go routine: https://play.golang.org/p/WHPahoayDbM ? for _, onedoer := range d { go func(od *doer, w *sync.Wai

Re: [go-nuts] Modules and internal packages

On Thursday, March 4, 2021 at 10:14:03 AM UTC-5 axel.wa...@googlemail.com wrote: > On Thu, Mar 4, 2021 at 3:54 PM Michael Ellis wrote: > >> Not sure if my case is all that special. Seems like the requirement for >> a full path to an internal package breaks the concept of "internal" because

Re: [go-nuts] Idiomatic Go code

On Thu, Mar 4, 2021 at 4:28 PM Christian von Kietzell < chris...@vonkietzell.de> wrote: > Side note about flushing: I'm flushing the wrapping > bufio.Writer there. I'd be surprised closing the underlying os.File would > be > enough to ensure all buffer contents have been written. > True, I didn't

Re: [go-nuts] Idiomatic Go code

Hi, thank you for the helpful comments. That's what I love about the Go community. On Thu, Mar 04, 2021 at 03:14:04PM +0100, 'Axel Wagner' via golang-nuts wrote: > - Who's responsible for doing that work? If I return *os.File directly > from getFile(), there's an implicit assumption that

Re: [go-nuts] Modules and internal packages

On Thu, Mar 4, 2021 at 3:54 PM Michael Ellis wrote: > Not sure if my case is all that special. Seems like the requirement for a > full path to an internal package breaks the concept of "internal" because > it gives everyone import access to whatever the internal package exports. > Really? I can

Re: [go-nuts] Modules and internal packages

On Thu, Mar 4, 2021 at 9:54 AM Michael Ellis wrote: > On Thursday, March 4, 2021 at 2:24:11 AM UTC-5 axel.wa...@googlemail.com > wrote: > >> On Thu, Mar 4, 2021 at 12:55 AM Michael Ellis >> wrote: >> >>> Thanks even though it's not the answer I was hoping for. Seems to me >>> that since the Go

Re: [go-nuts] Modules and internal packages

On Thursday, March 4, 2021 at 2:24:11 AM UTC-5 axel.wa...@googlemail.com wrote: > On Thu, Mar 4, 2021 at 12:55 AM Michael Ellis > wrote: > >> Thanks even though it's not the answer I was hoping for. Seems to me >> that since the Go Authors have accorded special status to directories named

Re: [go-nuts] Idiomatic Go code

I don't think it's inherently *un*idiomatic to return a cleanup function. But in this case, it seems unnecessarily complicated (and buggy). On Thu, Mar 4, 2021 at 2:19 PM Christian von Kietzell < chris...@vonkietzell.de> wrote: > - doSomething doesn't care whether the output is a file or a buffer

Re: [go-nuts] Idiomatic Go code

On Thu, Mar 4, 2021 at 6:19 AM Christian von Kietzell wrote: > > Hello Gophers, > > since I obviously don't have enough Twitter followers to get more than > one answer to my Go question I'm posting it here ;-) > > Would you consider this idiomatic Go code? > > https://play.golang.org/p/ymPt_9tKQ9p

[go-nuts] Idiomatic Go code

Hello Gophers, since I obviously don't have enough Twitter followers to get more than one answer to my Go question I'm posting it here ;-) Would you consider this idiomatic Go code? https://play.golang.org/p/ymPt_9tKQ9p I'm talking specifically about returning a cleanup function. My reasoni