Re: [go-nuts] Will Go be discontinued?

[Amnon]

On Monday, 25 July 2022 at 19:48:24 UTC+1 Carlos Jimenez wrote:

> I think it will be discontinued soon 
> The average lifespan of a discontinued Google product is *4 years and 1 
> month*. so should be a matter of months maybe 2.0 will be the last one 
> before shutdown
>

The average lifespan may be 4 years 1 month. But there is a massive 
standard deviation. Some google products (such as Search) seem to have a 
very much longer lifespan.
The mean lifespan of a product is massively skewed by the many experimental 
products which fail fast.

This thread was started in 2013.  has been dormant for 9 years. But Go has 
been anything but
Will Go be discontinued in a matter of months? As Neils Bohr once said, 
"Predictions are difficult, especially concerning the future". 
And never more so than it today's turbulent world. But if I was a betting 
man, I would not put money on Go being discontinued any times soon,
(though perhaps I should, as a hedge against my career being disrupted).

Anyway let's check back in a few months time and see if we are still here...

-- 
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/937d6c13-590b-44aa-84ee-898a60143044n%40googlegroups.com.

Re: [go-nuts] How to check Cmd.ProcessState without triggering the race checker?

[Steven Hartland]

Looks like session already has what you need as you can check
if session.Exited has been closed something like:

select {
case <- session.Exited:
  // Handle session has ended
default:
  // Handle session hasn't ended
}

On Sat, 23 Jul 2022 at 21:39, TheDiveO  wrote:

> In my open source file descriptor leak checker (Linux only) for Gomega,
> Go's race detector flags a race condition in my code where I need to
> check whether a Cmd.Process already has terminated
> 
> as its ProcessState has been set.
>
> if session.Command.ProcessState != nil {
> return nil, errors.New("session has already ended")
> }
>
> Now, this check might be called be called from a different Goroutine than
> another Goroutine waiting for the command to exit. In particular, this is
> the (what I consider to be the relevant) output of the race detector:
>
> WARNING: DATA RACE
> Write at 0x00c0002e8208 by goroutine 16:
>   os/exec.(*Cmd).Wait()
>   /home/.../sdk/go1.19rc2/src/os/exec/exec.go:598 +0x1eb
>   github.com/onsi/gomega/gexec.(*Session).monitorForExit()
>   /home/.../go/pkg/mod/
> github.com/onsi/gomega@v1.20.0/gexec/session.go:197 +0x44
>   github.com/onsi/gomega/gexec.Start.func1()
>   /home/.../go/pkg/mod/
> github.com/onsi/gomega@v1.20.0/gexec/session.go:96 +0x47
>
> Previous read at 0x00c0002e8208 by goroutine 12:
>   github.com/thediveo/fdooze/session.FiledescriptorsFor()
>   /home/.../github/fdooze/session/session_fds.go:21 +0x1b7
>   github.com/thediveo/fdooze/session.glob..func1.1.1()
>   /home/.../github/fdooze/session/session_fds_test.go:45 +0x30
>   runtime.call16()
>   /home/.../sdk/go1.19rc2/src/runtime/asm_amd64.s:724 +0x48
>   reflect.Value.Call()
>   /home/.../sdk/go1.19rc2/src/reflect/value.go:368 +0xc7
>   github.com/onsi/gomega/internal.NewAsyncAssertion.func1()
>   /home/.../go/pkg/mod/
> github.com/onsi/gomega@v1.20.0/internal/async_assertion.go:48 +0x16e
>   github.com/onsi/gomega/internal.(*AsyncAssertion).pollActual()
>   /home/.../go/pkg/mod/
> github.com/onsi/gomega@v1.20.0/internal/async_assertion.go:132 +0x82
>   github.com/onsi/gomega/internal.(*AsyncAssertion).match()
>   /home/.../go/pkg/mod/
> github.com/onsi/gomega@v1.20.0/internal/async_assertion.go:162 +0xe4
>   github.com/onsi/gomega/internal.(*AsyncAssertion).ShouldNot()
>   /home/.../go/pkg/mod/
> github.com/onsi/gomega@v1.20.0/internal/async_assertion.go:112 +0xa9
>   github.com/thediveo/fdooze/session.glob..func1.1()
>   /home/.../github/fdooze/session/session_fds_test.go:65 +0xf41
>   github.com/onsi/ginkgo/v2/internal.(*Suite).runNode.func2()
>   /home/.../go/pkg/mod/
> github.com/onsi/ginkgo/v2@v2.1.4/internal/suite.go:596 +0xea
>
> Is there actually any way to check use Cmd.ProcessState at all from a
> thread different from the one doing a Cmd.Wait? Might this be a design
> "weakness" of the Cmd type in that it doesn't cover such use cases?
>
> Any idea for a work around to find if the command might already have
> (prematurely) finished by the time I try to check for its open file
> descriptors?
>
> --
> 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/8ed84076-b29d-4840-8c15-09621e2fca61n%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/CAHEMsqYuX3SdE%2B9ds_ANkHYa24J7d7PEDLN6Fz9eUjxt5%2BnQxg%40mail.gmail.com.

Re: [go-nuts] Incorrect time zone DST for America/Sao_Paulo

[Ian Lance Taylor]

On Mon, Jul 25, 2022 at 3:47 PM Brendenson Andrade
 wrote:
>
> I discovered a problem with the America/Sao_Paulo time zone.
>
> Brazil doesn't have daylight saving time changes anymore, but Go still uses 
> DST -2 (the correct one is -3) for the America/Sao_Paulo time zone.
>
> I propose to change DST for this time zone.

For Unix systems Go uses the timezone information that is available on
the system.  In general Go uses the tzdata database
(https://www.iana.org/time-zones), and we aren't going to change that.

So: what system are you running?  Is the tzdata database up to date?
Is your timezone information up to date?  It's unlikely that there is
anything to change in Go here.

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/CAOyqgcX4DD2O1-TyPr2oRcGnX%3DVw1hNDNQvBzG9e94PpiVyR9w%40mail.gmail.com.

[go-nuts] Incorrect time zone DST for America/Sao_Paulo

[Brendenson Andrade]

I discovered a problem with the America/Sao_Paulo time zone.

Brazil doesn't have daylight saving time changes anymore, but Go still uses 
DST -2 (the correct one is -3) for the America/Sao_Paulo time zone.

I propose to change DST for this time zone.

-- 
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/d1c6f175-5990-4269-a14d-b65a4bd33aden%40googlegroups.com.

Re: [go-nuts] Will Go be discontinued?

[Carlos Jimenez]

I think it will be discontinued soon 
The average lifespan of a discontinued Google product is *4 years and 1 
month*. so should be a matter of months maybe 2.0 will be the last one 
before shutdown
On Monday, 5 August 2013 at 15:57:04 UTC+1 quar...@gmail.com wrote:

> Go Sweden Go! ;)
>
> /f
>
>
> Den måndagen den 5:e augusti 2013 kl. 16:26:29 UTC+2 skrev John C.:
>>
>> The regional map and especially list of cities provide food for thought.
>>
>> On Monday, August 5, 2013 10:18:56 AM UTC-4, Francesc Campoy Flores wrote:
>>>
>>> We can't share internal data, but this can show a little bit the rate of 
>>> adoption of Go outside of Google.
>>>
>>> http://www.google.com/trends/explore?q=golang#q=golang=q
>>>
>>> It doesn't look like people are losing interest :-)
>>>
>>>
>>> On Mon, Jul 29, 2013 at 6:47 AM, Sebastien Douche  
>>> wrote:
>>>
 On Mon, Jul 29, 2013 at 1:39 AM, Andrew Gerrand  
 wrote:
 > Google has already made a significant investment in Go, and the rate 
 of Go
 > adoption inside Google is increasing. We have graphs and everything!

 It might be cool to share the graphs.



 --
 Sebastien Douche 
 Twitter: @sdouche / G+: +sdouche

 --
 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/groups/opt_out.



>>>
>>>
>>> -- 
>>> --
>>> Francesc
>>>
>>

-- 
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/9d0f69d5-fdf3-4fa1-bdcc-28f260783f21n%40googlegroups.com.

[go-nuts] Re: How to check Cmd.ProcessState without triggering the race checker?

[TheDiveO]

Per,

I fully agree for the case where you have full control over the code 
architecture ... in such a case the only way is to stop digging and getting 
out of the hole. Or have a party leadership contest instead ... just 
[j|ch]oking.

In this particular situation I don't have control over the Gomega TDD 
session package and how it deploys Wait in a separate goroutine. On its 
own, I consider Gomega's design to be fine here. It is just when bringing 
file descriptor checks to a session/exec.Cmd where my issue comes up and 
where I can neither change Gomega's session Wait nor Go's exec.Cmd. The fd 
leak checks will be called potentially multiple times at seemingly 
arbitrary times for the session under test, while the session under test 
might throw its tantrum at any time if it pleases to do so.

After some more pondering, I opted for Python's "try first, beg forgiveness 
later" strategy by throwing out the problematic check and trying to read 
the PID's fd directory anyway. If the PID is still valid that will succeed, 
if its gone that moment, it'll fail. Catching that error and reporting a 
more test user-friendly error instead makes this more robust, as well as 
user friendly.

I like your idea of pidfd_open, but after pondering it for a long time I 
don't think that it does help in this peculiar use case. It even 
complicates fd checking in several ways, as I will need to sort it out from 
leak checking and at the same time attempting to not leak it itself. This 
might quickly turn against be for little gain. On top of this, 
https://man7.org/linux/man-pages/man2/pidfd_open.2.html points out that 
when the child gets reaped then the pidfd becomes invalid. Nevertheless, I 
really appreciate you bringing up pidfd_open!

On a side note: I still cannot get over the fact that the fd returned by 
pidfd_open call can be used with setns as pointed out by someone else to me.

-- TheDiveO
On Monday, July 25, 2022 at 9:56:14 AM UTC+2 p...@morth.org wrote:

> Hi,
>
> I think you need to restructure your code, because what you're actually 
> doing is checking whether the pid is valid or not.
> Since the pid is made invalid inside the Wait call (in the kernel), before 
> ProcessState is set, there's no way to do that safely.
>
> Instead, you should avoid calling Wait until you're done using the pid. 
> You'll have to use some other method for detecting if the process has 
> exited. On newer Linux versions, the preferred way would be a pidfd 
> obtained via pidfd_open.
>
> Regards,
> Per Johansson
> On Saturday, July 23, 2022 at 10:39:17 PM UTC+2 harald@gmx.net wrote:
>
>> In my open source file descriptor leak checker (Linux only) for Gomega, 
>> Go's race detector flags a race condition in my code where I need to 
>> check whether a Cmd.Process already has terminated 
>> 
>>  
>> as its ProcessState has been set.
>>
>> if session.Command.ProcessState != nil {
>> return nil, errors.New("session has already ended")
>> }
>>
>> Now, this check might be called be called from a different Goroutine than 
>> another Goroutine waiting for the command to exit. In particular, this is 
>> the (what I consider to be the relevant) output of the race detector:
>>
>> WARNING: DATA RACE
>> Write at 0x00c0002e8208 by goroutine 16:
>>   os/exec.(*Cmd).Wait()
>>   /home/.../sdk/go1.19rc2/src/os/exec/exec.go:598 +0x1eb
>>   github.com/onsi/gomega/gexec.(*Session).monitorForExit()
>>   /home/.../go/pkg/mod/
>> github.com/onsi/gom...@v1.20.0/gexec/session.go:197 
>>  +0x44
>>   github.com/onsi/gomega/gexec.Start.func1()
>>   /home/.../go/pkg/mod/
>> github.com/onsi/gom...@v1.20.0/gexec/session.go:96 
>>  +0x47
>>
>> Previous read at 0x00c0002e8208 by goroutine 12:
>>   github.com/thediveo/fdooze/session.FiledescriptorsFor()
>>   /home/.../github/fdooze/session/session_fds.go:21 +0x1b7
>>   github.com/thediveo/fdooze/session.glob..func1.1.1()
>>   /home/.../github/fdooze/session/session_fds_test.go:45 +0x30
>>   runtime.call16()
>>   /home/.../sdk/go1.19rc2/src/runtime/asm_amd64.s:724 +0x48
>>   reflect.Value.Call()
>>   /home/.../sdk/go1.19rc2/src/reflect/value.go:368 +0xc7
>>   github.com/onsi/gomega/internal.NewAsyncAssertion.func1()
>>   /home/.../go/pkg/mod/
>> github.com/onsi/gom...@v1.20.0/internal/async_assertion.go:48 
>>  
>> +0x16e
>>   github.com/onsi/gomega/internal.(*AsyncAssertion).pollActual()
>>   /home/.../go/pkg/mod/
>> github.com/onsi/gom...@v1.20.0/internal/async_assertion.go:132 
>>  
>> +0x82
>>   github.com/onsi/gomega/internal.(*AsyncAssertion).match()
>>   /home/.../go/pkg/mod/
>> 

[go-nuts] Protobuf build error with gogo - has inconsistent names structpb

[santhoshth...@gmail.com]

Hi Everyone

I am importing the proto of other project into my proto file and run protoc 
command. 
I got this below error :

*Go package "github.com/gogo/protobuf/types" has inconsistent names 
structpb (google/protobuf/struct.proto) and timestamppb 
(google/protobuf/timestamp.proto)*

*protoc command:*
User/project/web/tools/protoc-3.17.3/bin/protoc 
--proto_path=User/project:. 
-I=User/project/web/rpc/protomgr 
-I=User/project/web/protobuf-import 
--plugin=protoc-gen-twirp=User/project/bin/protoc-gen-twirp 
--plugin=protoc-gen-go=User/project/bin/protoc-gen-go 
--plugin=protoc-gen-go-grpc=User/project/bin/protoc-gen-go-grpc 
--twirp_out=. 
go_out=Mgoogle/protobuf/any.proto=github.com/gogo/protobuf/types,Mgoogle/protobuf/duration.proto=github.com/gogo/protobuf/types,Mgoogle/protobuf/struct.proto=github.com/gogo/protobuf/types,Mgoogle/protobuf/timestamp.proto=github.com/gogo/protobuf/types,Mgoogle/protobuf/wrappers.proto=github.com/gogo/protobuf/types:.
 
proto_file.proto


The both proto files has the import of 

*import "google/protobuf/timestamp.proto";import 
"google/protobuf/struct.proto";*


I can't figure out what is happening here. Can somebody provide some 
suggestions? 

-- 
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/35ae493c-b935-40f2-8e48-8326726dcc0fn%40googlegroups.com.

[go-nuts] Re: Print a json item wit a for loop

[Brian Candler]

You haven't said what you're trying to do, and the error tells you that p 
doesn't have a field called "jitem".

Perhaps what you are trying to do is to extract a member from a structure 
dynamically: that is, jitem is the *name* of a struct member, only known at 
runtime?  In that case, you can use the Reflect package:
https://go.dev/play/p/QxTsm7CqDWg

But that's really ugly and I think you should avoid it if at all possible.  
Go is not Python.

There are safer and simpler approaches, for example:
https://go.dev/play/p/MlNoZvGiuVc
https://go.dev/play/p/293uVj_usQ5

If all you're trying to do is pretty-print JSON, then encoding/json can do 
that for you:
https://go.dev/play/p/0oIKG7dn1KQ
or you can use a YAML library.

On Monday, 25 July 2022 at 04:37:21 UTC+1 a.enrriqu...@gmail.com wrote:

> Please help me with this
>
>
> func printitem(r Response, jitem string) []string {
> item := []string{}
> for _, p := range r.Result {
> item = append(item, jitem+":"+p.jitem)
> }
> return item
> }
> how to pass a variable to this, jitem
>
> p.jitem undefined (type struct{BlockNumber string "json:\"blockNumber\""; 
> TimeStamp string "json:\"timeStamp\""; Hash string "json:\"hash\""; Nonce 
> string "json:\"nonce\""; BlockHash string "json:\"blockHash\""; 
> TransactionIndex string "json:\"transactionIndex\""; From string 
> "json:\"from\""; To string "json:\"to\""; Value string "json:\"value\""; 
> Gas string "json:\"gas\""; GasPrice string "json:\"gasPrice\""; IsError 
> string "json:\"isError\""; TxreceiptStatus string 
> "json:\"txreceipt_status\""; Input string "json:\"input\""; ContractAddress 
> string "json:\"contractAddress\""; CumulativeGasUsed string 
> "json:\"cumulativeGasUsed\""; GasUsed string "json:\"gasUsed\""; 
> Confirmations string "json:\"confirmations\""} has no field or method 
> jitem)compilerMissingFieldOrMethod 
> 
>
>

-- 
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/e0e771c0-235f-4b49-a991-2f31bc4f4aa3n%40googlegroups.com.

[go-nuts] Re: How to check Cmd.ProcessState without triggering the race checker?

[p...@morth.org]

Hi,

I think you need to restructure your code, because what you're actually 
doing is checking whether the pid is valid or not.
Since the pid is made invalid inside the Wait call (in the kernel), before 
ProcessState is set, there's no way to do that safely.

Instead, you should avoid calling Wait until you're done using the pid. 
You'll have to use some other method for detecting if the process has 
exited. On newer Linux versions, the preferred way would be a pidfd 
obtained via pidfd_open.

Regards,
Per Johansson
On Saturday, July 23, 2022 at 10:39:17 PM UTC+2 harald@gmx.net wrote:

> In my open source file descriptor leak checker (Linux only) for Gomega, 
> Go's race detector flags a race condition in my code where I need to 
> check whether a Cmd.Process already has terminated 
> 
>  
> as its ProcessState has been set.
>
> if session.Command.ProcessState != nil {
> return nil, errors.New("session has already ended")
> }
>
> Now, this check might be called be called from a different Goroutine than 
> another Goroutine waiting for the command to exit. In particular, this is 
> the (what I consider to be the relevant) output of the race detector:
>
> WARNING: DATA RACE
> Write at 0x00c0002e8208 by goroutine 16:
>   os/exec.(*Cmd).Wait()
>   /home/.../sdk/go1.19rc2/src/os/exec/exec.go:598 +0x1eb
>   github.com/onsi/gomega/gexec.(*Session).monitorForExit()
>   /home/.../go/pkg/mod/
> github.com/onsi/gom...@v1.20.0/gexec/session.go:197 
>  +0x44
>   github.com/onsi/gomega/gexec.Start.func1()
>   /home/.../go/pkg/mod/
> github.com/onsi/gom...@v1.20.0/gexec/session.go:96 
>  +0x47
>
> Previous read at 0x00c0002e8208 by goroutine 12:
>   github.com/thediveo/fdooze/session.FiledescriptorsFor()
>   /home/.../github/fdooze/session/session_fds.go:21 +0x1b7
>   github.com/thediveo/fdooze/session.glob..func1.1.1()
>   /home/.../github/fdooze/session/session_fds_test.go:45 +0x30
>   runtime.call16()
>   /home/.../sdk/go1.19rc2/src/runtime/asm_amd64.s:724 +0x48
>   reflect.Value.Call()
>   /home/.../sdk/go1.19rc2/src/reflect/value.go:368 +0xc7
>   github.com/onsi/gomega/internal.NewAsyncAssertion.func1()
>   /home/.../go/pkg/mod/
> github.com/onsi/gom...@v1.20.0/internal/async_assertion.go:48 
>  
> +0x16e
>   github.com/onsi/gomega/internal.(*AsyncAssertion).pollActual()
>   /home/.../go/pkg/mod/
> github.com/onsi/gom...@v1.20.0/internal/async_assertion.go:132 
>  
> +0x82
>   github.com/onsi/gomega/internal.(*AsyncAssertion).match()
>   /home/.../go/pkg/mod/
> github.com/onsi/gom...@v1.20.0/internal/async_assertion.go:162 
>  
> +0xe4
>   github.com/onsi/gomega/internal.(*AsyncAssertion).ShouldNot()
>   /home/.../go/pkg/mod/
> github.com/onsi/gom...@v1.20.0/internal/async_assertion.go:112 
>  
> +0xa9
>   github.com/thediveo/fdooze/session.glob..func1.1()
>   /home/.../github/fdooze/session/session_fds_test.go:65 +0xf41
>   github.com/onsi/ginkgo/v2/internal.(*Suite).runNode.func2()
>   /home/.../go/pkg/mod/
> github.com/onsi/ginkgo/v...@v2.1.4/internal/suite.go:596 
>  +0xea
>
> Is there actually any way to check use Cmd.ProcessState at all from a 
> thread different from the one doing a Cmd.Wait? Might this be a design 
> "weakness" of the Cmd type in that it doesn't cover such use cases?
>
> Any idea for a work around to find if the command might already have 
> (prematurely) finished by the time I try to check for its open file 
> descriptors?
>

-- 
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/64d8618c-63a8-4cb1-879e-a28aec93da0cn%40googlegroups.com.