--- Log opened Tue Jan 11 00:00:01 2011 00:06 -!- toyoshim_ [~toyoshim@y252053.dynamic.ppp.asahi-net.or.jp] has joined #go-nuts 00:10 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has joined #go-nuts 00:19 -!- fenicks [~christian@log77-3-82-243-254-112.fbx.proxad.net] has left #go-nuts [] 00:29 -!- tvw [~tv@e176000225.adsl.alicedsl.de] has quit [Remote host closed the connection] 00:36 -!- cafesofie [~cafesofie@rnwifi-164-107-92-229.resnet.ohio-state.edu] has quit [Remote host closed the connection] 00:37 -!- rup [~rupert@deathknight.net] has quit [Ping timeout: 255 seconds] 00:39 -!- cafesofie [~cafesofie@rnwifi-164-107-92-229.resnet.ohio-state.edu] has joined #go-nuts 00:41 -!- liwei [~liwei@180.110.217.90] has joined #go-nuts 00:46 -!- virtualsue [~chatzilla@nat/cisco/x-zivcnsrvgibjppgi] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.5.16/20101130074220]] 00:46 -!- liwei [~liwei@180.110.217.90] has quit [Ping timeout: 272 seconds] 00:54 -!- foocraft [~dsc@89.211.255.96] has joined #go-nuts 00:56 < anticw> iant: off the top of your head do you know why gccgo -static binaries are a lot larger than those from [68]g ? 00:56 < anticw> btw, -m32 works ... i was ignore that till now but in an attempt to get some deployment issues smaller tried that ... it works fine but the code is slower so i shelved that for now 00:57 <+iant> gccgo brings in stuff from libc, so if you like -static you are getting, e.g., both fmt.Printf and printf 00:58 <+iant> also there is more debug info if you are using -g 00:58 < anticw> i strip that 00:58 <+iant> then all the libc stuff would be my guess 00:58 < anticw> iant: why would printf get sucked in from libc.a when i never call it? 00:58 <+iant> libgo calls it 00:58 < anticw> oh 00:58 < anticw> why? 00:59 <+iant> to implement print 00:59 <+iant> the builtin function 00:59 -!- daharon [~daharon@173-11-102-86-SFBA.hfc.comcastbusiness.net] has quit [Quit: Leaving] 00:59 < anticw> ah right ... 00:59 < anticw> we should just take that out :-) 00:59 < anticw> the spec doesn't require it 01:00 <+iant> it's handy, though 01:00 <+iant> there are some other calls to printf in libgo for error cases 01:00 <+iant> I didn't try to minimize it 01:00 <+iant> and I'm not sure how much it would help to remove all the calls, though I think it would help some 01:00 < anticw> im not that worried right now, i have larger issues 01:00 <+iant> me too 01:00 < anticw> like the ioctl's all break 01:01 < anticw> very few work the same between 32 and 64 bit 01:01 <+iant> yeah 01:14 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has joined #go-nuts 01:16 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|] 01:25 -!- skejoe [~skejoe@188.114.142.162] has quit [Ping timeout: 240 seconds] 01:25 -!- rup [~rupert@deathknight.net] has joined #go-nuts 01:26 -!- cafesofie [~cafesofie@rnwifi-164-107-92-229.resnet.ohio-state.edu] has quit [Remote host closed the connection] 01:27 -!- skejoe [~skejoe@188.114.142.162] has joined #go-nuts 01:29 -!- devrim [~Adium@160.79.7.234] has quit [Quit: Leaving.] 01:30 -!- cafesofie [~cafesofie@rnwifi-164-107-92-229.resnet.ohio-state.edu] has joined #go-nuts 01:36 -!- zeh [~zeh@187.106.49.62] has joined #go-nuts 01:40 -!- dRbiG [p@irc.kaer.tk] has quit [Read error: Connection reset by peer] 01:41 -!- liwei [~liwei@180.110.219.67] has joined #go-nuts 01:45 -!- ExtraSpice [~XtraSpice@88.118.33.48] has quit [Ping timeout: 240 seconds] 01:46 -!- liwei [~liwei@180.110.219.67] has left #go-nuts [] 01:47 -!- dRbiG [p@irc.kaer.tk] has joined #go-nuts 01:58 -!- zav [~lsd@189001130056.usr.predialnet.com.br] has quit [Quit: Leaving] 01:59 -!- niemeyer [~niemeyer@201-40-141-234.pltce701.dsl.brasiltelecom.net.br] has quit [Ping timeout: 240 seconds] 02:03 -!- Venom_X [~pjacobs@66.54.185.131] has quit [Ping timeout: 264 seconds] 02:03 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has joined #go-nuts 02:04 -!- Venom_X [~pjacobs@75.92.43.21] has joined #go-nuts 02:04 -!- Venom_X [~pjacobs@75.92.43.21] has quit [Client Quit] 02:12 -!- markcol [~markcol@74.125.59.1] has quit [Quit: markcol] 02:13 -!- markcol [~markcol@74.125.59.1] has joined #go-nuts 02:18 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts 02:25 -!- jesmon [~user@rrcs-69-193-6-191.nys.biz.rr.com] has joined #go-nuts 02:29 -!- bmizerany [~bmizerany@208.66.27.62] has quit [Read error: Connection reset by peer] 02:29 -!- bmizerany [~bmizerany@204.14.152.118] has joined #go-nuts 02:33 -!- nettok [~quassel@200.119.150.123] has quit [Quit: No Ping reply in 180 seconds.] 02:34 -!- nettok [~quassel@200.119.150.123] has joined #go-nuts 02:36 -!- zeh [~zeh@187.106.49.62] has quit [Quit: Leaving] 02:40 -!- skejoe_ [~skejoe@188.114.142.162] has joined #go-nuts 02:44 -!- skejoe [~skejoe@188.114.142.162] has quit [Ping timeout: 272 seconds] 02:45 -!- nettok [~quassel@200.119.150.123] has quit [Quit: No Ping reply in 180 seconds.] 02:45 -!- nettok [~quassel@200.119.150.123] has joined #go-nuts 02:47 -!- gr0gmint [~quassel@87.60.23.38] has quit [Remote host closed the connection] 02:55 -!- jhawk28 [~jhawk28@user-387c58d.cable.mindspring.com] has joined #go-nuts 02:55 -!- nettok [~quassel@200.119.150.123] has quit [Quit: No Ping reply in 180 seconds.] 02:56 -!- nettok [~quassel@200.119.150.123] has joined #go-nuts 03:03 -!- nettok [~quassel@200.119.150.123] has quit [Quit: No Ping reply in 180 seconds.] 03:03 -!- nettok [~quassel@200.119.150.123] has joined #go-nuts 03:04 -!- cafesofie [~cafesofie@rnwifi-164-107-92-229.resnet.ohio-state.edu] has quit [Remote host closed the connection] 03:07 < temoto> If i use time.After and then "timeout select", will it leak if operation is success and time channel is never read? Should i close the channel? 03:09 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has quit [Remote host closed the connection] 03:11 -!- nettok [~quassel@200.119.150.123] has quit [Quit: No Ping reply in 180 seconds.] 03:11 -!- bmizerany [~bmizerany@204.14.152.118] has quit [Remote host closed the connection] 03:12 -!- nettok [~quassel@200.119.150.123] has joined #go-nuts 03:12 -!- daxt [~daxt@112.135.67.19] has joined #go-nuts 03:14 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts 03:17 -!- nettok [~quassel@200.119.150.123] has quit [Quit: No Ping reply in 180 seconds.] 03:17 -!- nettok [~quassel@200.119.150.123] has joined #go-nuts 03:20 -!- gid [~gid@220-253-152-68.VIC.netspace.net.au] has quit [Ping timeout: 240 seconds] 03:25 -!- skejoe [~skejoe@188.114.142.162] has joined #go-nuts 03:26 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has quit [Quit: Leaving.] 03:26 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has joined #go-nuts 03:27 -!- serbaut1 [~joakims@88.80.182.68] has joined #go-nuts 03:28 -!- skejoe_ [~skejoe@188.114.142.162] has quit [Ping timeout: 255 seconds] 03:29 -!- cafesofie [~cafesofie@rnwifi-164-107-92-229.resnet.ohio-state.edu] has joined #go-nuts 03:29 -!- andreas_1indborg [~andreas@x1-6-00-1e-2a-29-58-14.k776.webspeed.dk] has joined #go-nuts 03:31 -!- ymasory [~ymasory@c-76-99-55-224.hsd1.pa.comcast.net] has quit [Ping timeout: 240 seconds] 03:34 -!- Netsplit *.net <-> *.split quits: atsampson, beneth`, tgall_out, preflex, serbaut, Mr_Dark, madari_, ubitux, andreas_hindborg, prip, (+8 more, use /NETSPLIT to show all of them) 03:36 -!- Netsplit over, joins: Kashia, Mr_Dark, Urtie, prip, jyxent, preflex, TheSeeker, tgall_out, ap3xo, ubitux (+5 more) 03:37 -!- daxt [~daxt@112.135.67.19] has quit [Excess Flood] 03:37 -!- daxt [~daxt@112.135.67.19] has joined #go-nuts 03:38 -!- daxt [~daxt@112.135.67.19] has quit [Remote host closed the connection] 03:42 -!- adu [~ajr@pool-72-83-254-159.washdc.fios.verizon.net] has joined #go-nuts 03:45 -!- Eridius [~kevin@unaffiliated/eridius] has quit [Ping timeout: 240 seconds] 03:46 -!- ymasory [~ymasory@c-76-99-55-224.hsd1.pa.comcast.net] has joined #go-nuts 03:46 -!- markcol [~markcol@74.125.59.1] has quit [Quit: markcol] 03:47 -!- nettok [~quassel@200.119.150.123] has quit [Quit: No Ping reply in 180 seconds.] 03:47 -!- nettok [~quassel@200.119.150.123] has joined #go-nuts 03:50 -!- nettok [~quassel@200.119.150.123] has quit [Client Quit] 03:51 -!- nettok [~quassel@200.119.150.123] has joined #go-nuts 04:01 -!- nettok [~quassel@200.119.150.123] has quit [Quit: No Ping reply in 180 seconds.] 04:01 -!- nettok [~quassel@200.119.150.123] has joined #go-nuts 04:15 -!- skejoe [~skejoe@188.114.142.162] has quit [Quit: Lost terminal] 04:16 -!- jesmon [~user@rrcs-69-193-6-191.nys.biz.rr.com] has quit [Remote host closed the connection] 04:21 -!- nettok_ [~quassel@200.119.186.159] has joined #go-nuts 04:24 -!- nettok [~quassel@200.119.150.123] has quit [Ping timeout: 250 seconds] 04:27 -!- watr_ [~watr@66.183.100.58] has joined #go-nuts 04:27 -!- rejb [~rejb@unaffiliated/rejb] has quit [Ping timeout: 276 seconds] 04:36 -!- mncaudill [~nolan@c-67-188-35-154.hsd1.ca.comcast.net] has joined #go-nuts 04:37 < mncaudill> hi all, quick (and probably stupid) question: how does one copy a map? 04:37 < mncaudill> the docs seem to be lacking on that one 04:38 < mncaudill> hi all, quick (and probably stupid) question: how does one copy a map? 04:38 < mncaudill> the docs seem to be lacking on that one 04:39 < uriel> copy()? 04:40 < cbeck> Pretty sure that only does slices 04:41 < mncaudill> cbeck: that's been my experience too 04:41 < cbeck> copy := make(map[foo]bar, len(orig)) for k,v := range orig {copy[k] = v} 04:41 < mncaudill> so there's not something built-in for that? 04:42 < nsf> no 04:42 < mncaudill> fair enough. thanks! 04:43 -!- keithcascio [~keithcasc@nat/google/x-yehamvuayscrbrog] has quit [Quit: Leaving] 04:44 < mncaudill> i start building a little something in Go last night for the first time. pretty slick little language 04:45 -!- tokuhiro_ [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has quit [Read error: Operation timed out] 04:50 < uriel> ops, sorry, in my deffense, I'm barely awake :) 05:04 -!- tokuhiro_ [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has joined #go-nuts 05:11 -!- viirya [~viirya@cml506-25.csie.ntu.edu.tw] has quit [Remote host closed the connection] 05:30 -!- bmizerany [~bmizerany@c-76-21-40-207.hsd1.ca.comcast.net] has joined #go-nuts 05:37 -!- prip [~foo@host98-124-dynamic.36-79-r.retail.telecomitalia.it] has quit [Ping timeout: 250 seconds] 05:44 -!- watr_ [~watr@66.183.100.58] has quit [Ping timeout: 255 seconds] 05:46 <@adg> temoto: no, it won't leak 05:47 < temoto> adg, thanks. 05:48 < temoto> Are there commonly used tools to detect leaks in Go programs in general? 05:48 <@adg> not yet, no 05:48 < temoto> i suppose valgrind wouldn't work 05:48 <@adg> valgrind gets _very_ upset at go programs 05:48 < temoto> : 05:48 < temoto> :) 05:48 <@adg> ;) 05:52 -!- bmizerany [~bmizerany@c-76-21-40-207.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 05:53 -!- antileet [~anirudhs@122.167.76.39] has joined #go-nuts 05:54 -!- Eko [~eko@ppp-70-225-140-127.dsl.ipltin.ameritech.net] has quit [Quit: Leaving] 05:54 -!- fabled [~fabled@mail.fi.jw.org] has joined #go-nuts 06:00 -!- tokuhiro_ [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has quit [Ping timeout: 240 seconds] 06:07 -!- bmizerany [~bmizerany@c-76-21-40-207.hsd1.ca.comcast.net] has joined #go-nuts 06:09 -!- bmizerany [~bmizerany@c-76-21-40-207.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 06:13 -!- mafs [~maikeru@unaffiliated/maikeru/x-7708887] has joined #go-nuts 06:15 -!- mikespook [~mikespook@183.47.227.8] has joined #go-nuts 06:15 -!- tokuhiro_ [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has joined #go-nuts 06:19 -!- lewis1711 [~lewis@125-239-255-244.jetstream.xtra.co.nz] has joined #go-nuts 07:00 -!- adu [~ajr@pool-72-83-254-159.washdc.fios.verizon.net] has quit [Quit: adu] 07:11 -!- LeNsTR [~lenstr@unaffiliated/lenstr] has joined #go-nuts 07:19 -!- antileet [~anirudhs@122.167.76.39] has quit [Ping timeout: 264 seconds] 07:30 -!- zozoR [~zozoR@56346ed3.rev.stofanet.dk] has joined #go-nuts 07:46 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts 07:57 -!- petrux [~petrux@host16-224-static.53-82-b.business.telecomitalia.it] has joined #go-nuts 08:17 -!- ymasory [~ymasory@c-76-99-55-224.hsd1.pa.comcast.net] has quit [Ping timeout: 255 seconds] 08:18 -!- temoto [~temoto@95-25-114-98.broadband.corbina.ru] has quit [Ping timeout: 240 seconds] 08:21 < dforsyth> is there a mktemp function somewhere that i am missing? 08:29 -!- arun [~arun@unaffiliated/sindian] has quit [Read error: Operation timed out] 08:30 -!- d2biG [p@irc.kaer.tk] has joined #go-nuts 08:31 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Read error: Operation timed out] 08:31 -!- snearch [~snearch@f053004182.adsl.alicedsl.de] has joined #go-nuts 08:32 -!- dRbiG [p@irc.kaer.tk] has quit [Ping timeout: 260 seconds] 08:33 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 08:44 -!- arun [~arun@2001:610:110:4e2:280:5aff:fe69:e130] has joined #go-nuts 08:44 -!- arun [~arun@2001:610:110:4e2:280:5aff:fe69:e130] has quit [Changing host] 08:44 -!- arun [~arun@unaffiliated/sindian] has joined #go-nuts 08:45 -!- ExtraSpice [~XtraSpice@88.118.33.48] has joined #go-nuts 08:47 -!- wtfness [~dsc@dyn-86-36-43-92.wv.qatar.cmu.edu] has joined #go-nuts 08:48 < nixness> Hi all 08:49 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts 08:49 < nixness> I *still* can't figure out the problem with the experiment I mentioned a few weeks back around here 08:49 < nixness> I had 2 merge sort implementations, one parallel and the other serial, both written in Go, and the parallel one is consistently slower 08:50 < jumzi> So there's a bottleneck somewhere, FIGURE IT OUT 08:50 < |Craig|> nixness: did you enable multiple processes, as well as not spawn large numbers of go routines? 08:51 < nsf> go runtime could be a bottleneck 08:51 < nixness> |Craig|, I did 08:51 < |Craig|> there are plenty of horribly slow ways to write a parallel merge sort 08:52 < nixness> I let a number of 512 elements be my lower bound for when I go parallel 08:52 < |Craig|> I wonder how creating a process, and communicating with it and garbage collecting it compares to sorting 512 numbers runtime wise... 08:54 < |Craig|> nixness: how many go routines are you making, and how many processes? 08:54 < |Craig|> and use more data if you want to favor the parallel one 08:55 < nixness> yeah so below 512 I don't spawn go routines, I just go sequential at that point 08:55 < nixness> s/sequential/serial/ 08:55 < nixness> but I've been testing with a million elements, a billion and so on 08:55 < nixness> and the parallel implementation is consistently slower 08:56 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has joined #go-nuts 08:56 < |Craig|> nixness: I repeat, how many go routines are you making, and how many processes? Also, how many cores on your machine? 08:57 < |Craig|> they should all be the same, and more than 1 optimally I'd think 08:57 -!- wrtp [~rog@92.17.51.127] has joined #go-nuts 08:58 < nixness> I have one process and I only spawn as many go routines as I've set GOPROCMAX, which is to 3 08:58 < Namegduf> Note: Go creates an unlimited number of threads for non-CPU tasks, such as syscalls 08:58 -!- tvw [~tv@e176008039.adsl.alicedsl.de] has joined #go-nuts 08:59 < Namegduf> nixness: Goroutines are cheap and efficient concurrency- but they're still concurrency and there's still communication overhead. 08:59 < Namegduf> If your algorithm is not sufficiently CPU heavy that the gains of concurrency outweigh the cost of communication, you will see a performance loss. 09:00 < nsf> which happens a lot, because goroutines are so easy to use 09:01 < Namegduf> It's cheap enough that in "real programs" it's something to worry about at the optimisation stage, not a matter that stops you writing nice elegant programs using goroutines 09:01 < Namegduf> But it does make benchmarks interesting 09:01 < Namegduf> Maybe 512 elements is too low, or the specifics of your implementation have issues. Hard to suggest where they are. 09:02 < nsf> personally I don't think goroutines are that elegant 09:02 < nsf> but whatever 09:03 < nsf> for a sorting algo, 512 is too low, yes 09:03 < |Craig|> I had to stop using channels and go routines like python's generators because there was significant performance overhead. (That said, when performance is not an issue, its a interesting thing to do) 09:03 < nixness> so what's a good number hmm 09:03 < Namegduf> You're already benchmarking; perhaps let that tell you where. 09:04 < jumzi> /dev/random? 09:04 < Namegduf> Change numbers, compare, etc. 09:04 < Namegduf> I think goroutines are extremely nice as an alternative to async I/O, and for independent request/connection handling at a more abstract level; "go handler(c)" then writing handler is a very nice way to write a server. 09:05 -!- photron [~photron@port-92-201-12-254.dynamic.qsc.de] has joined #go-nuts 09:05 < Namegduf> But I don't know what other concurrency primitives to compare them against in "elegance". 09:05 < Namegduf> Obviously full-blown threads don't compare and aren't nearly as nice. 09:06 < nixness> my threadcount is blowing off the roof I think :p 09:06 < Namegduf> Are you using gccgo? 09:06 < nixness> cuz I'm not locking the currentThreads variable, which I should 09:06 < nixness> no, 8g and 8l 09:06 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|] 09:07 < nixness> unless there's a Go way to do shared variables of course 09:07 < nixness> or if there's a way to cleanly go about limiting the number of threads 09:07 < Namegduf> Goroutines are not threads 09:07 < Namegduf> And you shouldn't treat them as such 09:07 < nixness> the way I want it to be is "if more than X threads currently, do it sequentially" 09:08 < Namegduf> That would be a bad idea 09:08 < Namegduf> Goroutines are primarily a memory cost 09:08 < Namegduf> You can have as many created as you like up to some very high limit 09:08 < nixness> so aren't they like threads but just more lightweight? 09:08 < Namegduf> At a very abstract level, yes. 09:08 < Namegduf> But this comes into the "lightweight" part. 09:09 < nixness> okay, so what's the difference between a go routine and a thread 09:09 -!- nettok_ [~quassel@200.119.186.159] has quit [Ping timeout: 255 seconds] 09:09 < Namegduf> A thread is visible to the OS, requires calling the OS to make, and has various other costs associated. 09:09 < Namegduf> I'm not sure of the details. 09:09 < nixness> and what are the benefits of a thread, then? 09:10 < Namegduf> A goroutine is not; it's basically a stack and a state and only the goroutine knows about it. 09:10 < Namegduf> In Go? There aren't any, you can't use them. 09:10 * nixness thinks of setcontext and getcontext 09:10 < Namegduf> Er, only the go runtime knows about it. 09:10 < Namegduf> Multiple threads permit multiple things to actually be run at once, and scheduled on the processor by the OS 09:11 < Namegduf> Whether they're actually "running at once" on different cores or some are running syscalls at the same time as others are doing other things. 09:11 < nixness> okay, so with that, I would think that I would not have a memory overhead on the system, like threads, but wouldn't be identified to the OS, unlike threads 09:11 < Namegduf> The primary cost of goroutines is in the 4KB stack each gets. 09:11 < Namegduf> (Or whatever you make it expand to) 09:12 < nixness> so the OS doesn't schedule my go routines 09:12 < Namegduf> Right. 09:12 < nixness> ...*snap* 09:12 < Namegduf> The Go runtime creates multiple OS threads and schedules your goroutines on them 09:12 < Namegduf> With up to GOMAXPROCS active CPU-using ones at once 09:13 < Namegduf> With others waiting on syscalls and such 09:14 < Namegduf> I'm explaining this kinda poorly but I hope it's making sense. 09:14 < nixness> Namegduf, it does, it's a very good high level description and we touched on what's going on low level so it's all good. 09:15 < Namegduf> It boils down to spawning up to tens or hundreds of thousands of goroutines without the same kind of overhead you'd get with threads. 09:15 < mpl> 10:11 < Namegduf> In Go? There aren't any, you can't use them. <-- are you saying you can't use benefits of threads or threads themselves? 09:15 < Namegduf> You can't use threads 09:15 < mpl> how about http://golang.org/pkg/debug/proc/#ThreadCreate then? 09:16 < mpl> I thought if one wished so he could explicitely use threads? 09:16 < mpl> although I haven't explored that and stuck with goroutines so far. 09:16 < Namegduf> That looks like a debugging package, not a way to do stuff in your own process. 09:16 < Namegduf> I don't understand why you'd WANT to do stuff with threads directly, though. 09:17 < mpl> ah yes... 09:17 < mpl> odd. I thought I had seen a few threads about using threads if one really really wanted so... 09:17 < Namegduf> Goroutines get all the benefits of them through being scheduled on them, at a fraction of the cost for lots of them. 09:17 < Namegduf> It might be possible but it sounds kinda crazy. 09:18 < Namegduf> I don't think you can have code be outside a scheduleable goroutine 09:18 < mpl> ah I know, I'm confusing with ppl wanting to explicitely do mutexes and such. 09:18 < Namegduf> Yeah, that's different. 09:18 < mpl> yeah. 09:19 < mpl> well it's a related issue. ppl are not encouraged to mutex their routines as they would do with threads. 09:19 < dforsyth> whats the best way to read a file line by line? read the whole thing and then split? 09:19 < Namegduf> Use bufio 09:19 < Namegduf> I think it has a read line method 09:19 < dforsyth> i saw that when i googled, but i dont see it in the docs :\ 09:19 < Namegduf> http://golang.org/pkg/bufio/ 09:20 < Namegduf> bufio.NewReader(filething) 09:20 < mpl> dforsyth: you wouldn't be related to charles forsyth from inferno/plan 9, would you? 09:20 < Namegduf> Aha. 09:20 < Namegduf> Then ReadBytes 09:20 < Namegduf> ReadBytes is how you do readline. 09:20 < dforsyth> yeah, readbytes 09:20 < dforsyth> mpl: nah 09:20 < mpl> k 09:21 < dforsyth> Namegduf: thanks, i should have scrolled some more X| 09:21 < Namegduf> mpl: I think the difference is that using mutexes doesn't conflict with any parts of the typical Go execution model, if I'm using the right words. 09:21 < Namegduf> mpl: While manual threading conflicts with the model in which all running code is in a goroutine which is scheduled 09:22 < Namegduf> You could write your own mutexes using a little assembly for atomic operations and some Go; sync.Mutex is itself like that. 09:22 < Namegduf> Manual threading would require... I guess figuring out exactly what you wanted it to actually *do* first. 09:23 < nixness> so should I use mutexes to lock the "threadCount" between go routines as I do the parallel merge sort, is there a more idiomatic way of doing this? 09:24 < Namegduf> If you really want to do it that way as described I'd use a mutex- but in Go a strong priority is placed on trying to have data owned by a single goroutine instead of handling concurrent access. 09:24 < mpl> Namegduf: yes, it's just that mutexes probably aren't the way to go in go most of the time. 09:24 < mpl> or at least not the best way. 09:25 < Namegduf> That said, I personally dislike goroutines created for the *sole purpose* of owning a *single* variable more- if only because they're so *slow* 09:25 < Namegduf> If you try to use it the way you would one you actually had normal access to. 09:25 < nixness> http://fpaste.org/UbFz/ 09:25 < Namegduf> And they're kinda weird design-wise too. 09:25 < Namegduf> That's just a personal thing, though, the consensus seems to be "mutexes as a last resort". 09:26 < Namegduf> I use them heavily but that's because shared state is part of my program's problem and performance is very important because everything it's compared against is written in C. :P 09:27 < nixness> heh you better not be working with the programming languages game :p 09:27 < nixness> brb 09:27 < mpl> and do you reckon you're having a hard time writing it than if you had to do it with threads and locks in C? 09:27 < Namegduf> Not at all. 09:27 < mpl> good then :) 09:27 < mpl> s/hard/harder/ 09:27 < Namegduf> If nothing else I keep mutexes local to their own pacage. 09:27 < Namegduf> *package 09:28 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has left #go-nuts [] 09:28 < Namegduf> GC is a big win there. 09:29 < mpl> alright, but gc and memory wins set aside, do you find yourself more at ease thinking in terms of locks and mutexes than with goroutines and channels? 09:29 < Namegduf> No. 09:29 -!- prip [~foo@host14-132-dynamic.35-79-r.retail.telecomitalia.it] has joined #go-nuts 09:30 < mpl> then go serves its purpose :) 09:30 < Namegduf> Threads wouldn't even work for this. 09:30 < Namegduf> A thread per client would be stupid expensive, so I'd have to use my own coroutines... 09:31 < mpl> well there's always rsc's libthread 09:31 < Namegduf> (Or be synchronous, but that's cheating on the whole thing because then locks go away) 09:31 < Namegduf> (Er, non-concurrent) 09:31 < Namegduf> There's a few fancy tricks I'm planning to pull that goroutines specifically enable, too. 09:32 < Namegduf> Well, in that they're concurrent. 09:32 < Namegduf> Being able to use synchronous I/O means it's okay if the other end can't handle the rate you're sending, you can just block indefinitely. 09:37 -!- mikespook [~mikespook@183.47.227.8] has quit [Quit: Leaving.] 09:39 -!- temoto [~temoto@81.19.91.15] has joined #go-nuts 09:42 < nixness> I think my merge sort implementation is slow because most of the time, every go routine is either sorting, or waiting for its subparts to sort 09:42 < nixness> I pasted it btw, that was the fpaste link 09:43 -!- sahid [~sahid@LNeuilly-152-21-22-10.w193-253.abo.wanadoo.fr] has quit [Quit: Ex-Chat] 09:44 < wrtp> nixness: you should definitely guard the thread count somehow 09:44 < wrtp> i don't think i'd do it like that though 09:44 < nixness> so what's a good way to limit the over head and get a faster-than-serial parallel merge sort? 09:45 < wrtp> i think i'd have a pool of goroutines servicing sort requests; each one would do its job sequentially 09:46 < wrtp> then there's no need to maintain a count 09:46 < nixness> hmm and no go routine would wait for the others to finish as well 09:46 < wrtp> you need to keep the unit of sequential work large enough that the concurrency is worth it 09:46 < nixness> so it's like a bottom up approach, to minimize overhead 09:46 < wrtp> yup 09:48 < nixness> but merging would be a PITA 09:48 < wrtp> i think you could make it very straightforward 09:50 -!- ronnyy [~quassel@p4FF1C702.dip0.t-ipconnect.de] has joined #go-nuts 09:51 < nixness> I'm running it on 10000000 elements now 09:51 < nixness> the race is still going :p 09:52 -!- Kashia [~Kashia@port-92-200-125-182.dynamic.qsc.de] has quit [Quit: This computer has gone to sleep] 09:52 < nixness> my parallel is consistently less in memory usage than the serial 09:54 < wrtp> your algorithm allocates too much memory 09:54 < wrtp> you can allocate exactly one duplicate array at the start 09:55 < nixness> and how would I use that? 09:55 * nixness serial one the race again 09:56 * nixness by a landslide 09:56 < nixness> so there's probably some aspect of Go's internals that I'm not getting straight, which is causing me to screw up 10:01 < nixness> I'll bbl 10:01 -!- nixness [~dsc@dyn-86-36-43-92.wv.qatar.cmu.edu] has quit [Quit: Leaving] 10:03 -!- clip9 [clip9@er.en.svarteper.com] has quit [Remote host closed the connection] 10:18 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 276 seconds] 10:18 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 10:37 -!- rlab_ [~Miranda@91.200.158.34] has joined #go-nuts 10:38 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 255 seconds] 10:45 -!- ronnyy [~quassel@p4FF1C702.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 10:46 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has joined #go-nuts 10:46 -!- rlab_ [~Miranda@91.200.158.34] has quit [Ping timeout: 240 seconds] 10:47 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 10:47 -!- tvw [~tv@e176008039.adsl.alicedsl.de] has quit [Remote host closed the connection] 10:48 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has left #go-nuts [] 10:53 -!- DerHorst [~Horst@e176107058.adsl.alicedsl.de] has joined #go-nuts 10:54 -!- ildorn [~ildorn@dslb-088-067-144-207.pools.arcor-ip.net] has joined #go-nuts 10:55 -!- shvntr [~shvntr@116.26.130.138] has joined #go-nuts 11:00 -!- daxt [~daxt@112.135.67.19] has joined #go-nuts 11:08 -!- cafesofie [~cafesofie@rnwifi-164-107-92-229.resnet.ohio-state.edu] has quit [Remote host closed the connection] 11:13 -!- vinisterx [~ryan@74-129-194-67.dhcp.insightbb.com] has quit [Ping timeout: 265 seconds] 11:15 < wrtp> i know nixness isn't here, but i got 10% speedup with multiprocessor mergesort 11:15 -!- daxt_ [~daxt@112.135.66.216] has joined #go-nuts 11:17 -!- daxt_ [~daxt@112.135.66.216] has quit [Remote host closed the connection] 11:17 < wrtp> i'm not quite sure what the theoretical maximum is, but i don't think it's much more than 25% 11:18 -!- reubenbond [~reubenbon@220-253-2-173.VIC.netspace.net.au] has joined #go-nuts 11:19 -!- daxt [~daxt@112.135.67.19] has quit [Ping timeout: 255 seconds] 11:21 < reubenbond> If I wanted to serialise some various int's into a []byte... how might I? 11:21 < reubenbond> encoding/binary gives me io.Writer... but it doesn't seem like the cleanest way 11:23 < wrtp> reubenbond: you can use binary.(Little|Big)Endian.PutU32Int 11:24 < wrtp> which is the quickest way of doing it if you're only doing one or two ints 11:24 < reubenbond> Oh I see... that's not in the go doc :/ 11:24 < wrtp> yes it is 11:24 < reubenbond> For argument's sake, what if I were doing it for more 11:25 < reubenbond> http://golang.org/pkg/encoding/binary/ 11:25 < reubenbond> Is that the correct URL? 11:25 < wrtp> yup 11:25 < wrtp> the ByteOrder interface shows you the methods. 11:25 < wrtp> and LittleEndian and BigEndian implement those methods 11:25 < reubenbond> I get it 11:25 < reubenbond> thanks 11:26 -!- niemeyer [~niemeyer@201-40-141-234.pltce701.dsl.brasiltelecom.net.br] has joined #go-nuts 11:26 < reubenbond> You seemed to indicate that there might be a faster way? 11:26 < wrtp> no, not faster, just easier for more complex data structures 11:26 < reubenbond> would that be using gobs? 11:27 < wrtp> well, you could use gobs, but not if you're trying to interoperate with an externally defined data format 11:27 -!- vinisterx [~ryan@74-129-194-67.dhcp.insightbb.com] has joined #go-nuts 11:27 < reubenbond> alright, gobs or JSON or something similar then 11:27 < wrtp> you can use encoding/binary to write encoded data structures to a bytes.Buffer 11:28 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-165-157.clienti.tiscali.it] has joined #go-nuts 11:28 < wrtp> why do you want to serialise some ints anyway? 11:29 < reubenbond> Thanks, I see how that method would work. I want to serialise them because I want to write a networking library 11:29 -!- DerHorst [~Horst@e176107058.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds] 11:31 < wrtp> what do you mean by a "networking library" 11:31 < wrtp> ? 11:31 < reubenbond> one based on UDP, intended for writing P2P apps 11:32 < reubenbond> Well, I need something to handle retransmission, congestion control, ordering, message separation 11:33 < wrtp> if you're just talking to yourself, then you're free to choose any format. 11:34 < wrtp> gob works quite well, and is good for backwards compatibility 11:34 < wrtp> (but the format may change in the future) 11:35 < reubenbond> I know. I was just asking out of curiosity. I'll likely use gobs for the overlay network 11:38 < wrtp> the thing to be aware of with gobs, particularly if you're dealing with UDP packets, is that it serialises the types first, then the values. you'd need to create a new Encoder for each UDP packet. 11:41 < reubenbond> I'll serialise into bytes and split over multiple packets - but I'll just do my own simple encoding for the UDP packets 11:41 < reubenbond> and they'll wrap more interesting values 11:44 -!- daxt [~daxt@112.135.66.216] has joined #go-nuts 11:54 -!- shishberg [~davemc@alcor.dreamhost.com] has joined #go-nuts 11:55 -!- shishberg [~davemc@alcor.dreamhost.com] has quit [Client Quit] 11:59 -!- mncaudill [~nolan@c-67-188-35-154.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds] 12:01 -!- mncaudill [~nolan@c-67-188-35-154.hsd1.ca.comcast.net] has joined #go-nuts 12:02 -!- tensorpudding [~user@99.23.127.179] has quit [Remote host closed the connection] 12:05 -!- snearch [~snearch@f053004182.adsl.alicedsl.de] has quit [Remote host closed the connection] 12:07 -!- rlab [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 12:09 -!- creack [~charme_g@163.5.84.215] has quit [Ping timeout: 276 seconds] 12:10 -!- LuitvD [~me@beigetower/luitvd] has joined #go-nuts 12:14 -!- Electric_Brain [~gerard@73.77.221.87.dynamic.jazztel.es] has joined #go-nuts 12:18 -!- boscop [~boscop@g227000139.adsl.alicedsl.de] has joined #go-nuts 12:23 -!- virtualsue [~chatzilla@nat/cisco/x-rpdagvqzfpzmrqov] has joined #go-nuts 12:29 -!- xash [~xash@d073018.adsl.hansenet.de] has joined #go-nuts 12:34 -!- _nil [~aiden@c-24-147-65-44.hsd1.ma.comcast.net] has quit [Ping timeout: 255 seconds] 12:35 -!- _nil [~aiden@c-24-147-65-44.hsd1.ma.comcast.net] has joined #go-nuts 12:37 -!- tvw [~tv@212.79.9.150] has joined #go-nuts 12:55 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has quit [Ping timeout: 260 seconds] 12:58 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has joined #go-nuts 13:03 -!- reubenbond [~reubenbon@220-253-2-173.VIC.netspace.net.au] has quit [Ping timeout: 264 seconds] 13:13 -!- ExtraSpice [~XtraSpice@88.118.33.48] has quit [Read error: Connection reset by peer] 13:18 -!- lewis1711 [~lewis@125-239-255-244.jetstream.xtra.co.nz] has quit [Quit: Leaving.] 13:22 -!- DarthShrine [~angus@pdpc/supporter/student/DarthShrine] has quit [Quit: DarthShrine] 13:26 -!- gr0gmint [~quassel@87.60.23.38] has joined #go-nuts 13:43 -!- skelterjohn [~jasmuth@c-68-45-238-234.hsd1.nj.comcast.net] has quit [Quit: skelterjohn] 13:45 -!- Aivars [~chatzilla@84.237.224.172] has joined #go-nuts 13:50 -!- daxt [~daxt@112.135.66.216] has quit [Ping timeout: 240 seconds] 13:51 -!- klavs [~chatzilla@84.237.224.172] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]] 13:51 -!- daxt [~daxt@112.135.77.97] has joined #go-nuts 14:03 -!- skejoe [~skejoe@188.114.142.162] has joined #go-nuts 14:07 -!- daxt_ [~daxt@112.135.75.251] has joined #go-nuts 14:07 -!- jhawk28 [~jhawk28@user-387c58d.cable.mindspring.com] has joined #go-nuts 14:09 -!- daxt [~daxt@112.135.77.97] has quit [Ping timeout: 260 seconds] 14:09 -!- jhawk28 [~jhawk28@user-387c58d.cable.mindspring.com] has quit [Read error: Connection reset by peer] 14:17 -!- d2biG [p@irc.kaer.tk] has quit [Quit: leaving] 14:21 -!- creack [~charme_g@163.5.84.215] has joined #go-nuts 14:28 -!- dRbiG [p@irc.kaer.tk] has joined #go-nuts 14:32 -!- iant [~iant@216.239.45.130] has quit [Ping timeout: 260 seconds] 14:32 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has joined #go-nuts 14:32 -!- outworlder [~stephen@189.90.170.251] has joined #go-nuts 14:35 -!- daxt [~daxt@112.135.74.161] has joined #go-nuts 14:37 -!- daxt_ [~daxt@112.135.75.251] has quit [Ping timeout: 264 seconds] 14:40 -!- LeNsTR [~lenstr@unaffiliated/lenstr] has quit [Quit: LeNsTR] 14:43 < zozoR> i love looking at the build status page 14:43 < aiju> which one? 14:43 < zozoR> http://godashboard.appspot.com/ 14:44 < aiju> haha 14:44 < zozoR> it likes, you get happy for all the progress 14:44 < aiju> linux arm fail fail fail fail 14:44 -!- iant [~iant@67.218.105.75] has joined #go-nuts 14:44 -!- mode/#go-nuts [+v iant] by ChanServ 14:44 < zozoR> i just like that something happens everyday 14:44 < zozoR> they even work sunday lol 14:45 < aiju> darwin support disappeared :O 14:45 < skelterjohn> only for 386 14:45 < zozoR> hurray :D 14:45 < zozoR> anyway, what does a function pointer look like in go 14:45 < zozoR> i dont think i've seen one yet 14:45 < skelterjohn> how old does a mac have to be to run a 386? 14:45 < aiju> orange and furry 14:45 < skelterjohn> var a func() 14:45 < zozoR> :D 14:46 < skelterjohn> a is now a function 14:46 < skelterjohn> you can call it 14:46 < skelterjohn> a() 14:46 < aiju> now you're thinking with pointers 14:46 < skelterjohn> var a *func() 14:46 < aiju> (i should use that phrase in a tutorial) 14:46 < zozoR> func foo(a func(a int, b int)(int)) {/*CODE*/} 14:46 < zozoR> ? 14:46 < skelterjohn> yes, that would work 14:46 < aiju> i'd recommend naming that type 14:46 < skelterjohn> readability does demand it 14:47 < zozoR> the int? 14:47 < aiju> the func(int,int)(int) 14:47 < skelterjohn> type MyFunc func(a, b int) (int) 14:47 < skelterjohn> then 14:47 < aiju> somehow Go function pointers manage to be less readable than C 14:47 < skelterjohn> func foo(a MyFunc) {...} 14:47 < zozoR> oh that way 14:47 < aiju> or i'm just used to the latter 14:47 < zozoR> makes sense 14:48 < zozoR> thanks :) 14:48 < aiju> void foo(int (*a)(int,int)) 14:48 <+iant> aiju: try writing a function type that returns a function type in Go or C 14:48 < aiju> i'd name that in either language 14:48 < skelterjohn> aiju: that is the same as MyFunc? 14:48 < skelterjohn> that is bizarre 14:48 < aiju> skelterjohn: should be 14:48 < aiju> two int arguments and int return type 14:49 < aiju> old C is cute, where int was optional 14:49 < skelterjohn> that does not seem more readable than the go version, to me 14:49 < aiju> foo(a,b) {} 14:49 < aiju> skelterjohn: i said, i might be just used to it 14:49 < aiju> esp. the infamous void (*)(void*) 14:51 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Ping timeout: 255 seconds] 14:51 -!- ExtraSpice [~XtraSpice@88.118.33.48] has joined #go-nuts 14:53 < skelterjohn> that's a function with return type void*? 14:53 < aiju> no with argument void* 14:53 < aiju> return_type (*name)(arguments) 14:54 < skelterjohn> yeah.... i'm gonna go ahead and declare go's version more readable 14:54 < aiju> it would have been interesting if there was no func keyword in Go 14:55 < skelterjohn> quite a "what if"! 14:55 < aiju> foo(a, b int) int {} 14:55 <+iant> all top level constructs are introduced by a keyword 14:55 <+iant> for a while we actually had function types be introduced just by '(', without requiring a func keyword 14:56 <+iant> but then we realized we had to permit parenthesizing types in some cases 14:56 < aiju> but? 14:56 < aiju> oh 14:57 < Namegduf> I like function types in Go. They mirror the declaration of a function of that type. 14:57 < Namegduf> "close enough" that I can parse them immediately, unlike C, at least. 14:57 < Namegduf> That could just be a lack of practice thing, though. 14:57 < wrtp> aiju: even worse than iant's example, IMO, try declaring an array of function pointers in C. 14:58 < skelterjohn> it isn't "type (*name)(args)*"? 14:59 < wrtp> skelterjohn: is that supposed to be C? 14:59 < skelterjohn> uh 14:59 < skelterjohn> in the same line as what aiju said earlier, "return_type (*name)(arguments)" 14:59 < skelterjohn> just 14:59 < skelterjohn> return_type (*name)(arguments)* 15:01 < skelterjohn> feel free to make fun of me 15:01 < skelterjohn> i don't offend easily 15:01 < wrtp> int (*p[5])() 15:02 < wrtp> skelterjohn: sorry, i just didn't know if you were responding to me 15:02 < skelterjohn> but, if you had type MyFoo int (*p)() 15:02 < wrtp> the only reasonable way to do it in C is to use typedefs 15:03 < skelterjohn> typedef, right 15:03 < skelterjohn> i haven't written C/C++ in a very long time 15:03 < skelterjohn> couple years now 15:03 < wrtp> skelterjohn: do you mean typedef int (*myfoo)() ? 15:03 < skelterjohn> heh 15:03 < skelterjohn> who knows 15:03 < skelterjohn> i give up 15:03 < aiju> int (*p[5])() doesn't look too bad to me 15:04 < aiju> but anyway, i like Go's style better 15:04 < aiju> [5]func p() (int) i suppose 15:04 < wrtp> yup 15:04 -!- sauerbraten [~sauerbrat@p508CE6E3.dip.t-dialin.net] has joined #go-nuts 15:04 < wrtp> aiju: i thought you found C fn pointers more readable than Go's :-) 15:07 < aiju> no 15:07 < aiju> don't interpret too much shit into what i say 15:07 < aiju> i say "i don't think C THAT bad" 15:07 < aiju> *is 15:07 < wrtp> aiju: actually in go it's var p [5]func() int 15:07 < wrtp> the name always comes at the start 15:07 < aiju> yeah 15:08 < wrtp> http://c-faq.com/decl/spiral.anderson.html 15:09 < aiju> i think i just got used to C 15:10 -!- clip9 [clip9@er.en.svarteper.com] has joined #go-nuts 15:10 < aiju> and if you do weird things with function pointers it's best to name them, in Go as well 15:12 < skelterjohn> "aiju: somehow Go function pointers manage to be less readable than C" 15:12 < skelterjohn> just sayin' O:-) 15:13 < aiju> skelterjohn: well, and then after that i said "or i just got used to C 15:13 < aiju> +" 15:13 < aiju> http://p.remotehost.co/pastes/2011-01-11T10:13:16.raw 15:13 < aiju> if you ever wanna be really mean :D 15:14 < skelterjohn> i am easily confused 15:14 < skelterjohn> when people try 15:15 -!- clip9 [clip9@er.en.svarteper.com] has quit [Remote host closed the connection] 15:26 -!- viirya [~viirya@cml506-25.csie.ntu.edu.tw] has joined #go-nuts 15:27 -!- kanru [~kanru@114-45-237-190.dynamic.hinet.net] has joined #go-nuts 15:29 -!- clip9 [clip9@er.en.svarteper.com] has joined #go-nuts 15:32 < skelterjohn> i wish googlecode tracked checkouts and downloadds 15:34 -!- clip9 [clip9@er.en.svarteper.com] has quit [Remote host closed the connection] 15:36 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts 15:38 -!- femtoo [~femto@95-89-196-149-dynip.superkabel.de] has joined #go-nuts 15:39 -!- Project-2501 [~Marvin@82.84.77.103] has joined #go-nuts 15:41 -!- teejae [~teejae@softbank219185095092.bbtec.net] has joined #go-nuts 15:42 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Read error: Connection reset by peer] 15:42 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-165-157.clienti.tiscali.it] has quit [Ping timeout: 240 seconds] 15:43 -!- araujo [~araujo@gentoo/developer/araujo] has joined #go-nuts 15:52 -!- ExtraSpice [~XtraSpice@88.118.33.48] has quit [Quit: Leaving] 15:56 -!- shvntr [~shvntr@116.26.130.138] has quit [Quit: leaving] 16:01 -!- iant [~iant@67.218.105.75] has quit [Quit: Leaving.] 16:02 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Read error: Connection reset by peer] 16:03 -!- araujo [~araujo@gentoo/developer/araujo] has joined #go-nuts 16:06 -!- markcol [~markcol@74.125.59.1] has joined #go-nuts 16:08 -!- awidegreen [~quassel@c-eacae555.08-2-73746f39.cust.bredbandsbolaget.se] has joined #go-nuts 16:13 -!- ildorn [~ildorn@dslb-088-067-144-207.pools.arcor-ip.net] has quit [Quit: Leaving.] 16:15 -!- artefon [~thiago@dhcp16.usuarios.dcc.ufmg.br] has joined #go-nuts 16:16 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 16:17 -!- ildorn [~ildorn@dslb-088-067-144-207.pools.arcor-ip.net] has joined #go-nuts 16:19 -!- petrux [~petrux@host16-224-static.53-82-b.business.telecomitalia.it] has quit [Quit: leaving] 16:20 -!- ExtraSpice [~XtraSpice@88.118.33.48] has joined #go-nuts 16:20 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Quit: Leaving.] 16:26 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3] 16:39 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has quit [Quit: skelterjohn] 16:45 -!- LeNsTR [~lenstr@unaffiliated/lenstr] has joined #go-nuts 16:46 -!- napsy [~luka@88.200.96.18] has joined #go-nuts 16:47 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has joined #go-nuts 16:50 -!- binarypie [~binarypie@adsl-99-37-224-209.dsl.pltn13.sbcglobal.net] has joined #go-nuts 16:51 -!- skejoe [~skejoe@188.114.142.162] has quit [Quit: Lost terminal] 16:53 -!- xash [~xash@d073018.adsl.hansenet.de] has quit [Ping timeout: 240 seconds] 16:55 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts 17:00 -!- femtoo [~femto@95-89-196-149-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 17:12 -!- ildorn [~ildorn@dslb-088-067-144-207.pools.arcor-ip.net] has quit [Quit: Leaving.] 17:15 -!- iant [~iant@nat/google/x-jfcwszpanfjgnykq] has joined #go-nuts 17:15 -!- mode/#go-nuts [+v iant] by ChanServ 17:26 -!- kanru [~kanru@114-45-237-190.dynamic.hinet.net] has quit [Ping timeout: 272 seconds] 17:27 -!- saschpe [~quassel@opensuse/member/saschpe] has joined #go-nuts 17:27 -!- keithcascio [~keithcasc@nat/google/x-lqttkxjaxstywdmz] has joined #go-nuts 17:31 -!- wrtp [~rog@92.17.51.127] has quit [Quit: wrtp] 17:33 -!- Venom_X [~pjacobs@75.92.43.21] has joined #go-nuts 17:36 -!- zozoR [~zozoR@56346ed3.rev.stofanet.dk] has quit [Quit: Morten. Desu~] 17:44 -!- Tbb__ [~tbb__@HSI-KBW-109-193-104-005.hsi7.kabel-badenwuerttemberg.de] has joined #go-nuts 17:58 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has joined #go-nuts 17:58 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has left #go-nuts [] 18:09 -!- nettok [~quassel@200.119.153.237] has joined #go-nuts 18:11 -!- BlaSux [7f000001@69.195.144.4] has quit [Ping timeout: 255 seconds] 18:12 -!- ildorn [~ildorn@dslb-088-067-144-207.pools.arcor-ip.net] has joined #go-nuts 18:21 -!- BlaSux [7f000001@69.195.144.4] has joined #go-nuts 18:22 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts 18:30 -!- femtoo [~femto@95-89-196-149-dynip.superkabel.de] has joined #go-nuts 18:31 -!- daxt [~daxt@112.135.74.161] has quit [Remote host closed the connection] 18:34 -!- saschpe [~quassel@opensuse/member/saschpe] has quit [Remote host closed the connection] 18:47 -!- virtualsue [~chatzilla@nat/cisco/x-rpdagvqzfpzmrqov] has quit [Ping timeout: 265 seconds] 18:51 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts 18:53 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3] 18:55 -!- rbraley [~rbraley@ip72-222-134-229.ph.ph.cox.net] has quit [Ping timeout: 265 seconds] 19:12 -!- rbraley [~rbraley@ip72-222-134-229.ph.ph.cox.net] has joined #go-nuts 19:12 -!- BlaSux [7f000001@69.195.144.4] has quit [Remote host closed the connection] 19:13 -!- BlaSux [7f000001@69.195.144.4] has joined #go-nuts 19:14 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:54e3:9fed:74fd:52e7] has joined #go-nuts 19:19 -!- dforsyth_ [~dforsyth@bastion.inap.yelpcorp.com] has quit [Quit: Updating Textual - http://www.codeux.com/textual/ — :-)] 19:19 -!- nettok_ [~quassel@200.119.165.154] has joined #go-nuts 19:21 -!- nettok [~quassel@200.119.153.237] has quit [Ping timeout: 240 seconds] 19:26 -!- grouzen [~grouzen@ip23-159.200.109.crimea.com] has quit [Ping timeout: 272 seconds] 19:28 -!- Fish- [~Fish@9fans.fr] has joined #go-nuts 19:30 -!- artefon [~thiago@dhcp16.usuarios.dcc.ufmg.br] has quit [Quit: bye] 19:36 -!- clip9 [clip9@er.en.svarteper.com] has joined #go-nuts 19:41 -!- salty [~kvirc@d24-141-238-88.home.cgocable.net] has joined #go-nuts 19:41 -!- clip9 [clip9@er.en.svarteper.com] has quit [Remote host closed the connection] 19:41 < salty> Hello 19:42 < temoto> o/ 19:43 < salty> I am wondering, is gis a go executable portable? can i run on windows? 19:43 < skelterjohn> gis? google image search? 19:43 -!- Eridius [~kevin@unaffiliated/eridius] has joined #go-nuts 19:44 < exch> If the executable has been compiled for anything other than windows, then no 19:45 < salty> Well, its compiled on Linux. I just don't understand really if its statically linked, 19:46 < salty> ... does it use the OSes tcp/ip stack. a 19:46 < jumzi> lol, if that isn't clear to you... you should read up on binary formats 19:46 < exch> Go does static linked for all it's stuff. But in order to run it on windows, you need to compile it with the windows compiler 19:46 < jumzi> (why you have to compile it for windows) 19:46 < jumzi> also 19:46 < salty> oh, ok, this is elf versus windows binary format ? 19:47 < salty> i'll read up on them 19:47 < jumzi> Yeah and more 19:47 < exch> This is why Go comes with a bunch of different compilers and linkers. 6g/l for linux, 8g/l for windows, etc 19:48 < exch> Whichever target you are actually compiling to, is determined by the GOOS and GOARCH environment variables you set 19:48 < salty> Oh ok, I get it. So 19:50 < salty> I was reading online a bit, is there a way to link a Go program to a C executable and call it? 19:50 < salty> All i see sorta like this is misc/cgo/life 19:52 < exch> cgo is a separate compiler which does allow you to 'bind' C code into your Go application. Afaik, this is the only situation where Go allows dynamic linking of existing C libraries 19:52 < cbeck> A C library, or an already linked executable? 19:52 < cbeck> for an already linked executable, you'll probably just use the exec pkg 19:53 < exch> Alternatively, you can use SWIG. It's a bit more complicated imho, but also allows wrapping of c++ code. Cgo doesn't do that 19:54 < salty> I'd like a single executable. 19:54 -!- tvw [~tv@212.79.9.150] has quit [Remote host closed the connection] 19:54 < cbeck> Then SWIG or cgo is your best bet 19:54 < salty> Either linked / binded by function call, or somhow link Go executable to C executable and call the Go from C (not sure if that's possibl) 19:54 < salty> ok, yes I was looking at SWIG too 19:56 < salty> Ok, thanks for the input exch, iumzi and cbeck 19:56 < salty> I'm on the right track with the things I'm looking at 19:56 -!- outworlder [~stephen@189.90.170.251] has quit [Remote host closed the connection] 19:56 < jumzi> what w8 19:57 < jumzi> look at the exec pkg first 19:57 -!- outworlder [~stephen@189.90.170.251] has joined #go-nuts 19:57 < salty> Yes... exec is the only thing I haven't started looking at, so will do that first, ty 20:00 -!- clip9 [clip9@er.en.svarteper.com] has joined #go-nuts 20:01 -!- femtooo [~femto@95-89-196-149-dynip.superkabel.de] has joined #go-nuts 20:01 < exch> Here's an example of Go linking with a C library (libvlc). It's prolly a bit complicated if you are not used to cgo, but it shows how this works. https://github.com/jteeuwen/go-pkg-libvlc 20:04 -!- femtoo [~femto@95-89-196-149-dynip.superkabel.de] has quit [Ping timeout: 240 seconds] 20:06 < salty> Ok thanks. From what I see, (by the way),swig allows me to call c from go, not other way around 20:07 < aiju> salty: please explain exactly what you want to do 20:08 < cbeck> Calling Go from C is not currently possible from what I know 20:08 < aiju> cbeck: it's perfectly possible 20:08 < aiju> it's just hairy 20:09 < cbeck> Except via a rigged up callback setup 20:09 < cbeck> Fair 20:09 < exch> Swig also does callbacks from C into Go, but from what little I've seen in trying it out, it's rather convoluted. Cgo also used to have a hack to allow callbacks, but those to required some black magic. Not sure if they are still possible though 20:09 < jumzi> WHY GO TROUGH ALL THIS TROUBLE!? 20:09 < aiju> why _GO_ haha! 20:09 < cbeck> s/possible/feasible/ perhaps 20:09 < cbeck> aiju: Booooooo 20:09 < salty> I would like my C program to run a go executable. But I just want a single executable. 20:10 < salty> So, I have to link them somewhow, and have C call a go routine. 20:10 < aiju> cbeck: just playing with what jumzi said 20:10 < aiju> salty: why do you want a single executale? 20:10 < jumzi> You should want a dynamic linked super executable! 20:10 * cbeck vomits 20:10 < salty> I'm looking at embedded things 20:10 < salty> maybe without a file system 20:11 < jumzi> ok things just makes less and less sense 20:11 < salty> lol, super executable? That sounds perfect. 20:11 < jumzi> Yeah, it got allot of cloud power too 20:11 < salty> Sorry. Ok. I just want to call Go from C. 20:11 < aiju> exec 20:11 < jumzi> don't? 20:11 < salty> I'll look at exch's uadvice up a bit ago. And exec package 20:12 < jumzi> nope 20:12 < jumzi> if you want to call GO from C 20:12 < jumzi> i'm now assuming you want to use a go executable 20:13 < jumzi> just call it like you would any other executable 20:13 < jumzi> it's all machine code in the end 20:13 -!- vinisterx [~ryan@74-129-194-67.dhcp.insightbb.com] has quit [Ping timeout: 240 seconds] 20:13 < skelterjohn> salty: typically you cannot combine two executables into a single executable 20:13 < skelterjohn> which one gets executed when you run it? 20:13 < salty> I know. This is why i'm having difficulty 20:13 < jumzi> well i usually wrap things in shelsscripts 20:14 < jumzi> shellscripts* 20:14 < aiju> salty: what do you need C code for? 20:14 < jumzi> I'm backing up aiju here, you could probably take another approach 20:14 < jumzi> unless your one of those curious ppl that has todo it "because" 20:15 < salty> lol, no iumzi, this isn't a mission impossible mission 20:15 < aiju> salty: explain 20:16 < salty> oh sorry aiju, the C code is doing things unrelated, bu 20:16 < salty> but needs to happen to iniitalize the OS 20:17 < aiju> sorry, but what the fuck? 20:17 < aiju> oic 20:17 < salty> I'm going to ask again in a while when I have more specifics 20:17 < aiju> does it compile with 8c? 20:17 -!- femtooo [~femto@95-89-196-149-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 20:17 < salty> I haven't checked. 20:17 < salty> I have a lot of things to look into / think about just from asking here, so i'll do this and maybe have better question later. 20:17 < aiju> it might be messy, but this should definitely work 20:18 -!- vinisterx [~ryan@74-129-194-67.dhcp.insightbb.com] has joined #go-nuts 20:19 < skelterjohn> famous last words 20:19 < aiju> haha 20:19 < temoto> Does string([]byte_var) creates a copy of those bytes or refers to same buffer? 20:19 < aiju> since strings are immutable probably the former 20:20 < skelterjohn> i believe, since strings are immutable and []byte_var is not, that it will create a copy 20:20 < skelterjohn> damn 20:20 < skelterjohn> too many words 20:20 < aiju> it could also do some funny copy-on-write stuff but i hardly think so 20:21 -!- waqas [~waqas@jaim.at] has joined #go-nuts 20:24 -!- WonTu [~WonTu@p57B52FA5.dip.t-dialin.net] has joined #go-nuts 20:25 -!- WonTu [~WonTu@p57B52FA5.dip.t-dialin.net] has left #go-nuts [] 20:28 -!- jhawk28 [~jhawk28@user-387c58d.cable.mindspring.com] has joined #go-nuts 20:29 -!- markcol [~markcol@74.125.59.1] has quit [Quit: markcol] 20:35 -!- deso_ [~deso@x0561a.wh30.tu-dresden.de] has joined #go-nuts 20:35 < teejae> hey guys 20:35 < teejae> http://pastebin.com/Dwfjx0AC 20:36 < teejae> still trying to get some pseudo duck typing going here 20:36 < aiju> why would you do that 20:36 < teejae> aiju: for that thrift compiler i was working on 20:36 < aiju> Go has duck typing, called interfaces 20:36 < teejae> aiju: the "exceptions" 20:37 < teejae> so in my pastebin, i should just convert type A to be an interface? 20:39 -!- Netsplit *.net <-> *.split quits: Soultaker, yebyen, impl, dju, tux21b, grncdr, arun, KBme, leczb, cco3-hampster, (+7 more, use /NETSPLIT to show all of them) 20:39 -!- dju_ [dju@fsf/member/dju] has joined #go-nuts 20:39 -!- Natch| [~natch@c-2bcfe155.25-4-64736c10.cust.bredbandsbolaget.se] has quit [Read error: Operation timed out] 20:40 -!- Natch| [~natch@c-2bcfe155.25-4-64736c10.cust.bredbandsbolaget.se] has joined #go-nuts 20:40 -!- Netsplit over, joins: pothos 20:41 -!- BlaSux [7f000001@69.195.144.4] has joined #go-nuts 20:41 -!- araujo [~araujo@gentoo/developer/araujo] has joined #go-nuts 20:41 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has joined #go-nuts 20:41 -!- arun [~arun@unaffiliated/sindian] has joined #go-nuts 20:41 -!- cco3-hampster [~conleyo@nat/google/x-mhnhqrwzlrhgtnjp] has joined #go-nuts 20:41 -!- impl [impl@atheme/member/impl] has joined #go-nuts 20:41 -!- KBme [~KBme@9angled-2-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined #go-nuts 20:41 -!- aiju [~aiju@unaffiliated/aiju] has joined #go-nuts 20:41 -!- leczb [~leczb@nat/google/x-ttguwiazilstnvfi] has joined #go-nuts 20:41 -!- yebyen [~yebyen@martyfunkhouser.csh.rit.edu] has joined #go-nuts 20:41 -!- Soultaker [~Soultaker@hell.student.utwente.nl] has joined #go-nuts 20:41 -!- mpl [~mpl@smgl.fr.eu.org] has joined #go-nuts 20:41 -!- zeroXten [~zeroXten@0x10.co.uk] has joined #go-nuts 20:41 -!- tux21b [~christoph@pyhost.srv.tux21b.org] has joined #go-nuts 20:41 -!- grncdr [~stephen@sdo.csc.UVic.CA] has joined #go-nuts 20:42 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has quit [Max SendQ exceeded] 20:48 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has joined #go-nuts 20:51 -!- fenicks [~christian@log77-3-82-243-254-112.fbx.proxad.net] has joined #go-nuts 20:52 -!- photron [~photron@port-92-201-12-254.dynamic.qsc.de] has quit [Ping timeout: 246 seconds] 20:55 -!- dforsyth_ [~dforsyth@bastion.inap.yelpcorp.com] has joined #go-nuts 20:55 -!- jhawk28 [~jhawk28@user-387c58d.cable.mindspring.com] has quit [Quit: Leaving...] 20:56 < temoto> Yeah, creates copy, i tested it. 21:01 -!- c9s_ [~c9s@59-126-64-204.HINET-IP.hinet.net] has quit [Ping timeout: 240 seconds] 21:03 -!- derferman_ [~derferman@24-176-188-13.static.reno.nv.charter.com] has joined #go-nuts 21:06 -!- c9s [~c9s@59-126-64-204.HINET-IP.hinet.net] has joined #go-nuts 21:10 -!- gr0gmint [~quassel@87.60.23.38] has quit [Remote host closed the connection] 21:13 -!- LeNsTR [~lenstr@unaffiliated/lenstr] has quit [Read error: Connection reset by peer] 21:13 -!- LeNsTR [~lenstr@unaffiliated/lenstr] has joined #go-nuts 21:14 -!- Kashia [~Kashia@port-92-200-125-182.dynamic.qsc.de] has joined #go-nuts 21:20 < teejae> aiju: thanks, have made it into an interface 21:20 < teejae> seems to do the trick 21:24 -!- tensorpudding [~user@99.23.127.179] has joined #go-nuts 21:25 -!- vinisterx [~ryan@74-129-194-67.dhcp.insightbb.com] has quit [Read error: Connection reset by peer] 21:26 -!- vinisterx [~ryan@74-129-194-67.dhcp.insightbb.com] has joined #go-nuts 21:30 -!- ildorn [~ildorn@dslb-088-067-144-207.pools.arcor-ip.net] has quit [Quit: Leaving.] 21:32 -!- sauerbraten [~sauerbrat@p508CE6E3.dip.t-dialin.net] has quit [Remote host closed the connection] 21:33 -!- teejae [~teejae@softbank219185095092.bbtec.net] has quit [Quit: teejae] 21:34 -!- bmizerany [~bmizerany@adsl-99-189-162-6.dsl.pltn13.sbcglobal.net] has joined #go-nuts 21:36 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:54e3:9fed:74fd:52e7] has quit [Quit: Leaving.] 21:46 -!- emjayess [~emjayess@pix1.i29.net] has joined #go-nuts 21:58 -!- Fish- [~Fish@9fans.fr] has quit [Quit: So Long, and Thanks for All the Fish] 22:02 -!- waqas [~waqas@jaim.at] has left #go-nuts [] 22:02 -!- ildorn [~ildorn@dslb-088-067-144-207.pools.arcor-ip.net] has joined #go-nuts 22:04 -!- nettok_ [~quassel@200.119.165.154] has quit [Read error: Connection reset by peer] 22:04 -!- tvw [~tv@e176008039.adsl.alicedsl.de] has joined #go-nuts 22:04 -!- outworlder [~stephen@189.90.170.251] has quit [Quit: Leaving.] 22:10 -!- ildorn [~ildorn@dslb-088-067-144-207.pools.arcor-ip.net] has quit [Quit: Leaving.] 22:11 -!- rlab [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 22:11 -!- awidegreen [~quassel@c-eacae555.08-2-73746f39.cust.bredbandsbolaget.se] has quit [Remote host closed the connection] 22:18 -!- petar [~petar@84-73-24-182.dclient.hispeed.ch] has joined #go-nuts 22:18 -!- Project-2501 [~Marvin@82.84.77.103] has quit [Quit: E se abbasso questa leva che succ...] 22:22 < petar> i was very glad to hear that go has not and will not implement exception handling.. and after reading the faq it became even clearer to my why i dislike garbling code with try/catch blocks and why its annoying when methods force me to do something about something i do not care about 22:22 < aiju> petar: there *is* panic/recover :P 22:23 * petar looks it up 22:23 < exch> There's no reason you should use it if you dont want to though :) 22:23 < Soultaker> you'd rather garble code with error propagation logic, which you are forced to handle because the caller might care, even if you don't? 22:23 < aiju> petar: pretty much like exceptions, but up to you 22:24 < exch> it is handy for servers where external factors can throw panics, but you don't want the server to die outright 22:24 < aiju> i.e. it's not used by the standard library except for really harsh stuff 22:24 < petar> Soultaker: well, thats what conventions and documentation is for, isn't it? 22:24 < exch> Also handy for high performance stuff like VM's where manually checking for err variables at every call adds significant overhead 22:24 < Namegduf> panic()/recover() is never used across package boundaries 22:25 < aiju> Namegduf: doesn't some init code in some libraries call it? 22:25 < Soultaker> petar: how do you figure? 22:25 < Namegduf> aiju: It won't assume a recover() 22:25 < exch> libraries really shouldn't use recover tbh 22:25 < Namegduf> aiju: A panic() escaping a panic() is equivalent to terminating the program aside that it can be blocked at a higher level 22:25 < Namegduf> Er, escaping a package 22:26 < aiju> yeah 22:26 < Namegduf> It's thus okay for impossible or programmer errors 22:26 < petar> Soultaker: even you follow a convention or read the docs if there is no convention.. i mean how were people handling errors until exception handling came along 22:26 < petar> s/even/either/ 22:26 < Namegduf> The lack of anything but termination conditions escaping other packages thus provides the benefit of lack of exceptions (ability to tell what's happening and what can have what errors) with the ability to use them where needed. 22:27 < Soultaker> well, with error propagation. 22:27 < aiju> UNIX had panic() lol 22:27 < Soultaker> but the point is that then you must check for and propagate any error returned by a function you call, in functions you write. 22:27 < Namegduf> If your code is garbled with error propagation it is bad code. 22:27 < Soultaker> because the code that calls your function might care. 22:27 -!- rbrewster [~rbrewster@pool-96-255-165-204.washdc.fios.verizon.net] has joined #go-nuts 22:28 < aiju> Namegduf: how so? 22:28 < Soultaker> the whole point of exceptions is that you only have to write catch-blocks at points where you actually want to handle the exception; propagation is automatic. 22:28 < petar> Soultaker: which also means that you get exceptions from layers which are way below your own 22:29 < Namegduf> aiju: Because your code does not separate I/O and other things which should legitimately error from logic at all 22:29 < Soultaker> which is why I found it surprising to see you complain about "garbling code" with try-catch blocks, because from my point of view, exception handling *saves* on the amount of boiler plate code you have to write. 22:29 < Soultaker> petar: sure, but if you can't handle those, you don't have to. 22:29 < exch> Namegduf: it's kinda hard to avoid. A significant portion of libraries have multiple returnv alues, of which one is the possible error. So your code will invariably be riddled with error checks. Not checkng them is bad behaviour imho. 22:30 < exch> arg. think I misunderstood your point. nvm 22:30 < petar> Soultaker: but you have to throw it around :) 22:30 < Namegduf> My point was that you should take input, feed it to logic, and then output 22:30 < Namegduf> Not have I/O buried at the bottom of your logic 22:30 < aiju> Namegduf: that's hardly a viable practice for all programs … 22:31 < Soultaker> petar: usually either you handle the exception or you ignore it (and it will go up implicitly) 22:31 < Namegduf> Not arguing for purity here, just saying that passing it up lots of layers is a design smell for other reasons 22:31 < petar> Soultaker: but you have to declare it when declaring the method 22:31 < Soultaker> but I agree with you that functions should document which exceptions can be raised (and should define a sensible set, rewrapping exceptions if necessary to give a simpler interface) 22:31 < petar> blah throws blahblah 22:31 < aiju> petar: what language is this? 22:31 < Soultaker> yes, ok. 22:31 < aiju> Java? 22:32 < petar> aiju: yes 22:32 < Soultaker> but in your case, you'd have to do that too, right? 22:32 < aiju> it's not required in neither C++ nor javascript 22:32 < Namegduf> The problem is that documenting what can be thrown is basically equivalent to error propagation overhead 22:32 < Soultaker> (in Java it's not required of RuntimeExceptions either) 22:32 < Namegduf> So you're not gaining that much. 22:32 < Soultaker> (those are things like OutOfMemory and DivisionByZero and NullPointerDereference or whatever those are called in Java) 22:33 < aiju> Go should be more appropriate for Gofy 22:33 < Soultaker> Namegduf: with the difference that you don't have to write the code to propagate them manually (it's a declarative approach) + the compiler checks for you that you either handle an exception, or declare it to be thrown. 22:33 < aiju> panic() should be renamed fuck() 22:33 < Soultaker> so you won't risk unintentionally ignoring error conditions. 22:34 < Namegduf> That's invalid on the grounds that not checking return values can still ignore bad results and it won't catch that. 22:34 < aiju> never happened to me 22:34 < Namegduf> You won't risk unintentionally ignoring *some* error conditions. 22:34 < petar> Soultaker: well, all i'm saying is that the try/catch block really mess up the flow of my code and throwing an exception around that some method forced on me just in order to finally run a simple chunk of code is annoying 22:34 < Soultaker> petar: I'm guessing you are working with Java then? 22:34 < petar> yes 22:34 < Soultaker> I would agree with you that Java tends to go a bit overboard with exceptions, using them for many "normal" and expected failure cases. 22:34 < Namegduf> In practice, Go is largely similar because the functions you care about tend to return things you're interested in as well 22:34 < petar> ok, i guess there are friendlier implementations then 22:35 < Namegduf> And you have to explicitly assign to _ to ignore a return value when you're getting others. 22:35 < skelterjohn> the only thing i don't like about the (val, err) return types is that it means i can't nest those function calls 22:35 < Namegduf> You can. 22:35 < skelterjohn> i have to separate them onto multiple lines 22:35 < Soultaker> True I suppose. In that regard Go may be a little better than some other languages. 22:35 < aiju> i don't think the problem is unintentionally ignoring errors 22:36 < Namegduf> Oh, I misunderstood. 22:36 < Soultaker> Though functions like Write() can still be called without checking the return value at all. 22:36 < Namegduf> Yes, but your code won't work right at all 22:36 < aiju> Soultaker: that's something only a beginner would do 22:36 < Namegduf> You need to know how much you've written 22:36 < skelterjohn> <- a beginner, then O:-) 22:37 < Namegduf> As Write() does not guarantee to have written it all even if successful. 22:37 -!- cafesofie [~cafesofie@dhcp-140-254-204-170.osuwireless.ohio-state.edu] has joined #go-nuts 22:37 < aiju> using Read / Write without a return value should be very noticable to the intermediate 22:37 < Soultaker> aiju: you say that, but e.g. GCC and glibc have recently added warnings to the compiler output when functions like fwrite() and fread() are used without checking the return value 22:38 < Soultaker> I assume they did that because people in reality actually use these functions without checking those results 22:38 < Namegduf> I think the only thing that shows is that you can catch it, and Go specifically doesn't. 22:38 < aiju> or because they think it sounded like a good idea 22:38 < Namegduf> Because I don't want to check results for every Printf 22:38 < aiju> like usually 22:38 < Namegduf> Or every Fprintf 22:38 -!- DarthShrine [~angus@pdpc/supporter/student/DarthShrine] has joined #go-nuts 22:39 < Soultaker> I mean: this is C! You can shoot yourself in the foot in many ways. But apparently this was one case they felt needed better coverage (despite functions like fwrite() being ancient, which means programmers should be familiar with their use) 22:39 < aiju> *sigh* you can shoot your foot in any language 22:39 < Soultaker> I don't know what this says other than "this is important, and people are getting it wrong all the time" 22:39 < Namegduf> Unless it's on by default it doesn't say that at all. 22:39 < aiju> anyway, i stopped taking gcc and glibc seriously 22:39 < Namegduf> The warning existing says "someone wanted to check this and we thought it was a reasonable feature request". 22:39 <+iant> wait, it wasn't gcc and glibc that added that warning 22:40 <+iant> gcc and glibc created the feature and made it available for use by anybody who wanted it 22:40 <+iant> it was the Ubuntu distributors of gcc and glibc who decided to enable it by default 22:40 <+iant> which I think was a big mistake 22:40 <+iant> or maybe the Debian distributors, I'm not sure 22:41 < aiju> reminds me of the kind of shit microsoft compilers complain about 22:41 < Namegduf> GCC has warning options to complain about variables declared anywhere other than the start of a function 22:41 < Soultaker> it's enabled as part of -Wall, which is a lot less pedantic than -Wextra. 22:41 < aiju> Namegduf: i write my code by that style 22:41 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has quit [Quit: skelterjohn] 22:41 < Namegduf> That still doesn't indicate any particular level of importance being assigned to it. 22:42 < Namegduf> There are *lots* of warnings. 22:42 < aiju> but yeah, gcc has warnings for the weirdest things 22:42 < aiju> warning: code may fail if meteor hits computer 22:43 < Namegduf> I'm not sure what the point of this was, anyway. 22:43 < Soultaker> True, but the warnings that are enabled are about things that people really do get wrong all the time, or wouldn't you even agree with that? 22:43 < Namegduf> Was it that ignoring return values was a real problem? 22:43 < Namegduf> Because Java doesn't prevent that either. 22:43 < Namegduf> I doubt its Write() equivalent throws an exception on an incomplete Write, for example. 22:43 < aiju> Soultaker probably says it should 22:43 < Soultaker> In Java, if a write fails, it throws an exception, which you are then forced to handle (or declare explicitly to be rethrown) 22:44 < Namegduf> A write being incomplete is not a failure in any other language 22:44 < aiju> Soultaker: write can fail without failing 22:44 < aiju> Namegduf: isn't it one in Go? 22:44 < Namegduf> No. 22:44 < Soultaker> well ok, now we're just arguing when fwrite() should fail, which wasn't really the point I'm trying to make :) 22:44 < Namegduf> No, we're not. 22:44 -!- ymasory [~ymasory@c-76-99-55-224.hsd1.pa.comcast.net] has joined #go-nuts 22:45 < Namegduf> I'm making the point that ignoring return value which mean something will always be able to break the program. 22:45 < Namegduf> And adding exceptions for failure conditions is insufficient to resolve that. 22:46 < Soultaker> By that logic, all programming languages are equally usuable, because they can all fail, and nothing can be done to resolve that. 22:46 < Soultaker> I don't accept that kind of fatalism :) 22:46 < Namegduf> I don't follow. 22:46 < aiju> well, you CAN add exceptions for everything which you think should be noticed 22:46 -!- napsy [~luka@88.200.96.18] has quit [Quit: leaving] 22:47 < aiju> however whether that's a good idea is an entirely different matter … 22:47 < Namegduf> aiju: You can't throw an exception without interrupting the rest of the execution of the function and local flow 22:47 < Soultaker> Namegduf: adding exceptions may not fix all problems, but it may help avoid some (even a large number of them) 22:47 < aiju> or you could just check those damn return values 22:47 -!- deso_ [~deso@x0561a.wh30.tu-dresden.de] has quit [Remote host closed the connection] 22:48 < Namegduf> Soultaker: I'm dubious because the exact same functions suffer from the exact same kind of problem in both. 22:48 < Soultaker> aiju: I agree that the more rigorous your programmers are, the less of a benefit exceptions become. 22:48 < aiju> if it returns an os.Error it could also have THIS FUNCTION MAY FAIL BE SURE TO CHECK THE RETURN VALUE written in bold print in the docs 22:48 < Namegduf> Write() with its present interface with return values ignored would be an uncaught error in either 22:49 < Namegduf> I think we should use static analyis tools for that. 22:49 < Soultaker> Namegduf: so maybe for Go's write method (which maps fairly closely to the POSIX write system call, right?) exceptions may not be the best solution. 22:49 < aiju> *yuck* POSIX 22:49 < aiju> don't give them credit for something they didn't invent :P 22:50 < Soultaker> or UNIX, whatever you want. 22:50 < petar> is there a go resolver library or is one supposed to use libc for that purpose? 22:50 < aiju> "resolver"? 22:50 < Soultaker> name resolution I presume? 22:50 < aiju> you mean DNS? 22:50 < petar> hm, yea, like in resolv.h :) 22:51 < petar> dns yes 22:51 < aiju> net? 22:51 < KBme> yes, net. 22:51 * petar checks immediately 22:51 < aiju> net.LookupHost 22:51 < Namegduf> Soultaker: It's pretty much "the" example of something which may fail and needs to be checked, as it handles half of I/O, which is a big source of external failure, I think. 22:51 < Namegduf> Soultaker: So I think that it fails to solve the return value issue there is fairly good grounds to be dubious it has a significant effect on it. 22:52 < Soultaker> Namegduf: ok then, your exception could contain information about the number of bytes written. 22:52 < taruti> yuck 22:52 < Namegduf> Okay, so now whoever handles the exception needs to remember that and not assume the whole thing failed. 22:52 < Namegduf> They can still incorrectly ignore information. 22:52 < Namegduf> You just moved where it was. 22:53 < taruti> a partial write is not an error some of the time 22:53 < Soultaker> I think in 99% of the use cases, if a blocking write fails, then the whole operation should fail anyway. (this is what happens in Java too, probably.) 22:53 < Namegduf> A partial write is not a failure 22:53 < Namegduf> It is normal 22:53 < aiju> Java fails indepedently of that *scnr* 22:53 < Soultaker> and special code that is prepared to handle partial writes correctly (which is really the exception to the rule) can still catch the exception and recover. 22:54 < aiju> is there some Go function or other nicety to make sure everything has been written btw? 22:54 < Namegduf> A partial write is just one example of a side-effecty function returning something important that you need to act on 22:54 < Namegduf> And a failure to actually use it 22:54 < Soultaker> Namegduf: I wouldn't say that. I'm pretty sure that the vast majority of C programs does not handle partial writes at all. 22:55 < Namegduf> Er... correct ones using write() do. 22:55 < Namegduf> It will *routinely* return a partial write on network sockets 22:55 < Namegduf> It's not a rare thing 22:55 < Soultaker> I think most applications would rather use fwrite() but that behaves similarly. 22:55 < Namegduf> It happens whenever the OS can only write part of it for some reason. 22:55 < aiju> fwrite is an abomination :< 22:55 < Soultaker> I'm pretty sure it blocks by default? 22:55 < aiju> Soultaker: yeah 22:55 < Namegduf> Even blocking writes can partially succeed. 22:56 < Namegduf> Same as in Go (which ALSO blocks by default) 22:56 < aiju> any use for non-blocking I/O? except hogging CPU 22:56 < Soultaker> That might be technically true, but I can almost guarantee you that in practice most applications will either consider a partial write a failure and abort or (incorrectly!) ignore it. 22:56 < taruti> Go uses non-blocking underneath iirc 22:56 < Namegduf> And you'd be wrong. 22:56 < taruti> Soultaker: don't write such buggy code. 22:57 < aiju> non-blocking or asynchronous? 22:57 -!- derferman [~derferman@24-176-188-13.static.reno.nv.charter.com] has quit [Quit: derferman] 22:57 < Soultaker> aiju: for select()-based network servers, I assume. 22:57 < taruti> aiju: for sockets epoll 22:57 < taruti> in linux 22:57 < Namegduf> A server implementation which did that would fail randomly and regularly, I believe 22:57 < aiju> that's asynchronous I/O 22:57 < Namegduf> The OS tends to utilise its right to short writes when dealing with network I/O 22:58 < Soultaker> I don't think I've actually seen that happen though. 22:58 < aiju> btw this should be some kind of thing easily found by static analysis 22:58 -!- georgekollias [~georgekol@men75-1-81-57-41-176.fbx.proxad.net] has joined #go-nuts 22:58 < aiju> even with profane methods such as grep 22:58 < Soultaker> (I mean, except in cases when the socket is broken anyway) 22:59 < Namegduf> Failing to handle it in C is like failing to handle EINTR 23:00 -!- kamaji [~kamaji@cpc2-aztw22-2-0-cust775.aztw.cable.virginmedia.com] has quit [Quit: leaving] 23:00 < Soultaker> (I know write() can be interrupted, but fwrite() can't, can it?) 23:00 < aiju> grep '[^=] *Write' *.go … 23:01 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit: Verlassend] 23:01 < aiju> is there some idiomatic pattern in Go to handle Write? 23:02 < aiju> http://p.remotehost.co/pastes/2011-01-11T18:02:19.raw i use something like this in C but I don't like it 23:02 < aiju> (there is proper error handling coe for rc < 0 after that) 23:04 < Soultaker> are you re-entering the loop if errno == EINTR, like Namegduf wants? :P 23:06 < taruti> btw one can write paniccing wrappers for write if one wants to 23:07 < taruti> thus one can get the "exceptions" when one wants, while not saddling everyones code with exceptions 23:07 < aiju> most signals kill the program anyway 23:07 < Namegduf> I think I confused it with EAGAIN, or they're related in some way, perhaps. 23:07 < Namegduf> Not sure. 23:08 < Namegduf> Not important. 23:08 < aiju> EAGAIN is usually just an error they didn't find a better name for 23:08 -!- wrtp [~rog@92.17.51.127] has joined #go-nuts 23:08 < aiju> like "no free process slot" 23:08 < Namegduf> As for wrappers, you can do that within a package, idiomatically, whenever your structure is such that it's easier to propagate errors within a package that way. 23:08 < aiju> EINTR is the rare case of a system call interrupted by a signal 23:09 < aiju> i should probably write my own write which does everything nicely … 23:09 < aiju> i wish it was part of the standard library 23:09 < Namegduf> You just don't do it between packages and you can safely assume that just reading that package you understand all the panics-which-should-be-caught which can happen in it and its design for ensuring they are all caught. 23:09 < aiju> (both C and Go) 23:09 -!- fenicks [~christian@log77-3-82-243-254-112.fbx.proxad.net] has left #go-nuts [] 23:13 < aiju> http://p.remotehost.co/pastes/2011-01-11T18:13:33.raw 23:13 < aiju> odd that there is no such function in the library 23:13 < aiju> (yes i couldn't resisting writing old style C) 23:14 < aiju> uh should be a len parameter 23:14 * aiju has to go sleeping anyway 23:25 -!- petar [~petar@84-73-24-182.dclient.hispeed.ch] has quit [Ping timeout: 265 seconds] 23:26 -!- Eko [~eko@198.202.202.21] has joined #go-nuts 23:26 -!- petar [~petar@84-73-24-182.dclient.hispeed.ch] has joined #go-nuts 23:33 -!- Venom_X [~pjacobs@75.92.43.21] has quit [Quit: Venom_X] 23:34 -!- wrtp [~rog@92.17.51.127] has quit [Quit: wrtp] 23:36 -!- cafesofie [~cafesofie@dhcp-140-254-204-170.osuwireless.ohio-state.edu] has quit [Read error: Connection reset by peer] 23:36 -!- cafesofi_ [~cafesofie@dhcp-140-254-204-170.osuwireless.ohio-state.edu] has joined #go-nuts 23:47 -!- daxt [~daxt@112.135.95.172] has joined #go-nuts 23:55 -!- boscop [~boscop@g227000139.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds] 23:57 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has joined #go-nuts 23:58 -!- daxt [~daxt@112.135.95.172] has quit [Remote host closed the connection] 23:58 -!- daxt [~daxt@112.135.95.172] has joined #go-nuts 23:59 -!- reubenbond [~reubenbon@220-253-2-173.VIC.netspace.net.au] has joined #go-nuts --- Log closed Wed Jan 12 00:00:02 2011