--- Log opened Tue Mar 08 00:00:48 2011 --- Day changed Tue Mar 08 2011 00:00 -!- shvntr [~shvntr@113.84.149.129] has joined #go-nuts 00:03 -!- shvntr_ [~shvntr@113.84.149.129] 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@78.100.186.63] has quit [Ping timeout: 255 seconds] 00:23 -!- nixness [~dsc@89.211.254.177] 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@200.119.188.127] 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@200.119.181.122] has joined #go-nuts 01:00 -!- nettok [~quassel@200.119.188.127] 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@89.211.254.177] has quit [Quit: Leaving] 01:15 -!- saturnfive [~saturnfiv@210.74.155.131] 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 #go-nuts 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@113.84.149.129] has quit [Quit: leaving] 02:05 -!- libv8 [~gj@cpc2-lewi9-0-0-cust84.2-4.cable.virginmedia.com] has joined #go-nuts 02:05 -!- shvntr [~shvntr@113.84.149.129] has joined #go-nuts 02:08 -!- Slant [~scott@120.18.39.130] has joined #go-nuts 02:11 -!- foocraft [~dsc@89.211.254.177] 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@120.18.39.130] has quit [Ping timeout: 260 seconds] 02:27 -!- mikespook [~mikespook@219.137.253.190] has joined #go-nuts 02:34 -!- qjcg [~qjcg@208.88.110.46] has joined #go-nuts 02:34 -!- qjcg [~qjcg@208.88.110.46] 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 #go-nuts 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 products 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@66.54.185.131] 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@200.119.181.122] 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 seconds] 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 seconds] 04:06 -!- drhodes [~none@drhodes.xen.prgmr.com] has quit [Ping timeout: 252 seconds] 04:07 -!- barkmore [~textual@50-46-115-110.evrt.wa.frontiernet.net] has joined #go-nuts 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: Leaving] 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@89.211.254.177] 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@113.84.149.129] has quit [Quit: leaving] 04:31 -!- Viriix [~joseph@c-67-169-172-251.hsd1.ca.comcast.net] has joined #go-nuts 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 2011-03-07 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 extension 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> http://img.jteeuwen.nl/var/albums/Misc/20110308-1299559144x-2xMar.png?m=1299559982 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 order 05:11 < steven> so the buffer is always empty every time that goroutine is created. 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 goroutine.. 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: Leaving] 05:29 -!- shvntr_ [~shvntr@113.84.149.129] 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@188.114.142.162] has joined #go-nuts 06:24 < steven> <3 06:32 -!- Slant [~scott@115.130.7.136] 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@188.114.142.162] 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@115.130.7.136] 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@210.74.155.131] has quit [Read error: Connection reset by peer] 07:10 -!- saturnfive [~saturnfiv@210.74.155.131] has joined #go-nuts 07:14 -!- Slant [~scott@115.130.21.240] 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 seconds] 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@41.233.113.242] has joined #go-nuts 07:31 -!- visof [~visof@41.233.113.242] has quit [Changing host] 07:31 -!- visof [~visof@unaffiliated/visof] has joined #go-nuts 07:31 -!- wrtp [~rog@92.16.113.213] has joined #go-nuts 07:37 -!- napsy [~luka@193.2.66.6] has joined #go-nuts 07:37 -!- piranha [~piranha@5ED4B890.cm-7-5c.dynamic.ziggo.nl] has joined #go-nuts 07:41 -!- Slant [~scott@115.130.21.240] 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@91.200.158.34] 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@151.22.69.61] has joined #go-nuts 08:28 -!- mariolone [~mariolone@151.22.69.61] has left #go-nuts [] 08:34 -!- tensorpudding [~user@99.56.160.152] 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 #go-nuts 09:08 -!- boscop [~boscop@f055255209.adsl.alicedsl.de] has joined #go-nuts 09:30 -!- mikespook [~mikespook@219.137.253.190] 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@115.130.14.179] 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@115.130.14.179] has quit [Quit: Slant] 10:23 -!- rtharper [~tomh@unaffiliated/sioraiocht] has quit [Remote host closed the connection] 10:25 -!- saturnfive [~saturnfiv@210.74.155.131] 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.80.177.53.242] has joined #go-nuts 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 seconds] 11:08 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 276 seconds] 11:09 -!- saturnfive [~saturnfiv@61.150.60.253] has joined #go-nuts 11:09 -!- saturnfive [~saturnfiv@61.150.60.253] has left #go-nuts [] 11:14 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 11:15 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Read error: Connection reset by peer] 11:32 -!- adu [~ajr@softbank220043138128.bbtec.net] has quit [Quit: adu] 11:39 -!- PortatoreSanoDiI [~Marvin@82.84.78.173] 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 out] 11:54 -!- Slant [~scott@115.130.18.249] has joined #go-nuts 12:09 -!- sahid [~sahid@LNeuilly-152-21-22-10.w193-253.abo.wanadoo.fr] has joined #go-nuts 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 something? 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 then 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@91.200.158.34] 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: http://codereview.appspot.com/4253052/diff/1019/src/pkg/os/exec.go 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 stuff. 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 inefficient) 12:30 < wrtp> or even func(args string) if you didn't want the args pre-parsed 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... prolog... 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 arguments 12:33 < Namegduf> At compile time. 12:33 < Slant> In a program directory with a normal program makefile (ala code.html) 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 #go-nuts 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@209.249.216.2] has joined #go-nuts 12:36 -!- tokuhiro__ [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has joined #go-nuts 12:36 -!- Wiz126 [~Wiz@24.229.245.72.res-cmts.sm.ptd.net] 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 type. 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@113.84.149.129] 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 #go-nuts 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 reflect? 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 constructor. 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 #go-nuts 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 arguments 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@91.200.158.34] 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@208.88.110.46] has joined #go-nuts 13:27 -!- qjcg [~qjcg@208.88.110.46] has left #go-nuts [] 13:34 -!- Slant_ [~scott@115.130.6.214] has joined #go-nuts 13:36 -!- Slant [~scott@115.130.18.249] 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@193.2.66.6] 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@193.2.66.6] has joined #go-nuts 13:54 -!- toyoshim_ [~toyoshim@y253149.dynamic.ppp.asahi-net.or.jp] has joined #go-nuts 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@66.54.185.131] 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.80.177.53.242] 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@188.114.142.162] has joined #go-nuts 14:31 -!- iant [~iant@216.239.45.130] 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@113.84.149.129] has quit [Ping timeout: 276 seconds] 14:44 -!- iant [~iant@67.218.107.6] 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> https://bitbucket.org/ww/goraptor/src/058b58f30096/goraptor.go#cl-147 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@193.2.66.6] 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 #go-nuts 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 DB 14:53 < steven> and you cant figure that out either using this lib. 14:53 < wrtp> steven: BTW http://www.sqlite.org/c3ref/column_database_name.html 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 so) 14:55 < wrtp> steven: i think a modified version of that package would be good 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 shift). 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@115.130.6.214] has quit [Quit: Slant] 15:11 < wrtp> steven: here's an idea for an updated version of Scan: http://pastebin.com/RTvzQTRj 15:13 -!- karpar [~karpar@112.96.224.12] 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, etc. 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 practically. 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 wrong 15:20 -!- imsplitbit [~imsplitbi@64.39.4.132] 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 #go-nuts 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 finished. 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: Leaving.] 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) ... https://gist.github.com/858028 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: http://pastebin.com/eTAfxqd6 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 loop 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 way. 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 functions. 15:29 -!- Project-2501 [~Marvin@82.84.69.234] 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 cleanly. 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 methods 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@82.84.78.173] has quit [Ping timeout: 252 seconds] 15:32 < wrtp> i don't actually see that it's necessary to use a goroutine at all 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@78.112.41.178] has joined #go-nuts 15:35 -!- cenuij [~cenuij@78.112.41.178] 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 anyway.) 15:36 < exch> I think it pays to do the reading and writing in separategoroutines 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 issue 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 important. 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 here 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 endcgocallback 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 #go-nuts 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: Leaving] 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@112.96.224.12] 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 reason 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 app 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 idea. 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@67.218.107.6] 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 straight? 16:18 -!- rlab_ [~Miranda@91.200.158.34] has joined #go-nuts 16:18 -!- rlab [~Miranda@91.200.158.34] 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 seconds] 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 Quit] 16:35 -!- Project-2501 [~Marvin@82.84.69.234] 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, 0x2b42ed0) 16:46 -!- skejoe [~skejoe@188.114.142.162] 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@92.16.113.213] has quit [Quit: wrtp] 16:58 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has quit [Quit: Leaving] 17:00 -!- djbrown [~djbrown@h236n2-g-va-a12.ias.bredband.telia.com] has joined #go-nuts 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@91.200.158.34] has joined #go-nuts 17:03 -!- rlab_ [~Miranda@91.200.158.34] 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@91.200.158.34] has joined #go-nuts 17:25 -!- rlab [~Miranda@91.200.158.34] 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@99.56.160.152] 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@75.144.24.109-BusName-walnutcreek.ca.hfc.comcastbusiness.net] has joined #go-nuts 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> http://code.google.com/p/bitly-api/wiki/ApiDocumentation#/v3/clicks_by_minute 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 powerful! 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 own? 18:11 < jnwhiteh> The limitations are OS based, mostly 18:11 < exch> I believe there was a benchmarking thread on the mailinglist recently 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 all 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 functionality 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 #go-nuts 18:21 < steven> true. 18:23 -!- keithcascio [~keithcasc@nat/google/x-scatqxsqihakqnnn] has joined #go-nuts 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 connection] 18:55 -!- KingPhilroy [~kingphilr@shc-nat-newhall.stonehill.edu] has joined #go-nuts 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 seconds] 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 reorganization 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 changeset? 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@91.200.158.34] has quit [Ping timeout: 255 seconds] 19:28 -!- AdamMan [~millertim@cpe-76-184-240-222.tx.res.rr.com] has joined #go-nuts 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 dynamically? 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@91.200.158.34] 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 ["Leaving"] 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 connection] 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 #go-nuts 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 linking 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 stuff 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, though 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 Inline::Go 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 ["Leaving"] 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 land 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 memory 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@91.200.158.34] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 20:14 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 20:19 -!- djbrown [~djbrown@h236n2-g-va-a12.ias.bredband.telia.com] has joined #go-nuts 20:25 -!- foocraft [~dsc@89.211.254.177] 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 process. 20:52 < steven> ie, a file with stdin/stdout, which you communicate with.. sorta.. 20:52 < steven> granted thats very limited compared to using genuine c bindings 20:58 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has quit [Quit: Leaving] 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@92.16.113.213] has joined #go-nuts 21:39 -!- wrtp [~rog@92.16.113.213] 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: Leaving.] 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@91.200.158.34] 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 #go-nuts 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.46.176.48.140] has joined #go-nuts 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.46.176.48.140] has left #go-nuts [] 22:53 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit: Verlassend] 22:54 -!- imsplitbit [~imsplitbi@64.39.4.132] 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 Fish] 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 seconds] 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 defaulthttpmux 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 perhaps 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 connection] 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