[go-nuts] Re: 10x latency spikes during GC alloc assist phase

[stbaker]

OK, I will add to that issue , but for the record here is our machine type 
and the env vars:

This GCP hardware has 64 virtual CPUs (a hyperthread on a 2.6GHz Xeon E5), 
with 416GB memory.  This is shared among other docker containers, of 
course, but as the trace file shows, our process uses 8 CPUs (and around 
16GB memory).  The environment variables of concern are that we set 
GOMAXPROCS to 8, SetGCPercent to 20, and while generating the profiles we 
set GODEBUG=gctrace=1,gcpacertrace=1.  


On Wednesday, July 26, 2017 at 5:56:10 AM UTC-7, r...@golang.org wrote:
>
> I would add to 14812 
> .
>  
> The report should include the environment variables, HW , and RAM. The 
> report should indicate if any environment variables are not set to the 
> default, such as GOGC (SetGCPercent).
>
> On Monday, July 24, 2017 at 8:44:10 PM UTC-4, stb...@laserlike.com wrote:
>>
>> Hi,
>>
>> We are experiencing a problem that I believe may be related to issue 
>> 14812 
>> 
>>  
>> but I wanted to ask here before adding to that case or filing a new issue. 
>> Of course, we’d also greatly appreciate any advice about how to make our 
>> program performant.
>>
>> Here is what we observe: at Laserlike one of our core user-facing 
>> services (the “leaf”) typically responds to a particular rpc in <400ms. 
>>  During GC we see spikes in latency to >5s on some simple requests.  The 
>> stop the world periods are short, so the GC spikes appear to happen at 
>> other times.
>>
>> We have been unable to replicate this in a simple program, but we did run 
>> our code in a test mode that repros it.  In our test environment the server 
>> loads ~10 GB of persistent data (never deleted so doesn’t really need to be 
>> GCed), and we ask for 8 processors.  We are running go version 1.8.3 on 
>> kubernetes on GCP machine of type n1-highmem-64.  To create the problem we 
>> send the server a single request with >500 tasks..
>>
>>
>> This google drive folder has leaf-logs-full.redacted.txt as well as other 
>> performance tooling files 
>> .
>>  
>>  A snippet from that log here shows normal query responses and timing:
>>
>> I0719 22:50:22.467367 leaf.go:363] Worker #5 done search for 
>> '[redacted]', took 0.013 seconds
>>
>> I0719 22:50:22.467406 leaf.go:225] Worker #5 starting search for 
>> '[redacted]'
>>
>> I0719 22:50:22.467486 leaf.go:363] Worker #6 done search for 
>> '[redacted]', took 0.001 seconds
>>
>> I0719 22:50:22.467520 leaf.go:225] Worker #6 starting search for 
>> '[redacted]'
>>
>> I0719 22:50:22.468050 leaf.go:363] Worker #9 done search for 
>> '[redacted]', took 0.005 seconds
>>
>>
>> We have observed that if a GC cycle happens to start while serving 
>> traffic (which is often) AND there is a large amount of time spent in 
>> assist, then our serving latency skyrockets by 10x.  In the log the 
>> slowdown commences roughly when pacer assist starts at I0719 
>> 22:50:31.079283 and then reverts to normal latencies shortly after the gc 
>> cycle completes at I0719 22:50:36.806085.
>>
>> Below I copy parts of the log where we see latencies of up to 729ms on 
>> tasks.  I also bold the line that shows 32929ms spent on alloc gc assist.
>>
>> We have captured an attached cpu profile during this time which seems to 
>> confirm a large amount of time spent in runtime.gcAssistAlloc.func1.
>>
>>
>> Pardon our ignorance about GC in golang, but our hypothesis about what 
>> may be going wrong is that our large in-memory data structures are causing 
>> gc to often go into assist mode, and that for reasons we don’t understand 
>> malloc becomes expensive in that mode.  Since we also create ~100k new data 
>> objects when processing user requests, we are guessing those allocs become 
>> very slow.  Another piece of evidence for this hypothesis is that we have 
>> another (prototype) implementation of this kind of service that makes more 
>> use of object pools and doesn’t seem to have as much of slowdown during GC.
>>
>> Note on large in-memory data-structures:
>>
>> The principal data structures can be thought of as:
>>
>> Map[uint64][]byte (about 10M map entries, the slice lengths between 5K to 
>> 50K) (around ~10G total memory usage) 
>>
>> Map[uint64][]uint64 (about 50M map entries, the slice lengths vary 
>> between 10 and 100K, in a zipfian distribution, about 3G total memory usage)
>>
>> These data structures mostly stay as is over the life of the program.
>>
>> We are trying to figure out how to solve this so would appreciate any 
>> advice. An engineer on our team wrote up the following ideas, none of which 
>> are that great:
>>
>>1. 
>>
>>Figure out a simple way to prevent our 

Re: [go-nuts] Details on the implementation decision for sync.Map

[Lucio]

On Wednesday, 26 July 2017 22:16:50 UTC+2, Ian Lance Taylor wrote:
>
> On Wed, Jul 26, 2017 at 1:07 PM, Florin Pățan  > wrote: 
> > 
> > I would like to understand a bit better one particular implementation 
> > decision regarding the new sync.Map feature. 
> >  [ ... ]
>
> Adding a new complex feature to the language is a high bar.  sync.Map 
> is a somewhat special purpose data structure.  We don't want to add 
> all potentially useful data structures to the language.  Especially 
> not if they can be implemented entirely as a library, even if the 
> resulting library does lose some compile-time type safety. 
>
> With all due respect, I think the sync and context packages are so closely 
coupled to the multitasking nature of Go as to be inseparable from it. I 
understand and really appreciate that decisions such as the above could not 
have been made as  wisely in the early days as is the case now, but I think 
Ian's defence of these decisions is unnecessary and misguided.

I sincerely hope that Go2 will take a page or two from Per Brinch Hansen 
and Edsgar J. Dijkstra and add data protection in the core language. I'm no 
language theoretician and I'm willing to be corrected, but it seems to me 
that applying synchronisation features by default, as well as context 
properties (the former to data structures and the latter to functions) 
could be balanced by code analysis equal or analogous to present day race 
detection to eliminate the unwanted synchronisation baggage at translation 
time.

Rob Pike's wish to keep compilation times down would inevitably suffer, but 
the language's "precision" would gain much. That said, I would not be the 
one to do the work, so I appreciate that such recommendations may be a bit 
out of place.

Good luck to Go2, no matter which direction it takes. I do believe that Go 
has done some very good path finding, Go2 will certainly deserve to be an 
even bigger success.

Lucio.

-- 
You received this message because you are subscribed to the Google 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 there some way to set value for unexported nil ptr field of a struct using reflect?

[feilengcui008]

Thanks for your answer :), even though the original question has been 
deleted.

I've used the reflect.NewAt to allocate a new memory at the same address of 
the unexported field's reflect.Value, it seems work.

for unexported not nil field

if !v.CanSet() {
   v = reflect.NewAt(v.Type(), unsafe.Pointer(v.UnsafeAddr())).Elem()
}


for unexported nil field

// since v is nil value, v.Elem() will be zero value
// and zero value is not addressable or settable, we
// need allocate a new settable v at the same address
v = reflect.NewAt(v.Type(), unsafe.Pointer(v.UnsafeAddr())).Elem()
newv := reflect.New(v.Type().Elem())
v.Set(newv)




在 2017年7月26日星期三 UTC+8上午9:08:50，Ian Lance Taylor写道：
>
> On Sun, Jul 23, 2017 at 12:46 AM, feilengcui008  > wrote: 
> > Hi, all: 
> > I'm writing a little fuzz tool for struct using reflect package, and 
> > came across the following case, but didn't find any way to solve it 
> > 
> > 
> > type TestStruct struct { 
> > a  *int   // unexported nil ptr field, how to modify it? 
> > b  int   // unexported not ptr field, can be modified using 
> > reflect.NewAt 
> > C  *int  // exported nil ptr field,  can be modified using 
> > reflect.New and value.Set 
> > } 
> > 
> > ts :=  {}  // a is nil ptr and not exported 
> > fieldA := reflect.ValueOf(ts).Elem().Field(0) 
> > // how to modify the value of a using the reflect value fieldA? 
>
> In general you can not use reflect to set unexported fields.  If that 
> were possible, then any package could use reflect to defeat the name 
> hiding used by any other package, which would make name hiding much 
> less useful. 
>
> 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] Alternative to reflect.DeepEqual that considers "shape" of cycles?

[Julian Andres Klode]

On Wed, Jul 26, 2017 at 04:55:39PM +, Jan Mercl wrote:
> On Wed, Jul 26, 2017 at 6:37 PM Julian Andres Klode 
> wrote:
> 
> > Is there an existing alternative to reflect.DeepEqual() that also
> respects the shape of the arguments? For example, the following tests fail:
> 
> a and b _are_ of equal shape and contain equal values:
> https://play.golang.org/p/Uam97DXOTy

The structs themselves are, yes. But the entire graph is
different (obviously). 

A - B \
|-/

vs.B \
   |-/

Or 2 nodes with 2 edges vs 1 node and 1 edge. There is basically
no practical difference here, but my goal is testing: I have code
that recursively rebuilds some structures (adding more information),
I want to ensure that the resulting graph has the same shape or
structure in my test case, not that they are practically equivalent.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

-- 
You received this message because you are subscribed to the Google 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] Details on the implementation decision for sync.Map

[Florin Pățan]

On Wednesday, July 26, 2017 at 9:16:50 PM UTC+1, Ian Lance Taylor wrote:
>
> On Wed, Jul 26, 2017 at 1:07 PM, Florin Pățan  > wrote: 
> > 
> > I would like to understand a bit better one particular implementation 
> > decision regarding the new sync.Map feature. 
> > 
> > Besides having to introduce a new keyword to the language and some 
> compiler 
> > work, what were the other issues that pushed the implementation as part 
> of 
> > the standard library instead of the language itself? 
> > 
> > And, obviously, since everyone is talking these days about Go 2, would 
> > having a newer version of the language at some point in the future, 
> maybe Go 
> > 1.14, help in moving this from the standard library to the language? 
> > 
> > The reason I ask is because the Go compiler / runtime already have a 
> form to 
> > express maps and ensure that, once a map is declared, the keys and 
> values 
> > will always be of the same type. The current sync.Map implementation 
> however 
> > allows for everything to be set as keys and values which means a lot of 
> type 
> > safety checks in the compiler are lost to the runtime. 
> > 
> > If this was already discussed, can you please link to that discussion as 
> > I've not managed to find it myself. 
>
> Adding a new complex feature to the language is a high bar.  sync.Map 
> is a somewhat special purpose data structure.  We don't want to add 
> all potentially useful data structures to the language.  Especially 
> not if they can be implemented entirely as a library, even if the 
> resulting library does lose some compile-time type safety. 
>
> Ian 
>


Thank you so much for the quick reply 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] Details on the implementation decision for sync.Map

[Ian Lance Taylor]

On Wed, Jul 26, 2017 at 1:07 PM, Florin Pățan  wrote:
>
> I would like to understand a bit better one particular implementation
> decision regarding the new sync.Map feature.
>
> Besides having to introduce a new keyword to the language and some compiler
> work, what were the other issues that pushed the implementation as part of
> the standard library instead of the language itself?
>
> And, obviously, since everyone is talking these days about Go 2, would
> having a newer version of the language at some point in the future, maybe Go
> 1.14, help in moving this from the standard library to the language?
>
> The reason I ask is because the Go compiler / runtime already have a form to
> express maps and ensure that, once a map is declared, the keys and values
> will always be of the same type. The current sync.Map implementation however
> allows for everything to be set as keys and values which means a lot of type
> safety checks in the compiler are lost to the runtime.
>
> If this was already discussed, can you please link to that discussion as
> I've not managed to find it myself.

Adding a new complex feature to the language is a high bar.  sync.Map
is a somewhat special purpose data structure.  We don't want to add
all potentially useful data structures to the language.  Especially
not if they can be implemented entirely as a library, even if the
resulting library does lose some compile-time type safety.

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] Details on the implementation decision for sync.Map

[Florin Pățan]

Hi,


I would like to understand a bit better one particular implementation 
decision regarding the new sync.Map feature.

Besides having to introduce a new keyword to the language and some compiler 
work, what were the other issues that pushed the implementation as part of 
the standard library instead of the language itself?

And, obviously, since everyone is talking these days about Go 2, would 
having a newer version of the language at some point in the future, maybe 
Go 1.14, help in moving this from the standard library to the language?

The reason I ask is because the Go compiler / runtime already have a form 
to express maps and ensure that, once a map is declared, the keys and 
values will always be of the same type. The current sync.Map implementation 
however allows for everything to be set as keys and values which means a 
lot of type safety checks in the compiler are lost to the runtime.

If this was already discussed, can you please link to that discussion as 
I've not managed to find it myself.

Thank you.

-- 
You received this message because you are subscribed to the Google 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 break a long code into lines in Golang?

[Jonathan]

Go makes it easy to use intermediates, and the code will be easier to read 
for someone else, possibly years from now.

{
  intervalMS := *Int64Flag_xxIntervalMS
  interval := time.Duration(intervalMS) * time.Millisecond
  elapsed := time.Now().Sub(timeStart)
  time.Sleep( interval - elapsed)
}

or, if you want to do this in several places:

sleepRemainder := func( timeStart time, intervalMS int ) {
  interval := time.Duration(intervalMS) * time.Millisecond
  elapsed := time.Now().Sub(timeStart)
  time.Sleep( interval - elapsed )
}

sleepRemainder( timeStart, Int64Flag_xxIntervalMS )

I've done this even when the code is only used once.  Sometimes it makes 
the code clearer by making the overall structure clearer.

Jonathan

-- 
You received this message because you are subscribed to the Google 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: Code Review - Applying functions on custom types

[Diego Medina]

I think we have a similar setup to what you are trying to do, we also 
started with Scala and about 3 years ago we moved it to Go (still use Scala 
for other parts of our app).

While working in Scala and other languages you are encourage to abstract 
things as much as you can, in Go it is often better to just address the 
issues/requirements at hand and be clear on what you are doing.
In our case we define a struct that has the expected fields and types for 
each column, and as we walk each row, we check that we get the expected 
type, then it's a matter of cleaning/adjusting values as we need to, assign 
the result of this cell to a variable and continue with the rest of the 
cells on this row, once done, we initialize our struct and save it to the 
database, move to the next row and repeat.

Hope it helps.


On Wednesday, July 26, 2017 at 10:09:07 AM UTC-4, Sofiane Cherchalli wrote:
>
> The schema is statically specified. The values always arrive in a defined 
> order. Each value has a defined type.
>
> On Tuesday, July 25, 2017 at 3:01:14 AM UTC+2, rog wrote:
>>
>> On 24 July 2017 at 23:21, Sofiane Cherchalli  wrote:
>>
>>> Yes, I'm trying to stream CSV values encoded in strings. A schema 
>>> defines a type of each value, so I have to parse values to verify they 
>>> match the type. Once validation is done, I apply functions on each value.
>>>
>>
>> Is the schema dynamically or statically specified? That is, do you know
>> in advance what the schema is, or do are you required to write
>> general code that deals with many possible schemas?
>>
>>
>>

-- 
You received this message because you are subscribed to the Google 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] Twitter search go code

[Shawn Milochik]

On Wed, Jul 26, 2017 at 11:47 AM, Tong Sun  wrote:

> Any simple go code out there that can search Twitter? Thx.
>
>
With a question this broad, you'd get much better and faster results by
using Google.

That said: https://www.youtube.com/watch?v=SQeAKSJH4vw=459s

-- 
You received this message because you are subscribed to the Google 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 1.9 Release Candidate 1 is released

[Brad Fitzpatrick]

https://tip.golang.org/doc/go1.9


On Wed, Jul 26, 2017 at 7:31 AM,  wrote:

> Great!
>
> Unfortunately, the "release notes" section points to the documentation; I
> can't find the actual release notes page.
>
>
>> --
> You received this message because you are subscribed to the Google 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] Alternative to reflect.DeepEqual that considers "shape" of cycles?

[Jan Mercl]

On Wed, Jul 26, 2017 at 6:37 PM Julian Andres Klode 
wrote:

> Is there an existing alternative to reflect.DeepEqual() that also
respects the shape of the arguments? For example, the following tests fail:

a and b _are_ of equal shape and contain equal values:
https://play.golang.org/p/Uam97DXOTy




-- 

-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] Alternative to reflect.DeepEqual that considers "shape" of cycles?

[Julian Andres Klode]

Is there an existing alternative to reflect.DeepEqual() that also respects 
the shape of the arguments? For example, the following tests fail:

type List struct {
next *List
}

func TestList(t *testing.T) {
a := {}
a.next = a
b := {a}
if reflect.DeepEqual(a, b) {
t.Error("Lists are equal")
}
}

Basically, it should also check if cycles occur in the same places 
(essentially just mapping pointer addresses to a counter and checking if 
the value (the counter) is the same on both sides when seeing a pointer).

-- 
You received this message because you are subscribed to the Google 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: no.something seem like impossible,but it happens!!!!【 string 】causes the crash !!!!!!!!!!!!!!

[ojucie]

I mean bytes.Buffer.

On Wednesday, July 26, 2017 at 8:08:13 AM UTC-3, JuciÊ Andrade wrote:
>
> Dear friend 3702, while you are at it, please change that string appending 
> strategy. Use a bufio.Buffer instead. It's way 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.

Re: [go-nuts] Why default stack size is 1gb?

[T L]

On Wednesday, July 26, 2017 at 10:37:44 AM UTC-4, Jan Mercl wrote:
>
> On Wed, Jul 26, 2017 at 4:26 PM T L  
> wrote:
>
> > BTW, I think we do need a GrowCurrentStackTo API, to avoid predicted 
> several stack copies in stack growing.
>
> The specification does not requires Go implementations to have any stack 
> at all.
>

we can just add it in the debug package, just like 
runtime/debug.SetMaxStack.
 

>
> -- 
>
> -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] Re: Reasoning behind behavior of range, when index is maintained

[Christoph Berger]

Hi Axel,

An attempt to explain this by looking at the C-style loop only:

The classic C-style for loop

for i:=0; i
> Hey,
>
> someone shared [this question](
> https://www.reddit.com/r/golang/comments/6paqc0/bug_that_caught_me_with_range/)
>  
> on reddit. I must say, that I'm surprised by the behavior myself. I would 
> have expected
> for i = range v
> to be semantically equivalent to
> for i = 0; i < len(v); i++
> and don't really understand the reasoning behind choosing different 
> semantics. Note, that the difference only exists, if i is declared outside 
> of the loop, that is, this is solely about the behavior after exiting the 
> loop-body.
>
> I'd greatly appreciate some explanation :)
>

-- 
You received this message because you are subscribed to the Google 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] Go Proxy Using HTTP Standard Library

[Andrew]

Hi,

I've installed a Discourse forum software to a cloud server in Docker. I 
want to write a simple Go server and install it to the same server to serve 
my own website(www.mysite.com).

How can I proxy all forum traffic to the Discourse(forum.mysite.com) in 
docker from my Go server using standard library? 

Thanks,
Andrew

-- 
You received this message because you are subscribed to the Google 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 break a long code into lines in Golang?

[Tong Sun]

Rule of thumb -- break anywhere *after *operation 

time.Sleep(time.Duration(*Int64Flag_xxIntervalMS) * time.
Millisecond - 
time.Now().Sub(timeStart))

or, 

time.Sleep(time.Duration(*Int64Flag_IntervalMS) * 
 time.Millisecond - 
 time.Now().
 Sub(timeStart))


On Tuesday, July 25, 2017 at 7:43:53 PM UTC-4, yihao yang wrote:
>
> Hi,
>
> I have some problems on break long code into lines when developing in 
> golang.
> Could you please help me on how to break a long code as following?
> time.Sleep(time.Duration(*Int64Flag_xxIntervalMS) * time.
> Millisecond - time.Now().Sub(timeStart))
>
> Thanks,
> Yihao
>

-- 
You received this message because you are subscribed to the Google 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 break a long code into lines in Golang?

[so . peter . 05]

yihao yang,

If you can't use a better name than Int64Flag_xxIntervalMS then 
at least make the code readable. For example,

interval := time.Duration(*Int64Flag_xxIntervalMS) * 
time.Millisecond
time.Sleep(interval - time.Since(timeStart))

Peter

On Tuesday, July 25, 2017 at 7:43:53 PM UTC-4, yihao yang wrote:
>
> Hi,
>
> I have some problems on break long code into lines when developing in 
> golang.
> Could you please help me on how to break a long code as following?
> time.Sleep(time.Duration(*Int64Flag_xxIntervalMS) * time.
> Millisecond - time.Now().Sub(timeStart))
>
> Thanks,
> Yihao
>

-- 
You received this message because you are subscribed to the Google 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 default stack size is 1gb?

[Jan Mercl]

On Wed, Jul 26, 2017 at 4:26 PM T L  wrote:

> BTW, I think we do need a GrowCurrentStackTo API, to avoid predicted
several stack copies in stack growing.

The specification does not requires Go implementations to have any stack at
all.

-- 

-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] Re: Go 1.9 Release Candidate 1 is released

[johnroth1]

Great!

Unfortunately, the "release notes" section points to the documentation; I 
can't find the actual release notes page.


>

-- 
You received this message because you are subscribed to the Google 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 default stack size is 1gb?

[T L]

BTW, I think we do need a GrowCurrentStackTo API, to avoid predicted 
several stack copies in stack growing.

On Monday, July 24, 2017 at 9:51:22 PM UTC-4, taozle wrote:
>
> my mistake, i mean the *max* stack size is 1gb which i saw it here 
> , not the default 
> stack size. Sorry for confusing
>
> On Tue, Jul 25, 2017 at 7:33 AM Florin Pățan  > wrote:
>
>> Iirc the default stack size is 2 or 4 kb not 1 gb. Where did you found 
>> the reference?
>>
>> --
>> You received this message because you are subscribed 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] Re: Code Review - Applying functions on custom types

[Sofiane Cherchalli]

The schema is statically specified. The values always arrive in a defined 
order. Each value has a defined type.

On Tuesday, July 25, 2017 at 3:01:14 AM UTC+2, rog wrote:
>
> On 24 July 2017 at 23:21, Sofiane Cherchalli  > wrote:
>
>> Yes, I'm trying to stream CSV values encoded in strings. A schema defines 
>> a type of each value, so I have to parse values to verify they match the 
>> type. Once validation is done, I apply functions on each value.
>>
>
> Is the schema dynamically or statically specified? That is, do you know
> in advance what the schema is, or do are you required to write
> general code that deals with many possible schemas?
>
>
>

-- 
You received this message because you are subscribed to the Google 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] In memory compilation and execution of Go code

[Ian Lance Taylor]

On Tue, Jul 25, 2017 at 9:53 PM, Cristian Adamo
 wrote:
>
> I'm looking for a way to compile an in memory go file and execute it within
> a go program.I have been looking around the go source code and found that
> perhaps something from the cmd/go/internal package could be used to do such
> task.

There is no support for that at present, and no real advantage since
the result would have to be written to disk anyhow in order to use it.
I suggest using the ordinary compilation process on a RAM disk.

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: 10x latency spikes during GC alloc assist phase

[rlh]

I would add to 14812 
.
 
The report should include the environment variables, HW , and RAM. The 
report should indicate if any environment variables are not set to the 
default, such as GOGC (SetGCPercent).

On Monday, July 24, 2017 at 8:44:10 PM UTC-4, stb...@laserlike.com wrote:
>
> Hi,
>
> We are experiencing a problem that I believe may be related to issue 14812 
> 
>  
> but I wanted to ask here before adding to that case or filing a new issue. 
> Of course, we’d also greatly appreciate any advice about how to make our 
> program performant.
>
> Here is what we observe: at Laserlike one of our core user-facing services 
> (the “leaf”) typically responds to a particular rpc in <400ms.  During GC 
> we see spikes in latency to >5s on some simple requests.  The stop the 
> world periods are short, so the GC spikes appear to happen at other times.
>
> We have been unable to replicate this in a simple program, but we did run 
> our code in a test mode that repros it.  In our test environment the server 
> loads ~10 GB of persistent data (never deleted so doesn’t really need to be 
> GCed), and we ask for 8 processors.  We are running go version 1.8.3 on 
> kubernetes on GCP machine of type n1-highmem-64.  To create the problem we 
> send the server a single request with >500 tasks..
>
>
> This google drive folder has leaf-logs-full.redacted.txt as well as other 
> performance tooling files 
> .
>  
>  A snippet from that log here shows normal query responses and timing:
>
> I0719 22:50:22.467367 leaf.go:363] Worker #5 done search for '[redacted]', 
> took 0.013 seconds
>
> I0719 22:50:22.467406 leaf.go:225] Worker #5 starting search for 
> '[redacted]'
>
> I0719 22:50:22.467486 leaf.go:363] Worker #6 done search for '[redacted]', 
> took 0.001 seconds
>
> I0719 22:50:22.467520 leaf.go:225] Worker #6 starting search for 
> '[redacted]'
>
> I0719 22:50:22.468050 leaf.go:363] Worker #9 done search for '[redacted]', 
> took 0.005 seconds
>
>
> We have observed that if a GC cycle happens to start while serving traffic 
> (which is often) AND there is a large amount of time spent in assist, then 
> our serving latency skyrockets by 10x.  In the log the slowdown commences 
> roughly when pacer assist starts at I0719 22:50:31.079283 and then reverts 
> to normal latencies shortly after the gc cycle completes at I0719 
> 22:50:36.806085.
>
> Below I copy parts of the log where we see latencies of up to 729ms on 
> tasks.  I also bold the line that shows 32929ms spent on alloc gc assist.
>
> We have captured an attached cpu profile during this time which seems to 
> confirm a large amount of time spent in runtime.gcAssistAlloc.func1.
>
>
> Pardon our ignorance about GC in golang, but our hypothesis about what may 
> be going wrong is that our large in-memory data structures are causing gc 
> to often go into assist mode, and that for reasons we don’t understand 
> malloc becomes expensive in that mode.  Since we also create ~100k new data 
> objects when processing user requests, we are guessing those allocs become 
> very slow.  Another piece of evidence for this hypothesis is that we have 
> another (prototype) implementation of this kind of service that makes more 
> use of object pools and doesn’t seem to have as much of slowdown during GC.
>
> Note on large in-memory data-structures:
>
> The principal data structures can be thought of as:
>
> Map[uint64][]byte (about 10M map entries, the slice lengths between 5K to 
> 50K) (around ~10G total memory usage) 
>
> Map[uint64][]uint64 (about 50M map entries, the slice lengths vary between 
> 10 and 100K, in a zipfian distribution, about 3G total memory usage)
>
> These data structures mostly stay as is over the life of the program.
>
> We are trying to figure out how to solve this so would appreciate any 
> advice. An engineer on our team wrote up the following ideas, none of which 
> are that great:
>
>1. 
>
>Figure out a simple way to prevent our goroutines slowing down during 
>GC.  I had some hopes LockOSThread() could be made to work, but it didn't 
>seem to help in my experiments.  I'm not ruling this solution out 
> entirely, 
>but if it's the write barriers that are the main problem, I don't have 
> much 
>hope.
>2. 
>
>Run at least 2 replicas of all our servers.  Manage their GC cycles 
>ourselves, synchronized so that at most one replica is in GC at any given 
>time.  The clients should either send all requests to both replicas (and 
>cancel when one replies), or use some more complicated Kubernetes and 
>client logic so a GCing replica is never sent requests.  This is the 

[go-nuts] In memory compilation and execution of Go code

[Cristian Adamo]

Hi guys, 

I'm looking for a way to compile an in memory go file and execute it within 
a go program.I have been looking around the go source code and found that 
perhaps something from the cmd/go/internal package could be used to do such 
task.

But my question is, is anyone familiar with that package or with the go 
compilation process who can help me here?

Thanks in advance for your help.

Best,
Cristian Adamo.



-- 
You received this message because you are subscribed to the Google 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 1.9 Release Candidate 1 is released

[Gergely Brautigam]

Yaay! Awesome!

On Tuesday, 25 July 2017 18:30:06 UTC+2, Chris Broadfoot wrote:
>
> Hello gophers,
>
> We have just released go1.9rc1, a release candidate of Go 1.9.
> It is cut from release-branch.go1.9 at the revision tagged go1.9rc1.
>
> Thank you to everyone who has helped to test Go 1.9 so far.
> We still need more people to test, especially on production workloads.
> Your help is invaluable.
>
> Report any problems using the issue tracker:
> https://golang.org/issue/new
>
> If you have Go installed already, the easiest way to try go1.9rc1
> is by using this tool:
> https://godoc.org/golang.org/x/build/version/go1.9rc1
>
> You can download binary and source distributions from the usual place:
> https://golang.org/dl/#go1.9rc1
>
> To find out what has changed in Go 1.9, read the draft release notes:
> https://tip.golang.org/doc/go1.9
>

Link needs to include 'go1.9' part. :) 

>
> Documentation for Go 1.9 is available at:
> https://tip.golang.org/
>

I feel like this is a bit redundant since you literary shared the doc link 
one above. Just saying. :) 
 

>
> Cheers,
> Chris
>
>

-- 
You received this message because you are subscribed to the Google 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: no.something seem like impossible,but it happens!!!!【 string 】causes the crash !!!!!!!!!!!!!!

[ojucie]

Dear friend 3702, while you are at it, please change that string appending 
strategy. Use a bufio.Buffer instead. It's way faster.


> type bad.go
package main

import (
"fmt"
"time"
)

func main() {
var s string
begin := time.Now()
for i := 0; i != 10; i++ {
s = s + "lalalala"
}
fmt.Printf("len = %d, %d ns\n", len(s), 
time.Now().UnixNano()-begin.UnixNano())
}

> bad.exe
len = 80, 3573571400 ns

> bad.exe
len = 80, 3564547900 ns

> bad.exe
len = 80, 3657745100 ns

> type good.go
package main

import (
"bytes"
"fmt"
"io"
"time"
)

func main() {
var b bytes.Buffer
begin := time.Now()
for i := 0; i != 10; i++ {
io.WriteString(, "lalalala")
}
s := b.String()
fmt.Printf("len = %d, %d secs\n", len(s), 
time.Now().UnixNano()-begin.UnixNano())
}

> good.exe
len = 80, 2991600 secs

> good.exe
len = 80, 4002600 secs

> good.exe
len = 80, 3001800 secs


-- 
You received this message because you are subscribed to the Google 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] Attaching to email and extracting email attachments

[jesse junsay]

@Konstantin K. - Yes been doing that. Have you successfully done this
problem before?

@Gulacsi - That's where I am right now.

Thanks guys. Will let you know if I figure this out...

On Wed, Jul 26, 2017 at 5:30 PM, Gulácsi Tamás  wrote:

> You only need to decode the Transfer-Encoding, and treate the file as
> Content-Type says.
>
>
> jesse junsay  ezt írta (időpont: 2017. júl. 26.,
> Sze, 8:52):
>
>> Thank you Tamas... I am already done with identifying each part using the
>> mime multipart... My main issue now is decoding it back to its binary form
>> and save it to disk... each attachment to its own data format. jpg
>> attachment to file.jpg, pdf attachment to file.pdf and txt attachment to
>> file.txt...
>>
>> On Wed, Jul 26, 2017 at 1:35 PM, Tamás Gulácsi 
>> wrote:
>>
>>> Check out github.com/tgulacsi/agostle - it walks the tree of mime parts
>>> of mail and converts everything to PDF, but you need the walk part only -
>>> which uses mime/multipart reader basically.
>>
>>
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/
>>> topic/golang-nuts/nfJyUx3BVvs/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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] no.something seem like impossible,but it happens!!!!【 string 】causes the crash !!!!!!!!!!!!!!

[Konstantin Khomoutov]

On Wed, Jul 26, 2017 at 02:46:08AM -0700, 370265...@qq.com wrote:

> > I think I can see at least one data race in your code. Try to run it using 
> > the race detector to verify.
> thanks.yes,i thought this before too,but string is basic type of golang,to 
> read and write the same variable of string should not case panic i think.

Implementing this would mean each access to each string variable would
need to use some sort of locking.  This is not tolerable as 99.9% of
code accessing variables of any type, including string, is not subject
for concurrency matters as such variables are confined to particular
goroutines.  Using automatic locking in such cases would cause
tremendous slowdowns for no reason.

That is, when you need concurrency, plan for concurrency and implement
it one way or another -- either through using channels or explicit
locking.

-- 
You received this message because you are subscribed to the Google 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] no.something seem like impossible,but it happens!!!!【 string 】causes the crash !!!!!!!!!!!!!!

[370265036]

thanks.yes,i thought this before too,but string is basic type of golang,to 
read and write the same variable of string should not case panic i think.

在 2017年7月26日星期三 UTC+8下午5:35:24，Jan Mercl写道：
>
> On Wed, Jul 26, 2017 at 11:28 AM <3702...@qq.com > wrote:
>
> I think I can see at least one data race in your code. Try to run it using 
> the race detector to verify.
>
> -- 
>
> -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] no.something seem like impossible,but it happens!!!!【 string 】causes the crash !!!!!!!!!!!!!!

[Jan Mercl]

On Wed, Jul 26, 2017 at 11:28 AM <370265...@qq.com> wrote:

I think I can see at least one data race in your code. Try to run it using
the race detector to verify.

-- 

-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] Attaching to email and extracting email attachments

[Gulácsi Tamás]

You only need to decode the Transfer-Encoding, and treate the file as
Content-Type says.

jesse junsay  ezt írta (időpont: 2017. júl. 26., Sze,
8:52):

> Thank you Tamas... I am already done with identifying each part using the
> mime multipart... My main issue now is decoding it back to its binary form
> and save it to disk... each attachment to its own data format. jpg
> attachment to file.jpg, pdf attachment to file.pdf and txt attachment to
> file.txt...
>
> On Wed, Jul 26, 2017 at 1:35 PM, Tamás Gulácsi 
> wrote:
>
>> Check out github.com/tgulacsi/agostle - it walks the tree of mime parts
>> of mail and converts everything to PDF, but you need the walk part only -
>> which uses mime/multipart reader basically.
>
>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/nfJyUx3BVvs/unsubscribe.
>> To unsubscribe from this group and all its topics, 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] no.something seem like impossible,but it happens!!!!【 string 】causes the crash !!!!!!!!!!!!!!

[370265036]

the code is like this(i make it simple,but the logic is not change)

const (   

Ignore = "-"

End= "\r\n"

)


type AccessLog struct {

Hash string

LowerIP  string

FlowType int8

SendTime int64

Host string

AppName  string

StreamName   string

Protocol string

StatusCode   string

Url  string

HttpAgentstring

Referstring

VideoFrameRate   int32

.

.

.

omit some variable

.

.

.

}


func appendValue(rsp string, value string) string {

if value == End {  // End

rsp += value

} else {

rsp += (value + "|")

}

return rsp

}


func (a *AccessLog) SetStatusCode(statusCode string) {

if a.StatusCode == "" {

a.StatusCode = statusCode

}

}


func (a *AccessLog) MakeString() string {

var rsp string

rsp = appendValue(rsp, Stop)

rsp = appendValue(rsp, a.Hash) 

rsp = appendValue(rsp, a.LowerIP) 

rsp = appendValue(rsp, fmt.Sprint(a.FlowType))

rsp = appendValue(rsp, fmt.Sprint(tt))

rsp = appendValue(rsp, a.Host)

rsp = appendValue(rsp, a.AppName) 

rsp = appendValue(rsp, a.StreamName)

rsp = appendValue(rsp, a.Protocol)

rsp = appendValue(rsp, a.StatusCode) *//every time crash in this line,and 
panic: **runtime error: invalid memory address or nil pointer dereference*

rsp = appendValue(rsp, a.Url) 

rsp = appendValue(rsp, Ignore) 

rsp = appendValue(rsp, Ignore)

.

.

.

}


*2 goroutinue will access the same variable which is type of *AccessLog  ,like 
this*


func changeAccessLog(a *AccessLog){

   .

   .

   .

   a.SetStatusCode(code)

   .

   .

   .

}


func makeStringAccessLog(a *AccessLog) {

   .

   .

   .

   rsp := a.MakeString()

   .

   .

   .

}

*//this is the caller function*

func callFunc(){

   .

   .

   .

   a := new(AccessLog)

   go changeAccessLog(a)

   go makeStringAccessLog(a)

   .

   .

   .

}


so, i don't understand why operate string variable will case crash.

of course,the code in my program is more complex,function SetStatusCode and 
MakeString will be called in the same time.

do somebody meet this before???




-- 
You received this message because you are subscribed to the Google 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] Attaching to email and extracting email attachments

[Konstantin Khomoutov]

On Wed, Jul 26, 2017 at 02:52:05PM +0800, jesse junsay wrote:

> > Check out github.com/tgulacsi/agostle - it walks the tree of mime parts
> > of mail and converts everything to PDF, but you need the walk part only -
> > which uses mime/multipart reader basically.
> Thank you Tamas... I am already done with identifying each part using the
> mime multipart... My main issue now is decoding it back to its binary form
> and save it to disk... each attachment to its own data format. jpg
> attachment to file.jpg, pdf attachment to file.pdf and txt attachment to
> file.txt...

You should study a bit of theory behind this.

As the first step, you can take any of your sample e-mail messages and
ask your mail reading program to show you the "raw" message's view.
You can also save the message as a file to your filesystem and then
use any "advanced" text viewer program (say, Notepad++ would do) to view
its "raw" content.  (If asked, save as "mbox" format or "EML" format.)

You can then see that each MIME part of your message has individual
header block followed by an empty line (sole CR+LF sequence) followed by
the body of that part.  This header contains several standard fields
defining what's the encoding of the following body, and what's the
format of the source data which was encoded.  Say, typically, the
encoding is Base64, and the format depends on the data -- it may be,
say, text/json or image/jpeg and so on.

Your task is to try and parse these fields as you iterate over the MIME
parts of your message and act accordingly.
The standard library has all the bits you need to carry out this task --
see [1, 2].

1. https://golang.org/pkg/mime/
2. https://golang.org/pkg/mime/multipart/

-- 
You received this message because you are subscribed to the Google 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: default --help flag behavior

[Konstantin Khomoutov]

On Thu, Jul 20, 2017 at 07:23:23AM +1000, Rob Pike wrote:

>>> I realize than running `mybinary --help` returns a nice help message
>>> along with a exit status 2.
>>> What is the reason it doesn't return 0?
[...]
>> It's reasonable to consider calling a command with a flag that is not
>> defined an error (whether that flag is -help or -verbose or -whatever). It
>> is common to return non 0 on error.
> The Unix tradition, fading away like all the other Unix traditions, is that
> exit code 0 is for success, 1 is for failed execution, and 2 is for
> reporting that the usage was incorrect, preventing it from running.
> Although one could make the case that "-help" did what it was supposed to
> do, tradition says the command didn't run because of the arguments, so the
> exit code should be 2.
> 
> "grep --help" doesn't grep anything because of what the arguments said. I
> just tried this with BSD grep and got exit code 2. For some reason, grep
> still obeys the Unix tradition. Someone will fix that soon, no doubt, but
> for now let's be consistent.

For what it worth, GNU coding guidelines suggest that running a tool
explicitly passing it the "--help" (or "-h" or another option with the
same meaning) is a conscious decision of the user and hence printing the
help message is carrying out the intended task.

Hence the tools are supposed to behave differently when run with
"--help" and when run with an invalid combination of the options: in the
former case they are supposed to print a reasonably complete help
synopsis and exit with status 0, otherwise they should print a terse
message explaining what went wrong and how to get help and exit with a
non-zero exit code.

To demonstrate how GNU grep behaves:

  ~$ grep
  Usage: grep [OPTION]... PATTERN [FILE]...
  Try 'grep --help' for more information.
  ~$ echo $?
  2
  
  ~$ grep --help >/dev/null
  ~$ echo $?
  0

I personally find such behaviour to be reasonably logical.
(Not that I'm to blame the Go's flag package 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] Attaching to email and extracting email attachments

[jesse junsay]

Thank you Tamas... I am already done with identifying each part using the
mime multipart... My main issue now is decoding it back to its binary form
and save it to disk... each attachment to its own data format. jpg
attachment to file.jpg, pdf attachment to file.pdf and txt attachment to
file.txt...

On Wed, Jul 26, 2017 at 1:35 PM, Tamás Gulácsi  wrote:

> Check out github.com/tgulacsi/agostle - it walks the tree of mime parts
> of mail and converts everything to PDF, but you need the walk part only -
> which uses mime/multipart reader basically.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/nfJyUx3BVvs/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Reasoning behind behavior of range, when index is maintained

['Axel Wagner' via golang-nuts]

This is actually a really good point, thanks :)

On Wed, Jul 26, 2017 at 1:37 AM, Chris Manghane  wrote:

> Hmm, well I can't give better reasoning off the top of my head, but I
> still have to wonder why you expect the behavior of those constructs to be
> the same, particularly. Imagine, you would like to capture both the
> iteration variable and the value itself, for example:
>
> var i, v = 0, ""
> for i, v = range someSlice {}
> println(v)
>
> What is the value of `v`? I expect that the last elements of the iteration
> of someSlice, namely len(someSlice) - 1 and someSlice[len(someSlice) - 1],
> would be stored in `i` and `v`, respectively. Alternatively, I might
> implement this as (or lower it to):
>
> var i, v = 0, ""
> for i = 0; i <= len(someSlice); i++ {
> v = someSlice[i]
> }
>
> With the alternative implementation, it seems like either the value in `v`
> would be completely invalid (or cause an out-of-bounds error) or there
> would be a mismatch between the value that `i` and `v` stop at after
> iteration. I'm not sure if that's official reasoning, but the semantics of
> range statements are different in many other situations as well so it seems
> consistent to me.
>
> On Tue, Jul 25, 2017 at 4:11 PM, Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
>
>> On Wed, Jul 26, 2017 at 12:52 AM, Chris Manghane 
>> wrote:
>>
>>> This is mentioned directly in the language specification under For
>>> statements with range clause :
>>>
>>>  For each entry it assigns iteration values to corresponding iteration
 variables if present and then executes the block.
>>>
>>> and
>>>
  For an array, pointer to array, or slice value a, the index iteration
 values are produced in increasing order, starting at element index 0. If at
 most one iteration variable is present, the range loop produces iteration
 values from 0 up to len(a)-1 and does not index into the array or slice
 itself. For a nil slice, the number of iterations is 0.
>>>
>>>
>>> This seems logically correct to me, as well. For an array or slice of
>>> len(array) = N, the for range statement generates N iteration values,
>>> starting from 0. The Nth iteration value would have to be N-1. The
>>> difference in semantics is because the post statement in a for loop must be
>>> executed after the body is executed. A typical for-loop assigns the N+1st
>>> iteration value to the iteration variable, but that is a user's choice.
>>>
>>> Hopefully that is more clear,
>>>
>>
>> Not really, sorry :) You basically reiterated the status quo, but did
>> hardly explain *why* those choices where actually made.
>>
>> > For an array or slice of len(array) = N, the for range statement
>> generates N iteration values, starting from 0. The Nth iteration value
>> would have to be N-1.
>>
>> That would also be the case if the loop would be equivalent to the
>> obvious for-loop in regards to indices.
>>
>> > he difference in semantics is because the post statement in a for loop
>> must be executed after the body is executed.
>>
>> Well, yeah, the question is, why wasn't this also done for range. Or
>> rather, why wasn't the range of indices assigned decided to be equivalent
>> with the most obvious for-loop.
>> Especially as it seems, that if you use :=, the generated code actually
>> *does* seem to include the extra increment (bringing the index to len(v),
>> even if unobservably), so pure efficiency does not seem to be the reason.
>>
>> The reason for the decision might very well be "someone just decided it
>> that way and now that's the way it is". That'd be fine. I'd just be
>> interested to know if there was a more deliberate reasoning behind this.
>>
>>
>>
>>> Chris
>>>
>>> On Tue, Jul 25, 2017 at 3:30 PM, 'Axel Wagner' via golang-nuts <
>>> golang-nuts@googlegroups.com> wrote:
>>>
 Hey,

 someone shared [this question](https://www.reddit.c
 om/r/golang/comments/6paqc0/bug_that_caught_me_with_range/) on reddit.
 I must say, that I'm surprised by the behavior myself. I would have 
 expected
 for i = range v
 to be semantically equivalent to
 for i = 0; i < len(v); i++
 and don't really understand the reasoning behind choosing different
 semantics. Note, that the difference only exists, if i is declared outside
 of the loop, that is, this is solely about the behavior after exiting the
 loop-body.

 I'd greatly appreciate some explanation :)

 --
 You received this message because you are subscribed to the Google
 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