Re: [go-nuts] Hashing (u)int8

[Daniel Skinner]

It's surprising but it's not. Who would have guessed 8bits would be more
expensive on a 64bit platform.

On Fri, Dec 16, 2016 at 11:15 PM Damian Gryski  wrote:

> The runtime has optimized map implementations for strings, int32 and
> int64-sized thing
>
> There is no optimized implementation for int8-sized things -- just use an
> array.
>
> Damian
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] Hashing (u)int8

[Damian Gryski]

The runtime has optimized map implementations for strings, int32 and 
int64-sized thing

There is no optimized implementation for int8-sized things -- just use an array.

Damian

-- 
You received this message because you 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] Hashing (u)int8

[Ayan George]

On 12/16/2016 07:01 PM, Ondrej wrote:
> Hey,
> I had int as a key in my map and later realised I only used 100 or so
> values, so swapped it for a uint8, expecting a minor speed increase, but
> saw a major slowdown instead. To recreate this, I tried this simple
> microbenchmark and was surprised by the difference between (u)int8/16
> and int/int32/int64.
> 
> https://play.golang.org/p/RxmtASRiS4
> 
> In my actual code I have the key in a slice, so I expected []uint8 to be
> more cache friendly than []int, but I guess any potential cache
> friendliness was outweighed by this hashing performance difference.
> 

It looks like any type that isn't the size of a word is slower.
Probably due to all sort of masking and maybe shifting it has to do.

-ayan

-- 
You received this message because you 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] Hashing (u)int8

[Ondrej]

Hey,
I had int as a key in my map and later realised I only used 100 or so 
values, so swapped it for a uint8, expecting a minor speed increase, but 
saw a major slowdown instead. To recreate this, I tried this simple 
microbenchmark and was surprised by the difference between (u)int8/16 and 
int/int32/int64.

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

In my actual code I have the key in a slice, so I expected []uint8 to be 
more cache friendly than []int, but I guess any potential cache 
friendliness was outweighed by this hashing performance difference.

Thanks for any info on 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Announcing Gogland – Brand New Go IDE from JetBrains

[Peter Gloor]

This sounds very promising. After I've been using Eclipse and Visual Studio 
for ages I feared to use any complicated IDE for Go and solely used simple 
editors and LiteIDE for my Go projects. The more I had to deal with web 
projects the more I've been missing an IDE that IDEAlly fills the gap. 

Recently I discovered WebStorm and installed the Go plugin at the same 
time. That said, I'm fairly new to JetBrains products. However, while I've 
got excited about WebStorm I could not really get warm with the Go part. 
 What I read now sounds very exciting. I'd love to take part in Beta 
testing and provide feedback.

Am Donnerstag, 15. Dezember 2016 15:28:40 UTC+1 schrieb Florin Pățan:

> Hi all,
>
>
> I'm very excited to announce a new episode in the life of the Go plugin 
> for IntelliJ.
>
>
> About three years ago, Sergey Ignatov and Alexander Zolotov started a 
> major rewrite of the plugin that took it to a working state. Since then 
> they've made more than 3000 commits, working day and night and even 
> weekends to make sure that Go programmers have a good experience with the 
> existing plugin.
>
>
> Back then, the plugin had little over 80K downloads. Now it’s got more 
> than 640K downloads, the Go community is growing at an impressive rate, and 
> there’s a high demand for a better developer experience compared to 
> everything else available. Noting all this, JetBrains has decided to put 
> its full support behind it and create a world class editor which will 
> deliver the same quality and functionality that you may be familiar with in 
> their other IDEs like IntelliJ IDEA, PyCharm, etc.
>
>
> Today, they've just announced their new dedicated Go IDE codenamed 
> Gogland, which picks up where the open-source plugin left off and 
> introduces a number of changes with many many more to come.
>
>
> To name a few of these exciting new features:
>
> - type comparison features
>
>  - go to inheritor structures
>
>  - go to super interfaces
>
>  - type based "smart completion"
>
> - extract function refactoring
>
> - built-in formatter equal to gofmt
>
> - sub-tests support (running, navigation, gutters)
>
> - tests debugging
>
> - semantic highlighting and parameter name hints
>
> - more Inspections and Quickfixes
>
>
> The IDE is currently in private beta and while it's under heavy 
> development, it's already in a very good shape. On my current setup, with a 
> GOPATH of over 7 GB of Go sources only, it takes about 5 minutes to have it 
> fully indexed (a one-time operation). The IDE starts in less than 10 
> seconds with the project ready to be edited.
>
>
> If you wish to become an early adopter of the IDE or get more information 
> about it, please go to its dedicated page, https://www.jetbrains.com/go/. 
> You also have a chance to give the final name for the IDE, so I encourage 
> you to join in.
>
>
> Finally, I'd like to thank Sergey and Alexander and all the other 
> contributors for all their hard work on this. It's been wonderful to work 
> with them on this project.
>
>
> Kind regards,
> Florin
>

-- 
You received this message because you 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: How to report about app crash to the monitoring server?

[Maksim Sitnikov]

Thanks for mentioning panicwrap. They've added forwardable signal recently, 
which I certainly need to be able to exit from the app by sending TERM to 
the parent process. But I think there some errors in implementation. I 
mentioned them here 
https://github.com/mitchellh/panicwrap/commit/ba9e1a65e0f7975f055d50a2c0201c50d941c24c
 
.


On Thursday, December 15, 2016 at 6:12:13 PM UTC+4, mhh...@gmail.com wrote:
>
> hi,
>
> https://github.com/mitchellh/panicwrap ?
> https://github.com/mitchellh/panicwrap/blob/master/panicwrap.go#L145
>
> to go a little further,
> https://github.com/mh-cbon/report-panic/blob/master/demo/demo.go#L12 ?
>
>
>
> On Thursday, December 15, 2016 at 11:08:34 AM UTC+1, Maksim Sitnikov wrote:
>>
>>
>> On Thursday, December 15, 2016 at 12:23:48 PM UTC+4, Dave Cheney wrote:
>>>
>>> The stack trace is written to stderr, export GOTRACEBACK=all if you want 
>>> a stack trace of all goroutines not just the one that faulted.
>>
>>
>> Thanks you. Yes,  it is. But how can I send it? App crashes when there is 
>> a panic in any goroutine. And I can't control creation of all goroutines. 
>> Is there any solution?
>>
>

-- 
You received this message because you 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: Upgraded to Go 1.8beta2 and now Atom go-plus isn't working

[Damian Gryski]

On Friday, December 16, 2016 at 4:36:24 PM UTC+1, kcr...@sessionm.com wrote:
>
> I've had some luck across golang version changes by recompiling 
> github.com/nsf/gocode, which I believe go-plus uses for autocompletion.
>

Also https://github.com/mdempsky/gocode which is a cleaned up version using 
the new go/* packages for improved compatiblity/stability.

Damian

-- 
You received this message because you 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] plugins and package main

[David Norton]

Hopefully in 1.9 then. Created issue #18350 
. Thanks, Ian.

On Friday, December 16, 2016 at 12:07:33 PM UTC-5, Ian Lance Taylor wrote:
>
> On Fri, Dec 16, 2016 at 8:32 AM, David Norton  > wrote: 
> > Any chance this could make it into 1.8? 
>
> No.  Sorry. 
>
> Ian 
>
> > On Friday, December 16, 2016 at 11:24:26 AM UTC-5, Ian Lance Taylor 
> wrote: 
> >> 
> >> On Fri, Dec 16, 2016 at 8:15 AM, David Norton  
> wrote: 
> >> > Or, maybe tell the go tool which package to consider "main" instead 
> of 
> >> > listing all packages. Would that work? 
> >> 
> >> I didn't mean to imply that it is necessary to list every package in 
> >> the plugin.  The plugin would contain those packages plus all packages 
> >> that they import.  Given that, I think your suggestion is equivalent 
> >> to building a plugin by listing a single package. 
> >> 
> >> Ian 
> >> 
> >> > On Friday, December 16, 2016 at 11:12:09 AM UTC-5, Ian Lance Taylor 
> >> > wrote: 
> >> >> 
> >> >> On Fri, Dec 16, 2016 at 8:09 AM, David Norton  
> >> >> wrote: 
> >> >> > We're experimenting with the new plugin package (in go 1.8 beta) 
> in 
> >> >> > telegraf. It would be convenient if plugin code could be in any 
> >> >> > package 
> >> >> > and 
> >> >> > not required to be in "package main". Is that possible? For 
> example, 
> >> >> > if 
> >> >> > we 
> >> >> > wanted a package to allow both the typical static linking and 
> >> >> > building 
> >> >> > as a 
> >> >> > plugin (shared library). Currently, this requires having code for 
> the 
> >> >> > same 
> >> >> > plugin split between different directories, one for the plugin's 
> >> >> > package 
> >> >> > and 
> >> >> > one for package main. 
> >> >> 
> >> >> One could imagine a mode in which the go tool is given a list of 
> >> >> packages to put into the plugin and auto-generates a main package 
> that 
> >> >> imports those packages. 
> >> >> 
> >> >> 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...@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...@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] plugins and package main

[Ian Lance Taylor]

On Fri, Dec 16, 2016 at 8:32 AM, David Norton  wrote:
> Any chance this could make it into 1.8?

No.  Sorry.

Ian

> On Friday, December 16, 2016 at 11:24:26 AM UTC-5, Ian Lance Taylor wrote:
>>
>> On Fri, Dec 16, 2016 at 8:15 AM, David Norton  wrote:
>> > Or, maybe tell the go tool which package to consider "main" instead of
>> > listing all packages. Would that work?
>>
>> I didn't mean to imply that it is necessary to list every package in
>> the plugin.  The plugin would contain those packages plus all packages
>> that they import.  Given that, I think your suggestion is equivalent
>> to building a plugin by listing a single package.
>>
>> Ian
>>
>> > On Friday, December 16, 2016 at 11:12:09 AM UTC-5, Ian Lance Taylor
>> > wrote:
>> >>
>> >> On Fri, Dec 16, 2016 at 8:09 AM, David Norton 
>> >> wrote:
>> >> > We're experimenting with the new plugin package (in go 1.8 beta) in
>> >> > telegraf. It would be convenient if plugin code could be in any
>> >> > package
>> >> > and
>> >> > not required to be in "package main". Is that possible? For example,
>> >> > if
>> >> > we
>> >> > wanted a package to allow both the typical static linking and
>> >> > building
>> >> > as a
>> >> > plugin (shared library). Currently, this requires having code for the
>> >> > same
>> >> > plugin split between different directories, one for the plugin's
>> >> > package
>> >> > and
>> >> > one for package main.
>> >>
>> >> One could imagine a mode in which the go tool is given a list of
>> >> packages to put into the plugin and auto-generates a main package that
>> >> imports those packages.
>> >>
>> >> 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...@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.

-- 
You received this message because you 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] filtering go in memory objects?

[JM]

I am now getting into data processing with go and looking for resources on 
filtering and querying slices and maps.  For example a slice or map of data 
in a in memory cache that will be queried instead of hitting the db.  There 
is a package here https://github.com/ahmetalpbalkan/go-linq but I am 
looking for other sources or references on filtering objects in memory.  I 
am looking for other more performant solutions, or examples of just 
iterating and manually filtering with your own logic and guide lines on the 
fastest way to search in go.

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.

Re: [go-nuts] plugins and package main

[David Norton]

Any chance this could make it into 1.8?

On Friday, December 16, 2016 at 11:24:26 AM UTC-5, Ian Lance Taylor wrote:
>
> On Fri, Dec 16, 2016 at 8:15 AM, David Norton  > wrote: 
> > Or, maybe tell the go tool which package to consider "main" instead of 
> > listing all packages. Would that work? 
>
> I didn't mean to imply that it is necessary to list every package in 
> the plugin.  The plugin would contain those packages plus all packages 
> that they import.  Given that, I think your suggestion is equivalent 
> to building a plugin by listing a single package. 
>
> Ian 
>
> > On Friday, December 16, 2016 at 11:12:09 AM UTC-5, Ian Lance Taylor 
> wrote: 
> >> 
> >> On Fri, Dec 16, 2016 at 8:09 AM, David Norton  
> wrote: 
> >> > We're experimenting with the new plugin package (in go 1.8 beta) in 
> >> > telegraf. It would be convenient if plugin code could be in any 
> package 
> >> > and 
> >> > not required to be in "package main". Is that possible? For example, 
> if 
> >> > we 
> >> > wanted a package to allow both the typical static linking and 
> building 
> >> > as a 
> >> > plugin (shared library). Currently, this requires having code for the 
> >> > same 
> >> > plugin split between different directories, one for the plugin's 
> package 
> >> > and 
> >> > one for package main. 
> >> 
> >> One could imagine a mode in which the go tool is given a list of 
> >> packages to put into the plugin and auto-generates a main package that 
> >> imports those packages. 
> >> 
> >> 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...@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: Go GC time creeping up

[Evan Digby]

Hi Dave,

Just to follow up as I believe we've resolved this issue. 

TL;DR: Ever-growing maps with convoluted logic surrounded by locks lead to 
poor response times.

Your response prompted us to not write off what we had assumed was an 
insignificant increase in heap size (~100mb over 24 hours) by acknowledging 
that it's steady and ever-increasing, which is bad regardless of the rate.

That said, I was a little surprised that the GC STW time for 950mb vs 850mb 
had a 5.5ms increase in our mean response time, even at 35k QPS. That still 
didn't feel like it was "working as designed", so we decided to throw that 
correlation out as a red herring, at least temporarily. 

Once we had freed ourself of that correlation and focused on the increase 
in the heap size that we had at first written off, we found the source of 
the issue. We had 5 maps with a single Lock around their access, and one of 
them was ever-growing (don't judge, it was before my time!). Since one of 
the maps was ever-growing in size (with string keys), the lock took 
progressively longer to release. There were lots of things going on inside 
the lock. I didn't benchmark to find out exactly which aspect of it was 
holding the lock progressively longer. 

Ugh.

Fortunately upon investigation we determined that the ever-growing map 
didn't need to grow forever. There is a clear and logical time and place to 
delete elements. We refactored a bit to remove all but 2 of those maps, 
ensure neither of them grow very large, and put them local to a single 
goroutine. Simplified the logic all around. Signals to add, remove, and 
report on it come in on buffered channels to avoid locks. 

This change has been running for over 48 hours now. The heap/GC increase is 
gone, and so has our progressively increasing response time.

Sweet.

Thanks again!

Evan

On Monday, 12 December 2016 14:36:14 UTC-8, Evan Digby wrote:
>
> Hi Dave,
>
> Thanks for the insight. I'll look further into the heap creep. I'll also 
> try to get together a log of a run past 8 hours over the next day or so on 
> a machine we're not regularly restarting the go process on to see if it 
> shows anything different. 
>
> Thanks again,
>
> Evan
>
> On Monday, 12 December 2016 14:30:45 UTC-8, Dave Cheney wrote:
>>
>> Thanks for posting this. Once your application gets to about 1600-1900mb 
>> goal the GC pauses seem to stabilise at 3.3+3.2. It looks like the anount 
>> of memory in use is creeping up slowly, from around 850 to 950 over the 
>> span of the trace. GC sweep time is proportional to the size of the heap, 
>> so this is expected.
>>
>> On Tuesday, 13 December 2016 09:20:07 UTC+11, Evan Digby wrote:
>>>
>>> Hi Dave,
>>>
>>> Thanks for the reply. Attached is the full GCTRACE for ~8 hours of run. 
>>> I believe it shows the creep, but I'm not terribly familiar with the 
>>> gctrace output. Something that should probably change over the next day or 
>>> so! (my familiarity)
>>>
>>> Starts with:
>>>
>>> gc 1 @0.116s 0%: 0.079+0.69+0.23 ms clock, 0.55+0.33/1.5/0.63+1.6 ms cpu
>>> , 17->18->15 MB, 18 MB goal, 40 P
>>> gc 2 @0.117s 0%: 0.10+1.3+0.52 ms clock, 0.80+0.33/5.5/1.0+4.1 ms cpu, 
>>> 16->21->20 MB, 31 MB goal, 40 P
>>> gc 3 @0.126s 1%: 0.083+5.3+5.5 ms clock, 1.2+0/5.9/6.3+82 ms cpu, 36->49
>>> ->35 MB, 40 MB goal, 40 P
>>> gc 4 @0.230s 1%: 0.090+2.0+0.25 ms clock, 1.5+0.077/7.5/1.4+4.2 ms cpu, 
>>> 39->40->24 MB, 70 MB goal, 40 P
>>> gc 5 @0.271s 1%: 0.065+2.9+0.24 ms clock, 1.1+0.050/20/20+4.4 ms cpu, 38
>>> ->39->31 MB, 49 MB goal, 40 P
>>> gc 6 @0.348s 1%: 0.082+9.9+0.27 ms clock, 2.4+0.10/57/103+8.3 ms cpu, 55
>>> ->56->43 MB, 62 MB goal, 40 P
>>> gc 7 @0.477s 1%: 0.034+17+0.26 ms clock, 1.1+0.057/85/133+8.6 ms cpu, 80
>>> ->83->64 MB, 86 MB goal, 40 P
>>> gc 8 @0.684s 1%: 0.047+41+0.27 ms clock, 1.5+0/123/2.5+8.8 ms cpu, 122->
>>> 123->79 MB, 129 MB goal, 40 P
>>> gc 9 @0.975s 4%: 0.004+0+37 ms clock, 0.14+0/123/2.5+1188 ms cpu, 126->
>>> 126->107 MB, 126 MB goal, 40 P (forced)
>>> gc 10 @1.071s 4%: 0.035+61+0.26 ms clock, 1.1+17/231/563+8.4 ms cpu, 295
>>> ->295->201 MB, 296 MB goal, 40 P
>>>
>>> Ends with:
>>>
>>> gc 17212 @28778.765s 3%: 3.0+117+3.7 ms clock, 96+1582/1042/546+118 ms 
>>> cpu, 1792->1802->924 MB, 1837 MB goal, 40 P 
>>> gc 17213 @28780.258s 3%: 2.6+119+4.1 ms clock, 83+1544/996/539+133 ms 
>>> cpu, 1803->1815->929 MB, 1848 MB goal, 40 P 
>>> gc 17214 @28781.711s 3%: 2.9+142+3.7 ms clock, 94+1588/1088/370+121 ms 
>>> cpu, 1812->1825->936 MB, 1858 MB goal, 40 P 
>>> gc 17215 @28783.094s 3%: 3.2+107+3.3 ms clock, 104+1723/1061/452+108 ms 
>>> cpu, 1827->1838->945 MB, 1873 MB goal, 40 P 
>>> gc 17216 @28784.500s 3%: 3.0+98+2.9 ms clock, 96+1652/943/463+95 ms cpu, 
>>> 1844->1854->947 MB, 1891 MB goal, 40 P 
>>> gc 17217 @28785.928s 3%: 2.7+118+3.4 ms clock, 87+1558/991/451+110 ms 
>>> cpu, 1848->1861->948 MB, 1895 MB goal, 40 P 
>>> gc 17218 @28787.284s 3%: 2.8+115+4.2 ms clock, 91+1588/932/461+135 ms 
>>> cpu, 1850->1862->960 MB, 1897 MB goal, 40 P 
>>

Re: [go-nuts] [ANN] browse

['Alan Donovan' via golang-nuts]

Correction: https://github.com/golang/go/issues/18348

On 16 December 2016 at 11:29, Alan Donovan  wrote:

> On 16 December 2016 at 11:01, Jan Mercl <0xj...@gmail.com> wrote:
>
>> go/{scanner ,parser} speed is okay.
>> It's problem is that it does not scale well in parallel execution when
>> there's a shared token.FileSet.
>>
>
> That's a good point.  I measured the benefit of fine-grained locking and
> it's compelling; see https://github.com/golang/go/issues/1834.
>

-- 
You received this message because you 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] browse

['Alan Donovan' via golang-nuts]

On 16 December 2016 at 11:01, Jan Mercl <0xj...@gmail.com> wrote:

> go/{scanner ,parser} speed is okay.
> It's problem is that it does not scale well in parallel execution when
> there's a shared token.FileSet.
>

That's a good point.  I measured the benefit of fine-grained locking and
it's compelling; see https://github.com/golang/go/issues/1834.

-- 
You received this message because you 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] plugins and package main

[Ian Lance Taylor]

On Fri, Dec 16, 2016 at 8:15 AM, David Norton  wrote:
> Or, maybe tell the go tool which package to consider "main" instead of
> listing all packages. Would that work?

I didn't mean to imply that it is necessary to list every package in
the plugin.  The plugin would contain those packages plus all packages
that they import.  Given that, I think your suggestion is equivalent
to building a plugin by listing a single package.

Ian

> On Friday, December 16, 2016 at 11:12:09 AM UTC-5, Ian Lance Taylor wrote:
>>
>> On Fri, Dec 16, 2016 at 8:09 AM, David Norton  wrote:
>> > We're experimenting with the new plugin package (in go 1.8 beta) in
>> > telegraf. It would be convenient if plugin code could be in any package
>> > and
>> > not required to be in "package main". Is that possible? For example, if
>> > we
>> > wanted a package to allow both the typical static linking and building
>> > as a
>> > plugin (shared library). Currently, this requires having code for the
>> > same
>> > plugin split between different directories, one for the plugin's package
>> > and
>> > one for package main.
>>
>> One could imagine a mode in which the go tool is given a list of
>> packages to put into the plugin and auto-generates a main package that
>> imports those packages.
>>
>> 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.

-- 
You received this message because you 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] plugins and package main

[David Norton]

Or, maybe tell the go tool which package to consider "main" instead of 
listing all packages. Would that work?

On Friday, December 16, 2016 at 11:12:09 AM UTC-5, Ian Lance Taylor wrote:
>
> On Fri, Dec 16, 2016 at 8:09 AM, David Norton  > wrote: 
> > We're experimenting with the new plugin package (in go 1.8 beta) in 
> > telegraf. It would be convenient if plugin code could be in any package 
> and 
> > not required to be in "package main". Is that possible? For example, if 
> we 
> > wanted a package to allow both the typical static linking and building 
> as a 
> > plugin (shared library). Currently, this requires having code for the 
> same 
> > plugin split between different directories, one for the plugin's package 
> and 
> > one for package main. 
>
> One could imagine a mode in which the go tool is given a list of 
> packages to put into the plugin and auto-generates a main package that 
> imports those packages. 
>
> 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] plugins and package main

[Ian Lance Taylor]

On Fri, Dec 16, 2016 at 8:09 AM, David Norton  wrote:
> We're experimenting with the new plugin package (in go 1.8 beta) in
> telegraf. It would be convenient if plugin code could be in any package and
> not required to be in "package main". Is that possible? For example, if we
> wanted a package to allow both the typical static linking and building as a
> plugin (shared library). Currently, this requires having code for the same
> plugin split between different directories, one for the plugin's package and
> one for package main.

One could imagine a mode in which the go tool is given a list of
packages to put into the plugin and auto-generates a main package that
imports those packages.

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.

[go-nuts] plugins and package main

[David Norton]

We're experimenting with the new plugin package (in go 1.8 beta) in telegraf 
. It would be convenient if plugin 
code could be in any package and not required to be in "package main". Is 
that possible? For example, if we wanted a package to allow both the 
typical static linking and building as a plugin (shared library). 
Currently, this requires having code for the same plugin split between 
different directories, one for the plugin's package and one for package 
main.

-- 
You received this message because you 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] browse

[Jan Mercl]

On Fri, Dec 16, 2016 at 4:27 PM adonovan via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> ssadump is loading, cgo-preprocessing, parsing, and type-checking the
entire transitive closure of source files required by the current package,
then building its SSA representation in a second pass, so these
measurements are not at all comparable.

I did not meant any unfair comparison, I just trusted what you wrote
earlier in a different thread ;-)



On Tue, Dec 13, 2016 at 3:49 PM adonovan via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> For example, with no flags, ssadump simply type-checks the specified
packages:
>
> $ go get golang.org/x/tools/cmd/ssadump
> $ cat a.go
> package main
> var x int = "string"
> $ ssadump a.go
> a.go:2:13: cannot convert "string" (untyped string constant) to int

That's why I used it as a base line



> Two other data points:
> ...

> then it loads that package and its dependencies from source in under
700ms.

Nice.

> 2) The golang.org/x/tools/cmd/gotype tool, which loads only a single
package from source, and loads export data for all imports, can process
that package in under 100ms.

I wanted to be independent of .a files. I agree with what you have
mentioned in the other thread - they are non reliable to be up to date.

> The go/parser is plenty fast enough.  ssadump may be the wrong starting
point for how to use it, though.

go/{scanner,parser} speed is okay. It's problem is that it does not scale
well in parallel execution when there's a shared token.FileSet. That's the
reason for internal/ftoken (locks on .File(), but the the returned *File
methods do no more locking whatsoever):

jnml@r550:~/src/github.com/cznic/browse/internal/gc$ go version
go version go1.7.4 linux/amd64
jnml@r550:~/src/github.com/cznic/browse/internal/gc$ go test -bench
.
BenchmarkScanner/StdGo-4  10 173466122 ns/op  41.53 MB/s
BenchmarkScanner/Std-430  37032476 ns/op 194.52 MB/s
BenchmarkParser/StdGo-4 5 275074432 ns/op  26.19
MB/s
BenchmarkParser/Std-4  10 138686331 ns/op  51.94
MB/s
PASS
ok   github.com/cznic/browse/internal/gc 15.725s
jnml@r550:~/src/github.com/cznic/browse/internal/gc$

Again, the comparison is not completely fair, go/{scanner/parser} does more
than this internal stuff is doing. At least as of now.

-- 

-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.

[go-nuts] Native messaging host library

[Sol]

After working on a native messaging host application for chrome and Firefox, I 
thought some might find it useful if I extracted the messaging part into 
library.
https://github.com/qrtz/nativemessaging
Your feedback is very much welcomed 

-- 
You received this message because you 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 is the role of -buildid?

[Ian Lance Taylor]

On Fri, Dec 16, 2016 at 2:04 AM,   wrote:
> When I run go build -x, I find that this are -buildid flags in the actual
> compile and link commands. What is it for?

See the long comment before the function isStale in cmd/go/pkg.go.

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.

[go-nuts] Re: Upgraded to Go 1.8beta2 and now Atom go-plus isn't working

[kcraig]

I've had some luck across golang version changes by recompiling 
github.com/nsf/gocode, which I believe go-plus uses for autocompletion.

On Friday, December 16, 2016 at 7:14:59 AM UTC-5, Diego Medina wrote:
>
> Hi,
>
> I have seen similar posts to this but I could not find any of them so 
> posting this.
>
> I went ahead and installed the latest beta to try it out, both my apps at 
> work work ok with it (yeah!), but now go-plus in Atom (and the autocomplete 
> plugin) won't autocomplete any more, it just offers "PANIC" as any 
> autcomplete.
>
> 1. What's the proper way to handle this issue.
> 2. Could this be added to the https://golang.org/doc/install page.
>
> When I previously run into this issue, I ended up making a mess of my 
> install, I think I deleted everything in $GOPATH and then one by one 
> started go get'ting everything I needed. I was fine with it because after 
> all, I love using Go, but my co-workers will be less willing to do all the 
> manual work just to get a new version going, so I'm hoping there is a 
> simple step I can tell them to follow to go from one version to the next.
>
> Thanks.
>
> Diego
>

-- 
You received this message because you 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: Installing two go releases side-by-side

[Francisco Souza]

On Fri, Dec 16, 2016 at 7:05 AM, Seb Binet  wrote:
>
>
> On Fri, Dec 16, 2016 at 1:02 PM, Caleb Doxsey  wrote:
>>
>> The easy solution here is gimme.
>>
>>
>> $ eval "$(gimme 1.8beta2)"
>>
>>
>> Downloads and installs go and sets all the environment variables for you.
>
>
> there's also something happening here:
> https://godoc.org/golang.org/x/build/version/go1.8beta1
> https://godoc.org/golang.org/x/build/version/go1.8beta2

gimme doesn't require go to install 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [ANN] browse

[adonovan via golang-nuts]

On Friday, 16 December 2016 06:22:47 UTC-5, Jan Mercl wrote:
>
> > but I am curious: why the need for internal/gc, "a Go compiler front 
> end. Work in progess" ?
> > it seems to be very much alike to go/types (or, rather, a mix of 
> go/types and go/ast).
>
> For example (not completely fair comparison but you get the idea):
>
> jnml@r550:~/src/github.com/cznic/browse$ go install -tags 
> debug.browse && browse
> main.go:162: loaded+xref0: 65 packages in 486.248926ms
> jnml@r550:~/src/github.com/cznic/browse$ time ssadump .
> 
> real 0m2.218s
> user 0m6.588s
> sys 0m0.628s
>

ssadump is loading, cgo-preprocessing, parsing, and type-checking the 
entire transitive closure of source files required by the current package, 
then building its SSA representation in a second pass, so these 
measurements are not at all comparable.  Two other data points:

1) If you modify ssadump to skip cgo preprocessing, type-checking of 
imported function bodies, and SSA construction:

conf.TypeChecker.FakeImportC = true 
conf.TypeCheckFuncBodies = func(path string) bool {
return path == "github.com/cznic/browse"
}
... = conf.Load(...)
return

then it loads that package and its dependencies from source in under 700ms.

2) The golang.org/x/tools/cmd/gotype tool, which loads only a single 
package from source, and loads export data for all imports, can process 
that package in under 100ms.

The go/parser is plenty fast enough.  ssadump may be the wrong starting 
point for how to use it, though.

-- 
You received this message because you 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] "plugin was built with a different version..."

[David Crawshaw]

The design doc predates the proposal repository.
https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit

On Fri, Dec 16, 2016 at 10:08 AM, David Norton  wrote:
> Thanks, David. Also, is there a proposal / design doc for the plugin pkg
> somewhere? I didn't see one in the proposal repo.
>
> On Wednesday, December 14, 2016 at 2:15:32 PM UTC-5, David Crawshaw wrote:
>>
>> The hash is a SHA1 of the package object data, generated by the
>> linker, cmd/link. The hash is created in the function genhash, and
>> placed in the moduledata in the symtab method.
>>
>> Using a hash of the object data means a plugin has to be compiled
>> against exactly the same package as the host binary.
>>
>> On Wed, Dec 14, 2016 at 1:54 PM, Ian Lance Taylor 
>> wrote:
>> > [ +crawshaw ]
>> >
>> > On Wed, Dec 14, 2016 at 9:03 AM, David Norton  wrote:
>> >> I'm trying to better understand how the runtime checks package versions
>> >> when
>> >> using the plugin pkg. If there's a mismatch, the following error occurs
>> >> at
>> >> run time:
>> >>
>> >>> plugin.Open: plugin was built with a different version of package ...
>> >>
>> >>
>> >>  That message originates, in the runtime, here. Where does runtimehash
>> >> get
>> >> set? Maybe someone could give a brief explanation of how version
>> >> checking
>> >> works when using the new plugin pkg?
>> >>
>> >> Thanks,
>> >> David
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "golang-nuts" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to golang-nuts...@googlegroups.com.
>> >> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you 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] "plugin was built with a different version..."

[David Norton]

Thanks, David. Also, is there a proposal / design doc for the plugin pkg 
somewhere? I didn't see one in the proposal repo.

On Wednesday, December 14, 2016 at 2:15:32 PM UTC-5, David Crawshaw wrote:
>
> The hash is a SHA1 of the package object data, generated by the 
> linker, cmd/link. The hash is created in the function genhash, and 
> placed in the moduledata in the symtab method. 
>
> Using a hash of the object data means a plugin has to be compiled 
> against exactly the same package as the host binary. 
>
> On Wed, Dec 14, 2016 at 1:54 PM, Ian Lance Taylor  > wrote: 
> > [ +crawshaw ] 
> > 
> > On Wed, Dec 14, 2016 at 9:03 AM, David Norton  > wrote: 
> >> I'm trying to better understand how the runtime checks package versions 
> when 
> >> using the plugin pkg. If there's a mismatch, the following error occurs 
> at 
> >> run time: 
> >> 
> >>> plugin.Open: plugin was built with a different version of package ... 
> >> 
> >> 
> >>  That message originates, in the runtime, here. Where does runtimehash 
> get 
> >> set? Maybe someone could give a brief explanation of how version 
> checking 
> >> works when using the new plugin pkg? 
> >> 
> >> Thanks, 
> >> David 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> Groups 
> >> "golang-nuts" group. 
> >> To unsubscribe from this group and stop receiving emails from it, send 
> an 
> >> email to golang-nuts...@googlegroups.com . 
> >> For more options, visit https://groups.google.com/d/optout. 
>

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

Re: [go-nuts] Announcing Gogland – Brand New Go IDE from JetBrains

[Daniel Skinner]

Great work, as a long time IntelliJ user for a variety of different
languages I'm excited to see how this Go-centric version turns out. Added
my name to the private beta.

On Thu, Dec 15, 2016 at 8:28 AM Florin Pățan  wrote:

> Hi all,
>
>
> I'm very excited to announce a new episode in the life of the Go plugin
> for IntelliJ.
>
>
> About three years ago, Sergey Ignatov and Alexander Zolotov started a
> major rewrite of the plugin that took it to a working state. Since then
> they've made more than 3000 commits, working day and night and even
> weekends to make sure that Go programmers have a good experience with the
> existing plugin.
>
>
> Back then, the plugin had little over 80K downloads. Now it’s got more
> than 640K downloads, the Go community is growing at an impressive rate, and
> there’s a high demand for a better developer experience compared to
> everything else available. Noting all this, JetBrains has decided to put
> its full support behind it and create a world class editor which will
> deliver the same quality and functionality that you may be familiar with in
> their other IDEs like IntelliJ IDEA, PyCharm, etc.
>
>
> Today, they've just announced their new dedicated Go IDE codenamed
> Gogland, which picks up where the open-source plugin left off and
> introduces a number of changes with many many more to come.
>
>
> To name a few of these exciting new features:
>
> - type comparison features
>
>  - go to inheritor structures
>
>  - go to super interfaces
>
>  - type based "smart completion"
>
> - extract function refactoring
>
> - built-in formatter equal to gofmt
>
> - sub-tests support (running, navigation, gutters)
>
> - tests debugging
>
> - semantic highlighting and parameter name hints
>
> - more Inspections and Quickfixes
>
>
> The IDE is currently in private beta and while it's under heavy
> development, it's already in a very good shape. On my current setup, with a
> GOPATH of over 7 GB of Go sources only, it takes about 5 minutes to have it
> fully indexed (a one-time operation). The IDE starts in less than 10
> seconds with the project ready to be edited.
>
>
> If you wish to become an early adopter of the IDE or get more information
> about it, please go to its dedicated page, https://www.jetbrains.com/go/.
> You also have a chance to give the final name for the IDE, so I encourage
> you to join in.
>
>
> Finally, I'd like to thank Sergey and Alexander and all the other
> contributors for all their hard work on this. It's been wonderful to work
> with them on this project.
>
>
> Kind regards,
> Florin
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] What is the role of -buildid?

[scauyjf]

When I run go build -x, I find that this are -buildid flags in the actual 
compile and link commands. What is it for?

-- 
You received this message because you 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: memclr optimazation does worse?

[rd6137]

Hi Solokov,

interesting idea, but it does not seem that the cache size would be the 
issue at hand here — please note that slices of more than 524288 integers 
do not fit in my laptop cache:

 1. The runtime is linear to the size of the array (no "cliff" — see 
attached picture)

 2. The page misses are ridiculously low (expected since the benchmark 
yields itself to contiguous allocation and processing):

 Performance counter stats for '/usr/local/go/bin/go test -bench=.':

  20882.464799  task-clock (msec) #0.998 CPUs 
utilized  
 4,947  context-switches  #0.237 
K/sec  
   239  cpu-migrations#0.011 
K/sec  
23,583  page-faults   #0.001 
M/sec  
64,142,963,898  cycles#3.072 
GHz
37,246,686,615  instructions  #0.58  insn per 
cycle 
 4,753,144,504  branches  #  227.614 
M/sec  
 2,870,298  branch-misses #0.06% of all 
branches  

I am running the following excerpt from the original code:
package P

import (
"strconv"
"testing"
)

func memclr(a []int) {
for i := range a {
a[i] = 0
}
}

func BenchmarkMemclr(b *testing.B) {
for i := 10; i < 40960; i *= 2 {
b.Run("bench"+strconv.Itoa(i), func(b *testing.B) {
var a = make([]int, i)
b.ResetTimer()
for i := 0; i < b.N; i++ {
memclr(a)
}
})
}
}





-- 
You received this message because you 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] HTTP Client based on middlewares

[bojan . delic]

Hi everybody.

I would like to get some feedback on set of libraries that I wrote. 
Together they are pluggable, middleware-based HTTP client.


Main idea is to replicate pattern from widely used for server 
implementation. We all know (and love) http.Handlerinterface, which is a 
base for bunch of libraries to extend on. I have also defined Handler 
interface, 
but one that receives context.Context and *http.Request and returns 
*http.Response and error. That is the base of the idea. Middlewares simply 
accept Handler and return other Handler. With some utility stuff (like easy 
way for chaining middlewares, simplified interface for writing of 
middlewares that only modify request or only read response), that is full 
description of cliware  library. (Name 
comes from CLIent middleWARE)


Based on cliware, I have written couple of (in my opinion) useful 
middlewares. They are grouped in couple packages in single repository 
. There is support for 
authentication, path, cookie and query parameters manipulation, request and 
response body managing, retry...


On top of all that, as a glue and for nicer interface, I have written 
simple http client. It is called GWC  (Go 
Web Client).


Main idea is to define reusable middlewares that can be applied to client 
(it will be applied to all requests), group (it will be applied to all 
requests that are part of same group) or request (only applied to single 
request). 


This should make writing clients for large APIs easier and should remove a 
lot of boilerplate code.

For full disclosure, I got an idea (and some middlewares implementation) 
from excellent h2non/gentleman  package. 
I was missing context support (gentleman has context, but it is not 
context.Context from standard library) and I had different idea how 
middlewares and composing should be done.


I would really like to get some feedback, either on design, API, 
implementation, anything really.

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.

[go-nuts] Upgraded to Go 1.8beta2 and now Atom go-plus isn't working

[Diego Medina]

Hi,

I have seen similar posts to this but I could not find any of them so 
posting this.

I went ahead and installed the latest beta to try it out, both my apps at 
work work ok with it (yeah!), but now go-plus in Atom (and the autocomplete 
plugin) won't autocomplete any more, it just offers "PANIC" as any 
autcomplete.

1. What's the proper way to handle this issue.
2. Could this be added to the https://golang.org/doc/install page.

When I previously run into this issue, I ended up making a mess of my 
install, I think I deleted everything in $GOPATH and then one by one 
started go get'ting everything I needed. I was fine with it because after 
all, I love using Go, but my co-workers will be less willing to do all the 
manual work just to get a new version going, so I'm hoping there is a 
simple step I can tell them to follow to go from one version to the next.

Thanks.

Diego

-- 
You received this message because you 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: Installing two go releases side-by-side

[Seb Binet]

see: https://go-review.googlesource.com/c/34385/

-s

On Fri, Dec 16, 2016 at 1:05 PM, Seb Binet  wrote:

>
>
> On Fri, Dec 16, 2016 at 1:02 PM, Caleb Doxsey  wrote:
>
>> The easy solution here is gimme .
>>
>>
>> $ eval "$(gimme 1.8beta2)"
>>
>>
>> Downloads and installs go and sets all the environment variables for you.
>>
>
> there's also something happening here:
> https://godoc.org/golang.org/x/build/version/go1.8beta1
> https://godoc.org/golang.org/x/build/version/go1.8beta2
>
> -s
>
>
>>
>> On Wednesday, December 14, 2016 at 11:58:55 AM UTC-5, aind...@gmail.com
>> wrote:
>>>
>>> I currently have the distribution "go version go1.7.1 darwin/amd64"
>>> installed. However, I'd like to test my applications on the 1.8 beta.
>>>
>>>- Is it okay to install another distribution without messing up the
>>>environment variables?
>>>- If I build from source, can I scope the installation to a specific
>>>directory?
>>>- What is the recommended procedure for having multiple
>>>installations side-by-side?
>>>
>>>
>>> Thank You,
>>> Akhil Indurti
>>>
>> --
>> You received this message because you 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: Installing two go releases side-by-side

[Seb Binet]

On Fri, Dec 16, 2016 at 1:02 PM, Caleb Doxsey  wrote:

> The easy solution here is gimme .
>
>
> $ eval "$(gimme 1.8beta2)"
>
>
> Downloads and installs go and sets all the environment variables for you.
>

there's also something happening here:
https://godoc.org/golang.org/x/build/version/go1.8beta1
https://godoc.org/golang.org/x/build/version/go1.8beta2

-s


>
> On Wednesday, December 14, 2016 at 11:58:55 AM UTC-5, aind...@gmail.com
> wrote:
>>
>> I currently have the distribution "go version go1.7.1 darwin/amd64"
>> installed. However, I'd like to test my applications on the 1.8 beta.
>>
>>- Is it okay to install another distribution without messing up the
>>environment variables?
>>- If I build from source, can I scope the installation to a specific
>>directory?
>>- What is the recommended procedure for having multiple installations
>>side-by-side?
>>
>>
>> Thank You,
>> Akhil Indurti
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] Re: Installing two go releases side-by-side

[Caleb Doxsey]

The easy solution here is gimme .


$ eval "$(gimme 1.8beta2)"


Downloads and installs go and sets all the environment variables for you.

On Wednesday, December 14, 2016 at 11:58:55 AM UTC-5, aind...@gmail.com 
wrote:
>
> I currently have the distribution "go version go1.7.1 darwin/amd64" 
> installed. However, I'd like to test my applications on the 1.8 beta. 
>
>- Is it okay to install another distribution without messing up the 
>environment variables?
>- If I build from source, can I scope the installation to a specific 
>directory? 
>- What is the recommended procedure for having multiple installations 
>side-by-side?
>
>
> Thank You,
> Akhil Indurti
>

-- 
You received this message because you 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] browse

[Jan Mercl]

On Fri, Dec 16, 2016 at 10:38 AM Seb Binet  wrote:

> it looks really slick (and I like how one can quickly navigate between
identifiers and go to their definition)

FTR, ctrl-click and middle-click open the target in a new window, like web
bowsers do.

> but I am curious: why the need for internal/gc, "a Go compiler front end.
Work in progess" ?
> it seems to be very much alike to go/types (or, rather, a mix of go/types
and go/ast).

For example (not completely fair comparison but you get the idea):

jnml@r550:~/src/github.com/cznic/browse$ go install -tags
debug.browse && browse
main.go:162: loaded+xref0: 65 packages in 486.248926ms
jnml@r550:~/src/github.com/cznic/browse$ time ssadump .

real 0m2.218s
user 0m6.588s
sys 0m0.628s
jnml@r550:~/src/github.com/cznic/browse$

-- 

-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.

Re: [go-nuts] Debug memory leaks in cgo calls

[Will Newton]

On Thu, Dec 15, 2016 at 12:57 AM, Pablo Rozas Larraondo
 wrote:
> I've seen this question asked before in the mail list but with no clear
> answers. I'm just asking it again in case someone has come up with a new way
> of doing this:
>
> Does anyone know about a good tool or method to detect memory leaks
> happening on C code being called by cgo?

I'm not aware of any really nice tool to do this. clang's memory
sanitizer may work (I think last time I looked the gcc equivalent was
not capable of doing leak detection). You can override the system
malloc with e.g. jemalloc which will give you more debug information
than the system malloc. Unfortunately most allocators leak detection
is done using an atexit handler and I didn't find a nice way to get Go
to run these handlers in my application. It is possible to run
jemalloc in a mode that dumps periodic heap traces to disk which you
can then diff to figure out which parts of the heap are growing.

-- 
You received this message because you 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] Debug memory leaks in cgo calls

[Marko Kevac]

There is an address sanitizer in gcc too.

On Thursday, December 15, 2016 at 10:15:23 PM UTC+3, Pablo Rozas-Larraondo 
wrote:
>
> Thanks Ian,
>
> So if I understand it well, this involves using clang compiler instead of 
> the default gcc when building Go code that uses cgo. I'll do some research 
> on how to do this.
>
> Cheers,
> Pablo
>
> On Wed, Dec 14, 2016 at 5:36 PM, Ian Lance Taylor  > wrote:
>
>> On Wed, Dec 14, 2016 at 4:57 PM, Pablo Rozas Larraondo
>> > wrote:
>> >
>> > I've seen this question asked before in the mail list but with no clear
>> > answers. I'm just asking it again in case someone has come up with a 
>> new way
>> > of doing this:
>> >
>> > Does anyone know about a good tool or method to detect memory leaks
>> > happening on C code being called by cgo?
>>
>> clang's address sanitizer can do memory leak detection.  I have not
>> tried that with Go myself, but I suggest starting with that to see if
>> you can make it work.
>>
>> 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] [ANN] browse

[Seb Binet]

On Fri, Dec 16, 2016 at 2:07 AM, Jan Mercl <0xj...@gmail.com> wrote:

> https://github.com/cznic/browse
>
> Browse packages in the terminal. The "rough at the edges" release.
>

it looks really slick (and I like how one can quickly navigate between
identifiers and go to their definition)

but I am curious: why the need for internal/gc, "a Go compiler front end.
Work in progess" ?
it seems to be very much alike to go/types (or, rather, a mix of go/types
and go/ast).

-s

PS: it's always very interesting to read your (Go) prose, 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.

[go-nuts] Re: How many bytes binary.Write write before an error?

[Tamás Gulácsi]

2016. december 16., péntek 9:30:41 UTC+1 időpontban Peng Wang a következőt 
írta:
>
> OK, now I actually get it. Just use a CounterWriter and return bytes num 
> it receives.
> Such writer already exists in the std lib?
>
>
No, as that's only 9 lines of code, as I've written previously.

-- 
You received this message because you 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: How many bytes binary.Write write before an error?

[Peng Wang]

OK, now I actually get it. Just use a CounterWriter and return bytes num it 
receives.
Such writer already exists in the std lib?

在 2016年12月16日星期五 UTC+8下午2:10:41，P Q写道：
>
> 2016년 12월 16일 금요일 오전 11시 5분 53초 UTC+9, Peng Wang 님의 말:
> Actually I don't really care about that, just don't want break the 
> interface requirement
> in the doc it says "WriteAt writes len(p) bytes from p to the underlying 
> data stream at offset off. It returns the number of bytes written from p (0 
> <= n <= len(p)) and any error encountered that caused the write to stop 
> early."
> but using binary.Write I lost that infomation. So what's the right way to 
> do it ? or just ignore it and return 0? 
>
> Write should inform the caller of the number of bytes written even though 
> some error happens during the write operation. (
> https://golang.org/pkg/io/#Writer states explicitly). It's recommended 
> for the WriteTo method to return a proper n, not 0.
>
> binary.Write dosen't return how many bytes are written, but not mean you 
> have to miss the information, because binary.Write calls internally to 
> io.Write.
>
> As Tamás Gulácsi says, you can wrap w in countWriter. And if error occurs, 
> examine countWriter.N field to get information about the number of bytes 
> written.
>
> I couldn't understand this wrapping could break the interface 
> requirements. The program you're writing need some even complicated 
> behavior i couldn't guess at?
>

-- 
You received this message because you 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.