Re: [go-nuts] Proposal: auto return String instead of []byte if requested

On Sat, Sep 12, 2020 at 4:25 AM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Hi y'all, > > given that the concern here seems to be performance (though, TBH, I doubt > this particular case is much of a bottleneck), this seems to be far simpler > to address as a compiler op

Re: [go-nuts] handling database.Query empty set

hi Andy, when you take a look at the documentation of the Rows type returned by Query you will see a helpful example of its common use, appending the scanned results into a slice. my recommendation would be to follow this example and then check if the len(slice) == 0 to detect an empty set.

Re: [go-nuts] writing to net.Conn tcp socket

Yep I did this in the end and it works fine... var user string for rows_users.Next() { rows_users.Scan(&user) if conn, ok := m[user]; ok { conn.Write([]byte(string(username + " has entered the room\n# "))) } } I think I will back off the project and go bac

[go-nuts] handling database.Query empty set

the database.Query func does not return ErrNoRows unlike the database.QueryRow func so how to I handle an empty set when I wish to run a query which returns multiple rows... // tell other players in the room you have entered rows_users, err := database.Query("SELECT username FROM users WHERE roo

Re: [go-nuts] writing to net.Conn tcp socket

On Saturday, 12 September 2020 19:36:18 UTC+1, Andy Hall wrote: > > to handle the map not returning a result ( so I don't attempt to > write to a non-existent connection ) I need to know the zero value of > type net.Conn > > net.Conn is an interface , and theref

Re: [go-nuts] writing to net.Conn tcp socket

So far this is working... // create map var m = make(map[string]net.Conn) // populate map with user connection m[username] = c // get user connection from map conn := m[username] // write to user connection conn.Write([]byte(string(username + " has entered the room\n# "))) but to handle the map n

Re: [go-nuts] writing to net.Conn tcp socket

On 9/12/20 8:27 PM, Andy Hall wrote: Thanks Martin...I'll be sure to add a mutex lock and unlock either side of the map call...probably shouldn't have chosen a networked multi-player game as my first project but I sure am learning a lot !! It's a very fun language too. There is also *sync.Map*

Re: [go-nuts] writing to net.Conn tcp socket

thanks brian...I have looked at sync / channels but I think the simplicity of mutex should work fine for me. On Sat, 12 Sep 2020 at 18:13, Brian Candler wrote: > > On Saturday, 12 September 2020 17:04:19 UTC+1, mb0 wrote: >> >> a global map is the way to go, however writing an reading the map fro

Re: [go-nuts] writing to net.Conn tcp socket

Thanks Martin...I'll be sure to add a mutex lock and unlock either side of the map call...probably shouldn't have chosen a networked multi-player game as my first project but I sure am learning a lot !! It's a very fun language too. On Sat, 12 Sep 2020 at 17:03, Martin Schnabel wrote: > > Hi Andy

Re: [go-nuts] writing to net.Conn tcp socket

On Saturday, 12 September 2020 17:04:19 UTC+1, mb0 wrote: > > a global map is the way to go, however writing an reading the map from > multiple go routines will fail (in your case different handle calls for > connections) because the map data structure is not safe for concurrent use > and must b

Re: [go-nuts] writing to net.Conn tcp socket

Hi Andy, a global map is the way to go, however writing an reading the map from multiple go routines will fail (in your case different handle calls for connections) because the map data structure is not safe for concurrent use and must be coordinated. the way it is usually solved is by adding

Re: [go-nuts] writing to net.Conn tcp socket

OK so I just moved the declaration of the map to the package itself which makes it universal...all working as expected. Thanks. On Saturday, September 12, 2020 at 1:35:49 PM UTC+1 Andy Hall wrote: > So this works fine... > > func handleConnection(c net.Conn) { > // get user details > username :=

Re: [go-nuts] writing to net.Conn tcp socket

So this works fine... func handleConnection(c net.Conn) { // get user details username := createUser(c, "Please enter you username (new users will be created / existing users will be loaded): ") // map username to connection var m = make(map[string]net.Conn) m[username] = c n := len(m) fmt.Printl

Re: [go-nuts] alloc vs totalalloc in memory

Dnia 2020-09-11, o godz. 17:13:22 Alexander Mills napisał(a): > Well why does TotalAlloc keep climbing up (increasing) in my program, | CUMULATIVE: increasing or increased in quantity, degree, or force by successive additions. | It means that every allocation made _adds_ to an ever increasi

Re: [go-nuts] Proposal: auto return String instead of []byte if requested

Hi y'all, given that the concern here seems to be performance (though, TBH, I doubt this particular case is much of a bottleneck), this seems to be far simpler to address as a compiler optimization - if the compiler can prove there are no other references to a `[]byte`, it can do the conversion ch

Re: [go-nuts] Proposal: auto return String instead of []byte if requested

There is a prerequisite to transfer ownership: it must be proved that no other values share ownership of the byte slice returned by ioutil.ReadFile. On Saturday, September 12, 2020 at 3:42:14 AM UTC-4 tapi...@gmail.com wrote: > Is it good to introduce owner transfer based string<->[]byte convers

Re: [go-nuts] Proposal: auto return String instead of []byte if requested

Is it good to introduce owner transfer based string<->[]byte conversions? After the conversion, the being converted string/[]byte values mustn't be used any more. Such as tlsCertData, _ = ioutil.ReadFile("/etc/ssl/mycert") var tlsCert string = bultin.ByteSlice2String(tlsCertData) // forbid usin