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

--- Log opened Fri Nov 19 00:00:09 2010
--- Day changed Fri Nov 19 2010
00:00 -!- nigelkerr [~nigelkerr@jstormichfw.jstor.org] has joined #go-nuts
00:08 < fafhrd1> weatherkid: hey, sorry, away for a bit
00:08 < weatherkid> ok
00:08 < fafhrd1> weatherkid: I don't know too much, but I'd test NOT as root
00:09 < weatherkid> I'm just compiling
00:09 < weatherkid> trust me, i know that risk.  been there, done that
00:09 -!- wrtp [~rog@92.17.75.221] has quit [Quit: wrtp]
00:09 < fafhrd1> it's probably attempting a different when root (i.e.  that
delievery to syslog), which isn't setup for your sustem
00:09 < weatherkid> ahh
00:09 < fafhrd1> right, but it's running tests
00:09 < fafhrd1> that's my guess at least
00:09 < weatherkid> ok
00:10 < weatherkid> i'll try real quick
00:10 < weatherkid> your idea
00:10 < fafhrd1> can't hurt -- the build is pretty darn quikc
00:13 -!- cyounkins [~cyounkins@CMU-415893.WV.CC.CMU.EDU] has quit [Ping timeout:
272 seconds]
00:14 -!- kanru [~kanru@118-160-164-12.dynamic.hinet.net] has joined #go-nuts
00:19 -!- fafhrd1 [~fafhrd@rrcs-72-43-5-235.nys.biz.rr.com] has quit [Ping
timeout: 245 seconds]
00:22 -!- nigelkerr [~nigelkerr@jstormichfw.jstor.org] has quit [Quit: nigelkerr]
00:29 -!- Scorchin [~Scorchin@host86-173-184-117.range86-173.btcentralplus.com]
has joined #go-nuts
00:32 < |Craig|> is there any way to force a go routine to run in the same
process as the one that started it?
00:33 -!- XenoPhoenix [~Xeno@cpc5-aztw24-2-0-cust39.aztw.cable.virginmedia.com]
has quit [Ping timeout: 240 seconds]
00:33 < enferex> |Craig|: Umm set GOMAXPROCS=1
00:33 < enferex> heh
00:34 < |Craig|> enferex: so I basically can't use unbuffered channels's
blocking all over in a multi core app
00:35 < |Craig|> unless I want it to be really slow
00:35 < |Craig|> I guess I'll make an iterator object instead of using a
channel then
00:36 < enferex> |Craig|: I'm not sure you can truly specify an afinity of a
goroutine to a specifc thread
00:39 -!- mikespook [~mikespook@58.61.201.77] has joined #go-nuts
00:42 -!- foocraft [~dsc@78.101.147.68] has quit [Ping timeout: 245 seconds]
00:59 -!- skelterjohn [~jasmuth@c-76-98-219-171.hsd1.pa.comcast.net] has joined
#go-nuts
01:09 -!- skelterjohn [~jasmuth@c-76-98-219-171.hsd1.pa.comcast.net] has quit
[Quit: skelterjohn]
01:12 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has quit [Remote
host closed the connection]
01:22 -!- Scorchin [~Scorchin@host86-173-184-117.range86-173.btcentralplus.com]
has quit [Quit: Scorchin]
01:23 -!- rejb [~rejb@unaffiliated/rejb] has quit [Quit: .]
01:26 -!- poolie [~mbp@canonical/launchpad/poolie] has joined #go-nuts
01:27 -!- skelterjohn [~jasmuth@c-76-98-219-171.hsd1.pa.comcast.net] has joined
#go-nuts
01:29 -!- kanru [~kanru@118-160-164-12.dynamic.hinet.net] has quit [Ping timeout:
255 seconds]
01:38 -!- Tv [~tv@gige.bur.digisynd.com] has quit [Ping timeout: 265 seconds]
01:41 -!- danslo [~daniel@s5593965d.adsl.wanadoo.nl] has quit [Quit: Leaving.]
01:42 -!- rbraley [~rbraley@ip72-222-128-78.ph.ph.cox.net] has joined #go-nuts
01:46 -!- devrim1 [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has quit [Quit:
Leaving.]
01:53 -!- ExtraSpice [~XtraSpice@88.118.33.48] has quit [Ping timeout: 240
seconds]
01:57 -!- foocraft [~dsc@78.101.147.68] has joined #go-nuts
02:07 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has joined #go-nuts
02:08 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has joined #go-nuts
02:09 -!- bmizerany [~bmizerany@208.66.27.62] has quit [Remote host closed the
connection]
02:09 -!- niemeyer [~niemeyer@189-10-175-46.pltce701.dsl.brasiltelecom.net.br] has
quit [Ping timeout: 240 seconds]
02:18 -!- spe [~phi@pool-71-178-14-3.washdc.fios.verizon.net] has joined #go-nuts
02:18 -!- aconran___ [~aconran@adsl-76-199-140-78.dsl.pltn13.sbcglobal.net] has
joined #go-nuts
02:20 -!- spe [~phi@pool-71-178-14-3.washdc.fios.verizon.net] has quit [Client
Quit]
02:22 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has joined #go-nuts
02:29 -!- skelterjohn [~jasmuth@c-76-98-219-171.hsd1.pa.comcast.net] has quit
[Quit: skelterjohn]
02:33 -!- weatherkid [~name@unaffiliated/weatherkid] has quit [Quit: get
satisfied!  • :: www.unitedservers.de ««« (Gamers.IRC) »»» gamersirc.net ::]
02:33 -!- gnuvince_ [~vince@70.35.164.30] has quit [Read error: Operation timed
out]
02:35 -!- gnuvince_ [~vince@70.35.171.47] has joined #go-nuts
02:48 -!- yinruzhi [~zhi@2001:da8:e000:90:0:5efe:a79:2abc] has joined #go-nuts
02:50 -!- nf [~nf@124-171-20-223.dyn.iinet.net.au] has joined #go-nuts
02:50 -!- mode/#go-nuts [+o nf] by ChanServ
02:50 -!- skelterjohn [~jasmuth@c-76-98-219-171.hsd1.nj.comcast.net] has joined
#go-nuts
03:06 -!- falconindy [~noclaf@unaffiliated/falconindy] has quit [Quit: Lost
terminal]
03:07 -!- falconindy [~noclaf@unaffiliated/falconindy] has joined #go-nuts
03:07 -!- Tv [~tv@cpe-76-168-227-45.socal.res.rr.com] has joined #go-nuts
03:28 -!- cco3 [~conley@c-69-181-138-209.hsd1.ca.comcast.net] has joined #go-nuts
03:33 -!- foocraft [~dsc@78.101.147.68] has quit [Ping timeout: 240 seconds]
03:37 -!- thhooommmm [~thom@70-139-188-39.lightspeed.hstntx.sbcglobal.net] has
quit [Read error: Connection reset by peer]
03:40 -!- skelterjohn [~jasmuth@c-76-98-219-171.hsd1.nj.comcast.net] has quit
[Quit: skelterjohn]
03:45 -!- skelterjohn [~jasmuth@c-76-98-219-171.hsd1.nj.comcast.net] has joined
#go-nuts
03:49 -!- skelterjohn [~jasmuth@c-76-98-219-171.hsd1.nj.comcast.net] has quit
[Client Quit]
03:57 -!- mnoel [~mnoel@c-75-65-250-60.hsd1.la.comcast.net] has quit [Quit: mnoel]
04:00 < plexdev> http://is.gd/holSt by [Robert Griesemer] in
go/src/cmd/godoc/ -- godoc: compute search index for all file systems under
godoc's observation
04:08 -!- XenoPhoenix [~Xeno@cpc5-aztw24-2-0-cust39.aztw.cable.virginmedia.com]
has joined #go-nuts
04:12 -!- mnoel [~mnoel@c-75-65-250-60.hsd1.la.comcast.net] has joined #go-nuts
04:23 -!- watr_ [~watr@66.183.108.186] has joined #go-nuts
04:36 -!- watr_ [~watr@66.183.108.186] has quit [Ping timeout: 265 seconds]
04:37 -!- res99 [~anonymous@201.237.130.70] has joined #go-nuts
04:42 -!- yinruzhi [~zhi@2001:da8:e000:90:0:5efe:a79:2abc] has left #go-nuts []
05:00 -!- adu [~ajr@pool-173-66-11-168.washdc.fios.verizon.net] has joined
#go-nuts
05:04 < |Craig|> running my code on a type defined as an int runs more than
twice as fast as a struct containing an int.  I thought it would just be an int at
runtime either way, but apparently not.  I'll have to investigate what operations
caused it
05:08 -!- zozoR [~zozoR@5634798d.rev.stofanet.dk] has joined #go-nuts
05:13 < |Craig|> ha, deleting the name for my return parameter makes my code
run slower.
05:14 < |Craig|> I might as well name it optimization, as thats all its
there for.
05:15 < |Craig|> 2% difference on my benchmark from one output parameter
getting named on a method thats not even called every time in my inner loop
05:16 -!- ajstarks [~ajstarks@pool-98-109-198-180.nwrknj.fios.verizon.net] has
joined #go-nuts
05:17 -!- ajstarks [~ajstarks@pool-98-109-198-180.nwrknj.fios.verizon.net] has
left #go-nuts []
05:19 -!- watr_ [~watr@66.183.108.186] has joined #go-nuts
05:20 < |Craig|> seems to make less of a difference if I tight loop the
method, but still 1%.  And that method that does some actual processing,
05:24 -!- Eridius [~kevin@unaffiliated/eridius] has quit [Ping timeout: 264
seconds]
05:25 -!- Wiz126 [Wiz@h62.126.232.68.ip.windstream.net] has quit [Quit: EOF]
05:25 -!- watr_ [~watr@66.183.108.186] has quit [Ping timeout: 245 seconds]
05:26 -!- Makoryu [~bloodgog@pool-71-174-191-10.bstnma.fios.verizon.net] has quit
[]
05:39 -!- adu [~ajr@pool-173-66-11-168.washdc.fios.verizon.net] has quit [Quit:
adu]
05:45 -!- mikespook [~mikespook@58.61.201.77] has quit [Quit: Leaving.]
06:04 -!- res99 [~anonymous@201.237.130.70] has quit [Ping timeout: 245 seconds]
06:07 -!- zozoR [~zozoR@5634798d.rev.stofanet.dk] has quit [Quit: Morten.  Desu~]
06:08 -!- watr_ [~watr@66.183.108.186] has joined #go-nuts
06:10 -!- res99 [~anonymous@201.237.130.70] has joined #go-nuts
06:12 -!- piyushmishra [~piyushmis@117.200.230.148] has joined #go-nuts
06:14 -!- kingfishr [~kingfishr@c-24-130-147-77.hsd1.ca.comcast.net] has quit
[Remote host closed the connection]
06:17 -!- kingfishr [~kingfishr@c-24-130-147-77.hsd1.ca.comcast.net] has joined
#go-nuts
06:17 -!- piyushmishra [~piyushmis@117.200.230.148] has quit [Ping timeout: 255
seconds]
06:20 -!- watr_ [~watr@66.183.108.186] has quit [Ping timeout: 276 seconds]
06:34 -!- piyushmishra [~piyushmis@117.200.224.55] has joined #go-nuts
06:36 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has joined #go-nuts
06:37 -!- piyushmishra [~piyushmis@117.200.224.55] has quit [Client Quit]
07:03 -!- Tv [~tv@cpe-76-168-227-45.socal.res.rr.com] has quit [Ping timeout: 272
seconds]
07:04 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:a138:e483:f1a7:8dde] has quit
[Read error: Operation timed out]
07:07 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Quit: Leaving]
07:13 -!- iant [~iant@216.239.45.130] has quit [Read error: Connection reset by
peer]
07:15 -!- thhooommmm [~thom@70-139-188-39.lightspeed.hstntx.sbcglobal.net] has
joined #go-nuts
07:16 -!- bjarneh [~bjarneh@1x-193-157-207-85.uio.no] has joined #go-nuts
07:17 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
07:20 -!- res99 [~anonymous@201.237.130.70] has quit [Remote host closed the
connection]
07:20 -!- thhooommmm [~thom@70-139-188-39.lightspeed.hstntx.sbcglobal.net] has
quit [Ping timeout: 276 seconds]
07:21 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:2c8a:d77e:d2cd:5051] has joined
#go-nuts
07:25 -!- thhooommmm [~thom@70-139-188-39.lightspeed.hstntx.sbcglobal.net] has
joined #go-nuts
07:30 -!- ExtraSpice [~XtraSpice@88.118.33.48] has joined #go-nuts
07:34 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has joined #go-nuts
07:34 -!- mode/#go-nuts [+v iant] by ChanServ
07:36 -!- thhooommmm [~thom@70-139-188-39.lightspeed.hstntx.sbcglobal.net] has
quit [Read error: Connection reset by peer]
07:37 -!- thhooommmm [~thom@70-139-188-39.lightspeed.hstntx.sbcglobal.net] has
joined #go-nuts
07:37 -!- thhooommmm [~thom@70-139-188-39.lightspeed.hstntx.sbcglobal.net] has
quit [Read error: Connection reset by peer]
07:45 -!- bortzmeyer1 [~bortzmeye@batilda.nic.fr] has joined #go-nuts
07:46 -!- thhooommmm [~thom@70-139-188-39.lightspeed.hstntx.sbcglobal.net] has
joined #go-nuts
08:14 -!- poolie [~mbp@canonical/launchpad/poolie] has quit [Remote host closed
the connection]
08:16 -!- sxs [~sxs@e180005158.adsl.alicedsl.de] has joined #go-nuts
08:17 < sxs> hi
08:19 -!- ucasano [~ucasano@host153-182-static.227-95-b.business.telecomitalia.it]
has joined #go-nuts
08:19 < sxs> what is the best practice to mark a test function as
incomplete?
08:20 < sxs> i search s.th.  kike testing.T.MarkIncomplete("foo bar")
08:27 -!- sxs [~sxs@e180005158.adsl.alicedsl.de] has quit [Quit: sxs]
08:27 -!- thhooommmm [~thom@70-139-188-39.lightspeed.hstntx.sbcglobal.net] has
quit [Read error: Connection reset by peer]
08:28 -!- fluf^arr [~camelid@s.pl0rt.org] has joined #go-nuts
08:28 -!- fluffle [~camelid@s.pl0rt.org] has quit [Read error: Connection reset by
peer]
08:28 -!- kimelto [~kimelto@sd-13453.dedibox.fr] has quit [Read error: Connection
reset by peer]
08:28 -!- kimelto [~kimelto@sd-13453.dedibox.fr] has joined #go-nuts
08:29 -!- serbaut1 [~joakims@88.80.182.68] has joined #go-nuts
08:29 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:2c8a:d77e:d2cd:5051] has quit
[Quit: Leaving.]
08:30 -!- aconran [~aconran@adsl-76-199-140-78.dsl.pltn13.sbcglobal.net] has quit
[Ping timeout: 245 seconds]
08:30 -!- bortzmeyer1 [~bortzmeye@batilda.nic.fr] has quit [Quit: Leaving.]
08:31 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
08:32 -!- serbaut [~joakims@88.80.182.68] has quit [Ping timeout: 245 seconds]
08:38 -!- cco3 [~conley@c-69-181-138-209.hsd1.ca.comcast.net] has quit [Ping
timeout: 240 seconds]
08:42 -!- awidegreen [~quassel@p5DF1F795.dip.t-dialin.net] has joined #go-nuts
08:48 -!- wrtp [~rog@92.17.98.41] has joined #go-nuts
08:53 -!- photron_ [~photron@port-92-201-129-190.dynamic.qsc.de] has joined
#go-nuts
09:00 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has quit [Ping
timeout: 245 seconds]
09:24 -!- araujo [~araujo@190.38.50.25] has joined #go-nuts
09:24 -!- araujo [~araujo@190.38.50.25] has quit [Changing host]
09:24 -!- araujo [~araujo@gentoo/developer/araujo] has joined #go-nuts
09:32 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
09:35 -!- sahid [~sahid@LNeuilly-152-21-22-10.w193-253.abo.wanadoo.fr] has quit
[Quit: Ex-Chat]
09:46 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has joined #go-nuts
09:46 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has quit [Ping
timeout: 245 seconds]
09:49 -!- virtualsue [~chatzilla@nat/cisco/x-vejzhwtdohcsqmcq] has joined #go-nuts
09:54 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Ping timeout: 240
seconds]
09:57 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has joined #go-nuts
09:57 -!- mode/#go-nuts [+v iant] by ChanServ
10:00 -!- tvw [~tv@e176006126.adsl.alicedsl.de] has joined #go-nuts
10:00 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has quit [Remote host closed
the connection]
10:12 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Ping timeout: 245
seconds]
10:17 -!- Tv [~tv@cpe-76-168-227-45.socal.res.rr.com] has joined #go-nuts
10:21 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
10:24 -!- mbohun [~user@ppp115-156.static.internode.on.net] has quit [Ping
timeout: 276 seconds]
10:27 -!- sacho [~sacho@90-154-151-43.btc-net.bg] has quit [Quit: Ex-Chat]
10:30 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|]
10:33 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
10:34 -!- Tv [~tv@cpe-76-168-227-45.socal.res.rr.com] has quit [Ping timeout: 265
seconds]
10:38 -!- wrtp_ [~rog@212.183.140.8] has joined #go-nuts
10:38 -!- wrtp__ [~rog@92.17.98.41] has joined #go-nuts
10:39 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|]
10:39 -!- wrtp [~rog@92.17.98.41] has quit [Read error: Connection reset by peer]
10:42 -!- wrtp_ [~rog@212.183.140.8] has quit [Ping timeout: 240 seconds]
10:58 -!- ecki_ [~ecki@gateway.multimediahaus.de] has joined #go-nuts
10:59 -!- tensorpudding [~user@99.148.202.191] has quit [Remote host closed the
connection]
11:00 -!- ecki_ [~ecki@gateway.multimediahaus.de] has quit [Client Quit]
11:02 -!- gnuvince1 [~vince@72.0.215.147] has joined #go-nuts
11:04 -!- gnuvince_ [~vince@70.35.171.47] has quit [Ping timeout: 272 seconds]
11:04 -!- qutron_xyxy [~xxx@91.187.0.48] has joined #go-nuts
11:13 -!- niemeyer [~niemeyer@189-10-175-46.pltce701.dsl.brasiltelecom.net.br] has
joined #go-nuts
11:24 -!- foocraft [~dsc@78.101.147.68] has joined #go-nuts
11:27 -!- qutron_xyxy [~xxx@91.187.0.48] has quit [Quit: Leaving]
11:28 -!- bjarneh [~bjarneh@1x-193-157-207-85.uio.no] has quit [Quit: leaving]
11:30 -!- ucasano [~ucasano@host153-182-static.227-95-b.business.telecomitalia.it]
has quit [Quit: ucasano]
11:33 -!- rbraley [~rbraley@ip72-222-128-78.ph.ph.cox.net] has quit [Ping timeout:
250 seconds]
11:38 -!- rbraley [~rbraley@ip72-222-128-78.ph.ph.cox.net] has joined #go-nuts
11:41 -!- andrebq [~chatzilla@189.107.166.251] has joined #go-nuts
11:42 < andrebq> goyacc works as a lexer to?  if not, somebody has any
suggestion on how to create the lexer?
11:49 -!- ceh [~ceh@celsius.it.uu.se] has joined #go-nuts
11:54 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3]
11:57 -!- ceh [~ceh@celsius.it.uu.se] has left #go-nuts []
12:09 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has joined #go-nuts
12:17 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts
12:21 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
12:36 < wrtp> andrebq: you can use all kinds of things as a lexer
12:37 < wrtp> one easy possibility is to use the scanner package
12:37 < wrtp> (you'll have to write a shim function mapping scanner
constants to your yacc constants)
12:38 < andrebq> wrtp: any automated lexer generator, like lex for Go?
12:39 < nsf> andrebq: also http://www.complang.org/ragel/ supports Go (in
trunk for now)
12:39 < nsf> I don't know about others, but I prefer to use it for writing
lexers
12:39 < wrtp> andrebq: writing a lexer is not hard.  lex is a beast
12:39 < andrebq> :)
12:40 < wrtp> what kind of lexing are you wanting to do?
12:40 < wrtp> oh yes, fmt.Scan* can be used for lexing without too much
difficulty
12:43 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has quit [Remote
host closed the connection]
12:49 -!- napsy [~luka@88.200.96.18] has joined #go-nuts
12:52 < andrebq> I will check the fmt.Scan latter, printer and ragel later
12:52 < andrebq> thanks for the help
12:55 -!- skejoe [~skejoe@188.114.142.231] has joined #go-nuts
12:55 < KBme> it's not possible to have slice constants?
12:56 -!- mnoel [~mnoel@c-75-65-250-60.hsd1.la.comcast.net] has quit [Read error:
Connection reset by peer]
12:56 -!- mnoel [~mnoel@c-75-65-250-60.hsd1.la.comcast.net] has joined #go-nuts
12:57 -!- mnoel [~mnoel@c-75-65-250-60.hsd1.la.comcast.net] has quit [Read error:
Connection reset by peer]
12:58 < KBme> or array
13:08 < wrtp> KBme: that's right
13:11 -!- napsy [~luka@88.200.96.18] has quit [Ping timeout: 255 seconds]
13:21 -!- nighty^ [~nighty@x122091.ppp.asahi-net.or.jp] has quit [Quit: Disappears
in a puff of smoke]
13:22 -!- nighty^ [~nighty@x122091.ppp.asahi-net.or.jp] has joined #go-nuts
13:31 -!- sacho [~sacho@90-154-151-43.btc-net.bg] has joined #go-nuts
13:33 -!- plainhao [~plainhao@208.75.85.237] has joined #go-nuts
13:50 -!- andrebq_ [~chatzilla@189.107.239.230] has joined #go-nuts
13:50 -!- Fish [~Fish@9fans.fr] has joined #go-nuts
13:50 < KBme> so, how would one define a constant list of strings (for
example) in a library?
13:51 -!- andrebq [~chatzilla@189.107.166.251] has quit [Ping timeout: 240
seconds]
13:51 < nsf> you can't, just define a simple var
13:51 < nsf> it is optimized in a special way by compiler
13:52 < nsf> in Go 'const' is not about restricting access to data
13:52 < wrtp> KBme: you have to trust to clients not to alter your data.  or
you can choose not to export it.
13:53 < nsf> yeah, you can write an accessor function
13:53 < nsf> which will ensure that no one will touch your list
13:53 < wrtp> strings themselves are read-only, so they will live in
read-only memory
13:54 < KBme> that's fine
13:54 < andrebq> KBme: a constant list of strings isn't a just a list of
const strings ?
13:54 < KBme> but it's just a "header" file
13:54 < KBme> so outside any function I can do var foo = ["foo", "bar"] ?
13:54 < wrtp> an interesting question is what happens when you're trying to
target an embedded platform with loads more ROM than RAM.
13:54 -!- plainhao [~plainhao@208.75.85.237] has quit [Quit: plainhao]
13:54 < nsf> KBme: no, the syntax is: var foo = []string{"foo", "bar"}
13:55 -!- plainhao [~plainhao@208.75.85.237] has joined #go-nuts
13:55 < KBme> oops right
13:55 < KBme> i can do that outside a function body?
13:55 < nsf> yes
13:55 < KBme> ok cool
13:55 < wrtp> i think the linker should be able to work out that some global
arrays are never altered, and move them to read-only memory
13:55 < KBme> that's fine with me
13:55 < nsf> also you can create an array
13:55 < nsf> var foo = [...]string{"foo", "bar"}
13:55 < KBme> ah
13:55 < KBme> better
13:55 < nsf> more chances that its initialization will be optimized away by
compiler
13:56 < KBme> didn't know the [...]string literal usage
13:56 < nsf> but it should be true for slices as well
13:56 < wrtp> KBme: it's not often used.
13:56 < wrtp> KBme: one advantage is that the compiler can do bounds checks
at compile time
13:56 -!- zozoR [~zozoR@5634798d.rev.stofanet.dk] has joined #go-nuts
13:57 < nsf> wrtp: certain bounds checks
13:57 < nsf> where an index is knows at compile-time
13:57 < nsf> known*
13:57 -!- ucasano [~ucasano@host153-182-static.227-95-b.business.telecomitalia.it]
has joined #go-nuts
13:58 < nsf> but you're right, arrays currently are mostly unused feature
13:58 < nsf> hopefully if someone will add proper escape analysis
(interprocedural one)
13:58 < nsf> they will find their place
13:59 < wrtp> i don't know why arrays should be any different to slices in
that case.
14:00 < nsf> yeah, compiler can optimize them as well in that case
14:00 < wrtp> yup
14:00 < nsf> and place on the stack
14:00 < wrtp> a slice is just like a pointer to an array with some extra
info.
14:01 < nsf> and when you create a slice with 'new' actually an array is
being allocated
14:01 < wrtp> i have a feeling that go will get a lot faster when this is
done
14:01 < nsf> it should be
14:01 < nsf> another important missing feature
14:01 < nsf> is autoinlining
14:02 < nsf> hehe, and you've pointed that just now on the ML :)
14:02 -!- napsy [~luka@88.200.96.18] has joined #go-nuts
14:02 < nsf> pointed out*
14:02 -!- skejoe_ [~skejoe@188.114.142.231] has joined #go-nuts
14:02 * nsf sighs
14:03 < nsf> especially with Go's additional overhead for function calls
14:03 < nsf> inlining is super important
14:04 < nsf> from the performance point of view
14:05 -!- skejoe [~skejoe@188.114.142.231] has quit [Ping timeout: 240 seconds]
14:06 < exch> I hope that packing a value into an interface{} can also be
made faster
14:06 < nsf> is it slow?
14:06 < exch> fairly slow, yes
14:06 < nsf> well, it's an allocation currently
14:07 < exch> Ya. it seems a new interface{} structure is created which
holds the type info + value
14:07 < nsf> and you can't avoid that
14:07 < nsf> because interface{} needs to maintain copy semantics
14:07 < nsf> but
14:07 -!- skelterjohn [~jasmuth@c-76-98-219-171.hsd1.nj.comcast.net] has joined
#go-nuts
14:07 < nsf> with escape analysis it is possible to place a fresh value on
the stack
14:07 < nsf> in some cases
14:07 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has quit [Quit:
Leaving.]
14:08 < nsf> but I bet it's a rare use case
14:08 -!- fafhrd [~fafhrd@unaffiliated/fafhrd] has left #go-nuts []
14:08 < nsf> exch: it doesn't hold the type info, it points to the type info
14:08 < exch> fair enough
14:09 < nsf> I thought that the most expensive operation is a run-time
virtual table creation
14:09 < nsf> but it should be optimized away in most cases
14:10 < nsf> for example if compiler sees that you're casting concrete type
A to interface type B, the operation should be nearly instant
14:10 < nsf> especially if type A is a pointer type
14:11 < exch> I hope it can be that fast
14:11 < nsf> but interface -> interface type assertion will always be
slow
14:11 < nsf> and that's a common thing
14:11 < exch> Currently it's a bottleneck in my VM code.  The stack is the
heart of the VM and requires lightspeed performance.  The conversions from
concrete types to interface{} is where things slow down considerably
14:12 < nsf> because interface{} is overused
14:12 < exch> I tried using some other means to store the values in the
stack, but interface{} seems to be the fastest of the bunch
14:12 < nsf> exch: it shouldn't be that way
14:12 < nsf> casting pointer type to interface{} should be very fast
14:13 < nsf> no need for virtual methods table, just the pointer and a type
info pointer
14:13 < nsf> 8 bytes on x86
14:13 < nsf> maybe there is a bug in compiler :)
14:13 < exch> It's not always a pointer type, but I think I can play around
with that and see if I can make sure the stack code always uses pointers to values
instead of the concrete values
14:14 < exch> Would be interesting to see how that affects performance
14:14 < nsf> in case if it's not a pointer type and type size is bigger than
size of a pointer
14:14 < nsf> then it's an allocation of that size
14:14 < nsf> a copy
14:14 < exch> I was afraid of that
14:14 < nsf> and two pointer assignments
14:15 < nsf> exch: is your code available online?
14:16 < nsf> I'm curious :)
14:16 < exch> Not at the moment
14:16 < nsf> ok
14:16 < Namegduf> Interface values should be kept on the stack
14:16 -!- andrebq [~chatzilla@189.107.239.230] has quit [Read error: Connection
reset by peer]
14:16 < Namegduf> I'm not sure why you'd ever take the address of one.
14:16 < nsf> Namegduf: if it's possible
14:16 < Namegduf> nsf: I think the only case it wouldn't would be closures
14:17 < Namegduf> You'd be passing it to stuff by value.
14:17 < nsf> no, the one and the most important one case is when interface
value escapes the current function
14:17 < nsf> then you have to move that value to heap
14:17 < exch> nsf: This is part of an older attempt.  The current one is
somewhat different, but the same problem occurs here as well:
https://github.com/jteeuwen/gvm/blob/master/vm/stack.go
14:17 < Namegduf> nsf: It can't.
14:17 < Namegduf> Unless you take the address of it.
14:17 < nsf> Namegduf: interface value is a pointer
14:17 < nsf> 8 bytes
14:17 < Namegduf> Right.
14:17 < nsf> pointer to the data
14:17 < nsf> and pointer to the type info
14:18 < Namegduf> I'm saying the interface value itself
14:18 < Namegduf> Will not be expensive to allocate
14:18 < Namegduf> As it will almost certainly be able to stay on the stack.
14:18 < nsf> yes, I understand
14:18 < nsf> but here you have to choose
14:18 < nsf> expensive copy
14:18 < nsf> or expensive alloc
14:19 < nsf> giving the fact that interfaces used a lot as function
arguments
14:19 < Namegduf> Yeah, but that won't be expensive.
14:19 < Namegduf> You're passing by value, which is not an escape.
14:19 < nsf> I guess making them pointers makes sense
14:19 < nsf> also
14:19 < KBme> :(
14:19 < nsf> interface should be able to hold data of any size
14:20 < KBme> so in netchan: i can't send a message on a channel and have
multiple people get the message?
14:20 < nsf> Namegduf: but interface is a pointer
14:20 < nsf> it is an escape :)
14:20 < exch> I did consider having the stack use integer 'addresses' of
values.  That significantly speeds it up, but then the data has to be stored
somewhere else, which just moves the issue to a different part of the code
14:20 < KBme> or with channels in general maybe
14:20 < Namegduf> An escape of what?
14:20 < KBme> like a "multicast" thing
14:20 < nsf> for example
14:20 < Namegduf> I was under the impression we were discussing the
conversion of a pointer to an interface.
14:20 < nsf> you have a function
14:20 < Namegduf> Both cause the thing pointed AT to escape
14:20 < nsf> it creates a var A int
14:20 -!- napsy [~luka@88.200.96.18] has quit [Ping timeout: 260 seconds]
14:20 < Namegduf> An int will not, in fact, have a pointer
14:20 < nsf> and assigns in to interface var B interface{} = A
14:21 < Namegduf> Types less than a word in size
14:21 < nsf> well, just imagine int is 128 bytes
14:21 < Namegduf> Are placed inside the interface
14:21 < nsf> or whatever :)
14:21 < nsf> my bad
14:21 < Namegduf> I can see what you mean, I just think it's less bad for
most basic types.
14:21 < nsf> var A BigStruct
14:21 < nsf> var B interface{} = A
14:21 < exch> KBme: Multiple receivers can listen on a channel, but a single
value can only be consumed once.  Not sure how that works for netchan though.
Doesn't that require explicitely setting a single Source and Destination endpoint?
14:22 < nsf> now B is 8 bytes long and at the moment let's suppose it holds
a pointer to a new instance of BigStruct but allocated on the stack
14:22 < nsf> but now if B escapes the function
14:22 < nsf> this value should be moved to the heap
14:22 < KBme> exch: no, i can import a channel multiple times but then
that's useless for me
14:23 < KBme> so i can't select on a map/slice of channels and can't have a
"multicast" channel...hmmmm
14:23 < KBme> touch
14:23 < KBme> tough*
14:23 < nsf> Namegduf: you can't avoid using pointer inside interface
implementation
14:23 < Namegduf> nsf: Yeah.
14:24 -!- skejoe_ [~skejoe@188.114.142.231] has quit [Quit: Lost terminal]
14:24 < Namegduf> That said, if the interface the type matches matches a
POINTER TO THE TYPE, rather than the type itself
14:24 < Namegduf> i.e.  some of the methods expect a pointer to, not the
type itself
14:24 < Namegduf> You're using the pointer anyway.
14:24 < nsf> yes
14:24 < Namegduf> So the case that you'd want a >word struct is kinda
rare.
14:24 < Namegduf> I'd expect to see perhaps point/vector structs
14:24 < nsf> exactly
14:25 < Namegduf> 2-4 word things.
14:25 < nsf> but still, interface{} can cause allocation
14:25 -!- skelterjohn [~jasmuth@c-76-98-219-171.hsd1.nj.comcast.net] has quit
[Quit: skelterjohn]
14:25 < nsf> because even though it is a pointer, it maintains a copy
semantics
14:25 < Namegduf> It requires referencing if larger than a word, yes.
14:25 < nsf> what I was talking about
14:25 < nsf> is that it is possible in some cases to avoid that allocation
14:26 < nsf> with escape analysis
14:26 < nsf> but that's just a rare case
14:26 < nsf> not sure if anyone even cares
14:26 < nsf> we need to fight interface{} overuse
14:26 < nsf> not optimizing it :)
14:26 < Namegduf> It'd be nice to, for small structs.
14:28 < nsf> and I strongly recommend to read Russ' blog post about
interfaces implementation
14:29 < nsf> it's not a black box and it's not a magic, its usage has
advantages and downsides
14:33 < nsf> exch: I see, []interface{} as a stack
14:33 < nsf> imho it's a very bad idea
14:33 < nsf> :D
14:33 < exch> I know
14:33 < nsf> well, writing VM in Go is generally a bad idea
14:33 < nsf> you need the level of C, C++ provides that as well
14:34 < exch> If there's a viable alternative in Go, im all ears :p
14:34 < exch> I tried storing the objects as raw []byte slices.  But the
unsafe magic required to make that happen is even slower
14:36 < nsf> C is better
14:37 -!- iant [~iant@67.218.104.238] has joined #go-nuts
14:37 -!- mode/#go-nuts [+v iant] by ChanServ
14:37 < exch> It is, but I like exploring Go and it's uses :p
14:37 -!- napsy [~luka@88.200.96.18] has joined #go-nuts
14:37 < nsf> well, if you do it for fun, then python is ok, but otherwise
you won't be able to compete with other VMs :)
14:38 < nsf> maybe it is sad
14:38 < nsf> but it's true
14:38 < exch> I have no intention of competing with them.  it's just a
playground.
14:38 < exch> yea, it's a shame really
14:38 < nsf> then Go is fine and interface{} is fine
14:38 < nsf> :)
14:39 -!- mcot_ [~mcot@pool-71-171-113-161.clppva.fios.verizon.net] has quit [Ping
timeout: 240 seconds]
14:39 < exch> Up until now the lack of performance didn't bother me, but I
find myself wondering more and more if I can't fix it :p
14:39 < exch> Perhaps it's time to switch to C for this particular project
then
14:40 < nsf> Go is too young, of course there is a lot of room for
performance experiments, but you know..  it's other project or a way of wasting
your time :)
14:41 < nsf> a lot of performance experiments are a failure
14:41 < nsf> or maybe it's just me :)
14:41 < exch> I've been thinking though, in that particular situation Go
could probably benefit from having Unions
14:41 < nsf> yes
14:41 < nsf> I'd love to see them
14:41 < exch> me to
14:42 < nsf> but as I've said before
14:42 < uriel> exch: stupid question, but what is the project and why is Go
too slow?
14:42 < nsf> I can't implement them
14:42 <+iant> We had a proposal for unions for a while, but they would up
looking a lot like interfaces
14:42 < nsf> therefore I'm silent
14:42 < nsf> actually all I want from unions is to be like C unions
14:42 < nsf> but there are problems with that approach
14:42 -!- lmoura_ [~lauromour@187.113.168.168] has joined #go-nuts
14:42 < nsf> especially with garbage collector
14:42 < nsf> it can't be precise in that way
14:43 <+iant> in a language like Go you kind of want to know the type of the
value in the union, so that reflection works
14:43 <+iant> C unions are obviously not type safe
14:43 < exch> uriel: it's one of my many attempts at a VM
14:44 <+iant> so then a union has a type and a value, and that is what an
interface is
14:44 < nsf> iant: well, it means compiler will use type checks implicitly,
I want unions exactly because they are required for speed
14:44 < exch> uriel: Also not 'too slow', ust not quite as fast as I hoped
it would be.  In particular the whole interface{} thing we discussed up there ^
14:44 < nsf> with type info they are interfaces indeed
14:44 < nsf> hehe
14:44 < nsf> yeah
14:44 -!- lmoura [~lauromour@187.113.175.203] has quit [Ping timeout: 260 seconds]
14:44 < nsf> although I think it would be possible to benefit from different
memory model
14:45 < nsf> union is not a pointer type
14:45 -!- artefon [~thiago@dhcp34.usuarios.dcc.ufmg.br] has joined #go-nuts
14:45 <+iant> what should happen if you pass a union to a function by value?
14:45 < nsf> copy all the data
14:45 < nsf> even if it's garbage
14:45 <+iant> I guess it could use a pointer behind the scenes
14:46 < nsf> no no no
14:46 <+iant> or you mean pass the largest size?
14:46 < nsf> the whole point of having unions
14:46 < nsf> is stack-like structures
14:46 <+iant> sure
14:47 < nsf> therefore it should be: <4 bytes, pointer to type info>
<N bytes (where N is max of all possible type sizes) of data>
14:47 <+iant> ok
14:47 < nsf> that's my view, I don't know
14:47 < nsf> maybe there are better ways
14:47 < nsf> frankly I don't need those 4 bytes at the beginning, but memory
safety requires it
14:48 < nsf> or other way to identify the type
14:48 < nsf> but at least
14:48 < nsf> it gives some kind of a better memory locality
14:48 < nsf> in some cases
14:48 < nsf> :D
14:49 < nsf> which are mostly stack structures
14:49 -!- wrtp [~rog@92.17.98.41] has quit [Ping timeout: 255 seconds]
14:49 < exch> datastores or really any type of 'generic' container
14:49 <+iant> what are the types you are putting in the union?
14:50 < nsf> I need unions for parser generator (lemon), it uses stack
internally for user defined types, mostly they are pointers, but sometimes they
are not
14:50 < nsf> currently as exch I use []interface{}
14:50 < nsf> I don't think it's slow though
14:50 < nsf> but it's slower than C version
14:50 < nsf> obviously
14:50 < exch> iant: so far it's limited to a few basic types + one custom
type.  int64, float64, string and a custom Map like type
14:51 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has joined #go-nuts
14:55 -!- wrtp [~rog@92.17.98.41] has joined #go-nuts
14:55 < nsf> in C++0x unions are scary
14:55 < nsf> because of ctors and dtors
14:56 < wrtp> nsf: what did you mean by "Go's additional overhead for
function calls"?
14:56 < nsf> wrtp: Go has dynamic stack size
14:56 < nsf> it adds additional overhead for each function call
14:56 < exch> You can get union behaviour in Go with some unsafe magic, but
it's pretty slow.  The question with 'proper' unions would be, if it can be made
to be faster than the unsafe approach
14:56 < nsf> it's not big, but it means it just adds cycles that are
optimized away with inlining
14:57 < nsf> exch: the real problem is garbage collector
14:57 < nsf> if it doesn't know the real type of a union
14:57 < nsf> it can't do precise marking
14:57 < exch> ya, I understand it's not exactly a safe way to just bypass
the type system
14:58 < exch> hence the 'unsafe' :p
14:58 < nsf> yeah
14:58 < wrtp> nsf: with inter-procedural analysis, you can probably get away
with many fewer checks on stack size
14:58 < nsf> wrtp: true, but inlining is not just about that
14:58 < nsf> you see, there is a room for improvement definitely
14:59 < wrtp> i was thinking about addressing your comment about go's
function call overhead.
14:59 < wrtp> of course in-lining is also a useful optimisation.
14:59 < nsf> currently we don't have inter-procedural analysis
15:00 < nsf> it's much easier to do inlining :)
15:00 < wrtp> i'd like type-safe unions.  they're great for channel
protocols, amongst other things.
15:00 -!- Project_2501 [~Marvin@82.84.79.101] has joined #go-nuts
15:00 < wrtp> inlining requires interprocedural analysis by definition :-)
15:00 <+iant> for a channel I think an interface is always going to be as
efficient as a type-safe union
15:01 < nsf> wrtp: well, yeah
15:01 < nsf> I guess both things mentioned are equally easy/hard to
implement
15:01 -!- foocraft [~dsc@78.101.147.68] has quit [Ping timeout: 245 seconds]
15:02 < wrtp> iant: it's not for efficiency that i'd like them - it's for
type safety and documentation
15:02 < nsf> one does preallocation of the stack size, other inlines code
15:02 <+iant> interfaces are just as type safe, so it's for documentation
then
15:03 < wrtp> interfaces aren't as statically type safe
15:03 <+iant> OK, fair enough
15:04 < wrtp> e.g.  when i see the go parser code, it's not clear what the
various node types are without going through all the documentation looking for
them.  a union might be better there.
15:04 < wrtp> and i think a type-safe union could be faster than an
interface when the size of the type passed over the channel is greater than
pointer-sized.
15:05 < wrtp> because you wouldn't have to allocate
15:05 < nsf> you should use gortfm :)
http://nsf.github.com/go/go_ast.html?t:stmt
15:05 < nsf> it can filter them out easily by name
15:05 <+iant> I would have to look at the channel implementation
15:06 -!- mcot_ [~mcot@65.196.71.3] has joined #go-nuts
15:06 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has quit [Quit:
noktoborus_]
15:06 < wrtp> nsf: that's ok only if the names that implement the interface
all have something in common...
15:06 < nsf> wrtp: as a matter of fact I think lack of type hierarchies
improves documentation
15:07 < nsf> because some people think that type hierarchies are somewhat
self-documenting
15:07 < nsf> they are not
15:07 < nsf> really..
15:07 < wrtp> nsf: i agree in general, but i think unions don't count as
type hierarchies
15:08 < nsf> but then you can't use them for documentation in many places :)
15:11 -!- Rotham [~Roth@uccs.232.21.53.206.cos.dyn.pcisys.net] has joined #go-nuts
15:11 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has joined #go-nuts
15:13 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has joined #go-nuts
15:15 -!- foocraft [~dsc@78.101.147.68] has joined #go-nuts
15:22 -!- tav_ [~tav@92.7.92.66] has joined #go-nuts
15:22 -!- tav [~tav@92.7.92.66] has quit [Read error: Connection reset by peer]
15:22 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has joined #go-nuts
15:23 -!- Venom_X [~pjacobs@74.61.90.217] has joined #go-nuts
15:26 -!- DerHorst [~Horst@e176096196.adsl.alicedsl.de] has joined #go-nuts
15:30 -!- iant [~iant@67.218.104.238] has quit [Ping timeout: 245 seconds]
15:30 -!- iant [~iant@216.239.45.130] has joined #go-nuts
15:30 -!- mode/#go-nuts [+v iant] by ChanServ
15:31 -!- foocraft [~dsc@78.101.147.68] has quit [Quit: Leaving]
15:35 -!- foocraft [~dsc@78.101.147.68] has joined #go-nuts
15:36 < skelterjohn> good morning
15:45 < wrtp> beautiful sunset here :-)
15:46 < skelterjohn> eastern europe?
15:46 < nsf> skelterjohn: don't think so
15:47 < skelterjohn> well, west europe is 5-6 hours ahead of where i am
(east coast US)
15:47 < skelterjohn> and it's 11 for me, so i figure you'd need a couple
more hours for it to be sunset
15:47 < nsf> it's morning in the US
15:47 < nsf> west coast
15:47 < nsf> yeah
15:47 < nsf> but other way
15:47 < nsf> 19:00 Moscow time
15:48 < skelterjohn> that's a good time for sunset
15:48 < wrtp> northern england
15:48 < skelterjohn> ah
15:48 < skelterjohn> 5pm for you?
15:48 < nsf> ok, I thought about dawn kind of sunset :)
15:48 < skelterjohn> nsf: that's sunrise :)
15:48 < wrtp> almost 4pm
15:48 < nsf> ah, yes
15:48 < nsf> my bad
15:49 <+iant> it's all just the earth turning
15:49 < nsf> hehe
15:49 < nsf> indeed
15:50 * skelterjohn wishes dropbox would enable the "exclude" feature and stop
copying .6 files all over the place
15:50 < nsf> make clean?
15:50 < wrtp> the earth turning...  and daylight savings time turning off,
so evenings suddenly get darker :-(
15:50 < skelterjohn> nsf: it copies them the moment they're created
15:50 < nsf> ah, shared folder
15:51 < skelterjohn> yeah
15:51 < nsf> I don't get that windowish stuff
15:51 < nsf> :D
15:51 -!- Venom_X [~pjacobs@74.61.90.217] has quit [Ping timeout: 240 seconds]
15:51 < skelterjohn> it's copying between a mac and a linux box :)
15:51 < nsf> e.g.  trying to be supersmart doing what you have never
expected
15:51 < nsf> use ssh
15:51 < skelterjohn> are you familiar with dropbox?
15:51 < nsf> yes
15:52 < nsf> I'm a console junkie, so I don't really by all that drag'n'drop
stuff
15:52 < nsf> buy*
15:52 < skelterjohn> ok, well, it's somewhat more convenient for syncing
folders on multiple computers than ssh is
15:52 < skelterjohn> dropbox works fine from the console.  in fact, it has
no UI at all
15:52 < nsf> sshfs is better for me
15:52 -!- Venom_X [~pjacobs@66.54.185.131] has joined #go-nuts
15:52 < skelterjohn> sshfs is nice, but then the files actually reside on
the remote machine
15:52 < skelterjohn> so doing io on them has high latency
15:53 < skelterjohn> with dropbox, the files reside on both machines
15:53 < skelterjohn> so i can work in the dropbox folder like any other, and
it will sync in the background
15:53 < skelterjohn> very useful
15:53 < nsf> true, but two scenarios: fast network or you have to wait
anyway for sync
15:53 < skelterjohn> waiting for sync isn't the problem.  it's the automatic
sync that i like
15:54 < skelterjohn> usually the wait between using one computer or another
is the drive home, so no problems there
15:54 < IRWolfie-> to sync important files I'd use version control :/
15:54 < nsf> ok, I don't mind, use whatever you like :)
15:54 < skelterjohn> sync and version control are two different things you
could want to do
15:54 < skelterjohn> i also use version control
15:55 < nsf> although you're right
15:55 < skelterjohn> and please don't think i'm just being contrary - i
intend only to share my opinion
15:55 < nsf> exclude feature for sync app is necessary
15:56 < nsf> sure, we all do
15:56 < skelterjohn> backups, sync between computers and version control are
different applications.  it just happens that people used cvs/svn for all three
15:56 < skelterjohn> but now i've got dropbox for sync and git/hg for
version control
15:56 < skelterjohn> and i find it all very convenient
15:56 * nsf loves that 'tar' has exclude feature
15:57 < nsf> very convenient
15:57 -!- gmilleramilar [~gmiller@184-106-207-119.static.cloud-ips.com] has quit
[Quit: Leaving.]
15:58 -!- iant [~iant@216.239.45.130] has quit [Quit: Leaving.]
16:05 -!- andrebq [~chatzilla@189.107.239.230] has joined #go-nuts
16:08 -!- iant [~iant@nat/google/x-oxaerbrtrqfuttgn] has joined #go-nuts
16:08 -!- mode/#go-nuts [+v iant] by ChanServ
16:13 -!- iant [~iant@nat/google/x-oxaerbrtrqfuttgn] has quit [Quit: Leaving.]
16:14 -!- andrebq [~chatzilla@189.107.239.230] has quit [Quit: ChatZilla 0.9.86
[Firefox 3.6.8/20100722155716]]
16:17 -!- DerHorst [~Horst@e176096196.adsl.alicedsl.de] has quit [Remote host
closed the connection]
16:19 -!- wrtp [~rog@92.17.98.41] has quit [Ping timeout: 240 seconds]
16:20 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has quit [Remote
host closed the connection]
16:21 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Quit: Leaving.]
16:24 -!- iant [~iant@nat/google/x-npcilkzwsiuwszdo] has joined #go-nuts
16:24 -!- mode/#go-nuts [+v iant] by ChanServ
16:24 -!- wrtp [~rog@92.17.98.41] has joined #go-nuts
16:24 -!- Rotham [~Roth@uccs.232.21.53.206.cos.dyn.pcisys.net] has quit [Remote
host closed the connection]
16:25 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has quit [Quit: Coyote finally
caught me]
16:33 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has joined #go-nuts
16:39 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3]
16:44 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has quit [Ping timeout: 240
seconds]
16:46 -!- meanburrito920 [~john@192.5.109.49] has joined #go-nuts
16:46 -!- meanburrito920 [~john@192.5.109.49] has quit [Changing host]
16:46 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has joined #go-nuts
16:46 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has joined #go-nuts
16:48 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts
16:56 -!- cco3 [~conley@c-69-181-138-209.hsd1.ca.comcast.net] has joined #go-nuts
17:11 -!- foocraft [~dsc@78.101.147.68] has quit [Quit: Leaving]
17:11 -!- eikenberry [~jae@ivanova.zhar.net] has joined #go-nuts
17:14 -!- kanru [~kanru@118-160-164-12.dynamic.hinet.net] has joined #go-nuts
17:15 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has quit [Quit:
leaving]
17:17 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has quit [Quit:
Leaving]
17:19 -!- watr_ [~watr@66.183.108.186] has joined #go-nuts
17:23 -!- watr_ [~watr@66.183.108.186] has quit [Client Quit]
17:30 -!- awidegreen_ [~quassel@p5DF1D7D4.dip.t-dialin.net] has joined #go-nuts
17:32 -!- mssm [~mssm@ip-95-221-102-122.bb.netbynet.ru] has joined #go-nuts
17:32 -!- awidegreen [~quassel@p5DF1F795.dip.t-dialin.net] has quit [Ping timeout:
245 seconds]
17:38 -!- cco3 [~conley@c-69-181-138-209.hsd1.ca.comcast.net] has quit [Ping
timeout: 260 seconds]
17:39 -!- xash [~xash@d045110.adsl.hansenet.de] has joined #go-nuts
17:40 < skelterjohn> oh need, x := append(y) will just give you a copy of y
17:40 < skelterjohn> need = neat
17:40 < wrtp> skelterjohn: i don't think so
17:40 < wrtp> i think you mean x := append(nil, y...)
17:41 < skelterjohn> oh you're right
17:41 < skelterjohn> append works in place?
17:41 < wrtp> yes
17:41 < wrtp> if there's enough capacity
17:41 < skelterjohn> yeah
17:41 < skelterjohn> i feel like the varargs packing/unpacking might make it
less efficient to do that instead of make/copy
17:42 -!- napsy [~luka@88.200.96.18] has quit [Ping timeout: 264 seconds]
17:42 < skelterjohn> needs to be, eg, append([]int{}, anIntSlice...) btw
17:42 < skelterjohn> compiler tells me that you can't do nil
17:43 < wrtp> oh, i think that may be a bug
17:43 -!- napsy [~luka@88.200.96.18] has joined #go-nuts
17:44 < skelterjohn> compiler says "first argument to append must be a
slice; have nil"
17:44 < skelterjohn> so if it's a bug, it's not accidental
17:44 -!- lmoura_ [~lauromour@187.113.168.168] has quit [Ping timeout: 264
seconds]
17:44 < wrtp> it was definitely indended that it work
17:44 < skelterjohn> just a misinterpretation on the part of whomever
implemented append
17:45 -!- fabled [~fabled@mail.fi.jw.org] has quit [Quit: Ex-Chat]
17:47 < wrtp> from gri's original post: - making a copy of a slice:
17:47 < wrtp> copy = append(nil, slice)
17:47 < wrtp> (of course, that's actually wrong as it should be slice...
17:47 < wrtp> )
17:48 -!- lmoura_ [~lauromour@187.113.168.168] has joined #go-nuts
17:48 < wrtp> i think it might be worth raising an issue, citing the
original post
17:51 -!- meanburrito920 [~john@tmp6c626d05a70e.STUDENT.CWRU.Edu] has joined
#go-nuts
17:51 -!- meanburrito920 [~john@tmp6c626d05a70e.STUDENT.CWRU.Edu] has quit
[Changing host]
17:51 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has joined #go-nuts
17:52 -!- krutcha [~krutcha@remote.icron.com] has joined #go-nuts
17:53 < skelterjohn> wish i could say append([]int, 1, []int{2,3,4}) and get
{1,2,3,4}
17:53 < skelterjohn> []int{2,3,4}...  i mean
17:54 < kimelto> it's a prepend then :)
17:54 < skelterjohn> well first i want to append 1, then i want ot append
2,3,4
17:54 < skelterjohn> but converting that to the parameter that append would
take requires an allocation anyway
17:54 < skelterjohn> so it wouldn't save me any efficiency
17:55 < wrtp> just call append twice
17:55 < skelterjohn> yeah
17:55 < wrtp> or do: append([]int{1}, []int{1,2,3,4}...)
17:56 < skelterjohn> oh, there you go
17:58 -!- mssm [~mssm@ip-95-221-102-122.bb.netbynet.ru] has quit [Ping timeout:
272 seconds]
18:00 < wrtp> or a+b+c is append(append(a, b), c)
18:00 < wrtp> oops i mean
18:00 < krutcha> is there significant overhead in calling via defer()
instead of manually?  Somebody on here the other night was mentioning a 3x
slowdown in his lock/access/unlock performance when he used defer to unlock, but I
haven't seen anything in the FAQ, the spec, the effective page, etc discussing
performance.  From what I read, defer is just a list of functions that get called,
so it shouldn't be much more than the overhead of another function call, right?
18:00 < wrtp> append(append(a, b...), c...)
18:00 < wrtp> defer involves at least one allocation and usually two
18:01 < wrtp> escape analysis might make them stack rather than heap
allocations in the future
18:01 < xash> krutcha: and even there is NOW a perfomanceleak with defer,
it's no argument, as the compiler is not optimized yet, so you shouldn't care
about
18:01 < wrtp> use defer if something you're calling might panic
18:02 < wrtp> or if performance isn't critical (i.e.  most of the time)
18:02 < Namegduf> defer also permits early returns
18:02 < wrtp> yup
18:02 < Namegduf> Without horrible tricks with using goto to manually jump
to a cleanup block or something
18:02 < wrtp> well - you can early return without defer, but you have to
remember to unlock
18:06 -!- artefon [~thiago@dhcp34.usuarios.dcc.ufmg.br] has quit [Quit: bye]
18:08 < krutcha> Are defer performance improvements reasonably prioritized
on the roadmap?  I use the crap out of it, quite happily, I just don't want to
paint myself into a corner by doing so
18:09 < krutcha> wrtp: what methods of early return wouldn't hit defer?  or
did I misunderstand you
18:09 < Namegduf> You do; he's saying early return without defer.
18:14 < wrtp> yup
18:15 < wrtp> krutcha: i dunno.  but performance improvements are definitely
on the roadmap, and the core go code uses defer all over the place, so i think
it's a reasonable likelyhood
18:17 < krutcha> I think the safety and code cleanup defer() offers is hard
to pass up.  Does this mean the allocations mentioned would be done then at the
time the defer statement is called, with defer effectively being a function
literal with some of it's own execution-time scope allocated?  I read that
evaluated parameters are all 'at time defer was called', is this true only of
variables referenced explicitely within the defer statement?
18:17 < krutcha> wrtp: cool beans :)
18:17 -!- xash_ [~xash@d126074.adsl.hansenet.de] has joined #go-nuts
18:17 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has quit [Quit:
Leaving.]
18:19 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has quit [Quit: Lost
terminal]
18:20 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
18:20 -!- fabled [~fabled@83.145.235.194] has joined #go-nuts
18:20 -!- danslo [~daniel@s5593965d.adsl.wanadoo.nl] has joined #go-nuts
18:21 -!- xash [~xash@d045110.adsl.hansenet.de] has quit [Ping timeout: 240
seconds]
18:24 -!- tdnrad [~Dan@terminal.research.cs.dal.ca] has joined #go-nuts
18:25 -!- jo [~identd@58-114-203-35.cable.dynamic.giga.net.tw] has joined #go-nuts
18:29 -!- jo [~identd@58-114-203-35.cable.dynamic.giga.net.tw] has quit
[Disconnected by services]
18:30 -!- piyushmishra [~piyushmis@117.200.231.134] has joined #go-nuts
18:31 -!- jochang [~identd@58-114-203-35.cable.dynamic.giga.net.tw] has joined
#go-nuts
18:31 -!- kanru [~kanru@118-160-164-12.dynamic.hinet.net] has quit [Ping timeout:
245 seconds]
18:32 < wrtp> krutcha: there's an allocation for the defer, and the function
literal (if used) has its own usual allocation(s)
18:35 -!- jochang [~identd@58-114-203-35.cable.dynamic.giga.net.tw] has quit
[Client Quit]
18:35 -!- jochang [~identd@58-114-203-35.cable.dynamic.giga.net.tw] has joined
#go-nuts
18:44 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
18:45 < krutcha> no dumb questions (I hope).  I've been wrestling a bit with
documentation of interfaces and finding their implementation.  For example struct
x doesn't imply anywhere that somebody has implemented 7 interfaces upon it.  It's
in the code, and greppable.  I know go ships with a lot of standard
make-life-easier toolbox programs like gofmt, godoc, etc.  Is there a plan for a
standard parsing tool to help with code location?  ie: show me all interfaces in
18:45 < krutcha> a code tree on struct X, or does struct X satisfy Reader{}?
etc?  Or is this a solved problem?
18:46 < nsf> looks like a lot of people want that
18:46 < nsf> not just you
18:46 < nsf> but unfortunately there is no such tool
18:46 -!- Fish- [~Fish@9fans.fr] has joined #go-nuts
18:46 < skelterjohn> such a tool could be misleading, though
18:46 < nsf> I can write it, but I don't want to :)
18:46 < KirkMcDonald> skelterjohn: How so?
18:47 < skelterjohn> people can give a struct certain methods, but that
doesn't mean they had that interface (and the functions that take that interface)
in mind
18:47 < KirkMcDonald> Perhaps.
18:47 < skelterjohn> i'm not saying the tool would not be useful
18:47 < nsf> nothing beats good documentation
18:47 < skelterjohn> but it would have false positives
18:47 < nsf> see Qt for example :)
18:47 -!- Fish [~Fish@9fans.fr] has quit [Ping timeout: 276 seconds]
18:48 < skelterjohn> especially interfaces with methods that have
interface{} parameters
18:48 < krutcha> agree on documentation but that is not enforceable, though
it does tend to give +meritocracy points to packages that hope to gain wide-spread
use
18:50 < krutcha> skelterjohn: true, but in Go, there is no technical
differentiation between having the right function prototypes and implementing an
interface.  So I don't think THAT is really solveable without developer
commentary.  Still, I'd rather find those functions than not be aware of them.
18:50 < skelterjohn> yes, i agree
18:50 < skelterjohn> like i said, i don't mean that it isn't a useful tool
18:51 < skelterjohn> just that it has the potential to be overwhelmed by
false positives, in some cases
18:51 -!- xash_ [~xash@d126074.adsl.hansenet.de] has quit [Quit: Lost terminal]
18:51 < nsf> personally I think it would be useless
18:51 < nsf> but that's just me
18:52 < skelterjohn> if there is a use for it, it is not useless.  it is
easy to come up with an example
18:52 < nsf> I've just written like 7-10k lines of code in Go, didn't feel
any need in that kind of tool
18:52 < nsf> s/just//
18:52 < nsf> I wrote like* (sounds better)
18:52 < nsf> :D
18:52 < nsf> sorry for my crappy english
18:52 < skelterjohn> both are correct
18:53 < nsf> yeah, that's the hard part
18:53 < skelterjohn> though "i've just written" implies that you wrote it
very recently
18:53 < skelterjohn> and "i wrote" implies lifetime
18:53 < nsf> I gave up trying to understand that, now I rely on my feelings
:)
18:53 -!- devrim [~Adium@160.79.7.234] has joined #go-nuts
18:54 < nsf> anyways, we're talking about the tool
18:54 -!- xash [~xash@d126074.adsl.hansenet.de] has joined #go-nuts
18:54 < krutcha> I'll supply a simple example..  if I can change my behavior
perhaps I can overcome this minus such a tool as you clearly have.
18:54 < krutcha> it may simply be a 'how I use the docs' issue
18:55 < nsf> giving use case is a good idea
18:55 < skelterjohn> one reason people can get away with it right now is the
fairly small amount of core library
18:55 < krutcha> I was working on a jabber client, and needed to use an MD5
digest.  I went here: http://golang.org/pkg/crypto/md5/
18:55 < skelterjohn> one can reasonably easily know all the structs in the
core library that satisfy io.Reader, for example
18:55 < krutcha> I realize I need a hash.Hash to call New on..  but that is
all I know about MD5 from the docs
18:56 < nsf> actually New returns has.Hash
18:56 < nsf> hash*
18:56 < krutcha> ah right, yes
18:56 < krutcha> so I call X := crypto.md5.New()
18:56 < krutcha> and I have a hash.Hash()
18:57 < nsf> you can't do that either :)
18:57 < nsf> it's just md5.New()
18:57 < nsf> yes, you have hash.Hash
18:57 < krutcha> ok
18:57 < nsf> :)
18:57 < skelterjohn> the examples where it would be useful are when there is
a package that uses an interface that needs to be implemented elsewhere
18:58 < krutcha> so I back up and look for a hash package with a Hash type
to move on..  I go here: http://golang.org/pkg/ and search for hash, or X.X.X.hash
18:58 < krutcha> or whatever
18:58 < skelterjohn> md5 doesn't take a hash, it *gives* a hash
18:58 < nsf> well, true
18:58 < krutcha> I find a top level hash package
18:58 < skelterjohn> but io.Reader, for example, requires you to create it
elsewhere
18:58 < nsf> and it contains Hash interface
18:59 < nsf> with four methods
18:59 < nsf> Write, Sum, Reset, Size
18:59 < krutcha> right, so I should be able to figure it out from there
18:59 < nsf> from where?  md5 package?
19:00 < krutcha> no from the hash package
19:00 < nsf> but you can do that, aren't you?
19:00 < krutcha> to figure out the use of the md5 packages returend hash
19:00 < nsf> http://nsf.github.com/go/hash.html
19:00 < nsf> but where comes the tool, I don't understand
19:00 < krutcha> and eventually I do puzzle it out.  But if there was no
golang.org/pkg webpage
19:01 < skelterjohn> certainly having some kind of documentation is useful -
no one disputes that
19:01 < nsf> I've written a documentation generator for you, you can
generate offline docs for yourself :)
19:02 < krutcha> hmm..  for open source this works, but since there are no
headers, can packages be installed as just compiled libs I can import?
19:02 < nsf> yes
19:03 < krutcha> I guess the answer is always documentation, I'm just a bit
concerned about finding things is all.
19:03 < nsf> and they contain full type information at the moment
19:03 < skelterjohn> certainly if a developer doesn't distribute source,
they'd need to distribute docs or it's not that useful
19:03 -!- virtualsue [~chatzilla@nat/cisco/x-vejzhwtdohcsqmcq] has quit [Ping
timeout: 272 seconds]
19:03 < nsf> I don't know about you, but you may want to try alt docs:
http://nsf.github.com/go/index.html (just don't use mouse, use keyboard)
19:03 < nsf> any questions - ask me
19:03 < skelterjohn> and yeah - you can technically recreate the godoc
without source, it just won't have the commentary
19:03 < nsf> it isn't popular, but for me it's more browsable thatn official
documentation
19:04 < nsf> than*
19:04 < krutcha> oh..  I saw this on the go-lang nuts earlier!
19:04 < skelterjohn> how can i dig into a package without the mouse
19:04 < nsf> skelterjohn: just type text and see what link is highlighted
19:04 < nsf> then press enter
19:05 < nsf> for go/ast for example you can type gast
19:05 < skelterjohn> cool
19:05 < nsf> enter clicks the highlighted link :)
19:05 < skelterjohn> how do i scroll the page without the mouse?
19:05 < skelterjohn> i have no page-down key on my laptop
19:05 < nsf> in chromium pgdn pgup works
19:05 < skelterjohn> btw it looks very slick
19:05 < nsf> :((
19:06 < nsf> well I don't know then
19:06 < skelterjohn> nsf: if tab unfocused the text box, i could use arrows
19:06 < nsf> notebooks are different
19:06 < skelterjohn> if i click out of the text box i can use arrows, anyway
19:06 < skelterjohn> and space/shift+space
19:06 < nsf> yeah, I know, but for some reason tab focuses the editbox and
selects all the text
19:06 * skelterjohn files an issue
19:06 < nsf> :)
19:07 < krutcha> nsf, is it viable to crosslink in the generated docs?  The
official docs don't either.  (minor timesaver)
19:07 < nsf> krutcha: it is possible, but the idea is a bit limited
19:07 < nsf> and requires more processing
19:07 < krutcha> ie: func New() hash.Hash might as well hotlink to
hash.Hash?
19:07 < krutcha> ah ok
19:07 < nsf> yeah, but you see
19:07 < skelterjohn> someone did an extension of godoc that crosslinked, but
it didn't make it into the core
19:07 < nsf> you can do: import hash "fmt"
19:08 < nsf> and now hash.Hash isn't really hash.Hash
19:08 < krutcha> oh..  I didn't know that
19:08 < nsf> it requires a fair amount of work to make it correct
19:08 < nsf> although for standard library I think it is fairly simple
19:08 -!- Tv [~tv@gige.bur.digisynd.com] has joined #go-nuts
19:09 < krutcha> what is the usecase to rename a package?
19:09 < nsf> potential name conflicts
19:09 < nsf> skelterjohn: https://github.com/nsf/gortfm/issues for my go
docs system, if you want something, file an issue
19:09 < skelterjohn> i can't just bug you directly?
19:10 < nsf> you can, but it means I have to add it there myself
19:10 < nsf> do that for me please :)
19:10 < skelterjohn> i forgot my issue
19:10 < nsf> hehe
19:10 < nsf> scrolling
19:10 < krutcha> ah..  so if I import (fake example) io.go.std.lib.hash, and
somebody else has franky.hax.hash, there are two hash packages, and MAYBE I want
to make use of both in my program?
19:10 < nsf> I will work on it tomorrow
19:10 < skelterjohn> requires github account
19:10 < skelterjohn> sorry
19:10 < skelterjohn> krutcha: yes
19:10 < nsf> ok, I've remembered it
19:11 < nsf> krutcha: exactly
19:11 < skelterjohn> nsf: it would be really awesome if you made it into a
program that i can run locally, similar to godoc
19:11 < nsf> or maybe you just don't like the long name
19:11 < nsf> like 'import cfg "configfile"'
19:11 < skelterjohn> then i can have it know about the non-core libs i've
got sitting around
19:11 < nsf> skelterjohn: https://github.com/nsf/gortfm
19:11 < nsf> download it
19:11 < skelterjohn> rtfm
19:11 < skelterjohn> nice
19:12 < nsf> see README
19:12 < skelterjohn> just noticed
19:12 < nsf> it explains how you can generate std lib reference for offline
usage
19:12 -!- Tv [~tv@gige.bur.digisynd.com] has quit [Client Quit]
19:12 < nsf> (the last commands snippet)
19:12 -!- Tv [~tv@gige.bur.digisynd.com] has joined #go-nuts
19:13 < krutcha> I also saw a few people working on ctags type behaviors on
the mailing list
19:13 < nsf> and it is possible to use gortfm for 3rd party documentation
19:13 < nsf> http://nsf.github.com/termbox/termbox.html
19:13 < nsf> krutcha: if you need autocompletion, say in vim, there is a
better tool for this job
19:13 < nsf> https://github.com/nsf/gocode
19:13 -!- jochang [~identd@58-114-203-35.cable.dynamic.giga.net.tw] has quit [Ping
timeout: 260 seconds]
19:13 < skelterjohn> anyway, i need to head out for a bit
19:14 < krutcha> l8r, thx for the help
19:14 < nsf> np
19:14 < krutcha> I don't know that I need autocompletion, but I do enjoy
making use of symbol tagging and lookup in many editors/IDE's when available
19:15 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has quit [Quit: skelterjohn]
19:15 < nsf> krutcha: http://nsf.110mb.com/gocode-demo.swf
19:15 < nsf> gocode in action
19:16 < krutcha> that is slick
19:16 < nsf> it does all the type inference and stuff
19:17 < krutcha> is termbox a vim extension?
19:17 < nsf> nope, termbox is just a terminal pseudo gui library
19:17 < nsf> like ncurses but 10 times simpler
19:18 < nsf> probably its usage is limited
19:18 < nsf> it wasn't tested a lot on different platforms
19:18 < krutcha> ah, and that demo?
19:18 < nsf> that demo is vim + gocode plugin
19:18 < krutcha> ahh
19:18 < nsf> that does autocompletion
19:18 < nsf> and it was integrated to goclipse somewhat
19:18 -!- ucasano [~ucasano@host153-182-static.227-95-b.business.telecomitalia.it]
has quit [Quit: ucasano]
19:19 < nsf> although I'm not sure about quality
19:19 < nsf> never used it
19:19 < nsf> I mean gocode was integrated :)
19:19 < nsf> provides autocompletion for it as well
19:19 < nsf> it can be integrated easily to emacs too, but looks like no one
needs that
19:20 -!- seromi [~seromi@cpe90-146-191-50.liwest.at] has joined #go-nuts
19:20 < krutcha> lately I've latched onto gedit for doing go, as it was the
first syntax highlighter I found
19:21 < nsf> it is possible to integrate that thing to gedit as well, but
I'm not familiar with its scripting interface
19:21 < nsf> I know it allows you to write plugins in python
19:21 < nsf> but you know..  if you want it, go for it :) vim works for me
19:22 < krutcha> I use vim a lot also but since I jump between os's so much
I find gedit easier as it's behavior closer mimics my windows/osx boxes
19:23 < krutcha> maybe I'll take a peek under gedit's hood and see if I can
get it going
19:23 < nsf> you can use vim on win/mac as well :)
19:23 < plexdev> http://is.gd/hr6f6 by [Adam Langley] in
go/src/pkg/crypto/cipher/ -- crypto/cipher: add package
19:23 < krutcha> I know, but on those platforms I'm stuck in application
specific IDE's for work :P
19:24 < nsf> i see
19:24 < TheSeeker> nsf: that demo kinda makes me want to learn how to use
vim :|
19:24 < nsf> do it
19:24 < nsf> although it shows nothing vim specific
19:24 < nsf> mostly it's just gocode
19:25 < TheSeeker> how does gocode work if it's not editor specific?
19:26 < krutcha> looks like it runs a server
19:26 < MaybeSo> it's a standalone server w/ a thin client, right?
19:26 < MaybeSo> yeah
19:26 < krutcha> so your plugins would have to talk to it
19:26 < nsf> yes, it is client/server
19:26 < nsf> plugin just passes data to the server and gets answer back
19:26 < nsf> the data is:
19:26 < nsf> contents of the current buffer, cursor position and current
file name
19:27 < nsf> and gocode gives autocompletion proposals back
19:27 < nsf> typical autocompletion time with warm cache is about 30ms
19:27 < nsf> with cold cache I don't know..  200-400ms
19:28 < krutcha> nice
19:28 < nsf> it can be smoothed out
19:28 < nsf> but I'll better implement some mechanism to make cache warm
before usage
19:28 < nsf> because it takes these 400ms, very fast anyway
19:29 < krutcha> yeah that's not really a big problem
19:29 < krutcha> I think I'll play with it tonight
19:29 < nsf> the whole cache thing is the most problematic area of the tool
actually
19:30 < nsf> because in go if one file changes, things in other files may
change their type
19:30 < krutcha> I thought I might throw together a test editor in go using
go-gtk or something, it would be fun to have an editor in go, for go, that knows
go
19:30 < nsf> anyway, looks like it works
19:30 < nsf> :D
19:31 < nsf> krutcha: it's a lot of work though
19:31 < nsf> and there are people like me
19:31 < nsf> I can't use a simple text editor
19:31 < nsf> where you move cursor with arrows on the keyboard
19:31 < nsf> it just doesn't work for me :)
19:31 < nsf> I need vim stuff
19:31 < nsf> sometimes I need vim macros
19:31 < nsf> and other fairly advanced features
19:31 < krutcha> there's always vim, thats the nice thing about vi/vim/etc
19:32 < nsf> but then what's the point in having two editors
19:32 < nsf> just confuses a lot
19:32 < krutcha> for me it's just a go exercise
19:33 < krutcha> I enjoy GUI, as long as I can still use the keyboard via
ctrl keys and whatnot
19:33 < nsf> well, if you want to, go for it
19:33 < nsf> :)
19:34 < krutcha> I'm just so used to ctl-f typesomething enter for
searching, with default behavior but a popup that lets me choose local buffer,
directory tree, workspace, case sensitivity etc as needed.
19:35 < krutcha> I've forgotten how to do all but the basics in vim due to
lack of use *for shame!*
19:35 < nsf> I got used to vim's '/' and it pisses me of that chromium
doesn't support that (firefox do)
19:35 < nsf> off*
19:35 < nsf> I guess there is a plugin or something
19:36 * nsf should really find it
19:36 < krutcha> ;)
19:36 -!- gummibaerchen [~timm@archlinux/trusteduser/gummibaerchen] has joined
#go-nuts
19:37 < krutcha> thanks for all the help and pointers-to-stuff, if I'm in a
productive mood tonight (PST) I may ping you for some gocode specifics as I noodle
with it.
19:37 < nsf> http://code.google.com/p/chromium/issues/detail?id=90
19:37 < nsf> :P
19:37 < nsf> id == 90!
19:37 < krutcha> lol
19:37 < krutcha> IE 7: WHO CARES!?!?!?!  It's IE. :)~ CRTL-F MY BUTT!
19:37 < krutcha> love it
19:37 < nsf> :)
19:39 < nsf> krutcha: sure, ask me here or via email, send patches, whatever
:)
19:39 < krutcha> roger that
19:39 < krutcha> EOT
19:39 -!- krutcha [~krutcha@remote.icron.com] has quit [Quit: Leaving]
19:40 -!- mat_ [~mat@prod2.absolight.net] has quit [Read error: Connection reset
by peer]
19:41 -!- napsy_ [~luka@88.200.96.18] has joined #go-nuts
19:41 -!- mat_ [~mat@prod2.absolight.net] has joined #go-nuts
19:42 -!- napsy [~luka@88.200.96.18] has quit [Ping timeout: 250 seconds]
19:44 -!- seromi [~seromi@cpe90-146-191-50.liwest.at] has quit [Quit: Colloquy for
iPad - http://colloquy.mobi]
19:45 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3]
19:47 -!- terrex [~terrex@84.122.72.127.dyn.user.ono.com] has joined #go-nuts
19:52 -!- xash [~xash@d126074.adsl.hansenet.de] has quit [Quit: Lost terminal]
19:55 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has joined #go-nuts
19:57 -!- femtooo [~femto@95-89-197-196-dynip.superkabel.de] has joined #go-nuts
19:58 -!- mcot_ [~mcot@65.196.71.3] has quit [Ping timeout: 260 seconds]
20:01 -!- trophi [~phi@pool-71-178-14-3.washdc.fios.verizon.net] has joined
#go-nuts
20:01 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has quit [Ping
timeout: 276 seconds]
20:12 -!- devrim [~Adium@160.79.7.234] has quit [Quit: Leaving.]
20:12 -!- devrim [~Adium@160.79.7.234] has joined #go-nuts
20:17 -!- artefon [~thiago@189.59.163.114] has joined #go-nuts
20:23 -!- teop [~teop@78.138.171.130] has quit [Ping timeout: 240 seconds]
20:23 -!- Chopinnn [~Chopin@ti0018a380-dhcp1590.bb.online.no] has joined #go-nuts
20:24 -!- Chopinn [~Chopin@ti0018a380-dhcp1590.bb.online.no] has quit [Read error:
Connection reset by peer]
20:27 -!- dju [~dju@fsf/member/dju] has quit [Quit: Quitte]
20:27 -!- Chopinnn [~Chopin@ti0018a380-dhcp1590.bb.online.no] has quit [Read
error: Connection reset by peer]
20:27 -!- Chopinn [~Chopin@ti0018a380-dhcp1590.bb.online.no] has joined #go-nuts
20:37 -!- tulcod [~auke@z032089.its-s.tudelft.nl] has joined #go-nuts
20:37 -!- tulcod [~auke@z032089.its-s.tudelft.nl] has left #go-nuts []
20:39 -!- piyushmishra [~piyushmis@117.200.231.134] has quit [Quit: Leaving.]
20:39 -!- plainhao [~plainhao@208.75.85.237] has quit [Quit: plainhao]
20:39 -!- fabled [~fabled@83.145.235.194] has quit [Quit: Ex-Chat]
20:42 -!- Adys [~Adys@unaffiliated/adys] has quit [Quit: I ♥ Unicode]
20:50 -!- Adys [~Adys@unaffiliated/adys] has joined #go-nuts
20:55 -!- nik9000 [~nik9000@vpn.radarfind.com] has joined #go-nuts
20:55 -!- tensorpudding [~user@99.148.202.191] has joined #go-nuts
20:56 -!- artefon [~thiago@189.59.163.114] has quit [Quit: bye]
21:04 -!- aho [~nya@fuld-4d00d1f9.pool.mediaWays.net] has joined #go-nuts
21:09 -!- XenoPhoenix [~Xeno@cpc5-aztw24-2-0-cust39.aztw.cable.virginmedia.com]
has quit [Quit: "Wait...  what?!"]
21:10 -!- aconran__ [~aconran@adsl-76-199-140-78.dsl.pltn13.sbcglobal.net] has
joined #go-nuts
21:11 < plexdev> http://is.gd/hrmzK by [Russ Cox] in
go/src/pkg/index/suffixarray/ -- index/suffixarray: use sort.Search
21:16 < tdnrad> in C/C++ when you add debugging output, you'll often #define
DEBUG and enclose the output in #IFDEF's for the preprocessor.  Since Go is still
working on the debugger side of things I want to ensure I have lots of debugging
output in case something goes wrong.  What is the preferred way of doing this?  If
I missed it documented somewhere please send me in the right direction.
21:19 < Namegduf> Add as needed.
21:20 < tdnrad> Is there any way to have this stripped out in a compiled
version?
21:22 -!- virtualsue [~chatzilla@nat/cisco/x-lloixnpwewaklifc] has joined #go-nuts
21:26 -!- Eridius [~kevin@unaffiliated/eridius] has joined #go-nuts
21:28 < plexdev> http://is.gd/hroTj by [Adam Langley] in
go/src/pkg/crypto/cipher/ -- crypto/cipher: add CFB and OCFB mode.
21:34 -!- nik9000 [~nik9000@vpn.radarfind.com] has left #go-nuts []
21:38 -!- rickard2 [~rickard@netra.esec.du.se] has joined #go-nuts
21:38 < rickard2> is there any package that allows you to do like a progress
meter in golang?  for instance saying "updating...  1%" and then change to
"updating...  2%" ?
21:42 -!- Fish- [~Fish@9fans.fr] has quit [Quit: So Long, and Thanks for All the
Fish]
21:45 -!- XenoPhoenix [~Xeno@cpc5-aztw24-2-0-cust39.aztw.cable.virginmedia.com]
has joined #go-nuts
21:47 -!- femtooo [~femto@95-89-197-196-dynip.superkabel.de] has quit [Quit:
Leaving]
21:59 -!- tdnrad [~Dan@terminal.research.cs.dal.ca] has quit [Quit: Leaving]
22:05 -!- sauerbraten_ [~sauerbrat@p508CEEF3.dip.t-dialin.net] has joined #go-nuts
22:16 < plexdev> http://is.gd/hrvmq by [Robert Griesemer] in
go/src/cmd/godoc/ -- godoc: use correct time stamp to indicate accuracy of search
result
22:18 -!- awidegreen_ [~quassel@p5DF1D7D4.dip.t-dialin.net] has quit [Remote host
closed the connection]
22:19 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
22:25 -!- krutcha [~krutcha@remote.icron.com] has joined #go-nuts
22:26 -!- belkiss [~belkiss@drn13-1-78-235-168-105.fbx.proxad.net] has joined
#go-nuts
22:33 -!- tdnrad [~tdnrad@142.68.13.224] has joined #go-nuts
22:40 -!- artefon [~thiago@189.59.163.114] has joined #go-nuts
22:42 -!- napsy [~luka@88.200.96.18] has quit [Read error: Operation timed out]
22:44 -!- Venom_X [~pjacobs@66.54.185.131] has quit [Quit: Venom_X]
22:47 -!- cco3 [~conley@c-69-181-138-209.hsd1.ca.comcast.net] has joined #go-nuts
22:47 -!- napsy [~luka@88.200.96.18] has joined #go-nuts
22:50 -!- terrex [~terrex@84.122.72.127.dyn.user.ono.com] has quit [Read error:
Connection reset by peer]
22:52 -!- Project_2501 [~Marvin@82.84.79.101] has quit [Quit: E se abbasso questa
leva che succ...]
22:52 -!- fenicks [~christian@log77-3-82-243-254-112.fbx.proxad.net] has joined
#go-nuts
22:53 < tdnrad> Any recommendations on how I might implement a state machine
in Go? Is there such thing as function pointers?
22:53 < fenicks> hi
22:54 < |Craig|> tdnrad: you can pass around function really easy in Go
22:55 < tdnrad> |Craig|, can you point me to some documentation or examples
on it?
22:57 < |Craig|> tdnrad: somewhere in the docs :).  They are just like any
variable.  x:=something.someFunct works just fine
22:57 -!- napsy [~luka@88.200.96.18] has quit [Read error: Connection reset by
peer]
22:57 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3]
22:57 < |Craig|> types are something like "funct(params) (returnvalues)"
22:59 < tdnrad> |Craig|, ok, do you know how I would declare a function in a
struct?  I'd like to make use a struct for each state, and each one reference
their own function, if that makes sense.  I realise that functions are not meant
to belong to a class like in most other languages, but this is a bit different I
think?
23:00 < |Craig|> if you want a function as a field in a struct, just give it
a field of a type thats a function
23:00 < |Craig|> myFuncRef funct(params) (returnvalues) // like this
23:01 < |Craig|> oops, func not funct
23:01 < |Craig|> http://golang.org/doc/go_spec.html#Function_literals is
somewhat relevent
23:01 < tdnrad> |Craig|, thank-you very much.  I think I understand
that. I'll give it a shot
23:04 < tdnrad> Excellent, this is exactly what I want.
23:04 -!- drc_ [~drc@dh165049.res.uvic.ca] has joined #go-nuts
23:06 < drc_> I'm having some trouble finding something out...  Are there
any tools similar to gcov I can use to check statment coverage of a go test suite?
23:08 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has joined #go-nuts
23:11 < MaybeSo> So I'm cross compiling some Go code from darwin to linux,
and I'm finding that the darwin version works w/o a problem but the cross compiled
linux version consistently reports a timeout on net.Dial from the http package --
it gets stuck in syn_ack state.  Anyone else here see that?
23:12 -!- napsy [~luka@88.200.96.18] has joined #go-nuts
23:14 -!- gnuvince_ [~vince@72.0.215.147] has quit [Quit: ""]
23:24 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has quit [Remote
host closed the connection]
23:26 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has joined #go-nuts
23:26 -!- tdnrad [~tdnrad@142.68.13.224] has quit [Read error: Connection reset by
peer]
23:27 -!- photron_ [~photron@port-92-201-129-190.dynamic.qsc.de] has quit [Ping
timeout: 276 seconds]
23:27 -!- tdnrad [~tdnrad@142.68.13.224] has joined #go-nuts
23:28 -!- bmizerany [~bmizerany@208.66.27.62] has joined #go-nuts
23:28 -!- wrtp [~rog@92.17.98.41] has quit [Quit: wrtp]
23:28 -!- tdnrad [~tdnrad@142.68.13.224] has quit [Read error: Connection reset by
peer]
23:29 -!- rlab [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller,
Faster, Easier.  http://miranda-im.org]
23:31 -!- tvw [~tv@e176006126.adsl.alicedsl.de] has quit [Remote host closed the
connection]
23:33 -!- bmizerany [~bmizerany@208.66.27.62] has quit [Remote host closed the
connection]
23:35 < drc_> Are there any tools that would allow me to look at statement
coverage of a GO program?  Something like gcov even if its simple.
23:36 < skelterjohn> what is statement coverage, exactly?
23:38 < KirkMcDonald> Tracking which source lines are actually executed.
23:38 < drc_> it tells you how many times each line of code was executed
23:38 < drc_> yeah
23:39 < KirkMcDonald> In the context of unit tests, it tells you how much of
the code is being tested, for instance.
23:39 < drc_> yup
23:39 < drc_> If there is a tool, I'm having an unusually difficult time
finding it.
23:40 < skelterjohn> go is short on profiling tools
23:40 < skelterjohn> debuggers, etc
23:41 < drc_> yeah.
23:44 -!- drc_ [~drc@dh165049.res.uvic.ca] has left #go-nuts []
23:47 < krutcha> what would happen if you ran a go program under some of the
valgrind tools?
23:49 < skelterjohn> if you compile with gccgo you can probably use a lot of
existing tools
23:49 < skelterjohn> if you use 5g/6g/8g probably not
23:49 < krutcha>
http://groups.google.com/group/golang-nuts/browse_thread/thread/c7d548974abdda92/fa2a57027f3bdc8f?#fa2a57027f3bdc8f
speaks to this, yeah was just looking
23:49 -!- aconran__ [~aconran@adsl-76-199-140-78.dsl.pltn13.sbcglobal.net] has
quit [Quit: aconran__]
23:49 < krutcha> with gccgo it may give a poor man's profile of a test
suite, but at best I think by functions called not lines covered
23:50 < skelterjohn> i've heard of people using gccgo + gdb, too
23:50 < skelterjohn> but i'm not skilled at getting that kind of thing
working
23:50 < skelterjohn> printlns for now
23:51 < krutcha> gdb would be useful, but threads != goroutines, and I doubt
gdb is aware of the runtime/gc..  so a lot of things would be going on that are
scaffolding and wouldn't resemble anything you wrote specifically (at least that
is my guess)
23:52 < skelterjohn> i think that would be ok - gdb would just ignore it
23:52 < skelterjohn> gcc tags the binaries with info to tell the debugger
what's going on
23:52 < skelterjohn> where the source is, etc
23:53 < skelterjohn> if it's not there, i figure gdb can just treat it as
unobservable
23:53 < krutcha> one way to find out :)
23:53 < skelterjohn> wait until someone else tries it for me?  :)
23:54 < krutcha> yup!
23:54 < skelterjohn> i'm on it
23:54 < krutcha> I haven't used the gcc stuff yet maybe I'll give it a go
next time I build
23:56 -!- mcot [~mcot@pool-71-171-113-161.clppva.fios.verizon.net] has joined
#go-nuts
--- Log closed Sat Nov 20 00:00:17 2010