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

--- Log opened Wed Apr 14 00:00:08 2010
--- Day changed Wed Apr 14 2010
00:00 -!- Wiz126 [Wiz126@] 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
00:10 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has joined
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@] has quit [Ping timeout: 240 seconds]
00:25 -!- path[l] [UPP@] 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
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@] 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
00:43 -!- Venom_X [~pjacobs@] has quit [Quit: Venom_X]
00:53 -!- letoh [~letoh@59-105-29-149.adsl.dynamic.seed.net.tw] has quit [Quit:
00:54 -!- carllerche [~carllerch@] 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@] has quit [Ping timeout: 276 seconds]
01:05 -!- smw [~stephen@pool-96-232-88-231.nycmny.fios.verizon.net] has joined
01:19 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Quit: WeeChat]
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@] 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
02:15 -!- path[l] [UPP@] has quit [Quit: path[l]]
02:18 -!- aho [~nya@f051009011.adsl.alicedsl.de] has joined #go-nuts
02:21 -!- nettok [~netto@] has joined #go-nuts
02:27 -!- nettok_ [~netto@] has joined #go-nuts
02:28 -!- Nitro [~nitro@] has quit [Ping timeout: 264 seconds]
02:30 -!- nettok [~netto@] has quit [Ping timeout: 276 seconds]
02:32 -!- nettok__ [~netto@] has joined #go-nuts
02:34 -!- jA_cOp [~yakobu@unaffiliated/ja-cop/x-9478493] has joined #go-nuts
02:36 -!- nettok_ [~netto@] 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@] has joined #go-nuts
03:07 -!- nettok__ [~netto@] has quit [Ping timeout: 240 seconds]
03:09 -!- Adys [~Adys@unaffiliated/adys] has quit [Ping timeout: 265 seconds]
03:10 -!- SecretofMana [~mana@] has joined #go-nuts
03:13 -!- Eridius [~kevin@unaffiliated/eridius] has quit [Ping timeout: 260
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@] has joined #go-nuts
03:31 -!- Macpunk [~macpunk@cpe-72-177-26-221.austin.res.rr.com] has joined
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@] has quit [Ping timeout: 240 seconds]
03:49 -!- kssreeram [~kssreeram@] has quit [Quit: kssreeram]
03:51 -!- nettok__ [~netto@] has joined #go-nuts
03:56 -!- nettok_ [~netto@] has quit [Ping timeout: 276 seconds]
04:00 < plexdev> http://is.gd/brOjU by [Russ Cox] in go/doc/ -- go_spec
04:09 -!- warthurton [~warthurto@pdpc/supporter/active/warthurton] has quit [Quit:
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
04:28 -!- rhelmer [~rhelmer@adsl-69-107-85-166.dsl.pltn13.pacbell.net] has joined
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@] has joined #go-nuts
05:00 -!- nettok__ [~netto@] 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@] has joined #go-nuts
05:14 -!- nettok_ [~netto@] has quit [Ping timeout: 276 seconds]
05:15 -!- carllerche [~carllerch@] has joined #go-nuts
05:17 -!- travlr [~palexande@c-69-254-44-10.hsd1.fl.comcast.net] has joined
05:23 -!- cco3 [~conley@c-69-181-139-23.hsd1.ca.comcast.net] has quit [Ping
timeout: 246 seconds]
05:23 -!- nettok [~netto@] has joined #go-nuts
05:26 -!- nettok__ [~netto@] 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@] 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@] has quit [Ping timeout: 248 seconds]
05:41 -!- carllerche [~carllerch@] has quit [Quit: carllerche]
05:43 -!- robot12 [~robot12@robot12.kgts.ru] has joined #go-nuts
05:43 -!- carllerche [~carllerch@] 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@] has joined #go-nuts
05:52 -!- carllerche [~carllerch@] has quit [Quit: carllerche]
05:55 -!- nettok_ [~netto@] has quit [Ping timeout: 240 seconds]
05:59 < nf> Archwyrm: fixed now
06:00 -!- warthurton [~warthurto@pdpc/supporter/active/warthurton] has joined
06:00 -!- nettok__ [~netto@] 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@] 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:
06:23 -!- nettok_ [~netto@] has joined #go-nuts
06:24 -!- sjbrown [~sjbrown@c-69-181-182-137.hsd1.ca.comcast.net] has joined
06:24 -!- sjbrown [~sjbrown@c-69-181-182-137.hsd1.ca.comcast.net] has quit [Remote
host closed the connection]
06:27 -!- nettok__ [~netto@] has quit [Ping timeout: 264 seconds]
06:27 -!- nettok_ [~netto@] 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:
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
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@] 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.] has joined
07:43 -!- Majk [~Majk@tm.] has quit
[Client Quit]
07:43 < petrux> manveru: I know.  :-) Ok, I'm going to search for some
07:43 < manveru> kmeyer: yeah, just wanted to reduce the amount of offset
07:43 < manveru> petrux: there is one in the go source
07:43 < petrux> manveru: I've found this post:
07:44 < petrux> Ok, didn't know that.  Thanks.
07:44 -!- rlab [~Miranda@] 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@] has joined #go-nuts
07:56 -!- JasonWoof [~JasonWoof@fsf/member/herkamire] has joined #go-nuts
07:58 -!- gnuvince [~vince@] has quit [Ping timeout: 258 seconds]
08:02 -!- tux21b [~christoph@] 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
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@] has joined #go-nuts
08:21 < JasonWoof> for running locally, I'm fine with just
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:
08:54 -!- path[l] [UPP@] 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@] has joined #go-nuts
08:58 < JasonWoof> chressie: cool!
09:04 -!- Fish-Work [~Fish@] 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@] has joined #go-nuts
09:07 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has joined
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@] 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:
09:16 -!- ssb [~ssb@] has quit [Ping timeout: 260 seconds]
09:18 -!- rlab [~Miranda@] has quit [Read error: Connection reset by
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@] has joined #go-nuts
09:36 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Ping timeout: 264
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
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@] has quit [Quit: path[l]]
09:59 -!- path[l] [~path@] has joined #go-nuts
10:04 -!- tvw [~tv@] 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
10:18 < manveru> JasonWoof:
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
10:28 -!- ampleyfly [~ampleyfly@h-148-139.A163.priv.bahnhof.se] has joined
10:29 < JasonWoof> my goal is to learn go, and fiddle with the new (to me)
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@] 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@] has quit [Remote host closed the
11:06 -!- path[l] [~path@] 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@] has left #go-nuts []
11:25 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Quit: WeeChat]
11:25 -!- kikofx [~kiko@] 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
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
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@] 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
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@] has quit [Quit: Leaving.]
12:44 -!- cmarcelo [~cmarcelo@] has joined #go-nuts
12:44 -!- cmarcelo [~cmarcelo@] has quit [Changing host]
12:44 -!- cmarcelo [~cmarcelo@enlightenment/developer/cmarcelo] has joined
12:49 -!- path[l]_ [~path@] has joined #go-nuts
12:50 -!- path[l] [~path@] has quit [Ping timeout: 246 seconds]
12:51 -!- Gracenotes [~person@wikipedia/Gracenotes] has quit [Ping timeout: 276
12:59 -!- rlab [~Miranda@] 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@] 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
13:26 -!- zyichi [~zyichi@] has joined #go-nuts
13:27 -!- letoh [~letoh@59-105-29-139.adsl.dynamic.seed.net.tw] has joined
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@] has joined #go-nuts
13:37 -!- meanburrito920 [~john@] 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
14:02 -!- iant [~iant@] has joined #go-nuts
14:03 -!- mode/#go-nuts [+v iant] by ChanServ
14:03 -!- Venom_X [~pjacobs@] 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
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
14:17 -!- surma [~surma@zb4c3.pia.fu-berlin.de] has left #go-nuts []
14:19 -!- Nitro [~nitro@] 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@] has joined #go-nuts
14:24 -!- meanburrito920 [~john@] has quit [Changing host]
14:24 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has joined #go-nuts
14:29 -!- tux21b [~christoph@] has quit [Quit: Ex-Chat]
14:35 -!- m-takagi [~m-takagi@linode.m-takagi.jp] has joined #go-nuts
14:36 -!- Wiz126 [Wiz126@] 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@] has joined #go-nuts
14:53 -!- drry [~drry@unaffiliated/drry] has quit [Read error: Connection reset by
14:54 -!- drry [~drry@unaffiliated/drry] has joined #go-nuts
14:55 -!- Wiz126 [Wiz126@] has joined #go-nuts
14:55 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Quit: Leaving.]
14:57 -!- Honeyman [~Alex@] has joined #go-nuts
14:58 -!- kaigan|work
[~kaigan@c-8290e255.1411-10-64736c14.cust.bredbandsbolaget.se] has quit [Quit:
14:59 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has quit [Quit:
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@] has quit [Ping timeout: 245 seconds]
15:04 -!- gnuvince_ [~vince@] 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
15:13 < Honeyman> They say that GCC 4.5 just got released.  Any idea anyone
will it include gccgo?
15:13 -!- zyichi [~zyichi@] has quit [Quit: zyichi]
15:16 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has quit [Quit:
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
15:20 -!- gnuvince [~vince@] has joined #go-nuts
15:22 -!- zyichi [~zyichi@] 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
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@] 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@] has joined
15:36 -!- Ikke [~ikkibr@] has quit [Changing
15:36 -!- Ikke [~ikkibr@unaffiliated/ikkebr] has joined #go-nuts
15:51 -!- yaroslav [~yaroslav@] has joined #go-nuts
15:51 -!- krzyma [~krzyma@] 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@] 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@] 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@] 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@] 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@] 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@] 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@] 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:
16:27 -!- krzyma [~krzyma@] has quit [Quit: Leaving.]
16:31 -!- Wiz126 [Wiz126@] has joined #go-nuts
16:32 -!- brrant [~John@65-102-225-46.hlrn.qwest.net] has joined #go-nuts
16:34 -!- tvw [~tv@] has joined #go-nuts
16:39 -!- Fish [~Fish@] has joined #go-nuts
16:42 -!- rv2733 [~rv2733@c-98-242-168-49.hsd1.fl.comcast.net] has quit [Quit:
16:45 -!- Xurix [~Luixsia@AToulouse-254-1-34-53.w81-250.abo.wanadoo.fr] has joined
16:48 -!- carllerche [~carllerch@] has joined #go-nuts
16:52 -!- surma [~surma@95-88-89-37-dynip.superkabel.de] has joined #go-nuts
16:53 -!- gisikw [~gisikw@] has joined #go-nuts
16:56 -!- rlab [~Miranda@] has quit [Read error: Connection reset by
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
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@] 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
17:05 -!- carllerche [~carllerch@] 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@] 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@] has quit [Quit: yaroslav]
17:11 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has joined
17:15 < Zoopee> JBeshir: let's say, that you have some stack of libraries
doing I/O.
17:16 -!- lux` [lux`@] has joined #go-nuts
17:16 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:ed0a:211:b2a4:6a84] has joined
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
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"
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
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
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
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@] 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
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
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
17:43 -!- Project_2501 [~Marvin@] 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
17:44 -!- carllerche [~carllerch@] 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@] 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@] 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
17:49 -!- TMKCodes [~toni@87-93-108-197.bb.dnainternet.fi] has quit [Quit:
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
17:52 -!- tvw [~tv@] 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:
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
18:07 < JBeshir> The os.Error interface does that, yes.
18:07 < Zoopee> JBeshir: if so, what's the advantage over just checked
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,
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
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
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
18:19 < JBeshir> I don't believe I made that implication.
18:19 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has quit [Quit: Lost
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@] has joined #go-nuts
18:23 -!- carllerche [~carllerch@enginey-9.border1.sfo002.pnap.net] has joined
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
18:27 -!- Honeyman [~Alex@] has quit [Quit: õÈÏÖÕ Ñ ÏÔ ×ÁÓ (xchat
2.4.5 ÉÌÉ ÓÔÁÒÛÅ)]
18:27 -!- Macpunk [~macpunk@cpe-72-177-26-221.austin.res.rr.com] has joined
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@] 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
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
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
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
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
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@] 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
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
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@] has joined #go-nuts
19:14 -!- millertimek1a2m3 [~adam@rrcs-67-79-54-130.sw.biz.rr.com] has joined
19:17 -!- zlu [~quassel@70-35-37-227.static.wiline.com] has joined #go-nuts
19:17 -!- Xeon [~chatzilla@] 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
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
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:
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
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
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
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
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
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:
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
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
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
20:10 -!- stalled [~stalled@unaffiliated/stalled] has quit [Ping timeout: 246
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@] has joined #go-nuts
20:17 -!- Wiz126 [Wiz126@] has joined #go-nuts
20:19 -!- terrex [~terrex@] 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
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
20:37 -!- krzyma [~krzyma@] 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
20:40 -!- Venom_X_ [~pjacobs@] 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
20:41 < Zoopee> Next step in programming language type systems: physical
20:41 -!- krelian [~chatzilla@] 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@] 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@] has quit [Remote host closed the connection]
20:49 -!- Venom_X_ [~pjacobs@] has joined #go-nuts
20:52 -!- Venom_X [~pjacobs@] has quit [Ping timeout: 258 seconds]
20:53 -!- rlab [~Miranda@] has quit [Read error: Connection reset by
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
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-] 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:
21:07 < surma> JBeshir: use m4 or somethin'
21:09 -!- stalled [~stalled@unaffiliated/stalled] has quit [Ping timeout: 246
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:
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,
21:18 < JBeshir> Probably more ugliness than it's worth, though.
21:18 -!- Fish [~Fish@] 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
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@] has quit [Ping timeout: 252 seconds]
21:24 -!- alexbobp [~alex@] 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@] has quit [Quit: Venom_X]
21:27 -!- deso [~deso@x0561a.wh30.tu-dresden.de] has quit [Remote host closed the
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
21:31 -!- Ikkebr [~ikkibr@unaffiliated/ikkebr] has quit []
21:31 -!- carllerche_ [~carllerch@enginey-9.border1.sfo002.pnap.net] has joined
21:31 -!- g0bl1n [~anonymous@a213-22-237-141.cpe.netcabo.pt] has quit [Quit:
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
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@] 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
21:52 -!- cmarcelo [~cmarcelo@enlightenment/developer/cmarcelo] has quit [Quit:
21:52 -!- Venom_X [~pjacobs@] 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:
22:09 -!- bmizerany [~bmizerany@dsl081-064-072.sfo1.dsl.speakeasy.net] has quit
[Remote host closed the connection]
22:12 -!- gisikw [~gisikw@] has quit [Quit: Leaving]
22:19 -!- General13372 [~support@71-93-97-216.dhcp.mtpk.ca.charter.com] has joined
22:21 -!- bmizerany [~bmizerany@dsl081-064-072.sfo1.dsl.speakeasy.net] has joined
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`@] has quit [Read error: Connection reset by
22:28 -!- mbarkhau [~koloss@dslb-084-059-161-165.pools.arcor-ip.net] has quit
[Quit: Leaving.]
22:34 -!- awidegreen [~quassel@] has quit [Remote host closed the
22:35 -!- Project_2501 [~Marvin@] 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@] 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@] 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
23:33 -!- Macpunk [~macpunk@cpe-72-177-26-221.austin.res.rr.com] has quit [Quit:
23:41 -!- ryan_baker [~ryan_bake@128-193-249-134.resnet.oregonstate.edu] has quit
[Quit: ryan_baker]
23:41 -!- Nitro [~nitro@] 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
23:53 -!- Venom_X_ [~pjacobs@] has joined #go-nuts
23:55 -!- iant [~iant@] has joined #go-nuts
23:56 -!- mode/#go-nuts [+v iant] by ChanServ
23:57 -!- Venom_X [~pjacobs@] has quit [Ping timeout: 276 seconds]
--- Log closed Thu Apr 15 00:00:46 2010