Re: [go-nuts] HTTP timeout per handler

[Santiago Corredoira]

Hi Nitin, but how about making the timeout longer thant the default? For
example having a general write timeout of 1 minute but allowing a certain
user to download a large file for 30 min.

El mar., 1 oct. 2019 a las 6:31, Nitin Sanghi ()
escribió:

> Santiago, you can use context to cancel the request after the certain time
> you like.
>
>   ctx, cancel := context.WithTimeout(ctx, 100*time.Millisecond)
>   defer cancel()  // releases
>
>
> On Mon, Sep 30, 2019, 8:54 PM Santiago Corredoira 
> wrote:
>
>> Using the http package, timeouts are defined per server. Is there any way
>> of changing it for a specific handler? Imagine a long download from a loged
>> user or a websocket but also be protected against clients that don't close
>> connections and fload the server.
>>
>> --
>> 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/1622fd96-3758-4066-9428-220b5887ddd5%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/CAF66pLYWaf9La9ku%2B6XrZn6%2B7EJ4%3DQ7H4FbtjPRDZsvP3%2BVjJg%40mail.gmail.com.

Re: [go-nuts] missing $GOPATH

[Dan Kortschak]

Filed https://golang.org/issue/34628

On Fri, 2019-09-27 at 15:19 +0930, Dan Kortschak wrote:
> Looking into it it appears that there's active work in
> go/build.defaultGOPATH that makes returning an informative error
> message impossible.
> 
> This made sense when it was done in 428df5e39c0[1], but since then
> 57568958774[2] has gone in which changes the message from something
> that was useful to something that is now almost devoid of
> information.
> 
> was:
> ```
> go install: no install location for directory
> /home/user/src/path.org/to/package outside GOPATH
>   For more details see: 'go help gopath'
> ```
> 
> now:
> ```
> missing $GOPATH
> ```
> 
> ISTM that the warning provided before 428df5e39c0 is now the better
> option in terms of confusion. Perhaps that warning could be an error
> so
> that functional behaviour that exists now would remain, but with an
> actual explanation. Stopping with this error would be helpful:
> 
> ```
> warning: GOPATH set to GOROOT (/home/user/go) has no effect
> ```
> 
> 
> [1]https://go-review.googlesource.com/c/go/+/33105/
> [2]https://go-review.googlesource.com/c/go/+/118095/
> 
> 
> On Fri, 2019-09-27 at 12:51 +0930, Dan Kortschak wrote:
> > Yes, that explains it. Perhaps the error could be more informative.
> > 
> > On Thu, 2019-09-26 at 20:19 -0700, Ian Lance Taylor wrote:
> > > On Thu, Sep 26, 2019 at 7:36 PM Dan Kortschak 
> > > wrote:
> > > > 
> > > > I am looking at some changes we have made to make code
> > > > generation
> > > > independent of GOPATH since from the SettingGOPATH page of the
> > > > wiki
> > > > says "If no GOPATH is set, it is assumed to be $HOME/go on Unix
> > > > systems
> > > > and %USERPROFILE%\go on Windows."
> > > > 
> > > > However, when I run `go env` I see `missing $GOPATH` in
> > > > response.
> > > > 
> > > > ```
> > > > ~ $ go env
> > > > GO111MODULE="on"
> > > > GOARCH="amd64"
> > > > GOBIN="/home/user/bin"
> > > > GOCACHE="/home/user/.cache/go-build"
> > > > GOENV="/home/user/.config/go/env"
> > > > GOEXE=""
> > > > GOFLAGS=""
> > > > GOHOSTARCH="amd64"
> > > > GOHOSTOS="linux"
> > > > GONOPROXY=""
> > > > GONOSUMDB=""
> > > > GOOS="linux"
> > > > GOPATH="/home/user"
> > > > GOPRIVATE=""
> > > > GOPROXY="https://proxy.golang.org,direct;
> > > > GOROOT="/home/user/go"
> > > > GOSUMDB="sum.golang.org"
> > > > GOTMPDIR=""
> > > > GOTOOLDIR="/home/user/go/pkg/tool/linux_amd64"
> > > > GCCGO="gccgo"
> > > > AR="ar"
> > > > CC="gcc"
> > > > CXX="g++"
> > > > CGO_ENABLED="1"
> > > > GOMOD="/dev/null"
> > > > CGO_CFLAGS="-g -O2"
> > > > CGO_CPPFLAGS=""
> > > > CGO_CXXFLAGS="-g -O2"
> > > > CGO_FFLAGS="-g -O2"
> > > > CGO_LDFLAGS="-g -O2"
> > > > PKG_CONFIG="pkg-config"
> > > > GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-
> > > > prefix-
> > > > map=/tmp/go-build038144482=/tmp/go-build -gno-record-gcc-
> > > > switches"
> > > > ~ $ unset GOPATH
> > > > ~ $ go env
> > > > missing $GOPATH
> > > > ```
> > > > 
> > > > Is this expected now?
> > > 
> > > The problem you are encountering is that /home/user/go is already
> > > being used for GOROOT, so it can't be used for GOPATH.  If the
> > > default
> > > location is unavailable, there is no fallback, so you get
> > > "missing
> > > $GOPATH".
> > > 
> > > 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/a08470225fa8e0ccf7c1ab7f252277474ae6a2b0.camel%40kortschak.io.

Re: [go-nuts] A confusion on the cgo document.

[Ian Lance Taylor]

On Mon, Sep 30, 2019 at 1:01 AM T L  wrote:
>
> https://golang.org/cmd/cgo/#hdr-Passing_pointers
>
> When passing a pointer to a field in a struct, the Go memory in question is 
> the memory occupied by the field, not the entire struct. When passing a 
> pointer to an element in an array or slice, the Go memory in question is the 
> entire array or the entire backing array of the slice.
>
> Why do structs and arrays have this difference?

Because it's normal to call a C function with ([0], len(a)) to let
the C function examine all elements of the array or slice.  It's not
normal to call a C function with () and expect the C function to
examine all elements of the struct; if the C function wants to examine
all elements of a struct, you would pass , not   But you don't
want to pass  to a C function; with the way C pointers work, you
want to pass a pointer to an element, not a pointer to the array or
slice.  (Admittedly passing a pointer to an array would work anyhow,
but passing a pointer to a slice would not.)

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/CAOyqgcVGUomQ3vYgoqVg0-5vgXNhRQCej_tFjxmWNMoLtPyqxQ%40mail.gmail.com.

Re: [go-nuts] Golang library for - ORM & Schema Migration

[bram]

Thank you all.  For schema migration i am looking for similar tool like 
flyway.
, 
Regards,
Bram.


On Sunday, September 29, 2019 at 2:34:55 AM UTC-7, Space A. wrote:
>
> ORM is a tool. It's not good or bad. Every tool, every language and 
> everything has limits. If you like spending time on writing and debugging 
> raw SQL - go ahead. The difference and very obvious in this discussion, is 
> that those who are not against ORM not trying to convince other party to 
> only use this and that and nothing else.
>
>
> вс, 29 сент. 2019 г. в 05:19, Marcin Romaszewicz  >:
>
>>
>> I've used naked SQL, and ORMs (Django in Python, Hibernate and EBean in 
>> Java, GORM in Go) for years, and I've noticed the following:
>>
>> 1) It's really easy to write very inefficient queries in an ORM. If you 
>> have a very simple 1:1 mapping between tables and objects, it's fast, 
>> efficient, easy to use, and by all means, use the ORM. However, once you 
>> start doing tricker things, like references to other objects (aka, foreign 
>> row constraints on other tables), or array type fields, things get really 
>> tricky.
>>
>> 2) A database abstraction layer is nice, because while SQL is standard, 
>> every dang database extends SQL in its own way that's usually not 
>> compatible with others. For example, Postgres supports array columns. MySQL 
>> does not. These two are both very popular. If you have an object which 
>> you're storing in a table, your approach in each DB will be drastically 
>> different. In Postgres, you just write the array into a column. In MySQL, 
>> you have to decompose to First Normal Form, meaning you create a table for 
>> the array column, and have some sort of array/table -> PK mapping. Or, you 
>> give up on any kind of easy array searching, and just marshal your array to 
>> JSON or whatever, and throw it in a CLOB.
>>
>> 3) An ORM ties your hands to using SQL in whatever approach it presents, 
>> so you frequently do naked SQL outside of the ORM, particularly if you want 
>> to use something to speed up a query which is very difficult for an ORM to 
>> express, such as Window Functions in Postgres.
>>
>> Given that no two SQL engines speak the same dialect, and ORMs don't 
>> understand intent, you're basically always debugging. If your object model 
>> is simple, an ORM saves work, if it's complex, I'd argue it's more work. If 
>> you have to support multiple DB's, eg, Postgres for production. SQLite for 
>> unit tests, you need a query builder since their syntax is incompatible, or 
>> stick to a compatible subset. SQL is a mess, ORM or no ORM, and in any 
>> language. Just use what works for you, and reevaluate if it starts to cause 
>> problems.
>>
>> I've been responsible for internet facing services backed by databases 
>> for quite a few years now, could rant about this for a long time. My 
>> current system, and the best one yet, having learned from past mistakes, 
>> uses something like Liquibase for schema management (I wrote it in Go, I'll 
>> be open sourcing it at some point, once it's battle hardened), and naked 
>> SQL queries, with some simple wrappers to hide nullable columns, since the 
>> zerovalue in go is simpler to work with than optionals.
>>
>> -- Marcin
>>
>>
>>
>> On Sat, Sep 28, 2019 at 6:12 PM Robert Engels > > wrote:
>>
>>> ORM is object relational mapping. Go is only pseudo object oriented. I 
>>> will say again that complex object graphs and persistence is very hard 
>>> without an ORM or a LOT of custom code. 
>>>
>>> Since Go does not have runtime compilation a true (or easy anyway) ORM 
>>> in Go requires code generation. 
>>>
>>> On Sep 28, 2019, at 9:32 AM, Rodolfo > 
>>> wrote:
>>>
>>> "First, nobody thinks that knowing ORM's query language absolves one 
>>> from knowing SQL."
>>>
>>> Speak for yourself.
>>>
>>> If you a hard spring boot user you can get into this problem.
>>>
>>> Example:
>>>
>>> findAll = select * from entity
>>>
>>> This is have nothing with SQL.
>>>
>>> findAllBySomeProperty = select * from entity where property = ?
>>>
>>> This is have nothing with SQL.
>>>
>>> Please, do not be rude, be honest.
>>>
>>> Em sáb, 28 de set de 2019 00:49, > 
>>> escreveu:
>>>
 First, nobody thinks that knowing ORM's query language absolves one 
 from knowing SQL.

 But the main issue is that Go SQL interface SUCKS. It's verbose, hard 
 to use and is difficult to integrate with additional tooling (try adding 
 generic tracing support, I dare you!). So often your SQL code is hidden in 
 reams of wrapper code that sets arguments and reads the results.

 So even simple ORMs that allow mapping of result sets to objects help 
 to reduce boilerplate clutter. More advanced ORMs also offer simple type 
 safe queries: https://github.com/go-reform/reform

 It's still nowhere close to LINQ for C# or http://www.querydsl.com/ 
 for Java, but it's getting there.

 On Friday, September 27, 2019 at 3:34:59 AM 

[go-nuts] Go policy does not fully support previous release

[Liam]

I was startled to learn that regressions found in the previous release 
(currently 1.12.x) will not be fixed in that release. Regressions are only 
fixed in the most recent release.

If you wait until 1.12.5 to upgrade a deployment from 1.11.x, and then 
discover a regression on the day 1.13 comes out, tough luck. Either upgrade 
again to 1.13 or resort to a custom build.

I filed a proposal to change this:
https://github.com/golang/go/issues/34622

-- 
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/54fe204e-e410-446f-8687-49b9c03f9095%40googlegroups.com.

Re: [go-nuts] go 1.13 won't compile

[Michael Ellis]

Robert,
It's probably worth a careful look at
https://github.com/golang/go/wiki/Modules#recent-changes and
https://golang.org/doc/go1.13#modules as well as Marcin's suggestion to run
go env. When I do the latter, I get

GO111MODULE=""
GOPRIVATE=""
(among many other variables but those are probably the important ones).
Those settings are working for me for projects that have modules and for
projects that don't.

One possibility is that some pieces of version 1.12 are still hanging
around.  As you  probably know the recommended approach to upgrading
requires removing the older version before installing the new.  See
https://golang.org/doc/install#uninstall

Cheers,
Mike

*“I want you to act as if the house was on fire. Because it is.” — Greta
Thunberg*


On Mon, Sep 30, 2019 at 12:21 PM Marcin Romaszewicz 
wrote:

> Could you post the output of "go env" run on linux mint? Maybe there's a
> clue in there.
>
>
> On Mon, Sep 30, 2019 at 9:14 AM Robert Solomon  wrote:
>
>> Then my question becomes, what's different about linuxmint 19.2 to
>> require me to set GO111MODULE=no
>>
>> On Mon, Sep 30, 2019, 11:06 AM Everton Marques 
>> wrote:
>>
>>> Your code from playground compiled fine for me on Debian Linux.
>>> Tested with Go 1.13 and 1.13.1.
>>>
>>> Just had to include the missing func:
>>>
>>> func GetUserGroupStr(f os.FileInfo) (string, string) {
>>> return "foo", "bar"
>>> }
>>>
>>>
>>>
>>> Em segunda-feira, 30 de setembro de 2019 11:34:52 UTC-3, Robert Solomon
>>> escreveu:

 Your experience matches mine when compiled on windows 10.

 But linuxmint experience is as I described.   Another responder asked
 me if it works when I set GO111MODULE=no.

 It does work when I do that.   I find it interesting that the linux
 behavior seems to be different

 On Mon, Sep 30, 2019, 9:17 AM Michael Ellis 
 wrote:

> FWIW, I copied your code from Go Playground into ~/go/src/dsrt/dsrt.go
> on my OS X machine.  I replaced an undefined function at line 375 (see
> below) with direct assignments for usernameStr and groupNameStr. It
> compiled (with go build) and ran without reporting an error under go 1.13.
>
> // usernameStr, groupnameStr := GetUserGroupStr(f) // util function in
> platform specific code, only for linux and windows.  Not needed anymore.
> Probably won't compile for foreign computer.
> // GetUserGroupStr() is undefined, so hardcode
> a couple of nonsense strings to test compilation.
> usernameStr := "foo"
> groupnameStr := "bar"
>
>
>
> On Saturday, September 28, 2019 at 2:55:51 PM UTC-4, rob wrote:
>>
>> I guess I was not clear enough.  My apologies.  dsrt is my own code.
>> I remember an earlier posting on this list recommended 'go install' 
>> instead
>> of 'go build'
>>
>> ~/go/src/dsrt/dsrt.go, util_linux.go, util_windows.go
>>
>> And I have written other small programs in go that I use for myself.
>> I put it in https://play.golang.org/p/U7FgzpqCh-B
>>
>> It compiles and runs fine on go 1.12.x under linux, and fine on go
>> 1.13 under windows 10.  I have not yet installed go1.13.1 on my windows 
>> 10
>> box.
>>
>> I remember a promise that anything that compiles under go 1.0.0 will
>> not be broken.  Not being able to compile using go 1.13 that works fine
>> using go 1.12.x, broke my code.
>>
>> I'm not a professional programmer.  I don't know what else to include
>> here to demonstrate my problem.
>>
>> Thanks for your response.
>>
>> --rob solomon
>>
>>
>>
>> On 9/28/19 11:42 AM, Marcin Romaszewicz wrote:
>>
>> What was the last version of Go which worked for you?
>>
>> "dsrt" isn't a valid module path in the new module resolution code.
>> Does it work if you disable modules - "GO111MODULE=off go install
>> dsrt"?
>>
>>
>>
>> On Sun, Sep 22, 2019 at 9:56 AM rob  wrote:
>>
>>> Hi.  I think I'm having an issue compiling my code w/ go 1.13.  I
>>> have
>>> not had any issues up until now.  I have my code in the default
>>> locations off of ~/go/src w/ a directory for each little bit of code
>>> I
>>> wrote.
>>>
>>> Running under linuxmint 19.2 amd64, I installed the go binary by
>>> first
>>> nuking /usr/local/go, and then
>>>
>>>  sudo tar -C /usr/local -xf go1.13.linux-amd64.tar.gz.
>>>
>>> When I run go version, I get go version go1.13 linux/amd64
>>>
>>> Now when I run
>>>
>>>  go install dsrt
>>>
>>> I'm getting an error message:
>>>
>>>  can't load package: package dsrt: mallformed module path "dsrt"
>>> :
>>> missing dot in first path element.
>>>
>>> I do not have, need or use a go.mod.  In fact, I don't really
>>> understand
>>> them.  And I don't yet understand what 

Re: [go-nuts] go 1.13 won't compile

[rob]

I hope this helps.  I removed the GO111MODULE=off that I added the other 
day to get compilation to work.


GOARCH="amd64"
GOBIN=""
GOCACHE="/home/rob/.cache/go-build"
GOENV="/home/rob/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/rob/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct;
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build194651225=/tmp/go-build 
-gno-record-gcc-switches"


On 9/30/19 12:21 PM, Marcin Romaszewicz wrote:
Could you post the output of "go env" run on linux mint? Maybe there's 
a clue in there.



On Mon, Sep 30, 2019 at 9:14 AM Robert Solomon > wrote:


Then my question becomes, what's different about linuxmint 19.2 to
require me to set GO111MODULE=no

On Mon, Sep 30, 2019, 11:06 AM Everton Marques
mailto:everton.marq...@gmail.com>> wrote:

Your code from playground compiled fine for me on Debian Linux.
Tested with Go 1.13 and 1.13.1.

Just had to include the missing func:

|
func GetUserGroupStr(f os.FileInfo)(string,string){
return"foo","bar"
}
|



Em segunda-feira, 30 de setembro de 2019 11:34:52 UTC-3,
Robert Solomon escreveu:

Your experience matches mine when compiled on windows 10.

But linuxmint experience is as I described.   Another
responder asked me if it works when I set GO111MODULE=no.

It does work when I do that.  I find it interesting that
the linux behavior seems to be different

On Mon, Sep 30, 2019, 9:17 AM Michael Ellis
 wrote:

FWIW, I copied your code from Go Playground into
~/go/src/dsrt/dsrt.go on my OS X machine.  I replaced
an undefined function at line 375 (see below) with
direct assignments for usernameStr and groupNameStr.
It compiled (with go build) and ran without reporting
an error under go 1.13.

// usernameStr, groupnameStr := GetUserGroupStr(f) //
util function in platform specific code, only for
linux and windows.  Not needed anymore.  Probably
won't compile for foreign computer.
                      // GetUserGroupStr() is
undefined, so hardcode a couple of nonsense strings to
test compilation.
usernameStr := "foo"
groupnameStr := "bar"



On Saturday, September 28, 2019 at 2:55:51 PM UTC-4,
rob wrote:

I guess I was not clear enough. My apologies. 
dsrt is my own code.  I remember an earlier
posting on this list recommended 'go install'
instead of 'go build'

~/go/src/dsrt/dsrt.go, util_linux.go, util_windows.go

And I have written other small programs in go that
I use for myself. I put it in
https://play.golang.org/p/U7FgzpqCh-B

It compiles and runs fine on go 1.12.x under
linux, and fine on go 1.13 under windows 10.  I
have not yet installed go1.13.1 on my windows 10 box.

I remember a promise that anything that compiles
under go 1.0.0 will not be broken.  Not being able
to compile using go 1.13 that works fine using go
1.12.x, broke my code.

I'm not a professional programmer.  I don't know
what else to include here to demonstrate my problem.

Thanks for your response.

--rob solomon



On 9/28/19 11:42 AM, Marcin Romaszewicz wrote:

What was the last version of Go which worked for
you?

"dsrt" isn't a valid module path in the new
module resolution code. Does it work if you
disable modules - "GO111MODULE=off go install dsrt"?



On Sun, Sep 22, 2019 at 9:56 AM rob
 wrote:

Hi. I think I'm having an issue compiling my
code w/ go 1.13. I have
not had any issues up until now.  I have my
code in the default
locations off of ~/go/src w/ a directory for
each little bit of code I
  

Re: [go-nuts] go 1.13 won't compile

[Marcin Romaszewicz]

Could you post the output of "go env" run on linux mint? Maybe there's a
clue in there.


On Mon, Sep 30, 2019 at 9:14 AM Robert Solomon  wrote:

> Then my question becomes, what's different about linuxmint 19.2 to require
> me to set GO111MODULE=no
>
> On Mon, Sep 30, 2019, 11:06 AM Everton Marques 
> wrote:
>
>> Your code from playground compiled fine for me on Debian Linux.
>> Tested with Go 1.13 and 1.13.1.
>>
>> Just had to include the missing func:
>>
>> func GetUserGroupStr(f os.FileInfo) (string, string) {
>> return "foo", "bar"
>> }
>>
>>
>>
>> Em segunda-feira, 30 de setembro de 2019 11:34:52 UTC-3, Robert Solomon
>> escreveu:
>>>
>>> Your experience matches mine when compiled on windows 10.
>>>
>>> But linuxmint experience is as I described.   Another responder asked me
>>> if it works when I set GO111MODULE=no.
>>>
>>> It does work when I do that.   I find it interesting that the linux
>>> behavior seems to be different
>>>
>>> On Mon, Sep 30, 2019, 9:17 AM Michael Ellis  wrote:
>>>
 FWIW, I copied your code from Go Playground into ~/go/src/dsrt/dsrt.go
 on my OS X machine.  I replaced an undefined function at line 375 (see
 below) with direct assignments for usernameStr and groupNameStr. It
 compiled (with go build) and ran without reporting an error under go 1.13.

 // usernameStr, groupnameStr := GetUserGroupStr(f) // util function in
 platform specific code, only for linux and windows.  Not needed anymore.
 Probably won't compile for foreign computer.
 // GetUserGroupStr() is undefined, so hardcode
 a couple of nonsense strings to test compilation.
 usernameStr := "foo"
 groupnameStr := "bar"



 On Saturday, September 28, 2019 at 2:55:51 PM UTC-4, rob wrote:
>
> I guess I was not clear enough.  My apologies.  dsrt is my own code.
> I remember an earlier posting on this list recommended 'go install' 
> instead
> of 'go build'
>
> ~/go/src/dsrt/dsrt.go, util_linux.go, util_windows.go
>
> And I have written other small programs in go that I use for myself. I
> put it in https://play.golang.org/p/U7FgzpqCh-B
>
> It compiles and runs fine on go 1.12.x under linux, and fine on go
> 1.13 under windows 10.  I have not yet installed go1.13.1 on my windows 10
> box.
>
> I remember a promise that anything that compiles under go 1.0.0 will
> not be broken.  Not being able to compile using go 1.13 that works fine
> using go 1.12.x, broke my code.
>
> I'm not a professional programmer.  I don't know what else to include
> here to demonstrate my problem.
>
> Thanks for your response.
>
> --rob solomon
>
>
>
> On 9/28/19 11:42 AM, Marcin Romaszewicz wrote:
>
> What was the last version of Go which worked for you?
>
> "dsrt" isn't a valid module path in the new module resolution code.
> Does it work if you disable modules - "GO111MODULE=off go install dsrt
> "?
>
>
>
> On Sun, Sep 22, 2019 at 9:56 AM rob  wrote:
>
>> Hi.  I think I'm having an issue compiling my code w/ go 1.13.  I
>> have
>> not had any issues up until now.  I have my code in the default
>> locations off of ~/go/src w/ a directory for each little bit of code
>> I
>> wrote.
>>
>> Running under linuxmint 19.2 amd64, I installed the go binary by
>> first
>> nuking /usr/local/go, and then
>>
>>  sudo tar -C /usr/local -xf go1.13.linux-amd64.tar.gz.
>>
>> When I run go version, I get go version go1.13 linux/amd64
>>
>> Now when I run
>>
>>  go install dsrt
>>
>> I'm getting an error message:
>>
>>  can't load package: package dsrt: mallformed module path "dsrt"
>> :
>> missing dot in first path element.
>>
>> I do not have, need or use a go.mod.  In fact, I don't really
>> understand
>> them.  And I don't yet understand what vendoring means.
>>
>> As an aside, I also compile on a win10 amd64 computer.  I installed
>> windows binary in the usual way on that computer, compiled my code
>> using
>> go install, and I've not had any issues there.  I only have an issue
>> here on linuxmint and go 1.13.
>>
>> What's up?
>>
>> --rob solomon
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to golan...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/3e9c5dad-2fda-9574-d8f9-8cedfb7986e5%40fastmail.com
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> 

Re: [go-nuts] go 1.13 won't compile

[Robert Solomon]

Then my question becomes, what's different about linuxmint 19.2 to require
me to set GO111MODULE=no

On Mon, Sep 30, 2019, 11:06 AM Everton Marques 
wrote:

> Your code from playground compiled fine for me on Debian Linux.
> Tested with Go 1.13 and 1.13.1.
>
> Just had to include the missing func:
>
> func GetUserGroupStr(f os.FileInfo) (string, string) {
> return "foo", "bar"
> }
>
>
>
> Em segunda-feira, 30 de setembro de 2019 11:34:52 UTC-3, Robert Solomon
> escreveu:
>>
>> Your experience matches mine when compiled on windows 10.
>>
>> But linuxmint experience is as I described.   Another responder asked me
>> if it works when I set GO111MODULE=no.
>>
>> It does work when I do that.   I find it interesting that the linux
>> behavior seems to be different
>>
>> On Mon, Sep 30, 2019, 9:17 AM Michael Ellis  wrote:
>>
>>> FWIW, I copied your code from Go Playground into ~/go/src/dsrt/dsrt.go
>>> on my OS X machine.  I replaced an undefined function at line 375 (see
>>> below) with direct assignments for usernameStr and groupNameStr. It
>>> compiled (with go build) and ran without reporting an error under go 1.13.
>>>
>>> // usernameStr, groupnameStr := GetUserGroupStr(f) // util function in
>>> platform specific code, only for linux and windows.  Not needed anymore.
>>> Probably won't compile for foreign computer.
>>> // GetUserGroupStr() is undefined, so hardcode a
>>> couple of nonsense strings to test compilation.
>>> usernameStr := "foo"
>>> groupnameStr := "bar"
>>>
>>>
>>>
>>> On Saturday, September 28, 2019 at 2:55:51 PM UTC-4, rob wrote:

 I guess I was not clear enough.  My apologies.  dsrt is my own code.  I
 remember an earlier posting on this list recommended 'go install' instead
 of 'go build'

 ~/go/src/dsrt/dsrt.go, util_linux.go, util_windows.go

 And I have written other small programs in go that I use for myself. I
 put it in https://play.golang.org/p/U7FgzpqCh-B

 It compiles and runs fine on go 1.12.x under linux, and fine on go 1.13
 under windows 10.  I have not yet installed go1.13.1 on my windows 10 box.

 I remember a promise that anything that compiles under go 1.0.0 will
 not be broken.  Not being able to compile using go 1.13 that works fine
 using go 1.12.x, broke my code.

 I'm not a professional programmer.  I don't know what else to include
 here to demonstrate my problem.

 Thanks for your response.

 --rob solomon



 On 9/28/19 11:42 AM, Marcin Romaszewicz wrote:

 What was the last version of Go which worked for you?

 "dsrt" isn't a valid module path in the new module resolution code.
 Does it work if you disable modules - "GO111MODULE=off go install dsrt
 "?



 On Sun, Sep 22, 2019 at 9:56 AM rob  wrote:

> Hi.  I think I'm having an issue compiling my code w/ go 1.13.  I have
> not had any issues up until now.  I have my code in the default
> locations off of ~/go/src w/ a directory for each little bit of code I
> wrote.
>
> Running under linuxmint 19.2 amd64, I installed the go binary by first
> nuking /usr/local/go, and then
>
>  sudo tar -C /usr/local -xf go1.13.linux-amd64.tar.gz.
>
> When I run go version, I get go version go1.13 linux/amd64
>
> Now when I run
>
>  go install dsrt
>
> I'm getting an error message:
>
>  can't load package: package dsrt: mallformed module path "dsrt" :
> missing dot in first path element.
>
> I do not have, need or use a go.mod.  In fact, I don't really
> understand
> them.  And I don't yet understand what vendoring means.
>
> As an aside, I also compile on a win10 amd64 computer.  I installed
> windows binary in the usual way on that computer, compiled my code
> using
> go install, and I've not had any issues there.  I only have an issue
> here on linuxmint and go 1.13.
>
> What's up?
>
> --rob solomon
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to golan...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/3e9c5dad-2fda-9574-d8f9-8cedfb7986e5%40fastmail.com
> .
>
 --
 You received this message because you are subscribed to a topic in the
 Google Groups "golang-nuts" group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/golang-nuts/5hh--qle2KI/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 golan...@googlegroups.com.
 To view this discussion on the web visit
 

[go-nuts] HTTP timeout per handler

[Santiago Corredoira]

Using the http package, timeouts are defined per server. Is there any way 
of changing it for a specific handler? Imagine a long download from a loged 
user or a websocket but also be protected against clients that don't close 
connections and fload the server.

-- 
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/1622fd96-3758-4066-9428-220b5887ddd5%40googlegroups.com.

[go-nuts] Re: Migrating Google App Engine Go app to Go 1.12

[rnovikov2016]

">

On Monday, September 30, 2019 at 5:33:34 AM UTC-4, Jan Mercl wrote:
>
> Hi list. 
>
> The modernc.org domain go-get redirector is hosted at the Google App 
> Engine and provides access to all packages found at this time at 
> https://gitlab.com/cznic. Go code for the redirector iself is 
> published at https://gitlab.com/cznic/modernc. The instance dashboard 
> shows a warning: "A version of your app is using a deprecated version 
> of Go. Please upgrade before October 1, 2019. Learn more". The "Learn 
> more" links here: 
>
> https://cloud.google.com/appengine/docs/standard/go112/go-differences?hl=en_US&_ga=2.244421253.-1415549777.1569833277
>  
>
> I'm pretty lost after reading the docs. It's not just about changing 
> `runtime: go` to `runtime: go112` in the `app.yaml` file. 
>
> As I'm using the deprecated `appengine` package 
> (
> https://gitlab.com/cznic/modernc/blob/ed5d04d89c1e4c74a2742191d62d89437a534b42/main.go#L21),
>  
>
> I should migrate to the Google Cloud client library. The docs link 
> here: https://github.com/googleapis/google-api-go-client. However, 
> looking at the godocs here 
> https://godoc.org/google.golang.org/api/appengine/v1, I cannot see any 
> `Main` API call to replace the call at `main:21`. 
>
> The redirector has 10K+ requests daily and I need to do the upgrade today. 
>
> Please help me, thanks in advance. 
>

-- 
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/bcbd7bf6-5d79-4e98-8114-fb468ac62826%40googlegroups.com.

Re: [go-nuts] go 1.13 won't compile

[Everton Marques]

Your code from playground compiled fine for me on Debian Linux.
Tested with Go 1.13 and 1.13.1.

Just had to include the missing func:

func GetUserGroupStr(f os.FileInfo) (string, string) {
return "foo", "bar"
}



Em segunda-feira, 30 de setembro de 2019 11:34:52 UTC-3, Robert Solomon 
escreveu:
>
> Your experience matches mine when compiled on windows 10.
>
> But linuxmint experience is as I described.   Another responder asked me 
> if it works when I set GO111MODULE=no.
>
> It does work when I do that.   I find it interesting that the linux 
> behavior seems to be different 
>
> On Mon, Sep 30, 2019, 9:17 AM Michael Ellis  > wrote:
>
>> FWIW, I copied your code from Go Playground into ~/go/src/dsrt/dsrt.go on 
>> my OS X machine.  I replaced an undefined function at line 375 (see below) 
>> with direct assignments for usernameStr and groupNameStr. It compiled (with 
>> go build) and ran without reporting an error under go 1.13.
>>
>> // usernameStr, groupnameStr := GetUserGroupStr(f) // util function in 
>> platform specific code, only for linux and windows.  Not needed anymore.  
>> Probably won't compile for foreign computer.
>> // GetUserGroupStr() is undefined, so hardcode a 
>> couple of nonsense strings to test compilation.
>> usernameStr := "foo"
>> groupnameStr := "bar"
>>
>>
>>
>> On Saturday, September 28, 2019 at 2:55:51 PM UTC-4, rob wrote:
>>>
>>> I guess I was not clear enough.  My apologies.  dsrt is my own code.  I 
>>> remember an earlier posting on this list recommended 'go install' instead 
>>> of 'go build'
>>>
>>> ~/go/src/dsrt/dsrt.go, util_linux.go, util_windows.go
>>>
>>> And I have written other small programs in go that I use for myself. I 
>>> put it in https://play.golang.org/p/U7FgzpqCh-B
>>>
>>> It compiles and runs fine on go 1.12.x under linux, and fine on go 1.13 
>>> under windows 10.  I have not yet installed go1.13.1 on my windows 10 box.
>>>
>>> I remember a promise that anything that compiles under go 1.0.0 will not 
>>> be broken.  Not being able to compile using go 1.13 that works fine using 
>>> go 1.12.x, broke my code.
>>>
>>> I'm not a professional programmer.  I don't know what else to include 
>>> here to demonstrate my problem.
>>>
>>> Thanks for your response.
>>>
>>> --rob solomon
>>>
>>>
>>>
>>> On 9/28/19 11:42 AM, Marcin Romaszewicz wrote:
>>>
>>> What was the last version of Go which worked for you? 
>>>
>>> "dsrt" isn't a valid module path in the new module resolution code. Does 
>>> it work if you disable modules - "GO111MODULE=off go install dsrt"?
>>>
>>>
>>>
>>> On Sun, Sep 22, 2019 at 9:56 AM rob  wrote:
>>>
 Hi.  I think I'm having an issue compiling my code w/ go 1.13.  I have 
 not had any issues up until now.  I have my code in the default 
 locations off of ~/go/src w/ a directory for each little bit of code I 
 wrote.

 Running under linuxmint 19.2 amd64, I installed the go binary by first 
 nuking /usr/local/go, and then

  sudo tar -C /usr/local -xf go1.13.linux-amd64.tar.gz.

 When I run go version, I get go version go1.13 linux/amd64

 Now when I run

  go install dsrt

 I'm getting an error message:

  can't load package: package dsrt: mallformed module path "dsrt" : 
 missing dot in first path element.

 I do not have, need or use a go.mod.  In fact, I don't really 
 understand 
 them.  And I don't yet understand what vendoring means.

 As an aside, I also compile on a win10 amd64 computer.  I installed 
 windows binary in the usual way on that computer, compiled my code 
 using 
 go install, and I've not had any issues there.  I only have an issue 
 here on linuxmint and go 1.13.

 What's up?

 --rob solomon


 -- 
 You received this message because you are subscribed to the Google 
 Groups "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to golan...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/3e9c5dad-2fda-9574-d8f9-8cedfb7986e5%40fastmail.com
 .

>>> -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/golang-nuts/5hh--qle2KI/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LtsWqufQHw%2BmJtAe60KnCHPag9SPVAtjkP2XzkkuHcwyg%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>>> -- 
>> You received this message because you are subscribed to a 

Re: [go-nuts] go 1.13 won't compile

[Robert Solomon]

Your experience matches mine when compiled on windows 10.

But linuxmint experience is as I described.   Another responder asked me if
it works when I set GO111MODULE=no.

It does work when I do that.   I find it interesting that the linux
behavior seems to be different

On Mon, Sep 30, 2019, 9:17 AM Michael Ellis 
wrote:

> FWIW, I copied your code from Go Playground into ~/go/src/dsrt/dsrt.go on
> my OS X machine.  I replaced an undefined function at line 375 (see below)
> with direct assignments for usernameStr and groupNameStr. It compiled (with
> go build) and ran without reporting an error under go 1.13.
>
> // usernameStr, groupnameStr := GetUserGroupStr(f) // util function in
> platform specific code, only for linux and windows.  Not needed anymore.
> Probably won't compile for foreign computer.
> // GetUserGroupStr() is undefined, so hardcode a
> couple of nonsense strings to test compilation.
> usernameStr := "foo"
> groupnameStr := "bar"
>
>
>
> On Saturday, September 28, 2019 at 2:55:51 PM UTC-4, rob wrote:
>>
>> I guess I was not clear enough.  My apologies.  dsrt is my own code.  I
>> remember an earlier posting on this list recommended 'go install' instead
>> of 'go build'
>>
>> ~/go/src/dsrt/dsrt.go, util_linux.go, util_windows.go
>>
>> And I have written other small programs in go that I use for myself. I
>> put it in https://play.golang.org/p/U7FgzpqCh-B
>>
>> It compiles and runs fine on go 1.12.x under linux, and fine on go 1.13
>> under windows 10.  I have not yet installed go1.13.1 on my windows 10 box.
>>
>> I remember a promise that anything that compiles under go 1.0.0 will not
>> be broken.  Not being able to compile using go 1.13 that works fine using
>> go 1.12.x, broke my code.
>>
>> I'm not a professional programmer.  I don't know what else to include
>> here to demonstrate my problem.
>>
>> Thanks for your response.
>>
>> --rob solomon
>>
>>
>>
>> On 9/28/19 11:42 AM, Marcin Romaszewicz wrote:
>>
>> What was the last version of Go which worked for you?
>>
>> "dsrt" isn't a valid module path in the new module resolution code. Does
>> it work if you disable modules - "GO111MODULE=off go install dsrt"?
>>
>>
>>
>> On Sun, Sep 22, 2019 at 9:56 AM rob  wrote:
>>
>>> Hi.  I think I'm having an issue compiling my code w/ go 1.13.  I have
>>> not had any issues up until now.  I have my code in the default
>>> locations off of ~/go/src w/ a directory for each little bit of code I
>>> wrote.
>>>
>>> Running under linuxmint 19.2 amd64, I installed the go binary by first
>>> nuking /usr/local/go, and then
>>>
>>>  sudo tar -C /usr/local -xf go1.13.linux-amd64.tar.gz.
>>>
>>> When I run go version, I get go version go1.13 linux/amd64
>>>
>>> Now when I run
>>>
>>>  go install dsrt
>>>
>>> I'm getting an error message:
>>>
>>>  can't load package: package dsrt: mallformed module path "dsrt" :
>>> missing dot in first path element.
>>>
>>> I do not have, need or use a go.mod.  In fact, I don't really understand
>>> them.  And I don't yet understand what vendoring means.
>>>
>>> As an aside, I also compile on a win10 amd64 computer.  I installed
>>> windows binary in the usual way on that computer, compiled my code using
>>> go install, and I've not had any issues there.  I only have an issue
>>> here on linuxmint and go 1.13.
>>>
>>> What's up?
>>>
>>> --rob solomon
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/3e9c5dad-2fda-9574-d8f9-8cedfb7986e5%40fastmail.com
>>> .
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/5hh--qle2KI/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golan...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LtsWqufQHw%2BmJtAe60KnCHPag9SPVAtjkP2XzkkuHcwyg%40mail.gmail.com
>> 
>> .
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/5hh--qle2KI/unsubscribe.
> To unsubscribe from this group and all its topics, 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/84d7a41b-5fff-428c-9e10-244ae2cc6a0b%40googlegroups.com
> 

Re: [go-nuts] go 1.13 won't compile

[Michael Ellis]

FWIW, I copied your code from Go Playground into ~/go/src/dsrt/dsrt.go on 
my OS X machine.  I replaced an undefined function at line 375 (see below) 
with direct assignments for usernameStr and groupNameStr. It compiled (with 
go build) and ran without reporting an error under go 1.13.

// usernameStr, groupnameStr := GetUserGroupStr(f) // util function in 
platform specific code, only for linux and windows.  Not needed anymore.  
Probably won't compile for foreign computer.
// GetUserGroupStr() is undefined, so hardcode a 
couple of nonsense strings to test compilation.
usernameStr := "foo"
groupnameStr := "bar"



On Saturday, September 28, 2019 at 2:55:51 PM UTC-4, rob wrote:
>
> I guess I was not clear enough.  My apologies.  dsrt is my own code.  I 
> remember an earlier posting on this list recommended 'go install' instead 
> of 'go build'
>
> ~/go/src/dsrt/dsrt.go, util_linux.go, util_windows.go
>
> And I have written other small programs in go that I use for myself. I put 
> it in https://play.golang.org/p/U7FgzpqCh-B
>
> It compiles and runs fine on go 1.12.x under linux, and fine on go 1.13 
> under windows 10.  I have not yet installed go1.13.1 on my windows 10 box.
>
> I remember a promise that anything that compiles under go 1.0.0 will not 
> be broken.  Not being able to compile using go 1.13 that works fine using 
> go 1.12.x, broke my code.
>
> I'm not a professional programmer.  I don't know what else to include here 
> to demonstrate my problem.
>
> Thanks for your response.
>
> --rob solomon
>
>
>
> On 9/28/19 11:42 AM, Marcin Romaszewicz wrote:
>
> What was the last version of Go which worked for you? 
>
> "dsrt" isn't a valid module path in the new module resolution code. Does 
> it work if you disable modules - "GO111MODULE=off go install dsrt"?
>
>
>
> On Sun, Sep 22, 2019 at 9:56 AM rob > 
> wrote:
>
>> Hi.  I think I'm having an issue compiling my code w/ go 1.13.  I have 
>> not had any issues up until now.  I have my code in the default 
>> locations off of ~/go/src w/ a directory for each little bit of code I 
>> wrote.
>>
>> Running under linuxmint 19.2 amd64, I installed the go binary by first 
>> nuking /usr/local/go, and then
>>
>>  sudo tar -C /usr/local -xf go1.13.linux-amd64.tar.gz.
>>
>> When I run go version, I get go version go1.13 linux/amd64
>>
>> Now when I run
>>
>>  go install dsrt
>>
>> I'm getting an error message:
>>
>>  can't load package: package dsrt: mallformed module path "dsrt" : 
>> missing dot in first path element.
>>
>> I do not have, need or use a go.mod.  In fact, I don't really understand 
>> them.  And I don't yet understand what vendoring means.
>>
>> As an aside, I also compile on a win10 amd64 computer.  I installed 
>> windows binary in the usual way on that computer, compiled my code using 
>> go install, and I've not had any issues there.  I only have an issue 
>> here on linuxmint and go 1.13.
>>
>> What's up?
>>
>> --rob solomon
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/3e9c5dad-2fda-9574-d8f9-8cedfb7986e5%40fastmail.com
>> .
>>
> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/golang-nuts/5hh--qle2KI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LtsWqufQHw%2BmJtAe60KnCHPag9SPVAtjkP2XzkkuHcwyg%40mail.gmail.com
>  
> 
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/84d7a41b-5fff-428c-9e10-244ae2cc6a0b%40googlegroups.com.

[go-nuts] [ANN] Rain: BitTorrent client and library

[Cenk Altı]

I would like to announce the BitTorrent client I wrote. It is the main 
client used at https://put.io, the cloud storage company that I work at. We 
are using it on production for several months. You can use it as a command 
line tool or as a library.

https://github.com/cenkalti/rain
https://godoc.org/github.com/cenkalti/rain

Any comment is appreciated.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a405c4cd-78fb-4acb-a4aa-6f81e02701d4%40googlegroups.com.

[go-nuts] Re: causal profiling in Go

[Vincent Blanchon]

That's interesting, thanks for sharing.
Also interested to know if someone got results with a similar approach.

>

-- 
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/9a6bf539-96b7-4588-9b67-e370af71ab1c%40googlegroups.com.

[go-nuts] causal profiling in Go

['Ingo Oeser' via golang-nuts]

Hi everyone,

does someone has experience with causal profiling in Go? (see 
http://www.sigops.org/sosp/sosp15/current/2015-Monterey/printable/090-curtsinger.pdf
 if you are not aware of that topic) 

Please note that I am aware of https://morsmachine.dk/causalprof but I want to 
hear a few more opinions on this. 

I am also aware of the standard go profiling.

So anyone else who tried Daniels work?

Best Regards 

Ingo 

-- 
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/065b67f1-db33-4f84-bf41-0b83ba192ab8%40googlegroups.com.

[go-nuts] Re: Migrating Google App Engine Go app to Go 1.12

[Jan Mercl]

On Mon, Sep 30, 2019 at 11:32 AM Jan Mercl <0xj...@gmail.com> wrote:

Panic mode off. Deployed, seems to work:
https://gitlab.com/cznic/modernc/commit/96339947ba67960ae5bd19b625b2816fdcc7af6e

Thanks to anyone who have read the OP.

-- 
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-WbyTdiQdqnSuXggjoCt8KiZrg9TDnrB6sxSQH41U39xg%40mail.gmail.com.

Re: [go-nuts] Migrating Google App Engine Go app to Go 1.12

[Jan Mercl]

On Mon, Sep 30, 2019 at 12:34 PM Matthew Zimmerman  wrote:
>
> My notice said that apps continue to run, you just can't deploy new versions.
>
> "Starting on October 1, 2019, as per our deprecation policy, you will no 
> longer be able to deploy new versions of App Engine Standard applications 
> that use Go 1.9 and earlier. However, applications that have already been 
> deployed will continue to run."

Thanks for the update! Somehow I cannot find that email, but I recall
receiving it some weeks ago.

I've already unfortunately disrupted the service for about 15 minutes.
It's now restored. Further brief dropouts are possible. Apologies to
anyone affected.

-- 
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-VnMot4ro1znX5EdbdeigaO5SF4Nfg5q%2B1b3UcWefvc7w%40mail.gmail.com.

Re: [go-nuts] Migrating Google App Engine Go app to Go 1.12

[Matthew Zimmerman]

My notice said that apps continue to run, you just can't deploy new
versions.

"Starting on October 1, 2019, as per our deprecation policy
,
you will no longer be able to deploy new versions of App Engine Standard
applications that use Go 1.9 and earlier. However, *applications that have
already been deployed will continue to run."*

On Mon, Sep 30, 2019, 5:33 AM Jan Mercl <0xj...@gmail.com> wrote:

> Hi list.
>
> The modernc.org domain go-get redirector is hosted at the Google App
> Engine and provides access to all packages found at this time at
> https://gitlab.com/cznic. Go code for the redirector iself is
> published at https://gitlab.com/cznic/modernc. The instance dashboard
> shows a warning: "A version of your app is using a deprecated version
> of Go. Please upgrade before October 1, 2019. Learn more". The "Learn
> more" links here:
>
> https://cloud.google.com/appengine/docs/standard/go112/go-differences?hl=en_US&_ga=2.244421253.-1415549777.1569833277
>
> I'm pretty lost after reading the docs. It's not just about changing
> `runtime: go` to `runtime: go112` in the `app.yaml` file.
>
> As I'm using the deprecated `appengine` package
> (
> https://gitlab.com/cznic/modernc/blob/ed5d04d89c1e4c74a2742191d62d89437a534b42/main.go#L21
> ),
> I should migrate to the Google Cloud client library. The docs link
> here: https://github.com/googleapis/google-api-go-client. However,
> looking at the godocs here
> https://godoc.org/google.golang.org/api/appengine/v1, I cannot see any
> `Main` API call to replace the call at `main:21`.
>
> The redirector has 10K+ requests daily and I need to do the upgrade today.
>
> Please help me, thanks in advance.
>
> --
> 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-UAeExU9iAcqD7aMSeQjdwdAuvC9D1oXv64MYAJSUqAew%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAD53Lr712G%2BQz_4ue%2BEMCdAVuQfo9LPjGayULn-_K60fCLbxOg%40mail.gmail.com.

[go-nuts] Migrating Google App Engine Go app to Go 1.12

[Jan Mercl]

Hi list.

The modernc.org domain go-get redirector is hosted at the Google App
Engine and provides access to all packages found at this time at
https://gitlab.com/cznic. Go code for the redirector iself is
published at https://gitlab.com/cznic/modernc. The instance dashboard
shows a warning: "A version of your app is using a deprecated version
of Go. Please upgrade before October 1, 2019. Learn more". The "Learn
more" links here:
https://cloud.google.com/appengine/docs/standard/go112/go-differences?hl=en_US&_ga=2.244421253.-1415549777.1569833277

I'm pretty lost after reading the docs. It's not just about changing
`runtime: go` to `runtime: go112` in the `app.yaml` file.

As I'm using the deprecated `appengine` package
(https://gitlab.com/cznic/modernc/blob/ed5d04d89c1e4c74a2742191d62d89437a534b42/main.go#L21),
I should migrate to the Google Cloud client library. The docs link
here: https://github.com/googleapis/google-api-go-client. However,
looking at the godocs here
https://godoc.org/google.golang.org/api/appengine/v1, I cannot see any
`Main` API call to replace the call at `main:21`.

The redirector has 10K+ requests daily and I need to do the upgrade today.

Please help me, thanks in advance.

-- 
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-UAeExU9iAcqD7aMSeQjdwdAuvC9D1oXv64MYAJSUqAew%40mail.gmail.com.

[go-nuts] Re: Can’t get latest package version with modules

[Christophe Meessen]

Solved the issue with the command:

go get -u github.com/XXX/go-YYY@latest

Is there another way  ? 

Le lundi 30 septembre 2019 11:01:17 UTC+2, Christophe Meessen a écrit :
>
> I have a small go program to test a third party package stored on github. 
> I’m using go1.13.1 with no GOPATH defined. Code is in ~/go/src. 
>
> When I first tried to compile the program, there was an error in the third 
> party package. I submitted a pull request to fix it and the manager merged 
> it. 
>
> The problem I’m facing now is that I can’t get go to use the newest 
> version of the package. 
>
> If I remove the require line in the go.mod file and do a go get, or go get 
> -u, or go get -u , I always get the older package although go 
> prints the message "go: finding github.com/XXX/go-YYY latest". It’s 
> definitely not the latest. 
> I’m stuck now and don’t know how to download the really latest version of 
> the package. 
>
> I guess I’m not supposed to manually clean the go cache (~/go/src/mod/
> github.com/XXX/go-YYY@...), or am I ? 
>

-- 
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/0691adf5-5b04-4e39-b2e9-295c260c9527%40googlegroups.com.

[go-nuts] Re: Can’t get latest package version with modules

[Christophe Meessen]

Note that the third party package has no tags. 

Le lundi 30 septembre 2019 11:01:17 UTC+2, Christophe Meessen a écrit :
>
> I have a small go program to test a third party package stored on github. 
> I’m using go1.13.1 with no GOPATH defined. Code is in ~/go/src. 
>
> When I first tried to compile the program, there was an error in the third 
> party package. I submitted a pull request to fix it and the manager merged 
> it. 
>
> The problem I’m facing now is that I can’t get go to use the newest 
> version of the package. 
>
> If I remove the require line in the go.mod file and do a go get, or go get 
> -u, or go get -u , I always get the older package although go 
> prints the message "go: finding github.com/XXX/go-YYY latest". It’s 
> definitely not the latest. 
> I’m stuck now and don’t know how to download the really latest version of 
> the package. 
>
> I guess I’m not supposed to manually clean the go cache (~/go/src/mod/
> github.com/XXX/go-YYY@...), or am I ? 
>

-- 
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/6975d023-f1db-442b-81d3-60d7c2f41597%40googlegroups.com.

[go-nuts] Can’t get latest package version with modules

[Christophe Meessen]

I have a small go program to test a third party package stored on github. 
I’m using go1.13.1 with no GOPATH defined. Code is in ~/go/src. 

When I first tried to compile the program, there was an error in the third 
party package. I submitted a pull request to fix it and the manager merged 
it. 

The problem I’m facing now is that I can’t get go to use the newest version 
of the package. 

If I remove the require line in the go.mod file and do a go get, or go get 
-u, or go get -u , I always get the older package although go 
prints the message "go: finding github.com/XXX/go-YYY latest". It’s 
definitely not the latest. 
I’m stuck now and don’t know how to download the really latest version of 
the package. 

I guess I’m not supposed to manually clean the go cache 
(~/go/src/mod/github.com/XXX/go-YYY@...), or am I ? 

-- 
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/f74ffd31-2e78-4c0a-bea9-1c2d6f84ea22%40googlegroups.com.

Re: [go-nuts] How to use .toml file to parse IP address and port to http server

[afriyie . abraham]

Hi,

I have solve the problem and it works now. Thanks.


On Monday, September 30, 2019 at 11:06:20 AM UTC+3, Afriyie Abraham Kwabena 
wrote:
>
> Hi,
>
> I have applied similar scenario to the function below but am not getting 
> the Ip address and the port number. Below is the function
>
> var addr string
>
> func init(){
>
> var conf Config
> if _, err := toml.Decode("config.toml", ); err != nil {
> // handle error
> }
> addr = net.JoinHostPort(conf.Addr, conf.Port)
> fmt.Println(addr)  // This printing empty
>  
> }
>
>
> func main() {
> 
> server := NewServer()
>
> go func() {
>
> if err := 
> server.ListenAndServeTLS("/home/cumucore/diam/server.crt", 
> "/home/cumucore/diam/server.key"); err != nil && err != 
> http.ErrServerClosed {
> logger.Fatalf("Could not listen on %s: %v\n", addr, err)
>
> if err := server.ListenAndServe(); err != nil {
> logger.Fatalf("Could not listen on %s: %v\n", addr, err)
> }
>
> }
> }()
> }
>
>
> // Create a new server
> func NewServer() *http.Server {
>
> return {
> Addr: addr,
> Handler:  diam.NewRouter(),
> ErrorLog: logger,
> ReadTimeout:  5 * time.Second,
> WriteTimeout: 10 * time.Second,
> IdleTimeout:  15 * time.Second,
> }
> }
>
> Ther config.toml file contain the key values as
> Addr = "192.168.9.186"
> Port = "8000"
>
> What might be the problem in this case
>
>
> On Sunday, September 29, 2019 at 5:18:55 PM UTC+3, Andrew Pillar wrote:
>>
>> Use net.JoinHostPort to concatenate the values you have in the struct 
>> and pass the to http.Server struct. 
>>
>>   if _, err := toml.Decode("config.toml", ); err != nil { 
>> // handle error 
>>   } 
>>
>>   addr, err := net.JoinHostPort(conf.Address, conf.PORT) 
>>
>>   if err != nil { 
>> // handle error 
>>   } 
>>
>>   src := { 
>> Addr: addr, 
>>   } 
>>
>> Be sure to set explicit struct tags on your destination struct that 
>> will be used for unmarshalling the toml. This way the decoder will know 
>> which struct fields to populate. 
>>
>>   type Config struct { 
>> PORTstring `toml:"port"` 
>> Address string `toml:"address"` 
>>   } 
>>
>> This will only be necessary though if you want the fields to map 
>> differently depending on their name. 
>>
>>

-- 
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/28360a86-da47-4226-90f2-59515a317210%40googlegroups.com.

Re: [go-nuts] How to use .toml file to parse IP address and port to http server

[afriyie . abraham]

Hi,

I have applied similar scenario to the function below but am not getting 
the Ip address and the port number. Below is the function

var addr string

func init(){

var conf Config
if _, err := toml.Decode("config.toml", ); err != nil {
// handle error
}
addr = net.JoinHostPort(conf.Addr, conf.Port)
fmt.Println(addr)  // This printing empty
 
}


func main() {

server := NewServer()

go func() {

if err := 
server.ListenAndServeTLS("/home/cumucore/diam/server.crt", 
"/home/cumucore/diam/server.key"); err != nil && err != 
http.ErrServerClosed {
logger.Fatalf("Could not listen on %s: %v\n", addr, err)

if err := server.ListenAndServe(); err != nil {
logger.Fatalf("Could not listen on %s: %v\n", addr, err)
}

}
}()
}


// Create a new server
func NewServer() *http.Server {

return {
Addr: addr,
Handler:  diam.NewRouter(),
ErrorLog: logger,
ReadTimeout:  5 * time.Second,
WriteTimeout: 10 * time.Second,
IdleTimeout:  15 * time.Second,
}
}

Ther config.toml file contain the key values as
Addr = "192.168.9.186"
Port = "8000"

What might be the problem in this case


On Sunday, September 29, 2019 at 5:18:55 PM UTC+3, Andrew Pillar wrote:
>
> Use net.JoinHostPort to concatenate the values you have in the struct 
> and pass the to http.Server struct. 
>
>   if _, err := toml.Decode("config.toml", ); err != nil { 
> // handle error 
>   } 
>
>   addr, err := net.JoinHostPort(conf.Address, conf.PORT) 
>
>   if err != nil { 
> // handle error 
>   } 
>
>   src := { 
> Addr: addr, 
>   } 
>
> Be sure to set explicit struct tags on your destination struct that 
> will be used for unmarshalling the toml. This way the decoder will know 
> which struct fields to populate. 
>
>   type Config struct { 
> PORTstring `toml:"port"` 
> Address string `toml:"address"` 
>   } 
>
> This will only be necessary though if you want the fields to map 
> differently depending on their name. 
>
>

-- 
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/9756a565-79c7-4eda-96f3-172e3ec6a908%40googlegroups.com.

[go-nuts] A confusion on the cgo document.

[T L]

https://golang.org/cmd/cgo/#hdr-Passing_pointers

When passing a pointer to a field in a struct, the Go memory in question is 
the memory occupied by the field, not the entire struct. When passing a 
pointer to an element in an array or slice, the Go memory in question is 
the entire array or the entire backing array of the slice. 

Why do structs and arrays have this difference? 

-- 
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/c8d7b2da-53cc-4350-afda-07d474c4b980%40googlegroups.com.