--- Log opened Wed Dec 08 00:00:37 2010 00:01 -!- thomas_b [~thomasb@cm-84.215.47.51.getinternet.no] has quit [Ping timeout: 265 seconds] 00:03 < cbeck> Before I get too much further into the guts of fftw, does anyone know of an existing wrapper package? (or any FFT package for that matter) 00:07 -!- MX80 [~MX80@cust222.253.117.74.dsl.g3telecom.net] has joined #go-nuts 00:14 -!- terrex [~terrex@84.122.72.127.dyn.user.ono.com] has quit [Quit: Leaving.] 00:20 -!- kanru [~kanru@2001:c08:3700:ffff::2b:dbc8] has joined #go-nuts 00:24 < foocraft> okay, I just had the worst parallel implementation of mergeSort in parallel run on my machine 00:24 < foocraft> (the one I wrote) 00:24 < foocraft> I think it was creating new arrays like crazy and I ran out of memory 00:24 -!- iant [~iant@nat/google/x-rdnxuijpctgaulvu] has quit [Ping timeout: 272 seconds] 00:25 < exch> :p 00:25 < exch> allocaiton is not your friend 00:25 < exch> *allocation 00:26 < foocraft> yeah I think I should figure out how to use a slice 00:26 < exch> You should probably not deal with fixed size arrays at all. Pretty much everything in Go is handled with slices 00:26 < foocraft> my split basically returns an array of arrays ( because I didn't know you can return multiple values when I wrote it :p), so now I want it to return two slices 00:27 -!- noff [~noff@89-55.79-83.cust.bluewin.ch] has quit [Ping timeout: 240 seconds] 00:27 -!- rejb [~rejb@unaffiliated/rejb] has quit [Quit: .] 00:28 -!- noff [~noff@89-55.79-83.cust.bluewin.ch] has joined #go-nuts 00:30 -!- iant [~iant@66.109.105.230] has joined #go-nuts 00:30 -!- mode/#go-nuts [+v iant] by ChanServ 00:31 < krutcha> if you're resizing slices a lot you may be allocating new arrays under the hood, and relinquishing old ones to the garbage collector 00:32 < krutcha> but what did you do before to run out of memory? 00:32 < foocraft> http://fpaste.org/pZue/ 00:33 < krutcha> I'm not 100% on where allocations take place with slices, I just assume if/when I resize a slice the underlying array gets released and a new one is created. 00:33 < foocraft> I think when you resize a slice, it will just have a different length and there will be no allocation, its memory range will just change 00:34 < foocraft> so I would imagine a slice to be implemented using two values, "low" and "high" 00:34 < exch> Anytime you do a make(), an allocation takes place. the append() funciton does that internally if and when necessary (eg: the capacity of the target slice insufficient to contain all values pushed into it) 00:34 < krutcha> I doubt that, a slice sits on an actual array which is contiguous memory. you can't just go farther off the end without reallocating. 00:35 < foocraft> yeah that makes sense, but only because the range it's representing is less than the range you're asking it to represent 00:36 < exch> that's when a resize happens. which means: allocate new array with new size -> copy old data to new array -> discard old array 00:36 < foocraft> damn. that seems expensive 00:36 < exch> It is 00:36 < exch> specially the copy() bit is very expensive 00:36 < foocraft> does it double the array size? 00:37 < foocraft> I think a simple check with cap should show the answer 00:37 < krutcha> it creates a new array of the needed size for what you added 00:37 < exch> len(slice) == current length. cap(slice) == max capacity 00:38 < krutcha> if you have a slice of 10, and append a slice of 2, you create a new slice of 12, with the 10 and 2 elements copied into it 00:38 < krutcha> afaik 00:38 < KirkMcDonald> Doubling the capacity means that appends happen in amortized constant time. 00:38 < krutcha> the original 10 and 2 still kicking around unless you don't reference them anymore 00:38 < foocraft> okay so I ran my parallel implementation with the new split, and I can still type here. That's a good sign :p 00:38 < foocraft> KirkMcDonald, interesting. so is that what it's doing? 00:39 -!- nighty__ [~nighty@210.188.173.245] has joined #go-nuts 00:39 < exch> You also don't have to loop over the slice to copy it's values over. Go has a builtin copy() function for that: copy(newslice, oldslice); You can even copy into or from slice subsets: copy(newslice[123:], oldslice[2:7]) 00:39 < KirkMcDonald> The spec only says that it is "sufficiently large." 00:39 < foocraft> or does it increase by fibo numbers? :p (which, I think, would be better) 00:40 < krutcha> hmm, so append has the freedom to allocate beyond the request in a forward-looking way? 00:40 < foocraft> of course it should do that 00:40 < KirkMcDonald> krutcha: I see no reason why it would not. 00:40 < KirkMcDonald> In fact I would be very surprised if it did something other than doubling the capacity. 00:41 < krutcha> well.. in C/C++ on the systems I work on, I could see why not.. there's often no more memory than what I request :P 00:41 < foocraft> they want to avoid doing that expensive, allocate + copy. 00:41 < KirkMcDonald> I'm pretty sure that std::vector::push_back doubles the capacity when it is required. 00:41 < exch> foocraft: from your paste, I also don't see why you should create 2 new slices. You can just return two new slices of the original @allItems.. as in: split := len(allitems)/2; return allItems[:split], allItems[split:] 00:41 < KirkMcDonald> Although that's probably implementation-defined. 00:42 < exch> That does no allocations or copies at all btw 00:42 < foocraft> shouldn't they both return the same thing, exch? 00:43 < foocraft> yeah I don't want it to copy :) 00:43 < exch> Well, I'm not entirely sure what your split does, but if it just cuts the allitems in half, then that will do it 00:43 < krutcha> :split is start of slice to the offset split, split: is offset split to end of slice 00:43 < exch> indeed 00:43 < krutcha> what did the original code do? 00:44 < exch> In full that would read [0:split] and [split:len(allItems)], but the 0 and len(..) bits are implied and automatically fille din by the compiler 00:44 < foocraft> it's insanely slow still :( 00:45 < foocraft> I think it's the way I go about creating new threads 00:45 < foocraft> it's almost as if I'm fork-bombing my machine 00:45 < foocraft> http://fpaste.org/gSu9/ 00:45 < krutcha> did you set GOMAXPROCS to something? 00:45 < foocraft> http://fpaste.org/ioxL/ 00:46 < foocraft> I didn't 00:46 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3] 00:47 -!- progettino [~Marvin@82.84.79.101] has quit [Quit: E se abbasso questa leva che succ...] 00:47 < foocraft> that's the serial and the parallel implementation 00:47 < krutcha> your split shouldn't need to return a slice of slices, it could just return two slices no? 00:47 < foocraft> yeah it could, let me fix that 00:47 < foocraft> but I think I'm spawning too many threads 00:49 < krutcha> possibly there's overhead to creating goroutines, thread scheduling, etc 00:50 < krutcha> it isn't necessarily worth it for a quick calculation (albeit cool), but better to keep the system busy while things are blocking on resources 00:51 < foocraft> I'm running that on big data, just to see the speed up I get with a serial vs parallel implementation 00:51 -!- skelterjohn [~jasmuth@c-68-45-238-234.hsd1.nj.comcast.net] has quit [Quit: skelterjohn] 00:51 < krutcha> you could try maybe N go routines with channels, and sending slices out to them and collecting the results instead 00:51 < nictuku> I can't reproduce http://code.google.com/p/go/issues/detail?id=386 anymore (related to Xen). can anyone else try? 00:51 < krutcha> via channels, just for a fun alternative 00:52 -!- skelterjohn [~jasmuth@c-68-45-238-234.hsd1.nj.comcast.net] has joined #go-nuts 00:52 < krutcha> ie batch processing your sort to a smaller amount of goroutines 00:52 < krutcha> to prevent the thread flooding 1 thread per simple work request 00:52 < adg> anyone got any suggestions for a screencast i should put together? 00:52 < foocraft> adg, thinking in Go! 00:53 < adg> short topics, something i can cover in 5 minutes 00:53 < foocraft> or, "doing things the go way" 00:53 < adg> foocraft: yes! i'd like to do something that explores go idioms, a bit like the blog posts do 00:53 -!- antonkovalyov [~antonkova@75-101-56-240.dsl.static.sonic.net] has quit [Remote host closed the connection] 00:53 < adg> what topic, though? concurrency? the type system? 00:53 < foocraft> I'm very interested in concurrency 00:54 < foocraft> you can see my failed experiment up there :p 00:54 < krutcha> the stuff that still wigs me out is use of empty interfaces, which I see floating all over the place and don't know what to do with :P 00:54 < foocraft> a serial merge sort works better than my parallel implementation in Go :p because there's "Something" I'm not doing right 00:54 < adg> foocraft: are you setting GOMAXPROCS ? 00:55 < foocraft> no 00:55 < adg> foocraft: well it won't execute the goroutines in parallel if you don't 00:55 < foocraft> is that a compile-time flag or something? 00:55 < nictuku> adg, maybe something related to unmarshaling. json comes to mind. 00:55 < krutcha> its a setting in the system package, can be done at runtime 00:55 < adg> foocraft: it's a runtime flag. either set the environment variable before running your program, or import runtime and call runtime.GOMAXPROCS at the beginning 00:55 < krutcha> oops runtime, not system 00:55 < adg> krutcha: so a little primer on interface types? hmm 00:56 < krutcha> adg: perhaps, I get general 'methods on types' interface use, but that's still useful for people 00:56 < adg> krutcha: i can see introducing the idea of type assertion and the type switch being useful 00:57 < adg> nictuku: that sounds like a good one 00:57 < adg> nictuku: there definitely is a trick to using the json package 00:57 < exch> foocraft: running your code, it seems to work ok here 00:57 < exch> I dont have a lot of input data thogh 00:57 < exch> *though 00:57 < foocraft> yeah, I just set the environment variable to 2 00:58 < foocraft> I run it on data generated randomly 1000000 numbers 00:58 < adg> thanks for the suggestions guys 00:58 < foocraft> http://fpaste.org/2GO9/ 00:58 < adg> very helpful 00:58 < krutcha> foocraft: I still wonder if spawning like 4 goroutines, then sending them work in channels and collecting results might not be better 00:58 < foocraft> run that and pipe everything to the parallel implementation 00:58 < foocraft> krutcha, that's what I want to find out :) 01:00 < foocraft> okay so I'm still alive and it's not slowing up my machine IT IS) 01:01 -!- noff [~noff@89-55.79-83.cust.bluewin.ch] has quit [Ping timeout: 245 seconds] 01:02 -!- noff [~noff@89-55.79-83.cust.bluewin.ch] has joined #go-nuts 01:04 < foocraft> okay so I've depressing results so far 01:04 < foocraft> cuz time ./genData 10000 | ./mergeSortParallel is like 3x more than with mergeSortSerial 01:05 < skelterjohn> merge sort is really data intense 01:05 < skelterjohn> pastebin the code? 01:06 < foocraft> http://fpaste.org/Ngco/ 01:06 -!- Tv [~tv@cpe-76-168-227-45.socal.res.rr.com] has joined #go-nuts 01:06 < foocraft> http://fpaste.org/XFjW/ 01:06 -!- kanru [~kanru@2001:c08:3700:ffff::2b:dbc8] has quit [Ping timeout: 260 seconds] 01:06 < foocraft> the parallel and the serial implementations 01:07 < skelterjohn> you could do it without triggering the GC, and use only O(2N) space instead of N lg N space 01:07 < foocraft> hmm how do I turn off GC? 01:08 < skelterjohn> not what i meant 01:08 < foocraft> (also, sorry about how the tabs turned out to be in the paste) 01:08 < skelterjohn> i meant that by doing the 2N space version, GC won't get triggered 01:08 < skelterjohn> since you won't let go of memory 01:08 <+iant> foocraft: you can turn off the GC by setting the environment variable GOGC to off 01:08 < foocraft> skelterjohn, gotcha 01:08 < skelterjohn> but my guess is something that has lots of GC action on memory shared between two goroutines can cause blocking 01:09 < foocraft> can I just turn it off and turn it back on after my mergeSort is over, within a program? 01:10 <+iant> foocraft: set runtime.MemStats.EnableGC to false to turn it off temporarily 01:10 -!- thomas_b [~thomasb@cm-84.215.47.51.getinternet.no] has joined #go-nuts 01:11 < skelterjohn> also...10000 items? means that 2^13 goroutines are spawned, i think 01:11 < foocraft> think 1000000 01:11 < foocraft> so I want to limit that, somehow 01:11 < foocraft> like say "only spawn two at a time or something 01:11 < skelterjohn> ack, i mean with N items, you spawn N goroutines 01:12 < skelterjohn> because at one level you are splitting N/2 pairs of items and giving each to a goroutine 01:12 < foocraft> I spawn 2^log_n = N yes 01:12 < skelterjohn> so, 2N-1 total 01:12 < skelterjohn> that this only takes 3x as long is quite impressive :) 01:13 < foocraft> for a million, it doesn't terminate and I can barely type :p 01:13 < skelterjohn> maybe only spawn a new one if the number of active goroutines is less than or equal to the number of cores available 01:14 < foocraft> I want something that's a clean way of doing "if threads spawned == limit, run this code in the same thread, otherwise, go thisThread()" 01:14 < nictuku> ugh, the compilation of the program generated by test/64bit.go takes 134Mb of RSS :-( 01:14 < skelterjohn> otherwise with each goroutine you add overhead for no speed 01:14 < skelterjohn> foocraft: i think the straightforward way is probably best 01:14 < foocraft> I *think* there should be a compilation flag 01:14 < skelterjohn> but make sure to say >= 01:15 < skelterjohn> since there is a possible race condition 01:15 < exch> lol 1 million completely trashes my system 01:15 < exch> 6gb of ram 01:15 < foocraft> well, the way it's written, there can't be a race condition, because reading from the channel two items will block until both mergeSorts are done 01:15 < |Craig|> foocraft: for N cores, I'd split the array into roughly N parts, send those slices off to go routines to sort, then merge them 01:16 < foocraft> hmm an N-way mergeSort. I only heard about that in class 01:16 < skelterjohn> foocraft: i don't think that prevents race conditions in this case 01:16 < skelterjohn> not the way your code is written 01:16 < foocraft> but since I'm on a 2 core machine, then I'm actually doing that 01:16 < |Craig|> foocraft: when using more than one core, lots of go routines = very slow due to context switching overheads 01:17 < skelterjohn> |Craig|: unless you're using gccgo, you don't context switch when going between goroutines 01:17 < skelterjohn> not necessarily, anyway 01:17 < foocraft> yeah, I'm aware of that. so is there a way to "cleanly" limit the number of threads spawned, and by clean, I meant that if we reach the limit, just run it in the same thread, otherwise, run it on a separate thread 01:17 < |Craig|> skelterjohn: how can it have more than one core loaded then? 01:18 < skelterjohn> you can have many goroutines on one core (and some others on a different one) 01:18 < skelterjohn> when you switch between goroutines on that one core, there shouldn't be a big context switch 01:18 < foocraft> skelterjohn, context switching isn't a compilation option, the os decides which thread to swtich to 01:18 < skelterjohn> the go runtime just jumps the program counter to a differnet part of the program 01:18 < skelterjohn> goroutines are not threads or processes 01:18 < |Craig|> for long running tasks, the overhead is not too bad, but if you make a goroutine to just merge sort 2 or 4 numbers, it would be faster to just sort them instead 01:18 < skelterjohn> they're much more lightweight 01:19 < foocraft> hmm |Craig|, I like that idea 01:19 < skelterjohn> foocraft: i didn't suggest it was a compilation option. but 6g/8g do goroutines as the nice lightweight bit 01:19 < skelterjohn> gccgo does a thread per goroutine (unless iant has been busy) 01:19 -!- mbohun [~user@ppp115-156.static.internode.on.net] has joined #go-nuts 01:20 < |Craig|> skelterjohn: then making many really short lived ones will be even slower 01:20 < skelterjohn> for gccgo? 01:21 < skelterjohn> making many short lived goroutines, with the 6g model, is much faster than doing the same thing with threads 01:21 < skelterjohn> must less memory, much less time 01:21 < |Craig|> creating a thread and waiting for a response has to have more overhead than an method call regardless. As long as you have at least as many go routines as processors, spewing them all over trying to parallelize won't help performance (but in some cases can help desing) 01:22 < |Craig|> so a recursive sort than spawns go rountines at each iteration is not going to run fast 01:22 < skelterjohn> but you do *not* create a thread when you create a goroutine 01:22 < foocraft> hmm with |Craig|'s idea, I get a deadlock 01:22 < skelterjohn> though i agree that even goroutines have prohibitive overhead with merge sort 01:24 -!- niemeyer [~niemeyer@189.73.142.213] has quit [Ping timeout: 245 seconds] 01:26 < |Craig|> you could make some sorting go routines, and have a load balanced system for feeding slices to merge into them, and make as many of them as you have processors 01:27 < foocraft> http://fpaste.org/pMj4/ 01:27 < |Craig|> they would copy the slices, and merge them back into place, and then pull in another pair of slices form their channel 01:27 < |Craig|> I'll be back later 01:27 < foocraft> thanks |Craig| 01:28 < foocraft> wait, there's a bug there 01:30 < foocraft> it deadlocks 01:30 < krutcha> I'd like to point out that it's dead easy in go to sit here and switch between parallel, serial, differen't numbers of goroutines, etc with minimal effort. Which is pretty awesome. 01:31 < foocraft> :) yeah I'm lovin it hehe 01:31 < foocraft> like, in C, I'd probably have to get throw in a bunch of semaphores, with minor design decisions like we just did 01:34 -!- krutcha [~krutcha@remote.icron.com] has quit [Quit: Leaving] 01:40 -!- tvw [~tv@e176006039.adsl.alicedsl.de] has quit [Ping timeout: 245 seconds] 01:40 < foocraft> if I get this one to work without thrashing my system, I think I'm going to spend next semester doing parallel algorithms with Go 01:45 < foocraft> http://fpaste.org/ozMO/ so as soon as I start spawning a thread in this function, I run into a deadlock 01:45 < foocraft> I think it's how I'm limiting my thread count 01:49 -!- antonkovalyov [~antonkova@adsl-75-18-220-88.dsl.pltn13.sbcglobal.net] has joined #go-nuts 01:51 -!- ExtraSpice [~XtraSpice@88.118.33.48] has quit [Ping timeout: 240 seconds] 01:55 < skelterjohn> foocraft: you aren't popping values off of ch until after the funciton returns 01:55 < skelterjohn> when you run that function in a diff goroutine it's ok 01:55 < skelterjohn> but since the sender and receiver for ch are in the same goroutine, and it's an unbuffered chan, there is deadlock 01:59 -!- shvntr [~shvntr@113.84.151.193] has joined #go-nuts 02:00 -!- Kashia [~Kashia@port-92-200-8-147.dynamic.qsc.de] has quit [Ping timeout: 260 seconds] 02:03 < plexdev> http://is.gd/imU06 by [Alex Brainman] in go/src/pkg/runtime/windows/ -- runtime: fix windows build 02:06 -!- Kashia [~Kashia@port-92-200-108-107.dynamic.qsc.de] has joined #go-nuts 02:08 -!- iant [~iant@66.109.105.230] has quit [Quit: Leaving.] 02:11 -!- shvntr [~shvntr@113.84.151.193] has quit [Quit: luck] 02:13 -!- itrekkie [~itrekkie@ip72-200-115-40.tc.ph.cox.net] has joined #go-nuts 02:13 -!- itrekkie [~itrekkie@ip72-200-115-40.tc.ph.cox.net] has quit [Client Quit] 02:21 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has quit [Ping timeout: 245 seconds] 02:22 -!- ios_ [~ios@180.191.43.229] has joined #go-nuts 02:25 -!- antonkovalyov [~antonkova@adsl-75-18-220-88.dsl.pltn13.sbcglobal.net] has quit [Remote host closed the connection] 02:29 -!- kanru [~kanru@2001:c08:3700:ffff::2b:ec7c] has joined #go-nuts 02:32 -!- noktoborus [debian-tor@gateway/tor-sasl/noktoborus] has joined #go-nuts 02:36 -!- liwei [~liwei@180.110.78.49] has joined #go-nuts 02:55 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has joined #go-nuts 03:00 -!- krutcha [~krutcha@S010600045a27676a.vs.shawcable.net] has joined #go-nuts 03:16 -!- boscop [~boscop@f055006106.adsl.alicedsl.de] has quit [Ping timeout: 245 seconds] 03:18 -!- boscop [~boscop@f055199010.adsl.alicedsl.de] has joined #go-nuts 03:19 -!- vermi [959f7527@gateway/web/freenode/ip.149.159.117.39] has joined #go-nuts 03:19 < vermi> at compile time, I get an error with this code fragment http://pastebin.com/k2d0m5s5 03:19 < vermi> tells me nsfw is undefined, and also nsfw declared but not used 03:20 < rmmh> vermi: you need to declare nsfw outside of the scope of the if statements 03:20 < vermi> as in var nsfw string ? 03:20 < |Craig|> vermi: its declared twice, but both are inside an inner scope 03:21 < rmmh> vermi: for example: nfsw := ""; if url..."q" { nsfw = "[NFSW"]; } 03:21 < vermi> oh i see 03:22 < rmmh> also interesting, an IRC bot written in Go 03:22 -!- mandragor [~ergudicsu@cpe-174-109-112-159.nc.res.rr.com] has joined #go-nuts 03:23 < rmmh> dynamic reloading is *really* nice with IRC bots, so I prefer scripting languages for them 03:23 < vermi> i still get a nsfw declared but not used 03:23 < |Craig|> vermi: make sure in your if you use = not := 03:24 < |Craig|> := makes another one 03:24 < rmmh> vermi: also, you might want to do http.URLEscape(tag) instead of http.URLEscape(site) 03:24 < vermi> ah yes, i see your point there 03:24 < vermi> rmmh: the original bot was written in Python, in fact; but we thought it'd be fun to fotz around with Go 03:26 < rmmh> just curious, is the framework open source? 03:26 < rmmh> I have my own Python IRC bot and I'm always interested in stealing^Wborrowing ideas 03:27 < vermi> for the Python one? Sure; it's not very impressive though: http://github.com/vermi/mpu 03:27 < rmmh> ah, irclib 03:27 < vermi> our main thought was to move fro irclib to twisted 03:28 < rmmh> (mine is http://github.com/rmmh/skybot) 03:28 < rmmh> irclib isn't multithreaded, right? 03:29 < vermi> no it isn't 03:29 < vermi> that's why we were going to move to twisted 03:30 -!- skelterjohn [~jasmuth@c-68-45-238-234.hsd1.nj.comcast.net] has quit [Quit: skelterjohn] 03:30 < vermi> then we decided to mess with Go instead for no real reason 03:30 < rmmh> :) 03:30 -!- rhencke [~rhencke@ppp-70-247-243-221.dsl.ltrkar.swbell.net] has joined #go-nuts 03:31 < rmmh> twisted felt too bloated, so I just wrote my own IRC netcode based on asynchat 03:31 < Tv> rmmh: twisted core is pretty tiny, feel free to ignore the rest.. 03:31 < Tv> rmmh: (and asynchat is just broken, compared to twisted...) 03:32 < rmmh> err, wait, I don't use asynchat 03:33 < rmmh> I'm just using raw sockets and threads with Queues for I/O 03:33 < rmmh> twisted's "everything is an object/factory" was annoying to me 03:36 < plexdev> http://is.gd/in6ir by [Andrew Gerrand] in 2 subdirs of go/ -- release.2010-12-08 03:36 < plexdev> http://is.gd/in6iz by [Andrew Gerrand] in go/ -- tag release.2010-12-08 03:37 -!- skelterjohn [~jasmuth@c-68-45-238-234.hsd1.nj.comcast.net] has joined #go-nuts 03:37 < rhencke> anyone ever get a program blow up on runtime.morestack? 03:38 < adg> rhencke: that has happened to me; can't remember what the solution was 03:38 < rhencke> adg: thanks. if you happen to remember what you did at some point, i appreciate it :) 03:39 < adg> how are you triggering it? 03:40 < rhencke> i'm calling go->c->go then it hates me 03:41 < rhencke> haven't managed to reproduce with a simple test case; it currently involves some c bindings i have 03:41 -!- niemeyer [~niemeyer@189.73.142.213] has joined #go-nuts 03:42 -!- `Wiz126 [Z@h62.126.232.68.ip.windstream.net] has joined #go-nuts 03:42 -!- Wiz126 [Z@h62.126.232.68.ip.windstream.net] has quit [Ping timeout: 265 seconds] 03:42 -!- foocraft [~dsc@89.211.184.236] has quit [Quit: Leaving] 03:43 < adg> rhencke: i guess it'd be helpful if you can boil it down to a minimal test case. i know that's not necessarily easy 03:44 < rhencke> adg: i will see if i can reduce the case down 03:44 -!- vermi [959f7527@gateway/web/freenode/ip.149.159.117.39] has quit [Quit: Page closed] 03:44 -!- gnuvince_ [~vince@220.252-ppp.3menatwork.com] has joined #go-nuts 03:47 -!- gnuvince [~vince@70.35.162.131] has quit [Ping timeout: 260 seconds] 03:48 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has joined #go-nuts 03:48 -!- mode/#go-nuts [+v iant] by ChanServ 03:49 < rhencke> adg: woo, i did it :) 03:57 < rmmh> is there a variant of all.bash that doesn't do a make clean? 03:58 -!- vermi [959f7527@gateway/web/freenode/ip.149.159.117.39] has joined #go-nuts 03:58 < adg> rmmh: make.bash 04:00 < rmmh> make.bash seems to clean everything as well? 04:00 < adg> rmmh: which part is being cleaned? 04:00 < adg> oh right, sorry, yes make.bash will run clean.bash 04:01 < vermi> so using the same code (http://pastebin.com/VdwPSTDQ) I've discovered that the image-searching site I'm using often returns an error for no apparent reason 04:01 < rmmh> go compiles fast, but a full recompile gets old quick 04:01 < vermi> so what I want to do is run the http.Get() again until err = nil 04:01 < rmmh> also is the build broken for anyone else 04:01 < vermi> but i'm not sure how to accomplish that 04:02 < rmmh> vermi: are you sure you want to loop infinitely? one retry would be more sane 04:02 < vermi> well i've been testing it out in my browser 04:02 < vermi> and sometimes it takes 10 or 15 retries 04:03 < Namegduf> Make sure you add a delay. 04:03 < rmmh> that seems like an easy way to make your bot flood the server 04:04 < vermi> i wish i knew why it was giving an error in the first place 04:04 < vermi> then i could correct for that 04:05 -!- kanru [~kanru@2001:c08:3700:ffff::2b:ec7c] has quit [Ping timeout: 260 seconds] 04:12 -!- vermi [959f7527@gateway/web/freenode/ip.149.159.117.39] has quit [Quit: Page closed] 04:18 -!- kanru [~kanru@2001:c08:3700:ffff::2b:f9ac] has joined #go-nuts 04:20 < rhencke> man, today was a lot of go changes 04:24 < adg> rmmh: "is the build broken?" http://godashboard.appspot.com/ 04:24 < rmmh> yeah I saw 04:24 < rmmh> was my own fault :) 04:24 < rhencke> stuff like the printf changes make me wonder about the line between compiler and program analyzer 04:24 -!- hoverbear [~Hoverbear@unaffiliated/hoverbear] has left #go-nuts ["WeeChat 0.3.4-dev"] 04:28 < rhencke> or if i overthink stuff :P 04:35 -!- lasersbambam [~krum@ruby.cat.pdx.edu] has quit [Ping timeout: 264 seconds] 04:39 -!- kanru [~kanru@2001:c08:3700:ffff::2b:f9ac] has quit [Ping timeout: 260 seconds] 04:40 < vsmatck> Is there any reason to stop goroutines before program exit if you don't care when they exit? 04:41 < Tv> vsmatck: unless there's a possibility they have pending tasks to finish, no 04:42 < vsmatck> Tv: Hm. That's what I was thinking. But had a funny feeling. Thanks for the advice. 04:42 -!- prip [~foo@host196-135-dynamic.43-79-r.retail.telecomitalia.it] has quit [Ping timeout: 240 seconds] 04:46 -!- ymasory [~ymasory@c-76-99-55-224.hsd1.pa.comcast.net] has quit [Quit: Leaving] 04:50 -!- [noff] [~noff@88-190.78-83.cust.bluewin.ch] has joined #go-nuts 04:52 -!- kanru [~kanru@2001:c08:3700:ffff::2b:fb8c] has joined #go-nuts 04:53 -!- noff [~noff@89-55.79-83.cust.bluewin.ch] has quit [Ping timeout: 255 seconds] 04:56 -!- prip [~foo@host241-9-dynamic.7-79-r.retail.telecomitalia.it] has joined #go-nuts 04:57 -!- devrim1 [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has joined #go-nuts 04:57 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has quit [Read error: Connection reset by peer] 04:59 -!- ios_ [~ios@180.191.43.229] has quit [Quit: Leaving] 05:00 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has quit [Ping timeout: 255 seconds] 05:06 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has joined #go-nuts 05:11 -!- mandragor [~ergudicsu@cpe-174-109-112-159.nc.res.rr.com] has quit [Read error: Connection reset by peer] 05:14 -!- liwei [~liwei@180.110.78.49] has left #go-nuts ["Leaving"] 05:14 < krutcha> erm silly question, can you have multiple initializers in the first statement of a for loop? 05:16 < rhencke> yes 05:16 < rhencke> for a, b := 1, 2; ... 05:17 < krutcha> hmm I thought as much, but what about with multiple returns involved 05:17 < krutcha> like a,b,c := func(),d 05:17 < rhencke> i think you can do that 05:18 < krutcha> where func returns _,_ two values 05:18 < rhencke> hm, maybe you can't 05:19 -!- kanru [~kanru@2001:c08:3700:ffff::2b:fb8c] has quit [Ping timeout: 260 seconds] 05:19 -!- bmizerany [~bmizerany@208.66.27.62] has quit [Remote host closed the connection] 05:19 < krutcha> yeah I'm not clear on that.. I'm looking at the spec 05:20 < krutcha> specifically in my case, naturally I want to go i, x, y := 0, range mymap { 05:20 < rhencke> when i try it, i get 'multiple-value x in single-value context' 05:20 < krutcha> because map doesn't return an index, only a key and a value 05:21 < krutcha> and I need to iterate linearly through a second structure as I walk key/value pairs in the map 05:22 < rhencke> i'm not sure if you can do that all in the for statement 05:22 < krutcha> I get: syntax error: unexpected range 05:22 < krutcha> hehe yeah it was a bit wishful 05:22 < krutcha> but seemed allllmost plausible in go 05:23 < rhencke> i guess it might get ambiguous in some cases 05:23 < rmmh> krutcha: for i := 0, x, y := range mymap ? 05:23 < krutcha> well.. thats the thing 05:23 < rmmh> err 05:23 < plexdev> http://is.gd/inj5P by [Alex Brainman] in go/src/pkg/syscall/ -- syscall: restrict access rights param of OpenProcess() to the minimum needed 05:23 < rmmh> krutcha: for i := 0; x, y := range mymap ? 05:23 < krutcha> thats two statements 05:23 < krutcha> in a for, one is init, the other is condition 05:23 < krutcha> isn't it? hmm 05:23 < krutcha> thats different with ranges 05:24 < krutcha> rmmh: you might be right for a range 05:24 < rmmh> err no 05:24 < rmmh> poor you, you'll have to use another line 05:25 < krutcha> crap 05:25 < rmmh> krutcha: specifically, RangeClause = Expression [ "," Expression ] ( "=" | ":=" ) "range" Expression 05:26 < krutcha> hmm 05:27 -!- niemeyer [~niemeyer@189.73.142.213] has quit [Ping timeout: 245 seconds] 05:28 < krutcha> ah well, another line it is! 05:33 -!- kanru [~kanru@2001:c08:3700:ffff::2c:841a] has joined #go-nuts 05:46 -!- [noff] [~noff@88-190.78-83.cust.bluewin.ch] has quit [Ping timeout: 264 seconds] 05:54 < plexdev> http://is.gd/inmrG by [Robert Griesemer] in go/src/pkg/go/token/ -- token/position.go: provide FileSet.File(), minor optimizations 05:55 < plexdev> http://is.gd/inmrP by [Robert Griesemer] in go/src/cmd/godoc/ -- godoc: use file instead of file set for computing line info 05:55 -!- piyushmishra [~piyushmis@117.200.228.221] has quit [Ping timeout: 272 seconds] 05:56 < krutcha> almost got my jabber client useful as a package, a lot of cleanup, I had gone a bit go-routine and channel happy and must learn moderation when faced with shiny new toys 05:59 < rhencke> krutcha: very hard to do, but very true 06:00 < rhencke> otoh, trying them for everything lets you figure out what they're good for 06:00 < krutcha> absolutely 06:01 -!- kanru [~kanru@2001:c08:3700:ffff::2c:841a] has quit [Ping timeout: 260 seconds] 06:13 -!- kanru [~kanru@2001:c08:3700:ffff::2c:8846] has joined #go-nuts 06:13 -!- _nil [~aiden@c-24-147-65-44.hsd1.ma.comcast.net] has quit [Ping timeout: 264 seconds] 06:14 -!- kanru [~kanru@2001:c08:3700:ffff::2c:8846] has quit [Client Quit] 06:14 -!- keithcascio [~keithcasc@nat/google/x-fzmhavrjyzmrefpc] has quit [Quit: Leaving] 06:21 -!- yugui [~yugui@yugui.jp] has joined #go-nuts 06:24 < vsmatck> XMPP seems like it'd be a good thing to have in the standard library. 06:24 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has joined #go-nuts 06:26 < Tv> vsmatck: not convinced, it's a complex protocol.. 06:26 < rhencke> plus the umpteen million extensions 06:26 < rhencke> maybe in a lib like protobuf 06:27 < Tv> i'd rather see a healthy ecosystem of add-ons, than a bloated & obsolete stdlib 06:27 < krutcha> after looking at xmpp a bit I'd tend to agree 06:27 < vsmatck> Hm, perhaps XMPP hasn't really been around long enough and is not adopted widely enough. 06:28 < krutcha> there's umpteen bajillion RFC's and also slight implementation variations on servers 06:28 < vsmatck> I guess it's not exactly on the level of HTTP. 06:28 < rhencke> xmpp has a lot of adoption, but its not http level 06:28 < rhencke> google talk is xmpp 06:29 < rhencke> xmpp gets a lot of internal corporate use, too 06:34 < adg> vsmatck: we have a websocket library, that's been around for less time than xmpp 06:34 < adg> xmpp is huge 06:34 < adg> but i'd rather see a high quality xmpp library outside the standard library than in 06:34 < adg> frankly websockets could go elsewhere, too 06:34 < adg> we need to make the whole third-party library experience better 06:35 * adg out 06:35 * vsmatck tries to get pprof working. 06:37 -!- Eridius [~kevin@unaffiliated/eridius] has quit [Ping timeout: 250 seconds] 06:49 -!- zozoR [~zozoR@56344bf6.rev.stofanet.dk] has joined #go-nuts 07:07 -!- rhencke [~rhencke@ppp-70-247-243-221.dsl.ltrkar.swbell.net] has quit [Quit: rhencke] 07:22 -!- piyushmishra [~piyushmis@117.200.231.121] has joined #go-nuts 07:23 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has quit [Ping timeout: 272 seconds] 07:33 -!- [noff] [~noff@pub1.heig-vd.ch] has joined #go-nuts 07:33 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts 07:35 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|] 07:39 -!- sacho [~sacho@87-126-42-243.btc-net.bg] has quit [Ping timeout: 240 seconds] 07:43 -!- sacho [~sacho@95-42-99-232.btc-net.bg] has joined #go-nuts 07:50 -!- tdc [~santegoed@host86-156-182-103.range86-156.btcentralplus.com] has joined #go-nuts 07:56 -!- photron [~photron@port-92-201-103-85.dynamic.qsc.de] has joined #go-nuts 08:00 < krutcha> erm, whats the deal with umask, ioutil.writefile, and permission values? I am definitely experiencing weird 08:01 < krutcha> ioutil.WriteFile(filename, avatar.Photo, 0x644) -> ---x--Sr-T (linux) 08:01 < Tv> krutcha: octal not hex 08:03 < krutcha> ahh.. hmm all the code examples I've seen used hex, one sec 08:04 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has quit [Quit: leaving] 08:04 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has joined #go-nuts 08:05 < krutcha> yeah that did it, thx 08:05 -!- Tv [~tv@cpe-76-168-227-45.socal.res.rr.com] has quit [Quit: Leaving.] 08:06 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 08:14 -!- tensorpudding [~user@99.148.202.191] has quit [Remote host closed the connection] 08:21 -!- zozoR [~zozoR@56344bf6.rev.stofanet.dk] has quit [Quit: Morten. Desu~] 08:30 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has quit [Quit: leaving] 08:30 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has joined #go-nuts 08:31 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 265 seconds] 08:33 -!- napsy [~luka@88.200.96.18] has joined #go-nuts 08:34 -!- noktoborus [debian-tor@gateway/tor-sasl/noktoborus] has quit [Ping timeout: 245 seconds] 08:43 -!- Project_2501 [~Marvin@82.84.79.101] has joined #go-nuts 08:44 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 08:48 -!- nighty__ [~nighty@210.188.173.245] has quit [Remote host closed the connection] 08:54 -!- rlab [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 08:56 -!- noktoborus [debian-tor@gateway/tor-sasl/noktoborus] has joined #go-nuts 09:11 -!- noam [noam@77.124.236.67] has quit [Ping timeout: 255 seconds] 09:11 -!- noam [noam@77.124.236.67] has joined #go-nuts 09:17 -!- ExtraSpice [~XtraSpice@88.118.33.48] has joined #go-nuts 09:18 < krutcha> threw current state of go pkg for XMPP I've been playing with up here https://github.com/krutcha/go-jabber , don't expect much, it's pretty basic and I didn't know anything about go OR xmpp when I started :P 09:27 < plexdev> http://is.gd/inKn5 by [Peter Mundy] in go/doc/ -- doc: fix installation $GOOS choices 09:44 -!- Innominate [~sirrobin@cpe-076-182-074-143.nc.res.rr.com] has quit [Ping timeout: 240 seconds] 10:08 -!- tdc [~santegoed@host86-156-182-103.range86-156.btcentralplus.com] has quit [Quit: tdc] 10:14 -!- wrtp [~rog@92.17.77.11] has joined #go-nuts 10:14 -!- noam [noam@77.124.236.67] has quit [Read error: Connection reset by peer] 10:15 -!- noam [noam@77.124.236.67] has joined #go-nuts 10:18 -!- Kashia [~Kashia@port-92-200-108-107.dynamic.qsc.de] has quit [Quit: This computer has gone to sleep] 10:24 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has joined #go-nuts 10:43 -!- ios_ [~ios@180.191.130.187] has joined #go-nuts 10:55 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts 10:57 * wrtp is in dylib hell 10:59 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 11:27 -!- tvw [~tv@212.79.9.150] has joined #go-nuts 11:27 -!- gnuvince_ [~vince@220.252-ppp.3menatwork.com] has left #go-nuts [] 11:29 < nsf> go/parser.ParseFile new interface is creepy 11:29 -!- Project_2501 [~Marvin@82.84.79.101] has quit [Quit: E se abbasso questa leva che succ...] 11:30 < nsf> it starts to look like Java 11:30 -!- niemeyer [~niemeyer@189.73.142.213] has joined #go-nuts 11:34 < nsf> no, it's not creepy, it simply sucks 11:34 -!- snearch [~snearch@f053003059.adsl.alicedsl.de] has joined #go-nuts 11:40 < Namegduf> Is there already a parser.File? 11:40 < Namegduf> Or a parser.SomeOtherFile? 11:41 < nsf> No 11:41 < nsf> there is a token.File 11:41 < Namegduf> Odd, then. 11:41 < Namegduf> Maybe it looked ugly within the package? 11:41 < nsf> the whole interface is ugly now 11:42 < nsf> Position is compressed and because of that it depends on a context 11:42 < nsf> and this context is FileSet 11:42 < nsf> so.. now if I want to use position I need to carry this FileSet everywhere 11:42 -!- Soultaker [~Soultaker@infinity.student.utwente.nl] has quit [Ping timeout: 255 seconds] 11:44 < nsf> fuck.. it breaks my app completely 11:45 < nsf> (gocode) 11:49 -!- noff_ [~noff@pub1.heig-vd.ch] has joined #go-nuts 11:52 -!- [noff] [~noff@pub1.heig-vd.ch] has quit [Ping timeout: 240 seconds] 12:01 -!- Soultaker [~Soultaker@infinity.student.utwente.nl] has joined #go-nuts 12:04 -!- rlab_ [~Miranda@91.200.158.34] has joined #go-nuts 12:05 -!- tdc [~santegoed@host86-156-182-103.range86-156.btcentralplus.com] has joined #go-nuts 12:05 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 240 seconds] 12:05 -!- DarthShrine [~angus@pdpc/supporter/student/DarthShrine] has quit [Quit: DarthShrine] 12:14 -!- Soultaker [~Soultaker@infinity.student.utwente.nl] has quit [Ping timeout: 245 seconds] 12:15 < nsf> gocode became 10-20% slower 12:19 < nsf> now autocompletions take 50ms instead of 30ms 12:20 < nsf> although, memory behaviour is a bit better now 12:20 < nsf> which is good 12:23 < nsf> nope, it's worse 12:24 < nsf> I think I will have to fork go/parser :\ 12:25 < MaybeSo> do you talk to the primary author at all? provide feedback? 12:25 < MaybeSo> they might be interested in hearing that your use case shows 2x slowdown. 12:25 < nsf> I don't like to talk much 12:26 < exch> :p 12:26 < exch> Luckily you dont have to talk on the interwebz, just type 12:27 -!- noam [noam@77.124.236.67] has quit [Ping timeout: 264 seconds] 12:27 < nsf> currently I'm just very unhappy with the GC 12:27 < nsf> sequence of dropping cache and filling it again in gocode quickly leads to memory consumption over 450 megs 12:27 < nsf> not good 12:29 < nsf> but maybe I'm just stupid and have no idea how to work with GCed languages 12:34 -!- noam [noam@77.124.236.67] has joined #go-nuts 12:35 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has joined #go-nuts 12:51 < wrtp> the GC is changing very soon 12:52 -!- mbohun [~user@ppp115-156.static.internode.on.net] has quit [Ping timeout: 255 seconds] 12:52 < wrtp> surely 1/20th of a second is an acceptable speed? 12:55 < nsf> I'm fine with speed, I don't like memory behaviour 12:57 -!- Soultaker [~Soultaker@infinity.student.utwente.nl] has joined #go-nuts 12:58 < nsf> and I've seen recent Russ' changesets for GC 12:58 < nsf> looks like he only speeds up sweeping part 12:58 < nsf> and doesn't change anything in general 13:01 -!- javax [~javax@galaxy.infidyne.com] has left #go-nuts [] 13:02 < nsf> and well, there is a possibility of a memory leak, but I think it's very unlikely 13:02 < nsf> I have only one global variable in gocode 13:02 < nsf> and drop-cache command clears it 13:02 < nsf> still, memory consumption grows 13:03 -!- skejoe [~skejoe@188.114.142.162] has joined #go-nuts 13:05 < nsf> and go memory allocator uses tcmalloc's algorithms as far as I know, I'm sure they are very good for a system-wide allocator, but on a per application basis.. probably not a very good idea 13:05 -!- xash [~xash@d126025.adsl.hansenet.de] has joined #go-nuts 13:06 < nsf> unless it's a dedicated server software 13:07 -!- zozoR [~zozoR@56344bf6.rev.stofanet.dk] has joined #go-nuts 13:08 < nsf> and sadly for me, this is what google targets with this language :) 13:18 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3] 13:20 -!- rlab_ [~Miranda@91.200.158.34] has quit [Ping timeout: 240 seconds] 13:27 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 13:38 -!- noff_ [~noff@pub1.heig-vd.ch] has quit [Ping timeout: 240 seconds] 13:42 -!- grumpytoad [~niel@t1004.greatnet.de] has quit [Ping timeout: 276 seconds] 13:46 -!- virtualsue [~chatzilla@nat/cisco/x-gswngtutzufwebyy] has joined #go-nuts 13:49 -!- Maxdamantus [~Maxdamant@203.97.238.106] has quit [Ping timeout: 260 seconds] 13:57 -!- plainhao [~plainhao@208.75.85.237] has joined #go-nuts 13:58 -!- xash [~xash@d126025.adsl.hansenet.de] has quit [Read error: Operation timed out] 14:03 -!- grumpytoad [~niel@t1004.greatnet.de] has joined #go-nuts 14:07 -!- virtualsue [~chatzilla@nat/cisco/x-gswngtutzufwebyy] has quit [Ping timeout: 260 seconds] 14:12 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has quit [Quit: Leaving.] 14:12 -!- virtualsue [~chatzilla@nat/cisco/x-vzfibmjcxqbuykle] has joined #go-nuts 14:12 -!- tdc [~santegoed@host86-156-182-103.range86-156.btcentralplus.com] has quit [Quit: Leaving] 14:15 -!- artefon [~thiago@189.59.204.192] has joined #go-nuts 14:19 -!- skejoe [~skejoe@188.114.142.162] has quit [Quit: Lost terminal] 14:19 -!- Innominate [~sirrobin@cpe-076-182-074-143.nc.res.rr.com] has joined #go-nuts 14:20 -!- xash [~xash@d126025.adsl.hansenet.de] has joined #go-nuts 14:23 -!- Maxdamantus [~Maxdamant@203.97.238.106] has joined #go-nuts 14:24 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Quit: WeeChat 0.3.2] 14:33 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts 14:34 -!- ExtraSpice [~XtraSpice@88.118.33.48] has quit [Quit: Leaving] 14:48 -!- ExtraSpice [~XtraSpice@88.118.33.48] has joined #go-nuts 14:50 -!- skelterjohn [~jasmuth@c-68-45-238-234.hsd1.nj.comcast.net] has quit [Quit: skelterjohn] 14:53 -!- Tv [~tv@cpe-76-168-227-45.socal.res.rr.com] has joined #go-nuts 14:57 -!- noam [noam@77.124.236.67] has quit [Ping timeout: 276 seconds] 14:59 -!- wrtp_ [~rog@92.17.77.11] has joined #go-nuts 14:59 -!- wrtp [~rog@92.17.77.11] has quit [Read error: Connection reset by peer] 15:00 -!- wrtp_ [~rog@92.17.77.11] has joined #go-nuts 15:00 -!- wrtp [~rog@92.17.77.11] has quit [Read error: Connection reset by peer] 15:02 < plexdev> http://is.gd/iou52 by [Rob Pike] in go/src/pkg/path/ -- path: fix printf glitch in test 15:02 -!- wrtp [~rog@92.17.77.11] has quit [Read error: Connection reset by peer] 15:02 -!- wrtp [~rog@92.17.77.11] has joined #go-nuts 15:02 -!- noam [noam@77.124.236.67] has joined #go-nuts 15:13 -!- iant [~iant@67.218.110.2] has joined #go-nuts 15:13 -!- mode/#go-nuts [+v iant] by ChanServ 15:32 -!- wrtp [~rog@92.17.77.11] has quit [Ping timeout: 276 seconds] 15:38 -!- wrtp [~rog@92.17.77.11] has joined #go-nuts 15:49 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Quit: Leaving.] 15:49 -!- ymasory [~ymasory@SEAS205.wlan.seas.upenn.edu] has joined #go-nuts 15:52 -!- Venom_X [~pjacobs@99-8-218-190.lightspeed.hstntx.sbcglobal.net] has joined #go-nuts 15:52 -!- awidegreen [~quassel@c-eacae555.08-2-73746f39.cust.bredbandsbolaget.se] has joined #go-nuts 15:54 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts 15:54 -!- zeroXten [~zeroXten@0x10.co.uk] has quit [Ping timeout: 276 seconds] 15:55 -!- zeroXten [~zeroXten@0x10.co.uk] has joined #go-nuts 16:10 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has quit [Ping timeout: 624 seconds] 16:31 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 265 seconds] 16:33 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 16:35 -!- krutcha [~krutcha@S010600045a27676a.vs.shawcable.net] has quit [Quit: Leaving] 16:40 -!- iant [~iant@67.218.110.2] has quit [Quit: Leaving.] 16:42 -!- ios_ [~ios@180.191.130.187] has quit [Quit: Leaving] 16:43 -!- Fish [~Fish@coss6.exosec.net] has joined #go-nuts 16:45 -!- ymasory [~ymasory@SEAS205.wlan.seas.upenn.edu] has quit [Ping timeout: 240 seconds] 16:53 -!- skelterjohn [~jasmuth@dsl092-234-022.phl1.dsl.speakeasy.net] has joined #go-nuts 16:56 -!- Venom_X [~pjacobs@99-8-218-190.lightspeed.hstntx.sbcglobal.net] has quit [Quit: Venom_X] 17:00 -!- skelterjohn [~jasmuth@dsl092-234-022.phl1.dsl.speakeasy.net] has quit [Quit: skelterjohn] 17:01 -!- sahid [~sahid@LNeuilly-152-21-22-10.w193-253.abo.wanadoo.fr] has quit [Quit: Ex-Chat] 17:07 -!- ville- [~ville@a107.ath.cx] has quit [Ping timeout: 240 seconds] 17:14 -!- thiago__ [~thiago@189.59.204.192] has joined #go-nuts 17:15 -!- emjayess [~emjayess@pix1.i29.net] has quit [Read error: Connection reset by peer] 17:16 -!- artefon [~thiago@189.59.204.192] has quit [Read error: Connection reset by peer] 17:24 -!- saschpe [~quassel@opensuse/member/saschpe] has joined #go-nuts 17:27 -!- ville- [~ville@a107.ath.cx] has joined #go-nuts 17:32 -!- keithcascio [~keithcasc@nat/google/x-kpczuhrtfljslfms] has joined #go-nuts 17:41 -!- skelterjohn [~jasmuth@c-71-230-156-50.hsd1.nj.comcast.net] has joined #go-nuts 17:43 -!- Venom_X [~pjacobs@66.54.185.131] has joined #go-nuts 17:45 -!- sauerbraten [~sauerbrat@p508CADF8.dip.t-dialin.net] has joined #go-nuts 17:46 -!- ct529 [~quassel@77-44-78-159.xdsl.murphx.net] has joined #go-nuts 17:48 -!- ct529 [~quassel@77-44-78-159.xdsl.murphx.net] has quit [Remote host closed the connection] 17:50 -!- krutcha [~krutcha@remote.icron.com] has joined #go-nuts 17:51 -!- jhawk28 [~jhawk28@user-387c58d.cable.mindspring.com] has joined #go-nuts 17:52 -!- jhawk28_ [~jhawk28@user-387c58d.cable.mindspring.com] has joined #go-nuts 17:52 -!- jhawk28 [~jhawk28@user-387c58d.cable.mindspring.com] has quit [Read error: Connection reset by peer] 17:55 -!- Kashia [~Kashia@port-92-200-108-107.dynamic.qsc.de] has joined #go-nuts 17:57 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 18:04 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts 18:07 -!- deso [~deso@x0561a.wh30.tu-dresden.de] has joined #go-nuts 18:09 -!- tvw [~tv@212.79.9.150] has quit [Remote host closed the connection] 18:24 -!- zozoR [~zozoR@56344bf6.rev.stofanet.dk] has quit [Quit: Morten. Desu~] 18:27 -!- TheMue [~TheMue@p5DDF755E.dip.t-dialin.net] has joined #go-nuts 18:30 -!- iant [~iant@nat/google/x-xhlzsswkddgorbtx] has joined #go-nuts 18:30 -!- mode/#go-nuts [+v iant] by ChanServ 18:36 -!- thiago__ [~thiago@189.59.204.192] has quit [Ping timeout: 250 seconds] 18:37 -!- thiago__ [~thiago@187.114.48.78] has joined #go-nuts 18:40 -!- skelterjohn_ [~jasmuth@c-71-230-156-50.hsd1.nj.comcast.net] has joined #go-nuts 18:40 -!- skelterjohn [~jasmuth@c-71-230-156-50.hsd1.nj.comcast.net] has quit [Read error: Connection reset by peer] 18:41 -!- virtualsue [~chatzilla@nat/cisco/x-vzfibmjcxqbuykle] has quit [Ping timeout: 265 seconds] 18:44 -!- xash [~xash@d126025.adsl.hansenet.de] has quit [Ping timeout: 240 seconds] 18:50 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 240 seconds] 18:51 < plexdev> http://is.gd/ip1hN by [Russ Cox] in go/src/cmd/ld/ -- ld: re-add ELF symbol tables 18:51 < plexdev> http://is.gd/ip1i0 by [Russ Cox] in go/src/cmd/ld/ -- ld: reading of ELF object files 18:51 < plexdev> http://is.gd/ip1il by [Russ Cox] in 3 subdirs of go/src/cmd/ -- 6l, 8l: minor changes & cleanup 18:51 < plexdev> http://is.gd/ip1iT by [Russ Cox] in go/src/cmd/gopack/ -- gopack: allow ELF/Mach-O objects in .a files without clearing allobj 18:51 < nsf> here we go :) 18:51 < plexdev> http://is.gd/ip1ja by [Russ Cox] in 2 subdirs of go/src/pkg/debug/ -- debug/elf, debug/macho: add ImportedLibraries, ImportedSymbols 18:51 < plexdev> http://is.gd/ip1jh by [Russ Cox] in go/src/cmd/ld/ -- ld: reading of Mach-O object files 18:51 -!- piyushmishra [~piyushmis@117.200.231.121] has quit [Quit: Leaving.] 18:51 < plexdev> http://is.gd/ip1kq by [Russ Cox] in 3 subdirs of go/src/pkg/ -- runtime/cgo: runtime changes for new cgo 18:51 < nsf> new cgo is coming 18:52 -!- tvw [~tv@e176005135.adsl.alicedsl.de] has joined #go-nuts 18:56 < kimelto> :) 18:56 -!- ville- [~ville@a107.ath.cx] has quit [Remote host closed the connection] 19:01 -!- ct529 [~quassel@77-44-78-159.xdsl.murphx.net] has joined #go-nuts 19:03 -!- wrtp [~rog@92.17.77.11] has quit [Ping timeout: 265 seconds] 19:08 < plexdev> http://is.gd/ip3A5 by [Russ Cox] in 3 subdirs of go/src/cmd/ -- 6l, 8l: support for linking ELF and Mach-O .o files 19:08 < plexdev> http://is.gd/ip3Ak by [Russ Cox] in 2 subdirs of go/src/ -- cgo: new cgo 19:08 < plexdev> http://is.gd/ip3B0 by [Russ Cox] in go/src/pkg/runtime/cgo/ -- runtime/cgo: take 2 19:09 -!- wrtp [~rog@92.17.77.11] has joined #go-nuts 19:16 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 19:16 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Quit: Leaving] 19:27 -!- emjayess [~emjayess@pix1.i29.net] has joined #go-nuts 19:27 -!- araujo [~araujo@190.38.50.25] has joined #go-nuts 19:27 -!- araujo [~araujo@190.38.50.25] has quit [Changing host] 19:27 -!- araujo [~araujo@gentoo/developer/araujo] has joined #go-nuts 19:32 < exch> adg: Are those 'go t.shirt()' shirts for sale somewhere? :p 19:37 -!- retybok [~retybok@i03m-212-195-151-239.d4.club-internet.fr] has joined #go-nuts 19:40 < plexdev> http://is.gd/ip83U by [Russ Cox] in go/src/pkg/syscall/ -- syscall: fix linux/arm build 19:40 < plexdev> http://is.gd/ip841 by [Russ Cox] in 3 subdirs of go/src/ -- libcgo: delete (replaced by runtime/cgo) 19:40 < plexdev> http://is.gd/ip84T by [Russ Cox] in go/src/ -- fix build: more libcgo references 19:42 -!- skelterjohn [~jasmuth@c-71-230-156-50.hsd1.nj.comcast.net] has quit [Quit: skelterjohn] 19:42 -!- Project_2501 [~Marvin@82.84.79.101] has joined #go-nuts 19:45 -!- rbraley [~rbraley@ip72-204-243-89.ph.ph.cox.net] has quit [Ping timeout: 260 seconds] 19:46 -!- noam [noam@77.124.236.67] has quit [Read error: Connection reset by peer] 19:46 -!- virtualsue [~chatzilla@nat/cisco/x-tbqhjlzttmcesixt] has joined #go-nuts 19:46 -!- noam [noam@77.124.236.67] has joined #go-nuts 19:47 -!- rbraley [~rbraley@ip72-204-243-89.ph.ph.cox.net] has joined #go-nuts 19:48 < wrtp> nsf: i haven't seen anything changing the GC yet. which CLs are you referring to? 19:49 < nsf> http://codereview.appspot.com/user/rsc 19:49 < nsf> http://codereview.appspot.com/3435041/ 19:49 -!- plainhao [~plainhao@208.75.85.237] has quit [Quit: plainhao] 19:50 -!- xash [~xash@d201245.adsl.hansenet.de] has joined #go-nuts 19:52 -!- antonkovalyov [~antonkova@75-101-56-240.dsl.static.sonic.net] has joined #go-nuts 19:54 -!- tensorpudding [~user@99.148.202.191] has joined #go-nuts 19:55 -!- anticw [~anticw@c-67-169-68-180.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer] 19:55 -!- anticw [~anticw@c-67-169-68-180.hsd1.ca.comcast.net] has joined #go-nuts 19:58 -!- ct529 [~quassel@77-44-78-159.xdsl.murphx.net] has quit [Remote host closed the connection] 20:01 < uriel> 12:58 < nsf> and I've seen recent Russ' changesets for GC 20:01 < uriel> nsf: where have you seen that? 20:01 < uriel> nsf: and AFAIK the changes in go/parser were supposed to speed things up, and certainly lower memory usage 20:02 < nsf> uriel: second link below 20:03 < uriel> nsf: if you are seeing leaks, are you using 8g or 6g? I seem to remember that there are some GC issues with 8g 20:03 < nsf> uriel: they made things slower and memory usage is another issue 20:03 < nsf> 8g 20:03 < nsf> they are not leaks 20:03 < nsf> these* 20:03 < uriel> then you might be tickling some bug, let me see if I can fin dit 20:03 < nsf> these are just free memory owned by GC 20:04 < nsf> oops, I meant 'above' earlier :D 20:04 < GilJ> Speaking of GC, does Go have fully working GC or not? I read somewhere that the garbage collecting part wasn't implemented 20:04 < GilJ> Don't remember where though :( 20:04 < nsf> 'below' is slightly different direction :D 20:04 < nsf> GilJ: it works 20:04 < GilJ> nsf: Ok thanks :) 20:04 < nsf> just not the way I want 20:05 < exch> It's a simplistic GC, but it works. New one in the works 20:05 < uriel> nsf: http://code.google.com/p/go/issues/detail?id=909 20:05 < GilJ> What would you like to see different, nsf? 20:05 < uriel> (and I think there are other related issues) 20:05 < uriel> 20:04 < GilJ> Speaking of GC, does Go have fully working GC or not? I read somewhere that the garbage collecting part wasn't 20:05 < uriel> implemented 20:05 < uriel> GilJ: you read wrong 20:05 < nsf> GilJ: I want it to minimize system memory usage 20:06 < nsf> because I have plans to implement desktop apps using Go 20:06 < nsf> and less memory they use - better 20:06 < uriel> GilJ: the GC is fully implemented, but it is being rewritten too 20:06 < nsf> currently Go mostly works for server software 20:06 < uriel> nsf: I don't see what the problem might be for client software... 20:07 < nsf> 450 megabytes of system memory usage, 60-120 megabytes is allocated, everything else is free and owned by GC in free lists 20:07 < nsf> something like that 20:07 < nsf> I can give you exact numbers if you want to 20:08 < GilJ> "Free lists?" 20:08 < nsf> yes 20:08 < kimelto> what is planned for the new GC? something like garbage first? 20:09 < nsf> GilJ: http://nsf.github.com/go/runtime.html?t:MemStatsType! 20:09 < nsf> see this structure 20:09 < GilJ> nsf: Thanks :) 20:09 < nsf> at the end it has a list 20:09 < nsf> 'BySize' 20:09 < nsf> GC keeps all of them under its control, it simply doesn't release memory back to OS 20:10 < nsf> it's ok for system-wide allocator 20:10 < nsf> and not a very good idea for per application basis 20:11 < GilJ> Ok I get it now, thanks nsf 20:11 < uriel> nsf: as i said, if you are going to complain about the GC, use 6g, becauxe 8g is known to be buggy 20:12 < nsf> my complains are not about bugs :) 20:12 < uriel> nsf: it not doing a good job is a bug 20:12 < plexdev> http://is.gd/ipcyO by [Adam Langley] in go/src/pkg/crypto/elliptic/ -- crypto/elliptic: remove mistakenly commited code 20:14 < wrtp> nsf: the GC will get better. just go with it for now. 20:15 < nsf> yeah, I know :) 20:15 -!- jhawk28_ [~jhawk28@user-387c58d.cable.mindspring.com] has quit [Ping timeout: 240 seconds] 20:17 -!- ct529 [~quassel@77-44-78-159.xdsl.murphx.net] has joined #go-nuts 20:19 < nsf> uriel: and maybe you're right as well 20:19 < nsf> I mean a lot of these memory usage comes from a bug, it is possible 20:19 < nsf> http://code.google.com/p/go/issues/detail?id=1210 20:19 -!- ct529 [~quassel@77-44-78-159.xdsl.murphx.net] has quit [Remote host closed the connection] 20:19 < nsf> especially that example kind of interesting 20:21 < nsf> I will download some 64bit linux distro and will try gocode with it 20:24 -!- xash [~xash@d201245.adsl.hansenet.de] has quit [Ping timeout: 245 seconds] 20:24 -!- coldturnip1 [~COLDTURNI@118-166-68-180.dynamic.hinet.net] has joined #go-nuts 20:25 -!- coldturnip [~COLDTURNI@118-166-70-93.dynamic.hinet.net] has quit [Ping timeout: 245 seconds] 20:26 -!- enherit [~enherit@cpe-98-149-170-48.socal.res.rr.com] has joined #go-nuts 20:27 < uriel> haha, funny name: http://code.google.com/p/rsc/ 20:29 < sl> haha! 20:29 -!- thiago__ [~thiago@187.114.48.78] has quit [Read error: Connection reset by peer] 20:38 -!- thiago__ [~thiago@187.114.48.78] has joined #go-nuts 20:39 -!- Eridius [~kevin@unaffiliated/eridius] has joined #go-nuts 20:39 -!- DarthShrine [~angus@60-242-109-62.tpgi.com.au] has joined #go-nuts 20:39 -!- DarthShrine [~angus@60-242-109-62.tpgi.com.au] has quit [Changing host] 20:39 -!- DarthShrine [~angus@pdpc/supporter/student/DarthShrine] has joined #go-nuts 20:44 < plexdev> http://is.gd/ipgUr by [Russ Cox] in go/src/cmd/5l/ -- 5l: fix build 20:44 < plexdev> http://is.gd/ipgUG by [Russ Cox] in 3 subdirs of go/src/cmd/ -- 5l (and 6l, 8l, ld): more arm build fixes 21:00 -!- photron [~photron@port-92-201-103-85.dynamic.qsc.de] has quit [Read error: Operation timed out] 21:00 -!- sauerbraten [~sauerbrat@p508CADF8.dip.t-dialin.net] has quit [Remote host closed the connection] 21:06 < adg> exch: i would like them to be. no plans as yet 21:07 < exch> aww 21:09 -!- boscop [~boscop@f055199010.adsl.alicedsl.de] has quit [Read error: Connection reset by peer] 21:10 -!- boscop [~boscop@f055199010.adsl.alicedsl.de] has joined #go-nuts 21:10 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has joined #go-nuts 21:13 -!- deso [~deso@x0561a.wh30.tu-dresden.de] has quit [Remote host closed the connection] 21:15 -!- boscop [~boscop@f055199010.adsl.alicedsl.de] has quit [Read error: Connection reset by peer] 21:15 -!- boscop [~boscop@f055199010.adsl.alicedsl.de] has joined #go-nuts 21:29 -!- noam [noam@77.124.236.67] has quit [Ping timeout: 240 seconds] 21:31 < plexdev> http://is.gd/ipnn9 by [Rob Pike] in 2 subdirs of go/src/pkg/ -- a few more errors caught by the print checker 21:36 -!- noff [~noff@88-190.78-83.cust.bluewin.ch] has joined #go-nuts 21:36 -!- noam [~noam@77.124.236.67] has joined #go-nuts 21:37 -!- TheMue [~TheMue@p5DDF755E.dip.t-dialin.net] has quit [Quit: TheMue] 21:44 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts 21:47 -!- saschpe [~quassel@opensuse/member/saschpe] has quit [Read error: Connection reset by peer] 21:48 < plexdev> http://is.gd/ippHc by [Russ Cox] in go/src/pkg/runtime/cgo/ -- runtime/cgo: adapt files copied from libcgo 21:48 < plexdev> http://is.gd/ippHo by [Russ Cox] in 2 subdirs of go/src/pkg/ -- arm: more fixes 21:50 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has quit [Quit: leaving] 21:52 < rmmh> how do I add a file to a pending codereview :| 21:53 -!- ronnyy [~quassel@drsd-4db3d4fc.pool.mediaWays.net] has joined #go-nuts 21:55 -!- jhawk28 [~jhawk28@user-387c58d.cable.mindspring.com] has joined #go-nuts 21:56 -!- jhawk28 [~jhawk28@user-387c58d.cable.mindspring.com] has quit [Read error: Connection reset by peer] 21:56 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has joined #go-nuts 22:02 <+iant> rmmh: run "hg change NNNN" and edit the list of files 22:03 < GilJ> If I have a package called unionfind, that implements a basic data structure, an interface with a Union and Find method, and a struct that contains the actual data, which one do I name UnionFind? The struct or the Interface? 22:04 <+iant> I think it depends on what you expect or want users of the package to use 22:04 < plexdev> http://is.gd/ipsdd by [Andrew Gerrand] in go/doc/ -- doc: fix invalid id attribute in faq 22:05 < GilJ> iant: ok, that makes sense, thanks alot! 22:06 < rmmh> GilJ: is this a disjointset? 22:07 < rmmh> someone with commit access should do s/for (.*), _ := range (.*)/for \1 := range \2/ to the tree 22:08 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has quit [Quit: hcatlin] 22:08 < GilJ> rmmh: No 22:09 < rmmh> why not 22:09 < rmmh> it's 100% useless 22:10 < GilJ> rmmh: It is, but I just wanted to play around with an interface 22:11 < rmmh> oh, sorry, I thought you said "no" in response to my regex :) 22:11 < GilJ> Ah sorry 22:11 < krutcha> what's useless? ranges? 22:14 -!- ronnyy [~quassel@drsd-4db3d4fc.pool.mediaWays.net] has quit [Remote host closed the connection] 22:15 -!- beneth` [~beneth`@ks358244.kimsufi.com] has quit [Quit: AnonOps] 22:15 -!- beneth` [~beneth`@ks358244.kimsufi.com] has joined #go-nuts 22:16 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 276 seconds] 22:18 -!- SRabbelier [~SRabbelie@188.142.63.148] has quit [Ping timeout: 250 seconds] 22:21 < plexdev> http://is.gd/ipva4 by [Rob Pike] in go/src/pkg/exp/nacl/av/ -- event.go: another print glitch from gocheck. 22:24 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 22:27 -!- fhs [~fhs@pool-74-101-63-115.nycmny.east.verizon.net] has joined #go-nuts 22:30 -!- watr_ [~watr@66.183.100.58] has joined #go-nuts 22:33 -!- retybok [~retybok@i03m-212-195-151-239.d4.club-internet.fr] has quit [Quit: leaving] 22:34 -!- boscop [~boscop@f055199010.adsl.alicedsl.de] has quit [Read error: Connection reset by peer] 22:34 -!- boscop [~boscop@f055199010.adsl.alicedsl.de] has joined #go-nuts 22:44 -!- awidegreen [~quassel@c-eacae555.08-2-73746f39.cust.bredbandsbolaget.se] has quit [Read error: Connection reset by peer] 22:45 -!- napsy [~luka@88.200.96.18] has quit [Quit: Lost terminal] 22:49 -!- Venom_X [~pjacobs@66.54.185.131] has quit [Quit: Venom_X] 22:51 -!- rlab [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 23:05 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit: Verlassend] 23:07 -!- thiago__ [~thiago@187.114.48.78] has quit [Quit: bye] 23:25 -!- Scorchin [~Scorchin@host109-152-113-87.range109-152.btcentralplus.com] has joined #go-nuts 23:33 -!- raylu [raylu@c-24-131-193-106.hsd1.pa.comcast.net] has quit [Read error: Connection reset by peer] 23:33 -!- raylu [raylu@c-24-131-193-106.hsd1.pa.comcast.net] has joined #go-nuts 23:34 < nsf> having a CPU without virtualization technology sucks.. 23:35 < nsf> qemu is like 20 times slower :D 23:36 -!- Scorchin [~Scorchin@host109-152-113-87.range109-152.btcentralplus.com] has quit [Ping timeout: 245 seconds] 23:49 -!- Scorchin [~Scorchin@host86-135-213-179.range86-135.btcentralplus.com] has joined #go-nuts 23:50 -!- Scorchin [~Scorchin@host86-135-213-179.range86-135.btcentralplus.com] has quit [Client Quit] --- Log closed Thu Dec 09 00:00:37 2010