[go-nuts] Re: Artistic Library for Go Programmers.

[lgodio2]

If you`re into C++ try Cimg (  https://cimg.eu/ )It's an excellent way 
to create your own images, fractals, artwork etc. but it does have a 
learning curve  ..
I also found Lode PNG quite usefu l https://lodev.org/lodepng/  but it 
requires a lot more  additional code than Cimg

On Sunday, August 16, 2020 at 3:50:15 PM UTC-4, mazzn...@gmail.com wrote:
>
> Color scales in Go 
> https://github.com/mazznoer/colorgrad 
>

-- 
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/2cb0f00f-0727-49ec-ab87-738ed8c010c3o%40googlegroups.com.

[go-nuts] Re: Why we don't have simple throws error statement

[lgodio2]

Has anyone ever tallied the number of different forum threads related to 
changing Go error handling ?  
The current method is obviously a vexing issue to many Go users, and
It seems silly that this issue has never been resolved by the Go team 
beyond maintaining the status quo... despite, IMHO, several good 
alternatives that have been suggested on this very forum.


On Friday, July 31, 2020 at 10:06:33 AM UTC-4, semi...@gmail.com wrote:
>
> Hey Community,
>
> I know, there are so many discussion about error handling. I read tons of 
> idea about that. Looks like most of idea rejected from community but every 
> idea brings our goal closer.
>
> May be we need simple solution. I like Go's simplest ways always. I don't 
> think so we need complex solution about that. Could we handle complexity 
> the error checking with simple throws statement?
>
>
> func myFileRDWRFunc(filename string) (string, error) {
>f, err := os.OpenFile(filename, os.O_RDWR, 0600)
>if err != nil { // backward compatibility
>return "", err
>}
>
> throws func(err error) { // catch all errors
>log.Println(err)
>f.Close()
>
> return "", err
>}()
>
> f.WriteString("anystring")
>f.Seek(0, 0)
> b := ioutil.ReadAll(f)
>
> return string(b), nil
> }
>
> Cheers.
>
> Semih.
>
>

-- 
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/e59eae6e-21c2-4f61-a222-48f6a43dbd74o%40googlegroups.com.

Re: [go-nuts] [generics] replace ()/(type ) with :[]

[lgodio2]

"  These are parameters, and should be thought of just like other 
parameters in a function call. .."

parameters yes,  but not in the current go context of 'parameter'   .. Is 
it not better syntax for  'generic parameters' to use special, distinctive 
symbols e.g.  C++ does via < Type > ?? 

On Thursday, June 18, 2020 at 12:31:04 PM UTC-4, Thomas Bushnell, BSG wrote:
>
> On Thu, Jun 18, 2020 at 9:46 AM Kiswono Prayogo  > wrote:
>
>> Personally () parentheses seems like to be harder to read, too similar 
>> with function calls.
>>
> This is exactly why I like it. These are parameters, and should be thought 
> of just like other parameters in a function call. 
>

-- 
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/03188960-2939-477e-a5ec-66c11f2fa9beo%40googlegroups.com.

Re: [go-nuts] x, err = some_func(); if err != nil { } seems awkward

[lgodio2]

"  It does seem that a lot of key decisions are being made on the basis of 
a very small sample of emoji votes in the issue tracker, so having a 
broader voting mechanism might be useful for informing the decision making 
process.. .."

At the very least, 'a broad voting mechanism'  would eliminate tons of 
repetitive posts regarding issues like ' if err != nil {..} '  and help Go 
developers focus of issues of major importance to Go users   

On Sunday, June 14, 2020 at 9:50:27 PM UTC-4, Randall O'Reilly wrote:
>
> I noticed a kind of circularity in the arguments around this issue.  The 
> simple "inline the if block" issue was created and rejected earlier: 
> https://github.com/golang/go/issues/27135 -- in part because the central 
> issue of error handling logic was supposed to be resolved by some other 
> upcoming proposals.  The newer issue: https://golang.org/issue/38151 has 
> some additional elements that potentially detract from the basic gofmt-only 
> version, and it has also been closed.  There is also this closely related 
> proposal which has not yet been rejected: 
> https://github.com/golang/go/issues/37141 
>
> Overall there is certainly a consistent message from a substantial number 
> of people that just compressing that high-frequency `if err != nil` logic 
> down to 1 line *somehow* would solve most of the problem!  But then there 
> are those who argue in favor of the status quo. 
>
> Because consistency in formatting is an essential part of Go, it seems 
> that this is fundamentally an "aesthetic" decision that must either be made 
> by the core designers, or, perhaps, finding some way of performing a 
> large-scale democratic voting process that would reasonably enable a large 
> portion of the Go community to weigh in.  It does seem that a lot of key 
> decisions are being made on the basis of a very small sample of emoji votes 
> in the issue tracker, so having a broader voting mechanism might be useful 
> for informing the decision making process..  Anyone know how to write a 
> good vote-collecting webserver in Go? :) 
>
> - Randy 
>
> > On Jun 14, 2020, at 12:39 PM, Tom Limoncelli  > wrote: 
> > 
> > Great minds think alike! 
> > 
> > On Sun, Jun 14, 2020 at 12:56 PM Ian Lance Taylor  > wrote: 
> >> 
> >> On Sun, Jun 14, 2020 at 8:25 AM Tom Limoncelli  > wrote: 
> >>> 
> >>> On Thu, Jun 4, 2020 at 3:34 PM Ian Lance Taylor  > wrote: 
>  
>  On Thu, Jun 4, 2020 at 8:43 AM > 
> wrote: 
> > 
> > ?? Why not a cleaner syntax e.g.  x = some_func ()  #{ }   .. symbol 
> # arbitrarily chosen 
>  
>  Besides what other people have said, it may be of interest to glance 
>  through 
> https://github.com/golang/go/issues?q=is%3Aissue+label%3Aerror-handling 
> >>> 
> >>> I assert that 80% of the annoyance that people feel is the number of 
> >>> lines required to handle errors, not the syntax.  Thus, a large 
> >>> segment of the community would stop caring about this if we modified 
> >>> gofmt, not the go language.  Specifically, gofmt would simply format 
> >>> short if's on one lie when possible. 
> >>> 
> >>> OLD: 
> >>> 
> >>> a, err := ioutil.ReadFile(patha) 
> >>> if err != nil { 
> >>>  return err 
> >>> } 
> >>> b, err := ioutil.ReadFile(pathb) 
> >>> if err != nil { 
> >>>  return err 
> >>> } 
> >>> c, err := ioutil.ReadFile(pathc) 
> >>> if err != nil { 
> >>>  return fmt.Errorf("wrapped %v: %w", pathc, err) 
> >>> } 
> >>> 
> >>> NEW: 
> >>> 
> >>>  a, err := ioutil.ReadFile(patha) 
> >>>  if err != nil { return err } 
> >>>  b, err := ioutil.ReadFile(pathb) 
> >>>  if err != nil { return err } 
> >>>  c, err := ioutil.ReadFile(pathc) 
> >>>  if err != nil { return fmt.Errorf("wrapped %v: %w", pathc, err) } 
> >>> 
> >>> This is half as many lines, thus makes it easier to fit on one 
> >>> screenful of an editor, which is often a cognitive limit for a 
> >>> developer. 
> >>> 
> >>> I'm not saying that this solves the problem, but I bet it would reduce 
> >>> the pressure to fix it. 
> >> 
> >> 
> >> 
> >> https://golang.org/issue/38151 
> >> 
> >> Ian 
> > 
> > 
> > 
> > -- 
> > Email: t...@whatexit.org Work: 
> tlimonce...@stackoverflow.com 
> > Blog:  http://EverythingSysadmin.com/ 
> > 
> > -- 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAHVFxgmaFQoRaZd65FLbzZUWD4bKFqaWcqXQ3H7vm%3DNimi6B2g%40mail.gmail.com.
>  
>
>
>

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

Re: [go-nuts] x, err = some_func(); if err != nil { } seems awkward

[lgodio2]

https://golang.org/issue/38151   great news !... lets hope something 
finally gets resolved
FWIW, I modify my original proposal: replacing   #{.. .}  with   err {...}  
 

On Sunday, June 14, 2020 at 12:57:01 PM UTC-4, Ian Lance Taylor wrote:
>
> On Sun, Jun 14, 2020 at 8:25 AM Tom Limoncelli  > wrote: 
> > 
> > On Thu, Jun 4, 2020 at 3:34 PM Ian Lance Taylor  > wrote: 
> > > 
> > > On Thu, Jun 4, 2020 at 8:43 AM > 
> wrote: 
> > > > 
> > > > ?? Why not a cleaner syntax e.g.  x = some_func ()  #{ }   .. symbol 
> # arbitrarily chosen 
> > > 
> > > Besides what other people have said, it may be of interest to glance 
> > > through 
> https://github.com/golang/go/issues?q=is%3Aissue+label%3Aerror-handling 
> > 
> > I assert that 80% of the annoyance that people feel is the number of 
> > lines required to handle errors, not the syntax.  Thus, a large 
> > segment of the community would stop caring about this if we modified 
> > gofmt, not the go language.  Specifically, gofmt would simply format 
> > short if's on one lie when possible. 
> > 
> > OLD: 
> > 
> > a, err := ioutil.ReadFile(patha) 
> > if err != nil { 
> >   return err 
> > } 
> > b, err := ioutil.ReadFile(pathb) 
> > if err != nil { 
> >   return err 
> > } 
> > c, err := ioutil.ReadFile(pathc) 
> > if err != nil { 
> >   return fmt.Errorf("wrapped %v: %w", pathc, err) 
> > } 
> > 
> > NEW: 
> > 
> >   a, err := ioutil.ReadFile(patha) 
> >   if err != nil { return err } 
> >   b, err := ioutil.ReadFile(pathb) 
> >   if err != nil { return err } 
> >   c, err := ioutil.ReadFile(pathc) 
> >   if err != nil { return fmt.Errorf("wrapped %v: %w", pathc, err) } 
> > 
> > This is half as many lines, thus makes it easier to fit on one 
> > screenful of an editor, which is often a cognitive limit for a 
> > developer. 
> > 
> > I'm not saying that this solves the problem, but I bet it would reduce 
> > the pressure to fix it. 
>
>
>
> https://golang.org/issue/38151 
>
> Ian 
>

-- 
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/f5812941-1a70-4613-a87b-363c7aef9b0eo%40googlegroups.com.

Re: [go-nuts] x, err = some_func(); if err != nil { } seems awkward

[lgodio2]

Amen Tom..  hard to believe that those who determine what Go syntax is, and 
is not, have yet to alter this uniquely awkward feature of the Go 
language.  

On Sunday, June 14, 2020 at 11:26:08 AM UTC-4, Tom Limoncelli wrote:
>
> On Thu, Jun 4, 2020 at 3:34 PM Ian Lance Taylor  > wrote: 
> > 
> > On Thu, Jun 4, 2020 at 8:43 AM > wrote: 
> > > 
> > > ?? Why not a cleaner syntax e.g.  x = some_func ()  #{ }   .. symbol # 
> arbitrarily chosen 
> > 
> > Besides what other people have said, it may be of interest to glance 
> > through 
> https://github.com/golang/go/issues?q=is%3Aissue+label%3Aerror-handling 
>
> I assert that 80% of the annoyance that people feel is the number of 
> lines required to handle errors, not the syntax.  Thus, a large 
> segment of the community would stop caring about this if we modified 
> gofmt, not the go language.  Specifically, gofmt would simply format 
> short if's on one lie when possible. 
>
> OLD: 
>
> a, err := ioutil.ReadFile(patha) 
> if err != nil { 
>   return err 
> } 
> b, err := ioutil.ReadFile(pathb) 
> if err != nil { 
>   return err 
> } 
> c, err := ioutil.ReadFile(pathc) 
> if err != nil { 
>   return fmt.Errorf("wrapped %v: %w", pathc, err) 
> } 
>
> NEW: 
>
>   a, err := ioutil.ReadFile(patha) 
>   if err != nil { return err } 
>   b, err := ioutil.ReadFile(pathb) 
>   if err != nil { return err } 
>   c, err := ioutil.ReadFile(pathc) 
>   if err != nil { return fmt.Errorf("wrapped %v: %w", pathc, err) } 
>
> This is half as many lines, thus makes it easier to fit on one 
> screenful of an editor, which is often a cognitive limit for a 
> developer. 
>
> I'm not saying that this solves the problem, but I bet it would reduce 
> the pressure to fix it. 
>
> Tom 
>
> -- 
> Email: t...@whatexit.org Work: 
> tlimonce...@stackoverflow.com 
> Blog:  http://EverythingSysadmin.com/ 
>

-- 
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/f3ee217c-3df2-4a29-bb62-7ad7337598beo%40googlegroups.com.

[go-nuts] x, err = some_func(); if err != nil { } seems awkward

[lgodio2]

?? Why not a cleaner syntax e.g.  x = some_func ()  #{ }   .. symbol # 
arbitrarily chosen

-- 
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/ea305494-c6ec-46f9-962d-9add01edc8bd%40googlegroups.com.

[go-nuts] files stored in /home/$USER/.cache/go-build/

[lgodio2]

What does Go use these files used for ? I've got loads of them...What 
happens if I delete some or all ? 

-- 
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/01519400-93f9-4825-80ad-5dc619835fa8%40googlegroups.com.

Re: [go-nuts] Does os.exec work ?

[lgodio2]

Than you..
I surely need to beef-up my comprehension of what os.exec does vs what it 
does not.

On Wednesday, March 25, 2020 at 2:54:07 PM UTC-4, Kurtis Rader wrote:
>
> The exec.Command() function works fine. The problem lies in your 
> understanding of what happens when you use a shell to execute that command 
> versus what the Go function does. When you type that command at a shell 
> prompt it parses the statement and creates a pipe and runs "echo" on the 
> LHS and "xsel" on the RHS of the pipe. The exec.Command() function does 
> none of that work. It simply runs an external program named "echo" with the 
> two arguments you provided. In other words it is as if you typed the 
> following at a shell prompt:
>
> echo "echo 'ABC'" "|xsel --clipboard"
>
> Resulting in the expected output given the arguments you passed to that 
> function:
>
> echo 'ABC'  |xsel --clipboard
>
> One solution is to use exec.Command() to run
>
> sh -c "echo 'ABC' |xsel --clipboard"
>
> That, however, is difficult to do in the general case since getting the 
> quoting correct is a challenge.
>
>
> On Wed, Mar 25, 2020 at 11:30 AM > wrote:
>
>> This simple command works correctly when submitted via the terminal, but 
>> the same command submitted to os.exec does not !!
>> .. and I can`t understand why...
>>
>> import ( "fmt"; "os"; "os/exec";  )
>>
>> func main() {
>>
>> cb := "ABCD"
>>
>> cmd := exec.Command ("echo", "echo "+ "'" +string(cb [0:len(cb)-1] ) 
>> +"'", " |xsel --clipboard" )
>> cmd.Stdout = os.Stdout
>> cmd.Stderr = os.Stderr
>> err := cmd.Run() ;if err != nil { fmt.Printf("\ncmd.Run() error: %s 
>> \n", err) }
>>
>> }
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/f9b34d9d-985f-4cbf-9a92-d3d46d72cf55%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/348fcfba-b375-4ac7-9198-c48a5242d8f3%40googlegroups.com.

[go-nuts] Does os.exec work ?

[lgodio2]

This simple command works correctly when submitted via the terminal, but 
the same command submitted to os.exec does not !!
.. and I can`t understand why...

import ( "fmt"; "os"; "os/exec";  )

func main() {

cb := "ABCD"

cmd := exec.Command ("echo", "echo "+ "'" +string(cb [0:len(cb)-1] ) +"'", 
" |xsel --clipboard" )
cmd.Stdout = os.Stdout
cmd.Stderr = os.Stderr
err := cmd.Run() ;if err != nil { fmt.Printf("\ncmd.Run() error: %s 
\n", err) }

}

-- 
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/f9b34d9d-985f-4cbf-9a92-d3d46d72cf55%40googlegroups.com.

[go-nuts] Re: Proposal: Error handling with else catch (else keyword)

[lgodio2]

Great suggestion 
f := os.Open("filename.ext")
else err != nil {
log.Fatal(err)
}

is much needed syntax improvement vs the current syntax. 

I would further suggest f ?= os.os.Open("filename.ext") : log.fatal("Cant 
open filename.ext") 
But the GO 'custodians' get apoplexy whenever they see any syntax that 
resembles the C ternary operator.
Chill-out 'custodians' !! 
'?' is just a symbol that can be replaced by some another one 
On Saturday, February 15, 2020 at 6:06:39 PM UTC-5, teknoslo wrote:
>
> This is more of a request for comments and not a complete proposal. I will try
> to keep this short(ish) and simple.
>
> Note that the `else` I will write about is not to be confused with the usual
> `else` used with `if`. It is an `else` in a slightly different context.
>
> `else` is basically an `if` with a variable initialized to the last return 
> value
> of a function call from the previous line.
>
> Note: "from the previous line" is a simplification. Between the function call
> and the `else` statement white space and comments are allowed, but nothing
> else.
>
> Another note: "function call" is also a simplification. It can be any 
> statement
> that returns a value. It could be, for example, the "comma ok" idiom used for
> testing whether an entry in a map is present.
>
> A few simple rules:
>
>- Only the last return value is ever taken, not multiple.
>- If there is no return value, `else` is not possible.
>- The variable is defined only within the scope of the `else` block.
>- The name of the variable can be any valid identifier.
>- Braces are mandatory.
>
>
> Code like this:
>
> f, err := os.Open("filename.ext")
> if err != nil{
> log.Fatal(err)
> }
>
> would become:
>
> f := os.Open("filename.ext")
> else err != nil {
> log.Fatal(err)
> }
>
> The `err` variable in the example above is automatically initialized to the 
> last
> return value of the function call `os.Open`. The variable could have any valid
> variable name and is defined only in the `else` block.
>
> I like to read the example above with an implicit try before the function 
> call.
> I.e., try opening filename.ext, else if err is not nil... For this reason, I
> call this construct else catch.
>
> A longer example from Error Handling - Problem Overview 
> :
>
> func CopyFile(src, dst string) error {
> r, err := os.Open(src)
> if err != nil {
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
> defer r.Close()
>
> w, err := os.Create(dst)
> if err != nil {
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
>
> if _, err := io.Copy(w, r); err != nil {
> w.Close()
> os.Remove(dst)
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
>
> if err := w.Close(); err != nil {
> os.Remove(dst)
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
> }
>
> would become:
>
> func CopyFile(src, dst string) error {
> r := os.Open(src)
> else err != nil {
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
> defer r.Close()
>
> w := os.Create(dst)
> else err != nil {
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
>
> io.Copy(w, r)
> else err != nil {
> w.Close()
> os.Remove(dst)
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
>
> w.Close()
> else err != nil {
> os.Remove(dst)
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
> }
>
> By using the else catch we declutter the function calls, more specifically
> assignments, thus improving readability. Error handling stays familiar,
> explicit, and simple.
>
> And since the variable in else catch is defined only in the `else` block, we 
> do
> not need to re-assign the `err` variable again and again, making the code more
> obvious and unambiguous.
>
> I would like to note that the else catch example is longer, but I think length
> should not be equated with readability.
>
>
>
> Else catch is not meant to replace the `if err != nil` idiom, but rather
> complement it. It would allow for a clear separation of return values we 
> "care"
> about and error handling. Or put another way, it would allow for a clear
> separation of a happy and an unhappy path of execution.
>
>
>
> What about the error handling blocks?
>
> We should not try to stash away error handling. Most gophers are already used 
> to
> skipping error handling blocks while reading Go. Using else catch would make
> that even easier. IDEs could collapse else catch blocks on command.
>
>
>
> Else catch is orthogonal and can be used for anything, not just error 
> handling.
> We just have to remember that it always takes the last (and no more) return
> value of a function call from the previous line.
>
> For example, we can test for existence of a key:
>
> m := map[string]int{

Re: [go-nuts] liteide x36.2 released.

[lgodio2]

All the links in this post  are incorrect
 

On Saturday, November 2, 2019 at 10:32:48 AM UTC-4, visualfc wrote:
>
> Hi, all.
> LiteIDE X36.2 released!
> This version fix gocode crash bug. Add new image viewer plugins. Folder 
> view support multi copy, move to trash. Fix windows floating dock 
> widget style.
>
> * LiteIDE Home
>
> * LiteIDE Source code
>
> * Release downloads
>
>
>
> ### 2019.10.30 Ver X36.2
> * LiteIDE
> * add new image viewer plugin
> * folder view support multi copy & paste
> * folder view support move to trash
> * fix gocode crash
> * update uk (Ukrainian) translation, thanks for cl0ne
> * LiteApp
> * fix floating dock widet style
> * add dock widget floating toolbar
> * folder view support multi copy and paste
> * folder view support move to trash action
> * ImageEditor
> * add new image viewer plugin
> * support image viewer and gif video play
> * GolangEdit
> * support go1.13 number literal syntax highlight
> * gotools & gocode
> * fix bad parser crash
>
> --
> Sent from YoMail for Gmail  
>

-- 
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/fc5fe0cd-af4c-448a-ad54-c99b1e68f903%40googlegroups.com.

[go-nuts] Re: A question about performance when traverse the array with row-wise and column-wise

[lgodio2]

Are your test results different  when rowSize = colSize> 1000 say ??



On Sunday, September 29, 2019 at 10:18:15 AM UTC-4, zct wrote:
>
> The test code is below:
> package main
>
> import (
> "testing"
> )
>
> const rowSize = 100
> const colSize = 100
>
> var array [rowSize][colSize]int
>
> func BenchmarkRow(b *testing.B) {
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> sum := 0
> for r := 0; r < rowSize; r++ {
> for c := 0; c < colSize; c++ {
> sum += array[r][c]
> }
> }
> }
> }
>
> func BenchmarkColumn(b *testing.B) {
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> sum := 0
> for c := 0; c < colSize; c++ {
> for r := 0; r < rowSize; r++ {
> sum += array[r][c]
> }
> }
> }
> }
>
>
> As we known, there is a cpu cache in computer, so the row-wise should 
> perform better than the column-wise. But the test result is :
>
> go test -bench=. -count=5
> goos: darwin
> goarch: amd64
> BenchmarkRow-430  42926367 ns/op
> BenchmarkRow-430  50048505 ns/op
> BenchmarkRow-432  38466153 ns/op
> BenchmarkRow-428  40887279 ns/op
> BenchmarkRow-430  36325967 ns/op
> BenchmarkColumn-4 34  30991838 ns/op
> BenchmarkColumn-4 36  30965998 ns/op
> BenchmarkColumn-4 39  31575142 ns/op
> BenchmarkColumn-4 33  35048352 ns/op
> BenchmarkColumn-4 38  32584167 ns/op
> PASS
>
> It show that the column-wise traverse is quicker than the row-wise. I test 
> it in my macbook and ubuntu server, the result is the same
>
>

-- 
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/7424c9d6-51d0-4f59-81a4-b0635fc40530%40googlegroups.com.

[go-nuts] adding files to existing ZIP archieves

[lgodio2]

How do I use files in ...\src\archive\zip to add files to an existing 
archive file MyArchieve.zip ?? 

-- 
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/d01f1863-0a63-4bd2-9d8d-68bc0af5eda9%40googlegroups.com.

Re: [go-nuts] Re: Question re fcns that return multiple values

[lgodio2]

f( g() ) compiles  when g returns exactly the number of args that f() 
requires, but if g() returns only 1/2 that number  f (g(), g() ) wont 
compile !! ...Is this not a Golang absurdity  ?? 

On Tuesday, August 6, 2019 at 7:26:46 PM UTC-4, Ian Lance Taylor wrote:
>
> On Tue, Aug 6, 2019 at 4:14 PM > wrote: 
> > 
> > ?? Am I wrong in saying that the statements I've submitted conform to 
> "As a special case, if the return values..." 
>
> The special case applies to f(g()) only.  It does not apply to f(g1(), 
> g2()). 
>
> Ian 
>
>
> > On Monday, August 5, 2019 at 11:38:24 PM UTC-4, L Godioleskky wrote: 
> >> 
> >> For f1 defined as func f1(k1, k2, k3 int) (x1, x2 int) {..} 
> >> and f2 defined as func f2(x,y int)   (xR int)   {..} 
> >> 
> >> Why does the compiler complain about the call stmt 
> >> f2 ( f1 (1,2,3)  )   ?? 
> > 
> > -- 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/d8cd287f-2a18-4143-8579-c92fdd6a3fa6%40googlegroups.com.
>  
>
>

-- 
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/013d64ed-1048-4121-8930-bd25909ef96d%40googlegroups.com.

[go-nuts] Re: Question re fcns that return multiple values

[lgodio2]

?? Am I wrong in saying that the statements I've submitted conform to "As a 
special case, if the return values..."

On Monday, August 5, 2019 at 11:38:24 PM UTC-4, L Godioleskky wrote:
>
> For f1 defined as func f1(k1, k2, k3 int) (x1, x2 int) {..} 
> and f2 defined as func f2(x,y int)   (xR int)   {..} 
>
> Why does the compiler complain about the call stmt 
> f2 ( f1 (1,2,3)  )   ??
>

-- 
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/d8cd287f-2a18-4143-8579-c92fdd6a3fa6%40googlegroups.com.

[go-nuts] Re: Question re fcns that return multiple values

[lgodio2]

Here a specific example:

The following compiles and runs as expected
m1x,m1y := ec.scalarMult(16,28,33)  
m2x,m2y := ec.scalarMult( 1,28,33)
rx,ry := ec.add (m1x,m1y, m2x, m2y)


However this stmt :rx,ry= ec.add(ec.scalarMult(16,28,33), 
ec.scalarMult( 1,28,33))  gives the following compiler error ...

# command-line-arguments
.\ECurve.go:272:14: not enough arguments in call to ec.add
.\ECurve.go:272:28: multiple-value ec.scalarMult() in single-value context




On Monday, August 5, 2019 at 11:38:24 PM UTC-4, L Godioleskky wrote:
>
> For f1 defined as func f1(k1, k2, k3 int) (x1, x2 int) {..} 
> and f2 defined as func f2(x,y int)   (xR int)   {..} 
>
> Why does the compiler complain about the call stmt 
> f2 ( f1 (1,2,3)  )   ??
>

-- 
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/f1b715c9-c22f-41d4-8652-c3c49b0c1e7f%40googlegroups.com.

[go-nuts] Go Library lists

[lgodio2]

The web page at http://go-lang.cat-v.org/pure-go-libs

provides Go a valuable list of various Go packages organized by subject 
category. 
Unfortunately it stopped updating Oct'2012.

If anyone knows of a currently maintained equivalent , please respond 

-- 
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/e8b2758d-0304-4c8e-a4f5-48857eb5ec2e%40googlegroups.com.

[go-nuts] Question re fcns that return multiple values

[lgodio2]

For f1 defined as func f1(k1, k2, k3 int) (x1, x2 int) {..} 
and f2 defined as func f2(x,y int)   (xR int)   {..} 

Why does the compiler complain about the call stmt 
f2 ( f1 (1,2,3)  )   ??

-- 
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/a2400f69-29f6-4f9c-92ab-c9dd763cb311%40googlegroups.com.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[lgodio2]

Michael,
Considering all  improvements you've made to the original, is the current 
version of your proposal clear to all following this thread ?

On Wednesday, June 5, 2019 at 6:03:12 PM UTC-4, Michal Strba wrote:
>
> Ian, have you had the time to evaluate the improvements to my proposal 
> (the original one in this thread)? I'd love to hear if it has some more 
> significat shortcomings and know what to think about. Or, if it has no 
> perspective, I'd love to hear why.
>
> I know you're busy, so responding with "I haven't had the time yet" is 
> completely understandable.
>
> Thanks
>
> On Wed, Jun 5, 2019, 22:18 Robert Engels  > wrote:
>
>>
>>
>>
>>
>>
>>
>> -Original Message-
>> >From: Randall O'Reilly >
>> >Sent: Jun 5, 2019 2:33 PM
>> >To: Robert Engels >
>> >Cc: Ian Lance Taylor >, Michal Strba <
>> faifa...@gmail.com >, golang-nuts > >
>> >Subject: Re: [go-nuts] Go 2 generics counterproposal: giving up 
>> restricting types
>> >
>> >That is a good point of clarification about the specific limitation of 
>> this proposal: it specifically reifies the existing Go type system and does 
>> NOT enable the generic-ification of arbitrary novel types.  If you can 
>> build a specialized type out of generic versions of existing Go types, then 
>> you’re good, but if you need something entirely different, then this won’t 
>> do it.  The key question is whether having a really simple and tractable 
>> “native types” version of generics solves enough problems, while avoiding 
>> the challenges of going “fully generic”, to hit that “Go” minimalism sweet 
>> spot.. 
>> >
>> >- Randy
>> >
>> >> On Jun 5, 2019, at 1:17 PM, Robert Engels > > wrote:
>> >> 
>> >> That is not sufficient. You can't require the usage of the built-in 
>> map, as specialized maps may have a completely different structure (special 
>> hash tables when the keys are ints, or more commonly special CAS techniques 
>> for highly concurrent lock-free maps).
>> >
>> >-- 
>> >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 golan...@googlegroups.com .
>> >To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/735428D9-5630-4F56-88AD-0F8E9E8CC473%40gmail.com
>> .
>> >For more options, visit https://groups.google.com/d/optout.
>>
>> Even more common data structures like linked maps, tree maps/sets 
>> wouldn't be possible. I think custom data structures are the prime usage 
>> for generics - which is why I suggested that rather than doing generics, 
>> you could do something like this:
>>
>> map:=make(map[String]String,"ordered,concurrent")
>>
>> which would use different implementations as decided by the Go platform 
>> (with maybe some way of registering additional ones via C, etc.)
>>
>> It keeps the simplicity of Go, using the existing syntax, but allows 
>> custom data structures (although not written in Go - maybe?)
>>
>> I think data structures are 95% of the use case of generics, but that is 
>> just my opinion (although earlier Java based studies I referred to seemed 
>> to support the claim).
>>
>

-- 
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/435b5a90-05ea-4d71-bfc7-47ec3824d5d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[lgodio2]

Sorry again for the power failure...let me try one last time

one of the annoying things you have to deal with as a team member is being 
assigned an "update" of code written by someone who no longer works for the 
team.
What makes this annoying is possibility of running into code sections that 
contain "crytic" statements that require lots of effort to understand.
 After looking at the link you provided, based on my history dealing with 
unnecessary and avoidable 'cryptic C++,
 my input  is:  Generics are a great idea EXCEPT when they allow use of 
cryptic syntax

On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, Michal Strba wrote:
>
> Hi Gophers! :)
>
> I've been thinking about generics in Go 2 ever since the original 
> contracts proposal and few days ago, ideas finally clicked. One of the main 
> things about this proposal is that it deliberately omits the ability to 
> restrict the set of types a function can work with. This is a limitation, 
> but I hope to convince you that we can still do a vast majority of the 
> things we were missing, when we were missing generics. 
>
> I'd love to share my proposal with you and engage in a good faith 
> conversation.
>
> Link to the proposal. 
> 
>
> Here's what the proposal covers:
>
> 1. Syntax of a new gen keyword.
> 2. Generic functions.
> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in 
> new function).
> 4. Semantics of generic values (ability to use them as map keys, ...).
> 5. Generic array lengths.
> 6. Reflection and interface{}.
> 7. Generic types (with two examples: List and Matrix).
> 8. Generic methods and their limitations due to reflection.
> 9. Generic interfaces.
> 10. List of things this proposal can't do.
>
> Thanks,
> faiface
>

-- 
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/4e266f34-32d8-4b3d-8f45-55da5651ed9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[lgodio2]

llow

On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, Michal Strba wrote:
>
> Hi Gophers! :)
>
> I've been thinking about generics in Go 2 ever since the original 
> contracts proposal and few days ago, ideas finally clicked. One of the main 
> things about this proposal is that it deliberately omits the ability to 
> restrict the set of types a function can work with. This is a limitation, 
> but I hope to convince you that we can still do a vast majority of the 
> things we were missing, when we were missing generics. 
>
> I'd love to share my proposal with you and engage in a good faith 
> conversation.
>
> Link to the proposal. 
> 
>
> Here's what the proposal covers:
>
> 1. Syntax of a new gen keyword.
> 2. Generic functions.
> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in 
> new function).
> 4. Semantics of generic values (ability to use them as map keys, ...).
> 5. Generic array lengths.
> 6. Reflection and interface{}.
> 7. Generic types (with two examples: List and Matrix).
> 8. Generic methods and their limitations due to reflection.
> 9. Generic interfaces.
> 10. List of things this proposal can't do.
>
> Thanks,
> faiface
>

-- 
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/5f5ec80f-ce98-4420-9837-d0800852ced1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[lgodio2]

On Thursday, May 30, 2019 at 1:24:55 PM UTC-4, L Godioleskky wrote:
>
> one of the annoying things you have to deal with as a team member is being 
> assigned an "update" of code written by someone who no longer works for the 
> team. What makes this annoying is possibility of running into code sections 
> that contain "crytic" statements that require lots of effort to understand. 
> After looking at the link you provided my input, based on dealing with 
> cryptic C++  is: Go should not allow cryptic syntax.
>
Generics are useful except when their syntax becomes cryptic 
 

>   w
>
> On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, Michal Strba wrote:
>>
>> Hi Gophers! :)
>>
>> I've been thinking about generics in Go 2 ever since the original 
>> contracts proposal and few days ago, ideas finally clicked. One of the main 
>> things about this proposal is that it deliberately omits the ability to 
>> restrict the set of types a function can work with. This is a limitation, 
>> but I hope to convince you that we can still do a vast majority of the 
>> things we were missing, when we were missing generics. 
>>
>> I'd love to share my proposal with you and engage in a good faith 
>> conversation.
>>
>> Link to the proposal. 
>> 
>>
>> Here's what the proposal covers:
>>
>> 1. Syntax of a new gen keyword.
>> 2. Generic functions.
>> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in 
>> new function).
>> 4. Semantics of generic values (ability to use them as map keys, ...).
>> 5. Generic array lengths.
>> 6. Reflection and interface{}.
>> 7. Generic types (with two examples: List and Matrix).
>> 8. Generic methods and their limitations due to reflection.
>> 9. Generic interfaces.
>> 10. List of things this proposal can't do.
>>
>> Thanks,
>> faiface
>>
>

-- 
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/168e423b-eb56-4c2c-8222-567756146dbc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

[lgodio2]

one of the annoying things you have to deal with as a team member is being 
assigned an "update" of code written by someone who no longer works for the 
team. What makes this annoying is possibility of running into code sections 
that contains "crytic" statements that require lots of effort to 
understand. After looking at the link you provided my input, based on 
dealing with cryptic C++  is:
  w

On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, Michal Strba wrote:
>
> Hi Gophers! :)
>
> I've been thinking about generics in Go 2 ever since the original 
> contracts proposal and few days ago, ideas finally clicked. One of the main 
> things about this proposal is that it deliberately omits the ability to 
> restrict the set of types a function can work with. This is a limitation, 
> but I hope to convince you that we can still do a vast majority of the 
> things we were missing, when we were missing generics. 
>
> I'd love to share my proposal with you and engage in a good faith 
> conversation.
>
> Link to the proposal. 
> 
>
> Here's what the proposal covers:
>
> 1. Syntax of a new gen keyword.
> 2. Generic functions.
> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in 
> new function).
> 4. Semantics of generic values (ability to use them as map keys, ...).
> 5. Generic array lengths.
> 6. Reflection and interface{}.
> 7. Generic types (with two examples: List and Matrix).
> 8. Generic methods and their limitations due to reflection.
> 9. Generic interfaces.
> 10. List of things this proposal can't do.
>
> Thanks,
> faiface
>

-- 
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/6ef558bc-f66d-409e-bb78-7e40360e7a55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Interesting public commentary on Go...

[lgodio2]

My thanks to all ... This thread has provided me a wealth of interesting 
and varied ideas regarding Go user community viewpoints on Go governance.

For what its worth here's my 'two cents' worth ...

In the end, every Go user has only one 'Go' he/she can choose to 
useRegardless of how, why and who etc. determines future directions of 
the language, the only real alternative a user has is to accept Go 'as is' 
or move on to something else ..If you choose to stay with Go, you have to 
accept it for what it is , not what you'd like it to be.

If you decide to stay with Go, this doesn't mean you have to stop 
advocating /supporting  changes to the language and/or changes to how the 
language is governed. 
As an aside, I'm one of the 'golang-nuts' who support adding a modernized 
version of the C ternary operator to Go, but many of my other golang-nuts 
think I'm 'nuts'  I also vote 'no' regarding generics.

If a Go user decides to move on to something else,  you'll still end up 
with governance issues ..
At one extreme you can move on to Python  which is governed by the  BDFL 
Guido van Rossum philosophy. 
Did van R do great things for Python ?  ...Let me answer this by saying  
that with I never got past the nightmare I experienced trying to install 
PIP, NumPy and SciPy packages on my Windows box.

At the other extreme you can move on to to something like C++ with a system 
of governance that can only be described as "Wild West"

For me the Governance issue is very much secondary to my more major issue 
which is the availability of packages I need to support the apps I want to 
develop.

For me, this is where Go ranks way above the other languages I've tried 
over my many years as a developer.
When I first moved over to Go the first package I wanted to get up and 
running was the Go "image" package.
It took me less that an hour to port one of my major C++ libPNG based image 
processing apps over to Go. 
This was enough to make me a Go believer considering the many months I 
wasted developing PNG image processing apps  using C++ and libPNG.

I could go on and on regarding similar experiences I've had with other Go 
packages, but my point is that, for me, 
Go's system of package management and its spectrum of available Go packages 
is what makes Go superior to other languages.

I'm am old timer with lots of C++ apps that I developed over the years 
before I switched over to Go.
I've ported many of these apps to Go, except for those that require too 
much time for me to convert, or those that require packages that are not 
available in Go.  So for now I have to live with both Go and C++.

Go governance is important but,  for me it is much less important than 
package availability and the ability to get packages up and running quickly.

So my my major issue is involves adding more packages to Go,  especially 
math-sci-engineering oriented packages so I can avoid having to switch over 
to Julia (or worse yet FORTRAN) when I need to develop these kind of apps.  
 
Yea, I've tried packages available on https://godoc.org/gonum.org/v1/gonum  
but I find many of these Go packages are primitive compared to those 
available in C++ (and in some cases even FORTAN)

Any way, that's my "two pennies" worth


On Thursday, May 23, 2019 at 9:18:25 AM UTC-4, L Godioleskky wrote:
>
> https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage
>

-- 
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/71cdb184-5d19-4ec7-bac8-c5131f3361f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Interesting public commentary on Go...

[lgodio2]

Ian: I find many of your comments related to how the Go team functions very 
interesting,
I for one would find it helpful if 2 or 3 times a year the Go Team would 
communicate to the Go community at large, information related  to where and 
in what direction(s) it is taking Go, and what directions the team has 
decided NOT to take Go . 

I think the idea of a relatively small team of people deciding what Go will 
/ will not morf into, is a sound one considering the what goes on within 
the C++ world,  

I also think it important that the Go team utilize some mechanism for 
screening input from the Go user community regarding changes / enhancements 
to the language, new packages etc.

An important measure of Go's value as a useful language is measured by the 
size of Go user community, which in my opinion is very much related what Go 
offers developers to make their life easier vs other languages.  


On Thursday, May 23, 2019 at 1:59:57 PM UTC-4, Ian Lance Taylor wrote:
>
> On Thu, May 23, 2019 at 9:18 AM > wrote: 
> > 
> > https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage 
>
> Thanks for the link.  There is clearly a real sense in which Go is 
> Google's language.  But I think I would like to emphasize some points 
> that don't necessarily contradict the blog post but may add some 
> nuance. 
>
> I'm a member of the Go team and I'm employed by Google.  I'm speaking 
> exclusively for myself here, not for Google nor for the Go team. 
>
> I've worked on free software for my entire career, before I joined 
> Google and indeed before Google existed.  I think it's fair to say 
> that Go is an open source language.  All the source code, including 
> the source code for all the infrastructure support, is freely 
> available and may be reused and changed by anyone.  For software the 
> most fundamental freedom is freedom to fork: freedom to take an 
> existing project in a new direction.  People have that freedom with 
> the Go language.  They don't necessarily have the freedom to call that 
> forked language "Go" (I'm not sure), but I think that limitation is 
> OK; it serves nobody to call different projects by the same name. 
>
> The blog post starts by quoting @kapoorsunny asking why there can't be 
> something like OpenGo, with a community implementation of generics.  I 
> hope that it is clear that the answer is that there could be.  Nothing 
> prevents that from happening.  In particular, Google doesn't prevent 
> that from happening. 
>
> So when someone says that Go is Google's language, they must mean 
> something else. 
>
> For any free software project, there is a set of people who can commit 
> changes to the project.  For the Go project, that is the set of people 
> who are on the approvers list, who can click the +2 button in Gerrit. 
> I don't think this list is publicly visible for anybody is not an 
> approver, but I just took a look.  Since some people who work at 
> Google use their personal e-mail addresses I could have made a 
> mistake, but I count 59 Googlers on the committers list and 51 
> non-Googlers. 
>
> So while Google is the majority, it's not an overwhelming one.  Again, 
> this can't be what it means to say that Go is Google's language. 
>
> A programming language is a type of shared software infrastructure. 
> It's most useful when everybody is using the same language, so code 
> written by person A can be reused by person B.  That means that 
> programming languages are most useful when we all agree on exactly 
> what the language is.  All successful languages have either a single 
> specification or a single primary implementation.  (Go and C++ are 
> examples of language based on a specification; Perl, at least before 
> Perl 6, is an example of a language based on an implementation). 
> These serve as the definition of what the language is: whatever the 
> specification says or whatever the implementation does. 
>
> I think most people would agree to all of the above.  Now some 
> opinion, where people may disagree. 
>
> If a language is to change over time, this specification or 
> implementation must change.  Somebody has to decide how changes will 
> be made.  All successful languages have a small set of people who make 
> the final decisions.  Many people will provide input to this decision, 
> but no successful language--indeed, no successful free software 
> project of any sort--is a democracy.  Successful languages pay 
> attention to what people want, but to change the language according to 
> what most people want is, I believe, a recipe for chaos and 
> incoherence.  I believe that every successful language must have a 
> coherent vision that is shared by a relatively small group of people. 
>
> As I said, that is my opinion, but I think it's true.  I would be 
> interested to hear of a counter-example. 
>
> Since Go is a successful language, and hopes to remain successful, it 
> too must be open to community input but must have a small 

[go-nuts] Interesting public commentary on Go...

[lgodio2]

https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage

-- 
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/ac6843c0-38fc-4388-a1dd-2dd2b78c0ac3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go if else syntax .. suggested replacement

[lgodio2]

Dave: Thanks for pursuing this issue and reporting back. 

Given the extent of responses to the original question by the Go community 
(pro and con), hopefully those responsible for Go syntax will re-visit the 
issue and decide whether Go statement "if test then {.. } else { .. }"  
prevents any possible abuse or confusion  that would occur if it were 
replaced with   ?test { ..} : { .. }

On Sunday, May 12, 2019 at 11:35:51 AM UTC-4, David Riley wrote:
>
> On May 12, 2019, at 06:55, Jesper Louis Andersen  > wrote:
>
> I don't think there are developers who find it unreadable once they know 
> the logic of that operator. However, if you don't know the rules, then it 
> looks like black magic.
>
> In large software developments, consistency beats convenience almost all 
> the time. You can somewhat easily add another developer, if the notation 
> rules are consistent. Whereas clever notational convenience costs for every 
> developer you add to the project. Giving people a choice means you have yet 
> another section in your style guide to understand and maintain.
>
> The deeper observation is that in a language with two syntactic classes, 
> statements and expressions, you can opt to have an if-like evaluation in 
> the expression class, or you can omit it. Go does the latter, where C does 
> the former. Of course, you can also define your language with a single 
> syntactic class. In that case, the above example can be written
>
> let color = if temperature > 80 then "red" else "green" in ...
>
> This style is used in a large selection of languages, which people often 
> call "functional languages". Though the lines of when something fits into 
> the moniker is somewhat blurry.
>
>
> As it happens, I did get to ask Ken Thompson about his reasoning when he 
> presented at VCF East last weekend.
>
> Ken said, as close to verbatim as my week-old memory gets, that they were 
> “too hard to compile right without the possibility of introducing subtle 
> bugs”. I didn’t press further, because there were plenty of people in line 
> to talk to him and I didn’t want to be rude; my assumption is that he was 
> talking about either order of expression execution, or the difficulty of 
> lumping the subexpressions together. He definitely didn’t have anything to 
> say about their potential for abuse or about them being confusing to new 
> programmers, but then we also didn’t talk long.
>
> Just adding that since I said I’d ask about it a few weeks ago.
>
> BTW, the video of his keynote chat with Brian Kernighan is not to be 
> missed; I was working the audio, so sorry about Brian’s levels, but he was 
> feeding back so I couldn’t turn him up any louder: 
> https://m.youtube.com/watch?v=EY6q5dv_B-o
>
>
> - 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 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/86a25187-3a9c-4e28-adf6-eafeb7651bbd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: How to run a go method on multiple cores ?

[lgodio2]

Can anyone recommend a good on-line doc for goroutines ? The best one I've 
found so far uses a very SLOW approach to present essential info
https://gobyexample.com/goroutines
 

On Monday, May 6, 2019 at 7:11:00 AM UTC-4, Nitish Saboo wrote:
>
> Hi,
>
> I want a go method to run on multiple cores.The go method is returning an 
> object. Can we achieve this using goroutine ?
> How can I achieve this ?
>
> 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/52ca0b92-e335-4681-adbd-886cb69daede%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: How to run a go method on multiple cores ?

[lgodio2]

If   func f (n int) []int { is some fcn that requires CPU time 
T (large) to calculate its return value  

And I write :
func main() {
var s [ ] int; 
s1  := f(1)  ;  s1  := f(2) 
...
}

I get  results after CPU time  2 T
?? To obtain results in < 2T time,  can I write  s1  :=  go f(1)  ;  s1  := 
go f(2)

On Monday, May 6, 2019 at 7:11:00 AM UTC-4, Nitish Saboo wrote:
>
> Hi,
>
> I want a go method to run on multiple cores.The go method is returning an 
> object. Can we achieve this using goroutine ?
> How can I achieve this ?
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: the Dominance of English in Programming Languages

[lgodio2]

this issue involves much more than Go code For example , we for whom 
English is not our native language use 'Google translate' to translate our 
golang-nuts questions into English and the golang-nuts responses back to 
our native language.  The second translation often produces produces 
very-strange (and often laughable) native language translations. So I think 
it is safe to conclude the first translation produces similar things in 
English because many of the golang-nuts responses indicate  gross 
misunderstanding of original question.

Some golang-nuts members are native Americans who have very little 
tolerance for non-American English  

On Saturday, May 4, 2019 at 6:15:00 PM UTC-4, Chris Burkert wrote:
>
> Some background why I was asking this: I have a history with 
> Squeak/Smalltalk and how Alan Kay worked with children. At work I also 
> teach 14/15 year old pupils during their 2 weeks internship and that is 
> simply too short to show them something about programming especially when 
> this is just one topic out of many. We usually convert numbers between 
> decimal, octal, binary and hexadecimal on the whiteboard. And because they 
> just knew 0-9 so far it becomes a sudden insight to some of them. These few 
> kids usually want to learn more (convert numbers programmatically) but 
> because they are intrinsically motivated the English language is not a 
> hurdle for them. That’s why I was wondering about the article.
>
> Thanks for all your comments. Reading the different perspectives about the 
> topic fascinates me a lot.
>
> Chris Burkert > schrieb am Mo. 29. Apr. 
> 2019 um 07:35:
>
>> I recently read an article (German) about the dominance of English in 
>> programming languages [1]. It is about the fact that keywords in a language 
>> typically are English words. Thus it would be hard for non English speakers 
>> to learn programming - argue the authors.
>>
>> I wonder if there is really demand for that but of course it is weird to 
>> ask that on an English list.
>>
>> I also wonder if it would be possible on a tooling level to support 
>> keywords in other languages e.g. via build tags: // +language german
>>
>> Besides keywords we have a lot of names for functions, methods, structs, 
>> interfaces and so on. So there is definitely more to it.
>>
>> While such a feature may be beneficial for new programmers, to me it 
>> comes with many downsides like: readability, ambiguous naming / clashes, 
>> global teams ...
>>
>> I also believe the authors totally miss the point that learning Go is 
>> about to learn a language as it is because it is the language of the 
>> compiler.
>>
>> However I find the topic interesting and want to hear about your opinions.
>>
>> thanks - Chris
>>
>> 1: 
>>
>> https://www.derstandard.de/story/2000101285309/programmieren-ist-fuer-jeden-aber-nur-wenn-man-englisch-spricht
>>
>

-- 
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 more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] What happens to global vars when main() ends ?

[lgodio2]

Thanks jake.. If previous comments I received indicate that I should put 
the original question to rest,... but memguard.go suggests it should be 
re-opened

On Saturday, May 4, 2019 at 1:23:40 PM UTC-4, jake...@gmail.com wrote:
>
> On Friday, May 3, 2019 at 9:44:05 PM UTC-4, lgo...@gmail.com wrote:
>>
>> I'm currently working on a specialized encryption system where the keys 
>> are global...
>> More importantly, I've been unable to locate any decent on-line docs 
>> describing exactly how Go GC works from a functional programming 
>> perspective..I found some docs describing various GC concepts and others 
>> that indicate how difficult a problem GC is, but nothing that tells me how 
>> Go's GC system works from a programmers perspective i.e. what happens when 
>> a function ends ? when main() ends ? 
>>  
>>
>> I recall other discussions in this group about secure memory. At least 
> one person suggested https://github.com/awnumar/memguard. Probably worth 
> looking at, and doing more searching before reinventing the wheel. 
>  
>
>>
>> On Friday, May 3, 2019 at 8:50:00 PM UTC-4, Matt Harden wrote:
>>>
>>> On Fri, May 3, 2019, 17:28  wrote:
>>>
 Does Go GC  destroy all global vars prior to the end of main() ? 

>>>
>>> What do you mean by "destroy"? Go is not an object oriented language and 
>>> doesn't have the concept of a destructor. So no, it doesn't, but it also 
>>> doesn't need to.
>>>
>>> May I ask, what led you to ask this 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] What happens to global vars when main() ends ?

[lgodio2]

Andrey..This is one one the better ones I've seen ..but clearly parts II 
and III of this article are still in the making.
 
Example:
var kk int;

func main() {  
 kk= 22
 { kkk := 10
   println ( kkk, kk)
 }
 println ( kk)
 //println (kkk)  //compiler error bec at this point kkk has been 
destroyed by GC


}  // But what happens to kk at this point ??


On Friday, May 3, 2019 at 9:48:39 PM UTC-4, andrey mirtchovski wrote:

>
> https://www.ardanlabs.com/blog/2018/12/garbage-collection-in-go-part1-semantics.html
>  
>

-- 
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 more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] What happens to global vars when main() ends ?

[lgodio2]

I'm currently working on a specialized encryption system where the keys are 
global...
More importantly, I've been unable to locate any decent on-line docs 
describing exactly how Go GC works from a functional programming 
perspective..I found some docs describing various GC concepts and others 
that indicate how difficult a problem GC is, but nothing that tells me how 
Go's GC system works from a programmers perspective i.e. what happens when 
a function ends ? when main() ends ? 
 

On Friday, May 3, 2019 at 8:50:00 PM UTC-4, Matt Harden wrote:
>
> On Fri, May 3, 2019, 17:28 > wrote:
>
>> Does Go GC  destroy all global vars prior to the end of main() ? 
>>
>
> What do you mean by "destroy"? Go is not an object oriented language and 
> doesn't have the concept of a destructor. So no, it doesn't, but it also 
> doesn't need to.
>
> May I ask, what led you to ask this 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] What happens to global vars when main() ends ?

[lgodio2]

Does Go GC  destroy all global vars prior to the end of main() ? 

-- 
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 more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: What does "identifier...type" mean in a function definition?

[lgodio2]

Am I missing something ??
When u say :
For any function F and some type T declared asfunc F(x ...T) {} 
within F x will have type []T.  You can call F with a slice s of type []T 
as   F(s...)

Why is this needed ?? What's the point of using this "crypto-syntax"  
rather than just declaring the function as  func F(x [ ]T) { }

On Friday, May 3, 2019 at 1:13:02 PM UTC-4, Ian Lance Taylor wrote:
>
> On Fri, May 3, 2019 at 7:57 AM Louki Sumirniy 
> > wrote: 
> > 
> > Ellipsis makes the parameter type into a slice, but in append it makes 
> the append repeat for each element, or do I misunderstand this? 
> > 
> > There is a syntactic distinction between them too. Parameters it is a 
> prefix to the type, append it is a suffix to the name. It neatly alludes to 
> the direction in which the affected variable is operated on - inside the 
> function name ...type means name []type and for append, we are splitting 
> the slice into a tuple (internally), at least as I understand it, and the 
> parameter is the opposite, tuple to slice. 
> > 
> > I sometimes lament the lack of a tuple type in Go (I previously worked a 
> lot with Python and PHP), but []interface{} isn't that much more difficult 
> and the ellipsis syntax is quite handy for these cases - usually loading or 
> otherwise modifying essentially a super simple container array. 
>
> For any function F and some type T declared as 
>
> func F(x ...T) {} 
>
> within F x will have type []T.  You can call F with a slice s of type []T 
> as 
>
> F(s...) 
>
> That will pass the slice s to F as the final parameter.  This works 
> for any variadic function F. 
>
> The append function is implicitly declared as 
>
> func append(to []byte, add ...byte) 
>
> You can call it as 
>
> append(to, add...) 
>
> Here F is append and T is byte. 
>
> There is a special case for append with an argument of type string, 
> but other than that append is just like any other variadic function. 
>
> Ian 
>
>
>
> > On Friday, 3 May 2019 16:44:47 UTC+2, Ian Lance Taylor wrote: 
> >> 
> >> On Fri, May 3, 2019 at 7:34 AM Louki Sumirniy 
> >>  wrote: 
> >> > 
> >> > The ellipsis has two uses in Go, one is in variadic parameters, the 
> other is in the slice append operator. It is essentially an iterator that 
> takes a list and turns it into a slice (parameters) or takes a slice and 
> turns it into a recursive iteration (append). Parameters with the ellipsis 
> are addressed inside the function as a slice of the type after the 
> ellipsis. 
> >> 
> >> Note that there is nothing special about append here, it's just like 
> >> passing a slice to any other variadic parameter.  See 
> >> https://golang.org/ref/spec#Passing_arguments_to_..._parameters . 
> >> 
> >> Ian 
> > 
> > -- 
> > 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 golan...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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 more options, visit https://groups.google.com/d/optout.

[go-nuts] Why does this simple snip generate an infinite loop ?

[lgodio2]

func main() {  

var c8 uint8; 
var S [256] uint8;
 
   for c8 = 0x00; c8 <= 0xff; c8 += 0x01 { S[c8]= c8 }
}

-- 
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 more options, visit https://groups.google.com/d/optout.

[go-nuts] multiple array declaration.. Is there a easier way ?

[lgodio2]

The following statement seems very awkward, is there a cleaner way to write 
it ?

var T0= [256]uint32;  var T1= [256]uint32; var T2= [256]uint32; var T3= 
[256]uint32;  var T5= [256]uint32 


-- 
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 more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Is it possible to simplify this snippet?

[lgodio2]

Great example of why future Go updates should include the ternary operator.
Your code is mess-ey when written using keywords 'if' or 'switch'
but  using '?' it becomes much cleaner

p.Rect.X +=  rl.IsKeyDown(rl.KeyA) ? -1:0   +  (rl.IsKeyDown(rl.KeyD) ? 1 : 
0 )  
p.Rect.Y +=  rl.IsKeyDown(rl.KeyW) ? -1:0   +  (rl.IsKeyDown(rl.KeyS) ? 1 : 
0 )  
 
On Wednesday, May 1, 2019 at 8:38:10 AM UTC-4, гусь wrote:
>
> if rl.IsKeyDown(rl.KeyA) {
> p.Rect.X -= 1
> }
> if rl.IsKeyDown(rl.KeyD) {
> p.Rect.X += 1
> }
> if rl.IsKeyDown(rl.KeyW) {
> p.Rect.Y -= 1
> }
> if rl.IsKeyDown(rl.KeyS) {
> p.Rect.Y += 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go if else syntax .. suggested replacement

[lgodio2]

To Kortschak and all others participating in this debate :

Please don't get hung up over my choice of symbol '?' . 
My choice of symbol '?' and ';' is causing people to equate my proposal 
with a proposal to adopt C's ternary operator in Go. This is not what I 
intended to propose.

My proposal  regarding ? test {...} : {.. } in is nothing more, nothing 
less than  a replacement for 
if (test) { ... } else {... }   i.e. 'if' and 'else' are replaced by 
symbols '?' and ';' ..

For example I propose that a statement like  ? (x >-1) { y=x; z= x*x } : { 
y=x*x; z= y  } compile in Go
EXACTLY THE SAME way that Go currently compiles the same statement with 
symbol '?' replaced by 'if' and ';' replaced by 'else' . Currently, neither 
C++, C nor Go will compile the above statement 

The  second part of my proposal called for allowing statements like x = 
(test) ? 1 : 0 to compile in Go.
C will currently  compile this statement but Go will not. But I stress 
again, I intended Go to compile this   
statement exactly the same way it compiles if (test) { x=1}  else { x=0 }  
AND that no nested '?' symbols are allowed in a single assignment statement.

In short, I'm proposing a cleaner way to write Go 'if'  'else' statements,  
nothing more, nothing less.

If anyone can offer a concrete example of how my proposed statement will 
cause problems in Go, just  replace my chosen symbol '?' with 'if' and 
symbol ';' with 'else'  and you'll have a statement that will currently 
compile in Go (and cause the same problems)



 ..  
On Thursday, April 25, 2019 at 5:15:23 PM UTC-4, kortschak wrote:
>
> The difference is that the ternary operator is an expression and the 
> if...else is a statement. If you're only suggesting a syntax change, 
> then the difference becomes one of readability. 
>
> I'll ask again, how would you preclude nesting without making the 
> language more complex? 
>
> On Thu, 2019-04-25 at 13:38 -0700, lgo...@gmail.com  wrote: 
> > Rob: 
> > 
> > Am I missing something ?? 
> > The proposed syntax  
> > test ? {  
> > } : {  
> > }   
> > 
> > with no-nesting allowed is equivalent to 
> > if test {  
> > //. 
> > } else { 
> > // ..  
> > }  
> > ..The former is just a cleaner way of writing the latter 
> > 
> > Any complaints regarding 'abuse' associated with the former equally 
> > apply  
> > to the latter 
> > 
> > On Thursday, April 25, 2019 at 11:47:21 AM UTC-4, Rob 'Commander' 
> > Pike  
> > wrote: 
> > > 
> > > 
> > > I am pretty sure that the decision not to have ?: in Go was a 
> > > unanimous  
> > > decision by Robert, Ken and myself after almost no discussion. It 
> > > is too  
> > > easy to abuse, as the FAQ states. 
> > > 
> > > -rob 
> > > 
> > > 
>

-- 
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 more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go if else syntax .. suggested replacement

[lgodio2]

Rob:

Am I missing something ??
The proposed syntax 
test ? { 
} : { 
}  

with no-nesting allowed is equivalent to
if test { 
//.
} else {
// .. 
} 
..The former is just a cleaner way of writing the latter

Any complaints regarding 'abuse' associated with the former equally apply 
to the latter

On Thursday, April 25, 2019 at 11:47:21 AM UTC-4, Rob 'Commander' Pike 
wrote:
>
> I am pretty sure that the decision not to have ?: in Go was a unanimous 
> decision by Robert, Ken and myself after almost no discussion. It is too 
> easy to abuse, as the FAQ states.
>
> -rob
>
>

-- 
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 more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go if else syntax .. suggested replacement

[lgodio2]

Rob : how can it be abused if the compiler wont allow nested ? operators ??

On Thursday, April 25, 2019 at 11:47:21 AM UTC-4, Rob 'Commander' Pike 
wrote:
>
> I am pretty sure that the decision not to have ?: in Go was a unanimous 
> decision by Robert, Ken and myself after almost no discussion. It is too 
> easy to abuse, as the FAQ states.
>
> -rob
>
>

-- 
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 more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go if else syntax .. suggested replacement

[lgodio2]

Just to clarify :  My original proposal was to include as part  of Go the 
syntax

(test) ? {
{ //..code block for test=true
} : {
  //..code block for test=false
} 

I am NOT in favor of allowing nested ternary operations

In addition, I also propose allowing un-nested '?' as an alternative 
assignment statement i.e.  var = (temp >80) ? "red": "blue"

Thus, any further discussion of this topic should not involve issues 
related to nested ternary operations 

On Tuesday, April 23, 2019 at 9:05:31 PM UTC-4, lgo...@gmail.com wrote:
>
> It sure would be nice if Go syntax allowed programmers to replace 
>
> if ( test) {
> ...do sonething
> } else {
> ..do something else
> }
>
> with 
>
> ? (test) {
> //...do something
> }
> {
> //..do something else
> }
>
> The ? operator can be anything the Go language team considers appropriate
>

-- 
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 more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go if else syntax .. suggested replacement

[lgodio2]

For me, choosing to write

color = temp < 80 ? { "blue", "red") 

 vs 
func ternary(cond bool, pos, neg interface{}) interface{} {
if cond {
return pos
} else {
return neg
}
}
color := ternary( temp < 80, "blue", "red")

is a no brainer


On Wednesday, April 24, 2019 at 5:25:09 PM UTC-4, Andrew Klager wrote:
>
> Is this so bad?
>
> func ternary(cond bool, pos, neg interface{}) interface{} {
> if cond {
> return pos
> } else {
> return neg
> }
> }
>
> color := ternary( temp < 80, "blue", "red")
>
>
>
> On Wed, Apr 24, 2019 at 4:14 PM Chris Broadfoot <
> ch...@chrisbroadfoot.id.au > wrote:
>
>>
>>
>> On Wed, Apr 24, 2019 at 4:22 AM Robert Engels > > wrote:
>>
>>> Though to the ops point, not sure why Go doesn’t have the ternary 
>>> operator - which is pretty ubiquitous. 
>>>
>>
>> https://golang.org/doc/faq#Does_Go_have_a_ternary_form
>>  
>>
>>>
>>> On Apr 23, 2019, at 9:56 PM, Robert Engels >> > wrote:
>>>
>>> Why? You have saved 5 characters for no practical gain. I think you 
>>> would enjoy Ada. 
>>>
>>> On Apr 23, 2019, at 8:05 PM, lgo...@gmail.com  wrote:
>>>
>>> It sure would be nice if Go syntax allowed programmers to replace 
>>>
>>> if ( test) {
>>> ...do sonething
>>> } else {
>>> ..do something else
>>> }
>>>
>>> with 
>>>
>>> ? (test) {
>>> //...do something
>>> }
>>> {
>>> //..do something else
>>> }
>>>
>>> The ? operator can be anything the Go language team considers appropriate
>>>
>>> -- 
>>> 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 golan...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> -- 
>>> 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 golan...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> 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 golan...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go if else syntax .. suggested replacement

[lgodio2]

If instead of writing:  temperature > 80 ? red : green
you choose to follow Marcus and write instead:
map[bool]string{true:"red",false:"green"}[temperature>80]

OR call 

func ternary(x int) int {
return map[bool]int{true:12345,false:-1}[x>0]
}

Go right ahead ! ..as they say,  "different strokes for different folks" 

But don't deny others the ability to choose the first alternative

On Wednesday, April 24, 2019 at 12:34:09 PM UTC-4, Marcus Low wrote:
>
> color := map[bool]string{true:"red",false:"green"}[temperature>80]
> Here you go.
>
> On Wednesday, April 24, 2019 at 10:08:53 PM UTC+8, Mark Volkmann wrote:
>>
>> Are there really developers that find this unreadable? 
>>
>> color := temperature > 80 ? “red” : “green” 
>>
>> I know what you are going to say. People will nest them. But even nested 
>> usage can be readable when formatted nicely with one condition per line. 
>> Another alternative is to allow only unnested ternaries. 
>>
>> R. Mark Volkmann 
>> Object Computing, Inc. 
>>
>> > On Apr 24, 2019, at 8:58 AM, Jan Mercl <0xj...@gmail.com> wrote: 
>> > 
>> >> On Wed, Apr 24, 2019 at 3:48 PM L Godioleskky  
>> wrote: 
>> >> 
>> >> The lack of a Go ternary operator is at odds with Go's major theme of 
>> clean and easy to read syntax. Those who choose not to use the ternary 
>> operator can always resort back to Go's current 'if -else' or 'case' 
>> syntax. So Go syntax suffers no negative impact by adding the ternary op to 
>> its syntax list.  Those opposed to the ternary op should not be allowed to 
>> deny it use other Go programmers, that consider it useful. 
>> > 
>> > That's backwards. Those who has to read the code can no more chose not 
>> > to decrypt the unreadable 4-level nested ternary operations instead of 
>> > 5 if statements. 
>> > 
>> > And to follow on your "logic". If you add to Go even just 10% of what 
>> > people consider useful, it will become a new C++, only much worse. And 
>> > again by your very logic. Why we, that haven't chosen to code in C++ 
>> > in the first place, would be denied by others to use Go, when those 
>> > others have C++ already at hand? 
>> > 
>> > Let everyone use the language he/she likes. Why ruin it for others 
>> > instead of that by forcing Go to become the same as his/her other 
>> > favorite language? 
>>
>

-- 
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 more options, visit https://groups.google.com/d/optout.

[go-nuts] Go if else syntax .. suggested replacement

[lgodio2]

It sure would be nice if Go syntax allowed programmers to replace 

if ( test) {
...do sonething
} else {
..do something else
}

with 

? (test) {
//...do something
}
{
//..do something else
}

The ? operator can be anything the Go language team considers appropriate

-- 
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 more options, visit https://groups.google.com/d/optout.

[go-nuts] ?? Does anyone know of a good on-line doc that describes how Go Garbage Collection works .. My recent web searches proved fruitless

[lgodio2]

all responses appreciated 

-- 
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 more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: built-in alternative to bcrypt?

[lgodio2]

Try scrypt at   github.com/elithrar/simple-scrypt  . It's not a 
'standard lib' item, but I've found the authors code easy to implemented as 
'package main' code vs 'package' code

On Monday, April 22, 2019 at 6:14:48 AM UTC-4, whiteh...@googlemail.com 
wrote:
>
> I'm porting some code over to Go, and currently looking at some password 
> hashing.  I'm wondering if there is a 'standard library' alternative to 
> using bcrypt?
>
> I am concerned about the Go binary size, since I'm already at 15MB!  So 
> I'm trying to limit external dependencies as much as possible.  
>
> The data being stored is not critical or sensitive, just some email 
> address mainly.  
>
> From my research it sounds like 'golang.org/pkg/crypto/sha512/' might be 
> what I need, but I dont see any clear alternative for the following 
> functions below:  
>
> I'm still new to Go, so I'm wondering what would be the recommended 
> solution using the standard library please?
>
> Peter
>
>
> bcrypt.GenerateFromPassword
>
> bcrypt.CompareHashAndPassword
>

-- 
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 more options, visit https://groups.google.com/d/optout.

[go-nuts] go build *.exe file size seems much too large

[lgodio2]

For this simple go code, the *.exe file size is 1800 KB ...why so large 
compared to equivalent C-compiled code ??
package main
import( "math"; "fmt" )
func main() {
fmt.Printf("\n %8.3f", math.Sin(1.2) )
}
Does the go generated *.exe file contain code only for math.Sin() or all 
the functions that comprise "math"  ?

Obviously there much more in the go *.exe file because of "fmt", but the 
basic question still is why is the go *.exe file so large ??
In addition to Sin() and Printf() what else is contained in the go *.exe 
file ??
   

-- 
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 more options, visit https://groups.google.com/d/optout.

[go-nuts] go execution speed for float64 based calculations vs float32

[lgodio2]

?? On 64-bit CPUs does anyone have any experience comparing the run-time 
speed of float64 based calculations vs float32 ?

Some of my C-code when translated to Go-code seems to run noticeably 
slower, so I'm wondering if I can speed things up by converting float vars 
to float32 vs float64 

-- 
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 more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: floating point question

[lgodio2]

I think michael Jones ' explanation is correct...when we  x : =1.3  
Go translates this to a binary representation of 1.3 that is a very close 
approximation to decimal 1.3
so when you do fmt.Printf( "\n %v ", x) you get the the binary version of x 
translated back to decimal, which will not be exactly 1.3

x=1.3(decimal)  is NOT==  1.3(binary) exactly  but will be very close 
approximation to it 

So to check floating point numbers for equaliy  don't use  if a== 1.4 
{.}   instead use if  math.Abs(x-1.4) < 1.0e-8 {... }
Whether you use 1.0e-8   or something some other value depends on your 
choice of 'how close to 1.4' would you consider ' is good enough' for the 
code you are working with 

On Monday, April 15, 2019 at 5:18:51 AM UTC-4, Miki Tebeka wrote:
>
> Hi,
>
> Can anyone explain the below?
> (When printing out b with %.20f it prints 1.20996447)
>
> Thanks
>
> package main
>
> import "fmt"
>
> func main() {
> a, b := 1.1*1.1, 1.21
> fmt.Println(a == b)  // true
> fmt.Println(1.1*1.1 == 1.21) // false
> }
>
>
>
>

-- 
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 more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Does anyone know how to implement dynamic two-dimensional arrays ??

[lgodio2]

Burak Marcin and Miki :  
 Many thanks, my problem is solved thanks to your comments 

On Sunday, April 21, 2019 at 1:10:40 AM UTC-4, lgo...@gmail.com wrote:
>
> Here's the snippet I'm trying to run
>
> package main
> import ( "fmt" )
>
> func main() {
>  Af(5)
> }
>
> func Af ( N int) {
>
> //var M = new([N][N]uint16) !compiler error
> //var M = make([N][N]uint16)!compiler error
>
> //var M = make([][]uint16, N*N)  ##  run-time error
>
> // run-time error
>   M := make( [][]uint16, N*N,N*N) 
>   for y:=0; y< N; y++ { 
> for x :=0; x< N; x++ { 
>M[y][x] = uint16(100*y +x)
>   }  }
>
>   for y :=0; y< N; y++ { 
>   fmt.Printf("\n y= %3d", y )
>   for x :=0; x< N; x++ { 
>fmt.Printf(" %3d ", M[x][y] )
>   }   }   
>  fmt.Printf("\n>>" )
> }
>

-- 
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 more options, visit https://groups.google.com/d/optout.

[go-nuts] Does anyone know how to implement dynamic two-dimensional arrays ??

[lgodio2]

Here's the snippet I'm trying to run

package main
import ( "fmt" )

func main() {
 Af(5)
}

func Af ( N int) {

//var M = new([N][N]uint16) !compiler error
//var M = make([N][N]uint16)!compiler error

//var M = make([][]uint16, N*N)  ##  run-time error

// run-time error
  M := make( [][]uint16, N*N,N*N) 
  for y:=0; y< N; y++ { 
for x :=0; x< N; x++ { 
   M[y][x] = uint16(100*y +x)
  }  }

  for y :=0; y< N; y++ { 
  fmt.Printf("\n y= %3d", y )
  for x :=0; x< N; x++ { 
   fmt.Printf(" %3d ", M[x][y] )
  }   }   
 fmt.Printf("\n>>" )
}

-- 
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 more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Learning Data Structures and algorithms with Golang

[lgodio2]

Bhagvan's disgrceful misuse of this forum to support his commercial 
endeavors should result in the  exclusion of all his  future posts


On Friday, April 5, 2019 at 10:28:52 AM UTC-4, Bhagvan Kommadi wrote:
>
> Check out my published book on Amazon from packt: 
>
>  Learning Data Structures and algorithms with Golang
>
>
> https://www.amazon.in/gp/product/1789618509?ref=em_1p_0_ti_=pe_2516461_197852611
>
>
> #machinelearning #go #fintech #algorithms #datastructures
>
>

-- 
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 more options, visit https://groups.google.com/d/optout.