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

--- Log opened Wed Mar 16 00:00:55 2011
00:07 -!- rtharper [~tomh@unaffiliated/sioraiocht] has quit [Remote host closed
the connection]
00:09 -!- jhawk28_ [~jhawk28@user-387c58d.cable.mindspring.com] has joined
#go-nuts
00:09 -!- htoothrot [~mux@66-169-185-121.dhcp.ftwo.tx.charter.com] has quit [Read
error: Connection reset by peer]
00:12 -!- crazy2be [~crazy2be@d209-89-248-73.abhsia.telus.net] has joined #go-nuts
00:13 -!- jhawk28 [~jhawk28@user-387c58d.cable.mindspring.com] has quit [Ping
timeout: 252 seconds]
00:13 < str1ngs> I would set it up like I suggested before use something
like lighttpd or cherokee.  w/e you use the most
00:20 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has quit [Quit:
hcatlin]
00:21 -!- m4dh4tt3r [~Adium@154.sub-75-208-216.myvzw.com] has quit [Ping timeout:
240 seconds]
00:25 -!- foocraft [~dsc@78.100.168.186] has joined #go-nuts
00:28 -!- htoothrot [~mux@66-169-185-121.dhcp.ftwo.tx.charter.com] has joined
#go-nuts
00:38 -!- krakensd1n [~krakensde@li221-186.members.linode.com] has left #go-nuts
[]
00:45 -!- saturnfive [~saturnfiv@219.144.163.209] has joined #go-nuts
00:45 -!- saturnfive [~saturnfiv@219.144.163.209] has left #go-nuts []
00:45 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has quit [Ping timeout:
615 seconds]
00:50 -!- dfc [~dfc@sydfibre2.atlassian.com] has joined #go-nuts
00:54 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-181-129.clienti.tiscali.it] has
quit [Quit: E se abbasso questa leva che succ...]
00:58 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the
connection]
01:03 < steven> do any of you use linux with go?
01:03 < steven> im wondering which distro is the lightest weight one to use
go on
01:04 -!- mikespook [~mikespook@116.21.153.120] has joined #go-nuts
01:05 < steven> oh wait what am i thinking..  go can target freebsd right?
01:05 < steven> ill just do that
01:05 -!- nettok [~quassel@200.119.191.151] has joined #go-nuts
01:07 -!- iant [~iant@67.218.107.6] has quit [Quit: Leaving.]
01:15 -!- saturnfive [~saturnfiv@210.74.155.131] has joined #go-nuts
01:34 -!- binarypie [~binarypie@adsl-99-35-135-146.dsl.pltn13.sbcglobal.net] has
quit [Ping timeout: 252 seconds]
01:36 < steven> ugh, it wont install in virtualbox.  sigh.
01:38 < nickbp> depends on what you mean by 'lightweight'
01:38 < nickbp> there are distros that use <8mb ram, others that use
<100mb disk spacke
01:38 < nickbp> -k
01:41 -!- b0rder [~border@114.246.93.45] has joined #go-nuts
01:48 < steven> i mean in terms of crap in the system
01:48 < steven> like, i dont need apt, etc
01:48 < steven> just want to install go
01:52 < nickbp> heres a pretty good site for browsing distros
http://distrowatch.com/
01:56 -!- slashus2 [~slashus2@74-141-110-130.dhcp.insightbb.com] has joined
#go-nuts
01:58 -!- boscop [~boscop@f055163136.adsl.alicedsl.de] has quit [Ping timeout: 250
seconds]
01:59 -!- slashus2 [~slashus2@74-141-110-130.dhcp.insightbb.com] has quit [Client
Quit]
02:02 -!- cenuij [~cenuij@78.112.41.178] has joined #go-nuts
02:02 -!- cenuij [~cenuij@78.112.41.178] has quit [Changing host]
02:02 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts
02:02 < niemeyer> steven: LOL
02:03 < niemeyer> steven: There was a "tiny" experimental project in the Go
tree which would run Go without an OS..  that's likely what you really want.
02:03 < niemeyer> steven: I suggest you pick the project up from the history
and make it work again with the current version of Go.
02:08 < enferex> have there been any talks about haveing a Go conferene or
summit?
02:09 -!- jhawk28_ [~jhawk28@user-387c58d.cable.mindspring.com] has quit [Quit:
Linkinus - http://linkinus.com]
02:11 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the
connection]
02:13 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has joined #go-nuts
02:18 < niemeyer> enferex: Not specifically for Go, that I'm aware of..
there's Google I/O, though
02:18 < enferex> yup
02:18 < enferex> thanks
02:18 -!- rurban [~chatzilla@178-191-210-28.adsl.highway.telekom.at] has joined
#go-nuts
02:22 -!- shvntr [~shvntr@113.84.150.52] has joined #go-nuts
02:24 < niemeyer> enferex: np
02:27 -!- itrekkie [~itrekkie@ip70-190-110-197.ph.ph.cox.net] has joined #go-nuts
02:30 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has joined #go-nuts
02:31 -!- mode/#go-nuts [+v iant] by ChanServ
02:38 -!- itrekkie [~itrekkie@ip70-190-110-197.ph.ph.cox.net] has quit [Quit:
itrekkie]
02:41 -!- itrekkie [~itrekkie@ip70-190-110-197.ph.ph.cox.net] has joined #go-nuts
02:52 -!- cenuij [~cenuij@78.112.41.178] has joined #go-nuts
02:52 -!- cenuij [~cenuij@78.112.41.178] has quit [Changing host]
02:52 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts
02:57 -!- Urmel| [~11087Urme@82-136-196-44.ip.telfort.nl] has quit [Read error:
Connection reset by peer]
02:57 -!- Urmel| [~11087Urme@82-136-196-44.ip.telfort.nl] has joined #go-nuts
03:03 -!- skelterjohn [~jasmuth@c-68-46-33-145.hsd1.nj.comcast.net] has joined
#go-nuts
03:23 -!- PJ_Robins [~finn@174-20-67-7.mpls.qwest.net] has quit [Remote host
closed the connection]
03:33 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the
connection]
03:50 -!- aho [~nya@fuld-590c7bbc.pool.mediaWays.net] has quit [Quit:
EXEC_over.METHOD_SUBLIMATION]
03:58 -!- gogogrrl [~max@p5DE8E0AB.dip.t-dialin.net] has joined #go-nuts
03:59 -!- niemeyer [~niemeyer@201-11-241-43.pltce701.dsl.brasiltelecom.net.br] has
quit [Ping timeout: 255 seconds]
04:00 -!- itrekkie [~itrekkie@ip70-190-110-197.ph.ph.cox.net] has quit [Quit:
itrekkie]
04:00 < Xenith> I don't suppose its possible to get at the socket descriptor
with a net.Listener or net.TCPListener, and then subsequently reattach to that
descriptor with a new Listener?
04:01 -!- gogogrrl_ [~max@p5DE8E1EB.dip.t-dialin.net] has quit [Ping timeout: 252
seconds]
04:02 -!- itrekkie [~itrekkie@ip70-190-110-197.ph.ph.cox.net] has joined #go-nuts
04:03 -!- binarypie [~binarypie@c-24-6-151-185.hsd1.ca.comcast.net] has joined
#go-nuts
04:04 -!- cenuij [~cenuij@78.112.41.178] has joined #go-nuts
04:05 -!- cenuij [~cenuij@78.112.41.178] has quit [Changing host]
04:05 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts
04:06 -!- itrekkie [~itrekkie@ip70-190-110-197.ph.ph.cox.net] has quit [Ping
timeout: 246 seconds]
04:10 -!- itrekkie [~itrekkie@ip70-190-110-197.ph.ph.cox.net] has joined #go-nuts
04:11 -!- itrekkie [~itrekkie@ip70-190-110-197.ph.ph.cox.net] has quit [Client
Quit]
04:13 -!- nettok [~quassel@200.119.191.151] has quit [Ping timeout: 276 seconds]
04:14 -!- rejb [~rejb@unaffiliated/rejb] has quit [Ping timeout: 246 seconds]
04:42 -!- arvindht [c2ed8e07@gateway/web/freenode/ip.194.237.142.7] has joined
#go-nuts
05:00 -!- binarypie [~binarypie@c-24-6-151-185.hsd1.ca.comcast.net] has quit
[Remote host closed the connection]
05:04 -!- itrekkie [~itrekkie@ip70-190-110-197.ph.ph.cox.net] has joined #go-nuts
05:07 -!- mikespook [~mikespook@116.21.153.120] has quit [Read error: Connection
reset by peer]
05:09 -!- mikespook [~mikespook@183.47.228.38] has joined #go-nuts
05:19 -!- yrashk [~yrashk@184-106-180-7.static.cloud-ips.com] has joined #go-nuts
05:21 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has joined #go-nuts
05:25 -!- joo [~joo@unaffiliated/joo] has joined #go-nuts
05:27 < joo> Hello I am here from #go to troll you
05:27 < joo> Why do you have such a weird logo?
05:32 < zozoR> define weird?
05:35 < exch> everyone loves a gopher
05:41 < KirkMcDonald> That's Gordon the Gopher.
06:02 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has quit [Remote host closed
the connection]
06:03 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has joined #go-nuts
06:05 -!- tensorpudding [~user@99.148.205.193] has joined #go-nuts
06:11 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
06:13 < crazy2be> night all
06:13 -!- crazy2be [~crazy2be@d209-89-248-73.abhsia.telus.net] has quit [Remote
host closed the connection]
06:30 -!- KirkMcDonald [~Kirk@python/site-packages/KirkMcDonald] has quit [Read
error: Operation timed out]
06:31 -!- KirkMcDonald [~Kirk@python/site-packages/KirkMcDonald] has joined
#go-nuts
06:33 -!- b0rder [~border@114.246.93.45] has quit []
06:34 < joo> I see.
06:34 < joo> You're copying Gnu with their...  Gnu
06:40 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the
connection]
06:43 < exch> nsf: gocode needs to be updated for the latest go weekly
06:44 < exch> "gocode.go:270: cannot use os.Environ() (type []string) as
type *os.ProcAttr in function argument"
06:44 < nsf> ...  :)
06:44 < nsf> I'm not a superman
06:44 < nsf> I'm working on it
06:44 < exch> work faster!  :D
06:44 < shakesoda> Go faster
06:44 < shakesoda> ;)
06:45 < exch> gofix solves the issue though
06:45 < exch> incidentally, gocode binary size went from 8.5 mb to 3.9 mb
06:46 < |Craig|> go fix gocode's go code with gofix?
06:46 < exch> something like that :p
06:48 -!- dfc [~dfc@sydfibre2.atlassian.com] has quit [Read error: Operation timed
out]
06:48 < Eko> do we intend gofix to only work between two releases?
06:49 < Eko> i.e.  after next release, will it continue to fix changes made
by this release?
06:50 < nsf> exch: there are also 8 tests that are failing
06:50 < nsf> so..  compiling gocode isn't everything
06:50 -!- dfc [~dfc@sydfibre2.atlassian.com] has joined #go-nuts
06:50 < Eko> if not, someone should write and check in a script that updates
by one revision at a time running gofix on the specified files/directories ;-)
06:50 < exch> nsf: true, but those tests dont break my aggregate build
script :p
06:51 < nsf> and btw
06:51 < nsf> here is the error message from yesterday's guy
06:51 < nsf> 44:104: expected ';', found '.' (and 5 more errors)
06:51 < nsf> it means package parser is broken
06:51 < nsf> fuck
06:53 -!- dfc [~dfc@sydfibre2.atlassian.com] has quit [Client Quit]
07:00 -!- rurban [~chatzilla@178-191-210-28.adsl.highway.telekom.at] has quit
[Ping timeout: 276 seconds]
07:07 < nsf> exch: fixed..  fully functional now
07:08 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
07:09 < exch> cool :)
07:23 < mikespook> Hi, how do I pass a void pointer into C function using
cgo.
07:23 < mikespook> or how do I write a go func and pass it into C for
callback.
07:24 -!- chressie [~chressie@dreggn.in-ulm.de] has quit [Quit: WeeChat 0.3.4]
07:37 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|]
07:48 -!- dfc [~dfc@124-169-149-145.dyn.iinet.net.au] has joined #go-nuts
07:48 -!- joo [~joo@unaffiliated/joo] has left #go-nuts []
07:51 -!- saturnfive1 [~saturnfiv@210.74.155.131] has joined #go-nuts
07:51 -!- saturnfive [~saturnfiv@210.74.155.131] has quit [Read error: Connection
reset by peer]
08:02 -!- itrekkie [~itrekkie@ip70-190-110-197.ph.ph.cox.net] has quit [Quit:
itrekkie]
08:02 < str1ngs> mikespook: there are some cgo examples ins misc/cgo folder
08:02 < mikespook> I've read that
08:02 < str1ngs> I'd have to see the signature the C function
08:03 < mikespook> foobar(void * f);
08:03 < mikespook> f is a pointer to a function
08:04 < str1ngs> so a callback ya..  that I'm not sure
08:04 -!- chressie [~chressie@dreggn.in-ulm.de] has joined #go-nuts
08:04 < str1ngs> mikespook: what you can do is created the call back in C
and pass that
08:05 < mikespook> ja, it is puzzle me
08:05 < str1ngs> for now.  but post to the google go-nut group.  my C is
weak at best
08:05 < mikespook> But I need a go func for callback, and pass it into a c
lib.
08:05 < str1ngs> mikespook: on sec I'll show you one I did.  but remember my
C is bad :P
08:06 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts
08:06 < str1ngs> mikespook:
https://github.com/str1ngs/gurl/blob/master/gurl.go
08:06 < mikespook> :-Dthx
08:07 < str1ngs> this uses a curl call back.  and then I simplified it to
call from Go. not the right way I'm sure but it works
08:09 < xulfer> Aren't they still working out cgo C -> Go callbacks?
08:10 < mikespook> ah!  thx str1ngs!  this is a funny way for callback.
08:11 < str1ngs> mikespook: aye but hey it works lol
08:11 < str1ngs> mikespook: post to the google group.  I'm not even a C
programmer :P
08:11 < mikespook> lol
08:12 < mikespook> I'm trying to wrap a wrapper for libgearman.
08:13 < str1ngs> mikespook: bindings pretty easy if the libs are good.  but
ya I can see callbacks being a pain.
08:13 < mikespook> maybe, I should impl the gearman's protocol but a C lib
wrapper...
08:14 < str1ngs> mikespook: here a binding I'm working on to libgit
https://github.com/str1ngs/go-git/blob/master/git.go
08:14 < str1ngs> mikespook: maybe some stuff will be useful in there like
the use of godef
08:14 < str1ngs> actually libgit2
08:15 < mikespook> Oh! cool
08:17 < str1ngs> mikespook: ya and often times I start to wonder if it might
be better to not now a 1 to 1 wrap but impliment some of it Go
08:18 < mikespook> I think so.
08:18 -!- tensorpudding [~user@99.148.205.193] has quit [Remote host closed the
connection]
08:19 < mikespook> Any way, Thank you!  str1ngs.
08:19 < str1ngs> mikespook: np, but do post to the google group about the
callback.
08:20 < str1ngs> I think eventually I'll need it to atleast for another
binding I'm working on.
08:20 < mikespook> all right, I would.
08:21 < str1ngs> mikespook: but I do think in the long run its better to
have native implementations
08:22 < mikespook> or the pkg give some way for callback.
08:23 < mikespook> looks like this: unsafe.Callback(func(){})
08:25 -!- chimes [~chimes@209.118.191.162] has quit [Ping timeout: 240 seconds]
08:29 < str1ngs> mikespook: I need to rewrite gurl.  that was in my infant
days messing with cgo
08:29 < mikespook> :-D
08:30 < str1ngs> eventually I want to make a go package that does alot of
what curl does.  atleast for http/https and ftp
08:31 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-160-239.clienti.tiscali.it] has
joined #go-nuts
08:31 -!- rtharper [~tomh@unaffiliated/sioraiocht] has joined #go-nuts
09:02 -!- wrtp [~rog@92.17.17.88] has joined #go-nuts
09:03 -!- venk [~user@CPE-124-189-81-145.azsz1.cht.bigpond.net.au] has joined
#go-nuts
09:07 -!- napsy [~luka@193.2.66.6] has joined #go-nuts
09:09 -!- SecretAgent [sa@28.158.143.98.nitemare.name] has joined #go-nuts
09:14 -!- arvindht [c2ed8e07@gateway/web/freenode/ip.194.237.142.7] has quit [Ping
timeout: 252 seconds]
09:29 -!- Boney_ [~paul@203-158-33-103.dyn.iinet.net.au] has joined #go-nuts
09:32 -!- Fish- [~Fish@coss6.exosec.net] has quit [Quit: So Long, and Thanks for
All the Fish]
09:32 -!- Boney [~paul@124-148-151-46.dyn.iinet.net.au] has quit [Ping timeout:
240 seconds]
09:33 -!- visof [~visof@unaffiliated/visof] has joined #go-nuts
09:36 -!- Fish [~Fish@exo3753.pck.nerim.net] has joined #go-nuts
09:44 -!- venk [~user@CPE-124-189-81-145.azsz1.cht.bigpond.net.au] has quit [Quit:
ERC Version 5.3 (IRC client for Emacs)]
09:54 -!- l00t [~i-i3id3r_@189.105.53.156] has quit [Remote host closed the
connection]
10:10 -!- rbraley [~rbraley@114.250.73.141] has joined #go-nuts
10:23 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has quit [Quit:
Leaving]
10:24 -!- skejoe [~skejoe@188.114.142.162] has joined #go-nuts
10:29 -!- saturnfive1 [~saturnfiv@210.74.155.131] has quit [Read error: Connection
reset by peer]
10:39 -!- ronnyy [~quassel@p4FF1C6BC.dip0.t-ipconnect.de] has joined #go-nuts
10:43 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has joined #go-nuts
10:48 -!- gid [~gid@220-253-33-95.VIC.netspace.net.au] has quit [Ping timeout: 252
seconds]
10:55 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has joined
#go-nuts
10:56 -!- dfc [~dfc@124-169-149-145.dyn.iinet.net.au] has quit [Quit: dfc]
10:58 -!- saturnfive [~saturnfiv@219.144.163.209] has joined #go-nuts
11:02 -!- saturnfive [~saturnfiv@219.144.163.209] has left #go-nuts []
11:06 -!- rlab [~Miranda@91.200.158.34] has quit [Read error: Connection reset by
peer]
11:07 -!- gid [~gid@220-253-158-27.VIC.netspace.net.au] has joined #go-nuts
11:29 -!- rup [~rupert@deathknight.net] has quit [Ping timeout: 276 seconds]
11:29 -!- dfc [~dfc@124-169-149-145.dyn.iinet.net.au] has joined #go-nuts
11:32 -!- shvntr [~shvntr@113.84.150.52] has quit [Quit: leaving]
11:35 -!- dfc [~dfc@124-169-149-145.dyn.iinet.net.au] has quit [Quit: dfc]
11:47 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has quit [Quit:
peace in teh middle east]
11:49 -!- artefon [~thiago@dhcp26.usuarios.dcc.ufmg.br] has joined #go-nuts
11:50 -!- cenuij [~cenuij@78.112.41.178] has joined #go-nuts
11:50 -!- cenuij [~cenuij@78.112.41.178] has quit [Changing host]
11:50 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts
11:59 -!- poseidon [~pondj@compile.vcu.edu] has quit [Ping timeout: 276 seconds]
12:07 -!- jgonzalez [~jgonzalez@173-14-137-134-NewEngland.hfc.comcastbusiness.net]
has joined #go-nuts
12:23 -!- Natch| [~natch@c-6dcde155.25-4-64736c10.cust.bredbandsbolaget.se] has
quit [Quit:  /(bb|[^b]{2})/]
12:24 -!- larva [~larvanitr@ec2-46-51-171-183.eu-west-1.compute.amazonaws.com] has
joined #go-nuts
12:26 -!- mdxi_ [~mdxi@li11-97.members.linode.com] has joined #go-nuts
12:26 -!- iTonnerre [tonnerre@ds1789693.dedicated.solnet.ch] has joined #go-nuts
12:26 -!- hokapoka_ [~hokapoka@hoka.hokapoka.com] has joined #go-nuts
12:26 -!- hypertux_ [~hypertux@vps1.joelegasse.com] has joined #go-nuts
12:26 -!- i___ [~none@69.164.206.224] has joined #go-nuts
12:26 -!- iTonnerre [tonnerre@ds1789693.dedicated.solnet.ch] has quit [Changing
host]
12:26 -!- iTonnerre [tonnerre@netbsd/developer/tonnerre] has joined #go-nuts
12:26 -!- scoeri_ [~jdekoste@progftp.vub.ac.be] has joined #go-nuts
12:26 -!- vsmatck [~smack@64-142-40-6.dsl.static.sonic.net] has quit [Ping
timeout: 240 seconds]
12:26 -!- hypertux [~hypertux@vps1.joelegasse.com] has quit [Ping timeout: 240
seconds]
12:26 -!- hokapoka [~hokapoka@hoka.hokapoka.com] has quit [Ping timeout: 240
seconds]
12:26 -!- nsfx [~nsfx@pool-96-225-70-167.nwrknj.fios.verizon.net] has quit [Ping
timeout: 240 seconds]
12:26 -!- Tonnerre [tonnerre@netbsd/developer/tonnerre] has quit [Ping timeout:
240 seconds]
12:26 -!- scoeri [~jdekoste@ecoop98.vub.ac.be] has quit [Ping timeout: 240
seconds]
12:26 -!- welterde [welterde@thinkbase.srv.welterde.de] has quit [Ping timeout:
240 seconds]
12:26 -!- mdxi [~mdxi@li11-97.members.linode.com] has quit [Ping timeout: 240
seconds]
12:26 -!- larva_ [~larvanitr@ec2-46-51-171-183.eu-west-1.compute.amazonaws.com]
has quit [Ping timeout: 240 seconds]
12:26 -!- i__ [~none@69.164.206.224] has quit [Ping timeout: 240 seconds]
12:26 -!- homa_rano [~erice@hmsvelociraptor.csail.mit.edu] has quit [Ping timeout:
240 seconds]
12:28 -!- nsfx [~nsfx@pool-96-225-70-167.nwrknj.fios.verizon.net] has joined
#go-nuts
12:31 -!- homa_rano [~erice@hmsvelociraptor.csail.mit.edu] has joined #go-nuts
12:32 -!- mikespook [~mikespook@183.47.228.38] has quit [Quit: Leaving.]
12:36 -!- vsmatck [~smack@64-142-40-6.dsl.static.sonic.net] has joined #go-nuts
12:39 -!- welterde [welterde@thinkbase.srv.welterde.de] has joined #go-nuts
12:42 < nsf> http://ompldr.org/vN3UyaQ/2011-03-16-174524_948x536_scrot.png
12:42 < nsf> :P
12:43 * nsf has added full ranges info to all AST nodes
12:43 < nsf> now it's very easy to highlight different code stuff
12:45 -!- niemeyer [~niemeyer@201-11-241-43.pltce701.dsl.brasiltelecom.net.br] has
joined #go-nuts
12:46 < nsf> hehe, there was a funny moment
12:46 < nsf> I've switched to g++ from clang++
12:46 < nsf> because clang++ fails to eat gcc's tr1/unordered_map
12:47 < nsf> but in clang there is a nice feature
12:47 < nsf> it throws warning if one of the enum elements wasn't handled by
a switch statement
12:47 < nsf> and the lack of that thing in gcc (or maybe I just need to turn
it on)
12:48 -!- jokoon [~jorinovsk@LMontsouris-156-26-32-176.w80-14.abo.wanadoo.fr] has
joined #go-nuts
12:48 < nsf> smacked me in a face
12:48 < nsf> ugh..
12:48 < ww> niemeyer: got tired of cabinet's thread-related heisenbugs, so
i'm using your mmap module to make a custom disc based tree...
12:49 < ww> however am finding it very inconvenient to use an array of
byte[] to hold datastructures...
12:49 < ww> in that circumstance go gives far less abstraction than C...
12:50 < ww> actually thinking of using CPP or M4 to generate the appropriate
go code...
12:50 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has joined #go-nuts
13:06 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has quit [Quit: ERC Version 5.3
(IRC client for Emacs)]
13:06 -!- ivan` [~ivan@li125-242.members.linode.com] has joined #go-nuts
13:06 < wrtp> ww: in that case, maybe unsafe might be appropriate
13:06 -!- ivan` [~ivan@li125-242.members.linode.com] has quit [Changing host]
13:06 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has joined #go-nuts
13:07 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has quit [Quit:
Leaving.]
13:09 < niemeyer> ww: Hmm, interesting
13:09 < niemeyer> ww: What's the deal with byte[]?
13:09 < niemeyer> ww: The casting is what bothers you?
13:10 < ww> wrtp: yes, but a bit worried that gc will try to collect mmaped
memory which would be bad
13:10 < ww> niemeyer: what guarantees do we have that the memory arrangement
of a struct will remain the same in the future?
13:11 < ww> with c they're pretty strong, particularly with __packed__
13:11 < niemeyer> ww: None for now, I believe
13:12 < ww> right, so if that changes, i'll have data being destroyed
13:12 < ww> which might be fine for the moment, this is a hightly
experimental thing
13:12 < niemeyer> ww: You can inspect it, though
13:12 < wrtp> ww: if you're doing persistent storage, you should marshal
rather than use unsafe
13:13 -!- skejoe [~skejoe@188.114.142.162] has quit [Quit: Lost terminal]
13:13 < niemeyer> ww: And yeah, I would suppose that anything you do right
now with Go should be put on that ballpark..  if changing in the future is not an
option, then it's not appropriate.
13:13 < ww> wrtp: no good.  index over lots of data.  needs to be fast
13:13 < niemeyer> wrtp: I suppose he's interested in some of the benefits
13:14 < wrtp> ww: marshalling is not necessarily slow
13:14 < niemeyer> wrtp: It is necessary much slower than an mmap
13:14 < wrtp> niemeyer: you can marshal and still use an mmap
13:14 < ww> wrtp: can you give an example of what you mean?
13:14 < niemeyer> ww: That said, you can use the mmap as a cache to the real
data
13:15 < niemeyer> wrtp: Sure..  and kill some of the points of using it
13:15 < niemeyer> ww: apt does that, for instance
13:15 < wrtp> niemeyer: depends where you think the overhead is
13:15 < niemeyer> wrtp: It doesn't depend where *I* think it is..  :-)
13:16 < niemeyer> wrtp: The overhead is there regardless of my observation.
:)
13:16 < wrtp> niemeyer: if you're doing persistent storage, it always pays
to use a well defined format.
13:16 < wrtp> :-)
13:16 < ww> in this case the data being stored are nodes in a tree
13:16 < wrtp> yeah yeah
13:16 < niemeyer> wrtp: Heh..  nonsense
13:16 < ww> this is an index into persistent storage
13:16 < niemeyer> wrtp: There are *so many* applications doing direct mmap
of data for speed reasons
13:17 < ww> i have a large amount of data of the form [4]uint64
13:17 < ww> i need to be able to find one quickly and iterate in order
13:17 < wrtp> ww: i'd start by marshalling (probably using encoding/binary)
and then optimise from there
13:17 < ww> that's exactly what i'm doing (small difference between that and
unsafe)
13:18 < wrtp> next step from using encoding/binary is to use the PutInt64
etc functions directly (reflection adds some overhead)
13:18 < ww> the thing is, writing a tree traversal with Uint64/PutUint64 is
possible but tedious since you can't directly use a struct
13:19 < wrtp> ww: i'd write a little helper function, GetNode(ptr uint64)
Node
13:19 < wrtp> which returns a node in the tree, unmarshalling it from the
mmap
13:20 < wrtp> you'll have the advantage that you'll use less storage,
because you won't have to adhere to the usual struct alignment restrictions
13:20 < wrtp> niemeyer: i think they do it mainly because it's dead easy to
do in C.
13:21 < wrtp> niemeyer: and then they suffer when they want to use a machine
with different endianness
13:21 < ww> alignment shouldn't be much of an issue, the footprint of a node
is exactly 64 bytes
13:22 < niemeyer> wrtp: Man..  try to read a bit about databases
13:22 < ww> actually, that can be made as small as 40 bytes but then
alignment gets troublesome for uint64
13:22 -!- sauerbraten [~sauerbrat@p508CB63B.dip.t-dialin.net] has joined #go-nuts
13:23 -!- napsy [~luka@193.2.66.6] has quit [Quit: leaving]
13:23 < wrtp> ww: marshalling 64 bytes is really very fast.  i wonder if
you'll notice the difference.
13:24 < niemeyer> apt is another good example of that..  I suffered for
years trying to beat the speed of loading with unmarshalling..  Simply not
possible..  loading the cache in memory means doing an mmap of a file.
Unbeatable.
13:24 < wrtp> niemeyer: what kind of database stuff?  i've looked a bit at
some database implementations.
13:24 < wrtp> apt?
13:24 < niemeyer> wrtp: apt-get?
13:25 < wrtp> ?
13:25 < wrtp> oh
13:25 < wrtp> is that a package installation thingy?
13:25 < wrtp> [vague memories]
13:25 < ww> indending to scale to 1e9 - 1e11 nodes...  certain i'll notice
the difference
13:26 < wrtp> ww: size limit on an array in Go is 2e9 entries
13:26 < niemeyer> wrtp: Yeah
13:26 < ww> aha.  that's good to know
13:26 -!- boscop [~boscop@f055163136.adsl.alicedsl.de] has joined #go-nuts
13:27 < ww> in any event, breaking up into segments is not a terribly big
problem
13:29 -!- karpar [~user@112.96.254.18] has joined #go-nuts
13:30 < ww> i wonder...  maybe just define the struct in c and use cgo...
only manipulate it from go
13:30 < ww> that should prevent gc worries as well
13:31 < wrtp> ww: the overhead of cgo will probably be more than the
overhead of marshalling
13:32 < ww> even just for accessing data with no function calls?
13:32 < wrtp> ww: what would the point be?
13:33 < niemeyer> No cgo is needed for *that*
13:33 < niemeyer> You can use 6c
13:33 < niemeyer> Or, Nc
13:33 < niemeyer> :)
13:33 < ww> guaranteed memory representation + convenience in writing
methods in go
13:33 < ww> so:
13:34 < ww> type MyStruct *C.mystruct
13:34 < niemeyer> ww: Ugh..  I'd agree with wrtp's earlier point in that
case..
13:34 < niemeyer> ww: If you want guaranteed memory representation across
platforms, then don't do it
13:35 < wrtp> ww: C doesn't guarantee memory representation
13:35 < ww> not across platforms, just consistency within one
13:36 < wrtp> ww: Go is as consistent (or as inconsistent) as C.
13:36 < ww> except that go is more likely to change than C
13:36 < wrtp> niemeyer: you should set the TARG of your mmap implementation
to launchpad.net/gommap
13:37 < ww> what i don't want is a change in go meaning an unreadable index
13:37 < wrtp> ww: if it does change, the format is trivial enough that it
would be easy to convert
13:37 < niemeyer> wrtp: Cool, we're doing some work on it, so will include
that
13:38 < niemeyer> Even Shaw has been fixing some problems in other platforms
13:38 < ww> niemeyer: i had some weirdness building it...
13:38 < niemeyer> ww: What was that?
13:38 -!- plainhao [~plainhao@208.75.85.237] has joined #go-nuts
13:38 < ww> goinstall ended up complaining sys/mman.h didn't exist
13:39 < ww> building it by hand with gomake worked fine though...  didn't
give it much thought
13:39 < niemeyer> ww: Regarding the memory representation, you might try
something similar to apt
13:39 < wrtp> niemeyer: also, it doesn't compile under MacOS without some
constants being removed from consts.c
13:39 < niemeyer> ww: The cache/working memory is platform specific, but
it's loaded from somewhere else and disposable
13:39 < niemeyer> ww: What's your OS?
13:40 < ww> also osx - but didn't have wrtp's problem
13:40 < niemeyer> wrtp: Cool, someone with an eye on MacOS will have to look
at it
13:40 < niemeyer> ww: Ah, nice, that's good to know
13:40 < ww> wrtp - which osx for you?
13:40 < wrtp> ww: 10.6.6
13:40 < ww> Darwin loki.local 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov
10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386
13:41 < ww> (why does kernel say 10.6.0?  the little gui dialog thing says
10.6.6...)
13:42 < wrtp> niemeyer: i had to remove MAP_ANONYMOUS MAP_GROWSDOWN
MAP_LOCKED MAP_NONBLOCK, MAP_POPULATE
13:42 < wrtp> and all the MADV constants
13:42 < wrtp> pity it can't be made goinstallable
13:42 -!- iant [~iant@67.218.107.6] has joined #go-nuts
13:42 -!- mode/#go-nuts [+v iant] by ChanServ
13:42 < niemeyer> wrtp: Why not?
13:42 < ww> wrtp that shouldn't be the case.  at the very least
MAP_ANONYMOUS is very standard
13:42 < niemeyer> wrtp: It surely can
13:43 < wrtp> niemeyer: well, it could if you hardwired the constants...  or
(doh!) use CGO
13:43 < wrtp> but then the constants would not be constants
13:44 < wrtp> or...  maybe they could be
13:44 < wrtp> i'll give it a go
13:44 < niemeyer> wrtp: THey can be, per OS
13:44 < wrtp> yeah
13:44 < wrtp> i hadn't thought until just then that you could export the C
constants direct to Go
13:45 < niemeyer> wrtp: It can change, but it's somewhat of a weird thing to
do from the OS perspective, so we can trust they won't change that often if ever
13:45 < ww> no...  i lied...  MAP_ANON not MAP_ANONYMOUS
13:45 -!- shvntr [~shvntr@113.84.150.52] has joined #go-nuts
13:45 < wrtp> yeah, it's not ANON not ANONYMOUS
13:46 < ww> calls that use those happen relatively infrequently i think.
13:46 -!- Natch| [~natch@c-6dcde155.25-4-64736c10.cust.bredbandsbolaget.se] has
joined #go-nuts
13:46 < ww> i'd opt for just using from cgo
13:46 < ww> that way you don't have to worry about what different platforms
think their constants are
13:47 < wrtp> ww: i don't think there has to be any performance penalty, but
i'm just checking
13:47 < niemeyer> ww: We only have to get this right once, so I'd rather
avoid cgo since there's really no real dependency on it
13:48 -!- gid [~gid@220-253-158-27.VIC.netspace.net.au] has quit [Ping timeout:
252 seconds]
13:48 < wrtp> niemeyer: cgo wouldn't actually link in any files.  i don't
think there's a problem with it.
13:48 < wrtp> better than hardwiring the constants, i reckon
13:51 < niemeyer> wrtp: Well, I personally find hardwiring the constants
once simpler than carrying that logic forever
13:51 < niemeyer> Even more considering that, strictly speaking, there's no
hardwiring
13:51 < niemeyer> Just use a C file to generate them, as done today
13:52 < wrtp> niemeyer: yeah - but you need to do that on each platform that
you're going to deploy on
13:52 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has quit [Ping
timeout: 250 seconds]
13:52 < niemeyer> wrtp: Yep, once
13:54 < skelterjohn> niemeyer: what rule did goinstall decide on for
filtering based on platform, if any?
13:54 < wrtp> niemeyer: couldn't be much simpler than this, surely?
http://pastebin.com/Cm2Fv0uA
13:54 < skelterjohn> it would be very simple to have a file with *_darwin*
in its name only work on macs
13:56 < wrtp> skelterjohn: that's what happens
13:56 < niemeyer> skelterjohn: foo_$(GOOS)_$(GOARCH).go/c/s
13:57 < niemeyer> skelterjohn: foo_$(GOOS).* and _$(GOARCH).* too
13:57 < skelterjohn> do you need to have both?
13:57 < skelterjohn> ah
13:57 < skelterjohn> what about _unix and _bsd
13:57 < skelterjohn> runtime has files like that
13:58 < niemeyer> wrtp: I don't understand what you mean by that..  this
isn't really solving the platform-specific problems
13:58 < wrtp> niemeyer: i think i'd go for the cgo approach with one file
with the constants that all platforms have in common, and system dependent files
for constants that only some systems have
13:58 < niemeyer> wrtp: These consts may not exist
13:58 < wrtp> that way it'll work automatically with even new platforms, as
long as they have the basic constants
13:59 < ww> the posix subset of them should exist everywhere
13:59 < wrtp> that kind of thing, yes
13:59 < wrtp> BTW, i think that "mmap" would be a better package identifier
than gommap
14:00 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has joined
#go-nuts
14:00 < wrtp> the "go" seems kinda redundant when we're writing in go :-)
14:00 < niemeyer> Yeah, I discussed that with Russ yesterday..  it'll be
gommap/mmap
14:00 < niemeyer> wrtp: It is, but is not redundant in the grand scheme
14:00 < wrtp> i agree that the path should be gommap
14:01 < wrtp> gommap/mmap is what i would have chosen
14:01 < niemeyer> Cool, let's do that then
14:02 < wrtp> i wondered about making the constants different types too; but
that's maybe overkill
14:02 -!- Venom_X [~pjacobs@75.92.43.21] has joined #go-nuts
14:03 -!- karpar [~user@112.96.254.18] has quit [Ping timeout: 260 seconds]
14:03 < ww> whatever makes for the least casting on the way down (i think
it's uint now)
14:03 -!- rup [~rupert@deathknight.net] has joined #go-nuts
14:04 < wrtp> ww: you should never have to cast them
14:04 < ww> i mean inside gommap
14:05 < ww> basically whatever Syscall wants
14:05 < aiju> no casting with mmap?
14:05 < aiju> magicß
14:05 < aiju> *?
14:05 -!- iant [~iant@67.218.107.6] has quit [Ping timeout: 260 seconds]
14:05 < ww> aiju: casting constants
14:05 < aiju> oh sure
14:05 -!- iant [~iant@216.239.45.130] has joined #go-nuts
14:06 -!- mode/#go-nuts [+v iant] by ChanServ
14:08 -!- gid [~gid@220-253-156-13.VIC.netspace.net.au] has joined #go-nuts
14:08 < xyproto> what should be captialized/upper/lower/camelcase in Go by
convension?  Uppercase constants, lowercase variables, captialized types and
camelcase methods?
14:08 < xyproto> *convention
14:08 < aiju> Uppercase exported, lowercase unexported?
14:09 < aiju> since that's enforced by the language there is little sense in
restricting that to anything
14:09 < xyproto> aiju: ok, thx.  But, I seem to recall that types (?) are
usually capitalized?
14:09 < aiju> yes, because they are exported ;P
14:10 < wrtp> xyproto: types are only capitalised when they're exported, as
aiju says
14:10 < xyproto> ok
14:10 < wrtp> same with constants
14:10 < wrtp> same with everything :-)
14:10 < xyproto> so constants are not usually uppercase
14:10 < ww> it is possible to have locwercase unexported types and sometimes
even useful
14:10 < xyproto> but, how about function names, is camelcase or use of "_"
to separate words (like in Python) most common?
14:10 < aiju> camelcase
14:10 -!- Venom_X [~pjacobs@75.92.43.21] has quit [Ping timeout: 246 seconds]
14:10 < kimelto> but you still have the choice between ExportedFunction and
Exported_function, unexportedFunction/unexported_function :)
14:10 < wrtp> xyproto: no.  only legacy constants from unix are upper case
14:10 < wrtp> camelcase
14:11 < wrtp> underscores are generally not used
14:11 < xyproto> ok.  So uppercase exported, lowercase unexported, camelcase
function names.  Got it :)
14:11 < aiju> "legacy constants"
14:11 < ww> i use _ for private symbols and camel case for exported ones
14:11 < ww> as in my_private_function
14:11 < aiju> i use CamelCase for exported and camelCase for unexported
14:11 < wrtp> aiju: that's the standard way
14:12 < xyproto> I like using uppercase for constants, lowercase for
variables, _ instead of camelcase and capitalized types, but that may just be me
14:12 < wrtp> legacy constants like os.O_RDWR
14:12 * ww finds camelCase not clear enought visually
14:12 < wrtp> xyproto: that's the usual C approach
14:12 < ww> but this is largely a matter of personal preference
14:12 < wrtp> go is different
14:12 < aiju> and then it's just bikeshed ...
14:13 < kimelto> \o/
14:13 < xyproto> wrtp: true enuough.  It surprises me that there's fewer
conventions, though, as a common visual appearance of how code looks can help
readability
14:13 < aiju> the worst is "tabs vs spaces"
14:13 < aiju> arguing about something you don't even see
14:13 < kimelto> spab of course!
14:13 < xyproto> aiju: well, you don't "see" any file, just the
representation by the editor/app you use to open it with
14:14 < xyproto> aiju: you would have quite the electron microscope to see
your files on a disk ;)
14:14 < aiju> yeah and i don't see the representation or whatever
14:14 < kimelto> If you use tabs, please of please, tabs *are* 8 spaces long
14:14 < kimelto> that's all Im asking ;)
14:14 < aiju> i didn't intend to kick off a philosophical discussion about
the perception of objects
14:14 < wrtp> xyproto: the conventions are stronger, if anything
14:14 < xyproto> kimelto: I like 4 spaces long tabs ;)
14:15 < xyproto> kimelto: but I agree with you
14:15 < wrtp> xyproto: look at the go source tree for examples
14:15 < aiju> just use what fucking pleases you and stop wasting your time
with ridiculous arguments
14:16 < xyproto> aiju: there's a scale that goes from "no cooperation, use
whatever you please, no discussions" through a nice center all the way to "only
cooperation, don't use what you please, only discussion"...
14:16 < xyproto> aiju: neither extremes are constructive, imo
14:17 < Namegduf> The benefits of any particular format are overwhelmed by
the gains of consistency
14:17 < Namegduf> Go has a standard formatter
14:17 -!- Venom_X [~pjacobs@66.54.185.131] has joined #go-nuts
14:17 -!- viirya [~viirya@cml506-25.csie.ntu.edu.tw] has quit [Read error:
Connection reset by peer]
14:17 < Namegduf> What it does is correct.
14:17 < aiju> well, in a project you should use what everyone else uses.
simple.
14:17 -!- viirya [~viirya@cml506-25.csie.ntu.edu.tw] has joined #go-nuts
14:18 < xyproto> ok, I'm convinced, with the presedences of the Go source
code and also the source formatter, it's very clear.  Thank you.
14:18 < ww> go enforces enough that "do whatever you please" doesn't leave
*that* much choice.  it kind of enforces the nice centre that you talk about
14:20 * ww would like a purple bike shed
14:20 < xyproto> north corea isn't conformist, they've just decided a lot of
colors for a lot of bike sheds
14:21 < Namegduf> All non-purple bike sheds will be burned to the ground
14:21 < Namegduf> Let the crusade begin!
14:21 <+iant> you can have any color bike shed you want, as long as it is
black
14:21 < xyproto> *korea
14:21 < kamaji> - Henry T. Jong Il
14:21 < xyproto> ;)
14:21 < aiju> programming discussions are more like
14:21 < aiju> "you shouldn't get a green bike shed, it might be mistaken for
grass by some stray cow and eaten"
14:22 < ww> aiju - that's why i want a purple one
14:22 < xyproto> aiju: hey, that can be a real problem, many parts of the
world
14:22 < Namegduf> I still say we should just shoot the giant shed eating
cows.
14:22 < skelterjohn> i say we kill them with arrows
14:22 <+iant> now there are cows that eat giant sheds?
14:22 < aiju> purple ones will be mistaken for alien landing sites
14:22 < Namegduf> Sure.
14:22 < Namegduf> aiju: That's a feature, not a bug
14:23 < aiju> just mimicing the logic behind most syntax discussion ;P
14:23 < Namegduf> Same!
14:23 < xyproto> syntax discussion is the lifeblood of irc ;)
14:23 -!- jokoon [~jorinovsk@LMontsouris-156-26-32-176.w80-14.abo.wanadoo.fr] has
quit [Quit: Quitte]
14:24 < aiju> no, porn is
14:24 < Namegduf> Syntax discussion too.
14:24 < skelterjohn> people use irc for porn?
14:25 < aiju> ever heard of xdcc?
14:25 < nsf> how about bike construction kit?  I want templates
14:25 < skelterjohn> i mean, i know it's possible
14:25 < nsf> lol
14:25 < skelterjohn> but ...  google...
14:25 < Namegduf> skelterjohn: There are libraries for converting images
into ASCII.
14:25 < nsf> Namegduf: orly?
14:25 < nsf> :))
14:26 < Namegduf> libcaca, yes.
14:26 < skelterjohn> rule 34, i guess
14:26 < nsf> I think such an idea is older than internet
14:26 -!- pharris [~Adium@rhgw.opentext.com] has joined #go-nuts
14:26 -!- gid [~gid@220-253-156-13.VIC.netspace.net.au] has quit [Ping timeout:
260 seconds]
14:26 < aiju> porn?
14:26 < nsf> image -> ASCII
14:28 < xyproto> are there optional arguments for functions in Go?
14:28 < mpl> libaa if you fancy black and white more :)
14:29 < skelterjohn> no, but there are optional arguments for composite
literals
14:29 < skelterjohn> so you can do something similar
14:29 < nsf> xyproto: in python sense, no
14:29 < nsf> but in C sense, yes
14:29 < skelterjohn> nsf: ?
14:29 < nsf> there are optional argument lists
14:30 < nsf> func X(args ...interface{})
14:30 < skelterjohn> oh
14:30 < skelterjohn> that's var args
14:30 < nsf> optional argument lists
14:30 < nsf> :)
14:30 < nsf> or wait
14:30 < nsf> it's alone
14:30 < nsf> optional argument list
14:30 < nsf> (at the end)
14:30 < nsf> :D
14:30 < skelterjohn> but you can't have a function that works both as
func(int, byte) and func(int, byte, int)
14:31 < skelterjohn> grr, sure you can
14:31 < nsf> uhm..
14:31 < nsf> yes
14:31 < Namegduf> You can but you have to curry it
14:31 < skelterjohn> func (int, byte) and func( byte )
14:31 < skelterjohn> can't do that
14:31 < nsf> you can too :)
14:31 < skelterjohn> can not
14:31 < nsf> but it will be a dynamic dispatch inside
14:31 < skelterjohn> the var args has to be the last one
14:31 < Namegduf> Oh, I was thinking in terms of types.
14:31 < skelterjohn> =p
14:31 < Namegduf> The solution for simple cases is to not use optional
arguments, generally.
14:31 < nsf> skelterjohn: func X(args ...interface{})
14:32 < nsf> and then check whether args[0] is byte or int
14:32 < Namegduf> Passing a nil or a 0 or whatever explicitly is normal.
14:32 < skelterjohn> that is not a useful way to do things
14:32 < nsf> no
14:32 < nsf> in fact don't do that!
14:32 < Namegduf> If you have a *lot* of optional arguments, varargs or a
struct are the solution.
14:32 < nsf> but it is possible :)
14:32 < skelterjohn> but you can make a struct for parameters
14:32 < skelterjohn> and only fill some of them with a composite litera
14:32 < skelterjohn> l
14:33 < Namegduf> Some languages encourage heavy use of optional arguments
to avoid giving nils or 0s
14:33 < Namegduf> Just don't do that, in Go.
14:33 < xyproto> ok, so "def add(x=2, y=4):" is best translated like "func
add(x, y int) {", where they are set to 2 and 4 if they are nil in the function?
14:33 < Namegduf> But in cases with lots of optional stuff...  yeah.
14:33 < nsf> don't do python in Go!
14:33 < Namegduf> No.
14:33 < skelterjohn> xyproto: don't do that :)
14:33 < skelterjohn> because 0 and 0 are valid int values
14:34 < Namegduf> It's best translated as func add(x, y int) { ...  } in
which you *explicitly use 2 and 4 when you mean it*.
14:34 < skelterjohn> unless you are talking about passing interfaces...
14:34 < Namegduf> And ints cannot be nil.
14:34 < skelterjohn> and then you lose all of go's nice type safety
14:34 < xyproto> ok :)
14:34 < Namegduf> Only pointers, slices, interfaces, and maps are nill.
14:34 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts
14:34 < Namegduf> Go does not have optional arguments, and the default
solution is to specify them all when using the function.
14:34 < nsf> I like how Rob Pike tricked everyone into thinking
14:34 < nsf> that Go is both dynamic and static
14:34 < Namegduf> *nil
14:34 < xyproto> so, passing a map instead, would that be acceptable?  A map
that could or could not contain the values x=2 and y=4 ?
14:35 < aiju> xyproto: the overhead is enormous
14:35 < Namegduf> No, it wouldn't, it'd be hideous and slow.
14:35 < aiju> both typing and runtime overhead
14:35 < Namegduf> Just *explicitly pass 2 and 4 when using it*.
14:35 < Namegduf> It's that simple.
14:35 < xyproto> ok, so basically, in regards to default values for
functions: just don't do it?
14:35 < Namegduf> Yes.
14:35 -!- femtoo [~femto@95-89-249-242-dynip.superkabel.de] has joined #go-nuts
14:35 < xyproto> ok.  But I will miss them.
14:35 < aiju> or define a second function
14:36 < xyproto> aiju: that's a good point
14:36 < Namegduf> A second function can work, but complicates your API, so
should only be used where a big gain
14:36 < Namegduf> The stdlib seems to avoid such
14:36 < xyproto> one can create a factory function that creates pre-curried
functions :P
14:36 -!- izaki [~lbivens@ool-44c688f2.dyn.optonline.net] has joined #go-nuts
14:37 < xyproto> like a function that returns a function that calls add with
4 and 2
14:37 < Namegduf> Only for functions with a given signature.
14:37 < aiju> yuck!
14:37 < aiju> Go is not Java
14:37 < Namegduf> Just don't do default arguments, all of this is adding way
more complexity than you're avoiding
14:37 < xyproto> aiju: is that Java-like?
14:37 < xyproto> aiju: ah, yes
14:37 < ww> for some things where defaults make sense, that get called
infrequently, i use goconfig and then process default values a bit by hand if
they're absent
14:38 -!- gid [~gid@220-253-63-193.VIC.netspace.net.au] has joined #go-nuts
14:38 < Namegduf> Use a struct, or a map, when you need to pass in any of a
large number of options
14:38 < ww> but that only makes sense for e.g.  setup of a foo that happens
once or twice based on a config file
14:38 < Namegduf> Don't use varargs for it at all, I think
14:38 < nsf> people talk too much
14:38 < xyproto> Namegduf: I like your approach
14:39 < nsf> all that time could be spent for writing add(2, 4); add(2, 4);
add(2, 4); add(2, 4);
14:39 < nsf> :)
14:39 < xyproto> nsf: :D
14:40 < nsf> and I'm pretty much serious about that
14:40 < nsf> the zen is in the middle
14:40 < nsf> sometimes it's good to do automatization
14:40 < nsf> sometimes it's much better to simply copy & paste
14:40 < nsf> or write by hand
14:40 < Namegduf> The rationale is that lack of default arguments makes it
easier to use an API; each function has one and only one form, and you can see its
full signature at any call.
14:40 < xyproto> I think teaching is a great way of learning, so I'm trying
to teach Go to a friend of mine.  I'm feeding him with daily Go Fact.  So, I'm
reminded daily of thins I don't know yet.  Hence all the questions (and talking).
14:40 < xyproto> *things
14:41 < xyproto> *Facts
14:41 < xyproto> And sorry about the typos, I'm having a bad typo-day.
14:42 < xyproto> nsf: I agree with your philosophy.  I like having the
options at hand, though.  It's nice to do things differently some times, just to
make life more interesting.
14:42 < nsf> no, it's not
14:42 < skelterjohn> yeah, pretty much it isn't
14:42 < xyproto> nsf: do you eat the same type of food every lunch?
14:43 < nsf> because it confuses other people
14:43 < skelterjohn> conformity may be bad for people
14:43 -!- rup [~rupert@deathknight.net] has quit [Read error: Operation timed out]
14:43 < skelterjohn> but it's great for code
14:43 < xyproto> but people write code
14:43 < skelterjohn> you may be happier
14:43 < skelterjohn> but your code will suck
14:43 < nsf> xyproto: imagine you go to the same cafe every day
14:43 < nsf> and order the same stuff
14:43 -!- rup [~rupert@deathknight.net] has joined #go-nuts
14:43 < Namegduf> xyproto: The most unique feature of Go is its simplicity.
Large numbers of options would pretty much remove that.
14:43 < nsf> they you'll get recognized there
14:43 < nsf> and the life will be simpler
14:44 < nsf> but if you order each time different stuff
14:44 < nsf> you'll have to order it every day
14:44 < skelterjohn> you know - 3 times a week at least i get the same damn
thing for lunch
14:44 < skelterjohn> and i still order it fully each time
14:44 < Namegduf> Go is easy to learn because there's not much of it.
14:44 < aiju> i have the same breakfast for months without caring
14:44 < ww> skelterjohn: sounds like you need a new lunch imbiss
14:44 < nsf> exactly, and fun shouldn't be about writing code
14:44 < Namegduf> More options means more things to learn, even if they
aren't used together often.
14:44 < xyproto> Namegduf: I like the simplicity of the syntax, but there
are endless posibilities for doing things in differentways
14:44 < nsf> fun should be about doing things
14:44 < nsf> that work
14:44 < aiju> doesn't make me waste time on thinking what i could eat
14:44 < Namegduf> xyproto: You can't have both.
14:45 < Namegduf> Go picks simplicity.
14:45 < Namegduf> if you want options, look at C++, which has all of them
14:45 < Namegduf> I don't think you want to go down that road
14:45 < xyproto> Namegduf: you can have both.  The programming language
brainfuck proves that.  You can have few options, but endless combinations.
14:45 < Namegduf> You have "endless combinations" in any Turing complete
language
14:45 < xyproto> Namegduf: exactly
14:45 < Namegduf> It's not relevant to options in features
14:46 < nsf> in a perfect world, programming language shouldn't be noticable
at all, like in real life with natural language
14:46 < Namegduf> Nor to the complexity of the language or the simplicity of
its usage
14:46 < nsf> fun comes from communication
14:46 < nsf> not from the act of saying things
14:46 < nsf> "oh..  looks, I'm saying a _wooord_"
14:46 < nsf> look*
14:46 < skelterjohn> take the complexity out of the language - there is
plenty of room for complexity in the algorithm that the language doesn't need to
be an attention whore
14:47 < Namegduf> Yeah, better to have fun doing interesting things than
playing with a "challenging" language
14:47 < Namegduf> :P
14:47 < nsf> lol, daily dose of philosophy
14:47 < xyproto> nsf: I like your story about simplicity, but I think a top
priority should be not to stagnate.  And fun does not come from communication, see
"nagging".
14:47 -!- skelterjohn [~jasmuth@c-68-46-33-145.hsd1.nj.comcast.net] has quit
[Quit: skelterjohn]
14:47 < xyproto> xyproto: communication can be fun, or not
14:47 < nsf> fun is always somewhere "above" the langauge, langauge is just
a tool
14:48 < nsf> it should help you do things and be invisible
14:48 < nsf> if possible
14:48 < xyproto> nsf: I think fighting simplicity should be above fun
14:48 < xyproto> nsf: it's just more important to not stagnate
14:48 < nsf> uhm..  why do you need to fight simplicity?
14:49 < xyproto> nsf: of course, it depends on your defintion, but some
forms of simplicity removes depth
14:49 < xyproto> nsf: like 1-bit colors instead of 24-bit.
14:49 < aiju> stupidity is not simplicity
14:50 < nsf> ok, I don't get your idea
14:50 < Namegduf> It does depend on the definition being used.
14:50 < nsf> anyways
14:50 < Namegduf> That isn't the definition used here.
14:50 < nsf> just do stuff, don't think about the language
14:51 -!- rup [~rupert@deathknight.net] has quit [Ping timeout: 248 seconds]
14:51 < nsf> language is like a hammer, it's fucking boring..  its shape,
its color, its purpose is fucking boring
14:51 < nsf> but it allows you to do stuff :)
14:51 < nsf> so..  just do
14:51 < Namegduf> I think the key part is that a language being simpler to
use makes it easier to read, easier to maintain, and easier to write new
algorithms in and design with.
14:51 < Namegduf> If you, personally, feel that it makes it less "fun", then
it doesn't override those concerns
14:52 < xyproto> Having a horrible or perfect hammer makes a huge
difference, though
14:52 < Namegduf> Because your idea of fun is purely a personal one, not
shared by everyone else.
14:52 < nsf> xyproto: but even if it's perfect, it's boring
14:52 < xyproto> Namegduf: who's idea of fun is not a personal one?
14:52 < Namegduf> No one's.
14:53 < xyproto> ok, in any case.  Regardless of hammers, bike sheds,
lunches, simplicity and fun.  I like the Go syntax and thanks for clearing up the
optional arugment-stuff.
14:53 < nsf> you know if you think too much about the language and have fun
playing with it, you can write books like "modern C++ programming" and fuck
people's brain
14:54 < xyproto> Thanks for the philosophical thoughs as well.  :)
14:54 < nsf> it's something to do in this life too..
14:54 < nsf> but I think it's not the best activity for a _true_ programmer
:)
14:56 < xyproto> only really autistic programmers are true programmers ;)
14:56 < nsf> also, I think it's funny that this kind of zen comes from
horrible languages which basically say: "think about me!  play with me!  have fun
with me!!  doing stuff is boring, dance with me!"
14:57 < nsf> and then you realizes, that..  "hey, it's language is bad,
because it's just a too much of a language there"
14:57 < nsf> realize*
14:57 -!- DerHorst [~Horst@e176124012.adsl.alicedsl.de] has joined #go-nuts
14:57 < Namegduf> "You're too fat to dance with, you'll crush me."
14:58 < nsf> it's actually very tempting to dig in C++'s template meta
programming crap, but if one understands the whole picture, that temptation can be
easily ignored
14:58 < xyproto> I agree.  Simplicity in that regard is a great asset for a
programming language.
14:58 < xyproto> And something worth striving for.
14:59 -!- shvntr [~shvntr@113.84.150.52] has quit [Read error: Operation timed
out]
14:59 < nsf> the main point that we shouldn't forget, that computers _are_
tools and everything within them as well
14:59 -!- m4dh4tt3r [~Adium@c-69-181-223-245.hsd1.ca.comcast.net] has joined
#go-nuts
14:59 < nsf> well, maybe it's a toy for somebody as well
14:59 < nsf> but here should be a clear difference
15:00 < nsf> you're playing or doing something useful
15:00 < nsf> and btw, if you want to play, playing games are much more fun
:)
15:00 < nsf> is*
15:00 * ww just got off the phone with three.co.uk who have talked themselves down
from £35/month to £20/month + htc handset.
15:00 < nsf> anyways..  I'm stopping here
15:00 * ww starts thinking about go arm cros compiler
15:01 -!- _DerHorst_ [~Horst@e176096102.adsl.alicedsl.de] has joined #go-nuts
15:01 -!- iant [~iant@216.239.45.130] has quit [Quit: Leaving.]
15:04 -!- DerHorst [~Horst@e176124012.adsl.alicedsl.de] has quit [Ping timeout:
255 seconds]
15:05 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
15:07 -!- jbooth1 [~jay@209.249.216.2] has joined #go-nuts
15:08 -!- _Horst_ [~Horst@e176125020.adsl.alicedsl.de] has joined #go-nuts
15:09 -!- visof [~visof@unaffiliated/visof] has quit [Quit: Leaving]
15:11 -!- _DerHorst_ [~Horst@e176096102.adsl.alicedsl.de] has quit [Ping timeout:
255 seconds]
15:13 -!- iant [~iant@nat/google/x-ogrxszvlzcstrpjd] has joined #go-nuts
15:13 -!- mode/#go-nuts [+v iant] by ChanServ
15:14 -!- boscop_ [~boscop@g226231181.adsl.alicedsl.de] has joined #go-nuts
15:17 -!- boscop [~boscop@f055163136.adsl.alicedsl.de] has quit [Ping timeout: 246
seconds]
15:18 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 276 seconds]
15:22 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has joined #go-nuts
15:23 < nsf> http://pastie.org/1678956
15:23 < nsf> that's how I see generics in my language
15:23 < nsf> generally speaking as a form of AST macros
15:23 -!- imsplitbit [~imsplitbi@64.39.4.132] has joined #go-nuts
15:25 < nsf> I think it's the most practical way to do that
15:25 < skelterjohn> void type?
15:26 < nsf> yes
15:26 < nsf> I'm C compatible, there will be a void pointer type
15:26 < nsf> (my lang will have pointer arithmetic)
15:26 < ww> your lang also has lots of semicolons
15:27 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
15:27 < nsf> at the moment, yes
15:27 < nsf> there will be an optional automatic semicolon insertion mode
15:27 < ww> not that that's a bad thing...  i'm switching back and forth
between c and go and python today and putting brackets and semicolons in all the
wrong places
15:28 -!- shakesoda [~colby@c-67-168-136-89.hsd1.wa.comcast.net] has quit [Quit:
shakesoda]
15:28 < nsf> at the moment it's just much easier for me that way
15:28 < nsf> I test a lot with: echo '...' | ./mycompiler
15:29 -!- _DerHorst_ [~Horst@e176108005.adsl.alicedsl.de] has joined #go-nuts
15:29 < nsf> anyways, I think that kind of system solves ugly problems:
15:29 < nsf> 1.  explicit inlining solves the instantiation problem
15:30 < nsf> 2.  plus explicit inlining provides an easy way to bloat your
code..  so don't write a lot of templated stuff :)
15:30 -!- _Horst_ [~Horst@e176125020.adsl.alicedsl.de] has quit [Ping timeout: 248
seconds]
15:30 < nsf> 3.  templates source code is packed and in binary form is
transfered between packages (serialized AST)
15:30 < nsf> I don't think it will affect compilation speed a lot
15:31 < skelterjohn> so if go wanted to do it this way, it would mean
including the AST in the .a file
15:31 < nsf> yes
15:31 < skelterjohn> which is an interesting approach
15:31 < nsf> I think it's the only practical approach
15:31 -!- _Horst_ [~Horst@e176125188.adsl.alicedsl.de] has joined #go-nuts
15:31 < nsf> template like C's macros, but type safe
15:31 < skelterjohn> i kind of like it
15:31 < nsf> templates*
15:31 < nsf> of course there are additional things to consider
15:31 < nsf> like varargs
15:32 < nsf> and other details
15:33 -!- luruke [~luruke@151.53.46.195] has joined #go-nuts
15:33 -!- DerHorst [~Horst@e176113042.adsl.alicedsl.de] has joined #go-nuts
15:33 -!- _DerHorst_ [~Horst@e176108005.adsl.alicedsl.de] has quit [Ping timeout:
255 seconds]
15:34 < nsf> oh, well, there is a mistake in syntax
15:34 < nsf> method form should be:
15:35 < nsf> or..  uhm..
15:35 < nsf> TBD :)
15:35 < nsf> but it's incorrect a little bit
15:35 < nsf> something like:
15:35 -!- ymasory [~ymasory@c-76-99-55-224.hsd1.pa.comcast.net] has quit [Quit:
Leaving]
15:35 < nsf> func (v[T] *Vector) ..
15:35 < nsf> more likely
15:35 < nsf> or not
15:36 < nsf> I don't know )
15:36 -!- _Horst_ [~Horst@e176125188.adsl.alicedsl.de] has quit [Ping timeout: 255
seconds]
15:36 < nsf> because *Vector[T] is a valid type and nothing says it's a
template
15:36 < nsf> T could be a valid type
15:37 < nsf> on the other hand <ident>[<type>] signals that this
is a template
15:37 -!- Paradox924X [~Paradox92@vaserv/irc/founder] has quit [Ping timeout: 255
seconds]
15:37 < nsf> there will be more problems with that in arg lists
15:37 < nsf> hm..
15:37 < nsf> but I'll figure something out
15:37 -!- Paradox924X [~Paradox92@c-68-35-229-34.hsd1.fl.comcast.net] has joined
#go-nuts
15:38 -!- PJ_Robins [~finn@174-20-67-7.mpls.qwest.net] has joined #go-nuts
15:39 < nsf> ah!
15:39 < nsf> func (v *Vector[T]) Append[T](e T)
15:39 < nsf> a lot of Ts
15:39 < nsf> but correct )
15:39 < nsf> technically I think first one can be omitted
15:39 < nsf> func (v *Vector) Append[T](e T)
15:39 < nsf> hm..
15:42 < nsf> and I don't have templated consts, so no metaprogramming
15:42 < nsf> hahaha
15:44 -!- gid [~gid@220-253-63-193.VIC.netspace.net.au] has quit [Quit: Leaving.]
15:47 < wrtp> nsf: what about providing a special form for type parameters?
15:47 < nsf> uhm?
15:47 < nsf> type parameters?
15:47 -!- binarypie [~binarypie@adsl-99-35-135-146.dsl.pltn13.sbcglobal.net] has
joined #go-nuts
15:47 < wrtp> like the T in Vector above
15:48 < nsf> but <ident>[<type>] is a special form
15:48 < ww> did closed make it out of release or is it only absent in the
new weeklies?
15:48 < wrtp> but the [T] is often redundant
15:48 < wrtp> e.g.  func[T](x T)
15:48 -!- luruke [~luruke@151.53.46.195] has quit [Quit: Leaving]
15:48 < wrtp> you could have func(x 'T) instead
15:49 < wrtp> where 'T introduces a new type parameter
15:49 < nsf> hm..
15:49 < nsf> an interesting point
15:49 < wrtp> that's the way ML does it, for example
15:49 < nsf> yeah, I'll definitely think about it
15:50 < nsf> this syntax in the example is just a first thing came to mind
15:50 < nsf> it's somewhat like D's
15:50 < nsf> D uses name!(type)
15:50 < wrtp> func (v *Vector['T]) Append(e 'T)
15:50 < nsf> no
15:51 < nsf> func (v *Vector) Append(e 'T)
15:51 < nsf> is enough
15:51 < wrtp> i don't think so
15:51 < nsf> you see at the moment of type resolving compiler will see that
Vector is a template
15:51 < nsf> ah..  yes, you're right
15:51 < nsf> func (v *Vector) Size() int
15:51 < nsf> oops
15:51 < nsf> :D
15:51 < nsf> yeah, it's required there
15:52 < nsf> on the other hand
15:52 < nsf> it's not
15:52 < nsf> you see, in:
15:52 < wrtp> it's required there only if you want to use T inside the body
of the function
15:52 < skelterjohn> does it not make sense to have a template type be
associated with the whole package, rather than a struct or function?
15:52 < nsf> func (v *Vector) Append(e 'T)
15:52 < nsf> T is not a new type here
15:52 < wrtp> skelterjohn: both
15:52 < nsf> T name should match the T in Vector's definition
15:52 < wrtp> nsf: i think it is
15:53 < wrtp> i don't think that would be good
15:53 < nsf> it will be good
15:53 < wrtp> func (v *Vector) Append(e v.T)
15:53 < wrtp> would be better
15:53 < nsf> for example: type Vector { data *'Element; }
15:53 < nsf> func (v *Vector) Append(e 'Element)
15:53 < wrtp> then it's obvious that T comes from the scope of Vector
15:53 < nsf> you see, these ' should match
15:54 < nsf> it's a separate namespace
15:54 < wrtp> nsf: yeah, i don't think that's good, because it means that a
single type can drag in loads of names
15:54 < nsf> for template types inside a struct/methods
15:54 < nsf> wrtp: uhm..  it won't be
15:54 < wrtp> it's not really a separate name space, because you're going to
need to refer to those types inside the body of the function
15:55 < nsf> but ' <- this thing says..  look into a namespace
15:55 < nsf> but ok, there are cases where you need template methods
15:55 < wrtp> func (v *Vector) AppendList(e v.Element, list
*List['v.Element])
15:56 < nsf> and name could clash
15:56 < nsf> names*
15:56 < nsf> yeah, something like that
15:56 < nsf> maybe even "e 'v.Element"
15:56 < wrtp> func Swap(x 'X, y 'Y) ('Y, 'X)
15:56 < wrtp> what namespace are those looking into?
15:57 < nsf> function's
15:57 < nsf> func is a separate namespace
15:57 < nsf> struct + methods is another
15:57 < wrtp> i think you only need the ' prefix when you're introducing a
new type
15:58 < nsf> no, it's referring to a template parameter
15:58 < nsf> which can be a type
15:58 < nsf> or a value O_o
15:58 < nsf> hm..
15:58 < nsf> I need to consider that as well
15:58 < nsf> anyways, I'll think about the syntax later
15:58 < nsf> at the moment I need to implement the C subset
15:59 < nsf> but I like your idea, even if I don't understand it fully
15:59 < nsf> and I remember in C++ there is another potential issue, for
which keyword 'typename' exists
16:00 < wrtp> func Reduce(x []'T, f func(a, b 'T) 'T) { var y T = x[0]; for
_, x := range x[1:] { y = f(y, x) }; return y}
16:00 < wrtp> note that it's only named 'T in the header of the function
16:00 < wrtp> inside the function you can just use plain T
16:00 < nsf> func Reduce(x []'T, f func(a, b 'T) 'T) { y := x[0]; for _, x
:= range x[1:] { y = f(y, x) }; return y}
16:00 < nsf> :)
16:01 < wrtp> yeah, but i wanted to show an example of using a type inside
the body
16:01 < nsf> hm..  but yeah
16:01 < nsf> good point
16:01 < nsf> function starts with a new scope
16:01 < nsf> and there will be a type defined in that scope
16:01 < wrtp> skelterjohn has a good point though - global variables are
difficult
16:02 < nsf> oh, I've missed his message completely :)
16:02 < wrtp> type Foo struct { A 'T; B func() 'T }
16:02 < nsf> maybe, who knows
16:02 < nsf> (it was the answer to skelterjohn's question)
16:03 < nsf> templated package!  :)
16:03 < nsf> sounds scary though
16:03 < wrtp> if you don't do package type parameterisation, then you can't
store generically defined variables in global variables safely
16:03 -!- ronnyy [~quassel@p4FF1C6BC.dip0.t-ipconnect.de] has quit [Remote host
closed the connection]
16:04 < wrtp> Foo<T: int>
16:04 < nsf> uhm..
16:04 < nsf> why?
16:05 < nsf> ah, well, I think it makes sense to restrict that
16:05 < nsf> in fact
16:05 < wrtp> because if you don't name the type parameters explicitly,
there's no inherent declaration order
16:05 < nsf> I think it makes sense to restrict everything as much as
possible :)
16:05 < wrtp> so you need to say which type parameter is associated with
which type
16:06 < jumzi> If i can't break my computer, it ain't a computer
16:06 < nsf> I think storing generics vars in global vars is a no-no
16:06 < wrtp> the major difficult thing is to integrate type parameters with
interfaces
16:07 < nsf> wrtp: how about saying no-no to everything which is hard?  :)
16:07 < wrtp> if you haven't got a coherent model for how type params work
with interfaces, then the language won't work
16:07 < wrtp> (although in general i agree)
16:07 < nsf> my basic requirement is to allow simple container types like
Vector and simple generic functions like Min/Max
16:08 < nsf> everything else is a big question
16:08 < wrtp> if you can't store generics in global vars, then you can't do
caching, for example
16:08 < nsf> but I realize that I do need some form of generics
16:09 < nsf> frankly I'm writing my compiler in C++ because it has
std::vector and std::unordered_map
16:09 < nsf> :)
16:10 < nsf> otherwise I would go with C
16:10 < nsf> so..  at least containers are important
16:10 < nsf> built-in types..  uhm..  no
16:11 < nsf> ok, back to work
16:13 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 240 seconds]
16:13 -!- binarypie [~binarypie@adsl-99-35-135-146.dsl.pltn13.sbcglobal.net] has
quit [Remote host closed the connection]
16:14 -!- binarypie [~binarypie@adsl-99-35-135-146.dsl.pltn13.sbcglobal.net] has
joined #go-nuts
16:14 -!- binarypie [~binarypie@adsl-99-35-135-146.dsl.pltn13.sbcglobal.net] has
quit [Remote host closed the connection]
16:17 -!- DerHorst [~Horst@e176113042.adsl.alicedsl.de] has quit [Remote host
closed the connection]
16:17 < steven> guys, is the postgres package goroutine-safe?
16:17 < steven> (the good one)
16:17 < steven> https://github.com/jbarham/pgsql.go
16:22 -!- foocraft [~dsc@78.100.168.186] has quit [Quit: Leaving]
16:24 -!- binarypie [~binarypie@adsl-99-35-135-146.dsl.pltn13.sbcglobal.net] has
joined #go-nuts
16:25 -!- binarypie [~binarypie@adsl-99-35-135-146.dsl.pltn13.sbcglobal.net] has
quit [Remote host closed the connection]
16:25 -!- Paradox924X [~Paradox92@c-68-35-229-34.hsd1.fl.comcast.net] has quit
[Changing host]
16:25 -!- Paradox924X [~Paradox92@vaserv/irc/founder] has joined #go-nuts
16:25 -!- binarypie [~binarypie@adsl-99-35-135-146.dsl.pltn13.sbcglobal.net] has
joined #go-nuts
16:25 -!- binarypie [~binarypie@adsl-99-35-135-146.dsl.pltn13.sbcglobal.net] has
quit [Remote host closed the connection]
16:27 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has quit [Quit:
Computer has gone to sleep.]
16:28 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has quit [Quit:
Leaving]
16:29 < nsf> adg: thanks for clarification in the blog post, awesome scheme
16:29 < nsf> I will support gocode project on a 'release'-basis
16:30 < nsf> instead of a 'weekly'
16:30 < nsf> but on the other hand
16:31 < nsf> I think 'weekly' is redundant
16:31 < nsf> because what is week anyway..  anyone who wants to follow the
tip will do so
16:31 < nsf> but 'release' is good for people who maintain apps and
libraries
16:32 < nsf> just my opinion
16:32 < ww> but...  why on earth is release just before an incompatible
change?
16:32 < skelterjohn> to give people more time to fix that change?
16:33 -!- binarypie [~binarypie@adsl-99-35-135-146.dsl.pltn13.sbcglobal.net] has
joined #go-nuts
16:33 < nsf> ww: but why do you care?
16:33 < nsf> just use release :)
16:33 < nsf> tip is for Go developer mainly I think
16:33 < nsf> 'release' should be for everybody else
16:33 < nsf> developers*
16:33 < skelterjohn> i think that having a lot of people use tip helps find
bugs
16:33 < ww> can't use release because of scheduler problems that were afaik
fixed the day after
16:33 < skelterjohn> because of that, i use tip, and report bugs when i find
them
16:34 < nsf> skelterjohn: and they complain a lot that my app or lib doesn't
work
16:34 < skelterjohn> ww what problem?  just curious
16:34 < ww> it was manifesting as panics when the memory allocator tried to
free blocks more than once...
16:34 < nsf> but I, as a maintainer cannot follow tip simply
16:34 < ww> lemme find the specific changeset
16:34 < skelterjohn> nsf: you can if you do versioning
16:34 < skelterjohn> of course, there is no universally accepted way to do
versioning
16:35 < ww> 7670:a45a5a3e3458
16:35 < nsf> no you see, 1.  I'm not interested
16:35 < skelterjohn> that doesn't mean you can't
16:35 < nsf> 2.  it's good to have a common point between every developer
16:35 < nsf> ok, yes, I can
16:35 < nsf> but I don't want to
16:35 < skelterjohn> ok
16:35 < ww> like...  immediately after the stable
16:35 < skelterjohn> probably because it's a pain
16:36 < skelterjohn> it would be nice if you could just do "git
freeze-this-version-for-release" when a release is made
16:36 < skelterjohn> and make it easy for people who only update to release
to stick to that version
16:36 < nsf> but I don't use tip at all :)
16:36 < nsf> Go's tip I mean
16:36 < skelterjohn> ok, that's fine
16:36 < skelterjohn> replace "you" with "I"
16:36 < skelterjohn> because i would like to do this :)
16:37 -!- binarypie [~binarypie@adsl-99-35-135-146.dsl.pltn13.sbcglobal.net] has
quit [Ping timeout: 246 seconds]
16:37 < ww> i don't mind this new strategy at all...  just think the first
"release" chose a bad revision
16:37 < nsf> yeah, it's a nice compromise
16:38 < nsf> some devs would like to base their projects on weekly basis
16:38 < nsf> others on release basis
16:38 < nsf> and end users will have to use release anyway
16:38 < nsf> :D
16:38 < nsf> then it's not a nice compromise
16:38 < nsf> hm..
16:39 < skelterjohn> i wonder if it would make sense to tie versions of
libraries to the version of the compiler
16:39 < skelterjohn> probably not
16:41 < nsf> I think that won't be an issue in future
16:41 < nsf> Go will become even more stable eventually
16:42 < nsf> and pretty much everything will be compatible on a source level
16:43 < skelterjohn> versioning is still an important issue
16:43 < skelterjohn> but i agree with your point about go stability
16:43 < nsf> maybe it is important
16:43 < nsf> nothing is important to me, hahaha
16:43 < nsf> :D
16:43 < skelterjohn> nsf the nihilist
16:44 < czr_> silly q: is there a PPA for ubuntu with 6g that anyone could
recommend?  or should I just bite the bullet and pull the newest from VCS?
16:44 < exch> I suppose it could be worth it to tag package commits with the
Go version it was meant for
16:44 < nsf> skelterjohn: it's not like nihilism
16:44 < skelterjohn> czr_: yes - niemeyer has one
16:44 < nsf> everything is here, but nothing matters
16:44 < nsf> hm..
16:45 < nsf> well, ok, let's stop that in the beginning
16:45 < nsf> another philosophycal topic
16:45 < czr_> skelterjohn, thanks, found it.
16:45 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts
16:45 < skelterjohn> wow, that was enough information?  :)
16:45 < czr_> I have a special relationship with google
16:45 < skelterjohn> heh
16:45 < czr_> "go ppa niemeyer"..
16:45 < nsf> )
16:46 < skelterjohn> what's a ppa, btw
16:46 < skelterjohn> i only had an answer because niemeyer had mentioned it
in the mailing list
16:46 < czr_> private package archive
16:46 < czr_> basically a repository for apt that someone else maintains
(not the distro)
16:47 < skelterjohn> cool
16:47 < czr_> canonical also provides build-services for that, so that
packages can be automatically built for multiple archs and all that
16:47 < czr_> but that's about the level that I know of the details :-).
16:47 < skelterjohn> czr_: I think it's better to use VCS, though, if you
are up to it
16:48 < czr_> I'd rather have old but stablish binaries than newest but
"doesn't even build all the time" binaries :-).
16:48 < czr_> but I'll look and see, I've yet to write a hello world
16:48 < czr_> (I pull a lot of stuff from upstream VCSes at work, and don't
really want to bring the same levels of frustration to home :-).
16:49 < skelterjohn> czr_: what you get from "hg pull -u" is very good at
building
16:49 < czr_> no breakage?
16:49 < skelterjohn> i use tip and i have not had any problems
16:49 < czr_> how often do you pull?
16:49 < skelterjohn> they're pretty careful and have an extensive test suite
16:49 < skelterjohn> once every two weeks or so
16:49 < skelterjohn> or when a new change is mentioned
16:49 < czr_> I'll keep that in mind.
16:50 < niemeyer> czr_: Yeah, the ppa has been maintained up-to-date
16:50 < czr_> oh heh.  seems that the PPA doesn't have golang for lucid..
16:51 < niemeyer> czr_: That's something I was thinking about today..  I
should fix it
16:51 < niemeyer> czr_: You can also try the golang-weekly package now, even
though that hasn't been announced yet
16:51 < niemeyer> czr_: Still suffering with building the arm packages, but
you probably don't care about that
16:51 < czr_> no golang-weekly either according to apt-cache..
16:51 * czr_ goes and digs around..
16:52 < niemeyer> czr_: If you're in Lucid, yeah, neither are available
16:52 < czr_> ah, you only build for maverick
16:52 * czr_ nods
16:52 < niemeyer> czr_: Let me push the stable one for Lucid
16:52 < czr_> oh, sure.  thanks
16:52 < niemeyer> czr_: Supposedly, it should just work
16:52 < czr_> I'
16:52 < nsf> adg: ah!  also a nice idea..  golang-announce mailing list
16:52 < czr_> oops.  I've heard that before :-).
16:52 < skelterjohn> niemeyer: how does goinstall work with the
distributions from your ppa?
16:53 < nsf> for those who don't want to see shit loads of messages
16:53 < nsf> I'd like to be able to receive release/projects announce
messages only :)
16:53 < niemeyer> skelterjohn: Poorly..  goinstall itself is being fixed
16:54 < skelterjohn> would sudo goinstall work?
16:54 < czr_> is goinstall something like easy_setup for python?
16:54 < czr_> easy_install even.
16:54 < niemeyer> skelterjohn: No, not right now
16:55 < skelterjohn> czr_: goinstall is something that downloads projects
from VCS and builds them locally
16:55 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
16:55 < skelterjohn> almost all 3rd party libraries are installed via
goinstall
16:55 < niemeyer> czr_: It is, yeah
16:55 < skelterjohn> for that reason alone it might be worth installing go
from vcs
16:55 < niemeyer> czr_: But better..  ;-)
16:55 < czr_> hmm.  but I want to reinvent wheels!
16:56 < czr_> but ok, I'll do the VCS way then
16:57 < niemeyer> czr_: That's a better way for the moment indeed
16:57 * czr_ nods
16:57 < czr_> niemeyer, do you actively test the armel version or is it just
for building-testing?
16:57 < niemeyer> czr_: I actively test it because building runs the full
test suite
16:58 < czr_> heh, bad wording on my part.  do you use it on arm yourself?
:-)
16:58 < niemeyer> czr_: No, today I don't
16:58 < ww> is it possible to have a const array?
16:58 < skelterjohn> ww: I don't think so
16:58 < niemeyer> ww: No
16:58 < nsf> it's possible to have a function
16:59 < nsf> that acts like a const array
16:59 < nsf> :D
16:59 < ww> pity...  no problem, just populate it in init() i guess
16:59 < skelterjohn> nsf: just like it's possible to have a non-const array
that acts like a const array
16:59 < niemeyer> ww: Well..  you can have a variable array :-)
16:59 < skelterjohn> ww: you can do var MyList = []Type{item1, item2, item3}
in global space
16:59 < nsf> var MyList = [...]Type{item1, item2, item3}
16:59 < nsf> that's an array
17:00 < nsf> skelterjohn proposes a slice
17:00 < skelterjohn> the difference, here, is not meaningful
17:00 < skelterjohn> either way will use memory, where a const array would
not
17:01 < ww> right.  not so concerned with memory for 4 bytes
17:01 < ww> (hmmm....  uint32 + unsafe) :P
17:04 -!- femtoo [~femto@95-89-249-242-dynip.superkabel.de] has quit [Read error:
Connection reset by peer]
17:04 < skelterjohn> i think a syntax like: const x = []{something1,
something2, something3}
17:04 < skelterjohn> would make sense
17:05 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has joined #go-nuts
17:05 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has left #go-nuts []
17:05 < skelterjohn> though i guess the utility is not high enough to
justify the feature addition
17:05 < czr_> net.TestGoogleSRV fails during build
17:05 < czr_> or tests rather.
17:05 < skelterjohn> DISTABLE_NET_TESTS=1 ./all.bash
17:06 < skelterjohn> disable
17:06 < skelterjohn> not distable
17:06 < czr_> hmm.  all.bash rebuilds everything again?
17:06 < skelterjohn> yep
17:06 < skelterjohn> you could just go into src/pkg and run make, i think
17:07 < czr_> yeah, I recognize it's using make underneath.  is there
support for -j from top-level script?
17:07 < skelterjohn> is that parallel making?
17:07 < czr_> yes
17:07 < skelterjohn> yes, that works
17:08 < czr_> my compiler is 6g!
17:08 < skelterjohn> hooray!
17:08 < czr_> damn, it's like twice 3G I have on my phone.
17:08 * czr_ celebrates
17:09 < skelterjohn> it is a pretty fast compiler, yeah
17:09 < czr_> I hope it's less buggy than 3g though :-)
17:09 < czr_> btw, where does the naming convention originate from?  (plan 9
yes, but what's the rationale behind it, comparing to say 'gcc' for all archs?)
17:10 < czr_> just curious, not poking for a flame war.
17:10 < skelterjohn> to make it easy to cross-compile
17:10 < skelterjohn> i can build for arm on my amd64 computer by using 5g
instead of 6g
17:10 < skelterjohn> go tries to limit the amount of compiler options
available
17:10 < czr_> ah, makes sense
17:10 < skelterjohn> so we do this instead of saying gc -target-arm
17:11 < czr_> but how would you go about doing a canadian cross?
17:11 < skelterjohn> tell me what a canadian cross is, first
17:11 < skelterjohn> <- not a prolang expert
17:11 < pharris> skelterjohn: Cross compiling the compiler.
17:11 < skelterjohn> i don't know
17:11 < pharris> So building a 5g that runs on Sparc from your AMD64 box.
17:11 < czr_> for example.
17:11 < skelterjohn> right, i understand
17:12 < skelterjohn> i just don't know how to do that :)
17:12 < pharris> (Not that Go really supports more than two CPUs at the
moment)
17:12 < czr_> also, there is a limited number of digits available too.
17:12 * czr_ hides & runs
17:12 < skelterjohn> the number of target architectures is also limited
17:12 < czr_> ok, but the crossing thing is a sane enough reason.
17:12 < steven> any of you used this?  https://github.com/jbarham/pgsql.go
17:12 < skelterjohn> though...  the number of numbers is not
17:12 < skelterjohn> we can just to 10g :)
17:12 -!- piranha [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts
17:13 < skelterjohn> not me, steven
17:13 < czr_> skelterjohn, yeah, I think you'll have to skip 10g though ;-).
17:13 < skelterjohn> something interesting about 10g in particular?
17:13 < czr_> oracle.
17:14 < skelterjohn> no one cares about oracle
17:14 < skelterjohn> stone age, etc
17:14 < czr_> they have quite modern lawyers
17:14 < czr_> but IANAL and will wait for 10g eagerly then :-).
17:15 < skelterjohn> :) you'll have to settle for 6g, for now
17:15 < skelterjohn> until they start making 1024bit processors
17:16 < czr_> I wonder what would be the practical mechanism to achieve any
sane code density on a 1k-bit wide reg arch.
17:16 < czr_> LZ77 implemented in silicon maybe
17:16 < czr_> although random-accessing that would be interesting.
17:18 < steven> i just created a way to manage several Go processes through
a bash script
17:18 < steven> including starting and stopping them
17:18 < skelterjohn> unique to go processes?
17:20 < steven> nope.
17:20 < steven> but its another peice to the puzzle of creating my
rails-clone in Go
17:21 < czr_> steven, grails?
17:21 < skelterjohn> i'm still curious about what rails provides that you
think is especially useful
17:21 < steven> czr_: thats a groovy framework
17:21 < steven> ie already taken :(
17:21 < czr_> ah.  sad.  you could call it Grails!  then.  /me hides & runs
17:21 < steven> heh
17:22 < skelterjohn> or "Let's Grails!"
17:22 < steven> but yeah, i think that Go would solve a lot of the scaling
issues people have with rails, while maintaining the rapid-development advantage
17:23 < czr_> g = compiler, l = linker?
17:23 < steven> probably
17:23 < skelterjohn> yes
17:23 < czr_> hmm.  lucid's file doesn't have magic for .6 files.
17:23 < skelterjohn> 6g, 6l, compiler and linker
17:23 < czr_> is there a static header for go compiler generated "object"
files (or whatever they are)..
17:24 < skelterjohn> .6 files have a human-readable header
17:24 < skelterjohn> but header is the wrong way to think about it
17:24 < skelterjohn> it's not like a C header
17:24 < skelterjohn> there is only the .6 file, which gets packed into a .a
file
17:25 < skelterjohn> *all* information about the package is in that .a file
17:25 < czr_> oh, I mean a binary header in from of the file.  nothing to do
with cpp/C conventions in this case :-)
17:28 < czr_> hmm.  my hello world executable is now ready.  trying to
establish whether libc.a is linked together at some point, but that's proving
somewhat difficult.
17:28 < czr_> how does the 6g compiler know how to emit system calls on my
linux?
17:28 < czr_> (assuming it does not link parts of libc.a into the target go
executable)
17:29 < skelterjohn> everything links go's runtime package
17:29 < skelterjohn> go's runtime package links libc, etc
17:30 < czr_> the runtime package is built when 6g is built?
17:30 < czr_> where would I find it
17:30 < skelterjohn> runtime package is built with all.bash
17:30 < skelterjohn> go/src/pkg/runtime
17:30 < skelterjohn> for the source
17:31 < skelterjohn> go/pkg/goos_goarch/runtime for the binary
17:31 < skelterjohn> go <- $GOROOT
17:31 < czr_> dynimport _ _ libc.so.6
17:33 < czr_> hmm.  there's a separate runtime.a at arch level too
17:33 < czr_> it's much larger than the stuff under runtime/
17:34 < czr_> ok, last question before I dive into the docs.  what would you
people use to analyze the generated assembly code in say, .6 file or .a file?
17:34 < czr_> (objdump parallel)
17:34 < skelterjohn> not something i know much about
17:36 < czr_> also, my strip doesn't really like 6g generated binaries.  is
this a known issue?  complains about overlaps of sections
17:36 < skelterjohn> what's strip
17:36 < czr_> (or rather, libbfd complains about the overlaps)
17:37 < czr_> strip is a tool to remove sections from object files
17:37 < skelterjohn> the 6g/8g/5g compilers don't build the same as gcc does
17:37 < czr_> in this case, since the binary is static, I thought I could
remove some unnecessary sections from it (with strip)
17:37 < skelterjohn> the generated code has a different structure
17:37 < czr_> the executables use ld.so to load, so the structure they have
at top-level must adhere to the same ELF spec as everything else
17:38 < skelterjohn> iant is the guy to ask about this stuff
17:38 * czr_ pokes at iant
17:38 < czr_> i'll prepare a pastebin about this, sec.
17:38 <+iant> not sure I understand the question
17:39 <+iant> 6g basically generate a Plan 9 executable wrapped up in an ELF
file
17:39 <+iant> the ELF symbol table is as small as possible
17:40 < czr_> iant, http://www.pastie.org/1679401
17:40 <+iant> argh, white on black
17:40 <+iant> OK, i can change the theme....
17:41 < czr_> sry, you can switch the theme, not my choice either.
17:42 < czr_> if this is not a known issue, I can investigate some more
17:43 <+iant> It's sort of known, I just don't think anybody has ever really
cared
17:43 < czr_> even if the sections overlap (say, the sizes of the sections
are +8 bytes off), it wouldn't matter as long nothing references the out-of-bounds
area
17:43 < czr_> ah, ok.  I will not worry then :-)
17:43 <+iant> here we are: http://code.google.com/p/go/issues/detail?id=1242
17:44 < czr_> ah, so it's an open issue then
17:44 < czr_> thanks
17:44 <+iant> I guess that now that we have DWARF, it would be more useful
to get strip working
17:44 <+iant> before the DWARF debug was there, there really wasn't anything
that strip could do anyhow
17:45 < czr_> well, I'm trying to figure out ways of dropping the size of
the hello world, strip was the obvious first choice (for me).
17:45 * czr_ nods
17:45 <+iant> make sure you are using the latest release, it makes binaries
significantly smaller
17:45 < czr_> I just pulled it :-).
17:45 < czr_> I'm scared when you say that though, they were even larger
before?  :-)
17:46 < czr_> ah.  after stripping, 6.out segfaults.
17:46 < czr_> didn't try that before.
17:46 < czr_> so something breaks, it's not just inconvenience.
17:48 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the
connection]
17:50 -!- sauerbraten [~sauerbrat@p508CB63B.dip.t-dialin.net] has quit [Remote
host closed the connection]
17:52 -!- luruke [~luruke@151.53.46.195] has joined #go-nuts
17:52 -!- luruke [~luruke@151.53.46.195] has quit [Client Quit]
17:53 < czr_> hmm.  I think there's at least issue in that .rela.plt is
given a wrong address, should be +4 since .dynstr comes before that and that 4
bytes.
17:54 * czr_ digs some more
17:55 -!- dahankzter [~henrik@92-244-3-192.customers.ownit.se] has joined #go-nuts
17:56 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
17:56 -!- TheMue [~TheMue@p5DDF56D6.dip.t-dialin.net] has joined #go-nuts
18:03 -!- artefon [~thiago@dhcp26.usuarios.dcc.ufmg.br] has quit [Quit: bye]
18:04 -!- dgnorton [~dgnorton@97.65.135.100] has joined #go-nuts
18:13 -!- jyxent [~jyxent@129.128.191.96] has quit [Read error: Operation timed
out]
18:21 -!- zozoR [~Morten@563476e6.rev.stofanet.dk] has joined #go-nuts
18:27 -!- gmilleramilar [~gmiller@38.104.67.234] has joined #go-nuts
18:30 < czr_> iant, http://www.pastie.org/1679557 (the theme might be
"midnight" again, sry in advance)
18:31 < czr_> I wrote a small prog that will arrange the readelf -S output
so that it's easy to see how the elf sections will be allocated and print out info
on overlaps and other issues
18:31 < czr_> I think (not sure) that BFD/strip will also not like allocated
but zero-sized sections
18:31 <+iant> A zero-sized section is not a problem
18:31 <+iant> but I agree there are some problems there
18:31 * czr_ nods
18:31 < czr_> but BFD complains about overlaps in places where there are
none too
18:32 < czr_> I threw out those sections whose VMA is zero, since I guess
it's safe to ignore them
18:32 -!- enferex [~enferex@users.757.org] has quit [Ping timeout: 276 seconds]
18:32 <+iant> I'm not sure why BFD complains about zero-sized sections, that
seems like a BFD bug
18:32 < czr_> I don't think it's zero sized per se, but once it gets into
the mode that it finds overlaps, it seems to become more "flaky"
18:32 -!- enferex [~enferex@users.757.org] has joined #go-nuts
18:33 < czr_> for example, it complains about the .hash overlapping with
.plt, when it doesn't (there's no space between the two, but that's not an issue)
18:33 <+iant> odd
18:33 < czr_> but I'd rather drink iranian crude oil than try to read libbfd
source code at the moment
18:33 < czr_> it's one of those places which sane people do not venture.
like ISC code.
18:34 < czr_> iant, also, does it make sense to mark zero sized sections
with "allocate" flag?
18:35 < czr_> that happens for .rela.plt for example
18:35 < czr_> and .rela too
18:37 -!- femtoo [~femto@95-89-249-242-dynip.superkabel.de] has joined #go-nuts
18:38 <+iant> it doesn't make much sense but it shouldn't hurt
18:39 * czr_ nods
18:39 < czr_> I've yet to have had good reasons to delve into ELF / ld.so
details, so I might be pointing out obvious things, try not to mind :-)
18:39 <+iant> no worries
18:43 -!- dgnorton2 [~dgnorton@97.65.135.100] has joined #go-nuts
18:46 -!- dgnorton [~dgnorton@97.65.135.100] has quit [Ping timeout: 260 seconds]
18:46 < czr_> iant, if I amend the bug report about the issue with the
findings and the url to the small prog, would that be considered rude or helpful?
18:47 <+iant> helpful
18:47 <+iant> thanks
18:47 < czr_> ok, will do.
18:48 < skelterjohn> those pastebins can expire, i think
18:49 < czr_> sure, not pointing to them.
18:49 -!- ddoman [~root@96.53.63.250] has joined #go-nuts
18:49 < czr_> updated: http://code.google.com/p/go/issues/detail?id=1242
18:52 -!- dahankzter [~henrik@92-244-3-192.customers.ownit.se] has quit [Quit:
Leaving.]
18:54 -!- artefon [~thiago@189.59.162.202] has joined #go-nuts
19:00 < czr_> oki, going to actually try to do something useful next.
before that, a question: are linux-specific system calls well supported directly?
stuff like fd watches, linux specific TCP SOL-options and such..
19:00 < czr_> or will using linux-specific stuff require writing C wrappers?
19:02 < skelterjohn> wrappers
19:02 -!- fabled [~fabled@mail.fi.jw.org] has quit [Quit: Ex-Chat]
19:02 < skelterjohn> cgo, etc
19:02 * czr_ nods
19:02 < czr_> is that a design decision on trying to keep go portable?
19:02 < skelterjohn> pure go code tries to be platform independent, for the
most part
19:02 * czr_ nods
19:02 < skelterjohn> well, that and the fact that these syscalls are C
functions :)
19:03 < skelterjohn> some are supported directly through runtime and other
(cgo using) packages
19:03 < skelterjohn> the ones that aren't you can expose on your own
19:03 * czr_ nods
19:13 < niemeyer> skelterjohn, czr_: That's not accurate
19:13 < skelterjohn> what'd i miss?
19:13 < niemeyer> syscalls are technically not C functions, and Go doesn't
use C or cgo for that
19:14 < czr_> ok.  s/syscalls/libc syscall wrappers/ :-)
19:14 < skelterjohn> well, some things it uses asm for, i guess
19:14 < dgnorton2> having trouble compiling the example at ...
https://bitbucket.org/taruti/http_jsonrpc.go/wiki/Home ...  getting error message
"example.go:4: can't find import: bitbucket.org/taruti/http_jsonrpc.go"
19:14 -!- tensorpudding [~user@99.148.205.193] has joined #go-nuts
19:14 < dgnorton2> any idea what I'm doing wrong?
19:15 < skelterjohn> dgnorton2: goinstall
bitbucket.org/taruti/http_jsonrpc.go
19:15 < skelterjohn> if an import looks like a URL, it is meant to be
goinstalled first
19:15 < dgnorton2> skelterjohn, thx
19:15 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has quit [Ping timeout:
620 seconds]
19:15 < niemeyer> czr_: The point is that there's likely no reason to use
libc syscall wrappers
19:16 < skelterjohn> niemeyer: when you make a syscall from go (potentially
via .s source), does it do the same kind of thing that happens when you move from
go to C via cgo?
19:17 < steven> why is Go so fast?
19:17 < steven> is it because its compiled, or static, or what?
19:17 < skelterjohn> steven: depends on what aspect you're asking about
19:17 < skelterjohn> and what you're comparing it to
19:17 < niemeyer> skelterjohn: No, it doesn't use cgo
19:17 < steven> um, low memory usage, fast execution, etc
19:17 < steven> compared to, say, python
19:17 < steven> or ruby
19:18 < skelterjohn> niemeyer: i know, but cgo switching involves a bunch of
stuff because of the different kind of stack
19:18 -!- fabled [~fabled@83.145.235.194] has joined #go-nuts
19:18 < skelterjohn> i was just wondering if it needed to do that for
syscalls too
19:18 < skelterjohn> steven: compiled languages are generally faster than
interpreted languages
19:18 < Namegduf> steven: Mixture of reasons.
19:19 < Namegduf> Compiled means it doesn't need to JIT and doesn't have the
inefficiencies interpreters often have
19:19 < skelterjohn> go's coroutine model also allows it to be very
efficient with large amounts of goroutines in the way that you can't be with
regular threads
19:19 < Namegduf> It isn't so much "static" as "types and the operations on
them are things which can be implemented quickly"
19:20 < Namegduf> They compile into efficient machine code that manipulates
memory with little indirection or overhead that isn't visible in the source.
19:20 < niemeyer> skelterjohn: Nope
19:20 < skelterjohn> cool
19:20 < Namegduf> This also pushes programmers to write faster code, because
there's no parts of types which are actually really slow to actually work.
19:21 < Namegduf> Arrays you can delete in the middle of are an example of
that kind of problem.
19:21 < Namegduf> Do it in a loop and your program is going to run like shit
and if you're a newbie you are not going to know why.
19:21 < czr_> niemeyer, err, so how would I use fd watchers then?  you're
suggesting using asm to do the syscalls?
19:21 < Namegduf> In Go it's obvious that you're doing the copy- and in Go
you can do the shortcut which allows fast deletion at the cost of ordering.
19:21 < niemeyer> czr_: Check out src/pkg/syscall
19:22 * czr_ hugs niemeyer
19:22 < czr_> that was exactly what I was actually looking for, but was too
afraid to ask :-)
19:23 < Namegduf> Go's memory usage is actually pretty awful in comparison
to C, but better than the competition, I guess.  :P
19:23 < Namegduf> That's a GC thing, I think.
19:23 < Namegduf> Comparing it to Java you get a dramatic win on Go's side,
for example.
19:24 -!- PortatoreSanoDiI [~Marvin@dynamic-adsl-94-36-180-250.clienti.tiscali.it]
has joined #go-nuts
19:24 < niemeyer> czr_: ;)
19:25 < czr_> niemeyer, am I correct to think that infact, 6g/6l technically
have no reason to link against libc.a (for the produced go executable)?
19:25 < Namegduf> There was some talk of switching them over to using libc
for net functions, which made me a little sad because it means Go programs need a
recompile for uclibc
19:26 < niemeyer> czr_: That's actually the case
19:26 -!- jyxent [~jyxent@129.128.191.96] has joined #go-nuts
19:26 < czr_> excellent.
19:26 < Namegduf> Well, actually, I guess they statically link, so...
should work.
19:26 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-160-239.clienti.tiscali.it] has
quit [Ping timeout: 250 seconds]
19:26 < czr_> how does go handle older kenrnels though?
19:26 < Namegduf> But I don't know if that actually happened.
19:26 < czr_> is there some dynamic disabling of certain syscalls when an
older kernel is detected?
19:26 < czr_> or a kernel on an arch which hasn't ported all syscall
implementations yet (this happens on arm quite often)
19:27 < niemeyer> czr_: I don't think that's a concern at the moment
19:27 < niemeyer> czr_: But sure, it wouldn't be hard to compile things
conditionally..  that's already done for different architectures/OSes
19:28 < czr_> err, but you'd need to do this during the runtime
19:28 < czr_> since otherwise the compiled binary is bound to the exact
system where it was compiled.
19:28 < Namegduf> Not the exact system
19:28 -!- alkavan [~alkavan@IGLD-84-229-168-230.inter.net.il] has joined #go-nuts
19:28 < Namegduf> Just one with all the syscalls Go has defined, and that it
uses
19:28 < Namegduf> Which I suspect is at least fairly liberal.
19:28 < czr_> sure.  but take timerfd for example
19:28 < czr_> getting that implemented for arm took literally ages
19:29 < skelterjohn> literally
19:29 < czr_> well.  almost literally.  :-)
19:29 < czr_> afair at least 6 months
19:29 -!- Fish- [~Fish@9fans.fr] has joined #go-nuts
19:30 < str1ngs> skelterjohn: so all the issue I had with stderr not
flushing...  turned out to be a make wrapper that I use :(
19:30 < czr_> granted, there were various issues with timerfd per se
(different APIs for the same syscall with different kernel versions).
19:34 < niemeyer> czr_: Not sure about what's your concern in that regard
19:34 < czr_> niemeyer, I guess it's largely theoretic at this point
19:35 < niemeyer> czr_: Sure, if you compile something which depends on a
syscall, it will not work in a system without the syscall.
19:35 < niemeyer> czr_: Not in Go, not in *any* language
19:35 < czr_> but suppose the following case.  you compile your program on
system A, running the newest and greatest.  then you transfer the binary to system
B, which is running a kernel two years older than system A.
19:36 < czr_> ah yes.  but if you can remove the binding/symbol when the
program starts based on kernel versioning you could make the program crash in a
useful way
19:36 < czr_> but, as said, it's so far theoretic as go is new.
19:36 < niemeyer> czr_: Heh
19:36 < niemeyer> czr_: That's not about Go
19:37 < Namegduf> czr_: If you build your program, and your program is using
syscalls not avaiable on the older system.
19:37 < Namegduf> In which case, as pointed out, there's nothing you can do.
19:38 < Namegduf> Trying to beat the kind of crash you'd get in any other
compiled language by doing a startup check is kinda dubious, for the sole purpose
of a nicer crash.
19:38 < czr_> yeah.  maybe I'm trying to find a solution to a problem that
doesn't really exist.
19:39 < czr_> also I don't think there's an easy way of dynamically even
detecting which syscalls are implemented by the kernel
19:39 < czr_> unless you hardcode that information somehow into the binary.
19:40 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.4]
19:40 < niemeyer> czr_: You're trying to find a solution to an unsolvable
problem, rather.  A program can't use something which is not available, that's
all.
19:41 < czr_> I disagree in that.  a program might take other execution
paths if some resource is not available.  but, I agree that it's not very useful
to even try to solve this.
19:44 < niemeyer> czr_: LOL..  "A program can't use something which is not
available." is about the most undeniable sentence I wrote in the last few years..
if you disagree with that, I'll have to move on.
19:44 < aiju> niemeyer: i disagree with that
19:45 < aiju> the program can use the cloud to make it available!
19:45 < niemeyer> Then it is available..
19:45 < czr_> niemeyer, suppose there are multiple ways to achieve some
effect with different syscalls.  the newer might provide a faster avenue for the
problem you're trying to solve, but you could also fall back on the older ones.
it just wouldn't be just as efficient.
19:46 < niemeyer> czr_: Yep..  the truism remains..  if the program is
compiled to expect the syscall to not be available, then it will work.
19:47 < niemeyer> czr_: There's nothing special happening there.
19:48 < Xenith> I don't suppose its possible to get at the socket descriptor
with a net.Listener or net.TCPListener, and then later reattach to that descriptor
with a new Listener?
19:51 -!- dgnorton2 [~dgnorton@97.65.135.100] has quit []
19:58 -!- zimsim [~simon@87.72.77.195] has joined #go-nuts
19:59 -!- femtoo [~femto@95-89-249-242-dynip.superkabel.de] has quit [Read error:
Connection reset by peer]
20:02 -!- aho [~nya@fuld-4d00d6a1.pool.mediaWays.net] has joined #go-nuts
20:06 -!- plainhao [~plainhao@208.75.85.237] has quit [Quit: plainhao]
20:06 -!- Project-2501 [~Marvin@82.84.97.129] has joined #go-nuts
20:07 -!- izaki [~lbivens@ool-44c688f2.dyn.optonline.net] has quit [Quit: leaving]
20:09 -!- PortatoreSanoDiI [~Marvin@dynamic-adsl-94-36-180-250.clienti.tiscali.it]
has quit [Ping timeout: 240 seconds]
20:09 -!- PortatoreSanoDiI [~Marvin@dynamic-adsl-94-36-179-245.clienti.tiscali.it]
has joined #go-nuts
20:11 < czr_> what is the proper way to fix typos in the go tutorial?
20:12 -!- Project-2501 [~Marvin@82.84.97.129] has quit [Ping timeout: 276 seconds]
20:12 < czr_> hmm.  nevermind, it was me.
20:14 -!- fabled [~fabled@83.145.235.194] has quit [Read error: No route to host]
20:25 -!- SirPsychoS [~sp@c-24-13-132-130.hsd1.il.comcast.net] has joined #go-nuts
20:26 < SirPsychoS> I feel like the testing package is behaving really
weirdly - with identical code, gob and flate both fail inside a Benchmark, but
they both work inside a main.main() function
20:28 < steven> so
20:28 < steven> anyone want to write a thing with me?
20:28 < steven> a web framework that makes rapid development easy?
20:29 < steven> i have a solid starting point but i could use another set of
ideas to make sure the idea is sound
20:29 < czr_> if you're not beyond borrowing ideas from python, web2py has
several interesting things all leading to rapid development
20:30 < KirkMcDonald> Speaking of borrowing things from Python, I still
think an equivalent abstraction to Python's WSGI would be a thing.
20:30 < steven> yeah web.go is okay
20:30 < steven> im talking about something closer to rails, though.
20:30 < steven> something more professional than web2py
20:30 < steven> ie something thats not a toy
20:30 -!- PJ_Robins [~finn@174-20-67-7.mpls.qwest.net] has quit [Remote host
closed the connection]
20:31 < zimsim> problem with thing that not are "toy's", they usually are
closer to "clusterfucks"
20:32 < steven> im not saying i like all of rails.  but it has a lot of good
ideas
20:33 < zimsim> Go is feels very flat.  You can use it like you use
LEGO-blocks.  While frameworks you describe usually have too much ...
20:33 < zimsim> they try to be too much
20:33 < steven> rails is very successful
20:33 < steven> for a reason.
20:34 < zimsim> I'm not saying they aint successfull, but spending some time
in them soon reveals these small irritating things which grow bigger and bigger
20:34 < zimsim> but that is just my opinion
20:34 < steven> k
20:35 < zimsim> I kind of like the approach Flask, the Python framework has
taken.
20:36 < zimsim> I builds upon libraries, glues them together.
20:36 < zimsim> The framework itself is < 1000 LOC i think
20:38 < SirPsychoS> is it possible that Tests and Benchmarks in package main
make flate fail and gob panic?
20:39 < SirPsychoS> because the same tests in a non-main package don't panic
20:48 -!- PJRobins [~quassel@174-20-67-7.mpls.qwest.net] has joined #go-nuts
20:49 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has quit [Remote host
closed the connection]
20:49 -!- Project-2501 [~Marvin@82.84.76.206] has joined #go-nuts
20:52 -!- PortatoreSanoDiI [~Marvin@dynamic-adsl-94-36-179-245.clienti.tiscali.it]
has quit [Ping timeout: 246 seconds]
20:55 -!- zimsim [~simon@87.72.77.195] has quit [Remote host closed the
connection]
20:58 -!- PJRobins [~quassel@174-20-67-7.mpls.qwest.net] has quit [Remote host
closed the connection]
20:58 -!- PJRobins [~quassel@174-20-67-7.mpls.qwest.net] has joined #go-nuts
21:02 -!- TheSeeker [~n@99-153-250-110.lightspeed.irvnca.sbcglobal.net] has quit
[Ping timeout: 240 seconds]
21:04 < steven> ok now that hes gone
21:04 < steven> anyone wanna help with my rails-like Go framework?
21:04 < aiju> sleep(10) could be used to simulate ruby performance
21:04 < steven> ;)
21:04 < skelterjohn> still curious about what want from rails
21:05 < aiju> function NonZero(x int) bool { return x != 0 }
21:05 < skelterjohn> what does it provide that you'd like to see for go
21:05 < steven> the way rails does convention over configuration is really
nice
21:05 < aiju> function First(x []int) int { return x[0] }
21:05 < steven> ie, auto-routing to /controllername/methodname by default
21:05 < skelterjohn> i'm certainly on board with that idea - i built gb
around it
21:05 < steven> unless otherwise specified
21:06 < steven> aiju: first doesnt raise an exception if the array is empty
21:06 < steven> aiju: in Go, it would
21:06 < skelterjohn> that's confusing
21:06 < aiju> it's ruby
21:06 < steven> yep
21:06 < skelterjohn> but, steven is talking about rails, not ruby
21:06 < steven> ruby is good.
21:06 < steven> its just slooow
21:06 < steven> and i do NOT like having to debug it every day
21:06 < aiju> ruby is "good"?
21:06 < steven> which is why i like Go, since its less dynamic.
21:06 < steven> :)
21:06 < aiju> x.nonzero?
21:06 < skelterjohn> err, my point was that First(emptyList) not having an
error is confusing
21:07 < steven> aiju: i did not say the stdlib is all good
21:07 < steven> the ruby stdlib has a lot of stupid things in it
21:07 < steven> but ruby itself is good
21:07 < aiju> like?
21:07 < steven> you just said one.
21:07 < aiju> no, what's good about it
21:07 < steven> the fact taht everything is an expression is nice
21:08 < steven> the way you pass blocks to methods is also convenient
21:10 < steven> the way most things are just methods is nice, and the
dynamic and open nature of classes is nice too.
21:10 < steven> but thats one thing i both like and hate about ruby.
21:10 < steven> it makes it easy to create a clusterflux thats hell to debug
(which is my dayjob)
21:10 < steven> in Go, its not nearly that easy to create a debugging
nightmare since its much more explicit
21:11 < steven> anyway
21:11 < steven> anyone wanna help with this framework or am i gonna go it
alone?
21:11 < aiju> that's my experience with javascript
21:11 < steven> what is
21:11 < aiju> debugging nightmare
21:11 < skelterjohn> steven: ask me again after this weekend
21:11 < steven> yeah.
21:11 < steven> k
21:11 < skelterjohn> i have a conference deadline friday night
21:11 < steven> cool which conf
21:12 < skelterjohn> uncertainty in artificial intelligence
21:12 < steven> ouch
21:12 < skelterjohn> :\
21:12 -!- wrtp [~rog@92.17.17.88] has quit [Quit: wrtp]
21:12 < steven> i mean, cool
21:12 < aiju> that problem is not limited to artificla ones
21:12 < skelterjohn> heh
21:12 < czr_> skelterjohn, the timetable for skynet is still open?
21:12 < aiju> how's AI doing?  any results yet?
21:12 < skelterjohn> aiju: no
21:13 < skelterjohn> czr_: the current track of AI is not one that leads to
self aware computers
21:13 < czr_> expert systems then?
21:13 < skelterjohn> there are more categories than expert system and
self-aware
21:14 < steven> my home LAN is named SkyNet
21:17 -!- napsy [~luka@88.200.96.18] has joined #go-nuts
21:22 -!- itrekkie [~itrekkie@ip70-190-110-197.ph.ph.cox.net] has joined #go-nuts
21:23 -!- zozoR [~Morten@563476e6.rev.stofanet.dk] has quit [Remote host closed
the connection]
21:27 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has quit [Quit: skelterjohn]
21:36 -!- imsplitbit [~imsplitbi@64.39.4.132] has quit [Quit: Bye!]
21:42 -!- ronnyy [~quassel@p4FF1C6BC.dip0.t-ipconnect.de] has joined #go-nuts
21:48 -!- pharris [~Adium@rhgw.opentext.com] has quit [Quit: Leaving.]
21:53 < str1ngs> steven: if you make a rails like frame can you make it more
like pylons.  and not like the rails scaffold crap
21:55 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit:
Verlassend]
22:03 < kamaji> Can something have more than one type?
22:03 < aiju> do you mean something like interfaces?
22:03 < KirkMcDonald> What, like a union?
22:03 < kamaji> I think I mean interface{} with a different name
22:04 < kamaji> type Foo interface{}
22:04 < kamaji> I don't think that makes any sense
22:05 < kamaji> I think I just need an interface
22:05 < kamaji> please ignore me until I figure out what question I was
asking :D
22:08 -!- skelterjohn [~jasmuth@c-68-46-33-145.hsd1.nj.comcast.net] has joined
#go-nuts
22:10 -!- killerboy [~mateusz@smrw-91-193-87-5.smrw.lodz.pl] has joined #go-nuts
22:11 -!- exherboer [~exherboer@pool-108-5-64-16.nwrknj.east.verizon.net] has
joined #go-nuts
22:11 < kamaji> killerboy: oh hi :P
22:12 -!- exherboer [~exherboer@pool-108-5-64-16.nwrknj.east.verizon.net] has left
#go-nuts ["WeeChat 0.3.4"]
22:12 < killerboy> hi
22:12 < killerboy> just checking what go is
22:12 < killerboy> never heard about it
22:13 < killerboy> oh no, it's c-like
22:13 < kamaji> killerboy: http://golang.org/doc/ExpressivenessOfGo.pdf
22:13 < kamaji> it's not really :)
22:13 < kamaji> I recommend reading that PDF, it's pretty good
22:13 < killerboy> ok
22:13 -!- Fish [~Fish@exo3753.pck.nerim.net] has quit [Read error: Operation timed
out]
22:13 < killerboy> i really like the logo
22:14 < kamaji> haha
22:14 < KirkMcDonald> Gordon the Gopher!
22:14 -!- Fish [~Fish@exo3753.pck.nerim.net] has joined #go-nuts
22:15 < killerboy> :-D
22:15 < killerboy> i like gopher too ;-)
22:16 < killerboy> ??  it does have pointers
22:17 < KirkMcDonald> Yes.  But they're not precisely like C's.
22:17 < kamaji> Yep, but I should warn you the example code in that PDF is
not up to date
22:17 -!- TheMue [~TheMue@p5DDF56D6.dip.t-dialin.net] has quit [Quit: TheMue]
22:17 < KirkMcDonald> You can't do pointer arithmetic.
22:17 < kamaji> which confused the hell out of me when I was reading it
22:17 < KirkMcDonald> (Well, you *can*, but you have to do terrible things.)
22:17 < aiju> terreo unsafe et donas ferrentem
22:19 -!- jbooth1 [~jay@209.249.216.2] has left #go-nuts []
22:20 < killerboy> are programming constructs inheritet from c?
22:20 < skelterjohn> depends on what you mean by "programming constructs"
22:20 < KirkMcDonald> killerboy: I'm not sure what you mean.
22:21 < KirkMcDonald> There are tremendous differences in both syntax and
semantics.
22:21 < killerboy> for, if, while...
22:22 < killerboy> switch
22:22 < aiju> no while ;P
22:22 < aiju> killerboy: just read the tutorial or something
22:22 < killerboy> aiju: still donno if it's interesting ;-)
22:23 -!- Fish- [~Fish@9fans.fr] has quit [Quit: So Long, and Thanks for All the
Fish]
22:23 < kimelto> you'll know it when you read it
22:24 < skelterjohn> killerboy: it has for, if, while (in the form of for),
switch, because it is an imperative language
22:24 < skelterjohn> these constructs are neither unique to C nor did C
introduce them
22:25 -!- napsy [~luka@88.200.96.18] has quit [Ping timeout: 260 seconds]
22:27 -!- dfc [~dfc@sydfibre2.atlassian.com] has joined #go-nuts
22:30 < killerboy> skelterjohn: true
22:33 < killerboy> C+Ada ;-)
22:36 < killerboy> what do you consider the most important improvement?
22:36 < killerboy> some distinguishing feature...
22:38 < kamaji> Orthogonality
22:38 < kamaji> as described in PDF
22:38 < kamaji> and simplicity
22:39 < Namegduf> Strict typing and simplicity and multiple return values
22:39 < kamaji> ...and a fanatical devotion to the pope.
22:39 < Namegduf> And that.
22:39 <+iant> channels
22:39 < kamaji> first-class concurrency
22:41 < skelterjohn> interface-oriented programming, instead of
object-oriented programming
22:41 < kamaji> Which is kinda weird to wrap your head around when you keep
trying to program like it's Java
22:42 < kamaji> and then you go "Oh...  I could've done it more flexibly in
10x less code "
22:42 < skelterjohn> that one was a big "aha!" moment for me
22:42 < killerboy> ok
22:43 < killerboy> i'm comparing it now to my fav lang, and trying to get
some conclusions
22:43 < skelterjohn> i find myself debugging code faster with go than with
java or C++
22:43 < skelterjohn> and that is saying a lot, because i don't know how to
pair go with gdb
22:43 < kamaji> killerboy: there's an in-browser compiler at golang.org
22:43 < skelterjohn> and with java and C++ i use GUI debuggers
22:45 < killerboy> when declaring a function do i have to tell to which type
it belongs?  (if i understand it correctly?  first parenthesis is for saying to
which class this method belongs?)
22:45 < Namegduf> skelterjohn: gdb <go executable>
22:45 < Namegduf> skelterjohn: There is no fancy tricks required
22:45 < Namegduf> You *do* need a recent enough Go, though
22:45 < skelterjohn> i'd have to figure out how to install the latest gdb
here
22:45 < skelterjohn> i'm on a mac
22:45 < skelterjohn> have to DL the latest xcode
22:46 < skelterjohn> it wants me to install snow leopard
22:46 < Namegduf> I'm not sure if you need the newest gsb
22:46 < skelterjohn> i don't really want to buy snow leopard
22:46 < Namegduf> *gdb
22:46 < Namegduf> Give it a try
22:46 < Namegduf> If you don't want to pay through the ass for basic things,
why do you run OS X?
22:46 < Namegduf> :P
22:46 < skelterjohn> "/Users/jasmuth/Dropbox/rl/go-glue/cmd/rmax/rmax.go":
not in executable format: File format not recognized
22:46 < skelterjohn> because the computer was a present
22:47 < Namegduf> You sue it on the executable.
22:47 < skelterjohn> and i like macs
22:47 < Namegduf> *use
22:47 < Namegduf> Not on a go file
22:47 < skelterjohn> i ran gdb on the executable
22:47 < skelterjohn> and when i tried to run, said no file loaded
22:47 -!- shakesoda [~colby@c-67-168-136-89.hsd1.wa.comcast.net] has joined
#go-nuts
22:47 < kamaji> Guys, the flamewar early warning system is off the charts
22:47 < skelterjohn> *shrug* i don't really want to learn all about gdb
right now
22:47 < Namegduf> Did it give any errors?
22:47 < kamaji> the little scribbly needle drew an apple
22:47 < Namegduf> Okay.
22:47 < skelterjohn> i tried "break main"
22:47 < skelterjohn> and it told me to try the file command
22:48 < Namegduf> Sounds like it didn't load it.
22:48 < killerboy> is it possible for me to define function for many types
at once?
22:48 < Namegduf> No.
22:49 < skelterjohn> you can embed types to share functionality
22:49 < skelterjohn> if a type has an embedded type with method Foo, and
doesn't define Foo for itself, it will use the embedded Foo
22:50 < Namegduf> Can you embed interface types?
22:50 < Namegduf> (It'd be an interesting way to use composition)
22:51 < killerboy> ok, i've read some of it, of course cannot be objective
after such a short reading
22:52 < killerboy> *more objective ;-)
22:52 < Namegduf> Object-ive!?
22:52 < Namegduf> Oh, no, I can calm down...
22:52 < skelterjohn> http://pastebin.com/WN8evQCM
22:52 < skelterjohn> a tour of embedding
22:52 < Namegduf> Nice, you can.
22:53 < killerboy> for me the most interesting is first-class concurrency
22:53 < skelterjohn> keep in mind - if you embed more than one thing that
defines Foo(), you have to tell which you're using
22:53 < killerboy> channels and such
22:53 < kamaji> Is the guy who wrote "gomatrix" on here?
22:53 < kamaji> (or gal)
22:53 < skelterjohn> <-
22:54 < kamaji> oh hi :D
22:54 < skelterjohn> hi there
22:54 < kamaji> Is there a quick reference for the types?
22:54 < skelterjohn> you could godoc it
22:54 < skelterjohn> i'm not good at hosting web pages
22:54 < kamaji> let me try that
22:54 < kamaji> haha
22:54 < kamaji> oh also, what's "1.0" and "matrix" in the source tree?
22:54 < skelterjohn> me trying to establish a versioning convention
22:54 < skelterjohn> i should probably stop
22:55 < skelterjohn> and delete 1.0
22:55 < killerboy> this is nice: Number of keywords is an approximate
measure of complexity
22:55 < skelterjohn> but, 1.0 is a frozen version
22:55 < killerboy> Smalltalk: 0 ;-)
22:55 < Namegduf> Very approximate
22:55 -!- chimes [~chimes@24.104.130.118] has joined #go-nuts
22:55 < kamaji> oh ok, cheers
22:56 < killerboy> does anyone know smalltalk and could contrast go and
smalltalk here?
22:56 < skelterjohn> smalltalk is object oriented
22:56 < skelterjohn> that's all i know about it
22:56 <+iant> smalltalk and go are fairly different
22:57 -!- ronnyy [~quassel@p4FF1C6BC.dip0.t-ipconnect.de] has quit [Remote host
closed the connection]
22:57 <+iant> smalltalk is a fairly pure object oriented language in that
all operations are done by applying a method to an object
22:57 <+iant> go is a more conventional imperative language
22:58 < kamaji> I'm getting some weird error "open
/usr/lib/go/lib/godoc/codewalk.html: no such file or directory" with godoc
22:58 < skelterjohn> i can't help you, there
22:58 <+iant> does that directory exist?
22:58 < kamaji> no, but I don't know what would make it
22:58 < skelterjohn> i bet if i ask niemeyer_away, he would host gomatrix on
goneat.org's godoc
22:59 < killerboy> iant: ok
22:59 < skelterjohn> kamaji: I have that file - perhaps something is wrong
with your distribution
22:59 < kamaji> skelterjohn: oh noo
22:59 < kamaji> I'm using the arch one
22:59 < kamaji> maybe needs an update
22:59 < killerboy> thanks for all answers :-D bye
22:59 < skelterjohn> bye killerboy
22:59 -!- killerboy [~mateusz@smrw-91-193-87-5.smrw.lodz.pl] has left #go-nuts []
23:00 < kamaji> as in arch linux
23:00 < kamaji> hey, you implemented SVD
23:00 < kamaji> awesome
23:02 < skelterjohn> :)
23:02 < kamaji> with unicode variable names
23:02 < kamaji> hahah
23:02 < skelterjohn> might have been a bad idea
23:02 < kamaji> I always wondered about that
23:02 < kamaji> looks nicer, but really hard to type ^^
23:03 < skelterjohn> well, i have a keyboard shortcut tos witch me between
the american and greek keyboard
23:03 < kamaji> oh, useful
23:03 < skelterjohn> which i made just so i could write gomatrix and gostat
23:03 < skelterjohn> i just thought it was neat to be able to use greek
letters
23:03 < skelterjohn> but i overdid it
23:03 < kamaji> gostat.....  that's a statistics library isn't it
23:03 < skelterjohn> it's not so much statistics, as an extended rand
23:03 < skelterjohn> provides more distributions and density functions
23:04 < kamaji> I started on my own one cause I couldn't find one
23:04 < kamaji> work deleted :P
23:04 < kamaji> oh, unavailable as yet?
23:04 < skelterjohn> i made gomatrix because because i needed it to make
gostat work with multivariable dists
23:04 < skelterjohn> no, it's available
23:04 < kamaji> oh no, i'm just dumb
23:04 < skelterjohn> gostat.googlecode.com
23:04 < kamaji> As long as you have the CDF for normal dist i'm ok
23:04 < skelterjohn> i do
23:05 < skelterjohn> wait, CDF
23:05 < skelterjohn> no, just the PDF :)
23:05 < kamaji> dangit
23:05 < skelterjohn> would love it if you added that
23:05 < kamaji> skelterjohn: return ((1.0/2.0) * (1 + math.Erf( (x-mu) /
(sd*math.Sqrt2))))
23:05 < kamaji> it's only one line :D
23:05 < skelterjohn> patches welcome
23:05 < kamaji> wait it could be my first ever patch :O
23:05 < skelterjohn> i don't need it :)
23:06 < skelterjohn> if you msg me your googlecode username i can add you as
a committer
23:06 < kamaji> I don't have one
23:06 < kamaji> I'll sign up
23:06 < kamaji> what an exciting day
23:06 < skelterjohn> lol
23:07 < skelterjohn> i sort of wish i had used github for these projects
23:07 < kamaji> Can I use my google account for this?
23:07 < skelterjohn> but i don't feel like breaking the code of all the many
people who use it
23:07 < skelterjohn> i think so
23:07 < skelterjohn> but you have to activate yourself as a googlecode user
i think
23:07 < kamaji> seems to work without activation
23:07 -!- cenuij [~cenuij@78.112.41.178] has joined #go-nuts
23:07 -!- cenuij [~cenuij@78.112.41.178] has quit [Changing host]
23:07 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts
23:07 < kamaji> i'll just msg you my gmail and see if that works
23:09 < skelterjohn> with github i wouldn't have to add you to the project -
you could just fork it and submit a pull request
23:09 < skelterjohn> i like that model a lot better
23:09 < kamaji> skelterjohn: that's quite nice actually
23:10 < skelterjohn> i think gostat's Normal_PDF function is wrong...
23:10 < skelterjohn> it uses a random sample in the computation...
23:10 < kamaji> lol
23:11 < skelterjohn> somehow math.Exp became NextExp, which is the next
sample from an exponential RV
23:11 -!- foocraft [~dsc@86.36.42.29] has joined #go-nuts
23:11 -!- piranha [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has quit [Quit:
Computer has gone to sleep.]
23:13 < kamaji> wait hang on, your PDFs are returning functions?
23:13 < kamaji> oh right, the actual distribution
23:13 < kamaji> ok
23:13 < skelterjohn> they curry
23:13 < kamaji> that's pretty nice
23:14 < skelterjohn> there is a lot of stuff that is a function of the dist
params and does not change from call to call
23:14 < kamaji> so do you call like Normal_PDF(mu, sd, x) or (mu, sd)(x) ?
23:14 < skelterjohn> the latter
23:14 -!- crazy2be [~crazy2be@d209-89-248-73.abhsia.telus.net] has joined #go-nuts
23:14 < skelterjohn> and you can hold on to (mu, sd)
23:14 < skelterjohn> and call it on multiple xs
23:15 < kamaji> I like your design better ^^
23:15 < skelterjohn> than what
23:15 < kamaji> plus you can pass around distributions without knowing
parameters
23:15 < kamaji> mine
23:15 < skelterjohn> ah
23:15 < kamaji> lol
23:15 < crazy2be> is there any way to include one struct within another?
Such that one struct inherits the fields of another
23:15 < skelterjohn> crazy2be: embedding
23:15 < skelterjohn> about 30 minutes ago i pasted this:
http://pastebin.com/WN8evQCM
23:15 < skelterjohn> which demonstrates embedding
23:16 < crazy2be> well then you just do struct A { blar int } struct B {A;
blar2 int}
23:17 < skelterjohn> yes
23:17 < crazy2be> but you have to do B.A.blar2 to get to blar2
23:17 < Namegduf> Don't confuse it with inheritance; binding means static.
23:17 < skelterjohn> then you have blar in things of type B
23:17 < kamaji> skelterjohn: What's the normal_normalizer in your functions?
23:17 < skelterjohn> crazy2be: only if it's ambiguous
23:17 < Namegduf> You can use B.blar2; for this it's just syntactic sugar
23:17 < Namegduf> For methods it has actual effect
23:17 < crazy2be> well, object literals require it
23:18 < Namegduf> As it affects interfaces met.
23:18 < skelterjohn> kamaji: it's a normalization constant for the normal
pdf
23:18 < skelterjohn> to make it sum to 1
23:18 < crazy2be> e.g.  you have to do B{A{1},2}
23:18 -!- TheSeeker [~n@99-153-250-110.lightspeed.irvnca.sbcglobal.net] has joined
#go-nuts
23:18 < crazy2be> which i suppose makes sence
23:18 < Namegduf> I gues they do
23:19 < skelterjohn> calling it normal_normalizer is a bit too cute, in
retrospect
23:21 < skelterjohn> but that weird number is 1/sqrt(2pi)
23:22 < kamaji> oh ok
23:22 < kamaji> that makes a bit more sense :P
23:22 < kamaji> Maybe define it as a constant?
23:22 < kamaji> in fact...
23:23 < kamaji> nah, I thought math might've had it
23:23 < kamaji> I guess it's a bit specific
23:23 < skelterjohn> a bit :)
23:24 < skelterjohn> it wouldn't bother me if it were a const
23:26 < kamaji> oh, stat.a is under "gostat.googlecode.com/hg/stat.a"
23:26 < kamaji> how do I get import to notice it?
23:27 < skelterjohn> you import "gostat.googlecode.com/hg/stat"
23:27 < kamaji> aw :\
23:27 < kamaji> so long~
23:27 < skelterjohn> you use its goinstall name
23:27 < kamaji> wait, i've been running make install
23:27 < kamaji> should I be using goinstall?
23:27 < skelterjohn> that will work too
23:27 < kamaji> ok
23:27 < skelterjohn> they install to the same place
23:27 < skelterjohn> (on purpose)
23:27 -!- rlab [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller,
Faster, Easier.  http://miranda-im.org]
23:28 < skelterjohn> brb
23:28 -!- iant [~iant@nat/google/x-ogrxszvlzcstrpjd] has quit [Ping timeout: 248
seconds]
23:29 -!- skelterjohn [~jasmuth@c-68-46-33-145.hsd1.nj.comcast.net] has quit
[Quit: skelterjohn]
23:38 -!- skelterjohn [~jasmuth@c-68-46-33-145.hsd1.nj.comcast.net] has joined
#go-nuts
23:41 -!- Venom_X [~pjacobs@66.54.185.131] has quit [Quit: Venom_X]
23:42 -!- jgonzalez [~jgonzalez@173-14-137-134-NewEngland.hfc.comcastbusiness.net]
has quit [Ping timeout: 252 seconds]
23:42 < kamaji> skelterjohn: pushed the change, thanks :D
23:42 -!- artefon [~thiago@189.59.162.202] has quit [Quit: bye]
23:43 < skelterjohn> protip: (1.0/2.0) = 0.5 :)
23:43 < kamaji> skelterjohn: me: facepalm
23:43 < kamaji> i'll just fix that...
23:44 < skelterjohn> it's probably compiled away in any case
23:44 < kamaji> worth the fix?
23:44 < skelterjohn> math.Sqrt2?  interesting
23:44 < skelterjohn> kamaji: doesn't bother me
23:44 < kamaji> ok i'm going to do it because i'm a bit embarassed :D
23:45 < skelterjohn> btw, now that you've added CDF for one function, you
have to add it for all the others too
23:45 < kamaji> You scared the crap out of me just then
23:46 < kamaji> But I probably will end up doing that anyway~
23:46 < skelterjohn> CDFs are definitely useful to have around
23:46 < kamaji> I'll add the ones that are easy to implement
23:47 -!- PJRobins [~quassel@174-20-67-7.mpls.qwest.net] has quit [Read error:
Connection reset by peer]
23:50 < kamaji> actually i'm just gonna leave it....  it's not that bad
23:52 < skelterjohn> yeah it's fine
--- Log closed Thu Mar 17 00:00:09 2011