--- Log opened Thu Mar 24 00:00:50 2011 00:06 -!- skelterjohn [~jasmuth@c-68-46-33-145.hsd1.nj.comcast.net] has joined #go-nuts 00:11 < ww> almost got it... but... anyone gotten cgo to work in a cross compiled environment? 00:12 < ww> cgo -dynimport of course fails... because cgo is build for osx/amd64 and it is trying to understand a linux/arm object file... 00:17 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has joined #go-nuts 00:18 < plexdev> http://is.gd/V5gygT by [Andrew Gerrand] in go/doc/ -- doc: update contrib.html to be more enticing 00:25 < str1ngs> ww: I assume you are on osx. you would have to make a arm-linux cross compiler. and even though I'm not sure if cgo can cross compile 00:26 -!- ExtraSpice [XtraSpice@88.118.35.153] has quit [Read error: Connection reset by peer] 00:26 < ww> str1ngs: yes, way past the makinga cross compiler part 00:27 < ww> arrived at the point where cgo tries to extract symbols... and isn't understanding the temporary arm binary it makes to do that 00:27 < str1ngs> may not know elf then 00:28 < ww> cgo -dynimport _cgo1_.o >_obj/_cgo_import.c_ && mv -f _obj/_cgo_import.c_ _obj/_cgo_import.c 00:28 < ww> cannot load dynamic symbols: no symbol section 00:28 < str1ngs> might have better luck on a linux box. or better yet native build go on the andriod 00:28 < ww> actually, it does understand it as elf 00:29 < str1ngs> do you have native compiler on the andriod? 00:29 -!- Zoopee [alsbergt@zoopee.org] has quit [Ping timeout: 255 seconds] 00:30 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has joined #go-nuts 00:31 < ww> no, but that may not be such a bad idea to try.... 00:32 < str1ngs> if you need a native compiler let me give you a link 00:32 < str1ngs> http://www.landley.net/aboriginal/downloads/binaries/extras/ 00:32 < str1ngs> http://www.landley.net/aboriginal/downloads/binaries/ this is cross and system images. the first one has native 00:33 < str1ngs> think yo need arm6l .. offhand 00:34 < str1ngs> if your droid cant handle native compiling then maybe use the qemu system images 00:35 < plexdev> http://is.gd/IzvzmM by [Alex Brainman] in 3 subdirs of go/src/pkg/ -- syscall: StartProcess fixes for windows 00:35 < str1ngs> ww: I was thinging of adding cross compiler support to my via project 00:39 < ww> let's see how far we get with arm5l (go has problems with arm6... illegal instructions and such) 00:40 < str1ngs> is your droid a arm5l though? 00:42 < ww> not sure... arm6 should be backwards compatible though 00:42 < ww> let me see... 00:43 < ww> actually is 6l 00:44 < str1ngs> ya stick with arm6l then 00:44 < str1ngs> try that native compiler 00:52 < plexdev> http://is.gd/VB3m16 by [Andrew Gerrand] in 3 subdirs of go/src/pkg/runtime/freebsd/ -- runtime: fix freebsd-amd64 (and part of 386) 00:52 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has quit [Quit: Computer has gone to sleep.] 00:56 -!- Zoopee [alsbergt@zoopee.org] has joined #go-nuts 00:59 -!- iant [~iant@67.218.107.6] has quit [Quit: Leaving.] 01:06 < ww> well... that's promising... 01:06 < ww> the phone locked up while untarring 01:08 < str1ngs> did you have enough space? 01:09 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has quit [Ping timeout: 250 seconds] 01:09 < ww> yeah 01:11 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has joined #go-nuts 01:17 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has joined #go-nuts 01:18 -!- nettok [~quassel@200.119.160.242] has joined #go-nuts 01:19 -!- saturnfive [~saturnfiv@210.74.155.131] has joined #go-nuts 01:19 -!- Zoopee [alsbergt@zoopee.org] has quit [Ping timeout: 248 seconds] 01:19 -!- saturnfive [~saturnfiv@210.74.155.131] has quit [Client Quit] 01:21 < ww> str1ngs: ahem... looks like this is going to be a longer running "project" 01:21 < ww> the permissions on the sd card are wacky 01:22 < ww> noteably no running binaries directly off of it 01:22 < ww> looking at the startup scripts, i can have a second partition on the sd card, which will be ext2... 01:23 < ww> but... i'll have to wait for my new sd card to arrive, which should be tomorrow... 01:24 < str1ngs> ah makes sense 01:24 < str1ngs> ww: is it ok to homebrew droids? 01:25 < ww> i'm running cyanogen... there are instructions on the wiki for a bare bones system... would be a good starting point 01:26 < ww> http://wiki.cyanogenmod.com/index.php?title=Barebones 01:26 < str1ngs> ww: well right now I'm working on a project called via. it would be possible to add cross support to it 01:26 -!- Zoopee [alsbergt@zoopee.org] has joined #go-nuts 01:27 < str1ngs> ww: basically via is a makepkg but written in go. 01:28 < ww> i see 01:28 < exch> http://img.jteeuwen.nl/var/albums/Misc/mpwc.png writing UI controls from scratch is a tricky proposition. specially if it has to work in multiple browsers O.o The scrollbar and playlist in that screenshot are two examples 01:28 < exch> they are nice and fast now though. Even with 4500+ rows of data to work with 01:28 < ww> from what i've seen so far, we need a good package manager for ASOP 01:28 -!- boscop [~boscop@g227113009.adsl.alicedsl.de] has quit [Ping timeout: 255 seconds] 01:29 < str1ngs> asop? 01:30 < ww> android open source... for some reason dyslexic 01:30 < str1ngs> well there is ipkg 01:30 < ww> one problem 01:30 < str1ngs> pacman might be a good choice to 01:30 < ww> ... is the distribution 01:31 < str1ngs> which? 01:31 < ww> google is keeping a stranglehold on it (android market) 01:31 < ww> so need something like apt or pacman 01:31 < str1ngs> ipkg is good for small stuff its a striped down dpkg 01:32 < str1ngs> pacman though imo is easy to work worth. but its makepkg is very bloated 01:32 < str1ngs> for embeded anyways 01:32 * ww tries to remember where i've seen ipkg before... 01:32 < ww> maybe openwrt? 01:32 < str1ngs> yes thinkg openwrt uses it 01:32 < str1ngs> imo would be fun to make a package manager in go 01:33 -!- ronnyy [~quassel@p4FF1C687.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 01:34 < str1ngs> ww: also alpine linux has a good packag manager 01:34 < str1ngs> better then pacman in some regards 01:34 < ww> indeed it would be 01:34 < str1ngs> ie package signing for one 01:35 < str1ngs> ww: https://github.com/str1ngs/via/tree/devel is what I'm playing with now. its very much WIP 01:35 < str1ngs> ww: via + a package manager and you are set 01:36 < str1ngs> I just got switched to naitve go downloading. and now add compression support 01:36 < str1ngs> grr hope that made sense lol 01:36 < ww> well... definitely to be continued... getting late for me... 01:36 < ww> (yes it made sense ) 01:37 < ww> 'night 01:37 < str1ngs> night 01:44 -!- crazy2be [~crazy2be@d209-89-248-73.abhsia.telus.net] has joined #go-nuts 01:45 < crazy2be> i keep getting a bad file descriptor error 01:45 < crazy2be> Warning: Failed to log request! write log/server/2011-03-23 19:36:31: bad file descriptor 01:45 < crazy2be> any ideas? 01:47 < crazy2be> when i open it using os.Open(), the err returned is nil, so i'm at a loss for where to find the error 01:47 < crazy2be> hmm maybe i'll try a reboot 01:49 < str1ngs> crazy2be: can you paste some code? 01:51 < crazy2be> http://pastie.org/1706545 01:51 < crazy2be> the only thing i can think of is that the : in the name are causing issues 01:52 < crazy2be> or that a reboot is needed, but other applications seem to be functioning fine 01:52 < crazy2be> runLogger() is run with go runLogger() near the start of main() 01:53 < crazy2be> because it's a multithreaded server, i thought channels would be the best way to do the logging 01:53 < str1ngs> crazy2be: hmm might want to use more unix friendly names 01:53 < crazy2be> rather than having multiple threads trying to write to a file 01:53 < crazy2be> str1ngs: such as? 01:53 < crazy2be> no space? 01:53 < crazy2be> or no :? 01:53 < str1ngs> yes 01:53 < str1ngs> but backticks might help 01:54 < str1ngs> first try with no space 01:54 < crazy2be> yeah if i change it to "2006-01-02+15:04:05" it's the same issue 01:57 < crazy2be> even with no spaces or colons: 01:57 < crazy2be> Warning: Failed to log request! write log/server/2011-03-23_19-59-32: bad file descriptor 01:57 < crazy2be> ima try rebooting i guess 01:57 -!- crazy2be [~crazy2be@d209-89-248-73.abhsia.telus.net] has quit [Remote host closed the connection] 01:59 < str1ngs> ya spaces are fine I just checked 01:59 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has joined #go-nuts 01:59 -!- mode/#go-nuts [+v iant] by ChanServ 02:00 < str1ngs> wait nope 02:02 < str1ngs> you need to add a read flag 02:02 -!- crazy2be [~crazy2be@d209-89-248-73.abhsia.telus.net] has joined #go-nuts 02:02 < str1ngs> well write flag rather 02:02 < crazy2be> yeah still the same issue 02:02 < crazy2be> oh didn't think of write flag 02:03 < str1ngs> godoc os | less see CONSTANTS section 02:03 < crazy2be> that would be it 02:03 < steven> is there a way to "serialize" data in Go? 02:03 < crazy2be> steven: yes 02:04 < steven> how so? 02:04 < crazy2be> json package is one 02:04 < crazy2be> that's what i use for most of my stuff 02:04 < str1ngs> crazy2be: you can use RDWR . not sure why I missed that either 02:04 < crazy2be> but there is also a binary one 02:04 < crazy2be> str1ngs: It's a wierd error, but i guess it makes sence now 02:05 < steven> gob? 02:05 < crazy2be> srt1ngs: But i only need os.O_WRONLY, since it's a log :P 02:05 < str1ngs> of course :P 02:05 < crazy2be> steven: that might do it to, have not used it 02:06 < crazy2be> str1ngs: I owe you one, that probably would have taken me a while to figure out 02:06 < crazy2be> i googled the error, and it was telling me the most likely cause was disk errors 02:06 < str1ngs> crazy2be: ah now worries. help me learn 02:06 < steven> aw snap. 02:06 < steven> gob looks perfect for this. 02:06 < crazy2be> steven: What are you trying to do? 02:06 < steven> i wanted to port another of my libs to Go 02:06 < str1ngs> can you serialize functions? 02:07 < steven> but apparently the stdlib contains pretty much everything 02:07 < steven> sonofabitch 02:07 < steven> str1ngs: i highly doubt it. the code of functions isnt accessible. 02:07 < crazy2be> steven: Just the useful stuff :) 02:07 < str1ngs> steven: naw just the type 02:08 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has quit [Ping timeout: 255 seconds] 02:08 < steven> str1ngs: oh yeah you can easily get the func type info in transmittable form 02:08 < steven> via reflect. 02:08 < steven> just not the useful part, ie the code 02:08 < steven> :) 02:08 < str1ngs> steven: https://github.com/str1ngs/via/blob/devel/plans/dash.go 02:08 < str1ngs> I need to figure out a better way to do that 02:09 < steven> str1ngs: to do what 02:09 < str1ngs> either serialize that. or some better way. not sure if you get whats going on there 02:10 < steven> nope. 02:10 < str1ngs> but when the file is loaded it self registers its self in a map. its a cheap hack 02:10 < steven> you cant serialize a function. 02:10 < steven> its logically not possible. 02:10 < str1ngs> not the fucntion just the type 02:11 < crazy2be> "Functions and channels cannot be sent in a gob. Attempting to encode a value that contains one will fail." 02:11 < str1ngs> dang 02:12 < str1ngs> I need a better meta format then what I"m using 02:15 < steven> package rpc is pretty much what i was planning on implementing. 02:15 < steven> grr 02:16 < crazy2be> steven: It's frustrating when you plan to do something, then find out the've thought of it already :P 02:16 < steven> yeah 02:16 < steven> story of my life. 02:16 < steven> ive pretty much given up on trying to do helpful/useful things, because all of its already been done 02:16 < str1ngs> hehe 02:17 < steven> so i just code whatever i want, since im sure none of it will ever be useful anyway 02:17 < steven> just like `godo` was redundant, since gorun and goscript already do the same thing 02:17 < str1ngs> I need a decompressor :P 02:17 < steven> i need a back massage 02:18 < str1ngs> ghey! 02:18 < str1ngs> something that can handle .tar.gz and .tar.bzip2 go has everthing in the stdlib just needs to be put together nicely :P 02:19 < steven> why not just shell out to tar and bunzip and gunzip? 02:20 < str1ngs> it does right now but forks are bad 02:20 < str1ngs> that means I'm dependant on those 02:20 < steven> forks? 02:20 < steven> why are you dependent on a fork? 02:20 < str1ngs> exec 02:20 < skelterjohn> in what way are they bad? 02:21 < steven> no dont use exec 02:21 < str1ngs> there bad in the sense I need to have tar etc 02:21 < steven> they arent bad, they just arent useful for *this* 02:21 < skelterjohn> exec.Run will do it for you 02:21 < str1ngs> you dont get it 02:21 < steven> http://golang.org/pkg/exec/ 02:21 < steven> right. use exec.Run 02:21 < steven> oh? i dont? 02:21 < str1ngs> no you dont 02:21 < steven> please help me get it 02:21 < steven> i hate not getting it 02:22 < str1ngs> why use tar and wget if I dont need it 02:22 < str1ngs> cant assume thats even installed 02:22 < steven> ah. 02:22 < steven> good piont 02:22 < str1ngs> this way. all I need is via gcc and make 02:22 < crazy2be> http://golang.org/pkg/archive/tar/ ? Or did you know about that already? 02:22 < str1ngs> if they dont have gcc or make. I have a stage1 tar ball 02:23 < skelterjohn> make isn't always installed :) 02:23 < str1ngs> see above 02:23 < str1ngs> it also will build a tool chain from stage1 tarball 02:23 -!- iant [~iant@216.239.45.130] has joined #go-nuts 02:23 -!- mode/#go-nuts [+v iant] by ChanServ 02:23 < str1ngs> crazy2be: aye 02:24 < str1ngs> https://github.com/str1ngs/gurl is replacing my wget forks 02:24 < str1ngs> it limited but works 02:24 < str1ngs> doesnt handle https yet either 02:25 < crazy2be> hmm? 02:25 < crazy2be> why are you writing a library to do that? 02:25 < str1ngs> becuase Its something I'd use alot 02:25 < crazy2be> you can just use the http lib to download, then pipe that to the gzip lib, then pipe that to the tar lib 02:25 < str1ngs> think libcurl 02:26 < crazy2be> i suppose 02:26 < str1ngs> no the files get cached some are large ie linux kernel is 72mb gcc is 65mb 02:26 < crazy2be> so it downloads *then* processes? 02:26 < str1ngs> right now it downloads, stages, builds and installs 02:27 < str1ngs> under a configured prefix of course 02:27 < str1ngs> ie /opt/via 02:27 < str1ngs> it also changes the dynamic linker to linke to /opt/via 's glibc 02:27 < str1ngs> so its dont dependant on the system 02:28 < str1ngs> this way if you dont have gcc or make. you can grab a tarball and it will just work 02:28 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has quit [Remote host closed the connection] 02:30 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has joined #go-nuts 02:30 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has quit [Remote host closed the connection] 02:32 < crazy2be> what package do you guys use for log files? 02:33 < crazy2be> in this case it's a http log 02:33 < crazy2be> so i want something a little more complex than the log package 02:33 < str1ngs> crazy2be: log package for limited stuff 02:33 < crazy2be> like right now i'm doing {"Path":"/img/hover-tab.png","Source":"[::1]:36154","Referrer":"http://localhost:8080/","ReqTime":1300934092549358000,"Extra":"file not modified","TotalTime":0.388258} 02:34 < crazy2be> and each request has a line like that 02:34 < crazy2be> but i'm wondering how i would parse something like that 02:34 < crazy2be> i guess i could decode line-by-line 02:34 -!- perdiy [~mkhl@sxemacs/devel/perdix] has joined #go-nuts 02:34 < crazy2be> but that would be a pain 02:34 < str1ngs> this is also http://code.google.com/p/log4go/ 02:35 < crazy2be> cool 02:35 < str1ngs> http://godashboard.appspot.com/package 02:35 < crazy2be> although xml configuration is kinda silly 02:35 < crazy2be> json or yaml is better, imo 02:36 -!- perdix [~mkhl@sxemacs/devel/perdix] has quit [Ping timeout: 252 seconds] 02:36 < str1ngs> hey better then my config.go :P 02:36 < crazy2be> lol mine uses ini 02:36 < crazy2be> but without sections 02:36 < crazy2be> so just a bunch of lines that are name=value 02:40 -!- keithcascio [~keithcasc@nat/google/x-srjknbhndbzkbbqw] has quit [Quit: Leaving] 02:42 < crazy2be> hmm, 10000 requests gives me a 1.4MB log file 02:42 < crazy2be> i guess that's not bad 02:45 -!- waqas [~waqas@jaim.at] has left #go-nuts [] 02:46 < exch> is it really necessary to store the field names with every request? Seems like a lot of redundant info in a file. 02:46 < exch> Just print the relevant bits in a fixed format. And if you must specify the format explicitely, add the format specifier as the first line in the logfile instead of each request 03:01 -!- PJRobins [~quassel@174-20-86-139.mpls.qwest.net] has joined #go-nuts 03:03 -!- PJRobins [~quassel@174-20-86-139.mpls.qwest.net] has quit [Remote host closed the connection] 03:15 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has quit [Remote host closed the connection] 03:22 < steven> man.. cat sed "awk"? bash cat, kill cat, cut cat tail, cut cat head, tar cat! yes, touch cat, make cat unzip! more! ...... wait, whoami?! ... less!!! 03:23 < Namegduf> I've had a much less interesting evening than you, apparantly. 03:24 -!- crazy2be [~crazy2be@d209-89-248-73.abhsia.telus.net] has quit [Ping timeout: 250 seconds] 03:24 -!- pingveno [~pingveno@c-98-246-133-8.hsd1.or.comcast.net] has quit [Ping timeout: 252 seconds] 03:25 < exch> poetry <3 03:25 < steven> haha 03:25 < steven> all commands in either /bin or /usr/bin locally 03:26 < niemeyer> Not to mention fsck 03:26 -!- pingveno [~pingveno@c-98-246-133-8.hsd1.or.comcast.net] has joined #go-nuts 03:27 < steven> hahahah 03:27 < steven> nice 03:27 < str1ngs> wonder you have a cat left :P 03:31 < Archwyrm> skelterjohn: I have actually been thinking about using gb's makefile generation for building ghack to produce the protobuf code. :) 03:32 < Archwyrm> skelterjohn: Also, it is somewhat of a hack implementation because the first client in the client/server architecture uses ncurses. Once the whole arch is more advanced, there will likely be a name change. 03:32 < Archwyrm> (uses ncurses and features hack/rogue-like gameplay) 03:32 < skelterjohn> heh, cool 03:32 < skelterjohn> wow, apropos of a comment i made two days ago 03:33 < skelterjohn> at least 03:33 < skelterjohn> :) 03:33 < Archwyrm> :) 03:33 < Archwyrm> Yes 03:33 < Archwyrm> Just got back from a trip where I had limited net access. 03:34 < skelterjohn> i had some trouble getting protobuf installed 03:35 < skelterjohn> it hung on ./configure 03:35 < skelterjohn> so i was unable to actually build ghack 03:37 < steven> <3 ./configure 03:37 < Archwyrm> Ah.. I'm using a distro supplied package here. 03:37 < Archwyrm> Yeah.. ;( 03:37 < steven> what OS are you all on and why do you like it? 03:37 < str1ngs> steven: archlinux but not for much longer :P 03:37 < Archwyrm> Arch Linux. Simplicity. 03:38 < str1ngs> I'm going indy 03:38 < steven> str1ngs: why not 03:38 < str1ngs> steven: I've been using archlinux since the Judd days it gone down hill alot 03:38 < str1ngs> now I'm rolling my own 03:38 < steven> hows it gone downhill? 03:39 < str1ngs> put it this way took 4 months to get a patch for /usr/local/bin to be added to the default path 03:39 < Archwyrm> :o 03:40 < steven> well thats not so bad 03:40 < str1ngs> it was to the blind user that needed it 03:40 < steven> /usr/local didnt even exist on my OS until i installed homebrew 03:41 < str1ngs> pretty sure /usr/local is standard on OSX 03:41 < steven> maybe. 03:41 < Archwyrm> I came from Slackware about two years ago and that is a bit like rolling your own sometimes. Arch has saved me quite a bit of time. 03:41 < Archwyrm> Any decent install script makes parent directories anyway. 03:42 < Archwyrm> Or any decent install(1) for that matter, heh. 03:42 < str1ngs> dont use ./configure on archlinux you'll get flamed 03:43 < steven> i have no idea what that does. 03:43 < str1ngs> autoconf tools 03:43 < steven> im new to unix.. started with mac os x a few years ago, slowly getting my feet wet 03:43 < Archwyrm> I make packages for anything that I want to install. Old habit from Slackware but Arch makes it so much easier. 03:44 -!- shvntr [~shvntr@116.26.129.194] has joined #go-nuts 03:45 < str1ngs> Archwyrm: in some regards yes but if you need to make a custom core package and track archlinux changes. the process is not transparent 03:45 < str1ngs> ie when you look at there svn commits its all gibberish 03:46 < Archwyrm> Hmm, I see. I haven't been in that situation. 03:46 < str1ngs> they have a changelog system but none of the the developers use it 03:47 -!- ajstarks [~ajstarks@pool-98-109-198-180.nwrknj.fios.verizon.net] has quit [Quit: ajstarks] 03:47 < str1ngs> for example I have about 20 odd patches I track. because getting them committed is an up hill battle. so I dont even bother anymore 03:47 < Archwyrm> Ah :( 03:48 < str1ngs> here's a good example godoc and goinstall from Community package is broken 03:49 < Archwyrm> Installing go packages at this point is almost useless, IMHO. Especially if you are a developer. 03:49 < str1ngs> fair enough but godoc? 03:49 < Archwyrm> These are separate packages, not just part of one go package? 03:50 < str1ngs> its all one package 03:50 < str1ngs> pacman -Ss go 03:50 -!- nettok [~quassel@200.119.160.242] has quit [Ping timeout: 248 seconds] 03:50 < Archwyrm> I did that and I get (predictably) a lot of unrelated stuff. :) 03:51 < Archwyrm> I see `pacman -Si go` though. 03:52 < str1ngs> anyways my point is . that its not worth investing the time to file bugs, when all they do is flame 03:52 < str1ngs> there so bogged down with meme and flaming nothing gets done. 03:53 < Archwyrm> Although hopefully with the weekly/monthly releases and being able to goinstall libs locally packages will become more viable. 03:53 < Archwyrm> Oh 03:54 < str1ngs> aye 03:54 < Archwyrm> I do have a bug to report but I haven't gotten around to it. protobuf and protobuf-python packages are different releases and are not compatible. 03:54 -!- Viriix [~joseph@c-67-169-172-251.hsd1.ca.comcast.net] has joined #go-nuts 03:55 < str1ngs> dawn your fire retardant gear :P 03:55 < Archwyrm> But between abs and makepkg, I fixed that so quickly and went on my merry coding way that I haven't had time to notify anyone about it. 03:55 < Archwyrm> :( 03:55 < steven> guys, 03:55 < steven> how would you go about solving this problem? 03:55 < Archwyrm> I should hope not. It is such a plainly obvious error. 03:56 < Archwyrm> One day I will get tired of pacman complaining that protobuf-python is a newer version than what is in the repos. ;) 03:56 < skelterjohn> str1ngs has the best typos :) 03:56 < skelterjohn> took me a while to translate "dawn" correctly 03:56 < str1ngs> I do sorry 03:56 < steven> you want to implement an "event-handler" that handles at least 0 types of events, and at most every type of event. 03:56 < Archwyrm> Hehe, somehow I didn't even notice that. 03:57 < steven> but in Go, interfaces demand that every single method must exist on an object, theres no concept of "optional methods" 03:57 < str1ngs> I have astigmatism so that does not help 03:57 < skelterjohn> have a bunch of different interfaces 03:57 < skelterjohn> one for each method 03:57 < skelterjohn> and keep track of the handler in an interface{} 03:57 < skelterjohn> and type assert it to the different method interfaces 03:57 < steven> hmm, but then i lose compile-time checking 03:57 < steven> im trying to avoid that. 03:57 < skelterjohn> that might not work, though 03:58 < steven> i have a current implementation thats pretty much ripping off the concept of inheritance 03:58 < steven> and it feels un-idiomatic in Go 03:58 < steven> here: 03:58 < skelterjohn> compositing a default implementation? 03:58 < steven> yes 03:58 < steven> the default impl contains a bunch of no-ops 03:59 < skelterjohn> yeah, that's certainly a way to do it 03:59 < steven> it doesnt feel idiomatic though 03:59 < skelterjohn> how is that better than the interface method i suggested? 03:59 < steven> but it keeps all my compile-time checking in place. 03:59 < steven> whereas your method relies on runtime chekcing 03:59 < skelterjohn> your method calls empty functions 03:59 < skelterjohn> it's not like the program dies when the type assert fails 04:00 < skelterjohn> it's just normal behavior 04:00 < steven> hmm.. 04:00 < steven> but it doesnt catch errors such as passing the wrong object to that function, for instance 04:00 < steven> by accident 04:00 < steven> btw, heres my current hack: 04:00 < skelterjohn> well, if you have the function take a param of type DefaultImpl 04:00 < steven> https://github.com/sdegutis/go-ircbot/blob/master/bot.go#L66-80 04:00 < steven> https://github.com/sdegutis/go-ircbot/blob/master/main.go#L8-24 04:00 < skelterjohn> then it won't work, because it will not keep the types for the SpecImpl 04:01 < steven> ooh i like that. 04:01 < steven> kinda 04:01 < skelterjohn> like what 04:01 < steven> wait 04:01 < steven> nm 04:02 < skelterjohn> oh well, i suppose if your function takes a param that is an interface with all the methods you want 04:02 < skelterjohn> then it would work fine 04:02 < steven> i just want to keep as much compile-time checking as possible, without being un-idiomatic 04:02 < skelterjohn> compile-time checking is a tool, not a goal 04:02 < skelterjohn> it is not an end in and of itself 04:02 < steven> one of my goals is safety 04:02 < steven> im coming from ruby 04:03 < skelterjohn> no - your goals are to make easy to read and maintain code 04:03 < skelterjohn> safety is one thing that helps that goal 04:03 < steven> and my dayjob is tracking down bugs caused by accidentally passing the wrong thing into a function 04:03 < steven> id like to practice avoiding that kind of stuff. this is a big way. 04:03 < skelterjohn> the composited default seems reasonable 04:04 < steven> not un-idiomatic? 04:04 < skelterjohn> though the fact that you need something pretending to be polymorphism makes me think you're working in too OO of a way 04:04 < steven> this is weird though: type NoopEventHandler int // doesnt matter what type it is 04:04 < steven> yeah i think so too 04:04 < skelterjohn> remember - don't spend time thinking about what your types should be and how they should relate to each other 04:05 < skelterjohn> just spend time thinking about the process that needs to happen to make things work 04:05 < steven> i like the idea of having multiple interfaces.. but then, i would need to pass the same object to multiple functions, or put it in multiple places in a struct, or something 04:05 < skelterjohn> maybe we can chat about it tomorrow - it's late and bedtime for me 04:06 < steven> although it might actually be a non-issue to just pass my handler into a struct in multiple values 04:06 < steven> ok cya 04:06 < steven> may god be with you brother <3 04:07 < str1ngs> skelterjohn: was it you that said the other day maps should be pointers? ie map[string]*string 04:07 < str1ngs> err shouldnt 04:07 < skelterjohn> i don't think so, str1ngs 04:07 < str1ngs> ah ok 04:07 < skelterjohn> map[string]*string certainly has its use 04:07 < skelterjohn> but map[string]string does as well 04:07 < str1ngs> I really suck with pointers. 04:08 < skelterjohn> string itself is a pointer type, under the hood 04:08 < steven> str1ngs: pointers are reeeally simple once it clicks in your brain 04:08 < steven> and fun! 04:08 < skelterjohn> so passing around pointers to strings doesn't make anything more efficient 04:08 < steven> thats one of the reasons i still like C even though i have things like Ruby 04:08 < str1ngs> steven: go makes its very easy. its C that I cant stand 04:08 < steven> nah its just as fun in C 04:08 < str1ngs> ******foo 04:08 < steven> the problem with pointers in C isnt pointers, its memory management 04:08 < str1ngs> wtf! 04:08 < str1ngs> true 04:08 < steven> thats available in Go too, isnt it? 04:09 < steven> infinite indirection? 04:09 < str1ngs> dunno I was kidding around 04:09 < steven> k 04:10 < str1ngs> steven: how do you like go compared to ruby? 04:10 < str1ngs> onlything I miss from ruby is blocks 04:11 < yebyen> i just wrote a sql query that is parameterized and quoted input 04:11 < steven> i really love ruby 04:11 -!- plainhao [~plainhao@208.75.85.237] has quit [Quit: plainhao] 04:11 < steven> i also really love go 04:11 < steven> they're like apples and oranges 04:11 < yebyen> and the ' character produces a fail 04:11 < str1ngs> yebyen: use backticks to escape everything 04:11 < yebyen> res = dbh.query("INSERT INTO testtable (testrecord1, testrecord2)" + " VALUES (?, ?)", "string %'", 'zxcvqwer'); 04:12 < yebyen> str1ngs: it's not go 04:12 < yebyen> i was just surprised 04:12 < yebyen> and nobody else to tell since nobody uses ferite 04:12 < str1ngs> an nvm mind me then 04:12 < yebyen> that looks safe though, ne? 04:13 -!- rejb [~rejb@unaffiliated/rejb] has quit [Ping timeout: 246 seconds] 04:13 < steven> ruby's got some awesome features inherited from list and from smalltalk. i just dont like the fact that its not type-safe 04:13 < steven> thats one thing i love about Go 04:13 < steven> and once Go gets generics, ill be blissful 04:13 < steven> any day now 04:13 < str1ngs> steven: ya I like that to. and the implied types are great so much better then java and c# in that regards 04:14 < steven> yeah i love Go's type inference 04:14 < steven> esp compared to ObjC #sigh 04:15 < str1ngs> have played with ObjC 04:15 < str1ngs> havent* 04:16 < str1ngs> something's I dont like about go. but I think it will get better. you need alot of boiler plate 04:16 < str1ngs> ie exec.Run compared to system 04:16 < steven> objc isnt interesting unless you want to create a gui on mac or iphone 04:17 < str1ngs> I run linux on my mac .. need I say more :P 04:17 < steven> ha 04:17 < steven> silly you 04:17 < steven> ;) 04:17 < str1ngs> its win I tell you 04:17 < steven> k 04:17 < str1ngs> 5$ for xcode 4.0 04:17 < str1ngs> mind you not sure what version of gcc that ships with 04:18 < steven> clang + llvm 04:18 < steven> ;) 04:18 < str1ngs> ya I heard they were moving to clang 04:18 < steven> i like the idea of having EventHandlers actually be a struct containing a bunch of interfaces (one per event-that-can-be-handled), and a single object that conforms to all of those interfaces can just be passed as every field in that struct 04:18 < str1ngs> I assume llvm can run without gcc on osx? 04:19 < steven> but, then you have a lot of this: EventHandler{ myHandler, myHandler, myHandler, myHandler, myHandler } 04:19 < steven> etc 04:19 < steven> which is uncool 04:19 < steven> str1ngs: probably 04:19 < steven> i cant think of a better way to do this though 04:20 < str1ngs> I'm not much help with interfaces :( 04:20 < str1ngs> I need to use them more though 04:20 < steven> only one other option i can think of, and im starting to think it might be a viable option: 04:20 < str1ngs> post to the ML 04:20 < steven> pass a single function, with the signature func(event Event, args []string) 04:20 < str1ngs> I think thats what I'm going to do about my Plan registration thing 04:20 < steven> yeah i should probably do that. 04:22 < str1ngs> I assume you used interfaces in gorm? 04:23 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Read error: Operation timed out] 04:23 < steven> plenty 04:23 < steven> :) 04:24 < str1ngs> I'm confident your web framework will be light. you use sqlite as your for db so I'm a happy camper 04:24 < str1ngs> first db* 04:28 < yebyen> i just wrote sqlite support into ferite today 04:28 < yebyen> then discovered that parameterized queries are not worth a damn 04:32 -!- SirPlus [~dsc@78.100.171.45] has quit [Read error: Connection reset by peer] 04:33 < steven> :) 04:33 < steven> str1ngs: im sure GoRM is unacceptably slow though ;) 04:34 < steven> str1ngs: i took your suggestion http://groups.google.com/group/golang-nuts/browse_thread/thread/6a29692249f75eb7 04:34 < steven> (hoping mayb someone like iant or adg looks at it) 04:35 < str1ngs> sorry was afk 04:38 < str1ngs> ahh might have a solution 04:38 < steven> oh? 04:39 * steven is eager to hear about it 04:39 < str1ngs> switch type checking 04:39 < str1ngs> https://github.com/str1ngs/gowm/blob/master/gowm.go#L111 04:40 < steven> thats the same as type assertion in this case 04:40 < str1ngs> messy toy project but you will get the idia 04:40 < steven> ie, losing compile-time checking 04:41 -!- edsrzf [~chickench@122-61-221-144.jetstream.xtra.co.nz] has joined #go-nuts 04:42 < str1ngs> check the xdg package though. 04:42 < str1ngs> its somewhat machine generated but it might give you some ideas on even handling 04:43 < str1ngs> event* 04:46 < steven> ok 04:47 < str1ngs> as far as I can see all the events are structs and then use type assert them in a loop 04:48 < steven> stil same problem :/ 04:49 -!- jesusaurus [jesusaur@firefly.cat.pdx.edu] has left #go-nuts ["WeeChat 0.3.2"] 04:50 < str1ngs> Event though is interface{} 04:50 < str1ngs> I think your to scared of using inteface{} :P 04:52 -!- kingfishr [~kingfishr@c-98-207-87-183.hsd1.ca.comcast.net] has joined #go-nuts 04:52 < steven> i think you arent scared enough ;) 04:53 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts 04:53 < steven> although im starting to think a single function with a switch-on-event should suffice. 04:53 < str1ngs> part of the problem with this is you need to know the methods and field for the struct 04:54 < str1ngs> but I think that's really what you want 04:55 < plexdev> http://is.gd/bAh1Qu by [Rob Pike] in go/src/pkg/gob/ -- gob: remove another allocation. 04:57 < steven> "The zero value for Buffer is an empty buffer ready to use." 04:57 < steven> i love that feature in Go 04:57 < steven> i love avoiding initializers. 04:57 < steven> <3 04:59 < steven> so, i like the idea of a event-switch, inside a generic HandleEvent(event string, args []string) function 04:59 < steven> but then for each event-case, ill have to do something like this: channel, username := args[0], args[1] 04:59 < steven> and thats pretty ugly.. is there a better way to do this? 05:00 < str1ngs> what do bool's init to? 05:00 < str1ngs> been meaning to check 05:00 -!- zozoR [~Morten@56344966.rev.stofanet.dk] has joined #go-nuts 05:01 < steven> str1ngs: false? 05:01 < steven> i assume thats the 0 value 05:02 < |Craig|> steven: set up a multiplexer like the http handler uses, then regester different event handlers with it 05:02 < str1ngs> steven: yep false 05:02 < |Craig|> use a map, string to function to get what to call for each event string 05:03 < str1ngs> fmt.Printf("%T = %v",t.isIt,t.isIt) ftw 05:03 < steven> |Craig|: hmm i like that 05:03 < steven> and since im the one creating events, i can even define events as constants, rather than strings, for extra compile-time checking 05:04 < steven> woot. 05:05 < |Craig|> passing functions around is a pretty good solution to a lot of problems 05:05 * steven <3 FP 05:06 < str1ngs> oh thats nice 05:07 < str1ngs> so map[string]func() something like that? 05:07 < steven> in a const( ... ) on multiple lines, if you want them all to increment, can you just define the first const as iota, and omit the definition of every one after it? 05:07 < str1ngs> iota ya 05:08 < str1ngs> you can also add addiotional stuff to iota to say multiples of two's 05:08 < str1ngs> let me find the url 05:08 < str1ngs> steven: http://golang.org/doc/effective_go.html#constants 05:08 < steven> oooh, map[EventType]func() 05:09 < steven> to ensure nobody just passes mymap[1] 05:09 < steven> but rather mymap[SomeEvent] 05:09 < steven> :D 05:10 < str1ngs> did you know you can test if a method exists? 05:11 < steven> yes. 05:11 < steven> in reflect 05:11 < str1ngs> if foo.Method != nil 05:12 < steven> is there a shorter way to do this? type EventType int; const ( UserDidJoinEvent EventType = iota; UserDidQuitEvent EventType = iota ) 05:12 -!- perdiy [~mkhl@sxemacs/devel/perdix] has quit [Remote host closed the connection] 05:12 < steven> str1ngs: oh yeah, that too. 05:12 < steven> str1ngs: that just returns a function pointer 05:12 < steven> afaik 05:12 < steven> another thing yo ucan do is: fnPtr := FooType.Method 05:13 < steven> suddenly, func (f FooType) Method(a int), becomes func(f FooType, a int), and you have a function pointer to it 05:13 < steven> <3 05:13 < str1ngs> think you can do cont ( foo1 = itoa; foo2; foo3 ) 05:14 < str1ngs> minus my syntax error 05:14 < steven> i can, but then i lose the type information for it 05:14 -!- tensai_cirno [~cirno@79.104.6.233] has joined #go-nuts 05:14 < steven> ie, foo1 becomes int i think 05:14 < steven> or uint 05:14 < steven> instead of EventType 05:14 < str1ngs> ah sorry I see what you mean 05:15 < steven> oh sweet this works 05:15 < steven> type EventType int 05:15 < steven> const ( UserDidJoinEvent EventType = iota UserDidQuitEvent 05:15 < steven> ) 05:15 < str1ngs> so I was right? 05:16 < steven> oops, i mean, type EventType int; const ( UserDidJoinEvent EventType = iota; UserDidQuitEvent ) 05:16 < steven> nope 05:16 < steven> you can omit the type after the first one 05:16 < steven> :) 05:17 < str1ngs> ah gotcha 05:17 < str1ngs> so Eventype = iota , gets carried down 05:18 < str1ngs> I'm like one of those people that teaches by bad example :P 05:18 < steven> yep 05:18 < steven> <3 05:18 < steven> hahaha 05:18 < steven> nah 05:18 < str1ngs> see that guy.. dont do what he does 05:18 < steven> ha! 05:18 < steven> thats me 05:18 < steven> all the way 05:19 < str1ngs> the problem with me is I was not privileged with higher education :( 05:21 < str1ngs> what editor do you use on mac? macvim? 05:21 < nsf> hehe, does anyone know why Go uses unary ^ instead of unary ~ as C does? 05:21 < steven> WHOA 05:22 < steven> btw str1ngs i used to use vim, then macvim, now textmate 05:22 < steven> anyway, WHOA! 05:22 < steven> i just found out that there is a slight implicit conversion! 05:22 < steven> for functions 05:22 < str1ngs> steven: I only use vim. one reason I don like mac there terminal ansi colors suck. unless you hack Terminal 05:24 < str1ngs> steven: can you get vim binding for textmate I'm lost without them 05:24 < steven> whoa 05:24 < steven> here: 05:24 < steven> https://gist.github.com/884620 05:25 < str1ngs> meh I"ll just stick with macvim when I use osx 05:25 < steven> str1ngs: i was writing my own terminal for a while 05:25 < steven> until i realized vt100 emulation requires learning more than 0 things. 05:25 < steven> but i got the basics working.. https://github.com/sdegutis/SteveTerm 05:26 < steven> str1ngs: i dont think you can get vim bindings for textmate no. but the auto-completion thingies textmate has in its bundles balances it out. 05:26 < str1ngs> rxvt runs on mac but it renders slow. or I could just use my .Xdefaults 05:26 < steven> plus theres a few emacs-type navigational bindings which i use in terminal anyway so im fine 05:26 < str1ngs> emacs bindings.. no thanks 05:26 < steven> like ^P, ^N, ^B, ^F, ^A, ^E, etc 05:27 < steven> aaaanway 05:27 < str1ngs> I even have readline use vi bindnings 05:27 < steven> check out my GIST! 05:27 < steven> https://gist.github.com/884620 05:27 < steven> implicit type conversion! i had no idea! 05:27 < str1ngs> ya you can have func typs and struct fields to 05:28 < str1ngs> I dont get your implied part though 05:28 < str1ngs> nothings implied there 05:28 < steven> the types are converted 05:28 < steven> inside TakeMyFunction, f is type MyFunctionType 05:29 < steven> inside main, it's type func(string) 05:29 < str1ngs> right but thats the function type so nothing is implied 05:29 < steven> i never had to convert it manually like you always have to 05:30 < str1ngs> because everythin is a func(string) 05:30 < str1ngs> which is the typ 05:30 < str1ngs> type* 05:31 < steven> BUT 05:31 < steven> this fails: 05:31 < steven> https://gist.github.com/884627 05:31 < steven> but if you call TakeMyInt(2) direclty, it passes. 05:32 < steven> this stuff is freaky! 05:32 < steven> im so confused 05:32 < str1ngs> ah 05:32 < str1ngs> I see what you mean 05:33 < str1ngs> custom types still confuse me some 05:33 -!- sjd [~sjd@204-195-89-40.wavecable.com] has joined #go-nuts 05:33 < steven> yeah, i dont understand why/when its implicitly converted 05:33 < steven> reading http://golang.org/doc/go_spec.html#Conversions now 05:33 < str1ngs> I wish I could figure out how to do type Foo *C.foo 05:33 < edsrzf> You can convert between a named and an unnamed type implicitly as long as they have the same underlying type. 05:33 < steven> str1ngs: type Foo (*C).foo 05:34 < steven> edsrzf: to how many levels? one? 05:34 < str1ngs> steven: really that really help with my libgit2 bindings 05:34 < edsrzf> What do you mean? 05:34 < steven> str1ngs: probaly, try it and see 05:35 < str1ngs> steven: aye save me haveing to wrap *C.foo all the time 05:35 < steven> edsrzf: they might have the same underlying type going several layers deep 05:35 < steven> str1ngs: oh that might not work. try it and see. 05:35 < steven> edsrzf: type a int; type b a; type c b; 05:35 < str1ngs> checking now 05:35 < steven> edsrzf: can c convert to int and vice versa? 05:35 < edsrzf> Oh, types don't layer. 05:36 < edsrzf> All those types have the same underlying type. 05:36 < edsrzf> But note that int is considered a named type. 05:36 < steven> oh, so the literal 2 is an unnamed type? 05:36 -!- vsayer [~vivek@2001:470:1f04:1a6b:21a:6bff:fe35:d2a5] has quit [Quit: Leaving] 05:37 < steven> wait, that only explains this recent gist, not the first one with the functions.. 05:37 < str1ngs> esh thats not even valid syntax 05:37 < edsrzf> Constants are separate. It's better not to talk about them in this topic. 05:37 < steven> haha yeah i didnt realize C was a package 05:37 < steven> sorry str1ngs 05:37 -!- lmoura [~lauromour@187.113.121.19] has quit [Ping timeout: 255 seconds] 05:37 < steven> i thoguht i twas a ptr 05:37 < str1ngs> steven: it is a pointer but a C pointer 05:38 < edsrzf> steven: the gist with the functions is explained by that rule. 05:38 -!- lmoura [~lauromour@187.113.121.19] has joined #go-nuts 05:39 < edsrzf> steven: func(s string) is an unnamed type. 05:39 < edsrzf> So it can be implicitly converted to MyFunctionType, which is a named type with the same underlying type. 05:39 < steven> edsrzf: ooooh. 05:39 < str1ngs> type File C.FILE 05:39 < steven> so why is func(s string) not namd, but int is? 05:40 < steven> i guess i dont understand what "named" means in this context in that case. 05:40 < str1ngs> is what they use in misc/cgo I play with that 05:40 < edsrzf> Named means that the type is bound to an identifier. 05:40 < str1ngs> basically int is like a named go type 05:41 -!- Viriix [~joseph@c-67-169-172-251.hsd1.ca.comcast.net] has left #go-nuts ["Leaving"] 05:41 < str1ngs> func(s string) is something you made. not a go type 05:41 < edsrzf> Just think of it as if there's some type that int represents that's not exposed through the language in any other way. 05:41 < steven> also, i need to figure out a cleaner way than this: 05:41 < steven> https://github.com/sdegutis/go-ircbot/blob/master/main.go#L11 05:41 < nsf> steven: everything that is composite isn't named 05:41 < edsrzf> The language treats int as if it was declared as "type int [something]", just at a higher scope than package scope. 05:41 < steven> edsrzf: oh i see. that makes it obvious now. 05:42 < steven> thanks 05:42 < str1ngs> steven: arg ...interface{} 05:42 < nsf> steven: []int [10]int *int 'chan int' map[int]int 'struct {a int;}' 'func(int)int' 'interface { Int()int; }' 05:42 < steven> that doesnt change it in the inside str1ngs 05:42 < steven> only the outside 05:42 < nsf> these all are not named :) 05:42 < steven> ie, myHandler(e, arg1, arg2) 05:43 < steven> when all i care about right now is how im using it inside myHandler, so i dont have to decalre it so ugly 05:43 < str1ngs> that will give you arg1 and arg2 even arg3 05:43 -!- perdix [~mkhl@sxemacs/devel/perdix] has joined #go-nuts 05:43 < str1ngs> or arg ...string 05:44 < str1ngs> think that would work 05:44 < steven> still missing the point 05:44 < steven> the problem is unpacking them 05:44 < steven> not packing them 05:44 -!- itrekkie [~itrekkie@ip72-201-208-165.ph.ph.cox.net] has quit [Quit: itrekkie] 05:45 < str1ngs> Sprintf 05:45 < str1ngs> but ya let me figure out how to unpack. you right would be cleaner 05:45 -!- fabled [~fabled@mail.fi.jw.org] has joined #go-nuts 05:48 < str1ngs> there []interface{} so you can loop through or use the array index 05:49 < str1ngs> os Sprintf 05:49 < str1ngs> or* 05:50 -!- gid [~gid@220-253-20-152.VIC.netspace.net.au] has joined #go-nuts 05:50 < str1ngs> oh strang no that wont work 05:51 -!- ExtraSpice [XtraSpice@88.118.35.153] has joined #go-nuts 05:51 < nsf> I don't understand, every language on the internet uses ~ for unary bitwise NOT 05:51 < nsf> why Go uses ^ 05:51 < nsf> :\ 05:51 < str1ngs> steven:split 05:51 < str1ngs> steven: there []string's 05:53 < str1ngs> split is the wrong term you need something like explode 05:53 < nsf> python, C/C++, Java, everything uses ~ as NOT :\ 05:53 < nsf> it must be a bad joke of some kind 05:57 < str1ngs> steven: ya I'm not sure. and technically there slices 05:57 < nsf> also, Go has bit clear binary op, wtf.. &^ 05:58 < nsf> what's wrong with C's "flags & ~bit" 05:58 < nsf> :\ 05:58 -!- ptrb [~peter@69.164.208.33] has quit [Read error: Operation timed out] 05:58 -!- ptrb [~peter@archimedes.bourgon.org] has joined #go-nuts 05:58 < nsf> ah, a &^= b 05:58 < nsf> ok 05:59 < nsf> but on the other hand it's the same as 05:59 < nsf> a &= ~b 06:00 < nsf> some decisions are a totally wtf to me 06:00 < nsf> : 06:00 < nsf> :\ 06:02 < nsf> a &= ~(1 << b); 06:02 < nsf> maybe they think it looks ugly 06:11 < exch> https://groups.google.com/forum/#!topic/golang-dev/wc8dyzWrP4E huzzah 06:12 < nsf> "build the entire Go standard library, with the exception of runtime and runtime/cgo (we believe that goinstall can already build everything except these two)" 06:12 < nsf> so it will be useless 06:13 < exch> there's a lot more in that document 06:13 < nsf> if it can't handle 'runtime' 06:14 < exch> all your code is called runtime? 06:14 < nsf> yeah, but I don't like their passion for reinventing tools 06:14 < nsf> exch: no, I mean it can't handle runtime package 06:14 < nsf> which has a non-trivial build process 06:15 < nsf> I'm sure goinstall will never be able to handle gocode build process as well 06:15 < exch> probably 06:15 < nsf> because it's a simple, but non-trivial two step build 06:15 < nsf> I'm building codegen, generating code and then building gocode 06:15 < exch> I have stuff which requires conditional includes to. goinstall currently fails on those 06:16 < nsf> goinstall tries to replace existing distribution tools, but not hard enough 06:16 < nsf> and also it wants to replace make 06:16 < nsf> O_o 06:16 < exch> I'm all for removing dependencies on external tools 06:16 < exch> specially make 06:16 < exch> but it shuold be done properly 06:17 < nsf> make is a solid tool, you can't easily replace it 06:17 < exch> Right now, everyone uses third party make tools, which makes distribution of code a pain in the ass 06:17 < str1ngs> these changes to gomake are nice. DESTDIR would be handy though 06:18 < str1ngs> I dont think GOPATH would handle that 06:18 < nsf> str1ngs: I've proposed to add DESTDIR to their make files like a year ago 06:18 < nsf> they just don't understand that 06:18 < nsf> for some reason 06:18 -!- zozoR [~Morten@56344966.rev.stofanet.dk] has quit [Remote host closed the connection] 06:19 < str1ngs> well its hard to distro package something without it 06:19 < nsf> http://groups.google.com/group/golang-nuts/browse_thread/thread/d870fff2a4cb4edc/9d292e03b1d5c0a9 06:19 < nsf> it was actually more than a year ago :) 06:19 < nsf> and at that time it was a one liner change 06:19 < str1ngs> well I dont think its an issue yet. 06:19 < nsf> which doesn't break anything 06:20 < nsf> not sure about now 06:20 < str1ngs> I like Makefiles. but once this is done there wont be a dependacy on make which it good 06:20 < str1ngs> makes go almost self hosting 06:21 < nsf> I don't think Go will be able to build itself without make 06:21 < nsf> and many projects will require make 06:21 < str1ngs> aye some parts but its move's towards self hosting 06:21 < str1ngs> still need gcc of cource 06:21 < str1ngs> course* 06:24 < str1ngs> ah GOPATH will handle DESTDIR 06:26 < nsf> I don't like that idea 06:26 < nsf> of reinventing stuff 06:26 < str1ngs> GOPATH=./pkghere:~/myshit 06:27 < str1ngs> if the package is not found it will put it in pkghere. then you can distro package . but there is problem. if its found somewhere else it will package there instead 06:28 < str1ngs> problem is people dont like Makefile. even though the go templates are trivial imo 06:28 -!- tensai_cirno [~cirno@79.104.6.233] has quit [Quit: Leaving] 06:28 < nsf> I want my libs in /usr/lib 06:29 < nsf> and Go doesn't care about FHS 06:29 < str1ngs> python and ruby dont do that? 06:29 < nsf> str1ngs: uhm? 06:29 < str1ngs> where does python put them /usr/lib/python/site-blah ? 06:29 < nsf> python's libs are in /usr/lib/python 06:29 < str1ngs> ok ya thought so 06:30 < str1ngs> ok so how does that translate in go terms? 06:30 < str1ngs> pkg 06:30 < nsf> python's libs are in /usr/lib/go/$GOOS_$GOARCH 06:30 < nsf> oops 06:30 < nsf> editing failure 06:30 -!- sjd [~sjd@204-195-89-40.wavecable.com] has quit [Quit: sjd] 06:30 < nsf> just /usr/lib/go/$GOOS_$GOARCH 06:30 < str1ngs> ok thats fine 06:30 < str1ngs> the problem is packaging 06:31 < nsf> DESTDIR 06:31 < str1ngs> right 06:31 < nsf> it was defined by GNU years ago 06:31 < nsf> at most linux people know what it is 06:31 < nsf> especially if they deal with packaging 06:31 < str1ngs> most people that know packaging 06:31 < nsf> yeah 06:32 < str1ngs> thing is go is kinda like its only little fs 06:32 < str1ngs> which is nice in some regards ie ~/go 06:32 < nsf> it's ok for development stage 06:32 < nsf> but it's a hostile behaviour regarding community integration 06:33 < str1ngs> when it comes to linux and FHS ya 06:33 < str1ngs> taken awhile to get the big distro's to use FHS even 06:33 < nsf> I think the same about many other project that like to install themselves in /opt 06:33 < nsf> projects* 06:33 < str1ngs> well /opts good for some stuff though. 06:33 < str1ngs> but I hear ya 06:34 < nsf> for stuff that doesn't care about FHS integration 06:34 < nsf> like plan9port 06:34 < nsf> :) 06:34 < nsf> haha 06:34 < str1ngs> lol 06:34 < Namegduf> Installing into ~/go is okay, the problem is assuming they can write to the installation. 06:35 < Namegduf> I heard there was some work for that. 06:35 < str1ngs> most cases they cant 06:35 < str1ngs> GOPATH should cover that 06:35 < str1ngs> but for distro packaging DESTDIR is handy or you have to manually use install 06:36 < str1ngs> for disto packaging /usr/lib/go is writeable just not directly its wrapped around fakeroot when you package 06:37 < nsf> another thing I don't like in Go 06:37 < nsf> is it's implicit configuration 06:37 < nsf> when you install it into a ~/go 06:37 < Namegduf> Implicit configuration? 06:37 < nsf> and then moving to /opt/go 06:37 < nsf> it won't work 06:37 < str1ngs> no different the gcc 06:37 < Namegduf> You can't install, then move, most things. 06:37 < str1ngs> you try moving gcc lol 06:37 < Namegduf> Linux programs simply aren't usually relocatable. 06:37 < nsf> but all sane apps are configurable 06:38 < nsf> e.g. --prefix=/usr 06:38 < nsf> explicitly 06:38 < Namegduf> Right. 06:38 < str1ngs> go does that 06:38 < Namegduf> And that will install into /usr and then only work in /usr. 06:38 < nsf> you can say: I want to build it here, but then move it there 06:38 < str1ngs> GOROOT = --prefix= 06:38 < Namegduf> You can, although --prefix has nothing to do with that. 06:38 < nsf> Namegduf: --prefix is configuration 06:39 < str1ngs> so is GOROOT 06:39 < nsf> DESTDIR is destination for make install 06:39 < Namegduf> nsf: Configuration for something else. 06:39 < str1ngs> GOROOT_FINAL does that nsf 06:39 < Namegduf> Configuration of the install AND running prefix, not install separate to prefix. 06:39 < nsf> ok 06:39 < str1ngs> just not for packages 06:40 < str1ngs> ie you can distro package go . but not distro package ... packages 06:41 < Namegduf> Fake writing stuff will work anyway, it's just annoying. 06:41 < str1ngs> fake writing? 06:43 -!- kingfishr [~kingfishr@c-98-207-87-183.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 06:47 -!- niemeyer [~niemeyer@201-66-179-18.pltce701.dsl.brasiltelecom.net.br] has quit [Ping timeout: 255 seconds] 07:00 -!- dfc [~dfc@sydfibre2.atlassian.com] has quit [Ping timeout: 250 seconds] 07:11 -!- str1ngs [~strings@unaffiliated/str1ngs] has quit [Quit: WeeChat 0.3.0] 07:14 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has joined #go-nuts 07:14 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has left #go-nuts [] 07:19 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 07:20 -!- adu [~ajr@softbank220043138128.bbtec.net] has joined #go-nuts 07:32 -!- vsayer [~vivek@2001:470:1f04:1a6b:21a:6bff:fe35:d2a5] has joined #go-nuts 07:37 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|] 07:37 -!- wrtp [~rog@92.17.43.168] has joined #go-nuts 07:45 -!- tensorpudding [~user@99.148.205.193] has quit [Remote host closed the connection] 07:47 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:481f:ae8d:9db1:e94c] has joined #go-nuts 07:55 -!- rtharper [~tomh@unaffiliated/sioraiocht] has quit [Remote host closed the connection] 07:57 -!- skejoe [~skejoe@188.114.142.162] has joined #go-nuts 08:00 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-182-79.clienti.tiscali.it] has joined #go-nuts 08:02 -!- olegfink [~olegfink@ppp92-100-69-165.pppoe.avangarddsl.ru] has quit [Read error: Operation timed out] 08:03 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts 08:10 < Namegduf> steven: Are you the Steven Degutis on the mailing list? 08:18 -!- olegfink [~olegfink@ppp92-100-117-112.pppoe.avangarddsl.ru] has joined #go-nuts 08:24 -!- dju [dju@fsf/member/dju] has joined #go-nuts 08:25 -!- dju [dju@fsf/member/dju] has quit [Max SendQ exceeded] 08:26 -!- dju [dju@fsf/member/dju] has joined #go-nuts 08:29 -!- aho [~nya@fuld-590c78ab.pool.mediaWays.net] has quit [Quit: EXEC_over.METHOD_SUBLIMATION] 08:32 -!- fzzbt [~jahman@melkinpaasi.cs.helsinki.fi] has joined #go-nuts 08:33 -!- rlab [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 08:41 -!- Niedar [~bleh@ip68-99-166-222.hr.hr.cox.net] has quit [Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )] 08:42 -!- Niedar [~bleh@ip68-99-166-222.hr.hr.cox.net] has joined #go-nuts 08:46 < Namegduf> Replied on the mailing list anyways, I'd not noticed how many hours it'd been, I'm used to 11 messages indicating a far shorter period. 09:12 -!- napsy [~luka@193.2.66.6] has joined #go-nuts 09:18 -!- ronnyy [~quassel@p4FF1C577.dip0.t-ipconnect.de] has joined #go-nuts 09:21 -!- stalled [~stalled@unaffiliated/stalled] has quit [Ping timeout: 252 seconds] 09:25 -!- enferex [~enferex@users.757.org] has quit [Ping timeout: 252 seconds] 09:26 -!- Niedar [~bleh@ip68-99-166-222.hr.hr.cox.net] has quit [Ping timeout: 260 seconds] 09:28 -!- shvntr [~shvntr@116.26.129.194] has quit [Ping timeout: 240 seconds] 09:30 -!- tvw [~tv@212.79.9.150] has joined #go-nuts 09:30 -!- stalled [~stalled@unaffiliated/stalled] has joined #go-nuts 09:34 -!- shvntr [~shvntr@116.26.129.194] has joined #go-nuts 09:42 -!- shvntr [~shvntr@116.26.129.194] has quit [Ping timeout: 240 seconds] 09:44 -!- shvntr [~shvntr@116.26.129.194] has joined #go-nuts 09:55 -!- olegfink [~olegfink@ppp92-100-117-112.pppoe.avangarddsl.ru] has quit [Ping timeout: 240 seconds] 10:15 -!- Niedar [~bleh@ip68-99-166-222.hr.hr.cox.net] has joined #go-nuts 10:15 -!- enferex [~enferex@users.757.org] has joined #go-nuts 10:18 -!- edsrzf [~chickench@122-61-221-144.jetstream.xtra.co.nz] has quit [Remote host closed the connection] 10:24 -!- niekie [quasselcor@CAcert/Assurer/niekie] has quit [Quit: No Ping reply in 180 seconds.] 10:25 -!- niekie [~niek@CAcert/Assurer/niekie] has joined #go-nuts 10:32 < xyproto> is it possible to write a html5 3d-game in Go, somehow? (like http://code.google.com/p/quake2-gwt-port/) 10:33 < xyproto> For instance by gathering input in the browser, sending it to a go server that sends back opengl calls for webgl? 10:33 < xyproto> (Where the server could be written in Go) 10:33 < xyproto> Would it be quick enough? 10:34 < xyproto> (I know the server-thing is a different idea from quake2-gwt-port, but still) 10:34 -!- foocraft [~dsc@dyn-86-36-41-37.wv.qatar.cmu.edu] has joined #go-nuts 10:40 -!- dfc [~dfc@124-169-149-145.dyn.iinet.net.au] has joined #go-nuts 10:41 < bXi> xyproto: i guess it would be possible but i don't think it'll be fast 10:47 < xyproto> bXi: ok, thx 10:53 -!- boscop [~boscop@f055249238.adsl.alicedsl.de] has joined #go-nuts 10:54 -!- skejoe [~skejoe@188.114.142.162] has quit [Quit: Lost terminal] 10:57 < bXi> what you could do is write the game in html5/javascript 10:57 < bXi> and write a go websocket server for communication with a database/other players 11:01 -!- ronnyy [~quassel@p4FF1C577.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 11:07 -!- preflex [~preflex@unaffiliated/mauke/bot/preflex] has quit [Ping timeout: 260 seconds] 11:11 -!- preflex [~preflex@unaffiliated/mauke/bot/preflex] has joined #go-nuts 11:17 -!- saturnfive [~saturnfiv@219.145.57.24] has joined #go-nuts 11:19 -!- saturnfive [~saturnfiv@219.145.57.24] has left #go-nuts [] 11:21 -!- niemeyer [~niemeyer@201-66-179-18.pltce701.dsl.brasiltelecom.net.br] has joined #go-nuts 11:25 -!- dfc [~dfc@124-169-149-145.dyn.iinet.net.au] has quit [Quit: dfc] 11:26 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has joined #go-nuts 11:32 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-168-54.clienti.tiscali.it] has joined #go-nuts 11:35 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-182-79.clienti.tiscali.it] has quit [Ping timeout: 250 seconds] 11:37 -!- cenuij [~cenuij@base/student/cenuij] has quit [Read error: Connection reset by peer] 11:45 -!- shvntr [~shvntr@116.26.129.194] has quit [Ping timeout: 255 seconds] 11:51 -!- fhs [~fhs@pool-74-101-66-112.nycmny.east.verizon.net] has quit [Quit: leaving] 11:53 -!- pjm0616 [~user@sigfpe-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [Ping timeout: 260 seconds] 11:55 -!- stalled [~stalled@unaffiliated/stalled] has quit [Ping timeout: 252 seconds] 11:56 -!- tensai_cirno [~cirno@80.250.216.102] has joined #go-nuts 11:56 -!- jscherer26 [~jscherer2@d199-74-181-32.try.wideopenwest.com] has joined #go-nuts 12:00 -!- artefon [~thiago@dhcp37.usuarios.dcc.ufmg.br] has joined #go-nuts 12:03 -!- cenuij [~cenuij@78.112.175.207] has joined #go-nuts 12:03 -!- cenuij [~cenuij@78.112.175.207] has quit [Changing host] 12:03 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts 12:04 -!- shvntr [~shvntr@116.26.129.194] has joined #go-nuts 12:07 -!- stalled [~stalled@unaffiliated/stalled] has joined #go-nuts 12:08 -!- pjm0616 [~user@sigfpe-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined #go-nuts 12:15 < nsf> and this is me again and I have another puzzle for you 12:15 < nsf> why Go has unary plus operator? 12:16 < nsf> I can only imagine one argument: a clarity in some cases 12:16 < nsf> like: 12:16 < nsf> do(+1); 12:16 < nsf> do(-1); 12:16 < Namegduf> Because otherwise +-+-+-+-30 won't work. 12:16 -!- tokuhiro__ [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has quit [Ping timeout: 255 seconds] 12:17 < nsf> in C it has a use of forcing implicit conversions 12:17 < nsf> in C++ it's left for compatibility and it's a subject of overloading 12:17 < Namegduf> Awesome. 12:18 < nsf> but Go has none of these 12:20 < nsf> is clarity a valid reason for that? 12:23 < nsf> and I still don't understand why NOT is ^ and why there is a binary AND NOT aka &^ 12:23 < nsf> :) 12:23 < nsf> a &^= 1 << n 12:23 < nsf> vs 12:23 < nsf> a &= ~(1 << n) 12:23 < nsf> is not valid to me 12:24 < nsf> and about NOT being ^ instead of ~, it's like too bad for a lexer to have one more token type? totally don't understand that 12:25 < nsf> especially because practically all languages use ~ 12:27 < nsf> http://www.flickr.com/photos/ntr23/650223983/lightbox/ 12:28 < nsf> hm.. but both ^ and ~ in the ass 12:28 * nsf tries to find a reason 12:28 < nsf> lol 12:28 < nsf> ah, and it's czech 12:29 -!- dRbiG [drbig@unhallowed.pl] has quit [Ping timeout: 276 seconds] 12:30 -!- dRbiG [drbig@unhallowed.pl] has joined #go-nuts 12:30 -!- skejoe [~skejoe@188.114.142.162] has joined #go-nuts 12:31 -!- jscherer26 [~jscherer2@d199-74-181-32.try.wideopenwest.com] has left #go-nuts [] 12:41 < wrtp> nsf: NOT is ^ instead of ~ because then we can use the same char for both xor and bitwise-not 12:42 < nsf> uhm, but XOR and NOT are quite different 12:42 < wrtp> no, a XOR a == NOT a 12:42 < nsf> uhm.. ok 12:42 < Namegduf> I don't think it is. 12:43 < Namegduf> a XOR a is just 0 12:43 < Namegduf> a NAND a == NOT a 12:43 < nsf> yeah 12:43 < wrtp> hmm, yes 12:44 < nsf> but there is not NAND or NOR or whatever 12:44 < nsf> :) 12:44 < nsf> no* 12:45 < nsf> when I wasn't trying to write a language that looks like Go it wasn't bothering me 12:45 < nsf> now it is :) 12:46 < nsf> because obviously blind copy&pasting is evil 12:47 < nsf> and more I do, more unanswered questions I have :) 12:48 < wrtp> here's the rationale from the spec: m ^ x with m = "all bits set to 1" for unsigned x 12:48 < wrtp> and m = -1 for signed x 12:48 < wrtp> so ^x is, in C, ~0 ^ x 12:48 < wrtp> which seems ok to me 12:49 < nsf> uhm, ok 12:51 < nsf> I guess I've missed that somehow 12:51 < nsf> but still, why &^ is a binary op :) 12:53 < nsf> maybe it has something to do with consts 12:53 < nsf> I don't know 12:57 < wrtp> yeah, i guess it just saves some brackets sometimes 12:57 < wrtp> i don't think it has anything to do with consts 12:57 < nsf> ok 12:57 < eaburns> part 12:57 < eaburns> sorry 12:57 -!- eaburns [~eaburns@c-24-62-248-129.hsd1.nh.comcast.net] has left #go-nuts [] 12:58 < wrtp> classic example from the source: ctxt.tok.Whitespace &^= 1 << '\n' 12:58 < wrtp> which would be &= ^(1 << '\n') otherwise 12:58 < nsf> yeah 12:59 < nsf> in C most people use macros for that 12:59 < wrtp> i would never use a macro for that in C 12:59 < nsf> :) 13:00 < nsf> http://stackoverflow.com/questions/47981/how-do-you-set-clear-and-toggle-a-single-bit-in-c 13:00 < nsf> this page is full of macros 13:02 < nsf> but for ~, I think compatibility with C is a pretty valid argument 13:02 < nsf> even if C's NOT op doesn't make sense 13:02 < wrtp> no macros in any of the top 4 answers... 13:02 < nsf> wrtp: ok, you've won 13:03 < nsf> but I would use a macro 13:03 < nsf> :) 13:03 < wrtp> nsf: converting from C is trivial - just translate ~ to ^ 13:03 < xyproto> I would use a monad 13:03 < xyproto> jk :P 13:03 < nsf> wrtp: yeah, but 13:03 < nsf> if you work with two languages, one more difference to remember 13:03 < Namegduf> I would use an abstract operation metaobject 13:03 < Namegduf> And 13:04 < Namegduf> ...no. 13:04 < xyproto> Namegduf: ;) 13:04 < Namegduf> I can't continue down that route. 13:04 < nsf> fortunately ^ or ~ isn't common 13:04 < Namegduf> Not today. 13:04 < nsf> for example imagine pointer specified '*' in that position instead 13:04 < nsf> changing it is like insane 13:04 < nsf> and I wanted to do this :) 13:05 < nsf> but I like reasons behind ^ 13:05 < nsf> it's like -a == 0 - a 13:05 < wrtp> yup 13:08 < xyproto> I'm trying to learn about channels and select. However, if I cut'b'paste the example from the Go Language Specification, I get a syntax error: syntax error: unexpected :=, expecting : or comma 13:08 < xyproto> This is from this line: case i3, ok := <-c3: 13:09 < xyproto> And here's the example code: http://gonuts.org/doc/go_spec.html#Select_statements 13:09 < xyproto> Ah, just remembered I downgraded Go to an earlier version yesterday... nvm 13:10 < wrtp> xyproto: yeah, that's a new feature. (actually the syntax is old, but was killed for a while) 13:10 < wrtp> previously it meant non-blocking read 13:10 < xyproto> wrtp: I see. I'll install the latest version from hg and see how it fares. :) 13:10 -!- jgonzalez [~jgonzalez@173-14-137-134-NewEngland.hfc.comcastbusiness.net] has joined #go-nuts 13:11 < wrtp> that reminds me, i've still got some code that i haven't converted. too late for automatic errors, damn. 13:12 -!- jokoon [~jorinovsk@LMontsouris-156-26-32-176.w80-14.abo.wanadoo.fr] has joined #go-nuts 13:12 < nsf> I've made a mistake fixing gocode for weekly release 13:12 < nsf> I think next time I will fix it only for real 'release' 13:12 < nsf> because it's what README says 13:12 < Namegduf> You're supposed to abandon it and let people fork it any time they want to use it. 13:13 < Namegduf> Like goconfig. 13:13 < nsf> oh, believe me if there will be a big syntax/semantics incompatibility 13:13 < nsf> I won't fix it :) 13:13 < nsf> for example: templates system 13:13 < nsf> if Go will have that one day, gocode will be broken 13:14 < nsf> because in that case rewriting it probably would be a better idea 13:15 < steven> cool, responses! 13:17 < steven> at first the idea of using channels for events seems like a more-complex-without-benefit version of event-switching, but the benefit that i can see is that unpacking becomes a lot easier 13:17 < steven> ie, each channel would contain a struct 13:18 < steven> instead of channel, user := args[0], args[1], i can do: args := <- eventChan; args.channel, args.user 13:18 < wrtp> steven: ah i was wondering if that was your post 13:18 < steven> yep. were you one of the guys? 13:18 < wrtp> steven: yeah, i suggested the channels 13:18 < steven> oh cool 13:19 < steven> whats the w for 13:19 < wrtp> william 13:19 < steven> william roger thomas peppe? 13:19 < steven> do i win? 13:19 < wrtp> nope 13:19 < steven> theodore? 13:20 < wrtp> the t you will never guess :-) 13:20 < steven> tyrannosaurus? 13:20 < steven> tectonics? 13:20 < steven> theophilus? 13:21 < cenuij> Tyberius 13:21 < steven> anyway, 13:21 < steven> one thing about channels that confuses me in this context is whether it blocks, and at one point it unblocks 13:21 < wrtp> it blocks 13:21 < cenuij> unless its buffered? 13:21 < wrtp> when an event is sent on the channel, it unblocks and returns the event 13:21 < steven> i guess if its an unbuffered channel, then it blocks until the handler receives the event 13:22 < wrtp> cenuij: no 13:22 < wrtp> it always blocks if there are no events in the channel 13:22 < steven> but in that case, they need to be on different goroutines, dont they? otherwise the receiver never has a change to receive 13:22 < steven> and currently im not using goroutines at all. 13:22 < wrtp> steven: yes, they need to be in separate goroutines 13:22 < wrtp> steven: you should! 13:22 < steven> that scares me 13:22 < steven> im scared 13:22 < wrtp> it's really not hard 13:22 < wrtp> and it's one of go's strengths 13:22 < Namegduf> Unbuffered channels block when writing and reading. 13:22 < Namegduf> Always. 13:23 < steven> ive had bad experiences with goroutines. one of my goals is to avoid them when they arent necessary, as they often add needless complexity with disproportionate benefit 13:23 < Namegduf> They continue when it has occurred. 13:23 < wrtp> Namegduf: not if a reader or a writer is already waiting 13:23 < Namegduf> steven: Are you the guy postig the event handler question on the mailing list? 13:23 < steven> yep 13:23 < wrtp> steven: i think they can make things simpler 13:23 < steven> thanks for your response Namegduf :) 13:23 < Namegduf> No problem. 13:24 < Namegduf> I thought it was relevant because for that purpose an IRC server and bot are fairly similar, aside that a server really really cares about performance. 13:24 -!- pharris [~Adium@rhgw.opentext.com] has joined #go-nuts 13:24 < Namegduf> I need to get back to that server as soon as I prepare a presentation on GO. 13:24 < Namegduf> *Go. 13:24 < steven> wrtp: assuming either the event handler or the event-generator is running in a non-main goroutine, i need to implement a way of signaling to it that the goroutine should exit/die 13:25 < Namegduf> Why? 13:25 < wrtp> steven: why's that? 13:25 < steven> for cleaning up 13:25 < wrtp> why bother? 13:25 < Namegduf> Not necessary. 13:25 < wrtp> :-) 13:25 < Namegduf> Generally a bad idea. 13:26 < wrtp> the runtime cleans itself up when you exit 13:26 < wrtp> anyway, it's easy to signal to an event consumer that it should die. just close the channel. 13:26 < steven> but if theres a chance i later want to refactor this out into a library in which multiple bots can be created, started, and stopped, within the same app, then im screwing myself by not taking care of cleanup 13:26 < Namegduf> Event handler goroutines work well just blocking until the program is shut down. It's also the only way to handle event handlers having arbitrary interdependencies in communication. 13:27 -!- adu [~ajr@softbank220043138128.bbtec.net] has quit [Quit: adu] 13:27 < xyproto> What is the simplest possible example of "chan" and "select"? 13:27 < Namegduf> Maybe. For that a close will work fine. 13:27 < nsf> xyproto: combining two timers 13:27 < Namegduf> What I do is block a bunch of goroutines reading from event channels, and terminate main() when they've all indicated they're good to shut down. 13:27 < nsf> let's say 100ms timer and 1s timer 13:28 < steven> xyproto: separate chan and select into two examples 13:28 < Namegduf> That way they're all alive and able to talk to each other, and it's possible for one to talk to another and know nothing will have terminated until it sends its quit. 13:28 < steven> xyproto: chan is way easy to understand. and select is literally just a switch between channel sends/receives, going with whichever one succeeds first 13:28 < wrtp> sync.WaitGroup can be helpful 13:28 < Namegduf> For this kind of use case, with a single writer, a close is a good idea 13:29 < Namegduf> Multiple writer cases, you should generally not use close 13:29 < Namegduf> Unless you Know What You Are Doing 13:29 < xyproto> nsf, steven: great, thanks 13:29 < Namegduf> (You need to communicate with the other writers and have them all stop before you can close, basically) 13:31 < wrtp> steven: if you want to shut down an IRC bot, then you can just close its connection. then the Read will terminate and the error will propagate to all the event readers 13:31 < Namegduf> THere's no reason close() won't work perfectly well here, I think. 13:31 < wrtp> Namegduf: you can't close() a net.Conn 13:32 < Namegduf> I was meaning for the event channels 13:32 < Namegduf> You have a channel with a single writer, the IRC bot package, and a reader goroutine (or more than one, technically, but it makes no difference). 13:32 < wrtp> Namegduf: sure, but you can't close an event channel if there's still a goroutine reading from the connection that might write to the channel at any time 13:32 < Namegduf> Bot terminates, bot closes all its event channels, event handlers terminate themselves. 13:33 < Namegduf> Yes, you can't use that as a quit mechanism, you're not the sole writer, the bot package is. 13:34 < wrtp> say there's a type for the IRC bot. you want some way for a user of the type to indicate that it wants to quit. 13:34 < wrtp> y 13:34 < wrtp> ou 13:34 < wrtp> 13:34 < Namegduf> I'm saying that's how the quit behaviour inside the bot package could work with channels equivalently to however it would work with callback functions 13:34 < Namegduf> Or horrible single-use interface types 13:34 < wrtp> Namegduf: i don't think it could work that way 13:35 < wrtp> because the bot package will have a goroutine reading from the IRC server 13:35 < Namegduf> You are misunderstanding "that way" horribly 13:35 < wrtp> ok 13:35 < Namegduf> wrtp: You call a quit method. Quit method closes connection. Connection closed, goroutine checks, okay, this quit is intended. 13:35 < Namegduf> Closes the event channels, termianting event handlers. 13:35 < Namegduf> All is good. 13:36 < wrtp> ah, that's exactly what i was trying to say earlier 13:36 < wrtp> i 13:36 < wrtp> 13:36 < wrtp> i thought you were saying that the bot handler could just close the event channels 13:36 < Namegduf> Readers can't close, no. 13:36 < Namegduf> Well, not usefully. 13:37 < wrtp> Namegduf: they can't close, but they can Close :-) 13:37 < Namegduf> Yes. 13:37 < Namegduf> Or send a message down a quit channel or call a quit function. 13:37 < wrtp> yeah, Quit might be a better name 13:38 < wrtp> steven: anyway, using goroutines and channels involves quite a mind shift, but it's worth it. programs written this way can be much more modular 13:38 < Namegduf> Well, I was meaning as distinct from closing the connection directly themselves, not the name. 13:38 < wrtp> Namegduf: yeah, i didn't really mean that. 13:39 < Namegduf> Ah, okay. 13:39 < wrtp> Namegduf: i said that as a shorthand for the package closing the connection 13:39 < Namegduf> I like channels but have found myself not using them much. 13:39 < Namegduf> Which is a pity. 13:40 < Namegduf> I need to evaluate my API for improvement there, perhaps, although I'm dubious of the effect on performance. 13:40 < wrtp> Namegduf: you should be aware that net connections use channels all the time, so the performance can't be too bad :-) 13:41 < wrtp> whether channels are useful or not depends on the nature of the program 13:41 < Namegduf> wrtp: Depends how many are involved 13:41 < wrtp> Namegduf: what depends? 13:41 < Namegduf> And what level of concurrency is present. 13:41 < Namegduf> How bad the performance is. 13:41 < Namegduf> Triggering one channel use, not bad. Triggering a hundred, bad. 13:43 < Namegduf> My problem is that I have to make the primary path very fast and it isn't a simple path. 13:43 < Namegduf> It's an IRC server, so the thing it needs to do very quickly is relay messages. 13:44 < wrtp> in servers, it's conventional to have one or two goroutines per client 13:44 < wrtp> and one for the server logic 13:44 < Namegduf> But it's a modular IRC server, designed to have parts written to enable clients to be connected via multiple s2s protocols, through a web frontend, etc 13:44 < wrtp> that seems ideal for a channel-based approach to me 13:44 < jnwhiteh> How can I concert a [60]uint8 to a string? 13:44 < skelterjohn> string(thearray)? 13:44 < jnwhiteh> apaprently not 13:45 < wrtp> actually probably string(thearray[:]) 13:45 < jnwhiteh> ah yes 13:45 < skelterjohn> that was my next suggestion 13:45 < Namegduf> wrtp: Doing 194 context switches and copies to send something to this channel 13:45 < Namegduf> wrtp: Is not "ideal" 13:45 < Namegduf> It probably isn't acceptable 13:45 < wrtp> Namegduf: why would you need to do 194 context switches? 13:45 < jnwhiteh> thanks =) 13:45 < Namegduf> 194 users to send to. 13:45 < wrtp> there's no need to do one context switch per user 13:45 < Namegduf> A channel send involves a context switch. 13:45 < wrtp> no it doesn't 13:45 < Namegduf> Yes, it does. 13:45 < wrtp> only if it's unbuffered 13:46 < Namegduf> Even if it's buffered. 13:46 < skelterjohn> it does if the other end of the channel is read by a different goroutine? 13:46 < Namegduf> The receiving goroutine must become active 13:46 -!- shvntr [~shvntr@116.26.129.194] has quit [Ping timeout: 248 seconds] 13:46 < Namegduf> That involves a context switch 13:46 < Namegduf> 100s of users in a channel is not uncommon; thousands exists. 13:46 < skelterjohn> Namegduf: have you seen evidence of the slowness of this approach, or are you speculating? 13:46 < Namegduf> It's not very good for a broadcast mechanism. 13:46 < wrtp> you don't necessarily need a goroutine for sending to a channel 13:47 < Namegduf> wrtp: No, but you need one for writing to a user. 13:47 < wrtp> that's why i said one *or two* goroutines per client 13:47 < wrtp> Namegduf: no you don't 13:47 < skelterjohn> Namegduf: I'd think it'd only be *necessary* to have a goroutine for reading from a client 13:47 < wrtp> you can do synchronous writes 13:47 < skelterjohn> writing to the client can be done in bulk 13:47 < Namegduf> No, you can't. 13:47 < skelterjohn> o_O 13:48 < Namegduf> Because you *cannot* block one client on another's connection. 13:48 < wrtp> ok, fair enough 13:48 < skelterjohn> are writes going to block? 13:48 < Namegduf> They certainly can? 13:48 < skelterjohn> *shrug* not an expert 13:48 < Namegduf> My current approach is to use a mutex and have a low timeout set on writes 13:48 < skelterjohn> i guess they block until an ack has been received, for tcp? 13:48 < Namegduf> They block when the OS's buffer is full 13:49 < skelterjohn> ah 13:49 < Namegduf> Which happens with bulk writes or when the client isn't receiving 13:49 < skelterjohn> then that other client would block, too 13:49 < Namegduf> Connect a broken TCP implementation, break channels 13:49 < ww> just sent to list: http://river.styx.org/ww/2011/03/godroid 13:49 < Namegduf> (IRC channels) 13:49 < wrtp> Namegduf: have you timed the overhead of using a goroutine-per-client? 13:49 < ww> thoughts and insights into cgo with cross compilation welcome :) 13:49 < Namegduf> wrtp: I use a goroutine per client for reading. Not writing. 13:49 < skelterjohn> his point is that this discussion might be theoretical 13:49 < skelterjohn> and in practice, you wouldn't notice any slowdown 13:50 < skelterjohn> even if it exists, to some extent 13:50 < Namegduf> No, because waiting until profiling to consider architectural performance issues is way too late. 13:50 < Namegduf> You wait to do small, in place optimisations 13:50 < skelterjohn> i disagree 13:50 < Namegduf> You can't retroactively fix an architecture 13:51 < skelterjohn> wouldn't it be nice to know if, in general, channels and context switches were slow enough to cause problems for this sort of architecture? 13:51 < Namegduf> Sure, write your own 10k lines of code to throw away when you find out it is 13:51 < Namegduf> I wanted to write a program. 13:51 < Namegduf> Not write it then throw it out because it was too slow. 13:52 < Namegduf> I did use to trigger a channel send for every channel join to every channel by every user 13:52 < Namegduf> And it was remarkably slow 13:52 < Namegduf> Getting rid of it sped joins for non-local (that is, no network connections for I/O locally) users by 2x 13:52 < skelterjohn> the outer two "channel"s were go channels, the inner was irc? 13:53 < Namegduf> First Go, then IRC. 13:53 < Namegduf> Remote users are important to optimise because while local sets maximum size on a server, remote sets maximum network size, total. 13:54 < wrtp> Namegduf: was the join channel send using a buffered channel? 13:54 < Namegduf> No. 13:54 < wrtp> that might have been the problem 13:54 < skelterjohn> the slowdown might have been from blocking, rather than context switch overhead 13:55 < wrtp> that kind of thing, yes 13:55 < skelterjohn> ww: why is it obvious that gotest will not work? 13:55 < Namegduf> Nevertheless, I'm pretty sure a writing-goroutine-per-user approach isn't ideal. 13:55 < wrtp> if the channel is unbuffered, then your master goroutine will context switch each time it tries to send to a client that isn't ready 13:56 < Namegduf> At the time, it wasn't sending to clients, it was just modifying the channel list, which was owned by a goroutine. 13:56 < Namegduf> To add the user to it. 13:56 < wrtp> Namegduf: nonetheless 13:57 < ww> skelterjohn: because gotest will try to run a program on the build host 13:57 < ww> but the program will be compiled as e.g. arm 13:57 < skelterjohn> ah, ok 13:58 < skelterjohn> then "Obviously gotest will not work because it will build the github.com/kless/goconfig/config" is kind of misleading :) 13:58 < Namegduf> wrtp: I'm pretty sure that even multiplying a "cheap" send operation by a few hundred or even a thousand will suck 13:58 < skelterjohn> you should say what you just said, instead 13:58 < Namegduf> Being able to batch up sends before it switches context only does so much. 13:58 < Namegduf> It has to switch to each and go through them eventually. 13:59 < skelterjohn> Namegduf: I'm interested in the framework you use to stress test this 13:59 < skelterjohn> is it something that's available? 14:00 < Namegduf> For the remote users, I used an internal module which introduced a large number and joined them to channels. The primary test was supposed to be RAM for remote users, but it took about three minutes to finish booting. 14:00 < Namegduf> There's reet for local users, been ages since I used it, though. 14:00 < Namegduf> Hard to get hold of, too. 14:00 -!- skejoe_ [~skejoe@188.114.142.162] has joined #go-nuts 14:00 * ww needs to copy edit... 14:00 < Namegduf> It makes an arbitrary number of connections with random nicks. 14:00 < wrtp> Namegduf: Go is specifically designed so that goroutine switches are very cheap. i think that you should use them as intended! 14:01 < Namegduf> wrtp: Goroutines are cheap but not free. 14:01 < wrtp> (even if you don't get ultimate performance - they'll get better) 14:01 < ww> skelterjohn: fixed 14:01 < skelterjohn> cool 14:01 < Namegduf> wrtp: The problem is that this is the thing it has to do really quickly. 14:02 < wrtp> Namegduf: actually, for sending messages out, i don't particularly think that it's necessary to use goroutines 14:02 < Namegduf> Okay. 14:02 < Namegduf> Right now I do but only if it blocks. 14:02 < Namegduf> It's kinda fancy and weird 14:03 < wrtp> the net package uses a non-blocking write and then falls back to a channel-based approach, which works ok 14:03 < Namegduf> Ah, that's the same thing I do, basically. 14:03 -!- skejoe [~skejoe@188.114.142.162] has quit [Ping timeout: 255 seconds] 14:03 < Namegduf> I use synchronous I/O with a low timeout, and if that fails it copies into a buffer, spawns a writing goroutine, and carries on. 14:04 < Namegduf> (It does not need to return results, so it can do that) 14:05 < wrtp> the difficulty with that is that once I/O has blocked, you'll end up always sending to the writing goroutine for that client, as it's a pain to shut down 14:05 < Namegduf> Solved. 14:06 -!- sysiphus [~opera@unaffiliated/sysiphus] has joined #go-nuts 14:06 < Namegduf> But it was a pain. 14:07 < Namegduf> I've even gone further and added the ability to do blocking I/O without blocking normal I/O at the same time, so you can send HUGE amounts to a client without buffer overflow issues or breaking normal IRC operation. 14:07 < Namegduf> Which was actually easy to implement but complex in concept. 14:07 < wrtp> Namegduf: BTW channel sending overhead can be about 200ns 14:07 < wrtp> th 14:07 < wrtp> at' 14:07 < wrtp> s 14:07 < wrtp> that's really not very much 14:08 < Namegduf> Eh. 0.2s for every channel message on a 1000 user channel in overhead. 14:08 < Namegduf> You can handle five a second, total. 14:08 < skelterjohn> 200ns != .2s 14:08 < Namegduf> Multiply by 1000. 14:08 < skelterjohn> 200ns = .0000002s 14:09 < Namegduf> Ah, yeah. 14:09 < skelterjohn> 1e9 ns = 1s 14:09 < Namegduf> micro, not mille. 14:09 -!- shvntr [~shvntr@116.26.129.194] has joined #go-nuts 14:09 < skelterjohn> nano! 14:09 < ww> i think the context switching, particuarly amongst different threads, is more of a worry than channels as such... as mentioned in the faq 14:10 < Namegduf> skelterjohn: I multiplied by 1000 14:10 < Namegduf> The results were in microseconds 14:10 < Namegduf> I have to break from the nice way of doing things in worse ways, though. 14:10 < skelterjohn> oh, i misread, sorry 14:11 < skelterjohn> .0002s for a send on a 1000 user channel isn't bad :) 14:11 * ww likes op/s rather than s/op and paints the bike shed orange 14:11 < Namegduf> I'm still worried about the context switching part 14:12 < wrtp> Namegduf: that included context switching 14:12 < skelterjohn> wrtp: how long for a send on a buffered chan w/o the context switch? 14:12 -!- plainhao [~plainhao@208.75.85.237] has joined #go-nuts 14:12 < wrtp> Namegduf: it's not a full context switch, after all 14:12 < ww> not in a position to test right now but i've seen soem significant slowdown chaining very simple transformation operations using a channel and threads... 14:12 < Namegduf> wrtp: How are unbuffered sends so expensive, then? 14:13 < wrtp> skelterjohn: i haven't measured, hold on 14:13 < Namegduf> Does it wait for a few seconds before deciding to wake up another goroutine or something? 14:13 < ww> s/a channel/channels/ 14:13 < wrtp> Namegduf: they're only expensive compared to a function call, which is about 10ns 14:13 < wrtp> or less 14:13 < Namegduf> wrtp: Then I'm not sure how about 40,000 unbuffered communications took upwards of 30 seconds 14:14 < skelterjohn> perhaps the reading goroutines weren't as responsive as they could have been 14:14 < skelterjohn> presumably they had other things they were doing, too 14:14 < Namegduf> Nah. 14:14 < steven> this is my current impl: 14:14 < ww> there must be something to do with taking the data from one thread and moving it to the receiver thread, pausing goroutines while it does that, maybe some locking, not sure how the implementation actually works 14:14 < steven> https://github.com/sdegutis/go-ircbot/blob/master/bot.go#L12-18 14:14 < Namegduf> This was during startup. 14:14 < steven> https://github.com/sdegutis/go-ircbot/blob/master/main.go#L8-15 14:14 < skelterjohn> ww: don't say "thread"! 14:14 < steven> itll probably be really easy to convert to a channel-based stuff. 14:15 < skelterjohn> famous last words 14:15 < skelterjohn> (from steven, not ww) 14:15 < steven> ha 14:15 < Namegduf> My current setup uses mutexes in most places, unfortunately. :( 14:15 < ww> skelterjohn: OS thread, where goroutines happen to be running in different ones 14:15 < steven> kind of like EventChan() here: http://golang.org/src/pkg/exp/draw/event.go?s=251:614#L3 14:15 < Namegduf> The big place is the core, and that's because a goroutine per channel and per user kinda sucks 14:15 < skelterjohn> ww: say "process" 14:16 * ww resists... process means something different to me 14:16 < skelterjohn> well, they mean something other than thread 14:16 < ww> skelterjohn: i meant specifically thread as in posix thread 14:17 < steven> i have a feature request: 14:17 < skelterjohn> well, not an expert on the runtime, but i'd think that there wouldn't be many pthread switches 14:17 < skelterjohn> steven: no 14:17 < steven> multiple arguments in a chan 14:18 < steven> a, b, c := <- ch 14:18 < steven> chan string string bool 14:18 < steven> :) 14:18 < skelterjohn> steven: make a struct 14:18 < skelterjohn> same thing 14:18 < steven> yeah i know 14:18 < steven> this way is slightly cleaner 14:18 < skelterjohn> oh good! 14:18 < steven> maybe 14:18 < skelterjohn> eh 14:18 < wrtp> skelterjohn: around 90ns for a send without context switch 14:18 < wrtp> with GOMAXPROCS=1 14:18 < skelterjohn> wrtp: how do you account for buffers filling up? 14:18 < skelterjohn> just curious 14:19 < ww> consider: two threads, t1, t2. two goroutines, sender and receiver, g1, g2 14:19 < skelterjohn> ww: why would there be two threads 14:19 < ww> g1 happens to be running in t1 and g2 happens to be running in t2 14:19 < ww> some data is sent from g1 to g2 over a channel 14:19 < Namegduf> GOMAXPROCS >1, pressumably 14:19 < ww> how does it actually arrive 14:19 < skelterjohn> so, two processes 14:19 < ww> Namegduf: right 14:19 < skelterjohn> p1 and p2 14:19 < wrtp> skelterjohn: http://pastebin.com/6NFqJ2uy 14:19 < Namegduf> wrtp: So you seriously think having thousands of channel sends per message send is a good server design? 14:19 < Namegduf> Honest question. 14:19 < ww> (sure say processes, if it makes you happy) 14:20 < skelterjohn> wrtp: aha, big buffer :) 14:20 < wrtp> Namegduf: if you've got thousands of clients, sure. 14:21 < Namegduf> 14:24 [Freenode] -!- 68350 71006 Current global users 68350, max 71006 14:21 < Namegduf> Thousands is pretty much the line for being a "serious" IRC network. 14:21 < Namegduf> Tens of is big. 14:22 < skelterjohn> not all on one server, though 14:22 < Namegduf> (Thousands on a single server is admittably reseved for things this big) 14:22 < skelterjohn> are cross-server messages done in bulk somehow? 14:22 < Namegduf> Yeah, remote users are not treated like local ones. 14:22 < steven> ooooh 14:22 < steven> crap 14:22 < wrtp> so you could broadcast 70 messages a second to all users 14:22 < steven> one thing i just realized is that channel-based events is gonna be harder to allow multiple handlers 14:23 < Namegduf> steven: Use a slice 14:23 < steven> with my other implementation, i could just call a function on every handler i have 14:23 < Namegduf> Slices are god 14:23 -!- rtharper [~tomh@unaffiliated/sioraiocht] has joined #go-nuts 14:23 < Namegduf> :P 14:23 < wrtp> steven: with channels, you can just send an event on each event channel 14:23 < steven> this way, i just send an event once, and only one handler will ever receive it 14:23 < Namegduf> So have a slice of event channels for each event 14:23 < Namegduf> Start them off at 0 length 14:23 < steven> Namegduf, wrtp: but only one handler can receive that event, even if two handlers want it at the same time 14:24 -!- zozoR [~Morten@56344966.rev.stofanet.dk] has joined #go-nuts 14:24 < Namegduf> Er 14:24 < Namegduf> What? 14:24 < Namegduf> No? 14:24 < Namegduf> You have a slice of event channels 14:24 < wrtp> steven: you'll want handlers to register themselves 14:24 < Namegduf> You send to all of tehm 14:24 < ww> think in terms of a network of message handlers, some point-to-point links some point-to-multipoint links 14:24 < steven> ooh let me see 14:24 < ww> sure implement them with slices 14:24 < wrtp> steven: so that you have a channel for each handler 14:24 < ww> remote users are point-to-multipoint behind point-to-point (between servers) 14:25 < Namegduf> bot.SendJoin(joinChannel) bot.SendJoin(joinChannel2) 14:25 < wrtp> Namegduf: thing is, you're rarely broadcasting to all users 14:25 < wrtp> because all users aren't on one channel 14:25 < ww> for each channel you have such a network of queues 14:25 < Namegduf> wrtp: Channels broadcast to all in a channel, and are far and away most of the traffic but yes, more than hundreds in a single channel per sever would be odd. 14:25 < ww> where channel is irc channel not go channel 14:26 < steven> oh i have an idea 14:26 < steven> ill have a function which returns a channel, but under the hood it creates a new channel, appends it to the channels to send the event to, and then returns it 14:26 < wrtp> steven: that's what i meant by "register" 14:27 < Namegduf> Sounds good. 14:27 < steven> so all i have to do is: joinChan := bot.JoinChannel() ... args := <- joinChan 14:27 < wrtp> exactly 14:27 < Namegduf> Yep. 14:27 < Namegduf> And when sending an event 14:27 < steven> but one issue still remains with that.. sending then will be synchronous and linear in the ordre they were registered 14:27 < Namegduf> You just range over the slice 14:27 < steven> but that seems fine. 14:27 < steven> nice. 14:27 < steven> <3 14:27 < Namegduf> Well, make them buffered. 14:27 < steven> thanks guys 14:27 < steven> god bless you all 14:27 < ww> should you mux messages for different irc channels on one go channel? 14:27 < Namegduf> Make the slice start at 0 length, you don't even need a nil check. 14:28 < Namegduf> (I love ranging over slices) 14:28 < Namegduf> (Makes input validation basically not needed) 14:28 < ww> maybe not, saves a "dst" header and some processing 14:28 -!- rtharper [~tomh@unaffiliated/sioraiocht] has quit [Ping timeout: 264 seconds] 14:28 < Namegduf> Messages for a user are complicated and varied 14:29 < wrtp> ww: you could if you wanted, but you wouldn't have to 14:29 < Namegduf> And include server log events, responses to commands, and messages from ther users 14:29 < Namegduf> So I would just have them be literal lines to send 14:29 < ww> could make a network of irc servers with netchan? 14:29 < wrtp> ww: easily 14:30 < Namegduf> You could use a chan as a transport 14:30 < Namegduf> You would not avoid any of the hard parts of the protocol 14:30 < Namegduf> Which are mostly related to the wonder of bursting 14:30 < wrtp> bursting? 14:30 < Namegduf> IRC servers synchronise when linking by "bursting" their entire states at each other 14:30 < Namegduf> And consistently applying timestamp rules to get to the same result 14:31 < wrtp> ah, synchronisation. my old bugbear. 14:31 < Namegduf> It's really awesome to try to synchronise a state that things are modifying concurrently and send messages for changes that happened after 14:31 < Namegduf> Without sending messages for anything that happened before. 14:32 < Namegduf> I solved it, without a Big Server Lock, but it was "fun". 14:33 < wrtp> Namegduf: better if you can avoid a state that things are modifying concurrently 14:34 < Namegduf> wrtp: IRC fundamentally involves it, unfortunately. 14:34 < wrtp> a goroutine is good for that :-) 14:34 < Namegduf> Channels have ban lists, they need checking. 14:34 < Namegduf> Member lists that need iterating. 14:34 < Namegduf> It's very, very stateful. 14:35 < wrtp> yeah, but that doesn't mean that the state has to be modified concurrently 14:35 < Namegduf> Well, you need to have something controling modifications. 14:35 < wrtp> sure, but that can be a single goroutine 14:35 < Namegduf> Yes... ish. 14:36 < Namegduf> At present what I do is export concurrency-safe functions. 14:36 < Namegduf> Nothing but the core package cares. 14:36 < Namegduf> So far as they're concerned, simultaneous changes are fine. 14:37 < Namegduf> That used to be implemented with a single own-everything goroutine, but I swapped it out for a mutex on each user and channel's state without external API changes, because it made for additional concurrency. 14:37 < Namegduf> Also faster. 14:38 < wrtp> do you mean "additional parallelism"? 14:38 < Namegduf> Yes. 14:38 < Namegduf> The real performance gain came from saying screw you to the memory model and relying on the full field behaviour of sync.Mutex's implementation and not doing any mutex on read at all. 14:38 < wrtp> "full field behaviour"? 14:38 < Namegduf> Er, memory barrier. 14:38 < Namegduf> I don't know why I thought field. 14:39 < Namegduf> The problem was, without that, the core had to contain all functionality that needed to read from multiple things in the core. Ban checks, for example. Otherwise, you got literally hundreds of calls in and out of the core for permission checks. 14:39 < wrtp> Namegduf: you know that might break in the future, don't you? 14:39 < Namegduf> Yes. 14:39 < Namegduf> In that case I will break out to assembly 14:40 < Namegduf> And issue a memory barrier instruction myself before releasing the mutex. 14:40 < xyproto> How can I keep track of functions that are started with "go", so that no go-functions are running when the program ends? 14:40 < xyproto> With channels? 14:40 < wrtp> xyproto: see sync.WaitGroup 14:40 < xyproto> wrtp: ahh, thanks 14:40 < steven> you writing an IRC server in Go? 14:41 < wrtp> Namegduf: if you're not doing any mutex on read, how do you manage mutation? 14:41 < Namegduf> wrtp: Everything not a single word is a pointer and updated atomically. 14:42 < Namegduf> Same solution as mentioned in Off To The Races 14:42 < Namegduf> It would be much harder without a garbage collector to fall back on. 14:43 < wrtp> i think you're probably making life harder for yourself by trying to screw the ultimate performance out of a single server instance rather than making it scalable and keeping things simple 14:44 < Namegduf> As I've said, my primary interest was in remote user count 14:44 -!- shvntr [~shvntr@116.26.129.194] has quit [Ping timeout: 252 seconds] 14:44 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts 14:44 < Namegduf> The problem is that permission checks and anything that cares about the membership list has to iterate through a lot of data, which means it either has to run inside the single goroutine entirely, thus requiring either it be part of the core or things outside the core be able to tinker with state and trusted not to mutate it wrongly, or they're very, very slow 14:44 < Namegduf> Because they need to do a lot of reads 14:44 < Namegduf> Writes are rare, reads are very common 14:44 < wrtp> Namegduf: there are other possibilities 14:45 < Namegduf> wrtp: Such as? 14:45 < wrtp> Namegduf: if access was structured, the core could do most of the management itself 14:45 < wrtp> also 14:45 < Namegduf> What kind of management? 14:45 -!- gid [~gid@220-253-20-152.VIC.netspace.net.au] has quit [Ping timeout: 276 seconds] 14:46 < wrtp> e.g. notifying clients when something happens related to a member they care about 14:46 < xyproto> is it possible to declare a list of channels with ie. var something []chan string 14:46 < xyproto> ? 14:46 < Namegduf> Okay. 14:46 < wrtp> xyproto: yes, but you need to make them 14:46 < xyproto> wrtp: ok 14:46 < Namegduf> It does that. 14:46 < Namegduf> (ish) 14:46 < nsf> http://pastie.org/1708389 14:47 * nsf has created his binary operator rules 14:47 < Namegduf> (It notifies subsystems, not clients, the subsytem then notifies clients, but that's a technicality) 14:47 < nsf> :D 14:47 < plexdev> http://is.gd/gMk7Sd by [Sameer Ajmani] in go/misc/emacs/ -- misc/emacs: gofmt: don't clobber the current buffer on failure 14:47 < Namegduf> It still doesn't solve issues like permission checks needing to iterate through ban data 14:48 < wrtp> Namegduf: an, you can provide the capability to execute a function inside the core state 14:48 < Namegduf> I could, but to put references into that function to core state 14:48 < Namegduf> I would need to export internals 14:48 < wrtp> but that's not too different to taking out a mutex 14:48 < Namegduf> And trust modules not to screw with them. 14:48 < wrtp> Namegduf: not necessarily 14:49 < Namegduf> Oh? 14:49 < wrtp> the argument to the function could be an interface which exposed a select view of core state 14:49 < Namegduf> So it's exposed but only through an interface passed into the function, so you'd have to do something obviously wrong like assign it to something outside your function and call it from outside to break things. 14:50 < wrtp> nsf: why do you want pointers to be compatible with non-pointers? 14:50 < nsf> wrtp: only with ints 14:50 < wrtp> Namegduf: yes 14:50 < nsf> for pointer arithmetic 14:50 < nsf> wrtp: but it's a draft 14:50 < Namegduf> Hm. 14:50 < wrtp> nsf: why does that help pointer arithmetic? 14:50 < nsf> wrtp: char *a, *b, *c; 14:50 < Namegduf> I'm not sure I favour it over the full memory barrier 14:50 < nsf> c = a + 1; 14:50 < skelterjohn> how else can you do &something+5 14:51 < Namegduf> Just because writes are rare and reads really common 14:51 < nsf> a is char* 14:51 < nsf> 1 is int 14:51 < Namegduf> And locking the core hurts parallelism a lot. 14:51 * ww wishes pointer arithmetic was a bit easier 14:51 < nsf> c = a + b; // invalid 14:51 < wrtp> oh yeah, sure 14:51 < wrtp> same rules as C 14:51 < Namegduf> Thinking about it, the parallelism problem is probably too bad. 14:51 < skelterjohn> heading to campus 14:51 < ww> had a tricky cgo problem with a **struct foo null terminated 14:51 -!- skelterjohn [~jasmuth@c-68-46-33-145.hsd1.nj.comcast.net] has quit [Quit: skelterjohn] 14:51 < ww> e.g. an array of c structs 14:52 < nsf> wrtp: although I'm not sure about this case: 14:52 < ww> pita to walk over them from go 14:52 < Namegduf> Still, though. 14:52 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has quit [Ping timeout: 260 seconds] 14:52 < nsf> type X int; var a int; var b *void; 14:52 < nsf> oops 14:52 < nsf> type X int; var a X; var b *void; 14:52 < nsf> a + b // valid? 14:52 < Namegduf> You came up with a major idea I hadn't thought of that avoids the need to write Go that is implementation dependent. 14:52 < wrtp> ww: yeah, cgo can be awkward. still you can always write the difficult code in C. 14:52 < nsf> X is an integer type after all 14:52 < nsf> maybe some kind of "type Offset uint" 14:52 < nsf> I guess, why not 14:53 < Namegduf> I need to consider it, as well as more channel usage. 14:53 < wrtp> Namegduf: me? 14:53 < Namegduf> Yeah. 14:53 < steven> oh i have an idea 14:53 < ww> wrtp yes i'm still getting a feel for when to write in c and when to write in go 14:53 < steven> would this do what i expect? 14:53 < Namegduf> I've been focusing on making the API very simple, very stupid 14:53 < steven> for ; args := <-userJoinedChan ; { ... do stuff, args is new each time } 14:54 < Namegduf> The intended function of the server is as a platform for writing a web frontend on and some other fancy things 14:54 < Namegduf> So it needs to have a core that doesn't really care how users are connected and other fun things. 14:54 < Namegduf> And it's largely succeeded. 14:54 < ww> almost starting to consider cgo as the rule rather than the exception. high level logic in go, low level often in c, small and well encapsulated though 14:54 < wrtp> steven: i don't think that's valid 14:54 < Namegduf> But making it pretty would be nice. 14:55 < Namegduf> ww: cgo is expensive, though 14:55 < wrtp> ww: what Namegduf says 14:55 < Namegduf> I think it involves a true thread-level context switch 14:55 < Namegduf> Because cgo has to run on a non-segmented-stack 14:55 < wrtp> ww: don't use C unless you need to link to some compatibility library 14:55 < wrtp> Namegduf: it doesn't 14:55 < wrtp> but it's still quite slow 14:55 < Namegduf> It doesn't now? 14:56 < Namegduf> I thought it used to. 14:56 < wrtp> Namegduf: no, not for quite a while 14:56 < Namegduf> Ah, sorry. 14:56 < wrtp> at least 6 months 14:56 < wrtp> i think 14:56 < Namegduf> Does it grow the stack instead? 14:56 < ww> maybe. some things, like dealing with data in non-go-controlled memory regions (e.g. mmaped) are possible but inconvenient in go... 14:56 < wrtp> Namegduf: it grabs a large stack from somewhere else and uses that 14:56 < Namegduf> Ah. 14:56 -!- gid [~gid@220-253-35-101.VIC.netspace.net.au] has joined #go-nuts 14:56 -!- tensorpudding [~user@99.148.205.193] has joined #go-nuts 14:57 < wrtp> ww: that's not too bad. go-mmap works ok as far as i could tell 14:57 < ww> yes, gommap is just fine 14:57 -!- Venom_X [~pjacobs@66.54.185.131] has joined #go-nuts 14:57 < wrtp> i hate reverting to C - it brings back all the possible sources of memory corruption of old 14:57 < ww> its treating arbitrary structures on top of byte arrays that is inconvenient 14:57 < Namegduf> steven: Move it inside the for loop 14:58 < Namegduf> And just use for { ... } 14:58 < Namegduf> Or just use args =, instead of := 14:58 < Namegduf> Being new each time is only very important if you're passing a pointer to it to something or some such. 14:59 < wrtp> ww: it's not hard - and you generally only have to write the code once... 14:59 < wrtp> steven: don't you mean for args := range userJoinedChan { ... } 14:59 < wrtp> ? 14:59 < ww> possible with lots of casts and unsafe.Pointers... but inconvenient and probably even more error prone than C because the syntax for doing that is made purposefully obtuse in go 15:00 < ww> and as for writing it only once, yes, but if the data structure is a little complex, that once can be difficult 15:00 < ww> anyways, there's an optimal place for the Go / C line, just not sure where it is yet... 15:00 < ww> i change my mind on that daily 15:01 < wrtp> ww: are you talking about interfacing with a C program the other end of the mmap? 15:01 -!- gid [~gid@220-253-35-101.VIC.netspace.net.au] has quit [Ping timeout: 252 seconds] 15:01 < wrtp> ww: or just using mmap for persistent storage of Go data structures? 15:01 < ww> wrtp no, actually in my particular case, having a hybrid AVL-tree / Trie as persistent data 15:02 < ww> this is the same database index thing we were talking about the other day (and i haven't touched since then) 15:02 < ww> so serialising and such not an option, too slow 15:02 < ww> straightforward to do in C, Go makes it difficult 15:04 < wrtp> surely it's only one line: func asStructSlice(x []byte) []Node {n := (*[1e9]Node)(unsafe.Pointer(&x[0]); return n[0:len(x)/unsafe.Sizeof(Node{})} 15:05 < wrtp> or something like that 15:05 < wrtp> and then you can work in Nodes from then on 15:08 < wrtp> (admittedly that is 4 lines really) :-) 15:13 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has joined #go-nuts 15:15 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has left #go-nuts [] 15:17 -!- gid [~gid@220-253-30-88.VIC.netspace.net.au] has joined #go-nuts 15:21 -!- DerHorst [~Horst@e176099010.adsl.alicedsl.de] has joined #go-nuts 15:26 < xyproto> I tried using channels and select for the very first time. Any critique or comments? http://go.pastie.org/1708543 15:27 -!- femtoo [~femto@95-89-249-242-dynip.superkabel.de] has joined #go-nuts 15:27 < jnwhiteh> xyproto: select is only really necessary when you can receive on multiple channels 15:28 < jnwhiteh> but its a nice way to do it so its easily expandable in the same format 15:28 < jnwhiteh> so can't criticise that all that much 15:28 < Namegduf> Or non-blocking sends/receives 15:28 < jnwhiteh> the farmer implementation is curious, however 15:28 < Namegduf> Rarely needed as they are (I think) 15:28 < xyproto> jnwhiteh: can you send through channels without select? 15:28 < Namegduf> Yes. 15:28 < jnwhiteh> xyproto: yes, of course 15:28 < Namegduf> channel <- blah 15:28 < xyproto> ah 15:28 < xyproto> :D 15:29 < foocraft> a select with one case is useless... 15:29 < jnwhiteh> and your farmer should really be prepared to receive from any cow at any time, instead of going down the line 15:29 < jnwhiteh> foocraft: except if you are goign to expand it later 15:29 < foocraft> jnwhiteh, this is the problem with our economy 15:29 < jnwhiteh> =) 15:29 < foocraft> jnwhiteh, when you do so, do that. 15:29 < xyproto> jnwhiteh: I see 15:30 < xyproto> Thanks guys 15:30 < xyproto> But, how can the farmer listen to all the cows at once? 15:30 < Namegduf> Yeah, it's not hard to improve it later. 15:30 < foocraft> xyproto, select 15:30 < wrtp> xyproto: i would have the farmer listen on only one channel 15:30 < Namegduf> Futureproof at the architectural level, not at a per line level, IMO 15:30 < jnwhiteh> indeed, I'd use a single channel 15:30 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has joined #go-nuts 15:30 < Namegduf> Individual lines can be improved 15:30 < xyproto> ah, so that there would only be one mootube that all the cows would moo through? 15:30 < foocraft> why don't we let the farmer multiplex on cows though? 15:30 < Namegduf> moo 15:30 < wrtp> but that channel would include the cow number as well as the "moo" 15:31 < xyproto> wrtp: great, sounds like a better idea :) 15:31 < wrtp> in general, you don't need non-blocking receives 15:31 < foocraft> I would like if every cow had a channel associated with it.. 15:31 < foocraft> and the farmer uses select 15:31 < Namegduf> I would just take a couple of the lines there to summarise all discussion on programming in Go that happens here. 15:31 < xyproto> foocraft: every cow does have a channel associated with it 15:31 < jnwhiteh> foocraft: how do you select on a slice of channels? 15:32 < foocraft> jnwhiteh, drat.. 15:32 < jnwhiteh> indeed :P 15:32 < xyproto> but, a real farmer would not be blocking when listening to the mootube, right? 15:32 < Namegduf> You can't. 15:32 < foocraft> Namegduf, it would've been nice if we could... 15:33 < foocraft> not sure if there's a down side to not being able to multiplex on a slice of channels 15:33 < jnwhiteh> foocraft: http://groups.google.com/group/golang-nuts/browse_thread/thread/3ba2157b3259ee54 15:33 < jnwhiteh> hence why we suggested the farmer listen to a single channel =) 15:34 < xyproto> :) 15:35 < foocraft> jnwhiteh, I agree 15:39 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has joined #go-nuts 15:41 < skelterjohn> wth 15:47 -!- aho [~nya@fuld-590c6ac3.pool.mediaWays.net] has joined #go-nuts 15:47 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-174-52.clienti.tiscali.it] has joined #go-nuts 15:48 < xyproto> skelterjohn: http://go.pastie.org/1708619 15:49 < xyproto> skelterjohn: I was using channels for the first time, and asked for c&c. 15:49 < skelterjohn> i figured something like that 15:49 < skelterjohn> but farmers, cows, mooing 15:49 < Namegduf> // TODO: Only one mootube instead of one per cow 15:49 < Namegduf> I want to see this in production code 15:49 < skelterjohn> sounds like my first programming languages class in college, when they taught us OO 15:49 < Namegduf> I will have to see if I can fit it in. 15:49 < xyproto> :D 15:50 < wrtp> xyproto: here's an alternative version: http://go.pastie.org/1708637 15:50 < Namegduf> // The farmer wants to turn on all the milktubes to stop the mooing 15:50 -!- imsplitbit [~imsplitbi@64.39.4.132] has joined #go-nuts 15:50 < Namegduf> This is hilarious stuff. 15:50 < xyproto> wrtp: nice, thanks :) 15:51 < wrtp> xyproto: of course, that code assumes that the farmer knows how many moos a cow will make :-) 15:51 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-168-54.clienti.tiscali.it] has quit [Ping timeout: 276 seconds] 15:51 < Namegduf> moo 15:51 < xyproto> wrtp: some cows may be wonky, the next version may contain radom mooing ;) 15:51 < xyproto> *random 15:52 < Namegduf> Request support for naming cows 15:53 < xyproto> wrtp: I didn't know make(chan string,) was allowed. What buffer size will be used? 15:53 < wrtp> xyproto: zero 15:53 < wrtp> it's a useful default 15:55 < xyproto> wrtp: ok. I find your program more elegant than mine, btw. :) But, what does "<-tube" do ? 15:55 < aiju> xyproto: read from tube 15:56 < xyproto> ok 15:58 < wrtp> xyproto: here's another version, where cows continually moo at random intervals until relieved. the farmer takes 2 seconds to connect a tube. http://go.pastie.org/1708660 15:58 < bugQ> what is the trailing comma in make(chan string,) ? 15:59 < wrtp> Namegduf: hilarious it may be, but it's actually not a bad representation of some kinds of problem 15:59 < Namegduf> No disagreement here. 16:00 < jnwhiteh> this definitely deserves a blog post 16:00 < jnwhiteh> =) 16:00 < Namegduf> Agree 16:00 < jnwhiteh> /r/go imo 16:00 < wrtp> bugQ: it was actually a mistake, but trailing commas are allowed in func calls so that arguments can occur on separate lines 16:01 < skelterjohn> hooray semi-colon insertion 16:01 < xyproto> I agree. A blogpost would be great. Anyone is allowed to use or derive from my version, as long as I can do the same with the improved versions. :) 16:01 < xyproto> ;) 16:01 < Namegduf> A GPL licence? 16:01 < wrtp> xyproto: feel free. i won't use it. 16:01 < xyproto> great 16:02 < Namegduf> EVIL GNU FANATIC 16:02 < Namegduf> No, I'm joking. :P 16:02 < aiju> the Robespierre Public License? 16:03 < xyproto> aiju: I see on wikipedia that he ended his life in the guillotine, but I've never heard of the license 16:04 < aiju> xyproto: his attitude on freedom resembles the one of Stallman 16:04 < skelterjohn> referring to how the GPL causes developers to decapitate those who use their code 16:04 < Namegduf> It's evil, like CC licences. 16:04 < Namegduf> You agree those are evil too, right? :P 16:04 < xyproto> are CC licenses also evil now? 16:04 < aiju> me? yes 16:05 < aiju> especially -NC ones 16:05 < xyproto> I must be behind the times 16:05 * exch has no problem with CC license 16:05 < Namegduf> Common CC licences (those including SA) are basically equivalent to the GPL, but for media 16:05 < Namegduf> I like them, but I like the GPL for non-libraries, too. 16:05 < exch> I use this one for my code http://creativecommons.org/publicdomain/zero/1.0/ 16:05 < Namegduf> Or, well, am at least appreciative of. 16:05 < bugQ> nc makes sense for dual licensing 16:05 < Namegduf> CC0 is what I'd use in place of BSD 16:06 < Namegduf> It's nice 16:06 < aiju> i use WTFPL 16:06 < aiju> nicely unambiguous 16:06 < Namegduf> CC0 is more unambiguous than WTFPL 16:06 < aiju> what's ambiguous about "DO WHAT THE FUCK YOU WANT TO"? 16:06 < Namegduf> Its lack of legal meaning 16:07 < Namegduf> As a clear licence for anything 16:07 < Namegduf> You can always "do what the fuck you want to do" *with* it in your possession, you just can't make new ones or distribute it 16:07 < Namegduf> I don't think it's seriously unclear, I just don't think it's clearer than "I release into the public domain" 16:08 -!- napsy [~luka@193.2.66.6] has quit [Read error: Operation timed out] 16:08 < Namegduf> Which has a very direct and specific meaning that you can do what you want to do with obvious legal standing. 16:08 < Namegduf> (The rest of CC0 is stuff for where public domain doesn't exist) 16:08 < Namegduf> I think WTFPL is better as a political point in a blog post than an actual licence. 16:09 < exch> it's a bit sad that you have to push a license to indicate absence of license :p 16:09 < Namegduf> Haha. 16:09 < Namegduf> Well, it isn't absence of licence. 16:10 < Namegduf> That's easy. 16:10 < Namegduf> You just don't have a licence. 16:10 < Namegduf> No one can copy or distribute your stuff. 16:10 < exch> true 16:10 < Namegduf> It's an absence of restrictions, though. 16:10 < Namegduf> Needing to indicate that is just a thing about copyright, unfortunately. 16:14 < exch> https://github.com/jteeuwen/mpwc/blob/master/screenshot.png it's coming along <3 webapp frontend for MPD. uses a simple go webserver as backend 16:21 -!- str1ngs [~strings@unaffiliated/str1ngs] has joined #go-nuts 16:24 < jnwhiteh> nsf: still can't goinstall gocode? 16:24 < nsf> it will never be possible 16:24 -!- napsy [~luka@88.200.96.18] has joined #go-nuts 16:24 < jnwhiteh> I figured as much, just hadn't paid attention :P 16:25 < jnwhiteh> what version of Go does it target right now? 16:26 < steven> 1.0 16:26 < jnwhiteh> ... 16:27 < steven> 1.1? 16:28 < jnwhiteh> if you don't know, why are you saying anything? 16:29 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has quit [Ping timeout: 240 seconds] 16:30 < nsf> jnwhiteh: latest weekly I guess 16:30 < jnwhiteh> that's what I figured, swapping over now 16:30 < jnwhiteh> the readme might want to be updated then =) 16:30 < nsf> no 16:31 < nsf> the next sync will be on a 'release' 16:31 < nsf> and so on 16:31 < nsf> it was my mistake 16:31 < nsf> updating it for the 'weekly' 16:31 < jnwhiteh> fair enough 16:31 < nsf> also if you have a working version of gocode 16:31 < nsf> you don't need to recompile it 16:32 < jnwhiteh> I don't =) 16:32 < nsf> ok 16:32 < jnwhiteh> not on this machine at least 16:34 < jnwhiteh> very helpful for this project, haven't looked at the code in a bit so don't remember all my members off the top of my head =) Thanks again 16:34 < nsf> sure 16:34 < nsf> I also have a C autocompletion daemon now 16:34 -!- tensai_cirno [~cirno@80.250.216.102] has quit [Quit: Leaving] 16:34 < nsf> works for C++ too 16:34 < nsf> github.com/nsf/ccode 16:35 < nsf> but that one is linux only, most likely 16:35 < wrtp> nsf: you should've written it in Go :-) 16:36 < nsf> it's possible, but I didn't want to add additional unnecessary dependencies 16:36 < nsf> because in that case it will also require libclang bindings 16:36 < nsf> basically it's a simplest possible libclang/vim integration app 16:36 < nsf> and autocompletion is fairly good 16:38 < nsf> http://ompldr.org/vN3k1aw/2011-03-24-214127_1028x704_scrot.png 16:38 < nsf> screenie 16:38 < nsf> NODE macro defines 'struct_type_t *node;' 16:38 < nsf> so it works with macros, etc. :) 16:39 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the connection] 16:39 < nsf> and I'm saying all that, because I need more users 16:39 < nsf> sort of 16:39 -!- jokoon [~jorinovsk@LMontsouris-156-26-32-176.w80-14.abo.wanadoo.fr] has quit [Quit: Quitte] 16:39 < nsf> :D 16:40 < nsf> but I guess very little amount of people here actually write C/C++ code in vim on linux :D 16:41 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has joined #go-nuts 16:43 < kimelto> nsf: interesting. is it portable? 16:44 < xyproto> nsf: I do. Sometimes. 16:44 < kimelto> arg. #1 readme 16:45 < xyproto> nsf: the screenshot looks great, I want to try it out 16:45 < nsf> kimelto: it depends 16:45 < nsf> app is very small 16:45 < nsf> so you can easily port it to other OS or arch 16:46 < nsf> it's like 2k lines of code or something 16:46 < kimelto> if it does not read from /proc it is a big step for portability :) 16:46 < nsf> it doesn't :) 16:46 < nsf> it uses unix sockets though 16:46 < nsf> and /tmp 16:46 < kimelto> Im pretty sure FreeBSD has them ;p 16:47 < nsf> also it relies on C99 behaviour for libc funcs 16:47 < nsf> and.. it uses C99 features 16:47 < nsf> strstr.h uses one of them 16:47 < xyproto> nsf: "cp ccode ~/bin" created an executable file called ~/bin here, other than that, it built smoothly :) 16:47 < nsf> what else 16:47 < kimelto> is libclang fun to play with in general? 16:48 -!- wrtp [~rog@92.17.43.168] has quit [Quit: wrtp] 16:48 < nsf> xyproto: interesting :) 16:48 < nsf> kimelto: I don't know 16:48 < nsf> libclang is a C++ library with C bindings 16:48 < kimelto> I want the opposite of "include what you use", that is "do not include what you dont use". could be fun to code with clang. 16:48 < nsf> C bindings are a bit uhm.. humble 16:49 < nsf> kimelto: I believe "include what you use" does that 16:49 < nsf> basically it's "include only what you use" 16:49 < nsf> that's the whole point :) 16:49 < xyproto> nsf: okay, now I've got it up and running in vim with a C project of mine. Works great. 16:50 < kimelto> oh I thought the point was to directly include the headers in the file that use them rather than relying on orher headers to grab them 16:50 < nsf> well and that yeah 16:50 < nsf> but it simplifies further refactoring processes 16:50 < nsf> like if you will remove something 16:50 * kimelto checks iwyu 16:50 < nsf> you'll need to remove its header only 16:50 < nsf> xyproto: nice :) 16:51 < nsf> xyproto: what OS/arch? 16:52 < nsf> a lot of distros (including archlinux) has this problem 16:52 < nsf> with LLVM 16:52 < nsf> they try to put its libs into /usr/lib/llvm/ 16:52 < nsf> and it causes something 16:52 < nsf> at least for 2.8 16:52 < nsf> I've filled bug for archlinux and they've fixed it 16:52 < xyproto> nsf: 64-bit Arch Linux, clang 2.8 16:53 < nsf> but not sure whether it's in testing or somewhere in the mainstream 16:53 < nsf> xyproto: I see 16:53 < nsf> nice, now I know it works on 64 bit 16:53 < nsf> :) 16:53 < nsf> I need to upload it to AUR someday 16:54 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has quit [Quit: Computer has gone to sleep.] 16:56 < nsf> http://projects.archlinux.org/svntogit/community.git/tree/llvm/trunk/clang-2.8-cindexer-clang-path.patch 16:56 < nsf> yeah, bug fixed in the community 16:56 < xyproto> nsf: what's the license called? 16:56 < nsf> so it should work without any problems :) 16:56 < nsf> xyproto: "I don't care" :) 16:56 < nsf> MIT, public domain 16:56 < nsf> whatever, I'll add MIT now 16:57 < nsf> ah, wait 16:57 < nsf> it has license 16:57 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 16:57 < nsf> uhm.. 16:57 < nsf> ya, MIT 16:59 < xyproto> nsf: thx :) 17:03 < xyproto> nsf: http://aur.archlinux.org/packages.php?ID=47696 17:04 < nsf> thanks :) 17:04 < xyproto> nfs: I can orphan it if you want it 17:04 < nsf> autoconf is not a make dependency though 17:05 < nsf> and make :) 17:05 < nsf> but whatever 17:05 < nsf> no one really cares I bet 17:05 < xyproto> nsf: oh, sorry about that, leftovers from another package, fixing now 17:06 < xyproto> nsf: fixed 17:06 < nsf> thanks 17:08 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has quit [Quit: peace in teh middle east] 17:10 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts 17:12 < xyproto> nsf: yey, the package got another vote :) 17:12 < nsf> mine 17:12 < nsf> ;) 17:12 < steven> i wish there was a way to simplify this code: for { i := <- intChan; /* do something with i */ } 17:12 < steven> oh wait, for range, right? 17:12 < xyproto> nsf: :) 17:12 < str1ngs> nsf: what kind of container would use use for configure flags. think gentoo use flags 17:13 < nsf> str1ngs: I don't like gentoo use flags 17:13 < steven> oooh nice. for range works perfectly for this. nice. 17:13 < |Craig|> steven, range over the chan is different in the respect it will end the loop if the channel closes, might even be better for you 17:13 < nsf> str1ngs: and I don't really get the question 17:13 < str1ngs> nsf: I know but these will be generic not used like gentoo 17:13 < steven> |Craig|: excellent 17:13 < steven> excellent! 17:13 < steven> this is so awesome. 17:13 < steven> im very happy about this. 17:13 < nsf> str1ngs: container? 17:14 < str1ngs> nsf: example makepkg hard codes configure. want I want to do is not hardcode things. but have sane defaults that I can reuse but add to 17:14 < nsf> str1ngs: uhm, I don't know :) 17:14 < nsf> as I said, I think it's a very bad idea 17:15 < nsf> it leads to differently configured software on a distro 17:15 < nsf> and it's a hell for developers 17:15 < nsf> archlinux is ok, because in order to customize each software 17:15 < nsf> you need to fix its pkgbuild 17:15 < str1ngs> no its just another way of use ./configure directly just not redundant 17:15 < nsf> it leads to a nice way of having things 17:16 < nsf> but if can fix all pkgbuilds with one config line 17:16 < nsf> ugh.. no thanks 17:16 < xyproto> I've often experienced that ./configure fails. With pkgbuilds, there's an extra layer of someone who's also made it work. 17:17 < str1ngs> calling ./configure --prefix in every PKGBUILD is redundant 17:17 < str1ngs> --prefix is never going to change 17:17 < nsf> uhm, maybe 17:17 < nsf> but sometimes there is no configure 17:17 < str1ngs> thats another storry 17:17 < nsf> using ./configure CONFIGURE_FLAGS? 17:17 < nsf> it's longer than prefix, lol 17:17 < str1ngs> you assume its bash :P 17:18 < nsf> yeah 17:18 < nsf> I don't know, I have no opinion on that 17:18 < nsf> :) 17:18 < str1ngs> I do :P 17:18 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-174-251.clienti.tiscali.it] has joined #go-nuts 17:19 < skelterjohn> i use different --prefix options occaisionally 17:19 < skelterjohn> when i'm on someone else's system, for example 17:20 < str1ngs> that's not what we are talking about 17:20 < skelterjohn> tl,dr 17:20 < str1ngs> I'm talking creating makepkg like system that not as redundant. ie prefix wont change 17:22 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-174-52.clienti.tiscali.it] has quit [Ping timeout: 264 seconds] 17:22 -!- foocraft [~dsc@dyn-86-36-41-37.wv.qatar.cmu.edu] has quit [Remote host closed the connection] 17:22 < xyproto> str1ngs: it would be nice, but there's also the issue of placing documentation and license-files in the right places. And declaring which license the package is under. 17:23 < str1ngs> xyproto: that fine I plan to handle that to 17:24 < str1ngs> xyproto: the idea being instead of doing ./configure;make and hardcoding flags. you can do Build = gnuBuild and add flags to the default ones. 17:24 < xyproto> str1ngs: I see. A sort of pacman-light for packages that uses autotools? 17:24 < str1ngs> xyproto: if its not a gnuBuild then you can do Build = linuxHeaderBuild and overide that Hook 17:25 < str1ngs> xyproto: no a complete replacement for makepkg 17:25 -!- ronnyy [~quassel@p4FF1C577.dip0.t-ipconnect.de] has joined #go-nuts 17:25 -!- itrekkie [~itrekkie@ip72-201-208-165.ph.ph.cox.net] has joined #go-nuts 17:25 < xyproto> str1ngs: I see. Well, if you make a better makepkg than makepkg, I'm all for it. :( 17:25 < xyproto> :) 17:25 < xyproto> *typo 17:25 < str1ngs> xyproto: https://github.com/str1ngs/via/blob/master/plans/wget.go 17:26 < str1ngs> still very much work in progress of course 17:26 < str1ngs> you can also use differct download hooks ie git w/e you need 17:27 < xyproto> str1ngs: ok, so a .go file is a kind of PKGBUILD? 17:27 < str1ngs> xyproto: right 17:27 < str1ngs> its hackish I need to figure out possibly not statically building them. maybe use packages instead 17:28 < str1ngs> even though that would be static to. but modular 17:28 -!- waqas [~waqas@jaim.at] has joined #go-nuts 17:29 -!- piranha [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts 17:32 < waqas> Any there any released Go applications yet (with target audience not limited to the Go community)? 17:32 -!- DerHorst [~Horst@e176099010.adsl.alicedsl.de] has quit [Remote host closed the connection] 17:34 < xyproto> waqas: I have one :D 17:34 < waqas> Oh? 17:34 < xyproto> waqas: it's a silly little app, but: addinclude.roboticoverlords.org 17:36 < waqas> It qualifies (though I would have just written a oneline shell script to do the same) :P 17:36 -!- cenuij [~cenuij@78.112.175.207] has joined #go-nuts 17:36 -!- cenuij [~cenuij@78.112.175.207] has quit [Changing host] 17:36 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts 17:37 < waqas> The one line would not have included all your tests and stuff ^^ 17:38 < xyproto> waqas: yeah, it's a simple app. On the other hand, it has a manpage, an Arch package, a windows executable and a webpage. I wanted to see how the whole fluff for a single Go-app would appear, before trying to write something I cared about 17:39 < xyproto> waqas: my discovery is that it's a smooth ride, with the exception of the Go-syntax being different for different go-packages on Arch (because it changes relatively quickly) 17:40 < waqas> Did you cross compile for windows? 17:40 < xyproto> waqas: also, it has a few tricks up its sleeve that would take some work with a bash script, like finding a good insertion point for includes, and "fixing" includes, so that just "stdio" on the commandline becomes "#include <stdio.h>" 17:40 < xyproto> waqas: yes 17:40 < waqas> Yeah, just noticed the tricks. Nice. 17:41 < xyproto> waqas: but, by all means, it's a small and slightly silly app :) 17:41 < waqas> How easy was cross compiling? I assume it required windows .lib files or something? 17:41 < xyproto> waqas: sorry, it wasn't cross compiling. I used a windows-computer at work to compile it. 17:42 < waqas> Ah, k 17:42 < xyproto> waqas: also, I've learned about a few things, like gofmt and the _tests-files since I wrote it :) 17:45 < waqas> xyproto: I was surprised at the executable size. Just noticed UPX :) 17:46 < xyproto> waqas: yeah, I used upx to work around that pacman said the executable had references to the directory it was built in 17:46 < xyproto> waqas: normally, the executables are stripped automatically, but strip bugs on go executables, so I tried using upx 17:46 < xyproto> waqas: not that upx is all that great (the executable starts a lot slower, for example), but still 17:47 < xyproto> waqas: the next version of the package will not use upx 17:48 < xyproto> waqas: ...unless you're talking about the windows version? :) 17:48 < str1ngs> upx strips? 17:48 < nsf> upx compresses 17:49 < str1ngs> ah gotcha 17:49 < xyproto> str1ngs: no, but it hides the references to the directory it was built in, which stops makepkg from complaining... 17:49 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-174-251.clienti.tiscali.it] has quit [Ping timeout: 276 seconds] 17:49 < xyproto> compresses, yes 17:49 < xyproto> it's not a great solution, though 17:50 < nsf> good for embedded systems 17:50 < xyproto> yeah, good point 17:50 < nsf> if you mean in general :) 17:50 < str1ngs> is it a cgo or go package? 17:50 < xyproto> mostly as a strip replacement ;) 17:50 < xyproto> str1ngs: go 17:50 < waqas> xyproto: I noticed the windows version's size, since the binary is linked right there. 17:50 < nsf> it's not a replacement, but a complement 17:50 < xyproto> waqas: I see 17:50 < str1ngs> xyproto: ah might try building it with gccgo 17:50 < str1ngs> but that adds a libgo.so depend 17:51 < xyproto> str1ngs: yeah, that's an option 17:51 < str1ngs> hmm is there away to strip *.a 's? 17:51 < nsf> there is a linker command 17:51 < nsf> 6l -s or something 17:51 < str1ngs> ah so link withugh debugging 17:51 < nsf> I don't remember 17:52 -!- aho [~nya@fuld-590c6ac3.pool.mediaWays.net] has quit [Quit: EXEC_over.METHOD_SUBLIMATION] 17:52 < xyproto> the next version of strip will supposedly work better with go executables, so my plan was just to wait a bit 17:52 < str1ngs> xyproto: gccgo make pretty small binaries. but it requires gcc 4.6 and a gold linker which arch already uses 17:52 < nsf> but maybe it won't solve your issue 17:53 < str1ngs> arch doesnt use 4.6 though of course :P 17:53 < nsf> str1ngs: uhm? arch uses ld by default 17:53 < xyproto> str1ngs: when gcc 4.6 comes out, it's probably a good option for Go applications on Arch :) 17:54 < str1ngs> nsf: arch uses gold 17:54 < nsf> str1ngs: uhm, I didn't noticed it 17:54 < str1ngs> xyproto: possibly I need to play with gcc more 17:54 < nsf> I haven't noticed* 17:54 < nsf> and gcc4.6 is out 17:54 < nsf> maybe not in archlinux though 17:55 -!- sauerbraten [~sauerbrat@p508CCEBC.dip.t-dialin.net] has joined #go-nuts 17:55 < gmilleramilar> if I have a "var a [8]mytype", how do I pass an array pointer to a CGO call? 17:56 < waqas> I wonder how much strip could possibly help. In my executables I suspect most of the size comes from unicode tables and reflection data required by the fmt and strings packages. 17:57 < str1ngs> gmilleramilar: it depends on the CGO call some times you can just do something like C.CString("test") other times you can pass just a *[0]uint8 17:57 < nsf> gmilleramilar: &a[0]? 17:58 < gmilleramilar> nsf: certanly compiles 17:59 < nsf> should work too 17:59 < nsf> :) 17:59 < str1ngs> nsf: 4.6 is out? 17:59 < gmilleramilar> nsf should really stand for "no seg fault" 17:59 < gmilleramilar> works 17:59 < nsf> str1ngs: yes 17:59 < str1ngs> nsf: yay I can stop useing my snapshot then 18:00 < nsf> str1ngs: but as I've said maybe not yet in archlinux 18:00 < str1ngs> nsf: thats fine I have my own tool chain 18:00 < nsf> for some reason it's not even flagged out-of-date 18:00 < str1ngs> in /opt just to piss you offf :P 18:00 < nsf> http://gcc.gnu.org/ 18:00 < str1ngs> go flag it piss allan off 18:00 < nsf> but that page says it's out 18:01 < nsf> :D 18:01 < str1ngs> why no gcc 4.5.. it was released this morning..wtf 18:02 < str1ngs> err 4.6 18:02 -!- wrtp [~rog@92.17.43.168] has joined #go-nuts 18:02 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts 18:04 < nsf> ah, looks like gcc 4.6 is still an RC 18:04 < nsf> or not, I don't know 18:04 < nsf> and I don't care 18:04 < nsf> why am I saying this 18:04 < nsf> :\ 18:07 < str1ngs> its in RC still only snapshots 18:07 -!- sysiphus [~opera@unaffiliated/sysiphus] has quit [Quit: sysiphus] 18:08 < steven> do we have generics yet? 18:08 < waqas> No 18:11 < steven> sweet 18:11 < steven> a combination of for-range over chan plus the right side only evaluating once, means my code is smalll 18:11 < steven> <3 18:11 -!- Urmel| [~11087Urme@82-136-196-44.ip.telfort.nl] has quit [Ping timeout: 264 seconds] 18:12 < steven> for event := range RegisterForEvents() { ... } 18:12 -!- Urmel| [~11087Urme@82-136-196-44.ip.telfort.nl] has joined #go-nuts 18:20 -!- rtharper [~tomh@unaffiliated/sioraiocht] has joined #go-nuts 18:20 < steven> where RegisterForEvents actually creates a new channel, adds it to its channels slice (which is looped over and an event is sent to each channel every time), and returns that channel 18:20 < steven> WIN. 18:22 -!- virtualsue [~chatzilla@nat/cisco/x-qrjjlbatpccutdja] has joined #go-nuts 18:24 < wrtp> steven: you do need to make sure the sender isn't iterating over the channel slice when RegisterForEvents adds it 18:24 < wrtp> often you can do that by making the registration something you send to the central goroutine 18:26 < steven> wrtp: umm 18:27 < steven> see this is why i wanted to avoid channels and goroutines 18:27 < steven> its like 2D vs 3D 18:27 < steven> you're adding an extra dimension 18:27 -!- waqas [~waqas@jaim.at] has left #go-nuts [] 18:27 -!- tensorpudding [~user@99.148.205.193] has quit [Read error: Connection reset by peer] 18:27 < steven> its like playing normal chess vs 3D chess 18:28 < wrtp> steven: naah, it's not that hard 18:28 < steven> right now im going to assume that events are only registered for before the main runloop is started 18:28 < steven> ie, before any events can ever be generated and issued 18:29 < wrtp> that's a reasonable assumption 18:29 < steven> later i can worry about making it more robust in the face of late-registration 18:29 < wrtp> (and easy to enforce) 18:30 -!- keithcascio [~keithcasc@nat/google/x-toozphnnaziiiiev] has joined #go-nuts 18:30 < skelterjohn> wrtp: if you use theSliceOfChans = append(theSliceOfChans, theNewChan), then I think you will be safe, even if it's iterating at the same time 18:31 < skelterjohn> because the iteration will be had over the old slice, which is not changed 18:31 < skelterjohn> the underlying array can have something extra, but it won't mess with the old slice because it will be after its bound 18:31 < skelterjohn> and if there is reallocation, you're even safer 18:34 < wrtp> skelterjohn: you won't be safe, because slice assignment is not atomic 18:34 < skelterjohn> you aren't changing any slices 18:34 < skelterjohn> you are only potentially writing to the array 18:35 < skelterjohn> but in a way that doesn't affect the old slice 18:35 < wrtp> yes you are, you're changing the slice theSliceOfChans 18:35 < wrtp> you're assigning a new value to it 18:35 < skelterjohn> but when you do range theSliceOfChans 18:35 < skelterjohn> it doesn't evaluate the symbol theSliceOfChans each time you iterate 18:35 < skelterjohn> it does it once at the beginning 18:36 < wrtp> yes, it evaluates it once, but that might be the exact time that you're assigning to it 18:36 < skelterjohn> you never are changing an existing slice when you add a new channel 18:36 < skelterjohn> you're only creating new ones 18:36 < wrtp> you're assigning to the *value* of a slice 18:36 < skelterjohn> oh i see 18:36 -!- Fish- [~Fish@9fans.fr] has joined #go-nuts 18:36 < skelterjohn> you're saying the = bit 18:37 < wrtp> yes 18:37 < skelterjohn> ok 18:37 < wrtp> "don't communicate by sharing memory" :-) 18:40 -!- rutkowski [~adrian@078088215197.walbrzych.vectranet.pl] has joined #go-nuts 18:42 -!- olegfink [~olegfink@92-100-140-59.dynamic.avangarddsl.ru] has joined #go-nuts 18:43 < kimelto> is reflection in Go more complex than accessing an hidden array? 18:44 -!- femtoo [~femto@95-89-249-242-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 18:44 < kimelto> in other words, is caching reflections information in an array worth it? 18:44 -!- tvw [~tv@212.79.9.150] has quit [Remote host closed the connection] 18:45 -!- artefon [~thiago@dhcp37.usuarios.dcc.ufmg.br] has quit [Quit: bye] 18:48 < skelterjohn> depends on what you mean by "worth it" 18:48 < skelterjohn> presumably to cache the information, you need to use reflect to get it in the first place 18:48 < skelterjohn> so in one sense, it'd be "simpler" to not worry about caching, and just use reflect each time 18:48 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 252 seconds] 18:49 -!- skejoe_ [~skejoe@188.114.142.162] has quit [Quit: Lost terminal] 18:49 -!- perdix [~mkhl@sxemacs/devel/perdix] has quit [Remote host closed the connection] 18:50 < steven> isnt reflect package about to get a whole lot faster soon? 18:50 < steven> didint somene say that? 18:50 < steven> im still waiting 18:50 < steven> (for that to happen) 18:50 < kimelto> :) 18:50 < plexdev> http://is.gd/2iO9Ft by [Robert Griesemer] in go/src/pkg/go/parser/ -- go/parser: resolve identifiers properly 18:52 < kimelto> skelterjohn: here worth it means, will it make a noticeable difference in performance. 18:52 < wrtp> steven: it should get faster, but i don't know by how much. the first CL has been posted to golang-dev 18:53 < skelterjohn> kimelto: is it slow if you don't cache? 18:53 < skelterjohn> do the easy part first, and then decide if you need to do the hard part 18:53 < wrtp> kimelto: depends what you're caching 18:53 < wrtp> if you're just getting the type of something, then it's very quick 18:53 < wrtp> since the type is just a pointer within the interface anyway 18:54 < wrtp> it can become worth it to cache things if you can build up (say) a closure or a virtual machine that encapsulates what you want to do with the type 18:54 < kimelto> wrtp: thanks 18:54 < steven> wrtp: CL? 18:54 < wrtp> change list 18:55 < wrtp> see the thread with the subject "reflect changes" 18:57 -!- perdix [~mkhl@sxemacs/devel/perdix] has joined #go-nuts 18:57 -!- rtharper [~tomh@unaffiliated/sioraiocht] has quit [Remote host closed the connection] 18:57 < wrtp> oh why oh why is search on google groups so broken? 18:59 < wrtp> can anyone find that thread in google groups? searching for "reflect changes" (the subject) does not find it. adding "vaguely" (which is in the first post in the thread) causes it to find nothing. fail. 18:59 -!- olegfink [~olegfink@92-100-140-59.dynamic.avangarddsl.ru] has quit [Ping timeout: 240 seconds] 19:00 < nsf> wrtp: http://groups.google.com/group/golang-dev/browse_thread/thread/cc0a55ce898fdaa1# 19:00 < nsf> it's in golang-dev 19:07 < skelterjohn> https://groups.google.com/d/topic/golang-dev/wc8dyzWrP4E/discussion <- well, I guess adj has gone and completely cloned gb 19:07 < skelterjohn> adg i mean 19:07 -!- aimxhaisse [~mxs@buffout.org] has joined #go-nuts 19:07 < skelterjohn> kind of discouraging, but it's just code 19:09 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts 19:10 < wrtp> nsf: did you manage to search for it? or did you just scroll down until you found it? 19:10 < nsf> scrolling 19:10 < nsf> :) 19:10 < ww> x 19:10 < nsf> I haven't tried the search, I just remember I saw it recently 19:11 * ww apologises for the outburst of x 19:14 -!- olegfink [~olegfink@ppp92-100-67-127.pppoe.avangarddsl.ru] has joined #go-nuts 19:17 < steven> hahaha 19:17 < steven> <3 ww 19:21 < TheSeeker> There's not a single gsoc program wither about or using go? :( 19:22 -!- saschpe [~quassel@opensuse/member/saschpe] has joined #go-nuts 19:22 -!- rutkowski [~adrian@078088215197.walbrzych.vectranet.pl] has left #go-nuts ["WeeChat 0.3.3-dev"] 19:24 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 19:27 -!- artefon [~thiago@189.26.238.78] has joined #go-nuts 19:31 < tensai_cirno> TheSeeker, found only that → http://www.rtems.org/wiki/index.php/GCCGoRTEMS 19:35 < bugQ> I think it's a policy thing, since mentors can't come from google 19:37 < steven> TheSeeker: what? 19:38 < steven> TheSeeker: what ar eyou looking for? 19:40 -!- jeng [~jeng@74.194.1.28] has joined #go-nuts 19:45 < tensai_cirno> steven, you are mentor? 19:45 -!- rtharper [~tomh@unaffiliated/sioraiocht] has joined #go-nuts 19:48 -!- waqas [~waqas@jaim.at] has joined #go-nuts 19:48 < steven> sure? 19:48 < steven> huh? 20:03 < steven> tensai_cirno: im confused 20:03 < steven> what do you mean? 20:05 < skelterjohn> gsoc = google summer of code 20:05 < skelterjohn> a gsoc mentor is someone who runs a gsoc project 20:05 < skelterjohn> students link up with mentors to do fun projects 20:07 -!- dfc [~dfc@124-169-149-145.dyn.iinet.net.au] has joined #go-nuts 20:10 -!- TheMue [~TheMue@p5DDF7009.dip.t-dialin.net] has joined #go-nuts 20:11 -!- dju_ [dju@fsf/member/dju] has joined #go-nuts 20:11 -!- olegfink [~olegfink@ppp92-100-67-127.pppoe.avangarddsl.ru] has quit [Read error: Operation timed out] 20:13 * waqas quite likes Go's use of interfaces 20:13 < waqas> It's influencing this HTTP server framework I'm writing in Lua 20:14 -!- dju [dju@fsf/member/dju] has quit [Ping timeout: 252 seconds] 20:14 -!- napsy [~luka@88.200.96.18] has quit [Quit: Lost terminal] 20:14 < ww> I thInk we (OKF) may be having some gsoc students 20:14 -!- saschpe [~quassel@opensuse/member/saschpe] has quit [Remote host closed the connection] 20:14 < ww> not on projects involving go though (of which there are no official ones) 20:16 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-175-70.clienti.tiscali.it] has joined #go-nuts 20:16 -!- napsy [~luka@88.200.96.18] has joined #go-nuts 20:18 < tensai_cirno> ww, OKF? 20:19 < ww> http://okfn.org/ 20:20 < steven> waqas: be careful about empty interfaces 20:20 < TheMue> wow, exchanged the network communication of my redis client from net/textproto to net (due to problems with binary data) and my existing unit tests are green with the first run. fine 20:20 < steven> good way to push what could be compile-time errors into runtime panics 20:20 < steven> for little benefit 20:21 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Quit: Leaving] 20:22 < waqas> steven: Lua doesn't have interfaces :) 20:22 < steven> just dont get carried away with it 20:23 < steven> when you get a new sword for your birthday, just because its a cool sword doesnt mean you need to go around killing everyone in your neighborhood with it 20:23 < steven> instead, you use it when you need to defend your people from enemies. 20:23 < steven> same with interfaces. dont overuse it just because its new and shiney 20:23 < steven> use it only when its the right tool 20:23 < steven> :) 20:25 < waqas> In this case what I liked was the use of codec-like interfaces, which allowed composition and chaining. 20:26 -!- nsf [~nsf@jiss.convex.ru] has quit [Ping timeout: 250 seconds] 20:26 < kamaji> waqas: Could you rephrase that? 20:27 < kamaji> as in function composition? 20:29 < bugQ> chaining I think refers to the monadic style of performing methods directly on return values 20:31 < bugQ> in imperative oop langs this often looks like a chain of dot operators 20:31 -!- waqas [~waqas@jaim.at] has left #go-nuts [] 20:32 -!- waqas [~waqas@jaim.at] has joined #go-nuts 20:33 < str1ngs> steven: i just hit my dog over the head with a shiny new interface{} he's not impressed 20:35 -!- olegfink [~olegfink@ppp92-100-67-127.pppoe.avangarddsl.ru] has joined #go-nuts 20:36 -!- rutkowski [~adrian@078088215197.walbrzych.vectranet.pl] has joined #go-nuts 20:37 < kamaji> bugQ: hmm ok, but how does that relate to interfaces? I feel a bit dumb :D 20:39 < bugQ> kamaji: interfaces determine which methods you can use to chain 20:39 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts 20:42 < bugQ> kamaji: e.g. if you had a generic list interface with map/reduce functions or whatever, you could perform the entire map/reduce operation with a single line of code by chaining the functions together 20:44 < bugQ> that style of coding is one of Ruby's selling points, and it's also similar to how monads in Haskell work 20:44 < bugQ> but just as viable in Go or Lua 20:44 < aiju> i can do everything in C with a line, it just gets very long ;P 20:45 -!- perdix [~mkhl@sxemacs/devel/perdix] has left #go-nuts ["Closing this World…"] 20:45 < kamaji> bugQ: that makes loads more sense now 20:45 < kamaji> cheers :) 20:45 < kamaji> actually I was sort of thinking of doing a half-arsed version of that on top of gomatrix ^^ 20:47 < kamaji> Can I use range on slices and maps without having to check if something is which? 20:47 < aiju> kamaji: you mean without a type checking? 20:47 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Ping timeout: 276 seconds] 20:48 < kamaji> aiju: that was a dumb question, wasn't it ^^ 20:48 < kamaji> I can't anyway since the map is string -> float64 20:49 -!- pharris [~Adium@rhgw.opentext.com] has quit [Quit: Leaving.] 20:52 -!- waqas [~waqas@jaim.at] has left #go-nuts [] 20:55 -!- jeng [~jeng@74.194.1.28] has quit [Quit: ChatZilla 0.9.86.1 [Firefox 4.0/20110318052756]] 21:03 < bugQ> kamaji: well they say there are no stupid questions 21:04 < bugQ> syntactically speaking the range expression doesn't involve explicit types 21:05 < bugQ> but the compiler has to know 21:06 < bugQ> so it will should you if you're using it on something you shouldn't 21:06 < bugQ> s/will should/should tell/ 21:07 < kamaji> I didn't even realise there was a problem with that sentence 21:07 < kamaji> hehe 21:07 < kamaji> but yeah, understood! thanks 21:15 -!- nrl [~nrl@pdpc/supporter/active/nrl] has joined #go-nuts 21:18 -!- plainhao [~plainhao@208.75.85.237] has quit [Quit: plainhao] 21:19 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has quit [Quit: skelterjohn] 21:26 -!- jbooth1 [~jay@209.249.216.2] has quit [Quit: Leaving.] 21:28 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 248 seconds] 21:28 -!- waqas [~waqas@jaim.at] has joined #go-nuts 21:28 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 21:31 < steven> i cant wait for generics 21:31 < steven> im so upset that we dont have them already. 21:31 < steven> i want Map() damnit. 21:31 < steven> and Reduce() 21:32 < steven> and etc 21:32 < aiju> haha 21:32 -!- dfc [~dfc@124-169-149-145.dyn.iinet.net.au] has quit [Quit: dfc] 21:32 -!- zozoR [~Morten@56344966.rev.stofanet.dk] has quit [Remote host closed the connection] 21:34 -!- sauerbraten [~sauerbrat@p508CCEBC.dip.t-dialin.net] has quit [Remote host closed the connection] 21:35 -!- rutkowski [~adrian@078088215197.walbrzych.vectranet.pl] has quit [Quit: WeeChat 0.3.3-dev] 21:39 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:481f:ae8d:9db1:e94c] has quit [Quit: Leaving.] 21:39 -!- waqas [~waqas@jaim.at] has left #go-nuts [] 21:39 < kamaji> steven: I thought I was the only one~~ 21:39 < kamaji> not really. but those would be so sexy 21:40 -!- waqas [~waqas@jaim.at] has joined #go-nuts 21:40 < kamaji> I want to write haskell in my Go 21:42 * ww ponders slice comprehensions 21:42 < str1ngs> go use haskell leave go alone damn it! :P 21:42 -!- napsy [~luka@88.200.96.18] has quit [Quit: leaving] 21:42 < kamaji> lol 21:42 <@adg> haha 21:42 <@adg> we had map, reduce, filter etc 21:42 <@adg> but theyre just inefficient 21:43 < kamaji> because of the lazy evaluation thing? 21:43 < kamaji> or lack of 21:43 <@adg> with channels you can kinda lazily evaluate 21:43 <@adg> but that causes GC problems 21:43 < kamaji> maan I haven't even looked at channels yet 21:44 < bugQ> they're called lazy streams and yeah 21:44 <@adg> and isnt very efficient as you need a goroutine for each operation 21:44 -!- imsplitbit [~imsplitbi@64.39.4.132] has quit [Quit: Bye!] 21:44 < kamaji> are goroutines still tied to threads? 21:44 < ww> adg: inefficient but makes for pretty code 21:44 <@adg> if you want efficient functional primitives you should use a language built around them, like haskell 21:45 < kamaji> I was just kidding, I just sometimes really want map 21:46 < kamaji> because it's so concise 21:46 <@adg> ww: i personally disagree. you can write much the sam stuff with for loops in a way that is more readable and easier to understand its performance characteristics 21:47 <@adg> kamaji: no goroutines are not tied to threads 21:47 < steven> kamaji: lisp ftw 21:47 -!- tensorpudding [~user@99.148.205.193] has joined #go-nuts 21:47 < str1ngs> they call it lisp for a reason just like bash :P 21:48 <@adg> kamaji: j think that is still how gccgo does it, but the main go compiler's runtime muxes goroutines on top of fewer os threads 21:48 < steven> ha 21:48 < steven> str1ngs: and ruby? ;) 21:48 <@adg> lisp ftw indeed 21:48 < str1ngs> steven: ruby's a gem 21:48 < kamaji> I had an idea 21:48 < kamaji> which may have been done 21:48 < kamaji> however: 21:49 < steven> guys, 21:49 < steven> for a go cmd project, should the cmd binary be under version control? 21:49 < aiju> ruby's the best example for a euphemism 21:49 < kamaji> If you define a system of interacting processes, in say CSP, shouldn't it be possible to generate an optimally performing scheduler specific to that system? 21:50 * ww runs shrieking from binaries in vcs 21:50 < kamaji> So instead of just generally muxing goroutines on top of threads, why can't you make that code dynamically adjust to the program 21:50 < str1ngs> gccgo use's pthreads gc multiplex's on pthreads. 21:51 < kamaji> str1ngs: I know, but i'm guessing that the main compiler doesn't do what I said 21:51 < kamaji> if the scheduler knows about which channels are connected to what, maybe it can do a better job? 21:52 < kamaji> maybe that wouldn't help at all 21:52 -!- TheMue [~TheMue@p5DDF7009.dip.t-dialin.net] has quit [Quit: TheMue] 21:53 < str1ngs> its been stated before there is room for optimization. just not right now 21:53 < kamaji> i'm just conjecturin' 21:55 < str1ngs> steven: no dont put binaries under version control. you can but its not wise 21:55 < ww> do i want to see if gccgo gets more mileage for android today? 21:57 < ww> are the instructions at http://golang.org/doc/gccgo_install.html current for a straight-ahead gccgo install? 21:57 < str1ngs> yes but I use the snapshots 21:58 < str1ngs> you can get 1) full gcc snap-shot 2) gcc-core g++ gccgo and overlay g++ and gccgo 21:59 < str1ngs> but better off with gcc full snapshot 22:02 < ww> which 4.X do you use? 22:03 < str1ngs> 4.6 of course 22:03 < ww> of course :) 22:03 < str1ngs> since gccgo is being release with 4.6 22:04 < ww> last time i actually paid attention was when i gnutered an hp 712/60 before you could run linux on one and when you still might have wanted to.... that's some time ago :P 22:04 < ww> str1ngs: i see go in 4.7... 22:04 < ww> but maybe that edge bleeds too much 22:04 < aiju> or just use gc! 22:04 -!- olegfink [~olegfink@ppp92-100-67-127.pppoe.avangarddsl.ru] has quit [Read error: Operation timed out] 22:05 -!- cenuij [~cenuij@base/student/cenuij] has quit [Read error: Connection reset by peer] 22:05 < str1ngs> ya I would try with gc first 22:05 < str1ngs> building gccgo is a while other beast. through in cross compiling and well you get the picture 22:05 < str1ngs> whole* 22:06 * ww is confused... gc? 22:06 < str1ngs> 6g 22:06 < aiju> the working go compiler 22:06 < ww> welll... working except for cgo 22:06 < str1ngs> ww: what stage are you at. you have a working 5g ? 22:07 < ww> str1ngs, oh yes. that's no problem 22:07 < ww> and i got cgo to do some of its work with the cross compiler 22:07 -!- rtharper [~tomh@unaffiliated/sioraiocht] has quit [Remote host closed the connection] 22:07 < str1ngs> so yo cross compiled go ? not native? 22:07 < ww> only when it tries to extract symbols from _cgo1.o it borks 22:07 < ww> str1ngs, yes that's easy. it basically just works 22:08 < ww> i mean, didn't cross compile go, rather built a go cross compiler 22:08 < str1ngs> ha 22:08 < str1ngs> ah that is easy to do ya 22:09 < str1ngs> can cgo even cross compile? 22:09 -!- cenuij [~cenuij@78.112.175.207] has joined #go-nuts 22:09 -!- cenuij [~cenuij@78.112.175.207] has quit [Changing host] 22:09 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts 22:09 < ww> some parts of it should directly work 22:09 < str1ngs> thats why I think if you build cgo natively you might have less issues. but that requires a whole native toolchain 22:10 < ww> elf is standard enough that it should be able to be coerced into extracting symbols 22:10 < ww> then there's just setting up the c call stack 22:11 < ww> str1ngs, right, that's a possibility as well, but waiting on the big sd card, and it will be a slow painful slog i think... 22:11 -!- virtualsue [~chatzilla@nat/cisco/x-qrjjlbatpccutdja] has quit [Ping timeout: 250 seconds] 22:11 < str1ngs> ww: well maybe shop for a native gcc should save you some work 22:11 < ww> (aside, *why* don't these android things just come with nfs or cifs kernel modules!??!?!) 22:11 < str1ngs> because there very limited with speed and resources in mind 22:12 < str1ngs> hence the limited libc. 22:12 < ww> str1ngs: right, i think you pointed me at one yesterday, just have to organise a bigger sd card and swap 22:12 < str1ngs> the linux subsystem does just enough to run the vm 22:12 < ww> s/swap/ext2 partition/ 22:13 < ww> str1ngs: limited resources is relative. i ran nfs on a sparc 1+ with a 25MHz processor and 32Mb of RAM no problem... 22:13 < str1ngs> ww: I really need to get a droid 22:13 < ww> even ran a c compiler and built whole systems from source... did take a while though 22:13 < aiju> i can't even run NFS on gigahertz machines without problems 22:13 < str1ngs> ya but how long ago what that? 22:14 < ww> some time ago, just pointing out that having the possibility of using nfs shouldn't be too much burden 22:14 -!- ronnyy [~quassel@p4FF1C577.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 22:15 < ww> str1ngs - three.co.uk just gave me one unasked 22:15 < ww> even talked me into a cheaper phone plan 22:16 * ww *shrug* 22:16 < str1ngs> ww: ML .. can you compile a simple main() with the ndk? 22:16 < ww> let's try... 22:18 -!- virtualsue [~chatzilla@cpc3-haye15-0-0-cust450.haye.cable.virginmedia.com] has joined #go-nuts 22:18 < str1ngs> disclaimer this is for educational purposes only. if your andriod catches fire its not my fault :p 22:21 -!- dfc [~dfc@sydfibre2.atlassian.com] has joined #go-nuts 22:22 < nickbp> thats a feature 22:22 < aiju> androids catching fire? 22:22 < aiju> no, that's too harmless 22:23 < aiju> androids should suffer nuclear meltdown 22:23 < ww> str1ngs: and much fiddling with c and linker flags, yes, int main(int c, char *argv[]) { printf("hello world\n"); } compiles and runs 22:25 < ww> https://gist.github.com/886031 22:25 < str1ngs> ok thats good 22:25 < str1ngs> but see Martin's post he seems to suggest issue with cgo 22:25 < ww> yes, that led me to think about gccgo 22:27 < aiju> what are you people even doing with cgo? 22:27 < str1ngs> cgo interfaces ctypes 22:28 < ww> aiju: if you want to interact with the phone in any interesting way, you have to call the android system libraries 22:28 < str1ngs> is c libs. sure it does more then that . but thats what I use it for 22:28 < str1ngs> ww: I guess syscall is not enough? 22:29 < ww> no, i think the c libraries are a bridge to the java stuff that runs the keyboard and other ui things 22:30 < ww> or maybe it is actually the other way around and the c libraries are the real deal. no clue 22:30 < ww> it might be possible to do some things like use the gps directly 22:30 < ww> where "keyboard" in my case is a picture of a keyboard that you poke with your fingers 22:31 < str1ngs> haha 22:31 < str1ngs> we've come along way 22:32 < str1ngs> stick with 5g for now 22:32 < str1ngs> read write /proc/ lol 22:33 < ww> i guess my usual "it's not portable" complaint about /proc doesn't really fly here :} 22:33 < str1ngs> nope 22:33 -!- Fish- [~Fish@9fans.fr] has quit [Quit: So Long, and Thanks for All the Fish] 22:33 < str1ngs> I dunno when everything is a file its pretty damn portable. just dont scrw up 22:36 < wrtp> kamaji: it's an interesting idea. i think rob pike's newsqueak did something like that. 22:37 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit: Verlassend] 22:37 < wrtp> but it's difficult in Go because channels are dynamic 22:37 < wrtp> so connection topology is also dynamic 22:38 < wrtp> when the compiler gets escape analysis, perhaps it could be done on channels too, which could potentially find out some topology informaton 22:40 < kamaji> wrtp: Oh I didn't realise that, does that mean it's closer to Ambient calculus than CSP? 22:40 < kamaji> is it actually based off one of those systems? 22:40 < kamaji> or pi maybe 22:41 -!- rlab [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 22:42 < wrtp> kamaji: it's not actually based off one of those systems, but yes it could probably be considered more similar to one of those 22:42 < wrtp> channels are first class values 22:43 < wrtp> (which is great, BTW, because passing a channel down a channel is a great way to do bidirectional communication) 22:43 < kamaji> ..... what does that even mean :D 22:43 < kamaji> oh I guess it would be like IP address 22:43 < kamaji> in terms of TCP/IP anyway 22:43 < kamaji> still weird :D 22:44 < wrtp> it's not weird really. as you say, it's a bit like passing around a tcp address 22:44 < wrtp> except that channels are typed 22:45 < kamaji> And unidirectional? 22:45 < wrtp> kinda 22:45 < wrtp> a channel is unidirectional but there's only one "end" 22:45 < wrtp> or at least, the same object names both ends 22:46 < wrtp> so i can do: c := make(chan bool, 1); c <- true; <-c 22:46 < wrtp> putting a value inside the channel buffer and then retrieving it again 22:46 < wrtp> you can type-restrict a channel to sending or receiving only 22:47 < wrtp> c := make(chan bool); var recvOnly <-chan bool = c 22:47 < kamaji> should that be "_ <- c" ? 22:47 < kamaji> i'm assuming it's a read and discard value ? 22:47 < wrtp> kamaji: no 22:48 < wrtp> yeah, but you can discard the value of any expression 22:48 -!- ExtraSpice [XtraSpice@88.118.35.153] has quit [Read error: Connection reset by peer] 22:48 < wrtp> and <-c is just an expression 22:48 < kamaji> oh right, that's just for multiple returns isn't it 22:48 < wrtp> yup 22:48 < kamaji> I quite like _, it's used in XC as well 22:48 < wrtp> XC? 22:48 < kamaji> XMOS' language 22:48 < wrtp> it's used in some functional languages too 22:49 < aiju> _ goes back to Prolog 22:49 < kamaji> it's basically C with first class channels, multiple return values, timers, etc. 22:49 < kamaji> but designed for a specific chip in mind 22:49 < kamaji> it's XMOS' thing 22:49 < wrtp> i'll have a look some time 22:49 < wrtp> go 22:49 < wrtp> tt 22:49 < wrtp> gotta head bedwards now 22:49 < kamaji> righto 22:49 < kamaji> have a good sleep 22:49 < kamaji> thanks for the tutorial :D 22:50 < wrtp> have fun - read the spec, it's well worth it 22:50 < wrtp> ttfn 22:50 -!- wrtp [~rog@92.17.43.168] has quit [Quit: wrtp] 22:51 < str1ngs> ww: I'm looking a guru plug might be better then android for this 22:51 < ww> aiju: just you wait. i will implement prolog in go yet 22:51 < ww> str1ngs: as a build environment? quite possibly 22:52 < aiju> ww: i started doing it 22:52 < ww> really? 22:52 < aiju> yeah 22:52 < aiju> with goroutines and hookers 22:52 < str1ngs> who doesnt like hookers 22:52 < str1ngs> wait nvm 22:52 < kamaji> ww: What I like about Go is that with enough time and effort you can recreate all your favourite languages in it :D 22:52 * ww suspects aiju lives near oranienstr 22:53 < aiju> problems made a rewrite necessary and well, i haven't looked into it further 22:53 < aiju> wtfi oranienstr? 22:53 < ww> but seriously... i'm really interested in prolog-like things for handling inference rules with rdf 22:54 < ww> aiju do i misremember you as german? 22:54 < kamaji> oh man, that reminds me 22:54 < aiju> ww: no, i am german 22:54 < kamaji> ww: check out the porter stemmer prolog implementation http://tartarus.org/~martin/PorterStemmer/prolog.txt 22:55 < kamaji> I cannot read that _at all_ 22:55 * ww used to live in berlin... 22:55 < aiju> i've never been to berlin 22:55 < ww> orianienstr is best avoided at night due to hookers 22:55 < aiju> oic 22:57 < ww> kamaji: for what i'm doing i don't need all of prolog, but do need back-chaining 23:03 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has joined #go-nuts 23:07 < kamaji> ww: I don't really know prolog, I just thought that program was amusing 23:18 < kamaji> Can I use my own types in a type switch? 23:18 <@adg> kamaji: of course 23:19 < kamaji> adg: i'm getting "Unknown label" 23:19 < kamaji> oh, does it have to be main.Type 23:20 -!- skelterjohn [~jasmuth@c-68-46-33-145.hsd1.nj.comcast.net] has joined #go-nuts 23:20 < ww> gcc takes soooo long to build.... 23:21 < skelterjohn> evening 23:22 < kamaji> oh my god i'm retarded 23:22 < kamaji> switch statements need a "case" 23:22 < kamaji> herp derp 23:22 < kamaji> ...... evening 23:23 < ww> heya skelterjohn 23:24 < plexdev> http://is.gd/bk88LG by [Devon H. O'Dell] in go/src/pkg/runtime/freebsd/386/ -- freebsd-386: update defs 23:26 < ww> on another topic, can anyone find a *normative* reference for JSON that doesn't include the whole JavaScript language? 23:26 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-175-70.clienti.tiscali.it] has quit [Quit: E se abbasso questa leva che succ...] 23:27 < kamaji> ww: is this not one? http://www.json.org/ 23:27 < kamaji> I don't know if those state machines represent the whole language 23:28 < str1ngs> ww: I build my that gcc tool chain with no frills 23:28 -!- piranha [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has quit [Quit: Computer has gone to sleep.] 23:29 < str1ngs> ww: but still takes about 35 minutes 23:31 < ww> kamaji: not complete enough, unfortunately. what about { "a": 1, "a": 2} which appears "valid". what is the behaviour in this case? 23:31 -!- boscop [~boscop@f055249238.adsl.alicedsl.de] has quit [Ping timeout: 248 seconds] 23:32 < kamaji> ww: that's valid JSON isn't it? 23:32 < kamaji> sorry, didn't quite follow 23:32 < kamaji> Do you need more than just the grammar? 23:33 < ww> which value corresponds to "a"? 23:33 < kamaji> the "string" FSA 23:33 < ww> kamaji: w3c working group trying to decide what json "is" in order to base a standard on it 23:34 < kamaji> isn't it just a document structure? 23:34 < kamaji> just like a grammar for sending data...? 23:34 < ww> it seems to be one that isn't as well defined as it seems at first glance 23:35 < kamaji> those FSAs seem ok to me... but then, you are the one trying to implement it :) 23:35 < ww> so in that case, if you write, var foo = { "a": 1, "a": 2} in javascript, and then do print(foo["a"]) what gets printed? 23:36 < kamaji> ok I may be totally misinterpreting your question 23:36 < kamaji> you're not asking "how do I parse JSON", you're asking "what do I do with a JSON object"? 23:37 < kamaji> bit confused :) 23:37 < ww> i'm asking, where is the spec that tells you what is and isn't valid json and covers behaviour in corner cases like this 23:39 < kamaji> ok, that page says "Excepting a few encoding details, that completely describes the language." 23:39 < kamaji> so those FSAs basically fully describe the language 23:39 < kamaji> that javascript assignment I believe would be outside the scope of the language itself 23:39 < kamaji> and i'm not sure what's "corner" about that case? 23:40 < waqas> Names within a JSON object are not required to be unique by the way. It's a SHOULD in the RFC. 23:40 < kamaji> oh oh I just got that.... sorry >_> 23:41 < waqas> An API could choose to return all values instead of just one. That's not part of the JSON definition. 23:41 < kamaji> So I guess it is outside the scope? 23:43 < jessta> it's a hashmap, so I'd expect the second value to override the first 23:43 < jessta> which is what javascript does 23:43 < waqas> jessta: The JSON spec doesn't say it's a hashmap. 23:44 < kamaji> javascript implementation is a hashmap I guess he means 23:44 < waqas> Indeed, most languages' is. 23:44 < kamaji> I'm really bad at reading comprehension today :D 23:44 < kamaji> I keep re-reading things and wondering how I misinterpreted them so badly 23:45 < kamaji> sigh 23:46 < waqas> Now I'm curious what the ecmascript spec says 23:47 < waqas> Anyway, this goes beyond syntax into semantics beyond what FSA/CFGs are capable of expressing. 23:49 < ww> waqas: plenty of background discussion on the list: http://lists.w3.org/Archives/Public/public-rdf-wg/2011Mar/ 23:49 < jessta> waqas: "A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array." 23:49 < ww> particularly one chap who's being very insistent on not quite understanding what the spec actually is 23:49 < jessta> note that the 'object' is actually in italics 23:50 < ww> and particularly in the case of multiple identical keys which comes up often in rdf, which is a SHOULD in the RFC and almost no parser in existence will really give you back a list... (so just put a list in as value in the first place? of course, obvious) 23:50 < jessta> and the rest implies strongly that the behaviour is expected to be a hashmap 23:51 < ww> other corner cases are what happens with keys that are uris (and we need to be very careful about encoding because that matters in rdf, so may end up putting more stringent requirements on json) 23:51 < ww> and things like colons in the keys for curie values... 23:51 < ww> it seems like a bit much worry to me honestly, i don't really think these are big problems 23:52 < kamaji> hmmmmm, what's the type of 'f' in 'f := "foo".(type)' ? 23:52 < ww> does ecmascript allow invalid characters in dictionary keys? unsure. does the rfc? yes 23:53 < ww> "invalid" meaning contains, e.g. : 23:53 < steven> kamaji: type, if it succeeds 23:54 < kamaji> type or Type? 23:54 < kamaji> I mean reflect.Type 23:54 < kamaji> is type a type? oh god ;_; 23:54 -!- jgonzalez [~jgonzalez@173-14-137-134-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 248 seconds] 23:55 < waqas> Interesting. The ecmascript spec's algorithm makes ({"a":1,"a":2}).a == 2, i.e., the last value. 23:56 < waqas> ww: : is invalid in keys? 23:56 < waqas> You mean without quoting? 23:57 < kamaji> waqas: that would be consistent with a hashmap, wouldn't it? 23:57 < ww> well rdf is stricter about uris than http. so if a uri is a key you have to be guaranteed that u == decode(encode(u)) 23:58 < waqas> kamaji: I'm not sure what you mean. Are you talking about syntax or the internal representation? 23:59 < ww> and even otherwise, if i have { "foaf:nick": "ww" } is that valid? sort of... even if i cannot write foo.foaf:name in ecmascript 23:59 -!- virtualsue [~chatzilla@cpc3-haye15-0-0-cust450.haye.cable.virginmedia.com] has quit [Quit: ChatZilla 0.9.86.1 [Firefox 4.0/20110318052756]] 23:59 < ww> i suspect the behaviour is almost always like a hashmap or a dictionary. --- Log closed Fri Mar 25 00:00:09 2011