Re: [go-nuts] Re: Using modules with go test ./...

[Paul Jolly]

John,

Scott is on the money with this response:

> I think you need to have a main module defined so there must be a go.mod in 
> cwd or upwards

The way to ensure that you are in a valid module context is simply:

go env GOMOD

which will return the path to the current (or main) module context (go.mod) if:

a) you are in module mode (either by being outside of GOPATH or with
GO111MODULE=on) and
b) there is a go.mod on the directory path from $PWD to the root.

As you have set GO111MODULE=on you can put your source code pretty
much anywhere you like; even within your GOPATH (whether GOPATH is set
or not, in the latter case as has been pointed out it defaults to
$HOME/go)

All you are missing is a go.mod file (go end GOMOD would confirm this,
and would return "")

Here's a simple example that shows things working within GOPATH:

$ export GO111MODULE=on
$ export GOPATH=/tmp/tmp.JJgvIDI0Uc
$ cd /tmp/tmp.In4INnkIH0
$ mkdir -p src/example.com/blah
$ cd src/example.com/blah/
$ cat 

Re: [go-nuts] Re: why does go reverse the order of name and type? "i int" vs "int i"

[Louki Sumirniy]

in programming languages putting the type first basically only appears in C 
and its (ill-born) children. But the reversal of word order like this is 
also present in norse and slavic languages with the definite article. It's 
actually the counter-intuitive pattern, and having learned to speak several 
languages with postfix definite articles and the awkwardness of this does 
slow down the process of mastering the language. Ultimately it doesn't 
matter whether you structure a language subject verb object, verb object 
subject, subject object verb, or whatever, but the Lisp verb object subject 
pattern is also counterintuitive and foreign to most programmers' native 
tongues.

But mainly putting the name first and then type afterwards makes it easier 
to read compound type declaration lists in parameters, as well as in 
structs, and follows the same pattern as key/value map/dictionaries. The 
adherence to this type first in C makes those structures also harder to 
read.

On Friday, 21 September 2018 03:08:57 UTC+2, Rob 'Commander' Pike wrote:
>
> PL/I is unmatched.
>
> -rob
>
>
> On Fri, Sep 21, 2018 at 10:13 AM Drew Derbyshire  > wrote:
>
>> On Wednesday, September 19, 2018 at 10:30:11 PM UTC-7, Sathish VJ wrote:
>>>
>>> I've been asked this question a few times and I haven't been able to 
>>> find an answer.  Why does go reverse the order of variable declaration:  "i 
>>> int" vs "int i"
>>>
>>
>> To match PL/I, of course.   :-)
>>
>> -ahd-
>>
>> -- 
>> 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.

Re: [go-nuts] Re: why does go reverse the order of name and type? "i int" vs "int i"

['Thomas Bushnell, BSG' via golang-nuts]

On Fri, Sep 21, 2018 at 11:07 AM Louki Sumirniy <
louki.sumirniy.stal...@gmail.com> wrote:

> in programming languages putting the type first basically only appears in
> C and its (ill-born) children.
>

Like that's literally wrong. I prefer Go's order, which borrows from Pascal.

But C's order is the same as Algol's, which is the same as FORTRAN's.

Go's and Pascal's order is, however, the same as COBOL.

Thomas

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

[Louki Sumirniy]

This is something that I have seriously considered to be the right way for 
Go to express other generic types. I am in fact in the middle of a project 
at the moment where I have created a pair of generic byte buffer types, one 
is the regular kind, the other uses memguard locked buffers, for keeping 
secrets out of reach of other processes on a system.

A lot of the complaints that lead to the idea of creating a generics system 
in Go tend to start from the absence of a few basic types. One is the set, 
and in particular the union operator. However, it is trivial to implement 
various types of sets and set operations based on maps or slices, and more 
often than not you save absolutely no time predeclaring a framework when 
you can just embed a number of other structs inside a type as well as by 
implementing or composing in interface implementations.

But knowing from having done quite a bit of study of data structures, being 
one of my favourite subjects, that one-size-fits-all only really happens in 
a very small number of cases. Hash table indexes like used to make maps, 
arrays and slices, but binary trees, since someone mentioned it, these have 
many different forms, as dictated by their application. You have heaps and 
you have trees, the former are better for queues and the latter for 
optimising searches. There is several ways to implement them. You have 
B-trees, btrees, red/black, B-heaps, AVL, and so on and so on. These are 
not really subject matter for basic language types, though the language 
might improve their use and readability with a number of special keywords 
and declaration types.

I think that the solutions to most of the problems lies in embedding error 
status into every type (except maybe machine-sized integers), a conditional 
return statement that allows you you to handle errors concisely within a 
statement block, and possibly some kind of built-in addition, in addition 
to the universal error status flag, which integrates some kind of 
configurable serialisation function for wire and storage. There is many 
options already available, but to make it simpler to invoke 'freeze' and 
'thaw' functions, which provides a data format that can optionally contain 
type metadata and enable this data to become, no matter what its' type, an 
object that any other function can pass around and as required see and 
access parts of the data that relate to the interface.

Very small changes, is what I am suggesting. Implicit error type in all but 
integers, a conditional break/return function (probably one for each) and 
more generally what I am suggesting is extend the built in 'error' 
interface to add set, unset and serialise/deserialise functions. And maybe 
a built-in structured logger that lets you track the state of all variables 
as each function operates on it, but only automatically in case of throwing 
an error.

I think that go almost already perfectly implements the generic type 
[]byte. Everything can be turned into []byte and []byte can encode any 
other variable.

Go is absolutely a leader in the programming language field. I just saw 
yesterday a blog post about 'new features in C++17' or whatever, 'that 
simplify your code'. Every single feature already in Go, the optional first 
statement in the 'if' structure, type inference through assignment to 
constants, and somethting else I forget. In every area of the core 
language, Go uses a pattern that is both simpler and more powerful than you 
find in most other languages, and that can trivially express many other 
patterns usually in a far more concise yet readable manner.

The changes for version 2, in my opinion, should first identify the real 
meat of the issues that people point at their previous language experiences 
to talk about, but go far deeper to decisions about syntax that are in many 
cases now quite obsolete concerns. In the old days, every byte was so 
expensive. The price is very low now and basically seems to be flattening 
out, so people are slowly starting to realise that certain conventions were 
only based on this bit-conservation.

Another issue has to do with creating brittle codebases with excessive need 
for copy and paste to implement something where in each instance the code 
only differs by the type of only one variable, that is functionally the 
same only differing in such as the number of bytes it can encode, sign, or 
any arbitrary number of other groupings of elements. Go's interfaces and 
embedding go a long way to neaten this up but this really is at the centre 
of what needs to be improved, and before anyone actually changes the 
language, explore the ways of expressing the pattern in go to see if the 
solution might just be idiom rather than syntax. Most of Go's idiom has 
been quite certain and settled and you don't take long to see by violating 
it what extra work and complexity you create. I have pretty high confidence 
in the Go Authors rejecting all but the simplest, and most expressi

[go-nuts] Improving Go's error handling syntax

[Louki Sumirniy]

I think that the issue with dealing with multiple conditions and certain 
pre-defined response patterns is at the centre of the error handling 
problems.

My suggestion is here: https://github.com/golang/go/issues/27794 and 
centers around extensions of the return and switch syntax.

The solution I am suggesting is adding a conditional to return statements 
(tacking on the head of an `if` statement to the end of a return), a 
multiple return case structure that resembles a map literal declaration, 
and adding another (maybe 'if') header to switch blocks for implicit 
fallthrough. Switch blocks already have 'case' and 'default', I am 
suggesting add 'if' to be a 'fallthrough' block. The conditional returns 
are because very often the main response to an error is to either panic or 
return an error value, but only in a particular case. I think if the if 
syntax is fully repeated (except with the statement only being between the 
return and if), this also means being able to use the `..., ok ` which 
would serve to act as a shorter version of a type switch for interface{} 
variables. For this maybe a special syntax as well.

I think that with these changes in place, a lot of the reasons for wanting 
generics would also be reduced. Type switches are a little boilerplatey and 
the lack of a conditional return means you have to often write a lot more 
lines of code, often involving if statements, when maybe your function only 
wants to handle one type (for now) and a default case. The most direct 
cognate in Go for generics is the interface{}, so making common operations 
and conditional branches around checks, fallthroughs and returns eliminates 
a lot of the wordiness of Go's support for generic typing.

I still don't think generics are needed, as to me the []byte is already 
fully generic. Writing methods that make this easy, and designing the 
scaffold of interfaces to allow easily welding together two different types 
that work on a (same but differently formatted) similar data type, such as 
really big numbers, or strings of symbols, collections of predefined types 
(without metadata) or typed collections, is not that difficult. The other 
thing is I think that all types more complex than 64 bit integers should 
have an implied error status variable (thus implicitly being a struct), as 
this reduces the need to use chain-breaking tuple returns.

Actually, I didn't mention the implied error value in all structured types 
in the issue I made. I have just made my own type that I can embed into 
anything I need to track an error as well as be able to chain simple, 
usually one or zero parameter methods together. I think that this is not a 
language side issue, more to do with a built-in interface. I think 'error' 
should also have metadata- and non-metadata serialisation functionality 
built in as well as set and clear functions. The serialisation functions 
can be easily overridden - when I talk about how in many cases solutions to 
issues in Go have to do with understanding the right pattern to use for a 
particular situation, that eliminates the need for a change in the syntax. 
It seems to me this is how the Go authors look at these things too - the 
cost of increasing compilation complexity, reducing interactivity and 
basically just wasting time, over issues of structure and readability that 
are just a lack of knowledge, in fact... so I think that these kinds of 
changes, as I am suggesting, are the more likely to be finally chosen, as 
they extend patterns a go programmer is already familiar with, they don't 
substantially change the parsing complexity. They keep in the same vein and 
continue consistent patterns found elsewhere in the language as well as 
presenting a more simple, but expressive solution than used in other 
languages.

-- 
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] AF_UNIX sockets on Windows in a golang release?

[lars]

Hello,

I'm interested in using the AF_UNIX sockets for Windows support that was 
recently merged into master 
(https://go-review.googlesource.com/c/go/+/125456), but it missed the 
go-1.11 release. Is there a way to tell what release will contain it, and 
if it's possible to know, roughly when that release will come out?

Thanks!
-lars

-- 
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: Why google doesnt make jdbc like library for go?

[ascarrasca]

He has a valid point. Most of the enterprise applications uses Oracle DB. I 
for one is looking for an oracle driver similar to what JDBC does (a simple 
to use, no separate installation needed). All of Go oracle drivers 
available uses Oracle Instant Client. I am currently in a hunt to migrate 
all our Java-based projects to different language. Right now, my options 
are .Net Core 2 and Go. I am more lean to Go in terms of memory footprints, 
but I find it difficult to find the necessary packages/libraries to connect 
to Oracle database.

If Google is very serious to attract enterprises to migrate their projects 
to Go, then I think they should fill those void. Don't expect that 
enterprises will migrate their DBs to PostgreSql or MySQL. That will be a 
big NO for migration.

just my 2 cents. ;)

On Saturday, January 15, 2011 at 2:27:49 AM UTC+9, Jim Teeuwen wrote:
>
> You could also just write your own ;)
>
> Most of the those database wrappers are all community projects. The Go 
> developers have better things to do at this point. Improving the 
> language/runtime trumps third party lib support at this point. This is 
> where the community comes in. If you need support for something, which is 
> not around yet. By all means try to write it yourself and share, so others 
> can benefit from your 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.

[go-nuts] discuss database/sql feature request: add ability to retrieve driver.Driver by registered driver name.

[Bas Van Beek]

The preferred method of working with database/sql is to use registered 
driver names to identify which driver to use for connecting to the database.

OpenCensus  now has instrumentation for database/sql 
by allowing database drivers to be wrapped with the ocsql 
 package.

The most idiomatic way to set-up ocsql 
 is to do something like 
this:

import (
_ "github.com/mattn/go-sqlite3"
"github.com/opencensus-integrations/ocsql"
)

var (
driverName string
errerror
db *sql.DB
)

// Register our ocsql wrapper for the provided SQLite3 driver.
driverName, err = ocsql.Register("sqlite3", ocsql.WithAllTraceOptions())
if err != nil {
log.Fatalf("unable to register our ocsql driver: %v\n", err)
}

// Connect to a SQLite3 database using the ocsql driver wrapper.
db, err = sql.Open(driverName, "resource.db")

Unfortunately database/sql does not have a function to retrieve the 
registered driver.Driver by its driver name, which could look like this:

// DriverByName showsn an example of a function to retrieve a registered 
driver by its name.
func DriverByName(name string) driver.Driver {
driversMu.Lock()
defer driversMu.Unlock()

return drivers[name]
}

So underwater ocsql  does 
the following dirty trick to retrieve the driver.Driver:

func Register(driverName string, options ...TraceOption) (string, error) { 
// retrieve the driver implementation we need to wrap with instrumentation
db, err := sql.Open(driverName, "")
if err != nil {
return "", err
}
dri := db.Driver()
if err = db.Close(); err != nil {
return "", err
}

...

}

The problem however is that Go 1.10 introduced the new interface 
DriverContext which, if implemented by a database driver, will make the 
call to sql.Open to retrieve the driver.Driver fail as it can error on the 
call to OpenConnector:

// If a Driver implements DriverContext, then sql.DB will call
// OpenConnector to obtain a Connector and then invoke
// that Connector's Conn method to obtain each needed connection,
// instead of invoking the Driver's Open method for each connection.
// The two-step sequence allows drivers to parse the name just once
// and also provides access to per-Conn contexts.
type DriverContext interface {
// OpenConnector must parse the name in the same format that Driver.Open
// parses the name parameter.
OpenConnector(name string) (Connector, error)
}


If the database driver to wrap with ocsql also does not export its 
driver.Driver implementation it will be not possible to use ocsql.

Would like to hear from the Go team and community if adding a DriverByName 
type function is acceptable given the use case presented above. It would 
surely make ocsql less brittle and better supported.

Cheers,

Bas van Beek

-- 
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: Why google doesnt make jdbc like library for go?

[Ian Davis]

On Fri, 21 Sep 2018, at 3:36 AM, ascarra...@gmail.com wrote:
> He has a valid point. Most of the enterprise applications uses Oracle
> DB. I for one is looking for an oracle driver similar to what JDBC
> does (a simple to use, no separate installation needed). All of Go
> oracle drivers available uses Oracle Instant Client. I am currently in
> a hunt to migrate all our Java-based projects to different language.
> Right now, my options are .Net Core 2 and Go. I am more lean to Go in
> terms of memory footprints, but I find it difficult to find the
> necessary packages/libraries to connect to Oracle database.> 
> If Google is very serious to attract enterprises to migrate their
> projects to Go, then I think they should fill those void. Don't expect
> that enterprises will migrate their DBs to PostgreSql or MySQL. That
> will be a big NO for migration.> 
> just my 2 cents. ;)

Hi. The post you are replying to is seven years old. Since then many
database drivers have been written. Please take a look at
https://github.com/golang/go/wiki/SQLDrivers

-- 
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: Using modules with go test ./...

[John]

Paul, thanks for the explanation.  But I think maybe either I'm missing 
something or I'm not explaining something correctly.

What I would expect with "go test ./..." is behavior similar to what I had 
before modules.  That behavior would be that the go tool would recursively 
run all tests from the directory I am in and below it, regardless if there 
was a package in the current directory. 

I built your example, which works exactly as you expect.  But it doesn't 
solve my issue, which is around "go test ./..." recursively.  As I go back 
up the hierarchy, if I do a go test ./..., it fails.  I could always test 
by just going into the package and running "go test".  I want to be able to 
recursively run tests as the current behavior allows with GOPATH.  If this 
recursive use of "./..." is going away with mod files, then I have to 
adjust to making smart tools.  But I've got to imagine that this isn't the 
intention or that I am still doing something incorrectly. 
 
Additionally, I have also tried to add go.mod files in sub directories that 
contain no go files between the root and the package.  This did not work 
either.

Thanks to everyone (Paul, Dave, Scott) who looked at this.

*Sidenote on my original directory(bug?):*
Interestingly enough, I have made a top level mod file and put a "hello 
world" main.go file.  That did not make this work.
But what looks like a bug is that I deleted both of those files, but if I 
run "go env GOMOD" at src/, I get back a path to a go.mod file that is the 
one I deleted.
Running "go mod tidy" gave the same error, so no auto cleanup
And go init mod also throws the same error.

I'm sure I can clean this up by removing some cached file somewhere.

On Friday, September 21, 2018 at 12:48:13 AM UTC-7, Paul Jolly wrote:
>
> John, 
>
> Scott is on the money with this response: 
>
> > I think you need to have a main module defined so there must be a go.mod 
> in cwd or upwards 
>
> The way to ensure that you are in a valid module context is simply: 
>
> go env GOMOD 
>
> which will return the path to the current (or main) module context 
> (go.mod) if: 
>
> a) you are in module mode (either by being outside of GOPATH or with 
> GO111MODULE=on) and 
> b) there is a go.mod on the directory path from $PWD to the root. 
>
> As you have set GO111MODULE=on you can put your source code pretty 
> much anywhere you like; even within your GOPATH (whether GOPATH is set 
> or not, in the latter case as has been pointed out it defaults to 
> $HOME/go) 
>
> All you are missing is a go.mod file (go end GOMOD would confirm this, 
> and would return "") 
>
> Here's a simple example that shows things working within GOPATH: 
>
> $ export GO111MODULE=on 
> $ export GOPATH=/tmp/tmp.JJgvIDI0Uc 
> $ cd /tmp/tmp.In4INnkIH0 
> $ mkdir -p src/example.com/blah 
> $ cd src/example.com/blah/ 
> $ cat  package main 
> func main() {} 
> EOD 
> $ go env GOMOD 
>
> $ go list 
> go: cannot find main module; see 'go help modules' 
> $ go mod init example.com/blah 
> go: creating new go.mod: module example.com/blah 
> $ go env GOMOD 
> /tmp/tmp.In4INnkIH0/src/example.com/blah/go.mod 
> $ go list 
> example.com/blah 
> $ go test 
> ?   example.com/blah[no test files] 
>
>
> Paul 
>

-- 
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: discuss database/sql feature request: add ability to retrieve driver.Driver by registered driver name.

[Tamás Gulácsi]

Why do you want to wrap the driver? Why not just the db?

2018. szeptember 21., péntek 15:32:40 UTC+2 időpontban Bas Van Beek a 
következőt írta:
>
>
> The preferred method of working with database/sql is to use registered 
> driver names to identify which driver to use for connecting to the database.
>
> OpenCensus  now has instrumentation for 
> database/sql by allowing database drivers to be wrapped with the ocsql 
>  package.
>
> The most idiomatic way to set-up ocsql 
>  is to do something 
> like this:
>
> import (
> _ "github.com/mattn/go-sqlite3"
> "github.com/opencensus-integrations/ocsql"
> )
>
> var (
> driverName string
> errerror
> db *sql.DB
> )
>
> // Register our ocsql wrapper for the provided SQLite3 driver.
> driverName, err = ocsql.Register("sqlite3", ocsql.WithAllTraceOptions())
> if err != nil {
> log.Fatalf("unable to register our ocsql driver: %v\n", err)
> }
>
> // Connect to a SQLite3 database using the ocsql driver wrapper.
> db, err = sql.Open(driverName, "resource.db")
>
> Unfortunately database/sql does not have a function to retrieve the 
> registered driver.Driver by its driver name, which could look like this:
>
> // DriverByName showsn an example of a function to retrieve a registered 
> driver by its name.
> func DriverByName(name string) driver.Driver {
> driversMu.Lock()
> defer driversMu.Unlock()
>
> return drivers[name]
> }
>
> So underwater ocsql  
> does the following dirty trick to retrieve the driver.Driver:
>
> func Register(driverName string, options ...TraceOption) (string, error) { 
> // retrieve the driver implementation we need to wrap with instrumentation
> db, err := sql.Open(driverName, "")
> if err != nil {
> return "", err
> }
> dri := db.Driver()
> if err = db.Close(); err != nil {
> return "", err
> }
>
> ...
>
> }
>
> The problem however is that Go 1.10 introduced the new interface 
> DriverContext which, if implemented by a database driver, will make the 
> call to sql.Open to retrieve the driver.Driver fail as it can error on the 
> call to OpenConnector:
>
> // If a Driver implements DriverContext, then sql.DB will call
> // OpenConnector to obtain a Connector and then invoke
> // that Connector's Conn method to obtain each needed connection,
> // instead of invoking the Driver's Open method for each connection.
> // The two-step sequence allows drivers to parse the name just once
> // and also provides access to per-Conn contexts.
> type DriverContext interface {
> // OpenConnector must parse the name in the same format that Driver.Open
> // parses the name parameter.
> OpenConnector(name string) (Connector, error)
> }
>
>
> If the database driver to wrap with ocsql also does not export its 
> driver.Driver implementation it will be not possible to use ocsql.
>
> Would like to hear from the Go team and community if adding a DriverByName 
> type function is acceptable given the use case presented above. It would 
> surely make ocsql less brittle and better supported.
>
> Cheers,
>
> Bas van Beek
>
>

-- 
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: Why google doesnt make jdbc like library for go?

[Tamás Gulácsi]

Oracle does not publish the specification of its SQL.Net protocol, so no 
clean room implementation is possible.
Either Oracle provides such a driver, or you have to use what it provides: 
OCI.

A small help in the right direction is github.com/oracle/odpi and 
gopkg.in/goracle.v2 - it does NOT need the InstantClient at compile time, 
only at runtime.
And it is a standard dtabase/sql driver, allowing everything through the 
standard interface.

2018. szeptember 21., péntek 15:32:40 UTC+2 időpontban Alvin Carrasca a 
következőt írta:
>
> He has a valid point. Most of the enterprise applications uses Oracle DB. 
> I for one is looking for an oracle driver similar to what JDBC does (a 
> simple to use, no separate installation needed). All of Go oracle drivers 
> available uses Oracle Instant Client. I am currently in a hunt to migrate 
> all our Java-based projects to different language. Right now, my options 
> are .Net Core 2 and Go. I am more lean to Go in terms of memory footprints, 
> but I find it difficult to find the necessary packages/libraries to connect 
> to Oracle database.
>
> If Google is very serious to attract enterprises to migrate their projects 
> to Go, then I think they should fill those void. Don't expect that 
> enterprises will migrate their DBs to PostgreSql or MySQL. That will be a 
> big NO for migration.
>
> just my 2 cents. ;)
>
> On Saturday, January 15, 2011 at 2:27:49 AM UTC+9, Jim Teeuwen wrote:
>>
>> You could also just write your own ;)
>>
>> Most of the those database wrappers are all community projects. The Go 
>> developers have better things to do at this point. Improving the 
>> language/runtime trumps third party lib support at this point. This is 
>> where the community comes in. If you need support for something, which is 
>> not around yet. By all means try to write it yourself and share, so others 
>> can benefit from your 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.

[go-nuts] Re: discuss database/sql feature request: add ability to retrieve driver.Driver by registered driver name.

[Bas Van Beek]

Because we don't want it to proliferate through your entire code base and 
packages as sql.DB is a struct, not an interface. It needs to be completely 
invisible to your code base once set-up. 

On Friday, September 21, 2018 at 5:32:24 PM UTC+2, Tamás Gulácsi wrote:

> Why do you want to wrap the driver? Why not just the db?
>
> 2018. szeptember 21., péntek 15:32:40 UTC+2 időpontban Bas Van Beek a 
> következőt írta:
>>
>>
>> The preferred method of working with database/sql is to use registered 
>> driver names to identify which driver to use for connecting to the database.
>>
>> OpenCensus  now has instrumentation for 
>> database/sql by allowing database drivers to be wrapped with the ocsql 
>>  package.
>>
>> The most idiomatic way to set-up ocsql 
>>  is to do something 
>> like this:
>>
>> import (
>> _ "github.com/mattn/go-sqlite3"
>> "github.com/opencensus-integrations/ocsql"
>> )
>>
>> var (
>> driverName string
>> errerror
>> db *sql.DB
>> )
>>
>> // Register our ocsql wrapper for the provided SQLite3 driver.
>> driverName, err = ocsql.Register("sqlite3", ocsql.WithAllTraceOptions())
>> if err != nil {
>> log.Fatalf("unable to register our ocsql driver: %v\n", err)
>> }
>>
>> // Connect to a SQLite3 database using the ocsql driver wrapper.
>> db, err = sql.Open(driverName, "resource.db")
>>
>> Unfortunately database/sql does not have a function to retrieve the 
>> registered driver.Driver by its driver name, which could look like this:
>>
>> // DriverByName showsn an example of a function to retrieve a registered 
>> driver by its name.
>> func DriverByName(name string) driver.Driver {
>> driversMu.Lock()
>> defer driversMu.Unlock()
>>
>> return drivers[name]
>> }
>>
>> So underwater ocsql  
>> does the following dirty trick to retrieve the driver.Driver:
>>
>> func Register(driverName string, options ...TraceOption) (string, error) 
>> { // retrieve the driver implementation we need to wrap with instrumentation
>> db, err := sql.Open(driverName, "")
>> if err != nil {
>> return "", err
>> }
>> dri := db.Driver()
>> if err = db.Close(); err != nil {
>> return "", err
>> }
>>
>> ...
>>
>> }
>>
>> The problem however is that Go 1.10 introduced the new interface 
>> DriverContext which, if implemented by a database driver, will make the 
>> call to sql.Open to retrieve the driver.Driver fail as it can error on the 
>> call to OpenConnector:
>>
>> // If a Driver implements DriverContext, then sql.DB will call
>> // OpenConnector to obtain a Connector and then invoke
>> // that Connector's Conn method to obtain each needed connection,
>> // instead of invoking the Driver's Open method for each connection.
>> // The two-step sequence allows drivers to parse the name just once
>> // and also provides access to per-Conn contexts.
>> type DriverContext interface {
>> // OpenConnector must parse the name in the same format that Driver.Open
>> // parses the name parameter.
>> OpenConnector(name string) (Connector, error)
>> }
>>
>>
>> If the database driver to wrap with ocsql also does not export its 
>> driver.Driver implementation it will be not possible to use ocsql.
>>
>> Would like to hear from the Go team and community if adding a 
>> DriverByName type function is acceptable given the use case presented 
>> above. It would surely make ocsql less brittle and better supported.
>>
>> Cheers,
>>
>> Bas van Beek
>>
>>

-- 
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] database/sql/driver: how to return *sql.Rows?

[Tamás Gulácsi]

For the discussion, see 
https://groups.google.com/forum/#!topic/golang-sql/HNvcgScdyt8

TL;DR Oracle may return a cursor (resultset, rows), but the driver cannot 
turn it into a proper *sql.Rows with the nice Scan functionality.
I've found a hack (make the driver return the driver.Rows in a Query call), 
but don't know whether there is a better way or not.

Any ideas?

Thanks in advance,
Tamás Gulácsi

-- 
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: A simplified generics constraint system.

[alanfo]

Thanks to all those who have had the patience to read this proposal and 
made comments on, or criticisms of, it.

Having carefully considered the points made, I have concluded that the 
current proposal falls short in two important respects:

1. It doesn't deal adequately with numeric precision and/or signed-ness.

2. It's incomplete in that it doesn't deal with types based on string or 
bool. Nor does it deal with the inter-convertible types: string/[]bool or 
string/[]rune which would be useful in practice.

Now a combination of my 'union' and 'except' assertions would address both 
of these criticisms. However, I have decided that these are too complicated 
and could lead to some difficult scenarios for the compiler or human reader 
to sort out. 

Although I still subscribe to the view that: "a simple to use and 
understand solution that covers 90% is better than a complex one to cover 
100%", I think this proposal can (and should) do much better than that - 
close to full coverage of *realistic* scenarios - while retaining its 
essential simplicity.

I have therefore decided to make the following changes to the proposal:

1. The 'union' assertion idea has been dropped completely.

2. Instead, the number of built-in contracts has been augmented by the 
following:

   * Boolean - any boolean type
   * String - any string type
   * Bytes - any string type or byte slice.
   * Runes - any string type or rune slice

This brings the number of built-in contracts up to 10 which is a lot but 
worthwhile, IMO, because of the extra expressiveness it will bring.

I continue to take the view that complex types are best segregated from the 
other numeric types for the reasons I originally gave in the proposal and 
also because to do otherwise would require, for completeness, the addition 
of 3 more built-in contracts (Numeric, NonInteger and Addable).
 
3. The 'except' constraint idea has been adopted but in a much restricted 
form: it will only be able to list built-in numeric types which are to be 
excluded from the contract. 

To be consistent with the built-in contracts, excluded types will be deemed 
to include defined types with the same underlying type.

The name will be changed to 'omit' which I think expresses its intent more 
clearly.

'omit' will enable us to deal properly with numeric types and, in 
particular, it will now be possible to build both 'Unsigned' and 'Signed' 
contracts from the Integer contract and also to disallow smaller integer 
types (such as int8 and uint8) where necessary. 

So that's a summary of what's changed and the revised proposal is still 
available at the same link:
https://gist.github.com/alanfo/fb2438f376dac0db3be5664702f39aab

As I said earlier, I hope Ian can make the draft design work (possibly with 
some simplifications in the light of feedback) but, if he can't, then I 
believe this proposal - which addresses the problem of 
operators/conversions in a different way - would be a plausible alternative.

I'll shut up now (where have I heard that before)!

Alan

 On Friday, September 14, 2018 at 11:32:29 AM UTC+1, alanfo wrote:
>
> It's now more than a fortnight since the Go 2 Draft Generics Design was 
> published and, like many others, I have spent considerable time:
>
> 1. Steeped in discussions about the draft.
>
> 2. Reading feedback papers by others (Roger Peppe's are particularly 
> illuminating) most of whom share my opinion that 'contracts' are 
> unsatisfactory and should be replaced, amended or simplified in various 
> ways.
>
> 3. Attempting to devise a workable alternative to contracts (as envisaged 
> in the draft) myself.
>
> I was then brought back to reality by this post by Robert Engels in the 
> 'Generics - Why contracts?' thread:
>  
> "As I’ve said elsewhere, a SIMPLE to use and understand solution that 
> covers 90% is better than a complex one to cover 100% IMO, and fits in well 
> with the rest of Go design. Go leaves out a lot - and it's a good choice."
>
> This convinced me that the draft design itself and many third party 
> proposals (including my own) were too ambitious and what we needed was 
> something much simpler that gave us 90% coverage and which everybody could 
> understand. 
>
> So I've added a simplified proposal to the feedback page which I feel 
> meets this more limited aim. For anyone interested, here's the link:
>
> https://gist.github.com/alanfo/fb2438f376dac0db3be5664702f39aab
>
> Although the new proposal is largely a simplified version of my 'full fat' 
> proposal, the paper itself is much more comprehensive as I've included 
> notes on why I think certain contracts should be built-in (but not others) 
> and have also tried to address the problems that were raised in the draft 
> design and overview papers themselves. 
>
> Any comments or constructive criticism are of course welcome.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop re

Re: [go-nuts] Re: Using modules with go test ./...

[thepudds1460]

> "What I would expect with 'go test ./...' is behavior similar to what 
I had before modules."

Hi John, all,

Just to expand slightly on the points from Dave, Scott, and Paul...

I suspect part of what you are encountering is that in general:

  1. Modules are opt-in for Go 1.11, so by design old behavior is preserved 
by default. This has a few implications, including you get old behavior by 
default inside GOPATH, but that only applies if you haven't explicitly 
forced non-default behavior via GO111MODULE. (In your case, you started 
with GO111MODULE=on set, so that is part of why you are not seeing the old 
behavior you are used to).
  
  2. Most of the modules-specific behavior requires that you be "inside" a 
module (that is, inside a file tree with a go.mod).
  
A consequence of #2 is that if you explicitly ask for modules-specific 
behavior (e.g., via setting GO111MODULE=on) but are *not* inside a file 
tree with a 'go.mod' file, then you might see an error message that 
effectively tells you need to be inside a module. In your case, I think 
that is why you saw the error "go: cannot determine module path for source 
directory" when you tried one of your early go commands with GO111MODULE=on 
but were outside of a file tree with a 'go.mod' file.

In addition, I think in a module-world, something like 'go test ./...' only 
tests the active module(s), and won't traverse down into an unrelated 
module that happens to be in a sub-directory of the current module. I 
believe the doc says that explicitly for a '...' pattern appearing in 'go 
list', and I think that is true beyond just 'go list', at least as far as I 
am aware:

>From https://tip.golang.org/cmd/go/#hdr-List_packages_or_modules 'go list' 
documentation:

  "The main module is the module containing the current directory. The 
active modules are the main module and its dependencies."

and

  "The special pattern "all" specifies all the active modules, first the 
main module and then dependencies sorted by module path. A pattern 
containing "..." specifies the active modules whose module paths match the 
pattern."

I think that explains at least one of the examples you sent where 'go test 
./...' did not work as you expected when modules were enabled (because in 
module-mode, './...' won't match modules that are not dependencies of the 
current module, even if they are in sub-directories, because they would not 
be part of the current "active modules").

One related item I'll mention is that a nice part of the modules work is 
that 'go test all' has been re-defined to be more useful to include all the 
packages in the current module, plus all the packages they depend on (in 
other words, all direct and indirect dependencies of the current module).  
If you want to test the current module and all of its dependencies, 'go 
test all' would do that (rather than 'go test ./...').

In any event, I am just a member of the community and we are all still 
learning about modules, so I would be happy to learn if any of what I 
outlined above doesn't line up with what you are seeing...

Finally, I'm not sure what would be going on with the last piece you 
reported where 'go env GOMOD' returned the path to a deleted 'go.mod' file.

Best,
thepudds

On Friday, September 21, 2018 at 11:31:44 AM UTC-4, John wrote:
>
> Paul, thanks for the explanation.  But I think maybe either I'm missing 
> something or I'm not explaining something correctly.
>
> What I would expect with "go test ./..." is behavior similar to what I had 
> before modules.  That behavior would be that the go tool would recursively 
> run all tests from the directory I am in and below it, regardless if there 
> was a package in the current directory. 
>
> I built your example, which works exactly as you expect.  But it doesn't 
> solve my issue, which is around "go test ./..." recursively.  As I go back 
> up the hierarchy, if I do a go test ./..., it fails.  I could always test 
> by just going into the package and running "go test".  I want to be able to 
> recursively run tests as the current behavior allows with GOPATH.  If this 
> recursive use of "./..." is going away with mod files, then I have to 
> adjust to making smart tools.  But I've got to imagine that this isn't the 
> intention or that I am still doing something incorrectly. 
>  
> Additionally, I have also tried to add go.mod files in sub directories 
> that contain no go files between the root and the package.  This did not 
> work either.
>
> Thanks to everyone (Paul, Dave, Scott) who looked at this.
>
> *Sidenote on my original directory(bug?):*
> Interestingly enough, I have made a top level mod file and put a "hello 
> world" main.go file.  That did not make this work.
> But what looks like a bug is that I deleted both of those files, but if I 
> run "go env GOMOD" at src/, I get back a path to a go.mod file that is the 
> one I deleted.
> Running "go mod tidy" gave the same error, so no auto cleanup
> And go init mod

[go-nuts] Re: go mobile android release?

[Damien Radtke]

Only thing I can think of would be to define build tags for each Android 
version, and then pass that through to gomobile.

On Thursday, September 20, 2018 at 4:07:18 PM UTC-5, Scott Cotton wrote:
>
> Howdy Gophers,
>
> Noob question for go mobile.  I was wondering if anyone knows a good way 
> to conditionally compile for native android apps based on the android 
> version?   (build tag android is too general for something I'm working on 
> as is the the range of supported versions in gomobile build).
>
> Best,
> Scott
>
>

-- 
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] x/mobile: forcing IntelliJ to fully reload changes to AAR

[Damien Radtke]

I've been playing around with building an Android application using Go by 
binding the Go code into an AAR library that Android can use: 
https://github.com/golang/go/wiki/Mobile#building-and-deploying-to-android-1

I've come up with a successful build setup that utilizes the gobind gradle 
plugin and an "implementation files(...)" line, but I'm not able to easily 
reload changes to the Go source code. Simply rerunning the gobind task does 
nothing, so I have to take the following steps to ensure that changes are 
noticed:

1. Delete the existing AAR file
2. Rerun gobind
3. Ensure Gradle changes are synced

I'm trying to find an easy way to consolidate these three steps into one, 
but I've not had any luck so far. I tried defining a custom gradle task 
that performs at least steps 1 and 2, but for some reason that causes a 
gradle sync to also delete the library, which thereby causes the build to 
fail.

Anyone have any tips on how to do this? The setup in the mobile's example 
repository seems to be even harder to reload changes, since there I had to 
comment out the "implementation project(...)" line, sync, uncomment, and 
resync.

-- 
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: Using modules with go test ./...

[John]

Thanks for the reply.  Other that the bug I encountered, this seems to be 
the behavior.

This new "mod" behavior for ./... at least for "go test" seems to be a step 
backwards.  It assumes a kind of test methodology based around a certain 
type of file layout.
If I am at the top of my src/ and I want to test everything underneath, I 
can't without adding some tooling.  I have to go inside a specific module.  
It is nice that it will now test dependencies.  I'm somewhat lost to why 
the go tool would need to change the behavior for "go test ./...", seems 
like adding go.mod wouldn't require this change.  

I imagine I might be in the minority in using test this way.  Its useful 
when you have a small monorepo to do tests.  People who run large monorepos 
must have advanced tooling and individual modules won't notice the behavior 
change.  

But this thread was about if this was expected, not if I think it should be 
changed (I can always open a bug, see if anyone else agrees).  It turns out 
I'm not doing something wrong per say, its just that it doesn't do what I 
want.  I need to adjust my expectations.


On Friday, September 21, 2018 at 11:05:28 AM UTC-7, thepud...@gmail.com 
wrote:
>
> > "What I would expect with 'go test ./...' is behavior similar to 
> what I had before modules."
>
> Hi John, all,
>
> Just to expand slightly on the points from Dave, Scott, and Paul...
>
> I suspect part of what you are encountering is that in general:
>
>   1. Modules are opt-in for Go 1.11, so by design old behavior is 
> preserved by default. This has a few implications, including you get old 
> behavior by default inside GOPATH, but that only applies if you haven't 
> explicitly forced non-default behavior via GO111MODULE. (In your case, you 
> started with GO111MODULE=on set, so that is part of why you are not seeing 
> the old behavior you are used to).
>   
>   2. Most of the modules-specific behavior requires that you be "inside" a 
> module (that is, inside a file tree with a go.mod).
>   
> A consequence of #2 is that if you explicitly ask for modules-specific 
> behavior (e.g., via setting GO111MODULE=on) but are *not* inside a file 
> tree with a 'go.mod' file, then you might see an error message that 
> effectively tells you need to be inside a module. In your case, I think 
> that is why you saw the error "go: cannot determine module path for source 
> directory" when you tried one of your early go commands with GO111MODULE=on 
> but were outside of a file tree with a 'go.mod' file.
>
> In addition, I think in a module-world, something like 'go test ./...' 
> only tests the active module(s), and won't traverse down into an unrelated 
> module that happens to be in a sub-directory of the current module. I 
> believe the doc says that explicitly for a '...' pattern appearing in 'go 
> list', and I think that is true beyond just 'go list', at least as far as I 
> am aware:
>
> From https://tip.golang.org/cmd/go/#hdr-List_packages_or_modules 'go 
> list' documentation:
>
>   "The main module is the module containing the current directory. The 
> active modules are the main module and its dependencies."
>
> and
>
>   "The special pattern "all" specifies all the active modules, first the 
> main module and then dependencies sorted by module path. A pattern 
> containing "..." specifies the active modules whose module paths match the 
> pattern."
>
> I think that explains at least one of the examples you sent where 'go test 
> ./...' did not work as you expected when modules were enabled (because in 
> module-mode, './...' won't match modules that are not dependencies of the 
> current module, even if they are in sub-directories, because they would not 
> be part of the current "active modules").
>
> One related item I'll mention is that a nice part of the modules work is 
> that 'go test all' has been re-defined to be more useful to include all the 
> packages in the current module, plus all the packages they depend on (in 
> other words, all direct and indirect dependencies of the current module).  
> If you want to test the current module and all of its dependencies, 'go 
> test all' would do that (rather than 'go test ./...').
>
> In any event, I am just a member of the community and we are all still 
> learning about modules, so I would be happy to learn if any of what I 
> outlined above doesn't line up with what you are seeing...
>
> Finally, I'm not sure what would be going on with the last piece you 
> reported where 'go env GOMOD' returned the path to a deleted 'go.mod' file.
>
> Best,
> thepudds
>
> On Friday, September 21, 2018 at 11:31:44 AM UTC-4, John wrote:
>>
>> Paul, thanks for the explanation.  But I think maybe either I'm missing 
>> something or I'm not explaining something correctly.
>>
>> What I would expect with "go test ./..." is behavior similar to what I 
>> had before modules.  That behavior would be that the go tool would 
>> recursively run all tests from the directory I am in 

[go-nuts] Re: Golang, how dare you handle my checks! (Critique of error proposal)

[Liam]

See also this comprehensive list of possible Go 2 error handling 
requirements on golang-dev:

https://groups.google.com/d/topic/golang-dev/4x7Fv_wIiZg/discussion


On Monday, September 10, 2018 at 6:11:16 AM UTC-7, Liam wrote:
>
>
> "Golang, how dare you handle my checks!"
> A Critique of the Go check/handle Error Proposal
>
>
> https://medium.com/@mnmnotmail/golang-how-dare-you-handle-my-checks-d5485f991289
>
>

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

[Lucio]

On Friday, 21 September 2018 11:52:40 UTC+2, Louki Sumirniy wrote:
>
> This is something that I have seriously considered to be the right way for 
> Go to express other generic types. I am in fact in the middle of a project 
> at the moment where I have created a pair of generic byte buffer types, one 
> is the regular kind, the other uses memguard locked buffers, for keeping 
> secrets out of reach of other processes on a system.
>
>
>> I like this exposition and I think it has inspired me to a realisation I 
have not seen mentioned in the many discussions I have tried to follow, 
namely that the existing generics in Go - numeric operators and  few 
special-purpose intrinsic functions, have a common property: only a very 
few operands, something that user generics will no doubt not be restricted 
to.

In other words, there is an overarching "contract" involved that enforces 
"simplicity". I don't know what the designers of a generic polymorphism 
paradigm can make of that, but I'm sure that much of the blood, sweat and 
tears shed so far have been caused in an attempt to extend the complexity  
of "generics" in addition to the scope of the receiver, arguments and 
result lists.

I hope this is helpful.

The other thought I had, but is very poorly baked, is that the "essence" of 
polymorphism in Go operators is analogous to the informal definition of 
interfaces: it can be determined by the compiler, even though it is not 
expressed in a formal notation (the magic of super-types like for example 
"numerics" to which the addition operator applies).

In a nutshell, defining a polymorphic function would entail omitting 
explicit type qualifications entirely and allowing the compiler to 
determine compatibility from the use of polymorphic operators and 
consequently rejecting combinations that, like in interfaces, do not fit 
permissible combinations of such operators. Lack of implicit conversions is 
then the remaining problem and I have not found (or even sought) a solution 
to that, but others' vision will no doubt be further reaching than my own.

I'm sorry if I'm not expressing my ideas very clearly, this is stretching 
my understanding somewhat.

-- 
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] How can I run a method in a subprocess in golang?

['ggyft' via golang-nuts]

My use case is that I am designing a scheduler that schedules various 
health checks (go method) periodically. Earlier I want to model run them in 
a new goroutine. But I ran into problems when I want to design timeout for 
each method. Basically go seems not able to kill goroutine and clean up 
resources like socket etc.

I am wondering rather than run method in goroutine, can I run it in 
subprocess so I can kill it safely? My platform is windows hope that 
doesn't matter.

-- 
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: x/mobile: forcing IntelliJ to fully reload changes to AAR

[Elias Naur]

Hi,

Since the gradle has no maintaner anymore 
(https://github.com/golang/go/issues/25314) so I deleted its mention from 
the Wiki page.

I think you're better off not using the plugin and manually rebuild the AAR 
file with gomobile bind.

 - elias

On Friday, September 21, 2018 at 8:13:20 PM UTC+2, Damien Radtke wrote:
>
> I've been playing around with building an Android application using Go by 
> binding the Go code into an AAR library that Android can use: 
> https://github.com/golang/go/wiki/Mobile#building-and-deploying-to-android-1
>
> I've come up with a successful build setup that utilizes the gobind gradle 
> plugin and an "implementation files(...)" line, but I'm not able to easily 
> reload changes to the Go source code. Simply rerunning the gobind task does 
> nothing, so I have to take the following steps to ensure that changes are 
> noticed:
>
> 1. Delete the existing AAR file
> 2. Rerun gobind
> 3. Ensure Gradle changes are synced
>
> I'm trying to find an easy way to consolidate these three steps into one, 
> but I've not had any luck so far. I tried defining a custom gradle task 
> that performs at least steps 1 and 2, but for some reason that causes a 
> gradle sync to also delete the library, which thereby causes the build to 
> fail.
>
> Anyone have any tips on how to do this? The setup in the mobile's example 
> repository seems to be even harder to reload changes, since there I had to 
> comment out the "implementation project(...)" line, sync, uncomment, and 
> resync.
>

-- 
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] Adding packages for the lang

[Hunter Breathat]

Hey does anyone know if we can request commits to add some basic 
Functionality to the lang core 
ex. A Node struct? Or a PriorityQueue?

Jw As they are some pretty common structs that used and was just wondering. 
I know we could host them on our own git{github,gitlab, git platfrom}. But 
is there a way to possibly submit some additions.

Thanks in advance and sorry if it sounds like a dumb question.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Adding packages for the lang

[Dave Cheney]

Additions to the language are handled via a written proposal process.

https://github.com/golang/proposal/blob/master/README.md

-- 
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] How can I run a method in a subprocess in golang?

[Justin Israel]

On Sat, Sep 22, 2018, 8:24 AM 'ggyft' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> My use case is that I am designing a scheduler that schedules various
> health checks (go method) periodically. Earlier I want to model run them in
> a new goroutine. But I ran into problems when I want to design timeout for
> each method. Basically go seems not able to kill goroutine and clean up
> resources like socket etc.
>

Rather than thinking about it as a lack of having a first class kill
command for goroutines, you need to run your goroutines in a way that the
work can be stopped. This can be accomplished with a Context that can be
closed or times out, or a channel that receives a stop signal, or even an
atomic that can be checked periodically. The work within the goroutine has
to be aware of stop conditions.

> I am wondering rather than run method in goroutine, can I run it in
> subprocess so I can kill it safely? My platform is windows hope that
> doesn't matter.
>

There is nothing stopping you from running health checks as separate
command as long as you have something to call.

-- 
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> 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: Generic alternatives: new basic types?

[Michael Jones]

these seem excellent points all around.

one area of difficulty seems to me the lack of operator overloading. now,
hold your breath, i'm not arguing for it here. but it highlights a kind of
structural issue that is in the air around the discussion of generics.
consider:

i instantiate a tree type to handle uin64 data. under the proposal, this
should work because guards assert that the type proposed must allow "==" to
be used.

i instantiate with some custom type that needs its own custom
"isEqual(a,b)" -- that will not instantiate because there is no "=="
operator for my custom type, even though there is an equality tester but
its name is not "==" and i can't overload "Operator==" to say so.


this is not an argument for operator overloading but rather the observation
that what the generic tree code actually wants is not an "==" for
instantiated types but the more general and less specific notion of "what
can i call to determine equivalence?"

one way is to have operator overloading so my type has equivalence testing
under a standard name. (==)

one way is to instantiate with the type name and a "test for equal"
function pointer that when nil means "just use =="

one way is to annotate my type's "isEqual()" a la json annotation with a
hint saying "use this for equality testing"


there may be many ways. but it seems generics would be simpler and more
generic if there was a way to be clear about such things. that is, to be
generic we want to ignore inessential differences in instantiation, but
extraneous difference (the name of equality testing) makes the essential
and inessential more confused.

On Fri, Sep 21, 2018 at 1:15 PM Lucio  wrote:

>
>
> On Friday, 21 September 2018 11:52:40 UTC+2, Louki Sumirniy wrote:
>>
>> This is something that I have seriously considered to be the right way
>> for Go to express other generic types. I am in fact in the middle of a
>> project at the moment where I have created a pair of generic byte buffer
>> types, one is the regular kind, the other uses memguard locked buffers, for
>> keeping secrets out of reach of other processes on a system.
>>
>>
>>> I like this exposition and I think it has inspired me to a realisation I
> have not seen mentioned in the many discussions I have tried to follow,
> namely that the existing generics in Go - numeric operators and  few
> special-purpose intrinsic functions, have a common property: only a very
> few operands, something that user generics will no doubt not be restricted
> to.
>
> In other words, there is an overarching "contract" involved that enforces
> "simplicity". I don't know what the designers of a generic polymorphism
> paradigm can make of that, but I'm sure that much of the blood, sweat and
> tears shed so far have been caused in an attempt to extend the complexity
> of "generics" in addition to the scope of the receiver, arguments and
> result lists.
>
> I hope this is helpful.
>
> The other thought I had, but is very poorly baked, is that the "essence"
> of polymorphism in Go operators is analogous to the informal definition of
> interfaces: it can be determined by the compiler, even though it is not
> expressed in a formal notation (the magic of super-types like for example
> "numerics" to which the addition operator applies).
>
> In a nutshell, defining a polymorphic function would entail omitting
> explicit type qualifications entirely and allowing the compiler to
> determine compatibility from the use of polymorphic operators and
> consequently rejecting combinations that, like in interfaces, do not fit
> permissible combinations of such operators. Lack of implicit conversions is
> then the remaining problem and I have not found (or even sought) a solution
> to that, but others' vision will no doubt be further reaching than my own.
>
> I'm sorry if I'm not expressing my ideas very clearly, this is stretching
> my understanding somewhat.
>
> --
> 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.
>


-- 

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

Re: [go-nuts] Golang, how dare you handle my checks! (Critique of error proposal)

[Sameer Ajmani]

That's quite an interesting wiki page, thanks for sharing.

On Thu, Sep 13, 2018 at 2:46 PM Liam Breck  wrote:

> The contents of the feedback wiki are interesting. The Go 2 error proposal
> hasn't seen much support, and there are lots of counter-proposals...
>
> https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback
>
>
> On Mon, Sep 10, 2018, 6:11 AM Liam  wrote:
>
>>
>> "Golang, how dare you handle my checks!"
>> A Critique of the Go check/handle Error Proposal
>>
>>
>> https://medium.com/@mnmnotmail/golang-how-dare-you-handle-my-checks-d5485f991289
>>
>> --
> 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] YANG related Go tools/packages

[Tharaneedharan Vilwanathan]

Hi All,

I am trying to get my hands dirty with YANG, converting yang to .proto,
JSON, etc. Can someone give me some pointers on what packages I should try
and/or provide some pointers? I tried to search and use but somehow I have
trouble finding tutorials etc to begin with.

Appreciate your help.

Thanks
dharani

-- 
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: Using modules with go test ./...

[Scott Cotton]

Hi all,

I for one would also consider the interface an improvement if as part of 
making modules work outside of a "main module" included making go test 
./... work
as before.  Perhaps ./... could mean find each top level module in src/ and 
test.

I am not sure what the modules implementors would prefer w.r.t. such 
feedback.  On
the one hand they need it and can't possibly envision how everyone uses the 
tooling,  and
have wisely called it preliminary.

On the other, maybe it's not a bug as modules are defined; also I think 
they have obligated 
themselves to maintaining support for the current functionality, which some 
might not
find fitting to the way they work. For example from golang.org/cmd/go:
"""
We intend to keep revising this support, while preserving compatibility, 
until it can be declared official (no longer preliminary), and then at a 
later point we may remove support for work in GOPATH and the old 'go get' 
command.
"""


This makes it unclear to me at least how to categorise or proceed with 
feedback like John's,
where there is an unexpected error.

I would like to suggest that a tendency towards flexibility in implementing 
the statement above from golang.org 
might allow a more informed basis on which to take modules out of 
preliminary status.  But others
may depend on or like modules behaviour like this.  I have no way of 
knowing.

Also, yes I agree the listing of the deleted go.mod looks like a bug to me 
as well.

Best,
Scott





On Friday, 21 September 2018 21:41:39 UTC+2, John wrote:
>
> Thanks for the reply.  Other that the bug I encountered, this seems to be 
> the behavior.
>
> This new "mod" behavior for ./... at least for "go test" seems to be a 
> step backwards.  It assumes a kind of test methodology based around a 
> certain type of file layout.
> If I am at the top of my src/ and I want to test everything underneath, I 
> can't without adding some tooling.  I have to go inside a specific module.  
> It is nice that it will now test dependencies.  I'm somewhat lost to why 
> the go tool would need to change the behavior for "go test ./...", seems 
> like adding go.mod wouldn't require this change.  
>
> I imagine I might be in the minority in using test this way.  Its useful 
> when you have a small monorepo to do tests.  People who run large monorepos 
> must have advanced tooling and individual modules won't notice the behavior 
> change.  
>
> But this thread was about if this was expected, not if I think it should 
> be changed (I can always open a bug, see if anyone else agrees).  It turns 
> out I'm not doing something wrong per say, its just that it doesn't do what 
> I want.  I need to adjust my expectations.
>
>
> On Friday, September 21, 2018 at 11:05:28 AM UTC-7, thepud...@gmail.com 
> wrote:
>>
>> > "What I would expect with 'go test ./...' is behavior similar to 
>> what I had before modules."
>>
>> Hi John, all,
>>
>> Just to expand slightly on the points from Dave, Scott, and Paul...
>>
>> I suspect part of what you are encountering is that in general:
>>
>>   1. Modules are opt-in for Go 1.11, so by design old behavior is 
>> preserved by default. This has a few implications, including you get old 
>> behavior by default inside GOPATH, but that only applies if you haven't 
>> explicitly forced non-default behavior via GO111MODULE. (In your case, you 
>> started with GO111MODULE=on set, so that is part of why you are not seeing 
>> the old behavior you are used to).
>>   
>>   2. Most of the modules-specific behavior requires that you be "inside" 
>> a module (that is, inside a file tree with a go.mod).
>>   
>> A consequence of #2 is that if you explicitly ask for modules-specific 
>> behavior (e.g., via setting GO111MODULE=on) but are *not* inside a file 
>> tree with a 'go.mod' file, then you might see an error message that 
>> effectively tells you need to be inside a module. In your case, I think 
>> that is why you saw the error "go: cannot determine module path for source 
>> directory" when you tried one of your early go commands with GO111MODULE=on 
>> but were outside of a file tree with a 'go.mod' file.
>>
>> In addition, I think in a module-world, something like 'go test ./...' 
>> only tests the active module(s), and won't traverse down into an unrelated 
>> module that happens to be in a sub-directory of the current module. I 
>> believe the doc says that explicitly for a '...' pattern appearing in 'go 
>> list', and I think that is true beyond just 'go list', at least as far as I 
>> am aware:
>>
>> From https://tip.golang.org/cmd/go/#hdr-List_packages_or_modules 'go 
>> list' documentation:
>>
>>   "The main module is the module containing the current directory. The 
>> active modules are the main module and its dependencies."
>>
>> and
>>
>>   "The special pattern "all" specifies all the active modules, first the 
>> main module and then dependencies sorted by module path. A pattern 
>> containing "..." specifies the active modules w

[go-nuts] Re: YANG related Go tools/packages

[Tamás Gulácsi]

My Google search for "YANG" showed the Wikipedia page as the first result;
that page (https://en.wikipedia.org/wiki/YANG#Implementations) lists 
several language bindings,
goyang (https://github.com/openconfig/goyang) the FIRST,
which has an .proto dumper example, too.

I don't think this needed much Google-Fu...

2018. szeptember 22., szombat 1:40:39 UTC+2 időpontban Tharaneedharan 
Vilwanathan a következőt írta:
>
> Hi All,
>
> I am trying to get my hands dirty with YANG, converting yang to .proto, 
> JSON, etc. Can someone give me some pointers on what packages I should try 
> and/or provide some pointers? I tried to search and use but somehow I have 
> trouble finding tutorials etc to begin with.
>
> Appreciate your help.
>
> Thanks
> dharani
>
>

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

[Lucio De Re]

On 9/22/18, Michael Jones  wrote:
> these seem excellent points all around.
>
> one area of difficulty seems to me the lack of operator overloading. now,
> hold your breath, i'm not arguing for it here. but it highlights a kind of
> structural issue that is in the air around the discussion of generics.
> consider:
>
> i instantiate a tree type to handle uin64 data. under the proposal, this
> should work because guards assert that the type proposed must allow "==" to
> be used.
>
> i instantiate with some custom type that needs its own custom
> "isEqual(a,b)" -- that will not instantiate because there is no "=="
> operator for my custom type, even though there is an equality tester but
> its name is not "==" and i can't overload "Operator==" to say so.
>
>
> this is not an argument for operator overloading but rather the observation
> that what the generic tree code actually wants is not an "==" for
> instantiated types but the more general and less specific notion of "what
> can i call to determine equivalence?"
>
> one way is to have operator overloading so my type has equivalence testing
> under a standard name. (==)
>
That's the APL approach, before operator overloading was invented. It
*nearly* got there, but the concept of "overloading" wasn't
sufficiently evolved yet. Naturally, there are other issues involved
there as well.

> one way is to instantiate with the type name and a "test for equal"
> function pointer that when nil means "just use =="
>
That's an interesting idea that makes a lot of sense in the Go 1
context, but it is a bit of compromise to convention that may have
shortcomings. Or maybe the exact opposite, it may well be the broadest
possible application.

> one way is to annotate my type's "isEqual()" a la json annotation with a
> hint saying "use this for equality testing"
>
This has been my thought for a while: a type is nothing more than a
variable attribute, which in some sense makes a property such as
"testable for equality" just such an analogous attribute for a type.
In fact, then pointers and indexing can also be reduced to analogous
properties and in due course one arrives at "mutable types" and a
whole new way to look at the compiler's job.

I know that's a stretch, but even if Go 2 does not provide for the
full extent of such a step, applying "attributes" to a language's
elements does open opportunities and in a disciplined environment
(which is where Go has the lead, in my opinion), a lot can be achieved
that has been much harder until now (sorry, I can't help being a bit
immodest about these "insights").

>
> there may be many ways. but it seems generics would be simpler and more
> generic if there was a way to be clear about such things. that is, to be
> generic we want to ignore inessential differences in instantiation, but
> extraneous difference (the name of equality testing) makes the essential
> and inessential more confused.
>
I think we've "overloaded" types for a long time without consideration
for the "essence" of a "type". My approach suggests that some
attributes that we use to qualify language elements do not fall
squarely under "type attributes", but need a few additional categories
and the discipline that only formalising them can produce.

Examples would be "immutable", "units" (the Go "time" type is a case
in point) and of course indirection and indexing. There probably are
others, as yet undiscovered, as much as pointers were a novel idea
back in the 1960s.

Once we break out of that box, we may desperately need to find ways to
control that genie, though :-).

Lucio.

-- 
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: YANG related Go tools/packages

[Tharaneedharan Vilwanathan]

Thanks, Tamas! I'll check it out.

Regards
dharani

On Fri, Sep 21, 2018 at 9:32 PM Tamás Gulácsi  wrote:

> My Google search for "YANG" showed the Wikipedia page as the first result;
> that page (https://en.wikipedia.org/wiki/YANG#Implementations) lists
> several language bindings,
> goyang (https://github.com/openconfig/goyang) the FIRST,
> which has an .proto dumper example, too.
>
> I don't think this needed much Google-Fu...
>
> 2018. szeptember 22., szombat 1:40:39 UTC+2 időpontban Tharaneedharan
> Vilwanathan a következőt írta:
>>
>> Hi All,
>>
>> I am trying to get my hands dirty with YANG, converting yang to .proto,
>> JSON, etc. Can someone give me some pointers on what packages I should try
>> and/or provide some pointers? I tried to search and use but somehow I have
>> trouble finding tutorials etc to begin with.
>>
>> Appreciate your help.
>>
>> Thanks
>> dharani
>>
>> --
> 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: Generic alternatives: new basic types?

[Lucio De Re]

"Google ate my homework, sir!"

Let me try again...

On 9/22/18, Ian Denhardt  wrote:
>
> This is a very good insight. There's no technical reason why Go couldn't
> define a built-in interface, much like `error`, for various operators,
> e.g.
>
> type adder(type T) interface {
> Add(T) T
> }
>
> ..and then the `x + y` just becomes a shorthand for `x.Add(y)`. Note
> that to express this we need the generics, because we need e.g. `int` to
> implement `adder(int)`, while `uint8` implements `adder(uint8)`.
>
This seems itself a very neat approach, in the light of my own intuition.

> Michael Jones's reply articulates a concern that I don't see a clean way
> around other than something like operator overloading: the current
> proposal leaves us with redundant interfaces; you have two ways of
> talking about equality, one for basic types and one for user-defined
> types. Same thing for comparison (people will want to sort both ints and
> user-defined types), and many of the other standard operators.
>
> It seems like the proposal would be massively simplified by operator
> overloading. Many people seem to have a general aversion to the idea,
> but I haven't yet seen the problem articulated in a way that makes sense
> to me. Why is it okay for `Write` to do anything from putting bits on a
> disk, to sending them around the world, to adding them to the state of a
> cryptographic hash function, but not okay for `==` to express equality
> on anything but a small handful of types?
>
> I have a suspicion that for many people (not necessarily), part of the
> concern comes from bad experiences with the way C++ does overloading.
>
The concern I have heard voiced (and agreed with) since the first
release of C++ is that operator overloading creates too great an
opportunity for obfuscation and some may find it irresistible, not
only intentionally, but with malicious intent.

It is a civilising feature of human nature not to release weapons of
mass destruction upon an unsuspecting audience. One also does lose
opportunities in the process and we may be on a cusp right now in
exactly this way.

> One problem is that it allows you to overload essentially *any*
> operator, including things like `&&` and `||` whose short-circuting
> semantics can't be replicated by a method. Thinking of `+` as a method
> call on the other hand is an abstraction that doesn't leak.
>
> I would like to hear a clear argument as to what is actually wrong with
> operator overloading, as it isn't obvious to me and it seems like folks
> are discarding a solution that has the potential to substantially
> simplify the proposal, without a well-articulated reason.
>
Operator overloading, perhaps even a more disciplined equivalent, does
not seem to be sufficient to encompass the entirety of the generics
problem, but it helps to identify the need for an extension to the
"type" concept that the C++ "class" does  not define adequately, but
almost certainly aspires to.

I think the approach by Ian above is a step in the right direction: a
formal description not just of a "type" concept, but of practically
any language element in Go that permits us to add attributes to
objects that are not yet covered by existing notations. That is Go's
contribution to programming notations, a disciplined approach such as
would be essential to discourage, not prevent, the obfuscation made
possible by "operator overloading".

In a way, after all, generics are exactly that: each a unique
operation applied to different "type instances" (in defined
combinations) that are expected to have specifically *that operation*
in common. Or, more appropriately, *that operation* is conventionally
believed to serve analogous purposes in different, but also similar,
"namespace" described by their parameters.

In seeking to formalise the mechanism to declare the common
properties, we also identify the differences, such identification
being itself a formalisation. That is the uncharted territory we can
no longer ignore and Go is a door opening into that territory. I don't
think what will be discovered there will leave Go unscathed: I think
there will have to be incompatible adjustments, I'm not sure that the
Go developers have a fall-back plan when their stated intention to
retain backwards compatibility with Go 1 is proven (if it is) to be
impossible to attain.

But the core essence of Go is its simplicity. As long as it remains an
objective and everything possible is done to retain such simplicity as
far as possible, Go will remain the pioneer in its field.

On  personal note, at this point there has been a lot of talk around
generics, one may well be led to believe that Go 2 is "just Go with
generics" (error handling in Go 1 is quite good enough for me, I only
gave a cursory glance to the proposal on enhancing that aspect of Go -
nothing else has caught my attention), which does not do the language
and its inventors and developers justice.

I feel Go 1 missed an opportunity to ass