George Shammas | 11 Mar 01:27 2012
Picon

Re: string tailing newline

Indeed, the problem was indeed the zeros. There should be a command
that does following. Or at the very least add 0 to the array for
TrimSpace. Its not the hardest thing to write, but it is hard to
debug. If I gave up a bit sooner, I would have never have split it
back into an array and saw the zeros.

line := strings.Trim(string(data), "\r\n"+string(0))

I suppose one could also use the returned value to slice only the
significant bits... Though cleaning the cruft off a string is normal,
which is why TrimSpace exists in the first place.

--George

On Sat, Mar 10, 2012 at 6:23 PM, Brad Fitzpatrick <bradfitz@...> wrote:
> Your trims would work if there weren't a bunch of zeros at the end.
>
> Tip: fix your zeros first.
>
> Secondary tip: don't ignore the return value of conn.Read.
>
>
> On Sat, Mar 10, 2012 at 11:40 AM, George Shammas <georgyo@...> wrote:
>>
>> Hey Everyone,
>>
>> I am using go for the first time, and it pretty fun. Currently I am
>> using the most recently weekly 3/4 and I have come upon a bug that is
>> driving me a bit buggy.
>>
(Continue reading)

Brad Fitzpatrick | 11 Mar 01:28 2012

Re: string tailing newline

No, you need to fix your zero problem first (see my second hint), and then you won't even have to trim the zeros off.


On Sat, Mar 10, 2012 at 4:27 PM, George Shammas <georgyo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Indeed, the problem was indeed the zeros. There should be a command
that does following. Or at the very least add 0 to the array for
TrimSpace. Its not the hardest thing to write, but it is hard to
debug. If I gave up a bit sooner, I would have never have split it
back into an array and saw the zeros.

line := strings.Trim(string(data), "\r\n"+string(0))

I suppose one could also use the returned value to slice only the
significant bits... Though cleaning the cruft off a string is normal,
which is why TrimSpace exists in the first place.

--George

On Sat, Mar 10, 2012 at 6:23 PM, Brad Fitzpatrick <bradfitz-iFWiy5xATs8dnm+yROfE0A@public.gmane.org> wrote:
> Your trims would work if there weren't a bunch of zeros at the end.
>
> Tip: fix your zeros first.
>
> Secondary tip: don't ignore the return value of conn.Read.
>
>
> On Sat, Mar 10, 2012 at 11:40 AM, George Shammas <georgyo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> Hey Everyone,
>>
>> I am using go for the first time, and it pretty fun. Currently I am
>> using the most recently weekly 3/4 and I have come upon a bug that is
>> driving me a bit buggy.
>>
>> I am listening for TCP connectings, then putting that string into a
>> channel that will be grabbed by the main loop. Spaces are fine, but
>> there should not be any new lines. However no matter what I do, there
>> is always a trailing newline. Of course if the incoming stream didn't
>> have one, then neither will the string.
>>
>> Here is a snip of my code
>>
>>        data := make([]byte, 255)
>>        _, err = conn.Read(data)
>>        checkErr("Problem reading connection stream:", err)
>>
>>        line := string(data)
>>        line = strings.TrimRightFunc(line, unicode.IsSpace)
>>        line = strings.Trim(line, string(10))
>>        line = strings.TrimSpace(line)
>>
>>        queue <- line
>>        log.Print("Received: " + string(line), []byte(line))
>>
>>
>> which always prints:
>>
>> 2012/03/10 14:19:30 Received: short
>> [115 104 111 114 116 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
>>
>> That blasted 10 always remains, taunting me. Am I doing something
>> wrong in trying to get rid of it? Again all I want is to remove is the
>> newlines. Everything else should stay.
>>
>> What I am really looking for is some kind of python equivalent of
>> strip() or a tcp read line.
>>
>> Thanks for any help you can provide.
>>
>> --George
>
>



--
{ "email":"georgyo <at> gmail.com", "phone":"+1 (347) 394-2945" }

Steven Blenkinsop | 11 Mar 01:36 2012
Picon

Re: Value declared and not used at setting a map

On 2012-03-10, at 6:55 PM, Archos <raul.san@...> wrote:

> This code gives an error which I was not not expecting because that
> value is being used really:
> 
> // * * *
> package main
> 
> var (
>    m1 = map[int]int{1:1,2:3}
>    m2 = map[int]int{1:1,2:2}
> 
>    all = []map[int]int{m1, m2}
> )
> 
> func main() {
>    for _, m := range all { // line 12
>        m = map[int]int{}
>        //println(m)
>    }

It really isn't. This code doesn't do what I believe you think it's doing. You aren't really mutating `all`
by assigning to `m`. You give m a new value, but the variable is never used anywhere.

`m` is a copy of each successive map value in `all`. Since maps are references, you can add, remove, or alter
map entries and it will impact the original maps. However, assigning to the map variable just reassigns
the variable to refer to a different map. It had no impact on the original map.
Ugorji Nwoke | 11 Mar 01:36 2012
Picon

Re: Re: duplicate method in interface

For embedded/anonymous fields, duplicate methods may cause concerns. However, for embedded interfaces, duplicate method definitions seem to cause concerns if/only if the method signatures are different (eg method abc() error and method abc() int), since an interface only defines signatures of method sets, not their implementation.


Now, the Go authors may be conservative and just restrict this use-case. And that's  fair. But I think it's still a fair question to ask.

On Saturday, March 10, 2012 5:12:32 PM UTC-5, Steven Blenkinsop wrote:
On 2012-03-10, at 4:15 PM, Guillaume Lescure <guil.lescure-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> I agree with you r2p2, it's should work according to the duck typing philosophy. I think it's a bug.

It is not a bug, it is working as intended and specified. Interfaces aren't defined based on some "duck typing philosophy", they are defined as the language authors saw fit.

The problem with just ignoring duplicates is that the methods may actually come from different places and mean different things (though the serendipity of this seems unlikely). An implementer may then not know which spec to follow. If this situation arises, the person defining the interface should make their intent explicit in the code.

Plausibly, the language could recognize that the method names originate in the same method spec and allow it. I think that would make sense and help in this case.

George Shammas | 11 Mar 01:48 2012
Picon

Re: string tailing newline

I actually acknowledged the slice in the second part of my response. I
understand that this would also work. (Although I didn't even think
about it in the first mail.)

data := make([]byte, 255)
n, err := conn.Read(data)
data = data[:n]

This is definitively more efficient. However it isn't obvious and I
would still need to trim to get rid of the newline though.

I was simply saying that a zero byte is effectively an invisible white
space, and should be treated as a white space.

--George

On Sat, Mar 10, 2012 at 7:28 PM, Brad Fitzpatrick <bradfitz@...> wrote:
> No, you need to fix your zero problem first (see my second hint), and then
> you won't even have to trim the zeros off.
>
> On Sat, Mar 10, 2012 at 4:27 PM, George Shammas <georgyo@...> wrote:
>>
>> Indeed, the problem was indeed the zeros. There should be a command
>> that does following. Or at the very least add 0 to the array for
>> TrimSpace. Its not the hardest thing to write, but it is hard to
>> debug. If I gave up a bit sooner, I would have never have split it
>> back into an array and saw the zeros.
>>
>> line := strings.Trim(string(data), "\r\n"+string(0))
>>
>> I suppose one could also use the returned value to slice only the
>> significant bits... Though cleaning the cruft off a string is normal,
>> which is why TrimSpace exists in the first place.
>>
>> --George
>>
>> On Sat, Mar 10, 2012 at 6:23 PM, Brad Fitzpatrick <bradfitz@...>
>> wrote:
>> > Your trims would work if there weren't a bunch of zeros at the end.
>> >
>> > Tip: fix your zeros first.
>> >
>> > Secondary tip: don't ignore the return value of conn.Read.
>> >
>> >
>> > On Sat, Mar 10, 2012 at 11:40 AM, George Shammas <georgyo@...>
>> > wrote:
>> >>
>> >> Hey Everyone,
>> >>
>> >> I am using go for the first time, and it pretty fun. Currently I am
>> >> using the most recently weekly 3/4 and I have come upon a bug that is
>> >> driving me a bit buggy.
>> >>
>> >> I am listening for TCP connectings, then putting that string into a
>> >> channel that will be grabbed by the main loop. Spaces are fine, but
>> >> there should not be any new lines. However no matter what I do, there
>> >> is always a trailing newline. Of course if the incoming stream didn't
>> >> have one, then neither will the string.
>> >>
>> >> Here is a snip of my code
>> >>
>> >>        data := make([]byte, 255)
>> >>        _, err = conn.Read(data)
>> >>        checkErr("Problem reading connection stream:", err)
>> >>
>> >>        line := string(data)
>> >>        line = strings.TrimRightFunc(line, unicode.IsSpace)
>> >>        line = strings.Trim(line, string(10))
>> >>        line = strings.TrimSpace(line)
>> >>
>> >>        queue <- line
>> >>        log.Print("Received: " + string(line), []byte(line))
>> >>
>> >>
>> >> which always prints:
>> >>
>> >> 2012/03/10 14:19:30 Received: short
>> >> [115 104 111 114 116 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
>> >>
>> >> That blasted 10 always remains, taunting me. Am I doing something
>> >> wrong in trying to get rid of it? Again all I want is to remove is the
>> >> newlines. Everything else should stay.
>> >>
>> >> What I am really looking for is some kind of python equivalent of
>> >> strip() or a tcp read line.
>> >>
>> >> Thanks for any help you can provide.
>> >>
>> >> --George
>> >
>> >
>>
>>
>>
>> --
>> { "email":"georgyo@...", "phone":"+1 (347) 394-2945" }
>
>

--

-- 
{ "email":"georgyo@...", "phone":"+1 (347) 394-2945" }

Brad Fitzpatrick | 11 Mar 01:53 2012

Re: string tailing newline

I promise it will become obvious & natural very soon.


But really, what you're doing isn't even what you want, since Read is allowed to return whenever it wants, after any amount of date (once per byte, even).  Look at the bufio package and its ReadLine / ReadSlice.  That's what you probably want.


On Sat, Mar 10, 2012 at 4:48 PM, George Shammas <georgyo <at> gmail.com> wrote:
I actually acknowledged the slice in the second part of my response. I
understand that this would also work. (Although I didn't even think
about it in the first mail.)

data := make([]byte, 255)
n, err := conn.Read(data)
data = data[:n]

This is definitively more efficient. However it isn't obvious and I
would still need to trim to get rid of the newline though.

I was simply saying that a zero byte is effectively an invisible white
space, and should be treated as a white space.

--George

On Sat, Mar 10, 2012 at 7:28 PM, Brad Fitzpatrick <bradfitz-iFWiy5xATs8dnm+yROfE0A@public.gmane.org> wrote:
> No, you need to fix your zero problem first (see my second hint), and then
> you won't even have to trim the zeros off.
>
> On Sat, Mar 10, 2012 at 4:27 PM, George Shammas <georgyo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> Indeed, the problem was indeed the zeros. There should be a command
>> that does following. Or at the very least add 0 to the array for
>> TrimSpace. Its not the hardest thing to write, but it is hard to
>> debug. If I gave up a bit sooner, I would have never have split it
>> back into an array and saw the zeros.
>>
>> line := strings.Trim(string(data), "\r\n"+string(0))
>>
>> I suppose one could also use the returned value to slice only the
>> significant bits... Though cleaning the cruft off a string is normal,
>> which is why TrimSpace exists in the first place.
>>
>> --George
>>
>> On Sat, Mar 10, 2012 at 6:23 PM, Brad Fitzpatrick <bradfitz-iFWiy5xATs8dnm+yROfE0A@public.gmane.org>
>> wrote:
>> > Your trims would work if there weren't a bunch of zeros at the end.
>> >
>> > Tip: fix your zeros first.
>> >
>> > Secondary tip: don't ignore the return value of conn.Read.
>> >
>> >
>> > On Sat, Mar 10, 2012 at 11:40 AM, George Shammas <georgyo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> > wrote:
>> >>
>> >> Hey Everyone,
>> >>
>> >> I am using go for the first time, and it pretty fun. Currently I am
>> >> using the most recently weekly 3/4 and I have come upon a bug that is
>> >> driving me a bit buggy.
>> >>
>> >> I am listening for TCP connectings, then putting that string into a
>> >> channel that will be grabbed by the main loop. Spaces are fine, but
>> >> there should not be any new lines. However no matter what I do, there
>> >> is always a trailing newline. Of course if the incoming stream didn't
>> >> have one, then neither will the string.
>> >>
>> >> Here is a snip of my code
>> >>
>> >>        data := make([]byte, 255)
>> >>        _, err = conn.Read(data)
>> >>        checkErr("Problem reading connection stream:", err)
>> >>
>> >>        line := string(data)
>> >>        line = strings.TrimRightFunc(line, unicode.IsSpace)
>> >>        line = strings.Trim(line, string(10))
>> >>        line = strings.TrimSpace(line)
>> >>
>> >>        queue <- line
>> >>        log.Print("Received: " + string(line), []byte(line))
>> >>
>> >>
>> >> which always prints:
>> >>
>> >> 2012/03/10 14:19:30 Received: short
>> >> [115 104 111 114 116 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
>> >>
>> >> That blasted 10 always remains, taunting me. Am I doing something
>> >> wrong in trying to get rid of it? Again all I want is to remove is the
>> >> newlines. Everything else should stay.
>> >>
>> >> What I am really looking for is some kind of python equivalent of
>> >> strip() or a tcp read line.
>> >>
>> >> Thanks for any help you can provide.
>> >>
>> >> --George
>> >
>> >
>>
>>
>>
>> --
>> { "email":"georgyo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org", "phone":"+1 (347) 394-2945" }
>
>



--
{ "email":"georgyo <at> gmail.com", "phone":"+1 (347) 394-2945" }

Archos | 11 Mar 01:57 2012

Re: Value declared and not used at setting a map

You're right. The next one is the way so solve it althought it isn't
possible change the value of some map from the slice (like I was
expecting).

// ***
package main

import "fmt"

var (
	m1 = map[int]int{1:1,2:3}
	m2 = map[int]int{1:1,2:2}

	all = []map[int]int{m1, m2}
)

func main() {
	for i, _ := range all {
		all[i]= map[int]int{}
	}

	fmt.Println(m1, m2)
	fmt.Println(all[0], all[1])
}
// ***
map[2:3 1:1] map[1:1 2:2]
map[] map[]

On Mar 11, 12:36 am, Steven Blenkinsop <steven...@...> wrote:
> On 2012-03-10, at 6:55 PM, Archos <raul....@...> wrote:
>
>
>
>
>
>
>
>
>
> > This code gives an error which I was not not expecting because that
> > value is being used really:
>
> > // * * *
> > package main
>
> > var (
> >    m1 = map[int]int{1:1,2:3}
> >    m2 = map[int]int{1:1,2:2}
>
> >    all = []map[int]int{m1, m2}
> > )
>
> > func main() {
> >    for _, m := range all { // line 12
> >        m = map[int]int{}
> >        //println(m)
> >    }
>
> It really isn't. This code doesn't do what I believe you think it's doing. You aren't really mutating `all`
by assigning to `m`. You give m a new value, but the variable is never used anywhere.
>
> `m` is a copy of each successive map value in `all`. Since maps are references, you can add, remove, or alter
map entries and it will impact the original maps. However, assigning to the map variable just reassigns
the variable to refer to a different map. It had no impact on the original map.

Guillermo Estrada | 11 Mar 01:59 2012
Picon

Re: Go binary distributions

Can anyone with the tools, knowledge and some free time, build the binary distribution of linux-arm? That should run on android devices right? I have a Transformer 101 running ICS 4.0.3 and I would love to code on it. It's already rooted so I guess it will be as simple as copying and pointing the Env Variables to start developing, shouldn't it? any insight on this is pretty appreciated.

George Shammas | 11 Mar 03:23 2012
Picon

Re: string tailing newline

I do believe this is what I have been looking for.

data,_,err := bufio.NewReader(conn).ReadLine()

Thanks!

On Sat, Mar 10, 2012 at 7:53 PM, Brad Fitzpatrick <bradfitz@...> wrote:
> I promise it will become obvious & natural very soon.
>
> But really, what you're doing isn't even what you want, since Read is
> allowed to return whenever it wants, after any amount of date (once per
> byte, even).  Look at the bufio package and its ReadLine / ReadSlice.
>  That's what you probably want.
>
>
> On Sat, Mar 10, 2012 at 4:48 PM, George Shammas <georgyo@...> wrote:
>>
>> I actually acknowledged the slice in the second part of my response. I
>> understand that this would also work. (Although I didn't even think
>> about it in the first mail.)
>>
>> data := make([]byte, 255)
>> n, err := conn.Read(data)
>> data = data[:n]
>>
>> This is definitively more efficient. However it isn't obvious and I
>> would still need to trim to get rid of the newline though.
>>
>> I was simply saying that a zero byte is effectively an invisible white
>> space, and should be treated as a white space.
>>
>> --George
>>
>> On Sat, Mar 10, 2012 at 7:28 PM, Brad Fitzpatrick <bradfitz@...>
>> wrote:
>> > No, you need to fix your zero problem first (see my second hint), and
>> > then
>> > you won't even have to trim the zeros off.
>> >
>> > On Sat, Mar 10, 2012 at 4:27 PM, George Shammas <georgyo@...>
>> > wrote:
>> >>
>> >> Indeed, the problem was indeed the zeros. There should be a command
>> >> that does following. Or at the very least add 0 to the array for
>> >> TrimSpace. Its not the hardest thing to write, but it is hard to
>> >> debug. If I gave up a bit sooner, I would have never have split it
>> >> back into an array and saw the zeros.
>> >>
>> >> line := strings.Trim(string(data), "\r\n"+string(0))
>> >>
>> >> I suppose one could also use the returned value to slice only the
>> >> significant bits... Though cleaning the cruft off a string is normal,
>> >> which is why TrimSpace exists in the first place.
>> >>
>> >> --George
>> >>
>> >> On Sat, Mar 10, 2012 at 6:23 PM, Brad Fitzpatrick <bradfitz@...g>
>> >> wrote:
>> >> > Your trims would work if there weren't a bunch of zeros at the end.
>> >> >
>> >> > Tip: fix your zeros first.
>> >> >
>> >> > Secondary tip: don't ignore the return value of conn.Read.
>> >> >
>> >> >
>> >> > On Sat, Mar 10, 2012 at 11:40 AM, George Shammas <georgyo@...>
>> >> > wrote:
>> >> >>
>> >> >> Hey Everyone,
>> >> >>
>> >> >> I am using go for the first time, and it pretty fun. Currently I am
>> >> >> using the most recently weekly 3/4 and I have come upon a bug that
>> >> >> is
>> >> >> driving me a bit buggy.
>> >> >>
>> >> >> I am listening for TCP connectings, then putting that string into a
>> >> >> channel that will be grabbed by the main loop. Spaces are fine, but
>> >> >> there should not be any new lines. However no matter what I do,
>> >> >> there
>> >> >> is always a trailing newline. Of course if the incoming stream
>> >> >> didn't
>> >> >> have one, then neither will the string.
>> >> >>
>> >> >> Here is a snip of my code
>> >> >>
>> >> >>        data := make([]byte, 255)
>> >> >>        _, err = conn.Read(data)
>> >> >>        checkErr("Problem reading connection stream:", err)
>> >> >>
>> >> >>        line := string(data)
>> >> >>        line = strings.TrimRightFunc(line, unicode.IsSpace)
>> >> >>        line = strings.Trim(line, string(10))
>> >> >>        line = strings.TrimSpace(line)
>> >> >>
>> >> >>        queue <- line
>> >> >>        log.Print("Received: " + string(line), []byte(line))
>> >> >>
>> >> >>
>> >> >> which always prints:
>> >> >>
>> >> >> 2012/03/10 14:19:30 Received: short
>> >> >> [115 104 111 114 116 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> >> 0
>> >> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> >> 0
>> >> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> >> 0
>> >> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> >> 0
>> >> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> >> 0
>> >> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> >> 0
>> >> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> >> 0
>> >> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
>> >> >>
>> >> >> That blasted 10 always remains, taunting me. Am I doing something
>> >> >> wrong in trying to get rid of it? Again all I want is to remove is
>> >> >> the
>> >> >> newlines. Everything else should stay.
>> >> >>
>> >> >> What I am really looking for is some kind of python equivalent of
>> >> >> strip() or a tcp read line.
>> >> >>
>> >> >> Thanks for any help you can provide.
>> >> >>
>> >> >> --George
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> { "email":"georgyo@...", "phone":"+1 (347) 394-2945" }
>> >
>> >
>>
>>
>>
>> --
>> { "email":"georgyo@...", "phone":"+1 (347) 394-2945" }
>
>

--

-- 
{ "email":"georgyo@...", "phone":"+1 (347) 394-2945" }

Brad Fitzpatrick | 11 Mar 03:26 2012

Re: string tailing newline

If you're going to ignore isPrefix there, you're going to be surprised one day.  Use bufio.*Reader.ReadString instead:




On Sat, Mar 10, 2012 at 6:23 PM, George Shammas <georgyo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I do believe this is what I have been looking for.

data,_,err := bufio.NewReader(conn).ReadLine()

Thanks!

On Sat, Mar 10, 2012 at 7:53 PM, Brad Fitzpatrick <bradfitz-iFWiy5xATs8dnm+yROfE0A@public.gmane.org> wrote:
> I promise it will become obvious & natural very soon.
>
> But really, what you're doing isn't even what you want, since Read is
> allowed to return whenever it wants, after any amount of date (once per
> byte, even).  Look at the bufio package and its ReadLine / ReadSlice.
>  That's what you probably want.
>
>
> On Sat, Mar 10, 2012 at 4:48 PM, George Shammas <georgyo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> I actually acknowledged the slice in the second part of my response. I
>> understand that this would also work. (Although I didn't even think
>> about it in the first mail.)
>>
>> data := make([]byte, 255)
>> n, err := conn.Read(data)
>> data = data[:n]
>>
>> This is definitively more efficient. However it isn't obvious and I
>> would still need to trim to get rid of the newline though.
>>
>> I was simply saying that a zero byte is effectively an invisible white
>> space, and should be treated as a white space.
>>
>> --George
>>
>> On Sat, Mar 10, 2012 at 7:28 PM, Brad Fitzpatrick <bradfitz-iFWiy5xATs8dnm+yROfE0A@public.gmane.org>
>> wrote:
>> > No, you need to fix your zero problem first (see my second hint), and
>> > then
>> > you won't even have to trim the zeros off.
>> >
>> > On Sat, Mar 10, 2012 at 4:27 PM, George Shammas <georgyo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> > wrote:
>> >>
>> >> Indeed, the problem was indeed the zeros. There should be a command
>> >> that does following. Or at the very least add 0 to the array for
>> >> TrimSpace. Its not the hardest thing to write, but it is hard to
>> >> debug. If I gave up a bit sooner, I would have never have split it
>> >> back into an array and saw the zeros.
>> >>
>> >> line := strings.Trim(string(data), "\r\n"+string(0))
>> >>
>> >> I suppose one could also use the returned value to slice only the
>> >> significant bits... Though cleaning the cruft off a string is normal,
>> >> which is why TrimSpace exists in the first place.
>> >>
>> >> --George
>> >>
>> >> On Sat, Mar 10, 2012 at 6:23 PM, Brad Fitzpatrick <bradfitz-iFWiy5xATs8dnm+yROfE0A@public.gmane.org>
>> >> wrote:
>> >> > Your trims would work if there weren't a bunch of zeros at the end.
>> >> >
>> >> > Tip: fix your zeros first.
>> >> >
>> >> > Secondary tip: don't ignore the return value of conn.Read.
>> >> >
>> >> >
>> >> > On Sat, Mar 10, 2012 at 11:40 AM, George Shammas <georgyo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> >> > wrote:
>> >> >>
>> >> >> Hey Everyone,
>> >> >>
>> >> >> I am using go for the first time, and it pretty fun. Currently I am
>> >> >> using the most recently weekly 3/4 and I have come upon a bug that
>> >> >> is
>> >> >> driving me a bit buggy.
>> >> >>
>> >> >> I am listening for TCP connectings, then putting that string into a
>> >> >> channel that will be grabbed by the main loop. Spaces are fine, but
>> >> >> there should not be any new lines. However no matter what I do,
>> >> >> there
>> >> >> is always a trailing newline. Of course if the incoming stream
>> >> >> didn't
>> >> >> have one, then neither will the string.
>> >> >>
>> >> >> Here is a snip of my code
>> >> >>
>> >> >>        data := make([]byte, 255)
>> >> >>        _, err = conn.Read(data)
>> >> >>        checkErr("Problem reading connection stream:", err)
>> >> >>
>> >> >>        line := string(data)
>> >> >>        line = strings.TrimRightFunc(line, unicode.IsSpace)
>> >> >>        line = strings.Trim(line, string(10))
>> >> >>        line = strings.TrimSpace(line)
>> >> >>
>> >> >>        queue <- line
>> >> >>        log.Print("Received: " + string(line), []byte(line))
>> >> >>
>> >> >>
>> >> >> which always prints:
>> >> >>
>> >> >> 2012/03/10 14:19:30 Received: short
>> >> >> [115 104 111 114 116 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> >> 0
>> >> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> >> 0
>> >> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> >> 0
>> >> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> >> 0
>> >> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> >> 0
>> >> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> >> 0
>> >> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>> >> >> 0
>> >> >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
>> >> >>
>> >> >> That blasted 10 always remains, taunting me. Am I doing something
>> >> >> wrong in trying to get rid of it? Again all I want is to remove is
>> >> >> the
>> >> >> newlines. Everything else should stay.
>> >> >>
>> >> >> What I am really looking for is some kind of python equivalent of
>> >> >> strip() or a tcp read line.
>> >> >>
>> >> >> Thanks for any help you can provide.
>> >> >>
>> >> >> --George
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> { "email":"georgyo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org", "phone":"+1 (347) 394-2945" }
>> >
>> >
>>
>>
>>
>> --
>> { "email":"georgyo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org", "phone":"+1 (347) 394-2945" }
>
>



--
{ "email":"georgyo <at> gmail.com", "phone":"+1 (347) 394-2945" }


Gmane