--- Log opened Mon Mar 07 00:00:49 2011
--- Day changed Mon Mar 07 2011
00:00 < cenuij> dfc: any hard quotes on the http parses use, other than Mr
Shaw?
00:02 < cenuij> Also, test cases though i guess there might be some already
for mongrel/2?
00:02 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has quit [Remote host
closed the connection]
00:03 < cenuij> I guess my main concern is a fast and tru http parser
00:04 < cenuij> which go can't provide at the moment.
00:05 < cenuij> But that's no fault
00:05 < cenuij> dub
00:05 < cenuij> thinking aloud
00:05 < cenuij> http is the mongo protocol
00:06 < cenuij> in go we get wonderful interfaces, satisfied by a shit ton
of code.
00:08 < dfc> cenuij: i think the go http package is pleanty fast enough
00:09 < cenuij> dfc: sure, fast but not safe
00:09 < dfc> it appears to be safe enough to run goland.org
00:09 < dfc> golang.org
00:11 < cenuij> I hope so
00:12 < cenuij> My go server falls over if someone farts at it
00:12 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has joined #go-nuts
00:12 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has joined #go-nuts
00:13 < cenuij> dfc: comments a few mins ago...
00:14 < cenuij> do you think the mongrel parser was on the back of the rager
machine work?
00:14 < cenuij> s/rager/ragel
00:14 <@adg> cenuij: what kills your go server?
00:14 < cenuij> adg: ,e
00:14 < cenuij> me
00:14 <@adg> i have a bunch of go http servers running in the wild,
including golang.org
00:14 <@adg> they're all stable.  never need to mess with them
00:15 < dfc> cenuij: i think zed shaw developed the ragel http grammar
concurrently with mongrel
00:15 < dfc> note: requires citation
00:15 < cenuij> dfc: noted
00:17 < cenuij> adg: duly noted but I'm antsy about this quick nod
00:18 <@adg> quick nod?
00:19 < cenuij> yep, you have some go servers and that's great.
00:19 <@adg> cenuij: i am asking you for more information about "My go
server falls over if someone farts at it"
00:20 <@adg> cenuij: if your server is unstable then that's a bug, either in
your code or in go
00:20 <@adg> cenuij: if it's the latter, i'd like to get it fixed, with your
help
00:24 < cenuij> adg: I'm happy you would get involved.
00:25 < cenuij> let me get my listings
00:25 < ww> ouch: terminate called after throwing an instance of
'std::runtime_error' what(): pthread_setspecific
00:26 <@adg> yikes
00:27 <@adg> ww: what caused that?
00:29 < ww> not entirely sure yet.  might be that third party libraries that
claim to be thread safe aren't (kyoto cabinet)
00:29 < cenuij> adg: 1 moment please i'm finding paste that will take my
paste
00:31 < vsmatck> Hm. flag.BoolVar doesn't make sense to me.  If I set the
default value to true, and then specify the option on the command line shouldn't
that result in false?
00:32 <@adg> vsmatck: why would it?
00:32 <@adg> vsmatck: that would be pretty confusing
00:33 < vsmatck> I'm thinking you specify the option to do what is !default.
00:33 <@adg> what if the default changes?
00:33 <@adg> suddenly your argument does the opposite of what you thought
00:34 < vsmatck> I don't understand.
00:34 < cenuij> adg: Are you Andre Gerrand?
00:34 <@adg> cenuij: yes
00:34 < vsmatck> Oh. Like dynamically changes.
00:34 <@adg> vsmatck: no, like the author of the program changes the default
00:35 < vsmatck> What does the default value mean.  I'm confused I think.
00:35 < cenuij> adg: How did you keep calm with the question you had at then
end of the fosdem speach?
00:35 <@adg> vsmatck: it's more consistent to know that -foo is shorthand
for -foo=true
00:35 <@adg> cenuij: it was a very long question, i had time to compose
myself :)
00:36 < cenuij> adg: diplomatic
00:36 <@adg> vsmatck: the default is just the default
00:36 < vsmatck> adg: oh!  I get it.
00:36 < vsmatck> I wasn't thinking about = at all.
00:36 <@adg> vsmatck: a better solution, if you want true to the be the
fault, would be to make the flag -nofoo with the default being false
00:36 <@adg> s/fault/default/
00:37 <@adg> cenuij: :)
00:37 < vsmatck> adg: Thanks for clearing that up for me.  :)
00:37 <@adg> vsmatck: no prob
00:39 < cenuij> adg: My server falls over because i'm hacking go together as
quickly as I can.  I'm trying to use slices as much as I can, but i worry about
myt results.
00:39 <@adg> i see
00:39 <@adg> write tests ;)
00:39 < cenuij> adg: are slices guaranteed with an array underneath?
00:39 <@adg> yes
00:40 <@adg> cenuij:
http://blog.golang.org/2011/01/go-slices-usage-and-internals.html
00:40 <@adg> also
http://blog.golang.org/2010/08/defer-panic-and-recover.html
00:40 <@adg> defer/recover might help you catch out-of-bounds errors in a
non-fatal way
00:40 <@adg> obviously you should fix the programming error, but you can
prevent them from taking down your server entirely
00:41 < cenuij> adg: The structures are not mine to define :(
00:41 -!- mikespook [~mikespook@219.137.252.84] has joined #go-nuts
00:41 <@adg> cenuij: why is that an issue?
00:42 < cenuij> adg: is seems like im juking betweeen encoding/binary and
bytes.NewBuffer too much
00:43 < cenuij> and I cant use a Buffer in any of the encoding/* funcs
00:45 < cenuij> Maybe i can it shift more but that desnt leave my line
readable
00:45 < cenuij> for most..
00:47 < ww> bytes.NewBuffer will make a copy of its argument i think
00:47 <@adg> you can't use a buffer?
00:48 <@adg> i'd be curious to see the code, maybe there's a better approach
00:50 < fzzbt> why this doesn't work: type []byte mytype; [...] var m
mytype; string(m); ? but string([]byte(m)) works.  why can't i convert it
directly?
00:51 <@adg> maybe it should
00:52 <@adg> file a bug?
00:52 < fzzbt> i think someone asked this question here before too, but
there was no answer.
00:52 <@adg> either the compiler is being overzealous of that is not
permitted by the spec
00:53 <@adg> http://golang.org/doc/go_spec.html#Conversions
00:53 -!- tensorpudding [~user@99.56.160.152] has quit [Read error: Connection
reset by peer]
00:53 <@adg> it's not permitted by the spec
00:54 <@adg> you could argue that it should be
00:54 <@adg> or you could just write a String() method for mytype
00:55 -!- napsy [~luka@88.200.96.18] has quit [Quit: Lost terminal]
00:56 < exch> adg: has your fosdem talk been recorded somewhere?
00:56 -!- tensorpudding [~user@99.56.160.152] has joined #go-nuts
00:57 < fzzbt> here was the original discussion http://dpaste.com/480552/
01:02 < fzzbt> []byte(x) feels redundant since it's clearly going to be
converted to string anyway.
01:02 <@adg> exch: yeah
01:02 <@adg> fzzbt:
http://nf.id.au/my-golang-talk-fosdem-2011-practical-go-progr
01:03 <@adg> uh
01:03 <@adg> that was for exch
01:03 < exch> ah thanks
01:03 < fzzbt> adg: :) okay i watch it then too
01:03 <@adg> fzzbt: one argument is that you don't immediately know what
string() is doing
01:04 <@adg> fzzbt: ie, []byte to string conversation does an allocation
01:04 <@adg> fzzbt: in the case of: type Foo string; var f Foo = "blah"; s
:= string(f)
01:04 <@adg> fzzbt: you're just converting types, not actually doing an
allocaiton
01:05 <@adg> fzzbt: but if you wanted to []byte(f), that'd would copy the
data without being obvious about it
01:05 <@adg> fzzbt: (just for arguments' sake)
01:06 < fzzbt> okay, that makes sense.
01:06 <@adg> i wonder if it works for numeric types?
01:07 <@adg> yep, works for numbers
01:07 -!- shvntr [~shvntr@113.84.144.143] has joined #go-nuts
01:07 <@adg> http://goo.gl/fQLEI
01:08 < fzzbt> so, slices are special?
01:09 <@adg> the slice/string conversion is, yes
01:10 <@adg> it has special properties
01:14 -!- _nil [~nil@users.vu.union.edu] has joined #go-nuts
01:14 < skelterjohn> evening
01:15 -!- saturnfive [~saturnfiv@210.74.155.131] has joined #go-nuts
01:15 < _nil> hey
01:16 < cenuij> skelterjohn: morning
01:17 < skelterjohn> someone always feels the need to correct me when i say
that :)
01:17 < cenuij> skelterjohn: no nought
01:17 < skelterjohn> no nought?
01:18 < cenuij> finger/kb
01:18 < cenuij> beer++
01:18 < skelterjohn> still no idea
01:19 < skelterjohn> nought an idea
01:20 < cenuij> I dunno, what's the appropriate response for "morning"?
01:21 < cenuij> or evening
01:21 < cenuij> fuck skelterjohn
01:21 < cenuij> i'm, sorry
01:21 < cenuij> I didnt see it was evening :)
01:22 < skelterjohn> what time is it, for you?
01:22 < cenuij> 02:30
01:23 < cenuij> John you might as well roll into our crowd and say "morning"
01:25 < skelterjohn> that'd be quite a move
01:25 < skelterjohn> give me 12 hours and i'll say morning
01:26 < cenuij> adg: also i hear perhaps you might make some changes to the
makge/goinstall system?
01:31 < cenuij> seems it's always the deb/ubuntu guys worrrying about the
small things.  The RedHat/SuSE guys will make it so ;)
01:34 < cenuij> in the meantime...  I seem to be making slices all the time
01:43 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the
connection]
02:01 < exch> adg: there's a typo in one of your slides.  "Exercises for the
reader (or listener)" - last sentence on the slide has 'bewteen' instead of
'between'.  The fosdem vid shows it at 53:28
02:01 <@adg> whoops
02:02 <@adg> exch: fixed ;)
02:03 < exch> cool :)
02:06 < exch> adg: smooth handling of the asshat's 'question' in the end
02:09 <@adg> thanks.  really, i think he did me a favour
02:11 -!- niemeyer [~niemeyer@201-40-140-176.pltce701.dsl.brasiltelecom.net.br]
has joined #go-nuts
02:13 < cbeck> adg: I don't suppose you'll be in Portland, OR anytime soon?
02:16 <@adg> cbeck: i hope to be there for OSCON
02:16 <@adg> in late July
02:24 < cbeck> Ah, cool
02:24 < cbeck> Speaking or just attending?
02:31 -!- itrekkie [~itrekkie@ip72-211-129-122.tc.ph.cox.net] has quit [Quit:
itrekkie]
02:31 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has quit [Quit:
Computer has gone to sleep.]
02:32 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has joined #go-nuts
02:37 <@adg> hopefully speaking!  haven't heard if they've accepted my talk
yet
02:37 <@adg> also rob submitted something
02:38 <@adg> and bradfitz might be speaking about camlistore
02:38 < cbeck> Ooh, very cool.
02:40 < cbeck> I'm a student at Portland State.  A bunch of us have been
working on getting a group discount for OSCON
02:40 < KirkMcDonald> Portland, eh.
02:41 < cbeck> Verily.
02:41 <@adg> i'm excited to go there, i hear it's a nice place.
02:41 < KirkMcDonald> I grew up there.
02:45 < cbeck> Anywho, I'm the chair of the student ACM group here, and
we're always looking to host speakers.
03:00 <@adg> cool, well shoot me an email adg@golang.org now and i'll
remember you when i'm planning the trip
03:03 < cbeck> Will do.
03:09 < steven> are there any ORMs for go yet, like what django has builtin,
for example?
03:10 -!- saturnfive [~saturnfiv@210.74.155.131] has quit [Read error: Connection
reset by peer]
03:10 < steven> im thinking of trying out web.go or something similar, but
just using raw sqlite or mysql or something would be painful, a wrapper would be
much nicer.
03:10 < exch> Not sure if an Object relational model makes sense in a
lgnaueg that has no object relations
03:10 -!- saturnfive [~saturnfiv@210.74.155.131] has joined #go-nuts
03:10 < exch> *language
03:10 < steven> touche.
03:11 < steven> still, im sure a higher-level wrapper of some kind would be
useful
03:42 -!- FX80 [~MX80@cust65.253.117.74.dsl.g3telecom.net] has quit [Ping timeout:
260 seconds]
03:52 -!- espeed [~espeed@63.246.231.57] has joined #go-nuts
04:07 -!- vsayer [~vivek@2001:470:1f04:1a6b:21a:6bff:fe35:d2a5] has joined
#go-nuts
04:10 -!- ymasory [~ymasory@c-76-99-55-224.hsd1.pa.comcast.net] has quit [Quit:
Leaving]
04:16 -!- rejb [~rejb@unaffiliated/rejb] has quit [Ping timeout: 246 seconds]
04:24 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has quit [Remote
host closed the connection]
04:28 -!- edsrzf [~kelvan@122-61-221-144.jetstream.xtra.co.nz] has joined #go-nuts
04:28 -!- zac314159 [~user@c-68-84-149-234.hsd1.nm.comcast.net] has joined
#go-nuts
04:29 -!- zac314159 [~user@c-68-84-149-234.hsd1.nm.comcast.net] has left #go-nuts
["ERC Version 5.3 (IRC client for Emacs)"]
04:30 -!- edsrzf [~kelvan@122-61-221-144.jetstream.xtra.co.nz] has quit [Client
Quit]
04:30 -!- ronny [~quassel@p4FF1C6A8.dip0.t-ipconnect.de] has joined #go-nuts
04:34 -!- Guest34589 [~quassel@p4FF1C0D9.dip0.t-ipconnect.de] has quit [Ping
timeout: 276 seconds]
04:35 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has quit [Ping timeout: 248
seconds]
04:47 < exch> since when can int be cast to a string?  as in: var i int; s
:= string(i)
04:51 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|]
04:52 -!- nettok [~quassel@200.119.161.206] has quit [Ping timeout: 276 seconds]
04:54 < KirkMcDonald> exch: That gives a string containing the code point
contained in the integer, if I remember right.
04:55 < exch> yes it does
04:56 < exch> just can't remember that working.  I always used
string([]int{n})
04:56 < exch> mm same for individual byte values
05:20 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has joined #go-nuts
05:25 -!- aho [~nya@fuld-590c62d1.pool.mediaWays.net] has quit [Quit:
EXEC_over.METHOD_SUBLIMATION]
05:33 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
05:40 < dfc> append([]string, []string) doesn't work does it ?
05:41 < dfc> should I wrap that in a function to unpack the 2nd []string
05:41 < dfc> or is that what ...  is for
05:43 < steven> dfc: append(strslice1, ...strslice2)
05:44 < steven> i believe thats the syntax.
05:44 < exch> ...  goes after the slicename
05:45 < exch> a = append(a, b...)
05:45 < dfc> s1 := []string{ "a", "b"} ; s2 := []string{ "c", "d"} ; s3 :=
append(s1, s2)
05:45 -!- Wiz126 [~Wiz@24.229.245.72.res-cmts.sm.ptd.net] has joined #go-nuts
05:45 < dfc> cannot use s2 (type []string) as type string in append
05:45 < exch> s2...
05:46 < dfc> exch: fantastic
05:46 < dfc> no need for my hacky appendv
05:46 < dfc> no need for my hacky appendv
05:47 < dfc> sadly append(s1, s2, s3...) is a bridge too far
05:47 < dfc> nm
06:01 -!- niemeyer [~niemeyer@201-40-140-176.pltce701.dsl.brasiltelecom.net.br]
has quit [Ping timeout: 246 seconds]
06:03 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has joined #go-nuts
06:07 -!- fabled [~fabled@mail.fi.jw.org] has joined #go-nuts
06:12 -!- skejoe [~skejoe@188.114.142.162] has joined #go-nuts
06:19 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has quit [Remote host closed
the connection]
06:20 -!- skejoe [~skejoe@188.114.142.162] has quit [Quit: Lost terminal]
06:27 -!- dfc [~dcheney@sydfibre2.atlassian.com] has quit [Ping timeout: 246
seconds]
06:27 < aiju> 07:18 < dfc> [06:50:07] sadly append(s1, s2, s3...) is a
bridge too far
06:28 < aiju> s1 = append(s1, s2); s1 = append(s1, s3...) is not THAT long …
06:34 < |Craig|> s1=append(s1, append(s2, s3...)...)
06:34 < aiju> or that hahaha
06:46 -!- vpit3833` [~user@203.111.33.203] has joined #go-nuts
06:47 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Remote host
closed the connection]
06:49 -!- cw_ [~anticw@parsec.stupidest.org] has joined #go-nuts
06:49 -!- anticw [~anticw@c-67-169-68-180.hsd1.ca.comcast.net] has joined #go-nuts
06:49 -!- mpl_ [~mpl@smgl.fr.eu.org] has joined #go-nuts
06:49 -!- jnwhiteh_ [~jnwhiteh@li37-84.members.linode.com] has joined #go-nuts
06:49 -!- chaos95_ [chaos95@mafianode.com] has joined #go-nuts
06:50 -!- d_m_ [d6@SDF.ORG] has joined #go-nuts
06:50 -!- rotorooter [~roto@64.79.202.154] has joined #go-nuts
06:51 -!- chressie1 [~chressie@dreggn.in-ulm.de] has joined #go-nuts
06:52 -!- tokuhiro__ [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has joined
#go-nuts
06:52 -!- irc [~irc@209.17.191.58] has joined #go-nuts
06:52 -!- Netsplit *.net <-> *.split quits: anticw_, cw, Guest55683,
tokuhiro_, charme_g, mpl, Innominate, d_m, chaos95, vpit3833, (+5 more, use
/NETSPLIT to show all of them)
06:52 -!- Netsplit over, joins: Innominate
06:53 -!- ptrb [~peter@69.164.208.33] has joined #go-nuts
06:56 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has joined #go-nuts
06:57 -!- charme_g [~charme_g@163.5.84.215] has joined #go-nuts
07:09 -!- edsrzf [~kelvan@122-61-221-144.jetstream.xtra.co.nz] has joined #go-nuts
07:15 -!- itrekkie [~itrekkie@ip72-211-129-122.tc.ph.cox.net] has joined #go-nuts
07:16 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has joined #go-nuts
07:21 -!- edsrzf [~kelvan@122-61-221-144.jetstream.xtra.co.nz] has quit [Quit:
Ex-Chat]
07:24 -!- adu [~ajr@softbank220043138128.bbtec.net] has joined #go-nuts
07:40 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
07:48 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
07:53 -!- dfc [~dfc@203-158-48-86.dyn.iinet.net.au] has joined #go-nuts
08:03 -!- dfc [~dfc@203-158-48-86.dyn.iinet.net.au] has quit [Quit: dfc]
08:07 -!- Adys [~Adys@unaffiliated/adys] has quit [Ping timeout: 276 seconds]
08:12 -!- dfc [~dfc@203-158-48-86.dyn.iinet.net.au] has joined #go-nuts
08:13 -!- wrtp [~rog@92.16.113.213] has joined #go-nuts
08:16 -!- dfc [~dfc@203-158-48-86.dyn.iinet.net.au] has quit [Client Quit]
08:19 -!- visof [~visof@unaffiliated/visof] has joined #go-nuts
08:19 -!- Fish [~Fish@exo3753.pck.nerim.net] has quit [Quit: So Long, and Thanks
for All the Fish]
08:25 -!- Fish [~Fish@exo3753.pck.nerim.net] has joined #go-nuts
08:34 -!- dfc [~dfc@203-158-48-86.dyn.iinet.net.au] has joined #go-nuts
08:44 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts
08:50 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|]
09:01 -!- dfc [~dfc@203-158-48-86.dyn.iinet.net.au] has quit [Quit: dfc]
09:04 -!- tensorpudding [~user@99.56.160.152] has quit [Remote host closed the
connection]
09:11 -!- electro_ [electro@c-bef570d5.033-10-67626721.cust.bredbandsbolaget.se]
has joined #go-nuts
09:23 -!- dfc [~dfc@203-158-48-86.dyn.iinet.net.au] has joined #go-nuts
09:25 -!- Adys [~Adys@unaffiliated/adys] has joined #go-nuts
09:33 -!- mikespook [~mikespook@219.137.252.84] has quit [Quit: Leaving.]
09:39 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Ping timeout: 276 seconds]
09:54 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts
10:01 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
10:01 -!- femtooo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts
10:04 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Ping timeout:
246 seconds]
10:15 -!- dfc [~dfc@203-158-48-86.dyn.iinet.net.au] has quit [Quit: dfc]
10:21 -!- saturnfive [~saturnfiv@210.74.155.131] has quit [Read error: Connection
reset by peer]
10:25 -!- boscop [~boscop@g227132192.adsl.alicedsl.de] has joined #go-nuts
10:41 -!- KingPhil_ [~kingphilr@shc-nat-newhall.stonehill.edu] has quit [Ping
timeout: 255 seconds]
10:48 -!- dfc [~dfc@203-158-48-86.dyn.iinet.net.au] has joined #go-nuts
10:55 < aiju> oh wow
10:55 < aiju> compiling and linking a Go hello world program is slower than
compiling the equivalent C++ program
10:55 < aiju> 1.3s vs 1.6s
10:56 < aiju> using g++ for the latter
10:57 -!- saturnfive [~saturnfiv@222.91.81.226] has joined #go-nuts
10:59 < schmrkc> how much of that is startup time for the compiler and
linker?  (:
11:00 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Quit: Leaving]
11:00 < taruti> aiju: haha :P
11:00 < taruti> the linker is slooow
11:00 < aiju> however, compiling 10 KLOC using g++ took over one minute
11:01 < aiju> 1s with Go
11:01 < taruti> g++ is slow while ld for hello world is quite fast, 6g is
fast while 6l is quite slow
11:01 < aiju> but nothing beats 8c's 0.38s
11:01 < schmrkc> aiju: I get 0.350 for compiling and linking the
helloworld.go and 1.021 for helloworld.cpp
11:02 < schmrkc> of course after the first run g++ beats the heck out of the
go linker :)
11:02 < schmrkc> I guess we all must abandon Go now :(
11:02 < aiju> haha
11:03 < aiju> more like writing an angry post to the mailing list
11:03 < schmrkc> :D
11:03 * aiju is currently writing 8086 code
11:03 < aiju> using something really ugly ...
11:04 < schmrkc> you were working on an OS iirc?
11:04 < aiju> global variables + lock for storage
11:04 < aiju> yeah
11:04 < aiju> only one program can execute open(2) because of global
variables :D
11:04 < schmrkc> I hear you're not aiming for a multiuser system there then
:)
11:05 < aiju> actually yes
11:05 -!- Urmel|Work [~UrmelWork@cache1.uk.logica.com] has joined #go-nuts
11:05 < aiju> it'll just be a bit sluggish if everyone starts opening files
;P
11:05 < schmrkc> :D
11:05 < aiju> i can't really help it
11:05 < aiju> the stack is outside the DS blah
11:06 < schmrkc> I have vague memories of 8086..
11:06 < schmrkc> everytime I'm doing something even related to OS-dev I
start off with going to long mode and life is good.
11:06 < aiju> hahahaha
11:06 < schmrkc> not really an option on 8086 (:
11:06 < aiju> long mode is stupid
11:06 < aiju> it's just as stupid as 32-birt
11:06 < aiju> -r
11:07 < aiju> 32-bit has some funny features which are tricky to use, like
segmentation
11:07 < aiju> instead of removing them, they are crippled in long mode
11:07 < schmrkc> well sure..  I'd argue that the whole x86 arch is broken
and should be replaced.
11:07 < aiju> they retain all the problems, but aren't useful either!
11:07 * schmrkc is more of an ARM person.
11:07 * aiju is more of a PDP-11 person.
11:07 < schmrkc> :)
11:07 < aiju> aiju.phicode.de/pdp11
11:08 < schmrkc> yikes!
11:08 < schmrkc> way cool.
11:09 < schmrkc> now you just need to hire some of the macbook swinging
webdesigners to beef your site up with some facebook integration and flash menues
:)
11:09 < aiju> hahahahah
11:10 -!- hcatlin [~hcatlin@host86-145-112-33.range86-145.btcentralplus.com] has
joined #go-nuts
11:10 -!- hcatlin [~hcatlin@host86-145-112-33.range86-145.btcentralplus.com] has
quit [Changing host]
11:10 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has joined
#go-nuts
11:10 < schmrkc> this 8086 thing you are doing.  Is it some justforfun
project, or what?
11:16 -!- dfc [~dfc@203-158-48-86.dyn.iinet.net.au] has quit [Quit: dfc]
11:17 < aiju> schmrkc: yeah
11:23 -!- skejoe [~skejoe@188.114.142.162] has joined #go-nuts
11:23 < fzzbt> I don't understand why one has to pass an object with methods
instead of just passing map of functions in the rpc package.  The Arith in the
doc's example doesn't even make any use if its method receiver (t *Arith).  What's
the point of that?  http://golang.org/pkg/rpc/
11:46 -!- virtualsue [~chatzilla@nat/cisco/x-hynqkyibhwiiudce] has joined #go-nuts
11:51 -!- coldturnip1 [~COLDTURNI@111-250-7-7.dynamic.hinet.net] has joined
#go-nuts
11:52 -!- coldturnip [~COLDTURNI@111-250-7-7.dynamic.hinet.net] has quit [Ping
timeout: 240 seconds]
12:07 -!- Slant [~scott@115.130.2.40] has joined #go-nuts
12:07 < Slant> Are there any guides to effective testing in Go?
12:08 < Slant> I'm trying to figure out how to TDD writing a network server.
12:08 < Namegduf> Use x_test.go files in a package.
12:08 < Slant> (Mocking?  Method call assertions.)
12:08 < Namegduf> And the testing thing included.
12:08 < Slant> Namegduf: I did get the x_test.go going.  That was easy.
12:09 < Slant> I suppose since go is statically compiled, mocking is
probably impossible.
12:12 -!- saturnfive [~saturnfiv@222.91.81.226] has left #go-nuts []
12:13 < Slant> Is exp.datafmt worth playing with to do parsing of binary
formats?
12:20 -!- j3parker [j3parker@artificial-flavours.csclub.uwaterloo.ca] has quit
[Ping timeout: 240 seconds]
12:20 -!- j3parker [j3parker@artificial-flavours.csclub.uwaterloo.ca] has joined
#go-nuts
12:22 -!- shvntr_ [~shvntr@113.84.144.143] has joined #go-nuts
12:22 -!- chressie1 [~chressie@dreggn.in-ulm.de] has quit [Quit: WeeChat 0.3.4]
12:23 -!- chressie [~chressie@dreggn.in-ulm.de] has joined #go-nuts
12:23 -!- shvntr_ [~shvntr@113.84.144.143] has quit [Client Quit]
12:29 < ww> Slant: to some extent you can mock by using interfaces, i.e.  a
"real" implementaion and a mock one, both provide the same interface...
12:29 < Slant> Ahh.  Gotcha.
12:29 < Slant> And inject in from there.
12:29 < wrtp> fzzbt: it means that the rpc package knows what type each
method has
12:29 < Slant> But, at some point, the pedal has to hit the metal.  And at
that point, it's just about reducing surface, right?
12:30 < wrtp> fzzbt: with a map of functions, each function has to have the
same type
12:30 < Namegduf> Slant: I think you can only test the external stuff of a
package.
12:30 < Namegduf> It's relatively unusual for packages to take external,
non-interface types and be expected to call methods on them.
12:31 < wrtp> Slant: i think exp/datafmt is only about printing of data
12:31 * Slant nods.
12:31 < Namegduf> So it's avoidable in most cases, I think.
12:31 < Namegduf> Where they do, I'm not sure what you can do.
12:31 < Namegduf> Convert to taking an interface, I guess.
12:32 < wrtp> Namegduf, Slant: it's conventional for a gotest file to be in
the same package as the thing it's testing.  that's so you can test internal
stuff.
12:32 < Namegduf> wrtp: Lack of mocking still makes that messy.
12:33 < Namegduf> Taking interfaces for everything internally is a nasty
idea
12:33 < wrtp> i don't know what you mean by mocking
12:33 < wrtp> (i haven't got a dynamic language background)
12:33 < Namegduf> wrtp: Mocking is where, instead of passing an instance of
a type, you pass an instance of a testing type with the same methos
12:33 < Namegduf> You can then test what methods are called
12:33 < Namegduf> And what with
12:33 < ww> i've seen TDD taken way too far where the mocking up of things
to support the tests becomes more complicated than the code itself...
12:34 < Namegduf> wrtp: I first encountered it in Java, not used it in a
"dynamic" language.
12:35 * ww has seen it heavily in python web development frameworks (e.g.  pylons,
pyramid)
12:35 < wrtp> i think it's going to be more useful in languages which rely
extensively on callback-type APIs
12:35 < Namegduf> Maybe the easiest thing to do is simply to outlaw
expecting certain things to be called on an instance of a type passed into
something.
12:35 < wrtp> i.e.  where you're always passing in an object and expect that
methods will be called on that object
12:35 < Namegduf> Go has the ability to pass closures, which are a simpler
way of satisfying most such usecases and easily testable.
12:35 < wrtp> that's more unusual in go
12:35 < Namegduf> Yeah.
12:36 < aiju> using types as a replacement for closures is one of the
ugliest Go idioms
12:36 < Namegduf> It's not a Go idiom, it's a Java idiom
12:36 < wrtp> and when you do have that, it's usual that the type is an
interface anyway
12:36 < wrtp> so easy to "mock"
12:36 < Namegduf> Right.
12:36 < aiju> Namegduf: just that some part of the stanard library use it
12:36 < aiju> +s
12:36 < Namegduf> aiju: Really?  Huh.
12:36 < skelterjohn> morning
12:36 < aiju> like sort.Sort
12:36 < Namegduf> I wouldn't call sort.Sort idiomatic, just necessary
12:36 < wrtp> aiju: in sort.Sort, it's more than just a replacement for a
closure
12:37 < wrtp> because you've got three entry points
12:37 < aiju> it's a replacement for two closures!
12:37 < Namegduf> So, hmm.  I guess it boils down to, do not pass
non-interfaces and expect methods to be called.
12:37 < aiju> oh three
12:37 < Namegduf> It's complicated and closures do a better job of that kind
of thing mostly.
12:37 < aiju> i don't like sort.Sort nevertheless
12:37 < wrtp> aiju: well, it's a kind of cunning hack to avoid the usual
overhead of boxing
12:38 < wrtp> but it works ok i reckon
12:38 < aiju> boxing?
12:38 < skelterjohn> i think it's a clever to get around a lack of generics
12:38 < wrtp> aiju: converting to interface{}
12:39 < skelterjohn> no one wants to create an array of
[]ComparableInterface
12:39 < wrtp> if you want to, then vector.Vector supports it anyway...
12:42 -!- niemeyer [~niemeyer@201-40-140-176.pltce701.dsl.brasiltelecom.net.br]
has joined #go-nuts
12:44 < wrtp> aiju: thing is, you can always go from closures to a type or
vice versa, so it doesn't really matter which is used
12:44 < aiju> how do i go from closures to a type?
12:44 < wrtp> aiju: make a type that holds the closures
12:45 < wrtp> aiju: and make the methods call them
12:45 < Namegduf> You make the set of closures into an interface with
methods
12:45 < aiju> well duh
12:45 < Namegduf> And then you make a type with methods which are your
closures
12:45 < aiju> that's quite some effort
12:45 < wrtp> Namegduf: didn't i just say that?
12:45 < Namegduf> And you pass your type and yeah, much less simple.
12:45 < aiju> as opposed to just putting something around a closure
12:45 < wrtp> i never know how much lag there is on this irc thingy
12:45 < Namegduf> Highly variable.
12:46 < Namegduf> Especially since I'm on a netbook on wireless.
12:46 < wrtp> my typing always comes back immediately
12:46 < Namegduf> Your typing is echoed by your client, not the server.
12:46 < wrtp> yeah.
12:46 < Namegduf> For more fun, multiple servers mean who spoke first varies
by place on the network.
12:46 < wrtp> so did you see my response to aiju before you typed yours?
(out of interest)
12:47 < aiju> special relativity applies to IRC
12:47 < Namegduf> Only the "make a type" part.
12:47 < aiju> there is no notion of simultaneity
12:47 < aiju> +common
12:47 < Namegduf> There's a limited notion of ordering
12:47 < Namegduf> But that's it
12:47 < Namegduf> And it's only defined for certain things.
12:48 < wrtp> it'd be nice to have some well defined partial ordering "this
person had seen this response when they typed theirs"
12:48 < wrtp> anyway, definite bikeshed :-)
12:49 -!- adu [~ajr@softbank220043138128.bbtec.net] has quit [Quit: adu]
12:49 < Namegduf> In general if you respond after you see a response your
response is guaranteed to appear after theirs
12:49 < Namegduf> In the current IRC implementation
12:49 < wrtp> yeah, but if i see a response after mine i don't know if
they've seen mine or not
12:49 < aiju> it's just like special relativity ;P
12:49 < Namegduf> Not really doable, because you'd need client cooperation.
12:50 < wrtp> Namegduf: yeah
12:50 < Namegduf> The client<->server lag is often a much bigger issue
than server<->server
12:51 < wrtp> aiju: the thing is that closures aren't nearly so appropriate
for multi-method interfaces.
12:51 < Namegduf> Up to three is okay
12:51 < wrtp> and for a single-method interface, the code is small and
simple
12:51 < Namegduf> Not really
12:51 < wrtp> i reckon that >1 should be an interface
12:52 < wrtp> because you're associating the different closures through a
common value
12:52 < Namegduf> Types aren't values.
12:52 < aiju> i'd much prefer a struct of closures
12:52 < Namegduf> A struct is what you're talking about, yeah.
12:52 < skelterjohn> but you pass it via an interface
12:53 < Namegduf> Types still aren't values.  It's just that the value is
irrelevant.
12:53 < wrtp> aiju: a struct of closures implies that all those closures are
independent
12:53 < Namegduf> No it doesn't.
12:53 < Namegduf> Why would it do that?
12:53 < aiju> yes they are
12:53 < wrtp> because they can all be "closed over" different local state
12:53 < Namegduf> They could be, but I think you're taking the word closure
overly literally
12:53 < aiju> if i just want a different ordering, i can simply change Less
12:54 < Namegduf> They're function pointers
12:54 < wrtp> and if you've got some kind of an API, then it's usual to
assume that all the methods operate on the same object
12:54 < aiju> tbqh i find the word "closure" for "inline function" or
"function pointer" to be annoying
12:54 < Namegduf> Not true in all cases.
12:54 < wrtp> also using an interface is more efficient currently
12:54 < Namegduf> I have a case where I pass three closures.
12:54 < Namegduf> core.Sync()
12:54 < wrtp> core?
12:55 < Namegduf> core is the main data storing part of the program
12:55 < Namegduf> Maintains state
12:55 < wrtp> sometimes a struct with closures is entirely appropriate
12:55 < wrtp> when the closures are independent things
12:55 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has joined #go-nuts
12:55 < Namegduf> You pass three functions, one per each of the three types
of thing the core stores
12:56 < wrtp> but for something like ReadCloser for example, it makes total
sense for the two functions to be operations on the same type
12:56 < Namegduf> And it calls each closure for each one, with concurrent
changes blocked in the meantime, letting you synchronise it.
12:56 < wrtp> Namegduf: why 3, not N ?
12:56 < Namegduf> Because the core is not a generic DB thing
12:57 < Namegduf> It stores specific stuff and permits specific operations
on it, and there are three specific stuffs
12:57 < wrtp> aiju: i suppose the main difference is a difference of
expectation: "this method is operating on this receiver" vs "this function invokes
this action"
12:58 < aiju> bleh
12:58 < aiju> i mean, who cares about that?
12:58 < Namegduf> wrtp: I find the idea of a type storing no data being
passed solely to provide type information in an interface ugly
12:58 < aiju> the only point of methods is to provide (1) interfaces and (2)
overloading depending on the receiver
12:58 < Namegduf> Generic function pointers cannot be assumed to be
operating on a "receiver"
12:58 < aiju> beyond that they're silly and useless
12:59 < Namegduf> And you can't assume all cases you pass more than one
operate on the same "receiver"
12:59 < Namegduf> If they *do*, *then* an interface might make sense.
12:59 < wrtp> Namegduf: i think that's what i was trying to say
13:00 < Namegduf> Okay.
13:00 < Slant> I notice there are no enum types.  Is it normal to use consts
and integers instead?
13:00 < wrtp> aiju: so what's sort.Sort doing that isn't one of your above
categories
13:00 < Namegduf> That can make sense.
13:00 < wrtp> Slant: you've got type ints and iota
13:00 < wrtp> s/type/typed/
13:01 < Slant> How does a typed in work?  I mean, it can't be restricted to
a const range, can it?
13:01 < wrtp> Slant: see
http://stackoverflow.com/questions/5037610/typed-constant-declaration-list/5041510#5041510
13:01 < Namegduf> As for struct vs individual ones...  I'd follow usual
rules for passing multiple parameters in a struct.
13:01 < wrtp> Slant: (no)
13:01 < Slant> wrtp: Thank you.
13:01 < Namegduf> Ugly by default by way of being more complex, but if the
struct is useful to keep around or there are way more parameters than there should
be, less complex than alternatives.
13:02 < wrtp> Namegduf: have you got an example of this "ugliness"?
13:02 < Namegduf> wrtp: The Win32 API
13:02 < wrtp> in Go, i mean
13:02 < Namegduf> No
13:03 < Namegduf> I don't think passing structs is common, because 15
parameter functions aren't
13:03 < wrtp> oh, sorry i was referring to " I find the idea of a type
storing no data being passed solely to provide type information in an interface
ugly"
13:03 < Namegduf> Oh. No, I think Go mostly avoids that, too.
13:03 -!- petrux [~petrux@host16-224-static.53-82-b.business.telecomitalia.it] has
joined #go-nuts
13:04 < Namegduf> I think it occurs more in OO languages; I've seen it used
with Module objects.
13:04 < Namegduf> Inherit from base, override virtual functions for hooks,
go.
13:04 < wrtp> it's not uncommon in Go to define a type that provides no
additional data, just to satisfy an interface
13:05 < wrtp> i don't mind it at all
13:05 < skelterjohn> if there are two different interfaces that you're
interested in, and they share method names with no shared functionality
13:05 < skelterjohn> you can define a type to say which one of them you're
thinking about when you pass the object
13:05 < wrtp> exactly
13:05 < Namegduf> "share method names with no shared functionality" is a
really odd case, and not one I've ever seen.
13:05 < Namegduf> It's considered unusual and degenerate, isn't it?
13:05 -!- ampleyfly [ampleyfly@gateway/shell/blinkenshell.org/x-eulkmzkbaoxyanwf]
has quit [Ping timeout: 276 seconds]
13:06 < skelterjohn> what if you have a library for probability stuff
13:06 < skelterjohn> and there is a Distribution interface
13:06 < wrtp> also, the advantage of interfaces over closures is that if
you've already got a type, you can hang several interfaces off it without needing
to create the closures
13:06 < skelterjohn> with a Sample() interface{} method
13:06 < skelterjohn> eh, getting a bit involved
13:06 < skelterjohn> but it happens :)
13:06 -!- ampleyfly [ampleyfly@gateway/shell/blinkenshell.org/x-wucckynhgyetufqp]
has joined #go-nuts
13:06 < Namegduf> wrtp: That is true, but is dependent on the "actually has
a receiver with meaningful data" part
13:07 < Namegduf> wrtp: Which I agreed was sensible.
13:07 < wrtp> sometimes it doesn't
13:07 < wrtp> and it's still ok
13:07 < Namegduf> Why would you already have a type to hang interfaces off
if the type didn't have data?
13:07 < Namegduf> Types without data are weird and ew
13:07 -!- adu [~ajr@softbank220043139062.bbtec.net] has joined #go-nuts
13:08 < Namegduf> You're using them just to pass around type information,
which is weird
13:08 < wrtp> Namegduf: there's an example here:
http://golang.org/src/pkg/time/sleep.go
13:09 < Namegduf> wrtp: Where?
13:09 < Namegduf> I see two types, both of which store meaningful data.
13:09 < wrtp> note that the methods on timerHeap never use the receiver
value
13:09 < wrtp> the type of timerHeap could just as well be bool
13:09 < wrtp> or struct{}
13:10 < Namegduf> Eh.
13:10 < Namegduf> No.
13:10 < wrtp> (and maybe it should be, to make it obvious)
13:10 < wrtp> yes
13:10 < Namegduf> It couldn't.
13:10 < Namegduf> Because:
13:10 < wrtp> it could
13:10 < Namegduf> timers timerHeap
13:10 < adu> hi all
13:10 < Namegduf> They operate on their type.
13:10 < Namegduf> They just operate on the single fixed instance of it.
13:11 < wrtp> it would be better if timers was declared as timers []*Event
13:11 < Namegduf> I agree, but then it couldn't have methods.
13:11 < Namegduf> It'd be better if the methods didn't ignore the receiver
and assume it's the only instance of the receiver possible, but it doesn't really
matter.
13:11 < Namegduf> It is internal-only code.
13:12 < wrtp> it could be declared var timerHeap struct{}{}
13:12 < wrtp> no
13:12 < Namegduf> No, it couldn't.
13:12 < wrtp> indeed
13:12 < Namegduf> It is used, it's just used explicitly by name by its
methods
13:12 -!- ampleyfly [ampleyfly@gateway/shell/blinkenshell.org/x-wucckynhgyetufqp]
has quit [Ping timeout: 276 seconds]
13:12 < Namegduf> Instead of via the receiver
13:12 < wrtp> anyway, the point is that all the methods just act on the
global variable
13:12 < Namegduf> That's weird of the methods, but not the type
13:12 < wrtp> yeah, the data inside the receiver is irrelevant
13:13 < Namegduf> Yeah, but it's not what I was complaining about.
13:13 < wrtp> it means that the access to the heap slice can be slightly
more efficient
13:13 < Namegduf> It's a type with meaningful data, with methods which
operate on the type to do reasonable stuff
13:13 < wrtp> because the receiver can be a value type
13:14 < Namegduf> The methods just ignore the receiver and operate only on
the global instance, which is odd but not the "type with no data, just methods"
thing.
13:15 < Namegduf> I just think things are getting complex and ugly when
you're operating on abstract types instead of just writing code that manipulates
actual data and does actual syscalls and returns actual results
13:15 < wrtp> i quite often define: type nullWriter struct{}; func
(nullWriter) Write(d []byte) (int, os.Error) {return len(d), nil}
13:15 < wrtp> which has no data :-)
13:15 < aiju> i don't mind empty types if the interface usually has a value
13:15 < wrtp> Namegduf: yeah, i'd agree with that
13:15 < aiju> like that nullWirter
13:15 < aiju> *Writer
13:15 < Namegduf> Yeah, but you wouldn't define io.Writer to be used like
that by default.
13:15 < Namegduf> I hope.
13:15 < wrtp> no
13:16 < Namegduf> You do that because it's a special case, normally
io.Writer is used on things that actually have data, or at least wrap something
which actually has data.
13:16 < Namegduf> Even if the data is just another io.Writer, it's
something.
13:16 < wrtp> Namegduf: so what's a good example from the windows world that
does this kind of thing?
13:17 < Namegduf> The Windows example was about structs as parameters due to
terrifying numbers of parameters.
13:17 < Namegduf> The example of types designed to be sets of functions, not
closures, comes from OO, and is the Module object kinda thing.
13:17 < wrtp> Namegduf: link?
13:18 < aiju> structs as parameters are a good idea actually, if you have
many parameters
13:18 < Namegduf> aiju: I agree, I just think many parameters is usually an
issue.
13:18 < aiju> sometimes you can't help it
13:18 < Namegduf> I'll say that it's a good idea if the struct is a coherent
block of data, too.
13:18 < wrtp> aiju: i'm just about to add a call with struct holding
parameters to the go API...
13:18 < Namegduf> Which you might wish to assemble and pass around as one
thing.
13:18 < aiju> Namegduf: yeah
13:18 < aiju> it's usually possible to reduce parameter count by grouping
data into structs
13:19 < Namegduf> I've managed to avoid the need
13:19 < Namegduf> But I think it depends on what you're doing.
13:19 < Namegduf> Or how tolerant you are of lots of data.
13:19 < Slant> eww.  Consts as integers means hungarian notation is
enforced.
13:19 < Slant> :-(
13:19 < aiju> how so?
13:19 < aiju> you can do
13:19 < aiju> type YourEnum int
13:20 < aiju> const ( a YourEnum = iota ...  )
13:20 < Namegduf> wrtp: What did you want a link to?
13:20 < wrtp> Namegduf: "Module object kinda thing"
13:21 < Namegduf> Ah.
13:21 < Namegduf> I'm not sure where in the source to link to, and I only
ran into it once.
13:21 < Namegduf> Not very complex to imagine, though.
13:21 < wrtp> ok, i'm always interested to see concrete examples of badness
:-)
13:21 -!- MX80 [~MX80@cust151.253.117.74.dsl.g3telecom.net] has joined #go-nuts
13:22 < Namegduf> Module abstract class with virtual methods for all
possible hooks, modules inherit from it defining their own type which overrides
the things they want to hook, pass the resulting thing back into the core.
13:22 < wrtp> Slant: yeah, i don't know what you mean by that
13:22 < wrtp> Namegduf: oh yeah, mixed abstract and concrete classes, that
was always nasty
13:22 < Slant> If you have const ( blahname YourEnum = iota )
13:22 < Slant> Followed by
13:22 < wrtp> overriding in general is nasty
13:23 < Namegduf> It's really the only way to do interfaces in OO
13:23 < Slant> const ( blahname ADifferentEnum = iota + 25 )
13:23 < Namegduf> But not nice.
13:23 < Slant> Then blahnames conflict.
13:23 < aiju> Slant: oh well
13:23 < wrtp> Namegduf: i know
13:23 < Slant> Because consts are actually untyped and global.  Sad.
13:23 < Slant> aiju: Yeah, oh well.
13:23 < Slant> aiju: Could be a lot worse.  ;-)
13:23 < wrtp> Slant: yes, they all live in the same namespace as functions
and types
13:23 -!- ampleyfly [ampleyfly@gateway/shell/blinkenshell.org/x-wefboacmgxgxqcsc]
has joined #go-nuts
13:23 < aiju> it would be worse the other way imho
13:24 < wrtp> you have to define functions and types with different names
too
13:24 < Namegduf> Package scope, not global per se
13:24 < nsf> the worst thing (as always) is C++0x
13:24 < Namegduf> But yeah.
13:24 < aiju> nsf: hahahaha
13:24 < Namegduf> C++0x has all the features.
13:24 < nsf> where enums are both globals and under their own namespace
13:24 < Namegduf> All of them.
13:24 < wrtp> aiju: in Limbo, you could define constants inside a struct
13:24 < nsf> I've tried to use C++0x enums honestly
13:24 < nsf> the worst nightmare ever
13:24 < nsf> "strongly typed enums"
13:25 < aiju> i simply stay away from C++
13:25 < wrtp> Slant: the fact that they're in the package namespace means
that the problem's not too bad
13:25 < nsf> it's hard
13:25 < Namegduf> C++ was my first language
13:25 < Slant> wrtp: Yeah, I agree.
13:25 < wrtp> as you have control over that name space
13:25 < nsf> there is a lot of C++ libraries
13:25 < Namegduf> I am not a fan.  :P
13:25 < aiju> nobody forces you to use them
13:25 < Slant> wrtp: Though, it means any consts that are exported become
kind of ugly.  Anywaaaay.
13:25 < nsf> aiju: nobody forces me to write software, you know
13:26 < aiju> what kind of libraries do you need that desperately?
13:26 < Namegduf> I think C++ can be a decent practical answer if you use
the C subset plus very restricted use of classes to fake interfaces
13:26 < wrtp> Slant: yeah, it's not really hungarian notation though, more
like "consistent naming scheme" :-)
13:26 < Namegduf> But I don't like it as a language.
13:26 < aiju> Slant: pkg.foo.bar or pkg.foo_bar is just bikeshed
13:26 < nsf> aiju: I won't say it, because it's another subject of a flame
war
13:26 < aiju> hahahahaha
13:26 < aiju> lemme guess, Qt
13:26 < nsf> like libX is crap, libY is crap too, bla bla bla
13:26 < nsf> Qt is nice, yes
13:26 < Slant> aiju: Well, I was thinking pkg.foo.fooConst ;-)
13:27 < wrtp> Slant: the os package does it quite a bit.
13:27 < Slant> aiju: What am I doing wrong here?
http://pastebin.com/A4wS4FK5
13:27 < nsf> even STL
13:27 < Slant> I have both dnsType and dnsClass types defined...
13:27 < aiju> type is a keyword
13:27 < aiju> i often stumbled over that one, too ....
13:27 < Slant> Ahh, nm.
13:27 < Slant> Yeah.
13:27 < Slant> haha.
13:27 < Slant> I just noticed as you said that.
13:27 < Slant> :-D
13:27 < aiju> or func
13:28 < Namegduf> Yeah, I do that sometimes.
13:28 < Slant> Is there a common alternate name that people use?
13:28 < aiju> it produces the weirdest errors
13:28 < Namegduf> I use blahtype
13:28 < nsf> Slant: pkg.foo.fooConst is java
13:28 < Slant> Like "cls" instead of "class"?
13:28 < Namegduf> msgtype, in my case.
13:28 < wrtp> Slant: in your case i might use dnsType
13:28 < Namegduf> I also use t here and there
13:28 < nsf> namespaces.are.good.why.cant.we.have.more.of.them.MyVarX = 10;
13:29 < Slant> nsf: I was pointing out that pkg.foo.fooConst is bad.
13:29 < nsf> ah, sorry then :)
13:29 < Slant> nsf: But that since consts are in the package namespace, it's
kind of enforced in Go if you have two consts with the same natural name.
13:29 < Namegduf> namespaces.are.good.why.cant.we.have.more.of.them.MyType
myTypeInstance = new namespaces.are.good.why.cant.we.have.more.of.them.MyType;
13:29 < aiju> Slant: what's that "foo" in there?
13:29 < Slant> In my case, there are two different "ANY" queries in DNS...
ANY QTYPE and ANY QCLASS.
13:29 < nsf> Slant: I think it's a mistake trying to apply "natural" names
to a programming language
13:30 < aiju> pkg.ANY_QTYPE and pkg.ANY_QCLASS?
13:30 < nsf> sounds like OOP bullshit to me, where modeling "real world,
natural objects" is essential
13:30 < Namegduf> Don't model.  Just do.
13:30 < aiju> nsf: i don't think he meant anything like that
13:30 < Namegduf> There is no model.  There is only do.
13:30 < Namegduf> :P
13:30 < Slant> aiju: pkg.A, pkg.NS, pkg.ANY_CLASS, pkg.ANY_TYPE
13:30 < Slant> vs.
13:30 < nsf> aiju: in any case
13:30 < nsf> that's my opinion
13:30 < Slant> pkg.class.A pkg.class.ANY.
13:30 < Slant> Anyway.
13:31 < aiju> nsf: i agree with that
13:31 < Slant> It's such a tiny thing.
13:31 < Slant> I just noticed that.
13:31 < aiju> class?
13:31 < aiju> there are no classes in Go
13:31 < Slant> dns.class.A
13:31 < Slant> :-D
13:31 < Namegduf> I think he means response type
13:31 -!- skejoe [~skejoe@188.114.142.162] has quit [Quit: Lost terminal]
13:31 < Namegduf> Class can be used for things other than the programming
thing
13:31 < Namegduf> That's cool.
13:31 < skelterjohn> like "you ain't got none"?
13:31 < Namegduf> It's good to have class, for exmaple.
13:31 < aiju> but what's that class in there
13:31 < aiju> a struct?
13:31 < Namegduf> skelterjohn: Yes.
13:32 < aiju> Marx' dream of a classless programming language
13:32 < Slant> In DNS, there are classes and types.  A class would be IN for
Internet, or CS for CSNet (obsolete ;-))
13:32 < nsf> in C there was a problem with namespaces, but even in that kind
of environment very big software exists
13:32 < nsf> afaik firefox (huge giant) doesn't even use namespaces in C++
13:32 < Slant> and types like A, NS, AAAA, TXT, etc.
13:32 < Namegduf> Slant: Yeah, you need to use CLS_A, CLS_ANY, and so forth.
13:32 < Namegduf> TYPE_A, TYPE_NS, etc.
13:32 < nsf> in Go there are _modules_, what can be possibly better?
13:32 < nsf> :)
13:32 < Slant> Namegduf: Right.
13:32 < Namegduf> It's actually a bit shorter.
13:33 < aiju> nsf: org.foo.bar.com.container.vector
13:33 < nsf> aiju: :D
13:33 < Slant> Namegduf: And that's what I meant by hungarian notation
because constants aren't namespaced.
13:33 < Namegduf> I share your sense of vague ungoodfeel about it.
13:33 < aiju> hungarian notation is something entirely different
13:33 < Namegduf> But it's not that bad.
13:33 < skelterjohn> what's the difference between hungarian notation and
namespace?  a "."?
13:33 < nsf> Slant: well, kind of
13:33 < nsf> but what's wrong with that?
13:33 < aiju> skelterjohn: tons of syntactic sugar
13:33 < wrtp> Slant: see http://golang.org/src/pkg/net/dnsmsg.go
13:34 < Slant> aiju: How is that not Hungarian notation?
13:34 < wrtp> for an example of how it was done in the go source
13:34 < aiju> hungarian notation is the silly practice of prepending types
to variable names
13:34 < nsf> hungarian notation is about shortcuts for common types
13:34 < aiju> like strName
13:34 < nsf> int - i
13:34 < wrtp> they used dnsType and dnsClass
13:34 < nsf> string - sz
13:34 < nsf> etc
13:34 < aiju> or lpcsName
13:34 < Namegduf> I once tried hungarian notation in a C program, but I
didn't enjoy it.
13:34 < nsf> and their composition, yes
13:34 < skelterjohn> Slant: why bother having a blahname for type 1 and a
blahname for type 2 if they're both blahnames?
13:35 < nsf> but what's wrong with TOKEN_LBRACE
13:35 < skelterjohn> if both types are derived from int, don't worry about
it - just code
13:35 < wrtp> http://msdn.microsoft.com/en-us/library/aa260976(v=vs.60).aspx
13:35 < nsf> or whatever other prefixed name
13:35 < aiju> namespaces is something people worry too much about
13:35 < aiju> hahahaha
13:35 < aiju> wrtp: that article is hilarious
13:36 < Slant> wrtp: Yup.
13:36 < Slant> I love rsc's TODO at the top.
13:36 < wrtp> aiju: isn't it?!
13:36 < aiju> most prefixes in Windows are wrong
13:36 < wrtp> Slant: so there you have it
13:36 < wrtp> Slant: they're prefixed with dns because they live in the net
package which does lots of other stuff too
13:37 < Slant> Exactly my complaint.  :-D
13:37 < aiju> Slant: srsly what's wrong with that?
13:37 < wrtp> if you were doing a just-DNS package, you wouldn't need the
dns prefix
13:37 < nsf> again, in C there were no much problems with that
13:37 < nsf> in Go there are f**king modules
13:38 < nsf> dreams come true
13:38 < aiju> i fucking hate it when people write "f**k"
13:38 < aiju> spell it out if you want to say it
13:38 < wrtp> Slant: i don't see much difference between type.HINFO and
TypeHINFO
13:38 < aiju> anyway, back to debugging 2KLOC of ASM
13:38 < nsf> aiju: fucking ok
13:38 < nsf> :)
13:38 < Namegduf> Type_HINFO is closer and prettier.
13:39 < aiju> i actually have less problems than with Javascript ;P
13:39 < wrtp> Namegduf: go generally uses camelcase
13:39 -!- Slant_ [~scott@115.130.4.45] has joined #go-nuts
13:39 < wrtp> and not underscores
13:39 < Slant_> wrtp: Catch that?  the TODO is priceless.
13:39 < Namegduf> wrtp: It also doesn't usually switch to capitals halfway
through
13:39 < Namegduf> wrtp: TYPE_HINFO would be preferrable to my eyes
13:40 < wrtp> Slant_: i don't see a problem with the TODO issue - it's just
about factorisation
13:40 < Namegduf> But eh, bikeshed.  :P
13:40 < wrtp> do we put the dns stuff in a separate module or not?
13:40 < wrtp> if we do, then a simple global replace changes all the
constants
13:42 -!- Slant [~scott@115.130.2.40] has quit [Ping timeout: 276 seconds]
13:42 < nsf> uhm..  kind of a different syntactical qustion: what do you
think about this thing in Go:
13:42 < nsf> type A [1]int
13:42 < ww> aiju: 'round here we say fscking
13:42 < ww> :P
13:42 < nsf> if A{1}[0] == 1 {1}
13:42 < skelterjohn> 1{1}?
13:43 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has joined #go-nuts
13:43 < nsf> well, it's just an example, have no real world sense
13:43 < wrtp> nsf: it's not valid syntax
13:43 < nsf> the problem here, that it cannot be parsed without typedef
table :)
13:43 < skelterjohn> oh - the {1} was the code
13:43 < nsf> Go allows it only like that:
13:43 < skelterjohn> if A{1}[0] == 1 { doStuff() }
13:43 < nsf> if (A{1}[0] == 1) {1}
13:43 < Namegduf> That looks...  weird.
13:44 < aiju> but why would you do that
13:44 < nsf> it's a hack, described in src/cmd/gc/lex.c somewhere
13:44 < Namegduf> Pretty much my thought.
13:44 < wrtp> ah of course
13:44 < nsf> just find "loophack"
13:44 < Namegduf> What does it do?
13:44 < wrtp> i remember now
13:44 < wrtp> it's an ambiguity
13:44 -!- rm445 [rm445@pip.srcf.societies.cam.ac.uk] has quit [Ping timeout: 240
seconds]
13:44 < skelterjohn> oh - because A could be a boolean expression
13:44 < skelterjohn> ?
13:44 < nsf> yes
13:44 < Namegduf> Ah, I see.
13:45 < nsf> or it is a type
13:45 < wrtp> A{1}[0] == 1 *is* a boolean expression
13:45 < nsf> yeah, you can see that
13:45 < nsf> but parser can't
13:45 < wrtp> indeed
13:45 < wrtp> but it doesn't need the typedef table to parse
13:45 < skelterjohn> so what happens when you try?
13:46 < wrtp> it's a *lex* hack
13:46 < wrtp> go can be parsed fine without knowing about types
13:46 < nsf> wrtp: no, it cannot be parsed with hack
13:46 < nsf> as I've said
13:46 -!- chomp [~ken@c-71-206-216-232.hsd1.pa.comcast.net] has quit [Ping
timeout: 255 seconds]
13:46 < nsf> go doesn't allow this kind of code
13:46 < nsf> it requires parens around if statement in that case
13:46 < nsf> if (A{1}[0] == 1) {1}
13:46 < nsf> like that
13:47 < nsf> the problem with compound literal syntax
13:47 < wrtp> which is fine IMHO
13:47 < nsf> which is: <type> { ...  }
13:47 < wrtp> because it's usual code
13:47 < wrtp> s/usual/unusual
13:47 < nsf> it's fine for an end user
13:47 < nsf> but an ugly hack in the compiler
13:48 < wrtp> sure, it's not great.  but at least it's lexical
13:48 < nsf> I think about a way to avoid that in my language
13:48 < nsf> just for the sake of requiring no hacks
13:48 < wrtp> i imagine they tried quite hard to remove it
13:49 < Namegduf> Use something other than {} for compound literals?
13:49 < nsf> I guess
13:49 < nsf> Namegduf: as an option, yes
13:49 < Namegduf> Options are bad.  :(
13:50 < wrtp> nsf: use « » :-)
13:50 < nsf> :DD
13:50 < nsf> well, there are options, all of them are weird though
13:51 < Namegduf> Next time I write something in C, I think I will use
defines to replace all syntax with emoticons
13:52 < nsf> one of the ideas to have a special "expr" in if statements,
which disallows the use of compound statements
13:52 < nsf> oops, I mean compound literals
13:52 < Namegduf> That's a way around, too.
13:52 < wrtp> Namegduf:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh/blok.c
13:53 < nsf> at least at the top level
13:53 < nsf> but even though it looks like a nice solution
13:53 < nsf> it's a confusion for a programmer
13:53 < nsf> like you can use that here, but you can't here
13:53 < wrtp> nsf: a struct literal is not a compound statement
13:53 < nsf> it's a compound literal
13:53 < Namegduf> wrtp: Argh
13:54 < wrtp> Namegduf: good innit?
13:54 < Namegduf> wrtp: Argh
13:54 < wrtp> i remember trying to debug it :-)
13:54 < Namegduf> Ouch.
13:55 < wrtp> nsf: i think it's worse if you have two subtly different
expression syntaxes in different places
13:55 < nsf> yes
13:55 -!- aho [~nya@fuld-4d00d6b0.pool.mediaWays.net] has joined #go-nuts
13:55 < wrtp> which is i think what you were proposing to do
13:55 < Namegduf> I wonder if the "refers to specific thing, not the
receiver" approach is the way to write singletons in Go.
13:55 < nsf> I'm not proposing anything at the moment
13:55 < nsf> just a one of the options
13:55 < Namegduf> It's kinda weird, because they're basically static methods
13:55 < wrtp> Namegduf: what's a singleton?
13:56 < Namegduf> wrtp: A type there's only ever one instance of.
13:56 < aiju> wrtp: a pseudo-non-global global variable
13:56 < Namegduf> Like timerHeap.
13:56 < wrtp> Namegduf: in general, you'd just use a function for that
13:56 < Namegduf> Yeah, that's what I'd do.
13:56 < nsf> Namegduf: How about methods of a global variable
13:56 < nsf> global variable is a singleton by itself
13:56 < nsf> its type won't be exported
13:56 < Namegduf> Not unless it's the only variable of that type.
13:57 < wrtp> the only reason for timerHeap is that it needs a type so that
it can get some methods so we can call heap functions on it
13:57 < nsf> but its methods will be
13:57 < nsf> Namegduf: exactly
13:57 < nsf> type is not exported, methods are
13:57 < nsf> and the var is
13:57 < Namegduf> Yes, I know.
13:57 < wrtp> nsf: methods aren't exported unless the variable is exported
13:57 < nsf> but var is exported
13:57 < nsf> or do you mean unless the type is exported?
13:57 < Namegduf> wrtp: I know.  Those methods ignore their receiver, which
means they're basically static methods.
13:58 < wrtp> Namegduf: yeah
13:58 < Namegduf> The only reason they're methods, not functions, is for
prettier syntax, given they do modify what they're called on.
13:58 < Namegduf> I'm wondering if that's an appropriate thing to do in that
kind of usecase, or not, when implementing a singleton type.
13:58 < wrtp> Namegduf: no, the reason they're methods is so that the can
implement the heap.Heap interface
13:58 < Namegduf> Oh, I see.
13:58 < wrtp> s/the/they
13:58 < Namegduf> That makes sense.
13:59 < wrtp> otherwise i'd have implemented them as functions
13:59 < Namegduf> Actually, I've run into this in my own code, I just used
the receiver as normal.
13:59 < Namegduf> So it was a "normal" type which just happened to only
exist once.
14:00 < wrtp> Namegduf: that's usual.  and usually, that would be just fine.
i was just trying to minimise overhead, so that all methods could do timers[0]
rather than timerHeap.timers[0]
14:01 < Namegduf> Yeah.
14:01 < Namegduf> Actually you could call the receiver "timers" in all of
them, and it'd suddenly use it without further chanes
14:01 < Namegduf> *changes
14:01 < Namegduf> But minimising overhead is reasonable.
14:01 < Namegduf> I was just trying to understand the fairly interesting
code there.
14:02 < Namegduf> Matching an interface on a "singleton type" explains it.
14:04 < steven> hey, i think i just found a way to do a race condition..  by
modifying an array thats closured from a goroutine
14:04 < steven> https://gist.github.com/858543
14:05 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts
14:05 < wrtp> steven: race conditions are very easy to create :-)
14:06 < wrtp> there's nothing in Go that stops them by design
14:06 < wrtp> steven: did you get that bot code working BTW?
14:07 < piranha> do you know if there is a faster regexp engine for Go than
the one from stdlib?  :) I saw a link to go-pkg-pcre wrapper on cat-v.org, but
it's broken :(
14:07 < aiju> tell uriel
14:08 < niemeyer> piranha: There's a codereview to port se2 to Go..  I'd
recommend trying that out, even to testbed it
14:08 < piranha> uriel: http://go-lang.cat-v.org/library-bindings here link
to go-pkg-pcre is broken
14:08 < piranha> niemeyer: it's twice as slow as regexp from stdlib :(
14:08 < aiju> russ wrote an insanely fast regex library in C
14:08 < niemeyer> Sorry, re2
14:08 < piranha> niemeyer: yep, it's called sre2 and it's slower
14:08 < aiju> it outperforms PCRE by a factor of one million on certain
regexes
14:09 < piranha> aiju: and how it's called?  :)
14:09 < aiju> http://swtch.com/~rsc/regexp/regexp1.html
14:09 < Namegduf> It's slower than PCRE on average and for compilation, but
it guarantees non-awful performance
14:09 < niemeyer> piranha: :(
14:09 < niemeyer> piranha: How're you trying it out?
14:09 < Namegduf> Permitting you to expose regexes to the user with a length
limit without them being able to do terrible things.
14:09 < piranha> niemeyer: well, in just did a simple test with
testing.Benchmark on some simple cases
14:10 < niemeyer> piranha: Note what others have said, though.  sre2 should
be linear to the input size in performance.
14:10 < piranha> well, I tried it, and application becomes 2-3 times slower
14:10 < niemeyer> piranha: What is the use case, out of curiosity?
14:10 < piranha> so it should be linear, and maybe it is, but for me it's
slow :(
14:11 < piranha> http://hg.piranha.org.ua/goreplace
14:11 < piranha> :)
14:11 < piranha> the problem is that I'm not that good in Go, and I have no
experience with C, so wrapping some C library is a bit of a challenge :)
14:11 < nsf> google's re2 isn't that fast
14:12 < nsf> https://github.com/dprokoptsev/pire that is fast (from Russia
with love :P)
14:12 < aiju> piranha: what do you need fast regex even for?
14:12 < piranha> but yeah, I'm willing to try if I'll need that
14:12 < steven> wrtp: yep:
14:12 < nsf> but not for Go though (
14:12 < steven> https://gist.github.com/858028
14:12 < piranha> aiju: well, I posted a link few messages earlier; basically
I'm tired of waiting while ack is going through my code :)
14:12 < steven> it doesnt actually do any bottish things, that parts not as
interesting..  all it does right now is properly handle incoming data on channels
14:12 < Namegduf> piranha: If performance is critical you should probably
not be using regexes
14:12 < steven> in goroutines i mean
14:13 < piranha> Namegduf: I need to!  I'm searching in files for a regexp
:)
14:13 < aiju> piranha: have you heard of grep?
14:13 < Namegduf> I think he's implementing grep.
14:13 < piranha> no way :P
14:13 < piranha> I'm doing a bicycle
14:13 < steven> and im not sure whether i should structure bot-specific
handling as a function you pass in that conforms to a given signature, or an
object conforming to a given interface..
14:13 < aiju> well, why reimplement it
14:13 < steven> thats a hard decision for me to make
14:14 -!- virtualsue [~chatzilla@nat/cisco/x-hynqkyibhwiiudce] has quit [Quit:
ChatZilla 0.9.86 [Firefox 3.5.17/20110121150727]]
14:14 < piranha> aiju: yes, I've heard of grep, but output could be better,
filtering of what to include/exclude could be better, and one thing which I need
often is replace, and I hate doing grep/sed all the time
14:14 -!- sauerbraten [~sauerbrat@p508CBA69.dip.t-dialin.net] has joined #go-nuts
14:14 < piranha> well, I suppose that's how ack appeared
14:14 < piranha> but anyway, this is also an exercise in learning Go
14:14 < aiju> huh?
14:15 < aiju> i don't get your problem
14:15 < piranha> http://betterthangrep.com/
14:15 < steven> guys..
14:16 < nsf> how is it possible?
14:16 < skelterjohn> hey you gu-uys!
14:16 < nsf> 1.  blazingly fast
14:16 < nsf> 2.  pure perl
14:16 < steven> do you ever have trouble deciding whehter you should require
a function with a given signature, or an interface conforming to a given
interface?
14:16 < nsf> wtf
14:16 < aiju> what the fuck
14:16 < aiju> this thing
14:16 < aiju> it's a shame for humanity
14:16 < Namegduf> I haven't had "trouble" yet, but it's a reasonable thing
to think about.
14:16 < aiju> look at the incredible --help output
14:16 < aiju> why the fuck does a grep tool need vhdl support
14:16 < skelterjohn> steven: depends if i want something else to use it, and
if it should be swappable for (another) something else
14:17 < Namegduf> steven: In general, require a function if there's no
obvious receiver
14:17 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has quit [Read
error: Connection reset by peer]
14:17 < nsf> :)
14:17 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts
14:17 < steven> ok.
14:17 < aiju> Color highlighting of search results.
14:17 < aiju> hahahahaha
14:18 < skelterjohn> it's not pure perl if it takes advantage of perl's
regexps
14:18 < piranha> well, grep does that :)
14:18 < steven> i guess it depends on how complex the interface is..  if it
can be summed up in a single function with specific args, it should be so.
14:18 < Namegduf> Yeah.
14:18 < aiju> if you port ack to go, ken will personally rip off your head
14:18 < steven> like, i could see handleCommand(commandname, sender, ...) as
being a function
14:18 < Namegduf> Yes, that would be good.
14:18 < piranha> aiju: anyway, just think that I'm doing a bicycle for the
sake of it; had no other ideas how to learn go :P
14:18 < steven> whereas Close(), Read(), Write() should obviously be in an
interface and so an object conforming to it should be passed in
14:18 < steven> i guess
14:19 < Namegduf> An instance of a type.
14:19 < nsf> and ack sounds a lot like awk
14:19 < nsf> I don't like that
14:19 < aiju> nsf: awk?
14:19 < ww> stupid heisenbug
14:19 < aiju> awk is a great tool
14:19 -!- pharris [~Adium@rhgw.opentext.com] has joined #go-nuts
14:19 < Namegduf> steven: In general, expect interfaces where you want data
to be passed which has functions which act on the data.
14:19 < piranha> aiju: :P I plan to add inotify-based daemon for faster
searching anyway, so it'll better
14:19 < aiju> what the fuck
14:19 < nsf> aiju: I mean the name
14:19 < Namegduf> And expect a function where you just want a function.
14:20 < Namegduf> Design on the idea that types should contain concrete
data, not be abstract, and you can stay close to actual operations on actual data.
14:23 < nsf> piranha: how about making something useful..  another
documentation generator for example
14:24 < piranha> nsf: hmmm..  I thought about another web framework, what do
you think?
14:24 < nsf> https://github.com/nsf/gortfm
14:24 < nsf> I did one
14:24 < nsf> documentation generator I mean
14:24 < nsf> I don't like web frameworks
14:24 < piranha> ah, nice
14:24 < nsf> http://nsf.github.com/go/
14:24 < nsf> here how it looks like
14:25 < piranha> nsf: I like it!
14:25 < nsf> but it is mostly keyboard-only
14:25 < nsf> something else would be nice with click'n'go interface
14:26 < nsf> for other people who don't like keyboard that much
14:26 < nsf> :)
14:26 < wrtp> steven: in general it's best to avoid callback stuff if you
can
14:27 < wrtp> a direct style is better if you can get it
14:27 < wrtp> think: how would i want to write a bot?
14:27 < wrtp> but obviously it's not always possible
14:29 < wrtp> nsf: still doesn't link to the source code :-)
14:29 < nsf> yep
14:29 < nsf> I don't think it's necessary
14:29 < nsf> :)
14:29 < wrtp> nsf: i think it's essential!
14:29 < nsf> (and I'm lazy to implement that)
14:29 < wrtp> (but of course it's your thing)
14:30 < wrtp> steven: rather than passing in a closure which is called with
an event, you could call a function, say GetEvent()
14:31 < skelterjohn> i was actually thinking "man it would be nice if this
linked source code" when i just looked at it, nsf
14:31 < skelterjohn> not joking
14:31 < nsf> skelterjohn: and as far as I remember you asked me about that
14:31 < skelterjohn> it's possible
14:31 < nsf> some time ago
14:31 < skelterjohn> i don't have a good memory for this sort of thing
14:31 < wrtp> steven: and you could arrange things so that "uninteresting
events" are filtered out.
14:32 < nsf> skelterjohn: I don't mind if someone will add that, but I'm
lazy to do it by myself
14:32 < nsf> and well there are few problems
14:32 < nsf> I don't want to host the whole go source code on this github
page
14:33 < nsf> so..  links to the golang.org are ok
14:33 < nsf> but..
14:33 < nsf> I don't know
14:33 < nsf> and it shouldn't be like that, documentation should be enough
to use a library
14:33 < nsf> if it's not..  there is a problem in documentation
14:33 < aiju> the steady state of documentation is wrong
14:34 < nsf> but if you really want to see a source code, just download it
and do that
14:34 < skelterjohn> i do.
14:34 < ww> is there an easy and convenient way to get godoc to *only* serve
docs for local packages?
14:35 < wrtp> i'll just use godoc :-)
14:35 < nsf> or in Go case most likely it's on your machine anyway
14:35 < skelterjohn> ww: I think you can tell it where to start looking
14:35 < nsf> ww: yes, there was something about that on the mailing list
14:35 < skelterjohn> and give it somewhere other than $GOROOT/src
14:37 < ww> would be nice if it would use relative links for the css and
stuff too...
14:37 -!- skelterjohn [~jasmuth@c-68-45-238-234.hsd1.nj.comcast.net] has quit
[Quit: skelterjohn]
14:37 < ww> i don't really want to dedicate a subdomain to it for e.g.
http://godoc.styx.org/pkg/bitbucket.org/ww/cabinet/
14:39 -!- chomp [~ken@c-71-206-216-232.hsd1.pa.comcast.net] has joined #go-nuts
14:43 -!- Slant [~scott@115.130.4.45] has quit [Quit: Slant]
14:56 < steven> speaking of which, does golang.org really run on the same
godoc binary that it gives us?
14:56 < steven> is it the exact same version or is it a modified version?
14:57 -!- qjcg [~qjcg@208.88.110.46] has joined #go-nuts
14:57 -!- qjcg [~qjcg@208.88.110.46] has left #go-nuts []
14:59 -!- plainhao [~plainhao@208.75.85.237] has joined #go-nuts
15:00 < exch> afaik, its the same program
15:00 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has joined #go-nuts
15:00 < steven> is every goroutine its own thread?  i know they dont
necessarily run on different processors, but im curious if they're always threads
or if sometimes they're "threads" running in a single thread like in python
15:01 < Namegduf> No.
15:01 < steven> oh, i thought every goroutine runs inside its own thread
15:02 < Namegduf> Go will distribute goroutines across an arbitrary number
of threads.
15:02 < exch> goroutines are multiplexed onto OS threads.  multiple ruotines
can run on the same thread and they can switch to different threads if the
scheduler deems it necessary to prevent everything from locking up
15:02 < Namegduf> Go will keep a given number of threads running a goroutine
each at a time, with the active goroutine in each varying.
15:03 < Namegduf> If a goroutine blocks a thread, another thread will
replace it.
15:03 < Namegduf> You generally don't need to worry about it; goroutines are
cheap, will execute concurrently, and may block however they like.
15:05 < steven> so then what does "execute concurrently" mean?  because if
two non-blocking goroutines are running simultaneously but in the same thread, i
dont see how that is concurrent.
15:05 < Namegduf> It isn't.
15:05 < wrtp> steven: concurrent doesn't mean parallel
15:05 < steven> are you saying that we can assume that any non-blocking
goroutines executing at the same time are gauranteed to run in parallel?
15:05 < steven> oh.
15:05 < steven> then i have no idea what concurrent means :)
15:05 < steven> i htought it meant parallel
15:06 < wrtp> steven: they're concurrent because when one blocks (or at any
time really) another one will run
15:06 < Namegduf> Not just that.
15:06 < Namegduf> They will run in p
15:06 < wrtp> there are two concurrent threads of execution
15:06 < Namegduf> *parallel if the number of CPU threads is above one.
15:07 < wrtp> as opposed to one serial thread of execution
15:07 < steven> this is getting really confusing suddenly.
15:07 < wrtp> yeah, they *can* run in parallel, but they *always* run
concurrently
15:07 < Namegduf> steven: You're assuming there's only two models:
15:07 < steven> so what should i safely assume is happening at any given
time when i use goroutines?
15:08 < wrtp> steven: you can make no assumption
15:08 < Namegduf> - M:1, multiple goroutines, one thread.
15:08 < Namegduf> - 1:1, one goroutine per thread.
15:08 < wrtp> apart from that chan operations will synchronise appropriately
15:08 < Namegduf> The actual state of affairs is M:N
15:09 < Namegduf> Multiple goroutines, multiple threads, different numbers
of each.
15:09 < steven> well i need to understand how goroutines work, at least in
the most basic abstract ways, so that i can use them proplerly..
15:09 < wrtp> if you GOMAXPROCS <= 1 then only one goroutine is actively
executing at a time - all the others are blocked
15:09 < Namegduf> Goroutines are lightweight "threads", scheduled over one
or more actual threads.
15:09 < wrtp> s/you//
15:10 < wrtp> steven: you can't go far wrong if you assume they're all
running in parallel
15:10 < steven> ive been assuming that so far, and havent run into trouble
yet
15:10 < nsf> at the moment goroutines are being scheduled cooperatively
15:10 < nsf> I guess that's the main thing to know about them
15:10 < wrtp> you just also have to know that there's no guarantee that a
goroutine will make progress if it doesn't talk to anything else
15:10 < nsf> it's not far from javascript or something
15:10 -!- visof [~visof@unaffiliated/visof] has quit [Remote host closed the
connection]
15:11 < nsf> :D
15:11 < wrtp> nsf: they're only cooperative if GOMAXPROCS<=1
15:11 < nsf> they are always cooperative
15:11 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has joined #go-nuts
15:11 < steven> so, regarding that statement wrtp, what happens when you
fire off a simple goroutine that doesnt block, and the goroutine who spawned it
also doesnt block?  when will the newly spawned goroutine ever execute?  if the
parent goroutine never blocks, i should assume it will never ever give the spawned
one a chance to run before the program ends.
15:11 < wrtp> nsf: i meant cooperatively scheduled
15:11 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts
15:12 < wrtp> steven: it may never execute
15:12 < Namegduf> Anyways, simplifying now I'm on a better connection and
can actually type.
15:12 < Namegduf> Bottom lining it:
15:12 < nsf> wrtp: afaik scheduler cannot stop executing goroutine in the
middle of some kind of operation
15:12 < nsf> it means they are always cooperative
15:12 < Namegduf> Go will execute GOMAXPROCS goroutines in parallel.
15:12 < wrtp> nsf: it can
15:13 < nsf> is it?
15:13 < nsf> I don't think so
15:13 < wrtp> if by "operation" you mean some kind of machine operation
15:13 < steven> is it safe for me to continue assuming they will execute in
parellel assuming i use channels (both buffered and unbuffered) proplerly to
communicate between goroutines?
15:13 < nsf> x += 2 for example
15:13 < Namegduf> Goroutines will be scheduled cooperatively across that
many threads.
15:13 < wrtp> otherwise you'd never get an parallelism
15:13 < skelterjohn> steven: "yield" is a better word than "block" in that
context
15:13 < Namegduf> Additionally, blocked goroutines may take up other
threads, but will not stop up other goroutines running.
15:13 < nsf> wrtp: erhm..  wrong
15:13 < nsf> you can get parallelism by executing 2 goroutines in parallel
15:14 < wrtp> nsf: you can easily get a race if two goroutines do x += 2
15:14 < nsf> no
15:14 < nsf> that's not what I meant
15:14 < wrtp> nsf: yes, and those 2 goroutines are not cooperatively
scheduled
15:14 < nsf> :(
15:14 < steven> i guess what im saying is, i dont care so much about
implementation details of how goroutines work, i just want to know what kind of
abstraction im working with and what its safe to assume, so i can use them
proplerly
15:14 < Namegduf> This is specific to gc, and subject to change.  The number
of threads used is implementation-defined.
15:14 < wrtp> they don't cooperate with each other - they are independently
executing
15:15 < nsf> wrtp: they are cooperating on a global level, again..
scheduler can't stop a goroutine
15:15 < steven> (similarly to how i dont care what kind of imlementation
append() uses, i just want to konw exactly what it will do, ie append one more
element to the slice.)
15:15 < Namegduf> steven: Treat them like threads, but remember that in a
loop making no syscalls, doing no allocation, and sending no messages, other
goroutines may not get a chance to run.
15:15 < nsf> only OS scheduler can stop a thread
15:15 < nsf> and switch everything to another thread
15:15 < steven> when you say sending messages you mean via channels, right?
15:15 < Namegduf> Yes.
15:15 < nsf> go scheduler is just a plain piece of code
15:15 < steven> and im not sure what syscalls means in this context.
15:15 < steven> i assume you dont mean calls to package syscall
15:15 < steven> ;)
15:15 < wrtp> nsf: but there can be N threads executing *in parallel*
15:16 < nsf> yes
15:16 < Namegduf> steven: I do, but I include indirect ones through other
packages.
15:16 < steven> like fmt.Printf?
15:16 < Namegduf> Yes.
15:16 < steven> (which i assume uses syscall underneath)
15:16 < Namegduf> Almost all interactions with anything outside the program
will result in syscalls.
15:16 < nsf> but their execution of multiple goroutines within a single
thread is always cooperative
15:16 < wrtp> nsf: those threads are not being scheduled cooperatively
15:16 < nsf> s/their//
15:16 < steven> oh ok.
15:16 < Namegduf> Syscalls are basically asking the kernel to do something
for you
15:16 < nsf> wrtp: but threads are being scheduler by OS
15:16 < nsf> the way OS likes to do it :)
15:16 < wrtp> nsf: and?
15:17 < nsf> and nothing
15:17 < Namegduf> Do not worry about parallelism- Go can provide it with
GOMAXPROCS at present and in other implementations can provide it other ways.
15:17 < nsf> goroutines are scheduler cooperatively :)
15:17 < wrtp> they're not cooperating
15:17 < nsf> scheduled*
15:17 < nsf> they're cooperating by using the same software scheduler :)
15:17 < steven> i wish my work was in Go, not Ruby on Rails..  sigh.
15:17 < wrtp> nsf: cooperative scheduling means that one thread explicitly
asks to pass control to another
15:17 < Namegduf> Do not worry about paying the high price of a thread per
goroutine- gc will not spawn a thread per goroutine.  gccgo will, but that's
intended to be improved.
15:17 < wrtp> nsf: go threads do not (always) use that model
15:18 < skelterjohn> wrtp: and in go, they do that by doing io, a syscall,
or runtime.Gosched :)
15:18 < wrtp> nsf: therefore they're not cooperatively scheduled
15:18 < Namegduf> It is not required by the implementation and not a nice
implementation to use.
15:18 < steven> do you know how many hoops we have to jump through to get
simple stuff working because ruby is so limited?  its ridiculous.
15:18 < wrtp> skelterjohn: or by just running, if GOMAXPROCS>1
15:18 < Namegduf> Discussing exactly what Go guarantees is complicated and
not particularly useful
15:18 < nsf> wrtp: ok, I will agree with "they're not completely
cooperatively scheduled"
15:18 < Namegduf> It doesn't guarantee much.
15:19 < wrtp> nsf: phew
15:19 < nsf> :)
15:19 < Namegduf> Discussing specifically what it guarantees for GOMAXPROCS
is probably a bad idea because GOMAXPROCS itself is an implementation detail...
15:19 < ww> GOMAXPROCS means OS processes or OS threads?
15:19 < Namegduf> OS threads.
15:20 < wrtp> steven: if you go with "they run completely in parallel, but
they may also run strictly one after another" then you won't go far wrong
15:20 < wrtp> ww: *running* OS threads
15:20 < Namegduf> More precisely, the number of OS threads running, not
blocked.
15:20 < Namegduf> Yeah.
15:20 < Namegduf> If one blocks Go may spawn another.
15:20 < steven> theres got to be some way of putting it where i cant go
wrong at all, though, right?
15:20 < nsf> go tries to abstract away all these stuff for some reason
15:20 < nsf> e.g.  OS threads
15:20 < Namegduf> It's also a maximum, for the obvious reason that there
might not be that many active goroutines.
15:20 < nsf> which is a mistake imho
15:21 < Namegduf> They aren't so much abstracted as an implementation detail
15:21 < ww> nsf: as well it should
15:21 < wrtp> steven: it's not hard to get it right - most useful code
communicates with other stuff to get things done
15:21 < Namegduf> You don't need to worry about them, they're just used to
make goroutines work
15:21 < nsf> it works for web servers
15:21 < nsf> but in general
15:21 < nsf> I don't think it's such a good abstraction
15:22 < Namegduf> I don't think it is an abstraction, because you don't
interact with them through some generic thing
15:22 < steven> wrtp: so the code i pasted to you earlier is written with
the right ideas/assumptions?
15:22 < Namegduf> You don't interact with them at all.
15:22 < wrtp> nsf: you'd prefer to have a different communication mechanism
to talk to a thread vs a coroutine?
15:22 < steven> the irc-bot stuff..
15:22 < wrtp> steven: yeah, i think so
15:22 < steven> cool
15:22 < nsf> and I don't have an opinion on how it should be
15:22 < wrtp> although i haven't had time to look at it much
15:22 < nsf> I can only say what feels wrong
15:22 < steven> i want to write a Rails almost-clone in idiomatic Go
15:22 < nsf> but it means that probably I'm wrong as well
15:22 < wrtp> nsf: why does it feel wrong to you?
15:22 < skelterjohn> steven: what does rails provide for you?
15:23 < nsf> I don't know :)
15:23 < steven> a job
15:23 < Namegduf> I like goroutines as they are.
15:23 < steven> hehe
15:23 < nsf> wrtp: I thought it's called "feels" because there is no logic
behind it :)
15:23 < wrtp> Namegduf: me too!
15:23 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has quit [Remote host closed
the connection]
15:23 < steven> you know, i think that using structs (for fields) and
methods on structs (for relationships), a quality ORM can be written in Go
15:23 < wrtp> nsf: no logic doesn't mean you can't talk about the feeling
:-)
15:23 < Namegduf> They behave as threads but are very cheap AND parallel
where useful, and the implementation makes it work (with a little prodding on the
parallel part).
15:23 < wrtp> steven: yeah
15:24 < wrtp> i've thought that
15:24 < Namegduf> ORMs make me sad.  :(
15:24 < steven> i think i would like to do that, starting with sqlite3.
15:24 < wrtp> even if you don't call it an ORM
15:24 < nsf> they are not that cheap
15:24 < steven> Namegduf: they can be useful when you wanna just get stuff
done.
15:24 < Namegduf> More precisely, the number of OS threads running, not
blocked.ing
15:24 < nsf> 4k per goroutine
15:24 < Namegduf> Er
15:24 < Namegduf> They're code which purely doesn't do anything.
15:24 < steven> anyone wanna go at it with me?
15:24 < wrtp> steven: call it a GoRM :-)
15:24 < steven> hehehe!  i like it!
15:24 < Namegduf> steven: I think it'd be better to have a generic
persistence thing than an ORM
15:25 < wrtp> nsf: i think it could be less than 4k per goroutine
15:25 < Namegduf> A simple persistence library, perhaps usable with an SQL
backend, would seem simpler.
15:25 < wrtp> nsf: the compiler could work out a stack minimum and use only
that
15:25 < Namegduf> It could be, they'd just have to decrease the base stack
size.
15:25 < nsf> also goroutines is a functional kind of abstraction, but the
general problem in parallel algos is data structures
15:25 < steven> im thinking of like..  db.getObject("tablename", id_int,
&obj) where obj is type SomeStruct, and has fields like name string, age int, etc
15:26 < nsf> well, Go provides only a channel
15:26 -!- shvntr [~shvntr@113.84.144.143] has quit [Quit: leaving]
15:26 < nsf> and says it's everything
15:26 < Namegduf> An SQL-specific persistence layer
15:26 < Namegduf> Eh.
15:26 < steven> and then obj.Save() will save it, obj.Brothers() gives you
the relation for all "brother" objects with "tablename" matching id = id_int,
15:26 < steven> etc.
15:26 < nsf> "use channels..  nya nya nya"
15:26 -!- sacho [~sacho@87-126-37-121.btc-net.bg] has joined #go-nuts
15:26 < steven> well yeah, mostly anything interesting is using sql
15:26 < Namegduf> steven: Your type would need to be designed to do it.
15:26 < wrtp> nsf: the Go attitude is that parallel data structures are
hard, so keep things serial as much as you can
15:26 < Namegduf> Which means it would need to be in that package.
15:26 < steven> thats fine, the type can be specific to that table in the
sql db
15:27 < Namegduf> Actually, no, it'd just need to be importing that package.
15:27 < steven> i think this is a good idea
15:27 < nsf> wrtp: I guess it's not what I want from a systems programming
language
15:27 < steven> and im ok with limiting it to SQL.
15:27 < Namegduf> Well, what are you trying to do?
15:27 < Namegduf> It can't persist arbitrary types
15:27 < nsf> squeezing everything from the available hardware is my idea of
a systems programming language :)
15:28 < wrtp> steven: how would you do relations
15:28 < Namegduf> obj seems to just represent a DB row
15:28 < steven> wrtp: im not sure..  brb work
15:28 < wrtp> nsf: that might be your definition, but i don't think it's
universally held :-)
15:29 < Namegduf> Serial data structures are too slow in some cases.  :(
15:30 < wrtp> Namegduf: sure, but there's nothing stopping you implementing
parallel data structures in go too...
15:30 < wrtp> (well, apart from no generics)
15:30 < Namegduf> wrtp: This is true, and I did it.
15:31 < wrtp> nsf: i haven't seen another decent concurrency abstraction
15:32 < wrtp> (that works well for imperative languages, he says quickly)
15:33 < nsf> I haven't either
15:34 < wrtp> nsf: so you'd ditch channels, but replace 'em with nothing
else.  fair enough, who needs concurrency anyway?
15:35 < nsf> but channels is an experimental feature
15:35 < nsf> adding it to a practical programming language
15:35 < nsf> isn't the best idea imho
15:35 < wrtp> nsf: not in go it isn't
15:35 < wrtp> they've been used in quite a few programming languages, and
they work well
15:36 < nsf> but whatever, google's language
15:36 < nsf> they are free to put everything they want into it
15:36 < nsf> I'm making my own, lol
15:36 < wrtp> and they're much better than the ubiquitous mutexes and
semaphores
15:36 < nsf> :)
15:36 < xulfer> Squeezing everything out of the hardware doesn't often
happen with C threads either.
15:36 < wrtp> with mutexes & semaphores from the '70s, right?
15:36 < skelterjohn> oldie but a goodie!
15:36 < Namegduf> I just wish channels could replace mutexes efficiently in
all usecases
15:36 < nsf> xulfer: because people don't even know how to use it
15:37 < nsf> and channel is just a mutexed queue
15:37 < Namegduf> They can technically do the same thing but "efficiently",
they struggle with.
15:37 < xulfer> Because synchronization has massive overhead, and so does
context switching, and it's often slower than a single thread.
15:37 < nsf> because efficient queue implementation requires additional info
15:37 < nsf> like amount of senders and receivers
15:37 < xulfer> and even on 'multi core', there's not even a tiny bit of
assurance your 20 threads or whatever won't be run on a single core.
15:38 < wrtp> nsf: the compiler could theoretically work out some info about
sender and receiver count
15:38 < nsf> xulfer: it's not the problem in Go case
15:38 < wrtp> in some cases
15:38 < nsf> wrtp: in some cases, maybe, we'll see
15:38 < wrtp> Namegduf: i'd like to see channels that were as efficient as
semaphores
15:38 < Namegduf> As I understand it, being usable in select{} forces a slow
implementation
15:39 < nsf> you see, channels are too general
15:39 < nsf> like all in one
15:39 < nsf> one data structure to rule them all
15:39 < nsf> won't work
15:39 < Namegduf> Maps are too general.  :P
15:39 < wrtp> general enough to allow composability, which is crucial
15:39 < taruti> just don't use channels if you feel like that
15:39 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has quit [Quit:
peace in teh middle east]
15:39 < Namegduf> You can use your own thing where you need to
15:39 < nsf> yeah, I'm just complaining
15:40 < nsf> nevermind :)
15:40 < Namegduf> They're nice for writing nice code, I just wish I didn't
find myself falling back to mutexes for package internals so often.
15:40 < wrtp> Namegduf: i don't mind using mutexes; that's not what channels
are about.
15:40 < Namegduf> Maybe it's just because I have lots and lots of shared
state that everything needs to use, and quickly, with no direct communication with
anything else.
15:41 < wrtp> Namegduf: yeah
15:41 < Namegduf> Or maybe I'm just bad at designing with them.  :P
15:41 < wrtp> Namegduf: that's a good model for a mutex-based thing
15:41 < nsf> that's a bad model for concurrency :)
15:42 < wrtp> nsf: no, it's a bad model for parallelism :-)
15:42 < nsf> ok
15:42 < nsf> I don't like to separate these things
15:42 < Namegduf> wrtp: My big issue is that there's lots and lots of
*reads*.
15:42 < wrtp> and performance is often adequate for needs.  blazing
performance is not always necessary.
15:43 < Namegduf> And there's no way using channels to get them to be fast.
15:43 < wrtp> i tend to use channels when there are *things happing* and
code that needs to know about those things.
15:43 < Namegduf> RWMutex is awful where contention is low
15:43 < wrtp> s/happing/happening/
15:43 < Namegduf> Two locks for every reader.
15:44 -!- rlab_ [~Miranda@91.200.158.34] has joined #go-nuts
15:44 < Namegduf> A regular Mutex is probably faster.
15:44 < wrtp> Namegduf: actually it uses an atomic op + a mutex lock now
15:45 < wrtp> Namegduf: a regular mutex must be faster
15:45 < wrtp> Namegduf: because it's doing strictly less
15:45 < Namegduf> wrtp: Mutex lock == an atomic op.
15:45 < wrtp> Namegduf: no, because a mutex lock can block and an atomic op
cannot
15:46 < Namegduf> wrtp: Well, okay, an atomic op is the expensive part of an
uncontented mutex lock
15:46 < Namegduf> *contended
15:46 < Namegduf> And RWMutex can be faster where the amount of gain from
multiple readers at once is significantly more than the cost of using it.
15:46 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 252 seconds]
15:47 -!- erus_ [50b135f2@gateway/web/freenode/ip.80.177.53.242] has joined
#go-nuts
15:47 < erus_> skelterjohn: go-gb examples arnt building properly for moi
15:48 < skelterjohn> hmm - apparently cgo does things a bit differently now
15:49 < skelterjohn> is it the package "e" that is messing up?
15:49 * wrtp is looking at the Semacquire implementation
15:49 < Namegduf> wrtp: Doesn't it do an atomic compare-and-swap?
15:50 < skelterjohn> erus_: ah i see - cgo now puts its intermediate stuff
in _obj instead of .
15:50 < erus_> yup e
15:51 < skelterjohn> that actually makes gb's job a bit easier
15:51 < skelterjohn> aside from me having to rewrite some stuff
15:51 < skelterjohn> but i had do do some weird things to make cgo not
litter . with garbage files
15:51 < wrtp> skelterjohn: most stuff :-) but all go files, at any rate.
15:52 < skelterjohn> seems that all generated sources go in _obj, but the
object files still go in .
15:52 < skelterjohn> that seems completely backwards
15:53 < skelterjohn> with gb, i made a _cgo directory and did all cgo
related stuff in there
15:54 < skelterjohn> so to clean i could just rm -rf _cgo
15:54 < wrtp> skelterjohn: i know, it's my fault
15:54 < wrtp> skelterjohn: but i tried putting object files in _obj and
everything broke
15:54 < wrtp> lots of Makefiles have lines like: CGO_OFILES=x.o y.o
15:55 < wrtp> which assumes x.o and y.o are in the current directory
15:55 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Remote host
closed the connection]
15:55 < skelterjohn> that would be for provided C source, right?
15:55 < skelterjohn> cgo doesn't generate those
15:56 < wrtp> skelterjohn: yes
15:56 < skelterjohn> do you put generated source in _obj just because it is
already reserved and gets cleaned up?
15:57 < wrtp> but if all objects are in _obj then the rule for making .o
from .c will put the result in _obj not the current directory, so the dependency
breaks
15:57 < wrtp> skelterjohn: yes
15:57 < skelterjohn> oh i understand that, no worries
15:57 < wrtp> i might make a CL to put all objects in _obj, but i wanted to
fix the immediate problem first
15:57 < skelterjohn> the only thing that breaks gb is the fact that cgo puts
things in places automatically
15:58 < skelterjohn> not the way you organize things
15:58 -!- Urmel|Work [~UrmelWork@cache1.uk.logica.com] has quit [Remote host
closed the connection]
15:58 < skelterjohn> is there a way to tell cgo where to put generated
files?
15:58 < wrtp> skelterjohn: i don't think so
15:58 < wrtp> skelterjohn: it's fairly messy
15:59 < skelterjohn> i just feel like cgo should have a -dst= flag, but i
can deal
15:59 < steven> guys,
15:59 < steven> https://gist.github.com/858686
16:00 < steven> step in the direction of automatically fetching the
table-name for a given obj (struct)
16:02 < wrtp> steven: i'm not entirely sure about automatically associating
type names with table names...  but i can't entirely think of a good reason why.
16:02 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has quit [Read
error: Connection reset by peer]
16:03 < steven> i think it would be a good default..  ie as long as we
provide some mechanism to manually specify the table name, but that would be
optional
16:03 < wrtp> steven: an alternative would be to have a registry of table
names and their associated types
16:03 < skelterjohn> erus_: fixed.  i just added _obj/ before a lot of the
hard coded names in gb/cgo.go
16:03 < skelterjohn> at least, the example builds :)
16:03 < steven> thats a less fun alternative wrtp ;)
16:04 < wrtp> steven: yeah
16:04 < skelterjohn> i like associating tables with types
16:05 < skelterjohn> steven: you're not using reflection for this every time
you do a look-up, right?
16:05 < skelterjohn> i feel like to do this well, you'd have to generate
some source
16:05 < wrtp> skelterjohn: i agree, i think, but i'm not sure about
associating tables with type names...
16:05 < skelterjohn> for the specific db
16:05 < wrtp> skelterjohn: nah, get it working first, then optimise :-)
16:06 < skelterjohn> heh
16:06 < steven> it could be cached, sure.
16:06 < wrtp> reflection is just about to become a whole lot faster anyway
16:06 < steven> but the point is to make it automatically done (even if just
once)
16:06 < wrtp> steven: one problem with using the type name as the table name
is that you can't have two tables holding the same type
16:07 < steven> uhh..
16:07 < steven> im confused
16:07 < skelterjohn> why is that bad, exactly?  :)
16:08 < steven> wrtp: when would you want two tables holding the same type?
16:08 < wrtp> different permissions?
16:08 < wrtp> different indexing strategies?
16:08 < steven> oh.
16:08 < skelterjohn> different contexts
16:08 < steven> thats where having a mechanism to specify the table name
manually comes in handy
16:08 < steven> like i said, this would be the default way, but it could be
overridden too.
16:10 < skelterjohn> nah, i'm leaning wrtp's way, now.  you should think of
the tables as remote collections of your type
16:10 < skelterjohn> and name them accordingly
16:10 < steven> i could do the basics of GoRM, but i couldnt do the more
complex stuff like join tables and building complex queries and whatnot..  but at
least i can start paving the road for someone smarter than me to take over :)
16:10 < wrtp> i'm going the other way now :-)
16:10 < skelterjohn> lol
16:10 < wrtp> thinking about it, i do like the idea of single table per type
because it makes relations easier
16:11 < wrtp> if one type has a slice of another type, you can automatically
fetch the other type from the other type's table
16:11 < wrtp> using the appropriate key relation
16:11 * steven considers pulling https://github.com/kuroneko/gosqlite3 and
starting GoRM on github
16:11 < skelterjohn> ah
16:12 < wrtp> steven: i think it's a good idea
16:12 < skelterjohn> certainly worth experimenting with
16:12 < steven> wanna help?  :)
16:12 < skelterjohn> i'll lend you a build tool
16:12 < skelterjohn> lol
16:12 < wrtp> steven: sure - i'll shout loudly from the sidelines!
16:12 < steven> ha
16:12 < wrtp> steven: and provide constructive criticism
16:12 -!- chomp [~ken@c-71-206-216-232.hsd1.pa.comcast.net] has quit [Read error:
Connection reset by peer]
16:12 < steven> i wonder if goroutines and sqlite3 will mix poorly
16:13 -!- mattn_jp [~mattn@s60.BMT-e1.vectant.ne.jp] has joined #go-nuts
16:13 < wrtp> steven: i can't remember if it's thread safe or not
16:14 < wrtp> steven: rather than diving in to start with, how about coming
up with a design document - a suggestion of how you plan to map go types to sql
tables
16:14 < wrtp> and post it as a proposal to golang or golang-dev
16:14 < wrtp> (or here, first)
16:15 < skelterjohn> sometimes it's important to not get ahead of oneself...
throw-away experiments are a good way to see if something is feasible
16:15 < skelterjohn> as long as you know you'll be ok with scrapping the
whole thing
16:15 < skelterjohn> and starting over
16:15 < wrtp> skelterjohn: i don't see anything that's rocket-sciency about
this.  the difficult bit is working out how the mapping should work, IMHO
16:15 < skelterjohn> yes...
16:16 < wrtp> although it'd be useful to know whether sqlite was thread safe
:-)
16:16 < wrtp> steven: since i suggested the name, i want commit privileges
:-)
16:17 < skelterjohn> lol
16:17 < steven> haha sure thing.
16:17 < skelterjohn> can you do that with the free github acct?
16:18 < steven> wrtp: the difficult part is what?  figureing out how to map
struct names to table names?
16:18 < wrtp> steven: working out how to map go types to sql entities
16:18 -!- xyproto [~alexander@77.40.159.131] has quit [Quit: WeeChat 0.3.4]
16:19 < steven> like, actually copy the data from one to the other?  ie,
once i have a map[string]string, getting that into the fields of the struct?
16:19 -!- sauerbraten [~sauerbrat@p508CBA69.dip.t-dialin.net] has quit [Remote
host closed the connection]
16:20 < wrtp> no, the details of the mapping, like can you have type Shop
struct {Name string; Inventory []*Item}
16:21 < steven> oh, you mean regarding relationships?
16:21 < wrtp> yeah
16:21 < steven> the rest seems easy, but relationships will probably be
trickier
16:21 < wrtp> steven: yeah, and they're the interesting thing
16:21 < steven> i was assuming there wouldnt be any arrays or slices for
relationships, instead there would be methods
16:22 < wrtp> steven: you could have both
16:22 < wrtp> slices are nice because they're a concrete thing
16:22 < steven> ie type Shop struct {Name string} ..  func (shop Shop)
Items() []Item { ...  }
16:22 < steven> making the relationships as fields seems like asking for a
Lot of trouble
16:22 < wrtp> depends whether you're reading or writing i guess
16:22 < steven> (1) you shouldnt store all the data in memory, especially in
a struct
16:23 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Quit: Leaving.]
16:23 < steven> (2) what would be done about recursive relationships?
(probably not that big of a deal in retrospect)
16:23 < steven> (3) its cached instead of fetched on demand
16:23 < wrtp> steven: how do you do updates?
16:24 < steven> #3 probably actually is a good idea, though..  ie, it should
have an internal, inaccessible cache which the public function uses
16:24 < steven> hmm, good question
16:24 < wrtp> how do standard ORM schemes deal with updates?
16:24 < steven> theres certainly no way to override field-set operations,
that would be silly
16:25 < steven> they do just that.  they override the setter
16:25 < wrtp> override the setter to make the change to the DB?
16:25 < steven> in Go you would probably have to have a method SetName(),
etc
16:25 < steven> no, override the setter to store the value locally, and when
SAve() is called, update the db
16:26 < steven> i wonder if theres a way to add methods..  i think there is.
16:26 < steven> but then we're gettting into ugly rails territory.
16:26 < steven> that kind of magic makes life so hard
16:26 < wrtp> nah, you can't do that and you don't want to
16:26 < skelterjohn> just do whole-object copying
16:27 < steven> actually that was a stupid idea
16:27 < steven> it should just be..  shop.name = 'whatever'; shop.Save()
16:27 < steven> no reason to override setters if tahts all they would be
doing anyway is storing it locally until a sve operatipon
16:27 < wrtp> steven: that's easy.  but what about relations?
16:28 < skelterjohn> shop.SaveRecursive() ?
16:28 < wrtp> update item.colour = 'red' where shop.name = 'Tesco'
16:29 < wrtp> (erm my SQL memory is ancient and faulty)
16:30 < steven> maybe db.Find(&shop, "tesco", "name") or db.Find(&shop, 42,
"id")
16:30 < steven> hmm..  my brain hurts now
16:31 < skelterjohn> maybe you also store a map[string]*Shop in the database
16:31 < wrtp> i think part of the problem (for me anyway) is that i don't
have a coherent model of what this thing is meant to be doing for us
16:31 < skelterjohn> and use it to look up the database
16:31 < skelterjohn> *look up the shop
16:31 < wrtp> we've got several functionalities:
16:32 < wrtp> - read some info from a db into a data structure
16:32 < wrtp> - write some info from a data structure into a db
16:32 < wrtp> - read some info into a data structure, modify it, write it
out to update the db
16:33 -!- jbooth1 [~jay@209.249.216.2] has joined #go-nuts
16:33 < wrtp> the first two alone are quite straightforward
16:33 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has quit [Quit:
Computer has gone to sleep.]
16:33 < wrtp> no caching or anything required
16:33 < wrtp> but the third is harder, i think
16:34 < skelterjohn> start with just writing the whole thing
16:35 < skelterjohn> efficiency is an implementation detail :)
16:35 < steven> wrtp: its supposed to abstract away the SQL so you're only
dealing with data structures, fields, and methods, and pretty much never touch raw
sql
16:35 < steven> in my mind anyway.
16:36 < steven> wrtp: i dont think the third is any different than the first
and second combined
16:36 < steven> wrtp: its just a combination of them, with a foo.bar = 42
put in between
16:37 < wrtp> maybe
16:37 < steven> it can be done, i think..  the problem is going to be
efficiency.
16:37 < steven> without writing raw sql code, you're going to have a hard
time building up proper transactional, efficient sql statements
16:37 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts
16:38 < wrtp> yeah, if i have 1000 rows and i change bar=42 in one, i don't
want to write out all the 1000 rows again
16:38 < steven> thats not really an issue
16:38 < steven> unless you're doing a save on an entire array, which im not
sure why that would happen or what woudl trigger that.
16:39 < wrtp> why not?  how does the gorm code know that bar has changed
there?
16:39 < steven> you would just do foo.bar = 42; foo.Save()
16:39 < skelterjohn> or gorm.Save(&foo)
16:39 < steven> ahh i like that better :)
16:39 < wrtp> steven: i though the point was that you could make arbitrary
updates throughout a data structure, then do Save on the data structure and it
would do something reasonably efficient
16:39 < steven> i keep forgetting this isnt ruby, and you cant magically add
methods..  so any methods written need to be always written.
16:40 < steven> so most (if not all?) of the methods would need to be in
package gorm
16:40 < skelterjohn> be most usable if they all were
16:40 < steven> wrtp: you would.  but the data structure generally doesnt
represent a whole table, but rather a single row in the table
16:40 < skelterjohn> so the user doesn't have to do anything other than
gorm.Save(&mydata)
16:41 < skelterjohn> maybe something extra to store db location info
16:41 < steven> Shop is a struct representing the table..  shop, an instance
of Shop, represents a single row (it has "id int" for that)
16:41 -!- Project-2501 [~Marvin@82.84.85.240] has joined #go-nuts
16:41 < steven> skelterjohn: db.Save()
16:41 < steven> db is type *Gorm :)
16:41 < steven> db := new(gorm.Gorm)
16:41 < skelterjohn> ah
16:42 < steven> db.Use("sqlite3", "path_to_db_file"); db.Save(&shop)
16:42 < steven> db.Find(&shop, "id", 1)
16:43 < steven> (thats better than shop := db.Find("id", 1) because then
Find has no way of konwing or specifying shop's type
16:43 < skelterjohn> it does if ids are unique across all objects
16:43 < steven> so you would be forced to do: var shop Shop; db.Find(...)
16:43 < skelterjohn> if they were, for instance, mapped to addresses
16:43 -!- awidegreen [~quassel@c-eacae555.08-2-73746f39.cust.bredbandsbolaget.se]
has joined #go-nuts
16:43 < steven> skelterjohn: it wouldnt know what table to look at though
16:44 < steven> just given "id" (the field name) and 1 (the value), doesnt
tell it what table to look in
16:44 < skelterjohn> implementation detail :)
16:44 < steven> i disagree
16:44 < skelterjohn> lookup-type+lookup-value has same big-oh as
lookup-value-given-type
16:45 < skelterjohn> well, not exactly
16:45 < steven> how would you implement this function to know what table to
look in?  func Find(fieldName string, value string) interface{} { ...  }
16:45 < skelterjohn> i woudlnt' implement that function
16:45 < steven> see what i mean?  you somehow need to know what table to
look in.
16:45 < steven> then im not sure we're having the same conversation ;)
16:45 < skelterjohn> i'd store, in the db, a map[string]TheType
16:46 < skelterjohn> and i'd get that map, lookup the thingy
16:46 < steven> but if you dont pass the thingy into Find() then you dont
have it
16:46 < skelterjohn> it's referenced by the map
16:46 < _nil> is the build broken on amd64 osx?
16:46 < skelterjohn> _nil: no
16:46 < skelterjohn> <- amd64 os x
16:47 < skelterjohn> i got the latest this morning
16:47 < skelterjohn> _nil: goinstall -a -clean
16:47 < steven> im just saying we should use `var shop Shop; db.Find(&shop,
"id", "42")` instead of `shop := db.Find("id", "42")` because the latter is
impossible.
16:47 < skelterjohn> :)
16:47 < skelterjohn> steven: it's clearly not impossible, even if you think
it's a silly idea
16:47 < steven> i didnt expect any disagreement about that statement, and so
it threw me off.
16:47 < skelterjohn> i won't argue with the opinion part
16:48 -!- JusticeFries [~JusticeFr@173-8-247-218-Colorado.hfc.comcastbusiness.net]
has joined #go-nuts
16:48 < _nil> skelterjohn: i'm on Tip
16:48 < _nil> working on a compiler bug
16:48 < skelterjohn> _nil: i did a "hg pull -u"
16:48 < skelterjohn> i don't know if that puts me on tip or not
16:48 < _nil> is that the same thing as hg sync
16:48 < _nil> i bet so
16:48 < steven> im saying it cant be done because you dont specify a table
name, and `db` represents the whole database, not just one table in it.
16:48 < skelterjohn> don't know
16:48 < skelterjohn> not an hg expert
16:48 < skelterjohn> steven: I'm saying it can be done if you keep id's
unique across all objects
16:48 < skelterjohn> oh - id is user-defined for you
16:48 -!- nixness [~dsc@78.100.186.63] has joined #go-nuts
16:48 < skelterjohn> not db-defined
16:49 < steven> uhh
16:49 < steven> shop_table can have a value at id=1 and item_table can have
a value at id=1
16:49 < skelterjohn> and i was talking about a scheme where that was not
allowde
16:49 < steven> ive never heard of ids being unique in an entire database
before
16:49 < skelterjohn> as i said.
16:49 < steven> this is completely new to me.
16:49 < skelterjohn> nevertheless it is perfectly possible
16:49 < steven> im not so sure it is.
16:50 < steven> and even if it is, im not sure what the benefit is
16:50 < skelterjohn> like i said, i won't argue that it isn't kind of silly
16:50 < skelterjohn> it's called 'brainstorming'
16:50 < steven> ok sorry
16:50 -!- foocraft [~dsc@78.100.210.180] has quit [Ping timeout: 255 seconds]
16:50 < steven> im finally on the same page as you
16:50 < steven> took me a minute to get my brain wrapped around what you
were saying.
16:51 < steven> anyway yeah.  i agree.
16:51 < steven> anyway i thnk we're onto something.
16:51 < skelterjohn> lol
16:51 < skelterjohn> good
16:51 < steven> im not sure how to manually fill in struct members when all
you have is the object, a name of a struct field as a string, and the value as a
string.
16:51 -!- piranha [~piranha@5ED4B890.cm-7-5c.dynamic.ziggo.nl] has joined #go-nuts
16:52 < steven> using a type switch, it seems reasonable to do type
conversions..  ie, if fieldtype == int, then struct.field = strconv.Atoi(val)
16:53 < skelterjohn> you'd have to define it for each possible type
16:53 < skelterjohn> hey - you may be interested in something i did -
goargcfg.googlecode.com
16:53 < steven> but i dont know how to actually do struct_obj."fieldname" =
value; i dont see a way in reflect package to do something like
SetField(&struct_obj, "fieldname", value)
16:53 < skelterjohn> it uses reflection and stuff to fill in data structures
from command line arguments
16:54 < skelterjohn> might be what you're looking for
16:54 < skelterjohn> in a different context
16:54 < steven> sweet.
16:54 -!- itrekkie [~itrekkie@ip72-211-129-122.tc.ph.cox.net] has quit [Read
error: Operation timed out]
16:55 < skelterjohn> what it does is let you define something like type X
struct { a int }
16:55 < skelterjohn> and on the command line say -a=5
16:55 -!- itrekkie [~itrekkie@ip72-211-129-122.tc.ph.cox.net] has joined #go-nuts
16:55 < skelterjohn> you can also nest structs
16:55 < exch> Is all this really worth it?  You're adding a sizable chunk of
abstraction which may, or may not make things easier to use.  It will certainly
add a considerable amount of performance and resource overhead with struct
allocations, reflection stuff etc
16:55 < skelterjohn> a.b=3
16:55 < steven> looks like exactly what im trying to do, skelterjohn
16:55 -!- tvw [~tv@212.79.9.150] has joined #go-nuts
16:55 < skelterjohn> exch: consider it an experiment
16:55 < exch> fair enough
16:56 < skelterjohn> i made goargcfg because i hate doign configuration work
16:56 -!- binarypie [~binarypie@adsl-99-35-135-146.dsl.pltn13.sbcglobal.net] has
joined #go-nuts
16:56 < skelterjohn> i don't like listing all the possible parameters for
the cmmand line twice - once declaring the variable and then declaring tha tit is
used on the command lien
16:56 < skelterjohn> lots of typos, whee
16:56 < steven> can you just cast any go value (including `val shop Shop`)
to reflect.Value?  is that how it works?
16:57 < skelterjohn> so, with argcfg, you can just have a struct with a
bunch of stuff, and then populate it
16:57 < skelterjohn> steven: i think so
16:57 < skelterjohn> i wrote argcfg a while ago and i kinda forgot how it
worsk
16:57 < skelterjohn> works
16:57 < exch> reflect.Value is an interface value which can represent any Go
type value
16:57 < steven> oh no, nevermind
16:57 < exch> it can be *StructValue, *IntValue, *InterfaceValue, etc, etc
16:57 -!- larva_ [~larvanitr@ec2-46-51-171-183.eu-west-1.compute.amazonaws.com]
has quit [Read error: Connection reset by peer]
16:57 < steven> you use reflect.NewValue(shop)
16:57 < steven> then you can cast that to StructValue, etc.
16:58 < steven> excellent, this stuff is gold.
16:58 -!- erus_ [50b135f2@gateway/web/freenode/ip.80.177.53.242] has quit [Ping
timeout: 245 seconds]
16:58 < steven> btw, who was it who says that the reflect package is about
to get a whole lot faster?
16:58 < steven> and how do you know?
16:58 < skelterjohn> wrtp, and he is in the know
16:58 < skelterjohn> about stuff
16:59 < skelterjohn> one of the bigger contributors who isn't actually
working for google
16:59 < skelterjohn> at least, as far as i know
16:59 < skelterjohn> lunch time
16:59 -!- MizardX [MizardX@ip-98-8-72-178.dialup.ice.net] has joined #go-nuts
16:59 -!- larva [~larvanitr@ec2-46-51-171-183.eu-west-1.compute.amazonaws.com] has
joined #go-nuts
17:01 < steven> oh cool.
17:03 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has joined #go-nuts
17:08 -!- skejoe [~skejoe@188.114.142.162] has joined #go-nuts
17:12 < nsf> hm..  I'm wondering why this lexer hack is actually required
17:12 < nsf> maybe it's possible to form the grammar the way it won't be
required anymore
17:13 < nsf> if () {} still will be required though
17:13 < nsf> hm..
17:13 < nsf> let's see
17:17 -!- visof [~visof@41.34.216.9] has joined #go-nuts
17:17 -!- visof [~visof@41.34.216.9] has quit [Changing host]
17:17 -!- visof [~visof@unaffiliated/visof] has joined #go-nuts
17:17 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Ping timeout: 250 seconds]
17:18 -!- imsplitbit [~imsplitbi@64.39.4.132] has joined #go-nuts
17:19 -!- PortatoreSanoDiI [~Marvin@dynamic-adsl-94-36-168-238.clienti.tiscali.it]
has joined #go-nuts
17:22 -!- adu [~ajr@softbank220043139062.bbtec.net] has quit [Quit: adu]
17:22 -!- Project-2501 [~Marvin@82.84.85.240] has quit [Ping timeout: 248 seconds]
17:23 -!- keithcascio [~keithcasc@nat/google/x-jrvxskbfqntknqwb] has joined
#go-nuts
17:23 -!- xyproto [~alexander@77.40.159.131] has joined #go-nuts
17:24 -!- ShadowIce
[~pyoro@HSI-KBW-109-193-120-162.hsi7.kabel-badenwuerttemberg.de] has joined
#go-nuts
17:24 -!- ShadowIce
[~pyoro@HSI-KBW-109-193-120-162.hsi7.kabel-badenwuerttemberg.de] has quit
[Changing host]
17:24 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts
17:24 -!- Natch [~natch@c-6dcde155.25-4-64736c10.cust.bredbandsbolaget.se] has
joined #go-nuts
17:25 -!- MizardX [MizardX@ip-98-8-72-178.dialup.ice.net] has quit [Changing host]
17:25 -!- MizardX [MizardX@unaffiliated/mizardx] has joined #go-nuts
17:25 < wrtp> skelterjohn: i only got the info from a post of russ's to
golang-dev
17:25 < wrtp> he's going to post a proposal for a redesign of reflect "in
the next few weeks"
17:26 < wrtp> steven, skelterjohn: FWIW, i prefer db.Find(&shop, "id", 1)
17:26 < wrtp> otherwise db.Find has to return an interface which you then
have to type cast
17:26 -!- Natch| [~natch@c-6dcde155.25-4-64736c10.cust.bredbandsbolaget.se] has
quit [Ping timeout: 255 seconds]
17:26 < Namegduf> Hmm.
17:27 < Namegduf> Doesn't look like it provides a way to handle multiple
results.
17:27 < Namegduf> "id" should reasonably not have one, but other searches
could.
17:27 < wrtp> Namegduf: it could provide multiple results if shop is of type
*[]Shop
17:27 < Namegduf> Perhaps, given you're willing to design the DB schema
around the needs of the program, you should have a db.Lookup(&shop, 1) thing
17:28 < wrtp> i mean *[]*Shop probably
17:28 < aiju> *[]* looks like a smiley
17:28 < Namegduf> Which uses your fixed id column.
17:28 < wrtp> it's an alient looking at *you*
17:28 < wrtp> s/alient/alien
17:29 < aiju> telling you that you should overthink your Go types ;P
17:29 < aiju> (i actually use *[]*foo sometimes and don't mind it too muhc)
17:29 < Namegduf> wrtp: It could, although that'd mean you'd have to do if
db.Find(&shops, "id", 1) > 0 { shop = shops[0] }
17:29 < steven> var shop []Shop; db.Find(&shop, "name", "joe's") // then
Find will retreive all the results and append(*shop, result)
17:29 < Namegduf> Rather than the simple db.Find(&shop, "id", 1)
17:30 < Namegduf> That'd work, with appropriate error handling.
17:30 < steven> if shop == slice { get all values; translate each of them to
shop objects; append each of them to shop } else { get single value ("limit 1");
set fields on shop }
17:30 < wrtp> steven: yes
17:30 < wrtp> steven: yes
17:31 < steven> easy peasy
17:31 < wrtp> exactly
17:31 < wrtp> you've got it sussed
17:31 < steven> looks like the whole API's been figured out except how to
get relationships
17:31 < Namegduf> You'd also not be able to use []Shop
17:31 < Namegduf> You'd have to use []Record
17:31 < steven> why Namegduf?
17:32 -!- adu [~ajr@softbank220043139062.bbtec.net] has joined #go-nuts
17:32 < Namegduf> Because you can't have your code do type assertions for
types it doesn't know exists.
17:32 -!- saschpe [~quassel@opensuse/member/saschpe] has joined #go-nuts
17:32 < wrtp> another possibility: f := func(shop *Shop)
{doSomething(shop)}; db.Find(f, "id", 1)
17:32 < steven> we would be using reflect package to know the type and all
the fields and their names and types of &shop
17:32 < steven> re Namegduf.
17:33 < wrtp> i.e.  if you pass a callback function with appropriate type,
it'll be called with each result in turn
17:33 < steven> wrtp: not sure i follow..
17:33 < Namegduf> Usable.  I'm not convinced this looks easier to use than
SQL, thoguh.
17:34 < Namegduf> It's pretty much the same syntax used by the sqlite
package
17:34 < steven> Namegduf: i thikn you will be convinced when you see it in
action.
17:34 < Namegduf> Except instead of writing a SELECT statement I write a
Find() function
17:34 < Namegduf> And for anything complex I need to learn a syntax equally
expressive as SQL
17:34 < Namegduf> But different.
17:34 < Namegduf> And I'm wondering how much gain I'm getting, exactly.
17:35 < steven> and instead of iterating through all the rows in the result,
you have a slice.  and instead of using a map for each row, you have a struct.
17:35 < Namegduf> That's trivial.
17:35 < wrtp> Namegduf: which sqlite package are you talking about?
17:35 < Namegduf> Except the struct part.
17:35 < Namegduf> Russ's one, I think?
17:35 -!- larva [~larvanitr@ec2-46-51-171-183.eu-west-1.compute.amazonaws.com] has
quit [Remote host closed the connection]
17:35 < wrtp> Namegduf: got a link?
17:36 < steven> im comparing it to
https://github.com/kuroneko/gosqlite3/blob/master/sqltest.go
17:36 < Namegduf> http://code.google.com/p/gosqlite/
17:37 < steven> its gonna be much cleaner.
17:38 -!- larva [~larvanitr@ec2-79-125-33-146.eu-west-1.compute.amazonaws.com] has
joined #go-nuts
17:38 < steven> oh, another idea, this one about error handling
17:38 < Namegduf> Not worth it.
17:38 < wrtp> Namegduf: that's much nicer than the kuroneko one
17:38 < wrtp> even though it's not documented and is old enough that it
doesn't compile any more...
17:38 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts
17:38 < steven> instead of having error handling after every fetch or
update, it might make sense to spawn a goroutine that handles errors, and just
write to an error channel if errors happen
17:38 < Namegduf> Adding a whole extra layer of abstraction to make it
"cleaner"...
17:38 < Namegduf> Why not just make *it* cleaner?
17:39 < Namegduf> steven: And return what to the code expecting a result?
17:39 < wrtp> Namegduf: i think that automatic mapping of structs to rows
could be quite nice
17:39 < steven> Namegduf: because its already clean as far as sqlite goes
17:39 < Namegduf> wrtp: But that's not what he's proposing.
17:39 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has quit [Ping
timeout: 246 seconds]
17:39 < steven> yah it is.
17:39 < wrtp> i thought it was
17:39 < Namegduf> What you're proposing won't work for arbitrary structs.
17:39 < steven> yes, it will.
17:39 < Namegduf> Because arbitrary structs do not have relationship
information.
17:39 < Namegduf> No, it won't.
17:39 < Namegduf> They don't have the methods you are referring to.
17:39 < steven> relationships will be tricky, i admit
17:39 < wrtp> they don't have to be arbitrary, any more than json encoding
encodes arbitrary structs
17:40 < Namegduf> JSON encoding does encode arbitrary structs.
17:40 < wrtp> Namegduf: no it doesn't
17:40 < steven> can a struct contain constants?
17:40 < Namegduf> steven: You cannot add methods, or assume methods are
present, on arbitrary structs.
17:40 < wrtp> Namegduf: it won't encode a channel or a function
17:40 < steven> Namegduf: im not planning to.
17:40 < Namegduf> steven: What happened to .Save()?
17:40 < steven> we discussed that the GoRM package would contain all the
methods for saving/fetching/updating/etc
17:40 < Namegduf> And all the relationship methods you were referring to?
17:40 < Namegduf> Okay.
17:40 < wrtp> steven: no a struct can't contain structs
17:41 < Namegduf> (They're called functions in that context)
17:41 < steven> im thinking maybe theres a way to embed relationship
information right into the definition of a struct
17:41 < wrtp> Namegduf: it would be gorm.Save(x) rather than x.Save()
17:41 < wrtp> steven: yeah
17:41 < Namegduf> wrtp: Okay.  Then it's changed since described earlier.
17:41 -!- Venom_X [~pjacobs@66.54.185.131] has joined #go-nuts
17:41 < wrtp> steven: remember you can have tags on struct fields
17:41 < Namegduf> Then what benefit are you getting?
17:41 < steven> ie type Person struct { name string, age int, relationships
= {"parents": "parents_table"} }
17:42 < wrtp> for instance to indicate key types
17:42 < steven> (excuse the obviously incorrect syntax for now)
17:42 < steven> wrtp: oh you can?
17:42 < steven> hmm
17:42 * steven looks up go spec
17:42 < Namegduf> This sounds like the sqlite module's interface, plus scan
mapping things to field names automatically
17:42 < wrtp> steven: does this have to work for arbitrary databases, or can
the database be designed around the needs of GoRM?
17:42 < steven> im thinking the latter
17:43 < wrtp> me too
17:43 < steven> ie, design it for new projects, not existing ones
17:43 < wrtp> yeah
17:43 < steven> that way we can move towards the ideal rather than
supporting legacy
17:43 < steven> (at least until 2.0 hehe)
17:43 -!- larva_ [~larvanitr@ec2-46-51-171-183.eu-west-1.compute.amazonaws.com]
has joined #go-nuts
17:43 < wrtp> Namegduf: maybe that's all it is, but it might be nice to do
some relations too
17:43 < Namegduf> Maybe.
17:44 < wrtp> steven: for a first cut, why not just do simple struct-to-row
conversion and vice versa
17:44 < Namegduf> Scan plus an insert function using a relationship mapping
thing?
17:44 < steven> good idea
17:44 < Namegduf> To convert pointers to other structs to keys to other rows
(potentially in other tables?)
17:44 < steven> hmm i never knew a bout struct tags before..  interesting
17:44 -!- tvw [~tv@212.79.9.150] has quit [Remote host closed the connection]
17:45 < Namegduf> This is actually interesting now, it sounds like it's
getting down to a fairly minimal idea that adds something instead of reinventing
SQL in a DB API so people "don't have to learn SQL", just your equally complex API
17:45 * Namegduf once had a guest lecture from the guy behind Django, for Python.
17:46 < steven> howd it go
17:46 < Namegduf> "Don't you hate SQL?" was basically the justification they
offered, although I think they might have been trying to play to the audience.
17:46 < steven> heh
17:46 -!- larva [~larvanitr@ec2-79-125-33-146.eu-west-1.compute.amazonaws.com] has
quit [Ping timeout: 255 seconds]
17:46 < aiju> well, SQL is a POS
17:46 < Namegduf> My thought was "No, I learned it in high school, if it's
hard you should probably have your compiler taken away."
17:46 < steven> haha.
17:47 < Namegduf> I don't remember anything else aside walking into the
second half with a box full of cans of energy drink, I was tired, it was dull, and
I was on IRC.
17:47 < Namegduf> I think it was mostly details which I figured I could just
read about on their website, and did.
17:48 < wrtp> i think the difficulty with SQL is knowing what operations
it's likely to translate to on the server side, so you can write efficient queries
17:48 < steven> db.FindRelated(&shop, &items, "partnum", "42") would return
all items belonging to shop who also have partnum=42 ..  ie, SELECT * FROM items
WHERE shop_id=<shop.id gets inserted here> AND partnum=42
17:48 -!- aho [~nya@fuld-4d00d6b0.pool.mediaWays.net] has quit [Quit:
EXEC_over.METHOD_SUBLIMATION]
17:49 < steven> db.FindRelated(&shop, &items, "", "") gets all of them
(sigh..  why cant we just have default args already?)
17:49 < wrtp> steven: i wonder if you could have some general notion of
structs-as-queries
17:49 < aiju> the difficulty with SQL is figuring out which of the jillions
of versions your server uses
17:49 < Namegduf> Because a couple of nil arguments are much easier to
reason with than variable arguments
17:49 < Namegduf> That line wasn't even bad.  :P
17:49 < steven> aiju: im thinking that for now we would only support sqlite3
and just try and keep it somewhat-generic so someone smarter can come in later and
add postgres support :)
17:49 < Namegduf> Short, pretty
17:50 < wrtp> so you could partially fill out a struct (e.g.  the Id field)
and have the Find function would fill out the rest.
17:50 < Namegduf> It was obvious that the conditions existed and were set to
empty
17:50 -!- aconran [~aconran-o@38.104.129.126] has joined #go-nuts
17:50 < aiju> SQL needs fucking Hollerith strings
17:50 < Namegduf> Explicitly saying "empty" is clearer than not specifying.
17:50 < steven> Namegduf: its not the line thats bad, its handling all the
boilerplate fetching code afterward
17:50 < Namegduf> Default parameters won't help there.
17:50 < wrtp> aiju: isn't that called TEXT?
17:51 < Namegduf> I really think, though, that this isn't going to end
anywhere useful.
17:51 < steven> wrtp: oh sweet, i dig that idea.  except, that would only
work for fetching one value, not multiple
17:51 < aiju> wrtp: huß
17:51 < aiju> ?
17:51 < Namegduf> It's nice and simple, but so's SELECT * FROM <table>
WHERE id=<x>
17:51 < steven> (cuz, which object of the slice would have the "fetching"
info?)
17:51 < Namegduf> SQL is only complex for complicated queries
17:51 < Namegduf> And complicated queries will be just as or more complex in
your wrapping API.
17:52 < steven> again, SQL isnt the problem..  its the boilerplate handling
the results that happens after you execute teh statement which is annoying
17:52 < steven> im just trying to add an abstraction layer which makes all
that boilerplate unnecessary
17:52 < steven> or hides it, i mean
17:52 < wrtp> yeah, and i think that Namegduf has some kind of a point here
17:52 < Namegduf> So instead of having your own weird syntax for specifying
the query
17:52 < Namegduf> Just have the query be SQL
17:52 < wrtp> yeah
17:52 < Namegduf> And the results be handled by your wrapper
17:52 < steven> but then theres not as much way of knowing how to unwrap the
results..  its not as obvious then.
17:53 < aiju> nobody uses most parts of SQL
17:53 < wrtp> steven: have you looked at that other sqlite package?
17:53 < steven> unless you either parse the SQL statement yourself as well,
or pass in data to clue it as to how to put the results into structs, etc
17:53 < steven> yeah, didnt have any examples *sadface*
17:53 < Namegduf> steven: I'm not saying let them specify full-formed
statements
17:53 < Namegduf> I'm just saying let them specify the WHERE clause
17:53 < steven> o
17:53 < wrtp> steven: yeah, but if you look at the source
17:54 -!- iant [~iant@216.239.45.130] has joined #go-nuts
17:54 -!- mode/#go-nuts [+v iant] by ChanServ
17:54 -!- femtooo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Read error:
Connection reset by peer]
17:54 < Namegduf> db.Find(&shop, "name = ?", name) isn't very complex
17:55 < Namegduf> And db.Find(&shop, "name = ? AND opendate = ?", name,
date) is much better than any API you could design otherwise
17:55 < exch> I used to work for a company which did everything in C# and
used a similar ORM for data access.  It was a major clusterf*ck of a library and
in order to do any complex queries on the objects, they had me develop an OQL
language which performed sql like filtering on the objects instead.
17:55 < exch> It was downright ludicrous
17:55 < Namegduf> Yeah, that's the kind of madness I'm talking about.
17:55 -!- visof [~visof@unaffiliated/visof] has quit [Remote host closed the
connection]
17:55 < skelterjohn> is amd64 the only supported 64bit arch for go?
17:55 < exch> the language worked, but compared to just using plain SQL
directly, the performance was abysmal
17:56 < steven> Namegduf: as long as the function knows what kind of struct
to map the values into, and whether its expecting a single result or an array,
then that seems like a good idea
17:56 < aiju> skelterjohn: yeah
17:56 < skelterjohn> thanks
17:56 < steven> but,
17:56 < aiju> Go only supports x86, amd64 and a bit of ARM
17:56 < steven> then what happens when you want to do custom join tables and
whatnot?
17:57 < skelterjohn> aiju: I'm fixing something for gb - and when building
cgo pkgs, i had -m64 on the command line, since it's on the command line when i
use make
17:57 < Namegduf> Well, one thing is that this way, you can always step
around the ORM and just use SQL directly.
17:57 < steven> oh, right, then you can drop back down into sqlite :)
17:57 < skelterjohn> but i wonder if it shouldn't be there for non amd64
17:57 < Namegduf> You can.
17:57 < Namegduf> You could also provide something more powerful if you can
think of an idea.
17:57 < aiju> -m64 means amd64 afaik
17:57 < steven> this seems real good so far.
17:57 < Namegduf> But the struct exists outside your package, the SQL exists
outside of it, you're just providing a useful simple mapper
17:57 < Namegduf> Yeah, this seems useful now.
17:57 < skelterjohn> at the moment, can one cross-target a cgo package?
17:58 < skelterjohn> that is, build it for amd64 while on a 386 machine?
17:58 < aiju> in theory yes
17:58 < aiju> but it's broken all the time D:
17:58 < aiju> you should support it nevertheless
17:59 < steven> if any of yalls want commit access, PM me your github names
and ill set it up after work
17:59 < skelterjohn> aiju: not really sure how - i've only got 64 bit
machines to test on
17:59 < ww> particularly for things like cross compiling to arm...
17:59 < aiju> wow
17:59 < aiju> i only have 32-bit machines
17:59 < Namegduf> steven: This sounds like the kind of thing that would be
worth just adding to an SQLite package.  Simple struct/slice of struct lookup and
filling out, simple struct field insert.  Ideally it'd be useful in a DB
independent thing
17:59 < Namegduf> But Go doesn't have an accepted one, yet.
18:00 < skelterjohn> aiju: you should help me test O:-)
18:00 < aiju> i use os.Open for accessing my databases
18:00 < aiju> platform-independent, simple and fast
18:00 < wrtp> Namegduf: yes
18:00 < steven> Namegduf: yeah im not sure about adding it to an existing
package, since the goal is hopefully to make it db-independent (postgres, mysql,
sqlite, etc)
18:01 < wrtp> steven: try starting with the
gosqlite.googlecode.com/hg/sqlite source
18:01 < ww> aiju got any good on disc hashes or trees you'd like to share?
18:01 < wrtp> and adding support for structs
18:01 < steven> wrtp: why do you recommend that one instead of the other
two?
18:01 < wrtp> steven: because it's very small, simple and quite elegant
18:01 < steven> re http://godashboard.appspot.com/project (search for
sqlite)
18:01 < steven> did you check those ones out to compare it with?
18:01 < wrtp> steven: and it was written by russ, so the code will be good
:-)
18:01 < steven> oh, sweet.
18:02 < adu> who is russ?
18:02 < aiju> russ cox
18:02 < skelterjohn> russ cox
18:02 < skelterjohn> rsc
18:02 < steven> was gonna ask
18:02 < steven> but figured its probably on the wikipedia page
18:02 < aiju> he broke Plan 9 and is now off to kill Go
18:02 < skelterjohn> lol
18:02 < nsf> :)
18:02 < nsf> it's true
18:03 < steven> oh ,http://golang.org/doc/go_faq.html
18:03 < wrtp> steven: yeah, looked at the others and i'd definitely start
with russ's
18:03 < Namegduf> steven: Could write it to expect a db connecction
interface that just happens to match the sqlite ones.
18:03 < Namegduf> *that sqlite one
18:04 < steven> Namegduf: maybe
18:04 < steven> yeah wrtp im starting with russ's for now.
18:04 < steven> btw,
18:04 < adu> http://swtch.com/~rsc/ ?
18:04 < ww> that sqlite one basically just exposes the c api
18:04 < Namegduf> That's an interesting thought, really.
18:04 < steven> are any variables ever const, in go?  i dont see a const
keyword, but maybe vars defined in the top level of the package are const?
18:04 < wrtp> steven: no
18:04 < Namegduf> Instead of having a DBI package, just get the DB packages
to have a standard interface.
18:04 < ww> it might be less convenient to make some other sql c api wrapper
look the same...
18:04 < ww> namedguf++
18:05 < ww> i used the sqlite as documenation for writing the kyoto bindings
18:05 < wrtp> steven: you'd need some way of getting the field names out of
a query result
18:06 < steven> i think i should learn how to use go's testing framework..
but man ive always hated tdd and bdd..  especially now that im hired at an Agile
company
18:06 < steven> wrtp: why?
18:06 < wrtp> steven: go's testing package is really simple
18:07 < nsf> I'm not sure about tdd
18:07 < ww> steven happy path obvious likely error and regression
18:07 < nsf> but tests are very useful
18:07 < nsf> if someone gives you the code, you need some proof that it
works
18:07 < ww> don't buy into the coverage obsessed people's spiel
18:07 < skelterjohn> "ww: steven happy path obvious likely error and
regression" whaaaa?
18:08 < steven> wrtp: if Find takes something in the form of "field1 = ? AND
field2 = ?" then it shouldnt matter about fetching those fields out of the
semi-query string, since it just gets converted into a full SQL statement and used
18:08 < steven> wrtp: and the results are mapped into the full struct.
18:08 < steven> so im not sure why you said that
18:08 < ww> skelterjoh - the tests you should bother writing, rather than
try to test every possibilitty up front
18:08 < wrtp> steven: i thought it take something like "select a, b from
sometable"
18:09 < wrtp> s/take/would take/
18:09 < steven> wrtp: nah, im not sure theres any benefit to limiting what
fields we're taking for any given struct/table
18:09 < steven> might as well just be select * from ...
18:09 < ww> start with the happy path, and add regression tests as you
encounter bugs, if it makes sense
18:09 < wrtp> well, you'd want that to work too...
18:09 < steven> especially since then you would have to relay to the user
which fields are valid and which arent
18:09 < wrtp> steven: i don't think so
18:10 < wrtp> other unmarshalling packages don't
18:10 < wrtp> e.g.  json, gob
18:10 < steven> i dont see any reason to not always do select * from
18:10 < steven> i think it should always do select * from
18:10 < adu> JSON++
18:10 < ww> i find the typing makes for fewer tests anyways because
compiling is a pretty good test of some things
18:10 < Namegduf> Doing select * from makes sense when filling out a struct
automatically
18:10 < wrtp> steven: what about joins?
18:10 < Namegduf> When the normal case by far is all the columns being
fields
18:10 < steven> wrtp: i figured we arent supporting joins, le the user drop
lower for that kind of thing
18:10 < Namegduf> JOIN is weird and should probably be done via a direct SQL
query
18:11 < steven> at least for 1.0
18:11 < Namegduf> Because it doesn't return a struct, so scanning into a
struct makes limited sense
18:11 < Namegduf> Er, because it doesn't return a specific table's rows.
18:11 < steven> ive seen django and rails do JOINs automatically, but thats
beyond my experience/understanding
18:11 < steven> so is it just me or is anyone else procrastinating at their
dayjob?  :)
18:11 < Namegduf> Django reimplements a lot of SQL in its API
18:11 < wrtp> ahem
18:11 < Namegduf> Rails is rails.
18:11 < wrtp> i've gotta go :-)
18:12 < steven> hehe
18:12 < skelterjohn> i'm supposed to write a proof
18:12 < steven> PM me your github names guys
18:12 < Namegduf> I need to sleep.
18:12 < steven> and ill get this show on the road tonight
18:12 < wrtp> steven: i use google code
18:12 < steven> ouch
18:12 < steven> jk ;)
18:12 * ww likes bitbucket
18:12 < wrtp> steven: and my email is rogpeppe@gmail.com
18:12 < wrtp> have fun
18:12 -!- wrtp [~rog@92.16.113.213] has quit [Quit: wrtp]
18:12 < steven> k
18:13 < Namegduf> One option for joins is to provide a specific function for
that, which generates a JOIN which does the Right Thing.
18:13 < Namegduf> But it can be added later.
18:14 < steven> yeah, for the simple cases
18:14 < steven> i dig it
18:14 < Namegduf> Have the WHERE clause still specified manually, have
another thing be a list of table names, have the thing unmarshalled into say which
table's columns it wants.
18:14 < skelterjohn> i think a gdbc interface would be nice to add, now
18:14 -!- rm445 [rm445@pip.srcf.societies.cam.ac.uk] has joined #go-nuts
18:14 < Namegduf> Then you could do something simple like look up an item
based on rows in another table pointing to it.
18:15 < ww> magic joins are dangerous - i'v seen people write high level
code that ends up being this massive sequence of outer joins because the orm hid
it from them...
18:15 -!- rm445 [rm445@pip.srcf.societies.cam.ac.uk] has quit [Client Quit]
18:15 < ww> caveat utilisor
18:15 < Namegduf> Trying to be as powerful as SQL involves matching its
capabilities, though, and, well, someone in here already related the resulting
construction of an OQL.  :P
18:16 < Namegduf> But for the simple thing of using it as a queriable
persistence layer...
18:16 -!- rm445 [rm445@pip.srcf.societies.cam.ac.uk] has joined #go-nuts
18:16 < adu> wow Russ Cox is cool
18:16 < skelterjohn> rofl
18:16 < exch> making a functional OQL is fun, but not very useful in the end
18:16 < steven> adu: careful not to step into idolatry
18:16 < steven> people are just people ;)
18:16 < adu> wtf, I never said "idol" is said "cool"
18:17 < steven> just sayin
18:17 < skelterjohn> potato, potato
18:17 < Namegduf> That really doesn't work online.
18:17 < steven> haha
18:17 < steven> :D
18:17 < adu> lol
18:17 < skelterjohn> no - i pronounced them differenty
18:17 < skelterjohn> you can't see it?
18:17 < Namegduf> Oh, carry on then.
18:17 < steven> i saw it
18:18 < Namegduf> I love the amount of English which is based on references
and metaphors pulling from shared culture.
18:18 < Namegduf> It's like a language designd to be deliberately impossible
to understand from outside.
18:19 < adu> Namegduf: I'm in Japan right now, an one of my English lessons
was about the phrase "What is it like?"
18:19 < Namegduf> Haha.
18:19 < ww> who is raining?
18:19 < steven> so what are the common operations?  (1) get single row from
table, (2) get multiple rows from table, (3) get row/rows from table based on
column(s) in another table, (4) save changes to these row(s) back into the table,
delete row(s), (5) delete row(s)
18:19 < steven> am i missing anything?
18:19 < Namegduf> English is like JavaScript.
18:19 < adu> Namegduf: somehow, explaining that like=similar didn't help
18:19 < nsf> no vim syntax script for lemon parser generator, huh
18:19 < skelterjohn> steven: are you thinking about a general database api?
18:19 < Namegduf> If you can't parse it one way you try parsing it another.
And another.
18:20 < nsf> gimme my syntax highlighting (
18:20 < Namegduf> adu: Yeah, it wouldn't.
18:20 < steven> skelterjohn: missed our earlier conversations?
18:20 < skelterjohn> i was out to lunch for a while
18:20 < steven> k
18:20 < skelterjohn> you might have changed topic
18:20 < steven> so yeah, basically.
18:20 < Namegduf> skelterjohn: He's looking at implementing an insert
struct/scan into struct thing with the goal of something ORM like
18:21 < Namegduf> With relationships in some way.
18:21 < skelterjohn> i know about the ORM bit
18:21 < skelterjohn> but it looked like you were doing an intermediate step
of a general db layer
18:23 < skelterjohn> which i think is a good idea :)
18:23 < skelterjohn> a go version of jdbc
18:24 < Namegduf> A general DB layer would be nice, even if SQL isn't
portable a single API to learn would be nice.
18:24 < Namegduf> A fairly significant undertaking, though.
18:25 < Namegduf> Ideally, though, it woudln't be so much a Go version of a
huge frameworky thing as an type Conn interface {}, type Stmt interface{}, and so
on, plus DB packages implementing the interface.
18:25 < skelterjohn> right
18:25 < Namegduf> We have interfaces, they're simple and pretty
18:25 < steven> what i have in my head so far should be simple enough to
implement in one or two spare evenings
18:26 < skelterjohn> we need a gdbc pkg, and a gdbc/mysql, gdbc/sqlite, etc
18:27 < Namegduf> We could technically just have the gdbc package, and just
have the regular mysql and sqlite packages meet the interfaces, which would be
nicest but involve coordination.
18:27 < adu> that would be sweet
18:28 < Namegduf> But yeah, it would be.
18:28 < adu> so how would you switch?
18:28 < skelterjohn> well, for a language that has web servers as one of its
major targets, it's not so weird to put these db APIs in the core
18:28 < adu> import pg instead of import mysql?
18:29 < Namegduf> That's what I'd expect.
18:29 < skelterjohn> var db gbdc.Database = mysql.GetDatabase(information)
18:29 < Namegduf> Yep.
18:29 < skelterjohn> or = pg.GetDatabase(information)
18:29 < Namegduf> Of course
18:29 -!- rom1504 [~rom1504@AMontpellier-159-1-112-67.w90-0.abo.wanadoo.fr] has
joined #go-nuts
18:29 < Namegduf> Then you get to check all your SQL still works.
18:29 < Namegduf> But you can still use the same API.
18:30 < Namegduf> They wouldn't essentially have to be in core, you'd just
need the third party libs to match it.
18:31 < djbrown> is it possible to do something like pythons
http://pastebin.com/XraRRfhL in go?
18:31 < Namegduf> What does getattr do?
18:31 < skelterjohn> i figure if we put 80 cyphers in the core, a common db
interface could go there too
18:31 < Namegduf> Yeah, the common interface being in core would make good
sense.
18:31 < Namegduf> It's small, it's simple...
18:32 < Namegduf> Hopefully...
18:32 < ww> hmmm...  could you pass an interface for the shape of a result
set and have that auto-populated per row?
18:32 < ww> instead of counting through a slice?
18:32 < Guest27269> Is it possible to use a vector of ints as the keytype
for a map?  I want to rule out duplicates off many vectors
18:32 < Namegduf> No.
18:32 < skelterjohn> ww good idea
18:32 < steven> one advantage ruby has over go, for webapps, is that you can
open an interactive ruby console in production environment, and run ruby commands
right there.
18:33 < steven> (im not saying its a good thing, im just saying it can be
useful and is possible with ruby, and not possible with go)
18:33 < Guest27269> so what would be a go'y way to do that?
18:33 < skelterjohn> steven: you did call it an advantage :)
18:33 < djbrown> Namegduf: in that instance it would be the same as doing
obj.method
18:33 < steven> heh fine
18:33 < skelterjohn> Guest27269: you can use something like
gohash.googlecode.com to allow arbitrary keys
18:33 < Namegduf> steven: Yeah, you can't do that in a compiled language.
18:33 -!- MizardX [MizardX@unaffiliated/mizardx] has quit [Ping timeout: 276
seconds]
18:33 < skelterjohn> Guest27269: you'd need to write the Hashcode() and
LessThan()/Equals() functions, though
18:34 -!- MizardX [MizardX@46.230.224.48] has joined #go-nuts
18:34 -!- MizardX [MizardX@46.230.224.48] has quit [Changing host]
18:34 -!- MizardX [MizardX@unaffiliated/mizardx] has joined #go-nuts
18:34 < steven> they seem to be making progress on an evaluator though,
Namegduf
18:34 < Guest27269> thanks a lot skelterjohn
18:34 < Namegduf> steven: Maybe, but it's still probably not worth it.  You
like fast and low RAM usage, right?
18:34 < Namegduf> steven: You're probably best just learning to work gdb
18:35 < Namegduf> It's a useful tool to know how to use.
18:35 < djbrown> Namegduf: basically i want to "search" for a method and see
if it exists and if it does call it
18:35 < skelterjohn> Guest27269: gohash's hashutil pkg shows how to do that
with a []float64, easy to adapt to a []int
18:35 < steven> gdb works with go?
18:35 < Namegduf> djbrown: It doesn't make sense in a statically typed
language.
18:35 < aiju> steven: more or less
18:35 < skelterjohn> steven: in theory - i'm scared to try
18:35 < steven> then yeah thats probably what im looking for :)
18:35 < Namegduf> steven: It's whiny and imperfect but functional.
18:35 < Namegduf> I have used it.
18:36 < aiju> you can certainly debug programs with it
18:36 -!- Guest27269 [~quassel@p4FF1C6A8.dip0.t-ipconnect.de] has quit [Remote
host closed the connection]
18:36 < Namegduf> djbrown: In a statically typed language you know what type
obj is, and it either has the method or doesn't, and you can call it.
18:36 < ww> so far i haven't needed to resort to gdb...  logging and
thinking a bit has been enough...
18:36 < steven> what i mean is, sometimes i need to go into productoin for
the client's website and load rails's console, and trigger a function to do
something.
18:36 < steven> can gdb do that?
18:37 < Namegduf> It's a Bad Idea
18:37 < aiju> using gdb is a Bad Idea usually
18:37 < steven> i have to do that in rails at least once a week
18:37 < Namegduf> In theory yes but not something to do for production
stuff.
18:37 < steven> (cuz our code sucks)
18:37 < steven> i mean, its good, but at some point all code sucks
18:37 < Namegduf> djbrown: If it's an interface, then I think you could type
assert that it matches an interface that includes that method.
18:37 -!- m4dh4tt3r [~Adium@c-69-181-223-245.hsd1.ca.comcast.net] has joined
#go-nuts
18:38 < Namegduf> And if that gets a true value from ok, call that method on
the resulting value.
18:38 < Namegduf> That's type unsafe and not a good way to write Go, though.
18:38 < ww> steven write a script or command line tool why not?
18:38 < steven> ww: no it has to be linked to the binary running in
production
18:39 < steven> to trigger code *inside* the running production code
18:39 < ww> in that case expose it as an rpc
18:39 < steven> although come to think of it, they dont need to share the
same process space.
18:39 < Namegduf> steven: The short version is no, you can't, unfortunately.
I suggest figuring out why you need to and solving it some other way.
18:39 < steven> after all, rails's console is really running another
instance, it just has the same environment setup.
18:39 < Namegduf> If there's a limited range of things you need to do, an
RPC or admin thing will work.
18:40 < aiju> rails has a console?
18:40 < steven> yes
18:40 < aiju> i want to link it up to a front panel for debugging
18:40 < Namegduf> Rails horrifies me.  :(
18:40 < steven> ditto
18:40 < steven> and its my dayjob
18:40 < Namegduf> It's like they took Java's RAM usage as a challenge
18:40 < Namegduf> And won
18:40 < uriel> exch: do you know what happened to
http://github.com/jteeuwen/go-pkg-pcre ?
18:40 < aiju> hahahahahaha
18:40 * steven is still a Mac/Cocoa programmer at heart
18:41 < aiju> steven: NSMeinFührer!
18:41 < Namegduf> Ah.
18:41 < steven> ha
18:41 * Namegduf is not a big Mac fan...  won't try to support it in FOSS stuff
because they want him to buy a £1000 computer to test it
18:41 < steven> Cocoa is so much easier than rails
18:42 < Namegduf> "Patches welcome", heh.
18:42 < skelterjohn> steven: they're not really....the same...
18:42 < steven> i know
18:42 < skelterjohn> one is a web platform
18:42 < skelterjohn> one is a GUI library
18:42 < Namegduf> 20.minutes.ago broke my brain.
18:42 < steven> objc+cocoa is still easier for me than rails is.
18:42 < exch> uriel: it sucked, so it had to go.  Someone else took ovver
the effort of maintaining it: http://git.enyo.de/fw/debian/golang-pkg-pcre.git/
not sure what it's state is though.  It belongs to Florian Weimer:
18:42 < aiju> [oh really?]
18:42 < Namegduf> I don't like OO, but I can understand an object model and
work with it
18:42 < steven> especially because rails changes every aspect of its api
MONTHLY it seems
18:42 < steven> we're still using rails 2.0.2 #sigh
18:42 < ww> namedguf woukd be inclined to support darwin but not osx as such
except by accident
18:43 < Namegduf> Ruby and Rails doesn't have an object model, it has a
bunch of objects named and arranged so as to form broken English
18:43 < aiju> why would someone run darwin without OS X?
18:43 < skelterjohn> can you find darwin anywhere other than os x?
18:43 < Namegduf> 10.upTo(20)
18:43 < aiju> skelterjohn: you can download it
18:43 < aiju> after all hurr durr it's open source!
18:43 < Namegduf> It's terrifying.
18:43 < aiju> 5.nonzero?
18:43 < aiju> .nonzero?  is my favourite example
18:43 < steven> you know what i was thining the other day, before i started
playing with Go again?  i was thinking "man, if only i could provide the values of
function pointers inside C structs at compile time, they would be just like
objects!"
18:44 < Namegduf> You can.
18:44 < steven> then a month later i started playing with Go, and it hit me,
"whoa!  they must have thought the same thing1"
18:44 < Namegduf> Haha.
18:44 < steven> re methods.
18:44 < jumzi> aiju: WE NEED MORE PROPRIETARY HURR DURR
18:44 < aiju> but who cares about objects?
18:44 < ww> because you don't have to buy a gbp1000 computer to run it, and
if it runs on darwin itt is likely to run on osx
18:44 < Namegduf> The result is that I can't work with Ruby at all.
18:44 < steven> im a little scared by the way Go does "inheritance" in
interfaces..  but honestly i havent come across a problem with it yet
18:44 < aiju> ww: i don't think darwin includes all the funny /Document and
Settings/ path names
18:45 < Namegduf> My head hurts trying to mentally parse the object model
18:45 < skelterjohn> aiju: i do find the layout a bit confusing, at time
18:45 < nsf> Go doesn't have inheritance
18:45 < skelterjohn> s
18:45 < nsf> it's more like composition
18:45 < Namegduf> It's OO but invalid OO somehow.
18:45 < ww> aiju: that's why the reverse isn't true
18:45 < nsf> no
18:45 < ww> sol for gui things of course
18:45 < Namegduf> Go doesn't have inheritance, yeah.
18:45 < aiju> ww: those things break my software usually
18:45 < nsf> in fact it _is_ composition
18:45 < uriel> piranha: thanks for the head up on the go-pcre broken link
btw
18:45 < skelterjohn> inheritance with interfaces doesn't mean much in any
language
18:45 < steven> right.
18:45 < aiju> ww: because the lib is in /Libraries/My
Ass/4.0/lib/bin/lib/myasslib/foo.a
18:45 < steven> so wait,
18:45 < piranha> uriel: np, would be nice to find a copy of this rope
anyway...
18:46 < skelterjohn> it's just the union of two interfaces
18:46 < Namegduf> Inheritance is not useful as a concept.
18:46 < steven> interfaces with compositions of other interfaces, just means
that the objects that conform to it simply have to implement more methods, and it
doesnt mean anythign else..  right?
18:46 < aiju> "who the fuck needs inheritance?" -- OO guy i know
18:46 < Namegduf> Yes.
18:46 < ww> yeah, that path convention is a pita
18:46 < steven> man Go is awesome.
18:46 < nsf> inheritance is a weird way to modify a vtable at compile time
18:46 < uriel> exch: thanks for the xplanation and pointer to replacement
18:46 < nsf> :)
18:46 < steven> i like select ahd channels and goroutines a lot
18:46 < Namegduf> In a language with inheritance, the "interfaces" available
for an object are its supertypes.
18:46 < steven> i want more reasons to abuse them :)
18:47 < steven> ie, writing a webserver or something.
18:47 < aiju> class Java implements Dragons {
18:47 < Namegduf> In Go, the interfaces available are all subsets of its
methods.
18:47 < aiju> steven: write a Go compiler in Go
18:47 < Namegduf> No need to model ahead of time, no need to futureproof, no
need for utter insanity
18:47 < steven> im not smart enough aiju
18:48 < nsf> steven: it isn't that hard
18:48 < nsf> with LLVM
18:48 < Namegduf> LLVM: Written in Go.
18:48 < nsf> or well, you can generate C or something
18:48 < aiju> how do you port LLVM to Go?
18:48 < Namegduf> Generating C: In Go.
18:48 < nsf> aiju: I wrote bindings
18:48 < steven> im not smart enough
18:48 < steven> sorry
18:48 < aiju> nsf: uh what
18:48 < ww> it would be interesting tool to have that given a type would
tell you all the interfaces it satisfies....
18:48 < aiju> does LLVM have a C interface i missed?
18:48 < nsf> https://github.com/nsf/gollvm
18:48 < steven> plus, how can goroutines be useful in a compiler?
18:49 < nsf> yes it has
18:49 < nsf> aiju: haskell uses it for example
18:49 < steven> it seems like a very linear thing, tbh
18:49 < nsf> and python
18:49 < Namegduf> ww: "All subsets of its methods"
18:49 < aiju> steven: goroutines turn out to be useful all over the place
18:49 < aiju> even if you think it is "linear"
18:49 < steven> i think of them as only useful for parallel processing
18:49 < ww> ...  as a documentation adjunct...
18:49 < aiju> no
18:49 < steven> what else are they useful for?
18:49 < aiju> steven: it's something entirely different
18:49 < Namegduf> ww: It might be interesting to know which subsets have
names somewhere, but it isn't particularly informative.
18:49 < Namegduf> I mean, there's not much you can do with the information.
18:49 < aiju> steven: http://aiju.phicode.de/misc/concurrency
18:50 < Namegduf> If you've a subset you want to use, you can.  If you want
to pass it to something you have a specific interface you want to check if it
meets.
18:50 < ww> namedguf it answer's the programmer's question, what can i do
with this instance?
18:50 < Namegduf> ww: How?
18:50 < aiju> steven: in a concurrent program, it's not rare that only one
goroutine is active at one time
18:50 < Namegduf> ww: You can do anything you can do through its methods.
18:51 < Namegduf> That's always true.
18:51 < ww> because you can then follow that to functions that can be passed
things of its type
18:51 -!- petrux [~petrux@host16-224-static.53-82-b.business.telecomitalia.it] has
quit [Quit: leaving]
18:51 < Namegduf> But why do you want to know all functions anywhere that
can be passed things of its type?
18:51 < steven> Namegduf: do you know anything about objc?
18:51 < ww> or rather things that accept interfaces satisfied by thid thing
18:51 < aiju> producing a call graph from Go code would be cool
18:51 < Namegduf> It's not a route towards implementing a given task.
18:52 < steven> Namegduf: im wondering if go's interfaces are exactly the
same concept as objc's protocols
18:52 < aiju> isn't objc one of the "message pass" languages?
18:52 < aiju> "function call is such a boring term, let's call it a message
pass!"
18:52 < Namegduf> steven: I kinda dislike languages which implement a model
for writing a program other than the way they actually work, then compile that
model into an actual implementation through unclear methods
18:52 < ww> namedguf i think it could be helpful to readers of docs
18:52 < steven> in objc, a protocol says "this object implements at least
these methods"
18:52 < Namegduf> ww: I think it might be interesting but I've not seen a
valid use case for it
18:52 < ww> maybe not all of them, but some of them - particularly those
learning the language
18:52 < steven> thats all it does.
18:53 < Namegduf> ww: Lots of "I want to know X" but not much "I am doing X,
and thus want to know X"
18:53 < aiju> it's kinda like Source, ???, PROFIT
18:53 < ww> first encounters of the language, i have X, what can i do with
it?
18:54 < Namegduf> Whatever the methods let you do.
18:54 < Namegduf> As I said, that's not a valid question.
18:54 < ww> and use that as a patg to explore the docs
18:54 < aiju> ww: are you talking about static analysis?
18:54 < ww> namedguf not true, i can also pass it to functions.  which
functions?  what do they do?  etc
18:54 < Namegduf> ww: You're repeating yourself, so I will do the same:
18:55 < Namegduf> ww: Lots of "I want to know X" but not much "I am doing X,
and thus want to know X"
18:55 < Namegduf> For it to be a use case it has to have a use
18:55 < Namegduf> Not just a story
18:55 < ww> what is the use case of learning?
18:55 < ww> you're talking like a professional, i'm thinking of students
18:56 < skelterjohn> <- professional student
18:56 < Namegduf> What is the use case for them to learn those specific
things?
18:56 < ww> :p
18:56 < skelterjohn> worst of both worlds
18:56 * steven gets back to work
18:56 < ww> namedguf when i was in school i didn't have a use case
18:56 < Namegduf> The use case "of learning" can be satisified in plenty of
better ways
18:57 < aiju> nuclear weapons are the only good way to end this discussion
18:57 < ww> in fact i don't like degree-mill-use-cases
18:57 < Namegduf> Hitler had questionable learning methods.
18:57 < Namegduf> aiju: Did I do that correctly?
18:57 < skelterjohn> that'll do
18:57 < aiju> i'd love to see a book about concurrent programming
18:57 * ww acknowledges old usenet conventon
18:57 < Namegduf> XD
18:58 < aiju> there is the classical CSP but i find it hard to read and too
theoretical
18:58 < aiju> i should probably just read 8½ source
18:58 < skelterjohn> what's that?
18:58 < aiju> 8½ or CSP
18:58 < aiju> +?
18:58 < aiju> the former is a concurrent window manager by Pike
18:58 < aiju> the latter is a book by Hoare
18:59 < skelterjohn> rob should port it to og
18:59 < skelterjohn> go
18:59 < evildho> er, why 8½
18:59 < skelterjohn> so we can have a native window manager
18:59 < aiju> evildho: his eigth and a halfth WM
18:59 < evildho> aiju: No, why use that as opposed to rio
18:59 < evildho> 8½ is old as shit
18:59 < aiju> i expect it to be simpler ;P
18:59 < evildho> rio is not complicated.
18:59 < aiju> probably should look at both
19:00 < evildho> it also has the benefit that it is in plan9port
19:00 < aiju> there is a paper about the 8½ design i think
19:00 < aiju> dunno about rio
19:00 < evildho> though with 9vx, you should be able to use / develop it
easily
19:00 < evildho> 8½ is the precursor to rio
19:00 < aiju> i have two native Plan 9 machines ;)
19:01 < evildho> so, rio superceded 8½; you should really look at that.
much of the architecture as described in the paper still applies.
19:03 -!- boscop_ [~boscop@f055255209.adsl.alicedsl.de] has joined #go-nuts
19:03 -!- boscop [~boscop@g227132192.adsl.alicedsl.de] has quit [Ping timeout: 246
seconds]
19:11 -!- adu [~ajr@softbank220043139062.bbtec.net] has quit [Quit: adu]
19:12 -!- jnwhiteh_ [~jnwhiteh@li37-84.members.linode.com] has quit [Read error:
Connection reset by peer]
19:19 -!- jnwhiteh [~jnwhiteh@WoWUIDev/WoWI/Featured/Dongle/cladhaire] has joined
#go-nuts
19:22 -!- tensorpudding [~user@99.56.160.152] has joined #go-nuts
19:23 -!- Fish- [~Fish@9fans.fr] has joined #go-nuts
19:44 < exch> yay.  my factor scripting thing in Go is actually starting to
work
19:46 -!- chimes [~chimes@24.104.130.118] has joined #go-nuts
19:49 < rl> has anyone used https://github.com/nsf/gocode ?
19:49 < nsf> um..
19:49 < rl> oh, hi
19:49 < skelterjohn> i think nsf has tried it out
19:49 < nsf> I think a lot of people use it
19:49 < nsf> github page has 62 followers
19:49 < skelterjohn> all the vim users out there
19:49 < exch> I have it hookd up to Gedit
19:49 < rl> nsf: I wasn't implying noone had used it, I was wondering if
someone was around who had ;)
19:50 < nsf> well, I use it
19:50 < nsf> when I write Go
19:50 < rl> I want to try it out myself in fact, but I ran into a problem
during make install, and I was wondering if I was doing something stupid
19:50 < nsf> sure, don't ask to ask just ask
19:52 < rl> hm, "how do I check if I my install of Go is up to date?" might
be a better question to ask
19:52 < nsf> go to dir with Go sources
19:52 < rl> turns out make install is failing because "os.StartProcess" is
undefined
19:52 < nsf> and type hg identify
19:53 < nsf> yes, it looks like an out-dated version
19:53 < rl> ok, i'll update it and try again, thanks
19:53 < nsf> os.ForkExec was renamed to os.StartProcess 1 release ago
19:53 < skelterjohn> just do "hg pull -u" in all relevant areas
19:53 < rl> (also, thanks for writing it, even though I haven't tried yet --
it looks awesome)
19:53 < nsf> ;)
19:54 < nsf> I'd suggest hg pull -u release
19:54 < nsf> oh, wait
19:54 < nsf> it's -b release
19:54 < nsf> or no
19:54 < nsf> I don't know :)
19:55 < nsf> I do: hg pull && hg update -r release
19:55 < rl> hg update release
19:55 < rl> yeah, I RTFMed
19:56 -!- espeed [~espeed@63.246.231.57] has quit [Ping timeout: 246 seconds]
19:58 -!- espeed [~espeed@63.246.231.57] has joined #go-nuts
19:59 < rl> man, compiling Go is hard work
20:00 < nsf> is it?
20:00 < nsf> cd src && ./all.bash
20:00 < rl> not for me, luckily
20:00 < rl> yea, my poor computer is taking its sweet time
20:01 < nsf> all.bash also runs tests
20:01 < nsf> which take most of the time
20:01 < nsf> because linker is slow
20:02 < nsf> and compiling lib tests takes more time than compiling lib
itself
20:02 < nsf> :)
20:03 < rl> got it working, awesome!
20:03 < nsf> go or gocode?  :)
20:03 < rl> gocode :)
20:03 < nsf> nice
20:04 < rl> also, I thought part of the goal of go was that compiling and
linking would be faster
20:04 < nsf> compiling is fast
20:04 < zozoR> but compiling the compiler is slow
20:04 < zozoR> :D
20:04 < nsf> and linking is not a bottleneck
20:05 < nsf> but hey, compiling is fast by design not by careful speed-wise
tuning
20:05 < nsf> there is room for improvements
20:05 < zozoR> which is epic
20:05 < zozoR> in a year, go will rape everything
20:05 < nsf> like using gold linker
20:05 < Namegduf> The Go compilers and runtime are in C
20:05 < Namegduf> And that is what all.bash is building
20:06 < nsf> zozoR: I don't think so :)
20:06 < Namegduf> As well as the stdlib and stuff in Go, but the C parts are
not Go-fast.
20:06 < nsf> but I hope Go will rape Java and .NET
20:06 < nsf> :D
20:07 < rl> if you're talking about only compile time it should certainly
beat C++ too
20:07 < skelterjohn> rl: most of the time in all.bash is running tests
20:07 < Namegduf> It beats C++ already by far.
20:07 < skelterjohn> you can build src/pkg very quickly
20:07 < Namegduf> As well as C.
20:07 < aiju> Namegduf: not really
20:07 < aiju> 10 KLOC 8c: 0.3s
20:07 < aiju> 10 KLOC 8g: 1s
20:07 < aiju> 10 KLOC g++: 60s (!)
20:07 < nsf> but Alexandrescu said that their D compiler is 4x faster than
Go
20:08 < rl> skelterjohn: this might sound sad but judging from the output
most of the time in all.bash was spent in the compiling/linking stage for me
20:08 < rl> Maybe I just have a very slow disk
20:08 < Namegduf> nsf: Which D compiler?
20:08 < skelterjohn> rl try "make clean all" in src/pkg
20:08 < nsf> Namegduf: I don't know
20:08 < Namegduf> The one missing half the features or the one which isn't
finished yet?
20:08 < nsf> Namegduf: :D
20:09 < aiju> my cat >/dev/null compiler is also faster than 8g
20:09 < rl> skelterjohn: 28.211s
20:09 < skelterjohn> 38s for me
20:09 * Namegduf doesn't really care, anyway
20:09 < skelterjohn> that's pretty good for the whole core
20:09 < rl> ooh, yay for my computer
20:09 < skelterjohn> <- laptop
20:10 < rl> ok, i laptops have slower hdds usually
20:10 < Namegduf> Go is far, far faster than C/C++, fast enough to build and
finish in a manner that causes no delay what so ever, even on significantly sized
stuff.
20:10 < xulfer> Me either.  Though I like the compilation time speedup it's
probably one of the features I'd say I care least about.
20:10 < Namegduf> I don't care about speed when it's already that fast.
20:10 < aiju> xulfer: have you ever worked with the Xilinx FPGA tools?  :D
20:10 < aiju> several minutes for 100 fucking lines
20:11 < aiju> then you *do* care about it
20:11 < nsf> I think Go compiler can be faster by a magnitude of 4
20:11 < rl> Namegduf: I wonder if most of the time spent on building go
might be just overhead from building many small packages rather than one big one
20:11 < nsf> at least
20:11 < rl> xulfer: you should try building really big binaries
20:11 < xulfer> aiju: The current project I'm on takes about 30 minutes on
an eight way xeon.
20:11 < rl> xulfer: then you'll appreciate it ;)
20:11 < xulfer> And, I don't care.
20:11 < rl> You don't care that it takes 30 minutes to build?
20:11 < skelterjohn> rl: 12s to make (cleaned already) on my lab's computer
:)
20:11 < xulfer> No, I care how it works.
20:11 -!- Project-2501 [~Marvin@82.84.77.44] has joined #go-nuts
20:12 < aiju> i don't mind long compile times if the source is supplied as
punch cards
20:12 < skelterjohn> heh
20:12 < Namegduf> You obviously do care in that if it took a week to build
that would probably be a problem, and if not then, a month would be
20:12 < rl> skelterjohn: damn, beat me hands down
20:12 < Namegduf> It just has a low rating as importance goes
20:12 < skelterjohn> my lab's computer is a stud - i built it
20:12 < Namegduf> But that's me being pedantic.
20:12 < xulfer> That would mean more paid free time for me.
20:12 -!- mattn_jp [~mattn@s60.BMT-e1.vectant.ne.jp] has quit [Quit: Ex-Chat]
20:12 < Namegduf> Heh.
20:12 < rl> when you start having to use distcc to compile your code
20:12 < Namegduf> Haha.
20:12 < skelterjohn> though it is maybe 3 years old now
20:13 < rl> and it still takes forever
20:13 < rl> it's a sign you could benefit from speeding up compile time
20:13 < aiju> compiling C is a bit more "modular" than compiling Go
20:13 < aiju> i don't have to rebuild modules
20:13 < exch> Factor has /very/ lenghty compile times because of the many
optimization passes, so developing Factor needs to be done in a special IDE which
has a listener/evaluator.  Only when you your program is done and ready for
deployment, do you actually compile it
20:13 < aiju> exch: oh wow
20:14 -!- PortatoreSanoDiI [~Marvin@dynamic-adsl-94-36-168-238.clienti.tiscali.it]
has quit [Ping timeout: 250 seconds]
20:14 < exch> On the upside, the IDE has very well integrated debug and help
mechanisms which definitely make writing concatenative code easier
20:14 < aiju> Forth got rid of compiles just to have hipster forth
reintroduce them?
20:15 < exch> the compilation is handy if you want to compile your code to
native binaries
20:15 < exch> without having to deploy some kind of runtime along with it
20:15 < exch> but yes, it is a bit of a pain to be so dependant on the IDE
just to develop factor stuff
20:16 < exch> shame, cos I love the language
20:16 < steven> Namegduf: thought you were going to sleep :P
20:16 < aiju> "IDE features are languages smells"
20:16 < Namegduf> Apparantly not.
20:16 < Namegduf> aiju: s/IDE //, am I right?
20:16 < aiju> hahahaha
20:17 < aiju> if .nonzero?  is considered a feature, then yes
20:18 < Namegduf> It is by the Ruby people on the mailing list.
20:18 < Namegduf> I fear them.
20:19 < steven> there was a time when i absolutely loved ruby
20:19 < Namegduf> Then you stopped taking drugs.
20:20 < Namegduf> :P
20:20 < steven> first i loved c++.  then i learned objc and loved it and
hated c++.  then i learned python and loved it and hated objc.  then i learned
ruby and loved it and hated python and liked objc once more.  then i learned lisp
and loved it and hated everything else.  then i got more familiar with C and loved
it, and had a deeper appreciation for objc.  then i learned Go and really really
love it.
20:20 < Namegduf> Wow, a Lisp phase.
20:20 < steven> (im omitting the less interesting things like lua and
javascript heh)
20:20 < nsf> you need to wait a bit
20:21 < nsf> and then start all over again
20:21 < Namegduf> I once wrote some Lisp
20:21 < nsf> hate Go, love C++
20:21 < Namegduf> I didn't enjoy it
20:21 < steven> ill probably find Go to be "meh" soon if this pattern is
telling at all
20:21 < steven> which might be the case.  but i kinda hope not :)
20:21 < aiju> the only good thing about LISP is (defmacro)
20:21 < aiju> and that one probably leads to unreadable code
20:21 < Namegduf> The best thing about Lisp is that nothing is written in it
20:21 < aiju> hahahaha
20:21 < aiju> EMACS
20:22 < cbeck> Emacs loves you <3
20:22 < nsf> The best thing about Lisp is that nothing is written in it and
there is vim
20:22 * Namegduf prefers functional languages which don't have lots of shared
state everywhere.
20:22 < aiju> let over lambda is cute
20:22 < exch> (what (I (dont (like (about (LISP (and (the (likes (is
obious))))))))))
20:22 < steven> when i learned Lisp, i did some evil OOP stuff in it:
http://degutis.org/entries/2010/12/6/oop-in-lisp-part-3
20:22 < aiju> but terribly imptacritcal
20:22 < Namegduf> Haskell would be fun but I can't read it at all.
20:23 < aiju> Haskell is fun until you reach 100 lines
20:23 < steven> ie, creating an OOP runtime simply using macros and a little
bit of cleverness.
20:23 < Namegduf> I read the beginner's guide, but it was kinda hard to work
out how to actually write a program using it.
20:23 < aiju> because then, lazy evaluation will kill your family
20:23 < aiju> randomly, of course
20:23 < Namegduf> Also, defining your own multicharacter operators is evil
20:23 < steven> overall, i think Go is the most fun with regards to channels
and goroutines and select, because it lets you deal with real-world stuff, like
networking, which is much harder in c
20:23 < aiju> Haskell is the "???, PROFIT" way of programming
20:23 < steven> and much more ugly in OOP languages like objc
20:24 < aiju> you enter something and pray and maybe it works
20:24 < aiju> then you write a thesis about how you think it works
20:24 < Namegduf> Networking in Go is beautiful and safe.
20:24 < steven> :)
20:24 < aiju> networking in Go is a rip off of networking in Plan 9 C
20:24 < Namegduf> I like Go because it's very simple to write it, low level
except where high level is good.
20:24 < steven> whats plan 9 c?
20:24 < Namegduf> aiju: Plan 9 C is synchronous?
20:24 < nsf> lol, this irc channel starts to look funny and weird
20:25 < aiju> Plan 9 C has dial(2)
20:25 < Namegduf> "starts"?
20:25 < nsf> :D
20:25 < aiju> steven: the C dialect of the Plan 9 operating system
20:25 -!- TheMue [~TheMue@p5DDF7C62.dip.t-dialin.net] has joined #go-nuts
20:27 -!- coldturnip [~COLDTURNI@111-250-2-225.dynamic.hinet.net] has joined
#go-nuts
20:27 < steven> whoa, what the heck is this package actually doing?
http://code.google.com/p/gosqlite/source/browse/sqlite/sqlite.go
20:27 < steven> it looks like it took half the fun out of GoRM already
20:28 -!- coldturnip1 [~COLDTURNI@111-250-7-7.dynamic.hinet.net] has quit [Ping
timeout: 250 seconds]
20:30 < exch> it just deals with an sqlite db
20:30 -!- rtharper [~tomh@unaffiliated/sioraiocht] has joined #go-nuts
20:30 < exch> bidings for other dbs are probably not going to be any
prettier
20:30 < exch> *bindings
20:31 < steven> oh nevermind, its doing the opposite end.
20:31 < steven> its translating arguments with a statement into a query
string
20:34 < rl> if I have a struct foo, and a foomap map[string]foo, is the
convention for erasing elements: foomap[key] = foo{}, false ? (I'm referring to
what you use as the stand-in object-that-wont-actually-be-stored-in-the-map)
20:34 < rl> it seems a bit odd to "create" an instance of the struct that I
won't use, but I assume the compiler realizes what I'm doing and that the end
result is that one isn't created, it just looks odd in code
20:35 -!- tgall_foo [~tgall@linaro/tgall-foo] has quit [Read error: Operation
timed out]
20:35 < steven> foomap[key] = whatever, false // deletes key
20:35 < rl> exactly, but what should I put in place of the "whatever"
20:35 < exch> yes, but whatever has to be a valid struct value in this case
20:35 < rl> would've been great to be able to do something like
20:35 < exch> since 'nil' doesnt work
20:35 < rl> _, exists := foomap[key]
20:35 < zozoR> _nil, false?  :D
20:36 < steven> oh.
20:36 < zozoR> wat
20:36 < zozoR> _nil, false?
20:36 < zozoR> why does it write nil
20:36 < zozoR> lol
20:36 < rl> what's _nil?  :P
20:36 < steven> can you do _?
20:36 < _nil> what?
20:36 < exch> r1 you can do that, but it wont remove anything
20:36 < rl> oh, that explains it
20:36 < zozoR> if i recall correctly foo[key] = _, false; deletes
20:36 -!- _nil [~nil@users.vu.union.edu] has left #go-nuts []
20:36 < steven> foomap[key] = _, false // is this possible?
20:36 < rl> exch: I know, I meant using _ to assign
20:37 < exch> ah
20:37 < rl> steven: I assumed not but I never actually tried
20:37 < steven> lets hope so!
20:37 < rl> maybe I should actually try..
20:37 < zozoR> apparently, writing a _ as first letter in my irc client,
translates to _nil :D
20:37 < zozoR> _,
20:37 < zozoR> this makes no sense
20:37 < zozoR> :D
20:37 < steven> cuz he exists
20:37 < steven> you're using Linkinus i bet
20:37 < MizardX> "_" is not a value, so "= _, false" is invalid
20:38 < nsf> zozoR: _nil (~nil@users.vu.union.edu) has left #go-nuts
20:38 < nsf> lol
20:38 < rl> nice going
20:38 < rl> but yea = _, false doesn't work :(
20:38 < nsf> that's why it translates to _nil
20:39 < zozoR> aha lol
20:39 < zozoR> epic
20:39 < rl> I guess I'll stick with foo{}, false for now, safe in my
assumption that the compiler will optimize it out..  but the code would look nicer
if I didn't have to do it (I'm tempted to have pointers as map value just so I can
use nil instead)
20:39 < steven> "cannot use _ as value"
20:39 < steven> crap.
20:40 < MizardX> foomap[key] = foomap[key], false
20:40 < steven> nice.
20:40 < skelterjohn> that would do an extra lookup
20:40 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has quit [Remote host
closed the connection]
20:40 < steven> meh
20:40 < exch> performing a map lookup though
20:40 < skelterjohn> foomap[key] = type{}, false
20:40 < steven> the word type?
20:40 < skelterjohn> type{} is just a zeroed version of whatever the value
type is
20:40 < skelterjohn> no
20:40 < exch> one can only hope that T{} does not actually allocate anything
in this case
20:40 < steven> oh.
20:41 < steven> thats what we already do.
20:41 < skelterjohn> if your type is struct X
20:41 < skelterjohn> = X{}, false
20:41 < skelterjohn> isn't = _ supposed to delete?
20:41 < exch> skelterjohn: the point is, does that allocate T{}?  cos it
would be pointless
20:41 < skelterjohn> not on the heap
20:42 < rl> I suspect neither version actually does any creation or
allocation
20:42 < rl> or lookup
20:42 < rl> because it's fairly obvious it will have no side-effects and
won't be stored in the map
20:43 < skelterjohn> = foomap[key], false will do a lookup
20:43 < rl> unless i'm missing something
20:43 < rl> I don't think so
20:43 < skelterjohn> because foomap[key] and false will be evaluated before
looking at the lhs
20:43 < rl> I think the compiler will go "well that will never be used"
20:43 < rl> and just skip the lookup
20:43 < Namegduf> If the compiler can easily optimise it
20:43 < Namegduf> Then assume it does until it becomes an issue in
benchmarks.
20:43 < skelterjohn> that would be a good optimization.  who knows if they
do it
20:43 < Namegduf> If it doesn't today it might tomorrow.
20:43 < skelterjohn> using Type{}, false is the current idiom
20:44 < Namegduf> Or perhaps can be made to do so instead of ugling.
20:44 < rl> Yeah, ok either way this is not an issue about efficiency.  my
program isn't CPU bound
20:44 < rl> skelterjohn: ok, i'll stick with that then
20:44 < rl> It's an issue of aesthetics more than anything else
20:44 < skelterjohn> did themap[key] = _ work before?
20:44 < skelterjohn> why is that i think it used to work - it definitely
doesn't now
20:45 < rl> maybe it did.  it's a rapidly evolving language and you're
living on the bleeding edge :p
20:45 < exch> I think m[k] = _, false would be the least 'ugly' solution to
this
20:45 -!- tgall_foo [~tgall@206.9.88.154] has joined #go-nuts
20:45 < skelterjohn> i just can't imagine why they'd take it out, if it was
ever in there
20:45 < Namegduf> skelterjohn: I remember it being proposed, don't ever
recall it being announced as implemented.
20:46 < rl> it's not really intuitive though; _ normally isn't used as an
rvalue right?
20:46 < rl> I have to admit I didn't even try it before asking because I
assumed it wouldn't work
20:46 < skelterjohn> it reads nicely
20:46 < skelterjohn> map of the key is nothing
20:47 < skelterjohn> or, entry for this key doesn't exist
20:47 < rl> then again it wouldn't be the first thing in Go which was
unintuitive, so maybe that's not a good enough argument by itself
20:47 < Namegduf> Well, built-in stuff is allowed to take more than one
type.
20:47 < Namegduf> You could make nil always legal.
20:47 < Namegduf> It would still be special casing, though.
20:47 < skelterjohn> nil and nothing are different
20:47 < exch> nil already is a special case
20:47 < rl> but _ isn't nothing
20:47 < exch> so adding another wouldnt hurt
20:47 < rl> _ just means "I don't care"
20:47 < Namegduf> _ is "null"
20:48 < skelterjohn> i read it as "nothing" :)
20:48 < skelterjohn> _ = a
20:48 < rl> _ is /dev/null
20:48 < skelterjohn> i am assigning a to nothing
20:48 < Namegduf> I think the problem is that the x, y syntax is inherently
not intuitive
20:48 < skelterjohn> val, _ val2 := foo().  call foo and assign it to val,
nothing and val2
20:48 < Namegduf> I just don't have a better suggestion.
20:48 < rl> Namegduf: tbh, no, the problem is that I have to "create" an
instance to remove one
20:48 < Namegduf> It's useful in some special cases, but that's it.
20:49 < rl> But I don't have a good solution either.  I think when you're
used to the "comma-ok idiom" the map removal isn't that awkward
20:49 < Namegduf> m[i] = x, x != nil
20:49 < Namegduf> Is kinda useful
20:49 < Namegduf> You can easily declare the zero value illegal and have
setting something to it delete it.
20:49 < Namegduf> In your API using a map.
20:50 < Namegduf> But in general I think the ignored x value is weird
20:50 < Namegduf> Actually, I think what I'd like is m[i] = _
20:50 < Namegduf> No , ok
20:50 < Namegduf> Just _ as the "delete" syntax.
20:50 < MizardX> if foo is nullable, foomap[key] = nil, false
20:51 < exch> m[k] = _ would work in any situation
20:51 < Namegduf> Maybe the , ok syntax optionally.
20:51 < Namegduf> But I'd lean to not.
20:51 < skelterjohn> if your key type is a struct rather than a pointer,
doing the extra Type{} won't slow things down any
20:51 < skelterjohn> because inside the map it will be tossing those around
like crazy anyway
20:52 < Namegduf> Yeah, passing structs by value is weird
20:52 < Namegduf> Because of that effect.
20:53 < rl> I think the speed is a red herring
20:53 < rl> In my case at least
20:53 -!- jcdny [~davis@mailrelay1.pbclients.com] has quit [Quit: Leaving]
20:53 < rl> Because the compiler could easily make it a non-issue, the issue
is how the code looks/reads.
20:54 < rl> = _ does seem to be the most reasonable alternative, but it does
give _ a new meaning
20:54 < skelterjohn> i disagree on the last point
20:54 < rl> Namegduf: You said you remember it being proposed, was there
some conversation around it?  I'd be curious to reading the design discussion if
there was any
20:54 < skelterjohn> but it's not well definied
20:55 < Namegduf> rl: Yes, a fair bit.
20:55 < Namegduf> I have no information that'd make it easier to search for
for me than you, though, it was a fair while ago and I've forgotten the titles of
stuff.
20:55 < rl> Do you remember where it took place?  Mailing list?
20:56 < Namegduf> Yes.
20:56 < rl> I'm good at searching, but it would help to know where to
search.  "go" is an unsurprisingly unrestrictive keyword
20:56 < rl> ok, I'll see if I have any luck
20:56 < Namegduf> "golang" usually works better.
20:56 < exch>
https://github.com/jteeuwen/gofactor/blob/master/docs/scripts/test1.gf <3
20:57 < Namegduf> Whoo, CC0
20:57 < rl> Here's at least one thread on it:
http://groups.google.com/group/golang-nuts/browse_thread/thread/72f46ebfb9efebbf/b520c791665f942c
20:57 < rl> (If anyone else is curious)\
20:57 -!- dahankzter [~henrik@92-244-3-192.customers.ownit.se] has joined #go-nuts
20:58 < rl> map[key] = _ is never discussed though
20:58 < rl> only map[key] = nil
20:58 < rl> and map[key] = _, false
20:59 < rl> both which don't work for good reason
20:59 < skelterjohn> why would the 2nd not work?
20:59 < Namegduf> _ alone was mentioned in amongst them, I thought.  Maybe I
misremember.
20:59 < Namegduf> skelterjohn: Probably hard to guarantee the boolean is
false.
20:59 < Namegduf> _, false literally works, but _, <anything not always
false> has problems.
21:00 < skelterjohn> oh i see - = _, true would be not allowed
21:00 < exch> 'm[k] = nil' makes no sense to begin with
21:00 < Namegduf> nil is a valid value
21:00 < exch> it just nils the value in the slot
21:01 < rl> skelterjohn: I think the biggest problem was what if the 2nd
argument wasn't obviously false or true
21:01 < rl> like based on user input
21:02 < Namegduf> It's also redundant.
21:02 < Namegduf> There's solutions- _, true could leave it unchanged.
21:02 < Namegduf> Or such.
21:02 < rl> Fair enough, but it's another edge-case to know of
21:02 < rl> I think = _ would be cleaner
21:03 < rl> if shouldDelete { map[key] = _ }
21:03 < rl> would be cleaner IMO
21:03 < Namegduf> I agree.
21:03 < exch> m[k] = _, shouldDelete isn't bad either
21:03 < Namegduf> It's special syntax and maybe less similar to other syntax
than map[key] = v, false
21:04 < Namegduf> But I like not having redundant stuff more.
21:04 < Namegduf> Besides, map deletion isn't really assignment, so making
it look odd is fine by me.
21:04 < Namegduf> Give not really a value when you're not really assigning.
21:04 < Namegduf> :P
21:05 < Namegduf> Assigning it to something not a value is probably the
clearest way of representing deletion as assignment, I think.
21:06 < Namegduf> Er, assigning something not a value to it.
21:07 < exch> One would amost consider a good old fashioned m.delete(k) a
viable solution :p
21:07 < exch> almost
21:07 < rl> I think the decision is to not have any methods on basic types
21:07 < KirkMcDonald> Be like Python, add a keyword!
21:07 < rl> but delete(m, k) could still work
21:07 < exch> yea
21:07 < KirkMcDonald> del m[k]
21:08 < Namegduf> Keywords are evil
21:08 < Namegduf> Represent everything with symbols!
21:08 < Namegduf> rl: All the built-ins are useful for more than one type,
though, and delete is a very generic now
21:08 < Namegduf> *name
21:09 < rl> true
21:09 < Namegduf> I suppose you could analogise it to append(), but the
difference is that append() only really makes sense for slices
21:09 < exch> it doesnt really aply to any other cases
21:09 < exch> del() that is
21:09 < Namegduf> And delete() could make sense in other things.
21:09 < exch> deleting indices or ranges from slices perhaps
21:09 < Namegduf> Yeah.
21:09 < Namegduf> But it wouldn't be a good idea to provide it for that.
21:10 < Namegduf> Because it's slow to do the stupid way and the smart way
involves knowing that ordering is unimportant.
21:10 < Namegduf> Which it couldn't assume.
21:10 < rl> Well I wouldnt' want to have an array with carefully maintained
ordering mangled by the delete()
21:11 -!- plainhao [~plainhao@208.75.85.237] has quit [Quit: plainhao]
21:11 < Namegduf> And I wouldn't want to copy 100 entries down instead of
swapping with the last and dropping the length when I don't care about ordering.
21:11 < rl> Yeah
21:11 < Namegduf> I think a generic delete on a slice is a bad idea.
21:11 < rl> maybe it should accept a boolean which is only used in the case
of an array which specifies which operation to use :p (I kid I kid)
21:12 < rl> (I'm just annoyed by having to specify -1 to string.split to
tell it "split as much as possible")
21:12 -!- skejoe [~skejoe@188.114.142.162] has quit [Quit: Lost terminal]
21:12 < rl> (I'd rather have two different methods: one for split all and
one for split some...  </rant>)
21:12 < rl> *strings.split and *functions, w/e
21:13 < KirkMcDonald> That's not as strange as what Python does for
str.split, I think.
21:14 < rl> Really?  help(''.split) seems entirely reasonable
21:14 < rl> No max # of splits?  Split as much as possible.  No delim?
Split on whitespace
21:14 < KirkMcDonald> rl: Yes!  Just that.
21:15 < rl> Oh. Maybe it's a matter of taste
21:15 < KirkMcDonald> The lack of a delimiter splits arbitrarily on
whitespace.
21:15 < rl> I find splitting on whitespace the most common thing
21:15 < Namegduf> Methods on types open portals to hell.
21:15 < KirkMcDonald> So 'foo\t bar'.split() == ['foo', 'bar']
21:15 < Namegduf> *constants
21:15 < Namegduf> If anyone writes a Go IDE can that be in the Tip of the
Day list?
21:15 < KirkMcDonald> And 'foo\t bar'.split(' ') == ['foo\t', '', 'bar']
21:15 < Namegduf> It really should be.
21:16 < KirkMcDonald> This is useful behavior, don't get me wrong.
21:16 < KirkMcDonald> But it is a little weird.
21:16 < rl> KirkMcDonald: I think it's reasonable.  But I'll agree that it's
weird that the default behavior is not the simplest behavior
21:16 < rl> Namegduf: what do you mean?
21:16 < KirkMcDonald> Also, using None as the delimiter is equivalent to not
specifying one.
21:17 < Namegduf> rl: Methods on constants.  " ".superfun(), 5.blah()
21:17 < Namegduf> Literals.
21:17 < rl> KirkMcDonald: That's because python can't distinguish between
passing no argument and passing "none" as an argument I suspect?  What else would
you expect would happen anyway?
21:17 < Namegduf> Not constants, literals.
21:17 < rl> Oh, yeah
21:17 < rl> But that's python
21:17 < rl> everything is an object
21:17 < KirkMcDonald> rl: No, Python does distinguish between these things.
21:18 -!- dfc [~dfc@203-158-48-86.dyn.iinet.net.au] has joined #go-nuts
21:18 < rl> In python "foo" isn't a literal, it's an object.  But that's a
different discussion for a different channel I think
21:18 < Namegduf> Python is about simple but its version of simple is
focused on intuitiveness, not simple semantics.
21:18 < KirkMcDonald> rl: If the function were written in Python, it might
look like: def split(self, sep=None, maxsplit=None):
21:18 < rl> (at least I dont' want to discuss python design in here)
21:18 < KirkMcDonald> rl: It *is* a literal.  It is also an object.
21:18 < KirkMcDonald> However, 5.blah() is a syntax error.  :-)
21:19 < KirkMcDonald> The 5.  is lexed as a float.
21:19 < rl> Ok, ok, I'll bite
21:19 < rl> Namegduf: I actually feel python is very simple, perhaps because
of the intuitiveness though.  But I'd never use it to write a big program
21:20 < KirkMcDonald> Python gets a bad rap on that front, I think.
21:20 < rl> It deserves it
21:20 < KirkMcDonald> But I use it for a living, on a rather large code
base.
21:20 < Namegduf> rl: I'm not saying it's ridiculously complex, just that
its focus is on intuitiveness first
21:20 < KirkMcDonald> So perhaps my perspective is skewed.
21:20 < Namegduf> .split() does The Right Thing
21:20 < rl> KirkMcDonald: Doesn't it bother you that a typo can go
undetected for ages until the specific branch of code with the typo is triggered,
unless you have 100% test coverage?
21:20 < Namegduf> It also happens to be a complex and arbitrary thing
21:21 < Namegduf> Yeah, Python is the kind of language that drives me to
unit testing.  :P
21:21 < KirkMcDonald> rl: Heh.  As a rule, if something like that makes it
out to the live site, it will be detected astonishingly quickly.
21:21 < rl> (That's my most fundamental problem with Python)
21:21 < KirkMcDonald> rl: Aside from that, we use mandatory code reviews.
21:21 < rl> Well, as a rule something like that shouldn't make it out to the
live site
21:21 < KirkMcDonald> Mere typos are relatively rare.
21:22 < Namegduf> I've had that problem with JS.
21:22 < rl> Do people really track down function names in code reviews to
make sure every single function call is correct?
21:22 < Namegduf> Did a major rework of an existing codebase.
21:23 < Namegduf> Bugs cropping up for ages after.  :(
21:23 < rl> JS is also bad yes.  My major beef with Js though is that you
can happily pass too many or too few arguments to a function without as much of a
nice hint that you might be doing something you don't want to
21:24 < rl> KirkMcDonald: If they do maybe the time they gain writing python
is wasted doing code reviews :p
21:24 < Namegduf> To be fair, typos are relatively obvious in names,
usually.  Usually.
21:25 < rl> Sure, typos was the quickest example to type out
21:25 < KirkMcDonald> Yes, usually.  Particularly if the person doing the
review is familiar with the names in our code base.
21:25 < rl> Missing out or adding an extra "s" though where it's not obvious
whether a function should name something plural might be harder to detect
21:26 < KirkMcDonald> Also, the person writing the code is fully expected to
test it before sending it out for review.
21:26 < Namegduf> But yeah, the idea of Python as fast to develop is one I
find dubious because to develop good code involves a bunch more time being careful
to not have tripped up.
21:26 < rl> KirkMcDonald: But if you have a fairly large codebase does any
person know it that well?
21:26 < Namegduf> And *requires* tests.
21:26 < rl> KirkMcDonald: Well then we're back to 100% test coverage
21:26 < KirkMcDonald> rl: We use relatively consistent names.  And only
people familiar with the code in the first place can check off on a review.
21:27 < rl> And if you're modifying core code even telling what you could be
breaking would be very hard, so manual testing of *everything* can't really be
expected
21:27 < Namegduf> Without tests it's that much worse.  If tests would be
worth it anyway...
21:27 < KirkMcDonald> rl: I'm not talking about unit tests as such.
21:27 < Namegduf> It's why I like Go.
21:27 < rl> Some tests are worth it..  100% test coverage isn't
21:27 < KirkMcDonald> rl: The number of people working on the core parts of
the code is very, very small.
21:27 < Namegduf> High-level language like dev speed, static compilation and
type checking.
21:27 < rl> KirkMcDonald: Well I'm glad you have enough people with enough
time on their hands that know the code that well
21:28 < steven> how do you delete an element from a slice or array?  (not
just zero it out, but remove that entry so the array or slice is one element
shorter)
21:28 < rl> You have to admit though that you realize you're placing a lot
of requirements on your process which wouldn't be necessary in other languages
right?
21:28 < Namegduf> Well
21:28 < rl> Ok not a lot, but fairly large requirements
21:28 < Namegduf> Python is much worse off without the extra bits
21:28 < Namegduf> With them I wouldn't presume to compare
21:28 < KirkMcDonald> rl: We use mandatory code reviews for all languages.
21:28 < Namegduf> If they'd be worth it anyway, it's no real loss.
21:29 -!- binarypie [~binarypie@adsl-99-35-135-146.dsl.pltn13.sbcglobal.net] has
quit [Remote host closed the connection]
21:29 < rl> KirkMcDonald: Yes, I'm not talking about mandatory code reviews,
those are good
21:29 < KirkMcDonald> rl: And it is entirely reasonable to expect someone to
make sure their code works before they submit it.
21:29 < rl> But when I review someone's code I normally don't bother
spending cycles figuring out if a function name is correct
21:29 < Namegduf> If they wouldn't be worth it if it wasn't for Python's
Pythonness, then there's a disadvantage there.
21:29 < rl> If the code base is large enough it severely limits the number
of people who could do a code review and know by heart every single function call
21:30 < Namegduf> And yeah...  it seems like without static checks of
obvious things you'd have to spend longer to do the analysis on its functions.
21:30 < rl> And as I said it's not always obvious who is calling the code
you're modifying
21:30 < rl> How do you know you've tested everything if you're testing it
manually?
21:30 < rl> "make sure your code works" is a good theory
21:30 < rl> But it's difficult to implement in practice
21:30 -!- binarypie [~binarypie@adsl-99-35-135-146.dsl.pltn13.sbcglobal.net] has
joined #go-nuts
21:31 < rl> Anyway, maybe before dismissing everything so easily
21:31 -!- Slant [~scott@115.130.5.163] has joined #go-nuts
21:31 < rl> KirkMcDonald: Haven't you ever had errors in production which
were due to mis-named functions or similar?
21:31 < rl> You already said "typos get caught quickly" in production, so I
assume there must be at least some precedent
21:32 < KirkMcDonald> Yes, certainly.  Typically they are caught during the
canary.
21:32 < rl> And doesn't that cause extra work?  Cherrypicking fixes,
delaying releases, and such?
21:33 < KirkMcDonald> Yes.  As any bug that only manifests when going live
would.
21:33 < rl> Sure, I'm not saying you dont' have those bugs in other
languages too.  I just thought it might happen more often in Python, where you
don't have the safety of a compiler
21:33 < rl> I'm not saying that it's totally unreasonable to work on a
Python codebase though
21:34 < rl> There are projects that start small in Python and grow to
unexpected sizes i guess
21:34 < KirkMcDonald> The use of Python was entirely intentional.
21:35 < rl> Intentional in the way of "let's write a large codebase in
python"?
21:35 < KirkMcDonald> Basically.  Python was chosen on its merits.
21:36 < rl> Ok, I might be making some assumptions about largeness as well.
Out of curiosity, what order of magnitude is "large", if you're at liberty to say?
21:36 < KirkMcDonald> I am not.
21:36 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has quit [Remote host closed
the connection]
21:36 < rl> I realize that in a codebase with hundreds of central libraries
that everyone uses
21:36 < rl> as well as individual projects ontop of that with a lot of
project-specific code
21:37 < rl> Is an unfair model for a "large" codebase in python
21:39 -!- Venom_X_ [~pjacobs@75.92.43.21] has joined #go-nuts
21:39 -!- ronny [~quassel@p4FF1C6A8.dip0.t-ipconnect.de] has joined #go-nuts
21:40 -!- Venom_X [~pjacobs@66.54.185.131] has quit [Ping timeout: 246 seconds]
21:40 -!- dfc [~dfc@203-158-48-86.dyn.iinet.net.au] has quit [Quit: dfc]
21:45 -!- dahankzter [~henrik@92-244-3-192.customers.ownit.se] has quit [Ping
timeout: 240 seconds]
21:46 -!- Slant_ [~scott@115.130.1.67] has joined #go-nuts
21:47 -!- Slant [~scott@115.130.5.163] has quit [Ping timeout: 250 seconds]
21:49 -!- saschpe [~quassel@opensuse/member/saschpe] has quit [Remote host closed
the connection]
21:52 -!- pharris [~Adium@rhgw.opentext.com] has quit [Quit: Leaving.]
21:56 -!- binarypie [~binarypie@adsl-99-35-135-146.dsl.pltn13.sbcglobal.net] has
quit [Remote host closed the connection]
21:56 -!- imsplitbit [~imsplitbi@64.39.4.132] has quit [Quit: Bye!]
21:57 -!- Slant [~scott@115.130.1.67] has quit [Ping timeout: 250 seconds]
22:08 -!- Netsplit *.net <-> *.split quits: stalled
22:08 -!- Netsplit *.net <-> *.split quits: rotorooter
22:08 < steven> type id interface{} // objc ftw ;)
22:08 -!- TheMue [~TheMue@p5DDF7C62.dip.t-dialin.net] has quit [Quit: TheMue]
22:09 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.4]
22:11 < skelterjohn> the one issue with that is that you can't give
something a "func() id" when it wants a "func() interface{}"
22:11 -!- piranha [~piranha@5ED4B890.cm-7-5c.dynamic.ziggo.nl] has quit [Quit:
Computer has gone to sleep.]
22:11 -!- rotorooter [~roto@64.79.202.154] has joined #go-nuts
22:11 < skelterjohn> steven: i experimented with "type Box interface{}" for
a while, but that issue made it annoying
22:14 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has quit [Quit: skelterjohn]
22:15 -!- EightBitBaker [~andreas@mivacukor.lha.sgsnet.se] has joined #go-nuts
22:22 < steven> hehe
22:28 -!- rlab_ [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller,
Faster, Easier.  http://miranda-im.org]
22:29 < steven> how do you guys like gotest?
22:30 * exch never used it
22:30 < exch> that is, I use the testing package, but not the gotest command
22:31 < exch> oh seems I do
22:31 < exch> 'make test' invokes it under the hood
22:35 -!- Fish- [~Fish@9fans.fr] has quit [Quit: So Long, and Thanks for All the
Fish]
22:37 -!- dfc [~dfc@sydfibre2.atlassian.com] has joined #go-nuts
22:40 < steven> :)
22:45 < MizardX> gotest requires bash, so I can't use it on windows without
something like cygwin.
22:48 < steven> ouch.
22:48 * steven weeps for anyone using windows
22:50 -!- Project-2501 [~Marvin@82.84.77.44] has quit [Quit: E se abbasso questa
leva che succ...]
22:50 * dfc consoles steven with a manly punch in the shoulder
22:54 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
22:54 -!- awidegreen [~quassel@c-eacae555.08-2-73746f39.cust.bredbandsbolaget.se]
has quit [Remote host closed the connection]
22:57 -!- skelterjohn [~jasmuth@c-68-45-238-234.hsd1.nj.comcast.net] has joined
#go-nuts
23:01 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit:
Verlassend]
23:02 -!- rtharper [~tomh@unaffiliated/sioraiocht] has quit [Remote host closed
the connection]
23:02 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has joined #go-nuts
23:03 -!- rtharper [~tomh@unaffiliated/sioraiocht] has joined #go-nuts
23:05 -!- eglaysher [~erg@nat/google/x-vaygpqgzejvdbiqh] has joined #go-nuts
23:10 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Ping timeout: 276 seconds]
23:16 -!- Venom_X [~pjacobs@75.92.43.21] has quit [Quit: Venom_X]
23:17 -!- Venom_X [~pjacobs@66.54.185.131] has joined #go-nuts
23:17 * steven weeps harder and girlier
23:17 -!- Guest30783 [~quassel@p4FF1C6A8.dip0.t-ipconnect.de] has quit [Remote
host closed the connection]
23:17 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
23:18 -!- boscop [~boscop@f055255209.adsl.alicedsl.de] has quit [Ping timeout: 246
seconds]
23:18 -!- DeedleFake [~Deedles@c-98-251-36-162.hsd1.ga.comcast.net] has joined
#go-nuts
23:20 < DeedleFake> Is there any way to set a slice to nil using the reflect
package?
23:22 < |Craig|> can slices even be nil?
23:23 < exch> yes.  but a nil value for a slice is simply a slice with 0
length and 0 capacity
23:23 < |Craig|> exch: thats a zero value, not nil isn't it?
23:24 < exch> myslice = nil; <- myslice is now a slice with 0 len, 0 cap
23:24 < |Craig|> oh, interesting
23:24 < |Craig|> are there any other types that works with?
23:26 < DeedleFake> When I try using SliceValue.Set(nil), it panics.  I took
a look at the code for the reflect package, and it attempts to access a variable
in the SliceValue struct without first making sure that it's not nil, hence the
panic.  It's kind of odd that it wouldn't try to catch that when there's a
SliceValue.IsNil() function...
23:29 < homa_rano> am I the only one really annoyed by the culture of
comparing slices to nil?  it's more general and more obvious to see if they're
empty
23:30 < steven> homa_rano: uhh, i have no idea what you're talking about
23:30 < steven> oh, didnt read upwards.
23:32 < homa_rano> there are a few interfaces in the standard pkgs that
demand that empty return slices be nil
23:33 < homa_rano> which requires a useless explicit check before and after
the function returns
23:33 < steven> homa_rano: but how would you "empty" a slice as easily and
clearly as slice=nil ?
23:33 < steven> you can do slice = make([]T) i guess..  but thats not really
the same as setting it to nil, in intent at least
23:33 <+iant> DeedleFake: if you use NewValue with the slice type, you
should get a value which is nil
23:34 <+iant> then you can use SetValue with that
23:34 < homa_rano> hmm, I just considered the garbage collection
implications of manually nil'ing slices instead of just returning an empty
subslice of them
23:35 < homa_rano> complaint (begrudgingly) withdrawn
23:35 < steven> how do you even return an empty subslice btw?
23:35 < steven> and yes, GC.
23:35 < DeedleFake> I tried that, but that requires that I explicitly tell
it what type the elements of the slice are, which means I'd have to use a switch
to cover every possible case.
23:35 < homa_rano> myslice[3:3]
23:35 < steven> myslice[0:0] ?
23:35 < homa_rano> which naturally occurs in some cases where the answer
happens to have no values
23:36 < homa_rano> (I'm looking at you suffixarray)
23:36 < steven> but that leaves the underlying array intact
23:38 -!- matti__ [~mumboww@c-24-6-22-101.hsd1.ca.comcast.net] has joined #go-nuts
23:45 -!- qjcg [~qjcg@208.88.110.46] has joined #go-nuts
23:45 -!- qjcg [~qjcg@208.88.110.46] has left #go-nuts []
23:51 < DeedleFake> Any ideas?
23:53 < DeedleFake> Oh well.  Thanks.
23:54 -!- DeedleFake [~Deedles@c-98-251-36-162.hsd1.ga.comcast.net] has left
#go-nuts ["Ex-Chat"]
23:54 -!- GoBIR [~gobir@c-24-130-224-186.hsd1.ca.comcast.net] has quit [Ping
timeout: 276 seconds]
23:56 -!- GoBIR [~gobir@c-24-130-224-186.hsd1.ca.comcast.net] has joined #go-nuts
--- Log closed Tue Mar 08 00:00:48 2011