--- Log opened Tue Mar 08 00:00:48 2011
--- Day changed Tue Mar 08 2011
00:00 -!- shvntr [~shvntr@] has joined #go-nuts
00:03 -!- shvntr_ [~shvntr@] has joined #go-nuts
00:06 -!- bXi [bluepunk@irssi.co.uk] has quit [Ping timeout: 276 seconds]
00:06 -!- bXi [bluepunk@irssi.co.uk] has joined #go-nuts
00:12 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has quit [Quit:
Computer has gone to sleep.]
00:21 -!- stalled [~stalled@unaffiliated/stalled] has joined #go-nuts
00:22 -!- nixness [~dsc@] has quit [Ping timeout: 255 seconds]
00:23 -!- nixness [~dsc@] has joined #go-nuts
00:24 -!- Urmel| [~11087Urme@82-136-196-44.ip.telfort.nl] has quit [Ping timeout:
248 seconds]
00:25 -!- Urmel| [~11087Urme@82-136-196-44.ip.telfort.nl] has joined #go-nuts
00:36 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has joined #go-nuts
00:38 -!- nettok [~quassel@] has joined #go-nuts
00:39 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has joined #go-nuts
00:43 < dfc> are there any goprotobuf users on the list ?
00:44 < dfc> the latest release has broken goprotobuf
00:44 < dfc> i wondered if anyone was fix it
00:52 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has quit [Remote
host closed the connection]
00:57 -!- nettok_ [~quassel@] has joined #go-nuts
01:00 -!- nettok [~quassel@] has quit [Ping timeout: 246 seconds]
01:04 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Ping timeout: 264 seconds]
01:11 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
01:14 -!- nixness [~dsc@] has quit [Quit: Leaving]
01:15 -!- saturnfive [~saturnfiv@] has joined #go-nuts
01:21 -!- Maxdaman1us [~Maxdamant@203-97-238-106.cable.telstraclear.net] has quit
[Ping timeout: 276 seconds]
01:24 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Ping timeout: 264 seconds]
01:25 -!- ymasory [~ymasory@c-76-99-55-224.hsd1.pa.comcast.net] has joined
01:30 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
01:39 -!- JusticeFries_
[~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net] has joined #go-nuts
01:41 -!- JusticeFries [~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net]
has quit [Ping timeout: 248 seconds]
01:43 -!- JusticeFries_
[~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net] has quit [Ping
timeout: 264 seconds]
01:56 -!- Maxdamantus [~Maxdamant@203-97-238-106.cable.telstraclear.net] has
joined #go-nuts
02:03 -!- shvntr [~shvntr@] has quit [Quit: leaving]
02:05 -!- libv8 [~gj@cpc2-lewi9-0-0-cust84.2-4.cable.virginmedia.com] has joined
02:05 -!- shvntr [~shvntr@] has joined #go-nuts
02:08 -!- Slant [~scott@] has joined #go-nuts
02:11 -!- foocraft [~dsc@] has joined #go-nuts
02:16 -!- rom1504 [~rom1504@AMontpellier-159-1-112-67.w90-0.abo.wanadoo.fr] has
quit [Ping timeout: 264 seconds]
02:22 -!- Slant [~scott@] has quit [Ping timeout: 260 seconds]
02:27 -!- mikespook [~mikespook@] has joined #go-nuts
02:34 -!- qjcg [~qjcg@] has joined #go-nuts
02:34 -!- qjcg [~qjcg@] has left #go-nuts []
02:52 -!- cco3 [~conley@c-69-181-140-72.hsd1.ca.comcast.net] has joined #go-nuts
02:56 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has quit [Remote host
closed the connection]
02:58 -!- JusticeFries [~JusticeFr@c-24-9-183-230.hsd1.co.comcast.net] has joined
03:00 < skelterjohn> dfc: post an issue on the repo site
03:00 < skelterjohn> devs love to get issues
03:01 < skelterjohn> because it's living proof that someone uses their
03:02 < dfc> right-o
03:02 < dfc> for the record go proto bufs is great
03:02 < dfc> 'cos it just works, unlike gob
03:02 < dfc> which doesn't
03:02 -!- tsykoduk [~tsykoduk@2001:470:1f04:671:20d:93ff:fe77:1dc4] has quit [Ping
timeout: 248 seconds]
03:02 < skelterjohn> heh
03:03 < skelterjohn> wouldn't it be funny if i were the gob developer?
03:03 < dfc> well, that would be embarising
03:04 < dfc> but if you were you could answer this vexing question
03:04 < skelterjohn> i can try
03:04 < skelterjohn> but probably not
03:04 < skelterjohn> i've never used gob
03:04 < dfc> do gob's need framing ? or can I just stuff them on the wire
and Unmarshal() will read only the bytes it needs ?
03:04 < dfc> oh phew, that measn you probably didn't develop it then
03:05 < skelterjohn> i imagine they do not need framing
03:05 < skelterjohn> at least, if i made it, i would make it so they could
be read right off the wire
03:05 < skelterjohn> that is, they'd frame themselves already
03:05 < skelterjohn> this seems easy to test :)
03:05 < dfc> yeah, last time protobufs broke I had a go at converting to gob
03:06 < dfc> but it wasn't as straight forward as it seams
03:06 < dfc> seems
03:26 -!- Venom_X [~pjacobs@] has quit [Quit: Venom_X]
03:28 -!- Eko [~eko@c-24-130-224-186.hsd1.ca.comcast.net] has joined #go-nuts
03:37 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has joined #go-nuts
03:51 -!- nettok_ [~quassel@] has quit [Ping timeout: 248 seconds]
03:53 -!- toyoshim_ [~toyoshim@y253149.dynamic.ppp.asahi-net.or.jp] has left
#go-nuts []
04:04 -!- dRbiG [drbig@unhallowed.pl] has quit [Read error: Operation timed out]
04:04 -!- rtharper [~tomh@unaffiliated/sioraiocht] has quit [Ping timeout: 252
04:06 -!- d_m_ [d6@SDF.ORG] has quit [Ping timeout: 252 seconds]
04:06 -!- jessta [~jessta@li7-205.members.linode.com] has quit [Ping timeout: 252
04:06 -!- drhodes [~none@drhodes.xen.prgmr.com] has quit [Ping timeout: 252
04:07 -!- barkmore [~textual@50-46-115-110.evrt.wa.frontiernet.net] has joined
04:07 -!- d_m [d6@SDF.ORG] has joined #go-nuts
04:08 -!- drhodes [~none@drhodes.xen.prgmr.com] has joined #go-nuts
04:09 -!- ymasory [~ymasory@c-76-99-55-224.hsd1.pa.comcast.net] has quit [Quit:
04:09 -!- barkmore [~textual@50-46-115-110.evrt.wa.frontiernet.net] has quit
[Remote host closed the connection]
04:10 -!- rtharper [~tomh@unaffiliated/sioraiocht] has joined #go-nuts
04:12 -!- dRbiG [drbig@unhallowed.pl] has joined #go-nuts
04:12 -!- foocraft [~dsc@] has quit [Quit: Leaving]
04:15 -!- rejb [~rejb@unaffiliated/rejb] has quit [Ping timeout: 246 seconds]
04:25 -!- niemeyer [~niemeyer@201-40-140-176.pltce701.dsl.brasiltelecom.net.br]
has quit [Ping timeout: 246 seconds]
04:28 -!- shvntr [~shvntr@] has quit [Quit: leaving]
04:31 -!- Viriix [~joseph@c-67-169-172-251.hsd1.ca.comcast.net] has joined
04:35 < dfc> adg: are you there ?
04:37 <@adg> yes
04:37 < dfc> r is the main committer on goprotobufs right ?
04:37 <@adg> mostly, yes.  also dsymonds is involved
04:38 < dfc> i have a tiny 1 line patch that fixes the breakage from
04:38 < dfc> i'll stick it in an issue
04:39 <@adg> yeah probably easiest
04:39 <@adg> what breakage was there?  i should have caught that
04:39 < dfc> extensions.go:148: cannot use v.Addr() (type *reflect.PtrValue)
as type uintptr in function argument
04:39 < dfc> because of the change to UnsafeAddr()
04:40 <@adg> oh yeah, i did change that internally, but forgot to make the
change publicly
04:40 < dfc> oh, so there is already a version that has this fix ?
04:40 < dfc> this happened before when log changed
04:41 < dfc> do you want a patch for the public version ?
04:41 <@adg> you can actually send a CL to rob using the codereview
04:41 <@adg> or just mail him the patch
04:41 < dfc> I can do that on other projects
04:41 < dfc> ?
04:41 < dfc> zounds!
04:41 <@adg> yep, codereview is not just for go!
04:41 <@adg> :)
04:41 <@adg> just need to enable the plugin for that project
04:41 < dfc> frak yeah!
04:42 < dfc> thanks for the suggetion
04:42 < dfc> then I can use clpatch to work around it
04:42 < dfc> on my local copies
04:42 <@adg> yahuh
04:43 -!- JusticeFries [~JusticeFr@c-24-9-183-230.hsd1.co.comcast.net] has quit
[Quit: JusticeFries]
04:45 < dfc> done, thanks for your help, it was a lot easier than I imagined
04:45 <@adg> nice, glad it worked out :)
04:47 <@adg> dfc: lol "gorptobuf"
04:47 <@adg> i'm going to call it that from now on
04:47 < dfc> arse
04:47 < dfc> i fixed i
04:47 < dfc> it
04:48 < dfc> but codereview will continue to shame me with a few more emails
before the next review cycle starts
04:51 < exch>
finally starting to get the hang of this
04:51 < exch> that's a standalone, small Go webserver which serves a
single-user application
04:51 < exch> in this case a front-end for MPD
04:55 <@adg> dfc: you can change it in codereview.appspot.com too
04:56 <@adg> neato
04:56 <@adg> exch: and i'm in the screenshot!
04:56 < exch> ya, now you're famous :p
04:58 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Remote host
closed the connection]
04:59 < steven> guys :)
04:59 < steven> i used some learnings i got this morning to make my
goroutine less stupid!
05:00 < steven> it changed from this: https://gist.github.com/858028
05:00 < steven> to this: https://gist.github.com/859866
05:00 < steven> specifically the Run method
05:01 -!- Adys [~Adys@unaffiliated/adys] has quit [Ping timeout: 246 seconds]
05:03 < exch> wouldn't it be better to move that goroutine out of the for
loop and give it it's own for loop?  The way I see it, you are re-allocating a new
bufio.reader on every loop iteration now.  That is not necessary
05:03 < exch> also, if the data from the server keeps pouring in, you're
going to spawn a billion go routines this way
05:06 < steven> exch: it started as its own for loop in a goroutine.  that
was the dumb way.
05:06 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has joined #go-nuts
05:06 < steven> the problem you mentioned is a real problem though, but its
solution is much simpler: move the reader var out of the goroutine and even out of
the for loop in the Run method ;)
05:06 < exch> yes..  you're still left with a ton of goroutines though
05:07 < steven> (1) they exit immediately because the channel they are
sending to is buffered
05:07 < steven> (2) they are cheap
05:07 < steven> thats actually all i got
05:08 < steven> but yeah, it seeems much better this way.
05:08 < exch> it only has 1 buffer slot, so it'll be full quickly enough,
which causes it to block.  An average IRC server spits out a ton of system
messages and cha data.  specially if you are in multiple (busy) channels
05:08 < exch> *chat
05:08 < steven> i dont think you understand
05:10 < exch> you're also allocating a new Input struct instance every time.
Not trying to ruin your work here or anything, just pointing out what I noticed :)
05:10 < steven> this is how that infinite loop works: (1) the goroutine is
executed and reads data from IRC, then sends it to the buffered channel, filling
its only slot.  (2) because its buffered, it doesnt block, and the goroutine exits
immediatly.  (3) concurrently, the select statement waits for either a quit
signal, or that IRC-message channel to receive 1 line
05:10 < steven> so its always a "send one, receive one" loop, always in that
05:11 < steven> so the buffer is always empty every time that goroutine is
05:11 < exch> is that guaranteed, even when GOMAXPROCS > 1 ?
05:11 < steven> oh, no, good point.
05:11 < steven> wait, yes.  i think it is.
05:12 < steven> because the select statement always waits to receive from
that channel, and theres always only 1 goroutine sending to that channel at any
given time.
05:12 < steven> so yes.  its fine regardless.
05:13 < steven> (it doesnt make sense to call Read from a network connection
more than 1 simultaneous time)
05:13 < steven> (ie, if 2 people call it simultaneously, ive no idea what
kind of bugs that causes)
05:13 < steven> so yes.  i think this is a much smarter solution at
https://gist.github.com/859866 :)
05:14 < steven> exch: also, i dont think the whole "new Input every time" is
a bad thing.
05:14 < steven> i imagine its pretty cheap.
05:14 < steven> not to mention, how else would i send both values across the
channel?  :P
05:15 < steven> the only reason this isnt linear btw is so that any other
goroutine can send bot.Quit() even while this one is blocking, waiting for another
line to come in from IRC.
05:15 < steven> er not "isnt linear"..  i mean, the only reason it uses a
05:15 < steven> the only reason its concurrent ;)
05:16 -!- Adys [~Adys@unaffiliated/adys] has joined #go-nuts
05:20 < exch> the signal handling doesnt seem to work reliably when the
remote end closes the connection.  the program seems to hang on a blocking read
somewhere when that happens
05:21 < steven> i believe i know where..
05:27 -!- keithcascio [~keithcasc@nat/google/x-jrvxskbfqntknqwb] has quit [Quit:
05:29 -!- shvntr_ [~shvntr@] has quit [Quit: leaving]
05:29 < steven> ha!
05:29 < steven> bot.Quit is a blocking call.
05:29 < steven> sent within the select that tries to receive it.
05:30 < steven> now the question is whether i should have invoked bot.Quit()
as go bot.Quit(), or whether bot.Quit() should run its own goroutine.
05:30 < steven> mmm, design questions...  *drool*
05:35 < steven> ok, time to work on gorm
05:39 -!- tobier [~tobier@c-1e9de055.712-1-64736c11.cust.bredbandsbolaget.se] has
quit [Ping timeout: 260 seconds]
05:40 -!- tobier [~tobier@c-1e9de055.712-1-64736c11.cust.bredbandsbolaget.se] has
joined #go-nuts
05:41 -!- libv8 [~gj@cpc2-lewi9-0-0-cust84.2-4.cable.virginmedia.com] has quit
[Quit: libv8]
05:41 < djbrown> is there some way to look for a method in a type
05:43 < exch> djbrown: you mean at runtime?  If that's the case, you could
try the reflect package
05:44 < djbrown> at runtime yeah
05:44 < djbrown> looking at reflect but not coming up with anything good
05:44 < steven> djbrown: its there.
05:45 < djbrown> all i've seen is that you can loop through all the methods
and look for a match to the name
05:46 < exch> ya
05:49 -!- foocraft [~dsc@dyn-86-36-42-96.wv.qatar.cmu.edu] has joined #go-nuts
05:49 < djbrown> was looking for something like GetMethod(method) but mabye
that's not there
06:01 < djbrown> wanted to use it to deal with incoming irc commands
06:03 < steven> djbrown: i thought the same thing.
06:03 < steven> months ago
06:03 < steven> so i did this
06:04 < steven> https://gist.github.com/601692
06:05 < dfc> can you nest switch statements ?
06:05 < dfc> this might appear an easy question
06:06 < djbrown> steven: pretty similar to what i have right now
06:06 < djbrown> steven: just alot cleaner ;)
06:07 < steven> hehe thanks
06:07 < steven> dfc: why not?
06:07 < steven> wy wouldnt you be able to?
06:08 < dfc> i hit a problem nesting default: statements
06:08 < dfc> but I think it might be a typo
06:09 < steven> yep
06:09 < steven> hey adg you here?
06:09 < steven> i thought you could do something like..  if 1 < b < 3
{ ...  } in go..  but i guess i was mistaken
06:10 < dfc> yup, turns out i'm a muppet
06:10 < dfc> nothing to see here, move alone
06:10 < dfc> along
06:10 < steven> uh
06:10 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has quit [Remote host closed
the connection]
06:10 < steven> ok?
06:10 < steven> :)
06:11 < steven> dont worry dfc, god loves you even when you make silly
mistakes :)
06:11 * dfc breaths a sigh of relief
06:11 -!- skejoe [~skejoe@] has joined #go-nuts
06:24 < steven> <3
06:32 -!- Slant [~scott@] has joined #go-nuts
06:35 -!- dfc [~dfc@sydfibre2.atlassian.com] has quit [Ping timeout: 248 seconds]
06:40 -!- MizardX [MizardX@unaffiliated/mizardx] has quit [Quit: zzz?  zzz?  ZZZ?]
06:43 -!- skejoe [~skejoe@] has quit [Quit: Lost terminal]
06:55 -!- aho [~nya@fuld-590c61f9.pool.mediaWays.net] has joined #go-nuts
07:02 -!- adu [~ajr@softbank220043138128.bbtec.net] has joined #go-nuts
07:02 -!- Slant [~scott@] has quit [Ping timeout: 264 seconds]
07:03 -!- Viriix [~joseph@c-67-169-172-251.hsd1.ca.comcast.net] has quit [Quit:
This computer has gone to sleep]
07:08 -!- ronny [~quassel@p4FF1C55F.dip0.t-ipconnect.de] has joined #go-nuts
07:09 -!- saturnfive [~saturnfiv@] has quit [Read error: Connection
reset by peer]
07:10 -!- saturnfive [~saturnfiv@] has joined #go-nuts
07:14 -!- Slant [~scott@] has joined #go-nuts
07:23 -!- vsayer [~vivek@2001:470:1f04:1a6b:21a:6bff:fe35:d2a5] has quit [Ping
timeout: 260 seconds]
07:23 -!- Guest35220 [~quassel@p4FF1C55F.dip0.t-ipconnect.de] has quit [Remote
host closed the connection]
07:24 -!- adu [~ajr@softbank220043138128.bbtec.net] has quit [Ping timeout: 246
07:29 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
07:31 -!- adu [~ajr@softbank220043138128.bbtec.net] has joined #go-nuts
07:31 -!- visof [~visof@] has joined #go-nuts
07:31 -!- visof [~visof@] has quit [Changing host]
07:31 -!- visof [~visof@unaffiliated/visof] has joined #go-nuts
07:31 -!- wrtp [~rog@] has joined #go-nuts
07:37 -!- napsy [~luka@] has joined #go-nuts
07:37 -!- piranha [~piranha@5ED4B890.cm-7-5c.dynamic.ziggo.nl] has joined #go-nuts
07:41 -!- Slant [~scott@] has quit [Ping timeout: 252 seconds]
07:52 -!- Urmel|Work [~UrmelWork@cache1.uk.logica.com] has joined #go-nuts
07:54 -!- piranha [~piranha@5ED4B890.cm-7-5c.dynamic.ziggo.nl] has quit [Quit:
Computer has gone to sleep.]
07:55 -!- rlab [~Miranda@] has joined #go-nuts
08:07 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|]
08:14 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has joined #go-nuts
08:14 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
08:14 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has quit [Read
error: Connection reset by peer]
08:16 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts
08:18 -!- nsf [~nsf@jiss.convex.ru] has quit [Client Quit]
08:19 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has joined #go-nuts
08:28 -!- mariolone [~mariolone@] has joined #go-nuts
08:28 -!- mariolone [~mariolone@] has left #go-nuts []
08:34 -!- tensorpudding [~user@] has quit [Read error: Connection
reset by peer]
09:02 -!- coldturnip [~COLDTURNI@111-250-2-225.dynamic.hinet.net] has quit [Read
error: Connection reset by peer]
09:03 -!- coldturnip [~COLDTURNI@111-250-2-225.dynamic.hinet.net] has joined
09:08 -!- boscop [~boscop@f055255209.adsl.alicedsl.de] has joined #go-nuts
09:30 -!- mikespook [~mikespook@] has quit [Quit: Leaving.]
09:33 < ww> hmmm: throw: malloc/free - deadlock
09:34 < ww> under stress with GOMAXPROCS>1
09:34 < aiju> report a bug
09:37 < wrtp> ww: can you reproduce it in a small program?
09:40 -!- Slant [~scott@] has joined #go-nuts
09:44 < ww> http://code.google.com/p/go/issues/detail?id=1591
09:44 < ww> wrtp: not yet
09:45 < ww> noted in the bug as a todo, but better to signal the potential
problem first i thought
09:49 < wrtp> not much help without some code to reproduce it :-)
09:51 < ww> wrtp: obviously.
09:52 < ww> need to separate out the relevant bits from my highly volatile
working directory soup :P
10:04 -!- DerHorst [~Horst@e176098186.adsl.alicedsl.de] has joined #go-nuts
10:05 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-165-113.clienti.tiscali.it] has
joined #go-nuts
10:17 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has quit [Ping
timeout: 276 seconds]
10:21 -!- Slant [~scott@] has quit [Quit: Slant]
10:23 -!- rtharper [~tomh@unaffiliated/sioraiocht] has quit [Remote host closed
the connection]
10:25 -!- saturnfive [~saturnfiv@] has quit [Read error: Connection
reset by peer]
10:31 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has joined #go-nuts
10:31 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Read error: Operation
timed out]
10:32 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
10:36 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
10:43 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has quit [Ping
timeout: 250 seconds]
10:44 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts
10:50 -!- erus_ [50b135f2@gateway/web/freenode/ip.] has joined
10:51 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.4]
10:56 -!- sacho [~sacho@87-126-37-121.btc-net.bg] has quit [Ping timeout: 276
11:08 -!- rlab [~Miranda@] has quit [Ping timeout: 276 seconds]
11:09 -!- saturnfive [~saturnfiv@] has joined #go-nuts
11:09 -!- saturnfive [~saturnfiv@] has left #go-nuts []
11:14 -!- rlab [~Miranda@] has joined #go-nuts
11:15 -!- tensai_cirno [~cirno@] has quit [Read error: Connection
reset by peer]
11:32 -!- adu [~ajr@softbank220043138128.bbtec.net] has quit [Quit: adu]
11:39 -!- PortatoreSanoDiI [~Marvin@] has joined #go-nuts
11:42 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-165-113.clienti.tiscali.it] has
quit [Ping timeout: 246 seconds]
11:43 -!- Fish [~Fish@exo3753.pck.nerim.net] has quit [Read error: Operation timed
11:54 -!- Slant [~scott@] has joined #go-nuts
12:09 -!- sahid [~sahid@LNeuilly-152-21-22-10.w193-253.abo.wanadoo.fr] has joined
12:09 < aiju> http://fuckyeahnouns.com/go
12:09 < aiju> should be on golang.org
12:13 < wrtp> i'm getting errors from codereview.  can anyone else view this
page, for instance: http://codereview.appspot.com/user/rog
12:14 < wrtp> darn it works for me again now
12:15 -!- sauerbraten [~sauerbrat@p508CADCA.dip.t-dialin.net] has joined #go-nuts
12:16 < wrtp> sporadically
12:17 < ww> was godoc's sync_minutes argument changed to nanoseconds or
12:17 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has joined #go-nuts
12:20 < djbrown> http://pastebin.com/zEPgb6G0 how bad of a method to deal
with incoming irc commands is that
12:20 < djbrown> there would be an else sending it to irc_unknown if it cant
find a match
12:20 < Namegduf> Why do you need reflect to do line parsing?
12:21 < Namegduf> Oh, ew, I just worked out what it does.
12:21 < Namegduf> Just use a *map*.
12:22 < djbrown> wouldnt you have to keep every possible command in that map
12:22 < Namegduf> You would have to put them in the map, yes.
12:23 -!- jessta [~jessta@li7-205.members.linode.com] has joined #go-nuts
12:23 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts
12:23 < Namegduf> That way your commands do not need to be methods on a
type, which makes it impossible to add them from outside a package and involves
lots and lots of methods.
12:24 < Namegduf> It's simpler, cleaner, and MUCH faster.
12:24 < djbrown> hmm
12:25 * Namegduf has a command map containing command structures, which contain
expected parameter counts.  After looking up the command, the line is finished
being parsed and the command is passed a slice containing the right number of
parameters.  It is never invoked with a wrong number of parameters.
12:25 < ww> arity
12:26 < Namegduf> But the key part of the command lookup is a simple
map->func lookup.
12:26 < Namegduf> Er, string->func lookup.
12:26 < djbrown> felt unnessecary to have to update two places when adding
something new but mabye not
12:27 -!- rlab [~Miranda@] has quit [Ping timeout: 252 seconds]
12:28 < ww> might be nice to have an apply builtin, apply(f, []args)
12:28 < Namegduf> What would it do?
12:28 < wrtp> could someone else try this URL, please:
12:28 < djbrown> server error
12:29 < wrtp> djbrown: thanks.  it's not just me then :-)
12:29 < ww> you would make func f(arg1, arg2, arg3)
12:29 -!- DerHorst [~Horst@e176098186.adsl.alicedsl.de] has quit [Remote host
closed the connection]
12:29 < Namegduf> If f is a varargs function, that's just f(args...)
12:29 < ww> right, but avoiding varargs bookkeeeping
12:29 < Namegduf> You can't.
12:30 < wrtp> i don't see why you'd want to use reflect at all for this
12:30 < wrtp> func(args []string) would be perfectly sufficient
12:30 < Namegduf> It's because he's trying to mimic how you would do it in
JS or some similar languages
12:30 < ww> you could implement apply with reflect (but it would be
12:30 < wrtp> or even func(args string) if you didn't want the args
12:30 < Namegduf> Where checking if a method exists for a name is cheap
12:31 < djbrown> Namegduf: python in go ;p
12:31 < Namegduf> Yes, stop trying to do that.
12:31 -!- Netsplit *.net <-> *.split quits: tokuhiro__, jumzi, Wiz126,
Zoopee, comex, jbooth1, jnwhiteh, krakensden
12:31 < Namegduf> :P
12:31 < Namegduf> ww: You can't implement it at all.
12:31 < wrtp> ww: without generics, there's no better way of doing it than
just writing it out, as Namegduf says
12:31 < Namegduf> Slices have a variable size.
12:31 < ww> or any number of other languages that have an apply...
12:32 < wrtp> Namegduf: it's easy to implement with reflection
12:32 < Namegduf> Non-varargs functions have only one size they accept.
12:32 < wrtp> that's what reflection is for
12:32 < Namegduf> For all others there are no reasonable semantics.
12:32 -!- jessta [~jessta@li7-205.members.linode.com] has quit [Read error:
Operation timed out]
12:32 < ww> wrtp you could handle this as a builtin as a special case
without opening up the generics can of worms
12:32 < aiju> the last good thing with reflection is hanging in my bath room
12:32 < wrtp> ww: why would you want to?  it's not a common case.
12:32 < Namegduf> It's not type safe, it's not useful.
12:32 < ww> isn't it?
12:32 < Namegduf> No, it isn't.
12:33 < Namegduf> f has a specific number of arguments.
12:33 < Namegduf> f(arg1, arg2, arg3), simple.
12:33 < ww> right, and it is possible to check the number and type of
12:33 < Namegduf> At compile time.
12:33 < Slant> In a program directory with a normal program makefile (ala
12:33 < wrtp> it's not statically type safe
12:33 < Namegduf> Yes, it is.
12:33 < Slant> how do I layout the files / directories so that my other
source files will be in different namespaces?
12:33 < wrtp> apply(f, args) isn't
12:33 < Namegduf> What you're talking about would involve reflection at
runtime, potential type errors, and has no advantages.
12:34 < Slant> i tried naming a file otherpack.go with "package otherpack"
and including it in the Makefile.
12:34 < Slant> But that was a no go.
12:34 < ww> can be checked at runtime with a builtin or reflection hack...
12:34 < Slant> Then did the subdirectory fun too.
12:34 < Namegduf> The builtin would need to work through reflections.
12:34 < Namegduf> *reflection
12:34 < wrtp> ww: why would it then be more efficient than using reflect?
12:34 < Namegduf> You can't just say "It's a builtin!" and avoid every
problem magically.
12:34 < ww> wrtp: it might save a few function calls
12:35 < Namegduf> Why would it be better than f(args[0], args[1], args[2])?
12:35 < Namegduf> That's *fast* and checked at compile time.
12:35 < wrtp> Namegduf: if you don't know the type of f, presumably
12:35 < Namegduf> wrtp: If you don't know it's type, then you can't call it
at all.
12:35 < aiju> are you writing python in go or something?
12:35 < aiju> f(..args) or whatever it was
12:35 < wrtp> Namegduf: you can, using reflection
12:35 -!- jnwhiteh [~jnwhiteh@WoWUIDev/WoWI/Featured/Dongle/cladhaire] has joined
12:35 < Namegduf> wrtp: Only if it's already a reflection type.
12:36 < wrtp> Namegduf: what?
12:36 < wrtp> Namegduf: you can reflect on any type
12:36 < Namegduf> wrtp: Only if it's already a reflect.Value
12:36 < wrtp> Namegduf: any type can be turned into a reflect.Value
12:36 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has joined #go-nuts
12:36 -!- jbooth1 [~jay@] has joined #go-nuts
12:36 -!- tokuhiro__ [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has joined
12:36 -!- Wiz126 [~Wiz@] has joined #go-nuts
12:36 -!- comex [comex@c-67-188-10-190.hsd1.ca.comcast.net] has joined #go-nuts
12:36 -!- Zoopee [alsbergt@zoopee.org] has joined #go-nuts
12:36 -!- krakensden [~krakensde@li221-186.members.linode.com] has joined #go-nuts
12:37 < Namegduf> Yes, but you don't have the type, or know what it is.
12:37 < Namegduf> Your code is being given a something.
12:37 < wrtp> Namegduf: you can get the type from the reflect.Value
12:37 < Namegduf> For some insane reason, it isn't a nice simple function
12:37 < Namegduf> Which means you've fucked up horribly, but anyway.
12:38 < wrtp> Namegduf: it's perfectly reasonable in some cases that you
only know the type at run time
12:38 < Namegduf> You then want to get the type out of it.
12:38 < Namegduf> wrtp: That's what type assertions are for, followed by a
regular function call
12:38 < Namegduf> Actually, that's a far better point.
12:38 < wrtp> Namegduf: that's not necessarily good enough
12:39 < wrtp> Namegduf: look at the rpc package for an example
12:39 < Namegduf> Well, you clearly have some specific type you're hoping it
is if you're trying to call t.
12:39 < wrtp> Namegduf: that's not true of the rpc package
12:39 < Namegduf> It wants to call functions, but it doesn't care about part
of their type?
12:39 < wrtp> it cares about their type, but it doesn't know at compile time
what that type is
12:40 < Namegduf> Hmm.
12:40 < wrtp> try godoc rpc
12:40 < Namegduf> I suppose that makes sense in that case.
12:40 < Namegduf> Specifically for RPC.
12:40 < wrtp> and read the documentation
12:40 < wrtp> Namegduf: there are lots of other cases too
12:40 < Namegduf> But why would you be doing this so often as to want a
built-in for runtime type screwing on functions?
12:41 < wrtp> you wouldn't
12:41 < wrtp> Apply isn't that useful
12:41 < wrtp> but the general principle of being able to call functions
whose type is known only at run time is.
12:42 < wrtp> anyway, Apply is easy to write
12:42 -!- shvntr [~shvntr@] has joined #go-nuts
12:45 < ww> wrtp: apply or some equivalent is present to a greater or lesser
extent in many languages...  that would suggest some utility at least...
12:45 < Namegduf> It isn't type safe.
12:45 < Namegduf> You're throwing away one of the advantages of Go.
12:46 < ww> Namegduf: that's a different point - i said it was useful not
that it was type safe.
12:46 < Namegduf> ww: Not being type safe makes it a Bad Idea unless there's
no alternative.
12:46 < ww> and it can be type safe at runtime and maybe in some restricted
sense at compile time (e.g.  append is type safe, so...)
12:47 < Namegduf> No, it can't be.
12:47 < Namegduf> Not without other changes, at least.
12:47 -!- Jgonzalez [~Jgonzalez@ool-457e1652.dyn.optonline.net] has joined
12:47 < Namegduf> There's no half-specified function type.
12:47 < Namegduf> You either know what type a function is, or it's wrapped
in an interface{}
12:47 < Namegduf> If you know what type it is, you can call it normally.
12:48 < Namegduf> If you don't, then there's no way to check at compile time
anything about it.
12:48 < Namegduf> ww: Anyways, do you have an argument for it being useful
beyond "other languages have it"?
12:49 < Namegduf> What practical, actual problems do you *need* it to solve
which crop up often enough to justify a built-in instead of some code using
12:49 < ww> right, so so the restricted version would be that you can follow
the call path and tell what type it is at compile time.  if there are conflicting
paths, e.g.  it could have more than one possible type, compile error
12:50 < Namegduf> That's...  not something the compiler can be assumed to do
for anything else.
12:50 < Namegduf> On thought, if it's knowable at compile time, you can just
use a type assertion to get the function type out.
12:51 < ww> Namegduf: i don't need it for anything i'm doing at the
moment...  just saw it being discussed in irc or something...
12:51 < Namegduf> Okay, then it doesn't offer anything to justify the
additional complexity of another built-in.
12:51 < ww> i have had call to use it in the past, but those projects i
haven't contemplated porting to go so i'm not sure there isn't a better way in
those contexts
12:52 < Namegduf> The appropriate ways to solve things in some languages
involve reflection in some cases, and not in others.
12:53 < Namegduf> In JS, structs are maps and visa versa, and checking if a
struct has a method with a given name is an appropriate and sensible way to do
command lookups.
12:53 * ww actually hasn't done very much in js
12:53 < Namegduf> In Go, it's breaking type safety and doing slow stuff for
no good reason.
12:53 < ww> (and doens't want to)
12:55 -!- suiside [tajnyman@unaffiliated/suiside] has quit [Quit: leaving]
12:55 < ww> if i ever get around to nlp and syntax trees and entailments on
top of those in go, i'll revisit...  that was the last time i ended up heavily
using things like apply...  (or actually *av)
12:55 < Namegduf> Doesn't sound common enough to justify a built-in.  :P
12:56 * ww isn't up for trying to make a strong argument for something not needed
by me right now
12:56 < Namegduf> (reflect.NewValue(f)).Call(args) == apply, exploding if it
doesn't work, I think.
12:58 < ww> if that works, that might be a useful snippet to put somewhere,
perhaps in the reflect docs
12:59 < Namegduf> I really hope reflect usage is not common enough to
justify that.
12:59 < ww> uriel: https://bitbucket.org/ww/goraptor ...  requires raptor2
13:00 < ww> Namegduf: with a caveat: this is how you do apply.  only do this
if you're sure there's not a better way
13:01 < Namegduf> ww: It's just two function calls, and one is a
13:01 < Namegduf> If you can't read the documentation for Call and then go
"Okay, so this operates on a reflect value, how do I get one...", then...
13:01 < ww> right, but it answers the question - which could become a faq -
"how do i do apply in go"
13:02 < Namegduf> Sounds like something that should go in an FAQ, not godoc.
13:02 < ww> sure
13:03 < Namegduf> I don't think the documentation in general should try to
answer questions like "How do I do X in Go?", it's job is to document the tools
that exist for you to use to do X.
13:03 < Namegduf> Not to explain how they can be assembled.
13:03 < Namegduf> It'd get complicated just covering all the potential Xs
which are far more commonly useful.
13:03 < Namegduf> Especially given that apply() is something which should
not be a commonly useful thing.
13:04 < Namegduf> Call basically *is* apply(), anyway, it just doesn't take
an interface{} directly.
13:04 < ww> i agree it should go in a faq not the main docs
13:04 -!- rtharper [~tomh@unaffiliated/sioraiocht] has joined #go-nuts
13:05 -!- Jgonzalez [~Jgonzalez@ool-457e1652.dyn.optonline.net] has quit [Ping
timeout: 240 seconds]
13:12 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
13:12 -!- pingveno [~pingveno@c-98-246-133-8.hsd1.or.comcast.net] has quit [Ping
timeout: 276 seconds]
13:14 -!- pingveno [~pingveno@c-98-246-133-8.hsd1.or.comcast.net] has joined
13:18 < skelterjohn> morning
13:19 < wrtp> Namegduf: that snippet doesn't work
13:19 < wrtp> in general
13:19 < wrtp> (although it would be nice if it did)
13:19 < Namegduf> wrtp: It doesn't?
13:19 < Namegduf> Pity.
13:19 -!- Fish [~Fish@exo3753.pck.nerim.net] has joined #go-nuts
13:19 < wrtp> Namegduf: no, it won't work if the function takes interface
13:20 < skelterjohn> wrtp: I was taking a look at the Make.pkg for cgo stuff
- a number of _CGO_LDFLAGS_(arch) are defined, but never used
13:21 < Namegduf> wrtp: Ah.
13:22 -!- rlab [~Miranda@] has joined #go-nuts
13:26 < wrtp> Namegduf: it doesn't work for variable-length arg lists
either, it seems
13:27 < Namegduf> Hmm, pity.
13:27 -!- qjcg [~qjcg@] has joined #go-nuts
13:27 -!- qjcg [~qjcg@] has left #go-nuts []
13:34 -!- Slant_ [~scott@] has joined #go-nuts
13:36 -!- Slant [~scott@] has quit [Ping timeout: 250 seconds]
13:37 < wrtp> Namegduf, ww: FWIW, here's how to do it properly.  that was
more effort than i thought!
13:37 < wrtp> http://pastebin.com/bR1kqHwC
13:39 < rm445> that's some impressive coding for a channel debate :-)
13:40 < wrtp> rm445: it started quite small :-)
13:42 -!- suiside [tajnyman@unaffiliated/suiside] has joined #go-nuts
13:43 -!- napsy [~luka@] has quit [Ping timeout: 246 seconds]
13:44 < wrtp> i think that reflect should support this with Call, but you
actually need two entry points
13:45 < wrtp> because you want reflect.Call(reflect.NewValue(fmt.Printf),
[]interface{}{reflect.NewValue("%d\n"), reflect.NewValue(99)})
13:46 < ww> wrtp: wow...  so maybe that's complicated enough that it should
be reflect.Apply?
13:47 < ww> and then it will inherit reflect's "do you really want to do
that?" aura
13:47 < wrtp> ww: i could see a case being made for having reflect.Apply(f
interface{}, args []interface{}) []interface{}
13:48 < wrtp> or just name if reflect.Call
13:48 < wrtp> s/if/it
13:48 < skelterjohn> makes it much easier to clone lisp
13:48 < aiju> LISP in Go?
13:48 < wrtp> skelterjohn: it's easy to clone lisp anyway :-) well, some
form of it...
13:48 -!- sauerbraten [~sauerbrat@p508CADCA.dip.t-dialin.net] has quit [Remote
host closed the connection]
13:49 < aiju> (type Foo (interface '(Foo Bar Quz)))
13:49 < skelterjohn> i think it would be more like
13:49 < skelterjohn> (type Foo (interface 3))
13:49 < skelterjohn> Foo has 3 methods
13:50 < skelterjohn> can't know more than that :)
13:50 -!- napsy [~luka@] has joined #go-nuts
13:54 -!- toyoshim_ [~toyoshim@y253149.dynamic.ppp.asahi-net.or.jp] has joined
14:01 -!- MX80 [~MX80@cust151.253.117.74.dsl.g3telecom.net] has quit [Ping
timeout: 260 seconds]
14:07 < ww> hmmm...  i wonder if my bug from earlier, the malloc/free
deadlock somehow had to do with having one big soupy package...
14:08 < ww> nope, spoke too soon: free 0xf8400baf80: not an allocated block
14:08 < ww> throw: free runtime·mlookup
14:09 < wrtp> ww: what's GOMAXPROCS set to?
14:10 < ww> wrtp in that case, 2.  with 1 it works fine
14:10 < wrtp> ww: have you tried disabling the garbage collector?
14:10 * ww will try (and hope i have enough ram)
14:11 < wrtp> :-)
14:11 < wrtp> how long before it crashes?
14:11 < ww> is there an env variable for that or twiddle in runtime?
14:11 < ww> wrtp seems a bit random, in that kcase about 670k statements
read and written
14:12 < ww> at about 18k statements / sec which is pretty good for a poor
little macbook air
14:14 -!- Venom_X [~pjacobs@] has joined #go-nuts
14:15 < ww> wrtp: how do i disable the GC?
14:15 -!- MX80 [~MX80@cust151.253.117.74.dsl.g3telecom.net] has joined #go-nuts
14:18 < skelterjohn> runtime.MemStats.EnableGC = false
14:18 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts
14:19 < ww> skelterjohn: ty (i actually saw that but wrongly assumed
MemStats was intended to be read-only)
14:19 -!- itrekkie [~itrekkie@ip72-211-129-122.tc.ph.cox.net] has quit [Ping
timeout: 252 seconds]
14:21 -!- itrekkie [~itrekkie@ip72-211-129-122.tc.ph.cox.net] has joined #go-nuts
14:21 < ww> wrtp: success with no GC
14:22 -!- erus_ [50b135f2@gateway/web/freenode/ip.] has quit [Ping
timeout: 245 seconds]
14:23 < ww> ...  repeatable success with no GC
14:23 < wrtp> ww: with no GC and GOMAXPROCS > 1, presumably
14:24 < ww> correct
14:24 < wrtp> BTW you can turn off the GC with the env var GOGC=off
14:25 < wrtp> ww: well, see how small you can make the code...  every little
helps the devs
14:25 < ww> yup
14:27 < ww> early days yet, but eventually this will really want to run with
GOMAXPROCS=8 at least...  lots of opportunities for parallelism here
14:29 -!- skejoe [~skejoe@] has joined #go-nuts
14:31 -!- iant [~iant@] has quit [Ping timeout: 250 seconds]
14:32 -!- visof [~visof@unaffiliated/visof] has quit [Quit: Leaving]
14:32 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has joined #go-nuts
14:33 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.4]
14:38 -!- skelterjohn [~jasmuth@c-68-45-238-234.hsd1.nj.comcast.net] has quit
[Quit: skelterjohn]
14:41 < ww> wow...  i think it has something to do with calls across the C
boundary...  which are surprisingly expensive...  but i'm suspicious of things
allocated with C.GoString
14:42 * ww i think i know how to test for it...
14:43 -!- shvntr [~shvntr@] has quit [Ping timeout: 276 seconds]
14:44 -!- iant [~iant@] has joined #go-nuts
14:44 -!- mode/#go-nuts [+v iant] by ChanServ
14:44 < wrtp> ww: yeah, cgo can be dubious
14:44 < wrtp> ww: if you're doing that, you might have a C bug
14:45 < wrtp> or...  you might not have properly retained references to Go
objects that you're using in C
14:45 < wrtp> so the GC might have cleaned them up
14:45 < wrtp> erm, no disrespect to cgo, iant :-)
14:45 < ww> unlikely on C bug - the part that I did in C is about two lines,
and the library that does most of the work is known to be solid for about 10 years
14:46 < wrtp> ww: are you passing it any Go-allocated objects?
14:47 < ww> wrtp yes, here is a typical example:
14:47 < ww>
14:47 < ww> the function raptor_term() and the function N3() that uses it
14:48 < ww> i don't see any opportunity for reference leaks there...
14:49 < ww> not to say they aren't happening elsewhere...
14:49 -!- napsy [~luka@] has quit [Quit: leaving]
14:49 -!- adu [~ajr@softbank220043139062.bbtec.net] has joined #go-nuts
14:49 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has joined #go-nuts
14:50 < ww> and in fact there, as elsewhere, i'm not actually pasing in go
objects, rather things made with C.CString()
14:50 < ww> which are not handled by the GC
14:52 < steven> crap.
14:52 < wrtp> ww: it doesn't look too dodgy at first glance anyway
14:52 < steven> i will have to modify
http://code.google.com/p/gosqlite/source/browse/sqlite/sqlite.go somehow, i dont
see a way around it.
14:53 -!- skelterjohn [~jasmuth@c-68-45-238-234.hsd1.nj.comcast.net] has joined
14:53 < wrtp> steven: i don't think that's a bad idea
14:53 < steven> because theres no way to know what order the fields are
being given in, in s.Scan()
14:53 < steven> they just come in whatever order they are ordered in in the
14:53 < steven> and you cant figure that out either using this lib.
14:53 < wrtp> steven: BTW
14:54 < steven> so either the user is forced to align their fields in their
struct exactly as its laid out in SQL, or i have to modify that file.
14:54 < steven> (and theres no tests with that file so it scares me to do
14:55 < wrtp> steven: i think a modified version of that package would be
14:56 < wrtp> rather than adding another layer
14:56 < wrtp> (if you keep things simple, anyway)
14:56 < Namegduf> steven: You could specify all fields in the SELECT
14:56 < Namegduf> Which will order them as specified
14:57 < wrtp> Namegduf: it'd be nice if the struct type could pick out the
required fields...
14:58 < steven> Namegduf: it still somehow needs to konw what fields there
are, which currently theres no way to in the sqlite package
14:59 < Namegduf> wrtp: I'm not sure "I want to save some but not all" is
that common, really...  doable with a sub structure is not any other way.
14:59 < Namegduf> steven: You can assume the DB is designed to meet your
needs, remember?
15:00 < steven> well, still
15:00 < wrtp> steven: not in the current sqlite package, but that link i put
up makes it easy to do
15:01 < steven> sigh..  my boss just told me hes very upset that i did not
continue working with them last wednesday until thursday at 6am (ie 22-hour
15:01 < steven> wrtp: i know, i just want to find a way around modifying
that package.
15:02 < wrtp> Namegduf: it means you could do var users []User;
sqlite.Execute("select * from usertable", &users)
15:02 -!- skelterjohn [~jasmuth@c-68-45-238-234.hsd1.nj.comcast.net] has quit
[Quit: skelterjohn]
15:02 -!- sauerbraten [~sauerbrat@p508CADCA.dip.t-dialin.net] has joined #go-nuts
15:02 < wrtp> and not need to name all the fields in the select statement
15:03 < steven> btw, https://github.com/sdegutis/GoRM so far
15:07 -!- Slant [~scott@] has quit [Quit: Slant]
15:11 < wrtp> steven: here's an idea for an updated version of Scan:
15:13 -!- karpar [~karpar@] has joined #go-nuts
15:13 -!- niemeyer [~niemeyer@201-40-140-176.pltce701.dsl.brasiltelecom.net.br]
has joined #go-nuts
15:14 < ww> wrtp: does runtime.LockOSThread() not work?
15:14 < wrtp> ww: i believe it should.  are you relying on it?
15:15 < ww> no, was speculating on a problem isolation strategy
15:15 < ww> shouldn't matter, really
15:16 < wrtp> ww: i think i'd try replacing the C code with simple stubs
that do nothing.
15:16 < ww> i've done that...  haven't reproduced it yet
15:16 < steven> btw wrtp check out my updated irc bot thing :)
15:16 < steven> https://gist.github.com/859866
15:16 < steven> muuuch saner goroutine for reading network data this time
15:17 < steven> no dealing with "quit channels" to kill rouge goroutines,
15:17 < steven> *rogue
15:18 < wrtp> steven: i'm not sure that's quite right
15:18 < steven> in Run() btw
15:18 < steven> why not?
15:18 < wrtp> steven: i don't think you want to be starting a new goroutine
for each line
15:18 < steven> i do.
15:19 < Namegduf> It's unnecessary
15:19 < steven> if you look at it, its really a synchronous loop
15:19 < Namegduf> And wrong.
15:19 < steven> i do not think its wrong.
15:19 < Namegduf> IRC clients assume previous lines are processed before new
ones are.
15:19 < steven> yes.
15:19 < Namegduf> Servers assume the same.
15:19 < jnwhiteh> IRC is a sequential protocol
15:19 < Namegduf> If you violate that you *will* break things.
15:19 < jnwhiteh> using a new goroutine to process each, that's wrong =)
15:19 < steven> i told you, this is sequenctial and practically synchronous
15:19 < steven> guys, you arent listening.
15:19 < steven> look:
15:19 < Namegduf> Then stop spawning goroutines, run it in the main one.
15:20 < jnwhiteh> why not make it actually sequential =)
15:20 < Namegduf> Spawning a goroutine to not run in parallel is stupid and
15:20 -!- imsplitbit [~imsplitbi@] has joined #go-nuts
15:20 < wrtp> Namegduf: it will be processed sequentially
15:20 < steven> Namegduf: no its not
15:20 < Namegduf> I said they were CHEAP, not that they were free
15:20 < steven> guys, stop being so stupid right now
15:20 < steven> and just listen to me
15:20 < wrtp> because quitRequestChan is only sent on once
15:20 < Namegduf> Yes, it is, because goroutines are not free.
15:20 -!- Viriix [~joseph@c-67-169-172-251.hsd1.ca.comcast.net] has joined
15:20 < Namegduf> They're an allocation of at least 4KB and a context switch
15:20 < steven> (1) a goroutine is spawned, and reads in teh background
15:20 < wrtp> however, it does seem a bit wasteful
15:20 < steven> (2) while its reading, immediately after its spawned, the
select waits for either it to send, or a quit messge to arrive.
15:21 < steven> (2a) NO NEW GOROUTINES are spawned until the current one is
15:21 < steven> (3) as soon as the only network-reading goroutine is
finished reading, it sends its data to the channel
15:21 < wrtp> why not have a separate long-running goroutine that simply
does: for {<- req; remoteChan <- readinput() }
15:21 < Namegduf> It doeesn't change that there's no reason what so ever to
spawn goroutines per line.
15:21 < Namegduf> I have a client handler.
15:21 < wrtp> i.e.  it waits for a request to read data, reads data and then
sends it back
15:22 < steven> (4) the parent goroutine can then proceed to process it, and
when its done, it starts the loop over.
15:22 < Namegduf> It reads until it has a line, it parses the line, it runs
the command, it goes back to reading
15:22 < Namegduf> Nice and simple
15:22 -!- m4dh4tt3r [~Adium@c-69-181-223-245.hsd1.ca.comcast.net] has quit [Quit:
15:22 < ww> is this a very unsafe way to copy a string into a buffer?
15:22 < steven> wrtp, Namegduf: compare that to this, my old version (which
is exactly what you guys are saying you would prefer) ...
15:22 < ww> C.memcpy(unsafe.Pointer(&buf[1]),
unsafe.Pointer(&[]byte(ustr)[0]), C.size_t(ulen))
15:22 < ww> where buf is returned (so still have a reference)
15:23 < ww> and ustr is basically the target of the method
15:23 < steven> wrtp,Namegduf: i agree it may be slightly more wasteful to
create a new goroutine for every single network-read.  but for the management
headache it resolves, i think its worth it.
15:24 < wrtp> steven: i meant something like this:
15:24 < Namegduf> steven: The correct way to abort a read is to have another
goroutine close the socket
15:24 < wrtp> i don't think that's significantly more complicated
15:24 < steven> and it isnt incorrect in its current version.
15:24 < ww> maybe i'm better off using a bytes.Buffer...
15:24 < jnwhiteh> wrtp: that is certainly how I would do it.
15:24 < jnwhiteh> in this particular example =)
15:25 < rm445> I think Goroutines are supposed to be so cheap that you spawn
them based on how you want to write your program, not worry about the cost.  Like
function calls.
15:25 < Namegduf> Not that cheap.
15:25 < Namegduf> Not "like function calls".
15:25 < jnwhiteh> its a flawed archite ture
15:25 < wrtp> oops obviously i haven't compiled that code
15:25 < jnwhiteh> they're not cheap so you can write bad code
15:25 < jnwhiteh> they're cheap so they can be used to accomplish certain
things =)
15:25 < wrtp> it wasn't bad code, just a bit more wasteful than necessary
15:25 < jnwhiteh> and they're more expensive than a function call, by a lot
15:26 < steven> i dont think what ive done is really that wsteful.
15:26 < Namegduf> It is.
15:26 < wrtp> and it wouldn't work correctly if any more cases were added to
the alt
15:26 < Namegduf> They're cheap compared to threads.
15:26 < wrtp> s/alt/select
15:26 < Namegduf> They're not cheap enough for that.
15:27 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has quit [Remote host
closed the connection]
15:27 < wrtp> i'd generally try to avoid starting new goroutines within a
15:27 < wrtp> especially when the alternative is easy
15:27 < rm445> of course they are not as cheap as function calls, my point
is that they're cheap enough that you can use them without worrying about them.
I've not done that much concurrency stuff, but I've run the example progs that
spawn hundreds of thousands of goroutines.
15:27 < jnwhiteh> you can either spawn new goroutines in a loop, or have a
loop in a goroutine
15:27 < jnwhiteh> which one makes sense, when they're equivalent?
15:27 < Namegduf> The way wrtp and you did it both ignores the obvious, easy
15:27 < Namegduf> You just read and loop.
15:28 < Namegduf> You indicate a quit by closing the socket.
15:28 < Namegduf> Which interrupts the synchronous I/O anyway.
15:28 < Namegduf> It is safe, it is the only way of actually interrupting
Read() I know of, rather than just ignoring its results.
15:28 < rm445> Are you guys familiar with the story, that the idea that
function calls are really cheap was deliberately spread with C and UNIX.  It
wasn't necessarily entirely true at the time, function call overhead *could* often
be significant on hardware at the time.
15:28 < wrtp> Namegduf: that's true.  i'd assumed that the loop was a
placeholder for something a bit more involved
15:29 < rm445> But they wanted people to avoid spaghetti code and write more
15:29 -!- Project-2501 [~Marvin@] has joined #go-nuts
15:29 < Namegduf> wrtp: I would try to simplify the shutdown indication to
that.  It works fine in my IRC server.
15:29 < wrtp> Namegduf: yeah, i don't see why you can't just read some
stuff, write some stuff.
15:29 < Namegduf> The core loops through and calls quit methods, the quit
methods set a quitting value and close the connection, read detects and terminates
15:30 < Namegduf> The process is more involved and has multiple stages due
to needing to write quit messages, wait until writes are done, handle write
errors, and so on and so forth
15:30 < Namegduf> But the principle of close as a signalling method should
work fine in complex code.
15:30 < wrtp> Namegduf: i don't even see why you need to be calling quit
15:31 < wrtp> ircbot.Read() string
15:31 < Namegduf> wrtp: It deals with those more complex bits, basically,
sending the quit message and blah.
15:31 < wrtp> ircbot.Write(s string)
15:31 < wrtp> ircbot.Quit(msg string)
15:31 < wrtp> ircbot.Close()
15:32 < Namegduf> I say the core, I mean the main goroutine of the client
package, but yeah.
15:32 -!- PortatoreSanoDiI [~Marvin@] has quit [Ping timeout: 252
15:32 < wrtp> i don't actually see that it's necessary to use a goroutine at
15:33 < wrtp> (but i'm not familiar with the IRC protocol)
15:33 < Namegduf> For a single connection, I guess you don't, but it's
probably a good idea to, anyway.
15:33 < ww> answer: it appears that was not safe
15:33 < Namegduf> Well, actually if you just expose Read(), it's the using
code's job to use one if it doesn't want to block
15:34 < Namegduf> But I assume you'd have the bot code read, parse, and call
callbacks on its own
15:34 < Namegduf> In which case, best it spawns its own goroutine so if you
like you can keep doing other stuff concurrently while communicating with the bot.
15:35 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has joined #go-nuts
15:35 < wrtp> ww: you're right, sorry, i missed your question.
15:35 -!- cenuij [~cenuij@] has joined #go-nuts
15:35 -!- cenuij [~cenuij@] has quit [Changing host]
15:35 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts
15:35 < Namegduf> (The main Perl frameworks for IRC bots work that way, but
once you start the bot control is permanently taken away from you, so you have to
write your whole program around the bot)
15:35 < exch> there's no telling what a bot will do with incoming data.  it
can be quite involved.  Multiple handlers can take their time handling the data
and perform their own writes
15:35 < Namegduf> (Although...  go ircbot.Foo() could easily solve that
15:36 < exch> I think it pays to do the reading and writing in
15:36 < wrtp> exch: why's that?
15:37 < jnwhiteh> I need to write my Go/Lua bot
15:37 < jnwhiteh> just haven't gotten around to it yet
15:37 < skelterjohn> i dislike frameworks
15:37 < exch> wrtp: because of the reason I just pointed out
15:37 < skelterjohn> utilities >>> frameworks
15:38 < wrtp> exch: i don't see why that implies separate goroutines
15:38 < exch> I dont see why not
15:38 < wrtp> if you've got multiple handlers, sure you need some kind of
demultiplexing, and that might be best done with goroutines, but that's another
15:38 < wrtp> exch: simpler without
15:39 < wrtp> synchronous read, synchronous write
15:39 < exch> https://gist.github.com/860423 this is pretty simple really.
2 routines, one for read, one for write.  Anything that needs to read/write does
so through the exposed channels.
15:39 < wrtp> skelterjohn: the nice thing about having concurrency is that
no framework need dominate
15:40 < skelterjohn> unless that framework is sdl :)
15:40 -!- Viriix [~joseph@c-67-169-172-251.hsd1.ca.comcast.net] has quit [Quit:
This computer has gone to sleep]
15:40 < Namegduf> My setup is weird
15:41 < Namegduf> Goroutine per connection reading, non-blocking Write()
method which spews into a buffer spawns a goroutine behind the scenes to write if
it takes too long.
15:41 < wrtp> exch: i don't see why it's useful to send on the Out channel
rather than just calling a Write method directly
15:41 < wrtp> that way it's easy to return an error notification too
15:41 < wrtp> similarly for read
15:42 < Namegduf> Plus WriteBlock(), which takes a closure generating stuff
to write, which is called to write regularly until it's done, without preventing
other writing from going ahead, returning once it's all done.
15:42 < wrtp> eek
15:42 < wrtp> no
15:42 < wrtp> if you're going to do that, then channels are better!
15:43 < Namegduf> wrtp: It lets you get 100,000 user IRC channels
15:43 < Namegduf> The gradual generation of output property is also
15:43 < skelterjohn> pro tip: don't join a 100k user IRC channel
15:43 < skelterjohn> sometimes scalability is not useful
15:43 < Namegduf> Yeah, irssi freezes up for a minute.
15:43 < exch> :P
15:43 < Namegduf> Yeah, but it also makes 1k and 10k channels never ever
flood you off.
15:44 < wrtp> Namegduf: how is WriteBlock better than just calling Write
many times in a row?
15:44 < Namegduf> wrtp: Because Write() does not block.
15:44 < wrtp> Namegduf: why not?
15:44 < Namegduf> Because it is Very Bad to block servers and other clients
on another client's slow writing.
15:44 < Namegduf> That is a denial of service attack issue.
15:44 < Namegduf> This is also why IRC servers do not do that now.
15:45 < wrtp> hold on, i thought we were talking about bots, i.e.  clients
15:45 < Namegduf> My setup isn't a client, no.
15:45 < wrtp> that was the original subject though
15:45 < Namegduf> Yes.
15:46 < wrtp> so your answer wasn't applicable
15:46 < Namegduf> It was, really, WriteBlock was just useless.
15:46 < ww> now that's interesting...  throw: bad defer entry in
15:46 < Namegduf> Goroutine to read, you don't really need one to write
unless you don't want to block.
15:46 < Namegduf> (There's ways to solve that from outside your code anyway)
15:47 < wrtp> Namegduf: i don't think you even need one to read unless you
want to be talking to multiple servers simultaneously
15:47 -!- Viriix [~joseph@c-67-169-172-251.hsd1.ca.comcast.net] has joined
15:47 < wrtp> and even then, i'd guess that the bot would want to be aware
of them, so would handle the channel comms itself
15:47 < Namegduf> wrtp: I would assume the code would want to loop
internally, reading, parsing, and doing stuff based on the parsing.
15:48 < Namegduf> ircbot.Read() is a kinda useless idea, you're not actually
implementing the IRC protocol at all, it's just a weird connection wrapper.
15:48 -!- ronny [~quassel@p4FF1C55F.dip0.t-ipconnect.de] has joined #go-nuts
15:48 < wrtp> Namegduf: exactly.  no need for a goroutine
15:48 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has quit [Quit:
15:48 < Namegduf> wrtp: I guess not, you could always just use go
ircbot.Start() or something.
15:49 < Namegduf> Instead of "ircbot.Start()"
15:49 < wrtp> ircbot.Read is just a placeholder for some function that reads
some stuff from the irc server, parses it and returns it
15:49 < Namegduf> As for multiple connections:
15:49 -!- karpar [~karpar@] has quit [Ping timeout: 250 seconds]
15:49 < Namegduf> Why not move stuff out of package scope into a type
15:49 < Namegduf> Then your package can spawn as many as you like.
15:49 < wrtp> Namegduf: yup
15:49 < Namegduf> Er, be used to spawn.
15:49 < Namegduf> State tracking is separate for each connection, so nothing
shared between them.
15:49 < wrtp> yup
15:50 < wrtp> ww: sounds like C memory corruption to me :-)
15:51 < wrtp> ww: (unless it's not, of course...)
15:53 < adu> yum yum...  memory corruption
15:53 < steven> i think i have a good setup as far as goroutines go for
reading network data and listening for a quit event simultaneously
15:53 < ww> that error has something to do with the trampoline...
15:53 < steven> if it werent for listening for a quit message, there would
be no need for a goroutine, and it would just be a loop.
15:54 < steven> but i want it to be able to listen for ^C while its waiting
for a network read when there is none yet
15:54 < ww> parser takes a callback, callback is really implemented in Go
but has a little C function to call into Go because of typecasting issues
15:54 < ww> (hard if not impossible to pass a correctly typed go function to
the C bit that expects a callback)
15:54 < wrtp> steven: why do you want to listen for ^C ?
15:55 < steven> so that i can quit the bot manually from the console (and in
doing so, making sure to clean up the connection)
15:55 < ww> actually, no i lied...  just need the little C stub to set the
callback handler...  it actually gets called "correctly"
15:55 < skelterjohn> steven: listen for ^D
15:55 < ww> maybe i should make a trampoline...
15:56 < steven> skelterjohn: its not reading stdin
15:56 < wrtp> steven: the connection will be cleaned up anyway...
15:56 < skelterjohn> that's the "nice" way to tell a program listening on
stdin to quit
15:56 < skelterjohn> oh
15:56 < steven> wrtp: not as cleanly though
15:56 < skelterjohn> maybe you should listen on stdin :) for quits, if
nothing else
15:56 < steven> wrtp: this way i can manually send a "QUIT" irc message
15:56 < steven> wrtp: (via the IRC protoco)
15:56 < wrtp> steven: i'd just wait for EOF on stdin
15:56 < steven> otherwise the conn would just die.
15:56 < steven> wrtp: that doesnt solve the issue at all
15:57 < steven> wrtp: instead of having a backgorund goroutine that waits
for SIGINT, i would have a bg goroutine that listens to stdin
15:57 < steven> doesnt solve anything, just changes it slightly for no good
15:57 -!- adu [~ajr@softbank220043139062.bbtec.net] has quit [Quit: adu]
15:57 < skelterjohn> the reason is good - ^C isn't meant for clean exits
15:57 < skelterjohn> it's meant for "this program needs to die now"
15:57 < steven> well fine, but it wont change the design or structure of the
15:58 < skelterjohn> what's the problem, again?
15:59 < steven> "if it werent for listening for a quit message, there would
be no need for a goroutine, and it would just be a loop."
15:59 < wrtp> there's still no reason for read to be in a separate goroutine
15:59 < steven> "but i want it to be able to listen for ^C while its waiting
for a network read when there is none yet"
15:59 < steven> yes, there is.
15:59 < wrtp> in the bot, you could do: <-sigchan; bot.Quit()
15:59 < wrtp> in a separate goroutine
15:59 < steven> you're right, but that wont ever get READ>
15:59 < wrtp> what?
15:59 < steven> because if the network-read isnt in a goroutine, it will
block if the network isnt sending.
16:00 < steven> ie, the quit wont happen immediately.
16:00 < wrtp> but if the Close the connection, the read will return
16:00 < wrtp> s/the/you
16:00 < steven> But,
16:00 < steven> i dont wanna just do conn.Close()
16:00 < steven> i want to send data first, remember?
16:00 < steven> a "QUIT\r\n"
16:00 < steven> (with a custom quit message)
16:00 < wrtp> that's fine - the Quit method doesn't have to read
16:00 < wrtp> it can just send a message and close the connection
16:01 < wrtp> whereupon the Read method will return and all's hunky dory
16:01 -!- JusticeFries [~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net]
has joined #go-nuts
16:01 < steven> well,
16:01 -!- JusticeFries [~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net]
has quit [Remote host closed the connection]
16:01 < steven> you're right.
16:01 < steven> but its a less flexible approach.
16:02 -!- JusticeFries [~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net]
has joined #go-nuts
16:02 < wrtp> i don't think you need the flexibility
16:02 < steven> so you're suggesting i simplify it so i dont have a
goroutine, giving up flexibility in the process
16:02 < wrtp> what flexibility?
16:02 < steven> i think thats a valid suggestion.  and pososibly a good
16:02 < wrtp> i don't think it's less flexible actually
16:02 < steven> hmm
16:02 < jnwhiteh> I don't see how you lose anything
16:02 -!- iant [~iant@] has quit [Quit: Leaving.]
16:03 < jnwhiteh> if you could explain, that might be useful =)
16:04 < steven> brb
16:16 < steven> crap.  boss says we're probably gonna work another 22 hour
day tomorrow.
16:16 < jnwhiteh> =(
16:16 < ww> boss if forcing you to work on Go irc bots for 22 hours
16:18 -!- rlab_ [~Miranda@] has joined #go-nuts
16:18 -!- rlab [~Miranda@] has quit [Ping timeout: 246 seconds]
16:18 -!- Viriix [~joseph@c-67-169-172-251.hsd1.ca.comcast.net] has quit [Quit:
This computer has gone to sleep]
16:18 < steven> no.  actual story work.
16:19 < steven> sigh.
16:19 < ww> wrtp: it doesn't happen with GC turned off...  so i wonder if
somewhere there is go-managed memory that is trying to be freed by C...
16:19 < fzzbt> 22 hour day?  how is that even legal?
16:20 < ww> `à la grève!
16:23 < exch> I'm all for giving a little extra at work, if and when
required.  But 22 hour workdays is ridiculous O.o
16:23 -!- Urmel|Work [~UrmelWork@cache1.uk.logica.com] has quit [Ping timeout: 240
16:25 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Quit: Leaving.]
16:31 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has quit [Quit:
Computer has gone to sleep.]
16:32 -!- PortatoreSanoDiI [~Marvin@dynamic-adsl-94-36-148-212.clienti.tiscali.it]
has joined #go-nuts
16:33 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts
16:33 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has quit [Client
16:35 -!- Project-2501 [~Marvin@] has quit [Ping timeout: 246 seconds]
16:36 < ww> boom!  throw: free runtime·mlookup
16:36 < ww> happened with maxprocs=1 this time
16:37 < ww> but in the same region: runtime.endcgocallback(0xf840004e40,
16:46 -!- skejoe [~skejoe@] has quit [Quit: Lost terminal]
16:52 -!- djbrown [~djbrown@h236n2-g-va-a12.ias.bredband.telia.com] has quit
[Quit: leaving]
16:53 -!- wrtp [~rog@] has quit [Quit: wrtp]
16:58 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has quit [Quit:
17:00 -!- djbrown [~djbrown@h236n2-g-va-a12.ias.bredband.telia.com] has joined
17:01 -!- m4dh4tt3r [~Adium@171.sub-75-208-177.myvzw.com] has joined #go-nuts
17:01 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has joined #go-nuts
17:02 -!- rlab [~Miranda@] has joined #go-nuts
17:03 -!- rlab_ [~Miranda@] has quit [Ping timeout: 264 seconds]
17:13 -!- rtharper [~tomh@unaffiliated/sioraiocht] has quit [Remote host closed
the connection]
17:19 -!- iant [~iant@nat/google/x-dlnbcerxezuajokd] has joined #go-nuts
17:19 -!- mode/#go-nuts [+v iant] by ChanServ
17:22 -!- pharris [~Adium@rhgw.opentext.com] has joined #go-nuts
17:23 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has joined #go-nuts
17:24 -!- rlab_ [~Miranda@] has joined #go-nuts
17:25 -!- rlab [~Miranda@] has quit [Ping timeout: 240 seconds]
17:27 -!- foocraft [~dsc@dyn-86-36-42-96.wv.qatar.cmu.edu] has quit [Ping timeout:
248 seconds]
17:28 -!- photron [~photron@port-92-201-97-47.dynamic.qsc.de] has joined #go-nuts
17:33 -!- foocraft [~dsc@dyn-86-36-34-249.qatar.cmu.edu] has joined #go-nuts
17:35 -!- saschpe [~quassel@opensuse/member/saschpe] has joined #go-nuts
17:36 < zozoR> i wonder why no one has ever asked google why stomach acid
does not dissolve the stomach : |
17:37 < aho> gastric mucosa
17:37 -!- tensorpudding [~user@] has joined #go-nuts
17:39 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts
17:42 -!- m4dh4tt3r [~Adium@171.sub-75-208-177.myvzw.com] has quit [Ping timeout:
250 seconds]
17:45 < steven> zozoR: apparently because #go-nuts is more helpful and gives
more immediate/reliable results than google
17:46 < xulfer> Heh I googled it and came up with an answer right away
17:46 < steven> hi
17:47 < zozoR> weird, what did you google o.o
17:47 < zozoR> gastric mucosa was not really the answer :D
17:48 < zozoR> it does not say anywhere that "gastric mucosa protects the
stomach against the acid"
17:48 -!- m4dh4tt3r
[~Adium@] has joined
17:49 * jumzi thinks zozoR needs to retake his chemistry class
17:50 * zozoR slaps himself
17:50 < zozoR> thanks for bringing up that acid isnt magic :D
17:51 < exch> belly of steel!
17:51 -!- rtharper [~tomh@unaffiliated/sioraiocht] has joined #go-nuts
17:52 < exch>
sweet mother of f*ck..  look at the xml response that requst generates O_o
18:05 < jumzi> Luckily xml i both easy to parse and easy to read, yet
18:05 < jumzi> is*
18:05 < exch> It needs to burn in raging hellfire
18:06 * cbeck runs away screaming
18:10 < steven> on modern day servers, what are the limitations as to how
many TCP connections a single (go) process can accept simultaneously?  ie, what
are the problems one might run into if they try to write a web server of their
18:11 < jnwhiteh> The limitations are OS based, mostly
18:11 < exch> I believe there was a benchmarking thread on the mailinglist
18:11 < jnwhiteh> you'll run into file descriptor limits first
18:11 < steven> oh.
18:11 < jnwhiteh> exch: the python/go one?  it didn't really go into this at
18:11 < jnwhiteh> steven: I've got lots of information on this if that helps
18:12 < exch> jnwhiteh: yea that's the one.  Not sure what it did and did
not cover though
18:12 < steven> cool
18:12 -!- foocraft [~dsc@dyn-86-36-34-249.qatar.cmu.edu] has quit [Quit: Leaving]
18:12 < jnwhiteh> There's a bug that causes Go(http) servers to crash under
heavy load right now that I'm trying to isolate
18:13 < jnwhiteh> but on my hardware the server can handle 3000-4500
concurrent connections generating sustained load
18:13 < jnwhiteh> but I had to add a limiter to the http package to get
those results
18:15 < jnwhiteh> file descriptor limits and ephemeral port ranges are two
obvious ones if you're sure you're not hitting bandwidth limits on the network
device, etc.
18:15 < steven> jnwhiteh: using the http package or the net package?
18:16 < jnwhiteh> using http and DefaultServeMux
18:16 < steven> ok.
18:16 < steven> i was considering going lower level and writing one based
purely on net
18:16 < jnwhiteh> I hit a malloc deadlock
18:16 -!- sacho [~sacho@87-126-37-121.btc-net.bg] has joined #go-nuts
18:16 < jnwhiteh> which obviously shouldn't happen =)
18:16 < jnwhiteh> you could do that, but you'd just be rewriting all the
18:16 < jnwhiteh> not sure that makes all that much sense
18:17 < jnwhiteh> given that it just uses net.Conns with buffering
18:20 -!- rurban [~chatzilla@88-117-13-227.adsl.highway.telekom.at] has joined
18:21 < steven> true.
18:23 -!- keithcascio [~keithcasc@nat/google/x-scatqxsqihakqnnn] has joined
18:25 < xulfer> And there's kernel limitations depending on the platform you
can run into.
18:25 < xulfer> But on almost all of them you can tune those.
18:40 < steven> whats a good assumption for a max number of connections ill
be able to accept and read/write simultaneously?
18:41 < Namegduf> You'll run into OS issues first, as said.
18:41 < Namegduf> Without them...  "a lot", hypothetically.
18:41 < Namegduf> Depends how tuned you get your design.
18:42 < Namegduf> Assuming they have a goroutine each, 100k is a pretty fair
number, but if you have enough RAM that's perfectly feasible.
18:43 < Namegduf> It's similar to C, in that the primary limiting factor is
how efficient your design is, not language limitations or inherent slowness.
18:49 -!- Fish- [~Fish@9fans.fr] has joined #go-nuts
18:51 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the
18:55 -!- KingPhilroy [~kingphilr@shc-nat-newhall.stonehill.edu] has joined
18:56 -!- femtooo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts
18:57 -!- fabled [~fabled@mail.fi.jw.org] has quit [Quit: Ex-Chat]
18:59 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Ping timeout:
276 seconds]
19:01 -!- boscop_ [~boscop@g229209193.adsl.alicedsl.de] has joined #go-nuts
19:03 -!- boscop [~boscop@f055255209.adsl.alicedsl.de] has quit [Ping timeout: 246
19:08 < steven> right
19:09 < ww> aha.  so weird memory corruption woes of earlier on seem to have
been fixed by changeset: 7670:a45a5a3e3458 summary: runtime: scheduler, cgo
19:09 < ww> ...  just yesterday
19:13 -!- boscop [~boscop@g229209193.adsl.alicedsl.de] has joined #go-nuts
19:13 < skelterjohn> all that did was have cgo put generated source in _obj
19:14 < skelterjohn> so unless something very strange was happening, it
wouldn't affect a memory corruption issue
19:14 < ww> skelterjohn: didn't look at the changes...  maybe a previous
19:14 -!- boscop_ [~boscop@g229209193.adsl.alicedsl.de] has quit [Read error:
Connection reset by peer]
19:14 < ww> but near that anyways
19:14 < skelterjohn> well, maybe the scheduler part
19:14 < skelterjohn> but the cgo reorganization didn't do it :)
19:19 < dfr|work> does regexp package support capturing groups?
19:20 < dfr|work> 'cause i don't think I see anything about that in the
package documentation [or any ways to access captured information....]
19:20 < exch> If you mean sub-matches by that, then yes.
19:21 < dfr|work> exch, I mean something like /^(.*)@(.*)$/
19:22 < dfr|work> exch, that way I can check that the string conforms to
expected format and get the data.
19:22 < exch> yes, that is supported
19:22 < exch> everything inside ( ...  ) is delivered to you in a sub-match
19:23 < exch> reg.FindSubmatch() and reg.FindStringSubmatch()
19:24 -!- TheMue [~TheMue@p5DDF782D.dip.t-dialin.net] has joined #go-nuts
19:24 < exch> gives a slice of matches.  Where m[0] is the full matching
text.  And the remaining indices are the groups you defined in order
19:24 < dfr|work> exch, oh, I think I get it.
19:24 < dfr|work> exch, so I can just do submatch against it and make sure I
don't get nil
19:24 < exch> yup
19:24 < dfr|work> exch, okay, cool.  Thanks :)
19:25 -!- saschpe [~quassel@opensuse/member/saschpe] has quit [Remote host closed
the connection]
19:26 -!- rlab_ [~Miranda@] has quit [Ping timeout: 255 seconds]
19:28 -!- AdamMan [~millertim@cpe-76-184-240-222.tx.res.rr.com] has joined
19:28 < AdamMan> hey guys
19:29 < dfr|work> okay, somewhat fishing, but if I have a slice, can I do
something like (foo, bar, zeta) := slice ? so that if it's of size 3, it will be
assigned to those variables?
19:29 < AdamMan> if I wanted to create a module in go
19:29 < AdamMan> and compile it
19:29 < AdamMan> could I load that module into python and call it
19:29 < AdamMan> kind of like what ctypes offers
19:29 < AdamMan> ?
19:30 < exch> dfr|work: nope
19:30 < dfr|work> exch, okay, thanks.  :)
19:30 < exch> AdamMan: everything in Go is statically linked.  You can't
create dynamic libraries with Go
19:31 -!- rlab [~Miranda@] has joined #go-nuts
19:31 < AdamMan> exch
19:31 < AdamMan> crap
19:31 < AdamMan> well I guess I'm not using go
19:32 < dfr|work> AdamMan, you can always create a go binary and invoke it
19:32 < AdamMan> yeah...
19:32 < AdamMan> it's not the same...
19:32 < exch> dfr|work: if you know slice will hold 3 values, you can do a,
b, c := s[0], s[1], s[2]
19:32 < AdamMan> maybe there will be a reimplementation of python under go
that will allow for thsi support
19:32 < dfr|work> exch, right, that's what I figured.  I'm just not sure
about shortcuts yet, so still learning :)
19:33 < exch> :)
19:35 < dfr|work> exch, what's a common go project structure?  src/ for
sources and test/ for tests?
19:35 < steven> i wonder if nginx would be better somehow if rewritten in go
19:35 < dfr|work> meh, I can probably figure that out myself the hard way.
19:36 < dfr|work> steven, what could be more interesting is a node.js
architecture implementation, maaaybe
19:36 < exch> I dont think there really is an established standard for
projetc layout.  Whatever works for you
19:37 < dfr|work> steven, that way can really stress the parallelization
aspects, may be.
19:41 -!- AdamMan [~millertim@cpe-76-184-240-222.tx.res.rr.com] has left #go-nuts
19:41 < skelterjohn> AdamMan: it's not that go is opposed to dynamic linking
- it's just not something that is on the current todo list
19:41 < skelterjohn> maybe it will be there one day
19:41 < skelterjohn> but it's not straightforward to do
19:41 < skelterjohn> damn, too late
19:43 -!- perdix [~mkhl@sxemacs/devel/perdix] has joined #go-nuts
19:44 < dfr|work> so I'm kinda guessing that the testing package doesn't
provide various testing assertions, e.g.  assertEquals etc?
19:53 -!- awidegreen [~quassel@c-eacae555.08-2-73746f39.cust.bredbandsbolaget.se]
has joined #go-nuts
19:53 < skelterjohn> no
19:53 < skelterjohn> such a function, if general, would require either
reflection or generics
19:54 < skelterjohn> at least in the cases when == is insufficient
19:54 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has quit [Read error:
Operation timed out]
19:58 -!- perdix [~mkhl@sxemacs/devel/perdix] has quit [Remote host closed the
19:59 < dfr|work> skelterjohn, well, I'd imagine == is fine with me...
19:59 < skelterjohn> mostly yes, but if you have two slices of things
19:59 -!- AdamMan [~millertim@cpe-76-184-240-222.tx.res.rr.com] has joined
19:59 < skelterjohn> and you want to see if they're the same, == won't work
19:59 < dfr|work> skelterjohn, basically, I guess my issue is struggling how
to specify those assertions.
19:59 < dfr|work> skelterjohn, yea, that's true.
19:59 < skelterjohn> if A != B { t.Error("A and B should really be equal!")
19:59 < skelterjohn> }
19:59 < AdamMan> what's the good in go if you can only produce a statically
linked binaries in go
19:59 < AdamMan> ?
19:59 < skelterjohn> AdamMan: Nothing about go means there can't be dynamic
20:00 < AdamMan> skelterjohn, ok
20:00 < skelterjohn> it's just hard, given the different runtime, and as a
result it's not on the todo list right now
20:00 < dfr|work> skelterjohn, right.  That's not as easy to read as
explicit expectations assertEquals(A, B)
20:00 < skelterjohn> dfr|work: I disagree.
20:00 < AdamMan> well, what can be done about inter-language integration?
20:00 < skelterjohn> At the moment, you can invoke C code from go, and from
there do whatever you like
20:00 < dfr|work> skelterjohn, that's cool.  ;) It's quite possible that
your eye is trained to that much better than mine.  ;)
20:00 < AdamMan> i mean...  C++ can be used to embed and extend python and
other languages, which makes them fast and
20:00 < skelterjohn> but, at the moment, you cannot embed go code in other
20:01 < dfr|work> skelterjohn, but even so, I guess I'll just poke my way
and see what's up.  :)
20:01 < AdamMan> skelterjohn, but you can't use C++ objects or code from
within go?
20:01 < skelterjohn> AdamMan: embedding python in another language doesn't
make it fast
20:01 < skelterjohn> embedding another language in python can be fast,
20:01 < skelterjohn> AdamMan: You can.
20:01 < skelterjohn> like i said, you can link C from a go program
20:01 < AdamMan> skelterjohn, right, but it's a capability I"m just saying
20:01 < skelterjohn> and then do whatever you like in the C code
20:01 < AdamMan> skelterjohn, ok, but you can't embed go within python?
20:01 < AdamMan> I would like to be able to do that
20:02 * ww was just working on some python stuff and kept typing braces and :=
20:02 < ww> :P
20:02 < skelterjohn> not at the moment, at least not easily
20:02 < AdamMan> are there any projects focusing on that?
20:02 < rurban> It would be trivial to setup perl to embedd go, via some
20:02 < skelterjohn> not that i'm aware of
20:02 < ww> AdamMan: you can definitely use C++ libraries from within go
20:03 < ww> as long as they have a C wrapper...
20:03 < ww> which is typical
20:03 < AdamMan> rurban, so you can embed go into perl
20:03 < AdamMan> ?
20:03 < AdamMan> and dynamically play with go types and functions?
20:03 < ww> not so sure of perl...  you'd have to replace perl's main()
20:04 < ww> aiui
20:04 < rurban> Not yet, but it would be 10min work.
20:04 -!- AdamMan [~millertim@cpe-76-184-240-222.tx.res.rr.com] has left #go-nuts
20:04 < skelterjohn> AdamMan: you cannot (without writing lots of your own
linking code) embed go in any other language
20:04 < skelterjohn> rurban: I would love to see it
20:04 * ww starts the clock...  10min
20:04 < skelterjohn> unless you mean just launch a go executable from perl
20:04 < skelterjohn> in which case that is not what we're talking about
20:05 < rurban> Rigth now I have to re-install my solaris box, sorry )
20:05 < skelterjohn> then forgive me for being a skeptic
20:05 < rurban> Ah, of course I would cheat :) go is fast, so why not
compile and link on the fly
20:05 < skelterjohn> because you want to deal directly with go's data and
20:06 < skelterjohn> otherwise you're just running a 2nd program and
examining communication channels
20:06 < skelterjohn> which is certainly a useful thing to do
20:06 < skelterjohn> but also trivial
20:06 -!- sauerbraten [~sauerbrat@p508CADCA.dip.t-dialin.net] has quit [Remote
host closed the connection]
20:06 < rurban> Reflection?  Ok, embedding perl or pythin into go would also
not be too hard.
20:06 < skelterjohn> right - you can definitely embed any language into go,
as long as you can invoke taht language using C code
20:06 < ww> you *could* embed perl into go and then give perl a goroutine
and arrange for perl to call go functions as though they were c functions...
20:07 < ww> but you'd have to individually bless the go functions to be
called and write many little wrappers
20:08 -!- Natch| [~natch@c-6dcde155.25-4-64736c10.cust.bredbandsbolaget.se] has
quit [Ping timeout: 246 seconds]
20:08 -!- Natch| [~natch@c-6dcde155.25-4-64736c10.cust.bredbandsbolaget.se] has
joined #go-nuts
20:09 -!- djbrown [~djbrown@h236n2-g-va-a12.ias.bredband.telia.com] has quit
[Remote host closed the connection]
20:09 < rurban> Since go has no dynamic FFI yet, it will be a bit hard, yes.
cgo is only static AFAIK
20:12 -!- XenoPhoenix [~Xeno@cpc13-aztw24-2-0-cust23.aztw.cable.virginmedia.com]
has quit [Ping timeout: 248 seconds]
20:13 -!- rlab [~Miranda@] has quit [Quit: Miranda IM! Smaller,
Faster, Easier.  http://miranda-im.org]
20:14 -!- rlab [~Miranda@] has joined #go-nuts
20:19 -!- djbrown [~djbrown@h236n2-g-va-a12.ias.bredband.telia.com] has joined
20:25 -!- foocraft [~dsc@] has joined #go-nuts
20:31 -!- boscop [~boscop@g229209193.adsl.alicedsl.de] has quit [Read error:
Connection reset by peer]
20:32 -!- boscop [~boscop@g229209193.adsl.alicedsl.de] has joined #go-nuts
20:40 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
20:42 -!- perdix [~mkhl@sxemacs/devel/perdix] has joined #go-nuts
20:52 < steven> keep in mind, you can also run them as an interactive
20:52 < steven> ie, a file with stdin/stdout, which you communicate with..
20:52 < steven> granted thats very limited compared to using genuine c
20:58 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has quit [Quit:
21:01 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts
21:04 -!- femtooo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Ping timeout:
246 seconds]
21:06 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Ping timeout: 276 seconds]
21:13 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
21:18 -!- pothos_ [~pothos@111-240-165-119.dynamic.hinet.net] has joined #go-nuts
21:20 -!- pothos [~pothos@111-240-171-231.dynamic.hinet.net] has quit [Ping
timeout: 260 seconds]
21:21 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has quit [Ping
timeout: 246 seconds]
21:22 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Read error:
Connection reset by peer]
21:23 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has quit [Remote host closed
the connection]
21:29 -!- boscop [~boscop@g229209193.adsl.alicedsl.de] has quit [Read error:
Connection reset by peer]
21:29 -!- boscop [~boscop@g229209193.adsl.alicedsl.de] has joined #go-nuts
21:32 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Ping timeout: 246 seconds]
21:33 -!- XenoPhoenix [~Xeno@cpc13-aztw24-2-0-cust23.aztw.cable.virginmedia.com]
has joined #go-nuts
21:35 -!- tvw [~tv@e176002093.adsl.alicedsl.de] has joined #go-nuts
21:36 -!- piranha [~piranha@5ED4B890.cm-7-5c.dynamic.ziggo.nl] has joined #go-nuts
21:37 -!- wrtp [~rog@] has joined #go-nuts
21:39 -!- wrtp [~rog@] has quit [Client Quit]
21:40 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
21:47 -!- iant [~iant@nat/google/x-dlnbcerxezuajokd] has quit [Quit: Leaving.]
21:48 -!- TheMue [~TheMue@p5DDF782D.dip.t-dialin.net] has quit [Quit: TheMue]
21:51 -!- cco3-hampster [~conleyo@nat/google/x-coayglfxgjwcmfga] has quit [Quit:
21:52 -!- sacho [~sacho@87-126-37-121.btc-net.bg] has quit [Quit: Ex-Chat]
21:52 -!- sacho [~sacho@87-126-37-121.btc-net.bg] has joined #go-nuts
21:54 -!- iant [~iant@nat/google/x-uzrcwyadedaonroz] has joined #go-nuts
21:54 -!- mode/#go-nuts [+v iant] by ChanServ
21:59 -!- rlab [~Miranda@] has quit [Quit: Miranda IM! Smaller,
Faster, Easier.  http://miranda-im.org]
22:06 -!- piranha_ [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has joined
22:08 -!- piranha [~piranha@5ED4B890.cm-7-5c.dynamic.ziggo.nl] has quit [Ping
timeout: 276 seconds]
22:10 -!- photron [~photron@port-92-201-97-47.dynamic.qsc.de] has quit [Ping
timeout: 246 seconds]
22:11 -!- niooins [2eb0308c@gateway/web/freenode/ip.] has joined
22:15 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Ping timeout: 264 seconds]
22:16 -!- awidegreen [~quassel@c-eacae555.08-2-73746f39.cust.bredbandsbolaget.se]
has quit [Read error: Connection reset by peer]
22:17 -!- viirya [~viirya@cml506-25.csie.ntu.edu.tw] has quit [Read error:
Connection reset by peer]
22:18 -!- viirya [~viirya@cml506-25.csie.ntu.edu.tw] has joined #go-nuts
22:21 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
22:29 -!- PortatoreSanoDiI [~Marvin@dynamic-adsl-94-36-148-212.clienti.tiscali.it]
has quit [Quit: E se abbasso questa leva che succ...]
22:30 -!- rtharper [~tomh@unaffiliated/sioraiocht] has quit [Remote host closed
the connection]
22:30 -!- DerHorst [~Horst@e177130087.adsl.alicedsl.de] has joined #go-nuts
22:32 -!- dfc [~dfc@sydfibre2.atlassian.com] has joined #go-nuts
22:33 -!- adu [~ajr@softbank220043138128.bbtec.net] has joined #go-nuts
22:39 -!- rtharper [~tomh@unaffiliated/sioraiocht] has joined #go-nuts
22:40 < rl> How do people feel about keeping state on a package level vs
passing around structs, if you think you'll ever only created one struct?
22:40 < rl> I've been playing around with it, seeing how not-OO I can do
things, but it's looking like it will make unittesting a true pain in the ass in
some cases
22:41 < |Craig|> I like what the http stuff does.  it has a default object,
but you can make more if you choose
22:41 < rl> Hm, that's a good idea
22:43 < rl> my biggest issue so far has been cases where a package A uses
package B in some way, but because everything in package B is package-level I have
no way of controlling how package A uses package B in any way, so I have to test
around that.
22:47 -!- niooins [2eb0308c@gateway/web/freenode/ip.] has left
#go-nuts []
22:53 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit:
22:54 -!- imsplitbit [~imsplitbi@] has quit [Quit: Bye!]
22:55 -!- Guest55108 [~quassel@p4FF1C55F.dip0.t-ipconnect.de] has quit [Remote
host closed the connection]
22:55 -!- piranha_ [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has quit [Quit:
Computer has gone to sleep.]
22:56 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has quit [Quit: skelterjohn]
22:58 -!- rurban [~chatzilla@88-117-13-227.adsl.highway.telekom.at] has quit [Ping
timeout: 276 seconds]
22:58 -!- Fish- [~Fish@9fans.fr] has quit [Quit: So Long, and Thanks for All the
23:01 -!- ronnyy [~quassel@p4FF1C55F.dip0.t-ipconnect.de] has joined #go-nuts
23:02 -!- boscop [~boscop@g229209193.adsl.alicedsl.de] has quit [Ping timeout: 246
23:10 -!- ronnyy [~quassel@p4FF1C55F.dip0.t-ipconnect.de] has quit [Remote host
closed the connection]
23:19 < dfc> |Craig|: i'm not a fan of the way the http package uses the
23:19 < dfc> i don't think its a pattern that should be emulated
23:19 -!- rtharper [~tomh@unaffiliated/sioraiocht] has quit [Remote host closed
the connection]
23:19 < dfc> i'd prefer, for example
23:19 < dfc> http.DefaultMux.AddListener()
23:19 < dfc> then http.ServeHttp(http.DefaultMux)
23:19 < dfc> ^ note, just making this up, i can't remember the real syntax
23:23 < |Craig|> dfc: I'll agree that its is not done the best way.  It
might even be better to put all the default stuff in a subpackage, http.default
23:23 < |Craig|> mainly I liked the idea of having a default
23:24 < dfc> i agree, it makes it more useful, and more demoable
23:25 < dfc> but the hidden magic that happens when you call
ListenAndServer() with a nil handler
23:25 < dfc> makes it hard to decouple
23:25 < dfc> and passing nil has a code smell
23:25 < dfc> better to make it ListenAndServe(..., http.DefaultMux)
23:26 < |Craig|> that did confuse me
23:27 < |Craig|> if we had http.default, we could do
http.default.ListenAndServe() if we wanted
23:27 < dfc> sure, it works, but it's too close to magic for my liking
23:27 < dfc> and it doesn't appear in the style of Go,
23:28 < |Craig|> anyway, I hate magic leaking into APIs
23:28 < dfc> from the looks of things bradfitz is the http czar now
23:28 < dfc> he'd be the man to talk to
23:29 < |Craig|> Any changes I'd suggest would be small and break backwards
compatibility.  Overall it works pretty slick :)
23:30 < |Craig|> I haven't done much with it though
23:30 < dfc> neither have I
23:30 < dfc> but I think brad is cooking up something world class
23:30 < dfc> the client classes especially I think are going to be top shelf
23:31 < dfc> adg: if I log an issue that goprotobuf blows up when you try to
build it with -j4, is r going to slap me ?
23:32 <@adg> dfc: give it a try
23:32 <@adg> at the very least, i will be amused
23:32 < dfc> i figured as much
23:32 < dfc> :P
23:32 <@adg> ;)
23:32 < dfc> with my newly aquired stockholm Makefile syndrome, it shouldn't
be hard to fix
23:33 < dfc> in short, DEPS=...  is not parallel make safe
23:39 < dfc> right, bug logged, and helmet donned
23:39 * dfc prepares for a slapping
23:39 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Ping timeout: 264 seconds]
23:46 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
23:47 -!- perdix [~mkhl@sxemacs/devel/perdix] has quit [Remote host closed the
23:49 -!- prip [~foo@host168-126-dynamic.36-79-r.retail.telecomitalia.it] has quit
[Ping timeout: 276 seconds]
23:54 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has joined #go-nuts
23:57 -!- iant [~iant@nat/google/x-uzrcwyadedaonroz] has quit [Quit: Leaving.]
--- Log closed Wed Mar 09 00:00:55 2011