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

[go-nuts] http.Transport and too many connection problem.

[bronze man]

As I can see from the comment of http.Transport :

// Transports should be reused instead of created as needed.

The comment telled me that I need reuse the transports.

But i am writing a rpc system that the caller can pass different dialler to 
make http request.
It almost impossible for my rpc package implementer to reuse the transports 
object.
And the caller of my rpc package do not want to reuse the object either.

So the workaround to those complex stuff is to disable the keep alive in 
http.Transport by default(the caller can open it if them reuse the object).

So How can I simplify this reuse stuff?
If I disable keepAlive, can http.Transport be gc? 

* If I store the transports in an map, I can not know which dialler is same 
as another.
* I can set the IdleConnTimeout to 60*time.Second.But I looks useless if 
the callers just create new object again and again.

-- 
You received this message because you are subscribed to the Google 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] Syntax errors involving compound literals

[sbkim via golang-nuts]

On Wednesday, August 24, 2016 at 10:22:22 PM UTC-7, Ian Lance Taylor wrote:
>
> On Wed, Aug 24, 2016 at 9:21 PM, sbkim via golang-nuts 
> > wrote: 
> > Hello group, 
> > 
> > Why are the following snippets errors? 
> > 
> > https://play.golang.org/p/mgEYMNNw9h 
> > type S struct { 
> >  i int 
> > } 
> > 
> >  if S{i: 0} == S{} { 
> >  } 
> > syntax error: unexpected == at end of statement 
> > 
> >  switch S{i: 0} == S{} { 
> >  } 
> > syntax error: unexpected i, expecting case or default or } 
> > 
> > It works without error if you surround each literal with ( ), or the 
> entire 
> > comparison expression with ( ). 
> > The following also works without error: 
> >  _ = S{i: 0} == S{} 
> > 
> > Does the language spec state those are errors, or is this a bug in the 
> > parser? 
>
> Search for "parsing ambiguity" in 
> https://golang.org/ref/spec#Composite_literals . 
>

Why hadn't I found that? Thanks for the pointer!

I guess this has to do with the fact that the parser doesn't care whether S 
is a type name or not.

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

[Vasko Zdravevski]

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] Confused about defer

[dc0d]

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: text/scanner: scan() vs peek()

[DrGo]

Thanks Sam,
I managed without a token_peek(). It just leads to more verbose code with 
calls to scan() and switches everywhere.

On Thursday, August 25, 2016 at 10:52:54 PM UTC+1, Sam Whited wrote:
>
> On Thu, Aug 25, 2016 at 2:09 PM, DrGo > 
> wrote: 
> > Ok! So my original post was not clear. Let us say you just executed 
> scan() twice on this string: a= x 
> > As expected, Scan() returned scanner.Ident for a, followed by a rune 
> indicating the = sign. 
> > Now, peek() will return 32 for the space whereas scan() returns 
> scanner.Ident for the identifier x. Peek() essentially returns the next 
> rune whereas scan() returns the next token which may or may not be a rune, 
> e.g., it could be an identifierm an iinteger or an page-length raw string. 
> > Finally, Next() advances the parser reading the next rune, so it is the 
> scanning equivalent of peek(). 
> > My question, should not there be a func that is equivalent in behaviour 
> to scan() except that it doesn't advance the scanner? 
>
> Ah, I see what you're asking. I'm not sure that I have a good answer 
> for that off the top of my head other than "that's not what Peek is 
> for". Peeking at an entire token would be a waste of time and 
> generally isn't something you need to do; peeking at a character (eg. 
> is the next character a '<' or a '>' or are we at the end of a line, 
> '\n') is more useful when rapidly scanning and lets us make common 
> decisions earlier than we would otherwise need too while saving a scan 
> call. 
>
> I'm sure someone who knows more about lexing can provide you with a 
> better answer though. 
>
> —Sam 
>

-- 
You received this message because you are subscribed to the Google 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: text/scanner: scan() vs peek()

[Sam Whited]

On Thu, Aug 25, 2016 at 2:09 PM, DrGo  wrote:
> Ok! So my original post was not clear. Let us say you just executed scan() 
> twice on this string: a= x
> As expected, Scan() returned scanner.Ident for a, followed by a rune 
> indicating the = sign.
> Now, peek() will return 32 for the space whereas scan() returns scanner.Ident 
> for the identifier x. Peek() essentially returns the next rune whereas scan() 
> returns the next token which may or may not be a rune, e.g., it could be an 
> identifierm an iinteger or an page-length raw string.
> Finally, Next() advances the parser reading the next rune, so it is the 
> scanning equivalent of peek().
> My question, should not there be a func that is equivalent in behaviour to 
> scan() except that it doesn't advance the scanner?

Ah, I see what you're asking. I'm not sure that I have a good answer
for that off the top of my head other than "that's not what Peek is
for". Peeking at an entire token would be a waste of time and
generally isn't something you need to do; peeking at a character (eg.
is the next character a '<' or a '>' or are we at the end of a line,
'\n') is more useful when rapidly scanning and lets us make common
decisions earlier than we would otherwise need too while saving a scan
call.

I'm sure someone who knows more about lexing can provide you with a
better answer though.

—Sam

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

Re: [go-nuts] Why does context.CancelFunc exist?

[Sam Whited]

On Thu, Aug 25, 2016 at 2:08 PM, Nate Finch  wrote:
> The type seems unnecessary.  It doesn't actually do anything different than
> a regular func().

You are correct that the behavior of the function doesn't differ, but
then again behavior isn't necessarily the point of the type system.
Having this be a type allows us to ensure that our methods only take
functions which we know cancel contexts (because they were returned by
one of the context methods or explicitly created by us for that
purpose). Also, If we're checking the underlying type of an empty
interface, checking if the underlying value is a CancelFunc is more
specific than just checking if it's any old func().

I think it's more about semantics and being explicit than it is about behavior.


> Also, how come WithCancel has named return values but WithDeadline and
> WithTimeout don't?

Glancing at the source there's no reason it needs to be. Probably just
because it was done this way originally, and it stuck around.

—Sam


-- 
Sam Whited
pub 4096R/54083AE104EA7AD3

-- 
You received this message because you are subscribed to the Google 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 protocol proxy, best practices

[Tamás Gulácsi]

Check out go4.org/syncutil for Gate to limit concurrency with ease.

-- 
You received this message because you are subscribed to the Google 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: text/scanner: scan() vs peek()

[DrGo]

Ok! So my original post was not clear. Let us say you just executed scan() 
twice on this string: a= x
As expected, Scan() returned scanner.Ident for a, followed by a rune indicating 
the = sign.
Now, peek() will return 32 for the space whereas scan() returns scanner.Ident 
for the identifier x. Peek() essentially returns the next rune whereas scan() 
returns the next token which may or may not be a rune, e.g., it could be an 
identifierm an iinteger or an page-length raw string.
Finally, Next() advances the parser reading the next rune, so it is the 
scanning equivalent of peek().
My question, should not there be a func that is equivalent in behaviour to 
scan() except that it doesn't advance the scanner?

Thanks 

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

[go-nuts] Why does context.CancelFunc exist?

[Nate Finch]

The type seems unnecessary.  It doesn't actually do anything different than 
a regular func().  Does it just exist to give a place for common 
documentation for each of the methods that use it?

IMO, the With* functions would be more clear if they didn't use a named 
type for func(), because now when I look at WithDeadline, I have to then 
look at CancelFunc to know what it's returning.

func WithDeadline(parent Context , 
deadline time .Time 
) (Context 
, CancelFunc 
)

vs

func WithDeadline(parent Context , 
deadline time .Time 
) (ctx Context 
, cancelFunc f 
unc())

IMO, the latter is more clear.

Also, how come WithCancel has named return values but WithDeadline and 
WithTimeout don't?


-- 
You received this message because you are subscribed to the Google 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: text/scanner: scan() vs peek()

[Jim Robinson]

I'll admit to not understanding how your question and code example mesh, 
but as far as I can tell Scanner.Peek is working as it is documented in the 
API, it returns the rune w/o advancing:

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

-- 
You received this message because you are subscribed to the Google 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] text/scanner: scan() vs peek()

[Sam Whited]

On Thu, Aug 25, 2016 at 12:55 PM, DrGo  wrote:
> Should not scanner.Peek do whatever scanner.Scan does just without advancing
> the scanner?

It does; scanner.Scan returns the next rune in the string and
scanner.Peek returns the next rune in the string without advancing the
scanner.

Are you confusing text/scanner (which operates on UTF-8 strings and
returns runes) and bufio's Scanner (which is an "interface for reading
data such as a file of newline-delimited lines of text")?

—Sam


-- 
Sam Whited
pub 4096R/54083AE104EA7AD3

-- 
You received this message because you are subscribed to the Google 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] text/scanner: scan() vs peek()

[DrGo]

Hello,

Perhaps I am misunderstanding the purpose or do not know how to optimally 
use this package, but the way I see it scanner.peek() is not doing what I 
expect it to do: return the next non-whitespace token (e.g., scanner.Ident, 
scanner.Int etc) without advancing the scanner. Instead it returns whatever 
is the next rune in the stream (which could be a space or any other char). 
So, as far as I could tell, there is no easy way to lookahead and switch 
the call to scanner.Scan on the kind of the next token. This complicates 
writing generic syntax checking functions like:

//TODO: handle error better

accept := func(wantedTok rune, wantedText string) {

tok = s.Scan()

log.Printf("%s: %d %s\n", s.Pos(), tok, s.TokenText())

if tok != wantedTok {

log.Fatalf("Syntax error at position %s. Expected %d. Found %d", 
s.Pos(), wantedTok, tok)

}

if wantedText != "" && wantedText != s.TokenText() { //case-sensitive?

log.Fatalf("Syntax error at position %s. Expected %s. Found %s", 
s.Pos(), wantedText, s.TokenText())

}

}


Should not scanner.Peek do whatever scanner.Scan does just without 
advancing the scanner?

-- 
You received this message because you are subscribed to the Google 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: Search for Another JSON Package

[dc0d]

Yes; I was super frustrated with big integers in JSON & your packages saved 
me big time! Thanks a lot!

On Thursday, August 25, 2016 at 3:19:19 PM UTC+4:30, Ugorji Nwoke wrote:
>
> I just checked the issue you created: 
> https://github.com/ugorji/go/issues/168 . I see you already closed it as 
> an error in your code.
>
> You typically shouldn't have to fork the library and make changes. It is 
> designed that you can achieve most of the customization you need by 
> implementing an interface or configuring a custom (en|de)code function for 
> given types.
>
> Glad it works for you.
>
> On Thursday, August 25, 2016 at 2:39:07 AM UTC-4, dc0d wrote:
>>
>> Thanks; the problem is I'm using a third party package with lots of 
>> data-structures and those data is going into CouchDB and deserializing 
>> would set the IEEE 754 hell loose.
>>
>> Also the `IntegerAsString` on `codec.JsonHandle` in ugorji package does 
>> not works - created an issue for that.
>>
>> I ended up forking the lib and use a custom Int and Int64 everywhere 
>> (implementing Marshaler and Unmarshaler interfaces).
>>
>> I hope this problem get solved inside standard lib too.
>>
>> Thanks;
>>
>> On Wednesday, August 24, 2016 at 9:33:10 PM UTC+4:30, Ugorji Nwoke wrote:
>>>
>>> https://godoc.org/github.com/ugorji/go/codec
>>> https://github.com/ugorji/go
>>> package name: github.com/ugorji/go/codec
>>>
>>> On Wednesday, August 24, 2016 at 5:30:10 AM UTC-4, dc0d wrote:

 Is there a JSON package that have these characteristics?


- can marshal numeric integer values to strings (like 
using `json:",string"` tag)
- can unmarshal  numeric integer values from *either* string or the 
number; based on the type of the field (some field like `MessageID 
 int64`)

 Why? Because IEEE 754 is really annoying and JSON standard treats all 
 numeric values as `float64`. So when a big integer number (a big `int64` 
 for example) gets serialized - which does perfectly - it can not get 
 deserialized.

>>>

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

[Nick Craig-Wood]

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] In the future, how to keep runtime.KeepAlive from dead code elimination?

[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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Re: Why a **T value can't call methods of *T and T if a *T value can call methods of T?

[Ian Lance Taylor]

On Thu, Aug 25, 2016 at 3:09 AM, T L  wrote:
>
> On Thursday, August 25, 2016 at 5:41:32 AM UTC+8, xiio...@gmail.com wrote:
>>
>> It doesn't/wouldn't seem to be any technical issue implementing methods on
>> any depth of pointer type .. as demonstrated in the unsafe example linked
>> from a previous related discussion (ie
>> https://groups.google.com/forum/#!msg/golang-nuts/qf76N-uDcHA/DTCDNgaF_p4J )
>>
>> It's not allowed by the specification - and surely the (sanity) reason for
>> this is that if you have pointers to pointers in this context you're
>> probably doing something wrong/unnecessary.
>
>
> The spec never says **T values can't call methods of *T.

There is, of course, no reason for the spec to say that.

The spec defines method sets for types.  A type **T can never have any methods.

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: Panic when calling fmt.Printnl() on string (segmentation violation)

[Dave Cheney]

Whenever you suspect memory corruption, try the race detector.

Can you also please post the full panic message, you cut off the important 
part

On Friday, 26 August 2016 01:11:49 UTC+10, arb...@gmail.com wrote:
>
> Hello everyone,
>
> My application occasionally crash when processing string variables. I can 
> not provide you with the full example, but the code looks more or less like 
> this:
>
> package main
>
> import "fmt"
>
> type Event struct {
> tokenA string
> tokenB string
> tokenC string
> tokenD string
> }
>
> func tokenLookup(tokens []string) {
> for _, token := range tokens {
> fmt.Println(len(token))// this will return the length of the string 
> correctly
> fmt.Println([]byte(token)) // this will panic 
> fmt.Println(token) // this will panic 
> }
> }
>
> func processEvent(event *Event) {
> tokenLookup([]string{
> event.tokenA,
> event.tokenB,
> event.tokenC,
> event.tokenD,
> })
> }
>
> I tested this and have the same problem when 1.6.2 and 1.7 versions. 
>
> Panic message look like this:
>
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x45cc71]
>
> goroutine 350 [running]:
> panic(0x95c1a0, 0xc420016130)
> /home/adwinsky/go/src/runtime/panic.go:500 +0x1a1
>
> Anyone would like to help me with debugging or maybe have an idea what 
> could cause that?
>
> Cheers
> Adam
>
>

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

Re: [go-nuts] Go protocol proxy, best practices

[Zlatko Čalušić]

Hello,

it would be hard to give you a complete solution without knowing many 
more details about your application.


So to comment on just one part, spawning goroutine, or two, per 
connection. It is absolutely THE correct way in Go. All those goroutines 
will be effectively mapped to system threads by the Go scheduler, and 
you need not worry too much about that, like in other languages. It's 
one of the distinct Go advantages, where developers job is easier thanks 
to simple yet very powerful abstractions.


Now, the number of goroutines will grow if you have many connections, 
but how many is too much? I've successfully launched hundreds of 
thousands of goroutines on the notebook I'm typing this message on, and 
the machine was perfectly usable whole time. And I was limited only by 
available memory, mind you. So, on the adequate server... you get the idea.


If you really care about the number of goroutines, then you should 
concentrate on proper timeouts and error handling, so in the case that 
systems you interface with are too slow or get unavailable, that you 
exit stale goroutines properly at some point, not just continue 
accumulating them.


Also, it could be that diameter server you mention is too slow because 
your Go app is too efficient. :) In that case you will need to actually 
limit the concurrency in your app, to give the diameter time to process 
all incoming requests.


Googling "golang concurrency patterns" will give you a lots of material 
to chew on and learn. I would advise reading the results from 
blog.golang.org first, because they're of high quality and very 
insightful, you can learn a lot from simple examples there.


On 25.08.2016 08:41, kvrat...@gmail.com wrote:

Hi all,

I'm looking for some good practices of concurrent programming in Go.

My software works and even customer satisfied :). But I feel job doesn't done 
perfectly.

The task was to convert some well documented but proprietary protocol to 
Diameter with custom dictionary.

But my feelings are not about protocols but about concurrent model which I 
implemented.

I spawn  goroutline per connection and this goroutline is responsible to 
assembly protocol messages from tcp stream.

Then I spawn another goroutline to process protocol message (calculate Crc and 
etc and make request to Diameter server, receive answer from Diameter server, 
and send response to server).

This per-message goroutline gets two arguments. There are request  and channel.

As soon as per-request goroutline creates response it sends it to channel.

Channel is processed by per-connection goroutine to send response.

I feel this simple model is not correct and stable under load. For example 
diameter server can be slow and number of goroutines and channels will grow 
dramatically.

When I did similar job in erlang I used this process model. But there 
supervisor controlled per-request workers.

Originally C-version uses several native threads with async logic (select and 
epoll) inside them.

Probably same async model can be implemented in Go by I would like to have 
benefits of Go using its concurrency features.

Could you advise correct concurrent model for my task?



--
Zlatko

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

[Val]

As you may have guesses, the html/package is not designed to perform such 
clever calculations. It handles only the html rendering logic.

You have 2 pretty good fallbacks actually : either precalculate and feed 
values to the template (server-side), or use javascript (client-side).
Cheers
Val

On Thursday, August 25, 2016 at 5:14:07 PM UTC+2, Carl Ranson wrote:
>
>
> HI All, 
>
> been playing with using go to pull data from a few sources and serve a 
> consolidated view as a webpage. 
> I've got most of it going ok, but hitting a wall trying to do a totals row 
> in an output table.
>
> anyone know if the html/template package is able to do this? 
>
> the fallback is to precalculate the totals and pass them as a struct to 
> the template as well. 
>
> thanks, 
> Carl. 
>
>
>

-- 
You received this message because you are subscribed to the Google 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 protocol proxy, best practices

[kvratkin]

Hi all,

I'm looking for some good practices of concurrent programming in Go. 

My software works and even customer satisfied :). But I feel job doesn't done 
perfectly.

The task was to convert some well documented but proprietary protocol to 
Diameter with custom dictionary. 

But my feelings are not about protocols but about concurrent model which I 
implemented.

I spawn  goroutline per connection and this goroutline is responsible to 
assembly protocol messages from tcp stream. 

Then I spawn another goroutline to process protocol message (calculate Crc and 
etc and make request to Diameter server, receive answer from Diameter server, 
and send response to server).

This per-message goroutline gets two arguments. There are request  and channel.

As soon as per-request goroutline creates response it sends it to channel. 

Channel is processed by per-connection goroutine to send response.

I feel this simple model is not correct and stable under load. For example 
diameter server can be slow and number of goroutines and channels will grow 
dramatically. 

When I did similar job in erlang I used this process model. But there 
supervisor controlled per-request workers.

Originally C-version uses several native threads with async logic (select and 
epoll) inside them.

Probably same async model can be implemented in Go by I would like to have 
benefits of Go using its concurrency features.

Could you advise correct concurrent model for my task?

-- 
You received this message because you are subscribed to the Google 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: Is it possible to create Application server in Golang?

[madars . vitolins]

There is one already, check Enduro/X ASG 
(https://github.com/endurox-dev/endurox, 
https://github.com/endurox-dev/endurox-go). You can create a modules which 
basically is stand alone Go binaries which does the Enduro/X organized IPC. 
Enduro/X monitors the processes, load balances the requests, allows dynamic 
configuration change (number of procsses, start/stop components, add new 
components), etc... It also allows to mix the languages, as the core 
Endurox is written for C.

otrdiena, 2016. gada 22. marts 13:30:18 UTC+2, Kolleru Gaurav rakstīja:
>
> Is is possible to simultaneously run two web application created in golang 
> so that both application run in sequence and maintain the web flow.
>

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

[Carl Ranson]

HI All, 

been playing with using go to pull data from a few sources and serve a 
consolidated view as a webpage. 
I've got most of it going ok, but hitting a wall trying to do a totals row 
in an output table.

anyone know if the html/template package is able to do this? 

the fallback is to precalculate the totals and pass them as a struct to the 
template as well. 

thanks, 
Carl. 


-- 
You received this message because you are subscribed to the Google 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] Panic when calling fmt.Printnl() on string (segmentation violation)

[arboooz]

Hello everyone,

My application occasionally crash when processing string variables. I can 
not provide you with the full example, but the code looks more or less like 
this:

package main

import "fmt"

type Event struct {
tokenA string
tokenB string
tokenC string
tokenD string
}

func tokenLookup(tokens []string) {
for _, token := range tokens {
fmt.Println(len(token))// this will return the length of the string 
correctly
fmt.Println([]byte(token)) // this will panic 
fmt.Println(token) // this will panic 
}
}

func processEvent(event *Event) {
tokenLookup([]string{
event.tokenA,
event.tokenB,
event.tokenC,
event.tokenD,
})
}

I tested this and have the same problem when 1.6.2 and 1.7 versions. 

Panic message look like this:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x45cc71]

goroutine 350 [running]:
panic(0x95c1a0, 0xc420016130)
/home/adwinsky/go/src/runtime/panic.go:500 +0x1a1

Anyone would like to help me with debugging or maybe have an idea what 
could cause that?

Cheers
Adam

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

[xiiophen]

[edit] Just retracting the statement *"if you have pointers to pointers in 
this context you're probably doing something wrong/unnecessary*." I made 
earlier - which is clearly wrong on a moments thought. 

Sorry..


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

[xiiophen]

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
?

-- 
You received this message because you are subscribed to the Google 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: Search for Another JSON Package

[Ugorji Nwoke]

I just checked the issue you 
created: https://github.com/ugorji/go/issues/168 . I see you already closed 
it as an error in your code.

You typically shouldn't have to fork the library and make changes. It is 
designed that you can achieve most of the customization you need by 
implementing an interface or configuring a custom (en|de)code function for 
given types.

Glad it works for you.

On Thursday, August 25, 2016 at 2:39:07 AM UTC-4, dc0d wrote:
>
> Thanks; the problem is I'm using a third party package with lots of 
> data-structures and those data is going into CouchDB and deserializing 
> would set the IEEE 754 hell loose.
>
> Also the `IntegerAsString` on `codec.JsonHandle` in ugorji package does 
> not works - created an issue for that.
>
> I ended up forking the lib and use a custom Int and Int64 everywhere 
> (implementing Marshaler and Unmarshaler interfaces).
>
> I hope this problem get solved inside standard lib too.
>
> Thanks;
>
> On Wednesday, August 24, 2016 at 9:33:10 PM UTC+4:30, Ugorji Nwoke wrote:
>>
>> https://godoc.org/github.com/ugorji/go/codec
>> https://github.com/ugorji/go
>> package name: github.com/ugorji/go/codec
>>
>> On Wednesday, August 24, 2016 at 5:30:10 AM UTC-4, dc0d wrote:
>>>
>>> Is there a JSON package that have these characteristics?
>>>
>>>
>>>- can marshal numeric integer values to strings (like 
>>>using `json:",string"` tag)
>>>- can unmarshal  numeric integer values from *either* string or the 
>>>number; based on the type of the field (some field like `MessageID 
>>> int64`)
>>>
>>> Why? Because IEEE 754 is really annoying and JSON standard treats all 
>>> numeric values as `float64`. So when a big integer number (a big `int64` 
>>> for example) gets serialized - which does perfectly - it can not get 
>>> deserialized.
>>>
>>

-- 
You received this message because you are subscribed to the Google 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: Allocating memory to consume a variable from channel in select statement

[T L]

On Wednesday, August 24, 2016 at 9:44:04 PM UTC+8, Chintan Sheth wrote:
>
> I am using select statement to dispatch work coming from multiple 
> goroutines, the variables used to consume the channel are allocated 
> manually as I am recycling those
>
>
> for {
>  a := getA()
>  b := getB()
>  select {
>  case a = <-chan1:
>   go doSomething(&a)
>  case b = <-chan2:
>   go doSomething2(&b)
>  }
> }
>
>
> This obviously does not work while listening on more than one channel, as 
> I wasting a get() call for the other type, is there any way to do some 
> "prework" before consuming the channel
>


 for {
 select {
 case a := <-chan1:
  go doSomething(&a)
 case b := <-chan2:
  go doSomething2(&b)
 }
}

-- 
You received this message because you are subscribed to the Google 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 5:41:32 AM UTC+8, xiio...@gmail.com wrote:
>
> It doesn't/wouldn't seem to be any technical issue implementing methods on 
> any depth of pointer type .. as demonstrated in the unsafe example linked 
> from a previous related discussion (ie 
> https://groups.google.com/forum/#!msg/golang-nuts/qf76N-uDcHA/DTCDNgaF_p4J 
> )
>
> It's not allowed by the specification - and surely the (sanity) reason for 
> this is that if you have pointers to pointers in this context you're 
> probably doing something wrong/unnecessary.
>
> I do get the OP's point that allowing any freedom is a great idea - and if 
> you want that C exists.
>
> Maybe there is some obscure reason or psychotic example when methods on 
> T actually has a use.
>
> In short  - not allowed by design because dogs chasing their own tail 
> doesn't even help the dog.
>


does "dogs chasing their own tail" do any harm? 

 

-- 
You received this message because you are subscribed to the Google 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 5:41:32 AM UTC+8, xiio...@gmail.com wrote:
>
> It doesn't/wouldn't seem to be any technical issue implementing methods on 
> any depth of pointer type .. as demonstrated in the unsafe example linked 
> from a previous related discussion (ie 
> https://groups.google.com/forum/#!msg/golang-nuts/qf76N-uDcHA/DTCDNgaF_p4J 
> )
>
> It's not allowed by the specification - and surely the (sanity) reason for 
> this is that if you have pointers to pointers in this context you're 
> probably doing something wrong/unnecessary.
>

The spec never says **T values can't call methods of *T.

***T may be rarely used, but **T is not very rarely to see.
 

>
> I do get the OP's point that allowing any freedom is a great idea - and if 
> you want that C exists.
>
> Maybe there is some obscure reason or psychotic example when methods on 
> T actually has a use.
>
> In short  - not allowed by design because dogs chasing their own tail 
> doesn't even help the dog.
>

Doesn't "not allow / break consistency" do more than "just keep 
consistency" in compiler implementation.
 

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

Not really. Runtime.KeepAlive is special, it'll continue to be special in the 
future. 

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

Does that mean that only inlined functions will be optimized and any 
functions not inlined will not be optimized ? 

在 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.