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