Re: [go-nuts] Contrary to popular opinion...

Don’t bother… Python is an abomination. Perfect for one-off scripts - anything beyond that steer clear. > On Feb 27, 2021, at 12:59 PM, Amnon wrote: > > I liked Python too. > But I never really understood why anyone though that dynamic typing was a > good idea. > Or why performance was so

Re: [go-nuts] Contrary to popular opinion...

Well, it seems that you don't like Python any more :) But I do like it -- and I like Go too. I'd guess that lots of other folks have figured out positive answers to your Python issues, 'cause Python ranks high on the popularity lists. E.g on the issue of invisible characters having semantic

[go-nuts] golang.org/x/sys and unsafe usage

Hi, I'm a bit confused as to how the golang.org/x/sys package works. >From the documentation of unsafe.Pointer: >(4) Conversion of a Pointer to a uintptr when calling syscall.Syscall. > The Syscall functions in package syscall pass their uintptr arguments > directly to the operating system,

Re: [go-nuts] golang.org/x/sys and unsafe usage

Hi, not an expert, but. On Sat, Feb 27, 2021 at 11:19 PM Reto wrote: > Now, as far as I can tell this forces non stdlib packages to adhere to > exactly that. > As far as I can tell x/sys is just a common namespace for the go authors, > but > as far as the compiler itself is concerned, that's a

Re: [go-nuts] golang.org/x/sys and unsafe usage

Oh, forgot to mention: The code I linked to has been moved or removed in master, vs. go 1.16. So the time of "when the implementation changes" might be "now" :) On Sun, Feb 28, 2021 at 2:11 AM Axel Wagner wrote: > Hi, > > not an expert, but. > > On Sat, Feb 27, 2021 at 11:19 PM Reto wrote: >

Re: [go-nuts] Contrary to popular opinion...

I liked Python too. But I never really understood why anyone though that dynamic typing was a good idea. Or why performance was so pathologically bad, or why they decided to make invisible characters semantically significant, or why python applications were so fiendishly complicated to deploy, or

Re: [go-nuts] Contrary to popular opinion...

Thanks, Amnon, for that well known quote from the Python world. Python has been one of my favorite languages for around 20 years. Even had the honor of meeting Guido while we were both working at Google a while back. Please, Python, do not integrate a dependency management system into your

Re: [go-nuts] Methods and pointer type receivers

On Sat, Feb 27, 2021 at 7:03 PM Deiter wrote: > >1. Why can’t receivers be a pointer type? > > They can be a pointer type. See, for example, https://tour.golang.org/methods/8. Also, as I write this the https://play.golang.org/p/rmnIexAGU-O you provided works. -- Kurtis Rader Caretaker of

Re: [go-nuts] Golang problem

Please provide your answer/code and we’ll look it over. > On Feb 27, 2021, at 5:47 AM, Vignesh Kumar wrote: > > Hello all, > > Thanks in advance, please help me to finish this assignment > > You are given a string S consisting of letters 'a' and 'b'. You want to split > it into three

Re: [go-nuts] Contrary to popular opinion...

On Sat, Feb 27, 2021 at 10:37 PM Bob Alexander wrote: > Try removing all the space from your post and see how understandable it is, > or remove all indentation from a Go program, etc. (Hmm, that would make > formatters a lot easier to write... ) Removing all spaces makes most languages

[go-nuts] Methods and pointer type receivers

Go: go1.15.8 darwin/amd64 OS: MacOS 11.2.1 The program here includes a type and a method that acts on that type: type Prefix struct { prefix string } func (rec *Prefix) outputString(s string) { fmt.Printf("%v: %v\n", rec.prefix, s) } Very

[go-nuts] Resolving type ambiguity w/ functions that return an interface

Go: go1.15.8 darwin/amd64 OS: MacOS 11.2.1 It makes sense to me that a function can have arguments that are interfaces - so long as the argument provides the methods that the function requires, it will be happy. However, I’m having a difficult time understanding functions that return an

[go-nuts] Using ellipses in a variadic function call

Go: go1.15.8 darwin/amd64 OS: MacOS 11.2.1 The program here includes a function with variadic arguments: func outputStrings(strings …string) Individual strings can be passed specifically: outputStrings("foo", "bar") You can also use an ellipses

Re: [go-nuts] Golang Problems

This mailing list is not your free resource for doing homework on your behalf. For $10_000 USD I will provide a solution. Otherwise, please go away and ponder if employment as a ditch digger isn't better suited to your skills. On Sat, Feb 27, 2021 at 7:02 PM Vignesh Kumar wrote: > Hello all, >

Re: [go-nuts] Using ellipses in a variadic function call

On Sat, Feb 27, 2021 at 7:03 PM Deiter wrote: > > Go: go1.15.8 darwin/amd64 > OS: MacOS 11.2.1 > > The program here includes a function with variadic arguments: > func outputStrings(strings …string) > > Individual strings can be passed specifically: > outputStrings("foo", "bar") > > You

Re: [go-nuts] Golang Problems

On Saturday, February 27, 2021 at 10:07:50 PM UTC-5 Kurtis Rader wrote: > This mailing list is not your free resource for doing homework on your > behalf. For $10_000 USD I will provide a solution. Otherwise, please go > away and ponder if employment as a ditch digger isn't better suited to

Re: [go-nuts] Methods and pointer type receivers

On Sat, Feb 27, 2021 at 7:03 PM Deiter wrote: > > Go: go1.15.8 darwin/amd64 > OS: MacOS 11.2.1 > > The program here includes a type and a method that acts on that type: > > type Prefix struct { > prefix string > } > > func (rec *Prefix) outputString(s string) { > fmt.Printf("%v: %v\n",

Re: [go-nuts] Golang Problems

We're not going to do your homework for you, but some things to consider: - maps are good at associating values with names - there's a strings.ToLower() function you will find useful - sort.Ints sorts ints in

Re: [go-nuts] Golang Problems

On Sun, Feb 28, 2021 at 6:32 AM Marcin Romaszewicz wrote: > - if s is a string, s[0] is a rune If s is a non-empty string, s[0] is a byte. > - if r is a rune, string(r) is a 1 character string If r is a rune, string(r) is a string of 1 or more bytes. -- You received this message because you

Re: [go-nuts] golang.org/x/sys and unsafe usage

On Sat, Feb 27, 2021 at 5:12 PM 'Axel Wagner' via golang-nuts wrote: > > On Sat, Feb 27, 2021 at 11:19 PM Reto wrote: >> >> Now, as far as I can tell this forces non stdlib packages to adhere to >> exactly that. >> As far as I can tell x/sys is just a common namespace for the go authors, but >>

[go-nuts] Golang problem

Hello all, Thanks in advance, please help me to finish this assignment You are given a string S consisting of letters 'a' and 'b'. You want to split it into three separate non-empty parts. The lengths of the parts can differ from one another. In how many ways can you split S into three parts,

[go-nuts] Golang Problems

Hello all, Thanks in advance. Please help me to finish this assignments. Write a program which will accept a string. This program should output all the characters and number of their occurrences, in order of their occurrences. So that, character appearing most number of times should be

[go-nuts] Help ASCII armor PGP Messages with golang.org/x/crypto/openpgp

https://play.golang.org/p/HpXdDlKcOPt This is an example what I want to do is return a encrypted message from Alice that can only be read by decrypted with Rogers key to reveal a sensitive message. -- You received this message because you are subscribed to the Google Groups "golang-nuts"

Re: [go-nuts] Resolving type ambiguity w/ functions that return an interface

On Sat, Feb 27, 2021 at 7:03 PM Deiter wrote: > > Go: go1.15.8 darwin/amd64 > OS: MacOS 11.2.1 > > It makes sense to me that a function can have arguments that are interfaces - > so long as the argument provides the methods that the function requires, it > will be happy. However, I’m having a

[go-nuts] Are the two unsafe uses safe?

1. func String2ByteSlice(s string) []byte { return (*[^uint(0) >> 1]byte)(unsafe.Pointer())[:len(s):len(s)] } 2. func String2ByteSlice(s string) []byte { return *(*[]byte)(unsafe.Pointer({string; int}{s, len(s)})) } -- You received this message because you are subscribed to the Google