Re: [go-nuts] [Generics] Constraints package name

['Axel Wagner' via golang-nuts]

On Sun, Jul 26, 2020 at 1:05 PM  wrote:

> Also, the name "is" doesn't follow the usual naming style of Go packages.
>>
>
> I'm not sure if there is a Go standard library package naming style other
> than "relatively short name".
>

"relatively short name" is less consistently applied than "be descriptive
of what's in there". Without the context of generics, what would you think
is in "is"? What's in "constraints"? What's in "quotedprintable"?


>
>
>> I tend to find such package names risky because they don't really say
>> what they contain.
>>
>
> The package doc comment can say that it contains constraints.
>
>
>> This means they become attractors of all kinds of different functionality
>> over time, where most of that functionality isn't belonging in there but in
>> separate packages. It is like declaring a package such as "util", "misc",
>> or "aux".
>>
>
> I'd trust the Go maintainers that they can resist to clutter it with
> unrelated things.
>
> --
> 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/f623ffc6-757c-44a7-bbcf-0e8b59efa714o%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/CAEkBMfH_q%2Bzqszfn%3D-8CjrTGJQ%2Bx1P%2BMjnDtitW4RObmvw2mjw%40mail.gmail.com.

Re: [go-nuts] Does method with pointer receiver keeps track of the receiver instance

[Tony Yang]

No problem, thanks!

On Fri, Jul 24, 2020 at 8:26 PM Ian Lance Taylor  wrote:

> On Fri, Jul 24, 2020 at 4:25 PM burak serdar  wrote:
> >
> > On Fri, Jul 24, 2020 at 5:21 PM Ian Lance Taylor 
> wrote:
> > >
> > > On Fri, Jul 24, 2020 at 4:07 PM Tony Yang  wrote:
> > > >
> > > > Hi Go community,
> > > >
> > > > I am wondering if a method with the pointer receiver keeps the
> receiver instance from garbage collected.
> > > >
> > > > To put the idea into a code example
> > > >
> > > > ```
> > > > type counter struct {
> > > > c int
> > > > }
> > > >
> > > > func (c *counter) next() int {
> > > > c.c = c.c + 1
> > > > return c.c
> > > > }
> > > >
> > > > func getNextFunc() func () int {
> > > > // Question: will c be garbage collected after the function retruns?
> > > > c := {}
> > > > return c.next
> > > > }
> > >
> > > The mere existence of a pointer receiver does not prevent a value from
> > > being garbage collected.  In your example, if the counter value is
> > > allocated on the heap in getNextFunc, that heap allocation can be
> > > collected after getNextFunc returns (in practice in this example c
> > > would be allocated on the stack, not the heap, anyhow).
> >
> >
> > What is returned from the function is a method, though. Isn't that
> > essentially a closure keeping a reference to c, and thus, c has to be
> > allocated on the heap, and cannot be garbage collected until the
> > returned function leaves the scope?
>
> My apologies, I completely missed that you returned a method rather
> than calling the method.
>
> Yes, doing this will prevent c from garbage collected.  Otherwise it
> would be impossible to call the returned function safely.
>
> 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/CADhGDyXUcf9WtN7s-S_rbHkeWK8dX1v-Q2crAv7K5vQVfbDLJQ%40mail.gmail.com.

Re: [go-nuts] Generic symbol metaproposal

[Michael Jones]

I'm never sure how much detail to share. The colorForth idea is a perfect
example of the thought about "another dimension" of specification. (Albeit
difficult to implement in practice). The upper/lower case signal is a good
one, and easy; it is limiting, but not terribly, and offers easy
frictionless specification.

The earlier comment about ";" being everywhere and nowhere in Go is
important. It leads to the question "what can we intuit?" That is a fine
starting place. For example, if the generic specification requires "()" or
"[]" or whatever around type-concretization lists, but the parser will add
them for you, then you'll never see either except in "pedantic" machine
generated code or the rareish case of a generic type list that needs
another generic type list as an element (the inner ones need delimiters).

I vote for this whatever symbol is chosen.

On Fri, Jul 24, 2020 at 3:16 PM David Riley  wrote:

> On Jul 24, 2020, at 5:50 PM, Ian Lance Taylor  wrote:
> >
> > On Fri, Jul 24, 2020 at 2:22 PM  wrote:
> > >
> > > On 7/23/20, Michael Jones  wrote:
> > > ...
> > > > Another delight is the uppercase signal for external.
> > > >
> > > > Maybe the “how to signal it” aspect of type instantiation could look
> to
> > > > these approaches as well—make the automatic understanding so magical
> that
> > > > the complete specification is unnecessary in most all cases, or the
> > > > signaling so intrinsic to the variables that no identification
> Symbol or
> > > > BracketedPair is necessary.
> > >
> > > Maybe braille?
> > > ⠓⠑⠇⠇⠕⠺⠕⠗⠇⠙
> > > https://www.royalblind.org/sites/www.royalblind.org/files/alphavet.PNG
> > >
> > > ⠊⠞ ⠊⠎ ⠑⠁⠎⠽
> >
> > I've always felt that color is underused in modern programming languages.
> >
> > func Max(T)(s []T) T
>
> Perhaps there could be some cross-pollination with ColorForth, wherein
> color actually is semantically meaningful.
>
> https://colorforth.github.io
>
>
> - Dave



-- 

*Michael T. jonesmichael.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/CALoEmQz%3D5WA0K8OV5q_ONpxESzP7wEtkBZtF32AMT08bvFR0DQ%40mail.gmail.com.

[go-nuts] CGo-free SQLite database/sql driver for linux/amd64 v1.4.0-beta1 is released

[Jan Mercl]

(reddit X-post)

>From the change log at https://godoc.org/modernc.org/sqlite#hdr-Changelog

2020-07-26 v1.4.0-beta1:

The project has reached beta status while supporting linux/amd64 only
at the moment. The 'extraquick' Tcl testsuite reports

630 errors out of 200177 tests on  Linux 64-bit little-endian

and some memory leaks

Unfreed memory: 698816 bytes in 322 allocations

Please try your production load tests and unit tests with the new
version. Your help testing these pre-release versions is invaluable.

Report any problems using the issue tracker (requires a GitLab
account): 
https://gitlab.com/cznic/sqlite/-/issues/new?issue%5Bassignee_id%5D=%5Bmilestone_id%5D=

-- 
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/CAA40n-VUH5qDdJW1oVPbbdyuMe%3DH2XOvUFU3tXrsTWMj1RS6sg%40mail.gmail.com.

[go-nuts] Re: How to get the methods list for each struct in golang.org/x/tools/go/ssa?

[xudongsun...@gmail.com]

The reason may be that I was using

*prog.MethodSets.MethodSet(m.Type())*

However, in golang the receiver of a method could be a struct type or a 
pointer to a struct type.
If the receiver of the method is a pointer, then only

*prog.MethodSets.MethodSet(types.NewPointer(tm.Type()))*

can return the methods.

On Friday, July 24, 2020 at 4:44:08 PM UTC-5 xudongsun...@gmail.com wrote:

> Hello everyone,
>
> I am trying to use golang.org/x/tools/go/ssa to get the methods list of 
> each struct type when doing static analysis on Kubernetes.
> This is the code I wrote to print out the method sets for each struct or 
> interface type.
>
> cfg := packages.Config{Mode: packages.LoadAllSyntax}
> initial, err := packages.Load(, pattern)
> if err != nil {
>log.Fatal(err)
> }
> prog, _ := ssautil.AllPackages(initial, 0)
> prog.Build()
>
> for _, pkg := range prog.AllPackages() {
>if pkg.Pkg.Path() == pattern {
>   for _, member := range pkg.Members {
>  fmt.Println(member)
>  if m, ok := member.(*ssa.Type); ok {
> fmt.Println(prog.MethodSets.MethodSet(m.Type()))
>  }
>   }
>}
> }
>
>
>
> I checked everything printed by fmt.Println(member) but it only contains 
> the pkg-level functions instead of struct methods.
> I also checked everything printed by fmt.Println(prog.MethodSets.MethodSet
> (m.Type())) and the method set for each struct/interface only contains 
> the abstract methods and their implementations. Many other methods (which 
> are not the implementation of some abstract methods) are missing here.
>
> *In one word, I am able to get all the pkg-level functions in the program 
> but I am NOT able the get the complete method list of any struct type in 
> the program.*
>
> *Here is what I want:*
> I want to get the complete method list (a list of *ssa.Function pointing 
> to the method) by calling some API with the struct type (or name)
>
> I googled around and read the related documents here: 
> https://pkg.go.dev/golang.org/x/tools/go/ssa?tab=doc but didn't find any 
> clue to solve the problem.
> I also read the golang.org/x/tools/go/ssa code but failed to find any API 
> to do so.
>
> Could anyone help to let me know how to do solve it in 
> golang.org/x/tools/go/ssa?
> Thank you 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/594fea33-77f3-44fc-af5c-10f9f518c580n%40googlegroups.com.

Re: [go-nuts] [Generics] Constraints package name

[Robert Engels]

I like ‘is’. Very readable and Go-like. 

> On Jul 26, 2020, at 6:05 AM, frederik.z...@gmail.com wrote:
> 
> 
>> On Sunday, July 26, 2020 at 12:46:38 PM UTC+2, Jesper Louis Andersen wrote:
>> 
>> You can always solve that with a rename:
>> 
>> import (
>>   is "constraints"
>> )
>> 
>> but you run the risk of users not knowing what the "is" package is.
> 
> Of course, but like you said, "is" would be unfamiliar to most other users. 
> People usually use the default package name and that's what we will have to 
> read the most.
>  
>> Also, the name "is" doesn't follow the usual naming style of Go packages.
> 
> I'm not sure if there is a Go standard library package naming style other 
> than "relatively short name". 
>  
>> I tend to find such package names risky because they don't really say what 
>> they contain. 
> 
> The package doc comment can say that it contains constraints.
>  
>> This means they become attractors of all kinds of different functionality 
>> over time, where most of that functionality isn't belonging in there but in 
>> separate packages. It is like declaring a package such as "util", "misc", or 
>> "aux".
> 
> I'd trust the Go maintainers that they can resist to clutter it with 
> unrelated things.
> -- 
> 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/f623ffc6-757c-44a7-bbcf-0e8b59efa714o%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/D9F02A8E-8BD6-425F-8646-38FCE30E9044%40ix.netcom.com.

Re: [go-nuts] [Generics] Constraints package name

[frederik . zipp]

On Sunday, July 26, 2020 at 12:46:38 PM UTC+2, Jesper Louis Andersen wrote:
>
>
> You can always solve that with a rename:
>
> import (
>   is "constraints"
> )
>
> but you run the risk of users not knowing what the "is" package is.
>

Of course, but like you said, "is" would be unfamiliar to most other users. 
People usually use the default package name and that's what we will have to 
read the most.
 

> Also, the name "is" doesn't follow the usual naming style of Go packages. 
>

I'm not sure if there is a Go standard library package naming style other 
than "relatively short name". 

>  

> I tend to find such package names risky because they don't really say what 
> they contain. 
>

The package doc comment can say that it contains constraints.
 

> This means they become attractors of all kinds of different functionality 
> over time, where most of that functionality isn't belonging in there but in 
> separate packages. It is like declaring a package such as "util", "misc", 
> or "aux".
>

I'd trust the Go maintainers that they can resist to clutter it with 
unrelated things.

-- 
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/f623ffc6-757c-44a7-bbcf-0e8b59efa714o%40googlegroups.com.

Re: [go-nuts] [Generics] Constraints package name

[Jesper Louis Andersen]

On Sun, Jul 26, 2020 at 9:30 AM  wrote:

> The package name "constraints" is quite a mouthful to read:
>
>   func Min[Elem constraints.Ordered](s []Elem) Elem {}
>
> Did you consider other package names like "is"?
>
>   func Min[Elem is.Ordered](s []Elem) Elem {}
>
>
You can always solve that with a rename:

import (
  is "constraints"
)

but you run the risk of users not knowing what the "is" package is. Also,
the name "is" doesn't follow the usual naming style of Go packages. I tend
to find such package names risky because they don't really say what they
contain. This means they become attractors of all kinds of different
functionality over time, where most of that functionality isn't belonging
in there but in separate packages. It is like declaring a package such as
"util", "misc", or "aux".

-- 
J.

-- 
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/CAGrdgiW48GA1-GU%3DiPBcYsm6W507YXRNbBsLROkQa1HBFbPzxA%40mail.gmail.com.

[go-nuts] Re: Help with Dataframes

[Pee Jai]

I created https://github.com/rocketlaunchr/dataframe-go to make dealing 
with data much easier.
It has an example code snipped in the docs on how to write dataframes to a 
csv file.

I created it because I found gota to be very cumbersome to use.

On Monday, May 29, 2017 at 9:23:51 PM UTC+10, Vikram Rawat wrote:
>
> Can anybody please tell me how to write GOTA Golang dataframes on a csv...
>
> It's been 2 days I am trying to find a way to write dataframes onto a csv. 
> can anybody please help me understand what does this IO.writer means and 
> how to use it...
>
> I have given up understanding it...
>
> Please any help will be appriciated. 
>

-- 
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/9327e204-1281-4505-82fb-eb9ca310e542o%40googlegroups.com.

[go-nuts] Re: I have own issue my whole project follow relative schema ./db

[Brian Candler]

Use go modules.

In the top directory:
go mod init github.com/username/project-name

This creates go.mod in the top directory.

Put additional packages in their own subdirectories.  But *don't* run "go 
mod init" for these.  They all share the top one.

Example: foo/bar.go contains 
package xyz
func Doit() {
...
}

Your users can then import it like this:

import "github.com/username/project-name/foo"
xyz.Doit()

The packages in other subdirectories of your module can refer to each other 
in the same way.  They should *not* use relative imports.  Forget that 
relative imports ever existed, and it will all 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f7a03a8e-9fb8-4c51-a601-922f78a5ed4fo%40googlegroups.com.

[go-nuts] [Generics] Constraints package name

[frederik . zipp]

The package name "constraints" is quite a mouthful to read:

  func Min[Elem constraints.Ordered](s []Elem) Elem {}

Did you consider other package names like "is"?

  func Min[Elem is.Ordered](s []Elem) Elem {}

is.Ordered
is.Integer
is.Signed
is.Unsigned

-- 
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/fb694112-7d2f-4db0-a0fd-86fd05459ae3o%40googlegroups.com.