--- Log opened Sun Mar 06 00:00:55 2011 00:17 -!- tarrant [~tarrant@69.169.141.202.provo.static.broadweavenetworks.net] has joined #go-nuts 00:22 -!- chomp [~ken@c-71-206-216-232.hsd1.pa.comcast.net] has quit [Quit: Leaving] 00:27 -!- photron [~photron@port-92-201-10-205.dynamic.qsc.de] has quit [Read error: Operation timed out] 00:31 -!- dshep [~dshep@24.130.32.125] has joined #go-nuts 00:37 -!- dshep [~dshep@24.130.32.125] has quit [Quit: dshep] 00:41 -!- dshep [~dshep@24.130.32.125] has joined #go-nuts 00:58 -!- tarrant [~tarrant@69.169.141.202.provo.static.broadweavenetworks.net] has quit [Quit: Leaving...] 01:07 -!- tarrant [~tarrant@69.169.141.202.provo.static.broadweavenetworks.net] has joined #go-nuts 01:07 -!- tvw [~tv@e176001205.adsl.alicedsl.de] has quit [Ping timeout: 255 seconds] 01:08 -!- tvw [~tv@e176000087.adsl.alicedsl.de] has joined #go-nuts 01:30 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has quit [Remote host closed the connection] 01:46 -!- foocraft [~dsc@78.100.210.180] has quit [Quit: Leaving] 01:55 -!- vinisterx [~ryan@74-129-201-27.dhcp.insightbb.com] has quit [Read error: Operation timed out] 02:05 -!- dshep [~dshep@24.130.32.125] has quit [Quit: dshep] 02:06 -!- tvw [~tv@e176000087.adsl.alicedsl.de] has quit [Remote host closed the connection] 02:11 < tarrant> What's the best way to convert a u_char array to a Gostring in cgo? 02:11 < steven> woot i wrote a channel-based fibonacci sequence :D 02:11 * steven dances 02:11 < steven> it was inspired by the fact that go's channels can be used very similarly to python's yield 02:12 -!- tarrant [~tarrant@69.169.141.202.provo.static.broadweavenetworks.net] has quit [Quit: Linkinus - http://linkinus.com] 02:15 < steven> guys, 02:16 < steven> am i correct in understanding that a select with only one case statement and no default statement is the same as just that case statement by itself (whether its a send or receive operation)? 02:16 -!- shvntr [~shvntr@113.84.151.19] has joined #go-nuts 02:23 -!- boscop [~boscop@f050135026.adsl.alicedsl.de] has quit [Ping timeout: 255 seconds] 02:29 < |Craig|> steven: I believe that is the case 02:37 <@adg> steven: yes this is true 02:41 < steven> wow, i just read the semaphre example in effective_go, for the first time, and i actually understood it. its really fricken cool stuff!! 02:42 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has quit [Ping timeout: 276 seconds] 02:44 < steven> does Go's concurrency abilities make it possible for a single Go process to replace a cluster of rails mongrels (assuming the processes are comparable)? 02:44 < steven> or am i misunderstanding something here? 02:54 -!- frewsxcv [~frewsxcv@109.169.57.37] has joined #go-nuts 02:54 -!- frewsxcv [~frewsxcv@109.169.57.37] has quit [Changing host] 02:54 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has joined #go-nuts 03:06 -!- foocraft [~dsc@dyn-86-36-42-96.wv.qatar.cmu.edu] has joined #go-nuts 03:20 <@adg> steven: probably 03:21 <@adg> serving http doesn't require much. a lot of web servers and frameworks are over the top 03:28 < steven> ok. 03:28 < steven> GUYS! 03:28 < steven> i figured out my problem!! 03:29 < steven> i already have a goroutine sending "ch <- value" and *afterwards*, i "close(ch)" outside that goroutine. 03:29 < steven> which causes the panic "runtime error: send on closed channel" 03:29 < steven> so im wondering, "what the crap?" 03:31 < steven> heres a good example: https://gist.github.com/857003 03:32 < exch_> the routine ding the sending should be responsible for closing :) 03:32 < steven> ooh. i didnt know that. 03:32 < steven> so that goroutine should listen in on some kind of "wantsQuit" chan, and close when appropriate? 03:33 < exch_> i'm also not sure why you have the channel write in a select statement 03:33 < steven> oh that was an experiment. 03:33 < exch_> select is used to poll channels for available data to read 03:33 < steven> sorry. 03:33 < exch_> np, just saying 03:34 < steven> ty 03:34 < steven> where did you get the idea that only the goroutine sending to a chan is resopnsible for closing it? 03:34 < steven> is that somewhere in the effective go docs or something? 03:35 < |Craig|> steven: because nothing else is safe 03:35 < steven> oh. for the reason i just found out? 03:35 < steven> *discovered 03:35 < |Craig|> if you close it any other way, you might close while sending, or close in 2 places at once, both of which are bad 03:35 < exch_> you get race conditions if something other than the writer closes the channel 03:36 < exch_> brb 03:36 -!- exch_ [~exch@h78233.upc-h.chello.nl] has quit [Quit: leaving] 03:36 < |Craig|> in your code, close does not happen after the send (see happens after in the spec) 03:36 -!- exch [~exch@h78233.upc-h.chello.nl] has joined #go-nuts 03:37 < steven> ah. thanks guys.. 03:37 < fzzbt> how do i get max value of uint64 type? in C there's INT_MAX etc. for int type in limits.h.. how in go? 03:37 < |Craig|> hum, thats not in the spec, I wonder where I read about that stuff.. 03:37 < fzzbt> or any type for that matter 03:38 < |Craig|> fzzbt: 2<<64-1, but there are constants somewhere 03:39 < |Craig|> fzzbt: http://golang.org/pkg/math/ 03:40 < exch> 1<<64-1 :) 03:40 < |Craig|> MaxUint64 = 1<<64 - 1 (I was wrong...) 03:40 < fzzbt> oh math.. 03:40 < |Craig|> 2**64, 1<<64. Silly me.... 03:43 < steven> this *seems* to work, but the channels are reported as not-closed.. probably because by the time main() is finished, the goroutine never executes. 03:44 < steven> so is there a better way to test this concept? https://gist.github.com/857003 03:47 < steven> ooh wait, no. its happening because i didnt retreive the 0-value for both channels after closing them. 03:48 < |Craig|> steven: the break is not needed, though if you want clarity, you can put a return there 03:48 < steven> oh good point. 03:49 < steven> i put it in there forgetting its not inside a for{} 03:49 < |Craig|> steven: also, if you just need to send a message to say you are done, you can skip the send, and just close the chan and it will produce 0 values 03:49 < steven> and i would generally put break instead of return in case any final actions would need to be taken, they can be put after the for{}, instead of being litered and duplicated inside the select/for loops 03:50 < steven> hmm good point. 03:50 < steven> but crap, i just realized, 03:50 < |Craig|> steven: also, using a for x:=range(chan) is really nice. Sucks items out until closed 03:50 < steven> this means i need to have a companion is-quitting-channel for every goroutine (with its own incoming channel) whom i may want to kill in the future 03:50 < steven> since a sender-goroutine cannot have any other way of knowing that some external force wants it to die to death. 03:51 < steven> |Craig|: oh sweet i didnt know range was a function too, thoguht it was just a for clause 03:51 < |Craig|> things you want to kill all at once can all be provided the sam kill chan 03:51 < |Craig|> *smae 03:51 < |Craig|> *same. I can't type aparently 03:52 < |Craig|> range is just a for clause, but you can use it to loop over channel contents 03:52 < steven> i would just check closed(killchan) at some point in every goroutine? 03:53 < |Craig|> steven: that or if you have a select that tends to block, give it a case in there 03:54 < steven> but, if i did something like case <- killchan, wont only one of the goroutines be able to receive a 0-value if i do clos(killchan) externally? 03:54 < steven> or does it send that final 0-value to all receiving expressions in existence? 03:54 < |Craig|> closed channels produce infinate o values 03:54 < steven> awesome! this is sweet! 03:55 < exch> for some reason closed(ch) always returns false, even after it has explicitely been closed 03:55 < |Craig|> I generally detect closing with for loops over channels, or selects. 03:55 < exch> http://pastie.org/1638220 03:55 < steven> exch: nope 03:56 < steven> here's why: 03:56 < steven> https://gist.github.com/857003 03:56 < steven> i thought that same thing 15 mins ago exch and was confused. but it turns out you need to receive from it one last time first. 03:57 < exch> weird. i never ran into that before 03:57 < steven> "After at least one such zero value has been received, closed(c) returns true." 03:57 < steven> yeah i only found out about it by accident and found that in the spec. 03:57 < exch> prolly cos I poll for reads in a loop 03:57 < steven> right, dito 03:57 < |Craig|> if you just say close, that won't sync with the other go routine, the close may happen much later 03:57 < exch> ah well. closed(c) will soon be gone 03:58 < steven> now i think im armed with (almost?) enough understanding to finally write this little bot in an idiomatic way that *doesnt* suck horribly and leak channels and cause race conditions etc 03:58 < steven> exch: why will closed() soon be gone? 03:58 < |Craig|> closed is a bad idea. If closed is false, you can't trust it because it might close before the next instruction> its only useful if its true 03:58 < exch> because if these confusions and race conditions it can cause 03:58 < steven> oh touche 03:58 < steven> ok ill try to write my stuff without closed() 03:58 < exch> it will be replaced with: v, ok := <-ch; ok will be false if the chan is closed 03:59 < |Craig|> if you say "if !closed(x) {x<-1}" you will have an issue. 03:59 < steven> but closed() isnt necessary anyway, considering you can just receive on a killchan to know when you're supposta die 03:59 < steven> exch: i saw that trick on stackoverflow earlier, but i couldnt find anything about it on golang.org (only relating to maps) 04:00 < steven> |Craig|: which i in fact did, earlier, for a while. 04:00 < steven> yay for knowledge! 04:00 < steven> we're so blessed :) 04:01 < exch> the v, ok := construct is used to check of mapkeys exist. it's also used to validate type assertions 04:01 < exch> as in: n, ok := v.(int); to see if v is an int or not 04:01 < skelterjohn> non stop language tutorial party this weekend 04:02 < skelterjohn> i like it 04:02 < steven> haha 04:02 < steven> <3 04:05 < steven> i finally have a solid example of how to kill a goroutine (which i could not figure out earlier).. 04:05 < steven> https://gist.github.com/857003 04:06 < steven> at least i hope its solid.. maybe its still not, but it seems to pass my (trivial) test. 04:06 < steven> select/goroutines/channels completely confused the heck out of me last time i tried to learn go. now i realize why go wasnt that fun, because without these things its just another language with nothing too special.. this is what makes it fun and special :) 04:08 < exch> they certainly make life easier in some situations 04:09 < skelterjohn> i like it because you can get right to work and not have to build up structure in order to do interesting things 04:09 < steven> right on. 04:09 < steven> my first goal is to build a solid, robust irc client (for a bot, probably) 04:09 < skelterjohn> though certainly the concurrency support is what drew me in the first place 04:09 < exch> yes, the lack of boilerplate is definitely a welcome change from C# 04:10 * steven comes from ObjC and lately some Ruby too 04:10 < exch> Go just gets shit done. 04:10 < skelterjohn> i've fooled around with ObjC for ios dev 04:10 < steven> yeah its alright, not as fun as Go but better than C++ 04:11 < skelterjohn> i thought it was a bit weird, tbh 04:11 < skelterjohn> i liked the ios memory management trick 04:11 < skelterjohn> but that is not an ObjC feature 04:12 < steven> heh 04:13 < |Craig|> I never did figure out why I get eternal handshakes. Anyone here know anything about tls? 04:13 < steven> not i, sorry 04:14 < exch> nope, sorry 04:14 < skelterjohn> is the handshake part of an existing protocol? 04:14 < skelterjohn> oh, i suppose tls is a protocol 04:14 < |Craig|> I've got python+twisted client side, and go+tls server side. No errors, but I can't sent anything because the handshake call never returns 04:14 < skelterjohn> why not put a sniffer on the stream and see what data is actually flying around? 04:15 < |Craig|> because debugging tls handshakes with a packetsniffer is not easy... 04:15 < skelterjohn> ok :) i've never heard of tls 04:15 < |Craig|> both client and server are on the same computer using the same certificate file 04:15 < skelterjohn> if you use a client in another language does it work ok? 04:15 < |Craig|> skelterjohn: how about ssl, heard of that? 04:16 < skelterjohn> yes, i've heard of ssl 04:16 < skelterjohn> i don't know much more than 'secure socket layer' 04:16 -!- rejb [~rejb@unaffiliated/rejb] has quit [Ping timeout: 246 seconds] 04:17 < |Craig|> its like the new SSL, though technically I think I'm falling back to SSL 04:18 < |Craig|> tsl 1.0 = SSL 3.1 aparently 04:18 < |Craig|> I don't know why they went with a new name 04:35 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has quit [Ping timeout: 246 seconds] 04:50 -!- iant [~iant@216.239.45.130] has quit [Ping timeout: 276 seconds] 04:52 -!- pearle [~pearle@blk-224-181-222.eastlink.ca] has quit [Quit: Leaving] 04:54 < steven> where does the return value if a goroutine's function go? is it possible to retreive, ever? 04:54 < steven> or is it discarded every single time? 04:55 < cbeck> discarded 04:56 < steven> k. 04:56 < steven> thanks 04:57 -!- foocraft [~dsc@dyn-86-36-42-96.wv.qatar.cmu.edu] has quit [Ping timeout: 252 seconds] 04:57 -!- vsayer [~vivek@c-76-102-205-58.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds] 05:02 < steven> this is both simpler and harder than i thought.. 05:03 < steven> its one thing to tell all the goroutines they need to be quit by giving them a chan to listen to, and when it receives, they know to die. 05:04 -!- foocraft [~dsc@dyn-86-36-42-96.wv.qatar.cmu.edu] has joined #go-nuts 05:04 < steven> but now i need to find a way to allow each goroutine to tell the main loop+select that it specifically wants the whole thing to quit, ie triggering the aforementioned cascade of goroutine-death 05:05 < steven> so it looks like i need to give each goroutine its own individual "wanna quit?" channel, and listen for every one of them in the main loop, to know when to quit. 05:05 < steven> is there a better solution than this? 05:07 < exch> http://jan.newmarch.name/go/index.html 05:07 < steven> whoaaaa 05:08 < exch> just saw that posted on hackernews 05:08 < steven> i doubt ill be able to understand this kinda stuff :) 05:08 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has joined #go-nuts 05:08 -!- mode/#go-nuts [+v iant] by ChanServ 05:08 < steven> im not all academic and whatnot. 05:09 < steven> oh sorry, i guess you werent responding to me so much as you were just saying it. 05:09 < steven> my mistaken. 05:09 < exch> hehe ya, just posted it for relevancy 05:11 < exch> it seems to provide a fair amount of rudimentary network theory which may come in handy at some point 05:11 < steven> :) 05:11 < steven> i wonder, does a still-open channel qualify for garbage collection if nobody has a refernce to it anymore? 05:12 < steven> (ie, nobody is sending/receiving/referencing it) 05:12 < steven> or must it be closed first? 05:12 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Remote host closed the connection] 05:12 < exch> if there are no rederences to it, it should be marked for cleanup afaik 05:12 < exch> *references 05:14 < steven> k. cuz im thinking that a better solution to this problem might involve giving every (relevant) goroutine a write-only channel allowing them each to write to it when they want to signal that its quittin time, only listening in one central spot, and never close it. 05:14 < steven> but i feel kinda nervous about having a channel that i never close, it seems like an unclean, un-balanced thing to do 05:14 < steven> what are your thoughts on this, guys? :) 05:16 < exch> If there is no way to do it cleanly, you probably need to rethink your code layout. having said that, we have a garbage collector for a reason. Your computer won't explode if you dont close it 05:16 < exch> I for one do prefer to clean up the mess I made though, but that's just me 05:17 < steven> ditto 05:18 < steven> but which would you prefer, to have a write-only chan that you pass around to every goroutine and never close, or individual write-close channels per goroutine? 05:19 < exch> one channel that is passed to the goroutines. The goroutines should not be responsible for closing it though, cos another ruotine may still be writing to it 05:19 < exch> the routine which created the channel should close it after all goroutines have finished doing their stuff 05:20 < exch> I can see how that is tricky though. How do you know when that has happened if they cant send some signal 05:20 < steven> hmm, this forces me to think about something i was just ignoring 05:20 -!- frewsxcv [~frewsxcv@109.169.57.37] has joined #go-nuts 05:20 -!- frewsxcv [~frewsxcv@109.169.57.37] has quit [Changing host] 05:20 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has joined #go-nuts 05:22 < steven> i guess they might not all want to write to it, since its optional. so its hard to know whens the right time to close it. 05:22 < steven> but i dont like thinking my goroutines have so much freedom that i never know what they're doing or what state they're in.. so perhaps i should know. 05:24 < steven> whoa, this is a weird problem i just ran into.. 05:25 < steven> i have a select that is only receiving from 2 channels, one was close()'d and one has not yet been written to at all. but the select seems to wait until the second one writes, and accepts that, instead of noticing the close()'d one! 05:25 < steven> im guessing whoever told me that close() just sends an endless supply of 0-values was mistaken, or maybe i just misunderstood. 05:26 < steven> oh no, the spec confirms this. 05:26 < steven> ugh. im confused. 05:28 < Namegduf> steven: Closed channels generally stop being read from by automatic stuff. 05:29 < Namegduf> range will stop once they are closed, and I suspect select will, too. 05:29 < steven> so they dont get notified simultaneously in all concurrent selects in all existing goroutines that are trying to receive from it? 05:30 < steven> crap. i was relying on the fact that select would continue to receive from it, in my entire design. crap. 05:30 < steven> back to square one. 05:30 < Namegduf> You can send a zero value. 05:30 < Namegduf> Although the problem of multiple readers exists. 05:30 < steven> i almost had something that worked, too.. https://gist.github.com/857055 05:31 < exch> http://pastie.org/1638405 this seems to work fine. 3 writers and one reader. 05:31 < exch> not sure if that covers your issues though 05:32 < exch> not sure if the closing is what kills the goroutines or the fact that main returns though. lemme test 05:33 < steven> add select{} to the end :) 05:33 < exch> mm nope. the close() is never registered with the workers in that sample 05:34 < steven> well one thing i can deduce is that the next select statement of mine, *does* properly notice that the channel is closed, and receive a 0 value because of it. 05:34 < steven> its just that the *current* one does not. 05:35 < steven> man i suck at english. 05:35 < exch> with a select{} at the end of main, the workers throw a panic because they attempt to write to a closed channel. 05:35 < exch> this is why closed() sucks 05:36 < steven> so what this seems to say is that if you close a chan, its not necessarily sent immediately to all receiving operations, but its sent.. sometime? 05:36 < steven> i dont get it. 05:36 < steven> OOOH 05:37 < steven> maybe this has to do with the fact that in select, the expression is evaluated only once. 05:37 < exch> a close() sends a nil value to the channel. but a goroutined trying to write to the chan is in a blocking call waiting for a spot to open up for it to write. it never registers the nil/close 05:39 < steven> "If multiple cases can proceed, a pseudo-random fair choice is made to decide which single communication will execute." -- shouldnt they just do "the topmost will proceed"? 05:40 < exch> Now I see why you had a send in a select statement. It seems some of the behaviour has recently changed. You used to be able to do: ok := ch <- 1; this would do a non-blocking send and ok would be true if it succeeded. This is now illegal 05:40 < steven> oh. i had no idea about that. 05:40 < exch> compiler now complains about that: test.go:11: send statement out <- i used as value; use select for non-blocking send 05:40 < exch> learn something new every day :p 05:40 < steven> no, thats not why i do that 05:41 < steven> i do it because the receiver (the main loop) may not be ready for the sending of the string data just yet, but in the meantime the main loop may have signalled that the goroutine should kill itself 05:41 < steven> so it puts the send string and the listen for quit message both in a select in hopes that it will know what to do. 05:42 < steven> it does, just not at the timing i expected. 05:42 < steven> *with the? 05:42 < exch> mm It would be handy if you had some measure of control over which case would run first then 05:43 < steven> right. at least thats my guess as to the behavior im seeing. 05:46 < steven> changing it to use one-signal-chan-per-goroutine solves this problem it seems. 05:48 < steven> so this horrible nightmare is what i ended up with, for the simplest of cases: https://gist.github.com/857055 05:49 -!- segy_ [~segfault@pdpc/supporter/active/segy] has joined #go-nuts 05:50 < steven> the things i dont like about it are (1) it has one "you need to die" signalling channel per input-fetching-goroutine, and (2) it has select statements up the wazoo in a way that i cant think of minimizing 05:52 < steven> i guess the second point isnt so bad, its just 2-per-goroutine when i would prefer 1.. the first handles the blocking data-fetching call (while listening for a quit), and the second handles the blocking sending-data operation (while listening for a quit) 05:52 -!- segy [~segfault@pdpc/supporter/active/segy] has quit [Ping timeout: 276 seconds] 05:52 < steven> cant think of a way to reduce that any further. 05:52 < steven> not without having less control over the lifetime of these goroutines, at least. 06:08 < exch> ?permt outrageouslylongandconvultedwordwithcakeandcoffee 06:08 < exch> oops 06:08 < exch> wrong chan 06:15 < exch> the bignum package is excellent for doing word/character permutations <3 06:33 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has joined #go-nuts 06:47 < |Craig|> steven: defer the calls you make after the loop, then you can remove the label and break, and just return 06:49 < |Craig|> my go routine killer tents to be a single "halt <-chan int" that I close to kill, and return when I pull a value from it in a select. If something is eating a stream of values on a channel, just use a for loop on the channel, and it will automatically fall through when its input chan is closed. 06:53 -!- perdiy [~mkhl@sxemacs/devel/perdix] has joined #go-nuts 06:54 -!- vsayer [~vivek@c-76-102-205-58.hsd1.ca.comcast.net] has joined #go-nuts 06:55 -!- perdix [~mkhl@sxemacs/devel/perdix] has quit [Ping timeout: 276 seconds] 07:03 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has joined #go-nuts 07:15 -!- photron [~photron@port-92-201-10-205.dynamic.qsc.de] has joined #go-nuts 07:18 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts 07:26 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has joined #go-nuts 07:28 -!- nettok [~quassel@200.119.175.24] has quit [Ping timeout: 264 seconds] 07:31 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Remote host closed the connection] 07:37 -!- tav [~tav@92.7.131.230] has quit [Read error: Connection reset by peer] 07:38 -!- Natch| [~natch@c-6dcde155.25-4-64736c10.cust.bredbandsbolaget.se] has quit [Ping timeout: 250 seconds] 07:38 -!- piranha [~piranha@5ED4B890.cm-7-5c.dynamic.ziggo.nl] has joined #go-nuts 07:39 -!- visof [~visof@41.233.109.100] has joined #go-nuts 07:39 -!- visof [~visof@41.233.109.100] has quit [Changing host] 07:39 -!- visof [~visof@unaffiliated/visof] has joined #go-nuts 07:46 -!- Natch| [~natch@c-6dcde155.25-4-64736c10.cust.bredbandsbolaget.se] has joined #go-nuts 07:54 -!- ymasory [~ymasory@c-76-99-55-224.hsd1.pa.comcast.net] has quit [Remote host closed the connection] 08:13 -!- piranha [~piranha@5ED4B890.cm-7-5c.dynamic.ziggo.nl] has quit [Quit: Computer has gone to sleep.] 08:15 -!- xulfer [~xulfer@cheapbsd.net] has joined #go-nuts 08:16 -!- tav [~tav@92.7.131.230] has joined #go-nuts 08:16 -!- karpar [~karpar@112.96.224.13] has joined #go-nuts 08:18 -!- karpar [~karpar@112.96.224.13] has quit [Client Quit] 08:19 -!- karpar [~karpar@112.96.224.13] has joined #go-nuts 08:21 -!- napsy [~luka@tm.213.143.73.175.lc.telemach.net] has joined #go-nuts 08:24 -!- pjm0616 [~user@sigfpe-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [Ping timeout: 260 seconds] 08:25 -!- karpar [~karpar@112.96.224.13] has quit [Ping timeout: 240 seconds] 08:28 -!- kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [Ping timeout: 260 seconds] 08:30 -!- Project_2501 [~Marvin@82.84.99.90] has joined #go-nuts 08:31 -!- karpar [~karpar@112.96.255.7] has joined #go-nuts 08:36 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts 08:41 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|] 08:46 -!- saturnfive [~saturnfiv@219.144.192.73] has joined #go-nuts 08:47 -!- saturnfive [~saturnfiv@219.144.192.73] has left #go-nuts [] 08:53 -!- karpar [~karpar@112.96.255.7] has quit [Ping timeout: 276 seconds] 09:08 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 09:15 -!- pjm0616 [~user@sigfpe-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined #go-nuts 09:20 -!- tensorpudding [~user@99.56.160.152] has quit [Remote host closed the connection] 09:33 -!- femtooo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts 09:36 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Ping timeout: 255 seconds] 09:37 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts 09:39 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts 09:40 -!- femtooo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Ping timeout: 255 seconds] 09:41 -!- edsrzf [~kelvan@122-61-221-144.jetstream.xtra.co.nz] has quit [Ping timeout: 252 seconds] 09:44 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Ping timeout: 260 seconds] 09:50 -!- ShadowIce [~pyoro@HSI-KBW-109-193-120-162.hsi7.kabel-badenwuerttemberg.de] has joined #go-nuts 09:50 -!- ShadowIce [~pyoro@HSI-KBW-109-193-120-162.hsi7.kabel-badenwuerttemberg.de] has quit [Changing host] 09:50 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts 10:02 -!- aconran [~aconran-o@38.104.129.126] has quit [Remote host closed the connection] 10:02 -!- femtooo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts 10:05 -!- aconran [~aconran-o@38.104.129.126] has joined #go-nuts 10:05 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Ping timeout: 246 seconds] 10:07 -!- nickbp [~eqoaq@216.93.241.7.askonline.net] has quit [Ping timeout: 276 seconds] 10:15 -!- nickbp [~eqoaq@216.93.241.7.askonline.net] has joined #go-nuts 10:19 -!- espeed [~espeed@63.246.231.57] has joined #go-nuts 10:20 -!- nickbp [~eqoaq@216.93.241.7.askonline.net] has quit [Ping timeout: 260 seconds] 10:22 -!- aconran [~aconran-o@38.104.129.126] has quit [Remote host closed the connection] 10:23 -!- aconran [~aconran-o@38.104.129.126] has joined #go-nuts 10:26 -!- GoBIR [~gobir@c-24-130-224-186.hsd1.ca.comcast.net] has quit [Ping timeout: 252 seconds] 10:30 -!- GoBIR [~gobir@c-24-130-224-186.hsd1.ca.comcast.net] has joined #go-nuts 10:34 -!- aconran [~aconran-o@38.104.129.126] has quit [Ping timeout: 276 seconds] 10:36 -!- nickbp [~eqoaq@216.93.241.7.askonline.net] has joined #go-nuts 10:49 -!- DerHorst [~Horst@e176102247.adsl.alicedsl.de] has joined #go-nuts 10:51 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts 10:54 -!- kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined #go-nuts 11:03 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Ping timeout: 276 seconds] 11:36 -!- visof_ [~visof@41.233.115.81] has joined #go-nuts 11:37 -!- visof__ [~visof@41.233.113.242] has joined #go-nuts 11:39 -!- saschpe [~quassel@opensuse/member/saschpe] has joined #go-nuts 11:39 -!- visof [~visof@unaffiliated/visof] has quit [Ping timeout: 248 seconds] 11:40 -!- Project_2501 [~Marvin@82.84.99.90] has quit [Quit: E se abbasso questa leva che succ...] 11:40 -!- visof_ [~visof@41.233.115.81] has quit [Ping timeout: 250 seconds] 11:48 < nsf> hm.. it's funny but I've never thought about bitwise operator precedence until now 11:48 < nsf> operators* 11:49 < nsf> and it turns out that in C it's a bit broken :) 11:49 < zozoR> isnt C broken? :D 11:49 < nsf> comparison operators have higher precedence than bitwise ops 11:49 < nsf> things like: x&mask == 0 won't work 11:50 < zozoR> (x&mask) == 0? 11:50 < nsf> (x&mask) == 0 should be written instead 11:50 < nsf> yes 11:50 < nsf> in Go it works 11:50 < zozoR> well, C is weird 11:50 < nsf> a little bit, yes 11:50 < zozoR> aiju said the other day "in soviet C namespace pollutes you" 11:51 < zozoR> i am the honored owner of a t-shirt that says that now :D 11:51 < zozoR> unfortunatly, nobody gets the joke : | 11:51 < nsf> I'm afraid in soviet russia we're using pascal instead 11:51 < nsf> :D 11:51 < zozoR> :D 11:52 < nsf> I think eastern europe is the only place where teachers still teach pascal in schools 11:53 < zozoR> they should teach go 11:54 < nsf> maybe, I don't have opinion on that 11:55 < nsf> pascal isn't the worst choice btw 11:55 < nsf> it's better than java 11:56 < zozoR> well, i only hear people bash java all the time 11:56 < nsf> :D 11:57 < nsf> and C++, I hate C++ 11:57 * nsf is writing a parser in C++ right now 11:57 < nsf> I hate it and I use it 11:57 < nsf> :D 11:59 < zozoR> i feel hate for C++ too 11:59 < zozoR> dont know why though 11:59 < Namegduf> C++ is extremely complex. 11:59 < Namegduf> It's basically C plus all the features. 11:59 < Namegduf> All of them. 11:59 < nsf> :) 12:00 < Namegduf> So you have the fun of manually writing low-level code with the fun of a very complex language. 12:05 < nsf> C is the "programmer is always right", C++ is the "compiler is always right".. and what you do as a programmer is standing in the middle of this fight 12:06 < xyproto> I'm trying out goinstall for the first time. How can I install, for example Go-SDL with it? I can't seem to make it work. 12:06 < nsf> and by C++ here I mean everything that was added on top of C 12:07 < xyproto> I just get: goinstall: github.com/banthar/Go-SDL: package has no files 12:10 -!- karpar [~karpar@112.96.255.5] has joined #go-nuts 12:12 < nsf> xyproto: goinstall may not work with all packages 12:12 < nsf> it's a hack basically 12:12 < nsf> a try to make a smart build system 12:12 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 252 seconds] 12:13 < nsf> apparently not a very smart idea 12:13 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 12:15 -!- napsy [~luka@tm.213.143.73.175.lc.telemach.net] has quit [Ping timeout: 260 seconds] 12:16 < zozoR> nsf, why does people hate java? 12:17 < nsf> I don't know... I don't know java 12:17 < nsf> :) 12:17 < nsf> I guess for its oververbosity 12:17 < nsf> public static final int wtf(); 12:17 < nsf> srsly? 12:18 -!- photron [~photron@port-92-201-10-205.dynamic.qsc.de] has quit [Read error: Operation timed out] 12:18 < nsf> C# is the same idea 12:18 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has quit [Ping timeout: 276 seconds] 12:18 < zozoR> ^^ 12:19 < zozoR> well, C# is supposed to be written with visual studio. ie. drag and drop code 12:19 -!- aho [~nya@fuld-590c7e54.pool.mediaWays.net] has quit [Quit: EXEC_over.METHOD_SUBLIMATION] 12:19 < zozoR> visual studio writes all the public static final function for you, so you only need to write actual code 12:21 < zozoR> i dont like programs that writes my code : ( 12:22 < nsf> yeah 12:22 < nsf> I've seen a bunch of screencasts about C# and VS 12:22 < nsf> it looks weird really 12:23 < zozoR> well, you can make a lot of code fast 12:23 < nsf> a lot of buggy code 12:23 < zozoR> partial class.. yuck -.- 12:24 -!- yebyen [~yebyen@martyfunkhouser.csh.rit.edu] has quit [Ping timeout: 255 seconds] 12:24 < zozoR> we are taught java on our universities (unless you are to study software) 12:25 < nsf> yep, I'm aware of that 12:25 < nsf> bad for you 12:25 -!- yebyen [~yebyen@martyfunkhouser.csh.rit.edu] has joined #go-nuts 12:26 < zozoR> i once read about a place where they could chose whatever langauge they wanted 12:26 < nsf> heaven? :) 12:26 < zozoR> nope xD 12:26 < nsf> lol 12:26 < zozoR> maybe it was just the assignment, but they had to make an http server 12:26 < zozoR> they could only get help if they used java 12:27 < zozoR> one guy chose python, write "import simplehttpserver" and "simplehttpserver.start()" or something 12:27 < zozoR> im pretty sure that there is a python lib for that 12:27 < nsf> :) 12:27 < zozoR> and that is why you are not allowed to use whatever language you want :D 12:28 < aiju> hahahahaahahaha 12:28 < aiju> there is no such thing as a simple HTTP server 12:28 < aiju> HTTP is fucking insane 12:29 < aiju> [12:55:12] <nsf> I think eastern europe is the only place where teachers still teach pascal in schools 12:29 < aiju> germany is part of eastern europe? 12:29 < zozoR> yea 12:29 < nsf> aiju: I don't think so 12:30 < zozoR> soviet germany 12:30 < aiju> i've been taught Pascal in school 12:30 < nsf> let me check out the map :) 12:30 < aiju> and i'm not an exception 12:30 < nsf> "Germany is a country in Western and Central Europe." 12:30 < aiju> Basic, Pascal, Prolog, Java, Assembler, C are the languages classically taught at german schools 12:30 < nsf> wiki says it's not 12:31 < aiju> (in decreasing order) 12:31 < nsf> aiju: well, good then, I was wrong about eastern europe only 12:31 < aiju> 13:29 < zozoR> [12:53:29] i am the honored owner of a t-shirt that says that now :D 12:31 < aiju> hahahahhaahaahahha awesome 12:32 < zozoR> you wont believe how many just stares at my t-shirt for fifteen seconds, then go "what" xD 12:32 < aiju> C's precedence rules are a relict of B btw 12:34 < mpl> for the record, they still teach pascal in some unis here as well (.fr). 12:34 < aiju> in some unis? oh wow 12:34 < aiju> german unis only teach Java and C 12:34 < aiju> i've been talking about high schools 12:35 < aiju> (and functional languages like Scheme ofc) 12:35 < mpl> ah, we don't have any cs courses in high school that I know of. 12:35 < xyproto> they tought Pascal/Delphi at unis here in Norway up until around 5 years ago 12:35 < aiju> i find it amazing that Prolog made it into the curriculum 12:35 -!- frewsxcv [~frewsxcv@109.169.57.37] has joined #go-nuts 12:35 -!- frewsxcv [~frewsxcv@109.169.57.37] has quit [Changing host] 12:35 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has joined #go-nuts 12:37 < xyproto> I want to write a small game in Go. Like Tetris or Digger. Where to start? 12:38 < xyproto> What would you use for graphics? HTML5+canvas+Go backend? SDL? OpenGL? 12:38 < zozoR> ncurses! :D 12:38 < nsf> https://github.com/nsf/gotris 12:38 < nsf> fix that one 12:38 < xyproto> as much as I like ncurses... ;) 12:38 < aiju> ncurses is a shame 12:38 < mpl> when I was applying for one of these masters where they were mainly using pascal as a teaching language, I asked them at the interview why they were not using a "useful for real life" language like C. maybe that's why I didn't get accepted :) 12:38 < xyproto> nfs: I'll take a look 12:38 < aiju> ncurses had a point when we all used VT100 to connect to our mainframe 12:39 < nsf> xyproto: it's broken because of language changes, I'm not maintaining it 12:39 < xyproto> ncurses works everywhere, though. And the ncurses-interfaces are usually highly responsive. 12:39 < aiju> mpl: hahahahaha 12:39 < nsf> other than that it's fully functional tetris on SDL+OpenGL 12:39 < aiju> xyproto: it doesn't work on my trusty ASR-33 :( 12:39 < Urmel|> https://code.google.com/p/pokemon-universe/source/browse/#svn%2Ftrunk%2FPackages%2FSDL <- simple sdl 1.3 wrapper for great justice 12:39 < xyproto> aiju: I had to google it. It looks like a printer? 12:40 < Urmel|> although youll have to tweak it a bit for your own use 12:40 < aiju> xyproto: a hardcopy terminal 12:40 < aiju> basically a terminal with a typewriter for output 12:40 < aiju> used in the early days of UNIX 12:40 -!- boscop [~boscop@f050135026.adsl.alicedsl.de] has joined #go-nuts 12:41 < zozoR> nsf, do you know if gosdl is fully functional? 12:41 < nsf> have no idea 12:43 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has joined #go-nuts 12:43 * aiju hopes that his emulator still works 12:43 < schmrkc> zozoR: What do you mean with "fully functional" here anyway? 12:43 < aiju> fuck, ofc not 12:43 < aiju> schmrkc: LISPy! 12:43 < zozoR> meaning you can use the library as much as you can use it from c++ or c 12:44 < aiju> you can use SDL, have i missed something? ;P 12:44 < aiju> w00t it still works 12:45 < schmrkc> zozoR: Not all of the SDL library is there, no. But any extra function that you find missing should be easy enough to add. 12:45 < schmrkc> zozoR: for example the joystick support is not there. 12:45 < aiju> http://phicode.de/git/?p=gb.git;a=summary btw 12:45 < zozoR> who uses joysticks for puters :D 12:46 < schmrkc> zozoR: I use my playstation gamepad all the time. 12:46 < schmrkc> zozoR: It is detected as a joystick device on looniks anyway. 12:46 < aiju> - c.F = FLAGZ 12:46 < aiju> + c.F |= FLAGZ 12:46 < aiju> that bug was really fun to find 12:46 < zozoR> oh 12:46 < schmrkc> aiju: haha :D 12:46 < aiju> schmrkc: esp. since c.F was 0 in 255/256 cases.... 12:47 < schmrkc> zozoR: I'm pretty sure there are some other functions with no go bindings yet.. but SDL is a very easy library, and even with my lack of Go knowledge I could make some bindings if they were missing. 12:48 < zozoR> true that 12:48 < schmrkc> then again I have written SDL libraries several times for other random languages ;) 12:48 < zozoR> ill play around with it later perhabs ^^ 12:48 < schmrkc> uh 12:48 < schmrkc> SDL bindings. 12:48 < schmrkc> yay. 12:48 < schmrkc> me too. 12:48 < schmrkc> I need it for my hello roguelike. 12:48 < zozoR> because it is time for homework to be done ^^ 12:48 < aiju> bleh SDL 12:49 < schmrkc> aiju: You no like the SDL? 12:49 < aiju> not really 12:49 < schmrkc> Is there some better alternative? 12:49 < aiju> no :( 12:49 < schmrkc> :D 12:49 < zozoR> -.- 12:49 < aiju> that's why I end up using it 12:50 < schmrkc> someone suggested allegro to me quite some time ago.. but it was troublesome. I forget what the issuew as. 12:50 < aiju> tho some of my programs use libdraw 12:51 < schmrkc> never herad of libdraw 12:51 < aiju> Plan 9 library 12:51 < schmrkc> oho. only for drawing I imagine? 12:51 < aiju> yeah 12:51 < aiju> i don't use SDL for audio et al 12:51 -!- yebyen [~yebyen@martyfunkhouser.csh.rit.edu] has quit [Ping timeout: 246 seconds] 12:52 < schmrkc> I'd think SDL was mainly used for drawing sprites and such anyhoo. 12:52 < schmrkc> perhaps libdraw does this too. 12:52 < aiju> libdraw has a blit function 12:52 < aiju> http://man.cat-v.org/plan_9/3/draw 12:52 < schmrkc> although it seems now SDL is mostly just used as a "backend" for getting some openGL context 12:52 < aiju> yuck wrong section 12:52 < aiju> http://man.cat-v.org/plan_9/2/draw 12:52 < aiju> i don't have too many opengl capable machines 12:53 * schmrkc nods nods. 12:53 < schmrkc> it is quite beneficial even for 2d games. 12:53 < aiju> yes 12:53 < aiju> i still don't have any machines for it 12:53 < aiju> well, i have ONE 12:53 < schmrkc> So plan9 eh? Useable as a "desktop" OS? 12:53 -!- yebyen [~yebyen@martyfunkhouser.csh.rit.edu] has joined #go-nuts 12:53 < aiju> depends what you do with your desktop 12:53 < schmrkc> really dumb question? :) 12:53 < schmrkc> right. 12:54 < schmrkc> run chrome, read mah mail. hack code. transfer stuff on and off my mp3player and digital camera. 12:54 < schmrkc> ssh and irssi ;) 12:54 < aiju> no multimedia, no real webbrowser (hm you can run Opera in linuxemu), no office suite 12:54 < schmrkc> ah right. 12:54 < aiju> chrome might work in linuxemu as well 12:54 < Urmel|> only SDL 1.2 is used as mainly a backend for an opengl context btw 12:54 < aiju> you can code C ;P 12:54 < schmrkc> Urmel|: oh ok. 12:54 < Urmel|> sdk 1.3 has it's own 2d renderer using opengl or directx (and some other stuff) 12:55 < schmrkc> aiju: Well I'll stay on the looniks then :) 12:55 < Urmel|> sdl* 12:55 < aiju> schmrkc: a Go port is coming ... 12:55 < schmrkc> Urmel|: Sounds cool. I'm going to check this out. Is there much change in the API? 12:55 < schmrkc> hmmm 12:55 < Urmel|> yeah a lot 12:55 < aiju> my PLan 9 machine is probably too slow for Go :D 12:55 < aiju> those frigging 2 MB binaries 12:56 < schmrkc> Urmel|: I think I remember some discussion about this in #lispgames. Some license change too is there? 12:56 < schmrkc> 2 MB! crazy! 12:56 < schmrkc> :D 12:56 -!- sauerbraten [~sauerbrat@p508C9E90.dip.t-dialin.net] has joined #go-nuts 12:56 < aiju> i only have 2 MB/s HD access on that machine 12:56 < Urmel|> schmrkc, well you can buy permission to statically link basically 12:56 < schmrkc> that sounds painful. 12:56 < schmrkc> Urmel|: oh ok. 12:56 < Urmel|> but dynamic linking is still free as always 12:56 < xyproto> When I compile the latest version of Go-SDL, with the latest version of Go (7647), the executable in the SDL-Go test-directory just says: zsh: permission denied: ./test 12:56 < aiju> SDL is LGPL? BLAH 12:56 < xyproto> What could be the reason? 12:56 < aiju> LGPL is the fucking worst 12:57 < schmrkc> Urmel|: I guess people just get their panties in a twist over nothing then. 12:57 < Urmel|> yup 12:57 < schmrkc> I find LLGPL quite ok. 12:57 < aiju> xyproto: no +x permission? 12:57 < aiju> LGPL is even worse than GPL per se 12:57 < aiju> as it puts dynamic linking over static linking 12:57 < Urmel|> the great thing about sdl 1.3 is that you use the same calls for both opengl and directx rendering and just easily switch between them 12:57 < xyproto> aiju: -rwxr-xr-x 12:57 < aiju> xyproto: dynamic linker stuff? 12:57 < schmrkc> aiju: GPL is very troublesome for lisp. (: 12:57 < aiju> xyproto: readelf foo | grep interpreter 12:58 < schmrkc> Urmel|: Sounds very nice indeed. 12:58 < xyproto> aiju: probably, but how do I figure that one out? ... I'll try readelf, thanks 12:58 < aiju> eh readelf -a 12:58 -!- ronny [~quassel@p4FF1C0D9.dip0.t-ipconnect.de] has joined #go-nuts 12:58 < xyproto> aiju: there's only one line for that: [Requesting program interpreter: ../gfx/_obj] 12:59 < aiju> yeah 12:59 < aiju> seems broken to me 12:59 < schmrkc> Urmel|: finding the 1.3 docs a bit lacking :D 12:59 < aiju> should be something like /lib/ld-linux.so.2 12:59 < xyproto> aiju: okay. Hm, I wonder why. Does gdb work with Go? 12:59 < aiju> xyproto: more or less 13:01 < Urmel|> yup that is true schmrkc 13:02 < xyproto> My goal is to make a small tetris or digger clone, but the OpenGL and SDL examples all fail. Perhaps ncurses really is the way to go. 13:02 < aiju> hahahaha 13:02 < aiju> i've got SDL working here 13:02 < aiju> that 0xf9-something SDL 13:03 < xyproto> aiju: do you have the latest version of Go? 13:03 -!- perdiy [~mkhl@sxemacs/devel/perdix] has quit [Remote host closed the connection] 13:03 < aiju> should be relatively new 13:03 < xyproto> aiju: some of the examples have worked sometimes here, after updating, but they never work all at the same time :) 13:03 < aiju> hahahah 13:05 < xyproto> I wish GPU-hardware were considered important enough to be supported directly from languages like Go and Python, not being delegated as special external packages. 13:05 < aiju> hahahahahahahahahaha 13:05 < aiju> i wish not 13:05 < aiju> GPUs are not CPUs 13:05 < aiju> they need a DSL 13:06 < xyproto> aiju: damn small linux? 13:06 < aiju> domain-specific language 13:06 < nsf> :) 13:06 < xyproto> aiju: digital subscriber line? 13:06 < xyproto> they are getting closer, though 13:06 < xyproto> with OpenCL and everything :P 13:06 < xyproto> okay, not closer to not needing a DSL 13:06 < aiju> i'd like to see an APL dialect for GPUs 13:06 < xyproto> but more suitable for general purpose computing 13:07 < aiju> last time i looked they looked *just* like APL hardware 13:08 < schmrkc> hmm.. 13:08 < schmrkc> GPU for general purpose computing? I dunno.. 13:08 < aiju> on a side note, i don't have GPGPU capable hardware 13:08 < aiju> y'all are just filthy rich bastards ;P 13:09 < schmrkc> yup. 13:10 < schmrkc> the low end nvidia cards are not that expensive :P 13:10 < schmrkc> It's sad really. all this fancy hardware and so much bloat. Life was better back in the days when one actually *used* the lil computing power one had :) 13:11 < aiju> i'm currently writing an OS for the 8086 for fun 13:11 < aiju> 640 KB of RAM yay! 13:11 < xyproto> aiju: I work for a company that specializes in utilizing GPUs for visualizing and converting seismic data. GPUs are a big deal. 13:12 < aiju> xyproto: i've only looked at opencl and didn't like it 13:12 -!- karpar [~karpar@112.96.255.5] has quit [Quit: Bye!] 13:13 < xyproto> aiju: perhaps CUDA is more likeable? But, OpenCL can fallback on the CPU, which is nice. 13:13 < schmrkc> aiju: fun hobby (: 13:14 < xyproto> aiju: remember to implement int 19h for reboots ;) 13:14 < aiju> it will have multitasking btw! 13:14 < aiju> just showing how much DOS sucks :> 13:15 < aiju> and that the suckage can't be explained by "the hardware wasn't good enough" 13:15 < xyproto> at least it was possible to make a tetris game without installing libraries... ;) 13:15 < aiju> heh 13:15 < xyproto> good old a000 13:16 < aiju> i actually wrote a tetris in assembly for DOS 13:16 -!- perdix [~mkhl@g227011248.adsl.alicedsl.de] has joined #go-nuts 13:16 < aiju> http://aiju.phicode.de/up/tetris.asm.txt 13:16 -!- perdix [~mkhl@g227011248.adsl.alicedsl.de] has quit [Changing host] 13:16 -!- perdix [~mkhl@sxemacs/devel/perdix] has joined #go-nuts 13:16 < xyproto> aiju: in mode 01, regular text mode? 13:17 < aiju> i think so 13:17 < aiju> look at the code :o) 13:17 < xyproto> aiju: just did. Just wondered why text mode :) 13:17 < aiju> well, it's simple 13:17 < xyproto> I have fond memories of 16-bit x86 assembly 13:18 < aiju> i need nothing but coloured tiles 13:18 < aiju> i don't like it too much 13:18 < aiju> it's terribly unorthogonal 13:18 < xyproto> true 13:18 < aiju> PDP-11 is much more fun 13:19 < aiju> http://phicode.de/git/?p=aas.git;a=blob;f=test/pdp11/regex.s;h=cc227121eb471f3548888aea0b91f0e263fca914;hb=HEAD 13:19 < aiju> very simplified regex compiler in PDP-11 13:20 -!- tensai_cirno [~cirno@95.165.253.130] has joined #go-nuts 13:28 -!- mattn_jp [~mattn@s60.BMT-e1.vectant.ne.jp] has joined #go-nuts 13:33 * steven jumps for joy 13:37 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts 13:41 < ww> can we run go on a pdp11? 13:41 < aiju> hahahaha 13:41 < aiju> probably not 13:42 < aiju> 2 MB of runtime don't fit in a 64 KB address space :) 13:42 < steven> i realized a graceful solution this morning for the problem i had last night, of my data-fetching goroutines not having a way to signal that they want to quit.. 13:43 < steven> they could just close their writing channel! 13:43 < ww> steven: yes! 13:43 < steven> :) 13:44 < ww> for { foo := <- ch; if closed(ch) { break } } 13:44 < steven> no 13:44 < steven> we should not use if closed().. 13:44 < aiju> never ever check closed 13:44 < ww> that's on the reading side 13:44 < aiju> or Pike will rip off your head 13:44 < steven> if foo, ok := <- ch; ok { break } 13:44 < steven> wait, !ok 13:45 < steven> aiju: right? 13:45 < aiju> probably 13:45 < aiju> depends what break does ;P 13:45 < steven> assuming break isnt in question ;) 13:45 < aiju> well, it really depends how you structure your code 13:45 < aiju> if you want to break if it's closed, than it's right 13:46 < ww> "never ever check closed" -- why do we have closed() then? 13:46 < aiju> ww: it'll go 13:46 < steven> ww: because of the way closed() works. 13:46 < steven> "After at least one such zero value has been received, closed(c) returns true." 13:46 < ww> steven: right, that's why we read from the channel first 13:46 < steven> so closed() will return false after a close() statement, until its read from at least one more time. 13:47 < steven> which is why the comma ok idiom works perfectly here, since it does a rad. 13:47 < steven> *read 13:47 < aiju> using closed() is just asking for a race condition 13:47 < steven> right. 13:47 < steven> which i found out the hard way last night. 13:47 < steven> so i have my code working much better now, thanks a lot to some awesome guys in here last night who didnt kick me for my verbosity 13:47 < ww> hmmm.... actually... i wonder if my mysterious error that i'm tracking down right now is such a race... 13:48 * ww fixes and checks... 13:48 < ww> hmmm... not quite: cannot use multiple-value assignment for non-blocking receive; use select 13:48 < steven> https://gist.github.com/857298 13:49 < steven> ww: another thing i learned last night; 13:49 < steven> ONLY a goroutine who is allowed to send to a channel should close it. 13:49 < ww> steven: of course 13:50 < Namegduf> More specifically, closing only works when there's either only one writer or the writers coordinate to know to stop sending 13:50 < steven> i found out because i was having an error due to this code: https://gist.github.com/857003/4a84989f7e38702fd9b60e250363fcb05754c7c9 13:50 < steven> Namegduf: right on. 13:50 < Namegduf> If you're not the "writer", you need to communicate with the writers so they know. 13:50 < steven> which means, i have no idea how to implement a multi-writer chan that i can close safely 13:51 < steven> (though to be honest, it doesnt seem like a bad thing to have a non-closed channel, so long as its GC'd properly) 13:51 < Namegduf> It isn't. 13:51 < Namegduf> close() is a useful thing you *can* optionally use to tell a reader to stop reading. 13:51 < Namegduf> Without making zero values illegal or such. 13:52 < Namegduf> But it's not required, not the equivalent of close() in an open()/close() where you should have one for every open(). 13:53 < Namegduf> Multi-writer the easiest thing to do is not to use close() in yoru designs 13:53 < Namegduf> *your 13:54 < steven> woo, i just came up with another cool solution.. i can defer my quit channel being closed instead of manually closing it whenever i return from my loop.. https://gist.github.com/857298 13:55 < ww> hmmm... so how do i do a blocking receive then, that should block until either a value is received or the channel is closed? 13:57 < Namegduf> That's the default. 13:58 < ww> so how do i distinguish between a zero-value and a closed channel? 13:58 < Namegduf> You can call closed(). 13:58 < ww> (without using closd()) 13:58 < ww> but.. but... 13:58 < aiju> foo, ok := ... 13:58 < Namegduf> foo, ok := is the new syntax for it 13:58 < Namegduf> Not added yet, I think 13:58 < aiju> orly? 13:58 < Namegduf> It used to do a non-blocking receive 13:59 < Namegduf> I don't know, I could be outdated. 13:59 < ww> Namegduf: not added in most recent release anyways: cannot use multiple-value assignment for non-blocking receive; use select 14:00 < Namegduf> Yeah, they took out non-blocking receive for a while so as to break existing code 14:00 < ww> right. so until it is added back, use closed() 14:00 < Namegduf> Before adding foo, ok := <-blah as a way to do a receive and check closed. 14:00 < xulfer> Speaking of. Do they have anything implemented or on the way regarding backgrounding a process? Other than doing the raw fork syscall of course (which is risky). 14:00 < ww> (where back means replaced) 14:00 < Namegduf> They'll be removing closed(), I think. 14:00 < Namegduf> People keep trying to do wrong things, like close channels in the reader 14:01 < Namegduf> To send messages to the writer 14:01 < ww> but in the meantime, the only way to do it is to check closed on the reader 14:01 < Namegduf> I think ranging over the channel and select might work. 14:01 < Namegduf> But yeah, otherwise... 14:01 < Namegduf> And you're right, there's a race condition with zero values that way. 14:02 < ww> Namegduf: that changes it into a non-blocking call... which in my case i don't want 14:02 < Namegduf> Not automatically. 14:02 < ww> if there is a default: 14:02 < Namegduf> select{} is only non-blocking with a default. 14:02 < steven> wait, why doesnt "input, ok := <- remoteChan" work in a case statement? 14:03 < aiju> steven: it doens't exist yet haha 14:03 < aiju> sorry for being misinformed 14:03 < Namegduf> It's not added yet. Planned, but not added so as to let people realise the old v, ok := <-chan syntax is gone and update. 14:04 < steven> daaaaang. 14:04 < ww> so to summarise, for { x := <- ch; if closed(ch) { break } ... } is the way to do it on the receiver end until the new syntax is put in 14:04 < steven> well its ok, because having done a receive already in the select makes closed() safe. 14:04 < Namegduf> Note that with multiple readers there is a race condition. 14:05 < steven> directly after a receive, closed() is safe. and inside a select case, you've already done a receive. so its inherently ok. 14:05 < Namegduf> If you send zeroes. 14:05 < steven> Namegduf: how so? 14:05 < Namegduf> No, it's only safe with only one reader. 14:05 < ww> in my case not a problem... 14:05 < steven> mine too, i only have one reader 14:05 < steven> but im confused. 14:05 < Namegduf> Send zero, send two, close- you receive zero, another reader gets the two and the close's zero value, context switches back to you. 14:05 < Namegduf> You check closed(), you detect it's closed. 14:06 < Namegduf> You discard the legitimate zero value. 14:06 < steven> touche. 14:06 < steven> the comma ok trick wont solve that problem though, will it? 14:06 < ww> and as it turns out, my problem is interaction between memory management in c and the go GC... 14:06 * ww refactors 14:06 < Namegduf> It will, because it will be atomic. 14:06 < steven> oh yeah it will becuase it combines them into one statement, which means they will go hand in hand every single time. 14:06 < Namegduf> Yes. 14:06 < steven> right? 14:06 < Namegduf> Yep. 14:07 < Namegduf> There's no room for that other reader to do an unlimited amount of stuff between the read and the closed(), so to spea. 14:07 < Namegduf> *speak 14:07 -!- hcatlin [~hcatlin@host86-145-112-33.range86-145.btcentralplus.com] has joined #go-nuts 14:07 -!- hcatlin [~hcatlin@host86-145-112-33.range86-145.btcentralplus.com] has quit [Changing host] 14:07 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has joined #go-nuts 14:19 -!- steevel [steevel@yahoe.se] has quit [Quit: leaving] 14:23 -!- napsy [~luka@88.200.96.18] has joined #go-nuts 14:23 -!- yugui___ [~yugui@yugui.jp] has quit [Quit: Tiarra 0.1+svn-24729: SIGTERM received; exit] 14:23 < steven> ha, i wrote this awful stuff months ago.. https://gist.github.com/601692 14:24 -!- yugui [~yugui@yugui.jp] has joined #go-nuts 14:26 < steven> channel-comma-ok idiom is also useful for givin a close-only channel to one sender and multiple readers. 14:26 < steven> i think 14:30 < skelterjohn> morning 14:30 < xyproto> good afternoon 14:31 < aiju> How are you gentlemen!! 14:31 < skelterjohn> for that kind of thing, steven, i feel like something from the sync package would be more appropriate 14:31 < skelterjohn> i'm ok 14:35 -!- foocraft [~dsc@dyn-86-36-42-96.wv.qatar.cmu.edu] has quit [Quit: Leaving] 14:36 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has quit [Quit: hcatlin] 14:42 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has joined #go-nuts 14:46 < tobier> are there any good tutorials for HTMl templates? the codelab wiki implementation doesn't work as is 14:47 -!- tensai_cirno [~cirno@95.165.253.130] has quit [Ping timeout: 246 seconds] 14:49 -!- karpar [~karpar@112.96.254.24] has joined #go-nuts 14:51 < tobier> actually, there is a bug in the codelab 14:51 < tobier> the paramaters to the template Execute are switched 14:59 -!- nettok [~quassel@200.119.161.206] has joined #go-nuts 15:06 -!- karpar [~karpar@112.96.254.24] has quit [Quit: Bye!] 15:06 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has quit [Quit: hcatlin] 15:16 -!- rurban [~chatzilla@178-191-149-74.adsl.highway.telekom.at] has joined #go-nuts 15:25 -!- TheMue [~TheMue@p5DDF6E8B.dip.t-dialin.net] has joined #go-nuts 15:27 -!- visof__ [~visof@41.233.113.242] has quit [Remote host closed the connection] 15:40 -!- saschpe [~quassel@opensuse/member/saschpe] has quit [Remote host closed the connection] 15:44 -!- skejoe [~skejoe@188.114.142.162] has joined #go-nuts 15:51 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts 15:54 -!- brad_ [~brad@cpe-098-026-053-035.nc.res.rr.com] has quit [Quit: leaving] 15:54 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 260 seconds] 16:08 < rurban> Now I have a bit more time to complete my cygwin port 16:09 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 16:18 -!- sauerbraten [~sauerbrat@p508C9E90.dip.t-dialin.net] has quit [Read error: Operation timed out] 16:26 -!- DerHorst [~Horst@e176102247.adsl.alicedsl.de] has quit [Remote host closed the connection] 16:27 -!- mattn_jp [~mattn@s60.BMT-e1.vectant.ne.jp] has quit [Remote host closed the connection] 16:30 -!- photron [~photron@port-92-201-10-205.dynamic.qsc.de] has joined #go-nuts 16:35 -!- Cromulent [~Cromulent@cpc8-reig4-2-0-cust24.6-3.cable.virginmedia.com] has joined #go-nuts 16:35 -!- shvntr [~shvntr@113.84.151.19] has quit [Ping timeout: 248 seconds] 16:36 -!- Cromulent [~Cromulent@cpc8-reig4-2-0-cust24.6-3.cable.virginmedia.com] has quit [Quit: Cromulent] 16:38 -!- shvntr [~shvntr@123.65.197.63] has joined #go-nuts 16:44 < ww> to what extent is calling into go from c thread safe? 16:52 -!- mutenewt [~mutenewt@adsl-99-22-110-84.dsl.chcgil.sbcglobal.net] has joined #go-nuts 16:57 < skelterjohn> if you mean a c program invoking go code, doesn't happen yet 16:57 < skelterjohn> if you mean a go program invoking c code that calls some go code, can you do that? i dunno 16:57 < skelterjohn> but if you can, there is nothing inherently non-threadsafe about it 16:57 < skelterjohn> no more than usual, anyway 16:58 < skelterjohn> what problems do you foresee? 16:58 -!- femtooo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 17:00 -!- deso_ [~deso@x0561a.wh30.tu-dresden.de] has joined #go-nuts 17:01 -!- chomp [~ken@c-71-206-216-232.hsd1.pa.comcast.net] has joined #go-nuts 17:22 < ww> skelterjohn: as usual, the hitch is with callbacks... 17:23 < ww> so there's this c library that parses some type of file. 17:23 < ww> you give its parsing function a callback (implemented in go) 17:23 < ww> the callback takes a record and sends it off over a channel 17:24 < ww> so there's a goroutine running the parsing function, and this parsing function calls back into go 17:25 < ww> "call back into go" -> no guarantee that the called back goroutine is running in the same OS thread as the parsing function that calls it, right? 17:25 < chomp> dubious 17:31 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has quit [Read error: Connection reset by peer] 17:32 -!- shvntr [~shvntr@123.65.197.63] has quit [Quit: leaving] 17:39 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts 17:42 -!- espeed [~espeed@63.246.231.57] has quit [Quit: Leaving] 17:49 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has joined #go-nuts 17:50 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has joined #go-nuts 17:53 -!- _nil [~caine@c-67-189-251-116.hsd1.ct.comcast.net] has joined #go-nuts 17:53 -!- awidegreen [~quassel@c-eacae555.08-2-73746f39.cust.bredbandsbolaget.se] has quit [Read error: Connection reset by peer] 17:54 -!- sauerbraten [~sauerbrat@p508C9E90.dip.t-dialin.net] has joined #go-nuts 17:54 < _nil> hey guys :) 17:55 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Ping timeout: 250 seconds] 17:58 -!- zonax9 [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has joined #go-nuts 18:00 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has quit [Ping timeout: 255 seconds] 18:00 -!- awidegreen [~quassel@c-eacae555.08-2-73746f39.cust.bredbandsbolaget.se] has joined #go-nuts 18:02 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts 18:06 -!- SetupLy [~setuply@84.15.187.118] has joined #go-nuts 18:07 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts 18:14 -!- ymasory [~ymasory@c-76-99-55-224.hsd1.pa.comcast.net] has joined #go-nuts 18:14 -!- tsykoduk [~tsykoduk@c-98-232-28-167.hsd1.wa.comcast.net] has quit [Ping timeout: 276 seconds] 18:19 -!- kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [Ping timeout: 264 seconds] 18:22 -!- SetupLy [~setuply@84.15.187.118] has left #go-nuts [] 18:28 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Ping timeout: 264 seconds] 18:31 -!- Pete_27 [~noname@110-174-103-31.static.tpgi.com.au] has quit [Ping timeout: 276 seconds] 18:31 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has joined #go-nuts 18:32 -!- perdix [~mkhl@sxemacs/devel/perdix] has quit [Remote host closed the connection] 18:33 -!- mutenewt [~mutenewt@adsl-99-22-110-84.dsl.chcgil.sbcglobal.net] has quit [Quit: Leaving] 18:34 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts 18:34 -!- deso_ [~deso@x0561a.wh30.tu-dresden.de] has quit [Read error: Operation timed out] 18:42 < chomp> How might one go about waiting on either a child process to exit or a buffered channel to have data 18:43 < chomp> I was trying to avoid polling with WNOHANG, but so far that's my only solution 18:45 -!- tsykoduk [~tsykoduk@c-98-232-28-167.hsd1.wa.comcast.net] has joined #go-nuts 18:49 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Ping timeout: 260 seconds] 18:49 -!- tsykoduk [~tsykoduk@c-98-232-28-167.hsd1.wa.comcast.net] has quit [Ping timeout: 252 seconds] 18:55 -!- tsykoduk [~tsykoduk@2001:470:1f04:671:20d:93ff:fe77:1dc4] has joined #go-nuts 18:55 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts 18:56 -!- StoneColdNinja [~idjit@cpe-68-174-246-95.si.res.rr.com] has joined #go-nuts 19:00 -!- StoneColdNinja [~idjit@cpe-68-174-246-95.si.res.rr.com] has quit [Remote host closed the connection] 19:01 -!- Idjit [~idjit@cpe-68-174-246-95.si.res.rr.com] has joined #go-nuts 19:01 -!- boscop_ [~boscop@g227132192.adsl.alicedsl.de] has joined #go-nuts 19:02 < skelterjohn> chomp: if you launch a child process with exec.Run, you get back an exec.Cmd that has a .Wait() function 19:02 < skelterjohn> and you can wait on a buffered channel by simply trying to recv from it 19:02 < skelterjohn> it will block until there is something 19:03 < chomp> I'm using StartProcess, and the returned Process provides a Wait() function as well - is that effectively the same thing? 19:03 < chomp> right, my goal is to wait on both, and continue when either condition is met 19:04 < skelterjohn> then, in a goroutine, you call the process's Wait() function - when it is read you send something over a channel 19:04 < chomp> the best i could think to do is have a goroutine doing the Wait, and have it send to a second buffered channel, then select on both channels 19:04 < skelterjohn> somewhere else you select on both that channel and the original buffered channel 19:04 < skelterjohn> well then 19:04 < chomp> heh 19:04 < skelterjohn> that seems like a good idea to me 19:04 -!- boscop [~boscop@f050135026.adsl.alicedsl.de] has quit [Ping timeout: 255 seconds] 19:04 < chomp> but supposing that i continue on the original channel condition. i'd like to terminate the waiting goroutine 19:04 -!- kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined #go-nuts 19:05 < skelterjohn> terminating the original process should do so 19:05 < chomp> which i have attemted to accomplish by explicitly killing the child process with a syscall. that does not appear to be happening 19:06 < chomp> i might just be sending the wrong signal though, or perhaps there's a more robust and idiomatic way to kill a process 19:06 < skelterjohn> Process.Release()? 19:07 < chomp> that does it? 19:07 < skelterjohn> guessing 19:07 < chomp> i looked at the implementation, seemed dubious 19:07 < skelterjohn> try it out 19:07 < chomp> will do 19:07 -!- Fish- [~Fish@9fans.fr] has joined #go-nuts 19:08 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Remote host closed the connection] 19:09 < chomp> hmm no dice 19:09 < chomp> maybe the child process is just being a bastard 19:11 < steven> is it possible in Go to define a sort of "abstract base class" that one class uses and expects a concrete instance of to be given to it to use? 19:11 < steven> (if that makes sense) 19:12 -!- Project_2501 [~Marvin@82.84.84.173] has joined #go-nuts 19:12 < chomp> nah. if i manually send SIGUP to the process from the shell, it dies and the go program operates normally, unblocking on Wait and cleaning up 19:13 < steven> oh, i thnk "interface" is exactly what im looking for 19:13 -!- perdix [~mkhl@sxemacs/devel/perdix] has joined #go-nuts 19:14 -!- __gilles [~gilles@poolp.org] has left #go-nuts [] 19:19 < exch> steven: if you need to 'inherit' fields or methods from your 'base' type, you can embed the base type in the new type. 19:21 < exch> http://pastie.org/1640258 like this 19:26 -!- Idjit [~idjit@cpe-68-174-246-95.si.res.rr.com] has left #go-nuts [] 19:26 -!- cco3 [~conley@c-69-181-140-72.hsd1.ca.comcast.net] has joined #go-nuts 19:35 < skelterjohn> but you have to be careful - that doesn't give you polymorphism 19:35 < skelterjohn> if you convert it back to the base class, you'll use the base class methods again 19:39 < exch> yup. its the closest thing go has to polymorphism 19:40 < skelterjohn> you can combine that with interfaces to get the behavior you're looking for 19:48 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has joined #go-nuts 19:54 < steven> exch, skelterjohn: right on 19:54 < steven> thanks 19:55 < steven> i dont want polymorphism.. i just wanted to get "protocol" (objc terminology) or "interface" (java terminology) behavior 19:55 < steven> so im experimenting with interfaces for a minute 19:55 -!- cco3 [~conley@c-69-181-140-72.hsd1.ca.comcast.net] has quit [Ping timeout: 252 seconds] 20:02 -!- sauerbraten [~sauerbrat@p508C9E90.dip.t-dialin.net] has quit [Remote host closed the connection] 20:04 -!- perdix [~mkhl@sxemacs/devel/perdix] has quit [Remote host closed the connection] 20:07 -!- binarypie [~binarypie@c-24-6-151-185.hsd1.ca.comcast.net] has joined #go-nuts 20:07 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.4] 20:08 -!- binarypie [~binarypie@c-24-6-151-185.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 20:12 -!- aimxhaisse [~mxs@buffout.org] has quit [Quit: leaving] 20:12 -!- aimxhaisse [~mxs@buffout.org] has joined #go-nuts 20:16 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-165-31.clienti.tiscali.it] has joined #go-nuts 20:19 -!- exch [~exch@h78233.upc-h.chello.nl] has quit [Quit: leaving] 20:20 -!- Project_2501 [~Marvin@82.84.84.173] has quit [Ping timeout: 276 seconds] 20:31 -!- exch [~exch@h78233.upc-h.chello.nl] has joined #go-nuts 20:31 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-170-135.clienti.tiscali.it] has joined #go-nuts 20:34 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-165-31.clienti.tiscali.it] has quit [Ping timeout: 248 seconds] 20:36 -!- vsayer [~vivek@c-76-102-205-58.hsd1.ca.comcast.net] has quit [Quit: Leaving] 20:48 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 20:54 -!- jlouis [jlouis@horus.0x90.dk] has quit [Remote host closed the connection] 21:00 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has quit [Read error: Operation timed out] 21:00 -!- frewsxcv [~frewsxcv@109.169.57.37] has joined #go-nuts 21:00 -!- frewsxcv [~frewsxcv@109.169.57.37] has quit [Changing host] 21:00 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has joined #go-nuts 21:01 -!- yugui_zzz [~yugui@yugui.jp] has quit [Ping timeout: 252 seconds] 21:03 -!- yugui_zzz [~yugui@yugui.jp] has joined #go-nuts 21:07 < steven> guys, 21:08 < steven> is it a bad idea to pass around a net.Conn object? should i pass a *net.Conn instead? does passing a plain net.Conn object make extraneous copies that should be avoided? 21:08 < steven> or worse, does passing around that object between functions actually create copies of the connection object that dont contain the state of that object? 21:10 < steven> oh good, its only a pointer. 21:11 < aiju> A wild pointer appears! 21:11 < steven> actually no, net.Conn is an interface 21:11 < steven> the actual object i have is probably *net.TCPConn which is a ptr to a struct that just has a file descriptor 21:19 -!- perdix [~mkhl@sxemacs/devel/perdix] has joined #go-nuts 21:22 < Namegduf> steven: I'm pretty sure copying an interface will just copy the two-word thing 21:23 < Namegduf> The thing inside the interface is actually immutable 21:24 < Namegduf> If it's a pointer you can change what it's pointing at but whenever you do anything to the value inside the interface, you have to call a method, passing it, or use a type assertion to assign it to something else, and that copies it. 21:24 -!- foocraft [~dsc@78.100.210.180] has joined #go-nuts 21:28 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has quit [Ping timeout: 260 seconds] 21:29 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has joined #go-nuts 21:37 -!- bXi [bluepunk@irssi.co.uk] has joined #go-nuts 21:41 -!- jlouis [jlouis@horus.0x90.dk] has joined #go-nuts 21:45 -!- TheSeeker2 [~n@99-153-250-110.lightspeed.irvnca.sbcglobal.net] has joined #go-nuts 21:45 -!- TheSeeker [~n@99-153-250-110.lightspeed.irvnca.sbcglobal.net] has quit [Disconnected by services] 21:46 -!- ww_ [~ww@river.styx.org] has joined #go-nuts 21:46 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has quit [Remote host closed the connection] 21:48 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has quit [Ping timeout: 246 seconds] 21:48 -!- madari_ [madari@AM.irc.fi] has joined #go-nuts 21:49 -!- XenoPhoe1ix [~Xeno@cpc13-aztw24-2-0-cust23.aztw.cable.virginmedia.com] has joined #go-nuts 21:49 -!- enferex_ [~enferex@users.757.org] has joined #go-nuts 21:49 -!- htoothro- [~mux@66-169-185-121.dhcp.ftwo.tx.charter.com] has joined #go-nuts 21:49 -!- tsung_ [~jon@112.104.53.151] has joined #go-nuts 21:49 -!- anticw_ [~anticw@c-67-169-68-180.hsd1.ca.comcast.net] has joined #go-nuts 21:49 -!- kurt_ [kurt@acm.poly.edu] has joined #go-nuts 21:49 -!- grncdr_ [~stephen@sdo.csc.UVic.CA] has joined #go-nuts 21:50 -!- Maxdaman1us [~Maxdamant@203-97-238-106.cable.telstraclear.net] has joined #go-nuts 21:50 -!- htoothrot [~mux@66-169-185-121.dhcp.ftwo.tx.charter.com] has quit [Ping timeout: 250 seconds] 21:50 -!- XenoPhoenix [~Xeno@cpc13-aztw24-2-0-cust23.aztw.cable.virginmedia.com] has quit [Ping timeout: 250 seconds] 21:50 -!- comex_ [comex@c-67-188-10-190.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds] 21:50 -!- tsung [~jon@112.104.53.151] has quit [Ping timeout: 250 seconds] 21:50 -!- steven [~steven@unaffiliated/steven] has quit [Ping timeout: 250 seconds] 21:50 -!- grncdr [~stephen@sdo.csc.UVic.CA] has quit [Ping timeout: 250 seconds] 21:50 -!- Paradox924X [~Paradox92@vaserv/irc/founder] has quit [Ping timeout: 250 seconds] 21:50 -!- Maxdamantus [~Maxdamant@203-97-238-106.cable.telstraclear.net] has quit [Ping timeout: 250 seconds] 21:50 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Ping timeout: 250 seconds] 21:50 -!- kurt [kurt@pdpc/supporter/active/kurt] has quit [Ping timeout: 250 seconds] 21:50 -!- madari [madari@AM.irc.fi] has quit [Ping timeout: 250 seconds] 21:50 -!- enferex [~enferex@users.757.org] has quit [Remote host closed the connection] 21:50 -!- anticw [~anticw@c-67-169-68-180.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds] 21:50 -!- ww [~ww@river.styx.org] has quit [Ping timeout: 250 seconds] 21:51 -!- comex [comex@c-67-188-10-190.hsd1.ca.comcast.net] has joined #go-nuts 21:52 -!- skejoe [~skejoe@188.114.142.162] has quit [Quit: leaving] 21:52 -!- cco3 [~conley@c-69-181-140-72.hsd1.ca.comcast.net] has joined #go-nuts 21:54 -!- Paradox924X [~Paradox92@c-68-35-229-34.hsd1.fl.comcast.net] has joined #go-nuts 21:55 -!- Paradox924X [~Paradox92@c-68-35-229-34.hsd1.fl.comcast.net] has quit [Changing host] 21:55 -!- Paradox924X [~Paradox92@vaserv/irc/founder] has joined #go-nuts 21:56 -!- rlab [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 21:56 -!- steven [~steven@pidsley.praxxium.com] has joined #go-nuts 21:59 -!- Guest95361 [~quassel@p4FF1C0D9.dip0.t-ipconnect.de] has quit [Quit: No Ping reply in 180 seconds.] 21:59 -!- ronny [~quassel@p4FF1C0D9.dip0.t-ipconnect.de] has joined #go-nuts 22:01 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts 22:01 < steven> guys, 22:02 < steven> how do you expand ~ in code via Go? 22:03 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has quit [Quit: Leaving] 22:06 -!- cco3 [~conley@c-69-181-140-72.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds] 22:09 < KirkMcDonald> os.Getenv("HOME") perhaps. 22:09 -!- TheMue [~TheMue@p5DDF6E8B.dip.t-dialin.net] has quit [Quit: TheMue] 22:09 -!- TheMue [~TheMue@p5DDF6E8B.dip.t-dialin.net] has joined #go-nuts 22:09 < steven> thats what im doin, was wondering if it was the idiomatic way 22:09 < KirkMcDonald> Though, that's not exactly the same thing. 22:09 < steven> right. 22:09 < KirkMcDonald> Since you can have e.g. ~username 22:10 -!- TheMue [~TheMue@p5DDF6E8B.dip.t-dialin.net] has quit [Client Quit] 22:11 < KirkMcDonald> Go needs to steal more functions from Python's os.path module. 22:11 < KirkMcDonald> http://docs.python.org/library/os.path#os.path.expanduser 22:12 -!- TheMue [~TheMue@p5DDF6E8B.dip.t-dialin.net] has joined #go-nuts 22:12 -!- TheMue [~TheMue@p5DDF6E8B.dip.t-dialin.net] has quit [Client Quit] 22:15 -!- awidegreen [~quassel@c-eacae555.08-2-73746f39.cust.bredbandsbolaget.se] has quit [Ping timeout: 248 seconds] 22:17 -!- perdix [~mkhl@sxemacs/devel/perdix] has quit [Remote host closed the connection] 22:18 < steven> i bet it would be really easy to write a competitor to django and rails in Go 22:18 < steven> a quality competitor too 22:18 -!- dilenger [~dcheney@sydfibre2.atlassian.com] has joined #go-nuts 22:20 < KirkMcDonald> Does Go have a FastCGI library? 22:21 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-170-135.clienti.tiscali.it] has quit [Quit: E se abbasso questa leva che succ...] 22:21 < dilenger> KirkMcDonald: nearly 22:22 < dilenger> i think someone was working on that very recently on the list 22:23 < KirkMcDonald> I wonder if an approximate equivalent to Python's WSGI would make sense in Go. 22:24 < dilenger> http://godashboard.appspot.com/package 22:24 < dilenger> there is a fastcgi impl there 22:27 -!- kurt [kurt@acm.poly.edu] has quit [Changing host] 22:27 -!- kurt [kurt@pdpc/supporter/active/kurt] has joined #go-nuts 22:29 -!- aho [~nya@fuld-590c62d1.pool.mediaWays.net] has joined #go-nuts 22:30 -!- Fish- [~Fish@9fans.fr] has quit [Quit: So Long, and Thanks for All the Fish] 22:38 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has joined #go-nuts 22:39 < cenuij> there are a few that will accept an fcgi request, web.go fcgi.go 22:41 < cenuij> though no working code that I know of in the public domain to request fcgi from a go server 22:42 -!- photron [~photron@port-92-201-10-205.dynamic.qsc.de] has quit [Ping timeout: 276 seconds] 22:42 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has quit [Remote host closed the connection] 22:43 < cenuij> KirkMcDonald: is the overhead of parsing WSGI that much better thanh FCGI? 22:43 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has joined #go-nuts 22:44 < KirkMcDonald> cenuij: The question suggests you are not familiar with WSGI. The two do different things. 22:44 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Remote host closed the connection] 22:44 < cenuij> KirkMcDonald: WSGI is a python gateway protocol? 22:44 < KirkMcDonald> cenuij: No, it is not. It is a Python API. 22:44 < cenuij> ah 22:45 < KirkMcDonald> cenuij: The idea being that you can write a web application against WSGI, then you can host that application using any WSGI-compliant server. 22:45 < KirkMcDonald> This abstracts the application from the protocol. 22:45 < cenuij> ok, compliant servers being python servers? 22:46 < KirkMcDonald> cenuij: There is an Apache module, mod_wsgi. There are a couple of FastCGI-WSGI bridges. 22:46 < KirkMcDonald> There are CGI-WSGI bridges, as well. 22:46 < cenuij> ok, but I don't understand where this is not analagous to fcgi? 22:46 -!- frewsxcv [~frewsxcv@109.169.57.37] has joined #go-nuts 22:46 -!- frewsxcv [~frewsxcv@109.169.57.37] has quit [Changing host] 22:46 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has joined #go-nuts 22:46 < KirkMcDonald> cenuij: FastCGI is a wire protocol. 22:46 < KirkMcDonald> cenuij: WSGI is a Python API. 22:48 < KirkMcDonald> cenuij: Rather than writing a server which listens for FastCGI requests, you just write some code where some function is written to be a WSGI request handler. It is passed a request, and returns a response. 22:48 < KirkMcDonald> Then you plug that into any of the many existing WSGI-compliant servers. 22:49 < cenuij> I'ts pythong only RPC? 22:49 < KirkMcDonald> WSGI isn't an RPC. 22:49 < KirkMcDonald> It's just a function. 22:50 < dilenger> similar to Rack ? 22:50 < cenuij> I'm confused 22:50 < KirkMcDonald> I am not familiar with Rack. 22:51 < KirkMcDonald> cenuij: Say you have a function you have written. This function is passed some information defining an HTTP request, and returns something representing an HTTP response. 22:51 < cenuij> If WSGI is not a protocol, or RPC, how can I communicate with it outside of python? 22:52 < KirkMcDonald> cenuij: You can't. Not directly. You need a server, either written in Python or using Python's C API, which imports this function, and knows how to call it. 22:52 < KirkMcDonald> cenuij: There are several such servers: mod_wsgi for Apache, some simple development servers, Wiseguy... 22:52 < cenuij> ok 22:53 < cenuij> would it not be easier for python servers to use some kind of RPC? 22:53 < cenuij> or that horrible slow fcgi? 22:53 < KirkMcDonald> So when I say something is a FastCGI-WSGI bridge, I mean that it is a FastCGI server, written in Python, which can be configured to import any WSGI application you have sitting around. 22:54 < cenuij> KirkMcDonald: aaah 22:54 < steven> why even bother with bridges or whatnot? why not just write your entire server in Go? 22:54 < cenuij> well that's reasonably cunning :) 22:54 < steven> err, app, not server. 22:54 < cenuij> steven: the world doesnt use go, yet... ;) 22:55 < KirkMcDonald> cenuij: The intent is to have a handy interface which can be plugged into whatever you actually want to serve the application with. 22:55 < exch> And it never will if someone doesnt start 22:55 < steven> but im saying, Go is so high-level that you can write a stand-alone webapp in it with little trouble 22:55 < steven> exch: right on 22:55 -!- tensorpudding [~user@99.56.160.152] has joined #go-nuts 22:55 < KirkMcDonald> cenuij: So if you invented some new, efficient RPC, you could just make a WSGI-compliant server, and plug the whole existing ecosystem of WSGI-compliant web applications into it. 22:56 < steven> serving files is built right into go -- https://gist.github.com/857832 22:56 < cenuij> KirkMcDonald: I'm with you now... and I see the point of view of python 22:57 < KirkMcDonald> cenuij: So! It might be handy to have such a standard interface for Go. 22:57 < cenuij> KirkMcDonald: thanks, i had previously associated wsgi with fcgi 22:57 < steven> oh i get why.. 22:57 -!- rurban [~chatzilla@178-191-149-74.adsl.highway.telekom.at] has quit [Ping timeout: 276 seconds] 22:57 < KirkMcDonald> cenuij: This is a depressingly common misconception. 22:58 < steven> because its handy to have the server (and its configuration) be separate than the webapp itself.. 22:58 < steven> ie mongrel/passenger/apache/etc are all separate from rails/sinatra/etc, and can be interchanged. 22:58 < KirkMcDonald> cenuij: I think it comes about because people see there is a mod_wsgi and a mod_fcgi, and they assume they represent the same abstraction. 22:59 < cenuij> KirkMcDonald: is wsgi a supported api in python libs or in the interpreters? 22:59 < KirkMcDonald> cenuij: In a sense there's nothing that needs supporting. 22:59 < KirkMcDonald> cenuij: The standard library has a reference implementation. 22:59 < KirkMcDonald> But in any serious production system, you probably wouldn't use that. 23:00 < cenuij> I don't suppose anyone has some background on fcgi? 23:01 < cenuij> it's almost as annoying as blizzards mpw archive's 23:01 < KirkMcDonald> cenuij: WSGI is a supported API in the sense that the document defining it is an officially-endorsed PEP: http://www.python.org/dev/peps/pep-0333/ 23:01 < KirkMcDonald> The standard library doesn't enter into it. It defines a function to be implemented by web applications, to be called by servers. 23:02 < KirkMcDonald> (This being Python, everything is dynamically typed.) 23:02 < cenuij> KirkMcDonald: thanks, i'll take care to read this. 23:03 < KirkMcDonald> (So you don't need what you'd need in a statically typed language: Standard base classes or interfaces, or what-have-you.) 23:03 < ww> in principle there si a way of embedding python into go... so a little bit of glue should be able to pull in wsgi apps... 23:03 < ww> but why you'd *want* to do that is not clear to me 23:03 < KirkMcDonald> It would buy you very little, heh. 23:03 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit: Verlassend] 23:04 < KirkMcDonald> cenuij: You should also be aware that there are efforts to revise the WSGI standard, and at least a couple of drafts of new versions. 23:05 < KirkMcDonald> The Python 3 version linked from PEP 333, as I understand it, is still a little up in the air. 23:05 < ww> somethign to do with working out how to properly treat unicode iirc 23:05 < cenuij> KirkMcDonald: My interest will probably lag behind that anyway, i'm still fighting having versions of py on dev boxes 23:05 < KirkMcDonald> ww: Just so. 23:05 < aiju> you don't revise standards, you just don't use them … 23:05 < cenuij> So i was reading on the mailing list, an offer to provide a new hash algo into the go libs. 23:06 < cenuij> and there was some resistance 23:06 < ww> i coincidentally wrote the same one as that guy... dont see a real reason why it can't just be an external package... 23:07 < aiju> i should read the mailing list 23:07 < aiju> it's just hilarious sometimes 23:07 < ww> otoh that algorithm is like six lines of code so it wouldn't be much of a burden to take it in house 23:07 * ww shrugs 23:08 < cenuij> it's hard to say what the "litmus" test should be 23:12 -!- Electro^ [electro@c-bef570d5.033-10-67626721.cust.bredbandsbolaget.se] has quit [Remote host closed the connection] 23:12 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has quit [Read error: Operation timed out] 23:15 < cenuij> ww: at the same time we will see lz* creeping into the libs, is it really so bad to have more hash algos? 23:17 < steven> does it make sense to write a webapp (say, a twitter-clone) purely in Go, and serve it directly on port 80 on some server? 23:17 < steven> as opposed to going through the whole apache dance, etc 23:21 < cenuij> do you trust go to parse the http request correctly? 23:26 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has quit [Ping timeout: 264 seconds] 23:28 < ww> i'd almost always put nginx in front for flexibility... proxy this, add cors headers to that etc... 23:29 < ww> cenuij: i don't feel very strongly about it. would tend to err on the side of keeping stdlib small though... 23:31 < ww> because the core committers will become a bottleneck as it gets more widely used if they have to gatekeep changes to libraries 23:32 < ww> most likely the real litmus test is whether they use it themselves and have a vested interest in maintaining it 23:33 < aiju> adding every algo on the planet doesn't seem like a good idea 23:34 < aiju> gosh, the runtime is already 200 KLOC 23:34 < aiju> s/runtime/stdlib 23:36 < cenuij> I'm in agreement. I will use nginx. I was tempted to use varnish as my proxy but henning-kamp's insistance that he had discouvered a new form of CS made my nano-Dijkstra monitor blow a valve. 23:42 < KirkMcDonald> The main reason, I think, to put a dedicated web server in front of the web application is to serve static files. 23:43 < dilenger> cenuij: i'd avoid varnish unless you actually need a caching reverse proxy 23:43 < dilenger> i never had any luck with its stability 23:44 < dilenger> but it does reastart VERY quickly 23:44 -!- boscop_ [~boscop@g227132192.adsl.alicedsl.de] has quit [Ping timeout: 255 seconds] 23:45 * ww is very suspicious of varnish, by default it is not http compliant (stomps on and ignores cache headers that are presumably set by the application to tell the cache what to do...) 23:45 < steven> KirkMcDonald: but the idea is that Go has the ability to be super fast at serving static files, comparable to nginx 23:47 < dilenger> steven: i'd expect go's static speed to be comperable to nginx, up to the point they are both limited by bandwidth and syscall thoughput 23:47 < ww> KirkMcDonald: i prefer to try to keep apps small and separate. don't really want them running in one image. very much not a fan of embedding a gigantic tree of wsgi apps in apache... 23:48 < ww> so something like nginx just to knit them together. could rewrite something in go that does the same thing, but why reinvent that wheel? 23:48 < steven> i can tell you one thing.. at work when one mongrel does, its nice that they all dont die. if they were all in one process, that could be very bad. 23:48 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has quit [Quit: Computer has gone to sleep.] 23:48 < steven> i suppose though that with proper error handling that isnt really a problem at all 23:49 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has joined #go-nuts 23:51 -!- _nil [~caine@c-67-189-251-116.hsd1.ct.comcast.net] has quit [Ping timeout: 264 seconds] 23:55 < cenuij> the mongrel http parser is practically a state machine, so far as I can grok it 23:56 < cenuij> which is nice 23:56 < cenuij> but it's not go 23:56 < cenuij> we have http 23:56 < dfc> the mongrel parser is written in ragel (?) 23:56 < dfc> and I believe that ragel can output a .go file 23:56 < dfc> but that is as far as I've looked into it 23:56 < dfc> the common wisdom is the ragel http parser is solid 23:57 -!- itrekkie [~itrekkie@ip72-211-129-122.tc.ph.cox.net] has joined #go-nuts 23:57 < dfc> and accepted as a semi standard of acceptable http parsing 23:58 < cenuij> dfc: this would make sense to me as the mongrel/mongrel2 http parser is in the C form of a state machine that is hard for me to immediately follow 23:58 < steven> :) --- Log closed Mon Mar 07 00:00:49 2011