Go Language Resources Go, golang, go... NOTE: This page ceased updating in October, 2012

--- Log opened Tue Jan 11 00:00:01 2011
00:06 -!- toyoshim_ [~toyoshim@y252053.dynamic.ppp.asahi-net.or.jp] has joined
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
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@] 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@] has quit [Ping timeout: 272 seconds]
00:54 -!- foocraft [~dsc@] 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@] 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@] has joined #go-nuts
01:29 -!- devrim [~Adium@] 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@] has joined #go-nuts
01:40 -!- dRbiG [p@irc.kaer.tk] has quit [Read error: Connection reset by peer]
01:41 -!- liwei [~liwei@] has joined #go-nuts
01:45 -!- ExtraSpice [~XtraSpice@] has quit [Ping timeout: 240
01:46 -!- liwei [~liwei@] 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@] 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@] has joined #go-nuts
02:04 -!- Venom_X [~pjacobs@] has quit [Client Quit]
02:12 -!- markcol [~markcol@] has quit [Quit: markcol]
02:13 -!- markcol [~markcol@] 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@] has quit [Read error: Connection
reset by peer]
02:29 -!- bmizerany [~bmizerany@] has joined #go-nuts
02:33 -!- nettok [~quassel@] has quit [Quit: No Ping reply in 180
02:34 -!- nettok [~quassel@] has joined #go-nuts
02:36 -!- zeh [~zeh@] has quit [Quit: Leaving]
02:40 -!- skejoe_ [~skejoe@] has joined #go-nuts
02:44 -!- skejoe [~skejoe@] has quit [Ping timeout: 272 seconds]
02:45 -!- nettok [~quassel@] has quit [Quit: No Ping reply in 180
02:45 -!- nettok [~quassel@] has joined #go-nuts
02:47 -!- gr0gmint [~quassel@] has quit [Remote host closed the
02:55 -!- jhawk28 [~jhawk28@user-387c58d.cable.mindspring.com] has joined #go-nuts
02:55 -!- nettok [~quassel@] has quit [Quit: No Ping reply in 180
02:56 -!- nettok [~quassel@] has joined #go-nuts
03:03 -!- nettok [~quassel@] has quit [Quit: No Ping reply in 180
03:03 -!- nettok [~quassel@] 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
03:09 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has quit [Remote
host closed the connection]
03:11 -!- nettok [~quassel@] has quit [Quit: No Ping reply in 180
03:11 -!- bmizerany [~bmizerany@] has quit [Remote host closed the
03:12 -!- nettok [~quassel@] has joined #go-nuts
03:12 -!- daxt [~daxt@] has joined #go-nuts
03:14 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
03:17 -!- nettok [~quassel@] has quit [Quit: No Ping reply in 180
03:17 -!- nettok [~quassel@] 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@] has joined #go-nuts
03:26 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has quit [Quit:
03:26 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has joined #go-nuts
03:27 -!- serbaut1 [~joakims@] has joined #go-nuts
03:28 -!- skejoe_ [~skejoe@] 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@] has quit [Excess Flood]
03:37 -!- daxt [~daxt@] has joined #go-nuts
03:38 -!- daxt [~daxt@] has quit [Remote host closed the connection]
03:42 -!- adu [~ajr@pool-72-83-254-159.washdc.fios.verizon.net] has joined
03:45 -!- Eridius [~kevin@unaffiliated/eridius] has quit [Ping timeout: 240
03:46 -!- ymasory [~ymasory@c-76-99-55-224.hsd1.pa.comcast.net] has joined
03:46 -!- markcol [~markcol@] has quit [Quit: markcol]
03:47 -!- nettok [~quassel@] has quit [Quit: No Ping reply in 180
03:47 -!- nettok [~quassel@] has joined #go-nuts
03:50 -!- nettok [~quassel@] has quit [Client Quit]
03:51 -!- nettok [~quassel@] has joined #go-nuts
04:01 -!- nettok [~quassel@] has quit [Quit: No Ping reply in 180
04:01 -!- nettok [~quassel@] has joined #go-nuts
04:15 -!- skejoe [~skejoe@] 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@] has joined #go-nuts
04:24 -!- nettok [~quassel@] has quit [Ping timeout: 250 seconds]
04:27 -!- watr_ [~watr@] 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
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:
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
05:37 -!- prip [~foo@host98-124-dynamic.36-79-r.retail.telecomitalia.it] has quit
[Ping timeout: 250 seconds]
05:44 -!- watr_ [~watr@] 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@] has joined #go-nuts
05:54 -!- Eko [~eko@ppp-70-225-140-127.dsl.ipltin.ameritech.net] has quit [Quit:
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
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@] 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
07:00 -!- adu [~ajr@pool-72-83-254-159.washdc.fios.verizon.net] has quit [Quit:
07:11 -!- LeNsTR [~lenstr@unaffiliated/lenstr] has joined #go-nuts
07:19 -!- antileet [~anirudhs@] 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
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@] 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
08:44 -!- arun [~arun@unaffiliated/sindian] has joined #go-nuts
08:45 -!- ExtraSpice [~XtraSpice@] 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
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
08:57 -!- wrtp [~rog@] 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
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
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
09:09 -!- nettok_ [~quassel@] 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
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
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
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
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
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
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
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
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
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@] has quit [Quit: Leaving.]
09:39 -!- temoto [~temoto@] 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
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
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
10:18 -!- rlab [~Miranda@] has quit [Ping timeout: 276 seconds]
10:18 -!- rlab [~Miranda@] has joined #go-nuts
10:37 -!- rlab_ [~Miranda@] has joined #go-nuts
10:38 -!- rlab [~Miranda@] 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@] has quit [Ping timeout: 240 seconds]
10:47 -!- rlab [~Miranda@] has joined #go-nuts
10:47 -!- tvw [~tv@e176008039.adsl.alicedsl.de] has quit [Remote host closed the
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
10:55 -!- shvntr [~shvntr@] has joined #go-nuts
11:00 -!- daxt [~daxt@] 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@] has joined #go-nuts
11:17 -!- daxt_ [~daxt@] has quit [Remote host closed the
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
11:19 -!- daxt [~daxt@] 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@] 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
12:02 -!- tensorpudding [~user@] has quit [Remote host closed the
12:05 -!- snearch [~snearch@f053004182.adsl.alicedsl.de] has quit [Remote host
closed the connection]
12:07 -!- rlab [~Miranda@] has quit [Quit: Miranda IM! Smaller,
Faster, Easier.  http://miranda-im.org]
12:09 -!- creack [~charme_g@] has quit [Ping timeout: 276 seconds]
12:10 -!- LuitvD [~me@beigetower/luitvd] has joined #go-nuts
12:14 -!- Electric_Brain [~gerard@] has joined
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@] 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@] has quit [Read error: Connection
reset by peer]
13:18 -!- lewis1711 [~lewis@125-239-255-244.jetstream.xtra.co.nz] has quit [Quit:
13:22 -!- DarthShrine [~angus@pdpc/supporter/student/DarthShrine] has quit [Quit:
13:26 -!- gr0gmint [~quassel@] 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@] has joined #go-nuts
13:50 -!- daxt [~daxt@] has quit [Ping timeout: 240 seconds]
13:51 -!- klavs [~chatzilla@] has quit [Quit: ChatZilla 0.9.86
[Firefox 3.6.13/20101203075014]]
13:51 -!- daxt [~daxt@] has joined #go-nuts
14:03 -!- skejoe [~skejoe@] has joined #go-nuts
14:07 -!- daxt_ [~daxt@] has joined #go-nuts
14:07 -!- jhawk28 [~jhawk28@user-387c58d.cable.mindspring.com] has joined #go-nuts
14:09 -!- daxt [~daxt@] 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@] has joined #go-nuts
14:28 -!- dRbiG [p@irc.kaer.tk] has joined #go-nuts
14:32 -!- iant [~iant@] has quit [Ping timeout: 260 seconds]
14:32 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has joined #go-nuts
14:32 -!- outworlder [~stephen@] has joined #go-nuts
14:35 -!- daxt [~daxt@] has joined #go-nuts
14:37 -!- daxt_ [~daxt@] 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@] 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
14:51 -!- ExtraSpice [~XtraSpice@] 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
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
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
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@] 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@] has quit [Quit: Leaving]
15:56 -!- shvntr [~shvntr@] has quit [Quit: leaving]
16:01 -!- iant [~iant@] 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@] 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:
16:15 -!- artefon [~thiago@dhcp16.usuarios.dcc.ufmg.br] has joined #go-nuts
16:16 -!- rlab [~Miranda@] has joined #go-nuts
16:17 -!- ildorn [~ildorn@dslb-088-067-144-207.pools.arcor-ip.net] has joined
16:19 -!- petrux [~petrux@host16-224-static.53-82-b.business.telecomitalia.it] has
quit [Quit: leaving]
16:20 -!- ExtraSpice [~XtraSpice@] 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@] 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@] has quit [Quit: Lost terminal]
16:53 -!- xash [~xash@d073018.adsl.hansenet.de] has quit [Ping timeout: 240
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:
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
17:31 -!- wrtp [~rog@] has quit [Quit: wrtp]
17:33 -!- Venom_X [~pjacobs@] 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@] has joined #go-nuts
18:11 -!- BlaSux [7f000001@] has quit [Ping timeout: 255 seconds]
18:12 -!- ildorn [~ildorn@dslb-088-067-144-207.pools.arcor-ip.net] has joined
18:21 -!- BlaSux [7f000001@] 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@] 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@] has quit [Remote host closed the
19:13 -!- BlaSux [7f000001@] has joined #go-nuts
19:14 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:54e3:9fed:74fd:52e7] has joined
19:19 -!- dforsyth_ [~dforsyth@bastion.inap.yelpcorp.com] has quit [Quit: Updating
Textual - http://www.codeux.com/textual/ — :-)]
19:19 -!- nettok_ [~quassel@] has joined #go-nuts
19:21 -!- nettok [~quassel@] 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
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@] 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@] has quit [Remote host closed the
19:56 < jumzi> what w8
19:57 < jumzi> look at the exec pkg first
19:57 -!- outworlder [~stephen@] 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 < 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
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
20:14 < jumzi> unless your one of those curious ppl that has todo it
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@] 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
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@] 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
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
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
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
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:
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
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@] has quit [Remote host closed the
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@] 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:
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
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
22:04 -!- nettok_ [~quassel@] has quit [Read error: Connection
reset by peer]
22:04 -!- tvw [~tv@e176008039.adsl.alicedsl.de] has joined #go-nuts
22:04 -!- outworlder [~stephen@] has quit [Quit: Leaving.]
22:10 -!- ildorn [~ildorn@dslb-088-067-144-207.pools.arcor-ip.net] has quit [Quit:
22:11 -!- rlab [~Miranda@] 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@] 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
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
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
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
22:33 < aiju> panic() should be renamed fuck()
22:33 < Soultaker> so you won't risk unintentionally ignoring error
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
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
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
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
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
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
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
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
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@] 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
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
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
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
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:
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
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
23:08 -!- wrtp [~rog@] 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
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@] has joined #go-nuts
23:26 -!- petar [~petar@84-73-24-182.dclient.hispeed.ch] has joined #go-nuts
23:33 -!- Venom_X [~pjacobs@] has quit [Quit: Venom_X]
23:34 -!- wrtp [~rog@] 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@] has joined #go-nuts
23:55 -!- boscop [~boscop@g227000139.adsl.alicedsl.de] has quit [Ping timeout: 240
23:57 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has joined #go-nuts
23:58 -!- daxt [~daxt@] has quit [Remote host closed the connection]
23:58 -!- daxt [~daxt@] has joined #go-nuts
23:59 -!- reubenbond [~reubenbon@220-253-2-173.VIC.netspace.net.au] has joined
--- Log closed Wed Jan 12 00:00:02 2011