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