[go-nuts] Re: In the future, how to keep runtime.KeepAlive from dead code elimination?

[Cholerae Hu]

I see, thanks.

在 2016年8月25日星期四 UTC+8上午11:42:10，Cholerae Hu写道：
>
> Hi all,
>
> I've read the source of package runtime, and found that runtime.KeepAlive 
> is an empty function. If go compiler can do dead code elimination in the 
> future, how to protect runtime.KeepAlive from being optimized?
>

-- 
You received this message because you are subscribed to the Google 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: Why can't convert []T to []T2 if T2 is a copy definition of T?

[Ian Lance Taylor]

On Fri, Aug 26, 2016 at 9:46 PM, T L  wrote:
>
>> "You are suggesting that there is an extra rule to forbids converting []T1
>> to
> []T2 when T1 and T2 have the same underlying representation."
>
> No. I understand []T1 can't be converted to []T2 when T1 and T2 have
> different underlying representation.
>
> Ok, the alternative of my question is: why []T2 and []T1 have different
> underlying representations when T2 and T1 have the same underlying
> representation?

They don't.

If T2 and T1 have the same underlying representation, then []T2 and
[]T1 have the same underlying representation.


>> "despite the overall prohibition on converting []T1 to
> []T2, you are permitted to convert them exactly when T1 and T2 have
> the same underlying representation.  That rule is much more complex
> than the current rule.  It means that people reading Go code have to
> understand when T1 and T2 have the same representation."
>
> So you mean there is no implementation obstacles to allow converting []Age
> to []int?

That is correct.


> The prohibition is just to make people less confused.

I would say that it is to make the language simpler.  There are fewer
things that people learning the language need to understand.


> But the current prohibition make me confused, may I am not a typical gopher.

Why does it make you confused?

On a 64-bit system, the types "int" and "int64" have the same
representation.  They are both 64-bit signed integers.  Does it
confuse you that Go rejects

var v int = int64(1)

?

If that does not confuse you, then the fact Go does not permit
assigning from []Age to []int should not confuse you.  It is the same
kind of thing: in Go, different types are different.

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] Re: Why can't convert []T to []T2 if T2 is a copy definition of T?

[T L]

On Saturday, August 27, 2016 at 12:28:16 PM UTC+8, Ian Lance Taylor wrote:
>
> On Fri, Aug 26, 2016 at 8:52 PM, T L  
> wrote: 
> > 
> > On Saturday, August 27, 2016 at 11:40:20 AM UTC+8, Ian Lance Taylor 
> wrote: 
> >> 
> >> On Fri, Aug 26, 2016 at 8:17 PM, T L  wrote: 
> >> > 
> >> > On Saturday, August 27, 2016 at 9:06:00 AM UTC+8, mura wrote: 
> >> >> 
> >> >> Hi, 
> >> >> 
> >> >> Generally speaking, you may find it a bit of struggling if you are 
> >> >> trying 
> >> >> to write Go code in an attempt to emulate *how* other languages can 
> do, 
> >> >> or 
> >> >> to argue with the compiler about how a fresh learner would come to 
> >> >> think in 
> >> >> the first place. A tip for making the learning/adaption process 
> >> >> smoother is 
> >> >> to focus on *what* you want to achieve in the problem domain 
> (instead 
> >> >> of 
> >> >> language domain, like fighting the compiler). 
> >> >> 
> >> >> Veteran gophers would be most helpful if you ask about the specific 
> >> >> functionalities or features you are trying to build. It's very 
> likely 
> >> >> that 
> >> >> the language problems you encountered don't exist at all in other 
> >> >> well-explored approaches. 
> >> >> 
> >> > 
> >> > And it is very appreciated if you can show the behind reason for "why 
> >> > can't 
> >> > []Age be converted into []int". 
> >> 
> >> You have gotten several different answers to that question. 
> >> 
> >> What kind of answer would you find satisfactory? 
> > 
> > No one have answered what is the behind reason for "why can't []Age be 
> > converted into []int" yet. 
> > 
> > I don't think "rules disallow it, so it can't" is a good answer. 
>
> Many people have answered it, including me.  Perhaps you missed my 
> answer; it is here: 
> https://groups.google.com/d/msg/golang-nuts/jDcUu4gUIRc/fX5pI66zFQAJ . 
>
> So, I'm sorry, but I have to ask again: what kind of answer would you 
> find satisfactory? 
>
> Ian 
>

I have read and replied your answer above.

And sorry I didn't convert all aspects in that reply.


> "..., which makes it hard to 
understand what kind of answer you are looking for, and why you are 
asking. Can you expand on that? "

Sorry, secret now. :)
Alternative answer: I'm curious on the details of Golang rules.

> "You are suggesting that there is an extra rule to forbids converting 
[]T1 to 
[]T2 when T1 and T2 have the same underlying representation."

No. I understand []T1 can't be converted to []T2 when T1 and T2 have 
different underlying representation.

Ok, the alternative of my question is: why []T2 and []T1 have different 
underlying representations when T2 and T1 have the same underlying 
representation?

> "despite the overall prohibition on converting []T1 to 
[]T2, you are permitted to convert them exactly when T1 and T2 have 
the same underlying representation.  That rule is much more complex 
than the current rule.  It means that people reading Go code have to 
understand when T1 and T2 have the same representation."

So you mean there is no implementation obstacles to allow converting []Age 
to []int?
The prohibition is just to make people less confused. 

But the current prohibition make me confused, may I am not a typical gopher.





 

-- 
You received this message because you are subscribed to the Google 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: Why can't convert []T to []T2 if T2 is a copy definition of T?

[Ian Lance Taylor]

On Fri, Aug 26, 2016 at 8:52 PM, T L  wrote:
>
> On Saturday, August 27, 2016 at 11:40:20 AM UTC+8, Ian Lance Taylor wrote:
>>
>> On Fri, Aug 26, 2016 at 8:17 PM, T L  wrote:
>> >
>> > On Saturday, August 27, 2016 at 9:06:00 AM UTC+8, mura wrote:
>> >>
>> >> Hi,
>> >>
>> >> Generally speaking, you may find it a bit of struggling if you are
>> >> trying
>> >> to write Go code in an attempt to emulate *how* other languages can do,
>> >> or
>> >> to argue with the compiler about how a fresh learner would come to
>> >> think in
>> >> the first place. A tip for making the learning/adaption process
>> >> smoother is
>> >> to focus on *what* you want to achieve in the problem domain (instead
>> >> of
>> >> language domain, like fighting the compiler).
>> >>
>> >> Veteran gophers would be most helpful if you ask about the specific
>> >> functionalities or features you are trying to build. It's very likely
>> >> that
>> >> the language problems you encountered don't exist at all in other
>> >> well-explored approaches.
>> >>
>> >
>> > And it is very appreciated if you can show the behind reason for "why
>> > can't
>> > []Age be converted into []int".
>>
>> You have gotten several different answers to that question.
>>
>> What kind of answer would you find satisfactory?
>
> No one have answered what is the behind reason for "why can't []Age be
> converted into []int" yet.
>
> I don't think "rules disallow it, so it can't" is a good answer.

Many people have answered it, including me.  Perhaps you missed my
answer; it is here:
https://groups.google.com/d/msg/golang-nuts/jDcUu4gUIRc/fX5pI66zFQAJ .

So, I'm sorry, but I have to ask again: what kind of answer would you
find satisfactory?

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] Using go test capabilities a as testing framework for other system.

[erich . cm]

Hi everyone, 

Let's say that I have a system (a C/C++ system with different binaries) and 
currently we use pytest to make functional testing in that system, execute 
commands with different arguments, retrieving the stdout, stderr and 
retcode for every execution. Pytest now gives us a good output and logs but 
I'm wondering if it's possible to make the same with Go.

So, the idea would be to have at the end a Go binary that I could execute 
and get an output similar that 'go test' produce, also the benchmark 
capabilities would be awesome, so you can now how much time takes every 
binary in their execution. 

Do you know if something like this already exists? 
Or what would be a good starting point to see how to use the 'go test' 
features from a go binary?

Thanks a lot!

-Erich

-- 
You received this message because you are subscribed to the Google 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: Why can't you take the address of a function's return value?

[T L]

On Saturday, August 27, 2016 at 11:34:05 AM UTC+8, T L wrote:
>
>
>
> On Tuesday, August 23, 2016 at 1:25:03 AM UTC+8, con...@superhuman.com 
> wrote:
>>
>> Hey All,
>>
>> I've been using a typedef of
>>
>> type MaybeTimestamp *int64
>>
>> so we can JSON encode timestamps correctly, see 
>> https://medium.com/coding-and-deploying-in-the-cloud/time-stamps-in-golang-abcaf581b72f
>>  
>> for inspriation
>>
>> I was surprised that the following didn't work (see 
>> https://play.golang.org/p/1QQylqTLkB):
>>
>> func NewMaybeTimestamp(t time.Time) MaybeTimestamp {
>> return ()
>> }
>>
>> // fails with:
>> // tmp/sandbox449672725/main.go:14: cannot take the address of 
>> t.Unix()
>>
>> I can fix this by introducing a temporary variable:
>>
>> func NewMaybeTimestamp(t time.Time) MaybeTimestamp {
>> temp := t.Unix()
>> return 
>> }
>>
>> Seeing as this is the obvious solution to this problem, I was pretty 
>> disappointed that the compiler couldn't insert the temporary for me.
>>
>> Is this something that should change, or is it just a limitation 
>> hard-coded by the compatibility guarantee?
>>
>
> Direct values, including const and temp values, are not addressable. But 
> there is an exception which is described in Ian's answer. 
>
 
>

The counter rule is: variables, including elements of variables, are always 
addressable. 
And there is also an exception for the counter rule: map elements are not 
addressable.

Please adapt it. Almost for every rule in Golang, there are some exceptions.

 

>
>> Conrad
>>
>>

-- 
You received this message because you are subscribed to the Google 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: Why can't convert []T to []T2 if T2 is a copy definition of T?

[T L]

On Saturday, August 27, 2016 at 11:40:20 AM UTC+8, Ian Lance Taylor wrote:
>
> On Fri, Aug 26, 2016 at 8:17 PM, T L  
> wrote: 
> > 
> > On Saturday, August 27, 2016 at 9:06:00 AM UTC+8, mura wrote: 
> >> 
> >> Hi, 
> >> 
> >> Generally speaking, you may find it a bit of struggling if you are 
> trying 
> >> to write Go code in an attempt to emulate *how* other languages can do, 
> or 
> >> to argue with the compiler about how a fresh learner would come to 
> think in 
> >> the first place. A tip for making the learning/adaption process 
> smoother is 
> >> to focus on *what* you want to achieve in the problem domain (instead 
> of 
> >> language domain, like fighting the compiler). 
> >> 
> >> Veteran gophers would be most helpful if you ask about the specific 
> >> functionalities or features you are trying to build. It's very likely 
> that 
> >> the language problems you encountered don't exist at all in other 
> >> well-explored approaches. 
> >> 
> > 
> > And it is very appreciated if you can show the behind reason for "why 
> can't 
> > []Age be converted into []int". 
>
> You have gotten several different answers to that question. 
>
> What kind of answer would you find satisfactory? 
>
> Ian 
>


No one have answered what is the behind reason for "why can't []Age be 
converted into []int" yet.

I don't think "rules disallow it, so it can't" is a good answer.
 

-- 
You received this message because you are subscribed to the Google 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: Why can't convert []T to []T2 if T2 is a copy definition of T?

[Ian Lance Taylor]

On Fri, Aug 26, 2016 at 8:17 PM, T L  wrote:
>
> On Saturday, August 27, 2016 at 9:06:00 AM UTC+8, mura wrote:
>>
>> Hi,
>>
>> Generally speaking, you may find it a bit of struggling if you are trying
>> to write Go code in an attempt to emulate *how* other languages can do, or
>> to argue with the compiler about how a fresh learner would come to think in
>> the first place. A tip for making the learning/adaption process smoother is
>> to focus on *what* you want to achieve in the problem domain (instead of
>> language domain, like fighting the compiler).
>>
>> Veteran gophers would be most helpful if you ask about the specific
>> functionalities or features you are trying to build. It's very likely that
>> the language problems you encountered don't exist at all in other
>> well-explored approaches.
>>
>
> And it is very appreciated if you can show the behind reason for "why can't
> []Age be converted into []int".

You have gotten several different answers to that question.

What kind of answer would you find satisfactory?

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: Why can't convert []T to []T2 if T2 is a copy definition of T?

[T L]

On Saturday, August 27, 2016 at 9:06:00 AM UTC+8, mura wrote:
>
> Hi,
>
> Generally speaking, you may find it a bit of struggling if you are trying 
> to write Go code in an attempt to emulate *how* other languages can do, or 
> to argue with the compiler about how a fresh learner would come to think in 
> the first place. A tip for making the learning/adaption process smoother is 
> to focus on *what* you want to achieve in the problem domain (instead of 
> language domain, like fighting the compiler).
>
> Veteran gophers would be most helpful if you ask about the specific 
> functionalities or features you are trying to build. It's very likely that 
> the language problems you encountered don't exist at all in other 
> well-explored approaches.
>
>
And it is very appreciated if you can show the behind reason for "why can't 
[]Age be converted into []int".
 

>
> On Friday, August 26, 2016 at 11:45:40 PM UTC+8, T L wrote:
>>
>>
>>
>> package main
>>
>> type Age int
>>
>> func main() {
>> var ages = []Age{17, 18, 19}
>> var ints = ([]int)(ages) // error: cannot convert ages (type []Age) 
>> to type []int
>> _ = ints
>> }
>>
>>

-- 
You received this message because you are subscribed to the Google 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: Why can't convert []T to []T2 if T2 is a copy definition of T?

[T L]

On Saturday, August 27, 2016 at 9:06:00 AM UTC+8, mura wrote:
>
> Hi,
>
> Generally speaking, you may find it a bit of struggling if you are trying 
> to write Go code in an attempt to emulate *how* other languages can do, or 
> to argue with the compiler about how a fresh learner would come to think in 
> the first place. A tip for making the learning/adaption process smoother is 
> to focus on *what* you want to achieve in the problem domain (instead of 
> language domain, like fighting the compiler).
>
> Veteran gophers would be most helpful if you ask about the specific 
> functionalities or features you are trying to build. It's very likely that 
> the language problems you encountered don't exist at all in other 
> well-explored approaches.
>
>
I'm not a new gopher. 
In fact, I would be more a veteran gopher than you. 
Sorry for saying this.
 

>
> On Friday, August 26, 2016 at 11:45:40 PM UTC+8, T L wrote:
>>
>>
>>
>> package main
>>
>> type Age int
>>
>> func main() {
>> var ages = []Age{17, 18, 19}
>> var ints = ([]int)(ages) // error: cannot convert ages (type []Age) 
>> to type []int
>> _ = ints
>> }
>>
>>

-- 
You received this message because you are subscribed to the Google 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 can't convert []T to []T2 if T2 is a copy definition of T?

[T L]

On Saturday, August 27, 2016 at 2:12:55 AM UTC+8, Ian Lance Taylor wrote:
>
> On Fri, Aug 26, 2016 at 10:51 AM, T L  
> wrote: 
> > 
> > On Saturday, August 27, 2016 at 1:43:03 AM UTC+8, Axel Wagner wrote: 
> >> 
> >> The effort is putting a special case into the language for this. 
> > 
> > 
> > I feel the effort is made to forbid converting []Age into []int instead 
> now. 
>
>
> What is your overall goal with all the questions you ask?  You seem to 
> have a certain point of view about the language, one that is not 
> shared by many other people who work with and on the language.  You 
> ask your questions in a very terse manner, which makes it hard to 
> understand what kind of answer you are looking for, and why you are 
> asking. 
>
> Can you expand on that? 
>
>
> To answer this specific question of yours, one in a long series, there 
> is one rule in the language: you can't convert []T1 to []T2.  You are 
> suggesting that there is an extra rule to forbids converting []T1 to 
> []T2 when T1 and T2 have the same underlying representation.  Your 
> statement is clearly incorrect; there is no such rule.  Perhaps I 
> misunderstand what you are saying.  However, the only way I know to 
> interpret what appears to be your suggestion is to add a new rule to 
> the language: despite the overall prohibition on converting []T1 to 
> []T2, you are permitted to convert them exactly when T1 and T2 have 
> the same underlying representation.  That rule is much more complex 
> than the current rule.  It means that people reading Go code have to 
> understand when T1 and T2 have the same representation.  It means that 
> that needs to be defined in the language, which it currently is not. 
> For example, on a 64-bit system, should we permit converting []int to 
> []int64, one on a 32-bit system should we permit converting []int to 
> []int32?  These questions do not have obvious answers, at least not to 
> me.  The rule saying you can't convert []T1 to []T2 is very simple, 
> and can be understood by even a beginning Go programmer. 
>

int64 and int (int32 and int) surely have different underlying types. I 
wouldn't deny this.
 

>
> 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] tbsp - Spoon-feed your table-based tests!

[Sam Boyer]

Hmm, I hadn't thought about that. But doing that might actually make it 
worth using as a library. There are definitely a couple things I wouldn't 
be able to replicate, but I'll think about it.

In the meantime...PRs welcome :)

On Thursday, August 25, 2016 at 12:41:17 PM UTC-4, Nick Craig-Wood wrote:
>
> On 17/08/16 16:06, Sam Boyer wrote: 
> > OK, so this is kind of a lark, but to celebrate the new subtesting 
> > system  
>
> > in Go 1.7, I fired out a quick lib for executing table-based 
> > tests https://github.com/sdboyer/tbsp. 
> > 
> > The implementation is pretty trivial, so I hardly expect people to 
> > actually import it. But, it's a nice little demonstration of what I 
> > think table-based testing should generally start to look like, now that 
> > subtests are a thing. 
> > 
> > Sorry if there's already something out there like this - I totally 
> > missed that subtests were coming in 1.7 until I saw the release notes, 
> > so I'm playing catchup. 
>
> Could you do a backwards compatibility mode so it would work in go 1.5 
> and 1.6?  If so that would be really useful! 
>
> -- 
> Nick Craig-Wood  -- 
> http://www.craig-wood.com/nick 
>

-- 
You received this message because you are subscribed to the Google 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 uppercase relevant at all for labels

[Ian Lance Taylor]

On Fri, Aug 26, 2016 at 2:12 PM, Jonathan Frisco  wrote:
> I'm relatively new to Go, so this may be an obvious question, but I couldn't
> find the answer by searching...
>
> All examples of statement labels I have seen (e.g.
> https://golang.org/ref/spec#Break_statements) use labels where the first
> character of the label name is capitalized, as if they are intended to be
> exported.  Docs I have read do not state this as a requirement that I can
> find, and I have read that labels are specifically not exported (as an
> exception to the rule that capitalized first letter = exported).
>
> So, is this merely a stylistic convention, or am I missing something?

It's just a style convention.  Whether a label is capitalized or not
has no effect.  Same for a local variable, for that matter.

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] Is uppercase relevant at all for labels

[Jonathan Frisco]

I'm relatively new to Go, so this may be an obvious question, but I 
couldn't find the answer by searching...

All examples of statement labels I have seen (e.g. 
https://golang.org/ref/spec#Break_statements) use labels where the first 
character of the label name is capitalized, as if they are intended to be 
exported.  Docs I have read do not state this as a requirement that I can 
find, and I have read that labels are specifically not exported (as an 
exception to the rule that capitalized first letter = exported).

So, is this merely a stylistic convention, or am I missing something?

-- 
You received this message because you are subscribed to the Google 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: Why can't convert []T to []T2 if T2 is a copy definition of T?

[Volker Dobler]

Am Freitag, 26. August 2016 21:13:16 UTC+2 schrieb xiio...@gmail.com:
>
> *[...] *I haven't checked the compiler code for this but would bet that 
> currently there is no step disallowing such an assignment.
>

Well, there is. As you noticed you cannot assign []Age to []int because
the compiler complains. So by matter of fact there is a step which
disallows it.

I'm curiously following your post but I have to admit I cannot
make much sense of them. There is a language specification
which describes what is allowed and what not. That is not really
uncommon, there are specifications for most other languages
starting from what a Turing machine is and which transitions
are allowed to Brainfuck, various assembly languages, the whole
C-family with various dialect of C, C++, Java, the Lisp-family,
Haskell, you name it. All are governed by a specification and
none allows everything which might be technically feasible. Like
everything in life there are tradeoffs and different people make
different tradeoffs. The Go creators decided on a set of tradeoffs.
I think it is okay to ask _why_ it was decided this or that way, this
helps understanding the language and it's intentions. Several
people with deep understanding of the language itself and how it
is implemented explained to you the rationale behind various
decisions taken during the design of the language specification
and I'm feeling uncomfortable with your harsh rejections of any
explanation given. Especially if rejected based on guessing or
betting.

V.

-- 
You received this message because you are subscribed to the Google 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: Why can't convert []T to []T2 if T2 is a copy definition of T?

[Volker Dobler]

Ahhrg, sorry, sorry, sorry!
My reply to this message should have gone to the last one of user T L
not yours.

I'd like to blame the Web UI, but it was just me being lazy. Sorry.

V.

Am Freitag, 26. August 2016 21:13:16 UTC+2 schrieb xiio...@gmail.com:
>
> *"I feel the effort is made to forbid converting []Age into []int instead 
> now."*
>
> I don't agree that allowing this conversion would be 'easier' than not 
> allowing.
>
> Allowing it requires the additional step of splitting/extracting from the 
> slice the element type and checking that (for assignability)
>
> I am fairly certain that currently that step isn't performed and the slice 
> is treated as a type unto itself, not as some sort of "composite type"
>
> It is/would be an extra step to achieve what is suggested in the original 
> example.
>
> I feel you are asking for extra recursion in the type analysis the 
> compiler does.
>
> I haven't checked the compiler code for this but would bet that currently 
> there is no step disallowing such an assignment.
>

-- 
You received this message because you are subscribed to the Google 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: Why can't convert []T to []T2 if T2 is a copy definition of T?

[xiiophen]

As an aside - there is a complication to this if this (original post) were 
allowed/added to the language specification


var (
a  float32   = 1.0
aa []float32 = []float32{1.0, 2.0, 3.0}
)

b := float64(a)   //is ok
bb := ([]float64)(aa) //not ok


If the second conversion bb was allowed it would require a lot of extra 
magic work underneath -as a new slice would have to be created, large 
enough to store float64s - not just a case of changing the slice header to 
point at a new type.

So in reference to the original example - either extra code would have to 
be added to do this work, or these cases of type conversion would have to 
be dissallowed for slices.. Either way that's more compiler code, not less. 

-- 
You received this message because you are subscribed to the Google 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: Why can't convert []T to []T2 if T2 is a copy definition of T?

[xiiophen]

*"I feel the effort is made to forbid converting []Age into []int instead 
now."*

I don't agree that allowing this conversion would be 'easier' than not 
allowing.

Allowing it requires the additional step of splitting/extracting from the 
slice the element type and checking that (for assignability)

I am fairly certain that currently that step isn't performed and the slice 
is treated as a type unto itself, not as some sort of "composite type"

It is/would be an extra step to achieve what is suggested in the original 
example.

I feel you are asking for extra recursion in the type analysis the compiler 
does.

I haven't checked the compiler code for this but would bet that currently 
there is no step disallowing such an assignment.

-- 
You received this message because you are subscribed to the Google 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 can't convert []T to []T2 if T2 is a copy definition of T?

[T L]

On Saturday, August 27, 2016 at 1:43:03 AM UTC+8, Axel Wagner wrote:
>
> The effort is putting a special case into the language for this. 
>

I feel the effort is made to forbid converting []Age into []int instead now.
 

>
> On Fri, Aug 26, 2016 at 7:11 PM, T L  
> wrote:
>
>>
>>
>> On Saturday, August 27, 2016 at 12:36:58 AM UTC+8, Axel Wagner wrote:
>>>
>>> There is none. It would be perfectly possible and reasonable to make 
>>> this possible, but it probably didn't seem worth the effort to introduce 
>>> this special case into the language which has such a limited use. If you 
>>> can't live without, you can always use unsafe to do it yourself (though, of 
>>> course, that's unsafe).
>>>
>>
>> What effort needs to make to convert []Age into []int? 
>>  
>>
>>>
>>> On Fri, Aug 26, 2016 at 6:09 PM, T L  wrote:
>>>


 On Saturday, August 27, 2016 at 12:05:28 AM UTC+8, Jan Mercl wrote:
>
>
>
> On Fri, Aug 26, 2016, 17:59 T L  wrote:
>
>>
>>
>>> -- 
>>>
>>
>> why the underlying types of []Age and []int are not the same.
>>
>
> The underlying type of an anonymous type []T is []T.
>
>
>
 What are differences between memory layouts of []Age and []int?
  

> -- 
>
> -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...@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] Why can't convert []T to []T2 if T2 is a copy definition of T?

['Axel Wagner' via golang-nuts]

The effort is putting a special case into the language for this.

On Fri, Aug 26, 2016 at 7:11 PM, T L  wrote:

>
>
> On Saturday, August 27, 2016 at 12:36:58 AM UTC+8, Axel Wagner wrote:
>>
>> There is none. It would be perfectly possible and reasonable to make this
>> possible, but it probably didn't seem worth the effort to introduce this
>> special case into the language which has such a limited use. If you can't
>> live without, you can always use unsafe to do it yourself (though, of
>> course, that's unsafe).
>>
>
> What effort needs to make to convert []Age into []int?
>
>
>>
>> On Fri, Aug 26, 2016 at 6:09 PM, T L  wrote:
>>
>>>
>>>
>>> On Saturday, August 27, 2016 at 12:05:28 AM UTC+8, Jan Mercl wrote:



 On Fri, Aug 26, 2016, 17:59 T L  wrote:

>
>
>> --
>>
>
> why the underlying types of []Age and []int are not the same.
>

 The underlying type of an anonymous type []T is []T.



>>> What are differences between memory layouts of []Age and []int?
>>>
>>>
 --

 -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...@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] Why can't convert []T to []T2 if T2 is a copy definition of T?

['Axel Wagner' via golang-nuts]

There is none. It would be perfectly possible and reasonable to make this
possible, but it probably didn't seem worth the effort to introduce this
special case into the language which has such a limited use. If you can't
live without, you can always use unsafe to do it yourself (though, of
course, that's unsafe).

On Fri, Aug 26, 2016 at 6:09 PM, T L  wrote:

>
>
> On Saturday, August 27, 2016 at 12:05:28 AM UTC+8, Jan Mercl wrote:
>>
>>
>>
>> On Fri, Aug 26, 2016, 17:59 T L  wrote:
>>
>>>
>>>
 --

>>>
>>> why the underlying types of []Age and []int are not the same.
>>>
>>
>> The underlying type of an anonymous type []T is []T.
>>
>>
>>
> What are differences between memory layouts of []Age and []int?
>
>
>> --
>>
>> -j
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Why can't convert []T to []T2 if T2 is a copy definition of T?

[T L]

On Saturday, August 27, 2016 at 12:05:28 AM UTC+8, Jan Mercl wrote:
>
>
>
> On Fri, Aug 26, 2016, 17:59 T L  wrote:
>
>>
>>
>>> -- 
>>>
>>
>> why the underlying types of []Age and []int are not the same.
>>
>
> The underlying type of an anonymous type []T is []T.
>
>
>
What are differences between memory layouts of []Age and []int?
 

> -- 
>
> -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] Why can't convert []T to []T2 if T2 is a copy definition of T?

[Jan Mercl]

On Fri, Aug 26, 2016, 17:59 T L  wrote:

>
>
>> --
>>
>
> why the underlying types of []Age and []int are not the same.
>

The underlying type of an anonymous type []T is []T.


-- 

-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] Why can't convert []T to []T2 if T2 is a copy definition of T?

[Jan Mercl]

On Fri, Aug 26, 2016, 17:45 T L  wrote:

>
>
> package main
>
> type Age int
>
> func main() {
> var ages = []Age{17, 18, 19}
> var ints = ([]int)(ages) // error: cannot convert ages (type []Age) to
> type []int
> _ = ints
> }
>

Because Go is a type safe language. []T and []T2 have different element
types and different underlying types, so in the general case the conversion
would not be type safe. Also, again in the general case, the memory layout
of the backing arrays of []T and []T2 are not the same.
-- 

-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] Why can't convert []T to []T2 if T2 is a copy definition of T?

[T L]

package main

type Age int

func main() {
var ages = []Age{17, 18, 19}
var ints = ([]int)(ages) // error: cannot convert ages (type []Age) to 
type []int
_ = ints
}

-- 
You received this message because you are subscribed to the Google 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: net.Conn.Write is failing in golang

[Aliaksandr Valialkin]

It looks like there is a timeout (aka deadline) set on the connection, so 
small responses are sent without problems, while large responses are 
interrupted by the timeout. 
See https://blog.cloudflare.com/the-curious-case-of-slow-downloads/ for 
details.

On Thursday, January 28, 2016 at 7:06:38 PM UTC+2, vijayan jay wrote:
>
> We are using net.Conn.Write(response) in our program were response is a 
> json data of length 84317829 bytes.
> Is there any chance for failure of write in golang when length of data is 
> more ?
> Because i could see that in one more scenario when length is 3585632 then 
> write is working fine.
>
> I have copied the error which i printed in the program,
> (EXTRA string=write tcp 127.0.0.1:3988->127.0.0.1:28459: write: broken 
> pipe)
>
> So could you please help here what could be reason for this issue ?
>
> Please let me know if you need any other information.
>

-- 
You received this message because you are subscribed to the Google 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: Why a **T value can't call methods of *T and T if a *T value can call methods of T?

[T L]

On Thursday, August 25, 2016 at 9:30:01 PM UTC+8, xiio...@gmail.com wrote:
>
> I get the original points. Though the current behaviour is in my opinion 
> consistent with https://golang.org/ref/spec#Method_declarations 
> "[Receiver] must be of the form T or *T (possibly using parentheses) where 
> T is a type name" and https://golang.org/ref/spec#Method_sets I can see 
> the case for extending methods to include any depth of indirection.
>
> Though I've never had a use case for methods on **T, it's clear that **T 
> 's can have real uses.
>
> If a language extension was requested, which behaviour would you prefer 
> for the method sets
>
> ie
>
> ***T has methods of ***T, **T, *T, T
> or
> ***T has methods of just ***T and **T
> ?
>

They are the same.
 

-- 
You received this message because you are subscribed to the Google 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: totalling a column in a html template.

[Asit Dhal]

Hi,
If you really need to calculate total, you should leave that completely to
the view layer(client side java script).


On Fri, Aug 26, 2016 at 8:55 AM, Simon Ritchie 
wrote:

> If you follow the Model View Controller (MVC) model, you should do all of
> the clever stuff in your controller and just use the view to render the
> result.
>
> When you invoke the view, you pass a structure with it contains the data
> to display.  The trick is to design your structure to contain all the data
> that the views needs.  In your case that might be a structure containing a
> total and a slice containing numbers.  In the view you iterate through the
> slice displaying each number, and then display the total.  If you want
> several columns then you might pass a structure containing a total and a
> slice of structures, where each structure contains the values for one row.
>
> Another typical example of this kind of thing is a page that contains some
> validated data with error messages.  In that case, your structure would
> contain the data and the error messages.
>
> --
> You received this message because you are subscribed to the Google 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: totalling a column in a html template.

[Aliaksandr Valialkin]

Hi Carl,

try quicktemplate  instead of 
html/template. It supports arbitrary data transformations inside the 
template code, so the 'totals' row may be easily implemented without 
external code:

Suppose you have the following row struct:

type Row struct {
URL string
Hits int
TimeSum time.Duration
}


Then the template function generating HTML table for the given rows may 
look like:

{% func TableWithTotals(rows []Row) %}
{% code
// declare ordinary Go variables inside template for calculating the 
'totals' row.
var (
hitsSum int
timeSum time.Duration
)

// Arbitrary data transformations may be performed here via usual Go 
code.
// For instance, rows may be sorted, filtered, aggregated and sliced 
before outputting
// them in the template.
%}



  
  #
  URL
  Hits
  Avg request duration
  

  {% for i, r := range rows %}
  {% code
  // increment totals
  hitsSum += r.Hits
  timeSum += r.TimeSum
  %}
  
  {%d i %}
  {%s r.URL %}
  {%d r.Hits %}
  {%v r.TimeSum / time.Duration(r.Hits) %}
  
  {% endfor %}

  
  Totals
  
  {%d hitsSum %}
  {%v timeSum / time.Duration(hitsSum) %}
  


{% endfunc %}



On Friday, August 26, 2016 at 1:14:11 PM UTC+3, Carl Ranson wrote:
>
>
> Ok, 
>
> Thanks for the answers. I've gone down the route of adding totals to my 
> data structure. 
>
> cheers, 
> CR.
>
>

-- 
You received this message because you are subscribed to the Google 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] runtime: split stack overflow

[Ian Lance Taylor]

On Fri, Aug 26, 2016 at 7:36 AM,   wrote:
>> Interesting.  Maybe we need to change this line in setsig in
>> runtime/os_darwin.go
>> *(*uintptr)(unsafe.Pointer(__sigaction_u)) = fn
>> to be
>> *(*uintptr)(unsafe.Pointer(__sigaction_u)) =
>> unsafe.Pointer(funcPC(sigtramp))
>
>
> That's not possible, the signatures of sa_tramp and sa_sigaction do not
> match:
>
> /* union for signal handlers */
> union __sigaction_u {
> void (*__sa_handler)(int);
> void (*__sa_sigaction)(int, struct __siginfo *, void *);
> };
>
> /* Signal vector template for Kernel user boundary */
> struct __sigaction {
> union __sigaction_u __sigaction_u; /* signal handler */
> void (*sa_tramp)(void *, int, int, siginfo_t *, void *);
> sigset_t sa_mask; /* signal mask to apply */
> int sa_flags; /* see signal options below */
> };

Good point.  OK, then perhaps we need setsig in os_darwin.go to set
the sigaction field to a new function, written in assembler, like
sigtramp, but taking just the sigaction arguments.  And presumably not
calling sigreturn.

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] runtime: split stack overflow

[martin . strenge]

>
> Interesting.  Maybe we need to change this line in setsig in 
> runtime/os_darwin.go 
> *(*uintptr)(unsafe.Pointer(__sigaction_u)) = fn 
> to be 
> *(*uintptr)(unsafe.Pointer(__sigaction_u)) = 
> unsafe.Pointer(funcPC(sigtramp))  
>

That's not possible, the signatures of sa_tramp and sa_sigaction do not 
match:

/* union for signal handlers */ 
union __sigaction_u { 
void (*__sa_handler)(int);
void (*__sa_sigaction)(int, struct __siginfo *, void *);
}; 

/* Signal vector template for Kernel user boundary */
struct __sigaction {
union __sigaction_u __sigaction_u; /* signal handler */ 
void (*sa_tramp)(void *, int, int, siginfo_t *, void *);
sigset_t sa_mask; /* signal mask to apply */
int sa_flags; /* see signal options below */
}; 

Martin 

-- 
You received this message because you are subscribed to the Google 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 the future, how to keep runtime.KeepAlive from dead code elimination?

[Ian Lance Taylor]

On Fri, Aug 26, 2016 at 2:56 AM, Cholerae Hu  wrote:
> I'm curious that how does compiler recognize runtime.KeepAlive specially?

The compiler already recognizes some functions specially, most notably
math.Sqrt.  Search for "Sqrt" in cmd/compile/internal/gc/walk.go.

Ian

> 在 2016年8月26日星期五 UTC+8上午12:04:57，Ian Lance Taylor写道：
>>
>> On Thu, Aug 25, 2016 at 12:15 AM, Cholerae Hu  wrote:
>> > Does that mean that only inlined functions will be optimized and any
>> > functions not inlined will not be optimized ?
>>
>> I'm not really sure what you are asking.
>>
>> A function that is not inlined will not be inlined.  That is
>> sufficient to ensure that runtime.KeepAlive works as intended.
>>
>> A function that is not inlined, for whatever reason, will still be
>> optimized as usual.
>>
>> Ian
>>
>> > 在 2016年8月25日星期四 UTC+8上午11:55:12，Ian Lance Taylor写道：
>> >>
>> >> On Wed, Aug 24, 2016 at 7:06 PM, Cholerae Hu 
>> >> wrote:
>> >> >
>> >> > I've read the source of package runtime, and found that
>> >> > runtime.KeepAlive is
>> >> > an empty function. If go compiler can do dead code elimination in the
>> >> > future, how to protect runtime.KeepAlive from being optimized?
>> >>
>> >> The KeepAlive function is marked with the magic go:noinline comment,
>> >> so it can't be inlined.
>> >>
>> >> In any case it seems possible that the compiler will recognize the
>> >> function specially in the future, for greater efficiency.
>> >>
>> >> 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.

Re: [go-nuts] runtime: split stack overflow

[Ian Lance Taylor]

On Fri, Aug 26, 2016 at 6:35 AM,   wrote:
>
> The reason for the morestack call is, that sigtramp is not called in my code
> example. The sa_tramp seems to be overwritten in my call to
> sigaction(int,struct sigaction*,struct sigaction*) and I cannot retrieve the
> original trampoline function via __sigaction(int, struct __sigaction*,
> struct sigaction*), to call it in my handler. Calling it directly would
> probably not work anyway, as sigtrampgo already calls sigreturn, but I want
> to be able to do calculations in the C handler if the Go handler has
> returned. So, I'm quite stuck here. Do you have any ideas?

Interesting.  Maybe we need to change this line in setsig in
runtime/os_darwin.go
*(*uintptr)(unsafe.Pointer(__sigaction_u)) = fn
to be
*(*uintptr)(unsafe.Pointer(__sigaction_u)) =
unsafe.Pointer(funcPC(sigtramp))

We really don't ever want to call fn here.

Ian

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

Re: [go-nuts] runtime: split stack overflow

[martin . strenge]

Hi,

It took a while to understand what's going on.
 

> I'm not sure which part of the os/signal docs you are thinking of. 


I'm referring to "Go programs that use cgo or SWIG", last paragraph ("If 
the Go signal handler is invoked on a non-Go thread not running Go code 
[...]"). I couldn't get any information about the crash in C from the Go 
signal handler. It remained silent and just quitted the program.

Crashes in Go code will work regardless of whether they are running on 

threads started by C or not.  So I assume you are talking about 
> crashes in C.  How do you want to handle those crashes?  Do you just 
> want to try to dump the stack?  How do you want to handle other C 
> threads when one C thread crashes? 
>

Yes, I meant crashes in C. I want to create a crash dump file and dump all 
C threads and Go routines. 

I do agree that your code should work in principle, and I'm not sure 
> why it doesn't. 
>
> If all you wan to do is handle SIGSEGV when it occurs in a C thread, 
> it may work to call signal.Notify(c, syscall.SIGSEGV).  The channel 
> will receive a signal wen a SIGSEGV occurs in C code.  At that point 
> it's not safe to continue, but it is safe to take whatever action you 
> like to dump C threads.  I'm not sure this will work, because it 
> depends on what happens when the SIGSEGV signal handler returns to the 
> C code that triggered the SIGSEGV. 
>

The reason for the morestack call is, that sigtramp is not called in my 
code example. The sa_tramp seems to be overwritten in my call to 
sigaction(int,struct sigaction*,struct sigaction*) and I cannot retrieve 
the original trampoline function via __sigaction(int, struct __sigaction*, 
struct sigaction*), to call it in my handler. Calling it directly would 
probably not work anyway, as sigtrampgo already calls sigreturn, but I want 
to be able to do calculations in the C handler if the Go handler has 
returned. So, I'm quite stuck here. Do you have any ideas?

I will open another thread to discuss the "correct way" to create a crash 
dump file for Go and C, and discuss my experiments. I'll leave this thread 
for the signal handler replacement on Darwin.

Thanks!
Martin

-- 
You received this message because you are subscribed to the Google 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: net.Conn.Write is failing in golang

[James Bardin]

On Fri, Aug 26, 2016 at 5:46 AM,  wrote:

> I found it's hard to match *this particular error (*"broken pipe"*)*, and
> handle it accordingly, is there a solution?
>


What do you want to do with this particular error? How would you handle it
differently than any other permanent error?

The error is exactly the same as you would encounter using the C socket
api, on linux it's syscall.EPIPE.

-- 
You received this message because you are subscribed to the Google 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: net.Conn.Write is failing in golang

[siliang . cao]

I found it's hard to match *this particular error (*"broken pipe"*)*, and 
handle it accordingly, is there a solution?

On Friday, January 29, 2016 at 1:06:38 AM UTC+8, vijayan jay wrote:
>
> We are using net.Conn.Write(response) in our program were response is a 
> json data of length 84317829 bytes.
> Is there any chance for failure of write in golang when length of data is 
> more ?
> Because i could see that in one more scenario when length is 3585632 then 
> write is working fine.
>
> I have copied the error which i printed in the program,
> (EXTRA string=write tcp 127.0.0.1:3988->127.0.0.1:28459: write: broken 
> pipe)
>
> So could you please help here what could be reason for this issue ?
>
> Please let me know if you need any other information.
>

-- 
*Grab is hiring. Learn more at **https://grab.careers 
*

By communicating with Grab Inc and/or its subsidiaries, associate companies 
and jointly controlled entities (“Grab Group”), you are deemed to have 
consented to processing of your personal data as set out in the Privacy 
Notice which can be viewed at https://grab.com/privacy/

This email contains confidential information and is only for the intended 
recipient(s). If you are not the intended recipient(s), please do not 
disseminate, distribute or copy this email and notify Grab Group 
immediately if you have received this by mistake and delete this email from 
your system. Email transmission cannot be guaranteed to be secure or 
error-free as any information therein could be intercepted, corrupted, 
lost, destroyed, delayed or incomplete, or contain viruses. Grab Group do 
not accept liability for any errors or omissions in the contents of this 
email arises as a result of email transmission. All intellectual property 
rights in this email and attachments therein shall remain vested in Grab 
Group, unless otherwise provided by law.

-- 
You received this message because you are subscribed to the Google 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] Continous Inspection of Go Code Quality

[DM]

Is there any tool available in GoLang for the Continuous Inspection of code 
quality something similar to SonarQube ?

-- 
You received this message because you are subscribed to the Google 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 the future, how to keep runtime.KeepAlive from dead code elimination?

[Dave Cheney]

runtime/mfinal.go:464

On Friday, 26 August 2016 19:56:49 UTC+10, Cholerae Hu wrote:
>
> I'm curious that how does compiler recognize runtime.KeepAlive specially?
>
> 在 2016年8月26日星期五 UTC+8上午12:04:57，Ian Lance Taylor写道：
>>
>> On Thu, Aug 25, 2016 at 12:15 AM, Cholerae Hu  
>> wrote: 
>> > Does that mean that only inlined functions will be optimized and any 
>> > functions not inlined will not be optimized ? 
>>
>> I'm not really sure what you are asking. 
>>
>> A function that is not inlined will not be inlined.  That is 
>> sufficient to ensure that runtime.KeepAlive works as intended. 
>>
>> A function that is not inlined, for whatever reason, will still be 
>> optimized as usual. 
>>
>> Ian 
>>
>> > 在 2016年8月25日星期四 UTC+8上午11:55:12，Ian Lance Taylor写道： 
>> >> 
>> >> On Wed, Aug 24, 2016 at 7:06 PM, Cholerae Hu  
>> wrote: 
>> >> > 
>> >> > I've read the source of package runtime, and found that 
>> >> > runtime.KeepAlive is 
>> >> > an empty function. If go compiler can do dead code elimination in 
>> the 
>> >> > future, how to protect runtime.KeepAlive from being optimized? 
>> >> 
>> >> The KeepAlive function is marked with the magic go:noinline comment, 
>> >> so it can't be inlined. 
>> >> 
>> >> In any case it seems possible that the compiler will recognize the 
>> >> function specially in the future, for greater efficiency. 
>> >> 
>> >> 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: totalling a column in a html template.

[Carl Ranson]

Ok, 

Thanks for the answers. I've gone down the route of adding totals to my 
data structure. 

cheers, 
CR.

-- 
You received this message because you are subscribed to the Google 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 the future, how to keep runtime.KeepAlive from dead code elimination?

[Cholerae Hu]

I'm curious that how does compiler recognize runtime.KeepAlive specially?

在 2016年8月26日星期五 UTC+8上午12:04:57，Ian Lance Taylor写道：
>
> On Thu, Aug 25, 2016 at 12:15 AM, Cholerae Hu  > wrote: 
> > Does that mean that only inlined functions will be optimized and any 
> > functions not inlined will not be optimized ? 
>
> I'm not really sure what you are asking. 
>
> A function that is not inlined will not be inlined.  That is 
> sufficient to ensure that runtime.KeepAlive works as intended. 
>
> A function that is not inlined, for whatever reason, will still be 
> optimized as usual. 
>
> Ian 
>
> > 在 2016年8月25日星期四 UTC+8上午11:55:12，Ian Lance Taylor写道： 
> >> 
> >> On Wed, Aug 24, 2016 at 7:06 PM, Cholerae Hu  
> wrote: 
> >> > 
> >> > I've read the source of package runtime, and found that 
> >> > runtime.KeepAlive is 
> >> > an empty function. If go compiler can do dead code elimination in the 
> >> > future, how to protect runtime.KeepAlive from being optimized? 
> >> 
> >> The KeepAlive function is marked with the magic go:noinline comment, 
> >> so it can't be inlined. 
> >> 
> >> In any case it seems possible that the compiler will recognize the 
> >> function specially in the future, for greater efficiency. 
> >> 
> >> 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] Call COM object method from Go without CGo

[lars.scheme via golang-nuts]

I have created a Direct3D9 wrapper in Go which uses CGo to interface with 
the COM objects in C. (https://github.com/gonutz/d3d9)

I would like to get rid of the dependency on a C-compiler under Windows so 
the user would not have to install MinGW or Cygwin to use DirectX from Go.

The problem is that d3d9.dll does not expose C-functions but uses COM. The 
only function that can be called directly after loading the DLL (with 
syscall.LoadLibrary("d3d9.dll")) is Direct3DCreate9. This returns a COM 
object which exposes all functionality as methods.

How can I call COM object methods in a DLL from pure Go without CGo?

I know of the Go-OLE library (https://github.com/go-ole/go-ole) which 
states it calls COM interfaces without CGo but I cannot, from the sources, 
see how I would go about doing the same thing for Direct3D9. A simple 
example with only the relevant parts would be of great help.

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

[dc0d]

Yes; it seemed to me that the return statement would get evaluated even 
after a panic. I thought of it as a special case of a deferred context - 
confused.

Thank you very much;

On Friday, August 26, 2016 at 12:11:03 PM UTC+4:30, Axel Wagner wrote:
>
> I'd think, the spec is reasonably unambiguous, if not very explicit. The 
> second version works, because of
>
> For instance, if the deferred function is a function literal and the 
>> surrounding function has named result parameters that are in scope within 
>> the literal, the deferred function may access and modify the result 
>> parameters before they are returned.
>
>
> and
>
> The recover function allows a program to manage behavior of a panicking 
>> goroutine. Suppose a function G defers a function D that calls recover and 
>> a panic occurs in a function on the same goroutine in which G is executing. 
>> When the running of deferred functions reaches D, the return value of D's 
>> call to recover will be the value passed to the call of panic. If D returns 
>> normally, without starting a new panic, the panicking sequence stops. In 
>> that case, the state of functions called between G and the call to panic is 
>> discarded, and normal execution resumes. Any functions deferred by G before 
>> D are then run and G's execution terminates by returning to its caller.
>
>
> i.e. after recover(), the execution continues as normally and the normal 
> behavior is, that you can modify named return parameters and the modified 
> version will then be returned.
>
> The first version also works as expected: recover() resumes execution as 
> normal and you can modify result and error as wished, but they are just 
> variables, not return values. Thus the function returns with the return 
> parameters unset (as you panic'ed before setting them with return).
>
> If it helps, you can imagine the return values as variables, initialized 
> to their zero values, which can be set in two ways: Either by having a 
> return or by naming them, which gives you direct access. A panic won't 
> modify them, but a defer'ed function might, if they are named. In your 
> first version, you never set them; return isn't called and they are not 
> named. In the second version you do set them; return isn't called, but you 
> name them and set them from the defer'ed function.
>
> Maybe the confusion is about what "after the surrounding function returns" 
> means? Maybe you interpret that as basically a "goto the line of the return 
> statement and execute it", whereas the spec means it as "executing the 
> function epilogue and return control to the caller"? The goto-like 
> interpretation doesn't make sense, in any case; there could be multiple, 
> pairwise contradictory return statements and it wouldn't be clear which is 
> executed.
>
> FWIW I do believe the spec could be clearer here. The behavior seems 
> logical and expected to me, but I do have trouble justifying this intuition 
> with the spec.
>
> On Fri, Aug 26, 2016 at 9:11 AM, dc0d  > wrote:
>
>> There deferred function here has not any return value - to get discarded. 
>> It rather assigns a value to the *closure* *err* variable.
>>
>> Since a defer statement "*invokes a function whose execution is deferred 
>> to the moment the surrounding function returns*", so I expected the *err* 
>> variable should have a value just before the return statement executes.
>>
>> The *err* variable is just a closure. Still I'm confused why the first 
>> version does not behave as expected - because the actual function *is 
>> not invoked yet* at the position of defer statement but just it's 
>> parameters. "*Instead, deferred functions are invoked immediately before 
>> the surrounding function returns*".
>>
>> Why this is not behaving as expected?
>>
>>
>> On Friday, August 26, 2016 at 3:25:11 AM UTC+4:30, Vasko Zdravevski wrote:
>>>
>>> I put your code snippet in the playground for easier sharing: 
>>> https://play.golang.org/p/ZvuNwjS7ZF
>>>
>>> I think the spec has the answer you're looking for regarding how named 
>>> result parameters are handled during a panic.
>>> https://golang.org/ref/spec#Defer_statements
>>>
>>> Specifically the sentence:
>>>
 If the deferred function has any return values, they are discarded when 
 the function completes. (See also the section on handling panics 
 .)

>>>
>>> Also,
>>>
 If the function's signature 
  declares result 
 parameters, the function body's statement list must end in a terminating 
 statement .

>>> https://golang.org/ref/spec#Function_declarations
>>>
>>> And the panic is the 'terminating statement'
>>>
>>> Hope this helps,
>>> Vasko.
>>>
>>> On Thursday, August 25, 2016 at 4:19:17 PM UTC-6, dc0d wrote:

 Assuming we have this test:

 func TestRecover(t *testing.T) {

[go-nuts] Re: Confused about defer

[pierre . curto]

To me this works as expected.

In both your versions, the return statement in Recover() is not even 
reached since the call to f panics. You recover from the panic in your 
defer statement and assign the err variable your error value.

Since in your first version, that variable is not returned, you do not see 
it outside of your Recover() function.
In your second version, the err variable is declared in your function 
signature, so it does get returned, hence why you see it.

Le vendredi 26 août 2016 09:11:19 UTC+2, dc0d a écrit :
>
> There deferred function here has not any return value - to get discarded. 
> It rather assigns a value to the *closure* *err* variable.
>
> Since a defer statement "*invokes a function whose execution is deferred 
> to the moment the surrounding function returns*", so I expected the *err* 
> variable should have a value just before the return statement executes.
>
> The *err* variable is just a closure. Still I'm confused why the first 
> version does not behave as expected - because the actual function *is not 
> invoked yet* at the position of defer statement but just it's parameters. 
> "*Instead, deferred functions are invoked immediately before the 
> surrounding function returns*".
>
> Why this is not behaving as expected?
>
> On Friday, August 26, 2016 at 3:25:11 AM UTC+4:30, Vasko Zdravevski wrote:
>>
>> I put your code snippet in the playground for easier sharing: 
>> https://play.golang.org/p/ZvuNwjS7ZF
>>
>> I think the spec has the answer you're looking for regarding how named 
>> result parameters are handled during a panic.
>> https://golang.org/ref/spec#Defer_statements
>>
>> Specifically the sentence:
>>
>>> If the deferred function has any return values, they are discarded when 
>>> the function completes. (See also the section on handling panics 
>>> .)
>>>
>>
>> Also,
>>
>>> If the function's signature 
>>>  declares result parameters, the function body's statement list must 
>>> end in a terminating statement 
>>> .
>>>
>> https://golang.org/ref/spec#Function_declarations
>>
>> And the panic is the 'terminating statement'
>>
>> Hope this helps,
>> Vasko.
>>
>> On Thursday, August 25, 2016 at 4:19:17 PM UTC-6, dc0d wrote:
>>>
>>> Assuming we have this test:
>>>
>>> func TestRecover(t *testing.T) {
>>>  f := func() (interface{}, error) {
>>>  panic(`TEST`)
>>>  }
>>>  r, e := Recover(f)
>>>  t.Log(r, e)
>>> }
>>>
>>> And two versions of *Recover* function.
>>>
>>> Version 1:
>>> func Recover(f func() (interface{}, error)) (interface{}, error) {
>>>  var result interface{}
>>>  var err error
>>>
>>>  defer func() {
>>>  if e := recover(); e != nil {
>>>  err = errors.Error(fmt.Sprintf("%v", e))
>>>  }
>>>  }()
>>>
>>>  result, err = f()
>>>
>>>  return result, err
>>> }
>>>
>>>
>>> Version 2:
>>> func Recover(f func() (interface{}, error)) (res interface{}, err error) 
>>> {
>>>  defer func() {
>>>  if e := recover(); e != nil {
>>>  err = errors.Error(fmt.Sprintf("%v", e))
>>>  }
>>>  }()
>>>
>>>  res, err = f()
>>>
>>>  return res, err
>>> }
>>>
>>>
>>> *Question:* Why the output of test for Version 1 is * * (*not 
>>> expected/wrong*) but for Version 2 is * TEST* (*as 
>>> expected/correct*)?
>>>
>>> - Go 1.7, Ubuntu 14.04 x64
>>>
>>

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

['Axel Wagner' via golang-nuts]

I'd think, the spec is reasonably unambiguous, if not very explicit. The
second version works, because of

For instance, if the deferred function is a function literal and the
> surrounding function has named result parameters that are in scope within
> the literal, the deferred function may access and modify the result
> parameters before they are returned.


and

The recover function allows a program to manage behavior of a panicking
> goroutine. Suppose a function G defers a function D that calls recover and
> a panic occurs in a function on the same goroutine in which G is executing.
> When the running of deferred functions reaches D, the return value of D's
> call to recover will be the value passed to the call of panic. If D returns
> normally, without starting a new panic, the panicking sequence stops. In
> that case, the state of functions called between G and the call to panic is
> discarded, and normal execution resumes. Any functions deferred by G before
> D are then run and G's execution terminates by returning to its caller.


i.e. after recover(), the execution continues as normally and the normal
behavior is, that you can modify named return parameters and the modified
version will then be returned.

The first version also works as expected: recover() resumes execution as
normal and you can modify result and error as wished, but they are just
variables, not return values. Thus the function returns with the return
parameters unset (as you panic'ed before setting them with return).

If it helps, you can imagine the return values as variables, initialized to
their zero values, which can be set in two ways: Either by having a return
or by naming them, which gives you direct access. A panic won't modify
them, but a defer'ed function might, if they are named. In your first
version, you never set them; return isn't called and they are not named. In
the second version you do set them; return isn't called, but you name them
and set them from the defer'ed function.

Maybe the confusion is about what "after the surrounding function returns"
means? Maybe you interpret that as basically a "goto the line of the return
statement and execute it", whereas the spec means it as "executing the
function epilogue and return control to the caller"? The goto-like
interpretation doesn't make sense, in any case; there could be multiple,
pairwise contradictory return statements and it wouldn't be clear which is
executed.

FWIW I do believe the spec could be clearer here. The behavior seems
logical and expected to me, but I do have trouble justifying this intuition
with the spec.

On Fri, Aug 26, 2016 at 9:11 AM, dc0d  wrote:

> There deferred function here has not any return value - to get discarded.
> It rather assigns a value to the *closure* *err* variable.
>
> Since a defer statement "*invokes a function whose execution is deferred
> to the moment the surrounding function returns*", so I expected the *err*
> variable should have a value just before the return statement executes.
>
> The *err* variable is just a closure. Still I'm confused why the first
> version does not behave as expected - because the actual function *is not
> invoked yet* at the position of defer statement but just it's parameters.
> "*Instead, deferred functions are invoked immediately before the
> surrounding function returns*".
>
> Why this is not behaving as expected?
>
>
> On Friday, August 26, 2016 at 3:25:11 AM UTC+4:30, Vasko Zdravevski wrote:
>>
>> I put your code snippet in the playground for easier sharing:
>> https://play.golang.org/p/ZvuNwjS7ZF
>>
>> I think the spec has the answer you're looking for regarding how named
>> result parameters are handled during a panic.
>> https://golang.org/ref/spec#Defer_statements
>>
>> Specifically the sentence:
>>
>>> If the deferred function has any return values, they are discarded when
>>> the function completes. (See also the section on handling panics
>>> .)
>>>
>>
>> Also,
>>
>>> If the function's signature 
>>>  declares result parameters, the function body's statement list must
>>> end in a terminating statement
>>> .
>>>
>> https://golang.org/ref/spec#Function_declarations
>>
>> And the panic is the 'terminating statement'
>>
>> Hope this helps,
>> Vasko.
>>
>> On Thursday, August 25, 2016 at 4:19:17 PM UTC-6, dc0d wrote:
>>>
>>> Assuming we have this test:
>>>
>>> func TestRecover(t *testing.T) {
>>>  f := func() (interface{}, error) {
>>>  panic(`TEST`)
>>>  }
>>>  r, e := Recover(f)
>>>  t.Log(r, e)
>>> }
>>>
>>> And two versions of *Recover* function.
>>>
>>> Version 1:
>>> func Recover(f func() (interface{}, error)) (interface{}, error) {
>>>  var result interface{}
>>>  var err error
>>>
>>>  defer func() {
>>>  if e := recover(); e != nil {
>>>  err = errors.Error(fmt.Sprintf("%v", e))
>>>  }
>>>  }()
>>>
>>>  

[go-nuts] Re: Confused about defer

[dc0d]

There deferred function here has not any return value - to get discarded. 
It rather assigns a value to the *closure* *err* variable.

Since a defer statement "*invokes a function whose execution is deferred to 
the moment the surrounding function returns*", so I expected the *err* 
variable should have a value just before the return statement executes.

The *err* variable is just a closure. Still I'm confused why the first 
version does not behave as expected - because the actual function *is not 
invoked yet* at the position of defer statement but just it's parameters. 
"*Instead, 
deferred functions are invoked immediately before the surrounding function 
returns*".

Why this is not behaving as expected?

On Friday, August 26, 2016 at 3:25:11 AM UTC+4:30, Vasko Zdravevski wrote:
>
> I put your code snippet in the playground for easier sharing: 
> https://play.golang.org/p/ZvuNwjS7ZF
>
> I think the spec has the answer you're looking for regarding how named 
> result parameters are handled during a panic.
> https://golang.org/ref/spec#Defer_statements
>
> Specifically the sentence:
>
>> If the deferred function has any return values, they are discarded when 
>> the function completes. (See also the section on handling panics 
>> .)
>>
>
> Also,
>
>> If the function's signature  
>> declares 
>> result parameters, the function body's statement list must end in a 
>> terminating 
>> statement .
>>
> https://golang.org/ref/spec#Function_declarations
>
> And the panic is the 'terminating statement'
>
> Hope this helps,
> Vasko.
>
> On Thursday, August 25, 2016 at 4:19:17 PM UTC-6, dc0d wrote:
>>
>> Assuming we have this test:
>>
>> func TestRecover(t *testing.T) {
>>  f := func() (interface{}, error) {
>>  panic(`TEST`)
>>  }
>>  r, e := Recover(f)
>>  t.Log(r, e)
>> }
>>
>> And two versions of *Recover* function.
>>
>> Version 1:
>> func Recover(f func() (interface{}, error)) (interface{}, error) {
>>  var result interface{}
>>  var err error
>>
>>  defer func() {
>>  if e := recover(); e != nil {
>>  err = errors.Error(fmt.Sprintf("%v", e))
>>  }
>>  }()
>>
>>  result, err = f()
>>
>>  return result, err
>> }
>>
>>
>> Version 2:
>> func Recover(f func() (interface{}, error)) (res interface{}, err error) 
>> {
>>  defer func() {
>>  if e := recover(); e != nil {
>>  err = errors.Error(fmt.Sprintf("%v", e))
>>  }
>>  }()
>>
>>  res, err = f()
>>
>>  return res, err
>> }
>>
>>
>> *Question:* Why the output of test for Version 1 is * * (*not 
>> expected/wrong*) but for Version 2 is * TEST* (*as expected/correct*
>> )?
>>
>> - Go 1.7, Ubuntu 14.04 x64
>>
>

-- 
You received this message because you are subscribed to the Google 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: totalling a column in a html template.

[Simon Ritchie]

If you follow the Model View Controller (MVC) model, you should do all of the 
clever stuff in your controller and just use the view to render the result.

When you invoke the view, you pass a structure with it contains the data to 
display.  The trick is to design your structure to contain all the data that 
the views needs.  In your case that might be a structure containing a total and 
a slice containing numbers.  In the view you iterate through the slice 
displaying each number, and then display the total.  If you want several 
columns then you might pass a structure containing a total and a slice of 
structures, where each structure contains the values for one row.

Another typical example of this kind of thing is a page that contains some 
validated data with error messages.  In that case, your structure would contain 
the data and the error messages.

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