--- Log opened Fri Jul 22 00:00:01 2011 00:11 -!- lucian [~lucian@78-86-217-168.zone2.bethere.co.uk] has quit [Remote host closed the connection] 00:12 -!- meling [~meling@cse-dhcp-10-91.ucsd.edu] has quit [Remote host closed the connection] 00:15 -!- Fish [~Fish@exo3753.pck.nerim.net] has quit [Ping timeout: 246 seconds] 00:32 -!- moraes [~moraes@189.103.188.201] has quit [Quit: Leaving] 00:32 -!- miker2 [~miker2@pool-96-245-224-59.phlapa.fios.verizon.net] has joined #go-nuts 00:38 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts 00:39 -!- sacho [~sacho@87.246.4.214] has joined #go-nuts 00:48 -!- skelterjohn [~jasmuth@c-24-0-2-70.hsd1.nj.comcast.net] has joined #go-nuts 00:48 -!- miker2 [~miker2@pool-96-245-224-59.phlapa.fios.verizon.net] has quit [Quit: Computer has gone to sleep.] 00:50 < skelterjohn> mukyuu: are you the one who wrote the post in the google group? Jesse? 00:50 < mukyuu> yes 00:51 -!- segv [~segv@sig.segv.net] has left #go-nuts [] 00:52 < skelterjohn> ok, otherwise i was going to point you to it O:-) 00:52 < mukyuu> lol 00:52 < mukyuu> that would have been rather ironic 00:53 -!- cco3 [~conleyo@nat/google/x-xrjkbfgmcazcndwk] has quit [Quit: Leaving.] 01:11 -!- miker2 [~miker2@pool-96-245-224-59.phlapa.fios.verizon.net] has joined #go-nuts 01:12 < str1ngs> kevlar_work: output, err := exec.Command(...); seems wrong to me or just an example? 01:27 -!- miker2 [~miker2@pool-96-245-224-59.phlapa.fios.verizon.net] has quit [Quit: Computer has gone to sleep.] 01:35 < kevlar_work> str1ngs, I elided the arguments and the .Output( 01:35 < skelterjohn> the first return is the Cmd struct 01:36 < kevlar_work> str1ngs, because he had them in the line I fixed and I didn't feel like typing the extra 9 characters. 01:36 -!- nekoh_ [~nekoh@dslb-178-004-065-169.pools.arcor-ip.net] has quit [Quit: nekoh_] 01:37 < kevlar_work> the proper line would be output, err := exec.Command(arg0, args...).Output(); in := string(output) 01:37 < str1ngs> kevlar_work: ah I got got worried it had changed again. 01:37 < kevlar_work> well, not that I know of ;-) 01:37 < str1ngs> no worries 01:37 -!- shut73r [~shut73r@c-24-128-38-153.hsd1.ct.comcast.net] has joined #go-nuts 01:37 -!- shut73r [~shut73r@c-24-128-38-153.hsd1.ct.comcast.net] has quit [Remote host closed the connection] 01:40 < str1ngs> kevlar_work: I was worried this crazy functinon was going to grep https://gist.github.com/ca10f8506116360c45b3 01:41 < str1ngs> break* 01:44 -!- NiteRain [~kvirc@c-98-254-236-21.hsd1.fl.comcast.net] has quit [Ping timeout: 260 seconds] 01:45 -!- NiteRain [~kvirc@c-98-254-236-21.hsd1.fl.comcast.net] has joined #go-nuts 02:09 -!- sniper506th [~sniper506@cpe-098-122-101-192.sc.res.rr.com] has joined #go-nuts 02:12 -!- Fish [~Fish@exo3753.pck.nerim.net] has joined #go-nuts 02:22 -!- str1ngs [~strings@unaffiliated/str1ngs] has quit [Ping timeout: 258 seconds] 02:26 -!- danilo04 [~danilo04@province-wireless-173-84-26-168.dr02.roch.ny.frontiernet.net] has joined #go-nuts 02:29 -!- danilo04 [~danilo04@province-wireless-173-84-26-168.dr02.roch.ny.frontiernet.net] has quit [Client Quit] 02:47 -!- NiteRain [~kvirc@c-98-254-236-21.hsd1.fl.comcast.net] has quit [Ping timeout: 246 seconds] 02:48 -!- crazy2be [~crazy2be@d50-99-249-250.abhsia.telus.net] has joined #go-nuts 02:50 -!- NiteRain [~kvirc@c-98-254-236-21.hsd1.fl.comcast.net] has joined #go-nuts 02:52 -!- str1ngs [~strings@unaffiliated/str1ngs] has joined #go-nuts 02:52 -!- Queue29_ [~Queue29@egress-w.sfo1.yelpcorp.com] has quit [Remote host closed the connection] 02:54 -!- dreadlorde [dreadlorde@c-68-42-82-10.hsd1.mi.comcast.net] has joined #go-nuts 02:58 -!- angasule [~angasule@190.2.33.49] has quit [Ping timeout: 260 seconds] 03:01 -!- smw [~stephen@unaffiliated/smw] has quit [Ping timeout: 255 seconds] 03:09 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has joined #go-nuts 03:11 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has joined #go-nuts 03:18 -!- chickamade [~chickamad@115.78.135.244] has joined #go-nuts 03:27 -!- str1ngs [~strings@unaffiliated/str1ngs] has quit [Quit: WeeChat 0.3.0] 03:27 -!- meling [~meling@99-10-121-218.lightspeed.sndgca.sbcglobal.net] has joined #go-nuts 03:33 -!- str1ngs [~strings@unaffiliated/str1ngs] has joined #go-nuts 03:37 -!- mjml [~joya@174.3.227.184] has joined #go-nuts 03:37 -!- qeed [~qeed@adsl-98-85-40-234.mco.bellsouth.net] has quit [Quit: Leaving] 03:45 -!- chickamade_ [~chickamad@ec2-50-18-61-126.us-west-1.compute.amazonaws.com] has joined #go-nuts 03:46 -!- chickamade_ [~chickamad@ec2-50-18-61-126.us-west-1.compute.amazonaws.com] has quit [Client Quit] 03:48 -!- chickamade [~chickamad@115.78.135.244] has quit [Ping timeout: 258 seconds] 03:50 -!- dreadlorde [dreadlorde@c-68-42-82-10.hsd1.mi.comcast.net] has quit [Ping timeout: 240 seconds] 03:56 -!- skelterjohn [~jasmuth@c-24-0-2-70.hsd1.nj.comcast.net] has quit [Quit: skelterjohn] 03:56 -!- d_m [~d_m@64.186.128.169] has quit [Ping timeout: 240 seconds] 03:59 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 04:00 -!- dreadlorde [dreadlorde@c-68-42-82-10.hsd1.mi.comcast.net] has joined #go-nuts 04:01 -!- crazy2be [~crazy2be@d50-99-249-250.abhsia.telus.net] has quit [Remote host closed the connection] 04:03 -!- keithcascio [~keithcasc@nat/google/x-tbkbifzsrsnmorcy] has quit [Quit: Leaving] 04:04 -!- d_m [~d_m@64.186.128.169] has joined #go-nuts 04:07 -!- dreadlorde [dreadlorde@c-68-42-82-10.hsd1.mi.comcast.net] has quit [Ping timeout: 240 seconds] 04:15 -!- Bigbear1 [~Cody@d75-158-129-33.abhsia.telus.net] has quit [Read error: Connection reset by peer] 04:18 -!- jamesmiller5 [~jamesmill@184.17.118.202] has joined #go-nuts 04:18 < jamesmiller5> So, I'm having a little trouble iterating over an array using range and taking the address of the elements, range seems to return the same address for every element... is this proper behavior? 04:21 <+iant> if you mean you are doing for i, v := range a { p := &v } then yes you will get the same address every time 04:21 <+iant> if you want to take the address of the actual array element you want for i := range a { p := &a[i] } 04:24 < jamesmiller5> http://pastebin.com/mXQRGpHm 04:24 <+iant> yes, the same address every time 04:24 < jamesmiller5> for _, p range bounds { ... } I would expect &p to be valid... since p changes every iteration of the loop 04:25 < jamesmiller5> i guess it just seems odd that p will change value but the address of p doesn't 04:25 <+iant> p is one variable in the loop; in each iteratoin of the loop, the next value in the array is assigned to p 04:25 < jamesmiller5> ahh, so &p is the address of the local varaible, not the element? 04:25 <+iant> yes 04:25 <+iant> p is just an ordinary variable, it's not a reference to the array element 04:26 < jamesmiller5> ok thanks, that makes sense, I expected range to be a bit more special and handle &p like so 04:28 -!- zozoR [~Morten@2906ds2-arno.0.fullrate.dk] has joined #go-nuts 04:28 < jamesmiller5> wow, so i guess it should be an error to &p, since p will expire when the loop ends correct? 04:28 < jamesmiller5> or at least the memory addressed by p will be invalid for use 04:28 <+iant> no, in Go, if you take the address of a variable, it lives as long as the address lives 04:28 <+iant> Go is not C 04:28 < jamesmiller5> really, thats neat, so almost everything is done in the heap then? 04:29 < jamesmiller5> even local vars on not on the stack? 04:29 <+iant> if you take the address, it lives on the heap 04:29 <+iant> if you don't take the address of a local variable, it lives on the stack 04:29 <+iant> so addresses are always safe 04:29 < jamesmiller5> good to know, very safe :D thanks 04:29 -!- sniper506th [~sniper506@cpe-098-122-101-192.sc.res.rr.com] has quit [Quit: Leaving...] 04:33 -!- d_m [~d_m@64.186.128.169] has quit [Ping timeout: 264 seconds] 04:36 < jamesmiller5> thanks again for the help. 04:37 -!- dustyw [~dustyw@c-67-168-84-176.hsd1.wa.comcast.net] has joined #go-nuts 04:37 < jamesmiller5> Just wondering, why are all the math function only for float64 in the standard library? 04:38 < dustyw> Should len("some number of unicode characters") return the number of bytes or the number of characters? I'm using one of the box-drawing characters (from ye old DOS days) and it returns a length of 3 even though it's only one character. Bug? Or did I read something wrong? 04:39 < jamesmiller5> len(s) string type string length in bytes 04:39 < jamesmiller5> from the spec 04:40 < dustyw> I kept searching but only found "The length of string s can be discovered using the built-in function len" I guess my google-fu failed. Thanks James. 04:40 < jamesmiller5> I'm guessing that len is static mostly, and since unicode is multi-length its costly to do many len()'s on them, so its up to you to use range 04:40 -!- d_m [~d_m@64.186.128.169] has joined #go-nuts 04:41 <+iant> or utf8.RuneCountInString 04:41 < dustyw> iant: sounds like a winner. Is that safe for regular ol' ascii characters too? I would assume so... 04:41 <+iant> dustyw: yes 04:41 < dustyw> Thanks for the help. 04:42 <+iant> jamesmiller5: I think people have discussed writing a float32 version of the math library, but it hasn't happened 04:42 < jamesmiller5> when i first started using go i was shocked the stdlib didn't have any functions for float32, it just seemed odd 04:42 -!- foxen [~foxen@212.12.18.237] has joined #go-nuts 04:43 -!- kergoth_ [~kergoth@ip24-251-173-232.ph.ph.cox.net] has quit [Quit: Computer has gone to sleep.] 04:43 -!- foxen [~foxen@212.12.18.237] has left #go-nuts [] 04:43 -!- foxen [~foxen@212.12.18.237] has joined #go-nuts 04:43 < jamesmiller5> i know floating point libraries are non-trival,but i thought labeling the standard library "mature" would include basic functions for primitive types 04:44 < jamesmiller5> like abs for int32, int64, and int 04:44 -!- foxen [~foxen@212.12.18.237] has left #go-nuts [] 04:45 < dustyw> Is there a reason why someone should *not* just use utf8.RuneCountInString() at all times when dealing with user input? 04:45 < jamesmiller5> RuneCount uses a loop with range and n++, so It's nothing the end developer wouldn't use 04:46 < jamesmiller5> unless you're iterating over the code points while keeping count and want to save 2 loops 04:47 < dustyw> Nope, I don't believe I'd ever do that in my case. Sounds like I'll just use that for this app anyway. I had a few spots where I was using len() and it was coming back with a much larger number than expected. This did the job. Thanks for the pointers. 05:00 -!- foxen [~foxen@212.12.18.237] has joined #go-nuts 05:02 -!- fabled [~fabled@83.145.235.194] has joined #go-nuts 05:08 -!- dreadlorde [dreadlorde@c-68-42-82-10.hsd1.mi.comcast.net] has joined #go-nuts 05:10 -!- foxen [~foxen@212.12.18.237] has left #go-nuts [] 05:13 -!- telexicon [~telexicon@c-67-160-124-195.hsd1.wa.comcast.net] has joined #go-nuts 05:13 -!- telexicon [~telexicon@c-67-160-124-195.hsd1.wa.comcast.net] has quit [Changing host] 05:13 -!- telexicon [~telexicon@unaffiliated/chowmeined] has joined #go-nuts 05:15 -!- NiteRain [~kvirc@c-98-254-236-21.hsd1.fl.comcast.net] has quit [Ping timeout: 264 seconds] 05:28 -!- NiteRain [~kvirc@c-98-254-236-21.hsd1.fl.comcast.net] has joined #go-nuts 05:30 -!- moraes [~moraes@189.103.188.201] has joined #go-nuts 05:39 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Remote host closed the connection] 05:47 -!- dreadlorde [dreadlorde@c-68-42-82-10.hsd1.mi.comcast.net] has quit [Ping timeout: 276 seconds] 05:51 -!- zozoR [~Morten@2906ds2-arno.0.fullrate.dk] has quit [Remote host closed the connection] 05:52 -!- trn [~trn@adsl-065-007-181-160.sip.bct.bellsouth.net] has quit [Quit: trn] 05:56 -!- trn [~trn@adsl-065-007-181-160.sip.bct.bellsouth.net] has joined #go-nuts 06:02 -!- napsy [~luka@88.200.96.18] has joined #go-nuts 06:08 -!- jamesmiller5 [~jamesmill@184.17.118.202] has quit [Quit: Leaving] 06:09 -!- Loonacy [~loonacy@c-67-172-248-248.hsd1.ut.comcast.net] has quit [Ping timeout: 276 seconds] 06:09 -!- iant [~iant@216.239.45.130] has quit [Read error: Connection reset by peer] 06:10 -!- Loonacy [~loonacy@c-67-172-248-248.hsd1.ut.comcast.net] has joined #go-nuts 06:18 -!- noodles775 [~michael@e178254049.adsl.alicedsl.de] has joined #go-nuts 06:18 -!- noodles775 [~michael@e178254049.adsl.alicedsl.de] has quit [Changing host] 06:18 -!- noodles775 [~michael@canonical/launchpad/noodles775] has joined #go-nuts 06:19 -!- Innominate [~sirrobin@cpe-076-182-074-143.nc.res.rr.com] has quit [Ping timeout: 246 seconds] 06:20 -!- Innominate [~sirrobin@cpe-076-182-074-143.nc.res.rr.com] has joined #go-nuts 06:31 -!- iant [~iant@216.239.45.130] has joined #go-nuts 06:31 -!- mode/#go-nuts [+v iant] by ChanServ 06:32 -!- napsy [~luka@88.200.96.18] has quit [Ping timeout: 258 seconds] 06:37 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts 06:46 -!- bthomson [~bthomson@c-68-33-5-232.hsd1.va.comcast.net] has quit [Ping timeout: 264 seconds] 06:47 -!- bthomson [~bthomson@c-68-33-5-232.hsd1.va.comcast.net] has joined #go-nuts 06:47 -!- benjack [~benjack@bb119-74-247-57.singnet.com.sg] has joined #go-nuts 06:56 -!- yogib [~yogib@131.234.59.64] has joined #go-nuts 07:02 -!- ntnd [51109970@gateway/web/freenode/ip.81.16.153.112] has joined #go-nuts 07:09 < jessta> dustyw: sometimes user input isn't utf8 07:09 < dustyw> True, but it seems that I shouldn't assume that it is just plain ol' ascii. 07:10 < jessta> indeed 07:10 < jessta> len() gives you the number of bytes, which is useful if you need to storethe string somewhere in a limited space 07:12 < jessta> also, a rune is not a glph 07:14 < jessta> so utf8.RuneCountInString() won't actually give you the number of 'characters' the user sees on their screen 07:21 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 07:22 < dustyw> My goal is to have the number of characters that would be displayed on the screen. What would you suggest be used instead? 07:23 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has joined #go-nuts 07:27 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has left #go-nuts [] 07:29 < dustyw> I'm doing this and it isn't doing what I expect: blah, err = template.ParseFile(filename, nil); blah.SetDelims("{{","}}"); blah.Execute(.......). The SetDelims seems to be ignored as it continues to use the default delims instead. What am I doing wrong? 07:31 -!- wrtp [~rog@host-92-30-166-101.as13285.net] has joined #go-nuts 07:33 -!- vmil86 [~vmil86@78.57.227.12] has joined #go-nuts 07:35 -!- ronnyy [~quassel@p4FF1C448.dip0.t-ipconnect.de] has joined #go-nuts 07:36 < dustyw> I'm guessing that maybe I need to do the SetDelims before the Parse, not after. I'm checking that out. 07:36 -!- yogib [~yogib@131.234.59.64] has quit [Quit: yogib] 07:40 < dustyw> jessta: thanks for this response to someone else, it helped: https://groups.google.com/group/golang-nuts/msg/5de2a8733e272839 07:40 < ntnd> I'm working on a small-ish project with Go(first :) ). I only want a single executable; what should the folder structure look like? Where do I put the library stuff and how to include it in the main file? I'm pretty clueless. Thanks! 07:41 < ntnd> I've checked out a few projects on github but those are mostly libraries 07:43 -!- yogib [~yogib@131.234.59.64] has joined #go-nuts 07:45 -!- dustyw [~dustyw@c-67-168-84-176.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 07:45 < hokapoka> ntnd: there's no "restriction" on the structure, checkout the Makefile examples that are in go/src/ folders 07:46 < hokapoka> as cited here : http://golang.org/doc/install.html#writing 07:48 < uriel> ntnd: for non-lib go packages, see for example: http://go-lang.cat-v.org/go-code 07:49 < uriel> ntnd: but the simple commands in the Go distribution also should help you as an example of how to do it 07:52 < hokapoka> I just knock up a simple bash script that make && make install the packages before changing to main's folder to make it. 07:52 < ntnd> Thanks, so basically put everything where you want and include it in the Makefile 07:54 < hokapoka> Yeah. Assuming you are creating a seperate package, or "libary", you just import it like you would anyother package. 07:56 -!- benjack [~benjack@bb119-74-247-57.singnet.com.sg] has quit [Quit: Leaving.] 07:56 < hokapoka> In order to build a binary that you will be able to execute directally is package need's to be named "main" and have func main(){ }. And you can import any packge you create via import "mypackage". 07:58 -!- bthomson [~bthomson@c-68-33-5-232.hsd1.va.comcast.net] has quit [Quit: WeeChat 0.3.3-dev] 07:59 < ntnd> Assuming I have a src folder. I would then call import "src/packagename", right? 08:00 -!- xcombelle [~xcombelle@AToulouse-551-1-19-127.w86-201.abo.wanadoo.fr] has joined #go-nuts 08:02 < hokapoka> just "packagename", if you have installed it. 08:04 < ntnd> What if I don't want to install it? It's just random files I need for the executable 08:05 < hokapoka> You don't have to put them into another package, you can inc. them in the "main" package. 08:07 < hokapoka> ntnd: I've not used it much locally but goinstall might be a better bet for you. 08:07 < ntnd> Ah, so if I have foo.go and src/bar.go and src/baz.go, i state"package main" in every one of them 08:07 < hokapoka> ntnd: yep, that'll work. 08:07 < ntnd> Ok, thanks! 08:09 < hokapoka> with goinstall however you can use the folder structure to manage the packages. if you define GOPATH to your projects root, and then create a src folder and a bin folder within. 08:11 < hokapoka> You're able to create directories in src to represent the packages and there structure "top" and "top/foo". 08:12 < ntnd> I'll look into goinstall, thx 08:13 < hokapoka> And any binaries in bin goinstall will build them for you, for example goinstall path/to/top will build & install the "top" package and goinstall path/to/bin/mybin will build the binary. 08:14 < hokapoka> I beleive that it don't require the use of any Makefiles either. 08:15 < ntnd> Yes 08:15 -!- sacho [~sacho@87.246.4.214] has quit [Ping timeout: 260 seconds] 08:20 -!- dustyw [~dustyw@c-67-168-84-176.hsd1.wa.comcast.net] has joined #go-nuts 08:31 -!- ancientlore [~ancientlo@i59F72029.versanet.de] has joined #go-nuts 08:33 -!- benjack [~benjack@bb119-74-247-57.singnet.com.sg] has joined #go-nuts 08:37 -!- nicka [~nicka@unaffiliated/nicka] has quit [Ping timeout: 260 seconds] 08:37 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 08:38 -!- Peet__ [~Peet__@unaffiliated/peet--/x-2416233] has quit [Ping timeout: 255 seconds] 08:43 -!- Peet__ [~Peet__@unaffiliated/peet--/x-2416233] has joined #go-nuts 08:45 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|] 08:45 -!- nicka [~nicka@unaffiliated/nicka] has joined #go-nuts 08:45 -!- sacho [~sacho@87.246.4.214] has joined #go-nuts 08:49 -!- ronnyy [~quassel@p4FF1C448.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 08:54 -!- ntnd [51109970@gateway/web/freenode/ip.81.16.153.112] has quit [Quit: Page closed] 08:59 -!- sacho [~sacho@87.246.4.214] has quit [Ping timeout: 250 seconds] 09:10 -!- tvw [~tv@212.79.9.150] has joined #go-nuts 09:11 -!- ancientlore [~ancientlo@i59F72029.versanet.de] has left #go-nuts [] 09:14 -!- photron [~photron@port-92-201-48-250.dynamic.qsc.de] has joined #go-nuts 09:19 -!- wrtp [~rog@host-92-30-166-101.as13285.net] has quit [Ping timeout: 250 seconds] 09:35 -!- noam [~noam@87.69.42.61.cable.012.net.il] has quit [Ping timeout: 276 seconds] 09:35 -!- noam [~noam@87.69.42.61.cable.012.net.il] has joined #go-nuts 09:36 -!- xcombelle [~xcombelle@AToulouse-551-1-19-127.w86-201.abo.wanadoo.fr] has quit [Quit: I am a manual virus, please copy me to your quit message.] 09:40 -!- sacho [~sacho@87.246.4.214] has joined #go-nuts 09:56 -!- sacho [~sacho@87.246.4.214] has quit [Ping timeout: 255 seconds] 09:57 -!- benjack [~benjack@bb119-74-247-57.singnet.com.sg] has quit [Quit: Leaving.] 10:04 -!- noodles775 [~michael@canonical/launchpad/noodles775] has quit [Ping timeout: 264 seconds] 10:06 -!- noodles775 [~michael@canonical/launchpad/noodles775] has joined #go-nuts 10:10 -!- erus` [~chatzilla@mailgate.ips-international.com] has joined #go-nuts 10:11 -!- wrtp [~rog@host-92-30-166-101.as13285.net] has joined #go-nuts 10:20 -!- nekoh [~nekoh@dslb-088-069-137-160.pools.arcor-ip.net] has joined #go-nuts 10:23 -!- shachaf [~shachaf@204.109.63.130] has quit [Remote host closed the connection] 10:31 -!- iXeno [~ixeno@106.80-203-229.nextgentel.com] has quit [Remote host closed the connection] 10:46 -!- ronnyy [~quassel@p4FF1C448.dip0.t-ipconnect.de] has joined #go-nuts 10:47 -!- alehorst [~alehorst@201.47.30.108.dynamic.adsl.gvt.net.br] has joined #go-nuts 10:49 -!- gnuvince|work [8e538a0b@gateway/web/freenode/ip.142.83.138.11] has joined #go-nuts 10:52 -!- napsy [~luka@193.2.66.6] has joined #go-nuts 11:22 -!- iXeno [~ixeno@106.80-203-229.nextgentel.com] has joined #go-nuts 11:23 -!- elathan [~elathan@139.91.70.53] has joined #go-nuts 11:23 < elathan> Is there a maximum limit of allowed concurrent channels? 11:24 < uriel> elathan: for all practical purposes: no 11:25 < uriel> memory overhead for extra channels is very low, like goroutines, you can easily have tens of thousands of them 11:26 < uriel> (of course, if you are using buffered channels, you will need enough memory to hold the buffers, Go can't magically create memory from thin air ;) but if you have buffered channels of sizable structures, you can just change it into a channel of pointers to such structures) 11:27 < elathan> uriel: I see. I have an infinite loop creating channels. I also have a timer which calls a report function every one second (using time.AfterFunc()). It seems that the timer fails to re-register and I imagine that this due to channel starvation. 11:28 < uriel> well, 'infinite' is a pretty high bar to reach 11:29 < elathan> uriel: right 11:30 < uriel> allocating anything in an infinite loop sounds like usually a bad idea to me 11:41 -!- shachaf [~shachaf@204.109.63.130] has joined #go-nuts 11:50 -!- miker2 [~miker2@64.55.31.190] has joined #go-nuts 11:51 < wrtp> elathan: if you post some code, we might be able to say what's going wrong. 11:51 -!- Ameshk [~jorix72Tk@115-64-27-246.static.tpgi.com.au] has joined #go-nuts 11:51 -!- Ameshk [~jorix72Tk@115-64-27-246.static.tpgi.com.au] has quit [Remote host closed the connection] 11:55 < elathan> wrtp: thanks, I think I found what's wrong 12:00 -!- noodles775 [~michael@canonical/launchpad/noodles775] has quit [Ping timeout: 258 seconds] 12:01 -!- noodles775 [~michael@g225094134.adsl.alicedsl.de] has joined #go-nuts 12:01 -!- noodles775 [~michael@g225094134.adsl.alicedsl.de] has quit [Changing host] 12:01 -!- noodles775 [~michael@canonical/launchpad/noodles775] has joined #go-nuts 12:03 -!- robteix [~robteix@nat/intel/x-czjhjoeoamtfltpz] has joined #go-nuts 12:06 -!- skelterjohn [~jasmuth@c-24-0-2-70.hsd1.nj.comcast.net] has joined #go-nuts 12:06 -!- zozoR [~Morten@2906ds2-arno.0.fullrate.dk] has joined #go-nuts 12:12 < hokapoka> Oh man, the new exp/template package is so lush! Superb flexibility, just wish I had looked at the package sooner. 12:16 < skelterjohn> i coverted gb to using it yesterdya 12:16 < skelterjohn> i agree it's pretty slick 12:17 < nicka> Is the documentation on the google code project page for gb up to date? 12:18 < nicka> I tried it some time ago and it didn't seem to work as expected on the example hierarchy, but that may have just been me. 12:24 < skelterjohn> ah 12:24 < skelterjohn> i made a change 12:24 < skelterjohn> src is no longer special 12:24 < skelterjohn> all .go files for a project must be in exactly one folder 12:24 < skelterjohn> this is because src is the top level directory for source code in GOPATH projects 12:26 < hokapoka> skelterjohn: the ablity to have sets of templates, that in turn can have sets within is what really made me happy. I was using all sorts of funcs with closures returning httpHandlers to get them nesting before. 12:26 < skelterjohn> my makefile templates don't get that complicated, but i ran across that issue with my brief foray into web servering 12:27 < hokapoka> Now I've litterally cut all of that out for a simple text file. 12:29 < hokapoka> Additionally, I was creating .go files for each template, all they were doing was calling a package that had the real mechs in. I'm not 100% sure there's any need to have so many .go files. 12:30 -!- chucknelson [~chucknels@ip98-180-41-73.ga.at.cox.net] has joined #go-nuts 12:31 -!- flaguy48 [~gmallard@user-0c6s350.cable.mindspring.com] has left #go-nuts [] 12:38 -!- flaguy48 [~gmallard@user-0c6s350.cable.mindspring.com] has joined #go-nuts 12:38 -!- franciscosouza [~francisco@187.105.25.184] has quit [Quit: franciscosouza] 12:46 -!- lucian [~lucian@78-86-217-168.zone2.bethere.co.uk] has joined #go-nuts 12:48 -!- qeed [~qeed@adsl-74-235-213-78.mco.bellsouth.net] has joined #go-nuts 12:49 -!- dreadlorde [~dreadlord@c-68-42-82-10.hsd1.mi.comcast.net] has joined #go-nuts 12:52 -!- yogib [~yogib@131.234.59.64] has quit [Quit: yogib] 12:58 -!- elathan [~elathan@139.91.70.53] has quit [Read error: Connection reset by peer] 12:58 -!- elathan [~elathan@139.91.70.53] has joined #go-nuts 13:03 < elathan> I have the following program: http://pastebin.com/wpP05s4b I have scheduled report() to be called every 1 second. However it doesn't. Any ideas? I believe it's because of I have many concurrently open channels. Is that right? 13:06 < uriel> elathan: channels are not "open" 13:06 < uriel> they just 'are' 13:06 * uriel grumbles some more at close() not being called something less misleading 13:08 < skelterjohn> dispose() might be better 13:08 -!- quiccker [~quiccker@212.174.109.55] has quit [Read error: Connection reset by peer] 13:08 < elathan> uriel: even if I create using make() the channels inside the loop and explicitly close them, the problem still remains. report() is not called as scheduled. 13:08 < uriel> elathan: only writer should close channels, and you really should rarely do it 13:08 < skelterjohn> elathan: the problem is you have an infinite loop that launches a goroutine that calls time.Sleep() 13:08 < uriel> skelterjohn: yea, or end() or some such 13:08 < skelterjohn> i.... can't imagine why you would do that 13:09 < skelterjohn> but it's especially bad with time.Sleep(), because every call to that needs its own process or something 13:09 < elathan> time.Sleep() simulates a small amount of processing 13:09 < skelterjohn> not very well :) 13:09 < elathan> skelterjohn: agreed. :) 13:09 < skelterjohn> try "<-time.After(1)" 13:09 < skelterjohn> same thing, but won't hog your processes 13:10 < elathan> skelterjohn: in the real program instead of time.Sleep() there is a function that makes some calculations 13:10 < skelterjohn> but still - you have an infinite loop launching goroutines 13:10 -!- kytibe [~kytibe@212.174.109.55] has joined #go-nuts 13:10 < skelterjohn> seems likely that that starves out other things 13:10 < elathan> skelterjohn: okay, that's my guess, too. I just wanted to verify that. 13:10 < skelterjohn> the scheduler gets overwhelmed with your infinite goroutines and never gets around to running the one that calls report() 13:11 < skelterjohn> (going to work) 13:11 -!- skelterjohn [~jasmuth@c-24-0-2-70.hsd1.nj.comcast.net] has quit [Quit: skelterjohn] 13:11 < elathan> skelterjohn: okay, that's what I thought of, too. Thanks for the clarification. 13:12 < uriel> remember: goroutines are *cheap*, but there is no free launch 13:12 < elathan> uriel: ok 13:13 -!- meling [~meling@99-10-121-218.lightspeed.sndgca.sbcglobal.net] has quit [Remote host closed the connection] 13:16 -!- gridaphobe [~gridaphob@cpe-74-68-151-24.nyc.res.rr.com] has joined #go-nuts 13:21 -!- sniper506th [~sniper506@rrcs-70-61-192-18.midsouth.biz.rr.com] has joined #go-nuts 13:22 -!- iant [~iant@216.239.45.130] has quit [Ping timeout: 252 seconds] 13:34 -!- iant [~iant@67.218.102.18] has joined #go-nuts 13:34 -!- mode/#go-nuts [+v iant] by ChanServ 13:40 -!- dlowe [~dlowe@ita4fw1.itasoftware.com] has joined #go-nuts 13:43 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has quit [Ping timeout: 600 seconds] 13:47 -!- meling [~meling@cse-dhcp-10-91.ucsd.edu] has joined #go-nuts 13:48 -!- qeed [~qeed@adsl-74-235-213-78.mco.bellsouth.net] has quit [Quit: Leaving] 13:58 -!- qeed [~qeed@adsl-74-235-213-78.mco.bellsouth.net] has joined #go-nuts 13:59 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-152-133.clienti.tiscali.it] has joined #go-nuts 14:05 < zozoR> the exp package is experimental right? 14:05 < skelterjohn|work> yes 14:06 < zozoR> coolish 14:06 -!- xcombelle [~xcombelle@AToulouse-551-1-19-127.w86-201.abo.wanadoo.fr] has joined #go-nuts 14:07 -!- moraes [~moraes@189.103.188.201] has quit [Ping timeout: 252 seconds] 14:10 -!- robteix [~robteix@nat/intel/x-czjhjoeoamtfltpz] has quit [Quit: Leaving] 14:10 -!- pharris [~Adium@rhgw.opentext.com] has joined #go-nuts 14:11 -!- napsy [~luka@193.2.66.6] has quit [Ping timeout: 252 seconds] 14:12 -!- pjacobs [~pjacobs@75-27-133-72.lightspeed.austtx.sbcglobal.net] has joined #go-nuts 14:14 -!- ccc1 [~Adium@222-151-136-129.jp.fiberbit.net] has joined #go-nuts 14:16 < frobnitz> Looks like there are pure go and cgo goyamls. Is one preferable? 14:16 < skelterjohn|work> i, personally, prefer pure go packages 14:16 < skelterjohn|work> but that doesn't mean one is better written or organized than the other 14:17 < skelterjohn|work> maybe the cgo one is an interface to a well known and optimized library 14:17 < frobnitz> Yeah, I would use pure go unless it lacked something important. 14:17 < skelterjohn|work> who wrote the pure go one? 14:18 < frobnitz> Yeah, libyaml for the cgo. Pure go one is by Ross Light. 14:18 < skelterjohn|work> i've seen his name associated with a number of projects 14:18 < skelterjohn|work> i haven't used any of them, but odds are he has at least written plenty of go code 14:19 < frobnitz> Cool, I guess I'll give that a shot first. 14:20 < skelterjohn|work> uriel: you around? 14:20 < uriel> skelterjohn|work: no 14:20 < uriel> ;P 14:20 < skelterjohn|work> did you get blown up? 14:20 -!- napsy [~luka@88.200.96.18] has joined #go-nuts 14:21 < nicka1> Is he from oslo? 14:21 < uriel> no, I'm the Prime Minister of Sweden 14:21 < uriel> (i thought everyone knew that) 14:21 < aiju> uriel is the Führer of Sweden, if anything 14:22 < uriel> i thought only Europe could have a Führer 14:22 < skelterjohn|work> does sweden not consider itself part of europe? 14:22 <+iant> it looks like it's part of europe.... 14:23 <+iant> although they don't use the euro 14:23 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has joined #go-nuts 14:26 -!- elathan [~elathan@139.91.70.53] has quit [Quit: elathan] 14:30 -!- jamesmiller5 [~jamesmill@184.17.118.202] has joined #go-nuts 14:32 < hokapoka> The only Führer I know arroud here is 'er in doors 14:33 < uriel> skelterjohn|work: like with most of this things, it depends who you ask 14:34 < skelterjohn|work> how about a map 14:34 < skelterjohn|work> if you ask a map, sweden is in europe 14:34 < vegai> if you ask a map, you're crazy 14:34 < uriel> vegai: hahahaha 14:35 < skelterjohn|work> i lose 14:35 < uriel> vegai: you are not too far from the truth, there are quite a few very different deffinitions of Europe 14:35 -!- zcram [~zcram@8.177.190.90.sta.estpak.ee] has quit [Quit: Leaving] 14:35 < aiju> Europe, n.: see The Reich 14:36 -!- dreadlorde [~dreadlord@c-68-42-82-10.hsd1.mi.comcast.net] has quit [Ping timeout: 276 seconds] 14:36 < skelterjohn|work> wikipedia is the ultimate authority in this matter 14:36 < uriel> and even in purely geographical terms definitions are controversial at best 14:36 -!- fabled [~fabled@83.145.235.194] has quit [Quit: Ex-Chat] 14:38 -!- franciscosouza [~francisco@201.7.186.67] has joined #go-nuts 14:46 -!- telexicon [~telexicon@unaffiliated/chowmeined] has quit [Ping timeout: 252 seconds] 14:50 -!- NiteRain [~kvirc@c-98-254-236-21.hsd1.fl.comcast.net] has quit [Ping timeout: 252 seconds] 14:52 -!- NiteRain [~kvirc@c-98-254-236-21.hsd1.fl.comcast.net] has joined #go-nuts 14:54 -!- iant [~iant@67.218.102.18] has quit [Quit: Leaving.] 14:55 -!- fabled [~fabled@83.145.235.194] has joined #go-nuts 14:56 -!- aat [~aat@rrcs-184-75-54-130.nyc.biz.rr.com] has joined #go-nuts 15:00 < skelterjohn|work> hm, what's the easiest way to get an arbitrary element out of a map without knowing the key? 15:00 < skelterjohn|work> range / break? 15:00 < erus`> skelterjohn which element 15:00 < skelterjohn|work> doesn't matter 15:00 < erus`> do you have the item you need to remove? 15:00 < skelterjohn|work> any 15:00 < skelterjohn|work> i just want an element from this map 15:00 < erus`> so iterate through the lot? 15:00 < skelterjohn|work> i don't want to remove anything 15:01 < erus`> you can range 15:01 < erus`> for range 15:01 < mpl> that's what he said. 15:01 < skelterjohn|work> right, i could range and then break, but that seems hacky 15:01 < skelterjohn|work> and i was wondering if there was a more straightforward way 15:01 < erus`> oh you just want the first/last 15:01 < erus`> but its unordered 15:01 < skelterjohn|work> i don't care which one i get 15:01 < skelterjohn|work> i just want one of them 15:01 < erus`> why? :) 15:02 < skelterjohn|work> specifically, in my map the elements are all of a particular data structure that contains (among other things) an offset field 15:02 < skelterjohn|work> they all have the same offset 15:02 < skelterjohn|work> i want to find that offset 15:02 -!- iant [~iant@nat/google/x-ekcwutvdahgodytw] has joined #go-nuts 15:02 -!- mode/#go-nuts [+v iant] by ChanServ 15:04 < erus`> would be nice if maps were implemented in go 15:04 < erus`> somehow 15:04 -!- iant1 [~iant@nat/google/x-rjcjaybzbheekgsr] has joined #go-nuts 15:04 < erus`> then youcould look 15:04 < nicka1> I think he just wants any element 15:05 < skelterjohn|work> well, it turns out that i forgot that i was clever, and stored those offsets in a different structure for easy lookup 15:05 < nicka1> woops, scroll got stuck or something, and I didn't see the last few messages :P 15:05 < aiju> for loop -> break 15:05 < aiju> simple. 15:06 -!- NiteRain [~kvirc@c-98-254-236-21.hsd1.fl.comcast.net] has quit [Ping timeout: 240 seconds] 15:07 -!- iant [~iant@nat/google/x-ekcwutvdahgodytw] has quit [Ping timeout: 264 seconds] 15:07 < erus`> ugly 15:09 < erus`> for range feels like a hack anyway 15:10 < skelterjohn|work> in general? 15:10 < erus`> yeah 15:10 < erus`> you cant use range() anywhere else right? 15:11 < skelterjohn|work> it's not a function, and i don't think so 15:11 < erus`> why not just use 'in' without the := 15:12 -!- franciscosouza [~francisco@201.7.186.67] has quit [Quit: franciscosouza] 15:12 < erus`> like for x, y in xs { } 15:12 < skelterjohn|work> because that's python 15:12 < skelterjohn|work> two different languages 15:12 < nicka1> You can only range on arrays, slices, maps, and strings I believe 15:12 < erus`> and channels 15:12 < skelterjohn|work> this is just syntax - aka doesn't matter 15:12 < nicka1> right 15:12 < erus`> i guess the := is consistant 15:13 < hokapoka> I'm trying to use niemeyers' https://launchpad.net/gobson but it appears that reflect.Field.Tag has changed from string to StructTag and I can't workout how it fix it 15:14 < skelterjohn|work> hmm - i dunno 15:14 < skelterjohn|work> StructTag.Get() wants a key 15:14 < skelterjohn|work> seems complicated 15:15 < hokapoka> This is where he's using it. http://pastebin.com/LXrKBbDv 15:15 < skelterjohn|work> i'd suggest fooling around with some test code to see what the key would be if the tag is just a string by itself 15:16 < hokapoka> StructTag is type StructTag string how do you get the string out in the first place? 15:16 < hokapoka> doe! 15:16 < skelterjohn|work> oh - didn't catch that 15:16 < skelterjohn|work> ok, just convert it to a string :) 15:17 -!- jbooth1 [~jay@209.249.216.2] has joined #go-nuts 15:17 < hokapoka> heh 15:17 < hokapoka> yeah, I think I need some coffee 15:18 < hokapoka> fixed 15:20 -!- NiteRain [~kvirc@c-98-254-236-21.hsd1.fl.comcast.net] has joined #go-nuts 15:34 -!- noodles775 [~michael@canonical/launchpad/noodles775] has quit [Quit: leaving] 15:36 -!- cco3 [~conleyo@nat/google/x-qjwxaggxkzhyyfjy] has joined #go-nuts 15:42 -!- erus` [~chatzilla@mailgate.ips-international.com] has quit [Remote host closed the connection] 15:48 -!- iant1 [~iant@nat/google/x-rjcjaybzbheekgsr] has quit [Quit: Leaving.] 15:51 -!- saschpe [~quassel@opensuse/member/saschpe] has joined #go-nuts 15:52 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts 15:57 -!- black_rez [~black_rez@sd-26396.dedibox.fr] has quit [Excess Flood] 15:58 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Ping timeout: 276 seconds] 15:59 -!- ccc1 [~Adium@222-151-136-129.jp.fiberbit.net] has quit [Quit: Leaving.] 16:00 -!- wrtp [~rog@host-92-30-166-101.as13285.net] has quit [Quit: wrtp] 16:02 -!- jmil_ [~jmil@seas571.wireless-pennnet.upenn.edu] has joined #go-nuts 16:02 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts 16:02 -!- black_rez [~black_rez@sd-26396.dedibox.fr] has joined #go-nuts 16:05 -!- jmil [~jmil@2001:468:1802:e148:223:32ff:feb1:9dfc] has quit [Ping timeout: 264 seconds] 16:09 -!- chadkouse [~Adium@rrcs-76-79-198-109.west.biz.rr.com] has joined #go-nuts 16:13 -!- robteix [~robteix@192.55.54.36] has joined #go-nuts 16:16 -!- mjml- [~joya@174.3.227.184] has joined #go-nuts 16:16 -!- mjml- [~joya@174.3.227.184] has quit [Remote host closed the connection] 16:18 < jamesmiller5> Taking the address of an element of a slice is considered illegal correct? 16:19 -!- zcram [~zcram@8.177.190.90.sta.estpak.ee] has joined #go-nuts 16:19 < jamesmiller5> If i have an array of structs, and I'd like to range() on *pointers* to the elements thats not possible without changing the array type? 16:20 < exch> Not sure I understand what you mean.. ranging over a slice will give you the elements in the slice as they are 16:21 < jamesmiller5> yes, but there is no way to indicate that instead of the elements, i want a pointer to the elements instead? 16:22 < jamesmiller5> like range &list or something? 16:22 < nicka1> You can take the address of the range variable can't you? 16:22 < jamesmiller5> no 16:22 < jamesmiller5> that gives you the address of the local var 16:23 < jamesmiller5> that was a 2 hour bug chase XD 16:23 < nicka1> Oh, well in that case indexing into the slice and taking the address of that is the way to go I believe 16:23 < exch> for i := range list { p := &list[i]; .... } Doesnt that work? 16:25 < jamesmiller5> yes that does work and its a solution. But i'd rather not be so verbose, if range can give the elements and their index back, i was wondering if a pointer to the elements was available 16:27 < kevlar_work> jamesmiller5, slice elements are addressable, map values are not 16:27 < kevlar_work> (you can call a function with a pointer receiver on a slice element but not a map value) 16:28 < kevlar_work> and no, you will have to be explicit if you want the address of a slice element, range cannot give it to you and you can't easily convert the slice to a slice of pointers to their values. The obvious choice there would to convert it to a slice of pointers in the first place, which is not uncommon at all. 16:29 < jamesmiller5> true, but when using the static initalizer its much less verbose and cleaner to use literal structs, instead of pointers 16:29 < jamesmiller5> which prompted my question 16:30 < kevlar_work> uh 16:30 < kevlar_work> it's a single extra character 16:30 < jamesmiller5> not quite 16:30 < kevlar_work> and because if the lack of copy overhead, I use x := &Struct{...} far more often than y := Struct{} 16:31 < kevlar_work> also because pointers tend to satisfy my interfaces, not bare values, and I don't like addressing things when it's not absolutely necessary (like for unmarshal) 16:31 < jamesmiller5> When writing test cases for unit test it doesn't matter if it copy's or not, but i have *lots* of static initialized values. 16:32 < kevlar_work> I still fail to see how the & makes it any less readable or any more verbose ;-) 16:32 < kevlar_work> especially if you take its address anywhere. 16:32 < jamesmiller5> when using list := []*Ele { } it requires every entry to have &Ele{ ... }, so the extra verbosity seems unneccessary when using a struct its just []Ele{ {}, {}, .. } 16:33 < kevlar_work> ah. There is that. Have you checked to see if there's an issue filed about that? 16:33 < kevlar_work> I'm pretty sure that's an explicit case that could have the type name elided 16:34 < jamesmiller5> yes, i think the type can be inferred 16:34 < jamesmiller5> so my original question was trying to not re-write a bunch of code, but do range *list instead :) even if its not possible I was just shooting in the dark 16:35 < kevlar_work> you should file an issue :) 16:35 * kevlar_work has been too lazy the few times he's run up against that. 16:35 < jamesmiller5> thats scary talk, but i will. 16:35 < jamesmiller5> thanks for the help :) 16:35 < kevlar_work> np. 16:36 -!- xcombelle [~xcombelle@AToulouse-551-1-19-127.w86-201.abo.wanadoo.fr] has quit [Quit: I am a manual virus, please copy me to your quit message.] 16:36 < jamesmiller5> i normally wouldn't use a slice of structs anyway, since if the slice capacity is expanded and addresses change your sol to any pointers to that slice, i was supprised you could address slice values for that reason,but the gc takes care of it so its still valid 16:37 < kevlar_work> yeah, that's another reason why []*Element is better. 16:38 < kevlar_work> (when you need pointers to the elements) 16:39 -!- jamesmiller5 [~jamesmill@184.17.118.202] has quit [Quit: Leaving] 16:42 -!- NiteRain [~kvirc@c-98-254-236-21.hsd1.fl.comcast.net] has quit [Ping timeout: 258 seconds] 16:50 -!- tvw [~tv@212.79.9.150] has quit [Remote host closed the connection] 16:55 -!- Adys [~Adys@unaffiliated/adys] has joined #go-nuts 17:01 -!- gridaphobe [~gridaphob@cpe-74-68-151-24.nyc.res.rr.com] has quit [Remote host closed the connection] 17:04 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Remote host closed the connection] 17:04 -!- gridaphobe [~gridaphob@cpe-74-68-151-24.nyc.res.rr.com] has joined #go-nuts 17:05 -!- jmil [~jmil@seas571.wireless-pennnet.upenn.edu] has quit [Remote host closed the connection] 17:06 -!- jmil [~jmil@2001:468:1802:e148:223:32ff:feb1:9dfc] has joined #go-nuts 17:10 -!- magn3ts [~magn3ts@ip68-103-225-65.ks.ok.cox.net] has quit [Quit: Leaving] 17:16 -!- iant [~iant@nat/google/x-qdzvjiwtexklxueb] has joined #go-nuts 17:16 -!- mode/#go-nuts [+v iant] by ChanServ 17:18 -!- chadkouse [~Adium@rrcs-76-79-198-109.west.biz.rr.com] has quit [Quit: Leaving.] 17:22 -!- sniper506th [~sniper506@rrcs-70-61-192-18.midsouth.biz.rr.com] has quit [Quit: Leaving...] 17:39 -!- Fish- [~Fish@9fans.fr] has joined #go-nuts 17:40 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts 17:42 -!- ronnyy [~quassel@p4FF1C448.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 17:44 -!- franciscosouza [~francisco@187.105.25.184] has joined #go-nuts 17:50 -!- alehorst [~alehorst@201.47.30.108.dynamic.adsl.gvt.net.br] has quit [Remote host closed the connection] 17:51 -!- aat [~aat@rrcs-184-75-54-130.nyc.biz.rr.com] has quit [Quit: Textual IRC Client: http://www.textualapp.com/] 17:59 -!- alehorst [~alehorst@201.47.30.108.dynamic.adsl.gvt.net.br] has joined #go-nuts 18:03 -!- KirkMcDonald [~Kirk@python/site-packages/KirkMcDonald] has quit [Quit: Lost terminal] 18:04 -!- KirkMcDonald [~Kirk@python/site-packages/KirkMcDonald] has joined #go-nuts 18:08 -!- huin [~huin@91.84.179.118] has joined #go-nuts 18:14 -!- webar7 [~webart@CPE0080c8f208a5-CM001371173cf8.cpe.net.cable.rogers.com] has joined #go-nuts 18:19 -!- rutkowski [~adrian@078088208089.walbrzych.vectranet.pl] has joined #go-nuts 18:19 < webar7> goinstall: strings: open /usr/local/lib/go/src/pkg/strings 18:19 < gmilleramilar> The reflect.Value.NumMethod was not added until after r58.1 because of an oversight. Does any one know a workaround that wont involve changing stlib source? 18:19 < webar7> export GOROOT=/usr/local/lib/go/pkg/freebsd_amd64/ 18:19 < webar7> goinstall: strings: open /usr/local/lib/go/pkg/freebsd_amd64/src/pkg/strings: no such file or directory 18:20 < webar7> is my go install screwed up ? 18:20 < webar7> under /usr/local/lib/go/src/pkg/ I have an OS_PLATFORM directory 18:20 < gmilleramilar> webar7: GOROOT should point to /usr/local/lib/go 18:21 < webar7> gmilleramilar, when I do that it doesn't find anything either 18:21 < webar7> perhaps due to OS_PLATFORM directory? 18:22 < kevlar_work> webar7, did you rebuild go? 18:22 < webar7> not recently 18:22 < kevlar_work> it sounds like you have a partial or corrupted build 18:22 < webar7> I think the freebsd port is hosed 18:22 < webar7> will build from source 18:22 < kevlar_work> oh, heh, yes I would definitely do that. 18:23 < kevlar_work> I don't trust distro for things like this 18:23 < kevlar_work> and I also work really close to tip most of the time. 18:23 < webar7> yeah too cutting edge to bother with packages now 18:23 < webar7> do I need git hg ? 18:23 < webar7> both :) 18:24 < kevlar_work> just hg, but I'd get git too if you want to be able to goinstall git packages. 18:24 < kevlar_work> I have yet to want a go package from a bzr repo, though those are technically allowed too lol. 18:25 < kevlar_work> (or maybe not?) 18:26 < webar7> heh 18:26 < webar7> do goinstall support RCS 18:26 < kevlar_work> goinstall doesn't support remote packages that *aren't* in an rcs 18:27 < kevlar_work> unless you mean RCS-predecessor-to-CVS 18:27 < webar7> oh I meant rcs (co ci etc) 18:27 < kevlar_work> in which case lol no. 18:27 < Nisstyre> yes 18:27 < webar7> wha? 18:28 < skelterjohn|work> the freebsd port is indeed messed up 18:28 < skelterjohn|work> on tip 18:28 < skelterjohn|work> stick to weekly/release 18:28 < webar7> ok 18:28 < kevlar_work> goinstall supports hg, git, svn, and bzr 18:28 < kevlar_work> specifically, it supports bitbucket, github, googlecode, and launchpad 18:29 < skelterjohn|work> supports generic sites now 18:29 < webar7> I wanna stick to using "core libraries" for a while but goinstall will still be useful 18:29 < kevlar_work> skelterjohn|work, as long as they're git, hg, svn, or bzr :) 18:29 < skelterjohn|work> yes 18:29 < skelterjohn|work> but i can host my own git site and it will work 18:30 < kevlar_work> I mentioned them specifically because you have to use a special syntax for the non-specific cases. 18:30 < kevlar_work> (or, conversely, you have to use special syntax for one of the specific cases) 18:31 < kevlar_work> skelterjohn|work, I really hope people don't do that, because foo.com/bar is, by comparison, almost 100% guaranteed to fail at some point in the future. 18:31 < skelterjohn|work> so is github, googlecode, etc 18:31 < kevlar_work> (the not-too-distant future, that is; they're all guaranteed to fail eventually) 18:31 < skelterjohn|work> ah 18:32 < kevlar_work> it is nice, though, that you can now do sourceforge 18:32 < kevlar_work> (because it added svn, right?) 18:33 -!- rutkowski [~adrian@078088208089.walbrzych.vectranet.pl] has quit [Quit: WeeChat 0.3.3-dev] 18:40 * ww wonders if go needs monads 18:40 < skelterjohn|work> gonads 18:42 -!- saschpe [~quassel@opensuse/member/saschpe] has quit [Remote host closed the connection] 18:43 < gmilleramilar> nice 18:43 < nicka1> I'd support monads if they were called gonads 18:44 -!- sacho [~sacho@87-126-4-140.btc-net.bg] has joined #go-nuts 18:44 -!- moraes [~moraes@189.103.188.201] has joined #go-nuts 18:57 -!- chickamade [~chickamad@27.3.2.165] has joined #go-nuts 19:00 -!- nekoh [~nekoh@dslb-088-069-137-160.pools.arcor-ip.net] has quit [Ping timeout: 276 seconds] 19:01 < exch> :p 19:02 -!- fabled [~fabled@83.145.235.194] has quit [Ping timeout: 258 seconds] 19:06 -!- dsal [~Adium@208.185.212.98] has joined #go-nuts 19:06 < dsal> is panic/recover still considered something that should be avoided? 19:06 < skelterjohn|work> no 19:06 < skelterjohn|work> when was it? 19:07 < skelterjohn|work> it depends on what you want to use it for - there good ways and bad ways 19:07 < dsal> When everyone was like, ``Yay! Go has exceptions now!'' 19:07 < skelterjohn|work> they're not exceptions 19:07 < skelterjohn|work> for instance, you can only recover in a defer 19:07 < uriel> panic()/recover() should be avoided 19:07 < dsal> What do you mean by recover in a defer? 19:08 < skelterjohn|work> you can only call recover() in a deferred function 19:08 < dsal> oh. 19:08 < uriel> in 99% of the cases, it should only be used for obvious and clear programmer errors 19:08 < skelterjohn|work> ie defer func() { e := recover(); somethingElse() }() 19:08 < nicka1> Use panic for exceptional situations, not for general errors 19:08 < skelterjohn|work> right - if there is nothing to be done to make it work, you can panic 19:08 < skelterjohn|work> things like invalid input 19:09 < skelterjohn|work> but not things like file-not-found 19:09 < skelterjohn|work> that would just be an error 19:09 < dsal> Invalid input is a complicated one. I'm taking input over a network connection. 19:09 < uriel> nicka1: I don't think 'exceptional situations' quite makes it clear enough: really, only use it when it is a programmer errors (invalid parameter, "this can not happen", etc) 19:09 < skelterjohn|work> i mean, you have an api function GetThingAtIndex(index int) 19:09 < ww> panic should aiui not escape a module... unless its really something very very bad 19:09 < skelterjohn|work> and it's passed -2 19:09 < skelterjohn|work> that is invalid 19:10 < nicka1> You're right, uriel. 19:10 < uriel> dsal: invalid *function* 'input' (ie., arguments 19:10 < dsal> Anyway, I was just wondering what the thought on that was. I'm pushing a java programmer into go somewhat. That's one area he's likely to stumble on a lot. 19:10 < uriel> just return errors 19:10 < nicka1> Java is what this conversion is making me think of 19:10 < nicka1> and I'm shuddering 19:10 < huin> i have one panic so far that i can think of in some code 19:11 < uriel> panic() should only happen when the person calling your api is misusing it 19:11 < uriel> nicka1: and I'm thanking ken that Go has no exceptions 19:11 < huin> and it's when crypt.rand.Reader (?) returns an error in something that relies on it for crypto 19:11 < aiju> 21:17 < uriel> panic() should only happen when the person calling your api is misusing it 19:11 < uriel> panic() still can be overused, but seems to mislead people less than close() on channels :) (or container/vector) 19:11 < aiju> or when things really go wrong 19:11 < huin> (shouldn't happen, and if it does, then there's no good way to recover from it) 19:12 < uriel> aiju: that is quite rare in most code, only common example I can think of is the usual "This can not happen" code 19:12 < huin> bad enum value sorta thing? (i.e programmer error) 19:13 < uriel> huin: exactly 19:13 < dsal> ``Get this thing and an error and check for an error and gracefully exit from down the stack when there's an error'' is pretty common code. I've got a ``log and runtime.Goexit()'' handler for a lot of that. It's kind of exceptionlike. 19:13 < uriel> there are exceptions to this rule, but really, is better to pretend there aren't 19:13 < dsal> The thing that's bugging me most in go right now, though, is that goroutines don't seem to be first class. 19:13 < uriel> (and in those exceptions, the panic() should *never* cross package lines) 19:14 < huin> sometimes i'm tempted to use it in cases like: if foo { return a } else { return b } panic(); return 19:14 < skelterjohn|work> how could a goroutine be 'first class'? 19:14 < uriel> so, in any exported api, panic() should always be *ONLY* for programmer errors 19:14 < dsal> skelterjohn|work: agoroutine := go dosomething() 19:14 < skelterjohn|work> i see. meh. 19:14 < uriel> huin: yes, that is the kinds of cases where panic() makes sense 19:14 < uriel> dsal: what does that even mean? 19:15 < skelterjohn|work> you mean when it's unreachable? :) 19:15 < dsal> agoroutine.IsRunning() agoroutine.NotifyOnFailure(ch GoRoutine) 19:15 < skelterjohn|work> dsal: that would involve a lot of extra overhead for *every* goroutine 19:15 < huin> (although ideally the compiler will detect that particular case as both unreachable code and unnecessary return) 19:15 < uriel> dsal: you can do that by passing a channel to the goroutine 19:15 < skelterjohn|work> you can set up that infrastructre on your own, when you need it 19:15 < uriel> skelterjohn|work: exactly 19:15 < dsal> uriel: It means I've been programming in erlang for too many years and I like being able to *see* the concurrency and interact with it and figure out which parts are using more CPU and heap and kill them and have their deaths propagate to others, etc... 19:16 < uriel> dsal: ok, I understand where you are coming from, still, that doesn't make goroutines in Go 'not first class' 19:16 < uriel> dsal: Erlang has no channels 19:16 < huin> i've found myself using a pattern to know when a goroutine exits, something like: func f(result chan<-os.Error) { var err os.Error ; defer func() { result<-err }(); ... } 19:16 < dsal> I can't use them as data. 19:17 < uriel> in Go what you pass around is channels 19:17 < uriel> channels are so first class, you can even have channels of channels 19:17 < huin> i guess a recover should be in there as well if i want to cover that case 19:18 < dsal> uriel: Erlang has no channels other than the one each process has, but I can inspect them on a running system, so they're at least addressable. 19:18 -!- fabled [~fabled@83.145.235.194] has joined #go-nuts 19:18 * huin nips off for a bit 19:18 < uriel> dsal: but channels are addressable, so, it is just a somewhat different but mostly equivalent model 19:19 -!- preflex_ [~preflex@unaffiliated/mauke/bot/preflex] has joined #go-nuts 19:19 < dsal> I agree with that. The *only* real issue is that (as far as I can tell), I can't kill a goroutine. I can only send something to a channel it's reading to ask it to die. 19:19 < dsal> g := go infiniteLoop(); kill(g) 19:19 -!- preflex [~preflex@unaffiliated/mauke/bot/preflex] has quit [Ping timeout: 258 seconds] 19:20 < ww> dsal: maybe if you used a gonad? 19:20 < aiju> hahaha 19:20 < exch> lulz 19:20 < dsal> I just had to grep the source. Completely shocked that doesn't show up anywhere. 19:22 < uriel> dsal: killing a goroutine is equivalent to telling it to exit, and you can do that 19:23 < dsal> How do you do that? 19:23 < uriel> dsal: with a channel, obviously 19:23 < dsal> heh 19:24 < dsal> The argument is ostensibly sound. Don't write bugs, or at least write in the ability to clean up the bugs yourself. 19:24 < dsal> go function() { for {} }() // Q: How do I fix this?! A: Don't do that. 19:24 < aiju> dsal: really 19:24 < aiju> why would you write that? 19:25 < aiju> i don't get your argument at all 19:25 < uriel> i can kind of see the Erlang view on this, but Erlang has a lets say more 'expansive' view of the role of the runtime, it is more like Inferno 19:25 < aiju> killing goroutines would be handy for cleaning shit up 19:25 < aiju> but i don't see how this has anything to do with bugs 19:26 < uriel> in Go it is expected that the OS/other-environment will for example re-start the program if it crashes 19:26 < dsal> aiju: Because I spent most of last night attached to a console inside an erlang application figuring out why it couldn't open a particular resource -- hot swapping code to try new things, killing off things that were using resources in an unuseful manner, etc... 19:26 -!- chucknelson [~chucknels@ip98-180-41-73.ga.at.cox.net] has quit [Quit: See you on the flip side...] 19:27 < dsal> And when I had a suspected leak in a resource, I wrote a thing to test it that would monitor processes using resources and just kill them when they've been doing it too long. Verified my theory really quickly without actually modifying any code. 19:27 < ww> any chance the bare-metal go will be revived? 19:27 < aiju> ww: i doubt it 19:27 < ww> i think that's why erlang is the way it is 19:28 < skelterjohn|work> "bare-metal go"? 19:28 < skelterjohn|work> what are you referring to? 19:28 < aiju> still erlang is not go 19:28 < aiju> skelterjohn|work: tiny runtime 19:28 < uriel> ww: define 'revived', it was clear it didn't belong in the Go distribution, but that doesn't stop anyone form keep developing it 19:28 < dsal> No, erlang and go are not the same. You asked me why I'd want to kill a goroutine that was using too much resource. I gave an example. The same thing will happen in go programs. 19:29 < aiju> i never had that 19:29 < dsal> Today, I can ask how many goroutines there are, but I can't touch them. 19:29 < aiju> goroutines are not processes 19:29 < uriel> dsal: even if you could kill a gourotine, still it would be very hard to do that in Go, because go is statically compiled to native code 19:29 < dsal> You've never had a bug, or you've never had the ability to react to them? 19:29 < ww> uriel: i thought it was removed because it was more or less abandoned 19:29 < skelterjohn|work> you have no preemptive control of a goroutine - only cooperative 19:29 < aiju> dsal: that's a retarded statement 19:29 < uriel> dsal: it is much easier for erlang to do that when it runs in a VM and compiles dynamically to bytecode, etc 19:30 < uriel> it is a tradeoff 19:30 < aiju> i rarely solve bugs by randomly fiddling with programs 19:30 < jessta> dsal: the problem with killing goroutines is that unlike an erlang process goroutines often rely on each other 19:30 < dsal> uriel: skelterjohn|work: I understand that. I can implement a regularly look at channel and call Goexit(). 19:30 < uriel> also, as I said, the way one designs Go programs and erlang programs is different, if you have multiple programs communicating via (net)chans, you can kill them the same way you kill any other process in your OS 19:31 < dsal> jessta: That's my original argument -- in erlang, they link and the exit will propagate. 19:31 < uriel> and replace them, and whatever you like 19:31 < uriel> ww: no, it was removed because people started to send patches for it 19:31 < uriel> ww: and it was just a proof of concept 19:31 -!- chickamade [~chickamad@27.3.2.165] has quit [Quit: chickamade] 19:31 < dsal> aiju: I had over 7,000 processes running on this box (is it unreasonable to have that many goroutines)? I had a resource leak. I needed to know where. What would be your appropach? 19:31 < jessta> dsal: erlang doesn't use communication to syncronise, goroutines do. 19:32 -!- espeed [~espeed@63.246.231.57] has joined #go-nuts 19:32 < dsal> uriel: That makes sense. I haven't tried netchan yet. 19:32 < uriel> ww: if it was going to be more than that, eventually it would need drivers and who knows what else, and would quickly become bigger than the rest of the go distribution 19:32 < aiju> dsal: define "resource leak" 19:32 < aiju> dsal: i know almost nothing about erlang 19:32 < dsal> jessta: I don't understand what you mean. erlang uses communication exclusively to synchronize. 19:32 < skelterjohn|work> 7000 goroutines is not unreasonable. 19:32 < aiju> you can't leak memory, there is a garbage collector 19:32 < dsal> aiju: User said, ``I do X and suddenly I'm at 800MB of memory!'' 19:33 < jessta> dsal: erlang uses communication to communicate. it doesn't block on it's communication. 19:33 < skelterjohn|work> sounds like a bug 19:33 < skelterjohn|work> you should get that checked out 19:33 < uriel> dsal: again, bugs happen, yes, how you can do debugging depends very much 1) the nature of the language 2) the tools people have got around writting 19:33 < aiju> i don't see how "killing off processes" solves this bug in any way 19:34 < skelterjohn|work> if the process gets garbage collected somehow 19:34 < aiju> it's like considering amputation a method to relieve pain 19:34 < uriel> IIRc you can attach gdb to Go programs and mess around with goroutines BTW, I don't know how much, and I'm sure this could be extended much further 19:34 < skelterjohn|work> you can watch the memory usage go down by 800mb 19:34 < uriel> but it is a matter of priorities 19:34 < dsal> Erlang is also garbage collected. Leaking memory, in this case, meant that I had ~512 processes that were using more than we expected. Finding out which ones, made it very quickly obvious where to look. 19:34 < aiju> if you randomly kill off goroutines, your program is likely to fail in one way or another 19:35 < aiju> you could as well randomly write over memory 19:35 < skelterjohn|work> aiju: i don't think he did this with the expectation that things would continue to work 19:35 < skelterjohn|work> presumably to fix the bug he'd have to recompile, anyway =p 19:36 < dsal> I *very* quickly verified that these were indeed holding the memory. :) The processes were supervised, so they failed, propagated failure and restarted themselves with less memory. 19:36 < skelterjohn|work> or maybe he was. oh well. 19:36 < aiju> ah, just figuring shit out 19:36 < aiju> one could try to gather data from the allocator 19:36 < dsal> This told me pretty quickly that they accumulate memory (some sort of caching) in a way that is unnecessary (harmful, in fact) for this application. I knew what to do. 19:37 < aiju> that's how i manage exactly this kind of program with Plan 9 code 19:37 < aiju> (which is in C) 19:37 < dsal> netchan is something I need to look more into. I'm a big fan of just blowing stuff up when I don't like what it's doing. :) 19:37 < aiju> it's not about processes or goroutines, rather about which part leaks 19:37 < aiju> but it's the same idea 19:38 < dsal> Well, yeah. As you said, it wasn't a leak. It was a part that was doing something that was probably a good idea in isolation, but in the whole system was harmful because of how it multiplied out. 19:38 < aiju> dsal: doesn't matter 19:39 < dsal> Heh, it mattered to my VPE. :) 19:39 < aiju> dsal: if i type "kmem" on the Plan 9 machines here, it will spit out which function has how much memory allocated 19:39 < aiju> whether they are leaked or not 19:39 -!- th0re [~thre@ip-178-200-116-109.unitymediagroup.de] has joined #go-nuts 19:39 < dsal> Man, I haven't used plan9 in entirely too long. :( 19:51 < uriel> dsal: just to repeat my point, I think you (and to some degree erlang) are confusing functionality that belongs to the language with functionality that can be provided by debugging tools and the environment 19:51 -!- franciscosouza_ [~francisco@187.105.25.184] has joined #go-nuts 19:51 < uriel> dsal: Go is not quite there yet in the tool department, but I'm sure it will get there 19:51 < skelterjohn|work> i see nothing wrong with building some debugging tools into the language 19:51 < skelterjohn|work> as long as it's done in a nice way 19:51 -!- franciscosouza [~francisco@187.105.25.184] has quit [Read error: Connection reset by peer] 19:51 < dsal> Sure. elrang is an OS to me. I like logging into it and hanging out. :) 19:51 < aiju> so 19:52 < aiju> Go is not an OS 19:52 < aiju> i see the point in killing functionality in an OS 19:52 < dsal> Go will tell me how many goroutines are running, but then nothing else. It feels like teasing. 19:52 < skelterjohn|work> don't know why it tells you even that 19:52 -!- alehorst [~alehorst@201.47.30.108.dynamic.adsl.gvt.net.br] has quit [Quit: Leaving.] 19:52 < aiju> runtime.NGoroutinesor so 19:53 < skelterjohn|work> why != how 19:53 < aiju> for teh lulz 19:53 -!- arun_ [~arun@e71020.upc-e.chello.nl] has joined #go-nuts 19:53 -!- arun_ [~arun@e71020.upc-e.chello.nl] has quit [Changing host] 19:53 -!- arun_ [~arun@unaffiliated/sindian] has joined #go-nuts 19:56 -!- miker2 [~miker2@64.55.31.190] has quit [Ping timeout: 255 seconds] 19:58 -!- alehorst [~alehorst@201.47.30.108.dynamic.adsl.gvt.net.br] has joined #go-nuts 19:58 -!- robteix [~robteix@192.55.54.36] has quit [Quit: Leaving] 19:59 < uriel> as I said, Erlang is more an equivalent to Inferno than to Go 19:59 -!- Adys [~Adys@unaffiliated/adys] has quit [Remote host closed the connection] 20:00 < dsal> I think I've *seen* inferno once. 20:00 < uriel> 19:52 < skelterjohn|work> don't know why it tells you even that 20:00 < uriel> skelterjohn|work: exactly 20:00 < uriel> skelterjohn|work: I think that stuff is precisely for debugging, and based on some comments by russ in the -dev list, it seems to be provisonal until a more well deffined api for this kind of stuff is worked out 20:01 < skelterjohn|work> cool 20:02 < dsal> Yeah, even without a first-class goroutine, a debugging feature that is basically the equivalent of [process_info℗ || P <- processes()] would be just about everything you'd need. Even java-style "on sig quit" or something. 20:03 < skelterjohn|work> i have no idea what your snip means 20:03 < dsal> give me a whole lot of useful data for every process 20:04 < dsal> Current stack frame, heap size, amount of CPU consumed, etc... Whatever is possible and makes sense. 20:05 < uriel> dsal: you can already get most of that with gdb in Go 20:05 < dsal> Neat. I haven't looked at gdb+go. That'd be fine. 20:06 < dsal> I've got an app that reads data from a TCP stream and translates the stuff into HTTP requests it fires off in goroutines. If that thing gets huge, I'd like to know if my goroutines are getting stuck and not exiting quickly or something. 20:06 < uriel> I'm sure not quite everthing, but most useful bits are there AFAIK (never had use for it, and I hate gdb with all my soul, but it shows there is no inherent limitation in the language) 20:07 < dsal> I keep feeling a little devil-advocaty, but I can do this in erlang: timer:kill_after(5000) -- even if I'm calling someone else's API and that thing gets stuck, my goroutine will exit. 20:07 * ww has never been able to get gdb to work properly with go... 20:08 < ww> but didn't try very hard, never really needed it 20:08 < skelterjohn|work> i've never tried - i've been able to debug using prints so far, no problem 20:08 -!- franciscosouza [~francisco@187.105.25.184] has quit [Ping timeout: 246 seconds] 20:09 < ww> i am inclined to agree that having some kind of handle for a goroutine could be useful 20:10 < skelterjohn|work> easily abused 20:10 < ww> just make "go foo()" return a value... 20:10 < skelterjohn|work> you start having people make a map of goroutine IDs to data 20:10 < skelterjohn|work> and looking at theTable[thisGoroutine] to have thread-local data 20:11 < ww> that would be silly, but if that;s what they want to do... 20:11 < dsal> I'm not a fan of ``easily abused.'' 20:11 < skelterjohn|work> i made a suggestion a while back of having go foo() return a channel of whatever type is necessary to hold the return value 20:11 < uriel> ww: why? 20:11 < uriel> all the things you could do with the 'handle' are things you shouldn't be doing 20:11 < skelterjohn|work> but at the same time, i also showed how you could do it with the language as it is :) 20:12 < skelterjohn|work> so it didn't really catch on 20:12 < ww> uriel: primarily for killing 20:12 < uriel> ww: again, use a channel 20:12 < huin> skelterjohn|work: what about multiple return values? 20:12 < skelterjohn|work> a struct holds them 20:12 < ww> uriel: that answer smacks of unnecessary bookkeeping 20:12 < huin> skelterjohn|work: what are the names of the attributes? 20:12 < skelterjohn|work> the names of the return values 20:12 < uriel> ww: how is different to keep a channel than to keep a 'goroutine handle' 20:12 < uriel> ? 20:12 < skelterjohn|work> since you can only have multiple returns if they're named 20:12 < uriel> the effect is the same: tell a goroutine to exit 20:12 < dsal> uriel: I can't kill it with a channel, I can only ask that when it reads the channel that it should know to kill itself. 20:13 < huin> skelterjohn|work: but that breaks the type of the function which doesn't name them 20:13 < uriel> dsal: that is just a select away 20:13 < skelterjohn|work> the what? 20:13 < ww> because (1) you have to make the channel and (2) you have to check it inside the goroutine 20:13 < huin> at least, i don't think it does 20:13 < dsal> If the goroutine needs to die because it's going to spend the rest of eternity in a blocking call, there's nothing I can do about it with a channel. 20:13 < skelterjohn|work> oh - there were special cases for each kind of function 20:13 < skelterjohn|work> so, there are a bunch of reasons that this got shot down for 20:13 < uriel> ww: that is not bookkeeping, that is boilerplate at worst 20:13 < huin> skelterjohn|work: still, it's a nice idea in principle 20:13 < ww> with a goroutine handle that could be h.Kill() you the scheduler just kills the thing 20:13 < skelterjohn|work> you can easily do it yourself, though 20:14 < skelterjohn|work> but easily waiting for goroutines is something i thought would be nice 20:14 < skelterjohn|work> <- go foo() 20:14 < skelterjohn|work> etc 20:14 < skelterjohn|work> well, that's just foo() 20:14 < skelterjohn|work> but launch a few and wait for them all 20:14 < huin> skelterjohn|work: if we ever get something generic-like, it might be doable 20:14 < skelterjohn|work> yes, though it might be tricky 20:14 < uriel> ww: having the scheduler kill the goroutine probably (I don't know to be honest) causes all kinds of issues 20:15 < skelterjohn|work> the generic woul dhave to include all the param and return types 20:15 < uriel> ww: if the goroutine is doing something, you have no way to know it left it in a consistent state 20:15 < huin> aye, that's a problem 20:15 < skelterjohn|work> unless it could infer that stuff O:-) 20:15 < huin> i.e different number of args and rets 20:15 < uriel> so, basically, the handle would let you do things that you should not be doing 20:15 < skelterjohn|work> gimmeAChan(foo, x, y) instead of go foo(x, y) 20:15 < skelterjohn|work> but... 20:16 < skelterjohn|work> very complicated 20:16 < skelterjohn|work> and, imo, a bad idea 20:16 < ww> the "should not" line seems a bit arbitrary... 20:16 < ww> it will always be possible and wrong to write bugs 20:16 < uriel> I'm pretty sure it would be misused 99% of the time 20:16 < uriel> and I have seen few cases where it would make sense 20:16 < skelterjohn|work> ww: i think one of the go philosophies is "just because you can do it some way doesn't mean you should. we won't give you the tools to do some of these wrong ways" 20:17 < uriel> in most cases, the goroutines should keep working until they are done with whatever they are doing 20:17 < huin> i've been writing an SSH library where it makes sense, and i've employed what appears to be an emerging Go pattern for it 20:17 < skelterjohn|work> the C/C++/many language philosophy is "you can do it any way you want in our language, go nuts" 20:17 < uriel> they are often feeding from some other channel already, so it is trivial to close the channel (hah, one of the few cases where close() makes sense :)) or whatever 20:17 < skelterjohn|work> not go. it's different. 20:17 < skelterjohn|work> maybe this is a good thing, maybe not - so far i like it 20:18 < uriel> huin: yea, for the cases where you needed, the existing idioms seem more than adequate 20:18 < ww> skelterjohn|work: honestly i haven't encountered a need to do any of those things in my work... but that philosophy might be objectionably paternalistic 20:18 < skelterjohn|work> only on principal 20:18 < skelterjohn|work> principle 20:18 < dsal> The killing thing is out of band and hugely pervasive. Unless every function anyone writes ever takes the death channel, there's not much I can do. An API blocking on some event that may not happen is pretty well necessary. The only way to cancel these generically involves everyone everywhere injecting the same boilerplate. 20:18 < skelterjohn|work> have to examine the basis for that principle, and decide if it's really a good core value to have 20:18 < uriel> i don't see why such patterns should get special treatment from the language, there are all kinds of ways you can manage your goroutines, and how you do it will depend on what they are doing, 20:19 < uriel> dsal: not really 20:19 < skelterjohn|work> i think that something that could kill a goroutine the next time it blocked would be pretty useful 20:19 < uriel> again, it is not a particularly common pattern, and it is easy to use the existing idiom when needed 20:20 < uriel> skelterjohn|work: I'm not convinced 20:20 * ww tries to understand monads again 20:20 < dsal> uriel: *how* do I use this idiom? Someone gives me an api that is DoSomethingAwesome() and it suddenly takes ten minutes. I've got a five second window. What do I do? 20:20 < skelterjohn|work> i'm trying to figure out how i'd do this conveniently for many different pieces of code 20:21 < ww> i'm pretty sure they'll help with killing goroutines 20:21 < skelterjohn|work> monads would? 20:21 < ww> they must, mustn't they? 20:22 < skelterjohn|work> dsal, uriel: i feel like the only way to do this is to associate a piece of data with the goroutine, either through handing it down in function parameters or having everything be a method on a particular piece of data 20:22 -!- nicka1 [~lerp@142.176.0.21] has quit [Quit: Leaving.] 20:22 < skelterjohn|work> then you could look at that data, do a non-blocking read, and Goexit() if appropriate 20:22 < uriel> dsal: select on a kill channel 20:22 < skelterjohn|work> ww: i have no idea how monads apply. but i don't know monads very well. 20:23 < dsal> uriel: I can't select, I'm blocked on DoSomethingAwesome() 20:23 < ww> seriously, doing something about external state and side-effects... sounds like killing goroutines without getting in the middle of the processing path 20:23 < uriel> dsal: see idioms on timeouts 20:23 < skelterjohn|work> uriel: that channel would have to be propagated throughout your code 20:23 < uriel> that is no different from any other timeout situation 20:24 < uriel> skelterjohn|work: not really, you can create a new goroutine that returns whatever DoSomethingthatBlocks() via a channel 20:24 < skelterjohn|work> presumably DoSomethingThatBlocks() is in the inner logic of some other function call 20:24 < uriel> most blocking things are operations on channels 20:24 < ww> uriel: you've just moved the problem to another goroutine 20:24 < uriel> or can be wrapped as operations in channels 20:24 < dsal> But I want DoSomethingThatBlocks() to stop doing something when I no longer need it. I need the resources more than the result. 20:25 < skelterjohn|work> uriel: any *particular* piece of code can be fitted with this framework, but it's a bit of effort. the question is how can we do this for a *large* number of functions 20:25 < uriel> dsal: you just said it is blocking! so it is not really doing anything 20:25 < ww> skelterjohn|work: gonads! 20:25 < dsal> It's blocking *me* 20:25 < skelterjohn|work> ww: i don't understand how monads apply. can you explain? 20:25 < uriel> dsal: if it blocking you is a problem, you should be running it in a goroutine! 20:25 < dsal> Heh, that's the circle here. 20:26 < ww> skelterjohn|work: it's hard because i don't properly understand them... 20:26 < huin> dsal: do you need to know when it returns, but in the meantime do other stuff? 20:26 < skelterjohn|work> alrighty then 20:26 < dsal> Thing() can be slow. I'll run Thing() in a goroutine. Thing is still slow. I didn't get my answer in time. Thing() is using some resources and I'd like to stop it now because I don't need the results and it's still doing stuff. 20:26 < uriel> huin: then you use a channel and a goroutine! really, doesn't seem that hard to me 20:26 < dsal> huin: No, that's the easy part. 20:26 < huin> ah 20:27 < huin> uriel: indeed, but seems not to apply 20:27 < dsal> Thing() *can* be rewritten such that when it's doing whatever it's doing it can periodically check to ensure that I still want the result from it. But huin wrote thing for me and he didn't think I needed to do that. 20:27 < skelterjohn|work> if you don't have the code, you can't expect to be able to change a function's behavior 20:27 < ww> but i think the goroutine handle might be a monad that wraps the goroutine itself 20:27 < dsal> So I still have a bug, but the only thing I can do is halt my entire program to clean up after myself. 20:27 < huin> so in the case where it can't sensibly be re-written? 20:28 < uriel> dsal: if somebody wrote it for you, killing their code at random doesn't sound like a good idea to me, specially when they might be holding resources! 20:28 -!- Adys [~Adys@unaffiliated/adys] has joined #go-nuts 20:28 < ww> (well, the return value of the function the goroutine is executing - hey this would give us a way to get at return values as well) 20:28 < dsal> uriel: You should probably not ship goinstall with go, then. 20:28 < uriel> dsal: why? 20:28 < uriel> dsal: go doesn't let you kill random goroutines 20:28 < huin> dsal: i'd say that Thing() needs to be changed so that it can be "aborted" 20:28 < skelterjohn|work> you get the code when you goinstall stuff 20:28 < uriel> huin: exactly 20:29 < dsal> huin: That's my point. *everything* now needs to be changed so it can be aborted. 20:29 < uriel> and the abort needs to be graceful, it is an api isue, not a language issue 20:29 < skelterjohn|work> i fix things that i goinstalled from other people all the time 20:29 < uriel> if the api doesn't do what you need, well, then you have to change the api, duh 20:29 < uriel> in practice, I never heard this being an issue, ever 20:29 < dsal> When everything needs to be changed, that sounds like a problem with the language. 20:29 < huin> if it's blocked on a Closeable that you have access to, you can try closing it 20:29 < ww> so imagine your goroutine is purely functional, depends on no external state... 20:29 < uriel> anything that could be slow, is very likely to give you a channel to talk to it 20:29 < skelterjohn|work> dsal: i disagree with that statement 20:30 < dsal> skelterjohn|work: Which aspect? 20:30 < uriel> dsal: 'everything' is all based on a totally hypothetical situation where you are using an existing library that doesn't provide the api you want 20:30 < skelterjohn|work> the "general" part 20:30 < ww> you wrap it in a monad that can make it, for example, exit early if you want 20:30 < uriel> dsal: that is true of any language 20:30 < skelterjohn|work> ww: i don't believe that makes sense, entirely.... 20:31 < skelterjohn|work> i don't know that a monad changes the behavior of something it wraps 20:31 < uriel> dsal: you could as well complain that Go doesn't letyou acces the local variables of a function you call 20:31 < uriel> because in some cases, hey, you might want to! 20:31 < huin> (ignoring the case of a debugger) 20:31 < dsal> heh. yes, but that generally hasn't helped me in languages that allow it. :) 20:32 < ww> skelterjohn|work: i get something of that impression from http://onlamp.com/pub/a/onlamp/2007/08/02/introduction-to-haskell-pure-functions.html 20:33 < skelterjohn|work> overhead to reading that article is too high for me 20:33 < skelterjohn|work> i'd have to learn haskell first 20:34 < dsal> uriel: I don't assume you don't know what you're talking about, and I can't argue that you haven't seen things. However, I'm spinning up goroutines that are calling http.Client.Do fairly frequently. It's possible that the server or network can stall one of those requests indefinitely. As far as I can tell, I simply can not stop that goroutine. 20:34 < ww> skelterjohn|work: that's kind of my problem too 20:34 -!- franciscosouza [~francisco@187.105.25.184] has joined #go-nuts 20:35 < huin> is it possible to set a timeout on such a connection? 20:35 < ww> dsal: yes, i have the same use case 20:35 < skelterjohn|work> dsal: you can timeout - and the leftover resources that are waiting for the client will be minimal 20:35 < kevlar_work> are we talking about http.Client.Do() hanging forever sometimes? 20:35 < dsal> skelterjohn|work: It's a file descriptor. I only have so many to work with. 20:36 < kevlar_work> if so, I'm curious if you guys see what I do: I can run tons of requests in series fine, but if I make gomaxprocs 9+ then I see them hang somewhat regularly 20:36 < ww> and in fact, i've had to resort to spawning external processes that canbe killed in the usuall way (and the things i'm fetching can be batched up so a few hundred requests per process, and i don't really care if i miss some) 20:37 < dsal> kevlar_work: I can't tell that that's happening to me right now, but if it did happen, there'd be nothing at all I could do about it in my program. :( 20:37 < skelterjohn|work> (going home for the weekend) 20:37 < huin> o/ 20:37 < dsal> skelterjohn|work: Have a nice one. Thanks for tolerating n00bs. :) 20:38 < kevlar_work> what I see is that a body.Close() from an internal http readAll gets hung on a channel send 20:38 * ww waves to skelterjohn|work 20:41 -!- sjbrown [~sjbrown@c-98-210-195-242.hsd1.ca.comcast.net] has joined #go-nuts 20:42 -!- zcram [~zcram@8.177.190.90.sta.estpak.ee] has quit [Quit: Leaving] 20:43 -!- ronnyy [~quassel@p4FF1C448.dip0.t-ipconnect.de] has joined #go-nuts 20:43 -!- th0re [~thre@ip-178-200-116-109.unitymediagroup.de] has quit [Quit: Der weg zur erkenntniss ist der richtige.] 20:45 < huin> i've just been looking at that Client.Do thing 20:46 < huin> i'm pondering that you can specify a transport of your own that might allow you to set a timeout 20:46 < kevlar_work> huin, you could 20:46 < huin> i guess i missed that point :/ 20:47 < kevlar_work> though the transport is complicated, so you'd probably end up just copy/pasting the DefaultTransport and adding a param and a call to Timeout 20:47 < huin> the Dial attribute looked promising 20:48 < huin> "// Dial specifies the dial function for creating TCP connections." 20:48 < huin> i figure you might just create an instance of http.Transport, and give the values you want 20:48 < huin> use a wrapped net.Dial function that sets a timeout 20:49 < huin> everything else should be fairly simple... specifying config params, really 20:49 < huin> not used it myself, mind 20:51 < kevlar_work> yeah, a dial wrapper would probably work nicely 20:51 < kevlar_work> something that nice might even be a candidate for the stdlib 20:51 < kevlar_work> NewTimeoutTransport(timeoutns int64) 20:51 < huin> pretty trivial, mind you 20:52 < kevlar_work> actually, russ would say that it's too few lines to be in the stdlib. 20:52 < huin> i suspect i'd agree ;) 20:52 -!- erus` [~chatzilla@cpc2-gill2-0-0-cust701.basl.cable.virginmedia.com] has joined #go-nuts 20:53 < huin> one thing i like about the stdlib is how net.Conn is an interface 20:54 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-152-133.clienti.tiscali.it] has quit [Quit: E se abbasso questa leva che succ...] 20:54 < huin> which means that if i ever get round to finishing my SSH lib, writing an SSH transport would be easily possible 20:54 -!- meling [~meling@cse-dhcp-10-91.ucsd.edu] has quit [Remote host closed the connection] 20:54 < huin> or more specifically: SSH TCP connection tunnelling would implement net.Conn 20:55 -!- rcrowley [~rcrowley@AGrenoble-551-1-7-133.w92-133.abo.wanadoo.fr] has joined #go-nuts 20:55 -!- keithcascio [~keithcasc@nat/google/x-mktauutoawjucpmf] has joined #go-nuts 20:56 -!- nekoh [~nekoh@dslb-188-107-168-137.pools.arcor-ip.net] has joined #go-nuts 20:56 < kevlar_work> neat 20:58 -!- huin [~huin@91.84.179.118] has quit [Quit: bedtime] 20:58 -!- meling [~meling@cse-dhcp-10-91.ucsd.edu] has joined #go-nuts 20:59 -!- tvw [~tv@e176005223.adsl.alicedsl.de] has joined #go-nuts 20:59 -!- fabled [~fabled@83.145.235.194] has quit [Quit: Ex-Chat] 21:03 -!- kamaji [~kamaji@handtomouse.demon.co.uk] has quit [Remote host closed the connection] 21:04 < dsal> Doh, missed huin. I actually could really use some basic ssh stuff right now for talking to gerrit so I can kill off another python script. 21:04 -!- smw [~stephen@unaffiliated/smw] has joined #go-nuts 21:05 < dsal> I'd really like this to at least be partially powered by go: http://dustinphoto.iriscouch.com/android/_design/app/index.html 21:05 < dsal> (not a single person with a gravatar up there right now...) 21:06 -!- fotang [~fotang@41.206.12.69] has joined #go-nuts 21:06 -!- dlowe [~dlowe@ita4fw1.itasoftware.com] has quit [Quit: Leaving.] 21:07 -!- rcrowley [~rcrowley@AGrenoble-551-1-7-133.w92-133.abo.wanadoo.fr] has quit [Quit: Computer has gone to sleep.] 21:09 -!- dreadlorde [dreadlorde@c-68-42-82-10.hsd1.mi.comcast.net] has joined #go-nuts 21:11 -!- zozoR [~Morten@2906ds2-arno.0.fullrate.dk] has quit [Remote host closed the connection] 21:12 < str1ngs> dsal: does it have to be ssh? how about rpc or jsonrpc? 21:12 < dsal> The only API I get from gerrit is ssh. 21:12 < dsal> Or polling. This updates your screen in realtime when things are happening. 21:13 < str1ngs> if there is a ssh api I would think there is a command line api to the same effect no? 21:13 < str1ngs> unless gerrit only works as some ssh daemon? ie like git-daemon? 21:13 < dsal> I use the ssh API from the commandline. :/ 21:13 < dsal> It's got a web server and an ssh server. 21:13 < dsal> There's no useful http API 21:14 -!- jbooth1 [~jay@209.249.216.2] has quit [Quit: Leaving.] 21:14 < str1ngs> right but what you can call from ssh you can call from command line. unless you dont have access to the server? 21:14 < dsal> That's how my python thing is working -- it just runs ssh as a subprocess. 21:15 < str1ngs> you can do the samething with go. obviously better to use a native ssh netcon but w/e works 21:15 < dsal> I just figured that if I were going to rewrite it, I'd like it to be better. 21:16 < str1ngs> but my other point is do you have access to the server? 21:16 < dsal> I do. 21:16 < str1ngs> so.. if you made say a jsonrpc you wouldnt need ssh 21:17 < dsal> Well, I have access to one of them. I'm watching two gerrit servers. 21:17 < dsal> What would the RPC do? 21:17 < str1ngs> rpc would give you a api to gerrit. instead of ssh you would exec instead. 21:17 < dsal> Well, going back a second... being on the OS running gerrit doesn't get me any closer. 21:17 < dsal> No, ssh *is* the interface. 21:17 < dsal> You ssh to gerrit. 21:18 < dsal> I can't get any closer to it without sshing into it. 21:18 < dsal> I can be on the same box, but I'd still have to ssh in. 21:18 < dsal> And the thing I'm doing here is following a stream of events it emits. I definitely don't want any polling. 21:18 < str1ngs> gerrit sounds like a pain in the ass then :P 21:19 < str1ngs> can you not just work off of the git repos directly? or do you miss all the review crap then? 21:19 < dsal> Heh. Just that part. I immediately lob the insides into couchdb and then it does everything I want. :) 21:19 -!- qeed [~qeed@adsl-74-235-213-78.mco.bellsouth.net] has quit [Quit: Leaving] 21:19 < dsal> Yeah, it's specifically these review events I want. X commented on Y, etc... 21:19 < str1ngs> hmm ya 21:19 < dsal> Although there are events even there that I don't get (filed bugs, etc...) 21:21 < str1ngs> so imo, the bestthing to do is to help with any ssh package that currently exists 21:21 < dsal> I agree with you. If you need it and are capable of providing it, it's your responsibillity. 21:21 < str1ngs> since this is probably useful to more people in the future. I know there is atleast one package on bitbucket. 21:22 < dsal> I started playing with that one one day, but it didn't quite do what I wanted and I was procrastinating anyway. 21:22 < dsal> I've written most of my go code while other work urgently waited. It's easier that way. 21:22 < str1ngs> ah, yes go is kinda young still for native package's 21:23 < dsal> I wrote my first go program on November 11 2009. Finished it in a board meeting. That's how I roll. 21:24 < str1ngs> go's a blast 21:24 < str1ngs> oddly the more you use it the better it gets. 21:24 < str1ngs> but I'm a big fan of k.i.s.s 21:25 < dsal> I didn't write anything else with it for a long time. Just started picking it back up again for... some reason. I'm not even sure why. 21:25 < dsal> I rewrote some node.js thing I had in go. It was bigger, but felt better. 21:26 < dsal> Is there a pub/sub kind of thing commonly used? I found a blog post, but it looked significantly different from the thing that's in my head. 21:26 < str1ngs> not sure what you mean by pub sub 21:27 < str1ngs> you mean private/public fields? 21:27 < franksalim> pubsub == observer 21:27 < dsal> service := Topic(); service.subsribe(ch); service.publish("an event") 21:27 < dsal> Yeah, that kind of thing. 21:28 -!- dfr|mac [~dfr|work@nat/google/x-bbkfszpfqvvbsifk] has joined #go-nuts 21:28 < dsal> Just a collection of channels, really. It'd be easy to write, but it seems like the kind of thing people would have around. 21:28 < str1ngs> ah maybe something like a WaitGroup 21:28 < str1ngs> see $ godoc sync WaitGroup 21:29 < dsal> That's interesting, but not what I want. :) 21:29 < str1ngs> I know go often doesnt do it the way you expect :P 21:29 < dsal> I've got an app that connects to a socket, reads stuff and emits structs. 21:29 < dsal> I'd like to have different things able to react to those structs. 21:30 < dsal> It's just a collection of channels basically, plus being able to register, unregister, automatically handle closed channels, etc... 21:30 < franksalim> in other words, the equivalent of multiple event listeners in other languages. as if there were topic channels in addition to queue channels 21:30 < dsal> yes. 21:31 < franksalim> i don't know of anything like that in the standard library, and i would also like to hear if anyone has any suggestions 21:31 < dsal> I can load balance pretty well, but I can't as easily have different things doing different work on the same input. 21:31 < str1ngs> generally this is done with interfaces and type assertion switch 21:32 < str1ngs> I guess you could use that as a basis then, sorta make your own register etc. 21:32 < dsal> I found something here labeled "broadcasting" http://rogpeppe.wordpress.com/category/computers/golang/ 21:32 < franksalim> there are multireader and multiwriter, which are similar in spirit, but operate on byte streams and can't be edited dynamically 21:32 < dsal> In my case, there's no interface or type assertion. There's just "chan Thing" 21:33 < dsal> 8 goroutines are each waiting to read from a channel. When a new Thing is available, they all get it. 21:35 -!- skelterjohn [~jasmuth@c-24-0-2-70.hsd1.nj.comcast.net] has joined #go-nuts 21:35 < dsal> Then I can have one for logging new Things, one for storing them in a DB, one for reacting to them and signaling other systems when certain rules apply, etc... I'm writing software that does this, so I'll probably write one of fifty such things along the way. 21:35 < dsal> It's kind of like node.js and "how do I do two things sequentially?" 21:37 -!- angasule [~angasule@190.2.33.49] has joined #go-nuts 21:38 -!- miker2 [~miker2@pool-96-245-224-59.phlapa.fios.verizon.net] has joined #go-nuts 21:45 < fotang> cant find a SOAP package for go. any idea if such exists at all? 21:46 < erus`> oh god SOAP 21:46 < fotang> yea soap 21:47 < kevlar_work> fotang, http + xml? 21:47 < kevlar_work> maybe make some interfaces and steal part of the third-party rest api? 21:47 < kevlar_work> I dunno, lol 21:48 < kevlar_work> I've always thought the S in SOAP should have been for s**tty not for simple. 21:49 < franksalim> name an initialism in which the 'S' stands for simple that isn't shitty 21:49 < kevlar_work> I don't know, lol 21:50 < kevlar_work> simple can't just be a name, it has to be a religion. 21:50 -!- pharris [~Adium@rhgw.opentext.com] has quit [Quit: Leaving.] 21:51 < fotang> kevlar_work: want to call some methods provided by some service 21:51 < fotang> guess i should look for restful service 21:52 < fotang> SMTP doesnt look easy either... 21:52 < skelterjohn> did we come to any conclusions on the goroutine termination debate? 21:52 < kevlar_work> fotang, if you're integrating with an existing service that only implements SOAP, then, well, I guess you have to use it 21:52 < skelterjohn> or am i going to get tomatoes thrown at me for bringing it up 21:53 < kevlar_work> fotang, but if you are designing the service you'll connect to, use jsonrpc or gobrpc 21:53 < kevlar_work> skelterjohn, I missed the debate, but I think my opinion was summarized on the mailing list at one point 21:53 < kevlar_work> though if you don't expect it to clean up any memory, then you might have a somewhat stronger argument than that OP did. 21:53 -!- franciscosouza [~francisco@187.105.25.184] has quit [Read error: Connection reset by peer] 21:54 < kevlar_work> but you still have the issue of any goroutines that will be waiting on that goroutine will then hang, and never be garbage collected 21:54 -!- miker2 [~miker2@pool-96-245-224-59.phlapa.fios.verizon.net] has quit [Ping timeout: 252 seconds] 21:54 < kevlar_work> so you couldn't, for instance, use it to kill an http.Do 21:54 < kevlar_work> because it uses at least two other goroutines with synchronous channels. 21:55 < skelterjohn> that's a different issue 21:55 < skelterjohn> goroutines that can provably never wake up should be cleaned, imo 21:56 -!- franciscosouza [~francisco@187.105.25.184] has joined #go-nuts 21:57 < kevlar_work> I doubt anyone would argue with you, but I think you'll find that it's not an easy problem to solve. 21:57 < kevlar_work> actually, no, I disagree with that 21:58 < skelterjohn> the deadlock detector already solves it 21:58 < kevlar_work> it makes it almost impossible to debug if you clean up the goroutines 21:58 < skelterjohn> and i can outline a correct algorithm easily 21:58 < skelterjohn> kevlar_work: the behavior of the program would not change in any way whatsoever 21:58 < skelterjohn> the goroutines that get cleaned will never wake up 21:59 < kevlar_work> skelterjohn, but you can't SIGQUIT and inspect the goroutine stack traces to debug hanging goroutines anymore 21:59 < skelterjohn> they're just entries on a list, and they keep memory resources from being cleaned 21:59 < skelterjohn> keep a list of goroutines that get cleaned up 21:59 < kevlar_work> and their stack traces? 22:00 < skelterjohn> there is a trade off between ease of debugging and ease of writing programs that don't leak memory 22:00 < kevlar_work> I think in a correct go program, zero such goroutines should exist, and when they do, it's something I should be able to debug. 22:00 < skelterjohn> then have it panic when this happens 22:00 < kevlar_work> leaking memory is a bug, hiding it is not the correct solution 22:00 < skelterjohn> i'm ok with that, but it won't happen since it would change the behavior of existing code, potentially 22:00 < kevlar_work> nah, that's not a barrier 22:01 -!- Bigbear1 [~Cody@d75-158-129-33.abhsia.telus.net] has joined #go-nuts 22:01 < kevlar_work> they break existing code all the time 22:01 < skelterjohn> true, but this is a bit more fundamental 22:01 < kevlar_work> but the benefit has to measure up. 22:01 < skelterjohn> not a change in syntax or API 22:01 < aiju> are you guys STILL ARGUING ABOUT THIS THING? 22:01 < kevlar_work> we resumed when we heard you coming 22:01 < aiju> ahhaha 22:01 < skelterjohn> i just got home a bit ago 22:01 < kevlar_work> (no really, we just started debating it) 22:01 < skelterjohn> we're talking about provably dead goroutines now 22:02 < skelterjohn> not the ability to kill goroutines 22:02 < kevlar_work> also, I don't think the current deadlock detector does what you think 22:02 < skelterjohn> i haven't thought about it, so that's likely 22:02 < kevlar_work> it only panics when no syscalls are outstanding and all goroutines are waiting on semaphores. 22:02 < kevlar_work> actually, the latter implies the former. 22:03 < skelterjohn> sure 22:03 < skelterjohn> provind a goroutine dead is easy though 22:03 < skelterjohn> proving 22:03 < skelterjohn> O(# goroutines), and you don't have to do it very often 22:04 < kevlar_work> uh, it's o(blocking goroutines*number of goroutines) 22:04 < skelterjohn> i meant for a single one 22:05 < skelterjohn> to do it for all of them would multiply by that factor 22:05 < skelterjohn> or maybe not - i hadn't thought the analysis through 22:05 < skelterjohn> but the algorithm is easy 22:05 < kevlar_work> I also think that removing "some" unreachable goroutines is worse than removing none 22:06 < kevlar_work> and it is not easy to prove that a goroutine WILL never be woken. 22:06 < kevlar_work> (see halting problem) 22:07 < kevlar_work> practically the only cases you'd remove would be go func(){ x := make(chan bool); <-x }() 22:07 -!- sjbrown [~sjbrown@c-98-210-195-242.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds] 22:07 < skelterjohn> anything where a goroutine blocks on a channel that has been forgotten about 22:07 < kevlar_work> yeah, but that almost never happens 22:07 < skelterjohn> sure it does 22:08 < skelterjohn> breaking on ranging over a channel 22:08 < skelterjohn> of course, since we know this leaks memory, we try to be careful 22:08 < skelterjohn> so in that sense, it "shouldn't" happen 22:08 < kevlar_work> huh? 22:08 < kevlar_work> what does ranging over a channel have to do with anything? 22:09 < kevlar_work> it neither brings a chanel into nor out of scope (inherently) 22:09 < skelterjohn> if the channel is a conduit of generated data, for instance something that's iterating through a data structure 22:09 < skelterjohn> if you range on that channel and break in the middle, the goroutine generating the data just blocks 22:09 < skelterjohn> trying to send the next bit 22:09 < kevlar_work> okay, so my argument still stands 22:09 -!- Fish- [~Fish@9fans.fr] has quit [Quit: WeeChat 0.3.5] 22:10 < skelterjohn> what, no one does this? 22:10 < kevlar_work> that almost never happens and I still don't think you should kill any unreachable goroutines unless you can kill all of them 22:10 -!- fotang [~fotang@41.206.12.69] has quit [Ping timeout: 276 seconds] 22:10 < kevlar_work> it's also abberant behavior, which we shouldn't enable 22:11 -!- ronnyy [~quassel@p4FF1C448.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 22:11 < skelterjohn> if i have a data structure, especially a container type, the easiest way to iterate through it would be to walk the structure in a different goroutine and send it on a channel 22:11 < skelterjohn> that is aberrant? 22:11 < kevlar_work> breaking out of that loop is 22:11 < skelterjohn> that's silly 22:12 < skelterjohn> of course there are good reasons to break out of that loop 22:12 < kevlar_work> no, what's silly is that x := cont.Iter(); for y := range x {break} mightn't be killed and for y := range cont.Iter() {} would be 22:12 < kevlar_work> s/{}/{break}/ 22:13 < skelterjohn> whaaat 22:13 < skelterjohn> what is the difference? 22:13 < kevlar_work> because someone trained to think that the latter is okay would assume the former is okay 22:13 < kevlar_work> that channel is still "reachable" in the first case 22:13 < kevlar_work> if it then goes into a long-running infinite loop later, it can never be provably dead 22:14 < skelterjohn> i see 22:14 < skelterjohn> sure 22:14 < skelterjohn> that's a good point 22:15 < kevlar_work> even with perfect escape analysis and perfect garbage collection and perfect infinite loop detection, I don't know if you could do it perfectly 22:15 < skelterjohn> so right now, to make this not leak a huge amount of memory, i have to either buffer the iteration channel or receive a break signal some other way 22:15 < skelterjohn> yes yes, halting problem 22:16 < skelterjohn> still you could clean up memory in a lot of cases 22:16 < skelterjohn> memory that will never be used 22:16 < kevlar_work> or just do `if skip {continue}` first in the loop 22:16 < skelterjohn> sounds efficient =p 22:17 < kevlar_work> skelterjohn, how would that be any different than if I did bad := make([]int, 1000) before the infinite loop and never used it? 22:17 < skelterjohn> or i could try and close the channel from the recv end, and make the other goroutine panic O:-) 22:17 < skelterjohn> kevlar_work: because that's obviously silly 22:17 < kevlar_work> skelterjohn, you could realize that this is why the container.Iter() is no longer a go design pattern 22:17 < skelterjohn> yes, i do 22:18 -!- pjacobs [~pjacobs@75-27-133-72.lightspeed.austtx.sbcglobal.net] has quit [Quit: Leaving] 22:18 < kevlar_work> and use .Map() or return a slice instead :) 22:18 -!- Peet__ [~Peet__@unaffiliated/peet--/x-2416233] has quit [Ping timeout: 255 seconds] 22:18 < kevlar_work> if you will always provably consume every element, then you can use the iter paradigm, otherwise don't. 22:18 < kevlar_work> also, the if skip {continue} is more efficient than letting the goroutine die ;-) 22:18 < kevlar_work> er, hang* 22:19 < skelterjohn> how about something that generates an infinite series? 22:19 < kevlar_work> skelterjohn, use a map() pattern 22:19 < skelterjohn> not sure what the map() pattern is 22:19 -!- Peet__ [~Peet__@unaffiliated/peet--/x-2416233] has joined #go-nuts 22:20 < kevlar_work> func (c Container) Map(fn func(e Element) (continue bool)) (consumed int) // or similar 22:20 < skelterjohn> ah 22:21 < skelterjohn> i like to be able to use the nice syntactic features that go offers 22:21 < skelterjohn> but c'est la vie 22:22 < kevlar_work> it's using closures :) 22:23 < skelterjohn> lots of typing 22:23 < kevlar_work> and you can easily use that map function to put the elements out on a channel with a break var/channel if you wanted. 22:23 < kevlar_work> like I said, you can use the iter paradigm if you always want all of the values. 22:23 < skelterjohn> i don't know if "easily" is the right word 22:24 < skelterjohn> what i do now, mostly, is use a buffered channel, write all the values and then the goroutine can exit 22:24 < kevlar_work> how is that different from returning a slice? 22:24 < skelterjohn> but don't get me wrong - i understand that you *can* do these things 22:24 < skelterjohn> not much, obv 22:25 -!- dreadlorde [dreadlorde@c-68-42-82-10.hsd1.mi.comcast.net] has quit [Ping timeout: 258 seconds] 22:25 < skelterjohn> when i range over it i don't have to _, the index 22:25 < skelterjohn> ? 22:25 < skelterjohn> *shrug* 22:25 < kevlar_work> ah. well, there is that. 22:26 -!- franciscosouza [~francisco@187.105.25.184] has quit [Read error: Connection reset by peer] 22:27 < skelterjohn> but it'd be nice if the same syntax on the client side could iterate through lazily without the worry of leaking resources 22:28 < kevlar_work> so use a slice :P 22:28 < skelterjohn> by lazy i mean the thing giving the data only evaluates the next bit when the previous bit is consumed 22:29 < skelterjohn> ie unbuffered channel 22:29 < kevlar_work> so use a map function :P 22:29 < skelterjohn> that wouldn't be the same syntax on the client side 22:29 < skelterjohn> and it would be a lot of annoying boilerplate 22:30 < kevlar_work> that's the tradeoff if you don't want to have to iterate over all of them. 22:30 -!- erus` [~chatzilla@cpc2-gill2-0-0-cust701.basl.cable.virginmedia.com] has quit [Remote host closed the connection] 22:30 < kevlar_work> honestly, this has never come up for me. 22:30 < skelterjohn> i'd prefer to trade-off with a sigint not telling me about the stalled goroutine =p 22:31 < skelterjohn> ok, well it comes up for me =p 22:31 < kevlar_work> when do you need lazy evaluation of individual elements where the overhead of a "skip" boolean is higher than the overhead of the context switches? 22:32 < skelterjohn> an infinite generative process 22:32 < skelterjohn> the skip overhead is pretty high 22:32 -!- photron [~photron@port-92-201-48-250.dynamic.qsc.de] has quit [Ping timeout: 255 seconds] 22:32 < kevlar_work> er, yeah, it would be with an unbuffered channel. 22:32 < skelterjohn> tough to buffer that channel too 22:32 < kevlar_work> the only time I've used a generator, I intended it to live around and never ranged over it 22:33 < kevlar_work> and it also had a way to kill it. 22:33 < kevlar_work> (I used it for generating unique IDs) 22:34 -!- keithcascio [~keithcasc@nat/google/x-mktauutoawjucpmf] has quit [Quit: Leaving] 22:34 < kevlar_work> (sending a unique ID over a "set" channel would reset the sequence, and closing the "set" channel caused it to stop.) 22:34 -!- gridaphobe [~gridaphob@cpe-74-68-151-24.nyc.res.rr.com] has quit [Quit: Leaving] 22:34 < kevlar_work> (it also had a buffered output channel to avoid context switches during load) 22:35 < skelterjohn> (have to prepare dinner) 22:35 < kevlar_work> (later) 22:43 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit: Verlassend] 22:44 -!- robteix [~robteix@host107.200-43-249.telecom.net.ar] has joined #go-nuts 22:45 -!- keithcascio [~keithcasc@nat/google/x-zwyggweeeajifiht] has joined #go-nuts 22:58 -!- franksalim [~frank@64-71-23-250.static.wiline.com] has quit [Quit: Leaving] 22:58 -!- rl [~rbl@84-74-142-37.dclient.hispeed.ch] has quit [Ping timeout: 258 seconds] 23:02 -!- vsmatck2 [0c041bf8@gateway/web/freenode/ip.12.4.27.248] has joined #go-nuts 23:07 -!- pvarga [~pvarga@pool-71-187-202-33.nwrknj.fios.verizon.net] has joined #go-nuts 23:08 -!- rlab [~Miranda@91.200.158.34] has quit [Read error: Connection reset by peer] 23:12 -!- nutate [~rseymour@cacsag4.usc.edu] has joined #go-nuts 23:19 -!- iant [~iant@nat/google/x-qdzvjiwtexklxueb] has quit [Ping timeout: 250 seconds] 23:24 -!- dsal [~Adium@208.185.212.98] has quit [Quit: Leaving.] 23:24 -!- robteix [~robteix@host107.200-43-249.telecom.net.ar] has quit [Quit: Computer has gone to sleep.] 23:25 -!- vsmatck2 [0c041bf8@gateway/web/freenode/ip.12.4.27.248] has quit [Quit: Page closed] 23:27 -!- Transformer [~Transform@ool-4a59e397.dyn.optonline.net] has joined #go-nuts 23:29 -!- Transformer [~Transform@ool-4a59e397.dyn.optonline.net] has quit [Excess Flood] 23:32 -!- iant [~iant@66.109.104.217] has joined #go-nuts 23:32 -!- mode/#go-nuts [+v iant] by ChanServ 23:36 -!- napsy [~luka@88.200.96.18] has quit [Ping timeout: 240 seconds] 23:43 -!- flaguy48 [~gmallard@user-0c6s350.cable.mindspring.com] has left #go-nuts [] 23:47 < jnwhiteh> Has anyone build Go on OS X Lion? 23:47 < jnwhiteh> I see some people on the mailing list have been successful, but I'm having a few issues =/ 23:47 -!- crazy2be [~crazy2be@d50-99-249-250.abhsia.telus.net] has joined #go-nuts 23:48 -!- robteix [~robteix@host107.200-43-249.telecom.net.ar] has joined #go-nuts 23:50 -!- Bigbear11 [~Cody@d75-158-129-33.abhsia.telus.net] has joined #go-nuts 23:52 -!- Bigbear1 [~Cody@d75-158-129-33.abhsia.telus.net] has quit [Ping timeout: 255 seconds] 23:56 -!- ijknacho [~goofy@71.123.134.24] has joined #go-nuts 23:57 -!- robteix [~robteix@host107.200-43-249.telecom.net.ar] has quit [Quit: Computer has gone to sleep.] --- Log closed Sat Jul 23 00:00:01 2011