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

--- Log opened Thu Nov 04 00:00:15 2010
00:11 -!- GoTest [~gotest@78-86-161-79.zone2.bethere.co.uk] has joined #go-nuts
00:13 -!- GoTest [~gotest@78-86-161-79.zone2.bethere.co.uk] has quit [Remote host
closed the connection]
00:15 -!- GoTest [~gotest@78-86-161-79.zone2.bethere.co.uk] has joined #go-nuts
00:16 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has quit [Quit:
This computer has gone to sleep]
00:18 -!- GoTest [~gotest@78-86-161-79.zone2.bethere.co.uk] has quit [Client Quit]
00:23 < artefon> what is the best method for working with chars?
00:25 < KirkMcDonald> artefon: I'm not sure what you mean.
00:25 < artefon> KirkMcDonald: i was thinking about the char type
00:26 < artefon> KirkMcDonald: but i think i can iterate over a string and
use switch for checking chars
00:27 < KirkMcDonald> Go does not have a "char" type.
00:27 < KirkMcDonald> It does have a "byte" type.
00:28 < KirkMcDonald> artefon: And iteration over a string gives ints.
00:28 < KirkMcDonald> Well, using "range" to iterate over a string gives
ints.
00:28 < artefon> KirkMcDonald: but the byte works with UTF8?
00:28 < artefon> KirkMcDonald: the range seems to be working ok
00:28 < KirkMcDonald> A byte holds a single byte.
00:29 < artefon> so, a character can have more than one byte
00:29 < artefon> so i better stick with ints
00:29 < KirkMcDonald> But using "range" decodes the UTF-8-encoded string on
the fly, yielding ints representing the Unicode code points.
00:29 < artefon> yes
00:29 < artefon> i want this
00:30 < artefon> because i am tokenizing a string
00:32 < KirkMcDonald> Okay.
00:32 < KirkMcDonald> So what was your question?  :-)
00:33 < MaybeSo> so I find myself copying huge chunks out of http/client.go
in order to get a version of Post() that lets me set my own headers and
req.UserAgent, is there something I'm missing here, some way to get at that
functionality w/o basically cloning all the private functions?
00:33 -!- sjbrown [~sjbrown@adsl-63-204-27-202.dsl.snfc21.pacbell.net] has joined
#go-nuts
00:33 < KirkMcDonald> MaybeSo: Perhaps edit the library and submit a patch.
00:34 -!- enherit [~enherit@cpe-98-149-170-48.socal.res.rr.com] has quit [Ping
timeout: 265 seconds]
00:34 < MaybeSo> *shrug* sure, I just figured I might be missing something
obvious
00:39 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has joined #go-nuts
00:40 < plexdev> http://is.gd/gGM3p by [Ken Thompson] in 3 subdirs of
go/src/ -- add hardware floating point.
00:40 < artefon> KirkMcDonald: i just wanted to know if there is no better
way
00:40 < artefon> but now i have another question ;)
00:40 < artefon> is there a way to iterate over vector.StringVector
00:41 -!- ExtraSpice [~XtraSpice@88.118.33.48] has quit [Remote host closed the
connection]
00:44 < KirkMcDonald> artefon: You can use range on it.  Notice that it is
defined as: type StringVector []string
00:44 < KirkMcDonald> If you have a *StringVector, you will need to
dereference it.
00:46 -!- cbeck [cbeck@firefly.cat.pdx.edu] has quit [Read error: Connection reset
by peer]
00:47 -!- GoBIR [~gobir@res-128-61-89-71.res.gatech.edu] has quit [Ping timeout:
240 seconds]
00:48 < artefon> humm
00:48 < artefon> KirkMcDonald: ooohh right
00:48 < artefon> KirkMcDonald: it worked
00:48 < artefon> thanks
00:48 -!- KBme [~KBme@2001:470:1f08:66b::2] has quit [Read error: Operation timed
out]
00:48 -!- cbeck_ [cbeck@firefly.cat.pdx.edu] has joined #go-nuts
00:48 -!- KBme [~KBme@9angled-2-pt.tunnel.tserv5.lon1.ipv6.he.net] has joined
#go-nuts
00:51 -!- GoBIR [~gobir@res-128-61-89-71.res.gatech.edu] has joined #go-nuts
00:52 -!- GoTest [~gotest@78-86-161-79.zone2.bethere.co.uk] has joined #go-nuts
00:52 -!- GoTest [~gotest@78-86-161-79.zone2.bethere.co.uk] has quit [Client Quit]
00:55 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has quit [Quit:
Leaving.]
00:57 < artefon> KirkMcDonald: thanks for your help
00:57 < artefon> byee guys
00:57 -!- artefon [~thiago@189.59.165.176] has quit [Quit: bye]
01:04 -!- iant [~iant@67.218.104.238] has quit [Quit: Leaving.]
01:05 -!- tvw [~tv@e176026241.adsl.alicedsl.de] has quit [Ping timeout: 245
seconds]
01:05 -!- kanru [~kanru@118-168-239-241.dynamic.hinet.net] has quit [Read error:
Operation timed out]
01:06 -!- flaguy48 [~gallard@user-0c6s350.cable.mindspring.com] has joined
#go-nuts
01:07 -!- adu [~ajr@pool-74-96-89-94.washdc.fios.verizon.net] has joined #go-nuts
01:16 -!- GoTest [~gotest@78-86-161-79.zone2.bethere.co.uk] has joined #go-nuts
01:16 -!- raylu [raylu@c-24-131-193-106.hsd1.pa.comcast.net] has left #go-nuts []
01:16 -!- GoTest [~gotest@78-86-161-79.zone2.bethere.co.uk] has quit [Client Quit]
01:18 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
01:26 -!- sjbrown [~sjbrown@adsl-63-204-27-202.dsl.snfc21.pacbell.net] has quit
[Quit: Leaving]
01:28 -!- mikespook [~mikespook@219.137.49.157] has joined #go-nuts
01:29 -!- ako [~nya@fuld-4d00d3c1.pool.mediaWays.net] has quit [Quit:
EXEC_over.METHOD_SUBLIMATION]
01:35 -!- lmoura [~lauromour@187.78.4.87] has quit [Quit: Leaving]
01:38 -!- dj2 [~dj2@CPE001f5b35feb4-CM0014048e0344.cpe.net.cable.rogers.com] has
joined #go-nuts
01:49 -!- atsampson [~ats@94-194-126-16.zone8.bethere.co.uk] has quit [Ping
timeout: 264 seconds]
01:50 -!- atsampson [~ats@94-194-126-16.zone8.bethere.co.uk] has joined #go-nuts
01:51 -!- Wiz126 [Wiz@h62.126.232.68.ip.windstream.net] has quit [Quit: bbl]
01:52 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has joined #go-nuts
02:01 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has joined #go-nuts
02:04 -!- binarypie [~binarypie@c-24-6-151-185.hsd1.ca.comcast.net] has joined
#go-nuts
02:16 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has quit [Quit:
Leaving.]
02:18 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has quit [Quit:
noktoborus_]
02:20 -!- niemeyer [~niemeyer@187.53.254.172] has quit [Ping timeout: 252 seconds]
02:22 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has joined #go-nuts
02:22 -!- Venom_X [~pjacobs@74.61.90.217] has quit [Quit: Venom_X]
02:24 -!- enherit [~enherit@71-83-188-75.dhcp.lnbh.ca.charter.com] has joined
#go-nuts
02:36 -!- dacc [~Adium@D-128-95-10-195.dhcp4.washington.edu] has quit [Ping
timeout: 250 seconds]
02:42 -!- dacc [~Adium@D-69-91-167-110.dhcp4.washington.edu] has joined #go-nuts
02:53 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3]
03:03 -!- dacc [~Adium@D-69-91-167-110.dhcp4.washington.edu] has quit [Quit:
Leaving.]
03:04 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has joined
#go-nuts
03:11 -!- binarypie [~binarypie@c-24-6-151-185.hsd1.ca.comcast.net] has quit
[Remote host closed the connection]
03:26 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has joined #go-nuts
03:26 -!- mode/#go-nuts [+v iant] by ChanServ
03:27 -!- htoothrot [~mux@71-8-117-228.dhcp.ftwo.tx.charter.com] has quit [Ping
timeout: 265 seconds]
03:31 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has quit [Ping
timeout: 272 seconds]
03:31 -!- iant [~iant@216.239.45.130] has joined #go-nuts
03:32 -!- mode/#go-nuts [+v iant] by ChanServ
03:32 -!- htoothrot [~mux@71-8-117-228.dhcp.ftwo.tx.charter.com] has joined
#go-nuts
03:32 -!- adu [~ajr@pool-74-96-89-94.washdc.fios.verizon.net] has quit [Quit: adu]
03:32 -!- Chopinnn [~Chopin@ti0018a380-dhcp2647.bb.online.no] has quit [Ping
timeout: 264 seconds]
03:34 -!- rejb [~rejb@unaffiliated/rejb] has quit [Ping timeout: 276 seconds]
03:38 -!- adu [~ajr@pool-74-96-89-94.washdc.fios.verizon.net] has joined #go-nuts
04:10 -!- Xenith [~xenith@2001:470:1:9:8002::1] has quit [Read error: Operation
timed out]
04:10 -!- Xenith [~xenith@2001:470:1:9:8002::1] has joined #go-nuts
04:12 -!- htoothrot [~mux@71-8-117-228.dhcp.ftwo.tx.charter.com] has quit [Ping
timeout: 272 seconds]
04:13 -!- cco3 [~conley@c-69-181-138-209.hsd1.ca.comcast.net] has joined #go-nuts
04:13 -!- enherit [~enherit@71-83-188-75.dhcp.lnbh.ca.charter.com] has quit [Ping
timeout: 245 seconds]
04:14 -!- htoothrot [~mux@66-169-185-121.dhcp.ftwo.tx.charter.com] has joined
#go-nuts
04:17 -!- dj2 [~dj2@CPE001f5b35feb4-CM0014048e0344.cpe.net.cable.rogers.com] has
quit [Remote host closed the connection]
04:38 -!- htoothrot [~mux@66-169-185-121.dhcp.ftwo.tx.charter.com] has quit [Ping
timeout: 260 seconds]
04:47 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Ping timeout: 240
seconds]
04:47 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has quit [Ping
timeout: 245 seconds]
04:48 -!- zozoR [~zozoR@5634798d.rev.stofanet.dk] has joined #go-nuts
04:53 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has joined #go-nuts
05:00 -!- tumdum [~tumdum@unaffiliated/tumdum] has joined #go-nuts
05:01 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
05:01 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has joined #go-nuts
05:03 -!- noktoborus__ [debian-tor@gateway/tor-sasl/noktoborus] has joined
#go-nuts
05:03 -!- htoothrot [~mux@66-169-185-121.dhcp.ftwo.tx.charter.com] has joined
#go-nuts
05:22 -!- tumdum [~tumdum@unaffiliated/tumdum] has quit [Quit: tumdum]
05:31 -!- tensorpudding [~user@99.148.202.191] has quit [Remote host closed the
connection]
05:31 -!- fabled [~fabled@mail.fi.jw.org] has joined #go-nuts
05:36 < uriel> slightly offtopic, but people here might find this quite
interesting:
05:36 < uriel> http://code.google.com/p/szl/
05:37 -!- Eridius [~kevin@unaffiliated/eridius] has quit [Ping timeout: 265
seconds]
05:37 < Archwyrm> Has anyone been successful at printing local variables in
gdb?  I did read the part about prepending the package name.
05:37 < uriel> (seems that word got out a bit too early, the links in the
homepage are broken)
06:04 -!- zozoR [~zozoR@5634798d.rev.stofanet.dk] has quit [Ping timeout: 264
seconds]
06:05 -!- viirya [~viirya@cml506-25.csie.ntu.edu.tw] has quit [Remote host closed
the connection]
06:06 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has quit [Quit:
This computer has gone to sleep]
06:07 -!- viirya [~viirya@cml506-25.csie.ntu.edu.tw] has joined #go-nuts
06:42 * nsf has just updated the alt go docs with his final crappy "design"
06:42 < nsf> at least it's more consistent now
06:49 -!- bjarneh [~bjarneh@1x-193-157-204-227.uio.no] has joined #go-nuts
06:55 -!- MashPotato [~ed@unaffiliated/mashpotato] has quit [Ping timeout: 265
seconds]
07:03 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|]
07:04 -!- MashPotato [~ed@unaffiliated/mashpotato] has joined #go-nuts
07:19 -!- adu [~ajr@pool-74-96-89-94.washdc.fios.verizon.net] has quit [Quit: adu]
07:31 -!- pgas [pgas@pdpc/supporter/active/pgas] has joined #go-nuts
07:32 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
07:50 -!- cco3 [~conley@c-69-181-138-209.hsd1.ca.comcast.net] has quit [Ping
timeout: 240 seconds]
07:51 -!- noktoborus__ [debian-tor@gateway/tor-sasl/noktoborus] has quit [Quit:
noktoborus__]
07:53 -!- ucasano [~ucasano@host153-182-static.227-95-b.business.telecomitalia.it]
has joined #go-nuts
07:55 -!- unhygienix [~unhygieni@host86-135-185-97.range86-135.btcentralplus.com]
has quit [Quit: unhygienix]
07:58 -!- GoBIR [~gobir@res-128-61-89-71.res.gatech.edu] has quit [Remote host
closed the connection]
08:00 -!- awidegreen [~quassel@p5DF1FBA7.dip.t-dialin.net] has joined #go-nuts
08:02 -!- GoBIR [~gobir@res-128-61-89-71.res.gatech.edu] has joined #go-nuts
08:12 -!- Tv [~tv@cpe-76-168-227-45.socal.res.rr.com] has quit [Quit: Leaving.]
08:19 -!- ronnyy [~quassel@2001:6f8:12c6:1c86:224:1dff:fed7:9541] has joined
#go-nuts
08:26 -!- Fish [~Fish@86.65.182.207] has joined #go-nuts
08:34 -!- pingveno [~pingveno@c-98-246-133-8.hsd1.or.comcast.net] has quit [Read
error: Connection reset by peer]
08:35 -!- pingveno [~pingveno@c-98-246-133-8.hsd1.or.comcast.net] has joined
#go-nuts
08:35 -!- SirPsychoS [~sp@c-24-13-132-255.hsd1.il.comcast.net] has joined #go-nuts
08:36 < SirPsychoS> Is there any better way to convert a []byte to a []int32
than using unsafe.Reflect and unsafe.Unreflect?  (and will that even work?)
08:48 -!- wrtp [~rog@92.17.68.10] has joined #go-nuts
08:57 -!- awidegreen_ [~quassel@p5DF1E2C3.dip.t-dialin.net] has joined #go-nuts
08:58 -!- awidegreen [~quassel@p5DF1FBA7.dip.t-dialin.net] has quit [Ping timeout:
245 seconds]
09:13 -!- zerd [~quassel@tor.zerd.net] has quit [Ping timeout: 240 seconds]
09:20 -!- sahid [~sahid@LNeuilly-152-21-22-10.w193-253.abo.wanadoo.fr] has joined
#go-nuts
09:20 -!- mikespook1 [~mikespook@219.137.253.133] has joined #go-nuts
09:20 -!- mikespook [~mikespook@219.137.49.157] has quit [Ping timeout: 240
seconds]
09:38 -!- mikespook1 [~mikespook@219.137.253.133] has quit [Quit: Leaving.]
09:39 -!- res99 [~anonymous@201.237.130.70] has quit [Quit: res99]
10:18 < nsf> does anyone know, is there a library in Go that will simplify
shell ops for me?  like "cp -r" for folders, etc.  Well actually that's the only
one I need for now, but it would be nice to have that kind of library
10:18 -!- SirPsychoS [~sp@c-24-13-132-255.hsd1.il.comcast.net] has quit [Ping
timeout: 240 seconds]
10:18 -!- boscop_ [~boscop@f055159129.adsl.alicedsl.de] has joined #go-nuts
10:19 -!- boscop [~boscop@f055016054.adsl.alicedsl.de] has quit [Ping timeout: 240
seconds]
10:20 < nsf> because, well, I can write all I need in ruby
10:20 < nsf> like a bunch of helper scripts
10:20 < nsf> but I really want to do all the stuff in go
10:24 -!- lmoura [~lauromour@187.78.4.87] has joined #go-nuts
10:24 -!- sacho [~sacho@46.10.9.69] has quit [Ping timeout: 255 seconds]
10:24 -!- sahid_ [~sahid@LNeuilly-152-21-22-10.w193-253.abo.wanadoo.fr] has joined
#go-nuts
10:25 -!- sahid_ [~sahid@LNeuilly-152-21-22-10.w193-253.abo.wanadoo.fr] has quit
[Client Quit]
10:31 < mpl> nsf: I don't understand your question.  what do you need more
than the syscalls in syscall or os ?
10:32 < nsf> mpl: I want "cp -r" :)
10:32 < nsf> even copying single file with "os" and "syscalls" isn't trivial
10:33 < mpl> you mean that you find it to complicated to do it with an
os.ForkExec for example?
10:34 < nsf> it is not portable
10:34 < mpl> uhm
10:34 < nsf> won't work for windows, it doesn't have "cp"
10:34 < mpl> how would you do it in ruby then?
10:35 < mpl> and how would ruby solve the problem that cp doesn't exist on
windows?
10:35 < nsf> I don't know about ruby
10:35 < nsf> but in python I can do that
10:35 < mpl> uh why did you say you could do it in ruby then?
10:36 < nsf> because I'll try to do it in ruby
10:36 < nsf> I'm sure ruby has the same stuff as python
10:36 < nsf> that's not the point at all
10:36 -!- artefon [~thiago@189.59.165.176] has joined #go-nuts
10:36 < nsf> I want that in go
10:36 < mpl> ok, then why would it be simpler in python ?
10:36 < nsf> if there is no such lib
10:36 < nsf> then it's ok
10:37 < mpl> I'm asking because I don't understand how/why python solves
this portability problem for you.
10:37 -!- sacho [~sacho@87-126-66-148.btc-net.bg] has joined #go-nuts
10:37 < mpl> does it have some sort of cp call that uses the right call
behind the scenes depending on the os?
10:38 < nsf> as far as I remember, yes
10:38 < mpl> uhm ok.
10:39 < nsf> http://docs.python.org/library/shutil.html
10:39 < mpl> well maybe you can propose a CL that offers such a feature is
the OS package.  dunno, don't really care honestly as I don't need windows
support.
10:40 < mpl> I see.
10:40 < nsf> frankly I don't care as well, I just need to get the thing done
10:40 < nsf> I have one ruby script already (which extracts info from go std
lib tree and makes a makefile for doc generator)
10:40 < nsf> I guess I'll just add more
10:51 < nsf> mpl: as expected, ruby has this thing even in a better form:
http://ruby-doc.org/core/classes/FileUtils.html
10:51 < nsf> because it resembles unix commands :)
10:53 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has joined #go-nuts
10:59 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Ping timeout: 240
seconds]
11:07 -!- tvw [~tv@e176006024.adsl.alicedsl.de] has joined #go-nuts
11:09 -!- zerd [~quassel@rex.zerd.net] has joined #go-nuts
11:18 -!- ExtraSpice [~XtraSpice@88.118.33.48] has joined #go-nuts
11:24 -!- niemeyer [~niemeyer@187.53.254.172] has joined #go-nuts
11:26 -!- virtualsue [~chatzilla@nat/cisco/x-unwhmxsqfagwdsci] has joined #go-nuts
11:31 -!- nf [~nf@124-171-40-108.dyn.iinet.net.au] has quit [Quit: received
SIGHEIL]
11:37 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3]
11:43 -!- beneth` [~beneth`@ks358244.kimsufi.com] has joined #go-nuts
12:05 -!- skejoe [~skejoe@188.114.142.231] has joined #go-nuts
12:08 -!- res99 [~anonymous@201.237.130.70] has joined #go-nuts
12:23 -!- virtualsue [~chatzilla@nat/cisco/x-unwhmxsqfagwdsci] has quit [Ping
timeout: 240 seconds]
12:24 -!- fhs [~fhs@pool-74-101-63-115.nycmny.east.verizon.net] has quit [Remote
host closed the connection]
12:36 -!- res99 [~anonymous@201.237.130.70] has quit [Quit: res99]
12:37 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has quit [Quit:
Leaving]
12:42 -!- nigelkerr [~nigelkerr@jstormichfw.jstor.org] has joined #go-nuts
12:51 -!- MX80 [~MX80@cust222.253.117.74.dsl.g3telecom.net] has joined #go-nuts
12:52 -!- fumblebee [~kgay@137.149.217.198] has joined #go-nuts
12:53 < fumblebee> Hello, I am learning Go for a comparative programming
languages course at university, I was wondering what you guys would say are some
of the more unique features of the language.
12:55 < Namegduf> Goroutines, methods on any time and interfaces, modules
and public/private rules
12:57 < Namegduf> Defer, multiple return values, and it might be neat to
discuss idioms like the use of panic()/recover() for true errors and
exception-like programming within a package, while retaining errors as returned
and the path of execution being what it looks like in all code you don't obviously
waive it in.
12:57 < Namegduf> *any type
12:59 < Namegduf> With goroutines, a useful thing to examine for extra is
the general use of synchronous I/O instead of asynchronous I/O, and the avoidance
of poll() and select(), and instead a "goroutine per connection" model;
12:59 < fumblebee> yeah
12:59 < fumblebee> I actually really like goroutines
12:59 < Namegduf> Synchronous I/O with channels for communication where
needed is much nicer to use, IMO.
12:59 < fumblebee> indeed
13:00 < Namegduf> Channels would be good, obviously.  :P
13:00 < Namegduf> Interfaces vs Objects would be a fun comparison, but I
would recommend being wary without a lot of experience in Go; you don't use them
in the same kind of ways.
13:00 -!- kanru [~kanru@218-161-123-221.dynamic.hinet.net] has joined #go-nuts
13:00 < fumblebee> yeah, I had already marked most of the features you
mentioned but it's nice to get confirmation obviously
13:01 < fumblebee> oh?
13:01 < fumblebee> What's the difference in Go?
13:01 < Namegduf> Generally, with objects you define a common "parent"
object ahead of time providing methods you want to implement; in general, you plan
ahead of time and have parent objects for subsets of functionality you want to use
generically, with inheritance.
13:02 < fumblebee> right
13:02 < fumblebee> I always forget that Go isn't technically OO.
13:02 < Namegduf> In Go, you just write the types with the methods you want,
then if you want to work on all types providing a subset of methods generically,
you define an interface *retroactively*.
13:02 < Namegduf> Because the types don't need to be changed to match a new
interface.
13:03 < fumblebee> so you basically write a "subclass" first then tie them
together later if you need them?
13:03 < Namegduf> Yes.
13:04 < fumblebee> innnnnteresting
13:04 < Namegduf> Embedding types in each other can allow a fairly clean
form of implementation inheritance, to avoid *some* code duplication, but you
don't get dynamic dispatch or the ability to assign the "subtype" to the "parent
type", I believe.
13:05 < fumblebee> there are a lot of cool ideas in this language, ever
since it came out I kinda wanted to learn it but as you may or may not know
assignments and stuff all the time isn't exactly conducive to learning a
programming language you don't really need.  I am pretty glad I picked this one.
13:05 < Namegduf> Yeah, I'm a bit of a fan.  :P
13:05 < Namegduf> And I do know what you mean there.
13:05 < fumblebee> no wai :O
13:06 < fumblebee> do you have any good tutorials for newbs btw?
13:06 < Namegduf> One-method interfaces are a nice idiom, too.
13:06 < fumblebee> aside from the stuff on the main site
13:06 < Namegduf> I defined a Write() method on my client type in my little
server
13:07 < Namegduf> And then used fmt.Fprintf(client, formatstring, ...)
13:08 -!- ExtraSpice [~XtraSpice@88.118.33.48] has quit [Remote host closed the
connection]
13:08 < fumblebee> >formatted print
13:08 < fumblebee> <3
13:08 < fumblebee> I hate concatenating stuff all over the place.
13:08 < Namegduf> Oh, important is type safety.
13:09 < Namegduf> Go is typed, doesn't permit types to implicit cast ever.
13:10 < Namegduf> Although it will wrap in an interface automatically if
passed to a function wanting a matched one.
13:10 < fumblebee> there's no casting?
13:10 < Namegduf> It has casting, it's just always explicit.
13:10 < Namegduf> C will convert between types of int and float
automatically.
13:10 < Namegduf> Go requires you do it explicitly.
13:11 < fumblebee> oh ok
13:11 < fumblebee> yeah alright, that actually makes a lot of sense
13:11 -!- cmarcelo [~cmarcelo@enlightenment/developer/cmarcelo] has joined
#go-nuts
13:11 < Namegduf> I like it, because casting changes the range of values the
type can handle safely, and making it "hidden" I think results in subtle bugs.
13:11 < Namegduf> Not type, variable.
13:12 < fumblebee> well to be fair if you do an unsafe implicit cast you get
a compiler warning(generally)
13:12 < Namegduf> That is true.
13:15 < fumblebee> also what is with the semi-colon thing
13:15 < fumblebee> it seems kind of silly to have them be optional in the
actual source code
13:16 < Namegduf> Treat "semicolon" as a word for "end of statement"
13:17 < Namegduf> End of statement is implicitly inserted at end of line
except where something else is required on it (like a +), and adding semicolons
between statements on the same line gives them end of statement marks and
separates them.
13:17 < Namegduf> By on large, you just don't use them.
13:18 < Namegduf> Unless separating statements on the same line.
13:18 < Namegduf> Anyways, must go, stuff to get done.  Thanks for the chat.
13:18 < fumblebee> yeah, thank you for the info
13:23 -!- ExtraSpice [~XtraSpice@88.118.33.48] has joined #go-nuts
13:27 -!- savechina [~savechina@221.216.242.76] has joined #go-nuts
13:29 -!- virtualsue [~chatzilla@nat/cisco/x-xmbbvppfdcnwduks] has joined #go-nuts
13:36 -!- DerHorst [~Horst@e176103213.adsl.alicedsl.de] has joined #go-nuts
13:43 -!- liron [~liron@guest-fw.dc4.itasoftware.com] has joined #go-nuts
13:43 -!- liron [~liron@guest-fw.dc4.itasoftware.com] has quit [Remote host closed
the connection]
13:43 -!- liron [~liron@ita4fw1.itasoftware.com] has joined #go-nuts
13:50 -!- zozoR [~zozoR@5634798d.rev.stofanet.dk] has joined #go-nuts
13:56 -!- dj2 [~dj2@216.16.242.254] has joined #go-nuts
13:59 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
13:59 < MashPotato> hi
13:59 < MashPotato> is "byte" go's equivalent to char?
14:00 < MashPotato> or are there any specific differences between the 'char'
type (in C or C++) and 'byte' in go?
14:01 < nsf> MashPotato: byte is an alias for uint8 in Go
14:01 < MashPotato> oh
14:01 < MashPotato> okay, thank you
14:01 < nsf> "byte familiar alias for uint8"
14:01 -!- artefon [~thiago@189.59.165.176] has quit [Quit: bye]
14:01 < nsf> and that's actually in the spec
14:02 < MashPotato> yeah, I had the spec open for days, just to learn Go a
tiny wee bit better ;-)
14:03 -!- fumblebee [~kgay@137.149.217.198] has quit [Ping timeout: 272 seconds]
14:03 < MashPotato> I'd still have kinda alot of questions, but I'm afraid
all of those would be way too basic for this channel, but hopefully someone starts
a "##go-basic" channel soon :D
14:03 < MashPotato> I'm sure it would one or another fella
14:03 < MashPotato> +help
14:05 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-152-44.clienti.tiscali.it] has
joined #go-nuts
14:09 < MashPotato> mhm, I guess it doesn't make much sense at this point,
no?
14:09 < nsf> just ask your questions here, and if they aren't stupid they
will be answered :)
14:10 < MashPotato> :D
14:11 < MashPotato> well, there is this particular feature that got me a
little puzzled, especially because I haven't seen anywhere else: interface{}, as
in func Foo(args...  interface{}), which would naturally allow all types, but why
'inteface' here?  why not 'mixed' or 'object' (as in c#)?
14:13 < nsf> I'm not sure about C#, but C# as far as I know has interfaces
as well
14:13 < nsf> just imagine empty interface
14:13 < nsf> everything satisfies it and in Go you're free from specifing
that fact
14:13 < nsf> basically interface{} is a value + type information
14:14 < nsf> if you have just int or just float..  it's just a value
14:14 < nsf> and I mean it's just a value in the memory, of course compiler
knows the type, but it's not written in real memory at runtime
14:14 < ptrb> is that append(a, b...); ...  syntax totally new for append()?
14:15 < nsf> ptrb: it has nothing to do with append, "b..." is a new syntax
for ...  args
14:15 < nsf> it was added some time ago
14:15 < nsf> for example you can do this with printf as well:
14:15 < nsf> fmt.Printf("%s %s %s", a...)
14:15 < nsf> where 'a' is:
14:16 < nsf> var a []interface{}
14:16 < ptrb> okay....
14:17 -!- mattn_jp [~mattn_jp@112-68-93-213f1.hyg1.eonet.ne.jp] has joined
#go-nuts
14:17 < ptrb> but what does that do?
14:18 < nsf> MashPotato: I'm not the best person when it comes to describing
something well, english isn't my first language, so..  I hope at least some of my
words about interface{} make sense
14:18 < ptrb> duplicate 'a' as many times as is necessary?  extract the
first 3 elements from the array and plop them into the %s's?
14:18 < nsf> ptrb: it's like * in python
14:18 < MashPotato> nsf: it's alright, english isn't my first language
either
14:18 < nsf> as far as I remember
14:18 < nsf> ptrb: these two are the same:
14:19 < nsf> 1.  fmt.Printf("%s %s %s", a[0], a[1], a[2])
14:19 < MashPotato> nsf: but thank you, I understand now
14:19 < nsf> 2.  fmt.Printf("%s %s %s", a...)
14:19 < nsf> len(a) == 3 of course
14:19 < ptrb> nsf: uh...  weird, okay.
14:21 < ptrb> I see, it only works on []type
14:21 < ptrb> and just expands it as necessary.  OK.
14:21 < nsf> yes
14:23 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has joined
#go-nuts
14:31 -!- lmoura [~lauromour@187.78.4.87] has quit [Quit: Leaving]
14:32 -!- virtualsue [~chatzilla@nat/cisco/x-xmbbvppfdcnwduks] has quit [Ping
timeout: 272 seconds]
14:32 -!- kanru [~kanru@218-161-123-221.dynamic.hinet.net] has quit [Ping timeout:
250 seconds]
14:32 -!- mattn_jp [~mattn_jp@112-68-93-213f1.hyg1.eonet.ne.jp] has quit [Quit:
mattn_jp]
14:32 -!- mattn_jp [~mattn_jp@112-68-93-213f1.hyg1.eonet.ne.jp] has joined
#go-nuts
14:33 < plexdev> http://is.gd/gIh2w by [Russ Cox] in go/ -- A+C: add Chris
Jones (individual CLA)
14:33 < plexdev> http://is.gd/gIh2K by [Chris Jones] in go/src/pkg/net/ --
net: fix LookupSRV
14:35 -!- prip [~foo@host243-124-dynamic.35-79-r.retail.telecomitalia.it] has quit
[Quit: Leaving]
14:35 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has quit [Quit:
This computer has gone to sleep]
14:41 -!- prip [~foo@host243-124-dynamic.35-79-r.retail.telecomitalia.it] has
joined #go-nuts
14:43 -!- skelterjohn [~jasmuth@c-76-124-135-199.hsd1.nj.comcast.net] has quit
[Quit: skelterjohn]
14:53 -!- virtualsue [~chatzilla@nat/cisco/x-cxdqafacwbvtufob] has joined #go-nuts
14:54 -!- Venom_X [~pjacobs@74.61.90.217] has joined #go-nuts
14:55 -!- savechina [~savechina@221.216.242.76] has quit [Quit: Leaving]
14:55 -!- artefon [~thiagon@150.164.2.20] has joined #go-nuts
14:56 -!- liron_ [~liron@guest-fw.dc4.itasoftware.com] has joined #go-nuts
14:58 -!- MizardX [b21e3f3c@gateway/web/freenode/ip.178.30.63.60] has joined
#go-nuts
14:58 -!- skelterjohn [~jasmuth@c-76-124-135-199.hsd1.nj.comcast.net] has joined
#go-nuts
14:58 -!- liron [~liron@ita4fw1.itasoftware.com] has quit [Ping timeout: 252
seconds]
15:00 -!- skelterjohn [~jasmuth@c-76-124-135-199.hsd1.nj.comcast.net] has quit
[Client Quit]
15:02 -!- liron [~liron@guest-fw.dc4.itasoftware.com] has quit [Quit: liron]
15:03 -!- liron [~liron@guest-fw.dc4.itasoftware.com] has joined #go-nuts
15:03 -!- liron [~liron@guest-fw.dc4.itasoftware.com] has quit [Remote host closed
the connection]
15:04 -!- liron [~liron@ita4fw1.itasoftware.com] has joined #go-nuts
15:05 -!- rbraley [~rbraley@ip72-222-128-78.ph.ph.cox.net] has joined #go-nuts
15:13 -!- virtualsue [~chatzilla@nat/cisco/x-cxdqafacwbvtufob] has quit [Ping
timeout: 265 seconds]
15:16 -!- tensorpudding [~user@99.148.202.191] has joined #go-nuts
15:17 -!- bjarneh [~bjarneh@1x-193-157-204-227.uio.no] has quit [Quit: adois]
15:28 -!- tgall_foo [~tgall@gentoo/developer/dr-who] has quit [Ping timeout: 250
seconds]
15:31 -!- rbraley [~rbraley@ip72-222-128-78.ph.ph.cox.net] has quit [Ping timeout:
276 seconds]
15:38 -!- tgall_foo [~tgall@gentoo/developer/dr-who] has joined #go-nuts
15:51 < plexdev> http://is.gd/gIqrd by [Ian Lance Taylor] in go/src/cmd/ld/
-- Use future official DWARF language code for Go.
15:51 -!- TheMue [~TheMue@p5DDF7D3B.dip.t-dialin.net] has joined #go-nuts
15:54 -!- rbraley [~rbraley@ip72-222-128-78.ph.ph.cox.net] has joined #go-nuts
15:55 -!- kanru [~kanru@118-168-239-241.dynamic.hinet.net] has joined #go-nuts
16:01 -!- Fish [~Fish@86.65.182.207] has quit [Remote host closed the connection]
16:03 -!- MashPotato [~ed@unaffiliated/mashpotato] has quit [Quit: Leaving]
16:04 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has joined #go-nuts
16:06 -!- virtualsue [~chatzilla@nat/cisco/x-nfnfnibjffpphflx] has joined #go-nuts
16:07 -!- plainhao [~plainhao@mail.xbiotica.com] has joined #go-nuts
16:11 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts
16:15 -!- DrHennessy [~alex@eng-5-80.hotspot.utah.edu] has joined #go-nuts
16:16 -!- DrHennessy [~alex@eng-5-80.hotspot.utah.edu] has quit [Client Quit]
16:16 -!- tvw [~tv@e176006024.adsl.alicedsl.de] has quit [Remote host closed the
connection]
16:18 -!- fumblebee [~kgay@137.149.217.156] has joined #go-nuts
16:24 -!- skejoe [~skejoe@188.114.142.231] has quit [Quit: Lost terminal]
16:25 -!- Tv [~tv@cpe-76-168-227-45.socal.res.rr.com] has joined #go-nuts
16:25 -!- lmoura [~lauromour@187.112.11.189] has joined #go-nuts
16:31 -!- binarypie [~binarypie@adsl-99-33-26-93.dsl.pltn13.sbcglobal.net] has
joined #go-nuts
16:35 -!- lmoura [~lauromour@187.112.11.189] has quit [Ping timeout: 245 seconds]
16:36 -!- raylu [raylu@c-24-131-193-106.hsd1.pa.comcast.net] has joined #go-nuts
16:36 < raylu> is len(string) stored in the string itself?
16:36 < cbeck> yes
16:38 < raylu> cbeck: yay.  thanks
16:39 -!- lmoura [~lauromour@187.112.11.189] has joined #go-nuts
16:45 -!- sauerbraten [~sauerbrat@p508CAE5D.dip.t-dialin.net] has joined #go-nuts
16:45 -!- MizardX [b21e3f3c@gateway/web/freenode/ip.178.30.63.60] has quit [Quit:
off]
16:46 -!- saschpe [~quassel@77-23-177-40-dynip.superkabel.de] has joined #go-nuts
16:47 -!- niemeyer_ [~niemeyer@189-72-21-191.pltce701.dsl.brasiltelecom.net.br]
has joined #go-nuts
16:48 -!- kanru [~kanru@118-168-239-241.dynamic.hinet.net] has quit [Ping timeout:
252 seconds]
16:49 -!- niemeyer [~niemeyer@187.53.254.172] has quit [Ping timeout: 245 seconds]
16:51 -!- Venom_X [~pjacobs@74.61.90.217] has quit [Quit: Venom_X]
16:56 -!- TheMue [~TheMue@p5DDF7D3B.dip.t-dialin.net] has quit [Quit: TheMue]
16:57 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has quit [Quit:
Leaving]
17:02 -!- artefon [~thiagon@150.164.2.20] has quit [Quit: Leaving]
17:03 -!- Fish [~Fish@9fans.fr] has joined #go-nuts
17:03 -!- mattn_jp [~mattn_jp@112-68-93-213f1.hyg1.eonet.ne.jp] has quit [Remote
host closed the connection]
17:08 -!- rbraley [~rbraley@ip72-222-128-78.ph.ph.cox.net] has quit [Ping timeout:
255 seconds]
17:16 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has joined #go-nuts
17:16 -!- philllip [~philllip@amigos02.distlab.diku.dk] has quit [Quit: Leaving]
17:16 -!- rbraley [~rbraley@ip72-222-128-78.ph.ph.cox.net] has joined #go-nuts
17:23 -!- zozoR [~zozoR@5634798d.rev.stofanet.dk] has quit [Quit: Morten.  Desu~]
17:24 -!- Fish [~Fish@9fans.fr] has quit [Remote host closed the connection]
17:26 -!- rbraley [~rbraley@ip72-222-128-78.ph.ph.cox.net] has quit [Ping timeout:
255 seconds]
17:26 < gmilleramilar> anyone up for porting joda-time to go?  :)
17:28 < wrtp> which bit of it?
17:29 < gmilleramilar> currently partial dates and datemath
17:29 < gmilleramilar> almost assuredly more in the future.
17:29 -!- Fish [~Fish@9fans.fr] has joined #go-nuts
17:30 -!- DerHorst [~Horst@e176103213.adsl.alicedsl.de] has quit [Remote host
closed the connection]
17:32 -!- rbraley [~rbraley@ip72-222-128-78.ph.ph.cox.net] has joined #go-nuts
17:32 -!- Boney_ [~paul@124-168-111-1.dyn.iinet.net.au] has joined #go-nuts
17:33 -!- Boney [~paul@203-217-71-205.dyn.iinet.net.au] has quit [Ping timeout:
272 seconds]
17:33 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has joined #go-nuts
17:34 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has quit [Read
error: Connection reset by peer]
17:36 -!- Fish [~Fish@9fans.fr] has quit [Remote host closed the connection]
17:36 -!- Fish [~Fish@9fans.fr] has joined #go-nuts
17:37 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has joined #go-nuts
17:37 -!- Fish [~Fish@9fans.fr] has quit [Remote host closed the connection]
17:38 -!- sahid [~sahid@LNeuilly-152-21-22-10.w193-253.abo.wanadoo.fr] has quit
[Quit: Ex-Chat]
17:43 -!- deso [~deso@x0561a.wh30.tu-dresden.de] has joined #go-nuts
17:51 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts
17:54 -!- creack [~charme_g@163.5.84.215] has quit [Ping timeout: 276 seconds]
17:58 -!- nigelkerr [~nigelkerr@jstormichfw.jstor.org] has quit [Quit: nigelkerr]
18:00 -!- femtooo [~femto@95-89-197-196-dynip.superkabel.de] has joined #go-nuts
18:01 -!- Fish [~Fish@9fans.fr] has joined #go-nuts
18:02 < wrtp> gmilleramilar: go for it - it might easily be useful.
18:02 < wrtp> but make sure it is inter-operable with the go time package
when at all possible...
18:03 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has quit [Ping
timeout: 245 seconds]
18:03 < wrtp> (i.e.  layer on it rather than try to replace it completely)
18:05 < gmilleramilar> (yeah, I was hoping someone else might say "I am", as
I don't really have time)
18:05 < wrtp> think of it as porting the ideas and the usefulness and some
names from the joda date libraries (i.e.  arithmetic on dates and times) rather
than the code itself.
18:05 < wrtp> ok
18:06 -!- lmoura [~lauromour@187.112.11.189] has quit [Ping timeout: 245 seconds]
18:06 < wrtp> it doesn't look too big (he says from having looke my look at
18:06 < wrtp> oops, was trying to delete that
18:06 -!- creack [~charme_g@163.5.84.215] has joined #go-nuts
18:07 -!- dj2 [~dj2@216.16.242.254] has quit [Remote host closed the connection]
18:07 < wrtp> i wonder if something with 95% of the functionality wouldn't
be pretty quick to code up
18:08 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has joined #go-nuts
18:08 < wrtp> you'd want to do it in nanoseconds not milliseconds
18:09 -!- lmoura [~lauromour@187.112.11.189] has joined #go-nuts
18:09 < wrtp> type instant int64
18:09 < plexdev> http://is.gd/gIFx3 by [Russ Cox] in go/lib/codereview/ --
codereview: more utf-8 nonsense
18:09 < plexdev> http://is.gd/gIFx7 by [Russ Cox] in 24 subdirs of go/src/
-- runtime: ,s/[a-zA-Z0-9_]+/runtimeĀ·&/g, almost
18:10 < gmilleramilar> yeah, unfortunately I think all the fiddly details of
the perpetual calendar itself would be a royal pain.
18:10 < gmilleramilar> not to mention time zones.
18:11 < wrtp> type Period struct { unit Unit; amount int64 }
18:11 < wrtp> gmilleramilar: if joda is open source, just borrow the fiddly
bits of the code.
18:12 < wrtp> just so long as they don't get too tricky
18:13 < gmilleramilar> I actually looked at it a while back, the code has
been pretty agressively abstracted to support different calendars (julian, etc.),
after spelunking for a couple hours I didn't understand it very well.
18:14 < wrtp> that probably means it's not easily ported directly to go
18:14 < gmilleramilar> agreed
18:14 < wrtp> go favours a more direct style
18:15 < wrtp> it makes me like source code is transparent once again.  :-)
18:16 < wrtp> does anyone know of a more reader-friendly language than go?
18:19 -!- htoothrot [~mux@66-169-185-121.dhcp.ftwo.tx.charter.com] has quit [Ping
timeout: 240 seconds]
18:21 -!- deso [~deso@x0561a.wh30.tu-dresden.de] has quit [Remote host closed the
connection]
18:23 -!- artefon [~thiagon@150.164.2.20] has joined #go-nuts
18:28 -!- ucasano [~ucasano@host153-182-static.227-95-b.business.telecomitalia.it]
has quit [Quit: ucasano]
18:28 < Tv> wrtp: you could argue python for that -- a higher-level language
makes that easier
18:29 < wrtp> but with python you don't know anything of what's actually
happening underneath just by looking at the code
18:29 < Tv> oh static typing FUD won't convince me a bit ;)
18:29 < wrtp> it's all just convention and conventions are not universal
18:29 < wrtp> static typing gives you some concrete guarantees that are
preserved by every running program
18:30 < Tv> on one extremely narrow field
18:30 < Tv> e.g.  channel behavior can be completely wild, and that's not
exposed in types
18:30 < wrtp> which makes it easier to read a program, because you have more
info available to you
18:30 < Tv> i'm saying types are not the most critical aspect of that
18:30 < wrtp> yeah, of course there are always runtime behaviours not
covered by the type system
18:30 < wrtp> types are really useful for that
18:31 < wrtp> what is most critical aspect of that?
18:31 -!- tumdum [~tumdum@unaffiliated/tumdum] has joined #go-nuts
18:31 < wrtp> s/is/is the/
18:32 < wrtp> i really like the fact that (*almost* universally) if you see
an identifier in a go program, you know where it comes from.
18:34 < wrtp> it's a really beautiful type system.  python's is also
beautiful, but marred by inheritance and some bad choices of module organisation.
18:35 -!- d_m [d6@SDF.ORG] has quit [Quit: Lost terminal]
18:40 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has quit [Quit:
Leaving.]
18:40 < uriel> wrtp: worse, python has not only *multiple* inheritance, but
also metaclasses, the python 'type' system is beyond insane
18:41 < uriel> just to explain how the method resolution order is calculated
takes three pages of dense explanations
18:42 < Namegduf> "Everything's a reference but some things are immutable
and magically replaced by a new reference" results in some odd behaviour, too.
18:43 -!- fumblebee [~kgay@137.149.217.156] has quit [Ping timeout: 252 seconds]
18:43 < Namegduf> Stuff that doesn't do what it looks like it does.
18:43 < Namegduf> Admittably, reference types that aren't obviously
distinguished from normal types is a problem in Go, too; defined structs can be
either and channels and maps are reference types.
18:44 < Namegduf> For much the same reason it is in C.
18:45 < Tv> go is surprisingly close to C in many things
18:45 < Tv> like, nil is only valid for pointer-like things
18:45 < wrtp> Namegduf: part of the reason why that's not such a problem in
Go is that programs can so easily be refactored automatically
18:46 < Namegduf> That's because numeric types already have 0
18:46 < Tv> the whole NULL == 0 is one of trippier parts of C
18:46 < Namegduf> Also because that's the way memory actually works, and
making numeric types nullable requires extra overhead.
18:46 < wrtp> yup
18:46 < Tv> frankly, Haskell got this one right, purely from a high-level
language perspective; Maybe is awesome
18:47 < wrtp> Tv: yeah it took me a while to get my head around that
18:47 < Tv> Namegduf: yup, i understand the reasoning
18:47 -!- yebyen [~yebyen@irie-arch.rit.edu] has quit [Remote host closed the
connection]
18:47 < Tv> just..  i don't always want to program that close to the metal
18:47 < Namegduf> I like things not being nullable, anyway.
18:47 < Namegduf> Fewer special cases.
18:47 < wrtp> Tv: Haskell makes it too easy to try to program the type
system
18:47 < Tv> it'd be nice to have Maybe-style guarantees of "this is never
null"
18:47 < Tv> wrtp: oh i avoid the language as a whole, but i like individual
ideas in it
18:48 < Tv> much like erlang ;)
18:48 < wrtp> Tv: you end up using Just anyway :-)
18:48 < Namegduf> Yeah, there wasn't a way figured to make non-nil pointers
without massive changes impacting everything.
18:48 < Namegduf> In Go.
18:48 < Tv> Namegduf: that's the whole point of Maybe; everything is not
nullable, you need to explicitly say when they can be null
18:48 < wrtp> i like the way that the semantics of go are a two way
conversation with the semantics of the underlying machine
18:48 < Namegduf> Yeah, I think you'd need to make "the whole point" of the
language be that to support it.
18:49 < Namegduf> Or at least take it as a major design goal early on.
18:49 < wrtp> yup
18:49 < Tv> wrtp: i just wish this awesome systems programming language
covered more of my needs ;)
18:49 < wrtp> what are your needs?
18:49 < Tv> right now, i'm writing python because it's just more productive
for this task
18:49 < Namegduf> People did try to come up with ways to do it in Go, but it
wasn't simple.
18:49 < Tv> wrtp: i am often very happy sacrificing 4-5x performance for
being able to write what i want in less lines & time
18:49 < wrtp> sure
18:50 < Namegduf> I always kinda grumble at that.
18:50 < wrtp> but it's nice if you can get the former without sacrificing
the latter
18:50 * Namegduf kinda feels that if a programmer wants to sacrifice 4-5x
performance he should only be expecting to be paid 1/4th or 1/5th the amount
18:50 < wrtp> i think go's pretty good for writing works-first-time programs
18:51 < Tv> Namegduf: think the entrepreneurial way: is it worth your time,
or should you just pay for an extra server in the cloud instead
18:51 < Tv> Namegduf: i don't need to burn many billable hours to justify an
extra server..
18:51 < wrtp> yeah, person time is often the most critical factor
18:51 < Namegduf> That's fine from an internal perspective
18:52 < Namegduf> My issue is with the idea that you can save person hours,
then sell it for the same amount.
18:52 < wrtp> but having something that works reliably and is easily
changeable is a big bonus too
18:52 < Namegduf> i.e.  Android
18:52 < Tv> wrtp: that's more about having good tests, in my mind
18:52 < Tv> wrtp: and few lines of code
18:53 < wrtp> i think that static guarantees are more useful the older a
program is.
18:53 < Namegduf> Strong typing helps reliability because it's much easier
to get it right the first time when you're reasoning with "I have been given a
number between 0 and 4 billion" than "I have been given a pointer to an object
which may be of any type"
18:53 < Tv> wrtp: i think tests >> static typing
18:53 < Namegduf> Strong typing also makes it *run faster*.
18:54 < Tv> wrtp: and frankly, python is so much easier to test than C
18:54 < Namegduf> It isn't just free, it's easier to implement quickly.
18:54 < Tv> wrtp: i'm still waiting to see where Go settles on that axis
18:54 < wrtp> smallish code and good tests help initially, but don't help
too much when refactoring.
18:54 < Tv> wrtp: i completely disagree with that...  :-/
18:54 -!- Wiz126 [Wiz@h62.126.232.68.ip.windstream.net] has joined #go-nuts
18:54 < wrtp> ok, the tests do
18:54 < Namegduf> I care far less about small code than I do about clear
code.
18:54 -!- pgas [pgas@pdpc/supporter/active/pgas] has quit [Quit: /quit]
18:55 < Namegduf> Python is fairly good at both, though.
18:55 < wrtp> i care about code that doesn't break when i try to make it do
something different
18:55 < Tv> Namegduf: yet, at the same time, languages in the C family
encourage stupidity like int overflows, which doesn't happen in higher-level
languages where a number will just grow happily
18:55 -!- virtualsue [~chatzilla@nat/cisco/x-nfnfnibjffpphflx] has quit [Ping
timeout: 245 seconds]
18:55 < wrtp> Tv: that's a performance tradeoff
18:55 < Tv> i know
18:55 < Tv> i understand
18:55 < Tv> i sometimes want it, but not always
18:55 -!- femtooo [~femto@95-89-197-196-dynip.superkabel.de] has quit [Quit:
Leaving]
18:56 < Tv> i wish the transition between those domains was less jarring
18:56 < wrtp> you might call it stupidity; another might say it's pragmatism
18:56 < Namegduf> Also code in the higher level language, not having a
defined range for input to accept, will often get bugs at extreme values.
18:56 < Tv> i will still claim C int overflows have caused way way more
damage
18:57 * Namegduf thinks in sets of values that could possibly be in an argument,
and sets that are accepted, and adds checks to make them match.  When functions
expecting numbers can be passed "orange", that's much harder.
18:57 < Tv> which makes me thing..  i wonder what it would take to have an
"infinite number" type in Go
18:57 < Namegduf> There's a package for it.
18:57 < Tv> big?
18:57 < Namegduf> Sounds right.
18:58 < Namegduf> You could also just use a float if you don't care about
losing precision.
18:58 < Tv> yeah..  c := a.Add(b)
18:58 < Tv> i hate floats..
18:58 < wrtp> Tv: it's not what's accepted as an argument, it's what we know
about it structurally...
18:59 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has joined #go-nuts
18:59 < wrtp> Tv: actually, in go it's.  c := big.NewInt().Add(a, b) :-)
19:00 < Tv> it a and b are ints when you start
19:00 < Tv> if they's big.Ints, then it should be my version
19:00 < Tv> no wait, you're right
19:01 < Tv> what an odd api
19:01 < Tv> i guess it's to minimize allocations
19:01 <+iant> exactly
19:01 < wrtp> it lets you control allocation
19:01 < Tv> the fact that it also returns z is funky
19:01 -!- lmoura [~lauromour@187.112.11.189] has quit [Ping timeout: 245 seconds]
19:02 < wrtp> it means that the result does not have to be allocated each
time, which can give you great speed ups in tight loops, and much less load on the
GC.
19:03 -!- Venom_X [~pjacobs@adsl-99-20-147-171.dsl.aus2tx.sbcglobal.net] has
joined #go-nuts
19:03 < wrtp> i'm not too keen on how it reads, but i think the design is
quite elegant.
19:03 < wrtp> i wouldn't mind some syntactic sugar around this area.
19:03 < Tv> yeah the whole C-like language with GC keeps confusing me ;)
19:03 < Tv> <3 go though
19:06 -!- lmoura [~lauromour@187.112.11.189] has joined #go-nuts
19:09 -!- wrtp [~rog@92.17.68.10] has quit [Read error: Connection reset by peer]
19:10 -!- wrtp [~rog@92.17.68.10] has joined #go-nuts
19:14 -!- Fish- [~Fish@9fans.fr] has joined #go-nuts
19:15 -!- artefon [~thiagon@150.164.2.20] has quit [Quit: Leaving]
19:20 -!- Venom_X [~pjacobs@adsl-99-20-147-171.dsl.aus2tx.sbcglobal.net] has quit
[Quit: Venom_X]
19:20 -!- tvw [~tv@e176006024.adsl.alicedsl.de] has joined #go-nuts
19:22 -!- ronnyy [~quassel@2001:6f8:12c6:1c86:224:1dff:fed7:9541] has quit [Read
error: Operation timed out]
19:23 -!- gr0gmint [~quassel@87.60.23.38] has joined #go-nuts
19:33 -!- SirPsychoS [~sp@c-24-13-132-255.hsd1.il.comcast.net] has joined #go-nuts
19:33 -!- Venom_X [~pjacobs@74.61.90.217] has joined #go-nuts
19:33 -!- res99 [~anonymous@201.237.130.70] has joined #go-nuts
19:48 -!- enherit [~enherit@cpe-98-149-170-48.socal.res.rr.com] has joined
#go-nuts
19:49 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
19:58 -!- Thomas3467 [~kvirc@188-23-102-20.adsl.highway.telekom.at] has joined
#go-nuts
20:00 < Thomas3467> hello guys, question: has golang a unpack() function
like php has (the network one, not for unpacking archives)?
20:04 -!- dju [dju@fsf/member/dju] has joined #go-nuts
20:05 < skelterjohn> Thomas3467: as a non php coder, i'm not sure what you
mean.  could you explain a little more?
20:07 < Thomas3467> need it to pack network streams, unpack("C*",
<networkstream>), pack("ccc", ...)
20:07 -!- skejoe [~skejoe@188.114.142.231] has joined #go-nuts
20:07 < skelterjohn> do you mean, for instance, easily convert some data
structure to and from a byte array?
20:07 < Thomas3467> http://www.php.net/manual/en/function.pack.php
20:08 < Thomas3467> yes
20:08 < skelterjohn> there are a few approaches to this
20:08 < skelterjohn> one second
20:09 -!- dju [dju@fsf/member/dju] has quit [Max SendQ exceeded]
20:09 < skelterjohn> one is you can use the unsafe package to get directly
at the bytes of some struct, but you should avoid this if you can
20:09 -!- dju [dju@fsf/member/dju] has joined #go-nuts
20:10 < skelterjohn> i think you can also use json to pack data
20:10 < skelterjohn> though i haven't used it personall
20:10 < skelterjohn> y
20:10 < skelterjohn> the gob package has some relevant looking stuff
20:12 -!- zozoR [~zozoR@5634798d.rev.stofanet.dk] has joined #go-nuts
20:12 < Thomas3467> ok thx
20:13 < plexdev> http://is.gd/gIS7L by [Russ Cox] in 2 subdirs of go/ -- gc:
line comments may end in EOF
20:14 < MaybeSo> Folks, do any of you write go programs using an idiom where
you have a function that takes an error channel and returns a channel of data,
leaving you to then select {} between the two, looking for either an error or the
data?
20:15 < MaybeSo> that's something I see discussed a bit on golang-nuts, but
I'm confused about whether or not the construction of the error channel would tend
to be buffered on unbuffered
20:16 < exch> MaybeSo: Only once so far
20:16 < skelterjohn> depends on whether or not the error is fatal
20:16 < skelterjohn> if you only report a fatal error, no point in buffering
the error channel
20:17 < exch> On my case the error channel was unbuffered.  An error would
mean critical failure, so no need to store more of them
20:17 < skelterjohn> if you can have non-fatal errors, then you'd be
treating it as a logger, and it would make sense to buffer it
20:17 < MaybeSo> skelterjohn: in this situation I'm sort of treating the
error channel like I'd treat exceptions in Java -- I don't ever expect an error to
actually be thrown unless something is really wrong
20:17 < skelterjohn> then like exch and I suggest, it should be unbuffered
20:19 < skelterjohn> btw that's not the only way to treat exceptions in java
:)
20:19 < MaybeSo> skelterjohn: sure, but that's how *I* tended to treat the
majority of exceptions.  :)
20:20 < skelterjohn> fair enough
20:23 -!- GoBIR [~gobir@res-128-61-89-71.res.gatech.edu] has quit [Ping timeout:
240 seconds]
20:23 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has quit [Ping
timeout: 276 seconds]
20:23 < MaybeSo> so if I use an unbuffered error channel, that would
indicate the function being called would need to write to errors from within a
goroutine?, e.g.  Eval(data Foo, errors chan os.Error) chan Stuff { c := make(chan
Stuff) go func() { ...  real work ...  }() return c} ?
20:23 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has joined
#go-nuts
20:24 < MaybeSo> sorry, I guess I should use pasteit or something
20:24 -!- tumdum [~tumdum@unaffiliated/tumdum] has quit [Quit: tumdum]
20:24 -!- gr0gmint [~quassel@87.60.23.38] has quit [Remote host closed the
connection]
20:25 < skelterjohn> yeah, well i guess in that case you might as well use a
buffered channel
20:25 < skelterjohn> for some reason i assumed this whole function would be
in its own goroutine
20:25 < skelterjohn> my fault
20:25 < MaybeSo> http://paste.pocoo.org/show/286197/
20:25 < MaybeSo> hopefully that's a more readable version of my question...
20:25 < skelterjohn> rule of thumb: code that fits on one line doesn't need
a pastebin :)
20:27 < skelterjohn> i was thinking more along, "if thereIsAProblem { go
func() { errors <- theProblem }() return }" for an unbuffered error channel
20:27 < MaybeSo> ah
20:27 < wrtp> MaybeSo: if you've only got one possible error, then it makes
sense to make the chan have a buf size of 1, so the goroutine can put its error
into the channel and go away.  the caller doesn't even need to wait on the error
channel if it doesn't want to.
20:27 < skelterjohn> if the thing that is reading the errors is in the same
chan as the thing that is writing them
20:27 < MaybeSo> ok, thanks guys
20:28 < skelterjohn> in the same chan -> in the same goroutine
20:31 < wrtp> MaybeSo: there's always a bit of a tension between passing a
channel in to be used and using a channel that's been returned.  the problem with
sharing error channels is that you lose information about the message's
provenance.  so it's probably worth returning a channel.  it's easy to interpose
another goroutine to write the error into a shared channel if desired.
20:31 < plexdev> http://is.gd/gITX5 by [Robert Griesemer] in
go/src/pkg/go/scanner/ -- go/scanner: line comments may end in EOF
20:32 < MaybeSo> wrtp: so you're saying return 2 channels?  one for data,
one for errors?
20:32 < MaybeSo> oh, a shared channell.  hrm.
20:32 < MaybeSo> so construct my own struct that can carry either payload,
data or error ?
20:32 < wrtp> MaybeSo: it depends on the situation.
20:32 < wrtp> that's an option too.
20:32 < MaybeSo> so may choices!  :D
20:32 < MaybeSo> s/may/many/
20:33 < wrtp> another, if you've got a shared data structure, is to close
the channel and make the error available from the data structure.
20:34 < wrtp> e.g.  for x := range foo.dataChan { ....  }; if foo.error !=
nil { log.Exitf("error found: %v", foo.error) }
20:34 < wrtp> the goroutine can set the error before calling close, so
there's no race.
20:36 < wrtp> another is to have a method on the data structure, conforming
to interface{Wait() os.Error}
20:36 -!- Eridius [~kevin@unaffiliated/eridius] has joined #go-nuts
20:36 < wrtp> which waits until the goroutine has terminated and returns the
error status when it has.
20:38 -!- dacc [~Adium@c-67-171-32-251.hsd1.wa.comcast.net] has joined #go-nuts
20:38 -!- tumdum [~tumdum@auk219.neoplus.adsl.tpnet.pl] has joined #go-nuts
20:38 < skelterjohn> fwiw, it's common to have multiple-value return, the
last of which is of type os.Error
20:38 -!- tumdum [~tumdum@auk219.neoplus.adsl.tpnet.pl] has quit [Changing host]
20:38 -!- tumdum [~tumdum@unaffiliated/tumdum] has joined #go-nuts
20:39 < skelterjohn> and if that error is not nil, the function didn't work
20:39 < skelterjohn> (keep it simple)
20:39 < exch> MaybeSo: You can also use defer/recover and panic() to
simulate exception handling if you don't want to pass channels for errors
everywhere
20:40 -!- Fish [~Fish@9fans.fr] has quit [Remote host closed the connection]
20:43 < wrtp> skelterjohn: that doesn't work so well if the "function" is
actually a collection of goroutines.
20:44 -!- skejoe [~skejoe@188.114.142.231] has quit [Quit: Lost terminal]
20:44 < wrtp> then you've got to "return" twice - once when the channel is
returned, and again if an error is encountered.
20:44 -!- rlab [~Miranda@91.200.158.34] has quit [Read error: Connection reset by
peer]
20:45 < MaybeSo> skelterjohn: re a return of a channel and a potential
error, that works up to a point.  I was trying to deal with two possible sources
of errors.  The first is before I start processing the response from a downstream
server, e.g., I can error out easily enough (return nil, err) up to the point that
I start reading the response.  But when I'm processing the response I wanted to be
able to return the data using a channel,so that I didn't have to buffer the
20:45 < MaybeSo> so I'm using the mime/multipart.Reader
20:45 < skelterjohn> my point is, it's too tempting to come up with a very
general, yet very complicated framework for doing these things, and depending on
the problem that might be over-doing it
20:46 < MaybeSo> I like the idea of using the defer/panic to potentially set
the error
20:46 < wrtp> there's no need to use any particular framework at all.  most
approaches are inter-operable.
20:46 < MaybeSo> that might make a lot of this simpler to read
20:46 < wrtp> defer/panic won't work if the code is another goroutine.
20:47 -!- tumdum [~tumdum@unaffiliated/tumdum] has quit [Quit: tumdum]
20:47 -!- GoBIR [~gobir@res-128-61-89-71.res.gatech.edu] has joined #go-nuts
20:47 < wrtp> MaybeSo: a previous message of yours got truncated after "so
that I didn't have to buffer the"...
20:47 < MaybeSo> sorry.
20:47 < MaybeSo> o that I didn't have to buffer the entire (potentially very
large) response set while still also being able to indicate an error occured in
the middle of reading the set.  What I'm doing is making an HTTP call that ends up
needing to process a multipart/mime response
20:48 < MaybeSo> s/^/s/
20:49 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has quit [Quit: skelterjohn]
20:49 < wrtp> would you want to be able to continue reading after the error?
20:49 < MaybeSo> nope
20:49 < plexdev> http://is.gd/gIVQI by [Graham Miller] in
go/src/pkg/runtime/ -- Small addition to previous optimization of memequal as
discussed here:
http://groups.google.com/group/golang-nuts/browse_thread/thread/f591ba36d83723c0/9aba02d344045f38
20:49 < MaybeSo> one error is all it takes to indicate the entire
transaction is a loss
20:49 < plexdev> http://is.gd/gIVQV by [Robert Griesemer] in go/doc/ -- go
spec: line comments may end in EOF
20:50 < wrtp> i don't see how using a channel removes any need for buffering
20:52 < MaybeSo> I mean I don't want to have to loop through the entire
response inside Eval(), building up a copy of everything the downstream server is
sending, before returning control to the part of the program that's reading the
individual parts
20:52 < MaybeSo> I obviously *could* construct it that way, I just thought
it'd be nicer to not have to
20:56 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
20:58 -!- rlab [~Miranda@91.200.158.34] has quit [Read error: Connection reset by
peer]
21:01 -!- MashPotato [~ed@unaffiliated/mashpotato] has joined #go-nuts
21:04 -!- dacc [~Adium@c-67-171-32-251.hsd1.wa.comcast.net] has quit [Quit:
Leaving.]
21:05 < wrtp> MaybeSo: Eval?
21:05 -!- napsy [~luka@88.200.96.18] has joined #go-nuts
21:05 < sauerbraten> from net.Conn reference: "Read(b []byte) (n int, err
os.Error)" I suggest b is a []byte to read into, and n is the number of bytes that
was read?
21:06 < MaybeSo> sorry, Eval() is the name of my function that is calling an
http server and processing the multipart response.
21:06 < wrtp> sauerbraten: yes
21:06 < sauerbraten> ok
21:07 < wrtp> MaybeSo: can't you just stop reading from the http.ClientConn
and return the error?
21:07 < MaybeSo> well, I thought that I had to execute the loop that reads
each part inside a go routine
21:09 < wrtp> i don't think so
21:09 < MaybeSo> here's an example of the original Eval code, that reads the
entire response before returning control to the caller:
21:09 < MaybeSo> http://paste.pocoo.org/show/286218/
21:09 < MaybeSo> I was trying to figure out a way to allow control to return
sooner, not requiring Eval() to build up this potentially huge vector, before
returning
21:10 < MaybeSo> at the very end is this bit of code that constructs the
response data channel and returns it
21:11 < MaybeSo> I was hoping to rearrange the code to allow Eval() to write
each Item directly to the channel instead of sticking it inside a vector until
everything was finished
21:11 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
21:11 < MaybeSo> It just struck me as being a nicer design where a lot of
memory didn't have to be set aside if, as should be the case 99.99% of the time,
no errors occured
21:12 < wrtp> why don't you just use a slice and append, and then return
that?
21:12 < wrtp> after all, the code has already built it
21:14 < MaybeSo> I'm sorry, I'm not understanding what you're suggesting.
:(
21:14 < wrtp> why bother starting a goroutine at all?
21:15 < wrtp> why not just return vec?
21:15 < MaybeSo> um.
21:15 < MaybeSo> Ok, let me take a step back
21:15 < MaybeSo> I'm trying to work toward using channels so that I don't
have to build the vector at all
21:16 < MaybeSo> I don't want to build the vector, I want to return control
right after I start processing the response
21:16 < MaybeSo> so I'm slowly change Eval() to try and accomplish that
21:17 < wrtp> ok, in that case, what about this type for Eval?  func (s
*Server) Eval(q *Query, seq chan<- *Item) os.Error
21:17 < MaybeSo> in other words, make the client responsible for setting up
the channel?
21:17 < wrtp> then no need to start a goroutine, just send on seq and return
the error.
21:17 < wrtp> yup
21:18 < wrtp> make sure you don't close the channel if you do this - it's
the responsibility of the caller, as they've set up the channel.
21:19 < MaybeSo> yeah, ok
21:22 < wrtp> something like this: http://paste.pocoo.org/show/286225/
21:27 -!- binarypie [~binarypie@adsl-99-33-26-93.dsl.pltn13.sbcglobal.net] has
quit [Remote host closed the connection]
21:29 -!- binarypie [~binarypie@adsl-99-33-26-93.dsl.pltn13.sbcglobal.net] has
joined #go-nuts
21:30 -!- cmarcelo [~cmarcelo@enlightenment/developer/cmarcelo] has quit [Quit:
Leaving]
21:31 -!- zozoR [~zozoR@5634798d.rev.stofanet.dk] has quit [Quit: Morten.  Desu~]
21:32 < MaybeSo> thank you for the example.  Would it be normal then to send
a nil down the channel to indicate to the caller that all the items have been
processed?
21:36 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-152-44.clienti.tiscali.it] has
quit [Read error: Connection reset by peer]
21:40 -!- dacc [~Adium@c-67-171-32-251.hsd1.wa.comcast.net] has joined #go-nuts
21:42 < wrtp> no, just returning is sufficient.
21:42 < wrtp> the caller can close the channel if they wish.
21:42 < wrtp> or send the error down an error channel
21:42 < wrtp> or whatever
21:43 < MaybeSo> sorry for being dense, but how will the caller know that
all the items have been sent on the channel and that nothing else will be
arriving?
21:43 < wrtp> you should document that no values will be sent on the channel
after the function has returned.
21:43 < wrtp> if it's an unbuffered channel, then you know that all the
values have already been received.
21:44 < wrtp> if it's buffered, then the caller can close the channel if it
wishes.
21:44 < MaybeSo> huh.  I'm having a hard time understanding how, if seq is
unbuffered, how Eval's call to "seq <- item" won't block forever unless the
reader of items is reading inside a goroutine
21:44 < wrtp> it would be ok for the caller to have several instances of
Eval all writing to the same channel.
21:45 < wrtp> yes, the reader of the channel must be reading in a separate
goroutine.
21:46 < wrtp> e.g.  c := make(chan *Item); go func() {err := srv.Eval(q, c);
close(c); if err != nil {panic(err)}}(); for i := range c { fmt.Printf("got item
%v\n", i) }
21:47 < MaybeSo> got it, thank you
21:49 < wrtp> or c := make(chan *Item); errc := make(chan os.Error); go
func() {errc <- srv.Eval(q, c)}(); for {select {case err := <-errc:
panic(err); case i := <-c: if closed(c) {return}; fmt.Printf("got item %v\n",
i)}}
21:50 < MaybeSo> that's very nice
21:53 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has quit [Read
error: Connection reset by peer]
21:54 < wrtp> it's quite a versatile construct.
21:54 < sauerbraten> why doesn't this piece of code work?
http://pastie.org/1273407 it says me "connection refused" when I want to read from
the server
21:55 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has joined #go-nuts
21:58 -!- sauerbraten [~sauerbrat@p508CAE5D.dip.t-dialin.net] has quit [Remote
host closed the connection]
22:00 < wrtp> what are you passing as the address parameter?
22:04 -!- ExtraSpice [~XtraSpice@88.118.33.48] has quit [Remote host closed the
connection]
22:05 < wrtp> you're not checking the return value of ParseIP - perhaps
you're not passing in a numeric address?
22:08 -!- unhygienix [~unhygieni@host86-135-185-97.range86-135.btcentralplus.com]
has joined #go-nuts
22:15 -!- dacc1 [~Adium@c-24-19-50-69.hsd1.wa.comcast.net] has joined #go-nuts
22:17 -!- Fish- [~Fish@9fans.fr] has quit [Remote host closed the connection]
22:19 -!- dacc [~Adium@c-67-171-32-251.hsd1.wa.comcast.net] has quit [Ping
timeout: 276 seconds]
22:20 -!- saschpe [~quassel@77-23-177-40-dynip.superkabel.de] has quit [Remote
host closed the connection]
22:26 -!- rlab [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller,
Faster, Easier.  http://miranda-im.org]
22:36 -!- liron [~liron@ita4fw1.itasoftware.com] has quit [Quit: liron]
22:39 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit:
Verlassend]
22:40 -!- binarypie [~binarypie@adsl-99-33-26-93.dsl.pltn13.sbcglobal.net] has
quit [Remote host closed the connection]
22:40 -!- ville- [~ville@a107.ath.cx] has quit [Ping timeout: 240 seconds]
22:55 -!- ville- [~ville@a107.ath.cx] has joined #go-nuts
23:04 -!- dacc1 [~Adium@c-24-19-50-69.hsd1.wa.comcast.net] has quit [Quit:
Leaving.]
23:07 -!- awidegreen_ [~quassel@p5DF1E2C3.dip.t-dialin.net] has quit [Remote host
closed the connection]
23:08 -!- fumblebee [~kgay@blk-138-44-93.eastlink.ca] has joined #go-nuts
23:09 -!- Peet__ [~Peet__@unaffiliated/peet--/x-2416233] has joined #go-nuts
23:17 -!- htoothrot [~mux@66-169-185-121.dhcp.ftwo.tx.charter.com] has joined
#go-nuts
23:32 -!- virtualsue [~chatzilla@nat/cisco/x-mdrjmiuxvsnfteah] has joined #go-nuts
23:41 -!- adu [~ajr@pool-74-96-89-94.washdc.fios.verizon.net] has joined #go-nuts
23:46 -!- boscop_ [~boscop@f055159129.adsl.alicedsl.de] has joined #go-nuts
23:47 -!- boscop [~boscop@f055159129.adsl.alicedsl.de] has quit [Ping timeout: 245
seconds]
23:47 -!- tvw [~tv@e176006024.adsl.alicedsl.de] has quit [Read error: Connection
reset by peer]
23:47 -!- tvw [~tv@e176006024.adsl.alicedsl.de] has joined #go-nuts
23:53 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has quit [Quit:
Leaving.]
23:55 -!- dj2 [~dj2@CPE001f5b35feb4-CM0014048e0344.cpe.net.cable.rogers.com] has
joined #go-nuts
23:57 -!- napsy [~luka@88.200.96.18] has quit [Quit: Lost terminal]
--- Log closed Fri Nov 05 00:00:15 2010