1 Dec 2011 01:01
1 Dec 2011 01:16
Re: Erlang OTP
This supervision system is not built in Go (else it's in Rust) but it could be used like inspiration: http://www.rust-lang.org/doc/std/files/task-rs.html On Nov 30, 7:57 am, r2p2 <robert-pet...@...> wrote: > Hi again, > > some minutes ago I stumbled over the netchan package. In me rises now > the wish to implement some of the Erlang/OTP features, like the state > behavior or the supervisor. > So, from my other posts you know that I am not that familiar with go at the > moment and I would be happy to hear some opinions. > > best regards > r2p2 > > PS: Because I have nearly never time, this would be a long term process.
1 Dec 2011 02:31
Re: Is there already a 'char' type hidden in any package?
OK, My problem is: I want to print out char array autotmatically (just like C language).
For a single char, I could write a simple method to display.
But, it is difficult to write a Stringer for array.
http://play.golang.org/p/lFpzmx0-s_
package main
import "fmt"
type char byte
func (c char)String()string{
return string(c)
}
type Person struct { // Is it possible to display many struct similar to this
name [5]char
age uint8
sex char // F:female, M:male
}
func main() {
a := char(97)
b := [3]char{'a','b','c'}
person := Person{[5]char{'A','p','p','l','e'}, 36, 'M'}
fmt.Println(a)
fmt.Println(b)
fmt.Println(person)
}
// Result:// a // OK
//[97 98 99] // Fail
//{[65 112 112 108 101] 36 77} // Both name & sex field Fail
1 Dec 2011 02:33
Re: Re: Non nil interface for nil pointer type
On Wed, Nov 30, 2011 at 4:55 PM, Kyle Lemons <kevlar-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
Interestingly, calling a method on a nil object in Go doesn't necessarily dereference a nil pointer.
Unless it's a value method. However, there's no way that the compiler could enforce nil pointers having a different method set from non-nil pointers, so the distinction can't be made in any meaningful way.
On Wed, Nov 30, 2011 at 17:05, Rémy Oudompheng <remyoudompheng-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:You are correct, but the method sets are only really
> How can this compile? *FortyTwo inherits the method set of FortyTwo,
> but how can it work the other way round?
relevant when assigning to an interface value.
Here, the compiler is rewriting ft.Print() into (&ft).Print()
as a convenience to the programmer.
Russ
There are three sections that seem relevant to method sets, but there's some inconsistency in what they're saying. I know what the intent is, but it seems like it could use clarifying. I seem to remember it all fitting together well, so either it's been rewritten, or I'm just reading it differently.
The section on method sets requires that methods have the correct receiver type, and explicitly rules out all other circumstances. The section on anonymous fields says that the fields and methods of anonymous fields are promoted so that they also belong directly to the outer struct type, and specifies the impact this has on method sets. However, the section on selectors describes this promotion as though it were purely a property of selection syntax rather than of struct types with anonymous fields, and distinguishes between the method set of the struct itself and the method set of each of its nested anonymous fields. This is somewhat incongruous. It seems to me that either promotion should be strictly a property of structs with anonymous fields, in which case selectors wouldn't have to take it specifically into account, or else it should be taken into account explicitly in the definition of method sets as well.
On that note, it's somewhat odd that the rule allowing calling pointer methods on addressable values of the base type is in the function call section. The selection expression x.m seems to be illegal under the selection rules, but is allowed for under the call rules. Since the selection rules deal specifically with method resolution, it doesn't seem like this particular special case of selectors should be dealt with as a special case of the call syntax, since the method call syntax is otherwise built on top of selection.
1 Dec 2011 02:38
Re: UDP socket Read timeout
for UDP, it's impossible to put that check in Read. you said you don't understand why con.Write help con.Read to detect 'connection refused'. This is because, con.Write() will send a packet to the server, but the server is shutdown, so the server's OS will send a 'connection refused' RST packet to your client. GGGO <ggcod...@...> wrote: > Hi, > you're right about 3rd possible value. > timeout on read always work but it just report this all time: 'read > udp ipaddress:port: i/o timeout'. > Even if connection is closed. > So the only solution I have found is to force a writing on socket, and > now "err:=con.Read()" return this : 'read udp ipaddress:port: > connection refused' > It's the only solution have found, maybe there is another better. > > But what I don't understand, is why con.write help con.Read to detect > 'connection refused', is it not possible to put this check in Read ? > > Thanks
1 Dec 2011 02:40
Re: Re: Is there already a 'char' type hidden in any package?
OK, My problem is: I want to print out char array autotmatically (just like C language).For a single char, I could write a simple method to display.But, it is difficult to write a Stringer for array.package mainimport "fmt"type char bytefunc (c char)String()string{return string(c)}type Person struct { // Is it possible to display many struct similar to thisname [5]charage uint8sex char // F:female, M:male}func main() {a := char(97)b := [3]char{'a','b','c'}person := Person{[5]char{'A','p','p','l','e'}, 36, 'M'}fmt.Println(a)fmt.Println(b)fmt.Println(person)}// Result:// a // OK //[97 98 99] // Fail //{[65 112 112 108 101] 36 77} // Both name & sex field Fail
I wasn't suggesting to actually create a char class; types are not like typedefs in C.
1 Dec 2011 02:42
Re: Re: UDP socket Read timeout
Are you trying to get the Read() to return when you call udpsock.Close() and it won't? You also seems to indicate that after calling Close(), the read timeout no longer fires. If this is the case, as rsc said, please post a minimal reproducing example for us to peruse.
1 Dec 2011 02:54
Re: Re: UDP socket Read timeout
Hi, On Thu, Dec 1, 2011 at 7:34 AM, GGGO <ggcoding@...> wrote: > But what I don't understand, is why con.write help con.Read to detect > 'connection refused', When the UDP packet you sent from a client arrived at a server, IP protocol family guys inside server do start packet delivery process: have a look at customer book, realize that there is no customer on a protocol, port corresponding to the incoming packet and finally report ICMP dst-unreach/port-unreach error to the client. The client could realize that seems like the server won't talk anymore by that ICMP error notification. > is it not possible to put this check in Read ? Mostly UDP based protocols implement its own dead peer detection mech such as heartbeat, keepalive, etc because that's the UDP way. If you really need a lightweight but a bit more reliable datagram-based vehicle you can use DCCP instead of UDP. Go standard packages not support DCCP yet but it wouldn't be tough work I think.
1 Dec 2011 03:28
Re: UDP socket Read timeout
Thanks everyone ! My question is answered ! GG On Nov 30, 8:54 pm, Mikio Hara <mikioh.mik...@...> wrote: > Hi, > > On Thu, Dec 1, 2011 at 7:34 AM, GGGO <ggcod...@...> wrote: > > But what I don't understand, is why con.write help con.Read to detect > > 'connection refused', > > When the UDP packet you sent from a client arrived at a server, > IP protocol family guys inside server do start packet delivery > process: have a look at customer book, realize that there is no > customer on a protocol, port corresponding to the incoming packet > and finally report ICMP dst-unreach/port-unreach error to the client. > > The client could realize that seems like the server won't talk anymore > by that ICMP error notification. > > > is it not possible to put this check in Read ? > > Mostly UDP based protocols implement its own dead peer detection > mech such as heartbeat, keepalive, etc because that's the UDP way. > > If you really need a lightweight but a bit more reliable datagram-based > vehicle you can use DCCP instead of UDP. Go standard packages > not support DCCP yet but it wouldn't be tough work I think.
1 Dec 2011 05:43
Re: Re: Is there already a 'char' type hidden in any package?
Kyle, thanks for your explain.
I prefer Go could let me show array in my defined stringer.
There are many char array and char in my protocol format.
I wish the default stringer will be smarter. I don't want to implement every stringer for every format.
So, if it is possible, I would like:
type char byte
func (c char) String() string {
return fmt.Sprintf("%c", c)
}
func (a []char)String() string { // Here is the important suggest syntax sugar
s := ""
for _,c := range a {
s += fmt.Sprintf("%c", c)
}
return s
}
type T1 {
c1 char
c2 [2]char
c3 [3]char
}
type T2 {
c4 [4]char
c5 [5]char
c []char
}
I wish to print out the T1, T2 in readable format without coding Stringer for T1 & T2
RSS Feed