[go-nuts] email body not showing up

I have implement below code, but body not showing up, so whats wrong with the code? // Connect to the remote SMTP server. c, err := smtp.Dial("mail.example.com:25") if err != nil { log.Fatal(err) } // Set the sender and recipient first if err := c.Mail("sen...@example.org"); err != nil { l

Re: [go-nuts] Re: I am starting Golang and I am looking for a example to Login, Logout, Signup..

In golang you have to mix and match various libraries. - For CSRF, I use http://www.gorillatoolkit.org/pkg/csrf - For password encryption, I use https://godoc.org/golang.org/x/crypto/bcrypt I like using golang without a comprehensive web framework because I understand all the pieces involved in m

[go-nuts] Do I need to use runtime.KeepAlive in this case?

package main // void a(long *p) {} import "C" import ( "unsafe" ) //go:noinline func b() { x := int64(0) C.a((*C.long)(unsafe.Pointer(&x))) // do something without x } func main() { b() } x should be considered unreachable after C.a . If x is something allocated on heap, do I need to use runt

[go-nuts] Re: I am starting Golang and I am looking for a example to Login, Logout, Signup..

Have you checked this? https://gist.github.com/mschoebel/9398202 -- 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. For mo

Re: [go-nuts] Re: Deferring a close that can fail

Hmmn, Donald Knuth would not have liked this (;-)) Knuthput, if I remember correctly, didn't have "fail on close()" semantics. > > --dave -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails fr

[go-nuts] [security] Vulnerability in golang.org/x/crypto/salsa20

Hello gophers, Commit b7391e95 fixes a vulnerability in the amd64 implementation of the golang.org/x/crypto/salsa20 and golang.org/x/crypto/salsa20/salsa packages that affects large message sizes or high counter values.

Re: [go-nuts] Re: Deferring a close that can fail

Looks as if "Close()-like things" all fall into two categories - the usual horrid one, in which you can discover too late something didn't complete, or - the trivial case, in which the pre-close operations are transactional and xxx.Close() only ever returns nil Which means I have to

Re: [go-nuts] Re: Deferring a close that can fail

On Wednesday, March 20, 2019 at 10:53:44 PM UTC+1, Kurtis Rader wrote: > > On Wed, Mar 20, 2019 at 2:08 PM Manlio Perillo > wrote: > >> Note from the Linux close documentation: >> >> Not checking the return value of close() is a common but nevertheless >> serious programming error. It is quite po

Re: [go-nuts] Re: Deferring a close that can fail

On Wed, Mar 20, 2019 at 2:08 PM Manlio Perillo wrote: > Note from the Linux close documentation: > > Not checking the return value of close() is a common but nevertheless > serious programming error. It is quite possible that errors on a previous > write (2) ope

[go-nuts] Re: Deferring a close that can fail

On Wednesday, March 20, 2019 at 12:57:51 AM UTC+1, David Collier-Brown wrote: > > It's a known bad thing to defer a close for anything buffered, as > discussed at https://www.joeshaw.org/dont-defer-close-on-writable-files/ > but some constructs lack a Sync() call. > > Note from the Linux close do

Re: [go-nuts] Deferring a close that can fail

> > On Wednesday, March 20, 2019 at 1:44:23 AM UTC-4, Shulhan wrote: Any Close on file or connection should be called only if only the > call to Open function or method success. > > You have two options here: either you remove the panic when Close is > error (only logging it) or call Close onl

Re: [go-nuts] Deferring a close that can fail

The update statement is fine as long as any data sources participate in an XA transaction. This is bar the simplest solution but may not meet performance constraints which is why people use other techniques. > On Mar 20, 2019, at 4:13 PM, David Collier-Brown wrote: > > > > > > 4:12 PM

Re: [go-nuts] Deferring a close that can fail

4:12 PM (less than a minute ago) > Any Close on file or connection should be called only if only the > call to Open function or method success. > > You have two options here: either you remove the panic when Close is > error (only logging it) or call Close only if Open is success. I > usual

Re: [go-nuts] Deferring a close that can fail

> > Any Close on file or connection should be called only if only the > call to Open function or method success. > > You have two options here: either you remove the panic when Close is > error (only logging it) or call Close only if Open is success. I > usually prefer the latter. > You an

Re: [go-nuts] boringcrypto+fipsonly: way more strict than fips 140-2?

On Wed, 20 Mar 2019 03:10:37 -0700 (PDT) Riccardo Raccuia wrote: > My intent is not to start a debate on any cipher/mode/signature algs' > weaknesses but merely to understand some the limitations that are enforced > when using the "crypto/tls/fipsonly" package of the famous boringcrypto > fork

Re: [go-nuts] Go command support for "make"

On Wed, Mar 20, 2019 at 7:01 AM Paul Jolly wrote: > > > test $(go list -f '{{.Stale}}' internal/package$) = "true" > > Does .Stale still have meaning/is it still accurate in a build cache world? I doubt it, but I'm not sure the original question has any meaning in that world. In a build cache wo

Re: [go-nuts] Go command support for "make"

Hi Ian, > test $(go list -f '{{.Stale}}' internal/package$) = "true" Does .Stale still have meaning/is it still accurate in a build cache world? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving e

Re: [go-nuts] Go command support for "make"

On Tue, Mar 19, 2019 at 10:05 PM Lucio wrote: > > I'm hoping this already has an answer, rather than require additional > features. I also don't expect this to be a popular request, but I do consider > its merits as greater than the disadvantages, so here goes. > > Efforts to eliminate the use o

Re: [go-nuts] Deferring a close that can fail

On Wed, Mar 20, 2019 at 12:57 AM David Collier-Brown wrote: > Is there an idiomatic way to address this? I ended up reading influxDB > code and doing all sorts of deranged safety-critical-system DFAs to > reassure myself this will actually work, but every time I do that, my brain > hurts! > > Not

Re: [go-nuts] [ANN] Fyne reaches 1.0

Hi Nick, Thanks for your message. As far as I can tell you cannot use OpenGL without Cgo or a native binding - like you say it would require reimplementing OpenGL in Go. We could, however, provide alternative drivers. The Shiny project has pure Go drivers for Windows and Linux which avoid OpenGL

[go-nuts] boringcrypto+fipsonly: way more strict than fips 140-2?

Hello golang-nuts, I haven't found a single discussion about this so out of pure curiosity i'm going to try and shoot the question. My intent is not to start a debate on any cipher/mode/signature algs' weaknesses but merely to understand some the limitations that are enforced when using the "

Re: [go-nuts] [ANN] Fyne reaches 1.0

Quoth Andrew Williams: > I just wanted to drop a quick announcement here for anyone watching the > progress of Fyne - we have reached 1.0! We now have a stable and performant > base API. This looks great, congratulations on reaching 1.0! I had very vaguely been aware of this project, but readi

[go-nuts] [ANN] Fyne reaches 1.0

I just wanted to drop a quick announcement here for anyone watching the progress of Fyne - we have reached 1.0! We now have a stable and performant base API. Moving forward we are excited to add new features and enhancements that have been requested over the months of development. The main

Re: [go-nuts] protobuf and golang

Thanks, I'll check it out. On Wed, Mar 20, 2019 at 2:23 AM Ian Denhardt wrote: > This might be more directly what you're after: > > https://kaitai.io/ > > Though disclaimer, I haven't used it myself. > > Quoting Wojciech S. Czarnecki (2019-03-19 20:25:08) > > On Mon, 18 Mar 2019 09:59:59 -07