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" }