Re: [go-nuts] Remind me, please, about "taking over" a socket

[Bakul Shah]

On Thu, 30 May 2019 20:10:30 -0700 Bakul Shah  wrote:
>
> You will have to use low level code like Socket(), Bind() etc. You can't
> use e.g. Dial("tcp", "192.168.1.1:smtp")

This should've been edited out since we are talking about Listen.

-- 
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/20190531031238.77959156E40C%40mail.bitblocks.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Remind me, please, about "taking over" a socket

[Bakul Shah]

On Thu, 30 May 2019 17:40:55 -0700 David Collier-Brown  
wrote:
>
> My leaky brain has lost an old technique...
>
> Once upon a time, I would send an old copy of a program a SIGHUP, and it 
> would shut down a socket listening on, for example, port 25 (SMTP). A newer 
> release of the program would succeeding in binding to port 25, taking over 
> any new connection requests. When the old program closed it's last email 
> transfer, it would then exit.
>
> The idea was to update a (mail-)server implementation without losing 
> transactions.
>
> I can no longer find the code I once used, nor other people's examples, 
> much less modern Golang examples!
>
> Please tell me we haven't lost this technique (:-()

man setsockopt and look for SO_REUSEADDR/SO_REUSEPORT

You will have to use low level code like Socket(), Bind() etc. You can't
use e.g. Dial("tcp", "192.168.1.1:smtp")


Something like
err := syscall.SetsockoptInt(s, syscall.SOL_SOCKET, syscall.SO_REUSEADDR, 1)
err := syscall.SetsockoptInt(s, syscall.SOL_SOCKET, syscall.SO_REUSEPORT, 1)

https://github.com/libp2p/go-reuseport has an example.

Though IMHO such ports should be passed from an *external*
program for security purposes (your service enpoint shouldn't
be opening any ports on its own). Also makes it easier to
test.

-- 
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/20190531031037.892A0156E40C%40mail.bitblocks.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] go version go1.12 and cannot find module providing package

[Tong Sun]

Hi, 

For this line,

https://github.com/go-jsonfile/jsonfiddle/blob/f44996d66c751dac409d15e5f132a65ece42da59/cmd_x2j.go#L17

I'm getting

build github.com/go-jsonfile/jsonfiddle: cannot load 
github.com/mkideal/cli/clis: cannot find module providing package 
github.com/mkideal/cli/clis

when building under go version go1.12. 
And things were fine before go1.12. 

Where the problem is? 
How to fix it? -- I've tried.

go get -v -u github.com/mkideal/cli

and

go get -v -u github.com/mkideal/cli/clis

but neither works. 

Is it because how the package is defined? But that's not much different 
from:
https://github.com/mkideal/cli/blob/41df2d00b0edfa4614da67cf68f41df9d4e55539/ext/decoders.go#L1
but how come that package is OK? 

Thx

-- 
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/8ed57e68-4b13-4869-a9b8-efe69e49dda7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Remind me, please, about "taking over" a socket

[Skip Tavakkolian]

Do you mean like tcp half-close?

On Thu, May 30, 2019, 5:40 PM David Collier-Brown 
wrote:

> My leaky brain has lost an old technique...
>
> Once upon a time, I would send an old copy of a program a SIGHUP, and it
> would shut down a socket listening on, for example, port 25 (SMTP). A newer
> release of the program would succeeding in binding to port 25, taking over
> any new connection requests. When the old program closed it's last email
> transfer, it would then exit.
>
> The idea was to update a (mail-)server implementation without losing
> transactions.
>
> I can no longer find the code I once used, nor other people's examples,
> much less modern Golang examples!
>
> Please tell me we haven't lost this technique (:-()
>
> --dave
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/36fabc29-6ccc-45f6-99bb-f728710c6e18%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJSxfmKG%3Dw3sWRMHXg5EPG%2BRBAxvbd1iSOnyPN1a%3De6zKL%3D%3D6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Remind me, please, about "taking over" a socket

[David Collier-Brown]

My leaky brain has lost an old technique...

Once upon a time, I would send an old copy of a program a SIGHUP, and it 
would shut down a socket listening on, for example, port 25 (SMTP). A newer 
release of the program would succeeding in binding to port 25, taking over 
any new connection requests. When the old program closed it's last email 
transfer, it would then exit.

The idea was to update a (mail-)server implementation without losing 
transactions.

I can no longer find the code I once used, nor other people's examples, 
much less modern Golang examples!

Please tell me we haven't lost this technique (:-()

--dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/36fabc29-6ccc-45f6-99bb-f728710c6e18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Interesting public commentary on Go...

[David Skinner]

I only rarely use generics in Go. When I do so, it is implemented using the 
+generate. The repos with my generics stuff is not public. If they were, 
they might be incomprehensible. While I rather like Fo, the thought of C++ 
style generics makes me cringe. Code must compile but it needs to be 
readable.

I am very old school, I started programming with 8008 machine code. If 
something does not meet my needs, I may complain, but I may just write what 
I need. Go does not have generics but it is very easy for any user to 
implement generics in a variety of ways on an as needed basis. The thing 
is, I am not committed to Go, I am willing to use whatever works best for 
me, and right now that is Go, and I believe that that is the result of the 
experience of the Go team residing at Google in working as a team.

I remember doing a code review at Sierra Online, it was a metrics project 
to evaluate employee performance, one programmer was so bad, I asked the 
head of the programming department to have him shot. He said, you want him 
fired? No, I want him shot, if you fire him, he will go and write bad code 
somewhere else. For some reason I do not understand, the company had a 
policy against shooting programmers that violated the style guidelines.

When this is your life and your livelihood, it is easy to get emotional. 
Right now, I am still saying Thank you Google, and Thank you to the Go Dev 
Team. Well Done! Hope you do better next year. :)



On Thursday, May 23, 2019 at 8:18:25 AM UTC-5, lgo...@gmail.com wrote:
>
> https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage
>

-- 
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/3e72df2e-e27d-4dbe-9545-8527bdce1e35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Go Module Mirror and Checksum Database in Beta!

[Katie Hockman]

Hey Gophers!



In the blog post Go Modules in 2019 ,
we announced our intent to provide a module mirror for accelerating Go
module downloads, an index for discovering new modules, and a checksum
database for authenticating module content.



We are excited to share that our module mirror, index, and checksum
database are now in beta, and are currently the default at tip for Go 1.13
development branch module-users!



Our privacy policy explains how we collect and use your information. The
privacy policy for all of these services is proxy.golang.org/privacy.



The module mirror at proxy.golang.org serves the go command’s proxy
protocol. The Go 1.13 development tree uses this mirror for all module
downloads by default. See the go command documentation at tip

for details. To make earlier versions of the go command use it (when in
module mode), set GOPROXY=https://proxy.golang.org.



The checksum database at sum.golang.org helps verify new downloads from
proxies or direct fetches, serving the URLs described in the Secure the
Public Go Module Ecosystem

proposal. The Go 1.13 development tree checks new module versions against
the checksum database by default. Earlier versions of the go command cannot
directly use the checksum database.

See the go command documentation at tip
 for
details.



If you are using Go 1.12 or earlier, you can manually check a go.sum file
against the checksum database with gosumcheck
:



go get golang.org/x/exp/sumdb/gosumcheck

gosumcheck /path/to/go.sum



The module index at index.golang.org serves a feed of module versions in
the order they are discovered. For example, see
https://index.golang.org/index?since=2019-03-04T18:00:15.161182-07:00



We hope you’ll try out these new services! Please file issues
 if you spot them, with the title
prefix “proxy.golang.org:” (or index.golang.org, or sum.golang.org). We
look forward to hearing about how it’s working for you!

Cheers,

Katie Hockman

-- 
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/CALvTBveJGhNQ0x3f6R-_gmXr%2B4fKfdNVvmHbDDC-qM1u_yDwbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] About godoc and private doc server

[Ain]

Hi

It seems that godoc doesn't work with modules, in the sense that it doesn't 
find / show documentation of the modules outside GOPATH...?

And about doc server... say I want to have private godoc server, mainly to 
serve doc of some private libs (hosted on github, but private repos) but 
wouldn't mind if it also contains stdlib doc and popular "public libs" - 
what options do I have? I can think of two:

1) something godoc based - install the libs into GOPATH, launch godoc and 
expose it... probably have to create custom template too;
2) use godoc.org, available at github golang/gddo repo.

Any other options?
Any tips how to set it up (ie what needs to be done to get godoc.org up and 
able to access private repos)?


TIA
ain

-- 
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/e5d53b6a-5212-41d9-be10-2c6463aeef7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Michal Strba]

Ian and David, thanks for the response! I personally don't consider MIn and
Max to be so important, however, I understand if you do. I've added a new
little part to the proposal that describes one possible way for them to be
supported:

Currently, the type-checker has to distinguish between three kinds of
> generic parameters:
>
> 1. Any type.
> 2. Any type with `==`.
> 3. Integer constant.
>
> This list could be extended to include support for _any numeric type_
> (with operators like `+`, `-`, ...). This would make it possible to make
> functions like `Min`, `Max`, and so on.
>

I've also added a better description of the scope of the identifiers
declared with the gen keyword as Ian pointed out:

The identifier after `gen` is then a generic type identifier visible in the
> whole rest of the function (signature and body).



št 30. 5. 2019 o 21:44 David Riley  napísal(a):

> On May 30, 2019, at 2:25 PM, Ian Lance Taylor  wrote:
> >
> > One of my guidelines for an acceptable generics proposal is that
> > people can write Min and Max.  Your proposal admits that it doesn't
> > permit that.  I think that is a problem.  I'm fine with the general
> > idea of "do 80% of the job" but in practice people really do want to
> > write Min and Max.  I think they are part of the 80% that needs to be
> > handled, not the 20% that can be omitted.
>
> I agree strongly with this metric. My principal reason for wanting
> generics is precisely so I can avoid writing the kind of repetitive code
> that I currently need to write to perform the exact same simple operations
> on similar datatypes.  Min and Max are perfect examples of that, Map and
> Filter are slightly more complex ones.
>
> If I can't write Min and Max for generic data types, I'm not using it.
> YMMV.
>
>
> - Dave

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

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

[David Riley]

On May 30, 2019, at 2:25 PM, Ian Lance Taylor  wrote:
> 
> One of my guidelines for an acceptable generics proposal is that
> people can write Min and Max.  Your proposal admits that it doesn't
> permit that.  I think that is a problem.  I'm fine with the general
> idea of "do 80% of the job" but in practice people really do want to
> write Min and Max.  I think they are part of the 80% that needs to be
> handled, not the 20% that can be omitted.

I agree strongly with this metric. My principal reason for wanting generics is 
precisely so I can avoid writing the kind of repetitive code that I currently 
need to write to perform the exact same simple operations on similar datatypes. 
 Min and Max are perfect examples of that, Map and Filter are slightly more 
complex ones.

If I can't write Min and Max for generic data types, I'm not using it.  YMMV.


- Dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/BC671E96-348F-409A-A24B-AD9DCE21783F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Aggressive Golang Garbage Collection Issues When Using cgo?

[Steven Estes]

 Thankyou kddavidson772. Although it's not critical for this particular 
test, I will add that to this test and another very similar to it that 
operates slightly differently. I have put the same seed code you suggest in 
other routines but other folks wrote the initial versions of this 
particular test and that piece seems to have been missed out on even in the 
original from which my test was cut down from.

-- 
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/a04d6d66-6a9e-4999-97b5-1c900b6f3307%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Adding a timeout to a script interpreter (without leaking a goroutine)

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

plus you'd lose the ability to compute ackerman's function, which i'm doing
all the time

On Wed, May 29, 2019 at 7:35 AM adonovan via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Tuesday, 21 May 2019 01:18:34 UTC-4, Ben Hoyt wrote:
>>
>> I'm looking at adding a timeout option to my GoAWK script interpreter...
>> Are there better / more performant ways to handle this?
>>
>
>
> Hi Ben, imposing resource bounds is a tricky problem. It's possible to do
> it in an interpreter implemented in C++, but it requires careful discipline
> throughout the implementation. It is essentially impossible to do in a
> target language whose variables are recycled by the garbage collector of
> the host language. Turing incompleteness of the target language (bounded
> recursion only) seems like it ought to help but in fact does not; a bounded
> program can still use all your memory and take ~forever.
>
> The only reliable way to impose bounds is to use the operating system. Put
> the untrusted code in a different process, impose a limit on its maximum
> memory size, and kill it if it hasn't finished by your deadline.
>
>
> --
> 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/b4182f6d-8a3c-41a2-9cb0-e9d3c7fb1780%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

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

[Ian Lance Taylor]

On Thu, May 30, 2019 at 12:28 PM Michal Strba  wrote:
>
> I've been thinking about generics in Go 2 ever since the original contracts 
> proposal and few days ago, ideas finally clicked. One of the main things 
> about this proposal is that it deliberately omits the ability to restrict the 
> set of types a function can work with. This is a limitation, but I hope to 
> convince you that we can still do a vast majority of the things we were 
> missing, when we were missing generics.
>
> I'd love to share my proposal with you and engage in a good faith 
> conversation.
>
> Link to the proposal.
>
> Here's what the proposal covers:
>
> 1. Syntax of a new gen keyword.
> 2. Generic functions.
> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in new 
> function).
> 4. Semantics of generic values (ability to use them as map keys, ...).
> 5. Generic array lengths.
> 6. Reflection and interface{}.
> 7. Generic types (with two examples: List and Matrix).
> 8. Generic methods and their limitations due to reflection.
> 9. Generic interfaces.
> 10. List of things this proposal can't do.

One of my guidelines for an acceptable generics proposal is that
people can write Min and Max.  Your proposal admits that it doesn't
permit that.  I think that is a problem.  I'm fine with the general
idea of "do 80% of the job" but in practice people really do want to
write Min and Max.  I think they are part of the 80% that needs to be
handled, not the 20% that can be omitted.

You need to think about scoping.  The "gen" keyword doesn't just mean
that the next identifier is a generic type; it also defines that
identifier for some scope, since your examples use it that way.  The
proposal needs to carefully spell out the scope of an identifier, and
exactly when it shadows or is shadowed by other objects with the same
name.

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/CAOyqgcUGKXt4XJVaa_5PZaaN%2BVxww9T%2BU%3De%2B%2BXEc5L-AgzHEBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How do you keep your modules up-to-date?

[James Hartig]

Marcin,

Thanks for the reply! So do you have Jenkins run go get -u, run tests, and 
then commit the changes? Does it automatically only update private repos or 
does it update both? Is there any review process each week to validate the 
updates?

I'm leaning towards a combination of what you suggested and what I 
mentioned as 2: Have CI run go get -u for all private repos before the 
build starts. So weekly would update all deps and each build would update 
all private deps.

On Thursday, May 30, 2019 at 12:19:28 PM UTC-4, Marcin Romaszewicz wrote:
>
> I have the same kind of setup at my company, and we use go modules in the 
> same way that we would use public modules. We periodically do a "go get -u" 
> to update them. Jenkins does that once a week, so at worst, we're a week 
> behind. If someone needs to manually pull in changes more urgently, they 
> can just run the "go get" themselves and commit go.mod and go.sum. It works 
> well. Don't be too smart with this stuff, and just let the module system 
> work as intended. When you use private repos, it's a pain in the butt to 
> have the auth work, but it sounds like you've got that solved.
>
> -- Marcin
>
> On Thu, May 30, 2019 at 7:55 AM James Hartig  > wrote:
>
>> What's the best way to automatically always pull the latest 
>> release/commit for certain repos? We use gerrit internally so all of our 
>> import paths for internal packages start with something like gerrit.corp. 
>> We have over 50 different repos and it would be painstaking to have to 
>> update (pull latest, run go get, commit, get review) every single one of 
>> those repos whenever an internal package was updated with a minor change.
>>
>> How do others solve the problem of outdated modules? Do developers 
>> frequently commit "Go modules updated" changes where they just update the 
>> go.mod? Is there a process defined where every repo has their deps updated 
>> once a month/week/etc?
>>
>> 1) Would it be better to just remove gerrit.corp lines from go.mod before 
>> it's committed so the dependencies are always resolved at run-time by CI?
>> 2) Should our CI system look at go.mod and run go get -u for each 
>> gerrit.corp line as part of the build/test pipeline?
>> 3) Or should we just run "go get -u ..." on every CI build to always have 
>> the latest minor updates of all modules?
>>
>> -- 
>> 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/909a63a6-0e02-4129-bf5d-efadb353acf4%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7e16bf06-8fd2-4c50-939f-6c4d44be917a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Aggressive Golang Garbage Collection Issues When Using cgo?

[kddavidson722]

Sry I ment genName()

-- 
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/3d0269a9-e67f-426b-9e2d-e9e248c983ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Raffaele Sena]

Completely agree about "Generics are useful except when their syntax
becomes cryptic". But reading this proposal (quickly, while doing a bunch
of other stuff :), the syntax is very clean and the proposal is very well
thought.


On Thu, May 30, 2019 at 10:44 AM Michal Strba  wrote:

> I agree with that. What exactly do you consider cryptic, though, about
> my proposal? I thought the syntax was very clean. Furthermore,
> regarding relating this to C++, I quote:
>
> > Just to make it clear, you aren't allowed to use operators like +, -, <,
> call methods, or access struct fields of a generic value
>
> I'm just not sure how your sentiment relates to the proposal.
>
> št 30. 5. 2019 o 19:41  napísal(a):
> >
> > Sorry again for the power failure...let me try one last time
> >
> > one of the annoying things you have to deal with as a team member is
> being assigned an "update" of code written by someone who no longer works
> for the team.
> > What makes this annoying is possibility of running into code sections
> that contain "crytic" statements that require lots of effort to understand.
> >  After looking at the link you provided, based on my history dealing
> with unnecessary and avoidable 'cryptic C++,
> >  my input  is:  Generics are a great idea EXCEPT when they allow use of
> cryptic syntax
> >
> > On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, Michal Strba wrote:
> >>
> >> Hi Gophers! :)
> >>
> >> I've been thinking about generics in Go 2 ever since the original
> contracts proposal and few days ago, ideas finally clicked. One of the main
> things about this proposal is that it deliberately omits the ability to
> restrict the set of types a function can work with. This is a limitation,
> but I hope to convince you that we can still do a vast majority of the
> things we were missing, when we were missing generics.
> >>
> >> I'd love to share my proposal with you and engage in a good faith
> conversation.
> >>
> >> Link to the proposal.
> >>
> >> Here's what the proposal covers:
> >>
> >> 1. Syntax of a new gen keyword.
> >> 2. Generic functions.
> >> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the
> built-in new function).
> >> 4. Semantics of generic values (ability to use them as map keys, ...).
> >> 5. Generic array lengths.
> >> 6. Reflection and interface{}.
> >> 7. Generic types (with two examples: List and Matrix).
> >> 8. Generic methods and their limitations due to reflection.
> >> 9. Generic interfaces.
> >> 10. List of things this proposal can't do.
> >>
> >> Thanks,
> >> faiface
> >
> > --
> > 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/4e266f34-32d8-4b3d-8f45-55da5651ed9e%40googlegroups.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAO6k0usA%3D6EdH6mpTPqYnpnEBWNu8GST%2Bam-G2rQEZNPGUPC7A%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Interesting public commentary on Go...

[Paul Jolly]

Just to expand on Russ' point about golang-tools:
 

> In fact there is now a roughly biweekly “Go tools” meeting which is 
> typically attended by more tool and editor integration authors from outside 
> Google than from inside Google and organized by a contributor outside 
> Google. (If you want to know more about that, email Paul Jolly, 
> pa...@myitcv.io .)
>

More details available in the golang-tools wiki: 
https://github.com/golang/go/wiki/golang-tools, including links to YouTube 
recordings and notes from previous sessions. 

Our standards have slipped somewhat and we now meet on Hangouts once a 
month, but that somewhat belies the huge progress currently being made with 
gopls, go/packages, go/analysis and all the various editors integrations. 

The (now) monthly calls, mailing list and Slack channels are open to 
everyone.

Please feel free to email me (p...@myitcv.io) or join 
https://groups.google.com/forum/#!forum/golang-tools if you have any 
questions.

Thanks


-- 
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/beefdd05-b5b9-41cc-881e-878f2e8325d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Michal Strba]

I agree with that. What exactly do you consider cryptic, though, about
my proposal? I thought the syntax was very clean. Furthermore,
regarding relating this to C++, I quote:

> Just to make it clear, you aren't allowed to use operators like +, -, <, call 
> methods, or access struct fields of a generic value

I'm just not sure how your sentiment relates to the proposal.

št 30. 5. 2019 o 19:41  napísal(a):
>
> Sorry again for the power failure...let me try one last time
>
> one of the annoying things you have to deal with as a team member is being 
> assigned an "update" of code written by someone who no longer works for the 
> team.
> What makes this annoying is possibility of running into code sections that 
> contain "crytic" statements that require lots of effort to understand.
>  After looking at the link you provided, based on my history dealing with 
> unnecessary and avoidable 'cryptic C++,
>  my input  is:  Generics are a great idea EXCEPT when they allow use of 
> cryptic syntax
>
> On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, Michal Strba wrote:
>>
>> Hi Gophers! :)
>>
>> I've been thinking about generics in Go 2 ever since the original contracts 
>> proposal and few days ago, ideas finally clicked. One of the main things 
>> about this proposal is that it deliberately omits the ability to restrict 
>> the set of types a function can work with. This is a limitation, but I hope 
>> to convince you that we can still do a vast majority of the things we were 
>> missing, when we were missing generics.
>>
>> I'd love to share my proposal with you and engage in a good faith 
>> conversation.
>>
>> Link to the proposal.
>>
>> Here's what the proposal covers:
>>
>> 1. Syntax of a new gen keyword.
>> 2. Generic functions.
>> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in new 
>> function).
>> 4. Semantics of generic values (ability to use them as map keys, ...).
>> 5. Generic array lengths.
>> 6. Reflection and interface{}.
>> 7. Generic types (with two examples: List and Matrix).
>> 8. Generic methods and their limitations due to reflection.
>> 9. Generic interfaces.
>> 10. List of things this proposal can't do.
>>
>> Thanks,
>> faiface
>
> --
> 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/4e266f34-32d8-4b3d-8f45-55da5651ed9e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

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

[lgodio2]

Sorry again for the power failure...let me try one last time

one of the annoying things you have to deal with as a team member is being 
assigned an "update" of code written by someone who no longer works for the 
team.
What makes this annoying is possibility of running into code sections that 
contain "crytic" statements that require lots of effort to understand.
 After looking at the link you provided, based on my history dealing with 
unnecessary and avoidable 'cryptic C++,
 my input  is:  Generics are a great idea EXCEPT when they allow use of 
cryptic syntax

On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, Michal Strba wrote:
>
> Hi Gophers! :)
>
> I've been thinking about generics in Go 2 ever since the original 
> contracts proposal and few days ago, ideas finally clicked. One of the main 
> things about this proposal is that it deliberately omits the ability to 
> restrict the set of types a function can work with. This is a limitation, 
> but I hope to convince you that we can still do a vast majority of the 
> things we were missing, when we were missing generics. 
>
> I'd love to share my proposal with you and engage in a good faith 
> conversation.
>
> Link to the proposal. 
> 
>
> Here's what the proposal covers:
>
> 1. Syntax of a new gen keyword.
> 2. Generic functions.
> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in 
> new function).
> 4. Semantics of generic values (ability to use them as map keys, ...).
> 5. Generic array lengths.
> 6. Reflection and interface{}.
> 7. Generic types (with two examples: List and Matrix).
> 8. Generic methods and their limitations due to reflection.
> 9. Generic interfaces.
> 10. List of things this proposal can't do.
>
> Thanks,
> faiface
>

-- 
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/4e266f34-32d8-4b3d-8f45-55da5651ed9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Michal Strba]

> Generics are useful except when their syntax becomes cryptic 

I agree, are you referring to anything specific?

Dňa štvrtok, 30. mája 2019 19:29:09 UTC+2 L Godioleskky napísal(-a):
>
>
>
> On Thursday, May 30, 2019 at 1:24:55 PM UTC-4, L Godioleskky wrote:
>>
>> one of the annoying things you have to deal with as a team member is 
>> being assigned an "update" of code written by someone who no longer works 
>> for the team. What makes this annoying is possibility of running into code 
>> sections that contain "crytic" statements that require lots of effort to 
>> understand. After looking at the link you provided my input, based on 
>> dealing with cryptic C++  is: Go should not allow cryptic syntax.
>>
> Generics are useful except when their syntax becomes cryptic 
>  
>
>>   w
>>
>> On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, Michal Strba wrote:
>>>
>>> Hi Gophers! :)
>>>
>>> I've been thinking about generics in Go 2 ever since the original 
>>> contracts proposal and few days ago, ideas finally clicked. One of the main 
>>> things about this proposal is that it deliberately omits the ability to 
>>> restrict the set of types a function can work with. This is a limitation, 
>>> but I hope to convince you that we can still do a vast majority of the 
>>> things we were missing, when we were missing generics. 
>>>
>>> I'd love to share my proposal with you and engage in a good faith 
>>> conversation.
>>>
>>> Link to the proposal. 
>>> 
>>>
>>> Here's what the proposal covers:
>>>
>>> 1. Syntax of a new gen keyword.
>>> 2. Generic functions.
>>> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in 
>>> new function).
>>> 4. Semantics of generic values (ability to use them as map keys, ...).
>>> 5. Generic array lengths.
>>> 6. Reflection and interface{}.
>>> 7. Generic types (with two examples: List and Matrix).
>>> 8. Generic methods and their limitations due to reflection.
>>> 9. Generic interfaces.
>>> 10. List of things this proposal can't do.
>>>
>>> Thanks,
>>> faiface
>>>
>>

-- 
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/042a2594-1a00-43e9-8866-86c362d9298b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[lgodio2]

llow

On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, Michal Strba wrote:
>
> Hi Gophers! :)
>
> I've been thinking about generics in Go 2 ever since the original 
> contracts proposal and few days ago, ideas finally clicked. One of the main 
> things about this proposal is that it deliberately omits the ability to 
> restrict the set of types a function can work with. This is a limitation, 
> but I hope to convince you that we can still do a vast majority of the 
> things we were missing, when we were missing generics. 
>
> I'd love to share my proposal with you and engage in a good faith 
> conversation.
>
> Link to the proposal. 
> 
>
> Here's what the proposal covers:
>
> 1. Syntax of a new gen keyword.
> 2. Generic functions.
> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in 
> new function).
> 4. Semantics of generic values (ability to use them as map keys, ...).
> 5. Generic array lengths.
> 6. Reflection and interface{}.
> 7. Generic types (with two examples: List and Matrix).
> 8. Generic methods and their limitations due to reflection.
> 9. Generic interfaces.
> 10. List of things this proposal can't do.
>
> Thanks,
> faiface
>

-- 
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/5f5ec80f-ce98-4420-9837-d0800852ced1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[lgodio2]

On Thursday, May 30, 2019 at 1:24:55 PM UTC-4, L Godioleskky wrote:
>
> one of the annoying things you have to deal with as a team member is being 
> assigned an "update" of code written by someone who no longer works for the 
> team. What makes this annoying is possibility of running into code sections 
> that contain "crytic" statements that require lots of effort to understand. 
> After looking at the link you provided my input, based on dealing with 
> cryptic C++  is: Go should not allow cryptic syntax.
>
Generics are useful except when their syntax becomes cryptic 
 

>   w
>
> On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, Michal Strba wrote:
>>
>> Hi Gophers! :)
>>
>> I've been thinking about generics in Go 2 ever since the original 
>> contracts proposal and few days ago, ideas finally clicked. One of the main 
>> things about this proposal is that it deliberately omits the ability to 
>> restrict the set of types a function can work with. This is a limitation, 
>> but I hope to convince you that we can still do a vast majority of the 
>> things we were missing, when we were missing generics. 
>>
>> I'd love to share my proposal with you and engage in a good faith 
>> conversation.
>>
>> Link to the proposal. 
>> 
>>
>> Here's what the proposal covers:
>>
>> 1. Syntax of a new gen keyword.
>> 2. Generic functions.
>> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in 
>> new function).
>> 4. Semantics of generic values (ability to use them as map keys, ...).
>> 5. Generic array lengths.
>> 6. Reflection and interface{}.
>> 7. Generic types (with two examples: List and Matrix).
>> 8. Generic methods and their limitations due to reflection.
>> 9. Generic interfaces.
>> 10. List of things this proposal can't do.
>>
>> Thanks,
>> faiface
>>
>

-- 
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/168e423b-eb56-4c2c-8222-567756146dbc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[lgodio2]

one of the annoying things you have to deal with as a team member is being 
assigned an "update" of code written by someone who no longer works for the 
team. What makes this annoying is possibility of running into code sections 
that contains "crytic" statements that require lots of effort to 
understand. After looking at the link you provided my input, based on 
dealing with cryptic C++  is:
  w

On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, Michal Strba wrote:
>
> Hi Gophers! :)
>
> I've been thinking about generics in Go 2 ever since the original 
> contracts proposal and few days ago, ideas finally clicked. One of the main 
> things about this proposal is that it deliberately omits the ability to 
> restrict the set of types a function can work with. This is a limitation, 
> but I hope to convince you that we can still do a vast majority of the 
> things we were missing, when we were missing generics. 
>
> I'd love to share my proposal with you and engage in a good faith 
> conversation.
>
> Link to the proposal. 
> 
>
> Here's what the proposal covers:
>
> 1. Syntax of a new gen keyword.
> 2. Generic functions.
> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in 
> new function).
> 4. Semantics of generic values (ability to use them as map keys, ...).
> 5. Generic array lengths.
> 6. Reflection and interface{}.
> 7. Generic types (with two examples: List and Matrix).
> 8. Generic methods and their limitations due to reflection.
> 9. Generic interfaces.
> 10. List of things this proposal can't do.
>
> Thanks,
> faiface
>

-- 
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/6ef558bc-f66d-409e-bb78-7e40360e7a55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Michal Strba]

Hi Gophers! :)

I've been thinking about generics in Go 2 ever since the original contracts 
proposal and few days ago, ideas finally clicked. One of the main things 
about this proposal is that it deliberately omits the ability to restrict 
the set of types a function can work with. This is a limitation, but I hope 
to convince you that we can still do a vast majority of the things we were 
missing, when we were missing generics. 

I'd love to share my proposal with you and engage in a good faith 
conversation.

Link to the proposal. 


Here's what the proposal covers:

1. Syntax of a new gen keyword.
2. Generic functions.
3. Unnamed generic arguments (a.k.a. a way to gve a type to the built-in new 
function).
4. Semantics of generic values (ability to use them as map keys, ...).
5. Generic array lengths.
6. Reflection and interface{}.
7. Generic types (with two examples: List and Matrix).
8. Generic methods and their limitations due to reflection.
9. Generic interfaces.
10. List of things this proposal can't do.

Thanks,
faiface

-- 
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/6f5f0785-93f7-475a-991c-fc919c5e6730%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Announcing NSWrap -- a comprehensive Objective-C binding generator for MacOS

[Greg Pomerantz]

I have been working on a binding generator that can read MacOS header files 
and provide bindings for Objective-C interfaces and library functions. 
NSWrap can also automatically generate classes implementing one or more 
named protocols or subclassing a specified class.

The automatically generated Go types implement method inheritance, and 
overloaded method names are disambiguated. Variadic functions and methods 
are supported and pointers to pointers are converted into slices. You can 
create selectors (to assign actions to NSControl objects, for example) and 
access Objective-C memory management methods (other than Automatic 
Reference Counting), including AutoreleasePools.

An example Cocoa application is provided in 24 lines of Go code. A 
text-mode Bluetooth Low Energy heart rate monitor in pure Go is 127 lines. 
The official git repository is linked below. This is the first release, so 
expect plenty of rough edges.

https://git.wow.st/gmp/nswrap

-- 
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/15be0140-b994-4692-9062-4792be74a8f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How do you keep your modules up-to-date?

[Marcin Romaszewicz]

I have the same kind of setup at my company, and we use go modules in the
same way that we would use public modules. We periodically do a "go get -u"
to update them. Jenkins does that once a week, so at worst, we're a week
behind. If someone needs to manually pull in changes more urgently, they
can just run the "go get" themselves and commit go.mod and go.sum. It works
well. Don't be too smart with this stuff, and just let the module system
work as intended. When you use private repos, it's a pain in the butt to
have the auth work, but it sounds like you've got that solved.

-- Marcin

On Thu, May 30, 2019 at 7:55 AM James Hartig  wrote:

> What's the best way to automatically always pull the latest release/commit
> for certain repos? We use gerrit internally so all of our import paths for
> internal packages start with something like gerrit.corp. We have over 50
> different repos and it would be painstaking to have to update (pull latest,
> run go get, commit, get review) every single one of those repos whenever an
> internal package was updated with a minor change.
>
> How do others solve the problem of outdated modules? Do developers
> frequently commit "Go modules updated" changes where they just update the
> go.mod? Is there a process defined where every repo has their deps updated
> once a month/week/etc?
>
> 1) Would it be better to just remove gerrit.corp lines from go.mod before
> it's committed so the dependencies are always resolved at run-time by CI?
> 2) Should our CI system look at go.mod and run go get -u for each
> gerrit.corp line as part of the build/test pipeline?
> 3) Or should we just run "go get -u ..." on every CI build to always have
> the latest minor updates of all modules?
>
> --
> 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/909a63a6-0e02-4129-bf5d-efadb353acf4%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] math.Atan implementation

[andrey mirtchovski]

Atan is implemented in assembly. for amd64 it's just a call to atan
(lowercase a): https://golang.org/src/math/atan_amd64.s

for 386 it is not: https://golang.org/src/math/atan_386.s

On Thu, May 30, 2019 at 9:15 AM rhiro  wrote:
>
> I'd like to see the implementation for math.Atan, but I see that 
> https://golang.org/src/math/atan.go seems to be a missing body for that 
> function "func Atan(x float64) float64".  Is this code being hidden, or is 
> there some other mechanism preventing it from showing up?  Thanks.
>
> --
> 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/8bf7aa9a-adf3-49b8-b9ee-3582d73b286b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[go-nuts] math.Atan implementation

[rhiro]

I'd like to see the implementation for math.Atan, but I see that 
https://golang.org/src/math/atan.go seems to be a missing body for that 
function "func Atan(x float64) float64".  Is this code being hidden, or is 
there some other mechanism preventing it from showing up?  Thanks.

-- 
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/8bf7aa9a-adf3-49b8-b9ee-3582d73b286b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] How do you keep your modules up-to-date?

[James Hartig]

What's the best way to automatically always pull the latest release/commit 
for certain repos? We use gerrit internally so all of our import paths for 
internal packages start with something like gerrit.corp. We have over 50 
different repos and it would be painstaking to have to update (pull latest, 
run go get, commit, get review) every single one of those repos whenever an 
internal package was updated with a minor change.

How do others solve the problem of outdated modules? Do developers 
frequently commit "Go modules updated" changes where they just update the 
go.mod? Is there a process defined where every repo has their deps updated 
once a month/week/etc?

1) Would it be better to just remove gerrit.corp lines from go.mod before 
it's committed so the dependencies are always resolved at run-time by CI?
2) Should our CI system look at go.mod and run go get -u for each 
gerrit.corp line as part of the build/test pipeline?
3) Or should we just run "go get -u ..." on every CI build to always have 
the latest minor updates of all modules?

-- 
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/909a63a6-0e02-4129-bf5d-efadb353acf4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Test a Golang API on the web

[Leonel Quinteros]

Amazon Web Services will give you the smallest instance of a virtual 
machine for free (at least for a year): https://aws.amazon.com/en/free
On Google Cloud Platform you can also have several services for free 
(forever) including a VM instance and an AppEngine deploy: 
https://cloud.google.com/free/
Similar options for Azure: https://azure.microsoft.com/es-es/free/

Good luck with your project! 


El lunes, 27 de mayo de 2019, 15:01:38 (UTC-3), aimar escribió:
>
> Hi,
>
> My teacher has asked me to develop an API with Golang and test it on the 
> web instead of localhost. I was thinking of github.io but then I figured 
> out, it doesn't support server-side languages and just support static 
> pages. Would you please let me know, if there is any platform which I can 
> test my API online rather than localhost? (for free, of course) 
> It is worth to mention my API generally generates just a couple of strings 
> from a JSON file, thus it does not need a database.
>
> thanks,
> Aimar
>

-- 
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/849c995a-534f-4c17-9e58-ce371608bdda%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] godoc(.org) query packages without cgo

[fgergo]

While browsing godoc.org for some functionality, I was wondering if
packages using cgo could be excluded from search results, like this:
"Hmm, I was wondering if godoc.org could show me packages with
"examplesearchterm" without cgo."

Did somebody look into implementing something like this earlier?

(Sometimes I would also like to exclude packages using package unsafe as well.)

I can imagine a more general search functionality, quering platform or
OS or minimal go version number or other "package context
dependencies" (what else?) would be useful as well.

If not godoc.org, does any other site implement similar search functionality?

Thanks!

-- 
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/CA%2BctqrqHGSZGW-3FELSZJV-ZGqaXqVg6CxA24%3D%3DQtJV8wGs%3DFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.