--- Log opened Wed Apr 14 00:00:08 2010 --- Day changed Wed Apr 14 2010 00:00 -!- Wiz126 [Wiz126@72.20.222.36] has joined #go-nuts 00:04 -!- franksalim [~frank@adsl-75-61-84-181.dsl.pltn13.sbcglobal.net] has quit [Quit: Ex-Chat] 00:04 -!- Gracenotes [~person@wikipedia/Gracenotes] has joined #go-nuts 00:10 -!- TR2N [email@89-180-176-24.net.novis.pt] has quit [Ping timeout: 246 seconds] 00:10 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has joined #go-nuts 00:10 -!- TR2N [email@89-180-231-124.net.novis.pt] has joined #go-nuts 00:11 < rogue780> I'm most comfortable with Eclipse, but that doesn't seem to be an option yet 00:13 < Archwyrm> rogue780: Why not? 00:15 < rogue780> Archwyrm, the lack of a go plugin for one...do I rely on IDEs too much? perhaps. 00:15 < Archwyrm> rogue780: http://go-lang.cat-v.org/text-editors/eclipse 00:18 < rogue780> thanks! 00:19 < Archwyrm> np 00:21 -!- path[l] [UPP@120.138.102.34] has quit [Ping timeout: 240 seconds] 00:25 -!- path[l] [UPP@120.138.102.34] has joined #go-nuts 00:26 < rogue780> crap. I just killed KDE 00:26 < uriel> rogue780: if you need an IDE to write code, you are doing something wrong 00:29 < rogue780> uriel, is my software didn't run, then I'm doing something wrong. If I need an IDE to write code than I'm using a crutch. If I just prefer syntax highlighting and the ability to collapse blocks of code, then I have a preference. If I have enough other projects in other languages and I like to use a unified development environment for all of them and don't have time to learn emacs or vim in addition to a new language then what am I? 00:30 * uriel finds almost any text editor easier to learn to use than an IDE 00:33 < KirkMcDonald> Any time invested in learning vim or emacs will pay dividends. 00:33 < KirkMcDonald> ... eventually. 00:34 <+iant> surely the whole point of an IDE is that you don't have to learn how to use it 00:34 < kmeyer> I don't think that's the point... 00:35 < KirkMcDonald> To my mind, the point of an IDE is having an integrated, graphical debugger. 00:36 < KirkMcDonald> And also project management. 00:36 -!- Venom_X [~pjacobs@71.20.102.220] has joined #go-nuts 00:36 -!- carllerche [~carllerch@enginey-9.border1.sfo002.pnap.net] has quit [Quit: carllerche] 00:37 * rogue780 upvotes KirkMcDonald 00:41 < bawr> KirkMcDonald: Woah. I did a double take, thought this is #python. ;) 00:42 < bawr> +1 on the IDE thing, but learning vim/emacs and gdb does pay off. 00:43 -!- Venom_X [~pjacobs@71.20.102.220] has quit [Quit: Venom_X] 00:53 -!- letoh [~letoh@59-105-29-149.adsl.dynamic.seed.net.tw] has quit [Quit: leaving] 00:54 -!- carllerche [~carllerch@208.87.61.146] has joined #go-nuts 00:55 -!- g0bl1n [~anonymous@a213-22-237-141.cpe.netcabo.pt] has quit [Ping timeout: 240 seconds] 00:57 -!- smw [~stephen@pool-96-232-88-231.nycmny.fios.verizon.net] has quit [Ping timeout: 245 seconds] 00:57 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has joined #go-nuts 00:59 -!- iant [~iant@67.218.107.95] has quit [Ping timeout: 276 seconds] 01:05 -!- smw [~stephen@pool-96-232-88-231.nycmny.fios.verizon.net] has joined #go-nuts 01:19 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Quit: WeeChat 0.3.1.1] 01:19 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has joined #go-nuts 01:28 -!- nhbar [~kv@wireless-169-235-38-75.ucr.edu] has quit [Quit: leaving] 01:47 -!- carllerche [~carllerch@208.87.61.146] has quit [Quit: carllerche] 01:51 -!- bmizerany [~bmizerany@dsl081-064-072.sfo1.dsl.speakeasy.net] has quit [Remote host closed the connection] 01:58 -!- Xera` [~brit@87-194-208-246.bethere.co.uk] has quit [Quit: ( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com )] 01:58 < plexdev> http://is.gd/brHYz by [Andrew Gerrand] in 2 subdirs of go/ -- release.2010-04-13 02:08 -!- cco3 [~conley@c-69-181-139-23.hsd1.ca.comcast.net] has joined #go-nuts 02:08 -!- Boggy-B|Helium [~Boggy-B|H@93-96-78-46.zone4.bethere.co.uk] has joined #go-nuts 02:15 -!- path[l] [UPP@120.138.102.34] has quit [Quit: path[l]] 02:18 -!- aho [~nya@f051009011.adsl.alicedsl.de] has joined #go-nuts 02:21 -!- nettok [~netto@200.119.155.150] has joined #go-nuts 02:27 -!- nettok_ [~netto@200.119.155.150] has joined #go-nuts 02:28 -!- Nitro [~nitro@208.92.17.21] has quit [Ping timeout: 264 seconds] 02:30 -!- nettok [~netto@200.119.155.150] has quit [Ping timeout: 276 seconds] 02:32 -!- nettok__ [~netto@200.119.155.150] has joined #go-nuts 02:34 -!- jA_cOp [~yakobu@unaffiliated/ja-cop/x-9478493] has joined #go-nuts 02:36 -!- nettok_ [~netto@200.119.155.150] has quit [Ping timeout: 264 seconds] 02:43 -!- slashus2 [~slashus2@74-137-24-74.dhcp.insightbb.com] has joined #go-nuts 02:57 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has joined #go-nuts 02:57 -!- mode/#go-nuts [+v iant] by ChanServ 03:03 -!- nettok_ [~netto@200.119.155.150] has joined #go-nuts 03:07 -!- nettok__ [~netto@200.119.155.150] has quit [Ping timeout: 240 seconds] 03:09 -!- Adys [~Adys@unaffiliated/adys] has quit [Ping timeout: 265 seconds] 03:10 -!- SecretofMana [~mana@142.46.164.30] has joined #go-nuts 03:13 -!- Eridius [~kevin@unaffiliated/eridius] has quit [Ping timeout: 260 seconds] 03:18 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has quit [Ping timeout: 264 seconds] 03:20 -!- Adys [~Adys@unaffiliated/adys] has joined #go-nuts 03:30 -!- path[l] [UPP@120.138.102.34] has joined #go-nuts 03:31 -!- Macpunk [~macpunk@cpe-72-177-26-221.austin.res.rr.com] has joined #go-nuts 03:35 -!- shasbot [~shasbot@ip70-171-218-55.tc.ph.cox.net] has quit [Ping timeout: 245 seconds] 03:37 -!- shasbot [~shasbot@ip70-171-218-55.tc.ph.cox.net] has joined #go-nuts 03:42 -!- SecretofMana [~mana@142.46.164.30] has quit [Ping timeout: 240 seconds] 03:49 -!- kssreeram [~kssreeram@122.174.139.125] has quit [Quit: kssreeram] 03:51 -!- nettok__ [~netto@200.119.155.150] has joined #go-nuts 03:56 -!- nettok_ [~netto@200.119.155.150] has quit [Ping timeout: 276 seconds] 04:00 < plexdev> http://is.gd/brOjU by [Russ Cox] in go/doc/ -- go_spec updates 04:09 -!- warthurton [~warthurto@pdpc/supporter/active/warthurton] has quit [Quit: warthurton] 04:16 < Archwyrm> Odd.. When I hg pull, I don't get release.2010-04-13 and the simple release tag is just missing. 04:17 < Archwyrm> wtf.. I have latest tip as well. 04:17 < Archwyrm> archwyrm@alien:~/src/go$ hg tip 04:17 < Archwyrm> changeset: 5289:f98f784927ab 04:28 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has joined #go-nuts 04:28 -!- rhelmer [~rhelmer@adsl-69-107-85-166.dsl.pltn13.pacbell.net] has joined #go-nuts 04:42 < kmeyer> possibly mirrors are a little out of sync 04:45 -!- kota1111 [~kota1111@gw2.kbmj.jp] has joined #go-nuts 04:48 < Archwyrm> Ah 04:48 < Archwyrm> Doesn't seem very atomic though.. 04:56 -!- nettok_ [~netto@200.119.155.150] has joined #go-nuts 05:00 -!- nettok__ [~netto@200.119.155.150] has quit [Ping timeout: 268 seconds] 05:02 -!- rbraley [~rbraley@ip72-222-129-178.ph.ph.cox.net] has joined #go-nuts 05:07 -!- TR2N [email@89-180-231-124.net.novis.pt] has left #go-nuts [] 05:10 -!- nettok__ [~netto@200.119.155.150] has joined #go-nuts 05:14 -!- nettok_ [~netto@200.119.155.150] has quit [Ping timeout: 276 seconds] 05:15 -!- carllerche [~carllerch@208.87.61.146] has joined #go-nuts 05:17 -!- travlr [~palexande@c-69-254-44-10.hsd1.fl.comcast.net] has joined #go-nuts 05:23 -!- cco3 [~conley@c-69-181-139-23.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds] 05:23 -!- nettok [~netto@200.119.158.151] has joined #go-nuts 05:26 -!- nettok__ [~netto@200.119.155.150] has quit [Ping timeout: 248 seconds] 05:32 < plexdev> http://is.gd/brSVN by [Alex Brainman] in 2 subdirs of go/src/pkg/ -- os, syscall: mingw bug fixes 05:33 -!- dju [dju@null.dmz.me] has joined #go-nuts 05:37 -!- nettok_ [~netto@200.119.158.151] has joined #go-nuts 05:39 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has quit [Ping timeout: 258 seconds] 05:41 -!- nettok [~netto@200.119.158.151] has quit [Ping timeout: 248 seconds] 05:41 -!- carllerche [~carllerch@208.87.61.146] has quit [Quit: carllerche] 05:43 -!- robot12 [~robot12@robot12.kgts.ru] has joined #go-nuts 05:43 -!- carllerche [~carllerch@208.87.61.146] has joined #go-nuts 05:48 < plexdev> http://is.gd/brTA5 by [Russ Cox] in 7 subdirs of go/src/pkg/runtime/ -- runtime: better trace for fault due to nil pointer call 05:51 -!- nettok__ [~netto@200.119.158.151] has joined #go-nuts 05:52 -!- carllerche [~carllerch@208.87.61.146] has quit [Quit: carllerche] 05:55 -!- nettok_ [~netto@200.119.158.151] has quit [Ping timeout: 240 seconds] 05:59 < nf> Archwyrm: fixed now 06:00 -!- warthurton [~warthurto@pdpc/supporter/active/warthurton] has joined #go-nuts 06:00 -!- nettok__ [~netto@200.119.158.151] has quit [Ping timeout: 246 seconds] 06:02 -!- robot12 [~robot12@robot12.kgts.ru] has quit [Ping timeout: 245 seconds] 06:04 < nf> Archwyrm: i removed the tag of the previous release, then had to go and give a presentation before i could tag the new one 06:05 < plexdev> http://is.gd/brUl7 by [Andrew Gerrand] in go/ -- release.2010-04-13 part two 06:14 -!- ryan_baker [~ryan_bake@128-193-249-134.resnet.oregonstate.edu] has joined #go-nuts 06:17 -!- nettok__ [~netto@200.119.158.151] has joined #go-nuts 06:18 -!- robot12 [~robot12@robot12.kgts.ru] has joined #go-nuts 06:21 < Archwyrm> nf: Ah, ok. Thanks. 06:22 -!- rv2733 [~rv2733@c-98-242-168-49.hsd1.fl.comcast.net] has quit [Quit: Leaving] 06:23 -!- nettok_ [~netto@200.119.158.151] has joined #go-nuts 06:24 -!- sjbrown [~sjbrown@c-69-181-182-137.hsd1.ca.comcast.net] has joined #go-nuts 06:24 -!- sjbrown [~sjbrown@c-69-181-182-137.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 06:27 -!- nettok__ [~netto@200.119.158.151] has quit [Ping timeout: 264 seconds] 06:27 -!- nettok_ [~netto@200.119.158.151] has quit [Client Quit] 06:30 -!- rsaarelm [~rsaarelm@cs181128175.pp.htv.fi] has quit [Quit: leaving] 06:30 -!- prip [~foo@host87-128-dynamic.36-79-r.retail.telecomitalia.it] has quit [Read error: Connection reset by peer] 06:31 -!- rsaarelm [~rsaarelm@cs181128175.pp.htv.fi] has joined #go-nuts 06:32 -!- ShadowIce [pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts 06:43 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts 06:59 -!- slashus2 [~slashus2@74-137-24-74.dhcp.insightbb.com] has quit [Quit: slashus2] 07:04 -!- prip [~foo@host87-128-dynamic.36-79-r.retail.telecomitalia.it] has joined #go-nuts 07:07 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has quit [Quit: This computer has gone to sleep] 07:14 -!- defectiv [~clays@c-24-5-65-40.hsd1.ca.comcast.net] has quit [Quit: This computer has gone to sleep] 07:20 -!- gnuvince [~vince@201.103-ppp.3menatwork.com] has quit [Ping timeout: 265 seconds] 07:25 -!- kaigan|work [~kaigan@c-8290e255.1411-10-64736c14.cust.bredbandsbolaget.se] has joined #go-nuts 07:30 < manveru> how can i make a bytes.Buffer sliceable? 07:31 < kmeyer> Bytes() 07:36 -!- Surma [~surma@95-88-89-37-dynip.superkabel.de] has joined #go-nuts 07:37 -!- gnuvince [~vince@70.35.163.245] has joined #go-nuts 07:41 -!- petrux [~petrux@host16-224-static.53-82-b.business.telecomitalia.it] has joined #go-nuts 07:41 < petrux> hi there 07:41 < manveru> kmeyer: i guess that's not very efficient then... 07:42 < petrux> newbie question: which editor shall I use to write Go code? Usually I'm an Emacs-maniac 07:42 < manveru> I'll try another approach 07:42 < kmeyer> manveru: you can work on a []byte buffer instead of a bytes.Buffer if you want it sliceable 07:42 < manveru> petrux: emacs is fine 07:43 -!- Majk [~Majk@tm.84.52.139.54.dc.cable.static.telemach.net] has joined #go-nuts 07:43 -!- Majk [~Majk@tm.84.52.139.54.dc.cable.static.telemach.net] has quit [Client Quit] 07:43 < petrux> manveru: I know. :-) Ok, I'm going to search for some go-mode.el 07:43 < manveru> kmeyer: yeah, just wanted to reduce the amount of offset calculation 07:43 < manveru> petrux: there is one in the go source 07:43 < petrux> manveru: I've found this post: http://kai.system7.de/2009/11/24/ubuntu-910-and-the-google-go-emacs-mode/ 07:44 < petrux> Ok, didn't know that. Thanks. 07:44 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 07:44 -!- tvw [~tv@e182076250.adsl.alicedsl.de] has joined #go-nuts 07:45 < petrux> did anyone tried to install Go on windows (using CygWin)? 07:46 < manveru> kmeyer: you know how i can get an instance of io.ReaderAt? 07:46 < kmeyer> manveru: I'm not here to answer every silly question you ask 07:46 < kmeyer> figrue it out 07:46 < manveru> Okay 07:47 -!- ryan_baker [~ryan_bake@128-193-249-134.resnet.oregonstate.edu] has quit [Quit: ryan_baker] 07:52 -!- tvw [~tv@e182076250.adsl.alicedsl.de] has quit [Read error: Operation timed out] 07:55 -!- gnuvince_ [~vince@70.35.165.166] has joined #go-nuts 07:56 -!- JasonWoof [~JasonWoof@fsf/member/herkamire] has joined #go-nuts 07:58 -!- gnuvince [~vince@70.35.163.245] has quit [Ping timeout: 258 seconds] 08:02 -!- tux21b [~christoph@90.146.60.30] has joined #go-nuts 08:03 -!- Xurix [~Luixsia@AToulouse-254-1-17-1.w81-250.abo.wanadoo.fr] has quit [Ping timeout: 248 seconds] 08:05 < JasonWoof> I'm not seeing usage on both my CPUs. Do I have to do something special so my goroutines use both cores? 08:06 < JasonWoof> I did basically: go expensive_long_task(); go expensive_long_task(); 08:06 < JasonWoof> I'm computing mandelbrot, so it's nicely cpu-bound 08:07 < JasonWoof> my cpu usage chart is pretty steady at 50% (so one of my two cores seems to be active) 08:07 < Archwyrm> JasonWoof: http://golang.org/pkg/runtime/#GOMAXPROCS 08:07 < Archwyrm> It defaults to 1 currently. 08:11 < JasonWoof> Archwyrm: awesome! thanks 08:13 < JasonWoof> works like a charm. 08:14 < JasonWoof> is there an easy way to find out how many CPUs there are? 08:14 < JasonWoof> does it slow go down to set GOMAXPROCS higher than the number of actual CPUs? 08:15 < Archwyrm> JasonWoof: If there is a way, it is probably in runtime. 08:16 < Archwyrm> On Linux you could always look in /proc 08:16 < Archwyrm> I don't know that it slows things down, but it probably depends on what you are doing and I doubt you get any benefit anyway. 08:17 -!- ikaros [~ikaros@f051096109.adsl.alicedsl.de] has joined #go-nuts 08:19 -!- GilJ [~gilles@85.10.72.85] has joined #go-nuts 08:21 < JasonWoof> for running locally, I'm fine with just runtime.GOMAXPROCS(2) 08:22 < JasonWoof> I've never played with threads/coroutines before 08:23 < JasonWoof> It's cool! I really really like having the UI on a different thread than the fractal crunching code 08:36 < Archwyrm> =) 08:48 < nf> mmm crunchy fractals 08:49 -!- aho [~nya@f051009011.adsl.alicedsl.de] has quit [Quit: EXEC_over.METHOD_SUBLIMATION] 08:54 -!- path[l] [UPP@120.138.102.34] has quit [Quit: path[l]] 08:54 < chressie> JasonWoof: you can also set GOMAXPROCS as environment variable, like GOMAXPROCS=2 ./mandelbrot 08:57 -!- nighty__ [~nighty@210.188.173.245] has joined #go-nuts 08:58 < JasonWoof> chressie: cool! 09:04 -!- Fish-Work [~Fish@86.65.182.207] has quit [Ping timeout: 276 seconds] 09:04 -!- Surma [~surma@95-88-89-37-dynip.superkabel.de] has quit [Quit: Leaving.] 09:04 -!- g0bl1n [~anonymous@a213-22-237-141.cpe.netcabo.pt] has joined #go-nuts 09:05 -!- Fish-Work [~Fish@86.65.182.207] has joined #go-nuts 09:07 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has joined #go-nuts 09:10 < plexdev> http://is.gd/bs3Lt by [Russ Cox] in go/src/pkg/bytes/ -- bytes: shuffle implementation, making WriteByte 50% faster 09:14 -!- path[l] [~path@59.162.86.164] has joined #go-nuts 09:16 -!- Surma [~bzfsurma@gooseberry.zib.de] has joined #go-nuts 09:16 -!- Macpunk [~macpunk@cpe-72-177-26-221.austin.res.rr.com] has quit [Quit: Leaving] 09:16 -!- ssb [~ssb@213.167.39.150] has quit [Ping timeout: 260 seconds] 09:18 -!- rlab [~Miranda@91.200.158.34] has quit [Read error: Connection reset by peer] 09:19 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Read error: Connection timed out] 09:21 -!- araujo [~araujo@gentoo/developer/araujo] has joined #go-nuts 09:23 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Max SendQ exceeded] 09:24 -!- araujo [~araujo@gentoo/developer/araujo] has joined #go-nuts 09:27 -!- ssb [~ssb@213.167.39.150] has joined #go-nuts 09:36 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Ping timeout: 264 seconds] 09:41 < JasonWoof> I can send a channel over a channel right? 09:41 < bortzmeyer> I never tried. Funny idea :-) 09:43 < JasonWoof> I'm just worried that the syntax is ambiguous 09:43 < JasonWoof> chan_a <- chan_b 09:43 < JasonWoof> does that read from chan_b, and send the result to chan_a? 09:43 < JasonWoof> or does that send chan_b to chan_a? 09:44 -!- araujo [~araujo@gentoo/developer/araujo] has joined #go-nuts 09:44 < JasonWoof> oh, wait. the former would be chan_a <- <- chan_b 09:45 < JasonWoof> chan_a <- <-chan_b 09:48 -!- ikaros [~ikaros@f051096109.adsl.alicedsl.de] has quit [Quit: Leave the magic to Houdini] 09:59 -!- path[l] [~path@59.162.86.164] has quit [Quit: path[l]] 09:59 -!- path[l] [~path@59.162.86.164] has joined #go-nuts 10:04 -!- tvw [~tv@212.79.9.150] has joined #go-nuts 10:15 < uriel> JasonWoof: yes, you can send channels over channels, that is a very powerful construct 10:17 < manveru> JasonWoof: there are a couple of examples in the docs for that 10:18 < manveru> JasonWoof: http://golang.org/doc/effective_go.html#chan_of_chan 10:19 < JasonWoof> manveru: thanks! 10:20 < JasonWoof> this is stretching my brain nicely. I might need some sleep before I can get this thing working :) 10:20 -!- General1337 [~support@71-93-97-216.dhcp.mtpk.ca.charter.com] has quit [Ping timeout: 246 seconds] 10:20 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has quit [Ping timeout: 246 seconds] 10:22 < manveru> JasonWoof: i just wrote mandelbrot myself, wanna share your code? :) 10:22 < manveru> not sure how to implement the calculation in goroutines 10:23 < manveru> always messes up my output 10:28 -!- ampleyfly [~ampleyfly@h-148-139.A163.priv.bahnhof.se] has quit [Read error: Connection reset by peer] 10:28 < JasonWoof> manveru: I'd like to later. right now my code is embarrassing. 10:28 -!- ampleyfly [~ampleyfly@h-148-139.A163.priv.bahnhof.se] has joined #go-nuts 10:29 < JasonWoof> my goal is to learn go, and fiddle with the new (to me) features 10:29 < JasonWoof> and I'm also very happy to play with making a very responsive interface 10:29 < manveru> heh 10:29 < manveru> i saw there's no tcl/tk binding yet 10:30 < JasonWoof> I've got a ticker which repaints the screen on a regular interval if anything's changed 10:30 < JasonWoof> oh, I'm using SDL 10:30 < JasonWoof> keepin' things simple 10:30 < manveru> so far my go stuff has been around 50x faster than ruby... and that's using only one cpu 10:30 < JasonWoof> huh. surprised it's not faster 10:32 < manveru> well, that's with ruby 1.9... 1.8 is around 90x slower 10:34 < manveru> i just hope i can crank out code as fast as with ruby too :) 10:35 -!- peterdn [~peterdn@cpc1-oxfd18-2-0-cust512.4-3.cable.virginmedia.com] has joined #go-nuts 10:36 < manveru> and maybe that someone will come up with better type inference and exceptions 10:40 -!- oal [~olav@5.79-160-122.customer.lyse.net] has joined #go-nuts 10:51 -!- nighty__ [~nighty@210.188.173.245] has quit [Quit: Disappears in a puff of smoke] 11:02 -!- perdix [~perdix@f055138016.adsl.alicedsl.de] has joined #go-nuts 11:02 -!- perdix [~perdix@f055138016.adsl.alicedsl.de] has quit [Changing host] 11:02 -!- perdix [~perdix@sxemacs/devel/perdix] has joined #go-nuts 11:06 -!- path[l] [~path@59.162.86.164] has quit [Remote host closed the connection] 11:06 -!- path[l] [~path@59.162.86.164] has joined #go-nuts 11:09 -!- Ikke [~ikkibr@unaffiliated/ikkebr] has joined #go-nuts 11:11 -!- perdix [~perdix@sxemacs/devel/perdix] has quit [Quit: A cow. A trampoline. Together they fight crime!] 11:22 -!- rv2733 [~rv2733@c-98-242-168-49.hsd1.fl.comcast.net] has joined #go-nuts 11:24 -!- kiko_ [~kiko@67.207.130.53] has left #go-nuts [] 11:25 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Quit: WeeChat 0.3.1.1] 11:25 -!- kikofx [~kiko@67.207.130.53] has joined #go-nuts 11:27 < JasonWoof> how's this syntax? 11:27 < JasonWoof> struct Point { x, y int }; pa := [2]Point{ Point{ 0, 0,}, Point{ 1, 2 } }; 11:28 < JasonWoof> my struct has 5 int members, and I need to initialize an array of 3 of them. I'm doing basically the above, but experiencing bugs 11:28 -!- ikaros [~ikaros@guests131.externals.de] has joined #go-nuts 11:31 < JasonWoof> small chance the bug is related, but I'm also hoping there's a better way to initialize stuff like this 11:35 -!- [Pete_27] [~noname@115-64-1-61.static.tpgi.com.au] has joined #go-nuts 11:36 -!- fwiffo [~none@unaffiliated/fwiffo] has joined #go-nuts 11:39 -!- ikaros [~ikaros@guests131.externals.de] has quit [Remote host closed the connection] 11:43 < manveru> hmm 11:45 -!- ikaros [~ikaros@guests131.externals.de] has joined #go-nuts 11:58 < manveru> JasonWoof: http://gist.github.com/365724 11:59 < manveru> i don't like the code... but i'm not sure how to do it different 12:00 -!- kota1111 [~kota1111@gw2.kbmj.jp] has quit [Quit: Leaving...] 12:00 < manveru> is there some kind of splat op? 12:04 < JasonWoof> manveru: that looks like it would work, but would only be worth it if it was used a lot 12:05 < manveru> yeah 12:05 < manveru> you might get shorter code using reflect 12:05 -!- Nitro [~nitro@208.92.17.21] has joined #go-nuts 12:06 < manveru> i'm just a beginner... will try that later :) 12:06 -!- Surma [~bzfsurma@gooseberry.zib.de] has quit [Quit: Leaving.] 12:11 -!- rsaarelm [~rsaarelm@cs181128175.pp.htv.fi] has quit [Ping timeout: 276 seconds] 12:13 < rue> Ha, was confused about the channel for a moment there 12:14 < manveru> rue: oi :) 12:14 < rue> *wave* 12:16 < rue> (I am waiting to see how the error/exception/nonlocalreturn thing turns out before investing much...but the channel is usually enlightening :) 12:16 -!- Xera^ [~brit@87-194-208-246.bethere.co.uk] has joined #go-nuts 12:17 < manveru> yeah... the error handling is quite annoying right now 12:20 < manveru> some stuff panics, some stuff returns error structs instead 12:20 < rue> Mm. There is some understandable scarring from "exception" abuse. I hope the currently popular (?) retval, err = foo() idiom evolves into properly separating success/failure from return values 12:21 < manveru> handling panics is pretty crazy 12:21 < manveru> and always checking the error return value is tiresome 12:23 < manveru> if something returns an error value, it makes chaining harder too 12:23 < rue> Yep. So, fingers crossed! Otherwise we might as well be using Alef :D 12:24 < manveru> and then there are many functions where you pass in an object that it modifies for you, but not all 12:34 < manveru> rue: alef? 12:35 < manveru> oh... 12:35 < manveru> i doubt that runs on linux? :) 12:36 < uriel> manveru: http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ 12:40 < rue> Alef -> Limbo -> Go as far as I am concerned ;) 12:40 < manveru> never heard of the other languages 12:42 -!- Nitro [~nitro@208.92.17.21] has quit [Quit: Leaving.] 12:44 -!- cmarcelo [~cmarcelo@200.184.118.130] has joined #go-nuts 12:44 -!- cmarcelo [~cmarcelo@200.184.118.130] has quit [Changing host] 12:44 -!- cmarcelo [~cmarcelo@enlightenment/developer/cmarcelo] has joined #go-nuts 12:49 -!- path[l]_ [~path@122.182.0.38] has joined #go-nuts 12:50 -!- path[l] [~path@59.162.86.164] has quit [Ping timeout: 246 seconds] 12:51 -!- Gracenotes [~person@wikipedia/Gracenotes] has quit [Ping timeout: 276 seconds] 12:59 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 13:09 -!- fwiffo [~none@unaffiliated/fwiffo] has quit [Ping timeout: 276 seconds] 13:12 -!- afurlan [~afurlan@scorpion.mps.com.br] has joined #go-nuts 13:12 -!- path[l] [~path@122.182.0.38] has quit [Quit: path[l]] 13:20 -!- nanoo [~nano@95-89-197-196-dynip.superkabel.de] has joined #go-nuts 13:21 -!- idea_squirrel [ct2rips@77-21-24-61-dynip.superkabel.de] has joined #go-nuts 13:26 -!- zyichi [~zyichi@113.44.0.70] has joined #go-nuts 13:27 -!- letoh [~letoh@59-105-29-139.adsl.dynamic.seed.net.tw] has joined #go-nuts 13:31 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has quit [Ping timeout: 260 seconds] 13:32 -!- ikaros [~ikaros@guests131.externals.de] has quit [Quit: Leave the magic to Houdini] 13:37 -!- meanburrito920 [~john@192.5.109.49] has joined #go-nuts 13:37 -!- meanburrito920 [~john@192.5.109.49] has quit [Changing host] 13:37 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has joined #go-nuts 13:41 -!- rsaarelm [~rsaarelm@cs181128175.pp.htv.fi] has joined #go-nuts 13:44 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has quit [Ping timeout: 240 seconds] 13:51 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has joined #go-nuts 14:02 -!- iant [~iant@67.218.107.11] has joined #go-nuts 14:03 -!- mode/#go-nuts [+v iant] by ChanServ 14:03 -!- Venom_X [~pjacobs@74.61.90.217] has joined #go-nuts 14:07 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has quit [Ping timeout: 245 seconds] 14:09 -!- TMKCodes [~toni@bbwirelessgw2-fee1dc00-62.dhcp.inet.fi] has quit [Ping timeout: 246 seconds] 14:13 -!- ponce [~ponce@paradisia.net] has joined #go-nuts 14:16 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has joined #go-nuts 14:17 -!- surma [~surma@zb4c3.pia.fu-berlin.de] has joined #go-nuts 14:17 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has quit [Client Quit] 14:17 -!- surma [~surma@zb4c3.pia.fu-berlin.de] has left #go-nuts [] 14:19 -!- Nitro [~nitro@208.92.17.21] has joined #go-nuts 14:20 -!- cco3 [~conley@c-69-181-139-23.hsd1.ca.comcast.net] has joined #go-nuts 14:24 -!- meanburrito920 [~john@192.5.109.49] has joined #go-nuts 14:24 -!- meanburrito920 [~john@192.5.109.49] has quit [Changing host] 14:24 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has joined #go-nuts 14:29 -!- tux21b [~christoph@90.146.60.30] has quit [Quit: Ex-Chat] 14:35 -!- m-takagi [~m-takagi@linode.m-takagi.jp] has joined #go-nuts 14:36 -!- Wiz126 [Wiz126@72.20.222.36] has quit [Ping timeout: 240 seconds] 14:37 -!- m-takagi [~m-takagi@linode.m-takagi.jp] has left #go-nuts ["Leaving..."] 14:45 < JasonWoof> manveru: looks like my fractal generator is one sitting away from being somewhat presentable. when that happens I'll publish to gitorious.org and let you know. 14:47 -!- robot12 [~robot12@robot12.kgts.ru] has quit [Quit: Leaving.] 14:48 -!- surma [~surma@zb4c3.pia.fu-berlin.de] has joined #go-nuts 14:51 -!- awidegreen [~quassel@62.176.237.78] has joined #go-nuts 14:53 -!- drry [~drry@unaffiliated/drry] has quit [Read error: Connection reset by peer] 14:54 -!- drry [~drry@unaffiliated/drry] has joined #go-nuts 14:55 -!- Wiz126 [Wiz126@72.20.220.206] has joined #go-nuts 14:55 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Quit: Leaving.] 14:57 -!- Honeyman [~Alex@212.67.17.185] has joined #go-nuts 14:58 -!- kaigan|work [~kaigan@c-8290e255.1411-10-64736c14.cust.bredbandsbolaget.se] has quit [Quit: kaigan|work] 14:59 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has quit [Quit: leaving] 14:59 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has joined #go-nuts 14:59 -!- micrypt [~micrypt@41-184-21-79.rv.ipnxtelecoms.com] has joined #go-nuts 15:01 -!- iant [~iant@67.218.107.11] has quit [Ping timeout: 245 seconds] 15:04 -!- gnuvince_ [~vince@70.35.165.166] has quit [Ping timeout: 276 seconds] 15:06 -!- nanoo [~nano@95-89-197-196-dynip.superkabel.de] has quit [Quit: Leaving] 15:06 < kimelto> morning! 15:08 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has joined #go-nuts 15:13 < Honeyman> They say that GCC 4.5 just got released. Any idea anyone will it include gccgo? 15:13 -!- zyichi [~zyichi@113.44.0.70] has quit [Quit: zyichi] 15:16 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has quit [Quit: leaving] 15:17 -!- surma [~surma@zb4c3.pia.fu-berlin.de] has left #go-nuts [] 15:20 -!- TMKCodes [~toni@bbwirelessgw2-fee1dc00-62.dhcp.inet.fi] has joined #go-nuts 15:20 -!- gnuvince [~vince@70.35.167.187] has joined #go-nuts 15:22 -!- zyichi [~zyichi@113.44.0.72] has joined #go-nuts 15:22 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has joined #go-nuts 15:30 -!- Ikke [~ikkibr@unaffiliated/ikkebr] has quit [Read error: Connection reset by peer] 15:31 -!- AmirMohammad [~amir@unaffiliated/gluegadget] has joined #go-nuts 15:31 -!- grahame [~grahame@billy.angrygoats.net] has quit [Ping timeout: 240 seconds] 15:33 -!- grahame [~grahame@billy.angrygoats.net] has joined #go-nuts 15:34 -!- iant [~iant@nat/google/x-kdxqraxzsixsshwo] has joined #go-nuts 15:34 -!- mode/#go-nuts [+v iant] by ChanServ 15:34 -!- path[l] [~path@122.182.0.38] has joined #go-nuts 15:36 -!- cco3 [~conley@c-69-181-139-23.hsd1.ca.comcast.net] has quit [Ping timeout: 276 seconds] 15:36 -!- Ikke [~ikkibr@189.58.209.254.dynamic.adsl.gvt.net.br] has joined #go-nuts 15:36 -!- Ikke [~ikkibr@189.58.209.254.dynamic.adsl.gvt.net.br] has quit [Changing host] 15:36 -!- Ikke [~ikkibr@unaffiliated/ikkebr] has joined #go-nuts 15:51 -!- yaroslav [~yaroslav@109.170.106.65] has joined #go-nuts 15:51 -!- krzyma [~krzyma@156.17.230.195] has joined #go-nuts 15:56 -!- slashus2 [~slashus2@74-137-24-74.dhcp.insightbb.com] has joined #go-nuts 16:00 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has quit [Ping timeout: 245 seconds] 16:01 -!- b00m_chef [~watr@d64-180-45-230.bchsia.telus.net] has joined #go-nuts 16:02 -!- zyichi [~zyichi@113.44.0.72] has left #go-nuts [] 16:02 < cbeck> I don't think there's any chance of that, at least until GC, among other things, starts working in gccgo 16:06 -!- Wiz126 [Wiz126@72.20.220.206] has quit [Ping timeout: 258 seconds] 16:08 -!- ikaros [~ikaros@f051096109.adsl.alicedsl.de] has joined #go-nuts 16:11 < Zoopee> So does anybody here have some context on the stance on exceptions vs. panic + error returns? 16:13 < Zoopee> I read the discussion on the mailing list following r's proposal. It sounded well reasoned, so slept through it, but now I don't actually understand the deal. 16:13 -!- nw3 [~new@sgenomics.org] has joined #go-nuts 16:14 < JBeshir> Panic/recover is intended to be used for a truly exceptional event indicating that whatever was attempted failed entirely. Generally, something that the programmer should be expecting not to happen. 16:14 -!- tvw [~tv@212.79.9.150] has quit [Ping timeout: 245 seconds] 16:15 < JBeshir> File I/O is the big exmple of what it isn't used for, because everyone expects (or should expect) file I/O to randomly fail. 16:15 < Zoopee> I don't want to just pitch in on the mailing list and ask questions that sound like a rethoric rant, as I'm sure there's something in that view I need to get more clear. 16:16 < JBeshir> The big uses so far seem to be internal to a package to handle and catch failures, and at, say, a webserver level, to catch any failure at all within serving a single page and only terminate that connection. 16:16 < Zoopee> (and figured some of the guys here may be more tolerant of my intuitive observations) 16:16 -!- Xeon [~chatzilla@222.73.189.44] has joined #go-nuts 16:17 < Zoopee> JBeshir: what's the difference between an error you expect to happen, and an error you don't expect to happen? It sounds to me just like a matter of probability and experience. 16:17 < Zoopee> BRB. 16:17 < JBeshir> Good question. 16:18 < JBeshir> I think one example of the former is "errors which the function is always permitted to return, even with valid input", and an example of the latter could be "errors caused by invalid input", but this is where my observations from the sidelines kinda begin to lose detail. 16:19 -!- Xeon_ [~chatzilla@222.73.189.45] has quit [Ping timeout: 276 seconds] 16:19 < JBeshir> I find it an interesting topic, not least because I absolutely despise trying to reason with my code in, say, Python, to be sure that it isn't able to randomly fail due to an exception that can be thrown sometimes, but not always. 16:19 -!- path[l] [~path@122.182.0.38] has quit [Quit: path[l]] 16:20 < JBeshir> So a mechanism that allowed me to fairly solidly write "safe code" was something I was interested in seeing develop (or not) 16:20 -!- path[l] [~path@122.182.0.38] has joined #go-nuts 16:20 -!- zlu_ [~quassel@70-35-37-227.static.wiline.com] has joined #go-nuts 16:24 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has quit [Ping timeout: 264 seconds] 16:25 < petrux> gotta go now 16:25 < petrux> bye 16:25 -!- petrux [~petrux@host16-224-static.53-82-b.business.telecomitalia.it] has quit [Quit: leaving] 16:25 -!- zlu_ [~quassel@70-35-37-227.static.wiline.com] has quit [Ping timeout: 252 seconds] 16:26 -!- idea_squirrel [ct2rips@77-21-24-61-dynip.superkabel.de] has quit [Quit: Verlassend] 16:27 -!- krzyma [~krzyma@156.17.230.195] has quit [Quit: Leaving.] 16:31 -!- Wiz126 [Wiz126@72.20.220.206] has joined #go-nuts 16:32 -!- brrant [~John@65-102-225-46.hlrn.qwest.net] has joined #go-nuts 16:34 -!- tvw [~tv@212.79.9.150] has joined #go-nuts 16:39 -!- Fish [~Fish@78.251.198.48] has joined #go-nuts 16:42 -!- rv2733 [~rv2733@c-98-242-168-49.hsd1.fl.comcast.net] has quit [Quit: Leaving] 16:45 -!- Xurix [~Luixsia@AToulouse-254-1-34-53.w81-250.abo.wanadoo.fr] has joined #go-nuts 16:48 -!- carllerche [~carllerch@208.87.61.146] has joined #go-nuts 16:52 -!- surma [~surma@95-88-89-37-dynip.superkabel.de] has joined #go-nuts 16:53 -!- gisikw [~gisikw@137.28.186.120] has joined #go-nuts 16:56 -!- rlab [~Miranda@91.200.158.34] has quit [Read error: Connection reset by peer] 16:57 < Zoopee> Sorry, I sporadically get some time and then something pops up again... 16:57 -!- pdusen [~pdusen@crob4-55.flint.umich.edu] has quit [Quit: Leaving] 16:58 < Zoopee> The thing is, the problem with exceptions seems just to be bad use. 16:58 < JBeshir> "depends" 16:58 < Zoopee> Having used computers for long enough, any kind of error is something I'd expect to happen. 16:58 < JBeshir> Certainly, what I'd call bad use and Go's people seem to, too, is considered idiomatic in a lot of languages whose core libraries work that way. 16:59 < JBeshir> So you'd expect an "invalid parameters" error to happen when you were calling it with valid input? 17:00 < Zoopee> And in languages that use them, File I/O is one example where exceptions seem like a very appropriate way to handle errors. Because there are a lot of things that can go wrong, and generally there are just a few places to handle them. 17:00 < JBeshir> I would disagree. 17:00 -!- Nitro [~nitro@208.92.17.21] has quit [Quit: Leaving.] 17:01 < Zoopee> BRB again, sorry... 17:01 < JBeshir> You're in effect requiring alteration to the design and guarantees of every function up the call stack up to the place handling the exception-and making all of this invisible. 17:01 -!- pdusen [~pdusen@crob4-55.flint.umich.edu] has joined #go-nuts 17:02 -!- General1337 [~support@71-93-97-216.dhcp.mtpk.ca.charter.com] has joined #go-nuts 17:05 -!- carllerche [~carllerch@208.87.61.146] has quit [Quit: carllerche] 17:05 -!- rhelmer [~rhelmer@adsl-69-107-85-166.dsl.pltn13.pacbell.net] has quit [Read error: Connection reset by peer] 17:07 -!- path[l] [~path@122.182.0.38] has quit [Quit: path[l]] 17:07 -!- deso [~deso@x0561a.wh30.tu-dresden.de] has joined #go-nuts 17:08 -!- Xurix [~Luixsia@AToulouse-254-1-34-53.w81-250.abo.wanadoo.fr] has quit [Read error: Connection reset by peer] 17:10 -!- yaroslav [~yaroslav@109.170.106.65] has quit [Quit: yaroslav] 17:11 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has joined #go-nuts 17:15 < Zoopee> JBeshir: let's say, that you have some stack of libraries doing I/O. 17:16 -!- lux` [lux`@151.95.184.172] has joined #go-nuts 17:16 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:ed0a:211:b2a4:6a84] has joined #go-nuts 17:16 < Zoopee> JBeshir: then somewhere on the leaf of the call tree, some function actually issues the low-level write call, and the write fails, say because the disk is full. 17:17 < Zoopee> JBeshir: what can this function do with the error code from write? 17:17 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has quit [Ping timeout: 245 seconds] 17:17 < JBeshir> Presumably, you need some compatible way for the lower-level read functions to indicate an error back up. 17:17 < JBeshir> Lacking one is design failure. 17:17 < jessta> Zoopee: nothing, it returns the error to the caller 17:18 < JBeshir> Er, I/O functions. 17:18 < Zoopee> jessta: and the caller is your library's "writefoo" function. 17:18 < jessta> since i/o functions are expected to likely result in error 17:18 < JBeshir> While exceptions are an easy solution to the problem on the face of it, they're not maintainable. You then have the problem that it's entirely undocumented that the higher stuff up the stack can throw IO exceptions, or equally possible, that they *may* throw IOExceptions. 17:18 < JBeshir> Or *when* they may happen. 17:19 < Zoopee> JBeshir: it sounds to me like you are just describing bad exception use patterns. 17:19 < JBeshir> I'm describing the pattern you just described. 17:19 < Zoopee> we agreed that generally in this case, the leaf function can do little with the error other than just pass it back up. 17:20 < JBeshir> Right. And while exceptions are a nice convenient way to do that without alteration to the middle of the stack, you're quietly hiding that you're altering the guarantees and behaviour of the stuff in the middle. 17:20 < Zoopee> and one level up, you are probably still within some stack of I/O abstraction, so that's still the only thing you can do. 17:20 * kimelto knows a small language which deal errors this way (returning error back up). it was called C iirc ;) 17:20 < JBeshir> If your stuff is that long and ugly, yes. 17:21 < Zoopee> now 5 levels up, you actually get to a function that called the I/O and can actually do something useful with it, such as write it elsewhere, display an error message, ask the user what to do and when to retry, or whatever. 17:22 < JBeshir> That's a rather unnecessarily enterprisy call stack, but yes. 17:22 < Zoopee> JBeshir: are you implying that any decent I/O involves calling the low-level write/read directly? What if you have some crypto, buffering, data structure manipulation, or whatever on the way? 17:23 < JBeshir> No, I'm implying that if all your I/O is layers upon layers upon layers within your program, then things might be a tad ugly. 17:23 < Zoopee> kimelto: C is nice, and is doing the right thing within its model (i.e. simple, low level structured control flow). 17:24 < JBeshir> Nevertheless, yes, with exceptions or with return values or with any other method, what things do is throw the error up to a higher level to deal with until things are dealt with. 17:25 < JBeshir> Okay, taking your five level example, the two options so far as I can see work out like this: 17:25 < Zoopee> I am not happy with the common exception use patterns I see in Python, Java or C++ BTW. It's clear to me that exceptions are often misused, like other language features. 17:25 < JBeshir> - Return values: Long, but if each level is only making one "real" I/O write downwards, it shouldn't be a large amount of bookkeeping at all. 17:26 < JBeshir> - Unchecked exceptions: By the time you're five levels up, you're now *five levels away* from where the possibility of an IO exception is visible. 17:26 < Zoopee> On the other hand, the general implication from the arguments I hear here against exceptions, is some programmer's habit of ignoring / not handling them, and letting them directly bubble up where they shouldn't. 17:26 < JBeshir> As return values get more cumbersome, guaranteeing that exceptions for things which *must* be handled are always handled also gets harder. 17:27 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has joined #go-nuts 17:28 < Zoopee> And it seems to me the equivalent bad practice with error returns -- just ignoring the error code returned by write -- is not rare either, and worse. 17:29 < jessta> the problem with exceptions is that they don't offer you anything for the complexity involved 17:29 < JBeshir> At the very least, that won't result in your program randomly crapping itself while running because you made a call into something which called something which called something which called something which threw an exception. 17:29 < JBeshir> This is all my opinion, but it looks like what you're doing is moving work from visible code to necessary, constantly vigilant bookkeeping by the programmer, and in order to do that, mutating the flow of the program. 17:29 < Zoopee> jessta: are you talking about the implementation complexity (i.e. dealing with the call stack) or with the complexity of use? 17:29 < jessta> unchecked exceptions are insane, checked exceptions are annoying 17:29 < jessta> Zoopee: both 17:30 < jessta> go's panic/recover is really nice 17:30 < Zoopee> JBeshir: instead, it would result in your program just silently ignoring the error from write and ending up with corrupt data without the user or whomever realizing it. 17:30 < JBeshir> Zoopee: The difference is, it's immediately visible on looking at the call to the write() function that that is happening. 17:30 -!- TMKCodes [~toni@bbwirelessgw2-fee1dc00-62.dhcp.inet.fi] has quit [Ping timeout: 246 seconds] 17:30 < JBeshir> Hell, you could probably write a regex to catch it. 17:31 -!- bjarneh [~bjarneh@1x-193-157-196-134.uio.no] has joined #go-nuts 17:31 < Zoopee> By "unchecked" vs "checked" exceptions, you mean declaring what exception types may be raised? 17:31 < JBeshir> While safe exception handling is "do whole program analysis in your head" level. 17:31 < jessta> Zoopee: checked, how java does it 17:31 < jessta> unchecked, how python, c# etc. do it 17:32 < JBeshir> I don't mind checked exceptions so much- they're annoying and they mutate program flow, but they at least make it easy to write code that works reliably. 17:32 < JBeshir> Unchecked... yeah. 17:33 < Zoopee> JBeshir: I'm sorry, I'm obviously missing something. What do you mean here by how obvious it is? In either case, the error occurred in write(...) 10 levels down the stack. In one case there is a failure which you silently ignored, in the other case there is an exception, which if not handled (which is a bad thing) just eventually causes the program to crash with a stack trace saying the write failed somewhere. 17:34 < Zoopee> jessta: alright, so basically the issue of declaring what exceptions a function may raise as part of its interface. 17:34 < JBeshir> Zoopee: I mean that if you looked at the code and saw a call to write without a check on the return value, you instantly know that that is wrong- if you didn't know write, then a look at its signature would let you know. And that if you wanted, you could grep the source for calls to write() which didn't do that. 17:35 < JBeshir> While guaranteeing that everything calling something that throws an exception has an exception handler, or its caller does, or ITS caller does, either mentally or via analysis, is much, much, much harder. 17:35 < jessta> Zoopee: checked exceptions are very much similar to having a function return an error 17:36 -!- kssreeram [~kssreeram@122.174.139.125] has joined #go-nuts 17:37 < jessta> Zoopee: except that with checked exceptions the compiler yells at you if you don't catch the exception somewhere 17:37 < Zoopee> JBeshir: with checked exceptions, that's very easy 17:37 < jessta> Zoopee: which makes a lot of things really annoying 17:37 < JBeshir> Checked exceptions solve that problem, yes, but they lose the "make it easier" aspect of exceptions. 17:38 < JBeshir> So basically they just twist the way the code looks. You may as well just return an "err" up the stack instead of having everything up the stack marked as FooException. 17:39 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has joined #go-nuts 17:39 < Zoopee> jessta: that's true, because there are cases where you really can't expect an error while writing the code -- and in these cases just letting the exception bubble up sounds like the most sensible thing to do. 17:40 < JBeshir> If you don't expect an error while writing the code, then you're going to fail at guaranteeing that it gets fed to an exception handler. 17:40 < JBeshir> If it's legitimately an error you SHOULDN'T be expecting, like out of bounds array access or similar, then that is what panic/recover is for. 17:41 < Zoopee> JBeshir: except that then there are two problems: (1) you have to have boilerplace code to essentially just pass the error on in every function in the stack, and (2) as every function generally has its own errors, you lose information from the root cause by the time you get to handle it. 17:41 < JBeshir> Zoopee: Unless the err object can contain such information 17:41 < JBeshir> Zoopee: Which it can 17:41 < JBeshir> Well, struct. 17:41 < JBeshir> Well, thing-behind-an-interface 17:42 < Zoopee> JBeshir: so an "error you shouldn't be expecting" is basically just a way to classify bugs in the program / library / hardware? 17:42 < JBeshir> The boilerplate code is necessary, as it fundamentally is what makes the fact that an error can occur and needs passing on visible. 17:42 < JBeshir> Think of checked exceptions-they have boilerplate, too. 17:43 < JBeshir> Albiet theirs makes a slightly different compromise. 17:43 -!- TMKCodes [~toni@87-93-108-197.bb.dnainternet.fi] has joined #go-nuts 17:43 < JBeshir> It's shorter if there's lots of sources for the exceptions in the function, but loses the ability to see *what* in the function is getting it passed up. 17:43 < jessta> Zoopee: an error you sohuldn't be expecting is a programming error 17:43 -!- Project_2501 [~Marvin@82.84.91.170] has joined #go-nuts 17:43 < jessta> nil pointer, out of bounds etc. 17:43 < JBeshir> I would agree with jessta, basically, I'm not sure how the Go people decided on it. 17:44 < Project_2501> deh! 17:44 < JBeshir> panic/recover definitely have a big role in making, say, an application server not fail due to a programmer error in code answering a single request. 17:44 -!- carllerche [~carllerch@208.87.61.146] has joined #go-nuts 17:45 < JBeshir> I think that panic/recover basically serve the same need as unchecked exceptions in Java. 17:45 < JBeshir> That's how I kinda make sense of them. 17:45 < jessta> JBeshir: that would be 'checked exceptions' 17:45 < JBeshir> jessta: Java has unchecked exceptions, too. 17:46 < Zoopee> This sounds dangerous to me -- I bet people are going to start using panic for simple errors they could handle a lot more gracefully. 17:46 < JBeshir> jessta: They're used for shit you're not expected to catch. 17:46 < jessta> oh, sorry 17:46 < JBeshir> (Programmer error, largely) 17:46 < jessta> Zoopee: no, they wont' 17:46 -!- carllerche [~carllerch@208.87.61.146] has quit [Client Quit] 17:46 < jessta> Zoopee: beceause it's annoying to use 17:46 < JBeshir> Zoopee: The biggest source of abuse is already dealt with. 17:46 < JBeshir> In my view. 17:47 < JBeshir> It's hardest to deal with unchecked exceptions when they're being thrown from outside your own code, and the worst offender for this I've had to deal with has been standard library code. 17:47 < jessta> Zoopee: and people will beat you with a stick if you let a panic out of your package 17:47 -!- Wiz126 [Wiz126@72.20.220.206] has quit [] 17:48 < jessta> bed time for me 17:48 < Zoopee> In fact, a lot of code I have to deal with in my job, involves such calls to log(...) + abort(...) (or some equivalent of) deep in all kinds of libraries, because the authors of the libraries couldn't be bothered with handling it in a more useful way. 17:48 < jessta> night chaps 17:48 < Zoopee> G'night, jessta. 17:48 < JBeshir> Zoopee: The "result, err" idiom makes non-exception-based error handling easier 17:49 < bawr> Non-exception based error handling *is* easier, too. 17:49 < JBeshir> Zoopee: And abusing panic() requires an explicit call to the built-in of that name 17:49 -!- mbarkhau [~koloss@dslb-084-059-161-165.pools.arcor-ip.net] has joined #go-nuts 17:49 -!- TMKCodes [~toni@87-93-108-197.bb.dnainternet.fi] has quit [Quit: Leaving] 17:49 < JBeshir> And people will yell at you for it, and there's no general coding style for handling using libraries which routinely panic() 17:49 < JBeshir> So I'm hoping that abuse will be minimal. 17:50 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has quit [Ping timeout: 240 seconds] 17:50 < Zoopee> JBeshir: sure. And I'm not against it. I (used to, nowadays less so) write a lot of C, and clearly if you program properly error handling there works, and Go is just an improvement here. 17:52 < Zoopee> But most real-world code doesn't just involve entirely hermetic functions, but calls some functions that can fail, for "circumstantial" reasons, i.e. uses some system calls, allocates memory, communicates, or whatever. 17:52 -!- tvw [~tv@212.79.9.150] has quit [Remote host closed the connection] 17:53 < Zoopee> So with this pattern, you end up with the situation (as you get in C) where most of your functions have an error return value. 17:54 < JBeshir> If that's the case, then to write safe code, you need to guarantee that all of these things are handled. 17:54 -!- Ikkebr [~ikkibr@unaffiliated/ikkebr] has joined #go-nuts 17:54 < JBeshir> Although I don't know whether it's idiomatic in Go to check for success of memory allocation. 17:54 < taruti> not being to reuse foo,e := ...; if(e) { } is a pain 17:54 < taruti> since := needs both variables to be new 17:54 < taruti> and using = requires defining the types 17:55 < taruti> and using e1, e2, ... is tedious 17:55 -!- micrypt [~micrypt@41-184-21-79.rv.ipnxtelecoms.com] has quit [Ping timeout: 260 seconds] 17:55 < JBeshir> I thought := could redefine things in certain cases. 17:55 < Zoopee> JBeshir: but errors that your code can automatically handle, are in fact quite atypical 17:55 < JBeshir> Mostly to assist with that. 17:55 < JBeshir> Zoopee: In that case, errors that your code can't automatically handle 17:55 < taruti> hmm 17:56 < taruti> maybe that has changes 17:56 < JBeshir> Zoopee: Have no reason to be returned up for handling 17:56 < taruti> *changed 17:56 < JBeshir> Zoopee: And are fitting for panic() 17:56 -!- Ikke [~ikkibr@unaffiliated/ikkebr] has quit [Ping timeout: 260 seconds] 17:57 < JBeshir> The short version is that if return values are painful for a given amount of errors, then exceptions are even more fun to guarantee proper handling of. 17:57 < Zoopee> JBeshir: no, because they aren't bugs, and you can expect them to happen. 17:57 < JBeshir> If you can't handle them, there's no point in returning them for handling. 17:57 < taruti> JBeshir: many times I just want a "try to run this and if it fails for any reason then ..." 17:57 < JBeshir> taruti: That would be what recover() is for. 17:57 < Zoopee> JBeshir: for the common class of errors, the most sensible thing to do with is to get an error message to the right channel. 17:58 < Zoopee> JBeshir: the fact that you can't handle them, doesn't mean nobody can. 17:58 < JBeshir> They're either possible to handle, in which case you may as well return them, or impossible to handle, in which case they aren't. 17:59 < JBeshir> "you" also refers to your caller, and there's no reason another goroutine could be able to handle it but the caller not. 17:59 -!- slashus2 [~slashus2@74-137-24-74.dhcp.insightbb.com] has quit [Quit: slashus2] 18:00 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:ed0a:211:b2a4:6a84] has quit [Quit: Leaving.] 18:00 < Zoopee> It's conceivable that the user the text editor you just wrote, when trying to save a file and getting a "sorry, save failed, disk full" error message from the editor, while the editor keeps running, will free up some space in his home directory, and retry. 18:00 < JBeshir> I'm not sure why a message to another goroutine instead of to the parent is a good idea there. 18:01 < taruti> recover/panic looks mostly like exceptions with weird names 18:01 -!- TR2N [email@89-180-213-209.net.novis.pt] has joined #go-nuts 18:01 < JBeshir> Generally, if you're performing more than one I/O operation at all, which is common, you need to know that stuff broke reasonably nearby 18:01 < JBeshir> So you need to let the parents know that something broke or else interrupt their execution. 18:01 < Zoopee> JBeshir: sorry, I suppose you're referring to the "get an error message to the right channel" where I was using the word "channel" in the common abstract sense, not to refer to the CSP channel concept. 18:02 < JBeshir> Ah, yeah, that'd be the problem. 18:02 < JBeshir> Sorry. 18:06 < Zoopee> JBeshir: so if (1) your common way of handling errors is just propagating them up, until you get to the level that can report or somehow actually handle them, and (2) you assert that every error should be handled, and (3) you actually want to maintain the details of what went wrong when passing errors up, so your error return type needs to accommodate all errors you may pass up, 18:07 < JBeshir> The os.Error interface does that, yes. 18:07 < Zoopee> JBeshir: if so, what's the advantage over just checked exceptions? 18:07 < taruti> hmm, this seems quite nice. 18:07 < JBeshir> Zoopee: You can spin that around. 18:07 < taruti> now add a goWithLimitedResources and <3 18:08 < JBeshir> I think they're both safe approaches, myself, but checked exceptions requires structuring everything around try and catch blocks instead of using normal if statements and similar, doing weird things to code flow. 18:08 < Zoopee> JBeshir: what I mean is, in this case you have all the inconvenience of checked exceptions, so what's the advantage? 18:09 < JBeshir> You also have all the features of checked exceptions, largely. 18:09 < JBeshir> There's a little more boilerplate, for a little more obviousness in what is actually going on, and where the errors being bubbled up are coming from. 18:10 < taruti> checked exceptions are quite painful 18:10 < JBeshir> The big reason passing it up is better is that you don't need to totally change how code is structured by wrapping it in try/catch blocks to perform error handling. 18:10 < JBeshir> At any level which does do it. 18:11 < JBeshir> You just do an if statement on the return value, next to where the return value is read. 18:11 -!- franksalim [~frank@adsl-75-61-84-181.dsl.pltn13.sbcglobal.net] has joined #go-nuts 18:12 < taruti> the recover needing to be directly in the deferred function bit seems weird (if I don't misunderstand things) 18:13 < Zoopee> JBeshir: with exceptions, if all I do is pass the exception up, I don't need any code in the function to do it. 18:13 < JBeshir> Zoopee: You need stuff in the signature. 18:13 < JBeshir> You also probably need to wrap everything in a try {} finally {} to make cleanup safe 18:13 < Zoopee> JBeshir: but I only need it once. 18:13 < JBeshir> In most languages 18:13 < JBeshir> But lets consider defer() vs finally() as another orthagonal thing 18:13 < JBeshir> Er, finally {} 18:14 < taruti> defer is very very nice 18:14 < JBeshir> Zoopee: Yeah, I addressed that. 18:14 < Zoopee> JBeshir: And if I need cleanup, then I either need defer, or try/finally, or save the error, clean up, and return. 18:14 < JBeshir> The last multiplied by the number of errors is quite ew, but yes. 18:14 < JBeshir> 18:10 <JBeshir> There's a little more boilerplate, for a little more 18:14 < JBeshir> obviousness in what is actually going on, and where the 18:14 < JBeshir> errors being bubbled up are coming from. 18:14 < JBeshir> At "I only need it once". 18:15 < JBeshir> I'm doubtful that the average function in this stack of five functions calling down to write() makes lots of I/O calls. 18:16 < Zoopee> Now imagine a function that calls write 5 times, perhaps also to more than one file, and compare adding "if err: return 0, err" after every call to write, to just using exceptions. 18:16 < JBeshir> I'd normally expect one thing, say saveFile() to make a whole bunch, and the rest to be stupider. 18:16 < taruti> f, e = openFile(...); if(e) { ... } ; defer func() { closeFile(f) } <- now the issue is if this panics between openfile and the defer 18:16 < JBeshir> If it does, it's panicing inside a block indicating that f was not opened. 18:17 < taruti> should defensive code be: var f File; defer func() { closeFile(f) } ; f,e = openFile(...); ... 18:17 < JBeshir> So... irrelevant. 18:17 < JBeshir> It doesn't need closing if it panics in there, does it? 18:17 < JBeshir> because if e != nil, then f was not opened correctly. 18:17 < taruti> JBeshir: I'm thinking of the possiblity of asynchronous panics. 18:17 < JBeshir> Asynchronous panics? 18:18 < taruti> not sure whether it is possible to get things like that in Go at the moment 18:19 < Zoopee> JBeshir: now we're back to the implication that you can localize your errors within the stack, and errors can only happen in a very restricted set of points in the code, which I assert is just not true in the real world. 18:19 < JBeshir> I don't believe I made that implication. 18:19 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has quit [Quit: Lost terminal] 18:19 < JBeshir> My sole implication is this: However spread errors are through the stack, return value overhead is less bad than unchecked exception overhead, and pretty much just a less code mutating form of checked exceptions 18:21 < Zoopee> JBeshir: my assertion is: (1) you are going to have errors somewhere down the stack from the function that can actually handle them, and (2) there will be functions that call multiple functions that can return an error, and will need to pass on up the error from each of these. 18:21 < JBeshir> I'm saying that 2 is atypical of most functions in the case where the stack is large. 18:21 -!- zlu [~quassel@70-35-37-227.static.wiline.com] has joined #go-nuts 18:22 < JBeshir> At least sufficiently so that it's not going to be an overwhelming problem. 18:22 -!- marsu [~marsu@93.14.56.167] has joined #go-nuts 18:23 -!- carllerche [~carllerch@enginey-9.border1.sfo002.pnap.net] has joined #go-nuts 18:25 < JBeshir> I'm also saying that the clarity offered by making the passing and what functions are being passed explicit is worth the additional boilerplate. 18:27 -!- Honeyman [~Alex@212.67.17.185] has quit [Quit: õÈÏÖÕ Ñ ÏÔ ×ÁÓ (xchat 2.4.5 ÉÌÉ ÓÔÁÒÛÅ)] 18:27 -!- Macpunk [~macpunk@cpe-72-177-26-221.austin.res.rr.com] has joined #go-nuts 18:28 < Zoopee> JBeshir: imagine a function like this: WriteRecord(File f, r Record) { switch r.type { case FOO: Write(f, r.elem); case SPECIAL: WriteSpecialRecord(f, r); case MIXED: WriteMixedRecord(f, r); ... } } 18:29 < Zoopee> JBeshir: Now your Write, WriteMixedRecord, WriteSpecialRecord, and friends may all return various I/O errors. 18:29 < Zoopee> JBeshir: And the read equivalent will involve memory allocation too... 18:30 -!- zlu [~quassel@70-35-37-227.static.wiline.com] has quit [Ping timeout: 276 seconds] 18:30 < JBeshir> I'm not sure that memory allocation is considered idiomatic to check for in Go. 18:31 < JBeshir> I wish you luck handling that one by exception in any way other than "whatever went wrong, clean it up and move on", which is what recover() is for. 18:31 < JBeshir> Because literally *everything* can do it. 18:31 < KirkMcDonald> The correct way to handle most errors, I think, it to terminate the process as loudly as possible. 18:33 < Zoopee> A simple read of some composite manually serialized data structure would actually likely involve many such functions, as each function first reads some header to get the type, then for composite types, calls read for all the relevant composite types, potentially in a loop if you have lists of objects serialized, and every such read on the way can fail, and every read of a blob of data will likely also allocate some memory. 18:33 < JBeshir> Zoopee: What you could do in that case, is set result, err = AppropriateWriteFunction() 18:33 < JBeshir> Zoopee: For each of the three possible calls 18:33 < JBeshir> And then have the boilerplate check on err once 18:33 < JBeshir> There you go, only once. 18:33 < Zoopee> JBeshir: but you need to do it after every such call 18:34 < JBeshir> But you're only making one call. 18:34 < JBeshir> You're just using a switch to pick which. 18:34 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 18:35 -!- slashus2 [~slashus2@74-137-24-74.dhcp.insightbb.com] has joined #go-nuts 18:35 < JBeshir> And I'm saying again and again that I'm not sure that memory allocation errors are considered within the realm of things you ought to handle. 18:35 < JBeshir> *every* heap allocation would need one, and heap allocations can be implicit 18:36 -!- tvw [~tv@e182076250.adsl.alicedsl.de] has joined #go-nuts 18:36 < JBeshir> If you take the address of a local variable, it is allocated on the heap. 18:36 < Zoopee> JBeshir: as for memory allocation failures: idiomatic or not, it can happen, I can expect it to happen with large allocations, and somewhere up the stack there's code that can gracefully handle it by reporting the failure to the user, returning an internal server error and logging it, or whatever. 18:36 < JBeshir> Large allocations are something different and special. 18:36 < JBeshir> And could be handled separately. 18:37 -!- scm [justme@c165103.adsl.hansenet.de] has quit [Ping timeout: 276 seconds] 18:37 < JBeshir> Returning an internal server error and logging it instead of completely crashing is *pretty much THE use case for recover()* 18:37 < Zoopee> JBeshir: in my serialized read example, you would have a lot of that, for instance. 18:37 < JBeshir> It literally is the best example of when you would use recover I have seen raised 18:37 < Zoopee> JBeshir: the same applies for write errors to a socket or file -- it's handled the same way. 18:37 < JBeshir> So "I would want to handle it because at some level I would want to deal with the whole thing crashing and discard the attempt" is I think not a valid reason to want to pass things up. 18:38 -!- scm [justme@c137062.adsl.hansenet.de] has joined #go-nuts 18:38 < JBeshir> Because that's recover()'s job. 18:38 < Zoopee> JBeshir: now you are contradicting your previous definition of when error returns as opposed to panic/recover are appropriate. 18:39 < JBeshir> Zoopee: No, you're taking what I emphasised as vague ideas as solid rules then trying to break them. 18:39 < JBeshir> Which frankly is not a constructive way to approach a conversation. 18:39 < Zoopee> Sorry, that wasn't my intention. 18:40 < Zoopee> But we were specifically using I/O errors as an example, and it's now not clear if you mean they should be handled using panic/recover or result, err returns. 18:40 < JBeshir> I/O, returns. 18:41 < JBeshir> I think this has gotten into trivialities, though. 18:41 < JBeshir> It's... just a little boilerplate. 18:41 < JBeshir> Boilerplate vs FooException-in-the-signature seems a minor thing to me. 18:42 < Zoopee> So why do you handle "cannot write 2MB to the file because the disk is full" differently than "cannot read 2MB from the file because there is no free memory"? 18:42 < JBeshir> Well, aside anything else, no free memory probably won't happen, from what I recall of OSes. 18:42 <+iant> In my opinion, there is nothing wrong with using panic within a single package, but in general, the only panic which should escape a single package is for something that "can't happen" 18:42 <+iant> running out of memory is something that "can't happen" 18:43 < JBeshir> I think the OS will happily allocate you your 2MB, then when you try to use it, invoke OOM killer 18:43 < JBeshir> Not sure about that. 18:43 <+iant> that tends to be how Linux works, yes 18:43 <+iant> other kernels work differently 18:44 < JBeshir> It's great to hear a proper opinion on it, thanks. 18:45 <+iant> well, it's just my opinion, it's not necessarily the only one 18:46 < Zoopee> The OOM killer is a rather complex thing these days. 18:46 < Zoopee> But simple memory allocations can definitely fail in many cases. 18:46 <+iant> not really 18:46 <+iant> not in practice 18:46 < Zoopee> brk(2) can set errno = ENOMEM, and so can malloc. 18:47 <+iant> and I say that having written a program which really does run out of memory (the linker) 18:47 <+iant> sure, it is possible 18:47 <+iant> but in a normal program it never happens 18:47 <+iant> it's acceptable to panic when it does happen 18:47 <+iant> because in a normal program it means that something has gone badly wrong 18:47 -!- jalmeida [~jalmeida@c934233f.virtua.com.br] has joined #go-nuts 18:47 <+iant> that's why I put "can't happen" in scare quotes 18:49 -!- terrex [~terrex@28.39.222.87.dynamic.jazztel.es] has joined #go-nuts 18:49 < Zoopee> My recollection from Linux is that the OOM killer is system wide, and tends to kill some heuristically chosen process. But if I do "ulimit -d 1048576" and run a program that tries to malloc(2097152), won't it get ENOMEM? 18:50 < Zoopee> Let me try this, I'm curious if I'll learn something unexpected here. 19:00 < anticw> iant: from a app POV in most OS there is no really nice way to deal with OOM 19:00 < anticw> iant: you can fault in a page in the middle of something unpredicatable and fall over 19:00 -!- illya77 [~illya77@74-254-133-95.pool.ukrtel.net] has joined #go-nuts 19:00 <+iant> I think I would say it depends on the goals of the OS 19:01 <+iant> a more reliable system would fail at the point where the memory allocation is made, and ensure that it can always satisfy any requested memory 19:01 <+iant> but that does constrain programs 19:01 <+iant> anyhow, different choices are possible 19:01 <+iant> and different choices are made in practice 19:02 <+iant> I'm not saying there is anything wrong with Linux's approach 19:02 < Zoopee> Alright, tried it on a few hosts with different systems. One two of them, ulimit just plain doesn't work (the program manages to allocate more memory than it should, and also access it in a loop). On three others where ulimit works, I get ENOMEM. 19:02 -!- TR2N [email@89-180-213-209.net.novis.pt] has quit [Ping timeout: 246 seconds] 19:05 -!- TR2N [email@89-180-217-41.net.novis.pt] has joined #go-nuts 19:06 -!- jalmeida [~jalmeida@c934233f.virtua.com.br] has quit [Remote host closed the connection] 19:06 -!- Eridius [~kevin@unaffiliated/eridius] has joined #go-nuts 19:08 < JBeshir> Zoopee: I'm curious what your point is 19:08 < JBeshir> Are you suggesting that checking all memory allocation is good? If so, what scheme would you suggest as a reliable means for doing so? 19:09 < KirkMcDonald> I would suggest that a failed memory allocation is usually not a recoverable error. 19:10 < JBeshir> I'm not sure any scheme; returning it up, checked exceptions, or unchecked exceptions, provide the ability to catch and handle it reliably in any manner other than one would with recover(), to abort entirely and try to move on. 19:14 -!- Xeon_ [~chatzilla@222.73.189.44] has joined #go-nuts 19:14 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has joined #go-nuts 19:17 -!- zlu [~quassel@70-35-37-227.static.wiline.com] has joined #go-nuts 19:17 -!- Xeon [~chatzilla@222.73.189.44] has quit [Ping timeout: 260 seconds] 19:19 -!- aho [~nya@f051194096.adsl.alicedsl.de] has joined #go-nuts 19:19 < Zoopee> Sorry, was away. 19:20 < Zoopee> JBeshir: in C code I always check malloc's return value. 19:21 < JBeshir> What do you do with it? 19:22 < Zoopee> JBeshir: for starters, avoid dereferencing the null pointer returned by malloc 19:22 < Zoopee> JBeshir: then generally return an error, which in the case of C depends on how error handling is done in that code, but tends to be a return -1, return NULL, or some equivalent. 19:25 < Zoopee> JBeshir: and in the appropriate place of the application code, give the user an error message "open file failed: Out of memorry", or return an "internal server error" and try to log it. 19:27 < Zoopee> Of course, if every malloc of 20 bytes fails, then likely there's not much the program can do at that point (i.e. even getting the error message to the user may fail), and it ends up just bailing out all the way up the stack. But the program does what it can, which often is good enough if you just have 1MB free, and happened to try to allocate 1.5MB somewhere. 19:27 -!- TMKCodes [~toni@bbwirelessgw2-fee1dc00-62.dhcp.inet.fi] has joined #go-nuts 19:27 < Zoopee> I would definitely not (intentionally) just ignore the return value, dereference the null pointer, and crash with a segmentation violation. That would be a bug. 19:27 < JBeshir> If you say so. 19:28 -!- actualmind [~bd5aa03c@gateway/web/freenode/x-gygcgxzntiksktel] has joined #go-nuts 19:28 < JBeshir> Most programs won't support stupid ulimits, and that seems to be the only case in which a normal program can semipsuedorely on it. 19:29 < Zoopee> what's semipsuedorely? 19:30 < JBeshir> sort-of-rely 19:30 < bawr> It's like quasipsuedorely, except twice. 19:32 < Zoopee> what's differentiates a "stupid ulimit" with a "smart ulimit"? 19:32 < JBeshir> "It exists" 19:32 < JBeshir> And is lower than the application's requirements, I guess. 19:35 < Zoopee> I'm really baffled. 19:35 < JBeshir> What I'm saying is that few programs consider ulimit constraint management their job. 19:35 -!- zlu [~quassel@70-35-37-227.static.wiline.com] has quit [Read error: Connection reset by peer] 19:36 < JBeshir> But the appropriate configuration of ulimit to be the job of whoever is setting ulimits for some reason. 19:36 < Zoopee> Any application that processes some kind variable length input all in memory has no limit to the amount of memory it can try to allocate. 19:36 < Zoopee> The program doesn't need to know about ulimit at all, and definitely not manage it. 19:37 < Zoopee> But gracefully reporting an error when the user tries to open a 5GB image file, rather than crashing outright with a segmentation violation, seems most reasonable to me. 19:38 < Zoopee> But we're now just arguing beside the point. 19:39 -!- illya77 [~illya77@74-254-133-95.pool.ukrtel.net] has quit [Read error: Connection reset by peer] 19:40 -!- g0bl1n [~anonymous@a213-22-237-141.cpe.netcabo.pt] has quit [Quit: g0bl1n] 19:41 < Zoopee> Clearly all these errors that can be handled with exceptions can also be handled with error return values. Evidently there common bad uses of both, where errors are just ignored or not handled where they should be. 19:42 -!- mbarkhau [~koloss@dslb-084-059-161-165.pools.arcor-ip.net] has quit [Read error: Connection reset by peer] 19:42 -!- mbarkhau [~koloss@dslb-084-059-161-165.pools.arcor-ip.net] has joined #go-nuts 19:44 -!- surma [~surma@95-88-89-37-dynip.superkabel.de] has left #go-nuts [] 19:44 -!- surma [~surma@95-88-89-37-dynip.superkabel.de] has joined #go-nuts 19:45 -!- shawn [~shawn@208-78-98-92.slicehost.net] has quit [Ping timeout: 276 seconds] 19:45 < Zoopee> If you define panic / recover as a mechanism that should only be used for totally unexpected conditions (i.e. hardware or system corruption, code bugs), you have a clear notion on what it's for. 19:46 < surma> Guys, I'm playing around with the tar-package. So, the headers require the mode and everything to be int64, os.Stat() however gives me uint64. Is there a way to convert between those two keeping the binary representation (like - I can't believe im saying it - C++ reinterpret_cast or something)? 19:47 < kmeyer> int64(uint64(n)) will give you the same binary representation, so long as you ensure n is less than 2^31 ;) 19:47 < Zoopee> In which case we are left with the more interesting regular errors, i.e. I/O, memory, computation, allocation, etc, no matter how common they are or not. And the question of error codes vs. exceptions for those. 19:48 < Zoopee> Why int64 and not uint64 for the mode? 19:49 < kmeyer> ask the author of the tar package 19:49 < surma> Zoopee: Don't ask me, that's how it's defined archive/tar wants int64, os.FIleInfo gives uint64 19:49 < surma> kmeyer: exactly, but I want it to work with values larger 19:49 < surma> kmeyer: I don't care about the value, I want the binary representation to remain 19:49 < kmeyer> you're asking for help breaking type-safety 19:50 < Zoopee> I suppose you only ever get non-negative values that fit in less than 64 bits there, so a simple cast should work. 19:50 -!- leonod [leonod@zreahese.hus.sgsnet.se] has joined #go-nuts 19:50 < kmeyer> why are you using Go again? 19:50 < surma> kmeyer: I know, but how am I supposed to create tar archives if I can't use the values that os.Stat() gives me oO 19:51 < JBeshir> surma: No, there's no reinterpret-cast, that would be unsafe. 19:51 < surma> Zoopee: actually, that's a good point. But this is still somewhat inconsistent 19:51 < kmeyer> you think os.Stat() will tell you have files that are larger than (2^63 - 1) bytes? 19:51 < surma> kmeyer: No - i'm more afraid of the timestamps (nanoseconds) 19:51 < kmeyer> Ah. 19:51 < kmeyer> Why is os.Stat returning signed integers? 19:51 < JBeshir> surma: If it IS over, there is literally no way to contain it in the format. 19:52 < kmeyer> oh, oops 19:52 < JBeshir> surma: So if it is over, there is no solution to your problem. 19:52 < JBeshir> So I would conclude that it is probably going to be under. 19:52 < kmeyer> cross your fingers ;) 19:52 < Zoopee> surma: clearly for timestamps, sizes and such you don't just want a bitwise copy of the binary value. 19:54 < JBeshir> Actually, if Go requires two-complement systems, then uint64() and int64() on each other IS a reinterpret cast, so to speak 19:54 < JBeshir> They both just alter the meaning of the highest bit. 19:54 < kmeyer> JBeshir: well, unless they wrap at the limit 19:54 < JBeshir> (Well, it depends how overflow works) 19:54 < kmeyer> right. 19:54 < surma> Zoopee: well yeah, but right now I copied the value (with a cast), and gnu tar says the timestamps are invalid, that's why I'm here ;) 19:54 < Zoopee> so if your value doesn't fit in a signed int64 and that's what the tar package is expecting, there's little you can do about it - just giving it a negative value won't help. 19:54 < JBeshir> kmeyer: I believe wrapping is how it would work if it was a reinterpret cast. 19:54 < JBeshir> 11111111...1 being -1 and all. 19:55 < kmeyer> Er, sorry. I mean wrapping to 0, not to negative infinity 19:55 < JBeshir> That would be curious behaviour 19:55 < kmeyer> 1111...1 -> 0111...1 19:55 < kmeyer> It would be. 19:55 < kmeyer> But I'm not sure anything else is more or less correct 19:55 < JBeshir> I don't think there is a "correct" 19:55 -!- letoh [~letoh@59-105-29-139.adsl.dynamic.seed.net.tw] has quit [Quit: leaving] 19:55 < JBeshir> The correct value cannot be represented in the type you're casting to. 19:55 < Zoopee> surma: what kind of timestamp do you have? you have to go many many years to the future to overflow a signed int64, even with nanoseconds. 19:56 < JBeshir> Hmm. 19:57 < JBeshir> It's apparantly truncated. 19:57 < JBeshir> http://golang.org/doc/go_spec.html#Conversions 19:57 < surma> Zoopee: i just noticed, my mode doesnt work either. directories are now files :-/ 19:57 < surma> Zoopee: I guess I'll do some more thorough digging first, before I ask you guys again. Right now i'm somewhat in the dark 19:57 < JBeshir> Truncation is nice. 19:58 < JBeshir> It's probably closer to correct in more cases than wrapping. 19:58 < kmeyer> er 19:58 < kmeyer> it looks like it truncates and wraps 19:59 < kmeyer> int8(uint16(0xF0)) -> 0xF0 19:59 < Zoopee> JBeshir: isn't truncation between two 64-bit values a no-op? i.e. you still just get an equivalent of a reinterpret_cast or whatever? 19:59 < JBeshir> Er... no? 20:00 < Zoopee> surma: as for the mode, if that doesn't work I think you have totally corrupt values. file modes don't even use 16 bites. 20:03 < surma> Zoopee: I know, that's why i'm struggling oO 20:03 < surma> Zoopee: Ah, I see... i probably forgot the type-field which I have to set manually 20:06 < Zoopee> JBeshir: uhmm, I must be misreading the spec then. It says it first sign-extends or zero-extends (depending on whether it's signed or unsigned), and then bitwise truncates. Going from n-bit unsigned to n-bit signed, the "indefinite" bitwise extention is {x_n, x_(n-1), ..., x_0} -> {..., 0, 0, x_n, x_(n-1), ..., x_0}, right? 20:06 -!- bert2 [~IceChat7@p4FDCAE97.dip.t-dialin.net] has joined #go-nuts 20:06 < JBeshir> I don't see the word "bitwise" 20:07 -!- Boggy-B|1elium [~Boggy-B|H@93-96-78-46.zone4.bethere.co.uk] has joined #go-nuts 20:07 < JBeshir> I don't really undertand your notation, either, sorry. 20:08 <+iant> converting from int64 to uint64 does not change the bits 20:08 < JBeshir> Ah, I see. 20:08 <+iant> a negative int64 will become a large uint64 20:09 < Zoopee> Sorry, "bitwise" is an overloaded term. But truncation to n bits, basically just means removing all bits after the nth bit, doesn't it? 20:10 < Zoopee> (I think "bitwise" really should just be used for operations across values that just operate on the corresponding bits of the values individually) 20:10 -!- stalled [~stalled@unaffiliated/stalled] has quit [Ping timeout: 246 seconds] 20:10 -!- Boggy-B|Helium [~Boggy-B|H@93-96-78-46.zone4.bethere.co.uk] has quit [Ping timeout: 264 seconds] 20:16 -!- krzyma [~krzyma@156.17.230.195] has joined #go-nuts 20:17 -!- Wiz126 [Wiz126@72.20.221.212] has joined #go-nuts 20:19 -!- terrex [~terrex@28.39.222.87.dynamic.jazztel.es] has quit [Remote host closed the connection] 20:20 -!- stalled [~stalled@unaffiliated/stalled] has joined #go-nuts 20:21 -!- oal [~olav@5.79-160-122.customer.lyse.net] has quit [Remote host closed the connection] 20:22 < Zoopee> As far as I can tell, all integer conversions in Go act just like casts in C. 20:24 -!- travlr [~palexande@c-69-254-44-10.hsd1.fl.comcast.net] has quit [Remote host closed the connection] 20:26 < Zoopee> The only thing you can't do in Go that you can do in C for number conversion is indirect pointer casts (the equivalent of "float x = *((int *) (&y))"), where you want a binary copy between types that is completely meaningless in terms of the value interpretation. 20:27 < kmeyer> you can do that with the unsafe package, I think 20:27 < kmeyer> but of course, that defeats the purpose of the static-typing 20:28 -!- shawn [~shawn@208-78-98-92.slicehost.net] has joined #go-nuts 20:29 < Zoopee> Well, only in the context where you are doing it. 20:31 < Zoopee> Which is the same as with reinterpret_cast in C++. The rest of your code is supposedly still checked and safe, so long as you really know what you are doing on that part where you bypassed the type checking. 20:32 < Zoopee> the string type is implemented with a length count, not null-terminated, right? 20:33 -!- actualmind [~bd5aa03c@gateway/web/freenode/x-gygcgxzntiksktel] has quit [Ping timeout: 248 seconds] 20:34 -!- bert2 [~IceChat7@p4FDCAE97.dip.t-dialin.net] has quit [Ping timeout: 260 seconds] 20:34 <+iant> right 20:34 < Zoopee> i.e. len(s) is O(1) and concatenating many strings naively is efficient other than for the copy 20:34 < Zoopee> Cool. 20:35 < JBeshir> And slicing strings is zero-copy, yes. 20:36 -!- bmizerany [~bmizerany@dsl081-064-072.sfo1.dsl.speakeasy.net] has joined #go-nuts 20:37 -!- krzyma [~krzyma@156.17.230.195] has left #go-nuts [] 20:38 -!- Kashia [~Kashia@port-92-200-37-101.dynamic.qsc.de] has joined #go-nuts 20:39 -!- travlr [~palexande@c-69-254-44-10.hsd1.fl.comcast.net] has joined #go-nuts 20:40 -!- Venom_X_ [~pjacobs@71.20.102.220] has joined #go-nuts 20:40 < surma> Zoopee: I figured it out, the tar-headers take seconds, not nanoseconds, that why gnu tar is bitching 20:40 -!- stalled [~stalled@unaffiliated/stalled] has quit [Ping timeout: 246 seconds] 20:41 < Zoopee> Next step in programming language type systems: physical units. 20:41 -!- krelian [~chatzilla@201.250.92.210] has joined #go-nuts 20:41 -!- Macpunk [~macpunk@cpe-72-177-26-221.austin.res.rr.com] has quit [Ping timeout: 260 seconds] 20:41 -!- Venom_X [~pjacobs@74.61.90.217] has quit [Ping timeout: 260 seconds] 20:43 < Zoopee> var power int (kilogram * metre * metre / second / second / second) = 200 20:44 -!- pdusen [~pdusen@crob4-55.flint.umich.edu] has quit [Read error: Connection reset by peer] 20:44 < Zoopee> s/int/float/, of course -- and typedefs to make it just "var power int (watt)" 20:47 < Zoopee> Actually thinking of it, it would be rather straightforward to implement entirely at the compiler level. 20:48 -!- GilJ [~gilles@85.10.72.85] has quit [Remote host closed the connection] 20:49 -!- Venom_X_ [~pjacobs@71.20.102.220] has joined #go-nuts 20:52 -!- Venom_X [~pjacobs@71.20.102.220] has quit [Ping timeout: 258 seconds] 20:53 -!- rlab [~Miranda@91.200.158.34] has quit [Read error: Connection reset by peer] 20:53 -!- stalled [~stalled@unaffiliated/stalled] has joined #go-nuts 20:58 < Zoopee> Every numeric type has an optional unit qualifier. These are represented as a 7-tuple (metre, kilogram, second, coulomb, kelvin, mole, candela) internally in the compiler, and as for types as a tag (of 7 words) on the symbols in object files. 20:59 -!- afurlan [~afurlan@scorpion.mps.com.br] has quit [Quit: Leaving] 21:00 -!- Xurix [~Luixsia@AToulouse-254-1-34-53.w81-250.abo.wanadoo.fr] has joined #go-nuts 21:00 -!- rv2733 [~rv2733@c-98-242-168-49.hsd1.fl.comcast.net] has joined #go-nuts 21:02 < Zoopee> Use of a value in one unit in context of another unit is a compilation error in the same way as using an int32 value for a uint32. 21:04 -!- g0bl1n [~anonymous@a213-22-237-141.cpe.netcabo.pt] has joined #go-nuts 21:05 < Zoopee> That alone wouldn't have prevented surma's problem though. You need the scale too, i.e. coefficients, as you are likely to have to deal with different units of the same dimension sometimes (i.e. nanoseconds/seconds, or even lbs/kg). 21:06 -!- thomas_b [~thomasb@cm-84.215.37.40.getinternet.no] has joined #go-nuts 21:07 < JBeshir> I would be interested in some kind of preprocessor-based extra-strength-type-system for Go. 21:07 < JBeshir> But I wouldn't know enough to say whether it belongs in the language or would even work well. 21:07 -!- warthurton [~warthurto@pdpc/supporter/active/warthurton] has quit [Quit: warthurton] 21:07 < surma> JBeshir: use m4 or somethin' 21:09 -!- stalled [~stalled@unaffiliated/stalled] has quit [Ping timeout: 246 seconds] 21:09 -!- perdix [~perdix@g227131143.adsl.alicedsl.de] has joined #go-nuts 21:09 -!- perdix [~perdix@g227131143.adsl.alicedsl.de] has quit [Changing host] 21:09 -!- perdix [~perdix@sxemacs/devel/perdix] has joined #go-nuts 21:09 -!- nhbar [~kv@wireless-169-235-63-127.ucr.edu] has joined #go-nuts 21:11 -!- rv2733 [~rv2733@c-98-242-168-49.hsd1.fl.comcast.net] has quit [Quit: Leaving] 21:12 -!- nhbar [~kv@wireless-169-235-63-127.ucr.edu] has left #go-nuts [] 21:14 < Zoopee> It's not inconceivable to add a tuple of float64 coefficients too though. The coefficients are static, as declared with the types -- a coefficient is never the result of arithmetic. Symbolic names are used for common alternative scale units (e.g. inch = 0.0254 metre). Arithmetic is only done on the coefficients at compile time when a conversion is (in the spirit of Go, explicitly) requested. 21:15 < surma> Zoopee: Although this would imply some implicit conversions which might not be desirable (at least not in go) 21:16 < Zoopee> surma: why implicit? 21:16 < surma> Zoopee: But I do agree, coefficients are a nice feature 21:16 < Zoopee> var t double<second> = 13.4 21:17 < surma> Zoopee: Now that you say it, without imlicit conversions it's still very useful 21:17 < JBeshir> Can't you create named types for that? 21:17 < surma> Zoopee: I was thinking about a function taking a double<hour> and you pass a double<second> 21:17 < surma> JBeshir: well, we'd have to define a lot of conversion functions then 21:18 < JBeshir> Aye. 21:18 < JBeshir> It would seem the way to do it with existing features, though. 21:18 < JBeshir> Probably more ugliness than it's worth, though. 21:18 -!- Fish [~Fish@78.251.198.48] has quit [Remote host closed the connection] 21:18 < surma> Indeed 21:19 < Zoopee> now "var u double<nano second>; u = t" is a compilation error, but "u = double<nano second>(a)" is OK, and (ignoring the trivial constant optimization in this case) just generates code to multiply by 1000000000. 21:21 < JBeshir> Zoopee: Why not just define a type called "nanosecond" based on uint64 or something? 21:22 -!- stalled [~stalled@unaffiliated/stalled] has joined #go-nuts 21:23 < Zoopee> So in your case with the tar package, you would just have gotten an incompatible units (uint64<nano second>, int64<second>) error from the compiler, which would have made it obvious, and it would only compile once you added the appropriate conversions. But you wouldn't need a manual division that you could get wrong -- just "tar_timestamp = int64<nano second>(timestamp)" would do the right thing no matter what type timestamp is. 21:23 -!- alexbobp [~alex@66.112.249.162] has quit [Ping timeout: 252 seconds] 21:24 -!- alexbobp [~alex@66.112.249.162] has joined #go-nuts 21:24 < Zoopee> JBeshdir: But then your type for "second" would be the same, and a naive conversion would give you unexpected values. 21:26 -!- Venom_X [~pjacobs@71.20.102.220] has quit [Quit: Venom_X] 21:27 -!- deso [~deso@x0561a.wh30.tu-dresden.de] has quit [Remote host closed the connection] 21:30 < Zoopee> I think the "type<units>" syntax would violate Go's context-free grammar property though. A shame because it looks so natural... 21:30 -!- Macpunk [~macpunk@cpe-72-177-26-221.austin.res.rr.com] has joined #go-nuts 21:31 -!- Ikkebr [~ikkibr@unaffiliated/ikkebr] has quit [] 21:31 -!- carllerche_ [~carllerch@enginey-9.border1.sfo002.pnap.net] has joined #go-nuts 21:31 -!- g0bl1n [~anonymous@a213-22-237-141.cpe.netcabo.pt] has quit [Quit: g0bl1n] 21:31 < Zoopee> Actually on second thought, it wouldn't -- < > are only used in comparison operators in Go currently, or so it seems from a quick search in the specs anyway. 21:32 -!- rhelmer [~rhelmer@adsl-69-107-66-185.dsl.pltn13.pacbell.net] has joined #go-nuts 21:32 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has quit [Ping timeout: 258 seconds] 21:35 -!- carllerche [~carllerch@enginey-9.border1.sfo002.pnap.net] has quit [Ping timeout: 264 seconds] 21:35 < Zoopee> Alright, I'm off. 21:36 < surma> Zoopee: cya, thanks for your help :) 21:40 -!- ShadowIce` [pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts 21:40 -!- eivindu [~eivindu@97.107.128.229] has joined #go-nuts 21:43 -!- ShadowIce [pyoro@unaffiliated/shadowice-x841044] has quit [Ping timeout: 252 seconds] 21:47 -!- leonod [leonod@zreahese.hus.sgsnet.se] has quit [] 21:47 -!- rhelmer [~rhelmer@adsl-69-107-66-185.dsl.pltn13.pacbell.net] has quit [Read error: Connection reset by peer] 21:47 -!- rhelmer [~rhelmer@adsl-69-107-66-185.dsl.pltn13.pacbell.net] has joined #go-nuts 21:52 -!- cmarcelo [~cmarcelo@enlightenment/developer/cmarcelo] has quit [Quit: leaving] 21:52 -!- Venom_X [~pjacobs@71.20.102.220] has joined #go-nuts 22:02 -!- jA_cOp [~yakobu@unaffiliated/ja-cop/x-9478493] has quit [Quit: Leaving] 22:03 -!- rv2733 [~rv2733@c-98-242-168-49.hsd1.fl.comcast.net] has joined #go-nuts 22:09 -!- ShadowIce` [pyoro@unaffiliated/shadowice-x841044] has quit [Quit: Verlassend] 22:09 -!- bmizerany [~bmizerany@dsl081-064-072.sfo1.dsl.speakeasy.net] has quit [Remote host closed the connection] 22:12 -!- gisikw [~gisikw@137.28.186.120] has quit [Quit: Leaving] 22:19 -!- General13372 [~support@71-93-97-216.dhcp.mtpk.ca.charter.com] has joined #go-nuts 22:21 -!- bmizerany [~bmizerany@dsl081-064-072.sfo1.dsl.speakeasy.net] has joined #go-nuts 22:23 -!- General1337 [~support@71-93-97-216.dhcp.mtpk.ca.charter.com] has quit [Ping timeout: 258 seconds] 22:24 -!- surma [~surma@95-88-89-37-dynip.superkabel.de] has left #go-nuts [] 22:24 -!- mtd [~martin@ops-13.xades.com] has quit [Ping timeout: 264 seconds] 22:25 -!- lux` [lux`@151.95.184.172] has quit [Read error: Connection reset by peer] 22:28 -!- mbarkhau [~koloss@dslb-084-059-161-165.pools.arcor-ip.net] has quit [Quit: Leaving.] 22:34 -!- awidegreen [~quassel@62.176.237.78] has quit [Remote host closed the connection] 22:35 -!- Project_2501 [~Marvin@82.84.91.170] has quit [Quit: E se abbasso questa leva che succ...] 22:38 -!- smw [~stephen@pool-96-232-88-231.nycmny.fios.verizon.net] has quit [Ping timeout: 245 seconds] 22:40 -!- gnuvince [~vince@70.35.167.187] has quit [Ping timeout: 248 seconds] 22:41 -!- gnuvince [~vince@201.55-ppp.3menatwork.com] has joined #go-nuts 22:59 -!- carllerche [~carllerch@enginey-9.border1.sfo002.pnap.net] has quit [Quit: carllerche] 23:02 -!- ikaros [~ikaros@f051096109.adsl.alicedsl.de] has quit [Quit: Leave the magic to Houdini] 23:02 -!- perdix [~perdix@sxemacs/devel/perdix] has quit [Quit: A cow. A trampoline. Together they fight crime!] 23:09 -!- ryan_baker [~ryan_bake@128-193-249-134.resnet.oregonstate.edu] has joined #go-nuts 23:17 -!- marsu [~marsu@93.14.56.167] has quit [Quit: Leaving] 23:19 -!- wuehlmaus [~wuehlmaus@p4FCC7E5D.dip.t-dialin.net] has quit [Ping timeout: 245 seconds] 23:24 -!- TMKCodes [~toni@bbwirelessgw2-fee1dc00-62.dhcp.inet.fi] has quit [Read error: Connection reset by peer] 23:30 -!- iant [~iant@nat/google/x-kdxqraxzsixsshwo] has quit [Ping timeout: 260 seconds] 23:33 -!- Macpunk [~macpunk@cpe-72-177-26-221.austin.res.rr.com] has quit [Quit: Leaving] 23:41 -!- ryan_baker [~ryan_bake@128-193-249-134.resnet.oregonstate.edu] has quit [Quit: ryan_baker] 23:41 -!- Nitro [~nitro@208.92.17.21] has joined #go-nuts 23:45 -!- felipe [~felipe@my.nada.kth.se] has quit [Quit: felipe] 23:51 -!- TMKCodes [~toni@bbwirelessgw2-fee1dc00-62.dhcp.inet.fi] has joined #go-nuts 23:53 -!- Venom_X_ [~pjacobs@71.20.102.220] has joined #go-nuts 23:55 -!- iant [~iant@67.218.109.44] has joined #go-nuts 23:56 -!- mode/#go-nuts [+v iant] by ChanServ 23:57 -!- Venom_X [~pjacobs@71.20.102.220] has quit [Ping timeout: 276 seconds] --- Log closed Thu Apr 15 00:00:46 2010