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