[go-nuts] confusing differences in reflect Type knowledge for a receiver vs. an argument

[Randall O'Reilly]

I'm new to golang, and am hitting some seemingly strange territory that I 
couldn't find much prior discussion about -- here's one example of the 
phenomenon in question:

https://stackoverflow.com/questions/22153269/how-to-reflect-fields-of-containing-struct-from-a-method-of-the-embedded-struct/49094937#49094937

In brief, it seems that reflect does NOT have access to the "true" 
underlying type of a struct, when accessing a function receiver struct 
pointer, but it DOES have access when an object is passed as a regular 
argument via an interface.  While I understand that the receiver is 
apparently special in terms of binding to the interface, there is also the 
statement that it is really just another arg..

In my use-case, I was trying to use reflect to provide some generic tree 
functionality that could automatically apply to "derived" types that embed 
a "Node" type with all the tree-relevant functionality.  However, depending 
on this difference in where the struct appeared (receiver vs. arg) I was 
variably getting the desired "inheritance" ability to access the fields of 
the derived types in the base type's code.  In particular, defining a 
MarshalJSON method for my base type forced everything to be Marshal'd as 
the base type, not as its actual type -- the generic Marshal gets the 
struct as an arg, whereas when you define this method you turn it into a 
receiver!

This issue generally seems relevant to this discussion about the value of 
struct embedding and the true nature of inheritance in Go: 
https://github.com/golang/go/issues/22013 -- as someone coming from the C++ 
world, I find the ability to get at least some basic inheritance 
functionality to be very powerful, while appreciating the extra flexibility 
of the compositional / interface model as well.  The example of generic 
JSON rendering shows how powerful reflection is, *when it can operate on 
the "true" underlying types* -- this peculiarity with the receivers not 
having the same "insight" into the true type seems like it should be an 
easily fixable limitation (to the extent that args really are all the 
same), and would make the overall behavior more consistent.

Philosophically, Go seems to be "optimized for the lazy" (or elegance if 
you prefer), which is certainly one of its main advantages compared to C++, 
but then in the discussion on that proposal, people seem all-too-willing to 
argue for rewriting a bunch of methods over and over again!  That seems to 
contradict this core philosophy.  Anyway, someone can hopefully let me know 
if I should file a bug ticket about this specific inconsistency (or let me 
know if it already exists somewhere -- I couldn't find it but could have 
not been using the right terms).

Here's a more succinct example based on above stackoverflow case:

https://play.golang.org/p/KmihXxU19Dd

package main

import (
"fmt"
"reflect"
)

type Inner struct {
InMbr bool
}

type InType interface {
InFun()
}

type Outer struct {
Inner
Id   int
name string
}

func (in *Inner) InFun() {
typ := reflect.TypeOf(in).Elem()
fmt.Printf("InFun on in always says Inner: %v\n", typ.Name())
// can I coerce the thing?
// it := in.(InType) // the "obvious" thing fails with: invalid type 
assertion: in.(InType) (non-interface type *Inner on left)
// try to obfuscate the process via reflect: (per 
https://groups.google.com/forum/#!msg/Golang-Nuts/KB3_Yj3Ny4c/Ai8tz-nkBwAJ)
vp := reflect.New(typ)
vp.Elem().Set(reflect.ValueOf(in).Elem())
it := vp.Interface().(InType)
ArgFun(it) // no such luck: argfun says "Inner" still
}

func ArgFun(in InType) {
typ := reflect.TypeOf(in).Elem()
fmt.Printf("ArgFun on in tells the truth: %v\n", typ.Name())
}

func main() {
val := Outer{}
val.InFun()
ArgFun(&val)
}

Output: 

InFun on in always says Inner: Inner
ArgFun on in tells the truth: Inner
ArgFun on in tells the truth: Outer


-- 
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: confusing differences in reflect Type knowledge for a receiver vs. an argument

[Randall O'Reilly]

Thank you for that clarification of what is happening under the hood.

Nevertheless, I do think there are many cases where it would be very valuable 
to have access through reflect of the true underlying type of the receiver 
struct.  This is evident in that stack overflow question, the *JSON code, and 
probably many other cases where reflect is used.  Just to be clear, in the 
[Un]MarshalJSON code, the inability to access the true type means that you 
cannot use an embedded interface to properly serialize derived types — any 
generic functionality you might want to add to the process must be added 
explicitly to each instance separately.  This leads to a need for major code 
replication, seemingly in contradiction to the Go philosophy.  Furthermore, I 
have many use-cases of wanting to generically access fields (Get / Set values, 
etc) that might be on a derived type of my tree Node type.

Anyway, if it is not technically possible, then there’s no point in wishing for 
it.  But I don’t think it is accurate to say that this would not extend the 
power and elegance of the language.

Meanwhile, in case others encounter this same situation, I have had to add a 
“this” member to my Node struct that stores the interface pointer version of 
the struct, so it is always possible to use that when access to the derived 
type is necessary.  Might make some Go folks barf, but it does the trick!  Just 
trying to get stuff working with the fewest LOC possible :)

- Randy

> On Mar 5, 2018, at 2:24 PM, Krzysztof Kowalczyk  wrote:
> 
> (in *Inner) InFunc() can't possibly say `in` is Outer.
> 
> This piece of code:
> 
> var := Outer{}
> val.InFunc()
> 
> Is really:
> 
> val := Outer{}
> var tmpInner *Inner = &(val.Inner)
> tmpInner.InFunc()
> 
> What is passed to InFunc is a pointer to Inner struct embedded inside Outer 
> struct, not a pointer to Outer struct.
> 
> The compiler did a little bit of magic behind the scenes because it makes 
> using struct composition more convenient.
> 
> The idea is that if you include Inner struct inside Outer struct, Outer 
> "inherits" fields and functions of Inner so syntactically you can say 
> outer.Foo() and it will call function defined in Inner() without you having 
> to say outer.Inner.Foo().
> 
> There's also confusion about what reflection is for.
> 
> In (in *Inner) InFoo() you already know the static type of in, which is a 
> pointer to struct Inner. There's no need to use reflection.
> 
> Reflection is for cases where you have interface type, including the most 
> common case of empty interface `interface{}`.
> 
> You can convert any value with static type to `interface{}`
> 
> var inter interface{} = in // you can convert any static type to interface{}
> // code using reflection on inter
> 
> // it := in.(InType) // the "obvious" thing fails with: invalid type 
> assertion: in.(InType) (non-interface type *Inner on left)
> 
> Here you can't use type assertion on `in` because it only works on interfaces 
> (https://www.programming-books.io/essential/go/a-25362-type-assertion) and 
> `in` isn't an interface. The compiler tells you so.
> 
> -- kjk
> 
> On Monday, March 5, 2018 at 10:28:25 AM UTC-8, Randall O'Reilly wrote:
> I'm new to golang, and am hitting some seemingly strange territory that I 
> couldn't find much prior discussion about -- here's one example of the 
> phenomenon in question:
> 
> https://stackoverflow.com/questions/22153269/how-to-reflect-fields-of-containing-struct-from-a-method-of-the-embedded-struct/49094937#49094937
> 
> In brief, it seems that reflect does NOT have access to the "true" underlying 
> type of a struct, when accessing a function receiver struct pointer, but it 
> DOES have access when an object is passed as a regular argument via an 
> interface.  While I understand that the receiver is apparently special in 
> terms of binding to the interface, there is also the statement that it is 
> really just another arg..
> 
> In my use-case, I was trying to use reflect to provide some generic tree 
> functionality that could automatically apply to "derived" types that embed a 
> "Node" type with all the tree-relevant functionality.  However, depending on 
> this difference in where the struct appeared (receiver vs. arg) I was 
> variably getting the desired "inheritance" ability to access the fields of 
> the derived types in the base type's code.  In particular, defining a 
> MarshalJSON method for my base type forced everything to be Marshal'd as the 
> base type, not as its actual type -- the generic Marshal gets the struct as 
> an arg, whereas when you define this method you turn it into a receiver!
> 
> T

Re: [go-nuts] Re: confusing differences in reflect Type knowledge for a receiver vs. an argument

[Randall O'Reilly]

On Mar 5, 2018, at 10:32 PM, Ian Lance Taylor  wrote:
> 
> Go doesn't have anything like inheritance in C++.  What you are
> calling the "true underlying type" simply doesn't exist in Go.  Go has
> embedded fields, and methods of embedded fields are promoted to become
> methods of the outer type in which they are embedded.  But the outer
> type does not inherit anything from the inner type, at least not if
> you are using the word "inherit" in the sense that it is used in C++.
> The promoted methods are still methods on the inner type, they are
> just accessible directly from the outer type.
> 
> I think it's generally best to approach these problems in terms of how
> Go works, rather than trying to recreate C++ approaches in Go.  Go
> doesn't work the way that C++ does.
> 
> Ian

So why then does reflect.TypeOf(obj) return the “Outer” type in the example 
code I posted, here:

func ArgFun(in InType) {
typ := reflect.TypeOf(in).Elem()
fmt.Printf("ArgFun on in tells the truth: %v\n", typ.Name())
}

https://play.golang.org/p/KmihXxU19Dd

I don’t think json.Marshal etc would work without this behavior..

Per the discussion here: https://github.com/golang/go/issues/22013 — it seems 
like Go is rather unclear about exactly what level of C++-like inheritance it 
wants to support.  I don’t want to recreate any of that discussion here, but 
I’ll just add a tiny vote for at least keeping the notion of embedding as it is 
— don’t throw the baby out with the bathwater!  The presence of interfaces and 
the compositional model in Go is TONS better than C++’s rigid inheritance 
constraints, but sometimes a simple inherit-and-extend model is just the right 
thing, and it seems like it doesn’t add that much additional complexity to 
support it.  Maybe just need to add a bit of relevant docs in places to resolve 
residual confusions, such as the one I encountered.  Thanks for all your hard 
work on creating this awesome language!

- Randy



-- 
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] stringer tool to generate string to const int conversion

[Randall O'Reilly]

I just made a few mods to the stringer tool to generate a function that 
converts a string back to the const int type, e.g., for this const int type:

// SignalType provides standard signals -- can extend by starting at iota + 
last signal here
type SignalType int64

const (
NilSignal SignalType = iota
SignalChildAdded // data is the added child
SignalChildDeleted   // data is deleted child
SignalChildrenDeleted// no data
SignalNodeUpdated// entire node updated
SignalFieldUpdated   // a field was updated -- data is name 
of field
SignalTypeBaseN  // number of base-level signal type 
consts -- this is start for any derived ones
)

it generates this function in the stringer output:

func StringToSignalType(s string) (SignalType, error) {
for i := 0; i < len(_SignalType_index)-1; i++ {
if s == 
_SignalType_name[_SignalType_index[i]:_SignalType_index[i+1]] {
return SignalType(i), nil
}
}
return 0, fmt.Errorf("String %v is not a valid option for type 
SignalType", s)
}

Seems like this might be of general utility?  Is there some other simpler way 
of doing this that I’m overlooking?  Patch below.  Didn’t handle the 
multiple-runs and map cases yet..

- Randy

diff --git a/cmd/stringer/stringer.go b/cmd/stringer/stringer.go
index 4b8d1ba4..291051f8 100644
--- a/cmd/stringer/stringer.go
+++ b/cmd/stringer/stringer.go
@@ -132,7 +132,7 @@ func main() {
g.Printf("\n")
g.Printf("package %s", g.pkg.name)
g.Printf("\n")
-   g.Printf("import \"strconv\"\n") // Used by all methods.
+   g.Printf("import (\"strconv\"; \"fmt\")\n") // Used by all methods.
 
// Run generate for each type.
for _, typeName := range types {
@@ -584,6 +584,15 @@ const stringOneRun = `func (i %[1]s) String() string {
}
return _%[1]s_name[_%[1]s_index[i]:_%[1]s_index[i+1]]
 }
+
+func StringTo%[1]s(s string) (%[1]s, error) {
+   for i := 0; i < len(_%[1]s_index)-1; i++ {
+   if s == _%[1]s_name[_%[1]s_index[i]:_%[1]s_index[i+1]] {
+   return %[1]s(i), nil
+   }
+   }
+   return 0, fmt.Errorf("String %%v is not a valid option for type %[1]s", 
s)
+}
 `
 
 // Arguments to format are:
@@ -600,6 +609,15 @@ const stringOneRunWithOffset = `func (i %[1]s) String() 
string {
}
return _%[1]s_name[_%[1]s_index[i] : _%[1]s_index[i+1]]
 }
+
+func StringTo%[1]s(s string) (%[1]s, error) {
+   for i := 0; i < len(_%[1]s_index)-1; i++ {
+   if s == _%[1]s_name[_%[1]s_index[i]:_%[1]s_index[i+1]] {
+   return %[1]s(i + %[2]s), nil
+   }
+   }
+   return 0, fmt.Errorf("String %%v is not a valid option for type %[1]s", 
s)
+}
 `
 
 // buildMultipleRuns generates the variables and String method for multiple 
runs of contiguous values.

-- 
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] Is it possible to unmarshall Json by selecting the struct from a field in the Json?

[Randall O'Reilly]

I implemented a type registry solution for this situation:
https://github.com/rcoreilly/goki/tree/master/ki/kit

you just add a one-liner after every struct you want to register, and it builds 
the map for you — makes it fully modular, etc.  Cheers,

- Randy

> On Mar 28, 2018, at 12:59 PM, Alex Efros  wrote:
> 
> Hi!
> 
> On Wed, Mar 28, 2018 at 02:13:55PM -0400, Shawn Milochik wrote:
>> Thanks for the challenge! I found some unused code in the getItem function,
>> and a way to make it a bit shorter by removing the lookup map. However,
>> depending on the number of struct types the map may be cleaner for OP.
>> 
>> https://play.golang.org/p/ZH09nHsrRoR
> 
> This wasn't supposed to be a challenge - I tried to be as less invasive
> as possible, just cleanup things a bit. If you wanna challenge - it's here:
> https://play.golang.org/p/N8YLUGdP4Kb
> I don't bother is it shorter, but (at least to me) it's more clear.
> 
> -- 
>   WBR, Alex.
> 
> -- 
> 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.

-- 
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] [ANN] GoKi Trees and GoGi GUI

[Randall O'Reilly]

https://github.com/goki/goki — key demo in: 
https://github.com/goki/goki/tree/master/gi/examples/widgets

This is the first release of a new Go framework built around the Tree as a core 
data structure (Ki = Tree in Japanese), which includes as its first application 
a fully-native Go GUI (built on top of a modified version of the Shiny 
OS-specific backend drivers, supporting Mac, Linux, and Windows so far).

Building on the central idea in Go that having a few powerful data-structures 
is essential for making many problems easier to solve, the GoKi trees are an 
attempt to provide a powerful tree structure that can support things like scene 
graphs, DOM’s, parsing trees, etc.

The GoGi graphical interface system is a kind of “proof is in the pudding” 
test, which weighs in at under 20k LOC and provides a reasonably full-featured 
GUI — with a bit more work it should be able to do most of the stuff you can do 
in Qt, and already includes a (self) reflection-driven GUI designer.

The overall design is an attempt to integrate existing standards and 
conventions from widely-used frameworks, including Qt (overall widget design), 
HTML / CSS (styling), and SVG (rendering). Rendering in SVG is directly 
supported by the GoGi 2D scenegraph, with enhanced functionality for 
interactive GUI's. This 2D framework also integrates with a (planned) 3D 
scenegraph, to support interesting combinations of these frameworks. Currently 
GoGi is focused on desktop systems, but nothing prevents adaptation to mobile.

Right now the rendering is based off of a modified version of 
https://github.com/fogleman/gg, but I’m very interested in integrating the new 
rasterx system that Steven Wiley recently announced.

I’d be very interested in people’s impressions, suggestions, etc, and welcome 
all interested contributors (there’s certainly much more to do) — it would be 
great if this could provide the start for a widely-supported Go-native GUI 
framework!  This was my first Go project after many years in C++ / Qt land, and 
I’m excited to join the community, and have really been impressed with the 
language and ecosystem etc.  The contrast in complexity and build time between 
Qt and GoGi is really striking, and has kept me going despite the huge amount 
of effort it took to get this new project off the ground..  Cheers,

- Randy

-- 
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: [ANN] GoKi Trees and GoGi GUI

[Randall O'Reilly]

Matt — thanks a ton for all the detailed comments!  Just quickly I figured out 
the git/hub steps to split out the top-level repositories into separate “ki” 
and “gi” repos, so the link and package paths are now:

https://github.com/goki/gi and ki

and hopefully this now works for the demo — just worked for me on my mac..

> go get github.com/goki/gi
> cd ~/go/src/github.com/goki/gi/examples/widgets
> go get ...
> go build
> ./widgets

More reactions later but just wanted to get that done so the paths should be 
stable now!  Cheers,

- Randy

> On May 4, 2018, at 9:09 AM, matthewju...@gmail.com wrote:
> 
> Hi Randy, here’s a code review.
> 
> Thanks for the BSD license.
> 
> I prefer the look of a minimized import path, I would have put the title 
> library at the top level (github.com/goki/ki).
> 
> To me the README doesn’t balance text and code examples well enough, I’d like 
> to see more example uses and less text. In package ki I’d hope the library 
> does enough work to not require so much README.
> 
> I think ki isn’t a bad package name after reading what it means but seeing 
> the package used in app code won’t show the point as obviously as an English 
> word for some people. tree.New() to me says “new data structure var” while 
> ki.New() says “I have to read the docs now”.
> 
> (when I say 'app' I mean a program that uses your library or a program 
> written to compile with a Go compiler; an application of the library, an 
> application of the Go programming language)
> 
> The Ki interface is a code smell to me. Usually I interpret library 
> interfaces as saying “the app provides an implementation of the interface and 
> the library provides shared logic that uses the interface methods” or in this 
> case I expect the ki lib will provide varying data structures and behaviors 
> that implement the ki var. Just reading down to line 42 of ki.go I feel like 
> this isn’t very Go-like.
> 
> You’re getting into generics territory with this:
> 
> func NewOfType(typ reflect.Type) Ki {
> 
> My view is idiomatic Go code tends to avoid this kind of thing due to 
> maintenance and readability burden. I haven’t used your lib but I am 
> concerned about it not being a big win over a per-app implementation. I can 
> see you’ve done a lot of work to make generics work.
> 
> In type Node I would consider embedding Props.
> 
> I haven’t looked at all of the methods but do the methods on Node need to be 
> to a pointer?
> 
> func (n *Node) Fields() []uintptr {
> 
> Seeing uintptr in a public method is a code smell to me.
> 
> In type Deleted consider maybe embedding sync.Mutex.
> 
> // fmt.Printf("finding path: %v\n", k.Path)
> 
> Instead of comments you may want to consider this pattern:
> 
> const debug = false
> …
> if debug {
> fmt.Printf("finding path: %v\n", k.Path)
> }
> 
> I think this library would be a good study for the Go 2 
> (https://blog.golang.org/toward-go2) generics effort, if you have time 
> consider writing an experience report and posting it: 
> https://github.com/golang/go/issues/15292
> 
> Perhaps consider embedding ki.Signal in gi.Action, and MakeMenuFunc, 
> ki.Signal, *Icon, and ButtonStates in ButtonBase, some fields in ColorView, 
> Dialog, FillStyle, FontStyle, LayoutStyle, LayoutData, Layout, MapView, 
> MapViewInline, Node2DBase, Paint, ImagePaintServer, SliceView, 
> SliceViewInline, SliderBase, SplitView, StrokeStyle, StructView, 
> StructViewInline, BorderStyle, ShadowStyle, Style, TabView, TextStyle, 
> TextField, SpinBox, ComboBox, TreeView, ValueViewBase, Viewport2D, Window. I 
> like to avoid any unnecessary field symbols.
> 
> These kinds of structs are a code smell to me:
> 
> type ColorValueView struct {
> ValueViewBase
> }
> 
> Why a Base type? Can your types be simpler?
> 
> type Node2D and type ValueView seem like other possible overuses of interface 
> to me. The size of type PaintServer is closer to what I’d expect with an 
> interface, and Labeler seems idiomatic.
> 
> I like the screenshot.
> 
> // check for interface implementation
> var _ Node2D = &Line{}
> 
> I don’t like this pattern.
> 
> Given the amount of code and project maturity I wouldn’t expect you to make a 
> lot of changes, but I do think it could have been built with a stronger 
> resilience to change. Thanks for sharing here.
> 
> Matt
> 
> On Friday, May 4, 2018 at 5:39:35 AM UTC-5, Randall O'Reilly wrote:
> https://github.com/goki/goki — key demo in: 
> https://github.com/goki/goki/tree/master/gi/examples/widgets 
> 
> This is the first release of a new Go framework built around the Tree as a 
> core data structu

Re: [go-nuts] Re: [ANN] GoKi Trees and GoGi GUI

[Randall O'Reilly]

ypes that build on those is exactly what you need!  I do wonder if 
perhaps the allergy to that framework has inhibited development of a GUI in Go 
up to this point — e.g., I saw in both the Shiny and 
https://github.com/walesey/go-engine frameworks that there was some awkwardness 
about the generic container nature of a scene graph…  

- Randy

ps. several of the other code review comments reflect the “alpha” status of 
this project and can easily be cleaned up. The README files in particular were 
mostly just “notes to self” and really need to be rewritten. :)

> On May 4, 2018, at 3:35 PM, Randall O'Reilly  wrote:
> 
>> 
>> The Ki interface is a code smell to me. Usually I interpret library 
>> interfaces as saying “the app provides an implementation of the interface 
>> and the library provides shared logic that uses the interface methods” or in 
>> this case I expect the ki lib will provide varying data structures and 
>> behaviors that implement the ki var. Just reading down to line 42 of ki.go I 
>> feel like this isn’t very Go-like.
>> 
>> You’re getting into generics territory with this:
>> 
>> func NewOfType(typ reflect.Type) Ki {
>> 
>> My view is idiomatic Go code tends to avoid this kind of thing due to 
>> maintenance and readability burden. I haven’t used your lib but I am 
>> concerned about it not being a big win over a per-app implementation. I can 
>> see you’ve done a lot of work to make generics work.

-- 
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] [ANN] GoKi Trees and GoGi GUI

[Randall O'Reilly]

abilities built in to the tree nodes, 
> like intra-node messaging, attribute maps, and more. So, I will echo some 
> other comments here and suggest that you might want to consider letting some 
> of those responsibilities fall to an object referenced by the node, which 
> might allow simpler nodes to avoid unneeded overhead.
> 
> 
> 
> I have been playing around a bit with GUIs also, but decided to base my stuff 
> on SDL 2. It looks like you are basing off of  something called shiny 
> (golang.org/x/exp/shiny) ? Abstracting away the OS specific layer to make an 
> all-platform GUI is a notoriously hard thing to do robustly, and is a 
> frequent source of problems, just like intermittent hangups. Even with 
> something as well supported as SDL, I was getting an intermittent bug until I 
> realized I absolutely need to call runtime.LockOSThread(). Something like 
> that might be going on here, and again we can follow up offline if you wish, 
> or if you have any questions about using oksvg or rasterx.
> 
> 
> 
> cheers,
> 
> Steve
> 
> 
> 
> 
> 
> 
> 
> 
> On Friday, May 4, 2018 at 3:39:35 AM UTC-7, Randall O'Reilly wrote:
> https://github.com/goki/goki — key demo in: 
> https://github.com/goki/goki/tree/master/gi/examples/widgets 
> 
> This is the first release of a new Go framework built around the Tree as a 
> core data structure (Ki = Tree in Japanese), which includes as its first 
> application a fully-native Go GUI (built on top of a modified version of the 
> Shiny OS-specific backend drivers, supporting Mac, Linux, and Windows so 
> far). 
> 
> Building on the central idea in Go that having a few powerful data-structures 
> is essential for making many problems easier to solve, the GoKi trees are an 
> attempt to provide a powerful tree structure that can support things like 
> scene graphs, DOM’s, parsing trees, etc. 
> 
> The GoGi graphical interface system is a kind of “proof is in the pudding” 
> test, which weighs in at under 20k LOC and provides a reasonably 
> full-featured GUI — with a bit more work it should be able to do most of the 
> stuff you can do in Qt, and already includes a (self) reflection-driven GUI 
> designer. 
> 
> The overall design is an attempt to integrate existing standards and 
> conventions from widely-used frameworks, including Qt (overall widget 
> design), HTML / CSS (styling), and SVG (rendering). Rendering in SVG is 
> directly supported by the GoGi 2D scenegraph, with enhanced functionality for 
> interactive GUI's. This 2D framework also integrates with a (planned) 3D 
> scenegraph, to support interesting combinations of these frameworks. 
> Currently GoGi is focused on desktop systems, but nothing prevents adaptation 
> to mobile. 
> 
> Right now the rendering is based off of a modified version of 
> https://github.com/fogleman/gg, but I’m very interested in integrating the 
> new rasterx system that Steven Wiley recently announced. 
> 
> I’d be very interested in people’s impressions, suggestions, etc, and welcome 
> all interested contributors (there’s certainly much more to do) — it would be 
> great if this could provide the start for a widely-supported Go-native GUI 
> framework!  This was my first Go project after many years in C++ / Qt land, 
> and I’m excited to join the community, and have really been impressed with 
> the language and ecosystem etc.  The contrast in complexity and build time 
> between Qt and GoGi is really striking, and has kept me going despite the 
> huge amount of effort it took to get this new project off the ground..  
> Cheers, 
> 
> - Randy 
> 
> 
> -- 
> 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.

-- 
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] [ANN] GoKi Trees and GoGi GUI

[Randall O'Reilly]

On May 5, 2018, at 8:38 AM, matthewju...@gmail.com wrote:
> In a generic container I would expect to see items typed as interface{} and 
> the behavior defined on a slice of interface{} or struct with private slice 
> of interface{} field.
> 
> From the godoc it looks like type Node implements type Ki, and there’s no 
> other type that implements Ki. I don’t understand why this is necessary, why 
> not just define the methods on type Node?
> 
> * But a diversity of functionality at each node (i.e., many different 
> possible node types) 
> 
> My thought is this calls for a type Node interface, then there would be more 
> types that implement Node. This line of thinking may lead to similar code to 
> what you have already, I’m not sure.

Here’s some explanation relative to those points:

* Ki is basically a “Node” interface, but you can’t name a struct and an 
interface the same thing, so we have Ki and Node as two sides of the same 
thing..

* The Ki interface allows specific nodes to override any of the functions, and, 
critically, ONLY an interface type knows what the actual underlying type of a 
struct is, so we need that to be able to access the fields etc of the actual 
struct at each node.  In general, having an interface in Go opens up lots of 
extra powers — could not have done many other things without it..

* There is no point in supporting a fully generic interface{} in a Tree 
container because the tree structure and logic requires each node to implement 
the same basic parent / child structure etc..  So Ki is the “minimal” interface 
for all tree nodes, and the Ki tree is a container of nodes that support that 
interface.

* The Node struct provides the default impl of the Ki interface, and typically 
you don’t need to impl it again in a different way, so almost always new Node 
types will just put Node as an anonymous embedded type, and perhaps modify some 
part of the Ki api as needed.

Cheers,
- Randy



-- 
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] Cross platform native(no dependencies) GUI options.

[Randall O'Reilly]

wrt the compilation slowdown issue, the cgo code that I adapted from shiny in 
the “as native as you can reasonably get in Go" GoGi GUI 
(https://github.com/goki/gi) is certainly the slowest part of the build, but 
even so, it is a *tiny* fraction of the compilation time of Qt (which can take 
over an hour!).  Just a few secs.  Fast enough to not get distracted and start 
reading reddit or whatever.. :)  Btw it does use the xgb package for X under 
linux.

ps. I fixed the closing-the-windows bug in linux and added a font browser and a 
file viewer / chooser / dialog, so things are moving along with GoGi / GoKi — 
hoping to get to the rasterx integration very soon...

- Randy

> On May 27, 2018, at 5:26 PM, Tyler Compton  wrote:
> 
> I did a bit more research and found https://github.com/BurntSushi/xgb which 
> interacts with X directly without the need for C bindings, so it is possible 
> to at least open a window without any cgo. However, I don't know of a way 
> that you can have cross-platform accelerated graphics without using OpenGL, 
> which will require cgo. Unfortunately, I'm not sure if what you want is 
> really feasible, and if it is you may not be very happy with the results.
> 
> There are GUI libraries out there for Go that require cgo but support all 
> major platforms. What is it about cgo that you're hoping to avoid?
> 
> On Sun, May 27, 2018 at 2:57 PM  wrote:
> I just do not want it to have cgo and it should be perfect.
> 
> 
> On Sunday, May 27, 2018 at 2:55:06 PM UTC-7, Tyler Compton wrote:
> I'm not sure if it's actually feasible to write a GUI library without 
> external libraries. A GUI that runs Linux will need to interact with an X 
> server or a Wayland compositer, and the library will have to interact with 
> their APIs somehow.
> 
> On Sun, May 27, 2018, 14:19  wrote:
> Yeah, the ones suggested all use cgo though.
> 
> 
> On Sunday, May 27, 2018 at 2:08:17 PM UTC-7, Sebastien Binet wrote:
> There was very recently a thread about this on Reddit:
> 
> https://www.reddit.com/r/golang/comments/8m5icy/cross_platform_native_gui_library/
> 
> sent from my droid
> 
> On Sun, May 27, 2018, 22:51  wrote:
> Hello,
> 
> I would like you guys to suggest some GUI libraries that do not have any 
> HTML/CSS or C bindings, are cross platform and require no dependencies.
> 
> When I say native, I mean no dependencies. I do not mean native to the OS. 
> This would be great but I don't see any available that have no C bindings. I 
> understand that to create a native to the OS experience there must be calls 
> to the OS API which in most cases use the C language.
> 
> Before anyone asks why I do not want C bindings, it is because they do not 
> have good cross compilation support or good compile speeds.
> 
> Suggestions appreciated, Thanks so much!
> 
> 
> -- 
> 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...@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...@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.
> 
> -- 
> 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.

-- 
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: Generics as builtin typeclasses

[Randall O'Reilly]

The implicit nature of contracts seems like a major sticking point.  If you are 
writing something like 1 << t to express “unsigned integer” then it seems like 
it would obviously be more explicit to directly state “unsigned integer”.  
contracts look really elegant, powerful, and well-defined from the perspective 
of the *compiler*, but from the *end-user perspective*, they really seem very 
indirect and implicit.  Overall my sense is that Go puts a lot more value on 
the end user rather than the compiler..

WRT the objection of introducing a bunch of new keywords to explicitly specify 
what is otherwise indirectly specified by contracts, there is already a full 
explicit list of such things in the reflect.Kind type.  Could we not just use 
that directly?  Given that contracts are supposed to be relatively rare anyway, 
requiring the inclusion of reflect might be acceptable.  And this is 
well-understood and widely used already.

- Randy

> On Sep 8, 2018, at 7:10 PM, Rob Pike  wrote:
> 
> "A contract is a compile-time description of which types are permitted
> for a polymorphic function or type."
> 
> No, it's not. It's a collection of statement-like operations that must be 
> legally compilable, under restricted circumstances, by the type at the point 
> of instantiation, plus some special rules for cases that are hard to handle 
> that way. It's more of an illustration, an example, than a description. It's 
> implicit, roundabout, a little magical.
> 
> I'm not criticizing the design, although it might sound like that, but there 
> is a certain lack of precision, of indirection, that makes this harder than I 
> hope it might be. And the first place to be precise is in the language that 
> defines what these new concepts are.
> 
> -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.

-- 
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] Generic alternatives: new basic types?

[Randall O'Reilly]

Given all the challenges associated with generics, it might be productive to 
follow up on this alternative approach of identifying a (small set) of new 
primitive containers and functions that would otherwise have been written using 
generics, that are of sufficiently general applicability as to merit inclusion 
in Go2?  I know this kind of discussion is had frequently on this list, e.g., 
recently in the case of tuples and ternary expressions, and the outcome is 
usually a pretty convincing “not gonna happen”, but MAYBE in the light of the 
generics discussion there might be some fresh insights along these lines?

It seems like one of the fundamental reasons generics are so “contrary” for Go 
is that they require exposing a bunch of low-level internal special-case logic 
(e.g., operator semantics, etc) in a “meta” explicit way.  Doing so in a clean, 
simple, elegant way may be impossible.  The current Go1 alternative strategy is 
to bury all that logic well out-of-sight and provide a simple, elegant “magic” 
set of language primitives that seamlessly interoperate with all the other 
basic types.  For those things that are supported in this way, the result is 
pure joy and simplicity :)  So, a logical alternative to generics is to think 
about anything of sufficient generality that is missing, and just add it in 
with the same kind of existing magic.

Another way of framing the issue is: if you give people generics, they will 
each write the same kind of functionality in slightly different ways.  Instead, 
the “Go” way is to figure out the *best* way to do something, and build that 
right on into the language as a primitive, which fully interoperates and deals 
with all the necessary idiosyncrasies of the other types.  I doubt anyone would 
argue that the existing “minimal basis set” of functionality is truly minimal 
and truly covers the vast majority of needs.

The list of plausible additions is likely quite small, and the draft generics 
proposal suggests what most of these might be:

* binary trees (llrb?) — can anyone really argue AGAINST this?

* sets — really map[T]struct{} seems fine here — probably not worth it?

* linked lists??  probably not given llrb?  also I’ve written many stacks and 
they seem trivial and painless using slices..

* tensors (n-dimensional arrays) — this would be GREAT for numerical stuff — 
there is an existing heroic implementation https://github.com/gorgonia/tensor 
but a minimal core builtin support for the basic slice-level functionality 
extended to multiple dimensions would be really nice!  Here’s a proposal: 
https://go.googlesource.com/proposal/+/master/design/6282-table-data.md

Functions:

* insert() primitive for slices — I wasn’t able to find prior discussion of 
this, but this is the ONLY major pain point for me in dealing with slices — it 
is 3 repetitive, relatively opaque lines of code every time, and seems well 
worth the “investment” in a new keyword..  I did find some debate about whether 
delete() should operate on slices too — seems like that would be a simple 
semantic convenience that makes code more explicit and the counter-arguments 
from the previous debate weren’t that strong IMO 
https://grokbase.com/t/gg/golang-nuts/1366rkp7ef/go-nuts-why-not-provide-a-delete-function-in-slices-just-like-in-maps

* max(), min(), abs() — how about it?  these seem like the main focus of 
generics discussion, and are a “safe” special case form of the ternary 
operator.  When I first found out that there wasn’t a max operator for ints in 
Go I was really shocked.. I got over it, but still, these are really basic 
mathematical operators that I use all the time..

* most of the other examples in the generics proposal seem like such trivial 
one-liners (sorting, map / reduce, the various channel functions) that it 
doesn’t quite seem worth it…  

Anyway, that is really it for my list — if these were in the language, it would 
make my code easier and simpler to write and understand.  I’m not sure I could 
say the same for any of the existing generics proposals.. :)

- Randy

> On Sep 18, 2018, at 2:05 PM, Michael Jones  wrote:
> 
> I believe average Go code will be better if there are map-quality llrb trees, 
> stacks, sets, ... for the taking, just as if tuples were a first class thing. 
> There were horrors in STL's evolution, but by now, everyone gets such data 
> structures right the first time they use them, just as they do now with Go 
> 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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] ints, floats package with Inter and Floater, etc?

[Randall O'Reilly]

This seems like such an obvious idea, but I was unable to find prior discussion 
about it — it is probably at least implicit in various generics alternative 
proposals etc, but anyway, seems like it might be worth at least saying why 
this wouldn’t be useful to provide in standard packages?

Idea: If there were standard packages that provide basic interfaces akin to 
fmt.Stringer, for ints and floats (and all other basic types), with 
bidirectional conversion functions, might that go a long way toward filling 
some of the generics gaps?

e.g.: https://play.golang.org/p/v1S1IMigoy6

// in package ints

type Inter interface {
Int() int64
FromInt(val int64)
}

func Max(a, b Inter) int64 {
if a.Int() > b.Int() {
return a.Int()
}
return b.Int()
}

so you could write ints.Max(a,b) for anything supporting the Inter interface..  
Obviously a Less method would be avail, and could be used for a fully generic 
sort on slices where you check if the slice element type supports the interface 
(including Floater and Stringer), and it falls back on a big reflect.Kind 
switch in the worst case.  I just wrote this and it seems ugly but useful when 
you really don’t know what you’ve got, and having the interface allows you to 
use things like Time values etc, and is probably faster than fully 
reflect-based.

A similar Floater interface could be defined, maybe in math, and an entire 
generic version of the math library could be implemented as wrappers using the 
Floater interface — obviously a bit of runtime cost using the interface methods 
but seems like it would save a lot of casting and for non-performance-critical 
cases would probably be worth the cleaner code.

If this was all defined as a standard package, then basically every type with 
relevant int, float, etc semantics could be expected to have the relevant 
interface methods, just like virtually everything has a Stringer interface, and 
you could very easily deal with just about any relevant type by defining the 
relevant interface-based methods..

So anyway, what is the fatal flaw with this idea that I’m not seeing?

- Randy

-- 
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] [ANN] GoGi / Gide cross-platform GUI toolkit and IDE app

[Randall O'Reilly]

We are excited to finally announce the beta version of the GoGi cross-platform 
graphical interface toolkit (a preliminary announcement was made back in May), 
and the Gide IDE application written in it:

* https://github.com/goki/gi
* https://github.com/goki/gide

Given the recent discussion about the need for a pure Go GUI framework, anyone 
interested in that should take a serious look at this.  It is now fully 
functional and we are using it daily.  There are plenty of good examples in 
https://github.com/goki/gi/examples to demonstrate how it works and what it can 
do, but the best example is the Gide IDE framework, which is now fully usable 
as an editor for any kind of text editing need (and is what we’re now using for 
all further development), but is still missing e.g., an integrated debugger and 
various other planned features.

At this point, nobody can complain that there isn’t a full-featured, fully 
native cross-platform GUI framework written ENTIRELY in Go!  GoGi uses a 
heavily modified version of the Shiny backend drivers, and the Linux and 
Windows codebase is *pure* Go.  MacOS requires a minimal, single Objective-C 
file for the Cocoa hooks (compiled with cgo), but otherwise everything else is 
entirely in Go.  I’m pretty sure at this point that this is the only 
full-featured GUI framework that is entirely Go-native, without depending on 
some other C-based toolkit.

I have been a long-time user of Qt, and my entirely biased opinion is that GoGi 
is now competitive with it, and it compiles in seconds instead of hours!  
Anyone with an existing Qt-based app should be able to port to GoGi relatively 
easily, although we certainly didn’t constrain ourselves to anything like full 
API compatibility — we took full advantage of native Go design etc, and it 
should hopefully feel very natural to Go users.

There is lots more discussion of the design etc on the Wiki pages 
(https://github.com/goki/gi/wiki).

It is great that there are now multiple GUI efforts — that seems like a sign of 
a healthy ecosystem.  If others are interested in taking advantage of our mods 
to the Shiny backend drivers, that should be something that could be used for 
any kind of GUI framework, and ideally it would be great to not duplicate 
efforts on that front, as it is certainly the biggest PITA in the whole 
enterprise.  I really didn’t want to have to learn that much about Objective C, 
the Windows API, or the X11 xgb framework, all of which seem thoroughly 
horrible in comparison to Go :)  We would welcome any input / PR’s etc that 
would make this code work for others, and hopefully get some help maintaining 
and expanding things going forward...

Vis-a-vis the points Ian made about the incentives for making this kind of GUI: 
our approach, like in Shiny, was to have as minimal of OS-specific dependency 
as possible, and really just push bitmaps out and get UI events in. So this 
means that indeed everything will look identical across platforms, and to my 
eye it is certainly above-threshold in appearance for most users, and 
generic-enough that it probably your average user wouldn’t know or care what 
kind of framework it was written in.  As has been noted, the browser has become 
the app for so many use-cases that it probably isn’t that big of a deal to have 
a “native” GUI anymore.

And our goals and incentives are entirely non-comercial.  I am a neuroscientist 
who depends on interactive GUI frameworks for brain modeling (and for teaching 
this material), and obviously someone who just loves programming a bit more 
than is probably healthy — and John Rohrlich is a senior researcher in my lab 
with a similar profile.  So basically we don’t care about any of the commercial 
incentives, and have just become too frustrated with the state of C++ and Qt to 
continue down our previous path.  And we were due for a major reboot in our 
overall approach.  Also, frankly, this thing was partly therapy for the 
relatively horrible state of the world, and wanting to create the kind of 
beauty, elegance and perfection that can only exist in software :)

Go is such an amazing, elegant language, that it inspired the desire to create 
a GUI framework to match!  You can judge for yourselves if we got anywhere 
close, and everyone’s tastes and goals are different, but anyway hopefully some 
others will be able to take advantage of all this work, and we are very open to 
any further input, contributions, etc.  We certainly took advantage of lots of 
great work by others, particularly Nigel Tao’s great efforts on Shiny, image, 
and font rendering libraries; Steve Wiley’s rasterx package for SVG-based 
rendering, Michael Fogleman’s gg rendering library, and Alec Thomas’ chroma 
syntax highlighter.

Cheers,
- Randy

- Randy

-- 
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...@g

Re: [go-nuts] [ANN] GoGi / Gide cross-platform GUI toolkit and IDE app

[Randall O'Reilly]

Installing Gide will install all of GoGi in the bargain: 
https://github.com/goki/gide/wiki/Install

or follow the directions in: 
https://github.com/goki/gi/tree/master/examples/widgets

Basically, the “main” executable packages actually pull in all the 
dependencies, whereas the top-level paths don’t.  Otherwise, it is just a 
standard go get … kind of thing.

There was a recent update to chroma that does require `go get -u ./ …` if you 
already had that installed.

There are indeed many dependencies — looks like we will need to figure out vgo 
at some point soon so that the install is more reliable.  I just double-checked 
that AS OF RIGHT NOW a -u update allows everything to build, so if you get some 
kind of build error, please do the update and see if that doesn’t fix it.

- Randy

> On Nov 12, 2018, at 2:11 PM, Tharaneedharan Vilwanathan  
> wrote:
> 
> Hi Randy,
> 
> I have a quick question.
> 
> Is there installation procedure?
> 
> How do you install this? For example, this is what I get:
> 
> Tharaneedharans-Mac-mini-2:examples dharani$ go get github.com/goki/gi
> can't load package: package github.com/goki/gi: no Go files in 
> /Users/dharani/gopath/src/github.com/goki/gi
> 
> (this is my general question anyway when the packages give this output. In 
> such cases, are we supposed to use "git clone"?)
> 
> Also, it seems to have many dependencies. Any details on them?
> 
> Regards
> dharani
> 
> 
> On Mon, Nov 12, 2018 at 12:56 AM Randall O'Reilly  
> wrote:
> We are excited to finally announce the beta version of the GoGi 
> cross-platform graphical interface toolkit (a preliminary announcement was 
> made back in May), and the Gide IDE application written in it:
> 
> * https://github.com/goki/gi
> * https://github.com/goki/gide
> 
> Given the recent discussion about the need for a pure Go GUI framework, 
> anyone interested in that should take a serious look at this.  It is now 
> fully functional and we are using it daily.  There are plenty of good 
> examples in https://github.com/goki/gi/examples to demonstrate how it works 
> and what it can do, but the best example is the Gide IDE framework, which is 
> now fully usable as an editor for any kind of text editing need (and is what 
> we’re now using for all further development), but is still missing e.g., an 
> integrated debugger and various other planned features.
> 
> At this point, nobody can complain that there isn’t a full-featured, fully 
> native cross-platform GUI framework written ENTIRELY in Go!  GoGi uses a 
> heavily modified version of the Shiny backend drivers, and the Linux and 
> Windows codebase is *pure* Go.  MacOS requires a minimal, single Objective-C 
> file for the Cocoa hooks (compiled with cgo), but otherwise everything else 
> is entirely in Go.  I’m pretty sure at this point that this is the only 
> full-featured GUI framework that is entirely Go-native, without depending on 
> some other C-based toolkit.
> 
> I have been a long-time user of Qt, and my entirely biased opinion is that 
> GoGi is now competitive with it, and it compiles in seconds instead of hours! 
>  Anyone with an existing Qt-based app should be able to port to GoGi 
> relatively easily, although we certainly didn’t constrain ourselves to 
> anything like full API compatibility — we took full advantage of native Go 
> design etc, and it should hopefully feel very natural to Go users.
> 
> There is lots more discussion of the design etc on the Wiki pages 
> (https://github.com/goki/gi/wiki).
> 
> It is great that there are now multiple GUI efforts — that seems like a sign 
> of a healthy ecosystem.  If others are interested in taking advantage of our 
> mods to the Shiny backend drivers, that should be something that could be 
> used for any kind of GUI framework, and ideally it would be great to not 
> duplicate efforts on that front, as it is certainly the biggest PITA in the 
> whole enterprise.  I really didn’t want to have to learn that much about 
> Objective C, the Windows API, or the X11 xgb framework, all of which seem 
> thoroughly horrible in comparison to Go :)  We would welcome any input / PR’s 
> etc that would make this code work for others, and hopefully get some help 
> maintaining and expanding things going forward...
> 
> Vis-a-vis the points Ian made about the incentives for making this kind of 
> GUI: our approach, like in Shiny, was to have as minimal of OS-specific 
> dependency as possible, and really just push bitmaps out and get UI events 
> in. So this means that indeed everything will look identical across 
> platforms, and to my eye it is certainly above-threshold in appearance for 
> most users, and generic-enough that it probably your average user wouldn’t 
> k

Re: [go-nuts] Suggestions for layout/structure/coding-patterns for GUI applications in Go?

[Randall O'Reilly]

Tom,

One very common and seemingly effective structure is the tree / scenegraph, 
which is used in Qt and, as the DOM, in HTML, and lots of other places. GoGi 
https://github.com/goki/gi uses this, so you can see native Go examples there.  
In Qt and GoGi in particular, you leverage the Layout to do a lot of the work — 
just add elements to it, and let it organize the appearance, etc.  You can use 
the visitor and model / view patterns to operate on the scenegraph and keep the 
logic decoupled from the appearance..

GoGi makes extensive use of another efficient trick: separating the decisions 
about what gui elements to construct from the process of configuring those 
elements.  There can be a lot of complex conditional logic in deciding what you 
want to build — tying this up with all the additional logic to create and 
manage those elements results in major spaghetti.  To decouple these, a slice 
of type, name tuples is constructed dynamically via the relevant logic, and 
then after that point, everything is relatively clean and modular in switching 
etc on how to configure / manage whatever was ultimately built.  See e.g., the 
https://github.com/goki/gi/blob/master/gi/dialogs.go code that has many 
different ways to configure the “config” slice for a dialog..

- Randy

> On Jan 11, 2019, at 4:30 PM, Tom  wrote:
> 
> Hi!
> 
> TL;DR: GUI applications seems pretty hard to structure the code in a readable 
> way. Can anyone recommend any patterns/layout or suggestions to structuring 
> such a codebase and keeping it readable?
> 
> I wrote a GUI application in Go late at night once (using gotk3). I tried to 
> keep it readable by functionally decomposing methods, keeping as much private 
> as possible, and keeping different dialogs/windows etc in different packages 
> (each dialog/window was mapped to a struct).
> 
> Despite this, each struct quickly turned into existential spaghetti, with 
> 10-20 fields on each struct and over a dozen methods, with quite high 
> coupling.
> 
> I thought about trying to break down pieces into smaller components (like a 
> struct for a subset of fields on the page), but that seemed like more 
> boilerplate with still quite a bit of coupling.
> 
> So my question is this: How do you structure Go GUI programs? What patterns 
> work? Anything well-written & open-source I can learn from?
> 
> GUI programs seems particularly heinous compared to server or system 
> programs, which (at least to me) seem a lot easier to tease out parts & keep 
> them simple-looking.
> 
> Thanks & love,
> Tom
> 
> -- 
> 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.

-- 
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] Naming convention for accessor functions?

[Randall O'Reilly]

I’m trying to figure out the best convention for the basic function of 
accessing elements in a container (specifically in the context of GUI elements 
in the case of GoGi / GoKi https://github.com/goki/gi, and also in our new 
biological neural network simulator in Go: https://github.com/emer/emergent).

The key issue is that we have containers that return an interface, which the 
user then needs to convert into a particular type.  If you have multiple return 
values from the accessor, then you cannot do this conversion directly in one 
line.  Sometimes you know your access will succeed, and other times you don’t — 
if you’re unsure, you’ll be checking for failure anyway..

So, first of all, it seems like we need two methods, one with a single return 
value of the interface, and another with two return values (either an 
additional error or a bool — there is another question as to which..).  The 
native Go map accessor nicely gives you the option depending on how many 
variables you give it, but we don’t have that luxury with regular methods (Go2 
proposal??).

The question is: which method should be the “default” and which should be 
“marked” with an extra label, and what should that label be?

Option 1: fast, risky version is the default, use “Check / WErr / Safe” (or 
another better name?) for the safer version that returns an error.  E.g., when 
looking up an element by Name, you might have:

• ThingByName(name string) Thing
• ThingByNameCheck(name string) (Thing, error)  // or WErr (“with err”) or Safe 
or ??

Option 2: opposite:

• ThingByName(name string) (Thing, error)
• KnownThingByName(name string) Thing

I have used option 2 in GoGi / GoKi, and like the label “Known” as capturing 
the idea that you don’t need an error because you know it will work (although 
are there even better options?), but I also feel like I use the “Known” case 
more frequently, and therefore it should be the unmarked default, and provide 
the affordance for new users that they should generally use that version and do 
their conversions directly and efficiently, e.g., foo := 
Container.ThingByName(“foo”).(*Actual).

Thanks for any advice!

- Randy

ps. while I’m emailing, I just setup a google groups email list for anyone 
using GoGi / GoKi etc: https://groups.google.com/forum/#!forum/goki-gi — I’m 
planning to do a lot of work soon getting the 3D part of it working finally, 
and will email updates there — will be a fair bit of disruption for a while, 
though the 2D API should remain largely stable (also modulo the outcome if this 
discussion..)

-- 
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: Naming convention for accessor functions?

[Randall O'Reilly]

FWIW, John Rohrlich came up with “ThingByNameTry” and we’re going with that — 
seems perfect to me in terms of semantics, brevity, etc.. Also, having the 
extra “Try” modifier at the end is good so both methods show up together in 
alpha-sorted docs lists etc.  Cheers,

- Randy

> On Feb 3, 2019, at 9:26 PM, Randall O'Reilly  wrote:
> 
> I’m trying to figure out the best convention for the basic function of 
> accessing elements in a container (specifically in the context of GUI 
> elements in the case of GoGi / GoKi https://github.com/goki/gi, and also in 
> our new biological neural network simulator in Go: 
> https://github.com/emer/emergent).
> 
> The key issue is that we have containers that return an interface, which the 
> user then needs to convert into a particular type.  If you have multiple 
> return values from the accessor, then you cannot do this conversion directly 
> in one line.  Sometimes you know your access will succeed, and other times 
> you don’t — if you’re unsure, you’ll be checking for failure anyway..
> 
> So, first of all, it seems like we need two methods, one with a single return 
> value of the interface, and another with two return values (either an 
> additional error or a bool — there is another question as to which..).  The 
> native Go map accessor nicely gives you the option depending on how many 
> variables you give it, but we don’t have that luxury with regular methods 
> (Go2 proposal??).
> 
> The question is: which method should be the “default” and which should be 
> “marked” with an extra label, and what should that label be?
> 
> Option 1: fast, risky version is the default, use “Check / WErr / Safe” (or 
> another better name?) for the safer version that returns an error.  E.g., 
> when looking up an element by Name, you might have:
> 
> • ThingByName(name string) Thing
> • ThingByNameCheck(name string) (Thing, error)  // or WErr (“with err”) or 
> Safe or ??
> 
> Option 2: opposite:
> 
> • ThingByName(name string) (Thing, error)
> • KnownThingByName(name string) Thing
> 
> I have used option 2 in GoGi / GoKi, and like the label “Known” as capturing 
> the idea that you don’t need an error because you know it will work (although 
> are there even better options?), but I also feel like I use the “Known” case 
> more frequently, and therefore it should be the unmarked default, and provide 
> the affordance for new users that they should generally use that version and 
> do their conversions directly and efficiently, e.g., foo := 
> Container.ThingByName(“foo”).(*Actual).
> 
> Thanks for any advice!
> 
> - Randy
> 
> ps. while I’m emailing, I just setup a google groups email list for anyone 
> using GoGi / GoKi etc: https://groups.google.com/forum/#!forum/goki-gi — I’m 
> planning to do a lot of work soon getting the 3D part of it working finally, 
> and will email updates there — will be a fair bit of disruption for a while, 
> though the 2D API should remain largely stable (also modulo the outcome if 
> this discussion..)
> 

-- 
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] get Package from types.Type

[Randall O'Reilly]

I’m probably missing something very basic, but I have a go/types.Type and I 
want to find which package it was defined in.  I can get the path of the 
Package using TypeString but somehow I can’t seem to figure out how to get the 
*Package itself!  I can’t find a “lookup package by path” and LookupParent or 
my own attempt to crawl the Scope() hierarchy up and down doesn’t seem to be 
working.. Thanks,

- Randy

-- 
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: get Package from types.Type

[Randall O'Reilly]

nevermind - I think I figured it out — just need to drill down Underlying until 
you find types.Named and get the Obj().Pkg() from that.  Only Named types have 
a package home..

- Randy

> On Feb 16, 2019, at 12:51 AM, Randall O'Reilly  wrote:
> 
> I’m probably missing something very basic, but I have a go/types.Type and I 
> want to find which package it was defined in.  I can get the path of the 
> Package using TypeString but somehow I can’t seem to figure out how to get 
> the *Package itself!  I can’t find a “lookup package by path” and 
> LookupParent or my own attempt to crawl the Scope() hierarchy up and down 
> doesn’t seem to be working.. Thanks,
> 
> - Randy
> 

-- 
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] Good metaphor for differentiating Go from other languages?

[Randall O'Reilly]

On the topic of “selling” the advantages of Go vs. other languages such as 
Python and C++, has anyone used the metaphor of other products that strongly 
emphasize clean, elegant design, such as Apple hardware (I wouldn’t make this 
case about their software, given the nature of objective-C and Swift), the 
Tesla cars, and other such “icons” of modern design?  It just occurred to me 
that this might be a powerful way to relate in one simple way what it is that 
people find so appealing about Go.  By comparison, every other language is 
clunky and ugly, etc..

e.g., I could imagine someone writing something like this:
https://www.smithsonianmag.com/arts-culture/how-steve-jobs-love-of-simplicity-fueled-a-design-revolution-23868877/

about Go vs. other programming languages, and in the process, really 
communicating the essence of what is so great about the language in a way that 
people can tangibly understand.  I see so many discussions and 
misunderstandings about Go being “kinda like C” and that is just so far from 
the mark.

Rob Pike’s talk: 
https://talks.golang.org/2015/simplicity-is-complicated.slide#1 makes all these 
points of course, very compellingly, but I wonder if adding the simple point 
“Go is the Bauhaus of programming languages" as a kind of tag-line.  The 
practical problem is that many people probably don’t know Bauhaus anymore, and 
saying “Go is the Apple of programming languages” has all kinds of issues...  
Tesla?  Steve Jobs instead of Apple?

- Randy

-- 
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] is it possible to run cgo -buildmode=c-shared dynamic library on main thread?

[Randall O'Reilly]

I’m building a shared library of Go code that is loaded as a module by python, 
and called from there.  Somehow, I need to ensure that one particular function 
is called on the main thread (Mac OS cocoa gui event loop code requires this).  
I tried adding an init() function in the library and called 
runtime.LockOSThread() there, but that didn’t work (docs say it should, but 
presumably that doesn’t apply to the dynamic lib situation).  Thanks,

- Randy

-- 
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] is it possible to run cgo -buildmode=c-shared dynamic library on main thread?

[Randall O'Reilly]

Kurtis — thanks for the suggestion — I had assumed that python always just runs 
in the main thread, and when I added this code to my python script, it shows 
that it is indeed running in the main thread:

import threading
if threading.current_thread() is threading.main_thread():
print("running in main thread!”)

after much searching, I can’t find anything suggesting that python spawns a new 
thread when calling dlopen to load the library, but I also am not sure that it 
doesn’t.. if it doesn’t then that puts the ball back into Go’s court — can 
anyone who knows the guts of this stuff comment about whether it might have 
something that automatically avoids the main thread when running as a library?? 
 Thanks,

- Randy

> On Feb 25, 2019, at 11:49 AM, Kurtis Rader  wrote:
> 
> On Mon, Feb 25, 2019 at 1:56 AM Randall O'Reilly  wrote:
> I’m building a shared library of Go code that is loaded as a module by 
> python, and called from there.  Somehow, I need to ensure that one particular 
> function is called on the main thread (Mac OS cocoa gui event loop code 
> requires this).  I tried adding an init() function in the library and called 
> runtime.LockOSThread() there, but that didn’t work (docs say it should, but 
> presumably that doesn’t apply to the dynamic lib situation).  Thanks,
> 
> You have to ensure you only call the function from the python main thread. 
> See 
> https://stackoverflow.com/questions/23206787/check-if-current-thread-is-main-thread-in-python
>  for how to do that. Using LockOSThread() only works if you call your Go 
> service loop function from the python main thread. You can't use it to force 
> your Go function to run on the main thread when called from a non-main thread.
>  
> -- 
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] is it possible to run cgo -buildmode=c-shared dynamic library on main thread?

[Randall O'Reilly]

digging into the source code in runtime/cgo/callbacks.go, suggests that indeed 
it does spawn a new thread for starting up the library (see code below).  Thus, 
the solution was to just call the initialization for the gui thread *after* the 
library has been loaded and initialized, which indeed is from the main thread.  
Now all I need to do is to figure out how to get python to keep running in a 
separate thread while its main thread is blocked in the event loop from which 
it never returns.. 

- Randy

// Creates a new system thread without updating any Go state.
//
// This method is invoked during shared library loading to create a new OS
// thread to perform the runtime initialization. This method is similar to
// _cgo_sys_thread_start except that it doesn't update any Go state.

//go:cgo_import_static x_cgo_sys_thread_create
//go:linkname x_cgo_sys_thread_create x_cgo_sys_thread_create
//go:linkname _cgo_sys_thread_create _cgo_sys_thread_create
var x_cgo_sys_thread_create byte
var _cgo_sys_thread_create = &x_cgo_sys_thread_create

// Notifies that the runtime has been initialized.
//
// We currently block at every CGO entry point (via _cgo_wait_runtime_init_done)
// to ensure that the runtime has been initialized before the CGO call is
// executed. This is necessary for shared libraries where we kickoff runtime
// initialization in a separate thread and return without waiting for this
// thread to complete the init.

//go:cgo_import_static x_cgo_notify_runtime_init_done
//go:linkname x_cgo_notify_runtime_init_done x_cgo_notify_runtime_init_done
//go:linkname _cgo_notify_runtime_init_done _cgo_notify_runtime_init_done
var x_cgo_notify_runtime_init_done byte
var _cgo_notify_runtime_init_done = &x_cgo_notify_runtime_init_done


> On Feb 25, 2019, at 8:13 PM, Kurtis Rader  wrote:
> 
> On Mon, Feb 25, 2019 at 6:03 PM Randall O'Reilly  wrote:
> Kurtis — thanks for the suggestion — I had assumed that python always just 
> runs in the main thread, and when I added this code to my python script, it 
> shows that it is indeed running in the main thread
> 
> I probably assumed too much when reading your original problem statement. 
> Python code always run in the main thread, as far as I know, unless you have 
> used the `threading` module, either directly or indirectly, to spawn 
> additional threads. The wording of your original problem statement implied 
> you were calling a Go function from python. In which case that Go function 
> should execute on the main thread if you haven't explicitly created 
> additional threads from the main python thread. But you can't assume that 
> loading your Go module from the python main thread will ensure the Go 
> functions execute on the main thread.
> 
> I've worked a lot with C++ code that utilizes threads and which is loaded by 
> a python program. But that doesn't involve anything like the Go M:N go 
> routine to thread scheduler. There are probably subtleties in mixing the two 
> languages that I'm not familiar with.
> 
> -- 
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Implementing an EventBus in Go

[Randall O'Reilly]

for reference, here is a very basic Qt-style signal / slot style subscribe / 
publish model in Go, just using a map of receivers and their receiver callback 
functions:
https://github.com/goki/ki/blob/master/ki/signal.go

- Randy

> On Mar 10, 2019, at 11:07 PM, Kasun Vithanage  wrote:
> 
> Yes, when a publisher publish for a topic it should be routed to all 
> subscribers to that topic :)
> 
> On Monday, March 11, 2019 at 10:28:17 AM UTC+5:30, Burak Serdar wrote:
> On Sun, Mar 10, 2019 at 10:41 PM Kasun Vithanage  wrote: 
> > 
> > Hi all, 
> > 
> > I've experience implementing event buses in Java. 
> > In Java, I used a singleton where I can register callbacks to methods and 
> > fire event from a publisher(maybe from another thread) and propagate it to 
> > subscribers. 
> > 
> > In Go what would be the best pattern to implement a pub/sub event bus? 
> > Are channels are a better choice than using callbacks in this scenario(one 
> > to many event propagation)? 
> 
> Are you talking about the event listeners in Java where all listeners 
> are called synchronously? You can't use channels for something like 
> this, and a list of callbacks would be the simplest solution. But you 
> mentioned you might be calling listeners in another thread. Do you 
> need a synchronous call where publish() will make sure all subscribers 
> get the event? If so, maybe you can use a mix of channels and 
> callbacks. You can keep a list of callbacks for listeners in the same 
> goroutine, and a list of channels for listeners in other goroutines, 
> and call/write to elements of both list. 
> 
> > Or callbacks are better for this? 
> > 
> > (I need to propagate events only to subscribers of the topic) 
> > 
> > Regards, 
> > Kasun 
> > 
> > -- 
> > 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...@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.

-- 
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] Proposal to add Index operator methods

[Randall O'Reilly]

Those are good points and FWIW I would be excited to use the proposed indexing 
functions and agree that they are a big part of the issue, independent of the 
operator overloading.  There has been a lot of discussion about supporting 
multidimensional indexing etc so this has been a major issue over the years, so 
maybe this will go forward!

- Randy

> On Oct 8, 2020, at 2:18 AM, Raanan Hadar  wrote:
> 
> So the first paragraph in my answer to Jon addresses this. But I think I 
> could have been clearer: I think 80% of the readability problem is addressed 
> by index operator methods, which is the critical part. Full operator 
> overloading is nice to have in my opinion and I argue people will gladly live 
> without it given all the other benefits Go brings to the table in software 
> engineering. I think its a very similar approach to what Go did with 
> pointers: Is full pointer arithmetic beneficial? yes, but it would no longer 
> be in the spirit of Go.
> 
> I think that using languages such as Matlab and Python as a starting point, 
> or "prototyping languages" is becoming less and less relevant today. This 
> might have been the way we developed algorithms ten years ago but today its 
> just like any software development. The reality many data scientists and 
> engineers face today is that data pipelines are constantly changing and 
> increasing in complexity. They need to be maintainable and allow for quick 
> iteration, integration and deployment. These are the qualities that Go excels 
> at. A language that can effectively achieve a prototype in 80% the syntax 
> efficiency but can sustain quality over time  is much more important than 
> having the richest syntax possible. Another point is that even while in the 
> "prototyping" phase, big data challenges which data scientist face today, 
> unlike ten years ago, will require the data scientist to do some heavy 
> lifting to get efficient compute, network and IO to get that initial result. 
> So in many cases the "prototype" is often a complex pipeline that is deployed 
> in k8s for example. 
> 
> I think that a Go-Python integration is excellent but as I noted, it leaves a 
> lot to be desired. A lot has been written about the "infinite loop of 
> sadness" (here is a good link: 
> https://medium.com/pachyderm-data/sustainable-machine-learning-workflows-8c617dd5506d).
>  I think this is a big problem with companies like Google having an excellent 
> understanding of challenges of sustaining data pipelines at scale. Its a lot 
> of what they do in their day to day. This is why, I think the synergy in a 
> single language will be amazing.
> 
> As for Julia, I was also excited when I first learned about it and I hope I 
> am not offending anyone using Julia here. Because on paper its marketed as 
> the killer language for this, but Julia has two big problems (I sample Julia 
> regularly):
> 1. Julia is nowhere near ready. Julia has a few more years before it gets its 
> basics down. I think it has made a lot of progress in the last few years but 
> someone trying Julia out in 2020 is guaranteed to hit some really annoying 
> hurdles from day one. I'll give you a trivial example, lets say you want an 
> IDE for Julia. Your best bet today is probably a text editor like vim or 
> emacs. You have JUNO for atom which is nice but no longer developed or the 
> vscode IDE, which might be amazing in a few years but is far from stable 
> (https://github.com/julia-vscode/julia-vscode/issues). And this is just one 
> critical issue out of many.
> 2. My second issue with Julia is more troublesome because unlike the first, I 
> don't think it will ever be solved. Julia is a language that was designed to 
> be very rich syntax and feature wise. But its toolchain was completely 
> neglected. Go has an amazing toolchain, its not the sexiest part of the 
> language, but its critical and it was designed to encourage good software 
> engineering. As Rob Pike said: "Although tools like these are rarely 
> mentioned in the context of language design, they are an integral part of a 
> language's ecosystem and the fact that Go was designed with tooling in mind 
> has a huge effect on the development of the language, its libraries, and its 
> community". Julia has poor package management and tooling which make it a 
> pain to deploy in production compared to Go.
> 
> In summary, If Go were to implement this, I really believe that it will run 
> circles around Julia even in a few years from now when it reaches puberty. 
> Because Go is a better language when it comes to software engineering.
> On Thursday, October 8, 2020 at 7:46:16 AM UTC+3 rcore...@gmail.com wrote:
> I think we all agree that Python has some major issues.. :) 
> 
> But the point of Jon's argument which struck me as very compelling is that Go 
> would really need full operator overloading to serve as a serious competitor 
> given the standards to which people have become accustomed. I didn't see in 
> your 

Re: [go-nuts] Go Create

[Randall O'Reilly]

There's also this:  https://github.com/golang/go/issues/37755 -- just retain 
GOPATH mode

Although, now that I've been using modules more, and my various interdependent 
packages are more stable, I am more sympathetic to something like #26640 
instead of retaining GOPATH.  Anyway, having SOME kind of good solution to this 
distributed workflow scenario would be great!

- Randy

> On Jan 13, 2021, at 5:53 AM, Wojciech S. Czarnecki  wrote:
> 
> Dnia 2021-01-13, o godz. 07:22:52
> Rob Pike  napisał(a):
> 
>> Also, one must be sure to remove the replace directive before
>> releasing the code, which is an easy detail to forget.
> 
> I'd humbly summon https://github.com/golang/go/issues/26640 here.
> Opened at the modules advent, still it sees no love from the Team.
> 
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
> 
> -- 
> 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/20210113145309.61f42301%40xmint.

-- 
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/E8444AA8-9139-4E57-BC78-44D9A56A0840%40gmail.com.

Re: [go-nuts] `go list` across multiple modules?

[Randall O'Reilly]

Is the slowness here related to https://github.com/golang/go/issues/29427 ?  
I'm not sure the earlier fix for that actually fixed the issues I was having 
(and the issue remains open) -- I need to do more research for my situation, 
but just in case this might be another reason to revisit the slowness factor 
there..

- Randy

> On Jan 15, 2021, at 3:43 PM, 'Tim Hockin' via golang-nuts 
>  wrote:
> 
> On Fri, Jan 15, 2021 at 2:17 PM Jay Conrod  wrote:
>> 
>> I was initially going to suggest adding the module subdirectories as 
>> requirements to the main go.mod, then replacing those with the 
>> subdirectories.
>> 
>> module example.com/m
>> 
>> go 1.15
>> 
>> require (
>>  example.com/other1 v0.0.0
>>  example.com/other2 v0.0.0
>>  example.com/m/submod v0.0.0
>> )
>> 
>> replace (
>>  example.com/other1 => ./staging/src/example.com/other1
>>  example.com/other2 => ./staging/src/example.com/other2
>>  example.com/m/submod v0.0.0 => ./submod
>> )
>> 
>> 
>> I think you might have tried this already. It gives the same "main module 
>> ... does not contain package" error. I believe that's a bug. I've opened 
>> #43733 to track it.
> 
> Interesting.  If that's a bug, then maybe I'll be able to do what I
> need once fixed.
> 
>> In general, it should be possible to give 'go list' an absolute or relative 
>> path (starting with ./ or ../) to any directory containing a package which 
>> is part of any module in the build list. For example, some tools list 
>> directories in the module cache to find out what package a .go file belongs 
>> to.
>> 
>> As a workaround, you could put a go.mod in an otherwise empty directory (in 
>> /tmp or something), then require the relevant modules from the repo and 
>> replace them with absolute paths. Then you can run 'go list' in that 
>> directory with absolute paths of package directories.
> 
> Interesting - is the difference the absolute paths vs relative?
> 
> I hoped maybe `-modfile` would do the same trick, but alas not:
> 
> ```
> $ (cd /tmp/gomodhack/; go list /tmp/go-list-modules/submod/used/)
> example.com/m/submod/used
> 
> $ go list --modfile /tmp/gomodhack/go.mod /tmp/go-list-modules/submod/used/
> main module (tmp) does not contain package tmp/submod/used
> ```
> 
> It also fails some cases:
> 
> ```
> (cd /tmp/gomodhack/; go list /tmp/go-list-modules/submod/used/)
> example.com/m/submod/used
> thockin@thockin-glaptop4 go-list-modules main /$ (cd /tmp/gomodhack/;
> go list /tmp/go-list-modules/staging/src/example.com/other1/used/)
> go: finding module for package 
> example.com/m/staging/src/example.com/other1/used
> cannot find module providing package
> example.com/m/staging/src/example.com/other1/used: unrecognized import
> path "example.com/m/staging/src/example.com/other1/used": reading
> https://example.com/m/staging/src/example.com/other1/used?go-get=1:
> 404 Not Found
> ```
> 
> It seems that is because the "main" (top-level dir) go.mod has
> `replace` directives with relative paths, which kubernetes really
> does.
> 
>> Incidentally, golang.org/x/tools/go/packages will call 'go list' under the 
>> hood in module mode. go/build might do the same, depending on how it's 
>> invoked. 'go list' may be the best thing to use if it gives the information 
>> you need.
> 
> Yeah, I noticed.  When GO111MODULE=off, everything I am doing is much
> faster.  I'm wary of depending on that forever, though.
> 
> Stepping back, I fear I am pushing the square peg into a round hole.
> Let me restate what I am trying to do.
> 
> I want to run a slow codegen process only if the packages it depends
> on have ACTUALLY changed (mtime is a good enough proxy) and I don't
> know a priori which packages need codegen.  I want to scan the file
> tree, find the files that need codegen, check their deps, and only
> then run the codegen.
> 
> We do this today with `go list` and GO111MODULE=off, but I was advised
> at some point that x/tools/go/packages was the future-safe approach.
> 
> If there's a better way, I am all ears.
> 
> Tim
> GO111MODULE=off
>> On Fri, Jan 15, 2021 at 11:59 AM 'Tim Hockin' via golang-nuts 
>>  wrote:
>>> 
>>> Hi.  This isn't exactly burning urgent, but it is a long-term issue
>>> for Kubernetes.  If there's anything I can do to catalyze the
>>> discussion - tests to run, info to dig up, etc - please let me know.
>>> 
>>> On Wed, Dec 23, 2020 at 10:48 AM Tim Hockin  wrote:
 
 Hi Paul!
 
 On Wed, Dec 23, 2020 at 4:23 AM Paul Jolly  wrote:
> 
>> I just can't figure out how to do this.  Maybe it can't be done in `go
>> list` ?  Or maybe we're just missing some detail of go modules..
> 
> go list operates in the context of a single module (in the mode you
> are interested in), so you cannot do this with a single command across
> multiple modules.
 
 This might be a real problem for us.  For this post I am reducing it
 to `go list`, but in actuality we have a small program that we wrote
 which does what we ne

[go-nuts] [ANN] GoGi, Gide, emergent version 1.0

[Randall O'Reilly]

The GoGi GUI system https://github.com/goki/gi has now been released at version 
1.0 -- the 3D framework is now in place and interoperates with the 2D framework 
(including embedding 2D in 3D scenes), and everything is working reliably so we 
can keep the API stable from this point onward.  There are lots examples and 
further docs on github.

The Gide IDE https://github.com/goki/gide, which serves as a kind of continuous 
testing system for GoGi, is also significantly updated and now fully 
functional, including a GUI debugger interface to delve, good completion & 
lookup for Go, git log, diff, blame views, etc.

And if you're interested in learning about biologically-based neural network 
models of the brain, the emergent package https://github.com/emer/emergent is 
the main driver for all this stuff, especially the need for an integrated 2D 
and 3D GUI.  We've now survived a few different undergrad classes with this 
system, so it has been reasonably well stress-tested.

The emer repository also has etable: https://github.com/emer/etable which 
provides a pandas / xarray (Python) like data table / frame based on 
row-aligned tensor columns, which could be of general use -- it implements 
Apache Arrow Table and gonum matrix interfaces, and provides GUI interfaces for 
table data and an interactive GUI wrapper around gonum plots, along with lots 
of other standard data management functionality.

Finally, both GoGi and emergent can be accessed through python via 
https://github.com/go-python/gopy -- this allows Go to be a nice "backend" to 
python scripts, which automatically gain full access to the entire Go-based API 
-- the next step here is to write a Go-to-Python translator to more easily 
support python users for final main-package code...

- Randy

-- 
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/0BC0F05B-135D-4E67-B6E3-9C0A3F48%40gmail.com.

Re: [go-nuts] Need a way to check only key exist or not? without value?

[Randall O'Reilly]

I think map[string]struct{} takes no storage for the value and is the most 
efficient way to do this.

- Randy

> On Apr 27, 2020, at 7:20 PM, Shishir Verma  wrote:
> 
> I think the idiomatic way to implement a set in golang is to use a map with 
> bool values. Here is an example from effective go documentation:
> 
> 
> attended := map[string]bool{
> "Ann": true,
> "Joe": true,
> ...
> }
> 
> if attended[person] { // will be false if person is not in the map
> fmt.Println(person, "was at the meeting")
> }
> 
> 
> 
> On Monday, 27 April 2020 22:16:20 UTC+5:30, adithya...@gmail.com wrote:
> Basically i need a slice with indexed values, so that i can check only 
> existence.
> or a map with only keys?
> How it can be done?
> 
> -- 
> 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/1201e6f3-621e-4875-9374-d7713fa7d8aa%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/6B2E6C64-4B49-48B2-95C3-FFA2852916EE%40gmail.com.

Re: [go-nuts] Image Resize and Crop

[Randall O'Reilly]

https://github.com/anthonynsimon/bild has parallel image ops of all sorts and 
is widely used & well supported.

- Randy

> On May 10, 2020, at 9:52 PM, robert engels  wrote:
> 
> I don’t know and I doubt anyone else does off the top of their head, so why 
> don’t you write a test and see?
> 
> Image processing is highly image and usage dependent, e.g. acceptable quality 
> vs. speed vs. memory.
> 
> Using non-quantifiable terms like “huge” is not testable nor verifiable.
> 
>> On May 10, 2020, at 9:50 PM, Vivi  wrote:
>> 
>> 
>> How does it compare to vipsthumbnail that utilize low memory usage which I 
>> believe it use horizontal threading, does Go's image/draw package consume 
>> large memory if the image source is huge?
>> 
>> 
>> On Monday, 11 May 2020 07:00:11 UTC+8, Nigel Tao wrote:
>> On Mon, May 11, 2020 at 4:28 AM robert engels  wrote: 
>> > All of the code to do scaling and cropping in the ‘image’ package in the 
>> > stdlib. 
>> 
>> Cropping is in the stdlib but scaling is not. Various scaling 
>> algorithms (e.g. nearest neighbor, Catmull-Rom) are in the 
>> golang.org/x/image/draw package instead. As 
>> https://godoc.org/golang.org/x/image/draw says, "This package is a 
>> superset of and a drop-in replacement for the image/draw package in 
>> the standard library". 
>> 
>> https://godoc.org/golang.org/x/image/draw#example-Draw has some example 
>> code. 
>> 
>> -- 
>> 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/b0443e9a-3edb-4bcb-b056-f11186188eb9%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/4ECA0CE7-D503-4331-84CC-80EF1A85FB0B%40ix.netcom.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/5FC5A709-67C6-4CD5-A64C-6EA91454%40gmail.com.

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

[Randall O'Reilly]

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.orgWork: 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/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 
https://groups.google.com/d/msgid/golang-nuts/39076902-CF66-4EEF-B541-5C47DF79454F%40gmail.com.

[go-nuts] [generics] Simplification: Methods refer to original type parameters instead of re-specifying each time

[Randall O'Reilly]

You could save a fair amount of typing and eyestrain by not replicating the 
type params for types, in their methods:

type Vector(type T) []T

func (v *Vector) Push(x v.T) { *v = append(*v, x) }



type Map(type K, V) struct {
root*node(K, V)
compare func(K, K) int
}

func (m *Map) InOrder() *Iterator(m.K, m.V) {
type kv = keyValue(m.K, m.V) // convenient shorthand
sender, receiver := chans.Ranger(kv)()
var f func(*node(m.K, m.V)) bool
...
}

Could also just have the bare type param name without the field-like specifier 
(e.g., K, V instead of m.K, m.V) but that makes it less obvious what K and V 
are -- m.K makes it clear that K is something I can find if I look at the 
definition of the type of m.

This also enforces consistent naming of type parameters across all methods.

- Randy

-- 
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/2605713E-73F3-4332-911D-D41EAE4DAF6A%40gmail.com.

Re: [go-nuts] [generics] Simplification: Methods refer to original type parameters instead of re-specifying each time

[Randall O'Reilly]

Good point!

I can think of 2 possible (non-mutex) solutions:

* Use an explicit type expression to refer to the type: `type(ms.T)` and the 
field is just `ms.T`

* Within the method scope, make `T` a valid type name, so you can just use `T` 
directly -- this might even be preferable overall as it is simpler, and should 
be clear what you're referring to in that context.  May still need `ms.T` and 
`type(ms.T)` variants to refer to the type parameters outside of the method 
scope (being able to do so might make some type linkages across interface types 
simpler -- haven't worked that through at all..)

- Randy

> On Jun 17, 2020, at 11:03 AM, Tyler Compton  wrote:
> 
> I think this syntax could get confusing when embedded fields is added to the 
> mix:
> 
> type MyStruct(type T) struct {
> T
> }
> 
> func (ms *MyStruct) MyMethod(t ms.T) {
> ms.T =  t
> }
> 
> In this example. ms.T means two very different things depending on where they 
> are used.
> 
> On Wed, Jun 17, 2020 at 3:45 AM Randall O'Reilly  wrote:
> You could save a fair amount of typing and eyestrain by not replicating the 
> type params for types, in their methods:
> 
> type Vector(type T) []T
> 
> func (v *Vector) Push(x v.T) { *v = append(*v, x) }
> 
> 
> 
> type Map(type K, V) struct {
> root*node(K, V)
> compare func(K, K) int
> }
> 
> func (m *Map) InOrder() *Iterator(m.K, m.V) {
> type kv = keyValue(m.K, m.V) // convenient shorthand
> sender, receiver := chans.Ranger(kv)()
> var f func(*node(m.K, m.V)) bool
> ...
> }
> 
> Could also just have the bare type param name without the field-like 
> specifier (e.g., K, V instead of m.K, m.V) but that makes it less obvious 
> what K and V are -- m.K makes it clear that K is something I can find if I 
> look at the definition of the type of m.
> 
> This also enforces consistent naming of type parameters across all methods.
> 
> - Randy
> 
> -- 
> 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/2605713E-73F3-4332-911D-D41EAE4DAF6A%40gmail.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/3CC5CE67-BE33-40B4-9C84-371ADD69D729%40gmail.com.

Re: [go-nuts] [generics] Generic functions calls little confusing to readers

[Randall O'Reilly]

Here's a proposal for a syntactic modification to the draft proposal that 
removes explicit type parameters from functions, and just uses generic types 
directly (e.g., the new interface types): 
https://github.com/golang/go/issues/39669

This would go a long way toward simplifying the syntax and avoiding most of the 
worst issues with parens, while otherwise being essentially identical to the 
draft proposal.

Here's a sample:

// draft proposal
func StrAndPrint(type L interface{}, T Stringer)(labels []L, vals []T) { ... }

// GT proposal
func StrAndPrint(labels []type, vals []Stringer) { ... }

you just use the generic types like any other existing types!  `type` can be 
used for an unconstrained generic type -- otherwise you use the generic 
interface type for constrained types.

- Randy

> On Jun 17, 2020, at 4:45 PM, google via golang-nuts 
>  wrote:
> 
> On Wednesday, 17 June 2020 07:54:02 UTC+10, Alexander Morozov wrote:
> I wonder how could we avoid this confusion (apart from using different 
> brackets :)).
> 
> I know the brackets discussion has been had before, and that there are some 
> technical, and non-technical reasons why parentheses were settled on, but 
> this really illustrates the limitations of relying on a single delimiter for 
> everything. Even in function declarations, where it's most clear what's 
> intended, there is a significant cognitive load placed on the  reader to 
> determine what's happening, possibly involving backtracking to a previous set 
> of parens. I think underestimating the impact of the syntax on reading 
> comprehension would be a grave mistake, and I strongly believe that the 
> proliferation of parens hurts here.
> 
> This second draft removes some other concerns that I had with the contracts 
> design, but this syntax issue has stuck out to me as problematic since the 
> start, and I can't shake it.
> 
> -- 
> 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/f1699384-f487-44a4-b8d6-17950b2c4913o%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/E5F0CAFF-3086-4345-A4CD-840A673B21AE%40gmail.com.

[go-nuts] mark pointer methods on interface type definitiion, not function?

[Randall O'Reilly]

Would it make sense to mark the methods requiring pointer receiver types on the 
interface definition, instead of on the function type parameters? It seems more 
logical given that this should be a general property of the semantics of the 
interface method in question, and not something each function should have to 
deal with separately.

>From the example in the draft proposal:

// Setter is a type constraint that requires that the type
// implement a Set method that sets the value from a string.
// Further, the Set method must take a pointer receiver.
type Setter interface {
*Set(string)
}

The * marks this method as requiring a pointer receiver.  This constraint can 
thus be enforced generically for any type up front at constraint-checking time.

A function using this interface constraint would just have a regular 
non-pointer type:

func FromStrings(type T Setter)(s []string) []T { ... }

- Randy

-- 
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/3AE909EC-AA38-4ECF-8F25-FE34D898C6FD%40gmail.com.

Re: [go-nuts] Generics and parentheses

[Randall O'Reilly]

Tagging onto this point: while Go deviates from other languages in a number of 
important ways, syntax at the level of things like parens, brackets, etc is not 
one of these key differences.  It is almost entirely consistent with the "de 
facto" C-style choices in this respect (to the extent that people mistakenly 
regard it as just a subset of C).  In this context, it does seem a bit of 
"being different for its own sake", to adopt something *other* than the < > 
convention for generic types.

Yes, Go should boldly Go where no language has gone before^*, but when it is 
basically adopting a well-established paradigm widely used in existing 
languages, doesn't it also make sense to adopt the well-established syntax 
associated with that paradigm? (although the proposed Go generics differ in 
some important ways from other languages, the use of type parameters is not one 
of them.)

While we've been asked to focus on the more "objective" facts of parsing 
considerations here, the above logic would suggest a different approach: if 
there is any way to adopt the established conventional syntax and make the 
parsing work, then that is what should be done.  So, essentially, this puts the 
onus back on the parser programmers to definitively *rule out* the use of < > 
-- is it really that difficult / costly to do a bit of look-ahead and 
disambiguate the different use cases? 

- Randy

* e.g., see https://github.com/golang/go/issues/39669 for a more radical 
departure from convention, doing away with the extra parens entirely.

> On Jul 14, 2020, at 9:45 PM, robert engels  wrote:
> 
> My opinion is that every major language (no flames please… lots of developers 
> write lots of programs and make money doing it) that supports generics uses < 
> > for generic types, so Go should too - since there is no reason to deviate 
> from this other than to avoid changes to the parser. Seems better to pay this 
> cost once - rather than every Go program that uses generics being harder to 
> read for eternity (especially for those readers that use a lot of languages).
> 
>> On Jul 14, 2020, at 11:13 PM, Ian Lance Taylor  wrote:
>> 
>> On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W.  
>> wrote:
>>> 
>>> This feels a little better, but honestly I'm still all for angle brackets 
>>> or like Watson suggested, guillamets.
>>> 
>>> fn(T1)(fn2(T2)(fn3(T3)(v))) // 1
>>> fn[T1](fn2[T2](fn3[T3](v))) // 2
>>> fn(fn2(fn3(v))) // 3
>>> fn«T1»(fn2«T2»(fn3«T3»v)))  // 4
>>> 
>>> To me, with a background in C++ and Typescript and a little bit of Rust, #3 
>>> and #4 are just natural and easier to read.
>> 
>> The advantage of parentheses is that the language already uses
>> parentheses for lists in various places.  Of course that is also the
>> disadvantage.
>> 
>> When considering something other than parentheses, I encourage people
>> to look for objective reasons why one syntax is better than another.
>> It's going to be different from other aspects of the language.  So
>> what reason would we have for preferring one syntax over another?
>> 
>> For example:
>> 
>> Robert already gave reasons why square brackets are better than angle 
>> brackets.
>> 
>> The disadvantage of guillemets is that they are hard to type on many
>> keyboards.  So to me either square brackets or angle brackets would be
>> better than guillemets.
>> 
>> The disadvantage of a two character sequence such as <: :> is that it
>> is more typing.  So again either square brackets or angle brackets
>> seem to me to be better.
>> 
>> An example of a reason that square brackets might be a poor choice
>> would be ambiguous parsing, or cases where the code is harder to read.
>> 
>> It's true that some other languages use angle brackets, but Go already
>> does many things differently.  That is only a minor advantage for
>> angle brackets.  To me at least it does not outweigh the
>> disadvantages.
>> 
>> In short, please try to provide reasons for a different syntax.  "It
>> looks good" is a valid reason, but please try to explain why it looks
>> better than square brackets or parentheses.
>> 
>> Thanks.
>> 
>> 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/CAOyqgcX-OXktNtUs0G4Ns0iEr3R2qLPpU7q1%3DrOY93%3DAO16a3g%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 
> https://groups.google.com/d/msgid/golang-nuts/825D82DD-C595-415D-B0C6-7BE090A015C7%40ix.netcom.com.

-- 
You received this message because you are subscribed to the Google Groups 

Re: [go-nuts] Generics and parentheses

[Randall O'Reilly]

Sorry to perseverate and belabor the point, but here's an analogy that makes 
the point perhaps more strongly and succinctly:

Imagine that, for some reason, Go didn't have the array/slice element operator 
syntax, [ ], and it was now going to be introduced in Go2, but instead of using 
this established existing convention, parens were going to be used instead of [ 
], due to some parser considerations.  I suspect many people would feel the 
same way they feel about the < > syntax: this is such an established convention 
that it would seem crazy to not adopt it.

If other languages can get their parsers to deal with this syntax, why not Go?  
Certainly fast parsing is an important feature, but if anything, readability is 
perhaps even more important than that?

And to specifically address the example from the original email:

> PS: For ambiguities with angle brackets consider the assignment
> 
>   a, b = w < x, y > (z)
> 
> Without type information, it is impossible to decide whether the right-hand 
> side of the assignment is a pair of expressions
> 
>   (w < x), (y > (z))
> 
> or whether it is a generic function invocation that returns two result values
> 
>   (w)(z)

wouldn't gofmt remove the superfluous (z) in this case (and even with a more 
complex expression inside the parens, as the > operator would have appropriate 
precedence?), in existing code?  And thus, would it not be reasonable to have a 
convention in this case that if you have an expression that fits the type 
parameter interpretation, that interpretation is used instead of the 
alternative?  And if you really wanted to write the alternative, you would be 
forced to make it explicit with the parens as noted:

a, b = (w < x), (y > (z))

This seems like a very rare case, and a small price to pay for following the 
established convention..

- Randy

> On Jul 14, 2020, at 11:53 PM, Randall O'Reilly  wrote:
> 
> Tagging onto this point: while Go deviates from other languages in a number 
> of important ways, syntax at the level of things like parens, brackets, etc 
> is not one of these key differences.  It is almost entirely consistent with 
> the "de facto" C-style choices in this respect (to the extent that people 
> mistakenly regard it as just a subset of C).  In this context, it does seem a 
> bit of "being different for its own sake", to adopt something *other* than 
> the < > convention for generic types.
> 
> Yes, Go should boldly Go where no language has gone before^*, but when it is 
> basically adopting a well-established paradigm widely used in existing 
> languages, doesn't it also make sense to adopt the well-established syntax 
> associated with that paradigm? (although the proposed Go generics differ in 
> some important ways from other languages, the use of type parameters is not 
> one of them.)
> 
> While we've been asked to focus on the more "objective" facts of parsing 
> considerations here, the above logic would suggest a different approach: if 
> there is any way to adopt the established conventional syntax and make the 
> parsing work, then that is what should be done.  So, essentially, this puts 
> the onus back on the parser programmers to definitively *rule out* the use of 
> < > -- is it really that difficult / costly to do a bit of look-ahead and 
> disambiguate the different use cases? 
> 
> - Randy
> 
> * e.g., see https://github.com/golang/go/issues/39669 for a more radical 
> departure from convention, doing away with the extra parens entirely.
> 
>> On Jul 14, 2020, at 9:45 PM, robert engels  wrote:
>> 
>> My opinion is that every major language (no flames please… lots of 
>> developers write lots of programs and make money doing it) that supports 
>> generics uses < > for generic types, so Go should too - since there is no 
>> reason to deviate from this other than to avoid changes to the parser. Seems 
>> better to pay this cost once - rather than every Go program that uses 
>> generics being harder to read for eternity (especially for those readers 
>> that use a lot of languages).
>> 
>>> On Jul 14, 2020, at 11:13 PM, Ian Lance Taylor  wrote:
>>> 
>>> On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W.  
>>> wrote:
>>>> 
>>>> This feels a little better, but honestly I'm still all for angle brackets 
>>>> or like Watson suggested, guillamets.
>>>> 
>>>> fn(T1)(fn2(T2)(fn3(T3)(v))) // 1
>>>> fn[T1](fn2[T2](fn3[T3](v))) // 2
>>>> fn(fn2(fn3(v))) // 3
>>>> fn«T1»(fn2«T2»(fn3«T3»v)))  // 4
>>>> 
>>>> To me, with a background in C++ and Typescrip

Re: [go-nuts] Generics and parentheses

[Randall O'Reilly]

Regarding the parsing: as I suggested in my email, but perhaps was unclear, in 
case of two conflicting *purely syntactic* interpretations (without using any 
type information), you could just choose the more high-frequency interpretation 
(i.e., type parameters) and force the programmer to use additional parens if 
they actually want the other interpretation.

So in the case of the example, w < x, y > (z) is *automatically, syntactically* 
interpreted as a function call using 2 type parameters, and if you want it to 
be two different relational expressions, you have to wrap them in parens: (w < 
x), (y > (z))

This latter use is likely to be vanishingly rare (someone could run their code 
analysis on it), so this seems like a small inconvenience.  Maybe there are 
other such conflicts?  If this is the only one, I don't think it is sufficient 
to rule out the use of < >.

My mention of the point about gofmt was just that it should get rid of the 
seemingly redundant extra paren around (z), but I just tried it and apparently 
it does not, even with gofmt -s.  Anyway, the above point stands: you CAN parse 
< > correctly by just making purely syntactic choices in the case of conflicts, 
and this applies to all Go tools using the same purely syntactic parsing pass.

Also, according to Tiobe, Scala is ranked 39, and whereas C, Java, C++, C#, are 
all top 10, and the C family is clearly the syntactic heritage of Go.

And the use of [ ] in map is more semantically associated with its conventional 
use as an element accessor in arrays / slices, not with some more general kind 
of type parameter.

- Randy

> On Jul 15, 2020, at 11:48 AM, Ian Lance Taylor  wrote:
> 
> On Tue, Jul 14, 2020 at 9:45 PM robert engels  wrote:
>> 
>> My opinion is that every major language (no flames please… lots of 
>> developers write lots of programs and make money doing it) that supports 
>> generics uses < > for generic types, so Go should too - since there is no 
>> reason to deviate from this other than to avoid changes to the parser. Seems 
>> better to pay this cost once - rather than every Go program that uses 
>> generics being harder to read for eternity (especially for those readers 
>> that use a lot of languages).
> 
> Thanks for the note.
> 
> I'll briefly mention, as others have, that Scala successfully uses
> square brackets for generics, and that in Go the map type already uses
> square brackets to indicate the generic key type (though the value
> type is outside the square brackets).  So it's not like this is
> entirely new ground.
> 
> It's also worth noting that the Go survey results
> (https://blog.golang.org/survey2019-results) show us that the
> languages most Go programmers are familiar with are Python and
> JavaScript, which of course do not use generics at all with any sort
> of brackets.  So the familiarity argument only goes so far.
> 
> More seriously, though, let's look closely at Robert's example:
> 
> a, b = w < x, y > (z)
> 
> When parsing this without any information about what the identifiers
> mean, this could be either an assignment of two values to two
> variables:
> 
> a = w < x
> b = y > (z)
> 
> or it could be a call of the instantiated function w passing the
> argument z and returning two results.  By the way, don't get
> distracted by the parentheses around z, it can be an arbitrary
> expression, so although (z) might be unusual using parentheses around
> a more complex expression might be entirely reasonable.
> 
> Without knowing the type of w, we can not parse this statement.  This
> has nothing to do with lookahead or the nature of parsing or anything
> else.  It's fundamental to the syntax.
> 
> In order for tools like gofmt and goimports to be effective and be
> fast enough to run on file save, they have to be able to parse Go code
> without knowing types.  In the general case, where w might actually be
> written as pkg.w, knowing the type of w will require chasing through
> an arbitrary number of imported packages.  Requiring simple tools like
> gofmt and goimports to do this kind of type checking would break one
> of the basic guidelines that Go has followed from the beginning: the
> language must be easy and fast to parse without knowing types.
> 
> I'll note that C++ also has this syntactic problem, and indeed C++
> cannot be parsed without full type information.  This is part of why
> tools that work with Go code run much faster than tools that work with
> C++ code, and is part of why the Go compiler is much faster than
> typical C++ compilers.
> 
> So it's really not a matter of "just fix the parser to use angle
> brackets."  As far as I've been able to tell, using angle brackets is
> technically infeasible, given the way that Go works.  Other languages
> make different choices, and those choices work for them, but this is
> not a choice that Go is able to make.
> 
> So, I hear you: you and many others would prefer angle brackets.  But
> unless and until someone explains how it could

Re: [go-nuts] "Interfaces" with type lists are a strange beast

[Randall O'Reilly]

FWIW, the "generic types" alternative syntax proposal: 
https://github.com/golang/go/issues/39669 includes an explicit distinction 
between generic interfaces and regular interfaces, and an earlier iteration of 
this idea included a new keyword, e.g., `prototype`, that would signal this 
distinction more clearly.  The current proposal instead just states that a 
generic interface must include a type list, and if there are no constraints, it 
is just a "fully generic" type list: `type type`, to signal that it is a 
generic interface.

In any case I do think that, conceptually, for the user's benefit and mental 
model of what is going on, it would be useful overall to have a clear 
distinction between generic and non-generic types, while also preserving the 
shared aspects as much as possible.  Interfaces *are* a form of generic-ness 
after all.

One additional idea would be that generic interfaces can embed regular 
interfaces, as a way to share code while also maintaining the clear conceptual 
distinction:

type GenericStringer interface {
   Stringer  // include standard Stringer interface
   type type // makes it a generic interface
}

If a separate keyword such as `prototype` were used to further distinguish from 
regular interfaces, it would be simpler and clearer:

type GenericStringer prototype {
Stringer  // prototypes can embed interfaces, but not the other way around
}

- Randy

> On Aug 3, 2020, at 4:00 PM, Ben Hoyt  wrote:
> 
> Per Ian's suggestion on the other thread I started
> (https://groups.google.com/g/golang-nuts/c/u9jqLPhEYO0/m/tnqezci8AwAJ),
> I'm breaking out this topic into a separate thread:
> 
> It seems strange to me that interfaces with type lists are really a
> different beast than regular interfaces, and aren't even meaningful as
> regular interfaces. (Trying to do that gives the error "interface type
> for variable cannot contain type constraints", which is relatively
> clear, at least.) As soon as an "interface" has a type list, it's not
> really a Go interface anymore (and interfaces with *only* type lists
> are not really interfaces at all, just type constraints). This seems
> confusing, though I'm not sure what the solution is.
> 
> Ian noted that this is mentioned very briefly at
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-interface-types
> but that he can't recall much discussion on this point.
> 
> That section in the draft design notes starkly that "They may not be
> used as ordinary interface types." And then:
> 
> "This restriction may be lifted in future language versions. An
> interface type with a type list may be useful as a form of sum type,
> albeit one that can have the value nil. Some alternative syntax would
> likely be required to match on identical types rather than on
> underlying types; perhaps type ==. For now, this is not permitted."
> 
> That seems a little far-fetched to me, almost like a justification of
> what we know to be odd / confusing in this proposal.
> 
> In terms of a "solution" for this, one that I'm sure has been thought
> about: what about keeping type constraints and interfaces completely
> separate? They are half the time anyway (when there are type lists),
> so why not make them separate all the time.
> 
> I realize this may be heading back towards contracts (though without
> the funky syntax for operators). I think the "Featherweight Go" paper
> says "we don't need two different concepts here", but the paper
> doesn't seem to discuss "type lists" at all (and type lists seem very
> important to this proposal, and definitely are to this immediate
> discussion).
> 
> Anyway, instead of saying "interface" you'd say "constraint":
> 
> // this isn't really an interface, so don't call it one:
> type SignedInteger constraint {
>type int, int8, int16, int32, int64
> }
> 
> // this also can't be used as in interface, so don't call it one
> type ComparableHasher constraint {
>comparable
>Hash() uintptr
> }
> 
> // yes, this duplicates the Stringer interface for use as a type constraint
> type Stringable constraint {
>String() string
> }
> 
> I realize in the design draft the "Stringer" interface is used as a
> type constraint heavily, but that seems like a bit of an example/toy.
> In real-world code, how likely is it that we'll be using lots of
> existing interfaces as constraints? To me it seems like that won't be
> common, but I don't have much to go on.
> 
> -Ben
> 
> -- 
> 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/CAL9jXCHa5%2B4LreE7acP_r3QEBMGKN6qzgzkLFv4VXsW5aoXfcw%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To

Re: [go-nuts] Is there a Go native approch to MPI (Message passing interface) ?

[Randall O'Reilly]

I just wrote a wrapper around open mpi in Go:  https://github.com/emer/empi

Also, here's a set of random go bindings I found:
• https://github.com/yoo/go-mpi
• https://github.com/marcusthierfelder/mpi
• https://github.com/JohannWeging/go-mpi
Even a from scratch implementation:

• https://github.com/btracey/mpi
Also a few libraries for using infiniband directly:

• https://github.com/Mellanox/rdmamap
• https://github.com/jsgilmore/ib
• https://github.com/Mellanox/libvma
Some discussion: https://groups.google.com/forum/#!topic/golang-nuts/t7Vjpfu0sjQ

- Randy

> On Sep 14, 2020, at 3:25 AM, Samuel Lampa  wrote:
> 
> On Thursday, June 11, 2015 at 2:53:36 PM UTC+2 Egon wrote:
> 1. In which cases a cluster of say 4 (or 10 or 100 for instance) Raspberry Pi 
> mini computers can be more cost-effective than a single computer with the 
> same amount of cores (does the cost of communicating the data between the 
> computers via the network not outweigh the fact that they car run tasks 
> simultaneously) ?
> 
> The general answer is Amdahl's Law 
> (http://en.wikipedia.org/wiki/Amdahl%27s_law), of course it's not always 
> applicable 
> (http://www.futurechips.org/thoughts-for-researchers/parallel-programming-gene-amdahl-said.html).
>  When moving things to multiple-computers you'll get a larger overhead in 
> communication when compared to a single-computer, at the same time you may 
> reduce resource-contention for disk, RAM (or other resources). So depending 
> where your bottlenecks are, it could go either way...
> 
> Yes, and also note that super-computers often use special network 
> protocols/technologies which support so called "Remote direct memory access" 
> (RDMA) [1], such as Infiniband [2], to get acceptable performance for 
> high-performance multi-core computations across compute nodes. Infiniband 
> cards are pretty expensive as far as I know, so will probably outweigh the 
> benefits of buying a lot of RPis.
> 
> I'd still be interested to hear if anybody knows about new developments on 
> MPI for Go (for HPC use cases if nothing else)? :)
> 
> [1] https://en.wikipedia.org/wiki/Remote_direct_memory_access
> [2] https://en.wikipedia.org/wiki/InfiniBand
> 
> Best
> Samuel
> 
> -- 
> 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/d1d39602-e48e-4c2e-909b-a85d0d7e81ban%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/2B3CAD1A-234F-4C09-BC21-24D6E01B87DA%40gmail.com.

Re: [go-nuts] Proposal to add Index operator methods

[Randall O'Reilly]

Jon's points probably sink this proposal.  Go is a very different language, and 
making it less self-consistent to solve some fraction of syntactic readability 
is almost certainly not going to get over the very high threshold for changing 
the language.

If you're going to switch over to Go, you'll have to learn a LOT of new 
concepts and change the way you approach things.  In the end, it is better that 
Go remain "pure and simple" -- the simpler it remains, the easier it is for 
anyone to learn it, no matter where they are coming from.

Another strategy, which I'm pursuing, is to support Python as a scripting 
language on top of Go backend code that does all the heavy lifting.  That is 
how Python is used in most cases already, except with C / C++ backends.  So, 
keep Python Python, and keep Go Go, but allow people to interoperate more 
easily.  This way, people can get some exposure to the virtues of Go, and maybe 
decide to switch over at some point..

This tool makes it relatively easy: https://github.com/go-python/gopy   I've 
also written a GoToPy converter https://github.com/goki/gotopy (will be moving 
over to go-python soon -- no time right now), so you can write 'main' programs 
in Go, then easily convert them over to Python (Go -> Python is very easy, the 
other way not so much), which provides a point of departure for Python folks to 
start using your code..

- Randy

> On Oct 6, 2020, at 12:56 AM, Raanan Hadar  wrote:
> 
> Lets start with saying that I think this is a valid criticism. 
> 
> Although it does not solve things 100%, it does solve the heart of the 
> problem for me at least: 
> There is a mixture of index operators with functional operators in the syntax:
> The [] operator gives the reader the 'where' context and the () gives the 
> reader the 'what' context. If you are using all your arguments via () causes 
> the readability problem. So while not having full operator overloading, you 
> still have to use .Add() instead of '+', the grammar is now consistent and 
> concise and separates the 'where' from the 'what'.
> 
> Also, please consider that different users have a different 'value scale' to 
> gain from this proposal:
> To a gonum user, this proposal is about a 20% improvement and nothing to run 
> home about.
> To a matlab/python programmer, this solves about 80% of their problems and 
> combining this with the other benefits of Go is enough to strongly consider 
> switching to Go.
> 
> Realistically, I don't think that I can convince the Go core dev team to add 
> full operator overloading and that is 
> probably the only way to achieve what you are suggesting... if you have 
> another way to achieve this, I am open
> In the end of the day, the question to ask is whether or not we 
> are better off in implementing this.
> On Tuesday, October 6, 2020 at 9:33:17 AM UTC+3 jonr...@gmail.com wrote:
> i think this looks nice but realistically only cleans up v simple cases.  a 
> lot of the very-verbose-and-not-so-elegant-looking multidimensional math 
> stuff looks "worse" than other languages because go doesn't have operator 
> overloading.  it is not clear to me this improves syntax too much in practice 
> on it's own.  (this is not a request to add operator overloading but merely 
> the non-controversial statement that operator overloading can help math-heavy 
> code look more "hand drawn" sometimes).
> 
> the gorgonia example is indicative of the issue: nil may be less 
> aesthetically pleasing than ":" (or not) but it's unlikely the surrounding 
> code looks anything like the math as expressed on paper by hand either.
> 
> gonum is quite convenient even with this...code that uses it can look a bit 
> more 1960s than other languages but it is simple and super-clear.  i like 
> that i am never (read: rarely) confused by () or , or [] etc characters in 
> go.  if you could find a way to cover more ground the change would look more 
> compelling to me.
> 
> On Mon, Oct 5, 2020 at 12:04 PM Raanan Hadar  wrote:
> It actually didn't change that much, I just applied your valuable feedback. 
> Thanks alot!
> 
> Its critical to communicate clearly.
> so I changed the before and after part of the proposal to be more 
> approachable to people who 
> are less familiar with numerical libraries in Go.
> 
> Its not a trivial proposal in that the main audience will probably use it in 
> a library and not in vanilla Go.
> But it was still a very valid point.
> 
> thanks again.
> 
> On Monday, October 5, 2020 at 3:19:02 AM UTC+3 jake...@gmail.com wrote:
> The examples I was looking at are gone now. That section has been completely 
> rewritten. So its kind of moot. Its possible that I was confusing the 
> 'before' and 'after' examples, since they were not clearly labeled. In any 
> case the rewritten version seems to make sense now. 
> 
> On Sunday, October 4, 2020 at 4:50:10 PM UTC-4 kortschak wrote:
> On Sun, 2020-10-04 at 09:06 -0700, jake...@gmail.com wrote: 
> > I stopped reading at the

Re: [go-nuts] Proposal to add Index operator methods

[Randall O'Reilly]

I think we all agree that Python has some major issues..  :)

But the point of Jon's argument which struck me as very compelling is that Go 
would really need full operator overloading to serve as a serious competitor 
given the standards to which people have become accustomed.  I didn't see in 
your replies a clear response to that, but maybe I missed it?

The really tricky issue is that everyone wants something like Python *as a 
starting point* when just messing around, because it is so easy and flexible to 
just write simple expressions etc.  But then once things start to scale up, all 
the "issues" start to outweigh those initial advantages.  And for a huge number 
of Python users, they never scale up and don't care about anything more than 
getting their immediate needs solved, mostly by copy / paste / modify 
programming..

That's why I think the Python / Go hybrid approach could be good -- end-user 
type people can mess around in Python, but the same functionality is available 
in Go, and as stuff starts to get scaled up to the point of requiring more 
libraries, those can hopefully be done in Go, so that Python always remains on 
the "messing around" scale of things, while the deeper infrastructure gets 
built out in Go..  This probably requires a fair bit of extra work and 
motivation on the part of the Go-side developers to keep up with things and 
support the developing needs of their users, so it may not be plausible for a 
larger-scale community, but it is working pretty well for my small-scale 
biological neural network modeling community..

Functionally, it is sort of similar to having a transpiler, in that Python is 
just providing a simple front-end syntax for accessing the deeper Go 
functionality.

Anyway, wasn't Julia supposed to solve all these issues? I don't know much 
about it in detail, but I googled just to see what the latest discussion there 
is relative to Python -- this thread is informative and current:

https://discourse.julialang.org/t/why-is-python-not-julia-still-used-for-most-state-of-the-art-ai-research/45896/17

The basic thrust is that people don't care and just go with what everyone else 
is doing.  This was the best quote IMO:

> There are countries that still do not use the metric system, you figure it 
> out.

Also this is informative:

> For my subjective idea I would also say Python, as someone mentioned here, is 
> much easier language than Julia. Coming from MATLAB looking at packages of 
> Julia seems to me as an act of wizard.

Python hits a sweet spot of simplicity and power.. Julia apparently does not.  
Go hits a different such sweet spot, but not with the same kind of transparent 
syntactic expressions needed for data science / ML etc.

- Randy

> On Oct 7, 2020, at 5:49 PM, Raanan Hadar  wrote:
> 
> So we respectfully disagree here, so the best thing I can do is add some 
> quality arguments. I think this is an important discussion that might cement 
> Go as a broad DSL in the sense that it does a lot of things exceptionally 
> well, but this issue will remain a blind spot.
> 
> I fully understand the need to keep Go "pure and simple". Its the key to its 
> success. But this is an important area where Go does not have enough features 
> to be effective. Secondly, I think that solving this issue can be achieved 
> while maintaining orthogonality and not hurting experience of the majority. 
> Third, as I answered Jon, I think that looking at this proposal, or more 
> generally, this problem, from the Go programmer's perspective, is like trying 
> to optimize a local optima. Go programmers don't have much to gain from this. 
> But from a global perspective that seeks to optimize software development as 
> a whole, there's a huge benefit that is overlooked here. Go was not designed 
> to cater the needs of the programmer but software engineering as an end to 
> end process (https://talks.golang.org/2012/splash.article).
> 
> With regards to Python, I've detailed common examples in my proposal, where 
> Python for numerical computing leaves a lot to be desired. Fundamental issues 
> which Go solves by design and are not addressed effectively by putting the 
> two together as you suggested. Secondly, I am not the only one saying that 
> there is a real need for a better language than Python. To name two good 
> examples: Yann LeCun said this last year: 
> https://venturebeat.com/2019/02/18/facebooks-chief-ai-scientist-deep-learning-may-need-a-new-programming-language/
>  and Jeremy Howard, former president and chief scientist of Kaggle and the 
> author of the fast.ai, strongly advocates that Python is not the way to go in 
> long run: https://www.youtube.com/watch?v=c-KAf2g6YN4  
> 
> 
> On Thursday, October 8, 2020 at 1:10:22 AM UTC+3 rcore...@gmail.com wrote:
> Jon's points probably sink this proposal. Go is a very different language, 
> and making it less self-consistent to solve some fraction of syntactic 
> readability is almost certainly not going to 

Re: [go-nuts] Should "go install module@version" interact with ~/.local/bin?

[Randall O'Reilly]

It would be great if there were a universal standard location in the user's 
$HOME directory that is already on the PATH, because that always trips up new 
users when starting to use a CLI.

But that does not appear to be the case on the mac -- this seems to be what a 
default user gets, at least on my system: 
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/Library/Apple/usr/bin

I didn't even know about ~/.local until this email, and I was a longtime linux 
user prior to mostly using a mac.  Windows is always different.  

Anyway, given those issues, probably better to stick with the current default 
like you say..

- Randy

> On Jul 13, 2021, at 2:43 PM, Tyler Compton  wrote:
> 
> With recent changes to go install, we now have an official, module-aware way 
> to locally build and install Go tools. This is a great step, but I wonder if 
> some renewed consideration should be made to where the tools are installed.
> 
> As I'm sure you all know, go install puts binaries in $GOPATH/bin or 
> $HOME/go/bin by default. I think that made more sense in a world where the 
> GOPATH was our primary means of Go development. However, with modules, I 
> would argue that GOPATH is becoming less and less a part of the Go 
> development experience. If go install placed binaries in ~/.local/bin by 
> default instead, it would be more in line with the way other local 
> installation tools work and wouldn't require users to update their $PATH at 
> all on some distributions. If we want to keep $GOPATH/bin, perhaps the tool 
> could put a symlink in ~/.local/bin instead.
> 
> I can think of a few reasons why this might not be a good idea:
> 
> What about other platforms, like Windows? I don't know if there's a place in 
> all operating systems where user-installed binaries are supposed to be 
> installed. It could be argued that the current approach is a better 
> cross-platform default.
> 
> Can't this already be achieved by setting $GOBIN? Sure. I still think there's 
> value in having the best possible default, but having $GOBIN as an option 
> makes this discussion less important.
> 
> Is this worth the confusion that changes like this inevitably create? Maybe 
> not. For those of us that use Go daily and already have $GOPATH/bin in our 
> $PATH, this may seem especially frivlious. I think a change like this 
> benefits those who don't develop in Go the most, and non-Go developers will 
> (probably) always outnumber Go developers :)
> 
> I'm curious to hear everyone's thoughts.
> 
> -- 
> 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/CAA%3DXfu0c4x5nW80jVehUs666iv%2B_9xp0frEudZH1u5zBHEm%2BjQ%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 
https://groups.google.com/d/msgid/golang-nuts/E87DA07A-8E0F-42D1-AF97-5C26F6E55F60%40gmail.com.

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

[Randall O'Reilly]

This seems similar to previous proposals based on introducing kind-based type 
categories for contracts.  Putting the kind right there in the arg instead of a 
separate contract seems like an improvement, keeping it more local to where it 
is used.  Why not just take this one step further and just introduce entirely 
new types:

* number
* slice
* map (re-useable from existing use-case?)
* etc

func Min(x, y number) number {
   if x < y {
  return x
   }
   return y
}

func Delete(sl *slice, idx int) {
   *sl = append((*sl)[:idx], (*sl)[idx+1:])
}

The compiler would just do its normal thing based on whatever actual kind you 
pass in — an implicit type switch basically..

You could convert any `number` into a specific type (e.g., float64) when you 
need to, and if you passed two different underlying types of numbers as args to 
Min, it would automatically up-convert to the one with highest precision.  
Essentially, this is undoing all the strict type specificity of Go, and making 
it work like C, or Python..

This minimalist approach avoids all the complexity and ugliness of 
parameterizing types etc — it is just a more generic type of type, and is more 
or less how the generic builtin operators and functions like len, copy, etc 
already work on their respective kinds.

Composite types seem like they might even just work without a type parameter:

type Vec2 struct {
   X, Y number
}

func (u Vec2) Add(v Vec2) Vec2 {
   return Vec2{u.X + v.X, u.Y + u.Y}
}

In summary, this is really just introducing a very controlled dose of dynamic 
typing into the language (adding a dash of Python into Go).  Probably this has 
already been considered and rejected hundreds of times over the course of these 
discussions, but I’ve lost track, and seems at least like a very simple 
conceptual proposal: you can achieve a lot of generics functionality by just 
introducing dynamic typing.  Syntactically and conceptually, it is far cleaner 
and simpler than anything else I’ve seen in the generics discussion, at least.

- Randy

> On May 31, 2019, at 6:52 AM, Michal Strba  wrote:
> 
> @Ian, I have been thinking and I’ve come up with a possible solution to yours 
> and some other problems. I’d love to hear your thoughts on it. Note, that 
> this is a very fresh idea.
> 
> I’m addressing two problems here:
> 
>   • Inability to do Min/Max and other generic numeric functions.
>   • There are a few kinds of generic parameters, but the kind is always 
> implicit. This can be a problem because changing the body of a function can 
> result in a backward-incompatible change, even when the signature remains the 
> same.
> Here are the ideas (also described in the proposal now, in the section called 
> ‘Further ideas’).
> 
> The kind of a generic parameters is currently completely implicit. Some 
> annotation could be added. One possible syntax could be like this:
> 
>   • gen n for generic array lengths.
>   • gen T for arbitrary types (convertible to interface{}).
>   • gen eq T for equalable types (comparable with == and usable as map 
> keys).
>   • gen num T for numeric types (with operators like +, -, <, …).
> Array lengths and arbitrary types can have the same notation because it’s 
> always possible to distinguish them by context. Alternatively, they could be 
> distinguished by capitalization (lower-case for array lengths, upper-case for 
> types).
> 
> Syntax-wise, eq and num would not be keywords on their own. Rather, gen eq 
> and gen num would be two-word keywords.
> 
> The syntax is rather ad-hoc, I admit. It’s a very fresh idea, completely open 
> to refinement. However, since there are only four cases, an ad-hoc syntax may 
> actually be the right choice.
> 
> It’s also easily extensible with new possible “contracts”, but I’d generally 
> advise against that.
> 
> The addition of the num restriction would actually enable many cool things. 
> First, the Min/Max functions:
> 
> func
>  Min(x, y gen num T) T {
> 
> if
>  x < y {
> 
> return
>  x
> }
> 
> return
>  y
> }
> 
> It would also be useful for generic math types, like vector and matrices. The 
> matrix example above uses float64, but it could be generalized to all numeric 
> types.
> 
> As an example, let’s take a look at a possible implementation of a 2D vector 
> type:
> 
> type Vec2(T) struct
>  {
> X, Y T
> }
> 
> There are no restrictions specified in the type definition. This is because 
> it’s methods and functions that require restrictions, not the types 
> themselves. For example, this String method requires no restrictions:
> 
> func (u Vec2(gen T)) String() string
>  {
> 
> return fmt.Sprintf("(%v, %v)"
> , u.X, u.Y)
> }
> 
> This Eq method requires the types to be comparable with ==:
> 
> func (u Vec2(gen eq T)) Eq(v Vec2(T)) bool
>  {
> 
> return
>  u.X == v.X && u.Y == v.Y
> }
> 
> But, this Add method requires the types to be numeric:
> 
> func
>  (u Vec2(gen num T)) Add(v Vec2(T)) Vec2(T) {
>  

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

[Randall O'Reilly]

I wrote up a coherent proposal based on the core of the idea below, and added 
it to the feedback wiki:

https://gist.github.com/rcoreilly/bfbee2add03c76ada82810423d81e53d

Overall I think it seems quite promising as perhaps the most “Go” version of 
generics possible, which solves the major use-cases, while retaining 
essentially the same existing syntax and just adding a few additional keywords. 
 I can’t see any major limitations other than those intrinsic to the idea 
itself (e.g., you can’t define a Min function that works across any type 
whatsoever), and I don’t think it introduces any violations of existing static 
type safety.  Curious to hear what others think!  Cheers,

- Randy

> On May 31, 2019, at 4:28 PM, Randall O'Reilly  wrote:
> 
> This seems similar to previous proposals based on introducing kind-based type 
> categories for contracts.  Putting the kind right there in the arg instead of 
> a separate contract seems like an improvement, keeping it more local to where 
> it is used.  Why not just take this one step further and just introduce 
> entirely new types:
> 
> * number
> * slice
> * map (re-useable from existing use-case?)
> * etc
> 
> func Min(x, y number) number {
>   if x < y {
>  return x
>   }
>   return y
> }
> 
> func Delete(sl *slice, idx int) {
>   *sl = append((*sl)[:idx], (*sl)[idx+1:])
> }
> 
> The compiler would just do its normal thing based on whatever actual kind you 
> pass in — an implicit type switch basically..
> 
> You could convert any `number` into a specific type (e.g., float64) when you 
> need to, and if you passed two different underlying types of numbers as args 
> to Min, it would automatically up-convert to the one with highest precision.  
> Essentially, this is undoing all the strict type specificity of Go, and 
> making it work like C, or Python..
> 
> This minimalist approach avoids all the complexity and ugliness of 
> parameterizing types etc — it is just a more generic type of type, and is 
> more or less how the generic builtin operators and functions like len, copy, 
> etc already work on their respective kinds.
> 
> Composite types seem like they might even just work without a type parameter:
> 
> type Vec2 struct {
>   X, Y number
> }
> 
> func (u Vec2) Add(v Vec2) Vec2 {
>   return Vec2{u.X + v.X, u.Y + u.Y}
> }
> 
> In summary, this is really just introducing a very controlled dose of dynamic 
> typing into the language (adding a dash of Python into Go).  Probably this 
> has already been considered and rejected hundreds of times over the course of 
> these discussions, but I’ve lost track, and seems at least like a very simple 
> conceptual proposal: you can achieve a lot of generics functionality by just 
> introducing dynamic typing.  Syntactically and conceptually, it is far 
> cleaner and simpler than anything else I’ve seen in the generics discussion, 
> at least.
> 
> - Randy
> 
>> On May 31, 2019, at 6:52 AM, Michal Strba  wrote:
>> 
>> @Ian, I have been thinking and I’ve come up with a possible solution to 
>> yours and some other problems. I’d love to hear your thoughts on it. Note, 
>> that this is a very fresh idea.
>> 
>> I’m addressing two problems here:
>> 
>>  • Inability to do Min/Max and other generic numeric functions.
>>  • There are a few kinds of generic parameters, but the kind is always 
>> implicit. This can be a problem because changing the body of a function can 
>> result in a backward-incompatible change, even when the signature remains 
>> the same.
>> Here are the ideas (also described in the proposal now, in the section 
>> called ‘Further ideas’).
>> 
>> The kind of a generic parameters is currently completely implicit. Some 
>> annotation could be added. One possible syntax could be like this:
>> 
>>  • gen n for generic array lengths.
>>  • gen T for arbitrary types (convertible to interface{}).
>>  • gen eq T for equalable types (comparable with == and usable as map 
>> keys).
>>  • gen num T for numeric types (with operators like +, -, <, …).
>> Array lengths and arbitrary types can have the same notation because it’s 
>> always possible to distinguish them by context. Alternatively, they could be 
>> distinguished by capitalization (lower-case for array lengths, upper-case 
>> for types).
>> 
>> Syntax-wise, eq and num would not be keywords on their own. Rather, gen eq 
>> and gen num would be two-word keywords.
>> 
>> The syntax is rather ad-hoc, I admit. It’s a very fresh idea, completely 
>> open to refinement. However, since there are only four cases, an ad-hoc 
>> syntax may

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

[Randall O'Reilly]

It’s great to see that so many people share my considerable enthusiasm for this 
proposal!  Seriously, nobody is willing to take a look and provide any feedback?

- Randy

> On Jun 3, 2019, at 2:53 AM, Randall O'Reilly  wrote:
> 
> I wrote up a coherent proposal based on the core of the idea below, and added 
> it to the feedback wiki:
> 
> https://gist.github.com/rcoreilly/bfbee2add03c76ada82810423d81e53d
> 
> Overall I think it seems quite promising as perhaps the most “Go” version of 
> generics possible, which solves the major use-cases, while retaining 
> essentially the same existing syntax and just adding a few additional 
> keywords.  I can’t see any major limitations other than those intrinsic to 
> the idea itself (e.g., you can’t define a Min function that works across any 
> type whatsoever), and I don’t think it introduces any violations of existing 
> static type safety.  Curious to hear what others think!  Cheers,
> 
> - Randy
> 
>> On May 31, 2019, at 4:28 PM, Randall O'Reilly  wrote:
>> 
>> This seems similar to previous proposals based on introducing kind-based 
>> type categories for contracts.  Putting the kind right there in the arg 
>> instead of a separate contract seems like an improvement, keeping it more 
>> local to where it is used.  Why not just take this one step further and just 
>> introduce entirely new types:
>> 
>> * number
>> * slice
>> * map (re-useable from existing use-case?)
>> * etc
>> 
>> func Min(x, y number) number {
>>  if x < y {
>> return x
>>  }
>>  return y
>> }
>> 
>> func Delete(sl *slice, idx int) {
>>  *sl = append((*sl)[:idx], (*sl)[idx+1:])
>> }
>> 
>> The compiler would just do its normal thing based on whatever actual kind 
>> you pass in — an implicit type switch basically..
>> 
>> You could convert any `number` into a specific type (e.g., float64) when you 
>> need to, and if you passed two different underlying types of numbers as args 
>> to Min, it would automatically up-convert to the one with highest precision. 
>>  Essentially, this is undoing all the strict type specificity of Go, and 
>> making it work like C, or Python..
>> 
>> This minimalist approach avoids all the complexity and ugliness of 
>> parameterizing types etc — it is just a more generic type of type, and is 
>> more or less how the generic builtin operators and functions like len, copy, 
>> etc already work on their respective kinds.
>> 
>> Composite types seem like they might even just work without a type parameter:
>> 
>> type Vec2 struct {
>>  X, Y number
>> }
>> 
>> func (u Vec2) Add(v Vec2) Vec2 {
>>  return Vec2{u.X + v.X, u.Y + u.Y}
>> }
>> 
>> In summary, this is really just introducing a very controlled dose of 
>> dynamic typing into the language (adding a dash of Python into Go).  
>> Probably this has already been considered and rejected hundreds of times 
>> over the course of these discussions, but I’ve lost track, and seems at 
>> least like a very simple conceptual proposal: you can achieve a lot of 
>> generics functionality by just introducing dynamic typing.  Syntactically 
>> and conceptually, it is far cleaner and simpler than anything else I’ve seen 
>> in the generics discussion, at least.
>> 
>> - Randy
>> 
>>> On May 31, 2019, at 6:52 AM, Michal Strba  wrote:
>>> 
>>> @Ian, I have been thinking and I’ve come up with a possible solution to 
>>> yours and some other problems. I’d love to hear your thoughts on it. Note, 
>>> that this is a very fresh idea.
>>> 
>>> I’m addressing two problems here:
>>> 
>>> • Inability to do Min/Max and other generic numeric functions.
>>> • There are a few kinds of generic parameters, but the kind is always 
>>> implicit. This can be a problem because changing the body of a function can 
>>> result in a backward-incompatible change, even when the signature remains 
>>> the same.
>>> Here are the ideas (also described in the proposal now, in the section 
>>> called ‘Further ideas’).
>>> 
>>> The kind of a generic parameters is currently completely implicit. Some 
>>> annotation could be added. One possible syntax could be like this:
>>> 
>>> • gen n for generic array lengths.
>>> • gen T for arbitrary types (convertible to interface{}).
>>> • gen eq T for equalable types (comparable with == and usable as map 
>>> keys).
>>> • gen num T for numeric types (with operators

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

[Randall O'Reilly]

On Jun 5, 2019, at 12:03 PM, Ian Lance Taylor  wrote:
> 
> On Wed, Jun 5, 2019 at 10:47 AM Randall O'Reilly  wrote:
>> 
>> It’s great to see that so many people share my considerable enthusiasm for 
>> this proposal!  Seriously, nobody is willing to take a look and provide any 
>> feedback?
>> 
>> - Randy
>> 
>>> On Jun 3, 2019, at 2:53 AM, Randall O'Reilly  wrote:
>>> 
>>> I wrote up a coherent proposal based on the core of the idea below, and 
>>> added it to the feedback wiki:
>>> 
>>> https://gist.github.com/rcoreilly/bfbee2add03c76ada82810423d81e53d
>>> 
>>> Overall I think it seems quite promising as perhaps the most “Go” version 
>>> of generics possible, which solves the major use-cases, while retaining 
>>> essentially the same existing syntax and just adding a few additional 
>>> keywords.  I can’t see any major limitations other than those intrinsic to 
>>> the idea itself (e.g., you can’t define a Min function that works across 
>>> any type whatsoever), and I don’t think it introduces any violations of 
>>> existing static type safety.  Curious to hear what others think!  Cheers,
> 
> 
> I don't understand how to use this proposal to write a type-safe
> concurrent hash map.  I think that is one of the key features that a
> generics implementation needs to support.

you can do any valid map operation on the generic type “map”, so at a minimum 
it seems like you could just add an appropriate mutex around each of the 
different operations, using a struct interface:

package safemap

type M struct interface {
   Map map
   Mu  sync.RWMutex
}

func (m *M) Set(k key(m), v elem(m)) {
m.Mu.Lock()
if m.Map == nil {
m.Map = make(m.Map)
}
m.Map[k] = v
m.Mu.Unlock()
}

…

any concrete map that shares that struct interface type signature automatically 
gets the associated methods:

import safemap

// MySafeMap implements the safemap.M struct interface
type MySafeMap struct {
Map map[string]string
Mu  sync.RWMutex
}

func MyFunc() {
   m := MySafeMap{}
   m.Set(“mykey”, “myval”) // at this point the Set method knows the concrete 
type of “m”, can compile Set
}

> As a less important issue, relying on a general construct like
> "number" is problematic in Go.  There are many different ways to slice
> up Go's types.  "number" is just one of them.  There is also integer,
> signed integer, unsigned integer, comparable, ordered, float, complex.
> One can even think of addable (includes string) and indexable and
> sliceable.
> 
> Ian

The proposal already does include some of those number subtypes (I did leave 
out complex, for simplicity..).  There is probably some optimal 80/20 choice to 
decide exactly which generic number categories to include.  For example, 
ordered could just be identical to number (i.e., all the different ints, 
floats, but excluding complex which is not really a number in the same sense — 
it is more like a vector).  You could add comparable to include complex+number 
but it might be simpler to just say that if you’re writing a generic function 
that operates on complex numbers, you have to use the “complex” generic to 
subsume 64 and 128 variants, and otherwise it is excluded from the “number” 
category and probably few people will notice or complain..  Likewise, maybe you 
don’t need generic “integer” in addition to both “signed” and “unsigned” (I’ll 
update my proposal to use “signed” instead of “integer” as that is more 
specific), but maybe the one extra keyword is worth it.  Anyway it seems like 
these details could definitely be worked out if the overall idea holds water.

I wasn’t really sure to do about string — might be useful to see how far you 
can get just treating it as a byte array from the generic perspective — 
otherwise it already stands alone in a type class by itself, so it doesn’t 
really need a generic version.

Adhering to the minimalist approach, I’m pretty sure you could most of what you 
want while avoiding things like addable, indexable and sliceable, and just 
using map, slice, array and their existing operators in a generic way.


-- 
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/DA59DC24-5C4A-4712-9CB2-B155A7C459DD%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Randall O'Reilly]

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 golang-nuts+unsubscr...@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.

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

[Randall O'Reilly]

On Jun 5, 2019, at 8:36 PM, Burak Serdar  wrote:
> 
> On Wed, Jun 5, 2019 at 11:47 AM Randall O'Reilly  wrote:
>> 
>> It’s great to see that so many people share my considerable enthusiasm for 
>> this proposal!  Seriously, nobody is willing to take a look and provide any 
>> feedback?
> 
> This reminds me of a proposal I wrote some months ago that uses
> existing types as contracts with a new "like" keyword for primitives.
> Your proposal takes that idea further and gets rid of contracts
> completely. Even though the syntax is cleaner, I think you lost some
> of the expressive power of contracts.  For instance:
> 
> Edges []Edge : does this mean that Edges is an array where each
> element is a type that satisfies Edge (and thus each element can have
> a different type), or that it is an array where each element is the
> same concrete type of Edge?
> 
> The motivation behind contracts was to ensure generic types can be
> compiled before instantiation. This proposal seems to give up on that.

Just to be clear, the proposal is definitely NOT to get rid of contracts at 
all!  The point is actually very similar to your proposal (as you noted) — 
here’s the link for reference: 
https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3

Specifically any contract specified using like(), e.g., your SignedNumber 
example (which becomes simply `signed` as the builtin generic type in my 
proposal) should be essentially identical from the compiler’s perspective, 
right?  They specify the same exact contract, just using a different syntax.

Likewise, any use of a generic native “slice” or “map” type definitely 
specifies a very concrete “contract” — it is just not an *arbitrary* contract — 
it is just the familiar existing contract that we all know and love..

I’m not sure about the claim that some of the examples in your proposal could 
actually be compiled effectively in advance of instantiation.  For example, 
anything involving a struct with specific fields (which is achieved using the 
struct interface syntax in my proposal, but is essentially functionally the 
same as the corresponding structs in your proposal and the draft proposal, 
again just with a different simpler syntax that avoids explicit type 
parameters), would presumably benefit considerably by knowing the concrete 
types involved to know about field offsets and specific types used in 
operations etc.  If you don’t know the concrete type(s), then you’re stuck 
using virtualized “boxing” kinds of approaches for everything in the code, 
right?  If you wait until you have the concrete type, the compiler can decide 
the best way to optimize the various costs associated with boxing vs. code 
bloat etc.

Anyway, just to reiterate, the core idea is definitely *not* to abandon 
contracts — just to use existing native contracts, which constitute a 
well-known, well-tested finite “basis set” of contracts.  By using this very 
limited space of contracts, we can use builtin keywords and a much simpler 
syntax, and the compiler should actually have an *easier* time compiling 
generic code compared to supporting arbitrary contracts.  I think it really is 
the same basic idea from your like() proposal, so I “like” it :)

- Randy

-- 
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/AC62F9E3-DC79-40B7-85C1-D6CB5CA0838A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Project Layout Question

[Randall O'Reilly]

In case it helps anyone else with this problem, there is an issue with the 
standard layout, and any project where all the code is in various 
subdirectories but there is no .go code at the top level: godoc.org won’t find 
it!

https://github.com/golang-standards/project-layout/issues/19
https://github.com/golang/gddo/issues/618

a good workaround is to create a doc.go file at the top level, which can be a 
handy place to put overall project docs I guess.

btw, a further advantage of moving all code (except doc.go) out of the top 
level is that it makes your github page look nicer, especially for being able 
to read the README file without having to scroll down too far.  I’ve adopted 
the strategy of just having a “stutter” in repeating the name of the overall 
repository as the main package subdirectory in the repository (e.g., gi/gi) — 
the std go import prefix is the same, but you get the advantage of moving all 
the code out of the top level.

- Randy

> On Jun 13, 2019, at 1:21 AM, Boris Mühmer  wrote:
> 
> Thanks for Your suggestions so far. I will have to do further tests to see 
> what suits our team best.
> 
> 
> Regards,
> Boris
> 
> Am Di., 11. Juni 2019 um 23:47 Uhr schrieb David Riley :
> On Jun 11, 2019, at 13:38, Ronny Bangsund  wrote:
> 
>> 
>> 
>> On Tuesday, June 11, 2019 at 2:47:44 PM UTC+2, Boris Mühmer wrote:
>> Is the project layout total rubbish?
>> 
>> I'm not sure - all I know is that it's different from how I prefer it, and 
>> "pkg" is the one thing I frequently see people dislike ;)
>> If you want to share packages, parent them to the project directory. 
>> Anything you feel is too niche you can hide inside internal/. Binaries in 
>> cmd/ makes it nice and tidy, but you can get away with top-level main 
>> packages if there's only one command and it's really simple (few source 
>> files to clutter it up).
> 
> This layout is, I feel, most useful for large projects which build many 
> binaries and have many packages (which is what we use it for). In that 
> context, it’s great.
> 
>> I might make a server cmd the same name as the project directory, and if 
>> possible, make it have CLI options to control itself (talk via local socket, 
>> gRPC, REST, whatever). Pleasing VS Code is mainly about configuring the 
>> build task(s). I like to have Release and Debug tasks, sometimes with tasks 
>> requiring other tasks (client-server projects, for instance).
> 
> One thing I’ve found it doesn’t work especially nicely with is things that 
> have files hardcoded to be in `pwd` (the common “task” utility is an example 
> of this), because then you get your nice, tidy top level cluttered with dreck 
> from your tools.
> 
> Also, `go test` runs its commands from the directory of the tested package, 
> not the current working directory, but that gripe is better hashed out 
> elsewhere.
> 
>> I haven't looked closely at the current state of modules to say anything 
>> about how it'll change up my standards, but it looks like we're expected to 
>> run module stuff out of the top-level directory. If not, aren't those parts 
>> better off breaking out into their own standalone projects? Running module 
>> setup in sub-directories with potentially different versions of external 
>> dependencies feels dirty.
> 
> It works fine with modules, at least assuming your repo directory is one 
> module! We haven’t tried it with sub-modules, mostly because that feels like 
> madness.
> 
> 
> - 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/174A6172-8A4B-47F0-9C49-F54A7D1B17A8%40gmail.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CALW2tjrL8bDJvqh3cZGMhK6GNoy7XNJhKFwmhFW9FJqH92KtqQ%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/E8204FB9-818A-4EDA-8301-90291057334C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: A proof-of-concept implementation of my generics proposal for Go

[Randall O'Reilly]

I also like this proposal, and have a related proposal with a somewhat 
different syntax that is even simpler and is essentially identical to existing 
Go code, just with “Generic Native Types” (GNT).  Here’s a couple of 
side-by-side comparisons:

///
// Min

Michal’s:

func Min(x, y type T ord) T {
if x < y {
return x
}
return y
}

GNT:

func Min(x, y number) type(x) {
…
}

///
// SyncMap

Michal’s:

type SyncMap(type K eq, type V) struct {
mu sync.Mutex
m  map[K]V
}

func (sm *SyncMap(type K eq, type V)) Store(key K, value V) {
sm.mu.Lock()
sm.m[key] = value
sm.mu.Unlock()
}

GNT:

type SyncMap struct interface {
mu sync.RWMutex
m  map   // a generic map
}

func (m *SyncMap) Store(k key(m.Map), v elem(m.Map)) {
…
}

A struct interface is like an interface, specialized for struct -- any struct 
with the specified fields gets the generic methods, instantiated for the 
concrete type, e.g.,:

// MySyncMap instantiates the SyncMap struct interface...
type MySyncMap struct {
mu sync.RWMutex
m  map[string]string
}

Here’s a significantly improved version of the proposal originally posted a few 
weeks ago:
https://gist.github.com/rcoreilly/bfbee2add03c76ada82810423d81e53d  This 
proposal also specifies a complete set of *fixed* “contracts” that are 
isomorphic to the existing native types, so it might appeal to people who 
prefer more explicit semantics for the generic args, compared to more generic 
generics.  Cheers,

- Randy

> On Jun 27, 2019, at 8:13 PM, Ben Hoyt  wrote:
> 
> I really, really like this. I liked the original proposal, but using the 
> "type" keyword seems very natural. And I like the 80/20 constraints thing 
> with eq/ord/num. Good work -- I hope this gets turned into an official 
> proposal and debated.
> 
> -Ben
> 
> 
> On Thursday, June 27, 2019 at 10:29:03 AM UTC-4, Michal Strba wrote:
> Hey everybody!
> 
> A few weeks ago, I posted about my proposal for generics in Go 2. You can 
> find it here.
> 
> Today, I finished a proof-of-concept implementation. It was a lot of fun and 
> I learned a lot about the internals of Go.
> 
> The implementation is a program that takes a Go file that uses generics and 
> translates it to a regular Go file that you can run.
> 
> Try it out here :)
> 
> I'm looking forwad to all your feedback!
> 
> Michal Štrba
> 
> -- 
> 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/199bad6c-ed62-44a6-960b-86503242537a%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/655EEB98-6928-48E9-84C4-24C259660E7D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Tool to convert svg to png/jpg

[Randall O'Reilly]

Here’s some partial SVG renderers in Go:

* https://github.com/srwiley/oksvg
* https://github.com/goki/gi (uses srwiley’s rasterx rasteriser, has separate 
SVG parsing / painting impl).

Cheers,
- Randy

> On Jan 31, 2020, at 6:54 PM, Michael Jones  wrote:
> 
> Just to be clear: PNG is a description of pixel values comprising an image 
> (RGBa, RGBa, RGBa, ...), SVG is a program for creating an image (set color to 
> blue, draw a circle, change to red, draw a line, ...). Going from SVG 
> (scalable vector graphics) to pixels is to render an image by executing the 
> simple program of graphical operation codes. (As said above)
> 
> Solutions depending on situation: most every browser has code to rasterize 
> SVG. Can you invoke one to produce your image? There are numerous free tools 
> to do the same--can you bundle one of those and invoke it as an external 
> program? Cairo can do it. (these are in addition to what you really seem to 
> want, which is a fully Go SVG -> PNG renderer.)
> 
> Good luck in your project,
> michael
> 
> On Fri, Jan 31, 2020 at 6:03 PM robert engels  wrote:
> There is no cross-platform graphics library included in Go.
> 
> Most likely you’ll need a C binding to Qt or similar to perform the 
> rasterization.
> 
> You might be able to put one together using something like 
> https://github.com/hajimehoshi/ebiten
> 
> 
>> On Jan 31, 2020, at 7:31 PM, maithri.fri...@gmail.com wrote:
>> 
>> I'm looking for one too but can't find anything online either..
>> 
>> On Monday, March 9, 2015 at 11:35:51 PM UTC-7, will wrote:
>> Hi Gophers,
>> 
>> Is there a Golang based tool (or library) tool to convert svg to png or jpg?
>> 
>> regards,
>> 
>> Will
>> 
>> -- 
>> 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/d03ad514-1e56-42a3-b7c6-798346a76ca1%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/BF136C90-3061-4E01-890B-A6FB38E94E07%40ix.netcom.com.
> 
> 
> -- 
> Michael T. Jones
> michael.jo...@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 
> https://groups.google.com/d/msgid/golang-nuts/CALoEmQw_8%3D3AkkrmZNG9Xrzq37TaauFF77wJUGjkp-Mx3%3DrUPQ%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 
https://groups.google.com/d/msgid/golang-nuts/5B2E195B-65B6-4D3A-B1C6-6208AB116645%40gmail.com.

[go-nuts] Any chance of not deprecating GOPATH ?

[Randall O'Reilly]

Apologies for being really slow on the uptake here, but I’m just now realizing 
that the master plan is to actually get rid of the GOPATH mode!  Is there any 
chance of possibly retaining it?  Is it too much work to maintain both modules 
and GOPATH modes?  I have absolutely no qualms with the modules and recognize 
that it is essential and a major improvement (and a huge amount of work).

But I really like GOPATH!  See: https://divan.dev/posts/gopath/ for some 
similar sentiments.

In short, GOPATH is great for simple, transparent, easy access to the source 
code, and in general it tends to work fine most of the time.  I have always 
thought of the modules as a kind of extra-hassle mode for “business types” that 
really need reproducible builds all the time, whereas “casual / lazy hackers” 
can just live in GOPATH and do just fine, especially when mostly dealing with 
their own code space (and especially across multiple packages).

So far, I’ve just been treating modules as something to update whenever I make 
an official tagged release, but that strategy seems to not work very well in 
practice, and, being lazy, have just been advising my users to turn 
GO111MODULE=off.  I’ve also generally been ignoring discussions of modules and 
apologize if this is a retread — just point me to the relevant discussion 
(didn’t find it in a quick search, except maybe in golang issues which are too 
long!)

Has someone written a short guide to replicate the “live source” mode of GOPATH 
within modules, so you can easily be updating code across multiple packages 
(and repositories) without having to do a lot of extra work to get one package 
to use the current version of the other etc?  That at least would be super 
handy, if it is possible.

- Randy

-- 
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/BAA3A299-9EC9-4A8F-9A44-9F6098CB618B%40gmail.com.

Re: [go-nuts] Any chance of not deprecating GOPATH ?

[Randall O'Reilly]

Thanks for the tip — that led me to these other relevant discussions:

* 
https://groups.google.com/forum/#!searchin/golang-nuts/gohack$20replace$20modules
* 
https://www.reddit.com/r/golang/comments/cvapcu/go_mod_how_to_get_it_to_find_packagesmodules_in/
* And now I understand the point of this tool: 
https://github.com/rogpeppe/gohack
* And here’s a very helpful tutorial: 
https://dev.to/maelvls/why-is-go111module-everywhere-and-everything-about-go-modules-24k

(It is worth noting that the official blogs don’t really address this issue — I 
just looked for “replace” in these blogs and it isn’t discussed: 
https://blog.golang.org/v2-go-modules)

The issue I’m having is well summarized from the reddit thread:

> Eg. Say I’m developing a library and a program at once. If I make changes to 
> the library, I also need to upload it to its git repo so it downloads it. 
> Alternatively, I can use the redirect. But then when I commit it to git, I 
> then need to remove the redirect line, otherwise the user who downloads the 
> program source needs to manually download the other library.
> It just makes development between two separate git repos really really 
> fucking hard. Before, I could just leave them In gopath and then I could edit 
> them both and work on them together. Then someone grabbing just the app would 
> just grab the dependency and it was done.

Given the prevalence and advantages of splitting large projects into different 
libraries & packages, the extra difficulties in dealing with this situation 
seem like a real impediment (and gohack doesn’t really solve the problem it 
seems — more for minor hacking but not for full-scale parallel development 
across packages / repos).

The current support for both GOPATH *and* modules seems like an ideal situation 
to me: there are two effective “branches” of the code (even without the extra 
hassle of git branches): the current GitHub code, and the tagged released 
versions with go.mod’s as needed for those releases.  Anyone who needs a stable 
build gets the tagged release and gets their reliable build using modules.  And 
the developers and bleeding edge folks can just live out of GOPATH as before.  
No need to remember to remove replace directives, etc — everyone’s happy (once 
you get past setting GO111MODULE appropriately)!  So maybe it could just be 
left this way :)

- Randy

> On Feb 1, 2020, at 10:50 PM, Tamás Gulácsi  wrote:
> 
> See the "replace" directive of go.mod. 
>replace my/pkg => ../../my/other/pkg
> Will use that other pkg instead of my/pkg.
> 
> -- 
> 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/920b-244f-4c5a-a188-c1a723ec8d76%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/FDA3AE68-8C9F-4D53-B731-EB2C39517462%40gmail.com.

Re: [go-nuts] golang as ML backend v/s C++

[Randall O'Reilly]

https://github.com/go-python/gopy can manage the python bindings for you 
automatically.  The bigger issue for ML is GPU.  I wrote a gosl (Go shader 
language) package that converts Go to hlsl which can be compiled in vulkan for 
compute shaders -- works well for my needs: https://github.com/emer/gosl   The 
same approach should also work for generating CUDA code, but I was already 
using vulkan in Go so that was easier.

In any case, after doing all the work of making my Go-based models available in 
Python via gopy, almost everyone found it easier to just use the Go models 
directly :)  That's the thing about Go: you really don't need the python front 
end in the same way that you do for C++, which takes so much longer to build, 
and is so unpleasant to code in.

The rest of the world will almost certainly keep using python and its 
established toolkits, so there isn't much hope of changing the ecosystem, but 
if you have some specific use-case and enjoy coding in Go, you can most likely 
make it work for you and some of your close friends :)

- Randy

> On Apr 14, 2024, at 10:31 PM, envee  wrote:
> 
> "
> - python -> c++ is one less layer of complexity to reason about than python 
> -> c -> go 
> "
> But doesn't the numpy package already use ctypes, for example ?maybe not a 
> golang-nuts question, but I was just wondering what is it that C++ can 
> perhaps do that Go cannot when creating bindings for Python ?
> 
> On Mon, Apr 15, 2024 at 1:05 PM Matt Parker  wrote:
> - python -> c++ is one less layer of complexity to reason about than python 
> -> c -> go
> - the go runtime is great for developer ergonomics, but is going to cost more 
> flops than equivalent code in c++ because of features like garbage 
> collection. additionally the concurrent features of go are great but 
> concurrent ML backends will probably be used a lot more than they are read + 
> written, so probably a fair tradeoff to sacrifice readability for performance 
> here. 
> On Sunday, April 14, 2024 at 8:15:51 AM UTC-4 envee wrote:
> After reading briefly about ML and how Python is used as a "veneer" for C++ 
> code, I was wondering why Go is not used as the backend, given it's excellent 
> concurrency support and ease of use.
> Basically, I was thinking if the backend is written as a shared object in Go, 
> and then used in Python using ctypes.
> I have seen a huge number of libraries on the awesome-go website, but don't 
> know if they have Python bindings.
> Any views ?
> What really is a limitation which does not encourage developers to prefer Go 
> over C++ as the ML backend ?
> 
> -- 
> 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/dc8d6282-d1cf-43db-a0ee-a1347e345638n%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/CALFCev5_64WLaXJrxAT8e8EDr5ts7xXO47gc91vONedETUQ9rg%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 
https://groups.google.com/d/msgid/golang-nuts/D9FF9D25-3877-4E11-AFFE-CAEFA8DFDEF9%40gmail.com.