--- 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