--- Log opened Thu Mar 10 00:00:55 2011 00:06 -!- ronny [~quassel@p4FF1C6C6.dip0.t-ipconnect.de] has joined #go-nuts 00:07 -!- jedws [~jwesleysm@sydfibre2.atlassian.com] has joined #go-nuts 00:11 -!- saracen [~saracen@81-5-140-201.dsl.eclipse.net.uk] has joined #go-nuts 00:11 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.4] 00:17 -!- _DerHorst_ [~Horst@e176101039.adsl.alicedsl.de] has joined #go-nuts 00:21 -!- DerHorst [~Horst@e177129051.adsl.alicedsl.de] has quit [Ping timeout: 246 seconds] 00:22 < saracen> I have a method which downloads files. I want to be able to return the data as it's downloaded via a channel, in chunks. The same file may be requested from different goroutines, in which case, I'd like to be able to send the data to multiple channels. 00:23 < saracen> Now, because there's multiple channels involved, would it be wise to send a copy of the buffer to each 00:23 < saracen> Or by pointer, with the buffer wrapped in a struct where I can use a mutex? 00:26 -!- gid [~gid@220-253-52-123.VIC.netspace.net.au] has joined #go-nuts 00:26 -!- iant [~iant@nat/google/x-hivutomtskvmhwsn] has quit [Ping timeout: 248 seconds] 00:27 -!- gid [~gid@220-253-52-123.VIC.netspace.net.au] has quit [Client Quit] 00:28 < saracen> If I wanted to have just a single buffer, and send it to multiple channels by pointer, is there something already inbuilt that would handle the locks for me? Like some sort of specialised reader/writer. The buffer would only need to be read once sent over the channel (But have it's own read offset) 00:28 < saracen> I'm new to go, so I hope at least some of this makes sense :( 00:32 < krakensden> pharris, it works like a charm, thanks 00:33 -!- iant [~iant@67.218.107.6] has joined #go-nuts 00:33 -!- mode/#go-nuts [+v iant] by ChanServ 00:42 < yiyus> saracen: convert your buffer to a string and send strings.Reader to the channel 00:43 -!- iant [~iant@67.218.107.6] has quit [Quit: Leaving.] 00:43 -!- iant [~iant@67.218.107.6] has joined #go-nuts 00:43 -!- mode/#go-nuts [+v iant] by ChanServ 00:54 -!- mikespook [~mikespook@219.137.49.35] has joined #go-nuts 00:54 -!- KBme [~KBme@9angled-2-pt.tunnel.tserv5.lon1.ipv6.he.net] has quit [Quit: KBme kthxbye] 00:55 -!- Guest63437 [~quassel@p4FF1C6C6.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 00:56 < dfr|work> dfc, ping 00:56 -!- KBme [~KBme@9angled-2-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #go-nuts 00:56 < dfc> hey mate 00:56 < dfc> i had a quick look last night 00:56 < dfr|work> dfc, so I'm making some progress 00:57 * dfc git pull's 00:57 < dfr|work> dfc, it seems like the error I'm getting for write is actually from read 00:57 < dfr|work> dfc, err, not yet, hehe 00:57 < dfr|work> oushed 00:57 < dfr|work> but don't mind all the trash output 01:04 < dfr|work> dfc, so basically seems like when I ask for features, server returns with an eventual EOF, that EOF puts the connection in "error" state and when I try to handshake via Write, it returns that error 01:05 < dfc> LOG: Gotten following features: <stream:stream from="gmail.com" id="D5CD5D3D469E4951" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client"><stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>X-GOOGLE-TOKEN</mechanism></mechanisms></stream:features> 01:05 < dfc> ^ this line 01:05 < dfc> does this actually come from the remote end 01:05 < dfr|work> yup 01:05 < dfc> so, gtalk does pick up the connection 01:05 < dfc> and sends some data 01:05 < dfr|work> dfc, yup, and then sends EOF 01:05 < dfc> here is what I would do 01:06 < dfc> use tshark to dump the connection pidgeon is making 01:06 < dfc> i have a suspicion that it stats out cleartext, then upgrades to TLS later 01:06 < dfr|work> well, I have pidgin dump the actual log of what it's sending. 01:06 < dfc> where you are connecting via TLS directly, which may not be supported (or working) on gtalk 01:06 < dfc> i'd look at the wire 01:06 < dfr|work> dfc, and i I think found the issue, which is in tls 01:07 < mdxi> one night a while back, there was compiler chat going on, and i mentioned how LLVM was enabling some compiler-as-a-service type stuff in xcode. they're going further with that now, doing static analysis on the fly: http://developer.apple.com/technologies/tools/whats-new.html#fix-it 01:07 < dfr|work> dfc, if you take a look at the log, the "tls error" field gets set to EOF between "boo" and "bar" 01:07 < dfr|work> dfc, so the reading of the features sets it to EOF 01:08 -!- raylu [raylu@c-24-131-193-106.hsd1.pa.comcast.net] has left #go-nuts ["thanks"] 01:09 -!- cnan [~cnan@122.80.198.193] has joined #go-nuts 01:09 < dfr|work> and that EOF prevents writing anything, as Handshake errors out and it returns error 01:09 < dfr|work> so the client never actually writes anything 01:09 -!- coldturnip [~COLDTURNI@111-250-14-65.dynamic.hinet.net] has joined #go-nuts 01:10 -!- coldturnip [~COLDTURNI@111-250-14-65.dynamic.hinet.net] has quit [Client Quit] 01:12 -!- saturnfive [~saturnfiv@210.74.155.131] has joined #go-nuts 01:13 < dfc> right, so what gtalk could be sending is, in a way, a redirect 01:13 < dfc> you've connected to me in the wrong format 01:13 < dfr|work> dfc, oh, interesting. 01:13 < dfc> here is some information (such that it is), please use that and go somewhere else 01:13 < dfc> when I looked at xmpp a while ago 01:13 < dfr|work> that's a good point... 01:13 < dfc> i thought the handshake looked like 01:14 < dfc> connect over a plain socket to 5222 01:14 < dfc> send some xml 01:14 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Ping timeout: 260 seconds] 01:14 < dfc> do tls upgrade 01:14 < dfc> send some more xml 01:14 < dfc> exchange features 01:14 < dfc> authenticate 01:14 < dfc> send some more xml 01:14 < dfc> then you are registered 01:14 < dfr|work> that sounds about right. 01:14 < dfc> let me dump the traffic that adium sends 01:17 < dfc> yup 01:17 < dfc> this is how it works 01:17 < skelterjohn> i've been thinking a bit about versioning 01:17 < dfr|work> dfc, so there's a small difference that I'm connecting to https port, whatever is 01:18 < dfr|work> as opposed to 5222 01:18 < dfc> ahh right 01:18 < skelterjohn> what if we allow a number to follow package and import statements? 01:18 < dfr|work> if I do 5222, it complains about "record overflow"..... 01:18 < dfc> of course 01:18 < dfc> because that is a text port 01:18 < dfr|work> which seems to be some n comparing to maxCiphertext 01:18 < dfc> like talking to port 80 via https 01:18 < dfr|work> can you explain what's going on? 01:18 < dfr|work> skelterjohn, that starts to sound like ruby gems 01:19 < skelterjohn> like, i'll write: package mypackage 354 01:19 < skelterjohn> and someone can: import "mypackage" 355 01:19 < skelterjohn> and it will complain if it can only find 354 01:19 < skelterjohn> if you just: import "mypackage" 01:19 < skelterjohn> it will take the highest version 01:19 < skelterjohn> if you just: package mypackage 01:20 < skelterjohn> it is unversioned and comes after any numbered version 01:20 < dfc> dfr|work: https://gist.github.com/863392 01:21 < skelterjohn> goinstall could be made to work with it by looking for proj.googlecode.com/hg/proj/354 01:21 < skelterjohn> when you try to goinstall proj.googlecode.com/hg/proj 354 01:22 <@adg> skelterjohn: what happens, then, if you have two packages that depend on different versions of proj.googlecode.com/hg/proj ? 01:22 < dfr|work> dfc, right. I get similar stuff if I do just a regular connection. 01:22 < dfr|work> dfc, my understanding is that the tls package is supposed to take care of all that certificate stuff 01:22 < skelterjohn> adg: presumably both would be linked in 01:22 < dfc> it does 01:22 <@adg> skelterjohn: but don't they need to be installed in the same place? 01:22 <@adg> with the same name? 01:22 < skelterjohn> something that says package mypackage 354 would go to $GOROOT/pkg/goos_goarch/mypackage.a.354 01:22 < dfr|work> dfc, basically, if I felt sure enough in my skills, I'd just use the raw connection. 01:22 < skelterjohn> or .354.a 01:23 < dfr|work> dfc, but it seems that tls package expects the ciphertext payload length to be 16484+2048, but it's larger.... 01:23 < dfr|work> so I'm not really sure what to do, hehe 01:23 <@adg> so really it would be import "package.354" 01:23 <@adg> so you would just say "goinstall proj.googlecode.com/hg/proj.354 01:23 < skelterjohn> well no - this would be something like "at least 354" 01:23 < skelterjohn> either that or at most 354 01:24 < dfc> dfr|work: is the correct port for talking to gtalk 443 ? 01:24 < skelterjohn> i haven't figured out which is better :) 01:24 <@adg> it should be precised 01:24 <@adg> precise 01:24 <@adg> otherwise what's the point 01:24 < dfr|work> dfc, i don't think so. I think it's 5222 01:24 < skelterjohn> import "mypackage" >354 01:24 < dfc> hostname := "talk.google.com:https" 01:24 < dfc> tlsconn, err := tls.Dial("tcp", "", hostname, nil) 01:24 < skelterjohn> import "mypackage" 354 01:24 < skelterjohn> import "mypackage" <354 01:24 <@adg> skelterjohn: i think that's too complicated. that means it can still break 01:24 < skelterjohn> yeah, just brainstorming 01:25 < dfr|work> dfc, yup. I changed that to 5222 and it's complaining about record overflow due to ciphertext received being larger than specified constant 01:25 <@adg> if you're thinking about versioning, you should be building against the versions expected by each package 01:25 < dfc> dfr|work: because port 5222 is a plain text port, it does not open with an ssl handshake 01:25 <@adg> exactly 01:25 <@adg> just my 2c anyway :) 01:25 < skelterjohn> i once suggested people take a convention of freezing versions of their products in a /versionNumber folder 01:25 < skelterjohn> no...not exactly 01:26 < skelterjohn> proj.googlecode.com/hg/version/proj 01:26 < skelterjohn> like that 01:26 < skelterjohn> so it would end with the same token 01:26 < dfr|work> adg, skelterjohn: your discussion sounds very similar to gems in ruby: http://docs.rubygems.org/read/chapter/16 01:26 < skelterjohn> i don't want to read a chapter on ruby :\ 01:26 < skelterjohn> :) 01:26 < dfc> dfr|work: http://www.google.com/support/forum/p/Talk/thread?tid=07d7b64ead981922&hl=en says 443 is the correct port 01:26 < dfr|work> skelterjohn, it's not exactly on ruby. 01:26 < dfc> my mistake 01:27 < dfr|work> skelterjohn, gem 'yourgem', "= 4.56.4" sounds very similar to package "mypackage", "= 4.56.4" :) 01:27 < skelterjohn> dfr|work: how does that scheme work for ruby? 01:28 < dfr|work> skelterjohn, basically you define gem versions, and then there're >, <, <=, ~> operations to specify what you require. 01:28 < dfc> dfr|work: i've replicated the problem you are seeing 01:28 < skelterjohn> yes, i read your link 01:29 < dfc> my suggestion is to make your library use port 5222, and do the TLS upgrade after the connection 01:29 < skelterjohn> oh, i didn't mean "how does this work", even though i said it 01:29 < skelterjohn> i meant how well was it received 01:29 < skelterjohn> do people get frustrated, etc 01:29 < skelterjohn> does it solve the problem 01:29 < dfr|work> skelterjohn, well, it's defacto standard. 01:30 < dfr|work> skelterjohn, I don't hear too many issues considering the specification. 01:30 < dfr|work> skelterjohn, there're a bit more issues of trying to get several different packages to live together in one install, blah blah 01:30 < skelterjohn> i don't know why you'd say something like ">=2, <3" 01:30 < dfr|work> so that you can be working on an application that uses version 1 and other application that uses version 2 01:30 < skelterjohn> if you know there is a version 3, you probably know what the highest version 2.x is 01:30 < skelterjohn> why not just say that? 01:31 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts 01:31 < dfr|work> skelterjohn, well, ">=2, <3" will pick up all 2.x and you may trust the devs not to break compatibility for 2.x 01:31 < dfr|work> so you don't mind grabbing all the latest 01:31 < dfr|work> but 3 introduces incompatibilities, so you avoid that. 01:32 < skelterjohn> so this is when version 2.2 is released, then version 3, and then version 2.3 01:32 < dfr|work> skelterjohn, yup. 01:32 < dfr|work> dfc, so not use the tls package? 01:33 < dfr|work> dfc, or you mean like do a latter tls dialing after connecting to 5222 ? 01:33 < dfc> worse 01:33 < dfc> you'll have to read the whole xmpp rfc 01:33 < dfc> its a bloody big spec 01:33 < dfr|work> dfc, >.< 01:33 < dfc> which was where I ran aground 01:33 < dfc> here is how the common handshaking works 01:33 < dfc> c connects to server on 5222 01:33 < dfc> client sends <xml> <stream: /> with some details about itself 01:34 < dfc> server sends <stream: /> 01:34 < dfc> with some details about the authentication methods required 01:34 < dfc> which, in the case of gtalk requires starttls 01:34 < dfc> the client sends > <starttls /> which indicates it's ready to start the handshaking 01:34 < dfc> the server sends <proceed /> which means its ready to start 01:35 < dfc> only if both of these thigns happen 01:35 < dfc> then you wrap the conn in a tls.Conn 01:35 < dfr|work> by openning a new one, correct? 01:35 < dfc> and initiate the handshake (which is probably by sending more data) 01:35 < dfr|work> yup 01:35 < dfr|work> okay, I think I get the idea... 01:36 < dfc> its the way that xmpp works, i think the direct ssl connection methods have gone away 01:36 < dfr|work> okay, makes sense, I guess 01:36 < dfc> you can probably fake the inital handshake stuff 01:36 < dfr|work> I'll try it tomorrow. I'm trying to get home today a bit before 1am :D 01:36 < dfc> just blat out the inital xml 01:36 < dfr|work> dfc, yup. 01:36 < dfc> then wrap it in a tls.Conn and keep writing 01:36 < dfc> then, come back later and add code to parse the initial handshake response 01:37 < dfr|work> dfc, i don't necessarily care. I'm developing specifically for gtalk.... 01:37 < dfr|work> and I guess later I can then support, but I'd do regex parsing anyway, most likely 01:37 < dfr|work> but anyhow. Thanks! I'll definitely give it a go tomorrow. :) 01:37 < dfc> no probs 01:37 < dfc> what I would do is use tshark or ngrep 01:38 < dfc> grab the plaintext that pidgeon sends on the wire 01:38 -!- JusticeFries [~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] 01:38 < dfc> then just replay that 01:38 < dfc> that will get you through the tls stage 01:38 < dfc> and up to the authentication stage 01:43 < dfr|work> dfc, yea. I should probably just try it with a simple conn to initiate the stuff, and then do TLS only once it asked to proceed 01:47 < dfc> it should be pretty easy with go 01:47 < dfc> where I ran into problems were trying to do it with non blocking sockets and java's very complicated ssl engine 01:49 -!- MizardX [MizardX@unaffiliated/mizardx] has joined #go-nuts 01:49 < dfc> dfr|work: something like this 01:49 < dfc> func DialGTalk(username, password string) (io.ReadWriteCloser, os.Error) { 01:49 < dfc> return authenticate(starttls(net.DialTCP("tcp", nil, "talk.google.com:5222"), username, password) 01:51 < dfc> oops, got flood smacked, try https://gist.github.com/863432 01:52 -!- seromi [~seromi@77.118.165.64.wireless.dyn.drei.com] has joined #go-nuts 01:53 -!- _DerHorst_ [~Horst@e176101039.adsl.alicedsl.de] has quit [Remote host closed the connection] 01:57 -!- iant [~iant@67.218.107.6] has quit [Quit: Leaving.] 01:59 -!- seromi [~seromi@77.118.165.64.wireless.dyn.drei.com] has quit [Ping timeout: 252 seconds] 02:02 -!- tav_ [~tav@92.7.141.101] has joined #go-nuts 02:06 -!- tav [~tav@92.7.141.101] has quit [Ping timeout: 276 seconds] 02:16 -!- mikespook1 [~mikespook@219.137.72.94] has joined #go-nuts 02:19 -!- bobertlo [~robert@user-38q4b4r.cable.mindspring.com] has joined #go-nuts 02:20 -!- mikespook [~mikespook@219.137.49.35] has quit [Ping timeout: 255 seconds] 02:23 -!- eglaysher [~erg@nat/google/x-vaygpqgzejvdbiqh] has quit [Quit: leaving] 02:34 * skelterjohn procrastinates 02:35 -!- rl [~rbl@84-74-142-37.dclient.hispeed.ch] has quit [Ping timeout: 255 seconds] 02:40 -!- niemeyer_away [~niemeyer@201-40-152-213.pltce701.dsl.brasiltelecom.net.br] has quit [Ping timeout: 246 seconds] 02:41 -!- shvntr [~shvntr@113.84.149.43] has joined #go-nuts 02:42 -!- rl [~rbl@84-74-142-37.dclient.hispeed.ch] has joined #go-nuts 02:45 -!- nettok [~quassel@200.119.164.209] has joined #go-nuts 02:47 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has joined #go-nuts 02:47 -!- mode/#go-nuts [+v iant] by ChanServ 02:47 < cnan> going to sleep? 03:19 -!- m4dh4tt3r [~Adium@125.sub-75-208-77.myvzw.com] has quit [Ping timeout: 252 seconds] 03:25 -!- cnan [~cnan@122.80.198.193] has left #go-nuts [] 03:34 -!- aho [~nya@fuld-4d00d19f.pool.mediaWays.net] has quit [Quit: EXEC_over.METHOD_SUBLIMATION] 03:47 < steven> guys 03:47 < steven> how do we uninstall something that we installed via "make install"? 03:47 < steven> (a go package) 03:47 -!- meanburrito920 [~john@76-217-6-100.lightspeed.irvnca.sbcglobal.net] has joined #go-nuts 03:47 -!- meanburrito920 [~john@76-217-6-100.lightspeed.irvnca.sbcglobal.net] has quit [Changing host] 03:47 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has joined #go-nuts 03:47 < exch> delete it manually 03:48 < steven> awww 03:53 < dfc> make nuke 03:58 -!- gogogrrl_ [~max@p5DE8E3A4.dip.t-dialin.net] has joined #go-nuts 04:02 -!- gogogrrl [~max@p5790F511.dip.t-dialin.net] has quit [Ping timeout: 276 seconds] 04:12 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has quit [Ping timeout: 276 seconds] 04:12 -!- MizardX [MizardX@unaffiliated/mizardx] has quit [Quit: A free* quit message.] 04:15 -!- meanburrito920 [~john@76-217-6-100.lightspeed.irvnca.sbcglobal.net] has joined #go-nuts 04:15 -!- meanburrito920 [~john@76-217-6-100.lightspeed.irvnca.sbcglobal.net] has quit [Changing host] 04:15 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has joined #go-nuts 04:15 -!- rejb [~rejb@unaffiliated/rejb] has quit [Ping timeout: 246 seconds] 04:24 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has quit [Ping timeout: 240 seconds] 04:25 -!- iant [~iant@216.239.45.130] has joined #go-nuts 04:25 -!- mode/#go-nuts [+v iant] by ChanServ 04:36 -!- mnoel [~mnoel@c-75-65-250-60.hsd1.la.comcast.net] has quit [Quit: mnoel] 04:43 -!- nettok [~quassel@200.119.164.209] has quit [Ping timeout: 252 seconds] 04:47 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has quit [Quit: leaving] 04:51 < nickbp> steven: protip: i tend to install stuff like that with '--prefix=/opt/foo' so if i ever want to delete it, its all there 04:52 < nickbp> downside is i need to add /opt/foo/bin to PATH 04:52 < nickbp> but i rarely have more than a couple of those anyway 04:59 -!- keithgcascio [~keithcasc@nat/google/x-fmnsiqfoejmebrpy] has quit [Quit: Leaving] 05:10 -!- shvntr [~shvntr@113.84.149.43] has quit [Ping timeout: 276 seconds] 05:10 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has joined #go-nuts 05:10 -!- shvntr [~shvntr@113.84.149.43] has joined #go-nuts 05:14 -!- gstrock [~gstrock@adsl-75-22-61-157.dsl.irvnca.sbcglobal.net] has joined #go-nuts 05:21 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has joined #go-nuts 05:21 -!- mikespook1 [~mikespook@219.137.72.94] has quit [Read error: Connection reset by peer] 05:23 -!- mikespook [~mikespook@219.137.72.94] has joined #go-nuts 05:34 -!- snearch [~snearch@f053009136.adsl.alicedsl.de] has joined #go-nuts 05:38 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the connection] 05:39 -!- cenuij [~cenuij@78.112.41.178] has joined #go-nuts 05:39 -!- cenuij [~cenuij@78.112.41.178] has quit [Changing host] 05:39 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts 05:49 -!- bobertlo [~robert@user-38q4b4r.cable.mindspring.com] has quit [Quit: leaving] 05:49 -!- donpdonp [~donp@184-100-206-241.ptld.qwest.net] has joined #go-nuts 05:49 < donpdonp> how can i feed a string to a parameter of type io.Reader ? 05:50 < donpdonp> oh nm found another way :) 05:50 -!- donpdonp [~donp@184-100-206-241.ptld.qwest.net] has left #go-nuts [] 05:51 < dfc> bytes.NewString(string) << i think 05:56 -!- cenuij [~cenuij@base/student/cenuij] has quit [Quit: drivers] 05:56 < exch> bytes.NewBufferString(str) 05:57 < dfc> i know it wasn't NewBuffer() 06:06 -!- gid [~gid@220-253-33-95.VIC.netspace.net.au] has joined #go-nuts 06:08 -!- htoothrot [~mux@66-169-185-121.dhcp.ftwo.tx.charter.com] has quit [Read error: Connection reset by peer] 06:09 -!- htoothrot [~mux@66-169-185-121.dhcp.ftwo.tx.charter.com] has joined #go-nuts 06:11 -!- cenuij [~cenuij@78.112.41.178] has joined #go-nuts 06:11 -!- cenuij [~cenuij@78.112.41.178] has quit [Changing host] 06:11 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts 06:12 -!- skejoe [~skejoe@188.114.142.162] has joined #go-nuts 06:13 -!- dfc [~dfc@sydfibre2.atlassian.com] has quit [Ping timeout: 276 seconds] 06:22 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-181-230.clienti.tiscali.it] has joined #go-nuts 06:22 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has quit [Remote host closed the connection] 06:36 -!- jedws [~jwesleysm@sydfibre2.atlassian.com] has quit [Ping timeout: 276 seconds] 06:44 -!- skejoe [~skejoe@188.114.142.162] has quit [Quit: Lost terminal] 06:46 -!- donpdonp [~donp@184-100-206-241.ptld.qwest.net] has joined #go-nuts 06:47 < donpdonp> how can i get time.UTC().Format() to use the RFC3339 format? 06:48 < donpdonp> weird. what wasnt working before is now working. thx anyways :) time.UTC().Format(time.RFC3339) 06:50 < nickbp> (☞゚∀゚)☞ 06:51 -!- donpdonp [~donp@184-100-206-241.ptld.qwest.net] has left #go-nuts [] 07:02 -!- poseidon [~pondj@compile.vcu.edu] has joined #go-nuts 07:15 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:570:6975:3301:5550] has joined #go-nuts 07:17 -!- itrekkie [~itrekkie@ip72-211-129-122.tc.ph.cox.net] has quit [Quit: itrekkie] 07:17 -!- itrekkie [~itrekkie@ip72-211-129-122.tc.ph.cox.net] has joined #go-nuts 07:23 -!- Wiz126 [~Wiz@24.229.245.72.res-cmts.sm.ptd.net] has quit [Ping timeout: 246 seconds] 07:26 -!- photron [~photron@port-92-201-75-58.dynamic.qsc.de] has joined #go-nuts 07:30 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts 07:33 -!- Urmel|Work [~UrmelWork@cache1.uk.logica.com] has joined #go-nuts 07:37 -!- htoothrot [~mux@66-169-185-121.dhcp.ftwo.tx.charter.com] has quit [Read error: Connection reset by peer] 07:54 -!- wrtp [~rog@92.16.113.213] has joined #go-nuts 07:59 -!- htoothrot [~mux@66-169-185-121.dhcp.ftwo.tx.charter.com] has joined #go-nuts 08:07 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts 08:07 -!- dropdrive [~dropdrive@cpe-72-227-159-70.nyc.res.rr.com] has quit [Ping timeout: 255 seconds] 08:11 -!- neshaug [~oyvind@213.239.108.5] has quit [Ping timeout: 276 seconds] 08:11 -!- neshaug [~oyvind@213.239.108.5] has joined #go-nuts 08:18 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Ping timeout: 240 seconds] 08:31 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 08:40 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 250 seconds] 08:43 -!- napsy [~luka@193.2.66.6] has joined #go-nuts 08:48 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 08:48 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|] 08:54 -!- thomas_b [~thomasb@cm-84.215.47.51.getinternet.no] has quit [Ping timeout: 246 seconds] 08:56 -!- aimxhaisse [~mxs@buffout.org] has quit [Quit: Red is dead, adieu Youri] 08:56 -!- thomas_b [~thomasb@cm-84.215.47.51.getinternet.no] has joined #go-nuts 08:56 -!- rlab_ [~Miranda@91.200.158.34] has joined #go-nuts 08:57 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 252 seconds] 09:01 -!- visof [~visof@unaffiliated/visof] has joined #go-nuts 09:09 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 09:11 -!- rlab_ [~Miranda@91.200.158.34] has quit [Ping timeout: 276 seconds] 09:32 -!- mikespook [~mikespook@219.137.72.94] has quit [Quit: Leaving.] 09:37 -!- fzzbt [~fzzbt@77.79.7.8] has quit [Remote host closed the connection] 09:40 -!- snearch [~snearch@f053009136.adsl.alicedsl.de] has quit [Quit: Verlassend] 09:48 -!- rlab_ [~Miranda@91.200.158.34] has joined #go-nuts 09:49 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 240 seconds] 09:52 -!- chimes [~chimes@24.104.130.118] has quit [Ping timeout: 248 seconds] 09:53 -!- chimes [~chimes@209.118.191.162] has joined #go-nuts 10:24 -!- PortatoreSanoDiI [~Marvin@dynamic-adsl-94-36-162-223.clienti.tiscali.it] has joined #go-nuts 10:27 -!- serbaut [~joakims@88.80.182.68] has quit [Read error: Connection reset by peer] 10:27 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-181-230.clienti.tiscali.it] has quit [Ping timeout: 246 seconds] 10:28 -!- PortatoreSanoDiI [~Marvin@dynamic-adsl-94-36-162-223.clienti.tiscali.it] has quit [Read error: Connection reset by peer] 10:29 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has joined #go-nuts 10:30 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has left #go-nuts [] 10:32 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-162-223.clienti.tiscali.it] has joined #go-nuts 10:35 -!- saturnfive [~saturnfiv@210.74.155.131] has quit [Read error: Connection reset by peer] 10:36 -!- tvw [~tv@212.79.9.150] has joined #go-nuts 10:40 < piranha> is it possible to statically compile some C lib I interfaced with cgo in my binary? :) 10:42 < wrtp> piranha: i think so 10:42 < piranha> cool! 10:42 < piranha> wrtp: do you know if will it be done automatically or do I need to do anything? 10:43 < wrtp> i don't know. you could start by making sure that the C lib doesn't have any dynamic library files around. that way if it succeeds, you know it's statically linked 10:44 < wrtp> i'm pretty sure that some of the changes they made to cgo recently were to enable this. 10:44 -!- dropdrive [~dropdrive@cpe-72-227-159-70.nyc.res.rr.com] has joined #go-nuts 10:44 < wrtp> (but i may be wrong!) 10:45 < piranha> aha, ok, thank you 10:48 -!- rtharper_ [~tomh@188-220-5-137.zone11.bethere.co.uk] has quit [Remote host closed the connection] 10:59 -!- ronnyy [~quassel@p4FF1C53F.dip0.t-ipconnect.de] has joined #go-nuts 11:01 -!- rtharper [~tomh@unaffiliated/sioraiocht] has joined #go-nuts 11:04 < wrtp> piranha: i'm not sure you can directly 11:04 < wrtp> i couldn't get it to work 11:05 < wrtp> you could probably do it by putting the C lib files in the go package directory and getting cgo to build them 11:07 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts 11:07 < piranha> aha, I see 11:07 < wrtp> it knows about gcc .o files, but not .a files 11:07 < wrtp> ah, i've thought of another possibility 11:08 < wrtp> although it might make the binary quite big 11:08 < wrtp> you might be able to link all the obj files in the library together into one big obj file 11:15 < wrtp> you could try asking in golang-nuts 11:18 -!- tensorpudding [~user@99.56.160.152] has quit [Remote host closed the connection] 11:19 -!- eaburns [~eaburns@c-24-62-248-129.hsd1.nh.comcast.net] has joined #go-nuts 11:21 -!- cco3 [~conley@c-69-181-140-72.hsd1.ca.comcast.net] has quit [Ping timeout: 252 seconds] 11:23 < wrtp> piranha: i got it working 11:25 -!- PortatoreSanoDiI [~Marvin@dynamic-adsl-94-36-162-223.clienti.tiscali.it] has joined #go-nuts 11:25 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-162-223.clienti.tiscali.it] has quit [Read error: Connection reset by peer] 11:31 < wrtp> piranha: you just need to create an object file containing the necessary stuff linked in from your library 11:31 < wrtp> which you can do with ld -r 11:47 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has joined #go-nuts 11:48 -!- DerHorst [~Horst@e176101039.adsl.alicedsl.de] has joined #go-nuts 11:48 -!- Urmel|Work [~UrmelWork@cache1.uk.logica.com] has quit [] 11:52 < piranha> wrtp: wow cool, thank you 11:55 -!- Urmel|Work [~UrmelWork@cache1.uk.logica.com] has joined #go-nuts 11:57 < wrtp> i don't know if it'll work for every case though 11:57 < wrtp> i'm trying to work out a way of doing it a more consistent way 11:58 < wrtp> i got it working by creating a C file that references all the symbols 11:59 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Quit: Leaving] 12:19 -!- DerHorst [~Horst@e176101039.adsl.alicedsl.de] has quit [Ping timeout: 255 seconds] 12:21 < wrtp> piranha: ok, here's a little shell script that should make this quite easy 12:21 < wrtp> http://pastebin.com/fU55QHqw 12:22 < wrtp> save it in your $GOBIN and make it executable 12:22 < wrtp> then in your Makefile, add this: 12:22 < wrtp> libfiles := $(shell xtract.sh lib1.a lib2) 12:22 < wrtp> CGO_OFILES=\ 12:22 < wrtp> $(libfiles)\ 12:23 < wrtp> where lib1.a and lib2 are names of any libraries you want to statically link in 12:23 < wrtp> (it should be lib2.a) 12:27 < ww> how do you pass cflags to gcc for the c part of a package? i mean CGO_OFILES? 12:27 < ww> i know could make custon makefile... but want goinstall to work... 12:28 < ww> maybe it won't with ofiles anyyways... 12:31 -!- stalled [~stalled@unaffiliated/stalled] has quit [Quit: ...] 12:33 < piranha> wrtp: huh, nice! :) 12:36 -!- niemeyer [~niemeyer@201-40-152-213.pltce701.dsl.brasiltelecom.net.br] has joined #go-nuts 12:36 -!- jedws [~jwesleysm@c114-77-210-9.rivrw3.nsw.optusnet.com.au] has joined #go-nuts 12:37 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.4] 12:39 < wrtp> ww: see the docs for cgo 12:40 -!- photron [~photron@port-92-201-75-58.dynamic.qsc.de] has quit [Read error: Operation timed out] 12:40 < wrtp> ww: i think that #cgo CFLAGS should work for all the c files 12:41 -!- stalled [~stalled@unaffiliated/stalled] has joined #go-nuts 12:41 < wrtp> piranha: it's a bit of a hack, but i couldn't think of anything better for the time being 12:41 < piranha> sure, I just started learning this stuff so anything is really helpful :) 12:42 < wrtp> piranha: if you're just learning, it's best to stick to pure go if you can 12:42 < piranha> yep, I know that 12:42 < piranha> but regexp library for go is quite lacking 12:43 < piranha> for example, it can't do a replacement with submatches right now 12:43 < wrtp> piranha: i think it can 12:43 < piranha> http://golang.org/pkg/regexp/#Regexp.ReplaceAll 12:43 < wrtp> oh no, i see you're right 12:44 < piranha> No support is provided for expressions (e.g. \1 or $1) in the replacement text. 12:44 < piranha> aha 12:44 < piranha> so I'd like to wrap something else (pcre will be enough), but I want it to be included in binary 12:44 -!- saturnfive [~saturnfiv@113.135.127.170] has joined #go-nuts 12:45 < wrtp> if that's all you need, it would be quite straightforward to do, i think 12:45 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 12:46 < piranha> sure :) 12:46 -!- rlab_ [~Miranda@91.200.158.34] has quit [Ping timeout: 240 seconds] 12:49 -!- jedws [~jwesleysm@c114-77-210-9.rivrw3.nsw.optusnet.com.au] has quit [Quit: jedws] 12:51 -!- jedws [~jwesleysm@c114-77-210-9.rivrw3.nsw.optusnet.com.au] has joined #go-nuts 12:52 < wrtp> it would make a good exercise :-) 12:55 -!- stalled [~stalled@unaffiliated/stalled] has quit [Quit: ...] 12:55 -!- jedws [~jwesleysm@c114-77-210-9.rivrw3.nsw.optusnet.com.au] has quit [Ping timeout: 252 seconds] 12:56 < piranha> wrtp: exactly! :-) 13:00 < wrtp> better (and more instructive) to do that than to wrap pcre IMHO 13:02 -!- skejoe [~skejoe@188.114.142.162] has joined #go-nuts 13:03 -!- rlab_ [~Miranda@91.200.158.34] has joined #go-nuts 13:04 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 264 seconds] 13:23 -!- MizardX [MizardX@ip-233-6-72-178.dialup.ice.net] has joined #go-nuts 13:23 -!- MizardX [MizardX@ip-233-6-72-178.dialup.ice.net] has quit [Changing host] 13:23 -!- MizardX [MizardX@unaffiliated/mizardx] has joined #go-nuts 13:25 < skelterjohn> morning 13:26 < ww> 'afternoon 13:29 < piranha> wrtp: ah, you mean adding subpattern replacement... well, that too, but regexp from stdlib is quite slow, actually. I need to measure though 13:29 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has joined #go-nuts 13:30 < wrtp> piranha: yeah, i think it it slow 13:30 < wrtp> depends what you're using it for though 13:30 < wrtp> s/it it/it is/ 13:30 < piranha> search in a lot of files 13:30 < piranha> so this matters 13:30 < piranha> I thought about trying to wrap re2, but it's in C++ and has no C API... 13:32 < piranha> s/trying to wrap/wrapping/ (I still need to improve my English :\) 13:32 < wrtp> piranha: there's this, but it doesn't provide much functionality beyond matching. http://code.google.com/p/sre2/ 13:32 < piranha> wrtp: it's twice as slow as regexp :) 13:32 < piranha> I've measured that 13:32 < wrtp> that's interesting. it's meant to be faster! 13:32 < piranha> yeah, I don't know why, but it's certainly slower 13:33 -!- pilgrum [~pilgrum@cpe-67-49-71-222.socal.res.rr.com] has quit [Quit: Leaving] 13:35 < wrtp> what kind of regexp were you testing it on? 13:36 < piranha> something simple, like ten plain letters 13:36 < piranha> ah no 13:37 < wrtp> piranha: on a file or a string? 13:37 < piranha> I've tried to match some (short) string with this list of regular expressions: []string{`*$`, `#*#`, `[._]*.swp`, `*.pyc`, `*.o`, `*.6`} 13:37 < piranha> no one of them matches this string (it was something like "qweqweqwe") 13:38 < wrtp> the first one is an invalid regexp, BTW 13:39 < wrtp> as are the last three 13:39 < skelterjohn> you're giving it file wildcards 13:39 < piranha> ah, really, those are for path.Match actually 13:39 < skelterjohn> which are not the same as regexps 13:39 < piranha> yes, I've copied strings I've used for path.Match, sorry :) 13:39 < skelterjohn> *.6 would be .*\.6 13:40 < piranha> []string{`~$`, `#.+#$`, `[._].*\.swp$`, `core\.[0-9]+$`, `\.pyc$`, `\.o$`, `\.6$`} 13:40 < piranha> here they are 13:40 < piranha> I don't know why I have "*$" as first string for path.Match, heh 13:41 < wrtp> almost of all of those have a fixed prefix, which regexp fast-paths. 13:42 < wrtp> if sre2 doesn't, then that might explain the results 13:42 < piranha> wrtp: fixed prefix? they are not anchored at start of line. 13:43 < piranha> path looks like some/dir/core.1234, for example 13:44 < skelterjohn> i'm not sure what you mean either, wrtp 13:44 < wrtp> piranha: no they're not anchored, but they have a non-variable textual prefix (e.g. "~", "#", "core", etc) 13:44 < wrtp> regexp uses strings.Index to find this prefix first before trying the rest of the regexp 13:45 < piranha> hm, ok 13:45 < wrtp> whereas sre2 just calls utf8.DecodeRune on each char 13:45 < piranha> maybe this is a cause, but in this case re2 won't be really faster... 13:46 < wrtp> no, it'll be slower 13:46 < wrtp> because it does a lot more for each character in the initial stage 13:47 < piranha> I mean even if it had this shortcut 13:47 < skelterjohn> why can regexp get away without using DecodeRune, where re2 can't? 13:48 < wrtp> skelterjohn: because it assumes that the input consists of well-formed utf8 13:48 < wrtp> skelterjohn: rather, strings.Index does 13:48 < wrtp> so you can compare two strings without converting to unicode 13:49 < wrtp> the two will have differing semantics when the input has malformed utf8 13:50 < wrtp> you might find that regexp is slower when searching for 'aaaaaaaaaaaaab' in a file full of endless 'a's. 13:50 < wrtp> because strings.Index is O(n^2) 13:50 < skelterjohn> O(n*m), maybe 13:51 < wrtp> yeah 13:51 < skelterjohn> not normal to assume the pattern is the same length as the string :) 13:51 < wrtp> yeah yeah, y'know what i mean :-) 13:51 < skelterjohn> it could easily be O(n) though 13:51 < skelterjohn> though the code would look more complicated 13:51 < wrtp> skelterjohn: not without increasing the constant 13:52 < wrtp> skelterjohn: and that's often more important 13:52 < skelterjohn> the constant is in there, don't you see it? -> O(n) 13:52 < wrtp> no, i mean the constant factor. the actual numbers rather than the asymptotic behaviour 13:52 < skelterjohn> i know 13:53 < wrtp> oh, sorry 13:53 < skelterjohn> i was making a joke 13:53 < skelterjohn> i'm not good at that 13:53 < wrtp> i've seen funnier :-) 13:53 < skelterjohn> no doubt 13:54 < wrtp> i'm not good at making jokes either :-) 13:54 < skelterjohn> but for strings.Index, a quick length check at the beginning to decide whether to be n*m or n+m would be possible 13:55 < wrtp> it depends on the input though. if the input contains very few occurrences of the first character in the match string, then it'll be O(n), and difficult to beat... 13:56 < skelterjohn> you would do this in cases where n is much larger than m 13:56 < skelterjohn> so the time taken to build the FSM is low 13:56 < skelterjohn> and when m is large enough such that n*m is high 13:57 -!- qjcg [~qjcg@208.88.110.46] has joined #go-nuts 13:57 < skelterjohn> there are a bunch of tradeoffs 13:57 < wrtp> i think it would be better if regexp itself did the trade-off rather than complicating the ultra-simple string implementation 13:58 -!- sauerbraten [~sauerbrat@p508CAD5D.dip.t-dialin.net] has joined #go-nuts 13:59 < skelterjohn> could be as simple as if len(pat) < something { do what we normally do } else { do it with a regexp } 13:59 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts 14:00 < wrtp> strings can't depend on regexp 14:00 < wrtp> oh i see 14:00 -!- qjcg [~qjcg@208.88.110.46] has left #go-nuts [] 14:00 < wrtp> yes, exactly 14:01 < wrtp> it's simpler than that even 14:01 < skelterjohn> it can't? 14:01 < skelterjohn> because regexp will do strings.Index sometimes? :) 14:01 < wrtp> skelterjohn: no, because regexp depends on strings 14:01 < skelterjohn> (that would certainly have to change to make this work) 14:03 < wrtp> you'd also have to make it not depend on bytes, which is harder 14:03 < wrtp> as it uses bytes.Buffer extensively 14:03 < wrtp> if i import strings, i don't want to import all of regexp too 14:03 < kimelto> If I have a variable which point to a type (possibly with data in it). Can I reset it to its clean state? I mean to "zero". 14:04 < wrtp> kimelto: you can, but only if you can assign to it 14:04 < skelterjohn> i don't know why bytes comes into it 14:04 < kimelto> The purpose would be to reuse allocated struct instead of free/alloc a new one 14:04 < skelterjohn> bytes doesn't depend on strings 14:04 < wrtp> skelterjohn: no, but regexp uses bytes.Index too 14:04 < kimelto> wrtp: without doing it manually I mean :) 14:04 < wrtp> in the same way as strings.Index 14:04 < wrtp> kimelto: you can just do: *ptr = zeroStruct 14:05 < skelterjohn> ah - this is a linker optimization - it shouldn't bring in stuff it doesn't need 14:05 < wrtp> where var zeroStruct myStructType 14:05 < wrtp> skelterjohn: what? 14:05 -!- napsy [~luka@193.2.66.6] has quit [Ping timeout: 250 seconds] 14:05 < skelterjohn> you don't need a byte buffer to match a fixed string with a FSM 14:05 < skelterjohn> not if you do it right 14:06 < wrtp> skelterjohn: it uses byte buffers for things other than matching 14:06 < wrtp> for instance to build up a string when replacing 14:06 < skelterjohn> right, so the linker should know how to not bring that in if the only thing used is matching 14:06 < skelterjohn> well, not so much "should" 14:06 < ww> i just rewrote some (much simpler) bits of code to just use copy/append instead of Buffer 14:06 < skelterjohn> as "it would be neat" 14:06 < wrtp> skelterjohn: you can't have cyclic dependencies, period. 14:07 < skelterjohn> there is no cyclic dependency issue here 14:07 -!- eaburns [~eaburns@c-24-62-248-129.hsd1.nh.comcast.net] has left #go-nuts [] 14:07 < wrtp> skelterjohn: i think there is. you want to make strings.Index (and by implication bytes.Index) faster by using a regexp when the matching string is large 14:08 < wrtp> that can only be done by having bytes.Index depend on regexp. 14:08 < wrtp> but regexp depends on bytes. 14:08 < wrtp> -> cyclic dependency 14:08 < skelterjohn> if you keep the same regexp pkg 14:08 < wrtp> sure, you could implement a load of other stuff. you could do boyer moore. 14:08 < skelterjohn> there is nothing fundamental saying this cannot be done avoiding cyclic dependencies 14:09 -!- plainhao [~plainhao@208.75.85.237] has joined #go-nuts 14:09 < wrtp> but i think it's best to keep bytes.Index and strings.Index very simple. 14:09 < wrtp> that way you know the performance characteristics, and if it becomes a bottleneck, you can use some other, more sophisticated form of matching 14:09 < kimelto> wrtp: myVar = MyType{} seems to work too :) 14:10 < wrtp> kimelto: yes, that'll work 14:10 < wrtp> although i thought you had a pointer type 14:11 < ww> wrtp: you are correct, gcc gets the #cgo CFLAGS: passed to it for c parts 14:11 < wrtp> ww: cool 14:12 < wrtp> skelterjohn: currently strings.Index and bytes.Index do no allocation. that would be difficult to do with a more sophisticated algorithm. 14:13 -!- stalled [~stalled@unaffiliated/stalled] has joined #go-nuts 14:13 < kimelto> wrtp: mmh with the zeroStruct it doesnt work with pointer too. at least I cant make it work :) 14:14 < kimelto> I only want to bzero() it!! :p 14:14 < wrtp> kimelto: *myVar = MyType{} 14:15 -!- saturnfive [~saturnfiv@113.135.127.170] has left #go-nuts [] 14:15 < kimelto> makes total sense 14:15 < wrtp> kimelto: that bit of Go is very like C 14:18 < kimelto> indeed :) 14:19 < wrtp> kimelto: you could even use memzero itself if it was really an issue... 14:25 -!- ww [~ww@river.styx.org] has quit [Ping timeout: 255 seconds] 14:30 -!- ildorn [~ildorn@dslb-188-105-055-124.pools.arcor-ip.net] has joined #go-nuts 14:32 -!- boscop [~boscop@f055110140.adsl.alicedsl.de] has joined #go-nuts 14:35 -!- ww [~ww@river.styx.org] has joined #go-nuts 14:36 -!- MizardX [MizardX@unaffiliated/mizardx] has quit [Ping timeout: 276 seconds] 14:36 -!- MizardX [MizardX@ip-233-6-72-178.dialup.ice.net] has joined #go-nuts 14:36 -!- MizardX [MizardX@ip-233-6-72-178.dialup.ice.net] has quit [Changing host] 14:36 -!- MizardX [MizardX@unaffiliated/mizardx] has joined #go-nuts 14:39 -!- plainhao [~plainhao@208.75.85.237] has quit [Remote host closed the connection] 14:40 -!- plainhao [~plainhao@208.75.85.237] has joined #go-nuts 14:45 -!- visof [~visof@unaffiliated/visof] has quit [Ping timeout: 240 seconds] 14:48 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts 14:49 -!- ildorn [~ildorn@dslb-188-105-055-124.pools.arcor-ip.net] has quit [Quit: Leaving.] 14:52 < ww> any of you web folks have a good http autoneg library for go? 14:53 -!- skelterjohn [~jasmuth@c-68-46-33-145.hsd1.nj.comcast.net] has quit [Quit: skelterjohn] 14:54 -!- lmoura [~lauromour@187.113.96.229] has quit [Read error: Connection reset by peer] 14:56 -!- lmoura [~lauromour@186.215.206.130] has joined #go-nuts 15:01 -!- Venom_X [~pjacobs@66.54.185.133] has joined #go-nuts 15:02 -!- dario [~dario@domina.zerties.org] has joined #go-nuts 15:03 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts 15:13 < wrtp> ww: not as far as i know 15:13 * wrtp had to google for [http autoneg] 15:14 < ww> wrtp: heavily used in semweb - get this resource in X format 15:14 < ww> actually funny bug in google chrome (may have been fixed) 15:14 < ww> if you look at the Accept header it sends, it prefers png to text/html or some such 15:15 < ww> now not many resources exist in both png and html variants so it almost never comes up in practice 15:15 < ww> but funny that chrome prefers pictures of web pages to web pages themselves :) 15:20 < wrtp> interesting 15:25 < ww> 2011/03/10 15:27:48 listen error: unknown network sctp 15:25 < ww> :( 15:25 < saracen> After storing a function pointer in a vector.Vector, how would I think go about calling it? At the moment, it throws an error complaining that interface{} is a non-function, so I have to cast it somehow. Any ideas? 15:25 < saracen> then go about* 15:26 < aiju> saracen: foo.(Type) 15:26 < aiju> called a type assertion 15:27 -!- jgonzalez [~jgonzalez@173-14-137-134-NewEngland.hfc.comcastbusiness.net] has joined #go-nuts 15:27 < saracen> Ah ha, thank you aiju :) 15:28 < wrtp> saracen: it's generally not recommended to use vector.Vector, unless there's a good reason for doing so 15:28 < wrtp> it's rarely necessary 15:29 < saracen> What other container would you recommend? I need to store a growable list of function pointers. From what I've seen, if I use a slice, I would then have to control the size of it manually 15:31 < aiju> no 15:31 < aiju> slice = append(slice, fn) 15:32 < wrtp> saracen: what aiju says 15:33 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has joined #go-nuts 15:36 < saracen> Ah, I see. thank you 15:36 < wrtp> np 15:49 -!- skejoe [~skejoe@188.114.142.162] has quit [Quit: Lost terminal] 15:50 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has quit [Excess Flood] 15:51 -!- Urmel|Work [~UrmelWork@cache1.uk.logica.com] has quit [Ping timeout: 250 seconds] 15:53 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has joined #go-nuts 16:02 < steven> i have done "append(slice, obj)" without assigning it 16:02 < steven> fortunately the compiler considers that an error :) 16:03 < steven> whereas PHP doesnt, which has caused me confusion in the past, hehe 16:06 < xyproto> will b be evaulated if a is true? if a || b 16:06 < xyproto> *evaluated 16:08 < MizardX> steven: append() might return a new slice, if the supplied one does not have enough capacity. 16:10 < MizardX> xyproto: || and && are shortcircuited, so no. 16:13 < xyproto> MizardX: k, thx 16:18 -!- plainhao [~plainhao@208.75.85.237] has quit [Quit: plainhao] 16:19 -!- plainhao [~plainhao@208.75.85.237] has joined #go-nuts 16:23 -!- MizardX [MizardX@unaffiliated/mizardx] has quit [Ping timeout: 240 seconds] 16:23 -!- JusticeFries [~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net] has joined #go-nuts 16:24 -!- MizardX [MizardX@unaffiliated/mizardx] has joined #go-nuts 16:24 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.4] 16:28 -!- JusticeFries [~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net] has quit [Read error: Connection reset by peer] 16:28 < xyproto> MizardX: I couldn't find anything about shortcircuiting in the go langauge spec, btw. 16:30 < MizardX> xyproto: Look under Logical operators 16:31 < MizardX> It's not stated with those words, but what is described is shortcircuiting 16:44 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has quit [Quit: Computer has gone to sleep.] 16:53 -!- shvntr [~shvntr@113.84.149.43] has quit [Quit: leaving] 16:57 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts 17:00 -!- MizardX [MizardX@unaffiliated/mizardx] has quit [Ping timeout: 240 seconds] 17:04 -!- piranha [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts 17:05 -!- MizardX [MizardX@ip-233-6-72-178.dialup.ice.net] has joined #go-nuts 17:05 -!- MizardX [MizardX@ip-233-6-72-178.dialup.ice.net] has quit [Changing host] 17:05 -!- MizardX [MizardX@unaffiliated/mizardx] has joined #go-nuts 17:09 -!- czr_ [czr@nexus.iohazard.net] has joined #go-nuts 17:10 < czr_> hi there. considering playing with go. how would you say go fits parsing binary data structures (binary network protocols) and generating binary stuff? (comparing to say C) 17:11 < jnwhiteh> given that there are structs and you read binary data directly into structs and vice-versa I think it does fairly well =) 17:11 < czr_> so stuff like bitfields, endianess conversion and such is easy? or verbose? 17:12 -!- rtharper [~tomh@unaffiliated/sioraiocht] has quit [Remote host closed the connection] 17:12 < jnwhiteh> I haven't dealt with endianess conversion at all, but I've had no problems with bitfields and binary structs of data, perhaps someone else has =) 17:13 < czr_> cool. I think that's enough for now, I'll take mi axe out and grind go a bit with it :-). thanks 17:13 < czr_> ideally I'd also like to use it on ARM (without VFP), but I guess if I wait enough, it will magically happen ;-).. 17:14 < wrtp> czr_: easier than C for parsing binary structures 17:14 < czr_> wrtp, excellent 17:14 < wrtp> czr_: can be a bit slower if you use the full power of the binary parsing 17:15 < czr_> also, what would be a best place to ask newbie-level questions? (newbie in go, not programming per se). is this channel ok, or is there a better place? 17:15 < wrtp> this is fine 17:15 * czr_ nods 17:16 < wrtp> czr_: see this package for encoding and decoding fixed-format binary: http://golang.org/pkg/encoding/binary/ 17:18 < czr_> wrtp, is the speed difference due to optimizing issues in the current compiler(s) or something more fundamental (ref-counting/suchlike)? 17:19 < czr_> ah yes, I also had a real question. how does go memory usage compares to say python? I've often found that python (esp on 64-bit) blows up wrt memory usage with larger work-sets. using maps is way too easy, but the memory is sucked away quickly. 17:22 -!- keithcascio [~keithcasc@nat/google/x-iyqrlzuvwqvkoubj] has joined #go-nuts 17:25 < wrtp> wrtp: the speed difference in that case is mostly due to the speed of the reflection package, which will get faster, but it's not clear how much faster. 17:26 < wrtp> czr_: i haven't used go much on large memory stuff, so i can't answer that question. go does make it easier to control memory layout and usage (to an extent) than python 17:26 < czr_> oki. I think I'll find out eventually. 17:26 < czr_> is there a way to release gc reclaimed free memory back to the OS? 17:27 < czr_> (Linux in this case) 17:27 -!- lmoura [~lauromour@186.215.206.130] has quit [Ping timeout: 255 seconds] 17:27 -!- cenuij [~cenuij@base/student/cenuij] has quit [Quit: It's beer o'clock!] 17:28 -!- plainhao [~plainhao@208.75.85.237] has quit [Remote host closed the connection] 17:29 < wrtp> czr_: no 17:29 < wrtp> not currently 17:30 < czr_> hmm. what about IPC between two go processes? 17:30 < czr_> (ending the process would reclaim memory, assuming one first moves the used dataset to the other process) 17:30 -!- ymasory [~ymasory@c-76-99-55-224.hsd1.pa.comcast.net] has quit [Quit: Leaving] 17:31 < wrtp> go processes share memory 17:32 < wrtp> so they both use the usual garbage collector mechanisms for reclaiming memory 17:33 < czr_> so, I start two separate go programs from a shell, and they use the same runtime environment somehow? 17:33 < wrtp> no 17:33 < wrtp> i thought you meant goroutines, sorry 17:33 < czr_> ah. yeah :-) np 17:33 < wrtp> yeah, each go process is its own world 17:33 < czr_> right. is there some recommended way to do IPC between two local go processes then? 17:33 < wrtp> when it comes to memory 17:34 < wrtp> czr_: either the netchan or the rpc package might suit your needs 17:34 < czr_> I could always go for something that marshals stuff into tmpfs and the other process demarshals it. but that would be.. something. is there automatic marshalling in go? 17:34 < wrtp> czr_: see the gob package 17:34 < wrtp> or the json package, if you want to go more verbose 17:34 < czr_> ok, I'll check them out. I think I should really do some testing and looking first before asking more questions :-) 17:34 < czr_> ugh no. json probably would be quite overheady 17:34 < wrtp> gob is the equivalent of python's pickle 17:35 < wrtp> it doesn't marshal everything though 17:35 < czr_> that's to be expected 17:35 < czr_> I normally use cPickle anyway with python, and it doesn't do magic either 17:35 < czr_> one last question (promise) 17:35 < wrtp> gob's fine for transferring the usual stuff between processes 17:35 < wrtp> np 17:35 < czr_> how difficult would it be to use system calls using asm wrappers? 17:36 -!- rtharper [~tomh@unaffiliated/sioraiocht] has joined #go-nuts 17:36 < czr_> as a precursor to getting rid of libc dependency 17:36 < czr_> (assuming the program is simple enough just to do basic I/O, socket stuff and mmap) 17:36 < wrtp> czr_: there is no libc dependency 17:36 < wrtp> czr_: go does it all itself anyway 17:36 < czr_> no libc dep? 17:36 < czr_> even at compile time? 17:36 < wrtp> (unless you deliberately decide to use some non-Go C code) 17:37 < wrtp> no, the compiler is built with gcc 17:37 -!- bleakgadfly [~bgadfly@nerdhaven.nuug.no] has quit [Quit: Lost terminal] 17:37 < czr_> interesting 17:37 < czr_> I think I misunderstood something I read earlier then 17:37 < czr_> thanks for your time wrtp 17:37 < wrtp> what did you read? 17:38 < czr_> that Go has only libc as a dependency 17:38 -!- lmoura [~lauromour@186.215.1.55] has joined #go-nuts 17:38 < wrtp> i think that must have meant the compiler 17:38 < czr_> I realize that currently the compilers generate statically linked programs, but I thought that libc.a would be included then 17:38 < wrtp> nope. 17:38 < czr_> ah yes, it was something to do with the compiled hello world program in go and why it was so "huge" 17:38 < wrtp> at least, i'm pretty sure they don't 17:38 < czr_> can't recall the exact url now unfortunately.. 17:39 < wrtp> the binaries are big because of the reflection data 17:39 < skelterjohn> czr_: it's huge because it has to link in a lot of package deps 17:39 < wrtp> (it keeps info on all types) 17:39 < czr_> ah. so all of go's "standard libs" (what do you call them?) are always included in all compiled go programs? 17:39 < skelterjohn> wrtp: you once hinted at reflect becoming a lot faster soon. can you say any more about that? 17:39 -!- gogogrrl_ [~max@p5DE8E3A4.dip.t-dialin.net] has quit [Read error: Operation timed out] 17:39 < skelterjohn> czr_: yeah (we call them the core) 17:40 < wrtp> czr_: no, only libraries that are used are linked in 17:40 < skelterjohn> err, right 17:40 < czr_> ok :-) 17:40 < wrtp> in fact, only functions that are used are linked in 17:40 < wrtp> but... 17:40 < czr_> can the compiler inline? 17:40 < skelterjohn> fmt.Println uses reflect 17:40 < czr_> (for example the endianess conversion stuff that you pointed me to earlier) 17:40 < wrtp> one of the ubiquitous packages is "fmt" - everything uses it, and it uses reflect and unicode 17:40 < wrtp> czr_: can't inline yet 17:41 < wrtp> although it's on the roadmap 17:41 -!- cco3 [~conley@c-69-181-140-72.hsd1.ca.comcast.net] has joined #go-nuts 17:41 < wrtp> skelterjohn: i don't know anything beyond hints from rsc on the mailing list 17:41 < czr_> ok. which compiler would you recommend to use? the gccgo one or the other one? 17:41 < skelterjohn> czr_: depends on what you want to do 17:42 < skelterjohn> if you want thousands of goroutines, use 6g/8g/5g 17:42 < czr_> yes please! :-) 17:42 < wrtp> skelterjohn: http://groups.google.com/group/golang-dev/msg/c13c8c68164d7aa0 17:42 < skelterjohn> if you don't use goroutines so much, and want faster code, use gccgo 17:42 < wrtp> czr_: 6g definitely 17:42 < skelterjohn> but last i heard, gccgo spawns a thread for a new goroutine 17:42 < wrtp> i've never managed to get gccgo compiled 17:42 < czr_> right. I guess linking against external libs would be easier with gccgo? 17:42 < skelterjohn> i've never tried 17:42 < wrtp> and it's much less travelled than the other one 17:42 < czr_> or is there a reason to use it instead of 6g? 17:42 < skelterjohn> czr_: it's easy with 6g 17:43 < skelterjohn> you can use cgo 17:43 < skelterjohn> czr_: gccgo uses gcc's optimizer 17:43 < skelterjohn> which is better than 6g's optimizer 17:43 < czr_> main reason I'm looking at go is coroutines. I want to test out how much easier it is to write "parallel" event driven protocol parsers using a "linear procedural" model instead of the stock select/state-machine driven approach 17:44 < wrtp> czr_: what kind of protocols? 17:44 < czr_> wrtp, line based usual suspects (http/*, smtp/*) and some binary stuff maybe later (dns, snmp) 17:45 < czr_> perfornace isn't paramount at this moment really. I'm willing to lose some if it makes general development easier and less error-prone 17:46 < wrtp> czr_: in which case, i'd say that the linear procedural model is exactly what go is good at. you don't have to worry about the other processes... 17:46 < czr_> well, you don't have to worry about concurrency with select/state-machines either, but writing the code is quite tedious with more complex stuff 17:47 < wrtp> czr_: yeah, it's dead easy with goroutines 17:47 < czr_> I have to lug some books from the car to the apartment next, but will be back later once I've setup something to play with 17:47 < czr_> thanks a lot, you've been a great help :-). and sorry about the newbie questions 17:47 < wrtp> i'll be gone by then, but back tomorrow 17:48 < wrtp> have fun 17:48 < czr_> no problems :-) 17:48 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 17:49 -!- gogogrrl [~max@p5DE8E3A4.dip.t-dialin.net] has joined #go-nuts 17:53 -!- dfr|work [~dfr|work@nat/google/x-igydcqpfmuagrveu] has quit [Remote host closed the connection] 18:05 -!- piranha [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has quit [Remote host closed the connection] 18:05 -!- dfr|work [~dfr|work@nat/google/x-uwutdxfrweniavqp] has joined #go-nuts 18:10 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts 18:14 -!- ccount [~ccount@aleph0.de] has joined #go-nuts 18:14 < ccount> hi 18:15 < skelterjohn> hi 18:15 -!- ShadowIce [~pyoro@HSI-KBW-109-193-120-162.hsi7.kabel-badenwuerttemberg.de] has joined #go-nuts 18:15 -!- ShadowIce [~pyoro@HSI-KBW-109-193-120-162.hsi7.kabel-badenwuerttemberg.de] has quit [Changing host] 18:15 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts 18:15 < ccount> what is the reason for strings being immutable in go? 18:24 -!- aho [~nya@fuld-590c74ed.pool.mediaWays.net] has joined #go-nuts 18:28 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Ping timeout: 264 seconds] 18:31 -!- Fish [~Fish@9fans.fr] has joined #go-nuts 18:40 <+iant> a mutable string is just []byte 18:40 <+iant> ccount: string constants just seem like a basic concept in a modern language 18:43 < aiju> string constants are a basic concept in virtually ANY language 18:43 < aiju> even FORTRAN IV has them 18:43 <+iant> yeah 18:44 <+iant> Forth doesn't have them 18:44 <+iant> I think 18:44 < aiju> no 18:44 < aiju> afaik they do some funny stuff with the parser and are a bit hackish, but they exist 18:44 <+iant> ok 18:45 < aiju> e.g. S" blubb" 18:46 < aiju> (note that the first space doesn't count) 18:48 -!- plainhao [~plainhao@208.75.85.237] has joined #go-nuts 18:49 -!- JusticeFries [~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net] has joined #go-nuts 18:50 < ccount> i see. thanks for the explanation 18:52 -!- TheMue [~TheMue@p5DDF574E.dip.t-dialin.net] has joined #go-nuts 18:58 -!- tvw [~tv@212.79.9.150] has quit [Remote host closed the connection] 19:00 -!- MizardX- [MizardX@ip-233-6-72-178.dialup.ice.net] has joined #go-nuts 19:00 -!- MizardX- [MizardX@ip-233-6-72-178.dialup.ice.net] has quit [Changing host] 19:00 -!- MizardX- [MizardX@unaffiliated/mizardx] has joined #go-nuts 19:01 -!- MizardX [MizardX@unaffiliated/mizardx] has quit [Ping timeout: 250 seconds] 19:03 -!- rtharper [~tomh@unaffiliated/sioraiocht] has quit [Remote host closed the connection] 19:05 -!- MizardX- [MizardX@unaffiliated/mizardx] has quit [Ping timeout: 250 seconds] 19:09 -!- photron [~photron@port-92-201-75-58.dynamic.qsc.de] has joined #go-nuts 19:35 -!- fabled [~fabled@mail.fi.jw.org] has quit [Quit: Ex-Chat] 19:37 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has quit [Read error: Connection reset by peer] 19:42 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.4] 19:42 -!- itrekkie [~itrekkie@ip72-211-129-122.tc.ph.cox.net] has quit [Ping timeout: 276 seconds] 19:43 -!- itrekkie [~itrekkie@ip72-211-129-122.tc.ph.cox.net] has joined #go-nuts 19:46 -!- TheMue [~TheMue@p5DDF574E.dip.t-dialin.net] has quit [Quit: TheMue] 19:52 -!- wrtp [~rog@92.16.113.213] has quit [Quit: wrtp] 19:56 -!- Venom_X [~pjacobs@66.54.185.133] has quit [Quit: Venom_X] 20:09 -!- ronnyy [~quassel@p4FF1C53F.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 20:36 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-170-213.clienti.tiscali.it] has joined #go-nuts 20:39 -!- pjm0616 [~user@sigfpe-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [Remote host closed the connection] 20:39 -!- tensorpudding [~user@99.56.160.152] has joined #go-nuts 20:39 -!- PortatoreSanoDiI [~Marvin@dynamic-adsl-94-36-162-223.clienti.tiscali.it] has quit [Ping timeout: 240 seconds] 20:41 -!- Venom_X [~pjacobs@66.54.185.133] has joined #go-nuts 20:48 -!- adu_ [~ajr@softbank220043138128.bbtec.net] has joined #go-nuts 20:51 -!- m4dh4tt3r [~Adium@c-69-181-223-245.hsd1.ca.comcast.net] has joined #go-nuts 20:53 -!- adu_ [~ajr@softbank220043138128.bbtec.net] has quit [Client Quit] 20:53 -!- adu_ [~ajr@softbank220043138128.bbtec.net] has joined #go-nuts 20:57 -!- adu [~ajr@softbank220043138128.bbtec.net] has quit [Client Quit] 20:57 -!- adu [~ajr@softbank220043138128.bbtec.net] has joined #go-nuts 21:02 -!- JusticeFries [~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net] has quit [Ping timeout: 250 seconds] 21:12 -!- sauerbraten [~sauerbrat@p508CAD5D.dip.t-dialin.net] has quit [Remote host closed the connection] 21:13 -!- Fish [~Fish@9fans.fr] has quit [Quit: So Long, and Thanks for All the Fish] 21:13 -!- MizardX [~MizardX@ip-218-41-179-93.dialup.ice.net] has joined #go-nuts 21:13 -!- MizardX [~MizardX@ip-218-41-179-93.dialup.ice.net] has quit [Changing host] 21:13 -!- MizardX [~MizardX@unaffiliated/mizardx] has joined #go-nuts 21:13 < dario> nothing up here ... 21:13 -!- Fish [~Fish@9fans.fr] has joined #go-nuts 21:14 -!- dropdrive [~dropdrive@cpe-72-227-159-70.nyc.res.rr.com] has quit [Quit: leaving] 21:14 -!- dropdrive [~dropdrive@cpe-72-227-159-70.nyc.res.rr.com] has joined #go-nuts 21:15 < adu> dario: tons 21:21 -!- photron [~photron@port-92-201-75-58.dynamic.qsc.de] has quit [Ping timeout: 276 seconds] 21:25 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has quit [Ping timeout: 276 seconds] 21:25 -!- tvw [~tv@e176005253.adsl.alicedsl.de] has joined #go-nuts 21:27 -!- PortatoreSanoDiI [~Marvin@dynamic-adsl-94-36-165-106.clienti.tiscali.it] has joined #go-nuts 21:30 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-170-213.clienti.tiscali.it] has quit [Ping timeout: 240 seconds] 21:30 -!- adu [~ajr@softbank220043138128.bbtec.net] has quit [Quit: adu] 21:30 -!- wrtp [~rog@92.16.113.213] has joined #go-nuts 21:38 < skelterjohn> you've got me. should be enough. 21:40 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts 21:46 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has quit [Quit: skelterjohn] 21:48 < steven> i dont think Go can take off as a web-app language like Ruby did, on account of its not interpreted 21:48 < steven> thus you cant as easily do things such as rake tasks and whatnot. so deployment and db management may become much more diffficult on production 21:50 -!- MizardX [~MizardX@unaffiliated/mizardx] has quit [Ping timeout: 240 seconds] 21:51 -!- plainhao [~plainhao@208.75.85.237] has quit [Quit: plainhao] 21:52 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Quit: Leaving] 21:53 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts 21:54 -!- MizardX [MizardX@ip-218-41-179-93.dialup.ice.net] has joined #go-nuts 21:54 -!- MizardX [MizardX@ip-218-41-179-93.dialup.ice.net] has quit [Changing host] 21:54 -!- MizardX [MizardX@unaffiliated/mizardx] has joined #go-nuts 21:59 -!- wrtp [~rog@92.16.113.213] has quit [Quit: wrtp] 22:04 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has quit [Read error: Operation timed out] 22:05 -!- JusticeFries [~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net] has joined #go-nuts 22:06 -!- MizardX [MizardX@unaffiliated/mizardx] has quit [Ping timeout: 248 seconds] 22:06 -!- MizardX [MizardX@ip-218-41-179-93.dialup.ice.net] has joined #go-nuts 22:06 -!- MizardX [MizardX@ip-218-41-179-93.dialup.ice.net] has quit [Changing host] 22:06 -!- MizardX [MizardX@unaffiliated/mizardx] has joined #go-nuts 22:09 -!- JusticeFries [~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 22:09 -!- virtualsue [~chatzilla@nat/cisco/x-xzrdaashtoomqymm] has joined #go-nuts 22:10 -!- JusticeFries [~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net] has joined #go-nuts 22:10 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has joined #go-nuts 22:11 -!- Fish [~Fish@9fans.fr] has quit [Read error: Operation timed out] 22:11 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 22:11 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:570:6975:3301:5550] has quit [Quit: Leaving.] 22:14 -!- m4dh4tt3r [~Adium@c-69-181-223-245.hsd1.ca.comcast.net] has quit [Quit: Leaving.] 22:15 -!- prudhvi [~prudhvi@look.ma.i.am.on.ipv6.at.prudhvi.de] has quit [Ping timeout: 260 seconds] 22:16 -!- dario [~dario@domina.zerties.org] has quit [Ping timeout: 255 seconds] 22:17 -!- prudhvi [~prudhvi@look.ma.i.am.on.ipv6.at.prudhvi.de] has joined #go-nuts 22:18 -!- dario [~dario@domina.zerties.org] has joined #go-nuts 22:18 -!- tux21b [~christoph@pyhost.srv.tux21b.org] has quit [Ping timeout: 276 seconds] 22:20 -!- jedws [~jwesleysm@c114-77-210-9.rivrw3.nsw.optusnet.com.au] has joined #go-nuts 22:25 -!- rlab_ [~Miranda@91.200.158.34] has quit [Ping timeout: 240 seconds] 22:26 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 22:26 -!- JusticeFries_ [~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net] has joined #go-nuts 22:26 -!- rtharper [~tomh@unaffiliated/sioraiocht] has joined #go-nuts 22:27 -!- Wiz126 [~Wiz@24.229.245.72.res-cmts.sm.ptd.net] has joined #go-nuts 22:28 -!- jbooth1 [~jay@209.249.216.2] has left #go-nuts [] 22:29 -!- Fish [~Fish@9fans.fr] has joined #go-nuts 22:30 -!- JusticeFries [~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] 22:31 -!- aho [~nya@fuld-590c74ed.pool.mediaWays.net] has quit [Quit: EXEC_over.METHOD_SUBLIMATION] 22:31 -!- napsy [~luka@88.200.96.18] has joined #go-nuts 22:31 -!- prudhvi [~prudhvi@look.ma.i.am.on.ipv6.at.prudhvi.de] has quit [Read error: Operation timed out] 22:35 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts 22:39 -!- dfc [~dfc@sydfibre2.atlassian.com] has joined #go-nuts 22:39 -!- napsy [~luka@88.200.96.18] has quit [Ping timeout: 252 seconds] 22:40 -!- prudhvi [~prudhvi@look.ma.i.am.on.ipv6.at.prudhvi.de] has joined #go-nuts 22:45 -!- rlab [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 22:50 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts 22:51 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.4] 22:51 -!- nutate [~rseymour@cacsag4.usc.edu] has joined #go-nuts 22:52 -!- foocraft [~dsc@89.211.254.177] has quit [Quit: Leaving] 22:55 -!- Fish [~Fish@9fans.fr] has quit [Quit: So Long, and Thanks for All the Fish] 22:57 -!- PortatoreSanoDiI [~Marvin@dynamic-adsl-94-36-165-106.clienti.tiscali.it] has quit [Quit: E se abbasso questa leva che succ...] 22:59 -!- skelterjohn [~jasmuth@c-68-46-33-145.hsd1.nj.comcast.net] has joined #go-nuts 23:02 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit: Verlassend] 23:03 -!- cenuij [~cenuij@78.112.41.178] has joined #go-nuts 23:03 -!- cenuij [~cenuij@78.112.41.178] has quit [Changing host] 23:03 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts 23:04 < dfc> dfr|work: are you there mate ? 23:04 < dfr|work> dfc, yup 23:04 < dfc> https://gist.github.com/865147 23:04 < dfc> i had a hack on this last night 23:04 < dfc> to use 23:05 < dfc> conn := xmpp.Dial() 23:05 < dfc> then you have to read the xml from the server about the stream:features 23:05 < dfc> then use 23:05 < dfc> conn.Starttls() 23:05 < dfc> but, there is a bug in starttls, you need to wait for the server to say <proceed /> 23:06 < dfc> thinking about it a bit more on the ride in 23:06 < dfc> there probably needs to be two structs 23:06 < dfc> xmpp.Client, and xmpp.Conn 23:06 < dfr|work> dfc, well, the Starttls can probably wait for the proceed for reading 23:06 < dfc> yeah, i will need to consume all the xml text 23:07 < dfc> before it starts the handshake 23:07 < dfc> otherwise when the tls.Conn trie sto handshake 23:07 < dfc> there will be some garbage in the buffer 23:07 < dfr|work> dfc, right. That shouldn't be all too hard, I think 23:07 < dfr|work> dfc, I'm actually working on the consuming of the first features from the non-tls thing. 23:07 < dfr|work> seems like if you just read with a large enough buffer, it returns... 23:08 < dfc> yeah, _most_ of the time it'll just work 23:08 < dfc> because the <proceed> message fits inside a packet 23:08 -!- foocraft [~dsc@89.211.254.177] has joined #go-nuts 23:08 < dfc> and the server has probably sent it with PSH 23:08 < dfc> so you can just read into a 1500 byte buffer and throw it away 23:08 < dfr|work> dfc, yup 23:08 < dfc> because if the tls negotiation fails 23:09 < dfc> you throw the connection on the floor 23:10 < dfr|work> dfc, well, so far I did get to proceed thing now.. let's see if establishing the tls connection will do the trick :D 23:13 -!- nutate [~rseymour@cacsag4.usc.edu] has quit [Quit: nutate] 23:20 < dfr|work> dfc, woot! 23:20 < dfc> don't woot too soon 23:20 < dfc> xmpp has a lot more supprises for you 23:20 < dfr|work> dfc, i got it to the "success" :) 23:20 < dfc> nice 23:20 < dfc> fortuntaly tls.Conn implements net.Conn 23:21 < dfr|work> dfc, well, I'm planning to pretty much abstract it all away. 23:21 < dfc> so you can do something like c.conn = tls.Client(c.conn, nil) 23:21 < dfr|work> dfc, and do the net.Conn stuff only as initial setup 23:21 < dfc> i think its a reasonable restriction to say that your library only supports tls connections 23:21 < dfc> or will mandate tls setup 23:21 < dfr|work> dfc, yea. I'm making it very directed for gtalk for now. 23:22 < dfr|work> dfc, because my goal is to actually make a bot. But it would be an excellent starting ground for anyone who'd like to play with xmpp in go 23:22 < dfr|work> BTW, pushed the more working version onto github 23:22 < dfr|work> but it's still the "get it dirty working state" though, hehe 23:30 < dfr|work> dfc, I made it message me!! :D 23:30 < dfr|work> dfc, okay, I think I'm in business now :D 23:33 -!- nutate [~rseymour@204.140.130.68] has joined #go-nuts 23:33 -!- nutate [~rseymour@204.140.130.68] has quit [Read error: Connection reset by peer] 23:35 -!- nutate [~rseymour@204.140.130.68] has joined #go-nuts 23:36 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has quit [Remote host closed the connection] 23:39 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Ping timeout: 260 seconds] 23:40 < dfc> dfr|work: wd 23:46 < dfr|work> dfc, do you have a gtalk account? ;) 23:48 < dfc> dave@cheney.net 23:53 -!- napsy [~luka@88.200.96.18] has joined #go-nuts 23:55 < dfr|work> dfc, alrighty.. seems like I'll have to continue tomorrow 23:55 < dfr|work> dfc, but I basically got it to spit back at you what you write to it 23:55 < dfr|work> dfc, now I need to clean the codebase a bit up and allow people to subscribe to messages 23:55 < dfr|work> and voila :D 23:56 -!- araujo [~araujo@gentoo/developer/araujo] has joined #go-nuts 23:57 -!- DerHorst [~Horst@e176101172.adsl.alicedsl.de] has joined #go-nuts --- Log closed Fri Mar 11 00:00:55 2011