--- 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