Re: [go-nuts] mytex.RWLock recursive read lock

[andrey mirtchovski]

> Is this simply a recommendation or should the docs be updated to clarify what 
> this means?

perhaps the latter, although that question only seems to come up once
every two or so years. here's a good link:

https://groups.google.com/d/msg/golang-nuts/XqW1qcuZgKg/Ui3nQkeLV80J

the entire discussion where i found it is interesting:

https://groups.google.com/g/golang-nuts/c/vN5ncBdtkcA/m/zf6EydsFsxgJ




On Mon, Sep 21, 2020 at 4:15 AM Henrik Johansson  wrote:
>
>
> https://golang.org/pkg/sync/#RWMutex
>
> Holds that this prohibits recursive read locks but why would it?
> I understand that deadlocks can happen in case write locks are held in 
> between the read locks
> but why can't a goroutine issue several RLock calls?
>
> It does actually work in the playground. https://play.golang.org/p/nOehJaeikxA
> Is this simply a recommendation or should the docs be updated to clarify what 
> this means?
>
>
> --
> 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/CAKOF696YKSGn3j%2BcyX7o0ukA7wnD2Kq19_QGefUoeMELUZGOWA%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/CAK4xykUmZK0HB1f84uc%2BXATMZRcuZ6nJr-ri5QaBWQnAS_r1iQ%40mail.gmail.com.

Re: [go-nuts] Is there +v Stringer interface?

[andrey mirtchovski]

>> fmt.Formatter is woefully under documented.
>
> My reference is pkg/errros - 
> https://github.com/pkg/errors/blob/master/errors.go#L127

we have wasted tens of man-hours hunting for a bug that didn't
manifest in logs due to that custom formatter. %#v basically went
directly to stringer without embedding type information (the
fallthrough, line 135 in the link you linked). it was difficult to
hunt and lead us to believe that custom formatters should be avoided.
in the end we switched away from pkg/errors using the new stuff
available as standard in go 1.14. the other lesson we learned is that
it's better to be explicit than implicit. wrapping nil errors with
.Wrap returning nil resulted in a lot of assumptions that confused
coders not experienced with that package. when we switched to %w
errors popped up where not expected because the explicitness of the %w
flag doesn't allow a nil error to be used with it.

nothing against the package, it served us well for a very long time.
but it was time for a change.

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

Re: [go-nuts] political fundraising on golang.org!

[andrey mirtchovski]

Hi,

I have a non-profit I'd like to support. Who do I ask to put a banner
on golang.org for me?

(reductio ad absurdum)

On Sun, Jun 14, 2020 at 4:08 PM Robert Engels  wrote:
>
> Equating not supporting this and supporting marginalized groups is not 
> correct. You can support marginalized groups all day and disagree on how best 
> to do so. It doesn’t have to be political at all.
>
> On Jun 14, 2020, at 4:43 PM, 'Axel Wagner' via golang-nuts 
>  wrote:
>
> 
> Hi,
>
> the Go Team and the Go Project are composed of people and expressing an 
> opinion - *especially* a political one - is well within their right (If I was 
> a conservative American I would wax poetically about the first amendment 
> here).
> Let's not pretend this is about politics or not. This is about *what* 
> politics. Some people will feel turned away if you support marginalized 
> groups. But not doing so will turn away other people. And as far as I'm 
> concerned, if I'm given the choice, I know perfectly well which of the two 
> I'm fine turning away. Black lives matter. And if you don't feel that way or 
> don't want to support that message, as far as I'm concerned, I won't be sad 
> to see you leave.
>
> On Sun, Jun 14, 2020 at 11:07 PM Sam Whited  wrote:
>>
>> What makes you think this is somehow politics and not simply supporting
>> an important not-for-profit at a time when it's particularly relevant
>> and important to do so? I don't see anything political about the topic
>> unless you count that some of the solutions are political (but this one,
>> donating to a respected non-profit, is not, so I still don't understand
>> your point).
>>
>> —Sam
>>
>> On Sun, Jun 14, 2020, at 16:44, Eric S. Raymond wrote:
>> > It is the injection of politics into a list where politics does
>> > not belong.
>>
>> --
>> 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/d7710db8-7e16-4e36-aa76-627de71cb7e9%40www.fastmail.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/CAEkBMfH12W0uj6UNRB6Y2mdBgb7w-nze0O_afJAZ0i5KwATW7A%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/0A551BF9-F25D-43C4-A678-2E449CC56716%40ix.netcom.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/CAK4xykXE8fGZ%2BZCUm-7QR13OKkv%2Bsa5fCEB3bXHh%3DTWACbWLVw%40mail.gmail.com.

Re: [go-nuts] Regarding time.NewTicker() and monotonic time

[andrey mirtchovski]

> Cool, makes sense.  Assuming NewTicker does return monotonic time.
>
> I wonder if there is a way to verify.

just fmt.Println the value you receive on the ticker chan, you'll see
the monotonic component tacked on in the end:

$ cat t.go
package main
import (
   "fmt"
   "time"
)
func main() {
   t := time.NewTicker(time.Second)
   fmt.Println(<-t.C)
}
$ go run t.go
2020-06-10 17:31:04.234797 -0600 MDT m=+1.003493724
$

-- 
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/CAK4xykVjdRG2SDXBF1DNT67tCYQs0tex3-KZvDE-i0UTQU2OmQ%40mail.gmail.com.

Re: [go-nuts] Regarding time.NewTicker() and monotonic time

[andrey mirtchovski]

> Does anyone know if the time data that NewTicker returns (i.e. via it's 
> channel, etc...) includes monotonic time?

it's right at the top: https://golang.org/pkg/time/

On Wed, Jun 10, 2020 at 4:48 PM Curtis Paul  wrote:
>
> It sounds like NewTicker will dynamically adjust to keep tick time "accurate".
>
> Does anyone know if the time data that NewTicker returns (i.e. via it's 
> channel, etc...) includes monotonic time?
> And if so is the definition of NewTicker referring to adjusting real time 
> clock or monotonic clock?
>
> I'm not really sure what to expect with using ticker in terms of timing 
> accuracy.
> Is NewTicker() monotonic?
>
> Also not quite sure what "Stop the ticker to release associated resources" 
> refers to.
>
> time.NewTicker()
>
> "NewTicker returns a new Ticker containing a channel that will send the time 
> with a period specified by the duration argument. It adjusts the intervals or 
> drops ticks to make up for slow receivers. The duration d must be greater 
> than zero; if not, NewTicker will panic. Stop the ticker to release 
> associated resources."
>
> --
> 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/ec9cf4f2-5404-4512-9b57-b4816ea47adeo%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/CAK4xykWnn1_PFCEGmX1Y1srH1anEMoZqUb6LoZ2DeiWffGM%2BHg%40mail.gmail.com.

Re: [go-nuts] Re: net.ParseIP unable to parse some types of ipv6 addresses

[andrey mirtchovski]

thanks. that ought to do it.

On Fri, May 1, 2020 at 11:16 AM Brian Candler  wrote:
>
> parseIP returns a net.IP which is just a slice of bytes without the zone.
>
> However, type net.IPAddr includes the zone.  Looks like net.ResolveIPAddr 
> will do the job:
>
> https://play.golang.org/p/7p1XXIrVGI0
>
> --
> 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/0168d004-5c54-4430-8c09-1a8a8d7ea736%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/CAK4xykXFVkrDe1w3T_24kyC9-Zd4DheJo6rpP7osemeRWSk%3Dcw%40mail.gmail.com.

[go-nuts] net.ParseIP unable to parse some types of ipv6 addresses

[andrey mirtchovski]

IPv6 addresses including a zone identifier [rfc4007] are not parsed
correctly by net.ParseIP. is there any point in creating an issue or
is this intentional and we're supposed to strip the zone identifier?

https://play.golang.org/p/kQKyYYnZydX

-- 
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/CAK4xykWcNUG8jRyiEDo6UD%2BYJd7nENBqgd7se_ji1FAgxefNnw%40mail.gmail.com.

Re: [go-nuts] how to design log package to avoid allocations

[andrey mirtchovski]

to avoid allocations you have to hint at the type of what you're going
to print. for example see/use zerolog: https://github.com/rs/zerolog

On Mon, Mar 9, 2020 at 10:36 AM 'Axel Wagner' via golang-nuts
 wrote:
>
> IMO, there really isn't a super good answer. The simple answer is: You need 
> to delay the actual `fmt.Sprintf` call as long as possible. Which generally 
> means, that the interface you consume (to allow the user to direct and 
> configure logging) will need to reflect formatting and all kinds of things 
> that the user actually doesn't want to deal with. So it's hard to find a good 
> tradeoff between API simplicity and usability and not allocating in this case.
>
> Another, maybe unforseen problem, is that you don't want logging to interfere 
> with production. It's a painful lesson to learn, that synchronous logging can 
> take down a production service with ease. If you want to be prepared for that 
> and reduce the runtime overhead of logging, you will have to make it 
> asynchronous. But that's fundamentally at odds with the above goal of 
> delaying formatting - the user will usually not expect arguments to loggers 
> to be used after the logging call returns. Buffering a formatted string 
> avoids that of course.
>
> Lastly, if you want runtime-configurability of logging and conditionally 
> discard messages, you will likely reach for interfaces and thus limit the 
> usefulness of escape analysis and inlining. So, by trying to allocate less, 
> you might end up allocating more, because the compiler has to put things on 
> the heap to be safe.
>
> FWIW, I've blogged about this a couple of years ago. The opinions expressed 
> there are probably controversial (and I haven't looked at it in a while - I 
> might not even agree with them myself anymore), but it might help open up 
> even more questions or give you some ideas. Also, there are of course many, 
> many logging APIs already existing and I'm sure the people who wrote and use 
> them will have strong opinions about those as well :) Personally, I've kind 
> of given up on the idea of a panacea log API.
>
> On Mon, Mar 9, 2020 at 4:27 PM Vasiliy Tolstov  wrote:
>>
>> Hi! I have some logging package and after memory profiling saw that for 
>> disabled log levels i'm allocate memory for message.
>> For example i'm send in logger only Info level. So i want to avoid 
>> Debug/Trace stuff.
>> but memory profiling says that for call log.Tracef("my message %v", msg) i'm 
>> allocate memory.
>> I don't want to guard all calls to check enabled log level to avoid 
>> allocation. How can i do zero allocation log in such case?
>> Thanks!
>>
>> --
>> Vasiliy Tolstov,
>> e-mail: v.tols...@selfip.ru
>>
>> --
>> 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/CACaajQswqK3DGHESCFd4pCdxndFpOFyKXhO25UDKgEsxYeK3SA%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/CAEkBMfF6kRp0V4LUGxfu3qDu4K7mpz%3DdhA76EU_qd1DfveZk-Q%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/CAK4xykU0Ra_c0p3nGY0j%3DfgPdvWDBbRDm1Sg7j6o3md-CjWJtA%40mail.gmail.com.

Re: [go-nuts] Fuchsia Programming Language Policy

[andrey mirtchovski]

my take:
- c++ programmers are going to c++ program. film at 11 (rob pike had a
talk about that)
- dart has UI
- rust is fashionable, but scary (if you've done rust you'll know why)

yes, go was touted as a systems programming language, but it meant
"distributed systems". had that been made clear from the beginning all
this strife would've disappeared. u-root.org shows that go can be used
at firmware level quite handily.

On Tue, Feb 25, 2020 at 2:05 PM Manlio Perillo  wrote:
>
> And the one that is good at both memory management and concurrency has 
> properties of the language that are not yet well-understood.
>
>
> Manlio
>
> On Tuesday, February 25, 2020 at 7:21:00 PM UTC+1, Michael Jones wrote:
>>
>> Actually, you should read the whole note -- it's fun. Half of the languages 
>> are bad because of memory leaks, the other half are bad because of having 
>> GC; half are bad because of difficult asynchronism, the other half are bad 
>> because of having a runtime. etc.
>>
>> It reads like an imperiously-worded tautology about safety/power/convenience 
>> coming at a cost.
>>
>> On Tue, Feb 25, 2020 at 9:51 AM Mohamed Yousif  wrote:
>>>
>>> It seems they are betting high on Dart/flutter and their front end is 
>>> already written with flutter. The assessment seems to be pretty much the 
>>> same as for Dart.
>>>
>>> Dart won with the ui side, while go was competing with C.
>>>
>>> On Tue, 25 Feb 2020 at 7:22 PM, Jon Conradt  wrote:

 The Fuchsia Programming Language Policy gives some insight into the 
 experience the Fuchsia team has had with Go, and it doesn't sound good.

 "The Fuchsia Platform Source Tree has had negative implementation 
 experience using Go. The system components the Fuchsia project has built 
 in Go have used more memory and kernel resources than their counterparts 
 (or replacements) the Fuchsia project has built using C++ or Rust."


 The Fuchsia Platform Source tree is defined as "The Fuchsia Platform 
 Source Tree is the source code hosted on fuchsia.googlesource.com."

 Their conclusion, and each language has some issues is pretty severe.

 Go is not approved, with the following exceptions:

 netstack. Migrating netstack to another language would require a 
 significant investment. In the fullness of time, we should migrate 
 netstack to an approved language.

 All other uses of Go in Fuchsia for production software on the target 
 device must be migrated to an approved language.

  That's a shame. I was hoping that Fuchsia would provide a way for Go to 
 have a nice GUI.

 Two of the issues listed as cons include the toolchain producing 'large 
 binaries' and the related issue of their being a 'substantial runtime.' It 
 seems to me that both of these issues can be addressed through some of the 
 techniques used to build tiny Docker images from Go, but I suspect they 
 would like to have a much simpler route, e.g. a go build flag.

 Jon

 --
 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/7778a387-f1f5-4ed0-8453-5b811bac4a6d%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 golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CAHrL7wHqJnDnEVe4%3D--%3DcSW9oA-eYxcbKagESdZHgSkrdLutpA%40mail.gmail.com.
>>
>>
>>
>> --
>> Michael T. Jones
>> michae...@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/a5227da6-c1ee-4754-95c4-c6bb1dd2d40f%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/CAK4xykW0cA8SwcDBthoAuPtuYajsEozkSRrS1uH3dC8yNWBQng%40mail.gmail.com.

Re: [go-nuts] Bound checks elimination hint.

[andrey mirtchovski]

got it down to two:

https://play.golang.org/p/jmTqhLGaLY_T

On Fri, Feb 21, 2020 at 11:24 AM Bruno Albuquerque  wrote:
>
> This is interesting. If I simplify the loop to something like this:
>
> nrgbaData := make([]byte, len(rgbData)+(len(rgbData)/3))
>
> _ = nrgbaData[len(rgbData)]
>
> for i := 0; i < len(rgbData); i++ {
> nrgbaData[i] = rgbData[i]
> }
>
> then the bounds check at the line inside the for loop is removed.
>
> But if I change it to this:
>
> nrgbaData := make([]byte, len(rgbData)+(len(rgbData)/3))
>
> _ = nrgbaData[len(rgbData)]
>
> for i := 0; i < len(rgbData); i += 3 {
> nrgbaData[i] = rgbData[i]
> }
>
> then the bounds check is not eliminated.
>
> Considering it is still guaranteed that "i" inside the loop will never be 
> equal to or greater than len(rgbData), I do not understand why the bounds 
> check is now required.
>
> Any ideas?
>
>
> On Fri, Feb 21, 2020 at 10:07 AM Bruno Albuquerque  wrote:
>>
>> Nope. Bound checks are still there. I am puzzled by this one.
>>
>>
>> On Fri, Feb 21, 2020 at 9:34 AM Sebastien Binet  wrote:
>>>
>>>
>>>
>>> On Fri, Feb 21, 2020 at 5:36 PM Bruno Albuquerque  wrote:

 I wrote some simple code to convert a RGB24 image represented as a []byte 
 to a NRGBA image (also as a []byte), like so:

 https://play.golang.org/p/Y7ICg7t4_nd

 Unfortunately, the performance is lacking here and I am trying to improve 
 it. The first low hanging fruit seems to be taking advantage of BCE:

 $go test -bench .
 goos: linux
 goarch: amd64
 BenchmarkNRGBA-8   484   2636344 ns/op

 $ go test -gcflags="-B" -bench .
 goos: linux
 goarch: amd64
 BenchmarkNRGBA-8   855   1654882 ns/op

 Unfortunately, I could not find an incantation that would remove the bound 
 checks. My naive attempt was to just do

 _ = nrgbaData[len(nrgbaData)-1]

 at around line 7 in the program above but this did not help and added one 
 extra bound check.

 Funny enough, if I do

 _ = nrgbaData[len(nrgbaData)]

 all the bound checks seem to be eliminated but, obviously, the program 
 panics at this line.
>>>
>>> what about:
>>>_ = nrgbaData[:len(nrgbaData)]
>>>
>>> does this also remove the bound checks?
>>>
>>> -s
>
> --
> 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/CAEd86TwC19nJDwAe-kR6Ze8zPf4zjPQp0dMksPAwMwsXCGWRiw%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/CAK4xykXszWjjPf25Un8ze7g2F_epnSFB0BaJmWGhJ%2BpLE_Mm0Q%40mail.gmail.com.

Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

[andrey mirtchovski]

?w=1 is an option.

On Tue, Feb 18, 2020 at 7:16 PM Wojciech S. Czarnecki  wrote:
>
> Dnia 2020-02-18, o godz. 10:16:57
> Manlio Perillo  napisał(a):
>
> > Here is an example of a diff with a lot of noise, where the actual change
> > is very hard to see:
> > https://gist.github.com/perillo/c5b3bdff9e8db9c89f316670d129c0dd
> >
> > Note that using `git diff -w` is not a solution, since it can only be used
> > locally.  The full diff will be shown by github and friends.
>
> Yes. It could be easily fixed with cosmetic changes to gofmt in a way that
> is tab-width neutral [1] but I doubt it would be seriously considered given
> current NIH-driven mood of dev's hive.
>
> [1] use marker relative to the opening brace hinting at the desired comment
> position, ie. compute type-start position relative to the opening brace then
> comment-start position relative to the marker from the comment of the brace
> line. Adjust both positions modulo 8 rounded up. Field name that gets over
> past the established type-start position stays over.
>
> Done.
>
> Everything, except overlong names, lines up on the screen with ts=2, ts=3, 
> ts=4
> as well as with ts=8. Changesets contain no whitespace changes, because there
> is no such gofmt introduced changes anymore — ofc unless you change type
> identifier past the rounded 8 boundary. Then whole struct will make to the
> changeset, not just huge parts of it.
>
> Hope this helps,
>
> > Manlio
>
> --
> Wojciech S. Czarnecki
>  << ^oo^ >> OHIR-RIPE
>
> --
> 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/20200219031558.77411fc7%40xmint.

-- 
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/CAK4xykUszUOJYGxv2WGxUegnY6eHR-tEcYbgqMkLJiXBknxx0w%40mail.gmail.com.

Re: [go-nuts] Virus detection issues on Windows/386 binaries built with -ldflags -s -w

[andrey mirtchovski]

sorry, wanted to add: submit your file to VT and see if it triggers a
detection there (like in my link it is most likely that only the MS
engine will detect it). then you have a case to argue.


On Tue, Feb 11, 2020 at 9:29 PM andrey mirtchovski
 wrote:
>
> you can find similar detections on virustotal. unfortunately it looks
> like a false positive:
>
> https://www.virustotal.com/gui/file/93eb448cedd4b4355065a4f9193d8548b02bc56ed5ba9e774095f9ab3da46227/detection
>
> there are members of this community working for microsoft, perhaps
> they'll have an avenue that will allow their engine to avoid a false
> positive on go code. not sure if they have an open channel to address
> this.
>
> On Tue, Feb 11, 2020 at 9:15 PM ajstarks  wrote:
> >
> > When building Windows binaries for pdfdeck [1] 
> > (https://github.com/ajstarks/deck/tree/master/cmd/pdfdeck) I noticed that 
> > the binary generated with on linux with:
> >
> > GOOS=windows GOARCH=386 go build -ldflags="-s -w" -o 
> > windows-386-pdfdeck.exe github.com/ajstarks/deck/cmd/pdfdeck
> >
> > will cause the Windows 10 Defender virus detection to think the binary is 
> > infected with Trojan:Win32/Wacatac.C!ml
> >
> > simply removing the -ldflags builds a binary that runs with no issues.  Has 
> > anyone else seen this?
> >
> > --
> > 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/67837c19-9d19-4976-8b12-44a7b8fedf6d%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/CAK4xykWP%2BPCUgmGOpoM5%2BJm6Kx_MGBOUZqwj_uY6OBf2GofMwQ%40mail.gmail.com.

Re: [go-nuts] Virus detection issues on Windows/386 binaries built with -ldflags -s -w

[andrey mirtchovski]

you can find similar detections on virustotal. unfortunately it looks
like a false positive:

https://www.virustotal.com/gui/file/93eb448cedd4b4355065a4f9193d8548b02bc56ed5ba9e774095f9ab3da46227/detection

there are members of this community working for microsoft, perhaps
they'll have an avenue that will allow their engine to avoid a false
positive on go code. not sure if they have an open channel to address
this.

On Tue, Feb 11, 2020 at 9:15 PM ajstarks  wrote:
>
> When building Windows binaries for pdfdeck [1] 
> (https://github.com/ajstarks/deck/tree/master/cmd/pdfdeck) I noticed that the 
> binary generated with on linux with:
>
> GOOS=windows GOARCH=386 go build -ldflags="-s -w" -o windows-386-pdfdeck.exe 
> github.com/ajstarks/deck/cmd/pdfdeck
>
> will cause the Windows 10 Defender virus detection to think the binary is 
> infected with Trojan:Win32/Wacatac.C!ml
>
> simply removing the -ldflags builds a binary that runs with no issues.  Has 
> anyone else seen this?
>
> --
> 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/67837c19-9d19-4976-8b12-44a7b8fedf6d%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/CAK4xykXE1wthNUKwLH7tcofztDiPsoGTxfYNiouMj2X9qfV%2Bug%40mail.gmail.com.

Re: [go-nuts] Help with Oauth2 "grant_type=client_credentials"

[andrey mirtchovski]

i would strongly advise against implementing advice received online
for something as important as auth. my suggestion is to work with curl
from the command line (examples are given on the webpage you linked)
until you have the process working. implementing that afterwards using
http.Client will be more or less trivial.

that said, you may be missing a call to SetBasicAuth with the client
id and secret, or sourcing a JWT beforehand from /oauth/token

On Tue, Feb 11, 2020 at 4:56 PM tmack8080  wrote:
>
> Hi,
>
>
>
> I'm not a programmer.
>
> I have this working in PowerShell.
>
>
>
> Requirement:
>
> Query hardware vendor web APIs, using the device serial number, for device 
> warranty status.
>
>
>
> The vendors require that the "client_id" and "client_secret", as well as the 
> "grant_type=client_credentials" be passed.
>
>
>
> All of the documentation I've located discusses using Oauth for 3rd party 
> authentication. Obviously, not what I'm doing. Can anyone point me to a 
> tutorial that uses "client_credentials"? I've not found one.
>
>
>
> I tried using the example on the authO website; no luck: 
> https://auth0.com/docs/api-auth/tutorials/client-credentials (you have select 
> Go from the list of languages). When printing out the 'payload' variable I 
> see it appended with a {0 -1} and I'm wondering if that's the problem:
>
>
> &{client_id=xx_secret=xx_type=client_credentials 
> 0 -1}
>
> {
>
>   "error":"invalid_request",
>
>   "error_description":"Missing or duplicate parameters"
>
> }
>
>
>
> 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/64214d0a-1191-4f46-8bfd-2c716cdb2d3f%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/CAK4xykVkQEspkzQ0D0wuZrznM4P1Mtt1KNXnobR9GZypxbUtrQ%40mail.gmail.com.

Re: [go-nuts] difference response from play.golang (bit operations)

[andrey mirtchovski]

sorry, i meant to put this in too;

https://play.golang.org/p/vn5iMAWbDiv

On Fri, Jan 3, 2020 at 11:27 AM andrey mirtchovski
 wrote:
>
> https://play.golang.org/p/cpKEQZJKDsh
>
> On Fri, Jan 3, 2020 at 11:24 AM X-Thief  wrote:
> >
> > thx but have you tried it? it just gives positive on playground.
> >
> > пятница, 3 января 2020 г., 22:05:48 UTC+4 пользователь Ian Lance Taylor 
> > написал:
> >>
> >> On Fri, Jan 3, 2020 at 9:50 AM X-Thief  wrote:
> >> >
> >> > Hey. Im realy newbish at bit operations
> >> >
> >> > Could you help me get the same result as in 
> >> > https://play.golang.org/p/FWocHVrF0Wt
> >> > On my PC and my server i got positive number from the script. But i need 
> >> > negative result if it is so
> >> >
> >> > Any suggestions?)
> >>
> >> Your PC and server are probably 64-bit systems but the playground is a
> >> 32-bit system.  To get consistent results use explicit conversions to
> >> int64.
> >>
> >> 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/3361a17f-b8e4-447a-89c1-943154834233%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/CAK4xykUroh2gbzROVYbwjFTXNxmfty8BAQC1h5dPeT-Q6ZQy0Q%40mail.gmail.com.

Re: [go-nuts] difference response from play.golang (bit operations)

[andrey mirtchovski]

https://play.golang.org/p/cpKEQZJKDsh

On Fri, Jan 3, 2020 at 11:24 AM X-Thief  wrote:
>
> thx but have you tried it? it just gives positive on playground.
>
> пятница, 3 января 2020 г., 22:05:48 UTC+4 пользователь Ian Lance Taylor 
> написал:
>>
>> On Fri, Jan 3, 2020 at 9:50 AM X-Thief  wrote:
>> >
>> > Hey. Im realy newbish at bit operations
>> >
>> > Could you help me get the same result as in 
>> > https://play.golang.org/p/FWocHVrF0Wt
>> > On my PC and my server i got positive number from the script. But i need 
>> > negative result if it is so
>> >
>> > Any suggestions?)
>>
>> Your PC and server are probably 64-bit systems but the playground is a
>> 32-bit system.  To get consistent results use explicit conversions to
>> int64.
>>
>> 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/3361a17f-b8e4-447a-89c1-943154834233%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/CAK4xykWKp_Um62ew_G_rP53SxwXuTYV8zTk_39EqiV9bap3ybw%40mail.gmail.com.

Re: [go-nuts] Reordering error output in flags package so Usage is printed before the error?

[andrey mirtchovski]

You'll need to create a FlagSet instead and pass ContinueOnError as
the error handling. If .Parse() returns an error call
.PrintDefaults(), then print the error.

On Sun, Dec 8, 2019 at 4:00 AM Thomas Nyberg  wrote:
>
> Hello,
>
> Given the following file `flag_example.go`:
>
> package main
>
> import "flag"
>
> func main() {
> flagName := flag.String("flagName", "flagValue", "Help message.")
> flag.Parse()
> _ = flagName
> }
>
> If I execute it with a bad flag passed I see the following:
>
> $ ./flag_example -flagName
> flag needs an argument: -flagName
> Usage of ./flag_example:
>   -flagName string
> Help message. (default "flagValue")
>
> What I would like to see is something like the following:
>
> $ ./flag_example -flagName
> Usage of ./flag_example:
>   -flagName string
> Help message. (default "flagValue")
>
> flag needs an argument: -flagName
>
> In other words, I would like to move the error to the end. Is there an easy 
> way to achieve this? I know about changing Usage, but that doesn't seem to 
> affect this specific issue. Thanks for any help!
>
> Cheers,
> Thomas
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CADDBb4JFEEhQcHVF2csObgCdEgQaGGQYJntYoiWYYOjko8tEzw%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/CAK4xykV-PSQTcfr_Jvq12nnSQ5rZ48nHepptVewVBvgfUwsdYw%40mail.gmail.com.

Re: [go-nuts] Re: Where is the middle of Brazil?

[andrey mirtchovski]

this is quickly becoming off-topic. however, from
https://en.wikipedia.org/wiki/Geographical_centre:

"As noted in a USGS document "There is no generally accepted
definition of geographic center, and no completely satisfactory method
for determining it."[1]

In general, there is room for debate around various details such as
whether or not to include islands and similarly, large bodies of
water, how best to handle the curvature of the Earth (a more
significant factor with larger regions) and closely related to that
issue, which map projection to use."
--
[1]: https://pubs.er.usgs.gov/publication/70039437

On Sat, Dec 7, 2019 at 9:32 AM JuciÊ Andrade  wrote:
>
> If one wants to improve precision she may use a bigger map.
> The resulting position would be the same, only more accurate.
>
> --
> 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/270e41e1-5dd5-4351-be8a-1ba683bdd6a8%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/CAK4xykV5zOMW%2Bbv3DWb1pTXad-rieqnYdoop6dpJwmsnkkGx2w%40mail.gmail.com.

Re: [go-nuts] cgo wrapper function not working in buildmode=c-shared with exported function

[andrey mirtchovski]

i think cgo does some magic with defining functions called via
C.funcname. if you have the same func defined in the C preamble as
well as call it from the same Go file you get the same func defined
twice. putting it elsewhere as an extern seems to work.

to be honest i never dug into it. i did it once for callbacks in a
library in 2013 and forgot about it :) it just works.

On Thu, Dec 5, 2019 at 9:52 PM Dan Kortschak  wrote:
>
> Thanks. Can you explain the reason for this so it sticks in my head?
>
> On Thu, 2019-12-05 at 21:03 -0700, andrey mirtchovski wrote:
> > you just need to split it in two files. the cfuncs go into another
> > (sorry for lack of playground link):
> >
> > $ go build cgo.go cfunc.go
> > $ ./cgo
> > Hello from stdio
> >
> > $ cat cgo.go
> > package main
> >
> > /*
> > #include 
> > extern void myprint(char *s);
> > */
> > import "C"
> >
> > import "unsafe"
> >
> > //export Example
> > func Example() {
> > cs := C.CString("Hello from stdio\n")
> > C.myprint(cs)
> > C.free(unsafe.Pointer(cs))
> > }
> >
> > func main() {
> > Example()
> > }
> > $ cat cfunc.go
> > package main
> >
> > /*
> > #include 
> > #include 
> >
> > void myprint(char* s) {
> > printf("%s\n", s);
> > }
> > */
> > import "C"
> >
> > On Thu, Dec 5, 2019 at 8:47 PM Dan Kortschak 
> > wrote:
> > >
> > > I am trying to write a shared module that will be called from C,
> > > but I
> > > have run into a problem in using the work-around in
> > > https://github.com/golang/go/wiki/cgo#the-basics for calling
> > > variadic C
> > > functions.
> > >
> > > The case that I have is more complex, but altering the example at
> > > the
> > > wiki demonstrates the problem; the function definition that is used
> > > to
> > > call on to printf appears more than once in the C code generated by
> > > Cgo.
> > >
> > > ```
> > > ~/src/github.com/kortschak/cgo $ cat cgo.go
> > > package main
> > >
> > > /*
> > > #include 
> > > #include 
> > >
> > > void myprint(char* s) {
> > > printf("%s\n", s);
> > > }
> > > */
> > > import "C"
> > >
> > > import "unsafe"
> > >
> > > //export Example
> > > func Example() {
> > > cs := C.CString("Hello from stdio\n")
> > > C.myprint(cs)
> > > C.free(unsafe.Pointer(cs))
> > > }
> > >
> > > func main() {}
> > > ~/src/github.com/kortschak/cgo $ go build -o cgo.so -buildmode=c-
> > > shared
> > > .
> > > # github.com/kortschak/cgo
> > > /tmp/go-build899365101/b001/_x002.o: In function `printf':
> > > /usr/include/x86_64-linux-gnu/bits/stdio2.h:104: multiple
> > > definition of
> > > `myprint'
> > > /tmp/go-build899365101/b001/_x001.o:/usr/include/x86_64-linux-
> > > gnu/bits/stdio2.h:104: first defined here
> > > collect2: error: ld returned 1 exit status
> > > ```
> > >
> > > Removing the "//export Example" comment prevents this failure, but
> > > then
> > > obviously also loses the exported function. I have tried protecting
> > > the
> > > function in a #ifndef/#endif, to no avail.
> > >
> > > Is it reasonable for me to expect this to work? If so, what am I
> > > doing
> > > wrong?
> > >
> > > thanks
> > > Dan
> > >
> > > --
> > > 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/ab825669afe753c505952f18fb6c61bc8e2dd24d.camel%40kortschak.io
> > > .
>

-- 
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/CAK4xykW1EiNZrXaytkrO%2BoiE4PQmF5ccDoc0b9aJgtMzXig8Bg%40mail.gmail.com.

Re: [go-nuts] cgo wrapper function not working in buildmode=c-shared with exported function

[andrey mirtchovski]

you just need to split it in two files. the cfuncs go into another
(sorry for lack of playground link):

$ go build cgo.go cfunc.go
$ ./cgo
Hello from stdio

$ cat cgo.go
package main

/*
#include 
extern void myprint(char *s);
*/
import "C"

import "unsafe"

//export Example
func Example() {
cs := C.CString("Hello from stdio\n")
C.myprint(cs)
C.free(unsafe.Pointer(cs))
}

func main() {
Example()
}
$ cat cfunc.go
package main

/*
#include 
#include 

void myprint(char* s) {
printf("%s\n", s);
}
*/
import "C"

On Thu, Dec 5, 2019 at 8:47 PM Dan Kortschak  wrote:
>
> I am trying to write a shared module that will be called from C, but I
> have run into a problem in using the work-around in
> https://github.com/golang/go/wiki/cgo#the-basics for calling variadic C
> functions.
>
> The case that I have is more complex, but altering the example at the
> wiki demonstrates the problem; the function definition that is used to
> call on to printf appears more than once in the C code generated by
> Cgo.
>
> ```
> ~/src/github.com/kortschak/cgo $ cat cgo.go
> package main
>
> /*
> #include 
> #include 
>
> void myprint(char* s) {
> printf("%s\n", s);
> }
> */
> import "C"
>
> import "unsafe"
>
> //export Example
> func Example() {
> cs := C.CString("Hello from stdio\n")
> C.myprint(cs)
> C.free(unsafe.Pointer(cs))
> }
>
> func main() {}
> ~/src/github.com/kortschak/cgo $ go build -o cgo.so -buildmode=c-shared
> .
> # github.com/kortschak/cgo
> /tmp/go-build899365101/b001/_x002.o: In function `printf':
> /usr/include/x86_64-linux-gnu/bits/stdio2.h:104: multiple definition of
> `myprint'
> /tmp/go-build899365101/b001/_x001.o:/usr/include/x86_64-linux-
> gnu/bits/stdio2.h:104: first defined here
> collect2: error: ld returned 1 exit status
> ```
>
> Removing the "//export Example" comment prevents this failure, but then
> obviously also loses the exported function. I have tried protecting the
> function in a #ifndef/#endif, to no avail.
>
> Is it reasonable for me to expect this to work? If so, what am I doing
> wrong?
>
> thanks
> Dan
>
> --
> 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/ab825669afe753c505952f18fb6c61bc8e2dd24d.camel%40kortschak.io.

-- 
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/CAK4xykURExDvQ6L-rGSx0fJcq9STha16u%2BqKEXp4PjgP3aau3w%40mail.gmail.com.

Re: [go-nuts] Where is the middle of Brazil?

[andrey mirtchovski]

i think JuciÊ wants us to crack the md5. i'm fresh off a CTF
competition so i don't have any more resources to throw at warming the
universe and increasing entropy, unfortunately...

On Sat, Nov 30, 2019 at 6:43 PM Michael Jones  wrote:
>
>
> My answer is this place.
> 14°35'03.5"S 53°03'51.3"W
> -14.584305, -53.064239
>
> Not an official national answer, just my own. (That said, I invented Google 
> Earth's technology and was the CTO of Google's Geo team from its 
> inception...so I have some minor street cred in such things. ;-)
>
> On Sat, Nov 30, 2019 at 5:30 PM JuciÊ Andrade  wrote:
>>
>> When I was a kid I asked my teacher why my country capital had been moved 
>> from Rio de Janeiro to Brasilia. She said the reason was Brasilia is right 
>> in the middle of our territory, that way our president could take care of 
>> our entire country more effectively. I accepted that answer. Many years 
>> later, contemplating a map, I doubted Brasilia is right in the middle.
>>
>>
>> Where is the middle of Brazil?
>>
>>
>> MD5 SHA-1
>>
>> 
>>
>> 4c021557d057327f2977dd739b67da6b b3913154ca0c5f48f3555c536fc987322169e607 
>> ihavetheanswer.txt
>>
>> --
>> 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/850ccd64-5c85-4c91-9438-bd28c4320b8a%40googlegroups.com.
>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.com
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CALoEmQwBJudMkah7eWRG9mhfCLjuJM%2B42LGdnP1BEAayH57EiA%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/CAK4xykVTe6avmw7%3Dn3WV6PEp2eh1MRN-E%3DVLLMCq3R1RA0PsLw%40mail.gmail.com.

Re: [go-nuts] Re: Slices, backing array, goroutines, perhaps Considerations for Go2

[andrey mirtchovski]

>> I think it only catches concurrent access to the same address, so not sure 
>> if it catches everything.
>
>
> If two things aren't writing concurrently to the same address, what's the 
> problem?

I took that to mean 'things may be updating concurrently at different
addresses inside an array backing the same slice'. But the race
detector will flag as soon as a read is attempted by another goroutine
on any of those.

-- 
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/CAK4xykU5nKhU0BFocR0XP-mYD0rY246Hu6Aq9AG95t-Dh7n-PA%40mail.gmail.com.

Re: [go-nuts] Where are the GO compiler sources?

[andrey mirtchovski]

'x' is for experimental. things that have a chance to get into the
standard library but are not finished yet. the major differentiator is
that they're not bound by the Go 1 guarantee that nothing changes
(i.e., they can change).

you should be able to find the compiler in https://golang.org/src/cmd/compile/

HTH

On Mon, Sep 16, 2019 at 3:06 PM joe mcguckin
 wrote:
>
> Also, what does the X (e.g. /X/) in the path of various runtime libraries 
> mean?
>
> Thanks,
>
> Joe
>
> --
> 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/3982e75a-af97-4baf-b4cc-424a5b6031d4%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/CAK4xykVUfgRh2%2BkLgVPv124mu37Xh_4xHyxgKmxxCudWhkb5SA%40mail.gmail.com.

Re: [go-nuts] Re: If v2.x.y+incompatible exists, then getting the modules based v3 version will always fail?

[andrey mirtchovski]

are you following the steps outlined below?

https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

in particular, for a v2 (or v3) it states that the go.mod file must be updated:

> Update the go.mod file to include a /v3 at the end of the module path in the 
> module directive (e.g., module github.com/my/module/v3).


On Fri, Sep 13, 2019 at 12:53 PM T L  wrote:
>
> I really don't get how modules are got.
> I create another repo with all versions are module based, but it still fails 
> on getting v2.
>
> $ go get github.com/go101/mod_versions_b/v2@latest
> go: finding github.com/go101/mod_versions_b/v2 v2.1.1
> go get github.com/go101/mod_versions_b/v2@latest: module 
> github.com/go101/mod_versions_b@latest (v1.0.0) found, but does not contain 
> package github.com/go101/mod_versions_b/v2
>
> It looks, the go command found the target version v2.1.1, but it downloads 
> v1.0.0 in the end.
> What is the mistake I made in the process?
>
>
> On Friday, September 13, 2019 at 2:22:16 PM UTC-4, T L wrote:
>>
>> For example,
>>
>> $ $ go get github.com/go101/mod_versions/v3@latest
>> go: finding github.com/go101/mod_versions/v3 v3.1.0
>> go get github.com/go101/mod_versions/v3@latest: module 
>> github.com/go101/mod_versions@latest (v2.0.0+incompatible) found, but does 
>> not contain package github.com/go101/mod_versions/v3
>>
>> Is it required to remove all v2.x.y+incompatible versions?
>
> --
> 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/71315e79-cbb0-4838-9c85-1ec183f7bb3f%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/CAK4xykW7bqA7MA1yBrXEq_PHURvwMo8K1eEgdb2BYUVz_Hq2oA%40mail.gmail.com.

Re: [go-nuts] playground - time.Sleep causes deadlock

[andrey mirtchovski]

see the "faking time" section here: https://blog.golang.org/playground

not sure if anything has changed since that article

On Sat, Aug 31, 2019 at 4:22 PM robert engels  wrote:

> Yes, the code runs fine locally. Reviewing the playground docs, it sees
> that at one point time.Sleep() was a no-op and it was changed. I am
> thinking that in the course of that change, they forgot to change the
> ‘deadlock’ detector.
>
> On Aug 31, 2019, at 5:17 PM, burak serdar  wrote:
>
> On Sat, Aug 31, 2019 at 4:13 PM robert engels 
> wrote:
>
>
> The code at https://play.golang.org/p/9ZdPVvwyaYK
>
> should not deadlock. But it reports:
>
>
> I had the same problem the other day. Code runs locally, but not on
> playground. It also had a sleep in a goroutine.
>
>
>
> fatal error: all goroutines are asleep - deadlock!
>
>
> But if you look at the stack traces, you see multiple routines (sampled)
> like:
>
> goroutine 1 [sleep]:
> runtime.goparkunlock(...)
> /usr/local/go/src/runtime/proc.go:307
> time.Sleep(0x3e8, 0x0)
> /usr/local/go/src/runtime/time.go:105 +0x1c0
> main.main()
> /tmp/sandbox327672725/prog.go:81 +0x140
>
> goroutine 5 [sleep]:
> runtime.goparkunlock(...)
> /usr/local/go/src/runtime/proc.go:307
> time.Sleep(0x1, 0x0)
> /usr/local/go/src/runtime/time.go:105 +0x1c0
> main.producer(0x430150, 0x40a0e0)
> /tmp/sandbox327672725/prog.go:49 +0x60
> created by main.main
> /tmp/sandbox327672725/prog.go:73 +0xe0
>
>
> These routines are asleep, not blocked. They will awake from sleep
> (eventually) - so there cannot be a deadlock.
>
> I am assuming this is a limitation of the Go playground back-end, but I
> can’t see it documented anywhere? Also, I’m not sure why this limitation
> would exist, since if all the routines are asleep or blocked, it is
> consuming no resources.
>
> Ideas?
>
> --
> 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/C7B46199-05EA-47C1-9594-200E2DD36F99%40ix.netcom.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/CAMV2RqpyK54ZsUJAPF%3D8Jk2GUjAXL%2B6E5-htX7R-wSuM_6MNVg%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/F957AAC7-A4F9-45D5-A80E-2BA788C6C721%40ix.netcom.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/CAK4xykX%3D1vALy1GDwAicJpN05nKMM60R7WMz6MBg97%2BLT%3DGZBg%40mail.gmail.com.

Re: [go-nuts] PCRE to RE2

[andrey mirtchovski]

I'm sorry to say that this list isn't RE2-specific (although one of
the main Go contributors wrote RE2). you will probably get very good
suggestions on how to convert that to Go's regex, which are RE2-like
and I hope you find your answer.

A good additional step to do for this particular list is to concoct a
small go example on play.golang.org with some sample input that you're
struggling with.

On Wed, Jul 24, 2019 at 11:11 PM Adam Takahashi  wrote:
>
> Hello,
>
> I currently have a regex in PCRE that is
>
> (.|\r|\n)*?(?=FOO)
>
> It reads in a random number of multiple lines of sentences, and stops when it 
> sees the word FOO in all caps. I am have problems converting this to a valid 
> RE2 expression.
> Any advice would help. 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/2b88000d-7344-40b6-8830-41f1f762962e%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/CAK4xykXUNER1vLLQ5bSXWQ23wMExn8Y5kKtwcSqp6MJTgMdwzg%40mail.gmail.com.

Re: [go-nuts] Re: About the Google logo on the new Go website

[andrey mirtchovski]

what you're doing has a term: character assassination.

please take it elsewhere. there are plenty of forums to air your grievances.

On Thu, Jul 18, 2019 at 11:31 PM Space A.  wrote:
>
> Another funny thing and I'm glad that you mentioned, is that "Woman Who Go" 
> and other known "non-google" initiatives, as you said, were founded or 
> co-founded by "developer advocate" Ashley McNamara. I don't know what kind of 
> contract or collaboration, or relations she had with Google or Google 
> employees, but she was quite "official" I would say, on all these 
> conferences. Now, she works for Microsoft. She also created and promoted own 
> printshop with Go-related merch with help of official Go community channels: 
> conferences, social networks, slack, etc. So, the interesting thing is that 
> in the post in Go blog it was claimed that 100% of money from new "official" 
> store will go to so-called non-profit org "GoBridge": 
> https://github.com/gobridge/about-us
> which is also seems to be founded or co-founded by her, along with other 
> existing Google and (perhaps some of the) ex-Google employees: 
> https://github.com/gobridge/about-us#leadership-team
> Ashley McNamara name there on the first place.
>
> You can Google a lot with her name and "GoBridge", "Woman Who Go" and other 
> keywords. For example here is her Patreon where she collects donations for 
> Go-related artworks, and also mentions that "Woman Who Go" and "GoBridge" are 
> being merged: https://www.patreon.com/posts/women-who-go-24864094
>
> So all money will still go to that same project but now with promotion made 
> on very top level, in official Go Programming Language blog. Even if that org 
> is true and registered "non-profit" org, I suspect it still pays salaries and 
> give contracts to sub-contractors. I tried to find any financial reports and 
> proofs or evidence of real actions taken, but all I found is some very 
> general stuff. At least it very suspicious. I don't believe that Google can't 
> fund such a non-profit initiative without affecting true artists.
>
> And apparently, very unlikely, that you paid a cent to any independent artist 
> over that years.
>
>
>
> On Friday, July 19, 2019 at 6:13:26 AM UTC+3, andrey mirtchovski wrote:
>>
>> really? throughout the years (and I've been here since the beginning)
>> i have spent infinitely more on non-google "go" merch than on google
>> go merch: stickers, t-shirts, campaigns supporting women who code,
>> etc, etc.
>>
>> come on. get off your high horse.
>
> --
> 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/39fb6e76-6acb-4470-b249-bcb202580d45%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/CAK4xykXes7KZfC939kzUkTrZivhqXhV3fv9PP4bHoSM-1EqM4A%40mail.gmail.com.

Re: [go-nuts] Re: About the Google logo on the new Go website

[andrey mirtchovski]

> Funny thing that today Google has announced "official" store for Go-related 
> merch, which in it's essence is a try to take away even an even tiny business 
> opportunities for artists who were creating some goods and had a very very 
> little outcome on this. Now they will have ZERO.

really? throughout the years (and I've been here since the beginning)
i have spent infinitely more on non-google "go" merch than on google
go merch: stickers, t-shirts, campaigns supporting women who code,
etc, etc.

come on. get off your high horse.

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

Re: [go-nuts] Re: About the Google logo on the new Go website

[andrey mirtchovski]

> Google invested in a tool for themselves, which helped a lot in getting some 
> zillions of bucks as return. Corps open smth to communities not because they 
> a "good", but because at some point they smart enough to make others work for 
> free.

I see a "Go Haters Handbook" in the works. I only wish Dennis Ritchie
could write the anti-foreword...

-- 
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/CAK4xykUN3Ftmo050Og__4zbQjPZtjkxntsBZcmyQf1v7%3D1VRuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Passing Struct from Go to C

[andrey mirtchovski]

the Go "Callback" struct may have completely different size and
alignment than the C.Foo one expected by C.initialize_engine.
therefore you want to construct the C version when calling
C.initialize_engine, and the Go version for everything else. Your call
may look something like this:

initStruct := C.calloc(1, sizeof(C.Foo))
initStruct.key_value_cb = C.callOnMeGo_cgo
initStrudct.data: C.int(1)

C.initialize_engine(pattern_db, module_path,
(*C.Foo)(unsafe.Pointer(initStruct)))

the Go Callback struct is not required unless you expect the callbacks
to change or be settable by library clients, in which case you'll need
to construct a more elaborate struct that implements locking and (at
least what I do) a map between callback names and interface{} pointing
to the callbacks sent by the library clients.

On Wed, Jul 10, 2019 at 8:14 AM Nitish Saboo  wrote:
>
> Hi Andrey,
>
> I am new to Go and cgo therefore did not exactly understand your point.
> Can you explain me in the context of the code that I had posted.It will 
> really help me to get hold of the things much better.
>
> Thanks,
> Nitish
>
> On Wed, Jul 10, 2019 at 5:19 PM andrey mirtchovski  
> wrote:
>>
>> what i do is have a similar struct in Go, and the original C one. here
>> 'callbacks' is the go one, and
>> "type Engine C.struct_cl_engine" is the opaque C one:
>>
>> https://github.com/mirtchovski/clamav/blob/master/callback.go#L63
>>
>> On Wed, Jul 10, 2019 at 5:25 AM Nitish Saboo  
>> wrote:
>> >
>> > Hi Andrey,
>> >
>> > I understand the issue here but how can I pass a callback function in a 
>> > struct to C code.I need a struct because I want to pass and an extra 
>> > parameter 'userdata' as well that I would require back as part of callback.
>> >
>> > Thanks,
>> > Nitish
>> >
>> > On Wed, Jul 10, 2019 at 4:39 PM andrey mirtchovski  
>> > wrote:
>> >>
>> >> i don't think you can use a go function directly in the callback. you
>> >> need a correctly-typed C helper to do it. at least that used to be the
>> >> case. see examples:
>> >>
>> >> https://github.com/mirtchovski/clamav/blob/master/cfuncs.go
>> >> https://github.com/mirtchovski/clamav/blob/master/callback.go

-- 
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/CAK4xykXPuOuEo-TCXrJDPhRymX_xQC-B_Yrywz1QcvkoYYA9PQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Passing Struct from Go to C

[andrey mirtchovski]

what i do is have a similar struct in Go, and the original C one. here
'callbacks' is the go one, and
"type Engine C.struct_cl_engine" is the opaque C one:

https://github.com/mirtchovski/clamav/blob/master/callback.go#L63

On Wed, Jul 10, 2019 at 5:25 AM Nitish Saboo  wrote:
>
> Hi Andrey,
>
> I understand the issue here but how can I pass a callback function in a 
> struct to C code.I need a struct because I want to pass and an extra 
> parameter 'userdata' as well that I would require back as part of callback.
>
> Thanks,
> Nitish
>
> On Wed, Jul 10, 2019 at 4:39 PM andrey mirtchovski  
> wrote:
>>
>> i don't think you can use a go function directly in the callback. you
>> need a correctly-typed C helper to do it. at least that used to be the
>> case. see examples:
>>
>> https://github.com/mirtchovski/clamav/blob/master/cfuncs.go
>> https://github.com/mirtchovski/clamav/blob/master/callback.go

-- 
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/CAK4xykVRS61Z5d-60QKTtNm%2BGO2TNbWeteb6KGNQq0490f8BVw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Passing Struct from Go to C

[andrey mirtchovski]

i don't think you can use a go function directly in the callback. you
need a correctly-typed C helper to do it. at least that used to be the
case. see examples:

https://github.com/mirtchovski/clamav/blob/master/cfuncs.go
https://github.com/mirtchovski/clamav/blob/master/callback.go

-- 
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/CAK4xykXyfti3P-49W-jbM9s_Jssb6m0w_FvN7JM6%3DR1s8mdGcg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[andrey mirtchovski]

- Other: [ ]

On Fri, Jul 5, 2019 at 5:12 PM Jakub Labath  wrote:
>
> But it's not a binary question.
>
> If you ask me
>
> Would like go to have Maybe/Option type instead of val, err - then I can say 
> yes.
> Would you like to have something such as Rust's Result instead of val, err - 
> then I can say yes (even though I understand this may not be possible due to 
> generics etc).
>
> But what is being asked here is would you like to have error handling and 
> flow of control functionality baked together - and then my answer is no.
>
> I know from several years of experience writing both go and python/java that 
> my go code is more stable than my python/java code is and the big part of it 
> is the proper error handling.
>
> And yes go does have panic/recover - but I never use them for the same 
> reasons I dislike exceptions. It's just really hard to reason about such 
> jumps in logic especially in massively concurrent programs that go allows us 
> to write.
>
>
>
> On Friday, July 5, 2019 at 10:30:43 PM UTC, andrey mirtchovski wrote:
>>
>> > So I was quiet on the topic then - I am not now.
>>
>> i guess you missed the point where I advocated for a new survey, well
>> advertised, where all the people who are fervent Go programmers but
>> somehow neglected to fill out the Go surveys for three years running
>> can cast their voice. "does go error handling need change: ◻️yes ◻️no
>
> --
> 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/3c8fc5c2-923f-46cd-965d-86889141dccb%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/CAK4xykXw4nUyiedRVKu%3DoH65w4u5qD8Cyg%2BdxuqGz2xFpBa%2BRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[andrey mirtchovski]

> So I was quiet on the topic then - I am not now.

i guess you missed the point where I advocated for a new survey, well
advertised, where all the people who are fervent Go programmers but
somehow neglected to fill out the Go surveys for three years running
can cast their voice. "does go error handling need change: ◻️yes ◻️no

-- 
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/CAK4xykXEtQZKeqyC8kLoHfokySD2xDzqY91hTz9_hMX%3DdkKtQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] OOM occurring with a small heap

[andrey mirtchovski]

0% 80.00%  1024.23kB 13.34%  
>> github.com/aws/aws-sdk-go/aws/request.(*Request).Sign
>>  0 0% 80.00%  1024.23kB 13.34%  
>> github.com/aws/aws-sdk-go/aws/signer/v4.(*signingCtx).build
>>  0 0% 80.00%  1024.23kB 13.34%  
>> github.com/aws/aws-sdk-go/aws/signer/v4.SignSDKRequest
>>  0 0% 80.00%  1024.23kB 13.34%  
>> github.com/aws/aws-sdk-go/aws/signer/v4.SignSDKRequestWithCurrentTime
>>  0 0% 80.00%  1024.23kB 13.34%  
>> github.com/aws/aws-sdk-go/aws/signer/v4.Signer.signWithBody
>>  0 0% 80.00%  1024.23kB 13.34%  
>> github.com/aws/aws-sdk-go/service/dynamodb.(*DynamoDB).GetItemWithContext
>>
>> On Tue, Jul 2, 2019 at 2:08 PM andrey mirtchovski  
>> wrote:
>>>
>>> What I have found useful in the past is pprof's ability to diff profiles. 
>>> That means that if you capture heap profiles at regular intervals you can 
>>> see a much smaller subset of changes and compare allocation patterns.
>>>
>>> On Tue, Jul 2, 2019, 10:53 AM 'Yunchi Luo' via golang-nuts 
>>>  wrote:
>>>>
>>>> I'm not so much pointing my finger at GC as I am hoping GC logs could help 
>>>> tell the story, and that someone with a strong understanding of GC in Go 
>>>> could weigh in here. In the last 4 seconds before OOM, "TotalAlloc" 
>>>> increased by only 80M, yet "HeapIdle" increased to 240M from 50M, RSS 
>>>> increased by 810M. The numbers don't add up for me. A running sum of 80M 
>>>> of heap objects were allocated in the time RSS increased by 10X that. If 
>>>> GC was completely off, I still wouldn't expect this to happen, which makes 
>>>> me want to rule out GC being blocked as a problem. Maybe there was runaway 
>>>> heap reservation because something in my code caused a ton of 
>>>> fragmentation? Is that sane? The heap profile lacking clues is also 
>>>> strange.
>>>>
>>>> Regarding the possibility of a race, I forgot I do have goroutine profiles 
>>>> captured along with the heap profiles at the time memory exploded. There 
>>>> are only 10 goroutines running on the serving path, which rules out too 
>>>> many concurrent requests being served (please correct me if I'm wrong). 
>>>> Those fan out to 13 goroutines talking to the db, all of which are in 
>>>> http.Transport.roundTrip (which is blocked on runtime.gopark so I assume 
>>>> they are waiting on the TCP connection). All other goroutines that don't 
>>>> originate in the stdlib are also blocked on `select` or sleeping. Our CI 
>>>> does run with go test -race, but I'll try doing some load testing with a 
>>>> race detector enabled binary.
>>>>
>>>> Bakul, that is sound advice. I've actually been debugging this on and off 
>>>> for a couple months now, with the help of several people, a few of which 
>>>> have peer reviewed the code. I agree it's most likely to be some runaway 
>>>> code that I caused in my logic, but we haven't been able to pin-point the 
>>>> cause and I've run out of hypothesis to test at the moment. This is why 
>>>> I've started asking on go-nuts@. The circuit breaker code was one of the 
>>>> first things I checked, has been unit tested and verified working with 
>>>> load tests. Now that you mention it, I actually did uncover a Go stdlib 
>>>> bug in http2 while doing the load tests... but that's unrelated.
>>>>
>>>>
>>>> On Tue, Jul 2, 2019 at 2:24 AM Bakul Shah  wrote:
>>>>>
>>>>> Before assuming it is the GC or something system related, you may wish to 
>>>>> verify it is *not your own logic*. Larger RSS could also be due to your 
>>>>> own logic touching more and more memory due to some runaway effect. The 
>>>>> probability this has to do with GC is very low given the very widespread 
>>>>> use of Go and the probability of a bug in new code is very high given it 
>>>>> is used on a much much smaller scale.
>>>>>
>>>>> This has the "smell" of a concurrency bug. If I were you I'd test the 
>>>>> code for any races, I'd review the code thoroughly with someone who 
>>>>> doesn't know the code so that I'm forced to explain it, and I'd add 
>>>>> plenty of assertions. I'd probably first look at the circuit breaker code 
>>>>> -- things like how does it know how many concurrent connections exist?

Re: [go-nuts] OOM occurring with a small heap

[andrey mirtchovski]

What I have found useful in the past is pprof's ability to diff profiles.
That means that if you capture heap profiles at regular intervals you can
see a much smaller subset of changes and compare allocation patterns.

On Tue, Jul 2, 2019, 10:53 AM 'Yunchi Luo' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I'm not so much pointing my finger at GC as I am hoping GC logs could help
> tell the story, and that someone with a strong understanding of GC in Go
> could weigh in here. In the last 4 seconds before OOM, "TotalAlloc"
> increased by only 80M, yet "HeapIdle" increased to 240M from 50M, RSS
> increased by 810M. The numbers don't add up for me. A running sum of 80M of
> heap objects were allocated in the time RSS increased by 10X that. If GC
> was completely off, I still wouldn't expect this to happen, which makes me
> want to rule out GC being blocked as a problem. Maybe there was runaway
> heap reservation because something in my code caused a ton of
> fragmentation? Is that sane? The heap profile lacking clues is also strange.
>
> Regarding the possibility of a race, I forgot I do have goroutine profiles
> captured along with the heap profiles at the time memory exploded. There
> are only 10 goroutines running on the serving path, which rules out too
> many concurrent requests being served (please correct me if I'm wrong).
> Those fan out to 13 goroutines talking to the db, all of which are in
> http.Transport.roundTrip (which is blocked on runtime.gopark so I assume
> they are waiting on the TCP connection). All other goroutines that don't
> originate in the stdlib are also blocked on `select` or sleeping. Our CI
> does run with go test -race, but I'll try doing some load testing with a
> race detector enabled binary.
>
> Bakul, that is sound advice. I've actually been debugging this on and off
> for a couple months now, with the help of several people, a few of which
> have peer reviewed the code. I agree it's most likely to be some runaway
> code that I caused in my logic, but we haven't been able to pin-point the
> cause and I've run out of hypothesis to test at the moment. This is why
> I've started asking on go-nuts@. The circuit breaker code was one of the
> first things I checked, has been unit tested and verified working with load
> tests. Now that you mention it, I actually did uncover a Go stdlib bug in
> http2 while doing the load tests... but that's unrelated.
>
>
> On Tue, Jul 2, 2019 at 2:24 AM Bakul Shah  wrote:
>
>> Before assuming it is the GC or something system related, you may wish to
>> verify it is *not your own logic*. Larger RSS could also be due to your own
>> logic touching more and more memory due to some runaway effect. The
>> probability this has to do with GC is very low given the very widespread
>> use of Go and the probability of a bug in new code is very high given it is
>> used on a much much smaller scale.
>>
>> This has the "smell" of a concurrency bug. If I were you I'd test the
>> code for any races, I'd review the code thoroughly with someone who doesn't
>> know the code so that I'm forced to explain it, and I'd add plenty of
>> assertions. I'd probably first look at the circuit breaker code -- things
>> like how does it know how many concurrent connections exist?
>>
>> In general, any hypothesis you come up with, you should have a test that
>> *catches* the bug given the hypothesis. Elusive bugs tend to become more
>> elusive as you are on the hunt and as you may fix other problems you
>> discover on the way.
>>
>> I even suspect you're looking at GC logs a bit too early. Instrument your
>> own code and look at what patterns emerge. [Not to mention any time you
>> spend on understanding your code will help improve your service; but better
>> understanding of and debugging the GC won't necessarily help you!]
>>
>> On Jul 1, 2019, at 12:14 PM, 'Yunchi Luo' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>> Hello, I'd like to solicit some help with a weird GC issue we are seeing.
>>
>> I'm trying to debug OOM on a service we are running in k8s. The service
>> is just a CRUD server hitting a database (DynamoDB). Each replica serves
>> about 300 qps of traffic. There are no memory leaks. On occasion (seemingly
>> correlated to small latency spikes on the backend), the service would OOM.
>> This is surprising because it has a circuit breaker that drops requests
>> after 200 concurrent connections that has never trips, and goroutine
>> profiles confirm that there are nowhere 200 active goroutines.
>>
>> GC logs are pasted below. It's interlaced with dumps of runtime.Memstats
>> (the RSS number is coming from /proc//stats). Go version is 1.12.5,
>> running an Alpine 3.10 container in an Amazon kernel
>> 4.14.123-111.109.amzn2.x86_64.
>>
>> The service happily serves requests using ~50MB of RSS for hours, until
>> the last 2 seconds, where GC mark time starts to 2-4X per cycle 
>> (43+489/158/0.60+0.021
>> ms cpu => 43+489/158/0.60+0.021 ms 

Re: [go-nuts] Counter-counter-counter proposals

[andrey mirtchovski]

"Users don't care about what the designer does. They care about what
they do. If every time you drove a car, you had to learn the meaning
of 100 knobs, the whole system wouldn't work. Simplicity comes from
tuning down the tasks required to drive the car into a certain set of
understood paradigms and tools. Yes, there are many people who would
love to pull up the hood and start tinkering with things. You can let
them, as long as that is all under the hood."

On Sun, Jun 30, 2019 at 8:50 PM Michael Jones  wrote:
>
> With so many strongly worded emotional emails flying it might be helpful to 
> remember that language design is about other people and other use cases than 
> your own. The truly good answer meets the needs of many and harms few, 
> anticipates that no answer is final, and is flexible. Here is a nice way to 
> think about it:
>
> Taste and Aesthetics, A Conversation with Ken Arnold, Part II
> by Bill Venners, September 16, 2002
> https://www.artima.com/intv/taste.html
>
>
> Responsibility for others means focusing on issues beyond your own. As CTO of 
> Google Maps, Earth, and Local Search, I had to think about what was good for 
> 1.5 billion unique monthly users, not what was good to me as a map guy. The 
> Go designers are in the same situation. When we offer advice to them, we 
> might best think that way too.
>
> --
> Michael T. Jones
> michael.jo...@gmail.com
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CALoEmQze-1ZuY5NTijiTmrpzbnbRzUT_kKD88s0XBzNHzqHjdw%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/CAK4xykVM%2ByivZJGPSVYj%3D5PPNwyZDDpfuA8pKyjQAOuRv7Mx3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[andrey mirtchovski]

>  I will let Andrey speak for himself.

Since this is turning into a bit of fisticuffs I will quote my private
message to you for clarity, here it is:

--8<-
Your point is a good one. I agree with your stance.

> Which is why nothing should be done, because every proposal is going to fall 
> short of exception handling, and be little more than syntactic sugar over 
> what is available today.
>
> And Go has advantages over in many areas so stating “if you want decent error 
> handling use Java” makes my case quite nicely.
--8<-

It still means "if you want Java error handling use Java".

What was lost from my original email is that I advocate another survey
which places the question of error handling at the front and that is
more vocally popularized/disseminated (the sample set from the 2018
survey that places 5% of participants as having issues with error
handling is not a sufficiently large one, the issue and proposals
trackers are an even smaller sample set).

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

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[andrey mirtchovski]

> go back to what is proven to work - Java and C++ are the dominant languages 
> in use today, adding their exception based error handling to Go is ‘the way 
> to Go” :)

the battle you're fighting has already been lost. if you want java you
know where to find it :)

-- 
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/CAK4xykVOcMaeDn8zMR%2BMbs4f%2BFS305wyLE%2BY_AQdZkcFugeMVw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[andrey mirtchovski]

> This issue seems to have resonated with a lot of people, which may be an 
> important data point when considering the try proposal

Where were all those people when the Go Surveys were being taken the
last few years? Overwhelmingly, the people have voted error handling
as a major issue. The voters may not be intimately involved with Go
development and may not be willing to produce proposals, but the votes
are there and speak loudly. A vocal minority skewing the proposals
with downvotes should not be a cause to abscond something that server
the greater good.

If the status quo can not be breached, the worst we can do is another
round of the Go Survey and vocally invite everyone to participate.

On Sat, Jun 29, 2019 at 2:03 PM Burak Serdar  wrote:
>
> On Sat, Jun 29, 2019 at 1:45 PM Robert Engels  wrote:
> >
> > If you don’t understand the history you are doomed to repeat it. The ‘try’ 
> > proposal is barely better than the current  situation. There is as a reason 
> > exception handling with try catch was designed along with OO. It simplifies 
> > error handling immensely. “Try” as you might, you might think you are 
> > improving on it, but you’re not.
>
> I think try-catch simplifies writing error handling code, but not
> necessarily simplifies understanding or modifying it once it is
> written.
>
> I, too, like the if err!=nil {} as it is. One improvement I can think
> of is reducing the boilerplate by implementing  a macro-like
> extension:
>
> func f() {
>   handle openErr(err) error {
> return err
>   }
>  x, openErr:=os.Open(...)
>
> openErr would be called if the error is non-nil. Some months ago I did
> write a proposal similar to this, and I was not the only one thinking
> along the same lines. It is backward compatible, and the code is still
> readable in my opinion.
>
>
>
> >
> > Go should implement caught exceptions and be done with it. Stop trying to 
> > be cute. Take what works elsewhere and stop thinking you’re always the 
> > smartest person in the room.
> >
> > On Jun 29, 2019, at 2:35 PM, Tyler Compton  wrote:
> >
> > Sorry, forgot to CC on my last email. Here it is again:
> >
> >> And you must understand the specific: you are solving relatively hard 
> >> problems developing language called Go with low mistake cost and we are 
> >> solving simple problems with a DSL called Go but our mistake cost is much 
> >> higher than yours.
> >
> >
> > Sorry, I'm not sure I understand. Who is the "you" and "we" in these 
> > circumstances? I should be clear, I'm not a Go core team member and I had 
> > nothing to do with the creation of the original "try" proposal. I've just 
> > been involved in the proposal and anti-proposal discussion and noticed a 
> > shift in tone.
> >
> >> I thought you are trying to be as practical as possible making a language 
> >> with such a retarded yet somehow usable type system in XXI. But this 
> >> recent proposal raises some suspicions...
> >
> >
> > What is XXI? Are you referring to Go's type system?
> >
> > On Sat, Jun 29, 2019 at 12:18 PM Denis Cheremisov 
> >  wrote:
> >>
> >> And prepare for wider audience in shitty “try” proposal after 1 July.
> >>
> >> --
> >> 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/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%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/CAA%3DXfu031bDbJheZ5-JUbsea1%2BYAn68dfO5ve8pn4T7%3DRFxqRQ%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/A4B77F76-E16F-4AE0-AAD4-29C553F079B0%40ix.netcom.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/CAMV2Rqq%2BeOZoyEVj-p%3DXJE3%3DUeA%2B%2B5ZLrTLp-SdxqVhxOqec9g%40mail.gmail.com.
> For more 

Re: [go-nuts] Pointer Method Receiver

[andrey mirtchovski]

Hi Ali,

I understand your desire to provide useful information about Go in
blog posts. This is commendable. However let's try to keep this list
for technical issues and keep empty posts containing just a link to a
minimum. More signal, less noise. Is there a particular issue you'd
like to raise? Is there a particular item you'd like to address? Let's
talk about that.

There are plenty of aggregators that will cheerfully accept your link:
/r/golang, HN, slashdot. There people can vote whether a particular
item is of interest. Here, it's just a mailing list. The more noise,
the less people are willing to monitor it, and the less real issues
get addressed.

Sincerely,

On Sun, Jun 16, 2019 at 1:12 PM Ali Hassan  wrote:
>
>
> https://koohinoorgo.blogspot.com/2019/06/methods-receiver-are-not-variable-type.html
>
>
> #golang
>
> --
> 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/4b493d1c-7f0c-4a66-9560-2a1fedae952e%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/CAK4xykXJbrKfYk%3DxFXST84sCQ1t6eVz2GMUSZrJqkTvp-aKnew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] https://godoc.org/github.com/couchbase/moss

[andrey mirtchovski]

collection is not an exported type:
https://github.com/couchbase/moss/blob/master/collection.go#L24

the ?m=all parameter should enable you to see those, but it's not
working for me on your link. perhaps because "collection" and
"Collection" are not considered by godoc to be two different things?
you may have to file a bug.

here's more info on m=all: https://godoc.org/golang.org/x/tools/cmd/godoc

On Wed, Jun 12, 2019 at 3:25 PM Gert  wrote:
>
> Is it just me or is stuff missing in godoc like for example
>
> // NewBatch returns a new Batch instance with hinted amount of
> // resources expected to be required.
> func (m *collection) NewBatch(totalOps, totalKeyValBytes int) (
> ...
> }
>
> from collection.go
>
> https://godoc.org/github.com/couchbase/moss
>
> --
> 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/fd93525d-f221-4d95-9f20-44dc60308538%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/CAK4xykV%3DHSg_7zq0QWZV%3DQiNMADWdiEJGoyezpp9N5KmMiajYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How can I compile my project only relay on my vendor folder with go modules?

[andrey mirtchovski]

"go mod vendor" will populate the vendor directory in your project,
then "go build -mod=vendor" will only use that directory to build.

On Tue, Jun 11, 2019 at 3:12 AM 唐彦昭  wrote:
>
> I need put my project on the server to compile.But my server can't connect to 
> internet.
> So I need to put all my relay in my vendor folder in my develop environment.
> How can I do this with go 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/e7f1ae76-3d41-494b-b771-0efc1a3c5784%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/CAK4xykXqhBkwrtOASqKdF4vKgeZzOvtERJAYiqatGFb6x9bgYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: A good indicator of code quality

[andrey mirtchovski]

"does it look like the go standard library?"

that style is desirable, yet inimitable

-- 
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/CAK4xykXwho1GeeJ883kPzCtOPXSNpPamLw6qAcBzQQgOLm8xYw%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.

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

[andrey mirtchovski]

On Fri, May 24, 2019 at 12:49 AM Rob Pike  wrote:
>
> If that's true - and it might well not be - it's a surprise to me. When 
> launching the language we explicitly made sure NOT to trademark it.
>

Go appears to be trademarked, as well as the new design of the Go
logo. Golang doesn't seem to be. Hopefully these links work:

http://tmsearch.uspto.gov/bin/showfield?f=doc=4801:7mlvuo.5.15
http://tmsearch.uspto.gov/bin/showfield?f=doc=4801:7mlvuo.5.14

Filing dates for both are August 2018, owner of the trademarks is Google.

-- 
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/CAK4xykV8YF21fncR-wLD-RL115o0eauDUJ19MhxMCrSOrAc7Qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go runtime in DLL not getting intialized(?) on some windows hosts

[andrey mirtchovski]

file an issue, please, if you have not done so already. i'd like to follow it.

On Mon, May 13, 2019 at 8:01 PM Jason E. Aten  wrote:
>
> Indeed, confirming data: I can re-create the crashing circumstances 
> immediately by renaming C:\Go to C:\Go1.12.5.
>
> On Tuesday, May 14, 2019 at 3:53:10 AM UTC+2, Jason E. Aten wrote:
>>
>> Installing the Go build environment locally on the deploy host fixed the 
>> crash. I'm guessing it is probably the missing timezone data on Windows, as 
>> in
>>
>> https://github.com/golang/go/issues/21881
>>
>> or some other assumption by the runtime inside the DLL that it is running on 
>> a machine that has the Go build environment installed.
>>
>> On Saturday, May 11, 2019 at 2:42:40 AM UTC+2, Ian Lance Taylor wrote:
>>>
>>> On Fri, May 10, 2019 at 1:43 PM Jason E. Aten  wrote:
>>> >
>>> > I wondering if anyone can shed some light on
>>> >
>>> > a) how I might understand when the Go runtime inside a DLL is supposed to 
>>> > be initialized;
>>>
>>> In c-shared mode the function _rt0_amd64_windows_lib is supposed to be
>>> called when the DLL is initialized.  That function, in
>>> runtime/rt0_windows_amd64.s, should start a new thread that will
>>> initialize the Go runtime.
>>>
>>> The Windows support for c-shared is very new, and perhaps there are
>>> some circumstances in which it does not arrange for
>>> rt0_amd64_windows_lib to be run when the DLL is loaded.  I'm not sure
>>> but I think the code that sets this up is (*peFile).addInitArray in
>>> cmd/link/internal/ld/pe.go.  So make sure that method is being called,
>>> and then make sure it is doing the right thing.
>>>
>>> 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/43733e84-b762-4c33-a8bc-047689bfdb4a%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/CAK4xykW-3_2%2BZpxgd5OGb_p%3DPESSjSXNPeYPFv11B6uTmPN%2BiQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] What happens to global vars when main() ends ?

[andrey mirtchovski]

when you terminate a process the virtual memory associated with that
process ceases to exist. any real memory associated with that process
is not addressable anymore. if another process allocates a page that
maps to a page previously held by the first process will get a
zeroed-out page.

you should not worry about leaking keys after a program exit. this is
not a GC concept, it's a modern operating system concept.

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

Re: [go-nuts] What happens to global vars when main() ends ?

[andrey mirtchovski]

https://www.ardanlabs.com/blog/2018/12/garbage-collection-in-go-part1-semantics.html

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

Re: [go-nuts] Re: If Go is using libc instead of syscalls on macOS now, why is it not shown via otool -L?

[andrey mirtchovski]

macOS doesn't support static linking user binaries. in fact I do see
libSystem linked for each go binary on my Mojave system, including the
simplest non-outputting hello world:

$ cat > t.go
package main; func main(){}
$ go build t.go && otool -L t
t: /usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current
version 0.0.0)
$

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

Re: [go-nuts] Re: Need help to launch hello.go

[andrey mirtchovski]

I'm sorry that I can't help more. It appears to me that the go builder
was able to create some of the temporary files it needs, but not
others. This is a very strange situation that I have not seen before.
Akin to having a full disk or otherwise exhausting the storage
availability.

I do not know how to diagnose any more of this on windows. Apologies.

On Tue, Apr 30, 2019 at 1:11 PM Avetis Sargsian
 wrote:
>
> Ok there is one file in
> E:\temp\go-build828919622\b001\importcfg.link
> end is empty in
> E:\temp\go-build828919622\b001\exe
>
> this is content of importcfg.link
> packagefile 
> hello=C:\Users\Avetis\AppData\Local\go-build\ae\aecfeab49f117df031d74e0ca3aad783ba25f0524b981cbb74a2db671205fadd-d
> packagefile fmt=C:\Go\pkg\windows_amd64\fmt.a
> packagefile runtime=C:\Go\pkg\windows_amd64\runtime.a
> packagefile errors=C:\Go\pkg\windows_amd64\errors.a
> packagefile internal/fmtsort=C:\Go\pkg\windows_amd64\internal\fmtsort.a
> packagefile io=C:\Go\pkg\windows_amd64\io.a
> packagefile math=C:\Go\pkg\windows_amd64\math.a
> packagefile os=C:\Go\pkg\windows_amd64\os.a
> packagefile reflect=C:\Go\pkg\windows_amd64\reflect.a
> packagefile strconv=C:\Go\pkg\windows_amd64\strconv.a
> packagefile sync=C:\Go\pkg\windows_amd64\sync.a
> packagefile unicode/utf8=C:\Go\pkg\windows_amd64\unicode\utf8.a
> packagefile internal/bytealg=C:\Go\pkg\windows_amd64\internal\bytealg.a
> packagefile internal/cpu=C:\Go\pkg\windows_amd64\internal\cpu.a
> packagefile 
> runtime/internal/atomic=C:\Go\pkg\windows_amd64\runtime\internal\atomic.a
> packagefile 
> runtime/internal/math=C:\Go\pkg\windows_amd64\runtime\internal\math.a
> packagefile 
> runtime/internal/sys=C:\Go\pkg\windows_amd64\runtime\internal\sys.a
> packagefile sort=C:\Go\pkg\windows_amd64\sort.a
> packagefile sync/atomic=C:\Go\pkg\windows_amd64\sync\atomic.a
> packagefile math/bits=C:\Go\pkg\windows_amd64\math\bits.a
> packagefile internal/poll=C:\Go\pkg\windows_amd64\internal\poll.a
> packagefile 
> internal/syscall/windows=C:\Go\pkg\windows_amd64\internal\syscall\windows.a
> packagefile internal/testlog=C:\Go\pkg\windows_amd64\internal\testlog.a
> packagefile syscall=C:\Go\pkg\windows_amd64\syscall.a
> packagefile time=C:\Go\pkg\windows_amd64\time.a
> packagefile unicode/utf16=C:\Go\pkg\windows_amd64\unicode\utf16.a
> packagefile unicode=C:\Go\pkg\windows_amd64\unicode.a
> packagefile internal/race=C:\Go\pkg\windows_amd64\internal\race.a
> packagefile 
> internal/syscall/windows/sysdll=C:\Go\pkg\windows_amd64\internal\syscall\windows\sysdll.a
> packagefile 
> internal/syscall/windows/registry=C:\Go\pkg\windows_amd64\internal\syscall\windows\registry.a
>
> вт, 30 апр. 2019 г. в 18:57, andrey mirtchovski :
>>
>> > PS F:\GoWorckspace\src\hello> go build -work
>> > WORK=E:\temp\go-build828919622
>> > open E:\temp\go-build828919622\b001\exe\a.out.exe: The system cannot find 
>> > the file specified.
>>
>> once you have done this you should be able to cd to
>> E:\temp\go-build828919622 and look around to see if any files have
>> been created, including b001\exe\a.out.exe.

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

Re: [go-nuts] Re: Need help to launch hello.go

[andrey mirtchovski]

> PS F:\GoWorckspace\src\hello> go install
> open E:\temp\go-build447177998\b001\exe\a.out.exe: The system cannot find the 
> file specified.

is this a school or work computer? if yes then a group policy may have
disabled the execution of exe files. supply the "-work" argument to go
build. it will print the working directory and will not delete it
after finishing its run. then you can navigate to it and see if the
.exe file is there at all. i imagine, since only the .exe is the
problem, you will be able to see all the other temporary files that go
created.

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

Re: [go-nuts] Re: Need help to launch hello.go

[andrey mirtchovski]

try setting GOTMPDIR. not sure what this corresponds to on windows,
but it will change where the go tool will create its temp files:

$ go run -x t.go
WORK=/var/folders/sp/06p28g2d0vs7gd2vhf26wl9mgn/T/go-build126372523
[...]
$ GOTMPDIR=/tmp/go go run -x t.go
WORK=/tmp/go/go-build661115935
[...]

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

Re: [go-nuts] strange bug

[andrey mirtchovski]

> But still, it would seem the range index should be unsigned - what would be 
> the purpose of it being signed? Similarly, the slice indexing should be 
> unsigned as well. Just thinking about it...

not the first time this has come up. here are a couple of references:

https://groups.google.com/d/msg/golang-nuts/QqTCTFwspcM/HLBxhqJKuMQJ
https://groups.google.com/forum/#!msg/golang-nuts/jJWAAMdquwQ/jhWhxJJbzVYJ

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

Re: [go-nuts] strange bug

[andrey mirtchovski]

> So, the question is: why ‘i’ isn’t treated as unsigned, since it is a range 
> index - won't it always be positive?

The author of the PR was most likely working on Go's tip (what will
become 1.13), where the requirement that the right operator in a shift
is an unsigned integer has been lifted.

compare the third paragraph between these versions:

https://tip.golang.org/ref/spec#Operators
https://golang.org/ref/spec#Operators

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

Re: [go-nuts] Go if else syntax .. suggested replacement

[andrey mirtchovski]

Please do! We need to resolve this connundrum for the next 5
generations of computer programmers!

On Wed, Apr 24, 2019 at 8:41 PM David Riley  wrote:
>
> On Apr 24, 2019, at 5:25 PM, andrey mirtchovski  wrote:
> >
> >> I may easily misremember, but that doesn't match my recollection.  I
> >> don't remember what position Rob and Robert took, but as I recall Ken
> >> was generally opposed to the ternary operator.  He had been in part
> >> responsible for adding it to C, and felt that it had been a mistake.
> >>
> >> Ian
> >
> > I am happy to stand corrected. I believe it was an offhand comment by
> > either Rob or Russ in one of the early Go talks. Unfortunately hard to
> > find 10 years later, especially in non-transcribed videos.
>
> Well, Ken is giving the keynote at the Vintage Computer Festival East this 
> year, maybe I can ask him then. :-)
>
>
> - 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go if else syntax .. suggested replacement

[andrey mirtchovski]

> I may easily misremember, but that doesn't match my recollection.  I
> don't remember what position Rob and Robert took, but as I recall Ken
> was generally opposed to the ternary operator.  He had been in part
> responsible for adding it to C, and felt that it had been a mistake.
>
> Ian

I am happy to stand corrected. I believe it was an offhand comment by
either Rob or Russ in one of the early Go talks. Unfortunately hard to
find 10 years later, especially in non-transcribed videos.

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

Re: [go-nuts] Go if else syntax .. suggested replacement

[andrey mirtchovski]

Here's the lore associated with the subject: Ken wanted ternary, Rob
and Robert did not. They overruled Ken (remember, early on all three
had to agree for a feature to go in). The end.

The number of frivolous and egregious abuse of ternary that I've seen
in _modern_ C code is too high.jpg

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

Re: [go-nuts] Go if else syntax .. suggested replacement

[andrey mirtchovski]

> ? (test) {
> //...do something
> }
> {
> //..do something else
> }

I believe the Go team considered this very carefully early on the
language's development and came to the decision to use "if test" for
"? (test)" and "} else {" for "}{" (without the implied newline). They
also threw in "} else if test {" for good measure, which your example
does not cover.

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

Re: [go-nuts] is -2147483648 the same as MinInt32

[andrey mirtchovski]

wolfram alpha is a good place to do numbers:
https://www.wolframalpha.com/input/?i=-1+%3C%3C+31

if you're on a mac, the calculator has a "programmer mode" which
allows arbitrary manipulations of bits.

On Sun, Apr 21, 2019 at 9:36 PM Pat Farrell  wrote:
>
> I have a logic error in my calculation. I am getting -2147483648 in an int32
> This sure looks a lot like MinInt32, but I can't seem to be able to tell, all 
> my calculators want to blow up on -1 << 31
>
>
> I'm willing to bet that my value is +/- one from whatever MinInt32 is in 
> decimal form.
>
> Is this correct?
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] go build *.exe file size seems much too large

[andrey mirtchovski]

the go runtime (bare, nothing else) is about 1.1MB now. the "fmt"
package brings almost a MB of dependencies including 800 or so
unicode-related functions (names/symbols), reflection, etc. the math
package brings almost nothing: 11 symbols.

-8<
$ cat t.go
package main

func main() {
}
$ go build t.go && ls -lh t
-rwxr-xr-x  1 a  s   1.1M 21 Apr 20:35 t
$ cat > t.go
package main
import "fmt"
func main() {
fmt.Println("test")
}
$ go build t.go && ls -lh t
-rwxr-xr-x  1 a  s   2.0M 21 Apr 20:36 t
$ cat > t.go
package main
import ("fmt"; "math")
func main() { fmt.Printf("\n %8.3f", math.Sin(1.2) ) }
$ go build t.go && ls -lh t
-rwxr-xr-x  1 a  s   2.0M 21 Apr 20:38 t
>8--

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

Re: [go-nuts] The smaller argument a time.Sleep call takes, the more allocations?

[andrey mirtchovski]

You need the -benchmem flag to get a report of allocations:

$ go test -bench=. -benchmem
goos: darwin
goarch: amd64
BenchmarkTestSleep_2000-4   1 2005447537 ns/op  456 B/op
 3 allocs/op
BenchmarkTestSleep_1000-4   1 1001627153 ns/op   64 B/op
 1 allocs/op
BenchmarkTestSleep_500-4   2 500908757 ns/op   36 B/op
   1 allocs/op
BenchmarkTestSleep_100-4  10 101720516 ns/op6 B/op
   0 allocs/op
BenchmarkTestSleep_10-4   100   12494871 ns/op0 B/op
 0 allocs/op
PASS
ok  _/tmp 6.911s

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

Re: [go-nuts] how to get file's current offset

[andrey mirtchovski]

On Fri, Apr 19, 2019, 4:48 PM Rob Pike  wrote:

> I just use 1 so I don't have to look up what it's called these days, but
> I'm seriously old school.
>

Does that pass code review or do people give you the benefit of doubt?

>

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

Re: [go-nuts] how to get file's current offset

[andrey mirtchovski]

> offset, err := f.Seek(0, io.SeekCurrent)

my code has been written so long ago i didn't even notice os.SEEK_CUR
is deprecated :)

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

Re: [go-nuts] how to get file's current offset

[andrey mirtchovski]

offset, err := f.Seek(0, os.SEEK_CUR)

On Thu, Apr 18, 2019 at 8:50 AM  wrote:
>
> I want to know file's current read offset after open a file, but I can not 
> found related API.
>
>
>
>
>
> f, err := os.Open("/tmp/")
> if err != nil{
> panic(err)
> }
>
> ... // some read operation
>
> // how can I get f's current read offset??
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Interaction between Modules and GOPATH

[andrey mirtchovski]

> So do *not* use go get when manually cloning the project then I take it?

That is correct. For most developers it would be one or more
repositories that contain many modules, not all of which would be
go-gettable anyway.

Also note that "go get" in module mode (outside of GOPATH) will
unpackage with non-writable permissions to the local cache, as
packages are not intended to be modified. Cloning the repo is the best
way to get something you can work on.

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

Re: [go-nuts] what does p stand for in io.Reader.Read argument

[andrey mirtchovski]

It may help to note that in the earliest references to the Read
interface in the history of the language it accepted a *[]byte, hence
'p' may indeed stand for pointer.

https://github.com/golang/go/commit/7c9e2c2b6c2e0aa3090dbd5183809e1b2f53359b#diff-bf734f53a84f388bf39699d291b06b1d

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

Re: [go-nuts] What's the max amount of RAM a Go program can allocate on 64-bit Windows?

[andrey mirtchovski]

There used to be a 512GB heap limit which was removed in Go 1.11.
Currently there should be no heap limit. For additional information
see:

https://github.com/golang/go/commit/2b415549b813ba36caafa34fc34d72e47ee8335c

On Tue, Mar 5, 2019 at 2:08 PM  wrote:
>
> I've seen various figures from older versions of 16 GB, 128 GB and (I think) 
> 32 GB.  What's the limit in recent versions of Go?
>
> John
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Inconsistent reporting of unused package variable initialized in init() but used elsewhere

[andrey mirtchovski]

in https://play.golang.org/p/5P5vcebYkGj you're shadowing s by
creating a new variable via :=

this is a common go interview question :)

On Sat, Feb 23, 2019 at 9:34 PM  wrote:
>
> Hello,
>
> It's likely that I'm misinterpreting the language spec. It's also easy to 
> circumvent by assigning the offending variable to _.  Even if this turns out 
> to be complying with the spec, thought this post may help anyone else looking 
> up this forum for answers.
>
> https://play.golang.org/p/5P5vcebYkGj reports an unused error for a package 
> variable initialized inside init() even though it's used elsewhere. In this 
> case doSomething() has 2 return values, one of which is the package variable 
> while the other is local.
>
> https://play.golang.org/p/DBXdNOHAA2Z does not report an error for a package 
> variable initialized inside init(). In this case doSomething() has a single 
> return value.
>
> https://play.golang.org/p/pdz2mMnQ_EZ  similarly does not report an error for 
> 2 package variables initialized inside init(). In this case doSomething() has 
> 2  return values as well.
>
> 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.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Visual Studio Code oddity with Go

[andrey mirtchovski]

reposting my private comment from a day ago for those searching for answers:

try "command-shift-p" or ctrl-shift-p depending on your operating
system, to bring the "all commands" pop-up. there you should be able
to find "Go: Install/Update tools". click on the checkboxes. hit
enter.

On Wed, Feb 20, 2019 at 7:14 AM Rich  wrote:
>
> I tried googling this but I not been able to find a solution, hopefully I can 
> ask this here and someone else knows how to fix this.  I use Visual Studio 
> Code -- because it's free. The issue I am having is that every time I use 
> Visual Studio Code I get the popup that says:
>
>> The Go extension is better with the latest version of "gocode".  Use "go get 
>> -u -v github.com/mdempsky/gocode" to update
>
>
> Anyone else have this or know how to fix this? It shouldn't ask EVERY time I 
> use Visual Studio Code?
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] go mod verify fails for github.com/docker/docker and github.com/hashicorp/go-rootcerts

[andrey mirtchovski]

There was a change to how go mod treats softlinks in repositories
which changed the hash generated for some packages (we found out the
issue via git.apache.org/thrift.git). If the repo contains softlinks
and you generated your go.mod file before Go 1.11.3 (Go 1.11.2 still
exhibited the bug) then the hashes will have changed.

Not sure if that's the problem you're experiencing, but another way to
verify is to go back to your older Go version and see if go mod verify
passes there (after cleaning all caches).

On Mon, Feb 18, 2019 at 7:52 AM Joseph Lorenzini  wrote:
>
> Hi all,
>
> I've been using go modules since 1.10. I am now on 1.11.5. Go mod verify is 
> now failing since I went to go 1.11. Negative is old, plus is new.
>
> -github.com/docker/docker v0.7.3-0.20180827131323-0c5f8d2b9b23 
> h1:Zl/9mUfPbYbnv895OXx9WfxPjwqSZHohuZzVcjJ5QPQ=
> +github.com/docker/docker v0.7.3-0.20180827131323-0c5f8d2b9b23 
> h1:mJtkfC9RUrUWHMk0cFDNhVoc9U3k2FRAzEZ+5pqSIHo=
> -github.com/hashicorp/go-rootcerts v0.0.0-20160503143440-6bb64b370b90 
> h1:9HVkPxOpo+yO93Ah4yrO67d/qh0fbLLWbKqhYjyHq9A=
> +github.com/hashicorp/go-rootcerts v0.0.0-20160503143440-6bb64b370b90 
> h1:VBj0QYQ0u2MCJzBfeYXGexnAl17GsH1yidnoxCqqD9E=
>
> I can "fix" this by simply removing the offending entries and allowing go mod 
> tidy to repopulate them. However, that defeats the purpose of the go.sum, 
> which is to say if a go mod verify has failed, then this should mean that the 
> source code I thought I had no longer exists.  What I am trying to figure out 
> is if the way go calculates the hashes has changed and there was or is a bug 
> in that or the source code for these two packages at the given git commit ID 
> no longer matches the source code checked out on disk. The later is more 
> concerning to me.
>
> Thanks,
> Joe
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Modules. A "new" system.

[andrey mirtchovski]

cray was optimized for throughput, after all ;)

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

[go-nuts] Re: [golang-dev] Re: [security] Go 1.11.5 and Go 1.10.8 are released

[andrey mirtchovski]

Got it, thanks.

On Wed, Jan 23, 2019 at 6:41 PM Julie Qiu  wrote:
>
> We will not be updating the archives for this release. The reason is because 
> these directories do not affect functionality, and we do not want to risk the 
> availability of the security release, nor we want to change the contents of 
> already published archives.
>
> Julie
>
> On Wed, Jan 23, 2019 at 8:00 PM andrey mirtchovski  
> wrote:
>>
>> sorry to be a bother, but are you publishing new archives? will you
>> publish new hashes for the archives with the commands executed thusly?
>>
>> On Wed, Jan 23, 2019 at 5:12 PM Julie Qiu  wrote:
>> >
>> > Hello gophers,
>> >
>> > Due to an issue with the release tooling (https://golang.org/issue/29906), 
>> > go1.11.5.linux-amd64.tar.gz and go1.10.8.linux-amd64.tar.gz include two 
>> > unnecessary directories in the root of the archive: "gocache" and "tmp".
>> >
>> > They are harmless and safe to remove.
>> >
>> > The following commands can be used to extract only the necessary “go” 
>> > directory from the archives:
>> >
>> > tar -C /usr/local -xzf go1.11.5.linux-amd64.tar.gz go
>> > tar -C /usr/local -xzf go1.10.8.linux-amd64.tar.gz go
>> >
>> >
>> > These commands will create a Go tree in /usr/local/go.
>> >
>> > Sorry for the inconvenience,
>> > Julie (on behalf of the Go team)
>> >
>> > On Wed, Jan 23, 2019 at 4:53 PM Julie Qiu  wrote:
>> >>
>> >> Hi gophers,
>> >>
>> >> We have just released Go 1.11.5 and Go 1.10.8 to address a recently 
>> >> reported security issue. We recommend that all users update to one of 
>> >> these releases (if you’re not sure which, choose Go 1.11.5).
>> >>
>> >> This DoS vulnerability in the crypto/elliptic implementations of the 
>> >> P-521 and P-384 elliptic curves may let an attacker craft inputs that 
>> >> consume excessive amounts of CPU.
>> >>
>> >> These inputs might be delivered via TLS handshakes, X.509 certificates, 
>> >> JWT tokens, ECDH shares or ECDSA signatures. In some cases, if an ECDH 
>> >> private key is reused more than once, the attack can also lead to key 
>> >> recovery.
>> >>
>> >> The issue is CVE-2019-6486 and Go issue golang.org/issue/29903. See the 
>> >> Go issue for more details.
>> >>
>> >> Downloads are available at https://golang.org/dl for all supported 
>> >> platforms.
>> >>
>> >> Cheers,
>> >>
>> >> Julie (on behalf of the Go team)
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "golang-dev" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to golang-dev+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.

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

[go-nuts] Re: [golang-dev] Re: [security] Go 1.11.5 and Go 1.10.8 are released

[andrey mirtchovski]

sorry to be a bother, but are you publishing new archives? will you
publish new hashes for the archives with the commands executed thusly?

On Wed, Jan 23, 2019 at 5:12 PM Julie Qiu  wrote:
>
> Hello gophers,
>
> Due to an issue with the release tooling (https://golang.org/issue/29906), 
> go1.11.5.linux-amd64.tar.gz and go1.10.8.linux-amd64.tar.gz include two 
> unnecessary directories in the root of the archive: "gocache" and "tmp".
>
> They are harmless and safe to remove.
>
> The following commands can be used to extract only the necessary “go” 
> directory from the archives:
>
> tar -C /usr/local -xzf go1.11.5.linux-amd64.tar.gz go
> tar -C /usr/local -xzf go1.10.8.linux-amd64.tar.gz go
>
>
> These commands will create a Go tree in /usr/local/go.
>
> Sorry for the inconvenience,
> Julie (on behalf of the Go team)
>
> On Wed, Jan 23, 2019 at 4:53 PM Julie Qiu  wrote:
>>
>> Hi gophers,
>>
>> We have just released Go 1.11.5 and Go 1.10.8 to address a recently reported 
>> security issue. We recommend that all users update to one of these releases 
>> (if you’re not sure which, choose Go 1.11.5).
>>
>> This DoS vulnerability in the crypto/elliptic implementations of the P-521 
>> and P-384 elliptic curves may let an attacker craft inputs that consume 
>> excessive amounts of CPU.
>>
>> These inputs might be delivered via TLS handshakes, X.509 certificates, JWT 
>> tokens, ECDH shares or ECDSA signatures. In some cases, if an ECDH private 
>> key is reused more than once, the attack can also lead to key recovery.
>>
>> The issue is CVE-2019-6486 and Go issue golang.org/issue/29903. See the Go 
>> issue for more details.
>>
>> Downloads are available at https://golang.org/dl for all supported platforms.
>>
>> Cheers,
>>
>> Julie (on behalf of the Go team)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Re: What are the reasonable reasons to use pointers?

[andrey mirtchovski]

Incidentally, here's Hoare's proposal for records (structs), and
pointers (references) for Algol 60:

https://archive.computerhistory.org/resources/text/algol/algol_bulletin/A21/P36.HTM

as with most things Hoare has produced, it is very well written and
presents a very good justification for the existence of each. read it
with the frame of mind of a person who has not been exposed to
pointers and structs.

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

Re: [go-nuts] C++ 11 to Golang convertor

[andrey mirtchovski]

> It would sure help if Go had sum types. Has there been any discussion
> of adding these?

one of many, but has links to others: https://github.com/golang/go/issues/19412

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

Re: [go-nuts] Append array to slice of slice behavior puzzles me

[andrey mirtchovski]

this is a case of a variable being reused during a range loop.
essentially k[:] is optimized to something resembling  (a pointer to
the memory location of the backing array) which is appended as such to
the [][]int variable. the next iteration it is the same variable in
memory, however it's pointing to a different backing array. the
address of that variable is added to [][]int again. in order to avoid
this you will have to redeclare k inside the loop to ensure a new
backing array is used when adding to the slice of slices.

maybe the easiest way to explain this is to point you towards this
blog post: https://blog.golang.org/go-slices-usage-and-internals and
to note that the for loop in your example expands/unrolls to something
like this, which breaks what you considered to "work" in your original
example:

a1 := [3]int{1, 2, 3}
a2 := [3]int{4, 5, 6}
a3 := [3]int{7, 8, 9}

s := make([][]int, 0)
a := a1
s = append(s, a[:])
a = a2
s = append(s, a[:])
a = a3
s = append(s, a[:])

fmt.Println(s)
On Wed, Nov 21, 2018 at 2:41 PM Sun Frank  wrote:
>
> Hi guys, I came across some code that surprised me, but I could not figured 
> out why it behave like this,
>
> s := make([][]int, 0)
> a1 := [3]int{1, 2, 3}
> a2 := [3]int{4, 5, 6}
> s = append(s, a1[:])
> s = append(s, a2[:])
> fmt.Println(s)
>
> mp := make(map[[3]int]bool)
> mp[[3]int{1, 2, 3}] = true
> mp[[3]int{4, 5, 6}] = true
> mp[[3]int{7, 8, 9}] = true
> res := make([][]int, 0)
> for k := range mp {
> fmt.Printf("key is %+v\n", k[:])
> res = append(res, k[:])
> fmt.Printf("after append: %+v\n", res)
> }
>
>  or on playground
>
> the output is:
>
> [[1 2 3] [4 5 6]]   // this is as expected
> key is [1 2 3]
> after append: [[1 2 3]]
> key is [4 5 6]
> after append: [[4 5 6] [4 5 6]]  // Why it get this not [[1 2 3] [4 5 6]]
> key is [7 8 9]
> after append: [[7 8 9] [7 8 9] [7 8 9]] // why even this?
>
>
> any thoughts?
>
>
> 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.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Memory limits

[andrey mirtchovski]

The 512GB heap limit was removed in go 1.11. Here's the commit that
did it, it has some additional information:

https://github.com/golang/go/commit/2b415549b813ba36caafa34fc34d72e47ee8335c

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

Re: [go-nuts] Re: invalid months and years in time package

[andrey mirtchovski]

as https://golang.org/pkg/time/#Date says:

The month, day, hour, min, sec, and nsec values may be outside their
usual ranges and will be normalized during the conversion. For
example, October 32 converts to November 1.
On Tue, Oct 23, 2018 at 3:12 PM  wrote:
>
> If you check the source code for the time.Date() function, you'll find that 
> it does indeed normalize the date by calling a private 'norm' function.
>
> So, if you enter a month of 13, it will overflow into January of the 
> following year.
>
> My guess is that they thought this was a better solution than returning an 
> error. It's also a convenient way to adjust a date (forwards or backwards) at 
> the same time as you initialize it.
>
> Alan
>
> On Tuesday, October 23, 2018 at 9:20:29 PM UTC+1, Taras D wrote:
>>
>> Yes sorry -1 is a valid year.
>>
>> An invalid month is any integer outside of [1,12]. We can always define 
>> month 13 as January if we adopt Z_12, but I expected an error to occur. 
>> Accepting months outside of [1,12] violates the Principle of least 
>> astonishment.
>>
>> For comparison, python verifies the month integer:
>>
>> > 1 datetime.date(2000, 13, 1)
>> ValueError: month must be in 1..12
>>
>>
>> So does golang accept these values because:
>> - a sensible definition exists for values outside of [1,12]?
>> - for performance reasons?
>>
>> Taras
>>
>> On Wednesday, 24 October 2018 01:23:35 UTC+11, Volker Dobler wrote:
>>>
>>> Why is year -1 invalid and what is an "invalid" month
>>> given that 13==1 in Z_12?
>>>
>>> V.
>>>
>>>
>>>
>>> On Tuesday, 23 October 2018 16:01:00 UTC+2, Taras D wrote:

 Hi,

 I was surprised to find the following worked without any reported errors:

 t1 := time.Date(-1, 1, 10, 23, 0, 0, 0, time.UTC) // invalid year
 t2 := time.Date(2000, 13, 10, 23, 0, 0, 0, time.UTC) // invalid month
 m := time.Month(13) // invalid month

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

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

Re: [go-nuts] Go language should become an ANSI and ISO standard.

[andrey mirtchovski]

> JavaScript needs a standard - there are many implementations and browsers. 
> For the moment, there is only one Go, and I like that.

one go, but two reference implementation. any other implementation is
expected to conscribe to the spec.

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

Re: [go-nuts] Understanding the doc (why can't I?)

[andrey mirtchovski]

> Unlikely :-)
>
> The following is much less obscure.
>
> func Shuffle(slice inteface{})
>
> & might have more more sense. e.g.
>
> var cards []card
> ...
> rand.Shuffle(cards)

you've now restricted Shuffle to "shuffling" only slices. and it has
to examine interface{} to determine if it's "shuffle-able". calling
Shuffle(nil) in your example would still not do anything (which is one
of the original issues of OP).  i posit that the current shuffle makes
good sense given the language. metaphysics notwithstanding.

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

Re: [go-nuts] Understanding the doc (why can't I?)

[andrey mirtchovski]

> May be it ought to be called FYShuffle?

then we'ld have to rename it if we switched the algorithm (which has
happened once for sort.Sort already). that's not what go is about :)

maybe you're advocating for implementing a Shuffle interface, which
brings us round about to where we are right now :)

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

Re: [go-nuts] Re: Understanding the doc (why can't I?)

[andrey mirtchovski]

> Well, ok. But I would call “Shuffle” a misleading misnomer, because until the 
> user defines a shuffler function (which perversely might not, or might fail 
> to, shuffle anything), it does not shuffle anything.

how would you implement shuffle in golang so that it's not a
misleading misnomer? i would presume that you would give Shuffle a
slice and expect it to return it shuffled? but then if the slice is
empty, Shuffle has still not shuffled anything :)

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

Re: [go-nuts] Go fonts for linux (plan9port) acme?

[andrey mirtchovski]

on mac (and I suppose linux too) you can use fontsrv to extract the
plan 9 font files as acme sees them. on my mac I did:

$ fontsrv -m font
$ acme -f font/GoMono/12a/font

here are screenshots of GoRegular and GoMono in 12a:

https://imgur.com/a/7xnGrmx

I will send you privately a tar of GoMono/12a which can be used
directly with acme.

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

[go-nuts] The benefits and costs of writing a POSIX kernel in a high-level language

[andrey mirtchovski]

I do not think this has been shared yet, please accept my apologies if
this is a repeat.

https://www.usenix.org/conference/osdi18/presentation/cutler

The paper contributes Biscuit, a kernel written in Go that implements
enough of POSIX (virtual memory, mmap, TCP/IP sockets, a logging file
system, poll, etc.) to execute significant applications. Biscuit makes
liberal use of Go's HLL features (closures, channels, maps,
interfaces, garbage collected heap allocation), which subjectively
made programming easier. The most challenging puzzle was handling the
possibility of running out of kernel heap memory; Biscuit benefited
from the analyzability of Go source to address this challenge.

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

Re: [go-nuts] Interaction of signals with defer

[andrey mirtchovski]

thank you. i will definitely consider this in the future!
On Tue, Sep 18, 2018 at 8:29 PM Dave Cheney  wrote:
>
> profile.Start() installs a ^C handler to try to make sure profiles are 
> properly flushed to disk before your process goes to the bit bucket in the 
> sky.
>
> > On 19 Sep 2018, at 12:23, andrey mirtchovski  wrote:
> >
> > you're talking about https://github.com/pkg/profile, presumably. while
> > i did find that fairly quickly and it appears to be very useful, it
> > wasn't immediately obvious that it would solve my particular issue.
> > unfortunately we're also averse to importing third-party packages
> > without additional vetting. i ended up using the http/pprof package
> > from the stdlib which gave me what i wanted.
> >> On Tue, Sep 18, 2018 at 7:55 PM Dave Cheney  wrote:
> >>
> >> pkg /profile will do the paperwork for you so ^C works when profiling.
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups 
> >> "golang-nuts" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an 
> >> email to golang-nuts+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Interaction of signals with defer

[andrey mirtchovski]

you're talking about https://github.com/pkg/profile, presumably. while
i did find that fairly quickly and it appears to be very useful, it
wasn't immediately obvious that it would solve my particular issue.
unfortunately we're also averse to importing third-party packages
without additional vetting. i ended up using the http/pprof package
from the stdlib which gave me what i wanted.
On Tue, Sep 18, 2018 at 7:55 PM Dave Cheney  wrote:
>
> pkg /profile will do the paperwork for you so ^C works when profiling.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Interaction of signals with defer

[andrey mirtchovski]

> It's a plausible mistake from any old Unix hand, I think.

anecdotally, i ran into this very same issue yesterday when trying to
instrument a 1.10 go program that allocated (but never used) more than
512 gigabytes of memory. i put in the memprofile saving code as a
deferred closure in main and hit ctrl+C at the crucial moment
expecting a memory profile to be generated, only to see nothing :)

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

Re: [go-nuts] Re: Go’s runtime vs virtual machine

[andrey mirtchovski]

> most languages offer programs at least some operating system like services 
> via a runtime service layer
> -> in C, this was initially "crt0" the thin c runtime
> -> in Go, the service layer is richer, offering thread management and 
> goroutine multiplexing, garbage collection, and more.
>
> the Go runtime is written in Go mostly and uses C or assembler to connect to 
> the host operating system.
> the Go runtime is linked with the developer's Go code, and the two of them 
> are constitute the output of go build or go install

I would add that, unlike VMs simulating CPUs, there can't be a
matryoshka-doll infinity of Go runtimes resting on other Go runtimes.
There is just one, which interfaces with the underlying OS directly.

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

Re: [go-nuts] Run a method with nil pointer

[andrey mirtchovski]

Plenty of previous discussions on the subject. Here's an example from 2012:

https://groups.google.com/d/msg/golang-nuts/wcrZ3P1zeAk/KaR68a8rROEJ

 I don't think reasoning has changed.
On Mon, Sep 3, 2018 at 10:38 PM Dat Huynh  wrote:
>
> Just a question.
>
> Why does Go allow to call a method with a nil pointer?
>
> https://play.golang.org/p/xPehesnfK9b
>
> Thanks,
> Dat.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Re: function's argument default value

[andrey mirtchovski]

> You're right but I think developers of Go can think about that because its 
> benefits are obvious.

can you please enumerate those benefits? many gophers are not
convinced they are obvious.

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

Re: [go-nuts] Limit goroutine resource usage?

[andrey mirtchovski]

it seems from your suggested solutions that you're concerned about cpu
usage. does the goroutine communicate with anything? you can limit its
resources by feeding it less data (via a limiter goroutine) or by
editing it itself do less work (via editing the code)? there is
nothing inherently needed from the operating system to throttle it, it
can all be done via go communication patterns. for example we often
limit how much work can be done by using a n-sized buffered channel
that ensures only n items are processed at a certain time.
On Wed, Aug 15, 2018 at 9:29 PM Olivia Nelson
 wrote:
>
> I'm trying to limit the CPU usage of a goroutine. Is there anything like 
> SuspendThread on windows and SIGSTOP/SIGCONTINUE on linux?
>
> I'm not sure if it's possible.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] C.malloc of Go type?

[andrey mirtchovski]

also useful if you're dealing with blobs of C memory:

https://utcc.utoronto.ca/~cks/space/blog/programming/GoCGoCompatibleStructs

On Sat, May 19, 2018 at 3:03 PM, Jan Mercl <0xj...@gmail.com> wrote:

>
> On Sat, May 19, 2018 at 10:42 PM Max 
> wrote:
>
> > The question is: is it allowed to take the unsafe.Pointer returned by
> C.malloc() and convert it to a pointer to a Go struct type?
>
> See https://golang.org/pkg/unsafe/#Pointer
> --
>
> -j
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] panic: runtime: unknown pc

[andrey mirtchovski]

It is unfortunately not reproducible. I got 2 crashes out of 500
million executions. I've updated to tip and have not seen it since.

On Fri, May 4, 2018 at 12:14 PM, Ian Lance Taylor <i...@golang.org> wrote:
> On Thu, May 3, 2018 at 11:39 PM, andrey mirtchovski
> <mirtchov...@gmail.com> wrote:
>>
>> I believe I've never encountered this nor seen anyone mention this
>> error before. It occurred while fuzzing a C library that we interface
>> with:
>>
>> PC=0x7fffbafc847c m=0 sigcode=0
>>
>> goroutine 0 [idle]:
>> runtime: unknown pc 0x7fffbafc847c
>> stack: frame={sp:0x7fff5fbff088, fp:0x0} 
>> stack=[0x7fff5fb80888,0x7fff5fbff8f0)
>>
>> registers:
>>
>> rax0x200018d
>> rbx0x7fffc3d971a8
>> rcx0x7fff5fbff088
>> rdx0x4000
>> rdi0x1
>> rsi0x4801000
>> rbp0x7fff5fbff0b0
>> rsp0x7fff5fbff088
>> r8 0x6
>> r9 0x7fffbaf18a50
>> r100x72
>> r110x246
>> r120x0
>> r130x7
>> r140x4000
>> r150x4801000
>> rip0x7fffbafc847c
>> rflags 0x246
>> cs 0x7
>> fs 0x0
>> gs 0x0
>>
>> [full stack trace available upon request, it starts/ends with "cgocall"]
>>
>> i'm not sure even how to approach this. would that be a runtime issue?
>> if you have any hints i'd be happy to listen :)
>
> This is a runtime issue.  Note that there have been some fixes for
> this on tip.  If you have reproduction instructions, please open an
> issue.  Thanks.
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

[andrey mirtchovski]

> math.Pow does not give as precise answers as the C++ std lib.

math pow doesn't just multiply X by itself Y times, it uses a
different algorithm:

https://golang.org/src/math/pow.go#L40

it would perhaps make sense to quantify the error margins that this
algorithm introduces.

not sure what c++ stdlib does.

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

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

[andrey mirtchovski]

every time float accuracy is mentioned i think of this:

http://0.30004.com/

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

Re: [go-nuts] [ANN] oksvg and rasterx; SVG 2.0 path compliant renderer and rasterizer

[andrey mirtchovski]

> I’d have thought the case would be the same with the AGPL.

https://opensource.google.com/docs/using/agpl-policy/

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

Re: [go-nuts] Why does the parallel version of a program runs slower?

[andrey mirtchovski]

In short, your concurrency is too fine-grained. Adding concurrency
primitives requires locking which is expensive, and creating a lot of
goroutines does consume resources, even if we consider it relatively
cheap.

If you slice the problem slightly differently it can be made faster:
one goroutine per number, but each goroutine calculates its number the
"normal" way, without using concurrency:

https://play.golang.org/p/lKYSbuK79sB

$ time ./tt 20 > /dev/null # new code

real 0m3.374s
user 0m5.129s
sys 0m0.016s

$ time ./t 20 > /dev/null # your original non-concurrent program

real 0m4.593s
user 0m4.538s
sys 0m0.019s



On Mon, Apr 16, 2018 at 9:09 AM, Tashi Lu  wrote:
> Hi all,
>
> As a newbie I tried to implement a simple program calculating the Catalan
> numbers, which are the numbers satisfying the recursion equation c(1) = 1;
> c(n) = c(n - 1) * c(1) + c(n - 2) * c(2) + ... c(1) * c(n).
>
> At first, I implemented it without channels:
> package main
>
> import (
> "fmt"
> "os"
> "strconv"
> )
>
> func catalan(n int) int {
> if n == 1 {
> return 1
> }
> res := 0
> for i := 1; i < n; i++ {
> res += catalan(n - i) * catalan(i)
> }
> return res
> }
>
> func main() {
> n, _ := strconv.Atoi(os.Args[1])
> for i := 1; i <= n; i++ {
> fmt.Println(catalan(i))
> }
> }
>
>
> Then I thought the calculation can be easily made concurrent, so I wrote the
> version below:
> package main
>
> import (
> "fmt"
> "os"
> "strconv"
> )
>
> func catalan(n int, ch chan int) {
> if n == 1 {
> ch <- 1
> return
> }
> res := 0
> for i := 1; i < n; i++ {
> ch1 := make(chan int)
> ch2 := make(chan int)
> go catalan(n - i, ch1)
> go catalan(i, ch2)
> res += <-ch1 * <-ch2
> close(ch1)
> close(ch2)
> }
> ch <- res
> }
>
> func main() {
> n, _ := strconv.Atoi(os.Args[1])
> for i := 1; i <= n; i++ {
> q := make(chan int)
> go catalan(i, q)
> fmt.Println(<-q)
> close(q)
> }
> }
>
>
> But I found the second version was unexpectly slower than the first:
> go run catalan.go 15  0.07s user 0.66s system 257% cpu 0.281 total
> vs
> go run catalan-parallel.go 15  3.80s user 0.97s system 130% cpu 3.662 total
>
> What's the reason behind this? How can I improve this concurrent version to
> make it faster?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Re: latest go examples

[andrey mirtchovski]

If you're looking for general examples of modern Go, perhaps the
JustForFunc series will be of interest:

https://www.youtube.com/channel/UC_BzFbxG2za3bp5NRRRXJSw

On Fri, Apr 13, 2018 at 10:28 AM, JM  wrote:
> thanks. I run a software engineering team so I've been less hands-on lately
> and want to get back into keeping my skills current.
>
>
> On Friday, April 13, 2018 at 10:14:08 AM UTC-6, JM wrote:
>>
>> Where can I find some examples of using go that uses the latest releases?
>> I went to golang.org but still looking. I am aware of gobyexample.com but
>> not sure if it's kept updated as new builds are released.
>> 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.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] latest go examples

[andrey mirtchovski]

Due to Go's compatibility promise most example code written since Go
1.0 should still be relevant, will compile, and will run. Libraries
have grown since 1.0 as our understanding of how to write Go code
improves (context.Context is one such innovation), but the examples in
the documentation are kept up to date and new ones are added with new
library functions when necessary.

Are you looking for something specific? If you're just curious about
"modern go" you can read any of the latest blog posts both from the go
team and externally, as well as numerous conference talks.

On Fri, Apr 13, 2018 at 10:14 AM, JM  wrote:
> Where can I find some examples of using go that uses the latest releases? I
> went to golang.org but still looking. I am aware of gobyexample.com but not
> sure if it's kept updated as new builds are released.
> 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.
> For more options, visit https://groups.google.com/d/optout.

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