--- Log opened Mon Jun 27 00:00:54 2011 00:06 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has joined #go-nuts 00:11 -!- franciscosouza [~francisco@187.105.24.41] has quit [Read error: Connection reset by peer] 00:14 -!- kfmfe04 [~kfmfe04@host-58-114-183-56.dynamic.kbtelecom.net] has joined #go-nuts 00:22 -!- franciscosouza [~francisco@187.105.24.41] has joined #go-nuts 00:42 -!- Bigbear1 [~Cody@d75-158-128-132.abhsia.telus.net] has quit [Ping timeout: 250 seconds] 00:42 -!- cafesofie [~cafesofie@ool-18b97779.dyn.optonline.net] has joined #go-nuts 00:42 -!- ExtraSpice [XtraSpice@78-57-204-104.static.zebra.lt] has quit [Remote host closed the connection] 00:43 -!- Bigbear1 [~Cody@d75-158-128-132.abhsia.telus.net] has joined #go-nuts 00:52 -!- ccc1 [~Adium@140.109.98.187] has joined #go-nuts 01:01 -!- mikespook1 [~mikespook@119.131.232.30] has quit [Quit: Leaving.] 01:02 -!- mikespook [~mikespook@119.131.232.30] has joined #go-nuts 01:03 -!- wchicken [~chicken@c-71-235-58-74.hsd1.ct.comcast.net] has quit [Ping timeout: 250 seconds] 01:08 -!- niemeyer [~niemeyer@89.127.177.74] has joined #go-nuts 01:14 -!- niemeyer [~niemeyer@89.127.177.74] has quit [Ping timeout: 240 seconds] 01:18 < crazy2be> how do i get an arbitrary pointer value? 01:18 < crazy2be> e.g. a pointer to memory location 0x1 01:18 < crazy2be> i'm checking the sanity of pointers passed in and out of Cgo code 01:18 < crazy2be> to try and find where the issues are 01:18 < crazy2be> and doing ptrType == 0x1 doesn't work 01:19 < crazy2be> since go is supposed to be safe and all 01:20 < temoto> crazy2be, why don't you check it while still in C mode? 01:22 < crazy2be> temoto: Because i'm not sure what c code is calling this go code :/ 01:23 < crazy2be> I don't quite understand why unsafe.Pointer doesn't seemt to abide by the normal type semantics 01:23 < crazy2be> hm 01:23 < temoto> panic can help to get stacktrace 01:23 < temoto> Or gdb 01:23 < temoto> afair, gdb 7 can debug go programs 01:25 < chomp> crazy2be, you should be able to cast an unsafe.Pointer to a uintptr and compare 01:25 < chomp> (uintptr)(unsafe.Pointer(foo)) == (uintptr)1 01:25 < crazy2be> chomp: Ah! I was trying unsafe.Uintptr 01:25 < crazy2be> which doesn't exist, of course 01:25 < chomp> :) 01:28 < crazy2be> and my cgo line numbers are *completely* messed up 01:28 < crazy2be> like normally cgo kinda generates its own wrapper files 01:29 < crazy2be> so the line numbers are a bit off 01:29 < crazy2be> this time, they are over 10 times higher than the number of lines in the generated cgo file 01:29 < crazy2be> so like like 1269 01:29 < chomp> cgo errors can be a little tricky to debug 01:30 < chomp> what specifically are you working with? 01:30 < crazy2be> go bindings to javascript, http://github.com/crazy2be/gojs 01:30 < crazy2be> it was positively full of unsafe.Pointer() 01:31 < temoto> You mean to V8? 01:31 < chomp> webkit javascriptcore 01:31 < crazy2be> JavaScriptCore 01:31 < temoto> Oh, never heard of such name. 01:31 < crazy2be> made by apple rather than google :P 01:32 * chomp clones gojs... 01:32 < crazy2be> chomp: checkout the ughunsafe branch 01:32 < crazy2be> I was trying to remove a bunch of the unsafe stuff 01:32 < chomp> do i just need to pull Javascriptcore sources into the build path? 01:33 < crazy2be> yeah sudo apt-get install webkit-dev or something for me 01:33 -!- Bigbear11 [~Cody@d75-158-128-132.abhsia.telus.net] has joined #go-nuts 01:33 < crazy2be> you shouldn't need the sources, just the headers and libs 01:33 < crazy2be> but i'm not really sure how cgo does all that :P 01:34 < crazy2be> I understand c, and I understand go, but not the bridge between them 01:36 < chomp> zounds i havent updated apt in like 2 months 01:36 < crazy2be> And I just pushed a couple of lines change to native.go 01:36 -!- franciscosouza [~francisco@187.105.24.41] has quit [Read error: Connection reset by peer] 01:36 -!- Bigbear1 [~Cody@d75-158-128-132.abhsia.telus.net] has quit [Ping timeout: 276 seconds] 01:36 < crazy2be> pointer to array is a *[0]uint8, which is basically go's *void 01:37 < crazy2be> it used to use StructType for that, because all the cgo types were stored in go as structs {} 01:37 < crazy2be> empty structs 01:37 -!- Bigbear11 [~Cody@d75-158-128-132.abhsia.telus.net] has quit [Client Quit] 01:37 < crazy2be> passing to cgo involved getting the unsafe.Pointer of one of these structs 01:38 -!- franciscosouza [~francisco@187.105.24.41] has joined #go-nuts 01:38 < chomp> hrmm i can't build the example 01:38 -!- robteix [~robteix@host243.200-82-125.telecom.net.ar] has joined #go-nuts 01:38 < crazy2be> for webkit or? 01:38 < chomp> your helloworld.go 01:39 < crazy2be> what's the error? 01:39 < chomp> ah hrm well i am using tip 01:39 < crazy2be> :P 01:39 < chomp> complaining about gojs.Exception not being a gojs.Value 01:40 < crazy2be> that's stange... 01:40 < crazy2be> are you on the ughunsafe branch? (although they should both compile) 01:40 < chomp> yeah 01:41 < crazy2be> what about running gotest? Does that compile for you? 01:41 < chomp> yep, but panic. which i assume is expected 01:41 < crazy2be> yeah 01:42 < crazy2be> hrph 01:42 -!- iwinulose [~charlesdu@c-67-188-13-8.hsd1.ca.comcast.net] has joined #go-nuts 01:42 < crazy2be> so the type I get back is a *[0]uint8 01:42 < crazy2be> which basically means go has no idea what it is 01:43 < chomp> get back from what where 01:43 < crazy2be> the guy who original wrote this got around that somehow by passing a pointer to an empty struct{} into cgo 01:43 < crazy2be> in value_to_javascript() 01:45 < crazy2be> and if I put a panic("") at the start of that to see the stack trace and get a clue what's going on 01:46 < crazy2be> then I get https://gist.github.com/1048190 01:46 < crazy2be> complete with negative line numbers! 01:47 < crazy2be> similar results for you? 01:47 < chomp> sec, poking around at some stuff 01:47 < crazy2be> :P 01:47 -!- franciscosouza_ [~francisco@187.105.24.41] has joined #go-nuts 01:48 -!- franciscosouza [~francisco@187.105.24.41] has quit [Read error: Connection reset by peer] 01:49 < crazy2be> I still don't entire understand how everything is supposed to work 01:49 < crazy2be> like how the bindings are supposed to work 01:49 -!- mikespook1 [~mikespook@119.131.232.30] has joined #go-nuts 01:49 -!- mikespook1 [~mikespook@119.131.232.30] has quit [Client Quit] 01:50 < crazy2be> and the lack of a proper stack trace certainly doesn't help... 01:50 -!- mikespook [~mikespook@119.131.232.30] has quit [Ping timeout: 260 seconds] 01:50 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has quit [Ping timeout: 260 seconds] 01:50 < chomp> ah i see. so the problem then is that v.ctx.ref == 1? 01:50 -!- nannto__ [~nanto@pee5b70.tokyff01.ap.so-net.ne.jp] has quit [Quit: Leaving...] 01:51 < chomp> sorry still wrapping my head around exactly what's happening here 01:52 < crazy2be> don't worry, so am I 01:52 < crazy2be> :P 01:52 < crazy2be> yeah it was 0x1 01:52 < crazy2be> which is obviously an invalid pointer value 01:53 < crazy2be> but that's curious 01:53 < crazy2be> because if it was uninitialized it would be 0 01:53 < chomp> because that means EvaluateScript is returning a Value with ctx==1 01:53 < crazy2be> since go zero-initializes everything 01:53 -!- nannto [~nanto@pee5b70.tokyff01.ap.so-net.ne.jp] has joined #go-nuts 01:55 < chomp> ok so 01:56 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has joined #go-nuts 01:56 < crazy2be> but I think that was because there was unsafe.Pointer() somewhere else initializing that 01:57 < chomp> the javascriptcore library provides no definition of the layout of OpaqueJSValue which is what JSEvaluateScript returns 01:57 < chomp> that would be why go gives you a *uint[0] 01:58 < chomp> though that... shouldn't matter 01:59 -!- lugu [~ludo@122.147.15.66] has quit [Quit: leaving] 01:59 < chomp> ah ok so you're giving NewValue the *uint[0] as an interface{} 02:00 < chomp> yeah i see 02:00 < chomp> that won't fly 02:01 < chomp> wait a second... 02:04 < crazy2be> Ah HA 02:04 < crazy2be> found one error 02:05 < crazy2be> ctx.EvaluateScript() was using ctx.NewValue rather than ctx.newValue 02:05 < chomp> that would explain why i couldn't make sense of this 02:05 < crazy2be> the former initializes a js object from a go type, the latter makes a new value object from a native javascript type 02:06 < chomp> yeah ok 02:06 < crazy2be> which is kindof a silly distinction for such a small difference in name 02:06 < crazy2be> but I made NewObject() and NewException() before making NewValue() 02:06 < chomp> didn't see newValue at all. noticed that were was all this reflection going on yet the incoming value should have always been a C.JSValueRef 02:06 < crazy2be> and then realized the name was taken 02:07 < crazy2be> yeah it's a monster of a library 02:07 < crazy2be> I'm trying to make it a bit saner 02:07 < chomp> one way to go would be to wrap the existing library in a more cgo-friendly C interface 02:08 < crazy2be> in what way? 02:08 -!- robteix [~robteix@host243.200-82-125.telecom.net.ar] has quit [Quit: Leaving...] 02:08 < chomp> heh well i don't know much about the library so it's hard to say 02:09 < chomp> i guess it's fairly straightforward is it is. all the data coming from C is just opaque pointers 02:11 < smw> Is there any type of thread pool library for Go? 02:11 < chomp> native.go feels a bit 02:11 < chomp> nasty 02:12 < crazy2be> yeah 02:13 < crazy2be> like this one 02:13 < crazy2be> func nativecallback_CallAsFunction_go(data_ptr unsafe.Pointer, ctx unsafe.Pointer, obj unsafe.Pointer, thisObject unsafe.Pointer, argumentCount uint, arguments unsafe.Pointer, exception *unsafe.Pointer) unsafe.Pointer { 02:13 < chomp> smw, there aren't really proper threads in go at all 02:13 < smw> chomp, I knew that. But is there a go routine pool? lol 02:13 < chomp> smw, though you should be able to use a goroutine pool and trust the scheduler to allocate schedule them on threads appropriately 02:13 < chomp> ah heh. not familiar with one, sorry 02:14 < chomp> doesn't seem like it would be difficult to implement in a couple lines though? 02:14 < smw> chomp, where would I find stuff like mutexes? 02:14 < chomp> spawn N goroutines, have them share a channel, done 02:14 < chomp> sync package 02:15 < chomp> though you may not want a mutex 02:15 < smw> chomp, yeah, I just want to see what other stuff they have 02:15 < chomp> crazy2be, yeah just came across that >< 02:15 < crazy2be> it's no go, it's c 02:15 < crazy2be> *not 02:15 < crazy2be> hacked into go :D 02:17 < smw> chomp, first I tried writing a prime number generator in C, java, python, and go to compare performance. Now I am trying to make a concurrent version in go :-). 02:18 < smw> chomp, go held up pretty well. Slower than C... but faster than java at least. 02:18 < crazy2be> smw: Really? 02:18 < crazy2be> that's pretty good 02:18 < chomp> well, it is compiled :) 02:18 < chomp> and not by a totally braindead compiler 02:18 < crazy2be> java isn't actually that slow 02:19 < crazy2be> ugly yes 02:19 < chomp> i realize java is too and is pretty "fast", but bytecode still aint machine code 02:19 < smw> crazy2be, yep. I was very impressed. gccgo may be faster though. 02:19 < chomp> any way you shake it 02:19 < smw> my guess is that stuff like zeroing out arrays did not help go :-P 02:19 < smw> go was half way between C and java 02:19 < smw> and python was not in the running when it took 9 seconds for 10,000 primes XD 02:20 < chomp> if you peek at the go tutorial here http://golang.org/doc/go_tutorial.html#tmp_361 you can see a simple concurrent prime sieve 02:20 < smw> yeah, I saw that 02:20 < smw> I want to use my current algorithm but test multiple numbers at once 02:21 < chomp> actually i lied, that doesn't look concurrent at all 02:21 < chomp> or at least, it only uses one generator 02:21 < smw> it is concurrent... 02:21 < smw> but not what I am looking for :-) 02:22 < chomp> it's concurrent but not in the sense that multiple coroutines are working on prime generation 02:22 < smw> right 02:22 -!- franciscosouza [~francisco@187.105.24.41] has quit [Read error: Connection reset by peer] 02:23 < smw> chomp, is there a way to send something like a kill signal to a routine? Even if it is working? 02:23 < chomp> no 02:23 < crazy2be> smw: Select on two channels if you can 02:23 < chomp> that'd be about it 02:23 < chomp> unless it's looking for a signal though no 02:23 < crazy2be> what are you trying to acheive? 02:23 -!- franciscosouza [~francisco@187.105.24.41] has joined #go-nuts 02:24 -!- flaguy48 [~gmallard@user-0c6s350.cable.mindspring.com] has left #go-nuts [] 02:24 < crazy2be> chances are you can acheive it, but not though a kill signal 02:25 < smw> crazy2be, if a prime number generator is working on a really big number and then I decide to kill the program in another go routine, how do I kill the prime generator? 02:25 < crazy2be> why do you want to kill it? 02:25 < crazy2be> is it taking too long? 02:25 < smw> crazy2be, because I decided to quit and I don't want to wait for the computation to finish 02:25 < crazy2be> I meant to say you could probably acheive it, but not by killing it 02:26 < crazy2be> not unless you design your algorithm to check if it should die every so often 02:26 < smw> crazy2be, as you can see, there is no real program, so there is no real problem. This is a hypothetical ;-). 02:27 < chomp> if you have some piece of code which is just crunching on numbers, it's not even yielding the cpu let alone responding to outside signals 02:27 < chomp> i mean it'll yield to the kernel but thats it 02:27 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has quit [Read error: Operation timed out] 02:28 < smw> chomp, ok. How do programs receive signals when I send a kill? 02:29 < chomp> when you send a kill, init will kill the process 02:30 < chomp> and then it won't be scheduled any more 02:30 < smw> but the program can capture the kill 02:30 < chomp> yes that is true, you can capture the kill 02:30 < smw> it is a signal of some sort 02:31 < chomp> but that doesn't change anything really ... 02:31 < smw> it stops normal execution 02:31 < crazy2be> does it? 02:31 < smw> I believe so 02:31 < smw> doesn't it? 02:31 < crazy2be> I've had plenty of programs not respont to kill signals 02:32 < crazy2be> I have to killall -s 9 them 02:32 < chomp> if you trap KILL you can do whatever you want but for one thing that's probably a terrible idea 02:32 < smw> yeah 02:33 < crazy2be> "Signal handlers can be installed with the signal() system call. If a signal handler is not installed for a particular signal, the default handler is used. Otherwise the signal is intercepted and the signal handler is invoked. The process can also specify two default behaviors, without creating a handler: ignore the signal (SIG_IGN) and use the default signal handler (SIG_DFL). There are two signals which cannot be intercepted and 02:33 < crazy2be> handled: SIGKILL and SIGSTOP." 02:33 < chomp> actually on most systems you can' 02:33 < chomp> yeah there ya go. 02:33 < crazy2be> so it's basically a callback 02:34 < smw> http://en.wikipedia.org/wiki/Signal_(computing) 02:34 < smw> yes 02:34 < smw> a signal is an async callback 02:34 < chomp> of course none of this has any bearing on the fact that code which chooses not to be aware of external signals will not be aware of external signals 02:34 < chomp> :) 02:35 < smw> chomp, maybe it would be possible to implement a signal system in go! lol 02:36 < chomp> you mean like a ... channel?! 02:36 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has joined #go-nuts 02:36 < smw> chomp, lol... 02:37 -!- ancientlore [~ancientlo@ip68-110-238-176.dc.dc.cox.net] has joined #go-nuts 02:44 -!- sniper506th [~sniper506@cpe-098-122-081-186.sc.res.rr.com] has quit [Quit: Leaving...] 02:46 < kevlar> Go already has signal handling. 02:46 < crazy2be> hey @ancientlore 02:46 < ancientlore> hey, what's up 02:46 < kevlar> KILL and STOP can't be trapped, but TERM and TSTP (which are intended to be handled) can be 02:47 < crazy2be> kevlar: Yes, but it seems to be impossible to specify a signal to not be handled 02:47 < kevlar> if a program doesn't die when you KILL it, that's because it's locked in a kernel syscall; if/when it completes, it will be stopped. 02:47 < kevlar> crazy2be: in Go, yes, but it's easy to emulate the default behavior 02:47 < crazy2be> e.g. to specify which signals you want to handle 02:48 < kevlar> that's because signal setup needs to be done in init() before you can specify what signals to handle 02:48 < kevlar> so they're all sent down signal.Incoming as soon as you import "os/signal" 02:48 < crazy2be> yeah 02:48 < kevlar> I have code to do ^Z ^C and ^\ if you want. 02:48 < chomp> which caused me a great deal of pain the first time i started playing around with it :) 02:48 -!- nannto [~nanto@pee5b70.tokyff01.ap.so-net.ne.jp] has quit [Read error: Connection reset by peer] 02:49 < kevlar> ^Z took a while to figure out, lol. 02:49 < kevlar> hmm, I should add it to go-wiki. 02:49 < crazy2be> go-wiki? 02:49 < kevlar> http://go-wiki.googlecode.com/ 02:49 < kevlar> it's the official unofficial go wiki, lol 02:50 < chomp> ^Z backgrounds the process doesnt it 02:50 -!- nannto [~nanto@pee5b70.tokyff01.ap.so-net.ne.jp] has joined #go-nuts 02:50 < kevlar> chomp: no, it sends SIGTSTP 02:50 < kevlar> which, by default, goes unhandled and causes your shell to suspend (STOP) your process 02:50 < chomp> ah right. 02:50 < crazy2be> cool 02:51 < crazy2be> although i'm not sure how it's 02:51 < kevlar> so the trick within your app to emulate ^Z is to SIGSTOP your own PID 02:51 < crazy2be> "unofficial" 02:51 < chomp> aha 02:51 < crazy2be> because it's members as all @golang.org 02:51 < crazy2be> *are 02:51 < crazy2be> I just can't type today :P 02:51 < kevlar> crazy2be: everyone who is in the CONTRIBUTORS file has edit access to the wiki 02:52 < chomp> ooohhh 02:52 * chomp goes and changes everything 02:52 < smw> really? sweet 02:52 < smw> time to start editing stuff :-) 02:52 < kevlar> I thought they sent out an email. 02:53 < chomp> maybe, i only just had something committed last week 02:54 < crazy2be> chomp: What did you commit? 02:54 -!- Nitro [~Nitro@unaffiliated/nitro] has quit [Ping timeout: 244 seconds] 02:54 < chomp> just the start of a patch to syscall, to add tty related support to StartProcess 02:55 -!- kfmfe04 [~kfmfe04@host-58-114-183-56.dynamic.kbtelecom.net] has quit [Ping timeout: 255 seconds] 02:55 < chomp> only changed a code generation script so far; have to wait on its outputs to accumulate 02:57 < smw> sweet, I do have access to edit the wiki :-D 02:58 < chomp> wonder if i should attempt to get go building on this windows box >.> 02:58 < chomp> seems windows go could use more love 02:59 < smw> for v := range myChannel {}. Will that block if it stops getting answers from the channel? 02:59 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has quit [Ping timeout: 255 seconds] 03:00 < smw> nm, answer is in go spec 03:05 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has joined #go-nuts 03:05 < ancientlore> any thoughts on the go packages out there for mongodb? 03:06 < chomp> perhaps you want https://github.com/mikejs/gomongo :) 03:07 < chomp> aptly named 03:07 < ancientlore> yeah, but then the go blog featured mgo - curious who they compare 03:07 < kevlar> ancientlore: check out http://godashboard.appspot.com/package 03:08 < kevlar> it's always a good idea to know the popular packages, as it means they're probably well supported and/or likely to compile with the latest Go release or weekly 03:09 < ancientlore> they are both fairly popular it seems - I'll have to check both out 03:18 < ancientlore> totally unrelated question. say I am programming using a few system calls for windows - and I used one that blocks the OS thread, like WaitForMultipleObjects(). Does the go runtime gracefully schedule other goroutines around that, so that it only blocks the goroutine making the call? I know go multiplexes goroutines on some number of OS threads. 03:19 < exch> it does detect blocking goroutines and rearranges things accordingly. Not sure if the windows implementation does that though 03:19 < exch> But it should 03:22 < ancientlore> ok. is there anything you need to do when you're going to make a blocking system call (one the blocks the OS thread as well as the goroutine), or you just do it and let go figure it out? 03:23 < ancientlore> or maybe I should just try it and see what happens ;-) 03:27 -!- niemeyer [~niemeyer@89.127.177.74] has joined #go-nuts 03:30 < exch> Just go with it and only worry about it if it actually ives you truble. That usually works for me :) 03:30 < exch> *gives *trouble 03:30 < chomp> does make me wonder how the scheduler and threads are managed 03:34 < chomp> http://is.gd/loIR46 03:34 < chomp> "when a goroutine enters a potentially blocking system call, the scheduler will start running other goroutines on a different OS thread." 03:36 < kevlar> it's implemented by turning blocking system calls into either (a) an OS thread or (b) an epoll/kqueue 03:36 < kevlar> things like sleep() are done with (a), things like I/O are done with (b) 03:36 < kevlar> which is only really important if you're doing something in tons of goroutines that might be in the (a) category 03:37 < kevlar> (if you're doing that with sleep(), you probably should switch to timer.After) 03:37 -!- tgall_foo [~tgall@206.9.88.154] has joined #go-nuts 03:39 -!- franciscosouza [~francisco@187.105.24.41] has quit [Read error: Connection reset by peer] 03:48 -!- franciscosouza [~francisco@187.105.24.41] has joined #go-nuts 03:52 < ancientlore> interesting. so in theory I shouldn't have to worry too much...but should be careful too. 03:54 < crazy2be> ancientlore: working on winnotify? :P 03:56 -!- Skola [~bas@5352A3FB.cm-6-3c.dynamic.ziggo.nl] has joined #go-nuts 03:56 -!- wchicken [~chicken@c-71-235-58-74.hsd1.ct.comcast.net] has joined #go-nuts 03:57 < ancientlore> hehe, just getting the info ready in case I want to use FindFirstChangeNotification, etc. 03:57 < Skola> is there a specific kind of programs Go is aimed at / made for? 03:57 < crazy2be> Skola: system programs 03:57 < crazy2be> but it's really good at everything imo 03:58 < crazy2be> er, almost everything 03:58 < Skola> ok, I do complex algorhytms in Haskell, command line stuff in Python, servers in Node.js 03:58 < Skola> where would Go fit in? 03:59 < crazy2be> I use it for command and server stuff 03:59 < crazy2be> because of the builtin multithreading 03:59 < Skola> where does it stand in terms of performance compared to C/C++? 03:59 < crazy2be> depends what you're doing 04:00 < Skola> where does it shine? 04:00 < crazy2be> expect it to be slower than C/C++, but faster than node.js 04:00 < chomp> it fits in as a general purpose language that balances performance with productivity 04:01 -!- fluffle [~camelid@s.pl0rt.org] has quit [Read error: Connection reset by peer] 04:01 < chomp> anything i would write in C or C++, i tend to want to write in go now 04:01 -!- fluffle [~camelid@s.pl0rt.org] has joined #go-nuts 04:01 < crazy2be> I like the tools 04:01 < crazy2be> like gofmt, godoc, gofix 04:01 < crazy2be> goinstall 04:01 < Skola> ja heard good things about the tools 04:02 < crazy2be> also it's really almost always logical what it does 04:02 < crazy2be> unlike javascript which has quite a few idiosyncrocies 04:02 < chomp> and it's a tiny language. it doesn't have a million marginally useful features. 04:02 < kuroneko> hmm. 04:02 < Skola> what about libs? 04:02 < crazy2be> lots of libs installable with goinstall 04:03 < crazy2be> what do you need one for? 04:03 < kuroneko> I'm busy trying to fix up some go compiler packages right now - does anyone here know how to amend the expected failures list? 04:03 < Skola> not sure yet :P 04:03 < crazy2be> there's a list at http://godashboard.appspot.com/package 04:03 < Skola> it depends what I'd be using it for 04:03 < crazy2be> common/recently used ones 04:03 < Skola> which I'm not clear about yet 04:03 < Skola> ok thanks :) 04:04 -!- ancientlore [~ancientlo@ip68-110-238-176.dc.dc.cox.net] has quit [Quit: ~ Trillian Astra - www.trillian.im ~] 04:05 < crazy2be> node is pretty nice because of all the community support 04:05 < Skola> yeah it is 04:05 < chomp> too bad it's js D: 04:05 < crazy2be> heh 04:05 < Skola> hah yeah 04:05 < crazy2be> yeah 04:05 < crazy2be> javascript never ends up in good code for me 04:05 < crazy2be> maybe I just don't have enough practice 04:06 < Skola> CoffeeScript and functional libraries make writing it quite enjoyable though, believe it or not 04:06 < chomp> it's an ok language and there are things i do like about it... but it's like python for me in that it feels so idontknowtherightword 04:06 < crazy2be> but my go code is almost always nicer than my javascript 04:06 < chomp> mushy 04:06 < chomp> crazy2be, i think it has to be the typing 04:06 < Skola> yes I'd be programming in Haskell if the web frameworks were more mature 04:06 < chomp> i just can't be comfortable with weak types 04:06 < crazy2be> yeah *shudder* 04:07 < chomp> haskell also has its performance tradeoffs does it not 04:07 < crazy2be> works o.k. for a small codebase 04:07 < Skola> Haskell performance is pretty amazing 04:07 < crazy2be> but anything too big 04:07 -!- rejb [~rejb@unaffiliated/rejb] has quit [Disconnected by services] 04:07 < Skola> the web frameworks are lightning fast 04:07 < Skola> but not very mature yet 04:07 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts 04:07 < chomp> thinking more in terms of computations 04:07 < crazy2be> neither are the go ones :P 04:07 < Skola> and for just raw performance its about 1 to 3x C 04:07 < chomp> though i guess that depends largely on how you write your code 04:08 < crazy2be> anyway night all 04:08 < Skola> gn 04:08 < crazy2be> good luck with go 04:08 < chomp> people seem to like web.go, might want to peek at that 04:08 < Skola> cheers 04:08 < Skola> I will chomp, thanks 04:08 < crazy2be> personally I use the builtin http library and a bunch of custom packages :P 04:09 < crazy2be> some of them are at http://github.com/crazy2be 04:09 < chomp> same, so far. 04:09 < Skola> will have a look :) 04:09 < chomp> though ive been playing more with websocket than anything else 04:10 < Skola> I like the way Go syntax looks 04:10 < Skola> it's often telling 04:11 < Skola> what's the main tutorial? the one at golang.org? 04:11 < Skola> it's for programmers familiar with C/C++ 04:11 < chomp> http://golang.org/doc/effective_go.html is the most often cited one 04:11 < Skola> My C isn't fantastic 04:11 < chomp> there's also http://golang.org/doc/go_tutorial.html 04:11 < crazy2be> night again 04:12 < chomp> night crazy2be 04:12 < Skola> gn 04:12 < Skola> chomp which one would you recommend 04:12 < chomp> i'd probably start with tutorial 04:12 < chomp> and keep http://golang.org/doc/go_spec.html handy 04:12 < Skola> ok 04:12 < chomp> the spec is quite small 04:12 < kuroneko> the golang basic tutorial should be enough to get you started, then effective go should cover most of the gaps for long enough for you to get comfortable with working from the spec + pkg doc 04:13 < chomp> as far as language specs go 04:13 < Skola> chomp yeah that's very small 04:13 < Skola> kirneko, alright thanks 04:13 < kuroneko> you don't really need to know C for any of that unless you want to play with cgo, which I don't recommend :) 04:14 < chomp> (yet) ;) 04:14 < kuroneko> [the first thing I did when I was playing about with go was use cgo >_< wasn't a good idea :)] 04:14 < chomp> though i guess not being too familiar with C does preclude cgo usage 04:15 < kuroneko> but don't let the C-like syntax or references make you think you need ot understand C to understand go. 04:15 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has quit [Remote host closed the connection] 04:15 < kuroneko> you really don't. 04:15 < Skola> what I'm seeing in the tutorial doesn't look at all scary 04:15 < chomp> heh probably better not to honestly - the similarities can be deceiving 04:16 < kuroneko> the similarities are a nightmare >_< 04:16 < kuroneko> I still get name/type order wrong occasionally 04:16 < kuroneko> it's HARD to untrain 15 years of C experience 04:16 < chomp> big fan of the go ordering now; it was a nuisance at first 04:17 < kuroneko> oh, I don't think it's an issue - it's just a great way to let old-timers shoot-themselves in the foot repeatedly :) 04:17 < kuroneko> fortunately it is compiled, so it's easily detected and fixed :) 04:17 -!- crazy2be [~crazy2be@S01060012171a573b.cg.shawcable.net] has quit [Ping timeout: 276 seconds] 04:18 < kuroneko> ah, awesome. Finally got my golang package to build under pbuilder. :) 04:18 * kuroneko discovered NOTEST 04:18 < Skola> a language that comes with vim files 04:18 < Skola> excellent 04:19 < chomp> ^ 04:19 < chomp> careful though if you use autoindent/cindent 04:20 < chomp> it's still pretty wonky because there is just no way to make vim do the right thing in some cases 04:20 < chomp> it particularly trips up on := assignment lines 04:20 < Skola> ok 04:25 -!- ccc1 [~Adium@140.109.98.187] has quit [Quit: Leaving.] 04:25 < Skola> should I go with the architecture specific compilers, or should I get gccgo? 04:26 < Skola> I mean to start out with 04:28 -!- dreadlorde [~dreadlord@c-68-42-82-10.hsd1.mi.comcast.net] has quit [Ping timeout: 246 seconds] 04:28 < chomp> ive never used gccgo 04:28 < chomp> hard to say 04:32 < Skola> Go code seems pretty terse 04:32 < Skola> I like it 04:32 -!- sacho [~sacho@79-100-61-93.btc-net.bg] has joined #go-nuts 04:32 < kuroneko> dont' use gccgo unless you've got a good reason to, or you like building compilers. 04:33 < Skola> heh ok 04:33 < Skola> could one write: if someBool { // do something }? 04:34 < Skola> or is it mandatory to use newlines here? 04:34 < chomp> you can do that 04:34 < Skola> but it's bad style? 04:34 < chomp> eh not necessarily 04:35 < Skola> ok 04:35 < chomp> nothing wrong with it imho 04:36 < Skola> is there a style guide? 04:37 < chomp> gofmt :) 04:37 < chomp> pretty much any go code you'll ever come across is expressed in exactly the same style 04:38 < Skola> wow that's nice 04:38 < chomp> but gofmt is a tool which formats go code for you automatically 04:38 < Skola> gofmt :[] 04:38 < Skola> so tabwidth of 8 is the standard? 04:39 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has joined #go-nuts 04:39 < chomp> i guess so 04:39 < chomp> i've always been partial to 4, but eh 04:39 < kuroneko> yes. 04:39 -!- niemeyer [~niemeyer@89.127.177.74] has quit [Ping timeout: 240 seconds] 04:39 < kuroneko> there is a general philosphy that if you're lines are getting too long with tabwidth 8, you should be breaking down your code more. 04:40 < kuroneko> That philsophy is not specific to go in the slightest. 04:41 < Skola> I've seen Linus propound it 04:41 < chomp> that's fair, and i'm not particularly religious about my tab stops 04:41 < chomp> but i like ts=4 :) 04:41 < Skola> node apps/libs use 2 04:41 < Skola> but the node source (C++) uses 8 04:41 < Skola> :[] 04:42 < chomp> anything less than 4 makes me cringe 04:42 < Skola> yes I think the node standard is unfortunate 04:42 < chomp> guess they figured js is already pretty goddamn ugly, why stop making it look worse 04:43 < Skola> it does look like hell with js 04:43 < Skola> but with CoffeeScript it's ok 04:43 < chomp> i will have to look at this coffeescript 04:44 < Skola> you should 04:44 < chomp> it does look pretty 04:44 < Skola> I completely hated JS 04:44 < Skola> but CS is really nice 04:44 < Skola> it's not _just_ syntax 04:45 -!- ijknacho [~goofy@cpe-72-190-64-3.tx.res.rr.com] has joined #go-nuts 04:45 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has joined #go-nuts 04:45 < chomp> heh i look at the ? operator and i think to myself, 'if(typeof foo != "undefined" && foo != null)' should never even be something one would want to express in a language 04:46 < Skola> I know 04:46 < Skola> so that's why CS takes care of it for you :P 04:46 < chomp> heh it's nice that the operator is there in coffeescript, but so so very unfortunate that it would ever need to be 04:46 < Skola> yeah 04:47 < Skola> that if statement you wrote would (disregarding the ? operator for a sec) look like this in CoffeeScript: 04:47 < chomp> foo? 04:47 < Skola> if typeof foo isnt "undefined" and foo isnt null 04:47 < chomp> ah 04:48 < chomp> now it looks like python 04:48 < Skola> hah 04:50 < Skola> and you can do things like: compute x for x in xs when x isnt false and flag isnt "set" 04:50 < Skola> which you may or may not hate 04:50 -!- zozoR [~Morten@2906ds2-arno.0.fullrate.dk] has joined #go-nuts 04:52 < Skola> or for example project euler (yay) problem 1: (last one I'll paste) 04:52 < Skola> (x for x in [0..999] when x % 3 is 0 or x % 5 is 0).reduce (xs, x) -> xs + x 04:53 < chomp> heh reminds me of haskell code 04:53 < Skola> that would be my fault (or accomplishment) 04:53 < Skola> but yeah, it does 04:54 < chomp> i started learning haskell a few months ago and got distracted by go 04:54 < chomp> very nice language 04:54 < chomp> and very nice type system 04:54 < chomp> will have to play with it some more soon 04:58 < Skola> same thing in Haskell: sum [x | x <- [1..999], mod x 3 == 0 || mod x 5 == 0] 04:58 < Skola> though there are about 20 other ways to write that ;[] 04:59 < chomp> oh wow somehow i totally missed the coffeescript lambda syntax 04:59 < chomp> which looks like C# 04:59 < chomp> that's very cool 04:59 < Skola> yeah! 04:59 -!- sacho [~sacho@79-100-61-93.btc-net.bg] has quit [Ping timeout: 240 seconds] 05:01 -!- sacho [~sacho@95-42-77-124.btc-net.bg] has joined #go-nuts 05:04 < zozoR> i once tried to learn ruby, but i did not get very far until i saw table or whatever that showed me how ruby can do the same thing in 20 different ways 05:05 < zozoR> at that point i quit learning ruby. 05:05 < chomp> that soudns exactly right. 05:05 < zozoR> 20 ways of doing the same thing asks for disaster 05:06 < Skola> Well in Haskell it's not _the same thing_, I didn't put it very well 05:06 < zozoR> ^^ 05:07 < Skola> There's always a best way 05:07 < Skola> it's not perl 05:08 < chomp> even if it were true for haskell it scores major points for being beautiful 05:08 < Skola> yeah it is very beautiful and elegant 05:19 -!- Skola [~bas@5352A3FB.cm-6-3c.dynamic.ziggo.nl] has quit [Ping timeout: 255 seconds] 05:20 -!- edsrzf [~edsrzf@122-61-221-144.jetstream.xtra.co.nz] has joined #go-nuts 05:21 -!- Skola [~bas@5352A3FB.cm-6-3c.dynamic.ziggo.nl] has joined #go-nuts 05:31 -!- Guest74132 [~john@c-71-202-154-251.hsd1.ca.comcast.net] has joined #go-nuts 05:32 -!- cafesofie [~cafesofie@ool-18b97779.dyn.optonline.net] has quit [Remote host closed the connection] 05:34 -!- bakedb [~kel@cpc4-lea21-0-0-cust755.6-3.cable.virginmedia.com] has joined #go-nuts 05:35 -!- wrtp [~rog@pD95E7F5C.dip.t-dialin.net] has joined #go-nuts 05:42 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Read error: Connection reset by peer] 05:43 -!- ExtraSpice [XtraSpice@78-57-204-104.static.zebra.lt] has joined #go-nuts 05:45 -!- Guest74132 [~john@c-71-202-154-251.hsd1.ca.comcast.net] has quit [Quit: leaving] 05:46 -!- meanburr1to920 [~john@c-71-202-154-251.hsd1.ca.comcast.net] has joined #go-nuts 05:46 -!- meanburr1to920 [~john@c-71-202-154-251.hsd1.ca.comcast.net] has quit [Client Quit] 05:48 -!- chomp [~chomp@c-67-186-35-69.hsd1.pa.comcast.net] has quit [Quit: Leaving] 05:51 -!- meanburr1to920 [~john@c-71-202-154-251.hsd1.ca.comcast.net] has joined #go-nuts 05:55 -!- awidegreen [~quassel@h-170-226.A212.priv.bahnhof.se] has joined #go-nuts 05:56 -!- wchicken [~chicken@c-71-235-58-74.hsd1.ct.comcast.net] has quit [Read error: Operation timed out] 06:01 -!- meanburr1to920 [~john@c-71-202-154-251.hsd1.ca.comcast.net] has quit [Quit: leaving] 06:04 -!- meanburr1to920 [~john@c-71-202-154-251.hsd1.ca.comcast.net] has joined #go-nuts 06:05 -!- kfeng [~kfeng@host-58-114-183-56.dynamic.kbtelecom.net] has quit [Quit: kfeng] 06:05 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-151-44.clienti.tiscali.it] has joined #go-nuts 06:06 -!- Skola [~bas@5352A3FB.cm-6-3c.dynamic.ziggo.nl] has quit [Ping timeout: 250 seconds] 06:07 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 06:10 -!- Skola [~bas@5352A3FB.cm-6-3c.dynamic.ziggo.nl] has joined #go-nuts 06:12 < magn3ts> so if I've already switched to tip... is hg pull update good enough? 06:14 -!- franciscosouza_ [~francisco@187.105.0.229] has joined #go-nuts 06:16 -!- franciscosouza [~francisco@187.105.24.41] has quit [Ping timeout: 252 seconds] 06:27 -!- tvw [~tv@e176005149.adsl.alicedsl.de] has joined #go-nuts 06:27 -!- noodles775 [~michael@canonical/launchpad/noodles775] has joined #go-nuts 06:29 -!- bakedb [~kel@cpc4-lea21-0-0-cust755.6-3.cable.virginmedia.com] has quit [Ping timeout: 255 seconds] 06:33 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has joined #go-nuts 06:44 -!- napsy [~luka@193.2.66.6] has joined #go-nuts 06:44 -!- piranha [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts 06:48 -!- meanburr1to920 [~john@c-71-202-154-251.hsd1.ca.comcast.net] has quit [Quit: leaving] 06:52 -!- awidegreen [~quassel@h-170-226.A212.priv.bahnhof.se] has quit [Ping timeout: 255 seconds] 06:53 -!- alexandere [~alexander@eijg.xs4all.nl] has joined #go-nuts 07:02 -!- franciscosouza [~francisco@187.105.0.229] has quit [Read error: Connection reset by peer] 07:04 -!- iwinulose [~charlesdu@c-67-188-13-8.hsd1.ca.comcast.net] has quit [Quit: iwinulose] 07:04 -!- franciscosouza [~francisco@187.105.0.229] has joined #go-nuts 07:04 -!- iwinulose [~charlesdu@c-67-188-13-8.hsd1.ca.comcast.net] has joined #go-nuts 07:10 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts 07:13 -!- tvw [~tv@e176005149.adsl.alicedsl.de] has quit [Remote host closed the connection] 07:22 -!- napsy [~luka@193.2.66.6] has quit [Quit: Lost terminal] 07:26 -!- karlom [d39cb80a@gateway/web/freenode/ip.211.156.184.10] has joined #go-nuts 07:34 -!- temoto [~temoto@95-26-169-117.broadband.corbina.ru] has quit [Ping timeout: 246 seconds] 07:34 -!- Slant [~scott@124-168-223-48.dyn.iinet.net.au] has joined #go-nuts 07:35 -!- napsy [~luka@193.2.66.6] has joined #go-nuts 07:38 -!- kfmfe04 [~kfmfe04@60-251-136-139.HINET-IP.hinet.net] has joined #go-nuts 07:40 -!- jemeshsu [~jemeshsu@bb220-255-88-127.singnet.com.sg] has quit [Read error: Connection reset by peer] 07:41 -!- jemeshsu [~jemeshsu@bb121-6-26-212.singnet.com.sg] has joined #go-nuts 07:44 -!- bakedb [~kel@188.28.234.76.threembb.co.uk] has joined #go-nuts 07:47 < cenuij> yeah hg update release or hg update weekly for less stable tree 07:49 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has left #go-nuts [] 07:51 -!- Slant [~scott@124-168-223-48.dyn.iinet.net.au] has quit [Quit: Slant] 07:52 -!- arun_ [~arun@unaffiliated/sindian] has quit [Ping timeout: 255 seconds] 07:54 < magn3ts> I'm having a heck of a time getting the vim scripts installed properly. :/ 07:54 < magn3ts> I have syntax highliting going for go... but still nothing is helping with indent 07:59 < dforsyth> setting autoindent doesnt do what you want? 08:01 -!- pyrhho [~pyrhho@host-92-27-75-48.static.as13285.net] has joined #go-nuts 08:01 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the connection] 08:03 < magn3ts> I got it now. 08:03 < magn3ts> I mixed up the ln syntax and had broken symbolic links, like a doofus 08:06 < magn3ts> Tabs are convention? 08:06 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts 08:10 < Queue29> magn3ts: gofmt will enforce tabs 08:10 < magn3ts> :[ 08:11 < magn3ts> okay 08:11 < Queue29> after you use it for a while you'll be more like :] 08:11 < magn3ts> I had just recently fallen in love with 3 or 4 space indents and brace on new line style. 08:12 < magn3ts> Now I'm abandoning both. :o how forgiving of input code is gofmt I wonder 08:18 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|] 08:22 < cenuij> magn3ts: just set your editor to display tabs at 4 spaces width! problem solved ;) 08:22 -!- wrtp [~rog@pD95E7F5C.dip.t-dialin.net] has quit [Quit: wrtp] 08:22 < cenuij> gofmt defaults to spacing fields etc with spaces, so don't worry about that 08:26 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 08:29 -!- fvbommel [~fvbommel_@86.86.15.250] has quit [Ping timeout: 276 seconds] 08:29 < magn3ts> I don't understand the fibonacci example. I feel like I'm missing something obvious. 08:34 < edsrzf> magn3ts: The one that's in the playground? 08:34 < magn3ts> yes 08:34 < edsrzf> Are you familiar with closures? 08:34 < magn3ts> I thought I was. I'm familiar with closures in javascript 08:35 < edsrzf> Closures in JavaScript are pretty similar to closures in Go. 08:35 -!- tvw [~tv@212.79.9.150] has joined #go-nuts 08:35 < edsrzf> I think the same example would work if modified for JavaScript 08:35 < magn3ts> I don't understand the wiring regarding the inner return 08:36 < magn3ts> is it a closure automatically due to the syntax? 08:36 < edsrzf> Yes 08:36 < magn3ts> The func() int part? 08:37 < edsrzf> The fact that it's used as an expression and that it doesn't have a name makes it a closure 08:38 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the connection] 08:38 < magn3ts> I think I understand now. I will play around. Thanks. 08:39 -!- cenuij [~cenuij@184.15.8.109.rev.sfr.net] has joined #go-nuts 08:39 -!- cenuij [~cenuij@184.15.8.109.rev.sfr.net] has quit [Changing host] 08:39 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts 08:39 -!- wrtp [~rog@pD95E7F5C.dip.t-dialin.net] has joined #go-nuts 08:40 -!- wrtp [~rog@pD95E7F5C.dip.t-dialin.net] has quit [Client Quit] 08:41 -!- DisposaBoy [~DisposaBo@79.142.65.19] has quit [Ping timeout: 258 seconds] 08:41 -!- edsrzf [~edsrzf@122-61-221-144.jetstream.xtra.co.nz] has quit [Remote host closed the connection] 08:42 -!- sebastianskejoe [~sebastian@188.114.142.217] has joined #go-nuts 08:42 -!- DisposaBoy [~DisposaBo@109.123.79.26] has joined #go-nuts 08:43 -!- TheSeeker [riiight@99-153-250-110.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 240 seconds] 08:49 -!- TheSeeker [riiight@99-153-250-110.lightspeed.irvnca.sbcglobal.net] has joined #go-nuts 09:05 -!- virtualsue [~chatzilla@nat/cisco/x-jfgzdkkgpciphhof] has joined #go-nuts 09:14 -!- kfmfe04 [~kfmfe04@60-251-136-139.HINET-IP.hinet.net] has quit [Quit: kfmfe04] 09:15 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has quit [Ping timeout: 264 seconds] 09:19 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has joined #go-nuts 09:30 -!- alexandere [~alexander@eijg.xs4all.nl] has quit [Quit: alexandere] 09:35 -!- fvbommel [~fvbommel_@131.155.247.122] has joined #go-nuts 09:38 * cenuij stares blankly at his monitor 09:39 < cenuij> "cannot use font (type *truetype.Font) as type *truetype.Font in return argument" 09:39 < cenuij> ¬_¬ 09:39 -!- ronnyy [~quassel@p4FF1C50C.dip0.t-ipconnect.de] has joined #go-nuts 09:42 < zozoR> lol :D 09:47 -!- fabled [~fabled@83.145.235.194] has joined #go-nuts 09:54 < zippoxer> lol; there's a secret hotkey in http://golang.org/doc/play/ 09:54 < zippoxer> shift + enter 09:54 < zippoxer> it means google uses it too 09:55 -!- fvbommel [~fvbommel_@131.155.247.122] has quit [Ping timeout: 276 seconds] 10:18 < zozoR> the golang faq is funny ^^ the guys answer a lot of questions about features or the lack of them with some form of reasoning and then ending the line with "also it is way easier to make the compiler this way" 10:18 < zozoR> :D 10:21 -!- pyrhho [~pyrhho@host-92-27-75-48.static.as13285.net] has quit [Ping timeout: 244 seconds] 10:27 -!- sacho [~sacho@95-42-77-124.btc-net.bg] has quit [Ping timeout: 276 seconds] 10:32 -!- Slant [~scott@124-168-223-48.dyn.iinet.net.au] has joined #go-nuts 10:34 -!- franciscosouza [~francisco@187.105.0.229] has quit [Read error: Connection reset by peer] 10:35 -!- ronnyy [~quassel@p4FF1C50C.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 10:39 -!- ronnyy [~quassel@p4FF1C50C.dip0.t-ipconnect.de] has joined #go-nuts 10:43 -!- ronnyy [~quassel@p4FF1C50C.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 10:44 -!- franciscosouza [~francisco@187.105.0.229] has joined #go-nuts 10:47 -!- tvw [~tv@212.79.9.150] has quit [Ping timeout: 255 seconds] 10:54 -!- Project-2501 [~Marvin@82.84.94.230] has joined #go-nuts 10:55 -!- alehorst [~alehorst@189.58.23.72.dynamic.adsl.gvt.net.br] has joined #go-nuts 10:57 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-151-44.clienti.tiscali.it] has quit [Read error: Operation timed out] 10:59 -!- ttblrs_ [U2FsdGVkX1@order.stressinduktion.org] has quit [Ping timeout: 240 seconds] 10:59 -!- kfmfe04 [~kfmfe04@NK219-91-85-120.adsl.dynamic.apol.com.tw] has joined #go-nuts 11:00 -!- ttblrs [~hannes@order.stressinduktion.org] has joined #go-nuts 11:02 -!- iwinulose [~charlesdu@c-67-188-13-8.hsd1.ca.comcast.net] has quit [Quit: iwinulose] 11:10 -!- zcram [~zcram@78-28-69-30.cdma.dyn.kou.ee] has joined #go-nuts 11:13 -!- pyrhho [~pyrhho@host-92-27-75-48.static.as13285.net] has joined #go-nuts 11:20 -!- gnuvince|work [8e544424@gateway/web/freenode/ip.142.84.68.36] has joined #go-nuts 11:24 -!- pyrhho [~pyrhho@host-92-27-75-48.static.as13285.net] has quit [Quit: pyrhho] 11:26 -!- pyrhho [~pyrhho@host-92-27-75-48.static.as13285.net] has joined #go-nuts 11:36 -!- flaguy48 [~gmallard@user-0c6s350.cable.mindspring.com] has joined #go-nuts 11:37 -!- ment [thement@ibawizard.net] has joined #go-nuts 11:39 -!- karlom [d39cb80a@gateway/web/freenode/ip.211.156.184.10] has quit [Ping timeout: 252 seconds] 11:39 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has quit [Ping timeout: 608 seconds] 11:40 -!- Project_2501 [~Marvin@82.84.75.66] has joined #go-nuts 11:41 -!- franciscosouza [~francisco@187.105.0.229] has quit [Quit: franciscosouza] 11:42 -!- franciscosouza [~francisco@187.105.0.229] has joined #go-nuts 11:43 -!- franciscosouza [~francisco@187.105.0.229] has quit [Client Quit] 11:43 -!- Project-2501 [~Marvin@82.84.94.230] has quit [Ping timeout: 240 seconds] 11:51 -!- tvw [~tv@212.79.9.150] has joined #go-nuts 11:52 -!- prip [~foo@host37-133-dynamic.42-79-r.retail.telecomitalia.it] has quit [Ping timeout: 258 seconds] 12:02 -!- tncardoso [~thiagon@150.164.2.20] has joined #go-nuts 12:09 -!- mattn_jp [~mattn@112-68-51-161f1.hyg1.eonet.ne.jp] has joined #go-nuts 12:10 -!- kfmfe04 [~kfmfe04@NK219-91-85-120.adsl.dynamic.apol.com.tw] has quit [Quit: kfmfe04] 12:13 < str1ngs> how do I test if err is ENOENT 12:14 < str1ngs> ie with os.Stat 12:16 -!- franciscosouza [~francisco@201.7.186.67] has joined #go-nuts 12:25 -!- Nitro [~Nitro@unaffiliated/nitro] has joined #go-nuts 12:26 < skelterjohn> this came up a few days ago - you can assert it to an *os.PathError and look at the Err field, which can be asserted to something else and compared to syscall.ENOENT 12:27 < skelterjohn> i don't remember what the type is though, i'd use Printf("%T", thePathErr.Err) to find it 12:27 < str1ngs> PathError is right 12:27 < str1ngs> but assert I'm having trouble with 12:27 < skelterjohn> but PathError's Err field 12:27 < skelterjohn> don't remember what that one is 12:27 < str1ngs> PatheError.Error 12:27 < skelterjohn> what its type is, when returned from os.Stat =p 12:28 < skelterjohn> since inside PathError it is an interface type 12:28 < skelterjohn> <- going to work 12:29 < str1ngs> ah I think this is the issue then syscall.ENOENT .. checking 12:31 -!- fvbommel [~fvbommel_@wlan-245125.nbw.tue.nl] has joined #go-nuts 12:36 -!- fvbommel [~fvbommel_@wlan-245125.nbw.tue.nl] has quit [Ping timeout: 240 seconds] 12:38 < ijknacho> str1ngs: try something like this: fi, err := os.Stat(myFile); if err != nil && err.(*os.PathError).Error == os.ENOENT { fmt.Printf("got ENOENT\n"); } 12:38 < str1ngs> ijknacho: haha thanks I just figured it out too 12:39 < str1ngs> can I assert like that out of a switch? 12:40 < ijknacho> like by using switch err.(type)? I'd think so 12:41 < str1ngs> I'm using switch err.(type) right now 12:41 < str1ngs> I'll try if though, less code 12:43 < str1ngs> if err != nil && err.(*os.PathError).Error == os.ENOENT works better thanks 12:45 -!- mattn_jp [~mattn@112-68-51-161f1.hyg1.eonet.ne.jp] has quit [Ping timeout: 260 seconds] 12:47 -!- Sep102 [~Sep102@c-71-227-179-131.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer] 12:48 -!- Sep102 [~Sep102@c-71-227-179-131.hsd1.wa.comcast.net] has joined #go-nuts 12:49 -!- pharris [~Adium@rhgw.opentext.com] has joined #go-nuts 12:49 -!- goon12 [~goon12@71-87-215-29.dhcp.oxfr.ma.charter.com] has joined #go-nuts 12:51 -!- sebastianskejoe [~sebastian@188.114.142.217] has quit [Quit: Lost terminal] 12:57 -!- goon12 [~goon12@71-87-215-29.dhcp.oxfr.ma.charter.com] has quit [Ping timeout: 264 seconds] 13:01 -!- mattn_jp [~mattn@112-68-51-161f1.hyg1.eonet.ne.jp] has joined #go-nuts 13:01 -!- Project_2501 [~Marvin@82.84.75.66] has quit [Read error: Connection reset by peer] 13:03 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-150-151.clienti.tiscali.it] has joined #go-nuts 13:04 -!- sniper506th [~sniper506@rrcs-70-61-192-18.midsouth.biz.rr.com] has joined #go-nuts 13:15 -!- Katibe [~Katibe@212.174.109.55] has joined #go-nuts 13:17 < Skola> :q 13:17 -!- Skola [~bas@5352A3FB.cm-6-3c.dynamic.ziggo.nl] has quit [Quit: leaving] 13:17 -!- prip [~foo@host134-130-dynamic.42-79-r.retail.telecomitalia.it] has joined #go-nuts 13:17 -!- Katibe [~Katibe@212.174.109.55] has quit [Remote host closed the connection] 13:20 -!- Katibe [~Katibe@212.174.109.55] has joined #go-nuts 13:28 -!- lucian [~lucian@78-86-217-168.zone2.bethere.co.uk] has joined #go-nuts 13:36 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the connection] 13:43 -!- virtualsue [~chatzilla@nat/cisco/x-jfgzdkkgpciphhof] has quit [Quit: ChatZilla 0.9.87 [Firefox 4.0.1/20110413222027]] 13:46 < skelterjohn|work> zippoxer: try updating gb 13:46 -!- alsvidr [~user@2a00:1398:2:4006:21f:16ff:fe28:b064] has joined #go-nuts 13:46 < skelterjohn|work> i fixed that bug a couple days ago 13:47 -!- prip [~foo@host134-130-dynamic.42-79-r.retail.telecomitalia.it] has quit [Ping timeout: 240 seconds] 13:49 -!- photron [~photron@port-92-201-42-18.dynamic.qsc.de] has joined #go-nuts 13:52 -!- DisposaBoy [~DisposaBo@109.123.79.26] has quit [Ping timeout: 240 seconds] 13:53 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has joined #go-nuts 13:56 -!- r_linux [~r_linux@static.200.198.180.250.datacenter1.com.br] has joined #go-nuts 13:58 -!- virtualsue [~chatzilla@nat/cisco/x-riufepoogggttuhe] has joined #go-nuts 13:58 -!- DisposaBoy [~DisposaBo@109.123.79.26] has joined #go-nuts 14:03 -!- ArgonneIntern [82ca0251@gateway/web/freenode/ip.130.202.2.81] has joined #go-nuts 14:25 -!- dgnorton [~dgnorton@97.65.135.112] has joined #go-nuts 14:27 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has joined #go-nuts 14:32 -!- Wiz126 [Wiz@h229.120.232.68.dynamic.ip.windstream.net] has quit [Ping timeout: 240 seconds] 14:32 -!- Wiz126 [Wiz@h229.120.232.68.dynamic.ip.windstream.net] has joined #go-nuts 14:36 -!- fvbommel [~fvbommel_@86.86.15.250] has joined #go-nuts 14:38 < zippoxer> skelterjohn|work: updated, but still it doesn't work well for me. I have one main.go file: http://www.pastie.org/2129326 14:38 < zippoxer> and whenever i compile using gb 14:38 < zippoxer> I get two errors: 14:38 < zippoxer> ./bin/main: line 1: syntax error near unexpected token `newline' 14:38 < skelterjohn|work> you can't have a cgo cmd 14:38 < zippoxer> ./bin/main: line 1: `!<arch>' 14:38 < skelterjohn|work> you can only have cgo packages 14:38 < zippoxer> ohhh. 14:39 < skelterjohn|work> and then your cmd can import the pkg 14:39 < zippoxer> okay 14:39 < skelterjohn|work> BUT that's not a very good error message, is it? 14:39 < skelterjohn|work> can you pastebin me the terminal output? 14:39 < skelterjohn|work> so i can figure out if it's gb's error reporting or something else 14:39 < zippoxer> that's all :P 14:39 < zippoxer> command is: gb 14:39 < zippoxer> output ^^ 14:40 < skelterjohn|work> run gb -v 14:40 < skelterjohn|work> tell me the last command line [stuff in brackets] before the error? 14:40 < skelterjohn|work> i bet it's from the cgo cmd 14:40 < zippoxer> same 14:40 < zippoxer> sec 14:40 < skelterjohn|work> gb -v is "verbose", and reports all command lines used 14:40 < skelterjohn|work> so it shouldn't be the same 14:40 < dgnorton> I'm a go noob and having trouble with a list of structs ... code with err msg at the bottom here - http://pastebin.com/r8eVeUtf 14:41 -!- virtualsue [~chatzilla@nat/cisco/x-riufepoogggttuhe] has quit [Ping timeout: 246 seconds] 14:41 < zippoxer> hey lol 14:41 < zippoxer> the error is when I run the generated executable 14:41 < zippoxer> ~/gotest# ./bin/main 14:41 < skelterjohn|work> dgnorton, you need to use a type assertion 14:41 < zippoxer> that's something I forgot to say.. 14:41 < zippoxer> it's not from the gb compilation 14:41 < dgnorton> B.(i.Value) ? 14:42 < skelterjohn|work> i.Value(*B) 14:42 < skelterjohn|work> i.Value.(*B), i mean 14:42 < skelterjohn|work> dgnorton: also, unless you specifically need a linked list, i don't recommend using container/list 14:42 < skelterjohn|work> if you just need a list you can add things to easily, use a regular slice and the append() built-in function 14:43 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 14:44 < skelterjohn|work> zippoxer: i'm still interested in what gb -v reports. err, clean it first, so actually do "gb -cbv" 14:44 < skelterjohn|work> to do a clean build, verbosely 14:44 < dgnorton> skelterjohn: thx...assertion fixed it 14:45 < dgnorton> skelterjohn: I don't know how many items will be in the list 14:45 -!- sacho [~sacho@90.154.193.207] has joined #go-nuts 14:45 < skelterjohn|work> that's fine - a slice w/ append() is the right way to do that 14:45 < skelterjohn|work> theSlice = append(theSlice, theNewItem) 14:45 < skelterjohn|work> then you won't need to do any type assertions 14:46 < dgnorton> probably my lack of go understanding but that seems less efficient 14:46 < zippoxer> skelterjohn|work: it works with the package structure like you said :) 14:46 < zippoxer> sec 14:47 < skelterjohn|work> dgnorton: append uses the capacity-doubling strategy. a slice has both a length and capacity - allocated data that is not being used 14:48 < skelterjohn|work> if the capacity is great enough, append will copy the new item into that extra space and change length 14:48 < skelterjohn|work> otherwise it will allocate a new array with twice the capacity of the old one, and use it instead. 14:48 < dgnorton> skelterjohn: ok...got it...and that will probably be ok for this scenario 14:49 < skelterjohn|work> O(log n) allocations and O(n) allocated memory, where n is the max length of the list 14:49 < zippoxer> skelterjohn|work: here's what "gb -cbv" says when the cgo part is on main package: http://www.pastie.org/2129376 14:49 < dgnorton> thanks 14:50 < skelterjohn|work> zippoxer: i think it's linking to bin/main the way it would link a package with the name "main" 14:50 -!- virtualsue [~chatzilla@host81-148-52-109.in-addr.btopenworld.com] has joined #go-nuts 14:50 -!- napsy [~luka@193.2.66.6] has quit [Ping timeout: 250 seconds] 14:50 < skelterjohn|work> i must have hardcoded in the requirement that cgo only be for packages, and i should add an error report 14:51 -!- pjacobs [~pjacobs@75-27-133-72.lightspeed.austtx.sbcglobal.net] has joined #go-nuts 14:51 < zippoxer> but still the cgo in main structure reproduce the error ^^^^ 14:51 < zippoxer> ohh ok 14:51 < zippoxer> it doesn't bother me anyway 14:53 < zippoxer> this thing: a, b := abPlease(); a {} 14:54 < zippoxer> works with if, but not with for? 14:54 < zippoxer> I don't understand, they both accept conditions 14:54 < skelterjohn|work> it would be ambiguous with for 14:54 < skelterjohn|work> since for already uses semicolons 14:54 < zippoxer> ohh 14:54 < zippoxer> yeah :P 14:54 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has joined #go-nuts 14:59 -!- tvw [~tv@212.79.9.150] has quit [Remote host closed the connection] 15:02 < smw> http://code.google.com/p/goconf/ compiles now :-). Although the tests are panicking :-\. 15:02 < skelterjohn|work> baby steps :) 15:02 < smw> skelterjohn|work, yep 15:02 -!- Project-2501 [~Marvin@82.84.73.155] has joined #go-nuts 15:02 < smw> when I made this lib, there was no such thing as a panic! 15:02 -!- wchicken [~chicken@c-71-235-58-74.hsd1.ct.comcast.net] has joined #go-nuts 15:02 < smw> Anyways, after I fix this, I need to rewrite it and get rid of the old code from goconfig :-P 15:03 < smw> skelterjohn|work, after fixing all the compiling errors, I saw people had filed bugs describing how to fix each problem. 15:03 < smw> lol 15:04 < skelterjohn|work> hehe 15:04 -!- pjacobs2 [~pjacobs@66.54.185.130] has joined #go-nuts 15:04 < skelterjohn|work> i have thought about turning goargcfg.googlecode.com into a config file reader - as it stands it's a command line arg parser 15:05 < skelterjohn|work> but it uses reflect to populate a struct you give it 15:05 < smw> cool 15:05 < skelterjohn|work> and it does nesting, so things liky -X.Y.Z=123 work 15:05 < smw> ok 15:05 -!- virtualsue [~chatzilla@host81-148-52-109.in-addr.btopenworld.com] has quit [Ping timeout: 255 seconds] 15:05 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-150-151.clienti.tiscali.it] has quit [Ping timeout: 258 seconds] 15:06 -!- pjacobs [~pjacobs@75-27-133-72.lightspeed.austtx.sbcglobal.net] has quit [Read error: Operation timed out] 15:06 < smw> skelterjohn|work, for some reason people are happy with my lib after then get it working. Therefore, the problem must be in the test and not the actual code :-) 15:06 < smw> at least... I hope it is 15:07 -!- ijknacho [~goofy@cpe-72-190-64-3.tx.res.rr.com] has quit [Ping timeout: 258 seconds] 15:11 < smw> skelterjohn|work, got any idea how to debug this? http://paste.pocoo.org/show/421301/ 15:11 -!- virtualsue [~chatzilla@nat/cisco/x-frkjllateydwoxts] has joined #go-nuts 15:11 < skelterjohn|work> besides looking at get.go line 124 and wondering why the index is out of bounds? 15:12 < smw> nope. that sounds like a good idea 15:12 -!- napsy [~luka@88.200.96.18] has joined #go-nuts 15:12 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has joined #go-nuts 15:13 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 15:13 < smw> skelterjohn, the most aweful part is that this use to work! lol 15:13 < smw> skelterjohn, what changed to cause index out of bounds? 15:13 < skelterjohn|work> i'd have to look at the code 15:13 < smw> looking now :-P 15:16 -!- chomp [~chomp@dap-209-166-184-50.pri.tnt-3.pgh.pa.stargate.net] has joined #go-nuts 15:18 -!- dreadlorde [~dreadlord@c-68-42-82-10.hsd1.mi.comcast.net] has joined #go-nuts 15:28 < smw> anyone know how to apply for the beta of go on appengine? 15:32 -!- Slant [~scott@124-168-223-48.dyn.iinet.net.au] has quit [Quit: Slant] 15:33 < kevlar_work> smw, looks like they turned off the trusted tester signup spreadsheet. 15:34 < kevlar_work> read into that what you will ;-). The link has been removed from the Go Language Blog post but not from the original AppEngine blog post. 15:34 -!- virtualsue [~chatzilla@nat/cisco/x-frkjllateydwoxts] has quit [Read error: Connection reset by peer] 15:35 -!- noodles775 [~michael@canonical/launchpad/noodles775] has quit [Quit: leaving] 15:35 -!- virtualsue [~chatzilla@nat/cisco/x-gypngijjkedteudn] has joined #go-nuts 15:40 < smw> ok 15:40 -!- Tv [~Tv@cpe-76-168-227-45.socal.res.rr.com] has joined #go-nuts 15:40 < smw> kevlar, I did not sign up because I did not have a project idea 15:41 < smw> now I do XD 15:41 < smw> kevlar_work, ^ 15:42 < skelterjohn|work> i bet the google group for it has about 10 posts asking this question 15:43 < smw> skelterjohn|work, I just found this https://spreadsheets.google.com/a/ionflux.com/spreadsheet/viewform?formkey=dGJ6LXlIYWk4MjhnM0dubUstUHFKVXc6MQ&ndplr=1 :-\ 15:43 -!- rcrowley [~rcrowley@c-71-202-44-233.hsd1.ca.comcast.net] has joined #go-nuts 15:44 < skelterjohn|work> probably what kevlar_work was referring to 15:44 < smw> yeah 15:45 -!- Queue29 [~Queue29@egress-w.sfo1.yelpcorp.com] has joined #go-nuts 15:47 < ArgonneIntern> interesting read if anyone cares http://blog.golang.org/2011/06/profiling-go-programs.html 15:49 -!- Project_2501 [~Marvin@82.84.91.156] has joined #go-nuts 15:50 -!- jbooth1 [~jay@209.249.216.2] has joined #go-nuts 15:52 -!- Project-2501 [~Marvin@82.84.73.155] has quit [Ping timeout: 260 seconds] 15:54 < smw> ArgonneIntern, thanks 15:54 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-155-41.clienti.tiscali.it] has joined #go-nuts 15:55 < ArgonneIntern> it's interesting, by changing two things they managed to get runtime below c++ equivelant 15:56 < ArgonneIntern> but all it shows is the C compilers are better with maps and go's compilers are better with arrays/slices 15:56 < ArgonneIntern> I think everyone already knew that 15:57 -!- Project_2501 [~Marvin@82.84.91.156] has quit [Ping timeout: 240 seconds] 15:57 < ArgonneIntern> still 50+ seconds to 4 is pretty good 16:00 < KirkMcDonald> In the end he also changed the C++ version to more closely match the optimized Go version. 16:00 < ArgonneIntern> yes 16:01 < ArgonneIntern> which also resulted in the C++ code running faster as well 16:01 < ArgonneIntern> not the same magnitude faster 16:01 < KirkMcDonald> Though not by nearly the same-- yeah. 16:01 < ArgonneIntern> but faster 16:01 < ArgonneIntern> yea, this just means go compilers have a ways to go IMO 16:01 < ArgonneIntern> they will get there, c++ compilers have had a lot more time to develop 16:08 -!- fenicks [~fenicks@log77-3-82-243-254-112.fbx.proxad.net] has quit [Ping timeout: 246 seconds] 16:10 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Remote host closed the connection] 16:11 < Namegduf> It also shows that people writing "papers" on language performance seem to know jack shit in BOTH the cases I've seen. 16:12 * Namegduf grumbles about people who write nicely optimised C(++) and then make no effort at all in the Go version. 16:12 -!- wchicken [~chicken@c-71-235-58-74.hsd1.ct.comcast.net] has quit [Ping timeout: 255 seconds] 16:12 < zippoxer> "cannot use &cases (type *[]*Case) as type []interface { } in function argument" 16:12 < zippoxer> and: "cannot use &cases (type *[]*Case) as type *[]*interface { } in function argument" 16:13 < zippoxer> so what kind of interface will accept *[]*Case? 16:13 < ArgonneIntern> anyone know if anyone is working on bindings for openCL 16:13 < Namegduf> I mean, surely if you're going to write something as presumptious as a "paper", you use a profiler to check that the performance gap isn't just some quirk of how you personally wrote your program, yes? 16:13 -!- napsy [~luka@88.200.96.18] has quit [Ping timeout: 255 seconds] 16:14 < ArgonneIntern> zippoxer: what is Case 16:14 < zippoxer> a struct 16:14 < ArgonneIntern> hmm 16:15 < zippoxer> I tried *[]interface and []*interface too 16:15 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has joined #go-nuts 16:15 < zippoxer> only interface{} works, but than I can't use it as a slice. 16:16 -!- GeertJohan [~Squarc@ip4da06866.direct-adsl.nl] has joined #go-nuts 16:16 < zippoxer> (in the function) 16:16 < Namegduf> "In fact, in Hundt's paper, he explains that the Java program needed just this change to get anything like reasonable performance, but he did not make the same change in the other garbage-collected implementations." 16:16 < Namegduf> WTF? 16:16 < vegai> => Java ftw yay! 16:17 < ArgonneIntern> zipper is cases an array of structs 16:17 < ArgonneIntern> or an array of stuct pointers 16:17 < zippoxer> cases is []*Case 16:18 < zippoxer> but when I pass it to the func with &cases, it's *[]*Case 16:18 < ArgonneIntern> right 16:18 < ArgonneIntern> cause you're sending the address 16:18 < zippoxer> yeah I need the address 16:18 < zippoxer> but 16:18 < zippoxer> the func doesn't accept it! 16:18 < ArgonneIntern> not really 16:18 < zippoxer> y? 16:18 -!- awidegreen [~quassel@h-170-226.A212.priv.bahnhof.se] has joined #go-nuts 16:18 < ArgonneIntern> cause the array is static and will be copied without the & 16:19 < ArgonneIntern> but whats in the array are pointers 16:19 < ArgonneIntern> so you will change your original data 16:19 < zippoxer> I want to re assign the array 16:19 < ArgonneIntern> unless you plan on removing or adding some 16:19 < zippoxer> not it's values 16:19 < ArgonneIntern> ok 16:19 < zippoxer> it will work too without the &? 16:19 < zippoxer> (re-assigning) 16:20 < ArgonneIntern> func (something *[]*Case) doesn't work? 16:20 < zippoxer> it works of course, but I need it to accept more kinds of struct 16:20 < zippoxer> *[]*AnotherStruct 16:20 < zippoxer> etc.. 16:21 < ArgonneIntern> ahh I see 16:21 < zippoxer> func (something interface{}) works, but than something isn't a slice and I can't append to it 16:21 < zippoxer> sad :( 16:22 < ArgonneIntern> can I ask how you would know what interface is coming in if it did work 16:22 < ArgonneIntern> I'm unfamiliar with using interfaces as parameters generically 16:23 < zippoxer> mmm that's my problem actually 16:23 < ArgonneIntern> in C++ you could use typeid if it was pointers to it's parent, but I havn't seen anything like that in go 16:24 < chomp> well you would use a type assertion in this case 16:24 -!- alsvidr [~user@2a00:1398:2:4006:21f:16ff:fe28:b064] has left #go-nuts ["ERC Version 5.3 (IRC client for Emacs)"] 16:24 < ArgonneIntern> does that return an error if it fails? 16:24 < chomp> it can, it has a multivalued version 16:24 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has left #go-nuts [] 16:24 < ArgonneIntern> interesting 16:24 < chomp> foo, ok := value.(InterfaceName) 16:25 < ArgonneIntern> hah well now that, that's settled how do we get it able to pass an &[]*struct as *[]*interface{} 16:26 < zippoxer> we can pass &[]*struct as interface{} 16:26 < chomp> yeahm you just do 16:26 < zippoxer> but than, that interface value isn't a slice :( 16:26 < zippoxer> then* 16:27 < chomp> why does it need to be a slice? 16:27 < ArgonneIntern> prob so he can append 16:27 < zippoxer> so I can append to it :) 16:27 < zippoxer> maybe I found a conversation about that: http://groups.google.com/group/golang-nuts/browse_thread/thread/225fad3b5c6d0321 16:27 < zippoxer> but I gtg for 20 min~ 16:28 < zippoxer> so thanks for the help for now 16:31 < ArgonneIntern> yes perhaps there is no resonable conversion of type []*Case to type []*Interface 16:31 < ArgonneIntern> as the conversation says some ways down 16:31 < magn3ts> Anyone have godag building with go tip? 16:35 < ArgonneIntern> zippoxer: http://research.swtch.com/2009/12/go-data-structures-interfaces.html, bring it in as type interface{} and type it once inside to an array of choice, as chomp suggested. 16:35 -!- mrsrikanth [~mrsrikant@59.92.81.39] has joined #go-nuts 16:36 < chomp> no, that doesn't work 16:36 < chomp> you can't "type it", you can only assert its type 16:36 < ArgonneIntern> "static type interface{}, meaning no guarantee of any methods at all: it could contain any type" quoted from the link above 16:36 < chomp> it's an array, and you can assert that it's an array and that's fine 16:36 < ArgonneIntern> that's what I mean 16:36 < chomp> but it's not a slice. 16:36 < ArgonneIntern> oh 16:36 < ArgonneIntern> so you would know what it is but not be able to append 16:38 < chomp> i'm skeptical that passing an interface{} receiving a slice would somehow actually receive only the underlying array 16:38 < magn3ts> Are there docs like are available on golang.org for tip? 16:38 < chomp> magn3ts, you can run godoc locally in your tip tree 16:38 < ArgonneIntern> couldn't you slice the assertion? I believe I've done this with linked list 16:38 < chomp> magn3ts, and it will serve formatted html docs just like golang.org has 16:38 -!- sl0 [none@sp.inri.net] has joined #go-nuts 16:38 < chomp> directly from the source code 16:39 < GeertJohan> Hum... how do I declare a slice inside a struct? 16:39 -!- lucian [~lucian@78-86-217-168.zone2.bethere.co.uk] has quit [Remote host closed the connection] 16:39 < chomp> struct { myslice []type } 16:39 < GeertJohan> ah ok:) and then, is the sliced make'd when I initialize the struct using new? or do I need to "make" the struct? or do I initialize the struct and then make the slice in the struct? 16:40 < chomp> you can use new or an initializer list 16:40 < ArgonneIntern> someInterface = append(someInterface.(*[]*Case).[number:number2], "samething") 16:40 < chomp> i always use intiializer syntax, i.e foo := &StructName{} 16:41 < chomp> with intializers optionally specified either in-order or by-name inside the {} 16:41 -!- wchicken [~chicken@c-71-235-58-74.hsd1.ct.comcast.net] has joined #go-nuts 16:41 < GeertJohan> ok, so say Ihave a slice then I should put "myslice: make(slice etc.)" between de {} ? 16:41 < GeertJohan> *de=the 16:41 -!- prip [~foo@kimochi.ath.cx] has joined #go-nuts 16:42 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-153-41.clienti.tiscali.it] has joined #go-nuts 16:43 < ww> GeertJohan: hou kom nie? 16:44 < magn3ts> If I want to switch back from tip... do I do `hg update release` ? 16:44 < ww> hg up -r release 16:45 < GeertJohan> ww: ? 16:45 < chomp> ArgonneIntern, zippoxer, peep this: http://pastie.org/2129918 16:45 < ww> yes why not? 16:46 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-155-41.clienti.tiscali.it] has quit [Ping timeout: 260 seconds] 16:51 -!- mattn_jp [~mattn@112-68-51-161f1.hyg1.eonet.ne.jp] has quit [Quit: leaving] 16:54 -!- fabled [~fabled@83.145.235.194] has quit [Quit: Ex-Chat] 16:55 < magn3ts> If I have src/main.go and src/gopcap/pcap/pcap.go... 16:56 < magn3ts> wouldn't I do import "./gopcap/pcap/pcap" ? 16:57 -!- niemeyer [~niemeyer@83.141.95.158] has joined #go-nuts 16:58 < chomp> only if you have a pcap binary package actually built in gopcap/pcap/pcap 16:58 < chomp> essentially when you say "./path/to/module" the compiler will look for ./path/to/module.a 16:59 -!- nekschot [~bla@a78242.upc-a.chello.nl] has joined #go-nuts 16:59 < ww> your life will be easier if you set things up from the beginning with paths like gitbucket.baz/magn3ts/gopcap 16:59 < chomp> ^ 16:59 < chomp> and use goinstall for your own packages 16:59 < magn3ts> It's not my own package. 17:00 -!- pyrhho [~pyrhho@host-92-27-75-48.static.as13285.net] has quit [Quit: pyrhho] 17:00 < chomp> well, then use goinstall for whoever's package it is 17:00 < chomp> goinstall github.com/xb95/gopcap 17:00 < magn3ts> and then use the domain/path in the import like ww listed? 17:00 -!- comex [~ec2-user@ec2-67-202-46-7.compute-1.amazonaws.com] has joined #go-nuts 17:00 < chomp> then import in your code with import "github.com/xb95/gopcap" 17:00 < magn3ts> or goinstall gopcap.googlecode.com/hg/ 17:01 < chomp> either way... 17:01 < magn3ts> I see. 17:01 < magn3ts> very clean/neat :) 17:01 < chomp> and actually i guess the import would be import "whatever.domain/path/gopcap/pcap" 17:04 < magn3ts> Hm, and what if the package fails to build with goinstall but builds okay normally? (it uses a C library if it matters) 17:05 < chomp> might need some changes 17:05 < magn3ts> http://pastebin.com/raw.php?i=mEiVkn9i 17:05 < chomp> there are comment flags that can be added to make goinstall+cgo play nicely 17:05 < chomp> yeah... 17:05 < magn3ts> :S 17:06 < chomp> guess it hasn't been tested with goinstall? o_O 17:06 < chomp> basically there should be a 17:06 < ww> see https://bitbucket.org/ww/zoom/src/381984a756b6/zoom.go#cl-1 for example 17:06 < chomp> /#cgo LDFLAGS: -lpcap 17:06 < chomp> err // 17:07 < chomp> before the import "C" 17:07 < magn3ts> Oh I see. 17:07 < chomp> and then goinstall would know how to link 17:07 < ww> iirc the plan is to get rid of gomake so eventually you'll have to do that anyways 17:08 < chomp> sounds good to me 17:08 < magn3ts> get rid of gomake? to promote the use of? godag? 17:08 < ww> just goinstall i think 17:09 -!- powerje_1 [~powerje@nat/google/x-qwesxtviwkmhfzyq] has joined #go-nuts 17:09 -!- powerje_1 [~powerje@nat/google/x-qwesxtviwkmhfzyq] has left #go-nuts [] 17:09 -!- powerje_1 [~powerje@nat/google/x-qwesxtviwkmhfzyq] has joined #go-nuts 17:09 < skelterjohn|work> gb will work wherever goinstall does O:-) 17:09 < kevlar_work> for lack of a better name, I've been calling it gomake++ lol 17:10 < kevlar_work> but I think there are going to be two separate commands, goinstall and gomake 17:10 < kevlar_work> one builds the current directory, the other searches GOPATH and does a build/install 17:10 < skelterjohn|work> i believe the intent is to rename goinstall as gomake at some point 17:10 < skelterjohn|work> and if you goinstall something that can be found locally, it will do it 17:11 < kevlar_work> no, I think the team is pretty invested in the "goinstall" name :) 17:11 < skelterjohn|work> i guess it's possible, but i'm quoting a golang-dev message 17:11 < skelterjohn|work> but that was a while ago, so they may have changed their minds 17:11 < kevlar_work> oh? 17:11 < kevlar_work> I'm building on what I've seen in the go/build discussion 17:12 < kevlar_work> which is pretty recent 17:12 < skelterjohn|work> that's more recent 17:12 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts 17:12 < kevlar_work> I've just seen lots of presentations and heard lots of comments from the team about how they want goinstall to be super-duper easy to use 17:12 < skelterjohn|work> they also changed their minds about whether go/build should exist... when i suggested it they told me to not waste my time 17:13 * ww hasn't bneen paying attention to the list recently 17:13 < kevlar_work> skelterjohn|work, I had a similar experience, but what I was actually told in retrospect was "don't bother doing it now until we have a better idea about what a project should actually look like" 17:13 < skelterjohn|work> it's hard to track golang-dev, since so much of it is code-review requests 17:13 < skelterjohn|work> what i was told was "won't it just invoke goinstall?" 17:14 < kevlar_work> since I'm using Go at work, I think it's in my own best interest to keep an eye on all of the mailing lists ;-) 17:14 < kevlar_work> I don't want to get surprised by something and have the rest of my team use it as ammunition to not use Go in the future. 17:15 < skelterjohn|work> sensible 17:17 < kevlar_work> I can only imagine how difficult it would be to start a project in go at a company that *didn't* invent it. There still seems to be some friction even here. 17:17 -!- powerje_1 [~powerje@nat/google/x-qwesxtviwkmhfzyq] has quit [Quit: leaving] 17:18 < magn3ts> I'm curious what the "right" way to handle this pkg is now. Should I clone the repo and fix it and then goinstall from there? Or fix locally and install (how?) 17:18 < skelterjohn|work> you work at google? 17:18 < kevlar_work> but I guess people are always going to be resistant to change, so I'm resigned to that. 17:18 < skelterjohn|work> magn3ts: if the project sets its makefile up correctly, it should be installable locally using the makefile or remotely using goinstall 17:18 < skelterjohn|work> to the same target 17:19 < skelterjohn|work> if you're interested in contributing and it's a github project, then the thing to do is clone, fix, and make a pull request back 17:19 < skelterjohn|work> then the original can incorporate your changes (if they want) 17:19 < kevlar_work> magn3ts, you could (a) fork it on whatever hosting site it uses, (b) maintain a GOPATH directory in which you install all local forks, or (c) submit a patch to the maintainer and just `make install` in the mean-time. 17:19 < magn3ts> heh, it's googlecode and I don't like how it handles clones 17:19 < skelterjohn|work> me neither - that's why i switched to github for my projects 17:20 < kevlar_work> I heart github. 17:20 -!- niemeyer [~niemeyer@83.141.95.158] has quit [Ping timeout: 240 seconds] 17:20 < kevlar_work> you also aren't limited to 10 projects on github. 17:22 < kevlar_work> (oh, and github allows you to, you know, use git) 17:22 -!- zaero [~eclark@servo.m.signedint.com] has quit [Ping timeout: 264 seconds] 17:28 -!- wchicken [~chicken@c-71-235-58-74.hsd1.ct.comcast.net] has quit [Ping timeout: 244 seconds] 17:29 -!- pjacobs [~pjacobs@66.54.185.130] has quit [Ping timeout: 246 seconds] 17:29 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has quit [Ping timeout: 252 seconds] 17:29 -!- Halavanja [~chatzilla@anlextwls002-095.wl.anl-external.org] has joined #go-nuts 17:30 < Halavanja> do golang templates for plain text or html support conditionals in the template itself 17:30 -!- NiteRain [~kvirc@c-98-254-236-21.hsd1.fl.comcast.net] has joined #go-nuts 17:30 -!- iant [~iant@216.239.45.130] has joined #go-nuts 17:30 -!- mode/#go-nuts [+v iant] by ChanServ 17:30 < Halavanja> such as if {something} >2 Do this 17:30 < skelterjohn|work> i don't believe so 17:30 < Halavanja> okay 17:30 < skelterjohn|work> you can check for the zero-value 17:30 < skelterjohn|work> i think 17:31 < Halavanja> ok 17:31 < kevlar_work> Halavanja, go templates are designed to completely decouple logic from the template 17:31 < Halavanja> okay so its not like the python genshi templates in that regard 17:31 < kevlar_work> it's like jsontemplate 17:31 < kevlar_work> iirc 17:32 < kevlar_work> all you get is {field}, {.section struct}, and {.repeated section list} 17:32 < Halavanja> Ill take a look at that then 17:32 < Halavanja> Thats all i found in the documentation too 17:32 < Halavanja> I just wanted to be sure I wasn't missing something 17:32 < kevlar_work> that's because the documentation is all there is ;-). 17:32 < Halavanja> haha 17:32 < kevlar_work> there are some other goinstallable template packages that do more 17:32 < kevlar_work> moustache, I believe, is a common one 17:33 < Halavanja> ill give that one a look 17:33 < Halavanja> I'm not sure if i want to deviate from the standard library yet 17:33 < kevlar_work> you should probably try to use the standard template to make sure it can't do what you want 17:33 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has quit [Ping timeout: 240 seconds] 17:33 < kevlar_work> I haven't really found it lacking in my own experience 17:34 < kevlar_work> and what few things it's missing I've been able to hack in using formatters or niladic functions. 17:34 -!- napsy [~luka@88.200.96.18] has joined #go-nuts 17:34 < ArgonneIntern> So funny story, one of my college mates got hired at a company called Epic in madison WI. So more of my friends applied and failed. They posted their failure on facebook. So of course I joked in their dispair and said I had an interview. Well my friend was apparently so good of friends with me he put my name in to the company as a recommended potential employee, he thought I was serious. 17:34 < Halavanja> I have skimmed over those as well and thought it would be a solution 17:35 < ArgonneIntern> So feeling bad I actually tossed a resume to them. I ended up getting a phone interview, which resulted in a knowledge and logic test. Which has now, today culminated in an on site interview 17:35 < ArgonneIntern> all the while I never actually cared to be hired by them and was half assing it the entire time 17:35 < kevlar_work> ArgonneIntern, no interest in working there? 17:35 < ArgonneIntern> so this joke has gotten way out of hand 17:35 < kevlar_work> lol. 17:35 < Halavanja> haha 17:36 < ArgonneIntern> well now I don't know, the starting salary is 72k 17:36 < skelterjohn|work> ArgonneIntern: this puts you in a really good bargaining position if they offer you a job 17:36 < ArgonneIntern> indeed it does 17:36 < skelterjohn|work> say you won't accept anything less than 90 17:36 <+iant> but if you are definitely not going to work for them, you should tell them that before the interview 17:36 < kevlar_work> that's not bad at all. Especially for Madison, which has relatively low Cost of Living. 17:36 < ArgonneIntern> well on the prog test, I literally said in my head, "some of these aren't very efficient, but I don't care cause I'm not that interested" 17:37 < ArgonneIntern> and still they are paying for me to go up there 17:37 <+iant> I only say that because I once interviewed a candidate, and at the end he told me he had already taken another job and was only doing the interview for practice 17:37 <+iant> wow that was annoying 17:37 < ArgonneIntern> originally I counted on them not wanting me, but now I don't know. My friend does work there, and they do weed out a ton of candidates 17:37 < kevlar_work> iant, wow. If you want practice, find a local university and hit up their career people. that's a dick move. 17:37 < ArgonneIntern> so maybe I would like working there 17:37 <+iant> of course if there is a possibility of taking the job, go ahead and do the interview 17:38 <+iant> you'll learn more about the company 17:38 < ArgonneIntern> it's just funny how a joke turns into a flight to madison all espense paid 17:38 < skelterjohn|work> how far away from madison are you? 17:39 < ArgonneIntern> I don't even graduate till december lmao I wasn't even going to start applying until sept 17:39 < ArgonneIntern> currently I'm at argonne for internship so 2 and a half hours 17:39 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has joined #go-nuts 17:39 < skelterjohn|work> where's argonne? 17:39 < ArgonneIntern> but my real house is is about 6 hours away 17:39 < ArgonneIntern> argonne national labs in IL 17:40 < kevlar_work> ArgonneIntern, woo, midwest. 17:40 < ArgonneIntern> they kind of invented commercial nuclear power 17:40 < kevlar_work> I used to be from there. 17:40 < Halavanja> Argone is in the Chicago area 17:40 < ArgonneIntern> yes 17:40 < ArgonneIntern> like 20-30 mins south depending on traffic 17:40 -!- bakedb [~kel@188.28.234.76.threembb.co.uk] has quit [Ping timeout: 258 seconds] 17:40 < kevlar_work> Chicago was always too cold and windy and crowded for me. 17:41 < ArgonneIntern> I love it here. I would accept a full time position here for much less than Epic is about to offer me 17:41 < skelterjohn|work> you must be unmarried 17:41 < ArgonneIntern> no I'm married 17:41 < ArgonneIntern> wife has a degree 17:41 < ArgonneIntern> I'd rather take happiness over money 17:41 < Halavanja> Good way to live life 17:41 < skelterjohn|work> certainly happiness has value 17:41 < ArgonneIntern> it would be a dream job to work here 17:42 < skelterjohn|work> but i'm assuming that epic isn't the pit of hell 17:42 <+iant> but everybody knows that money can buy happiness 17:42 < ArgonneIntern> which is why I'm seriously considering taking the job if they offer it to me 17:42 < ArgonneIntern> lmao 17:42 < skelterjohn|work> especially if you can bump it up to 80 17:42 -!- awidegreen [~quassel@h-170-226.A212.priv.bahnhof.se] has quit [Remote host closed the connection] 17:42 < ArgonneIntern> the way my friend says 72 is basically what they offer 17:42 < skelterjohn|work> are you finishing up undergrad? 17:42 < magn3ts> I got it to install with goinstall, but now it fails to see the import with the same pattern 17:42 < ArgonneIntern> they don't like bargaining so they just pay you well up front 17:43 < skelterjohn|work> ArgonneIntern: that just means he wasn't a good negotiator ;) 17:43 < magn3ts> can't find import: github.com/colemickens/gopcap/pcap 17:43 < ArgonneIntern> yes I made it clear I'm finishing my ungrad first 17:43 < skelterjohn|work> magn3ts, look in $GOROOT/pkg/$GOOS_$GOARCH 17:43 < skelterjohn|work> find the .a file representing the project 17:43 < ArgonneIntern> I spent 8 years in the military to pay for my ungrad lol, no one is taking that away from me 17:43 < kevlar_work> ArgonneIntern, I originally accepted my current job because I have, uh, ridiculous student debt to pay off, but the longer I'm here the more I think I could make a career out of it. I wouldn't say money can buy happiness, but it can certainly give you the freedom to be happy later. 17:43 < skelterjohn|work> if the package is at $GOROOT/pkg/$GOOS_$GOARCH/X/Y.a, then you import "X/Y" 17:44 -!- awidegreen [~quassel@h-170-226.A212.priv.bahnhof.se] has joined #go-nuts 17:44 < magn3ts> ah 17:44 < ArgonneIntern> kevlar_work: yea I know what you mean. Stability is happiness for me a lot of the time 17:44 < ArgonneIntern> and epic can def offer that 17:44 < magn3ts> I see now >_> strange that the import name hinges on the path rather than package name, is that typical for go style? 17:44 < skelterjohn|work> yes. 17:44 < skelterjohn|work> there is no package database 17:44 < skelterjohn|work> other than the filesystem 17:45 < magn3ts> hm, ok 17:45 < skelterjohn|work> it's convention to have the package name be the last token in the import path, though 17:45 < skelterjohn|work> so people don't get confused 17:45 < magn3ts> heh 17:45 -!- powerje_ [~powerje@nat/google/x-wfbbcszdhmkcajos] has quit [Quit: leaving] 17:47 -!- Fish [~Fish@9fans.fr] has joined #go-nuts 17:49 < magn3ts> hm goinstall seems to install to repo-name.a even if I put the go files in a subdirectory in my repo. How do I get the package name to be the last token via a github repo 17:50 -!- robteix [~robteix@nat/intel/x-vmrusavikismhzxk] has joined #go-nuts 17:52 < kevlar_work> magn3ts, you have to make it a subdirectory, e.g. github.com/kylelemons/go-gypsy/yaml 17:52 < magn3ts> yeah I did that: https://github.com/colemickens/gopcap/tree/master/pcap 17:53 < kevlar_work> so if the files in pcap/* are "package pcap" then you can goinstall github.com/colemickens/gopcap/tree/master/pcap and import "github.com/colemickens/gopcap/tree/master/pcap" 17:53 < magn3ts> hm. ok 17:54 < skelterjohn|work> yeah - generally if you "goinstall X" then you import "X" 17:54 < magn3ts> I was missing the tree/master bit 17:54 < skelterjohn|work> i bet you could goinstall github.com/colemickens/gopcap/pcap 17:55 < skelterjohn|work> without tree/master 17:55 < magn3ts> neither are working here still 17:55 < skelterjohn|work> yes definitely 17:55 < magn3ts> :s 17:55 < skelterjohn|work> i get an error about pcap.h, but otherwise that goinstall line worked 17:55 < magn3ts> really? 17:56 < magn3ts> goinstall: github.com/colemickens/gopcap/pcap: open /home/cole/Code/go/src/pkg/github.com/colemickens/gopcap/pcap: no such file or directory 17:56 < skelterjohn|work> try 17:56 < skelterjohn|work> goinstall -u -clean github.com/colemickens/gopcap/pcap 17:56 < skelterjohn|work> if there was a previous version of the code alreayd downloaded, it doesn't get the new version unless you add -u 17:57 < magn3ts> how was it tracking it? I was puring ~/Code/go/src/pkg/github.com 17:57 < magn3ts> oh well, that worked :) 17:57 < skelterjohn|work> i don't follow 17:57 < skelterjohn|work> puring? 17:57 < magn3ts> purging* 17:57 < skelterjohn|work> did you set GOPATH? 17:57 * magn3ts chuckles 17:58 < magn3ts> there's a gopath too? 17:58 < skelterjohn|work> not setting GOPATH isn't a problem 17:58 < skelterjohn|work> but it lets you put downloaded packages somewhere other than $GOROOT/src 17:58 < magn3ts> oh, I had been wondering about that. 17:59 < GeertJohan> what is the largest integer type in go ? 17:59 < GeertJohan> uint64 ? 17:59 < skelterjohn|work> int64 17:59 < GeertJohan> ok 17:59 < skelterjohn|work> and its unsigned partner uint64 17:59 < GeertJohan> ok :) thx 17:59 < skelterjohn|work> np 17:59 < GeertJohan> unsigned will do best :) won't go negative :) 17:59 < magn3ts> thanks for the help 18:01 < skelterjohn|work> magn3ts: i'm surprised purging the source didn't work - maybe it checks if the .a file exists, first? 18:02 < kevlar_work> w.r.t this current thread on golang-nuts; what's so freaking "time critical" about finance? 18:02 < kevlar_work> when I think time-critical, that's definitely not what my mind goes to 18:02 < skelterjohn|work> auto-traders 18:03 < kevlar_work> I think routers, mars rovers, and moving vehicles. 18:03 < skelterjohn|work> they are extremely time-critical 18:03 < skelterjohn|work> mars rovers are *not* time critical :) 18:03 < exch> sniping eachother on sub-millisecond timescales 18:03 < xb95> It's called 'high frequency trading'. 18:03 < xb95> http://en.wikipedia.org/wiki/High-frequency_trading 18:04 < ArgonneIntern> facebook is time critical, finance can take a back seat 18:05 < ArgonneIntern> gotta get those status updates man 18:05 < ArgonneIntern> I want to know the second someones kid falls over, my happiness depends on it 18:05 < kevlar_work> I still don't see how high-frequency trading is something that Go couldn't do. If you really don't want the stop-the-world, then structure your program such that you can run it without the GC 18:06 < skelterjohn|work> yes - i mentioned that in the ML thread 18:06 < skelterjohn|work> coding in such a way to avoid allocations is just as challenging as manual memory management 18:06 < skelterjohn|work> that is, not particularly, but you need to be careful 18:06 < kevlar_work> I do see that Go can't be used in real-time applications which require determinism because it relies so much on memory allocation 18:06 < kevlar_work> but determinism isn't a requirement in time critical applications, just being "fast enough" 18:06 < Namegduf> Go is not really designed for "hard realtime" 18:06 < Namegduf> I think. 18:06 < kevlar_work> Namegduf, precisely. 18:06 < Namegduf> But hard realtime is relatively rare. 18:07 < Namegduf> Even if it could do it, it'd probably be bad at it. 18:07 < kevlar_work> things like mars rovers and routers and moving vehicles ;-) 18:07 < Namegduf> Routers aren't hard realtime 18:07 < Namegduf> They're "soft". 18:07 < Namegduf> Other examples of "soft" are video rendering. 18:08 < kevlar_work> past a certain bandwidth point, I would say routers do become hard realtime 18:08 < Namegduf> Where being behind is bad but odd cases are tolerable, the key thing is speed 18:08 < skelterjohn|work> i have to say again, mars rovers do not really have time-critical code 18:08 < kevlar_work> skelterjohn|work, having worked on a mars rover, they are hard real-time systems. 18:08 < skelterjohn|work> what on there needs hard real-time? 18:08 < Namegduf> Hmm. 18:09 < skelterjohn|work> certainly not the control 18:09 < kevlar_work> skelterjohn|work, at a minimum, the entry/descent/landing 18:09 < skelterjohn|work> they don't go fast 18:09 < Namegduf> Constant sending of information? 18:09 < skelterjohn|work> oh that's not the rover 18:09 < kevlar_work> skelterjohn, who do you think controls EDL? 18:09 < skelterjohn|work> but i can see that stuff needing it 18:09 < kevlar_work> skelterjohn, and running on a slow CPU makes the real-time even more important 18:09 < Namegduf> Proper high speed routers aren't even programmed in a general programming language anyway. 18:09 < skelterjohn|work> i guess as someone who doesn't work on rovers, i thought of the rover bit as being the bit that tooled around on the martian tundra 18:10 < skelterjohn|work> go this way for a bit, go that way for a bit 18:10 < ArgonneIntern> the best part is how it's what, 5 year old tech, once it gets there lol 18:10 < Namegduf> What do they call that weird thing that routes straight from NIC to NIC bypassing the CPU? 18:10 < kevlar_work> ArgonneIntern, it's only a 7 month flight, but the technology freeze happens 1-2 years before launch 18:10 < Namegduf> All I remember is that when it turns off, due to filtering or such, if you're putting a lot of bandwidth through it, Bad Things happen. 18:10 < ArgonneIntern> kevlar_work: so why is everyone freaking about a manned mars flight taking years to get there? 18:11 < Namegduf> I think special programmable hardware is used anyways there. 18:11 < skelterjohn|work> no one thinks it takes years to get there... 18:11 < ArgonneIntern> kevlar_work: if we can be there in 7 months 18:11 < skelterjohn|work> it just takes a really long time 18:11 < kevlar_work> ArgonneIntern, the problem is that it's a 7 month flight, 140 day stay, and then 7 month flight back if you take optimal trajecotires 18:11 < kevlar_work> wow, trajectories* 18:11 < ArgonneIntern> I like the first version better 18:11 < Namegduf> Anyways, I think whether Go can do hard realtime is a non-issue 18:11 < kevlar_work> indeed. 18:12 -!- icy [~icy@lighttpd/icy] has joined #go-nuts 18:12 < Namegduf> Not a problem designed to solve, often not a problem solved with regular languages anyway 18:12 < kevlar_work> yeah. 18:12 < kevlar_work> or a regular operating system. 18:12 < ArgonneIntern> did google guys intend for go to be used at NASA? 18:12 < skelterjohn|work> heh 18:12 < kevlar_work> ArgonneIntern, lol no. 18:12 < Nisstyre> yes 18:12 < kevlar_work> well, not for hard real time programming at NASA. 18:12 -!- pjacobs [~pjacobs@rrcs-24-73-248-196.sw.biz.rr.com] has joined #go-nuts 18:13 < zippoxer> if NASA uses python somewhere in their systems... 18:13 < ArgonneIntern> ROFL 18:13 < zippoxer> so they'll probably switch to go 18:13 < skelterjohn|work> go was intended to be a lang that could take advantage of multi-core systems 18:13 < kevlar_work> but let me tell you, there are plenty of things that are written in disgusting masses of Python at JPL that should be rewritten, and Go would be a candidate. 18:13 < ArgonneIntern> my boss thinks go is excellent for systems programming 18:13 < Halavanja> Kevlar_work: lol 18:14 < skelterjohn|work> especially multi-core servers 18:14 < ArgonneIntern> skelterjohn|work: yes, which is basically what I'm doing lol 18:14 < zippoxer> the truth is that for most simple web system, python is much better in most perspectives 18:14 < zippoxer> systems* 18:14 < skelterjohn|work> if you want to serve a page to a few buddies 18:14 < skelterjohn|work> then html is the language for you 18:14 < zippoxer> I said system! 18:14 < icy> I have a simple http server using http.ListenAndServe which does some tiny work upon requests. right now it gets about 2-3 req/s but I see 240 goroutines (runtime.Goroutines()). this number seems a bit excessive. how can I find out what those goroutines are doing? 18:15 < skelterjohn|work> but writing complex programs in python has perils 18:15 < Namegduf> "system" doesn't convey meaning. 18:15 < skelterjohn|work> i've done it, and it's easy for the code to lose shape and become unmanageable 18:15 < kevlar_work> icy, ^\ 18:15 < Namegduf> And whether Python is "better" is very much a matter of opinion. 18:15 < zippoxer> ur right 18:15 < Namegduf> I happen to disagree. 18:15 < skelterjohn|work> different tools for different tasks 18:15 < icy> kevlar_work: ctrl+\ will give me stack traces? 18:15 < skelterjohn|work> i consider both python and go to be in my toolbelt 18:15 < Namegduf> Go's ridiculously cheap and easy synchronous-IO-in-concurrent-goroutines makes everything servery easy 18:16 < ArgonneIntern> icy: 2-3 reuqests should def not give you 240 go routines lol 18:16 < skelterjohn|work> it depends on what he's doing with the requests 18:16 < ArgonneIntern> unless you told it to do that 18:16 < ArgonneIntern> right 18:16 < icy> ArgonneIntern: I even force Connection: close on them 18:16 < zippoxer> when the code grows up you'll want some static typed language 18:16 < skelterjohn|work> perhaps there are goroutines that have gotten untethered from the rest of the runtime 18:16 < skelterjohn|work> and just sit there taking up memory 18:16 < skelterjohn|work> (though they won't take up any cycles at all) 18:17 < Namegduf> I reject the premise that writing down an extra token (the type) when declaring variables, only sometimes, makes prototyping that much slower. :P 18:17 < kevlar_work> icy, yes, it will dump stack traces for all of your goroutines. you're probably not closing the Bodu 18:17 < kevlar_work> Body* 18:18 < skelterjohn|work> kevlar_work: interesting about ctrl+\ I didn't know that 18:18 < ArgonneIntern> error = request.Body.Close() 18:18 < kevlar_work> skelterjohn, I believe SIGQUIT triggers a panic, which triggers a stack trace. 18:18 < skelterjohn|work> gotcha 18:18 < kevlar_work> at least that's how it seems. 18:18 < skelterjohn|work> not a terminal expert 18:19 < skelterjohn|work> i only know ctrl-c and kill -9 18:19 -!- zaero [~eclark@173-28-217-101.client.mchsi.com] has joined #go-nuts 18:19 < skelterjohn|work> there is no middle ground. 18:19 < ArgonneIntern> kill -9 18:19 < ArgonneIntern> ^win 18:20 < icy> I guess sending a SIGSEGV would trigger a panic too 18:21 < icy> kevlar_work: so even if the handler function returns, I have to close the Body? 18:22 -!- ijknacho [~goofy@cpe-72-190-64-3.tx.res.rr.com] has joined #go-nuts 18:22 < kevlar_work> icy, you always have to close the body 18:22 < icy> well I expected it to be garbage collected 18:23 < skelterjohn|work> goroutines aren't garbage collected (yet, hopefully) 18:24 < ArgonneIntern> so we have to delete memory manually in them? 18:24 < skelterjohn|work> not what i meant, exactly 18:24 < ArgonneIntern> well if a variable points to something.. 18:24 < skelterjohn|work> but if you do something like, "ch := make(chan int); go func() { ch <- 2 }()" and then do nothing with ch from then on 18:24 < skelterjohn|work> there is a hanging goroutine 18:24 < skelterjohn|work> ch won't get cleaned 18:24 < ArgonneIntern> oh crap... 18:25 < ArgonneIntern> yeah, that's my situation, better clean that up 18:25 < skelterjohn|work> i don't know if this has been changed 18:25 < chomp> really? o_O 18:25 < ArgonneIntern> I'm glad someone mentioned that 18:25 < ArgonneIntern> lol 18:25 < skelterjohn|work> but it's certainly possible to clean this up 18:25 < skelterjohn|work> like i said, this may have been fixed, but it used to be an issue 18:25 < chomp> even if someone reads from ch and the goroutine finishes? 18:25 < skelterjohn|work> if the goroutine finishes, then it's a different story 18:25 < chomp> ah ok. 18:26 < chomp> blew my mind for a second there. :p 18:26 < skelterjohn|work> i'm talking about when a goroutine hangs, and can never ever finish 18:26 < ArgonneIntern> well in icy's situation the goroutine finishes 18:26 < icy> well, my goroutines finish 18:26 < skelterjohn|work> i thought you had 240 of them 18:26 < icy> I have 18:26 < skelterjohn|work> i'm not saying you spawned them all 18:26 < icy> but the function that the goroutines runs, returns 18:26 < zozoR> go func() {ch := make(ch int); ch <-2} <-- would hang right? :D 18:26 < skelterjohn|work> zozoR: right 18:26 < kevlar_work> skelterjohn, ArgonneIntern, that's still the behavior 18:26 < icy> and there is no channel stuff like in your example 18:26 < zozoR> awesome :D 18:27 < kevlar_work> bradfitz suggests using buffered channels when that might happen 18:27 < skelterjohn|work> kevlar_work: do you know if there has been any more thought on it? 18:27 < chomp> ok, i can see why you'd expect that to be collected, but it looks more like programmer error :p 18:27 < ArgonneIntern> so a go routine can return and not... end itself? 18:27 < skelterjohn|work> this is something that the runtime can figure out 18:27 < kevlar_work> so the goroutine writes successfully and then the goroutine exits and if the channel isn't used anywhere, it gets GC'd 18:27 < chomp> unbuffered channel though 18:28 < chomp> ah nevermind 18:28 -!- pjacobs [~pjacobs@rrcs-24-73-248-196.sw.biz.rr.com] has quit [Quit: Leaving] 18:28 < skelterjohn|work> if you can't get from a goroutine to an actively running goroutine through shared memory, then it can never resume 18:28 < kevlar_work> skelterjohn, it's currently still impossible for the GC to know that a goroutine is completely disconnected from the world 18:28 < skelterjohn|work> when you say impossible, you mean it doesn't do it? or there is a fundamental reason 18:28 < ArgonneIntern> so if a channel is still open, the go routine won't finish? 18:29 < kevlar_work> ArgonneIntern, well, if it's closed, it will panic ;-) 18:29 < kevlar_work> currently a goroutine must return to be deleted 18:29 < icy> hm my goroutine number is increasing slowly (though not with the same rate as I get req/s) 18:29 < skelterjohn|work> ArgonneIntern: only close channels if you're the sender 18:29 < icy> now I have 247 of them 18:29 < ArgonneIntern> how do you see num of go routines? 18:30 < icy> runtime.Goroutines() 18:30 < kevlar_work> icy, did you ^\ and look through the traces? 18:30 < icy> I'm going to add a defer req.Body.Close() to the top of the handler function and see if that helps 18:31 < skelterjohn|work> kevlar_work: i'd think the problem would be not that hard - you take an inactive goroutine and figure out what channel it's waiting on, and see what goroutines know about that channel 18:31 < skelterjohn|work> if no other goroutines know about it, then the goroutine is lost 18:31 < skelterjohn|work> if an active goroutine knows about it, the goroutine is not lost 18:31 < skelterjohn|work> if only inactive goroutines know about it, you keep searching 18:31 < skelterjohn|work> via the same method 18:32 < skelterjohn|work> of course there is a "will this instruction ever execute" question there, which is not answerable (halting problem), but you can get most of them 18:32 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts 18:32 < chomp> there is no doubt it would be possible to implement as far as i can tell 18:32 < skelterjohn|work> and you won't clean up something that needs to stay (no false positives) 18:32 < chomp> but is it worth implementing 18:32 < chomp> there are a lot of resources a coroutine could be blocking on 18:32 < icy> hm now I need to find out how to scroll in this screen session :) 18:32 < icy> to see the traces 18:32 < chomp> that might never be unblocked, and might have a means of detecting that 18:33 < kevlar_work> skelterjohn, it's possible for another goroutine to reference something in the halted goroutine that is able to trigger sending the channel to another goroutine which could then unblock it 18:33 < skelterjohn|work> that wouldn't be messed up by what i'm suggesting 18:34 < chomp> the runtime would know that the goroutine is the only one who has a reference to the channel 18:34 < GeertJohan> I still haven't really figured out how to solve the whole no-inheritance problem :s I do know about the "sub-interfaces" thing ''type Foo interface{a() string};; type Bar interface{Foo; b() string}'' But I still didn't really figure out what I really need... I explained my problem/question here: http://pastebin.com/wK1KTawR 18:34 < chomp> which would make it the only goroutine capable of passing it off to someone else, and yet it's blocking on that channel already 18:34 < skelterjohn|work> whatever it is that the goroutine is blocking on (channel, sync.mutex) you look for references in the other goroutines 18:34 < ArgonneIntern> yea my http.handlerfuncs don't close either 18:35 < kevlar_work> skelterjohn, there's also the small problem that there is no notion of "owning" data, so you can't see what goroutines "own" references to the channel. 18:35 < ArgonneIntern> I'm explicitely closing the request body and my go routines hang 18:35 < skelterjohn|work> what i'm saying has nothing to do with ownership 18:35 < chomp> what about a resource that can be unblocked by external influence but still may never be unblocked 18:35 < kevlar_work> some of this will come when we get escape analysis, so you might be able to build on that, but I rather doubt it will even be easy with that. 18:35 < skelterjohn|work> just knowledge-of 18:35 < chomp> liek say reading a net.Conn 18:35 -!- pjacobs [~pjacobs@66.54.185.130] has joined #go-nuts 18:35 < chomp> whose opposite end is supposed to be fed by another goroutine that is for whatever reason not operating 18:35 < skelterjohn|work> that wouldn't get cleaned 18:35 < icy> ArgonneIntern: so you see the same as I do? 18:35 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has joined #go-nuts 18:35 < skelterjohn|work> unless you can prove it won't happen 18:36 < ArgonneIntern> icy: yes 18:36 < skelterjohn|work> i'm not saying there're be no false negatives 18:36 < ArgonneIntern> icy: mine hang until I end the http connections from the client 18:36 < skelterjohn|work> just that there would be no false positives (where positive is "clean this goroutine up" 18:36 < skelterjohn|work> ) 18:36 < icy> ArgonneIntern: the weird thing is that it seems to happen just with some of them as it does not increase at the same rate as I get requests 18:36 < kevlar_work> skelterjohn, you're welcome to try to implement it ;-) 18:36 < icy> ArgonneIntern: ah no, yours will be just http keep-alive 18:36 < skelterjohn|work> the runtime is complicated :< 18:36 < icy> try req.Close = true 18:36 < skelterjohn|work> if someone showed me how it worked i probably would try 18:37 < skelterjohn|work> but i've looked.. 18:37 < kevlar_work> skelterjohn|work, me too :( 18:37 < skelterjohn|work> i can't follow it 18:37 < kevlar_work> I am always tempted to go to Go office hours and ask whoever is there to walk me through it ;) 18:37 < skelterjohn|work> haha 18:37 < kevlar_work> but I'm either not available or I convince myself that'd be a bad use of their time. 18:38 < skelterjohn|work> wait... 18:38 < skelterjohn|work> there are actually go office hours? 18:40 < ArgonneIntern> wow this sucks 18:40 < ArgonneIntern> this is a serious issue IMO 18:41 < chomp> what? 18:41 < ArgonneIntern> the fact that go routines stay open 18:41 < chomp> it sounds like you're doing it wrong 18:41 < ArgonneIntern> I know I am 18:41 < ArgonneIntern> but it shouldn't be this unintuitive 18:41 < ArgonneIntern> it should work like the rest of the language, just as a general flow of it all 18:42 < chomp> i'm not sure what you mean 18:42 < chomp> i've never had this problem with anything 18:42 < ArgonneIntern> my go routines are staying open for, what I'm assuming is, data not being garbage collected? 18:42 < chomp> did i miss a paste somewhere? 18:42 < ArgonneIntern> I'm still a bit confused as the convo went crazy for awhile 18:42 < chomp> that's nonsensical 18:42 < icy> so I've started the daemon again with "defer req.Body.Close()" added, now it has 30 goroutines. I'll see if it keeps on slowly growing 18:43 < skelterjohn|work> ArgonneIntern: it's usually not a problem - just be careful about spawning things that just send to channels... if the reader of that channel might stop halfway through, you have a dangling goroutine 18:43 < ArgonneIntern> http://www.pastie.org/2130443 this routine stays open and never ends. When I would think it should 18:44 < ArgonneIntern> :'( 18:44 < skelterjohn|work> tl;dr 18:44 < skelterjohn|work> i don't think it says "go" in there 18:44 < ArgonneIntern> that's an http handler func 18:44 < ArgonneIntern> that is spawned when a request comes in 18:44 < ArgonneIntern> so that is the routine 18:44 < skelterjohn|work> so one of the locks are never released to it? 18:45 < icy> skelterjohn|work: http.ListenAndServer() calls go on your handler funcs automatically 18:45 < ArgonneIntern> no they are both released 18:46 < skelterjohn|work> i suggest adding some defers 18:46 -!- hargettp_ [~hargettp_@dhcp-161.mirrorimage.net] has joined #go-nuts 18:46 < skelterjohn|work> well, maybe not 18:46 < skelterjohn|work> currentRequests is a channel? 18:46 < chomp> i would in any case defer func() { request.Close = true }() 18:46 < ArgonneIntern> there is nothing there that screams, hey keep this routine open 18:46 < ArgonneIntern> no 18:46 < skelterjohn|work> a slice? 18:46 < ArgonneIntern> currentRequests is a map 18:46 < skelterjohn|work> no a map 18:47 < icy> chomp: why would you defer that? 18:47 < ArgonneIntern> sorry, sometimes I type faster than I can think 18:47 < chomp> because he wants it to happen regardless of how the goroutine exits 18:47 < chomp> presumably 18:47 < ArgonneIntern> it's just natural to hit the enter key at the end of a thought 18:47 -!- GeertJohan [~Squarc@ip4da06866.direct-adsl.nl] has quit [Quit: Leaving.] 18:47 < chomp> same with request.Body.Close(), no? 18:47 < icy> so just do it in the beginning :) 18:48 < skelterjohn|work> in his code there are only two ways to return, and only one of them sets request.Close = true 18:48 < chomp> well, touche there 18:48 < icy> no, Body.Close() actually closes it 18:48 < chomp> i assumed printError would panic or something, i guess that's a poor assumpition 18:48 < icy> req.Close just tells it to close it after writing to it (aka disable http keep-alive) 18:48 < ArgonneIntern> skelterjohn|work: I was testing the Close = true, I never get into that return in the data I'm testing it with 18:48 < chomp> none of this would keep the goroutine hanging around in any case anyway 18:49 < skelterjohn|work> yeah... does this function always return? 18:49 -!- Dr_Who [~tgall_foo@linaro/tgall-foo] has joined #go-nuts 18:49 < ArgonneIntern> skelterjohn|work: it seems to, it returns all the data I ask it to 18:49 < skelterjohn|work> are you and icy working on the same code? 18:49 < ArgonneIntern> skelterjohn|work: no 18:50 < ArgonneIntern> skelterjohn|work: I don't know him at all, his questions just made me check my code and see if I had the same problem, and I do, kinda 18:50 < skelterjohn|work> what if you added defer request.Body.Close()? 18:50 < ArgonneIntern> I'll try it 18:50 < skelterjohn|work> since you don't close it in the line 15 clause 18:51 < ww> func pub(i) { for _; !closing() { i <-pint } } 18:51 < ArgonneIntern> but if I don't get into that if it shouldn't matter 18:51 < ww> go pub(me) 18:51 < chomp> ww, excellent. i still have about 7 hours before that happens >.> 18:52 < chomp> me := make(chan beer) ? 18:52 < ArgonneIntern> defering the close does nothing 18:52 < ww> chomp: make(chan pint) yes :) 18:52 < skelterjohn|work> ArgonneIntern: what makes you think that this is the goroutine that is sticking around? 18:53 < chomp> i assumed pint was simply a value of type beer :) 18:53 < ArgonneIntern> because I have test programs that call just this function 18:53 < skelterjohn|work> oh, outside of the context of a server? 18:53 < icy> http://go.paste.lighttpd.net/2117 this is my current code 18:53 < ArgonneIntern> and the routine numbers go up 18:53 < ArgonneIntern> yes 18:53 < skelterjohn|work> that is odd 18:53 < ArgonneIntern> but after the request is served it doesn't end the routine 18:53 < skelterjohn|work> well, try commenting out bits until it stops happening :) 18:53 < ArgonneIntern> but once the client is closed the routines close 18:53 < skelterjohn|work> i see 18:54 < skelterjohn|work> then my guess is there are goroutines trying to read from the request body 18:54 < ArgonneIntern> 1 routie per request 18:54 < ArgonneIntern> and I explicitely close it 18:54 < skelterjohn|work> what if you try it with a handler that just returns immediately 18:54 < ArgonneIntern> lemme see 18:55 < chomp> and then iteratively move your return down by one line and see what happens :) 18:55 < skelterjohn|work> right :) 18:55 < skelterjohn|work> also, i think the request.Body.Close() is unnecessary - it must already be closed if ioutil.ReadAll(request.Body) returns 18:56 < chomp> hmm gdb can poke around individual coroutine stacks can it not 18:56 < ArgonneIntern> does the client have to close the connection or something? 18:56 < skelterjohn|work> ArgonneIntern: i don't know enough about http to answer that 18:56 < ArgonneIntern> I changed it to do nothing but return and it still hangs 18:56 < ArgonneIntern> so it must be something with the client 18:57 < icy> ArgonneIntern: no it should not have to close the connection. if the server sends "Connection: close" header 18:57 < chomp> hmmm 18:57 < ArgonneIntern> icy: i'm not sending that 18:57 < ArgonneIntern> icy: maybe I should lol 18:57 < chomp> looking at ServeHTTP source in src/pkg/http/server.go 18:57 < icy> req.Close = true does it 18:58 < chomp> it seems possible that this is a bug 18:58 < icy> well actually if you send data before setting this flag, then it can't send the header because it already sent the body 18:58 < ArgonneIntern> aha! let me tryt his 18:59 < icy> but I do set it immediately in my src :) 18:59 < ArgonneIntern> didn't help 18:59 < icy> chomp: where exactly do you spot a bug? 18:59 < chomp> i might not, just trying to make sense of this 19:00 < chomp> what happens if timeout is selected before done 19:00 < chomp> seems the goroutine that calls the handler will block writing to done 19:00 < icy> I checked if it's keeping any file descriptors open which is 100% not the case so those are all closed 19:01 < ArgonneIntern> it seems wierd to me that I close the client and the routines end 19:01 < chomp> it wouldnt preclude all fds being closed 19:01 < ArgonneIntern> something isn't closing 19:01 < chomp> but yeah that doesnt make sense then 19:02 < chomp> hmm 19:03 < ArgonneIntern> yea this kinda sucks...cause if I don't figure this out I can't have this happening over 1000 node request a day 19:03 < ArgonneIntern> that will bog down very fast 19:03 < skelterjohn|work> actually... not that fast :) 19:03 < skelterjohn|work> the go runtime can track 100s of thousands of goroutines without issue 19:03 -!- bakedb [~kel@cpc4-lea21-0-0-cust755.6-3.cable.virginmedia.com] has joined #go-nuts 19:03 < skelterjohn|work> but yes...it's still not ideal 19:04 -!- Crnobog [~crnobog@cpc3-nmal12-0-0-cust48.croy.cable.virginmedia.com] has quit [Read error: Connection reset by peer] 19:04 < chomp> it seems like it's possible for closeAFterReply to maybe not be set to true? 19:04 < ArgonneIntern> well they do close when the client ends, but I would certainly like them to close before that 19:04 < chomp> even if Connection: close is set in the header? 19:04 -!- keithcascio [~keithcasc@nat/google/x-ltlbsdrbeynkaznn] has joined #go-nuts 19:04 < ArgonneIntern> yes chomp 19:04 < ArgonneIntern> err wait, who has to set that? 19:04 < ArgonneIntern> the server or the client 19:04 < chomp> it's internal to http 19:04 -!- Crnobog [~crnobog@cpc3-nmal12-0-0-cust48.croy.cable.virginmedia.com] has joined #go-nuts 19:04 < chomp> go code 19:05 < icy> both can set that :) 19:05 < icy> req.Close = true at the beginning will make it send that as the response header 19:05 < chomp> no the actual flag in http 19:05 < chomp> in the http.Response 19:06 -!- virtualsue [~chatzilla@nat/cisco/x-gypngijjkedteudn] has quit [Read error: Operation timed out] 19:06 < ArgonneIntern> request is of type http.Response in a handler func 19:06 < ArgonneIntern> so request.Close = true sets it 19:07 < chomp> honestly i'm not seeing how that's true 19:07 < icy> so I had it running for a while now and I see 65 goroutines 19:08 < chomp> looking at the http package sources, it looks like response.closeAfterReply does not get set properly in all cases 19:08 < icy> with 27 file descriptors open 19:09 -!- gnuvince|work [8e544424@gateway/web/freenode/ip.142.84.68.36] has quit [Quit: Page closed] 19:09 < ArgonneIntern> ahhhhh 19:09 < ArgonneIntern> I see what you're saying chomp 19:09 < icy> chomp: even if it would be looping one more time, trying to get another request from the client, it should detect it when the client goes away (timeout, connection close) 19:09 < chomp> that's true icy, i was just realizing that 19:09 < ArgonneIntern> chomp: you mean in the header data type in the request type 19:09 < chomp> in fact if Connection: close is in the response, the client should close the connection and the read should fail 19:10 < chomp> unless the client is being stupid 19:11 < icy> eh if I see this right, the timeouts are by default 0? 19:11 < chomp> ArgonneIntern, actually i mean the closeAfterReply flag in the response struct defined in server.go at line 120 of src/pkg/http/server.go 19:11 < skelterjohn|work> shouldn't depend on the client not being stupid 19:11 < skelterjohn|work> i think that's "software for business 101" 19:11 < chomp> skelterjohn|work, heh 19:12 < chomp> in this case it appears to? if the client leaves a connection open, there's no way to force it closed short of using HTTP < 1.1 19:12 < chomp> or i guess setting a short timeout ? 19:12 -!- tncardoso [~thiagon@150.164.2.20] has quit [Quit: Leaving] 19:13 < icy> chomp: the server will close the connection too if you send Connection: close 19:14 < icy> or well, it should 19:14 < chomp> well there sure isn't any code here to make that happen 19:14 < chomp> it only explicitly sets closeAfterReply to false iff Connectoin == keep-alive 19:14 < chomp> but it defaults to false anyway and is only set true in a few unrelated cases 19:15 < ArgonneIntern> it's certainly not closing connections for me, no matter what I do 19:15 < ArgonneIntern> only thing that closes it is the client ending execution 19:15 < ArgonneIntern> which is crap 19:15 -!- virtualsue [~chatzilla@host81-148-52-109.in-addr.btopenworld.com] has joined #go-nuts 19:15 < chomp> can you change your client to use an HTTP 1.0 request 19:15 < chomp> just to test this 19:15 -!- dreadlorde [~dreadlord@c-68-42-82-10.hsd1.mi.comcast.net] has quit [Ping timeout: 240 seconds] 19:16 < ArgonneIntern> my client is also in go lol 19:16 -!- huin [~huin@91.85.188.1] has joined #go-nuts 19:16 < ArgonneIntern> Imean, in my situation it won't hurt, because the clients always eventually end when requests have been met 19:16 < ArgonneIntern> but it's def not the optimal situation 19:17 < ArgonneIntern> I essentially have go routines doing nothing 19:17 < ArgonneIntern> since that go routines end when the client ends, it just has to be be connection related 19:18 < skelterjohn|work> sounds like the issue has been diagnosed... maybe someone should file an issue, and fix it 19:18 < ArgonneIntern> hah...I'm still betting it's something we don't know 19:19 < chomp> no this is pretty clearly what's going on. 19:19 < icy> I don't think it's diagnosed 19:19 < chomp> after your request is served, the server continues to block reading on the connection 19:19 < chomp> so unless the client closes the connection, your goroutines will hang 19:19 < icy> I'm trying to find the src of ReadRequest as seen invoked in line 177 of server.go 19:19 < chomp> there is actually -no way- to force the server to close after reply 19:19 < crunge> I want to create a generator that can be "cancelled" before having produced all the data it can. My first thought is a to make a goroutine that sends the data on a channel and have the recipient close the channel, but it looks like the sender can't properly detect that. Do I give the sender a "finished" channel? Is there a more idiomatic way of doing this? 19:20 < skelterjohn|work> crunge: yes a finished channel 19:20 < skelterjohn|work> that's the idiomatic way 19:20 < skelterjohn|work> having the receiver close the channel is specifically frowned upon 19:20 < skelterjohn|work> (since it induces a race condition) 19:21 < ArgonneIntern> does go even support the receiver ending it explicitely 19:21 < crunge> skelterjohn|work: yeah, since detecting a closed channel is done with the receive operator, the sender would have to receive the data it might have stuffed in 19:21 < ArgonneIntern> I don't think it does 19:21 < chomp> sure, anyone can close a channel 19:21 -!- Dr_Who [~tgall_foo@linaro/tgall-foo] has quit [Quit: Dr_Who] 19:21 < ArgonneIntern> oh you're talking channels 19:21 < skelterjohn|work> crunge: i'm not really following what you said there, but i'm glad you have it under control :) 19:22 < crunge> skelterjohn|work: yeah, I was signalling that I understand the reason 19:22 < skelterjohn|work> cool :) 19:22 < skelterjohn|work> ah, yes i follow you now 19:22 < skelterjohn|work> the sender could also detect it by trying to send and catching the panic 19:22 < skelterjohn|work> but that seems a bit clunky 19:22 < crunge> yeah 19:23 -!- virtualsue [~chatzilla@host81-148-52-109.in-addr.btopenworld.com] has quit [Ping timeout: 250 seconds] 19:23 < crunge> I can at least see that as un-idiomatic 19:23 < skelterjohn|work> i wrote some stuff to run a process, and when the process returned a value would be sent on a channel. there was also another channel for killing the process - if you sent an int on it, it would get killed with that signal 19:24 < ArgonneIntern> chomp: you wanna report this? 19:24 < chomp> ArgonneIntern, i'm going to put together a test case and make sure i've got a solid understanding of it 19:24 < chomp> and maybe also a good working solution for it 19:24 < ArgonneIntern> ok 19:24 < chomp> but sure, i'll post something on dev 19:25 < chomp> it's unclear to me what the "correct" solution is 19:25 -!- cafesofie [~cafesofie@ool-18b97779.dyn.optonline.net] has joined #go-nuts 19:25 < crunge> So with the "finished" channel, am I trying to read a boolean from it or just wait for it to be closed. I don't want to have to send a "not finished" signal for the generator to produce the next item. 19:25 < skelterjohn|work> i have a 2d geometry library i've been working on... is "geom" an acceptable name or would "geom2d" be better? 19:25 < chomp> but maybe there'll be some insight from others 19:25 -!- yebyen [~yebyen@martyfunkhouser.csh.rit.edu] has quit [Ping timeout: 276 seconds] 19:25 < chomp> skelterjohn|work, geom sounds nice to me 19:25 < crunge> skelterjohn|work: goem/2d? 19:26 < skelterjohn|work> implies that one day i'd add a geom/3d :) 19:26 < chomp> crunge, good luck importing that ;) 19:26 < crunge> skelterjohn|work: someone else might 19:26 < chomp> (without a name override) 19:26 < chomp> i do agree that more general geom is better 19:26 < skelterjohn|work> and yeah - couldn't have 2d as a package name 19:26 < chomp> it will obviously be extended one day 19:26 < ArgonneIntern> chomp: shouldn't the solution be to for request.Close = true to actually do something 19:26 < chomp> and you can worry about dimensionality when that day comes :) 19:26 < crunge> well, geom/g2d if a leading digit makes an illegal identifier 19:27 < chomp> ArgonneIntern, looking at the documentation, that certainly seems like a good idea :P 19:27 < crunge> so how do I check a channel without blocking? 19:28 < ArgonneIntern> chomp: I mean looking at the docs it doesn't look like it actually does anything 19:29 < skelterjohn|work> crunge: select 19:29 -!- virtualsue [~chatzilla@nat/cisco/x-jvwyxhzxuhrljvtn] has joined #go-nuts 19:29 < icy> ArgonneIntern: I'm looking at the src I can't spot .Close being referenced anywhere 19:29 < skelterjohn|work> if you add a default: case to your select, it will fire instead of blocking on the channel read/send 19:29 < chomp> ive found plenty of references to .Close, just not in server.go 19:30 < icy> chomp: where? 19:30 < crunge> skelterjohn|work: so the default case is what triggers work to be done, the specific case causes the return 19:30 < skelterjohn|work> sounds about right, yeah 19:30 < chomp> persist.go, transfer.go, transport.go 19:30 < chomp> actually transfer.go is irrelevant 19:30 -!- bakedb [~kel@cpc4-lea21-0-0-cust755.6-3.cable.virginmedia.com] has quit [Ping timeout: 250 seconds] 19:30 < chomp> persist.go appears to be relevant though 19:31 < crunge> select { case iAmFinished := <- finished_chan: return; default: doMoreCrap() } 19:31 < aiju> iHaveFinished 19:31 < chomp> unfortunately setting req.Close = true in your reponse function will not elicit an effect until the -next- successful read on the connection, so it seems 19:31 < skelterjohn|work> case <- finished_chan: return 19:31 < aiju> ah fuck, that joke doesn't work in english 19:31 < skelterjohn|work> don't need to actually store it 19:31 < crunge> skelterjohn|work: word 19:32 < ArgonneIntern> I set it to true and readall from it 19:32 < ArgonneIntern> and it doesn't do anything 19:32 < chomp> ? 19:32 < crunge> aiju: in English I think it makes a reasonable double entendre. The work is done, and the goroutine is destined to die 19:32 < chomp> not the same 19:32 < skelterjohn|work> crunge: i bet he's making a sexual referense 19:32 < skelterjohn|work> reference 19:32 < aiju> haha 19:32 < aiju> "ich habe fertig" is stereotypical bad german 19:33 < crunge> skelterjohn|work: I find the default case for a channel read to be simple and clean, but non-obvious 19:33 < chomp> func (*ServerConn) Read() is what ultimately matters here 19:33 < skelterjohn|work> crunge: i hear you 19:33 < crunge> skelterjohn|work: thanks for the guidance 19:33 < skelterjohn|work> it used to be "val, ok := <- ch" for non-blocking, and ok would be false if nothing was read 19:34 < skelterjohn|work> but that got changed to be blocking, with ok = false for if the channel was closed 19:34 < skelterjohn|work> since select could already do a non-blocking read 19:34 < skelterjohn|work> and no problem 19:35 < chomp> so 19:35 < skelterjohn|work> "ich habe fertig" -> "i have farted"? 19:35 < chomp> yeah 19:35 < ArgonneIntern> chomp: do you know where header map[string]string keys and values are set 19:35 < chomp> setting Close has no effect 19:35 < chomp> it's only used before your handler is callled 19:35 < chomp> and is set based on incoming headers from the client 19:35 < aiju> skelterjohn|work: "i have done" 19:35 < ArgonneIntern> chomp: yes I suspected that 19:35 < aiju> instead of the correct "ich bin fertig" 19:36 < ArgonneIntern> the server tells the client to close in the response header 19:36 < chomp> which makes sense. i wouldn't expect modifications to the request object to have any effect on behavior 19:36 < skelterjohn|work> and fertig can't turn into a verb, like "done" can? 19:36 < TheSeeker> I keep hoping that if I hang out in this channel long enough I'll learn Go by osmosis. I don't think it's working though. :( 19:36 < ArgonneIntern> but I can't find where map[string]string header keys are predifined 19:36 < ArgonneIntern> what is the key for telling the client to close 19:36 < skelterjohn|work> TheSeeker: gotta code 19:36 < chomp> w.Header().Set("Connection", "close")? 19:37 < ArgonneIntern> I don't know 19:37 < chomp> it is. 19:37 < ArgonneIntern> I can't see where it is defined 19:37 < ArgonneIntern> where do you see that 19:37 < chomp> where what's defined 19:37 < chomp> that's code you would need to write 19:37 < chomp> in your handler function. 19:37 < chomp> or even in your client-side request header if you so choose 19:38 -!- yebyen [~yebyen@martyfunkhouser.csh.rit.edu] has joined #go-nuts 19:39 < ArgonneIntern> cleaner in server 19:39 < icy> but still, shouldn't it leak a) faster and b) also file descriptors? 19:39 < ArgonneIntern> it would appear that is the solution if those keys exist 19:39 < ArgonneIntern> lemme try it 19:40 < chomp> well yeah it should definitely leak file descriptors 19:41 -!- prip [~foo@kimochi.ath.cx] has quit [Ping timeout: 240 seconds] 19:41 < ArgonneIntern> MFer setting that key didn't doa nything 19:41 < chomp> ArgonneIntern, yes but it shouldnt alone... read the docks at http://golang.org/pkg/http/#Response 19:42 < chomp> docs* geez 19:42 < chomp> that should cause the Close flag to be true in the Response your client receives. Close is merely "advice" - http will never force close based on that response 19:43 < icy> req.Close = true does send Connection: close for me btw 19:43 -!- tgall_foo [~tgall@206.9.88.154] has quit [Quit: This computer has gone to sleep] 19:43 < icy> chomp: what do you mean by that last sentence? 19:43 -!- photron [~photron@port-92-201-42-18.dynamic.qsc.de] has quit [Ping timeout: 276 seconds] 19:44 < chomp> if a response header sets Connection: close, then the Reponse received by a go http client will have the Close flag set to true 19:44 < chomp> beyond that, the header elicits no additional behavior by the http implementation 19:44 < icy> oh you mean specificly in go 19:44 < icy> go clients that is 19:44 < chomp> in other words, it's up to you to actually close the connection 19:44 < chomp> yes 19:45 < icy> I don't have go clients 19:45 < icy> the server should close the connection aswell as the client with this header set 19:45 < ArgonneIntern> well....so what is the damn point then lol 19:45 < chomp> well, the point is communicatoin. 19:45 < chomp> what exactly is wrong with closing your own connections? 19:46 < ArgonneIntern> i'm using an http.Client 19:46 < ArgonneIntern> and it doesn't have a close 19:46 < ArgonneIntern> sadface 19:46 < ArgonneIntern> "Client is not yet very configurable." 19:46 < chomp> maybe you want a ClientConn? 19:47 < ArgonneIntern> yes I might have to change to client Conn 19:47 < chomp> it's a ReadWriteCloser 19:47 < ArgonneIntern> is it 19:47 -!- tgall_foo [~tgall@206.9.88.154] has joined #go-nuts 19:47 < chomp> looking at the http docs I can't help but parse a very juvenile message directly under "type Client" 19:48 < ArgonneIntern> lol 19:48 < chomp> in the index that is 19:50 < chomp> it's actually not a proper ReadWriteCloser, but it does provide a Read, a Write and a Close :) 19:51 < ArgonneIntern> Client? 19:51 < chomp> ClientConn 19:51 < ArgonneIntern> ohhh 19:51 < ArgonneIntern> wow I thought I was really stupid 19:51 < ArgonneIntern> I was trying to close it, saying to myself....it doesn't have a close ffs! 19:51 -!- prip [~foo@host22-24-dynamic.43-79-r.retail.telecomitalia.it] has joined #go-nuts 19:51 < ArgonneIntern> but yes I see the clientconnc lose 19:52 < chomp> unfortunately clientconn is pretty low level 19:52 < ArgonneIntern> Id on't see why you would institute a client package without a close 19:52 < ArgonneIntern> yea 19:53 < chomp> are you just using Get? 19:53 < ArgonneIntern> no mostly i'm posting 19:54 < ArgonneIntern> wonder if they would except a change to http.Client that auto closes on the close connection in the response header 19:55 < ArgonneIntern> clientConn shouldn't as it's lower level, but http.Client is much higher level so maybe it would be appropriatte? 19:56 -!- Halavanja [~chatzilla@anlextwls002-095.wl.anl-external.org] has quit [Ping timeout: 240 seconds] 19:58 < ArgonneIntern> icy: server won't close the connection using handlerfuncs 19:58 < ArgonneIntern> icy: and there does not appear to be a close in that package. Same with http.Client. So you need to switch to clientConn, and/or serverConn 19:59 < chomp> well as he said he's not using go clients 19:59 < chomp> a proper http client will adhere to the Connection: close header 20:01 < icy> the server should adhere to what he says too :) 20:01 -!- tncardoso [~thiago@189.59.185.173.dynamic.adsl.gvt.net.br] has joined #go-nuts 20:01 < ArgonneIntern> icy: listenAndServe definitely doesn't 20:02 < ArgonneIntern> in fact none of them do implicitely, only some do explicitly 20:02 -!- bakedb [~kel@cpc4-lea21-0-0-cust755.6-3.cable.virginmedia.com] has joined #go-nuts 20:02 < icy> I just tried it with telnet btw, the server does not close the connection 20:02 < icy> even though it advertises Connection: close 20:03 < ArgonneIntern> in the response? 20:03 < ArgonneIntern> or in the request 20:03 < icy> the response 20:03 < ArgonneIntern> doesn't matter, there isn't a go package that explicitly will close the connection on either client or server 20:03 < icy> if I send Connection: close in the request, then the server closes the connection properly 20:04 < ArgonneIntern> we just spent the last hour and a half proving that 20:04 < ArgonneIntern> err implictly 20:04 < chomp> icy, actually if the client request coming into the go http server has Connection set to close, it looks like the server will close the connection... maybe. 20:04 < ArgonneIntern> sorry 20:04 < icy> chomp: what I just said too :) 20:04 < chomp> ah yeah 20:04 < icy> you can try it with golang.org and telnet hehe 20:04 < chomp> setting req.Close = true in your handler does nothing - go doesnt care about the request at all once it's handed it off to you 20:05 < icy> chomp: well, it does seem to trigger a Connection: close header in the response 20:05 < ArgonneIntern> there isn't a way to set the http.Client request header is there? 20:05 < ArgonneIntern> for the go client 20:05 < chomp> not that i can tell ArgonneIntern 20:06 < icy> you can use http.Client.Do() with your own request 20:06 < ArgonneIntern> looks like I'm switching to client conns, since http.Client is useless? 20:07 -!- dgnorton [~dgnorton@97.65.135.112] has quit [] 20:07 < ArgonneIntern> actually icy that might work 20:08 < chomp> oh snap 20:08 < ArgonneIntern> :P 20:08 < xb95> http://en.wikipedia.org/wiki/High-frequency_trading 20:08 < xb95> Dammit, sorry. 20:08 < chomp> xb95, well hello 20:08 < chomp> gief money please. 20:09 < icy> :) 20:11 -!- bakedb [~kel@cpc4-lea21-0-0-cust755.6-3.cable.virginmedia.com] has quit [Quit: Ex-Chat] 20:11 -!- prip [~foo@host22-24-dynamic.43-79-r.retail.telecomitalia.it] has quit [Ping timeout: 276 seconds] 20:11 < ArgonneIntern> icy: so if you send close to the server in the header it closes? 20:12 < ArgonneIntern> for the request 20:13 < icy> yes 20:14 < ArgonneIntern> so you solved your massive go routines? 20:14 -!- Halavanja [~chatzilla@mcswl207.mcs.anl.gov] has joined #go-nuts 20:16 < icy> well I have no control over the clients, they are flash :/ 20:16 < icy> and you can't send headers from flash 20:17 < icy> I think though that after a long timeout, the connections get closed and the goroutines collected 20:18 < icy> problem is I have to wait ages to see the effects 20:19 < skelterjohn|work> is there no way to kill the connection serverside? 20:19 < skelterjohn|work> maybe have your own timeout mechanism with time.AfterFunc 20:20 < icy> that would be ugly 20:20 < skelterjohn|work> you think so? it seems fine to me 20:21 < skelterjohn|work> go func(aConnection ConnectionType) { <-time.After(TimeoutLength); aConnection.ForceClosed() }(aConnection) 20:22 < icy> well I mean you should not have to do this 20:23 < icy> the default http.Server has both timeouts set to 0 making them infinite, I think that's one issue 20:23 < icy> then there is w.closeAfterReply not properly being set 20:24 < skelterjohn|work> can you change the timeout length? 20:25 < chomp> icy, have you tried adding a simple patch to server.go which sets closeAfterReply in to true when Connection == "close"? 20:26 < chomp> just to see if the understanding is actually correct 20:26 < icy> manually yes. by using srv := &Server{Addr: ..., Handler: ..., ReadTimeout: ..., WriteTImeout: ...}; srv.ListenAndServe() 20:27 < ArgonneIntern> skelterjohn|work: you can close the connection server side, ify ou don't use http.Listenandserve 20:27 < icy> I think I will have to set those timeouts to something low anyways because my daemon can get massive numbers of requests at times 20:27 < ArgonneIntern> which he wants to use because it's really easy to set up 20:27 < skelterjohn|work> ah, yes ListenAndServe hides some things from you, but that's the price of convenience 20:27 < ArgonneIntern> skelterjohn|work: IMO the problem isn't listenandserve 20:27 < ArgonneIntern> it's http.Client 20:28 < ArgonneIntern> why that doesn't have a .Close() is not right 20:28 < ArgonneIntern> or at least an easy way to set that field and in the Post and Gets 20:28 < skelterjohn|work> does it even make sense for it to have a .Close() 20:28 < ArgonneIntern> not really which is why I just said what I did 20:29 < ArgonneIntern> what we really want to do set the header 20:29 < skelterjohn|work> don't Post() and Get() calls each create their own connections and close them when done? 20:29 < ArgonneIntern> no 20:29 < skelterjohn|work> o_O 20:29 < ArgonneIntern> connection is default set to keep-alive 20:29 < skelterjohn|work> i see 20:29 < ArgonneIntern> and there is no way to change it unless you do an http.Do 20:29 < ArgonneIntern> err http.Client.Do() 20:29 < icy> the problem with the simple interface is that I think you could DoS a server super easily as it has no way to close away connections 20:30 < skelterjohn|work> then it might be worth filing an issue about that 20:30 < ArgonneIntern> also icy has a point 20:30 < ArgonneIntern> it would be SUPER easy to do that 20:30 < chomp> to be fair keep-alive is the standard default behavior of an HTTP/1.1 connection. but yeah it should be possible to change that behavior even with a high level interface like Client 20:31 < icy> you can't even effectively implement "N connections per IP" limits 20:31 < ArgonneIntern> I have t personally thank icy lol, I wouldn't have noticed this until my daemon had 10k go routines 20:32 < icy> well, I get at peaks several thousand req/s so I'm worried about performance :) 20:32 -!- pharris [~Adium@rhgw.opentext.com] has quit [Quit: Leaving.] 20:33 < ArgonneIntern> I'm concerned about ticketing it because it says in http.Client that it's not finished yet 20:33 < icy> it's not only an issue of http.Client 20:33 < ArgonneIntern> so they may already know about it 20:33 < ArgonneIntern> "Client is not yet very configurable." 20:33 < ArgonneIntern> well I know 20:33 < ArgonneIntern> it's both really 20:33 -!- kfeng [~kfeng@host-58-114-183-56.dynamic.kbtelecom.net] has joined #go-nuts 20:33 < ArgonneIntern> the handler funcs should have a way to close connection also 20:34 < icy> in the server you get a ResponseWriter and Request, and you can't close them :) 20:34 < skelterjohn|work> ArgonneIntern: don't let that stop you from filing an issue 20:34 < icy> it doesn't expose any type of client or connection to you 20:34 < skelterjohn|work> the issue tracker serves as both a bug tracker and todo list 20:35 < ArgonneIntern> i'll report it lol 20:35 < ArgonneIntern> why not I have nothing to lose, people already know I'm a noob 20:36 < ArgonneIntern> http://code.google.com/p/go/issues/detail?id=1967&colspec=ID%20Status%20Stars%20Priority%20Owner%20Reporter%20Summary 20:36 < ArgonneIntern> nvm 20:36 < icy> imho Request.Close = true should result in ResponseWiter.closeAfterReply to be set to true 20:36 < ArgonneIntern> apparently it's a known issue 20:36 < ArgonneIntern> yes 20:36 < ArgonneIntern> read the link I just posted 20:36 < ArgonneIntern> it was accepted 20:37 < skelterjohn|work> be sure to check out brad's solution 20:37 -!- dreadlorde [~dreadlord@c-68-42-82-10.hsd1.mi.comcast.net] has joined #go-nuts 20:38 < icy> this is a related bug but not the same 20:39 < ArgonneIntern> it would solve the issue 20:39 < ArgonneIntern> as the server could close the connection 20:39 < ArgonneIntern> by moving the TCP close up in the interface 20:40 < ArgonneIntern> read down in the comments 20:40 < ArgonneIntern> also please star the issue 20:40 < icy> I did read it 20:40 < icy> but it's not the same 20:40 < icy> even if all data from the body was sent and it was closed, the connection remains open 20:41 < icy> as it does not realize it's not a keep-alive connection and tries to read another request 20:41 < icy> which by default has a timeout of 0 so it wait... well, a long time 20:42 < chomp> ah yeah it is not the same issue 20:42 < ArgonneIntern> there is a way for the client to not keep alive 20:42 < ArgonneIntern> brad you smart man you 20:42 < icy> but not for the server :) 20:43 < ArgonneIntern> http.Client.RoundTripper.DisableKeepAlives = true 20:43 -!- alsvidr [~textual@dslb-188-099-240-157.pools.arcor-ip.net] has joined #go-nuts 20:44 < chomp> and what i learned from that thread is that tip.goneat.org hosts a tip godoc site 20:44 < ArgonneIntern> imma try that. I'll still help you icy if it works for me, maybe we can find a similar 3-4 chain deep solution lol 20:44 < brad_> heh 20:44 < ArgonneIntern> it's brad! 20:44 < ArgonneIntern> brad this bug/issue is so annoying 20:44 < ArgonneIntern> lol 20:45 < brad_> ha 20:45 < brad_> I am not the same brad 20:45 < brad_> :) 20:45 < ArgonneIntern> oh 20:45 < ArgonneIntern> it's ok, you're still cool in my book 20:46 < brad_> anyone who likes go is a friend of mine 20:46 < brad_> :) 20:47 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-153-41.clienti.tiscali.it] has quit [Read error: Connection reset by peer] 20:47 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-153-41.clienti.tiscali.it] has joined #go-nuts 20:48 -!- zozoR [~Morten@2906ds2-arno.0.fullrate.dk] has quit [Remote host closed the connection] 20:49 -!- alehorst [~alehorst@189.58.23.72.dynamic.adsl.gvt.net.br] has quit [Quit: Leaving.] 20:49 -!- Transformer [~Transform@ool-4a59e397.dyn.optonline.net] has joined #go-nuts 20:50 -!- alsvidr [~textual@dslb-188-099-240-157.pools.arcor-ip.net] has quit [Quit: Textual IRC Client: http://www.textualapp.com/] 20:50 -!- kamaji [~kamaji@cpc2-aztw22-2-0-cust775.aztw.cable.virginmedia.com] has joined #go-nuts 20:51 < kamaji> hi all, quick question: trying to build go on my laptop but the getting started guide doesn't produce a binary 20:51 < kamaji> what do? 20:51 < kamaji> when running all.bash 20:51 < kamaji> i've tried deleting the entire repository and re-downloading it 20:52 -!- Transformer [~Transform@ool-4a59e397.dyn.optonline.net] has quit [Excess Flood] 20:52 < ArgonneIntern> grr so that doesn't work 20:53 < ArgonneIntern> RoundTripper is not of a type transport 20:53 < ArgonneIntern> MFER 20:53 < ArgonneIntern> this is so annoying lol 20:53 < str1ngs> kamaji: what error? 20:53 < kamaji> str1ngs: no error 20:53 < str1ngs> kamaji: also do you have the prereqa? 20:53 < skelterjohn|work> kamaji: does it take 5 minutes to run? 20:53 < str1ngs> ed bison gcc make etc 20:53 < kamaji> skelterjohn|work: nope 20:53 < kevlar_work> kamaji, do you have ed and bison installed? 20:54 < skelterjohn|work> someone should really add something to make.bash to check that dependency.... 20:54 < kamaji> I did last time 20:54 < kamaji> let me chekc 20:54 < kamaji> I'm guessing no 20:54 < kamaji> goddamnit 20:54 < skelterjohn|work> :) 20:54 < kamaji> thanks :p 20:54 -!- virtualsue [~chatzilla@nat/cisco/x-jvwyxhzxuhrljvtn] has quit [Ping timeout: 252 seconds] 20:54 < kamaji> cba to run tests, make.bash will run as well, right? 20:54 < str1ngs> kamaji: pacman -S base-devel 20:55 < skelterjohn|work> yes 20:55 < str1ngs> but you still need ed iirc 20:55 < skelterjohn|work> i almost never run all.bash 20:55 < str1ngs> kamaji: if you are still running arch of course :P 20:55 < kamaji> of course :D 20:55 < kamaji> I think I have base-devel already 20:55 < str1ngs> so probably just ed 20:55 < kamaji> jeap 20:55 < kamaji> it's taking a billion years to run now, so that looks like a success 20:56 < str1ngs> why I like ./make.bash 20:56 -!- virtualsue [~chatzilla@nat/cisco/x-etbdllocgpwjcxbs] has joined #go-nuts 20:56 < kamaji> hooray for the Atom processor 20:56 < str1ngs> atom 20:56 < str1ngs> oh use ./make.bash imo 20:56 < kamaji> I am 20:56 < kamaji> I don't know if this netbook would ever finish all.bash 20:56 < kamaji> it might just melt instead 21:01 < kevlar_work> skelterjohn, it's been added to tip, maybe weekly 21:01 < kevlar_work> skelterjohn, also, the ed dependency is going away in tip too. 21:02 < skelterjohn|work> oh... good, then 21:05 < kevlar_work> at least, I think it got checked in. 21:05 -!- robteix [~robteix@nat/intel/x-vmrusavikismhzxk] has quit [Ping timeout: 255 seconds] 21:05 < kevlar_work> now that I think about it, I'm not sure if I saw the *** SUBMITTED message. 21:07 < kamaji> oh bugger, there appears to be an error in some code somewhere 21:07 < kevlar_work> kamaji, in what code? 21:07 < kevlar_work> everything (woah) is green on http://godashboard.appspot.com/ 21:08 < kevlar_work> I'm not sure I've ever seen a full page of OK on there before. 21:08 < kamaji> haha 21:08 < kamaji> it was complaining there was a char where it wanted const char 21:08 -!- Nitro [~Nitro@unaffiliated/nitro] has quit [Ping timeout: 240 seconds] 21:08 < kamaji> I just changed it, i'll see if that works~ 21:08 < kevlar_work> kamaji, you need bison not bison++ 21:08 -!- virtualsue [~chatzilla@nat/cisco/x-etbdllocgpwjcxbs] has quit [Ping timeout: 250 seconds] 21:08 < kamaji> I just assumed the arch package "bison" was that 21:08 < kamaji> lemme look 21:09 -!- alkavan [~alkavan@IGLD-84-228-136-116.inter.net.il] has joined #go-nuts 21:09 < kamaji> yeah, seems to be regular bison? 21:10 < kevlar_work> what version? 21:10 < kamaji> 2.5 21:11 < kevlar_work> what's the error message? 21:11 < kevlar_work> I know I've seen this on the ML but can't find it. 21:11 < icy> haha I think I found a hack to force closing of connections. I can overwrite req.ProtoMinor to 0 which makes it set w.closeAfterReply to true and close the connection :D 21:12 < kamaji> kevlar_work: rebuilding, hang on 21:12 < kamaji> y.tab.c:5203:9: error: passing argument 1 of 'yyerror' discards 'const' qualifier from pointer target type [-Werror] 21:13 < icy> ArgonneIntern 21:13 < ArgonneIntern> icy: 21:13 < kamaji> oh, issue with 2.5 apparently 21:13 < icy> read what I just wrote, might help you too 21:13 < kevlar_work> either that or too recent GCC 21:13 <+iant> kamaji: that is fixed on tip, I believe, perhaps not in a release yet 21:14 -!- fvbommel [~fvbommel_@86.86.15.250] has quit [Read error: Connection reset by peer] 21:14 < kevlar_work> oh, nevermind. 21:14 < kevlar_work> I didn't read far enough down the thread >:-) 21:14 < ArgonneIntern> icy: what is protominor 21:14 < kamaji> hehe 21:14 < icy> ArgonneIntern: HTTP/1.1 <- second number 21:14 < kevlar_work> ArgonneIntern, the minor protocol (HTTP/1.1) version number 21:14 < huin> i'm wondering about the heap profiling stuff. is it showing me how much memory has been allocated (and potentially been freed), or is it telling me how much is still in use? 21:14 < ArgonneIntern> oh 21:14 < icy> HTTP/1.0 does not do keep-alive by default 21:14 < ArgonneIntern> lmao 21:14 < kevlar_work> http/1.0 had much different ideas about connections 21:14 < ArgonneIntern> hmm let me try 21:15 < kevlar_work> huin, Go (almost) never returns memory to the operating system after it allocates 21:15 < kamaji> iant: oh, release is the one I have 21:15 < ArgonneIntern> wait...this is from the client tot he server 21:15 < icy> I do it on the server 21:15 < ArgonneIntern> this doesn't solve the server issue 21:15 < huin> kevlar_work: well i mean "freed" as in malloc-freed 21:15 < ArgonneIntern> on request? 21:15 -!- virtualsue [~chatzilla@nat/cisco/x-zqffhnrlbirfforn] has joined #go-nuts 21:15 < ArgonneIntern> that seems odd 21:15 -!- exch [~blbl@87.209.181.34] has quit [Ping timeout: 264 seconds] 21:15 < icy> I overwrite the protominor of the request :) 21:15 < icy> hence why I said it's a hack :D 21:16 < kevlar_work> huin, afaik, it doesn't report anything about the few small things that do get free()d 21:16 < kevlar_work> in general, if you make([]int, 1024*1024), that memory is never going back to the OS. 21:16 < huin> it's not about going back to the OS that worries me 21:16 <+iant> kamaji: hmmm, actually the patch was committed May 26, isn't that in a release yet? 21:17 < ArgonneIntern> icy: omfg you are a genius 21:17 < huin> it's about memory not being released back to the malloc pool 21:17 < ArgonneIntern> it works 21:17 < ArgonneIntern> that saves me so much work reworking all this code 21:17 < kevlar_work> huin, the OS == the malloc() pool 21:17 < huin> malloc is not a system call 21:17 < kevlar_work> icy/argonne, you might post that solution to the bug and/or mailing list. 21:18 <+iant> http://code.google.com/p/go/issues/detail?id=1843 21:18 < kevlar_work> huin, what is your actual issue? 21:18 -!- Fish [~Fish@9fans.fr] has quit [Quit: So Long, and Thanks for All the Fish] 21:18 < ArgonneIntern> it really should have already read protominor before giving the func access to the request lol 21:18 < ArgonneIntern> it's kinda fishy that it doesn't 21:18 < kevlar_work> huin, when Go gets memory from the operating system using malloc(), it is then given to a Go object, which can be reclaimed by the go runtime by the garbage collector 21:18 < huin> kevlar_work: possible memory leak, and i'm needing to know how to interpret the heap profile output properly 21:18 < kevlar_work> even if this happens, it is not free()d. 21:18 < icy> it did read it, but it does read it again when finishing the request :) 21:19 < huin> kevlar_work: okay, well gc'd then 21:19 < ArgonneIntern> so then why doesn't setting close and connection:close in the request work? 21:19 < kamaji> iant: well I tried tip, same error 21:19 < kamaji> tip is the most recent, right? 21:19 < icy> I'm not sure about that one yet 21:19 < kevlar_work> can you nopaste your heap profile output? there are a few different ways to get at it. 21:19 < huin> kevlar_work: although i was under the impression that the GC uses free() under the hood, and free is just part of the malloc lib 21:19 < ArgonneIntern> I'm going to report this as an issue 21:19 < kevlar_work> kamaji, hg pull -u == tip 21:19 <+iant> kamaji: is it the same error that is in that issue? 21:20 < ArgonneIntern> it is seperate of their issue 21:20 < kamaji> oh, I was doing "hg pull -r tip" 21:20 < kevlar_work> that may work too. 21:20 -!- DisposaBoy [~DisposaBo@109.123.79.26] has quit [Ping timeout: 255 seconds] 21:20 < kamaji> hm, it says "no changes found" 21:20 < icy> ArgonneIntern: to be honest I have a feeling that there can be many more things dug up in the http package 21:20 < kevlar_work> huin, not in the gc compiler, not sure about gccgo. 21:21 -!- cafesofie [~cafesofie@ool-18b97779.dyn.optonline.net] has quit [Remote host closed the connection] 21:21 < kamaji> kevlar_work: hg pull -u == tip just errors for me 21:21 < ArgonneIntern> icy: this issue is fairly important though and needs to be addressed sooner than later, if the package is to be taken seriously 21:21 < kevlar_work> kamaji, I meant: `hg pull -u` is tip 21:21 < huin> kevlar_work: i've got a heap profile sitting on disk at the moment, although i don't know how much use it is to anyone else unless i upload the binary with it 21:22 < ArgonneIntern> icy I'm off for the night, good working with you on this issue 21:22 < kamaji> kevlar_work: oh.... hehe. well that has no changes 21:22 < icy> ArgonneIntern: agreed, btw I know why the header does not work 21:22 < kevlar_work> huin, I meant the text output you get when you run it. have you read http://blog.golang.org/2011/06/profiling-go-programs.html ? 21:22 < kamaji> but weirdly, no changes for pull -r release 21:22 < kamaji> so i'm not sure what's going on 21:22 < ArgonneIntern> icy: why 21:22 < huin> kevlar_work: yes 21:22 < kevlar_work> kamaji, pull -r release won't pull anything new 21:22 < icy> look at server.go lines 181 and 192, those are the only lines that can make it close the connection 21:22 < huin> i'll paste that then 21:22 < kevlar_work> you have to update after pull to get the changes 21:22 < kamaji> oh... 21:22 < icy> and it only gets there if the proto is not 1.1 21:22 < kevlar_work> update -r release will update to release, update will update to tip 21:23 < kamaji> ah I see. 21:23 < huin> kevlar_work: http://paste.pocoo.org/show/421613/ 21:23 < kamaji> third time lucky then maybe :) 21:23 < kevlar_work> (at least I'm pretty sure that's all right; I get confused by mercurial sometimes after using git for awhile) 21:24 -!- hpvincent [~zig@nap13-11-83-156-121-34.fbx.proxad.net] has quit [Remote host closed the connection] 21:24 < kevlar_work> huin, okay, so what about this bothers you? 21:24 < huin> kevlar_work: i want to know if the 95MiB allocated by doDefault has been freed 21:24 < ArgonneIntern> icy: WOW, this handles http 1.1 very poorly lol 21:25 < kevlar_work> huin, is this a short-running program? 21:25 < huin> kevlar_work: nope. daemon 21:25 -!- flaguy48 [~gmallard@user-0c6s350.cable.mindspring.com] has left #go-nuts [] 21:25 < huin> well, server anyway 21:25 < kevlar_work> huin, are you using http/pprof? 21:25 < icy> ArgonneIntern: handling http properly is btw pretty hard 21:26 < huin> kevlar_work: not in this case, but i can enable it 21:26 < icy> in fact, I'd bet there is no webserver out there that handles it *completely* right in every respect :) 21:26 < kamaji> kevlar_work: ah that's worked 21:26 < kamaji> cheers! 21:26 < kevlar_work> kamaji, no problem. 21:27 < kevlar_work> huin, that and http://golang.org/pkg/runtime/#MemProfile might help you examine some things better 21:28 < ArgonneIntern> icy: does line 160 ever get called anywhere 21:28 < kevlar_work> MemProfileRecord has alloc/free/inuse stats for you. 21:29 < icy> ArgonneIntern: yes, if you send it an Expect: 100-continue header 21:29 < huin> kevlar_work: yeah. already got those. most of the memory is used up by quite small allocations. not that it tells me where they were allocated 21:29 < icy> it replaces the req.Body with the expectreader 21:29 < huin> kevlar_work: using the http/pprof method just gives me the same answer as before 21:30 < kevlar_work> huin, http/pprof can allow you to get an idea over time of what it looks like, memprofile tells you how much has been freed. 21:30 < kevlar_work> and by freed, I mean garbage collected. 21:30 < kevlar_work> it won't get free()d either way. 21:31 < ArgonneIntern> icy: anyways you have a better grasp on this than I do. Maybe you should report it, the bug tracker location is in the orc channel greeting.title thing 21:31 < huin> indeed. i have compared the two and the amount of memory that has been malloc'd and hasn't been freed is consistent with what the heap profiler tells me 21:31 < ArgonneIntern> icy: make sure to mention the hack in case anyone else has this issue 21:31 < kevlar_work> huin, you might want to break your thinking away from malloc/free. 21:32 < kevlar_work> they're not helpful concepts when reasoning about memory in Go. 21:32 < kevlar_work> especially when it comes to the actual memory footprint of your application. 21:32 < huin> kevlar_work: i honestly don't think that's a useful comment. memory is allocated, and freed. 21:32 < huin> free is not a system call 21:33 < huin> it's not an important distinction here whether the free is manual or GC. it can only be by the GC 21:33 -!- ijknacho [~goofy@cpe-72-190-64-3.tx.res.rr.com] has quit [Ping timeout: 240 seconds] 21:36 < kevlar_work> huin, they're not helpful concepts because when/whether you allocate memory on the heap is out of your control, and when/whether memory you do allocate is available for reuse is also (unless you explicitly remove references and call runtime.GC) outside of your control 21:36 < kevlar_work> thus, your reasoning should be more about making sure you don't maintain spurious references to memory you don't need and keeping things on the stack when you can 21:37 -!- exch [~blbl@ip34-181-209-87.adsl2.static.versatel.nl] has joined #go-nuts 21:37 < huin> well quite. and that's the problem i'm trying to track down as to why this memory is still allocated 21:37 < huin> i don't see why you think my reasoning has a problem 21:38 < kevlar_work> well, tracking down where the memory is in use should be pretty straightforward given that you have the heap profile 21:38 < kevlar_work> I would take a closer look at whoever is calling deflate 21:39 -!- Halavanja [~chatzilla@mcswl207.mcs.anl.gov] has quit [Quit: ChatZilla 0.9.87 [Firefox 5.0/20110622232440]] 21:40 < huin> kevlar_work: as far as i can tell i'm only compressing in one place in the program 21:41 < huin> and that place closes the zlib writer when complete 21:41 < kevlar_work> huin, but what are you doing with what's returned from it 21:42 -!- ArgonneIntern [82ca0251@gateway/web/freenode/ip.130.202.2.81] has quit [Ping timeout: 252 seconds] 21:42 < huin> it writes bytes into a bytes.Buffer, which should also be freed 21:43 < huin> the actual data written to the buffer is kept, but the size of those slices is around the 4k mark 21:43 < huin> those only account for a few MiB 21:44 < huin> it's the internal buffers inside the flate compressor that don't appear to be freed, and it's not obvious to me why. that's the problem i'm trying to figure out 21:44 < kevlar_work> huin, keep in mind that when you write past the end of the bytes.Buffer, it will be reallocated, and that allocation will probably look like it's coming from whoever was writing to it 21:45 < huin> i would expect that memory to be attributed to code in bytes.Buffer 21:45 < huin> bytes.Buffer allocates a new, bigger, slice when it needs to, then copies the original data and the new data into it 21:45 < kevlar_work> huin, well, have you looked at what lines of code it's attributing the memory? 21:46 < huin> the 90 to 95MiB? 21:46 -!- virtualsue [~chatzilla@nat/cisco/x-zqffhnrlbirfforn] has quit [Ping timeout: 264 seconds] 21:47 < kevlar_work> any of them, but sure that seems like a sensible place to start. 21:47 < huin> yes, that's in that paste i did a while ago 21:47 < kevlar_work> go reread the blog post I linked. 21:47 < huin> on a line-by line basis it's: http://paste.pocoo.org/show/421645/ 21:47 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit: Verlassend] 21:48 < kevlar_work> that's on a function-by-function basis 21:48 -!- chomp [~chomp@dap-209-166-184-50.pri.tnt-3.pgh.pa.stargate.net] has quit [Quit: Leaving] 21:48 < huin> no, that last paste is on line by line 21:48 < huin> the original was per function 21:48 -!- flaguy48 [~gmallard@user-0c6s350.cable.mindspring.com] has joined #go-nuts 21:48 < kevlar_work> I'm talking about using pprof `list` 21:48 < kevlar_work> which shows you a function with the memory each line of the function has allocated 21:48 < kevlar_work> as in the blog post 21:48 < huin> that unfortunately does not work for me 21:49 < huin> however the output from top10 for line-by-line gives sane results 21:49 < huin> it's just missing filenames, which is presumably why the list command doesn't work 21:50 < kevlar_work> try it in $GOROOT/src/pkg 21:50 < kevlar_work> though I don't know if that will help. 21:51 < kevlar_work> have you looked at the svg output, as suggested by the blog post? 21:51 < kevlar_work> that can give you a good idea of who's calling what. 21:51 < huin> sadly not 21:51 < huin> and yes, i'm looking at the SVG 21:51 -!- sniper506th [~sniper506@rrcs-70-61-192-18.midsouth.biz.rr.com] has quit [Quit: Leaving...] 21:51 < kevlar_work> huin, the other thing to remember is that you probably don't see the bytes.buffer calls because they're so fast, the memory profiler can't/doesn't see them 21:51 -!- piranha [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has quit [Quit: Computer has gone to sleep.] 21:51 < huin> apart from missing the filenames etc. - the output of the profiler seems clear enough 21:52 -!- smw [~stephen@unaffiliated/smw] has quit [Ping timeout: 255 seconds] 21:52 < huin> i dunno about that last part though... the results of it look consistent with what i'd expect 21:52 < kevlar_work> so I think it's pretty clear that buffers from deflate are being kept around; whether this is a bug or not I can't tell you. 21:53 -!- mrsrikanth [~mrsrikant@59.92.81.39] has quit [Quit: Leaving] 21:53 < huin> there's an entry for bytes.*Buffer.grow() which shows a value i've seen elsewhere and looks sanely low 21:53 < kevlar_work> (a bug in your code; it's less likely a bug in compress) 21:53 < huin> but yeah - what you say is my conclusion 21:53 -!- prasmussen [pii@rasm.se] has quit [Ping timeout: 255 seconds] 21:53 < kevlar_work> huin, that means only that it didn't see it very many times 21:53 < huin> and yeah, my suspicion is on my own code first 21:53 < icy> hehe with my ProtoMinor hack, I'm down to 5 goroutines from 60 :) 21:53 -!- i__ [~none@unaffiliated/i--/x-3618442] has quit [Ping timeout: 244 seconds] 21:53 -!- russell_h [~russell_h@osuosl/staff/russellh] has quit [Ping timeout: 244 seconds] 21:54 -!- prasmussen [pii@rasm.se] has joined #go-nuts 21:54 < kevlar_work> icy, did you report your hack? 21:54 -!- i__ [~none@69.164.206.224] has joined #go-nuts 21:54 -!- russell_h [~russell_h@ash.osuosl.org] has joined #go-nuts 21:54 < icy> yes and I made a typo in the ticket title... :( 21:55 < icy> http://code.google.com/p/go/issues/detail?id=2011 21:55 < kevlar_work> lol. whatever ;-) 21:55 < icy> can't seem to be able to edit it 21:56 < kevlar_work> icy, btw, you're not eating up file descriptors by having open connections, at least you shouldn't be with epoll/kqueue 21:56 < kevlar_work> but yes, goroutines cost memory. 21:57 < icy> ah damnit another typo in there. should be Request.ProtoMinor not w.ProtoMinor. why can't I edit this thing :( 21:57 < icy> kevlar_work: hu? epoll/kqueue do not help with file descriptor limits 21:58 < icy> they just make them less expensive when idle 21:58 < kevlar_work> *shrug* I could be wrong. 21:58 < huin> i'll have to work on this tomorrow. bedtime for me 21:58 < kevlar_work> icy, you just have to post a comment. 21:58 -!- huin [~huin@91.85.188.1] has quit [Quit: bedtime] 22:00 -!- cenuij [~cenuij@184.15.8.109.rev.sfr.net] has joined #go-nuts 22:00 -!- cenuij [~cenuij@184.15.8.109.rev.sfr.net] has quit [Changing host] 22:00 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts 22:07 < kamaji> alright cheers for the help everyone! 22:07 < kamaji> i'm off to bed 22:07 -!- kamaji [~kamaji@cpc2-aztw22-2-0-cust775.aztw.cable.virginmedia.com] has quit [Quit: sleeep] 22:08 -!- piranha [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts 22:13 -!- awidegreen [~quassel@h-170-226.A212.priv.bahnhof.se] has quit [Ping timeout: 240 seconds] 22:16 -!- dreadlorde [~dreadlord@c-68-42-82-10.hsd1.mi.comcast.net] has quit [Ping timeout: 258 seconds] 22:18 -!- niekie [~niek@CAcert/Assurer/niekie] has quit [Quit: No Ping reply in 180 seconds.] 22:18 -!- niekie [~niek@CAcert/Assurer/niekie] has joined #go-nuts 22:18 -!- KBme [~KBme@2001:470:cabe:666:666:666:666:666] has quit [Quit: KBme kthxbye] 22:18 -!- KBme [~KBme@2001:470:cabe:666:666:666:666:666] has joined #go-nuts 22:20 -!- Xenith [~xenith@xenith.org] has quit [Ping timeout: 260 seconds] 22:20 -!- Xenith [~xenith@xenith.org] has joined #go-nuts 22:21 -!- piranha [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has quit [Quit: Computer has gone to sleep.] 22:21 -!- Natch| [~natch@c-adcee155.25-4-64736c10.cust.bredbandsbolaget.se] has quit [Ping timeout: 240 seconds] 22:22 -!- russell_h [~russell_h@ash.osuosl.org] has quit [Changing host] 22:22 -!- russell_h [~russell_h@osuosl/staff/russellh] has joined #go-nuts 22:22 -!- chomp [~chomp@c-67-186-35-69.hsd1.pa.comcast.net] has joined #go-nuts 22:22 -!- Natch| [~natch@c-adcee155.25-4-64736c10.cust.bredbandsbolaget.se] has joined #go-nuts 22:23 -!- arun_ [~arun@e71020.upc-e.chello.nl] has joined #go-nuts 22:23 -!- arun_ [~arun@e71020.upc-e.chello.nl] has quit [Changing host] 22:23 -!- arun_ [~arun@unaffiliated/sindian] has joined #go-nuts 22:26 -!- chomp [~chomp@c-67-186-35-69.hsd1.pa.comcast.net] has quit [Read error: Connection reset by peer] 22:27 -!- chomp_ [~chomp@c-67-186-35-69.hsd1.pa.comcast.net] has joined #go-nuts 22:37 -!- Domtron_Vox [~chatzilla@196.sub-174-254-146.myvzw.com] has joined #go-nuts 22:42 -!- Nitro [~Nitro@unaffiliated/nitro] has joined #go-nuts 22:43 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the connection] 22:50 -!- Slant [~scott@124-168-223-48.dyn.iinet.net.au] has joined #go-nuts 22:51 -!- rlab [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 22:51 -!- r_linux [~r_linux@static.200.198.180.250.datacenter1.com.br] has quit [Quit: lalala caindo fora] 22:57 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has quit [Remote host closed the connection] 22:58 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has joined #go-nuts 22:59 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-153-41.clienti.tiscali.it] has quit [Quit: E se abbasso questa leva che succ...] 23:04 -!- dreadlorde [~dreadlord@c-68-42-82-10.hsd1.mi.comcast.net] has joined #go-nuts 23:06 -!- Adys_ [~Adys@unaffiliated/adys] has joined #go-nuts 23:06 -!- Adys_ [~Adys@unaffiliated/adys] has quit [Client Quit] 23:07 -!- Slant [~scott@124-168-223-48.dyn.iinet.net.au] has quit [Quit: Slant] 23:11 -!- warlock_mza [~warlock@86-91-231-201.fibertel.com.ar] has joined #go-nuts 23:11 -!- pjacobs [~pjacobs@66.54.185.130] has quit [Ping timeout: 252 seconds] 23:15 -!- fvbommel [~fvbommel_@86.86.15.250] has joined #go-nuts 23:16 -!- franciscosouza [~francisco@201.7.186.67] has quit [Quit: franciscosouza] 23:24 -!- StoVoKor [~va3atc@24-246-17-37.cable.teksavvy.com] has joined #go-nuts 23:24 -!- va3atc [~va3atc@24-246-17-37.cable.teksavvy.com] has quit [Read error: Connection reset by peer] 23:24 -!- napsy [~luka@88.200.96.18] has quit [Ping timeout: 276 seconds] 23:28 -!- StoVoKor [~va3atc@24-246-17-37.cable.teksavvy.com] has quit [Ping timeout: 246 seconds] 23:40 -!- robteix [~robteix@host243.200-82-125.telecom.net.ar] has joined #go-nuts 23:40 -!- purple10 [~Kareem@79-78-93-1.dynamic.dsl.as9105.com] has joined #go-nuts 23:44 -!- graftenberg [~graftenbe@ip69-17-252-231.vif.net] has joined #go-nuts 23:44 < graftenberg> has anyone used the mgo (the go mongo libs)? 23:45 < jessta> graftenberg: briefly 23:45 < kevlar_work> icy, looks like your issue got fixed :o 23:46 < chomp> i noticed that too :p 23:46 < kevlar_work> that was fast. 23:46 < kevlar_work> bradfitz ftw. 23:46 < chomp> three cheers for fitz 23:46 < chomp> on a totally unrelated note, has goinstall or cgo behavior changed substantially in the last week or so? 23:47 -!- purple10 [~Kareem@79-78-93-1.dynamic.dsl.as9105.com] has left #go-nuts [] 23:47 < chomp> goinstall is suddenly failing to build a cgo package of mine, and it appears to be failing to link properly 23:50 < jessta> chomp: I think the go/build package changes broke cgo 23:51 -!- franciscosouza [~francisco@187.105.0.229] has joined #go-nuts 23:51 < chomp> hrm 23:51 < jessta> ummm...broke goinstall's ability to use cgo 23:51 < chomp> heh 23:51 < chomp> guess i'll poke around the code 23:53 < kevlar_work> git checkout HEAD^ ftw 23:54 < kevlar_work> (s//insert-hg-equivalent-here/) 23:54 < schmichael> hg update -C default # use with caution 23:54 < chomp> is that the same as tip? 23:54 < chomp> <- mercurial noob 23:54 < schmichael> ah no, default is a branch name 23:54 < schmichael> tip == HEAD 23:55 < schmichael> default == master 23:55 < chomp> ah. unfortunately my package now also depends on a change that just went into tip :) 23:57 < chomp> actually i probably just need to rebuild goinstall 23:58 -!- pjacobs [~pjacobs@75-27-133-72.lightspeed.austtx.sbcglobal.net] has joined #go-nuts 23:58 < kevlar_work> yeah, gotta love it: I needed something new from net, but really wanted pre-cgo net 23:58 < kevlar_work> alas, Go is a moving target. 23:58 < chomp> yeah that did it. apparently now goinstall will use a Makefile to build. yay. 23:58 < kevlar_work> But that's why it's an exciting time to be working on it. 23:59 < str1ngs> chomp: you using pkg-config? 23:59 < chomp> it's nice to see a project evolving so rapidly 23:59 < chomp> and yet relatively (!) stable 23:59 < str1ngs> as in the cgo directive 23:59 < kevlar_work> (I mean, hello, what other programming language still needs its XML marshalling written?) 23:59 < chomp> str1ngs, no, i am only using LDFLAGS 23:59 < kevlar_work> (It's nice to contribute something people might be able to use) 23:59 < str1ngs> chomp: hmm I know pkg-config is broke but I think LDFLAGS still works 23:59 < chomp> but recently a -make flag was added to goinstall (true by default) which uses a Makefile to build instead of whatever it was doing before --- Log closed Tue Jun 28 00:00:01 2011