--- Log opened Mon Jun 27 00:00:54 2011
00:06 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has joined #go-nuts
00:11 -!- franciscosouza [~francisco@] has quit [Read error:
Connection reset by peer]
00:14 -!- kfmfe04 [~kfmfe04@host-58-114-183-56.dynamic.kbtelecom.net] has joined
00:22 -!- franciscosouza [~francisco@] has joined #go-nuts
00:42 -!- Bigbear1 [~Cody@d75-158-128-132.abhsia.telus.net] has quit [Ping
timeout: 250 seconds]
00:42 -!- cafesofie [~cafesofie@ool-18b97779.dyn.optonline.net] has joined
00:42 -!- ExtraSpice [XtraSpice@78-57-204-104.static.zebra.lt] has quit [Remote
host closed the connection]
00:43 -!- Bigbear1 [~Cody@d75-158-128-132.abhsia.telus.net] has joined #go-nuts
00:52 -!- ccc1 [~Adium@] has joined #go-nuts
01:01 -!- mikespook1 [~mikespook@] has quit [Quit: Leaving.]
01:02 -!- mikespook [~mikespook@] has joined #go-nuts
01:03 -!- wchicken [~chicken@c-71-235-58-74.hsd1.ct.comcast.net] has quit [Ping
timeout: 250 seconds]
01:08 -!- niemeyer [~niemeyer@] has joined #go-nuts
01:14 -!- niemeyer [~niemeyer@] has quit [Ping timeout: 240 seconds]
01:18 < crazy2be> how do i get an arbitrary pointer value?
01:18 < crazy2be> e.g.  a pointer to memory location 0x1
01:18 < crazy2be> i'm checking the sanity of pointers passed in and out of
Cgo code
01:18 < crazy2be> to try and find where the issues are
01:18 < crazy2be> and doing ptrType == 0x1 doesn't work
01:19 < crazy2be> since go is supposed to be safe and all
01:20 < temoto> crazy2be, why don't you check it while still in C mode?
01:22 < crazy2be> temoto: Because i'm not sure what c code is calling this
go code :/
01:23 < crazy2be> I don't quite understand why unsafe.Pointer doesn't seemt
to abide by the normal type semantics
01:23 < crazy2be> hm
01:23 < temoto> panic can help to get stacktrace
01:23 < temoto> Or gdb
01:23 < temoto> afair, gdb 7 can debug go programs
01:25 < chomp> crazy2be, you should be able to cast an unsafe.Pointer to a
uintptr and compare
01:25 < chomp> (uintptr)(unsafe.Pointer(foo)) == (uintptr)1
01:25 < crazy2be> chomp: Ah! I was trying unsafe.Uintptr
01:25 < crazy2be> which doesn't exist, of course
01:25 < chomp> :)
01:28 < crazy2be> and my cgo line numbers are *completely* messed up
01:28 < crazy2be> like normally cgo kinda generates its own wrapper files
01:29 < crazy2be> so the line numbers are a bit off
01:29 < crazy2be> this time, they are over 10 times higher than the number
of lines in the generated cgo file
01:29 < crazy2be> so like like 1269
01:29 < chomp> cgo errors can be a little tricky to debug
01:30 < chomp> what specifically are you working with?
01:30 < crazy2be> go bindings to javascript, http://github.com/crazy2be/gojs
01:30 < crazy2be> it was positively full of unsafe.Pointer()
01:31 < temoto> You mean to V8?
01:31 < chomp> webkit javascriptcore
01:31 < crazy2be> JavaScriptCore
01:31 < temoto> Oh, never heard of such name.
01:31 < crazy2be> made by apple rather than google :P
01:32 * chomp clones gojs...
01:32 < crazy2be> chomp: checkout the ughunsafe branch
01:32 < crazy2be> I was trying to remove a bunch of the unsafe stuff
01:32 < chomp> do i just need to pull Javascriptcore sources into the build
01:33 < crazy2be> yeah sudo apt-get install webkit-dev or something for me
01:33 -!- Bigbear11 [~Cody@d75-158-128-132.abhsia.telus.net] has joined #go-nuts
01:33 < crazy2be> you shouldn't need the sources, just the headers and libs
01:33 < crazy2be> but i'm not really sure how cgo does all that :P
01:34 < crazy2be> I understand c, and I understand go, but not the bridge
between them
01:36 < chomp> zounds i havent updated apt in like 2 months
01:36 < crazy2be> And I just pushed a couple of lines change to native.go
01:36 -!- franciscosouza [~francisco@] has quit [Read error:
Connection reset by peer]
01:36 -!- Bigbear1 [~Cody@d75-158-128-132.abhsia.telus.net] has quit [Ping
timeout: 276 seconds]
01:36 < crazy2be> pointer to array is a *[0]uint8, which is basically go's
01:37 < crazy2be> it used to use StructType for that, because all the cgo
types were stored in go as structs {}
01:37 < crazy2be> empty structs
01:37 -!- Bigbear11 [~Cody@d75-158-128-132.abhsia.telus.net] has quit [Client
01:37 < crazy2be> passing to cgo involved getting the unsafe.Pointer of one
of these structs
01:38 -!- franciscosouza [~francisco@] has joined #go-nuts
01:38 < chomp> hrmm i can't build the example
01:38 -!- robteix [~robteix@host243.200-82-125.telecom.net.ar] has joined #go-nuts
01:38 < crazy2be> for webkit or?
01:38 < chomp> your helloworld.go
01:39 < crazy2be> what's the error?
01:39 < chomp> ah hrm well i am using tip
01:39 < crazy2be> :P
01:39 < chomp> complaining about gojs.Exception not being a gojs.Value
01:40 < crazy2be> that's stange...
01:40 < crazy2be> are you on the ughunsafe branch?  (although they should
both compile)
01:40 < chomp> yeah
01:41 < crazy2be> what about running gotest?  Does that compile for you?
01:41 < chomp> yep, but panic.  which i assume is expected
01:41 < crazy2be> yeah
01:42 < crazy2be> hrph
01:42 -!- iwinulose [~charlesdu@c-67-188-13-8.hsd1.ca.comcast.net] has joined
01:42 < crazy2be> so the type I get back is a *[0]uint8
01:42 < crazy2be> which basically means go has no idea what it is
01:43 < chomp> get back from what where
01:43 < crazy2be> the guy who original wrote this got around that somehow by
passing a pointer to an empty struct{} into cgo
01:43 < crazy2be> in value_to_javascript()
01:45 < crazy2be> and if I put a panic("") at the start of that to see the
stack trace and get a clue what's going on
01:46 < crazy2be> then I get https://gist.github.com/1048190
01:46 < crazy2be> complete with negative line numbers!
01:47 < crazy2be> similar results for you?
01:47 < chomp> sec, poking around at some stuff
01:47 < crazy2be> :P
01:47 -!- franciscosouza_ [~francisco@] has joined #go-nuts
01:48 -!- franciscosouza [~francisco@] has quit [Read error:
Connection reset by peer]
01:49 < crazy2be> I still don't entire understand how everything is supposed
to work
01:49 < crazy2be> like how the bindings are supposed to work
01:49 -!- mikespook1 [~mikespook@] has joined #go-nuts
01:49 -!- mikespook1 [~mikespook@] has quit [Client Quit]
01:50 < crazy2be> and the lack of a proper stack trace certainly doesn't
01:50 -!- mikespook [~mikespook@] has quit [Ping timeout: 260
01:50 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has quit [Ping timeout:
260 seconds]
01:50 < chomp> ah i see.  so the problem then is that v.ctx.ref == 1?
01:50 -!- nannto__ [~nanto@pee5b70.tokyff01.ap.so-net.ne.jp] has quit [Quit:
01:51 < chomp> sorry still wrapping my head around exactly what's happening
01:52 < crazy2be> don't worry, so am I
01:52 < crazy2be> :P
01:52 < crazy2be> yeah it was 0x1
01:52 < crazy2be> which is obviously an invalid pointer value
01:53 < crazy2be> but that's curious
01:53 < crazy2be> because if it was uninitialized it would be 0
01:53 < chomp> because that means EvaluateScript is returning a Value with
01:53 < crazy2be> since go zero-initializes everything
01:53 -!- nannto [~nanto@pee5b70.tokyff01.ap.so-net.ne.jp] has joined #go-nuts
01:55 < chomp> ok so
01:56 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has joined #go-nuts
01:56 < crazy2be> but I think that was because there was unsafe.Pointer()
somewhere else initializing that
01:57 < chomp> the javascriptcore library provides no definition of the
layout of OpaqueJSValue which is what JSEvaluateScript returns
01:57 < chomp> that would be why go gives you a *uint[0]
01:58 < chomp> though that...  shouldn't matter
01:59 -!- lugu [~ludo@] has quit [Quit: leaving]
01:59 < chomp> ah ok so you're giving NewValue the *uint[0] as an
02:00 < chomp> yeah i see
02:00 < chomp> that won't fly
02:01 < chomp> wait a second...
02:04 < crazy2be> Ah HA
02:04 < crazy2be> found one error
02:05 < crazy2be> ctx.EvaluateScript() was using ctx.NewValue rather than
02:05 < chomp> that would explain why i couldn't make sense of this
02:05 < crazy2be> the former initializes a js object from a go type, the
latter makes a new value object from a native javascript type
02:06 < chomp> yeah ok
02:06 < crazy2be> which is kindof a silly distinction for such a small
difference in name
02:06 < crazy2be> but I made NewObject() and NewException() before making
02:06 < chomp> didn't see newValue at all.  noticed that were was all this
reflection going on yet the incoming value should have always been a C.JSValueRef
02:06 < crazy2be> and then realized the name was taken
02:07 < crazy2be> yeah it's a monster of a library
02:07 < crazy2be> I'm trying to make it a bit saner
02:07 < chomp> one way to go would be to wrap the existing library in a more
cgo-friendly C interface
02:08 < crazy2be> in what way?
02:08 -!- robteix [~robteix@host243.200-82-125.telecom.net.ar] has quit [Quit:
02:08 < chomp> heh well i don't know much about the library so it's hard to
02:09 < chomp> i guess it's fairly straightforward is it is.  all the data
coming from C is just opaque pointers
02:11 < smw> Is there any type of thread pool library for Go?
02:11 < chomp> native.go feels a bit
02:11 < chomp> nasty
02:12 < crazy2be> yeah
02:13 < crazy2be> like this one
02:13 < crazy2be> func nativecallback_CallAsFunction_go(data_ptr
unsafe.Pointer, ctx unsafe.Pointer, obj unsafe.Pointer, thisObject unsafe.Pointer,
argumentCount uint, arguments unsafe.Pointer, exception *unsafe.Pointer)
unsafe.Pointer {
02:13 < chomp> smw, there aren't really proper threads in go at all
02:13 < smw> chomp, I knew that.  But is there a go routine pool?  lol
02:13 < chomp> smw, though you should be able to use a goroutine pool and
trust the scheduler to allocate schedule them on threads appropriately
02:13 < chomp> ah heh.  not familiar with one, sorry
02:14 < chomp> doesn't seem like it would be difficult to implement in a
couple lines though?
02:14 < smw> chomp, where would I find stuff like mutexes?
02:14 < chomp> spawn N goroutines, have them share a channel, done
02:14 < chomp> sync package
02:15 < chomp> though you may not want a mutex
02:15 < smw> chomp, yeah, I just want to see what other stuff they have
02:15 < chomp> crazy2be, yeah just came across that ><
02:15 < crazy2be> it's no go, it's c
02:15 < crazy2be> *not
02:15 < crazy2be> hacked into go :D
02:17 < smw> chomp, first I tried writing a prime number generator in C,
java, python, and go to compare performance.  Now I am trying to make a concurrent
version in go :-).
02:18 < smw> chomp, go held up pretty well.  Slower than C...  but faster
than java at least.
02:18 < crazy2be> smw: Really?
02:18 < crazy2be> that's pretty good
02:18 < chomp> well, it is compiled :)
02:18 < chomp> and not by a totally braindead compiler
02:18 < crazy2be> java isn't actually that slow
02:19 < crazy2be> ugly yes
02:19 < chomp> i realize java is too and is pretty "fast", but bytecode
still aint machine code
02:19 < smw> crazy2be, yep.  I was very impressed.  gccgo may be faster
02:19 < chomp> any way you shake it
02:19 < smw> my guess is that stuff like zeroing out arrays did not help go
02:19 < smw> go was half way between C and java
02:19 < smw> and python was not in the running when it took 9 seconds for
10,000 primes XD
02:20 < chomp> if you peek at the go tutorial here
http://golang.org/doc/go_tutorial.html#tmp_361 you can see a simple concurrent
prime sieve
02:20 < smw> yeah, I saw that
02:20 < smw> I want to use my current algorithm but test multiple numbers at
02:21 < chomp> actually i lied, that doesn't look concurrent at all
02:21 < chomp> or at least, it only uses one generator
02:21 < smw> it is concurrent...
02:21 < smw> but not what I am looking for :-)
02:22 < chomp> it's concurrent but not in the sense that multiple coroutines
are working on prime generation
02:22 < smw> right
02:22 -!- franciscosouza [~francisco@] has quit [Read error:
Connection reset by peer]
02:23 < smw> chomp, is there a way to send something like a kill signal to a
routine?  Even if it is working?
02:23 < chomp> no
02:23 < crazy2be> smw: Select on two channels if you can
02:23 < chomp> that'd be about it
02:23 < chomp> unless it's looking for a signal though no
02:23 < crazy2be> what are you trying to acheive?
02:23 -!- franciscosouza [~francisco@] has joined #go-nuts
02:24 -!- flaguy48 [~gmallard@user-0c6s350.cable.mindspring.com] has left #go-nuts
02:24 < crazy2be> chances are you can acheive it, but not though a kill
02:25 < smw> crazy2be, if a prime number generator is working on a really
big number and then I decide to kill the program in another go routine, how do I
kill the prime generator?
02:25 < crazy2be> why do you want to kill it?
02:25 < crazy2be> is it taking too long?
02:25 < smw> crazy2be, because I decided to quit and I don't want to wait
for the computation to finish
02:25 < crazy2be> I meant to say you could probably acheive it, but not by
killing it
02:26 < crazy2be> not unless you design your algorithm to check if it should
die every so often
02:26 < smw> crazy2be, as you can see, there is no real program, so there is
no real problem.  This is a hypothetical ;-).
02:27 < chomp> if you have some piece of code which is just crunching on
numbers, it's not even yielding the cpu let alone responding to outside signals
02:27 < chomp> i mean it'll yield to the kernel but thats it
02:27 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has quit [Read error:
Operation timed out]
02:28 < smw> chomp, ok.  How do programs receive signals when I send a kill?
02:29 < chomp> when you send a kill, init will kill the process
02:30 < chomp> and then it won't be scheduled any more
02:30 < smw> but the program can capture the kill
02:30 < chomp> yes that is true, you can capture the kill
02:30 < smw> it is a signal of some sort
02:31 < chomp> but that doesn't change anything really ...
02:31 < smw> it stops normal execution
02:31 < crazy2be> does it?
02:31 < smw> I believe so
02:31 < smw> doesn't it?
02:31 < crazy2be> I've had plenty of programs not respont to kill signals
02:32 < crazy2be> I have to killall -s 9 them
02:32 < chomp> if you trap KILL you can do whatever you want but for one
thing that's probably a terrible idea
02:32 < smw> yeah
02:33 < crazy2be> "Signal handlers can be installed with the signal() system
call.  If a signal handler is not installed for a particular signal, the default
handler is used.  Otherwise the signal is intercepted and the signal handler is
invoked.  The process can also specify two default behaviors, without creating a
handler: ignore the signal (SIG_IGN) and use the default signal handler (SIG_DFL).
There are two signals which cannot be intercepted and
02:33 < crazy2be> handled: SIGKILL and SIGSTOP."
02:33 < chomp> actually on most systems you can'
02:33 < chomp> yeah there ya go.
02:33 < crazy2be> so it's basically a callback
02:34 < smw> http://en.wikipedia.org/wiki/Signal_(computing)
02:34 < smw> yes
02:34 < smw> a signal is an async callback
02:34 < chomp> of course none of this has any bearing on the fact that code
which chooses not to be aware of external signals will not be aware of external
02:34 < chomp> :)
02:35 < smw> chomp, maybe it would be possible to implement a signal system
in go!  lol
02:36 < chomp> you mean like a ...  channel?!
02:36 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has joined #go-nuts
02:36 < smw> chomp, lol...
02:37 -!- ancientlore [~ancientlo@ip68-110-238-176.dc.dc.cox.net] has joined
02:44 -!- sniper506th [~sniper506@cpe-098-122-081-186.sc.res.rr.com] has quit
[Quit: Leaving...]
02:46 < kevlar> Go already has signal handling.
02:46 < crazy2be> hey @ancientlore
02:46 < ancientlore> hey, what's up
02:46 < kevlar> KILL and STOP can't be trapped, but TERM and TSTP (which are
intended to be handled) can be
02:47 < crazy2be> kevlar: Yes, but it seems to be impossible to specify a
signal to not be handled
02:47 < kevlar> if a program doesn't die when you KILL it, that's because
it's locked in a kernel syscall; if/when it completes, it will be stopped.
02:47 < kevlar> crazy2be: in Go, yes, but it's easy to emulate the default
02:47 < crazy2be> e.g.  to specify which signals you want to handle
02:48 < kevlar> that's because signal setup needs to be done in init()
before you can specify what signals to handle
02:48 < kevlar> so they're all sent down signal.Incoming as soon as you
import "os/signal"
02:48 < crazy2be> yeah
02:48 < kevlar> I have code to do ^Z ^C and ^\ if you want.
02:48 < chomp> which caused me a great deal of pain the first time i started
playing around with it :)
02:48 -!- nannto [~nanto@pee5b70.tokyff01.ap.so-net.ne.jp] has quit [Read error:
Connection reset by peer]
02:49 < kevlar> ^Z took a while to figure out, lol.
02:49 < kevlar> hmm, I should add it to go-wiki.
02:49 < crazy2be> go-wiki?
02:49 < kevlar> http://go-wiki.googlecode.com/
02:49 < kevlar> it's the official unofficial go wiki, lol
02:50 < chomp> ^Z backgrounds the process doesnt it
02:50 -!- nannto [~nanto@pee5b70.tokyff01.ap.so-net.ne.jp] has joined #go-nuts
02:50 < kevlar> chomp: no, it sends SIGTSTP
02:50 < kevlar> which, by default, goes unhandled and causes your shell to
suspend (STOP) your process
02:50 < chomp> ah right.
02:50 < crazy2be> cool
02:51 < crazy2be> although i'm not sure how it's
02:51 < kevlar> so the trick within your app to emulate ^Z is to SIGSTOP
your own PID
02:51 < crazy2be> "unofficial"
02:51 < chomp> aha
02:51 < crazy2be> because it's members as all @golang.org
02:51 < crazy2be> *are
02:51 < crazy2be> I just can't type today :P
02:51 < kevlar> crazy2be: everyone who is in the CONTRIBUTORS file has edit
access to the wiki
02:52 < chomp> ooohhh
02:52 * chomp goes and changes everything
02:52 < smw> really?  sweet
02:52 < smw> time to start editing stuff :-)
02:52 < kevlar> I thought they sent out an email.
02:53 < chomp> maybe, i only just had something committed last week
02:54 < crazy2be> chomp: What did you commit?
02:54 -!- Nitro [~Nitro@unaffiliated/nitro] has quit [Ping timeout: 244 seconds]
02:54 < chomp> just the start of a patch to syscall, to add tty related
support to StartProcess
02:55 -!- kfmfe04 [~kfmfe04@host-58-114-183-56.dynamic.kbtelecom.net] has quit
[Ping timeout: 255 seconds]
02:55 < chomp> only changed a code generation script so far; have to wait on
its outputs to accumulate
02:57 < smw> sweet, I do have access to edit the wiki :-D
02:58 < chomp> wonder if i should attempt to get go building on this windows
box >.>
02:58 < chomp> seems windows go could use more love
02:59 < smw> for v := range myChannel {}.  Will that block if it stops
getting answers from the channel?
02:59 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has quit [Ping timeout:
255 seconds]
03:00 < smw> nm, answer is in go spec
03:05 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has joined #go-nuts
03:05 < ancientlore> any thoughts on the go packages out there for mongodb?
03:06 < chomp> perhaps you want https://github.com/mikejs/gomongo :)
03:07 < chomp> aptly named
03:07 < ancientlore> yeah, but then the go blog featured mgo - curious who
they compare
03:07 < kevlar> ancientlore: check out
03:08 < kevlar> it's always a good idea to know the popular packages, as it
means they're probably well supported and/or likely to compile with the latest Go
release or weekly
03:09 < ancientlore> they are both fairly popular it seems - I'll have to
check both out
03:18 < ancientlore> totally unrelated question.  say I am programming using
a few system calls for windows - and I used one that blocks the OS thread, like
WaitForMultipleObjects().  Does the go runtime gracefully schedule other
goroutines around that, so that it only blocks the goroutine making the call?  I
know go multiplexes goroutines on some number of OS threads.
03:19 < exch> it does detect blocking goroutines and rearranges things
accordingly.  Not sure if the windows implementation does that though
03:19 < exch> But it should
03:22 < ancientlore> ok.  is there anything you need to do when you're going
to make a blocking system call (one the blocks the OS thread as well as the
goroutine), or you just do it and let go figure it out?
03:23 < ancientlore> or maybe I should just try it and see what happens ;-)
03:27 -!- niemeyer [~niemeyer@] has joined #go-nuts
03:30 < exch> Just go with it and only worry about it if it actually ives
you truble.  That usually works for me :)
03:30 < exch> *gives *trouble
03:30 < chomp> does make me wonder how the scheduler and threads are managed
03:34 < chomp> http://is.gd/loIR46
03:34 < chomp> "when a goroutine enters a potentially blocking system call,
the scheduler will start running other goroutines on a different OS thread."
03:36 < kevlar> it's implemented by turning blocking system calls into
either (a) an OS thread or (b) an epoll/kqueue
03:36 < kevlar> things like sleep() are done with (a), things like I/O are
done with (b)
03:36 < kevlar> which is only really important if you're doing something in
tons of goroutines that might be in the (a) category
03:37 < kevlar> (if you're doing that with sleep(), you probably should
switch to timer.After)
03:37 -!- tgall_foo [~tgall@] has joined #go-nuts
03:39 -!- franciscosouza [~francisco@] has quit [Read error:
Connection reset by peer]
03:48 -!- franciscosouza [~francisco@] has joined #go-nuts
03:52 < ancientlore> interesting.  so in theory I shouldn't have to worry
too much...but should be careful too.
03:54 < crazy2be> ancientlore: working on winnotify?  :P
03:56 -!- Skola [~bas@5352A3FB.cm-6-3c.dynamic.ziggo.nl] has joined #go-nuts
03:56 -!- wchicken [~chicken@c-71-235-58-74.hsd1.ct.comcast.net] has joined
03:57 < ancientlore> hehe, just getting the info ready in case I want to use
FindFirstChangeNotification, etc.
03:57 < Skola> is there a specific kind of programs Go is aimed at / made
03:57 < crazy2be> Skola: system programs
03:57 < crazy2be> but it's really good at everything imo
03:58 < crazy2be> er, almost everything
03:58 < Skola> ok, I do complex algorhytms in Haskell, command line stuff in
Python, servers in Node.js
03:58 < Skola> where would Go fit in?
03:59 < crazy2be> I use it for command and server stuff
03:59 < crazy2be> because of the builtin multithreading
03:59 < Skola> where does it stand in terms of performance compared to
03:59 < crazy2be> depends what you're doing
04:00 < Skola> where does it shine?
04:00 < crazy2be> expect it to be slower than C/C++, but faster than node.js
04:00 < chomp> it fits in as a general purpose language that balances
performance with productivity
04:01 -!- fluffle [~camelid@s.pl0rt.org] has quit [Read error: Connection reset by
04:01 < chomp> anything i would write in C or C++, i tend to want to write
in go now
04:01 -!- fluffle [~camelid@s.pl0rt.org] has joined #go-nuts
04:01 < crazy2be> I like the tools
04:01 < crazy2be> like gofmt, godoc, gofix
04:01 < crazy2be> goinstall
04:01 < Skola> ja heard good things about the tools
04:02 < crazy2be> also it's really almost always logical what it does
04:02 < crazy2be> unlike javascript which has quite a few idiosyncrocies
04:02 < chomp> and it's a tiny language.  it doesn't have a million
marginally useful features.
04:02 < kuroneko> hmm.
04:02 < Skola> what about libs?
04:02 < crazy2be> lots of libs installable with goinstall
04:03 < crazy2be> what do you need one for?
04:03 < kuroneko> I'm busy trying to fix up some go compiler packages right
now - does anyone here know how to amend the expected failures list?
04:03 < Skola> not sure yet :P
04:03 < crazy2be> there's a list at http://godashboard.appspot.com/package
04:03 < Skola> it depends what I'd be using it for
04:03 < crazy2be> common/recently used ones
04:03 < Skola> which I'm not clear about yet
04:03 < Skola> ok thanks :)
04:04 -!- ancientlore [~ancientlo@ip68-110-238-176.dc.dc.cox.net] has quit [Quit:
~ Trillian Astra - www.trillian.im ~]
04:05 < crazy2be> node is pretty nice because of all the community support
04:05 < Skola> yeah it is
04:05 < chomp> too bad it's js D:
04:05 < crazy2be> heh
04:05 < Skola> hah yeah
04:05 < crazy2be> yeah
04:05 < crazy2be> javascript never ends up in good code for me
04:05 < crazy2be> maybe I just don't have enough practice
04:06 < Skola> CoffeeScript and functional libraries make writing it quite
enjoyable though, believe it or not
04:06 < chomp> it's an ok language and there are things i do like about
it...  but it's like python for me in that it feels so idontknowtherightword
04:06 < crazy2be> but my go code is almost always nicer than my javascript
04:06 < chomp> mushy
04:06 < chomp> crazy2be, i think it has to be the typing
04:06 < Skola> yes I'd be programming in Haskell if the web frameworks were
more mature
04:06 < chomp> i just can't be comfortable with weak types
04:06 < crazy2be> yeah *shudder*
04:07 < chomp> haskell also has its performance tradeoffs does it not
04:07 < crazy2be> works o.k.  for a small codebase
04:07 < Skola> Haskell performance is pretty amazing
04:07 < crazy2be> but anything too big
04:07 -!- rejb [~rejb@unaffiliated/rejb] has quit [Disconnected by services]
04:07 < Skola> the web frameworks are lightning fast
04:07 < Skola> but not very mature yet
04:07 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts
04:07 < chomp> thinking more in terms of computations
04:07 < crazy2be> neither are the go ones :P
04:07 < Skola> and for just raw performance its about 1 to 3x C
04:07 < chomp> though i guess that depends largely on how you write your
04:08 < crazy2be> anyway night all
04:08 < Skola> gn
04:08 < crazy2be> good luck with go
04:08 < chomp> people seem to like web.go, might want to peek at that
04:08 < Skola> cheers
04:08 < Skola> I will chomp, thanks
04:08 < crazy2be> personally I use the builtin http library and a bunch of
custom packages :P
04:09 < crazy2be> some of them are at http://github.com/crazy2be
04:09 < chomp> same, so far.
04:09 < Skola> will have a look :)
04:09 < chomp> though ive been playing more with websocket than anything
04:10 < Skola> I like the way Go syntax looks
04:10 < Skola> it's often telling
04:11 < Skola> what's the main tutorial?  the one at golang.org?
04:11 < Skola> it's for programmers familiar with C/C++
04:11 < chomp> http://golang.org/doc/effective_go.html is the most often
cited one
04:11 < Skola> My C isn't fantastic
04:11 < chomp> there's also http://golang.org/doc/go_tutorial.html
04:11 < crazy2be> night again
04:12 < chomp> night crazy2be
04:12 < Skola> gn
04:12 < Skola> chomp which one would you recommend
04:12 < chomp> i'd probably start with tutorial
04:12 < chomp> and keep http://golang.org/doc/go_spec.html handy
04:12 < Skola> ok
04:12 < chomp> the spec is quite small
04:12 < kuroneko> the golang basic tutorial should be enough to get you
started, then effective go should cover most of the gaps for long enough for you
to get comfortable with working from the spec + pkg doc
04:13 < chomp> as far as language specs go
04:13 < Skola> chomp yeah that's very small
04:13 < Skola> kirneko, alright thanks
04:13 < kuroneko> you don't really need to know C for any of that unless you
want to play with cgo, which I don't recommend :)
04:14 < chomp> (yet) ;)
04:14 < kuroneko> [the first thing I did when I was playing about with go
was use cgo >_< wasn't a good idea :)]
04:14 < chomp> though i guess not being too familiar with C does preclude
cgo usage
04:15 < kuroneko> but don't let the C-like syntax or references make you
think you need ot understand C to understand go.
04:15 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has quit [Remote host
closed the connection]
04:15 < kuroneko> you really don't.
04:15 < Skola> what I'm seeing in the tutorial doesn't look at all scary
04:15 < chomp> heh probably better not to honestly - the similarities can be
04:16 < kuroneko> the similarities are a nightmare >_<
04:16 < kuroneko> I still get name/type order wrong occasionally
04:16 < kuroneko> it's HARD to untrain 15 years of C experience
04:16 < chomp> big fan of the go ordering now; it was a nuisance at first
04:17 < kuroneko> oh, I don't think it's an issue - it's just a great way to
let old-timers shoot-themselves in the foot repeatedly :)
04:17 < kuroneko> fortunately it is compiled, so it's easily detected and
fixed :)
04:17 -!- crazy2be [~crazy2be@S01060012171a573b.cg.shawcable.net] has quit [Ping
timeout: 276 seconds]
04:18 < kuroneko> ah, awesome.  Finally got my golang package to build under
pbuilder.  :)
04:18 * kuroneko discovered NOTEST
04:18 < Skola> a language that comes with vim files
04:18 < Skola> excellent
04:19 < chomp> ^
04:19 < chomp> careful though if you use autoindent/cindent
04:20 < chomp> it's still pretty wonky because there is just no way to make
vim do the right thing in some cases
04:20 < chomp> it particularly trips up on := assignment lines
04:20 < Skola> ok
04:25 -!- ccc1 [~Adium@] has quit [Quit: Leaving.]
04:25 < Skola> should I go with the architecture specific compilers, or
should I get gccgo?
04:26 < Skola> I mean to start out with
04:28 -!- dreadlorde [~dreadlord@c-68-42-82-10.hsd1.mi.comcast.net] has quit [Ping
timeout: 246 seconds]
04:28 < chomp> ive never used gccgo
04:28 < chomp> hard to say
04:32 < Skola> Go code seems pretty terse
04:32 < Skola> I like it
04:32 -!- sacho [~sacho@79-100-61-93.btc-net.bg] has joined #go-nuts
04:32 < kuroneko> dont' use gccgo unless you've got a good reason to, or you
like building compilers.
04:33 < Skola> heh ok
04:33 < Skola> could one write: if someBool { // do something }?
04:34 < Skola> or is it mandatory to use newlines here?
04:34 < chomp> you can do that
04:34 < Skola> but it's bad style?
04:34 < chomp> eh not necessarily
04:35 < Skola> ok
04:35 < chomp> nothing wrong with it imho
04:36 < Skola> is there a style guide?
04:37 < chomp> gofmt :)
04:37 < chomp> pretty much any go code you'll ever come across is expressed
in exactly the same style
04:38 < Skola> wow that's nice
04:38 < chomp> but gofmt is a tool which formats go code for you
04:38 < Skola> gofmt :[]
04:38 < Skola> so tabwidth of 8 is the standard?
04:39 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has joined
04:39 < chomp> i guess so
04:39 < chomp> i've always been partial to 4, but eh
04:39 < kuroneko> yes.
04:39 -!- niemeyer [~niemeyer@] has quit [Ping timeout: 240 seconds]
04:39 < kuroneko> there is a general philosphy that if you're lines are
getting too long with tabwidth 8, you should be breaking down your code more.
04:40 < kuroneko> That philsophy is not specific to go in the slightest.
04:41 < Skola> I've seen Linus propound it
04:41 < chomp> that's fair, and i'm not particularly religious about my tab
04:41 < chomp> but i like ts=4 :)
04:41 < Skola> node apps/libs use 2
04:41 < Skola> but the node source (C++) uses 8
04:41 < Skola> :[]
04:42 < chomp> anything less than 4 makes me cringe
04:42 < Skola> yes I think the node standard is unfortunate
04:42 < chomp> guess they figured js is already pretty goddamn ugly, why
stop making it look worse
04:43 < Skola> it does look like hell with js
04:43 < Skola> but with CoffeeScript it's ok
04:43 < chomp> i will have to look at this coffeescript
04:44 < Skola> you should
04:44 < chomp> it does look pretty
04:44 < Skola> I completely hated JS
04:44 < Skola> but CS is really nice
04:44 < Skola> it's not _just_ syntax
04:45 -!- ijknacho [~goofy@cpe-72-190-64-3.tx.res.rr.com] has joined #go-nuts
04:45 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has joined #go-nuts
04:45 < chomp> heh i look at the ? operator and i think to myself,
'if(typeof foo != "undefined" && foo != null)' should never even be something one
would want to express in a language
04:46 < Skola> I know
04:46 < Skola> so that's why CS takes care of it for you :P
04:46 < chomp> heh it's nice that the operator is there in coffeescript, but
so so very unfortunate that it would ever need to be
04:46 < Skola> yeah
04:47 < Skola> that if statement you wrote would (disregarding the ?
operator for a sec) look like this in CoffeeScript:
04:47 < chomp> foo?
04:47 < Skola> if typeof foo isnt "undefined" and foo isnt null
04:47 < chomp> ah
04:48 < chomp> now it looks like python
04:48 < Skola> hah
04:50 < Skola> and you can do things like: compute x for x in xs when x isnt
false and flag isnt "set"
04:50 < Skola> which you may or may not hate
04:50 -!- zozoR [~Morten@2906ds2-arno.0.fullrate.dk] has joined #go-nuts
04:52 < Skola> or for example project euler (yay) problem 1: (last one I'll
04:52 < Skola> (x for x in [0..999] when x % 3 is 0 or x % 5 is 0).reduce
(xs, x) -> xs + x
04:53 < chomp> heh reminds me of haskell code
04:53 < Skola> that would be my fault (or accomplishment)
04:53 < Skola> but yeah, it does
04:54 < chomp> i started learning haskell a few months ago and got
distracted by go
04:54 < chomp> very nice language
04:54 < chomp> and very nice type system
04:54 < chomp> will have to play with it some more soon
04:58 < Skola> same thing in Haskell: sum [x | x <- [1..999], mod x 3 ==
0 || mod x 5 == 0]
04:58 < Skola> though there are about 20 other ways to write that ;[]
04:59 < chomp> oh wow somehow i totally missed the coffeescript lambda
04:59 < chomp> which looks like C#
04:59 < chomp> that's very cool
04:59 < Skola> yeah!
04:59 -!- sacho [~sacho@79-100-61-93.btc-net.bg] has quit [Ping timeout: 240
05:01 -!- sacho [~sacho@95-42-77-124.btc-net.bg] has joined #go-nuts
05:04 < zozoR> i once tried to learn ruby, but i did not get very far until
i saw table or whatever that showed me how ruby can do the same thing in 20
different ways
05:05 < zozoR> at that point i quit learning ruby.
05:05 < chomp> that soudns exactly right.
05:05 < zozoR> 20 ways of doing the same thing asks for disaster
05:06 < Skola> Well in Haskell it's not _the same thing_, I didn't put it
very well
05:06 < zozoR> ^^
05:07 < Skola> There's always a best way
05:07 < Skola> it's not perl
05:08 < chomp> even if it were true for haskell it scores major points for
being beautiful
05:08 < Skola> yeah it is very beautiful and elegant
05:19 -!- Skola [~bas@5352A3FB.cm-6-3c.dynamic.ziggo.nl] has quit [Ping timeout:
255 seconds]
05:20 -!- edsrzf [~edsrzf@122-61-221-144.jetstream.xtra.co.nz] has joined #go-nuts
05:21 -!- Skola [~bas@5352A3FB.cm-6-3c.dynamic.ziggo.nl] has joined #go-nuts
05:31 -!- Guest74132 [~john@c-71-202-154-251.hsd1.ca.comcast.net] has joined
05:32 -!- cafesofie [~cafesofie@ool-18b97779.dyn.optonline.net] has quit [Remote
host closed the connection]
05:34 -!- bakedb [~kel@cpc4-lea21-0-0-cust755.6-3.cable.virginmedia.com] has
joined #go-nuts
05:35 -!- wrtp [~rog@pD95E7F5C.dip.t-dialin.net] has joined #go-nuts
05:42 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Read error:
Connection reset by peer]
05:43 -!- ExtraSpice [XtraSpice@78-57-204-104.static.zebra.lt] has joined #go-nuts
05:45 -!- Guest74132 [~john@c-71-202-154-251.hsd1.ca.comcast.net] has quit [Quit:
05:46 -!- meanburr1to920 [~john@c-71-202-154-251.hsd1.ca.comcast.net] has joined
05:46 -!- meanburr1to920 [~john@c-71-202-154-251.hsd1.ca.comcast.net] has quit
[Client Quit]
05:48 -!- chomp [~chomp@c-67-186-35-69.hsd1.pa.comcast.net] has quit [Quit:
05:51 -!- meanburr1to920 [~john@c-71-202-154-251.hsd1.ca.comcast.net] has joined
05:55 -!- awidegreen [~quassel@h-170-226.A212.priv.bahnhof.se] has joined #go-nuts
05:56 -!- wchicken [~chicken@c-71-235-58-74.hsd1.ct.comcast.net] has quit [Read
error: Operation timed out]
06:01 -!- meanburr1to920 [~john@c-71-202-154-251.hsd1.ca.comcast.net] has quit
[Quit: leaving]
06:04 -!- meanburr1to920 [~john@c-71-202-154-251.hsd1.ca.comcast.net] has joined
06:05 -!- kfeng [~kfeng@host-58-114-183-56.dynamic.kbtelecom.net] has quit [Quit:
06:05 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-151-44.clienti.tiscali.it] has
joined #go-nuts
06:06 -!- Skola [~bas@5352A3FB.cm-6-3c.dynamic.ziggo.nl] has quit [Ping timeout:
250 seconds]
06:07 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has quit
[Remote host closed the connection]
06:10 -!- Skola [~bas@5352A3FB.cm-6-3c.dynamic.ziggo.nl] has joined #go-nuts
06:12 < magn3ts> so if I've already switched to tip...  is hg pull update
good enough?
06:14 -!- franciscosouza_ [~francisco@] has joined #go-nuts
06:16 -!- franciscosouza [~francisco@] has quit [Ping timeout: 252
06:27 -!- tvw [~tv@e176005149.adsl.alicedsl.de] has joined #go-nuts
06:27 -!- noodles775 [~michael@canonical/launchpad/noodles775] has joined #go-nuts
06:29 -!- bakedb [~kel@cpc4-lea21-0-0-cust755.6-3.cable.virginmedia.com] has quit
[Ping timeout: 255 seconds]
06:33 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has joined
06:44 -!- napsy [~luka@] has joined #go-nuts
06:44 -!- piranha [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts
06:48 -!- meanburr1to920 [~john@c-71-202-154-251.hsd1.ca.comcast.net] has quit
[Quit: leaving]
06:52 -!- awidegreen [~quassel@h-170-226.A212.priv.bahnhof.se] has quit [Ping
timeout: 255 seconds]
06:53 -!- alexandere [~alexander@eijg.xs4all.nl] has joined #go-nuts
07:02 -!- franciscosouza [~francisco@] has quit [Read error:
Connection reset by peer]
07:04 -!- iwinulose [~charlesdu@c-67-188-13-8.hsd1.ca.comcast.net] has quit [Quit:
07:04 -!- franciscosouza [~francisco@] has joined #go-nuts
07:04 -!- iwinulose [~charlesdu@c-67-188-13-8.hsd1.ca.comcast.net] has joined
07:10 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
07:13 -!- tvw [~tv@e176005149.adsl.alicedsl.de] has quit [Remote host closed the
07:22 -!- napsy [~luka@] has quit [Quit: Lost terminal]
07:26 -!- karlom [d39cb80a@gateway/web/freenode/ip.] has joined
07:34 -!- temoto [~temoto@95-26-169-117.broadband.corbina.ru] has quit [Ping
timeout: 246 seconds]
07:34 -!- Slant [~scott@124-168-223-48.dyn.iinet.net.au] has joined #go-nuts
07:35 -!- napsy [~luka@] has joined #go-nuts
07:38 -!- kfmfe04 [~kfmfe04@60-251-136-139.HINET-IP.hinet.net] has joined #go-nuts
07:40 -!- jemeshsu [~jemeshsu@bb220-255-88-127.singnet.com.sg] has quit [Read
error: Connection reset by peer]
07:41 -!- jemeshsu [~jemeshsu@bb121-6-26-212.singnet.com.sg] has joined #go-nuts
07:44 -!- bakedb [~kel@] has joined #go-nuts
07:47 < cenuij> yeah hg update release or hg update weekly for less stable
07:49 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has left #go-nuts []
07:51 -!- Slant [~scott@124-168-223-48.dyn.iinet.net.au] has quit [Quit: Slant]
07:52 -!- arun_ [~arun@unaffiliated/sindian] has quit [Ping timeout: 255 seconds]
07:54 < magn3ts> I'm having a heck of a time getting the vim scripts
installed properly.  :/
07:54 < magn3ts> I have syntax highliting going for go...  but still nothing
is helping with indent
07:59 < dforsyth> setting autoindent doesnt do what you want?
08:01 -!- pyrhho [~pyrhho@host-92-27-75-48.static.as13285.net] has joined #go-nuts
08:01 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the
08:03 < magn3ts> I got it now.
08:03 < magn3ts> I mixed up the ln syntax and had broken symbolic links,
like a doofus
08:06 < magn3ts> Tabs are convention?
08:06 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts
08:10 < Queue29> magn3ts: gofmt will enforce tabs
08:10 < magn3ts> :[
08:11 < magn3ts> okay
08:11 < Queue29> after you use it for a while you'll be more like :]
08:11 < magn3ts> I had just recently fallen in love with 3 or 4 space
indents and brace on new line style.
08:12 < magn3ts> Now I'm abandoning both.  :o how forgiving of input code is
gofmt I wonder
08:18 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|]
08:22 < cenuij> magn3ts: just set your editor to display tabs at 4 spaces
width!  problem solved ;)
08:22 -!- wrtp [~rog@pD95E7F5C.dip.t-dialin.net] has quit [Quit: wrtp]
08:22 < cenuij> gofmt defaults to spacing fields etc with spaces, so don't
worry about that
08:26 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has quit
[Remote host closed the connection]
08:29 -!- fvbommel [~fvbommel_@] has quit [Ping timeout: 276 seconds]
08:29 < magn3ts> I don't understand the fibonacci example.  I feel like I'm
missing something obvious.
08:34 < edsrzf> magn3ts: The one that's in the playground?
08:34 < magn3ts> yes
08:34 < edsrzf> Are you familiar with closures?
08:34 < magn3ts> I thought I was.  I'm familiar with closures in javascript
08:35 < edsrzf> Closures in JavaScript are pretty similar to closures in Go.
08:35 -!- tvw [~tv@] has joined #go-nuts
08:35 < edsrzf> I think the same example would work if modified for
08:35 < magn3ts> I don't understand the wiring regarding the inner return
08:36 < magn3ts> is it a closure automatically due to the syntax?
08:36 < edsrzf> Yes
08:36 < magn3ts> The func() int part?
08:37 < edsrzf> The fact that it's used as an expression and that it doesn't
have a name makes it a closure
08:38 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the
08:38 < magn3ts> I think I understand now.  I will play around.  Thanks.
08:39 -!- cenuij [~cenuij@] has joined #go-nuts
08:39 -!- cenuij [~cenuij@] has quit [Changing host]
08:39 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts
08:39 -!- wrtp [~rog@pD95E7F5C.dip.t-dialin.net] has joined #go-nuts
08:40 -!- wrtp [~rog@pD95E7F5C.dip.t-dialin.net] has quit [Client Quit]
08:41 -!- DisposaBoy [~DisposaBo@] has quit [Ping timeout: 258
08:41 -!- edsrzf [~edsrzf@122-61-221-144.jetstream.xtra.co.nz] has quit [Remote
host closed the connection]
08:42 -!- sebastianskejoe [~sebastian@] has joined #go-nuts
08:42 -!- DisposaBoy [~DisposaBo@] has joined #go-nuts
08:43 -!- TheSeeker [riiight@99-153-250-110.lightspeed.irvnca.sbcglobal.net] has
quit [Ping timeout: 240 seconds]
08:49 -!- TheSeeker [riiight@99-153-250-110.lightspeed.irvnca.sbcglobal.net] has
joined #go-nuts
09:05 -!- virtualsue [~chatzilla@nat/cisco/x-jfgzdkkgpciphhof] has joined #go-nuts
09:14 -!- kfmfe04 [~kfmfe04@60-251-136-139.HINET-IP.hinet.net] has quit [Quit:
09:15 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has quit [Ping
timeout: 264 seconds]
09:19 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has joined #go-nuts
09:30 -!- alexandere [~alexander@eijg.xs4all.nl] has quit [Quit: alexandere]
09:35 -!- fvbommel [~fvbommel_@] has joined #go-nuts
09:38 * cenuij stares blankly at his monitor
09:39 < cenuij> "cannot use font (type *truetype.Font) as type
*truetype.Font in return argument"
09:39 < cenuij> ¬_¬
09:39 -!- ronnyy [~quassel@p4FF1C50C.dip0.t-ipconnect.de] has joined #go-nuts
09:42 < zozoR> lol :D
09:47 -!- fabled [~fabled@] has joined #go-nuts
09:54 < zippoxer> lol; there's a secret hotkey in
09:54 < zippoxer> shift + enter
09:54 < zippoxer> it means google uses it too
09:55 -!- fvbommel [~fvbommel_@] has quit [Ping timeout: 276
10:18 < zozoR> the golang faq is funny ^^ the guys answer a lot of questions
about features or the lack of them with some form of reasoning and then ending the
line with "also it is way easier to make the compiler this way"
10:18 < zozoR> :D
10:21 -!- pyrhho [~pyrhho@host-92-27-75-48.static.as13285.net] has quit [Ping
timeout: 244 seconds]
10:27 -!- sacho [~sacho@95-42-77-124.btc-net.bg] has quit [Ping timeout: 276
10:32 -!- Slant [~scott@124-168-223-48.dyn.iinet.net.au] has joined #go-nuts
10:34 -!- franciscosouza [~francisco@] has quit [Read error:
Connection reset by peer]
10:35 -!- ronnyy [~quassel@p4FF1C50C.dip0.t-ipconnect.de] has quit [Remote host
closed the connection]
10:39 -!- ronnyy [~quassel@p4FF1C50C.dip0.t-ipconnect.de] has joined #go-nuts
10:43 -!- ronnyy [~quassel@p4FF1C50C.dip0.t-ipconnect.de] has quit [Remote host
closed the connection]
10:44 -!- franciscosouza [~francisco@] has joined #go-nuts
10:47 -!- tvw [~tv@] has quit [Ping timeout: 255 seconds]
10:54 -!- Project-2501 [~Marvin@] has joined #go-nuts
10:55 -!- alehorst [~alehorst@] has joined
10:57 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-151-44.clienti.tiscali.it] has
quit [Read error: Operation timed out]
10:59 -!- ttblrs_ [U2FsdGVkX1@order.stressinduktion.org] has quit [Ping timeout:
240 seconds]
10:59 -!- kfmfe04 [~kfmfe04@NK219-91-85-120.adsl.dynamic.apol.com.tw] has joined
11:00 -!- ttblrs [~hannes@order.stressinduktion.org] has joined #go-nuts
11:02 -!- iwinulose [~charlesdu@c-67-188-13-8.hsd1.ca.comcast.net] has quit [Quit:
11:10 -!- zcram [~zcram@78-28-69-30.cdma.dyn.kou.ee] has joined #go-nuts
11:13 -!- pyrhho [~pyrhho@host-92-27-75-48.static.as13285.net] has joined #go-nuts
11:20 -!- gnuvince|work [8e544424@gateway/web/freenode/ip.] has joined
11:24 -!- pyrhho [~pyrhho@host-92-27-75-48.static.as13285.net] has quit [Quit:
11:26 -!- pyrhho [~pyrhho@host-92-27-75-48.static.as13285.net] has joined #go-nuts
11:36 -!- flaguy48 [~gmallard@user-0c6s350.cable.mindspring.com] has joined
11:37 -!- ment [thement@ibawizard.net] has joined #go-nuts
11:39 -!- karlom [d39cb80a@gateway/web/freenode/ip.] has quit [Ping
timeout: 252 seconds]
11:39 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has quit [Ping timeout:
608 seconds]
11:40 -!- Project_2501 [~Marvin@] has joined #go-nuts
11:41 -!- franciscosouza [~francisco@] has quit [Quit:
11:42 -!- franciscosouza [~francisco@] has joined #go-nuts
11:43 -!- franciscosouza [~francisco@] has quit [Client Quit]
11:43 -!- Project-2501 [~Marvin@] has quit [Ping timeout: 240 seconds]
11:51 -!- tvw [~tv@] has joined #go-nuts
11:52 -!- prip [~foo@host37-133-dynamic.42-79-r.retail.telecomitalia.it] has quit
[Ping timeout: 258 seconds]
12:02 -!- tncardoso [~thiagon@] has joined #go-nuts
12:09 -!- mattn_jp [~mattn@112-68-51-161f1.hyg1.eonet.ne.jp] has joined #go-nuts
12:10 -!- kfmfe04 [~kfmfe04@NK219-91-85-120.adsl.dynamic.apol.com.tw] has quit
[Quit: kfmfe04]
12:13 < str1ngs> how do I test if err is ENOENT
12:14 < str1ngs> ie with os.Stat
12:16 -!- franciscosouza [~francisco@] has joined #go-nuts
12:25 -!- Nitro [~Nitro@unaffiliated/nitro] has joined #go-nuts
12:26 < skelterjohn> this came up a few days ago - you can assert it to an
*os.PathError and look at the Err field, which can be asserted to something else
and compared to syscall.ENOENT
12:27 < skelterjohn> i don't remember what the type is though, i'd use
Printf("%T", thePathErr.Err) to find it
12:27 < str1ngs> PathError is right
12:27 < str1ngs> but assert I'm having trouble with
12:27 < skelterjohn> but PathError's Err field
12:27 < skelterjohn> don't remember what that one is
12:27 < str1ngs> PatheError.Error
12:27 < skelterjohn> what its type is, when returned from os.Stat =p
12:28 < skelterjohn> since inside PathError it is an interface type
12:28 < skelterjohn> <- going to work
12:29 < str1ngs> ah I think this is the issue then syscall.ENOENT ..
12:31 -!- fvbommel [~fvbommel_@wlan-245125.nbw.tue.nl] has joined #go-nuts
12:36 -!- fvbommel [~fvbommel_@wlan-245125.nbw.tue.nl] has quit [Ping timeout: 240
12:38 < ijknacho> str1ngs: try something like this: fi, err :=
os.Stat(myFile); if err != nil && err.(*os.PathError).Error == os.ENOENT {
fmt.Printf("got ENOENT\n"); }
12:38 < str1ngs> ijknacho: haha thanks I just figured it out too
12:39 < str1ngs> can I assert like that out of a switch?
12:40 < ijknacho> like by using switch err.(type)?  I'd think so
12:41 < str1ngs> I'm using switch err.(type) right now
12:41 < str1ngs> I'll try if though, less code
12:43 < str1ngs> if err != nil && err.(*os.PathError).Error == os.ENOENT
works better thanks
12:45 -!- mattn_jp [~mattn@112-68-51-161f1.hyg1.eonet.ne.jp] has quit [Ping
timeout: 260 seconds]
12:47 -!- Sep102 [~Sep102@c-71-227-179-131.hsd1.wa.comcast.net] has quit [Read
error: Connection reset by peer]
12:48 -!- Sep102 [~Sep102@c-71-227-179-131.hsd1.wa.comcast.net] has joined
12:49 -!- pharris [~Adium@rhgw.opentext.com] has joined #go-nuts
12:49 -!- goon12 [~goon12@71-87-215-29.dhcp.oxfr.ma.charter.com] has joined
12:51 -!- sebastianskejoe [~sebastian@] has quit [Quit: Lost
12:57 -!- goon12 [~goon12@71-87-215-29.dhcp.oxfr.ma.charter.com] has quit [Ping
timeout: 264 seconds]
13:01 -!- mattn_jp [~mattn@112-68-51-161f1.hyg1.eonet.ne.jp] has joined #go-nuts
13:01 -!- Project_2501 [~Marvin@] has quit [Read error: Connection
reset by peer]
13:03 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-150-151.clienti.tiscali.it] has
joined #go-nuts
13:04 -!- sniper506th [~sniper506@rrcs-70-61-192-18.midsouth.biz.rr.com] has
joined #go-nuts
13:15 -!- Katibe [~Katibe@] has joined #go-nuts
13:17 < Skola> :q
13:17 -!- Skola [~bas@5352A3FB.cm-6-3c.dynamic.ziggo.nl] has quit [Quit: leaving]
13:17 -!- prip [~foo@host134-130-dynamic.42-79-r.retail.telecomitalia.it] has
joined #go-nuts
13:17 -!- Katibe [~Katibe@] has quit [Remote host closed the
13:20 -!- Katibe [~Katibe@] has joined #go-nuts
13:28 -!- lucian [~lucian@78-86-217-168.zone2.bethere.co.uk] has joined #go-nuts
13:36 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the
13:43 -!- virtualsue [~chatzilla@nat/cisco/x-jfgzdkkgpciphhof] has quit [Quit:
ChatZilla 0.9.87 [Firefox 4.0.1/20110413222027]]
13:46 < skelterjohn|work> zippoxer: try updating gb
13:46 -!- alsvidr [~user@2a00:1398:2:4006:21f:16ff:fe28:b064] has joined #go-nuts
13:46 < skelterjohn|work> i fixed that bug a couple days ago
13:47 -!- prip [~foo@host134-130-dynamic.42-79-r.retail.telecomitalia.it] has quit
[Ping timeout: 240 seconds]
13:49 -!- photron [~photron@port-92-201-42-18.dynamic.qsc.de] has joined #go-nuts
13:52 -!- DisposaBoy [~DisposaBo@] has quit [Ping timeout: 240
13:53 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has joined #go-nuts
13:56 -!- r_linux [~r_linux@static.] has joined
13:58 -!- virtualsue [~chatzilla@nat/cisco/x-riufepoogggttuhe] has joined #go-nuts
13:58 -!- DisposaBoy [~DisposaBo@] has joined #go-nuts
14:03 -!- ArgonneIntern [82ca0251@gateway/web/freenode/ip.] has joined
14:25 -!- dgnorton [~dgnorton@] has joined #go-nuts
14:27 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has joined
14:32 -!- Wiz126 [Wiz@h229.120.232.68.dynamic.ip.windstream.net] has quit [Ping
timeout: 240 seconds]
14:32 -!- Wiz126 [Wiz@h229.120.232.68.dynamic.ip.windstream.net] has joined
14:36 -!- fvbommel [~fvbommel_@] has joined #go-nuts
14:38 < zippoxer> skelterjohn|work: updated, but still it doesn't work well
for me.  I have one main.go file: http://www.pastie.org/2129326
14:38 < zippoxer> and whenever i compile using gb
14:38 < zippoxer> I get two errors:
14:38 < zippoxer> ./bin/main: line 1: syntax error near unexpected token
14:38 < skelterjohn|work> you can't have a cgo cmd
14:38 < zippoxer> ./bin/main: line 1: `!<arch>'
14:38 < skelterjohn|work> you can only have cgo packages
14:38 < zippoxer> ohhh.
14:39 < skelterjohn|work> and then your cmd can import the pkg
14:39 < zippoxer> okay
14:39 < skelterjohn|work> BUT that's not a very good error message, is it?
14:39 < skelterjohn|work> can you pastebin me the terminal output?
14:39 < skelterjohn|work> so i can figure out if it's gb's error reporting
or something else
14:39 < zippoxer> that's all :P
14:39 < zippoxer> command is: gb
14:39 < zippoxer> output ^^
14:40 < skelterjohn|work> run gb -v
14:40 < skelterjohn|work> tell me the last command line [stuff in brackets]
before the error?
14:40 < skelterjohn|work> i bet it's from the cgo cmd
14:40 < zippoxer> same
14:40 < zippoxer> sec
14:40 < skelterjohn|work> gb -v is "verbose", and reports all command lines
14:40 < skelterjohn|work> so it shouldn't be the same
14:40 < dgnorton> I'm a go noob and having trouble with a list of structs
...  code with err msg at the bottom here - http://pastebin.com/r8eVeUtf
14:41 -!- virtualsue [~chatzilla@nat/cisco/x-riufepoogggttuhe] has quit [Ping
timeout: 246 seconds]
14:41 < zippoxer> hey lol
14:41 < zippoxer> the error is when I run the generated executable
14:41 < zippoxer> ~/gotest# ./bin/main
14:41 < skelterjohn|work> dgnorton, you need to use a type assertion
14:41 < zippoxer> that's something I forgot to say..
14:41 < zippoxer> it's not from the gb compilation
14:41 < dgnorton> B.(i.Value) ?
14:42 < skelterjohn|work> i.Value(*B)
14:42 < skelterjohn|work> i.Value.(*B), i mean
14:42 < skelterjohn|work> dgnorton: also, unless you specifically need a
linked list, i don't recommend using container/list
14:42 < skelterjohn|work> if you just need a list you can add things to
easily, use a regular slice and the append() built-in function
14:43 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has quit
[Remote host closed the connection]
14:44 < skelterjohn|work> zippoxer: i'm still interested in what gb -v
reports.  err, clean it first, so actually do "gb -cbv"
14:44 < skelterjohn|work> to do a clean build, verbosely
14:44 < dgnorton> skelterjohn: thx...assertion fixed it
14:45 < dgnorton> skelterjohn: I don't know how many items will be in the
14:45 -!- sacho [~sacho@] has joined #go-nuts
14:45 < skelterjohn|work> that's fine - a slice w/ append() is the right way
to do that
14:45 < skelterjohn|work> theSlice = append(theSlice, theNewItem)
14:45 < skelterjohn|work> then you won't need to do any type assertions
14:46 < dgnorton> probably my lack of go understanding but that seems less
14:46 < zippoxer> skelterjohn|work: it works with the package structure like
you said :)
14:46 < zippoxer> sec
14:47 < skelterjohn|work> dgnorton: append uses the capacity-doubling
strategy.  a slice has both a length and capacity - allocated data that is not
being used
14:48 < skelterjohn|work> if the capacity is great enough, append will copy
the new item into that extra space and change length
14:48 < skelterjohn|work> otherwise it will allocate a new array with twice
the capacity of the old one, and use it instead.
14:48 < dgnorton> skelterjohn: ok...got it...and that will probably be ok
for this scenario
14:49 < skelterjohn|work> O(log n) allocations and O(n) allocated memory,
where n is the max length of the list
14:49 < zippoxer> skelterjohn|work: here's what "gb -cbv" says when the cgo
part is on main package: http://www.pastie.org/2129376
14:49 < dgnorton> thanks
14:50 < skelterjohn|work> zippoxer: i think it's linking to bin/main the way
it would link a package with the name "main"
14:50 -!- virtualsue [~chatzilla@host81-148-52-109.in-addr.btopenworld.com] has
joined #go-nuts
14:50 -!- napsy [~luka@] has quit [Ping timeout: 250 seconds]
14:50 < skelterjohn|work> i must have hardcoded in the requirement that cgo
only be for packages, and i should add an error report
14:51 -!- pjacobs [~pjacobs@75-27-133-72.lightspeed.austtx.sbcglobal.net] has
joined #go-nuts
14:51 < zippoxer> but still the cgo in main structure reproduce the error
14:51 < zippoxer> ohh ok
14:51 < zippoxer> it doesn't bother me anyway
14:53 < zippoxer> this thing: a, b := abPlease(); a {}
14:54 < zippoxer> works with if, but not with for?
14:54 < zippoxer> I don't understand, they both accept conditions
14:54 < skelterjohn|work> it would be ambiguous with for
14:54 < skelterjohn|work> since for already uses semicolons
14:54 < zippoxer> ohh
14:54 < zippoxer> yeah :P
14:54 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has joined
14:59 -!- tvw [~tv@] has quit [Remote host closed the connection]
15:02 < smw> http://code.google.com/p/goconf/ compiles now :-).  Although
the tests are panicking :-\.
15:02 < skelterjohn|work> baby steps :)
15:02 < smw> skelterjohn|work, yep
15:02 -!- Project-2501 [~Marvin@] has joined #go-nuts
15:02 < smw> when I made this lib, there was no such thing as a panic!
15:02 -!- wchicken [~chicken@c-71-235-58-74.hsd1.ct.comcast.net] has joined
15:02 < smw> Anyways, after I fix this, I need to rewrite it and get rid of
the old code from goconfig :-P
15:03 < smw> skelterjohn|work, after fixing all the compiling errors, I saw
people had filed bugs describing how to fix each problem.
15:03 < smw> lol
15:04 < skelterjohn|work> hehe
15:04 -!- pjacobs2 [~pjacobs@] has joined #go-nuts
15:04 < skelterjohn|work> i have thought about turning
goargcfg.googlecode.com into a config file reader - as it stands it's a command
line arg parser
15:05 < skelterjohn|work> but it uses reflect to populate a struct you give
15:05 < smw> cool
15:05 < skelterjohn|work> and it does nesting, so things liky -X.Y.Z=123
15:05 < smw> ok
15:05 -!- virtualsue [~chatzilla@host81-148-52-109.in-addr.btopenworld.com] has
quit [Ping timeout: 255 seconds]
15:05 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-150-151.clienti.tiscali.it] has
quit [Ping timeout: 258 seconds]
15:06 -!- pjacobs [~pjacobs@75-27-133-72.lightspeed.austtx.sbcglobal.net] has quit
[Read error: Operation timed out]
15:06 < smw> skelterjohn|work, for some reason people are happy with my lib
after then get it working.  Therefore, the problem must be in the test and not the
actual code :-)
15:06 < smw> at least...  I hope it is
15:07 -!- ijknacho [~goofy@cpe-72-190-64-3.tx.res.rr.com] has quit [Ping timeout:
258 seconds]
15:11 < smw> skelterjohn|work, got any idea how to debug this?
15:11 -!- virtualsue [~chatzilla@nat/cisco/x-frkjllateydwoxts] has joined #go-nuts
15:11 < skelterjohn|work> besides looking at get.go line 124 and wondering
why the index is out of bounds?
15:12 < smw> nope.  that sounds like a good idea
15:12 -!- napsy [~luka@] has joined #go-nuts
15:12 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has joined #go-nuts
15:13 -!- Queue29 [~Queue29@173-8-182-114-SFBA.hfc.comcastbusiness.net] has quit
[Remote host closed the connection]
15:13 < smw> skelterjohn, the most aweful part is that this use to work!
15:13 < smw> skelterjohn, what changed to cause index out of bounds?
15:13 < skelterjohn|work> i'd have to look at the code
15:13 < smw> looking now :-P
15:16 -!- chomp [~chomp@dap-209-166-184-50.pri.tnt-3.pgh.pa.stargate.net] has
joined #go-nuts
15:18 -!- dreadlorde [~dreadlord@c-68-42-82-10.hsd1.mi.comcast.net] has joined
15:28 < smw> anyone know how to apply for the beta of go on appengine?
15:32 -!- Slant [~scott@124-168-223-48.dyn.iinet.net.au] has quit [Quit: Slant]
15:33 < kevlar_work> smw, looks like they turned off the trusted tester
signup spreadsheet.
15:34 < kevlar_work> read into that what you will ;-).  The link has been
removed from the Go Language Blog post but not from the original AppEngine blog
15:34 -!- virtualsue [~chatzilla@nat/cisco/x-frkjllateydwoxts] has quit [Read
error: Connection reset by peer]
15:35 -!- noodles775 [~michael@canonical/launchpad/noodles775] has quit [Quit:
15:35 -!- virtualsue [~chatzilla@nat/cisco/x-gypngijjkedteudn] has joined #go-nuts
15:40 < smw> ok
15:40 -!- Tv [~Tv@cpe-76-168-227-45.socal.res.rr.com] has joined #go-nuts
15:40 < smw> kevlar, I did not sign up because I did not have a project idea
15:41 < smw> now I do XD
15:41 < smw> kevlar_work, ^
15:42 < skelterjohn|work> i bet the google group for it has about 10 posts
asking this question
15:43 < smw> skelterjohn|work, I just found this
15:43 -!- rcrowley [~rcrowley@c-71-202-44-233.hsd1.ca.comcast.net] has joined
15:44 < skelterjohn|work> probably what kevlar_work was referring to
15:44 < smw> yeah
15:45 -!- Queue29 [~Queue29@egress-w.sfo1.yelpcorp.com] has joined #go-nuts
15:47 < ArgonneIntern> interesting read if anyone cares
15:49 -!- Project_2501 [~Marvin@] has joined #go-nuts
15:50 -!- jbooth1 [~jay@] has joined #go-nuts
15:52 -!- Project-2501 [~Marvin@] has quit [Ping timeout: 260 seconds]
15:54 < smw> ArgonneIntern, thanks
15:54 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-155-41.clienti.tiscali.it] has
joined #go-nuts
15:55 < ArgonneIntern> it's interesting, by changing two things they managed
to get runtime below c++ equivelant
15:56 < ArgonneIntern> but all it shows is the C compilers are better with
maps and go's compilers are better with arrays/slices
15:56 < ArgonneIntern> I think everyone already knew that
15:57 -!- Project_2501 [~Marvin@] has quit [Ping timeout: 240 seconds]
15:57 < ArgonneIntern> still 50+ seconds to 4 is pretty good
16:00 < KirkMcDonald> In the end he also changed the C++ version to more
closely match the optimized Go version.
16:00 < ArgonneIntern> yes
16:01 < ArgonneIntern> which also resulted in the C++ code running faster as
16:01 < ArgonneIntern> not the same magnitude faster
16:01 < KirkMcDonald> Though not by nearly the same-- yeah.
16:01 < ArgonneIntern> but faster
16:01 < ArgonneIntern> yea, this just means go compilers have a ways to go
16:01 < ArgonneIntern> they will get there, c++ compilers have had a lot
more time to develop
16:08 -!- fenicks [~fenicks@log77-3-82-243-254-112.fbx.proxad.net] has quit [Ping
timeout: 246 seconds]
16:10 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Remote host
closed the connection]
16:11 < Namegduf> It also shows that people writing "papers" on language
performance seem to know jack shit in BOTH the cases I've seen.
16:12 * Namegduf grumbles about people who write nicely optimised C(++) and then
make no effort at all in the Go version.
16:12 -!- wchicken [~chicken@c-71-235-58-74.hsd1.ct.comcast.net] has quit [Ping
timeout: 255 seconds]
16:12 < zippoxer> "cannot use &cases (type *[]*Case) as type []interface { }
in function argument"
16:12 < zippoxer> and: "cannot use &cases (type *[]*Case) as type
*[]*interface { } in function argument"
16:13 < zippoxer> so what kind of interface will accept *[]*Case?
16:13 < ArgonneIntern> anyone know if anyone is working on bindings for
16:13 < Namegduf> I mean, surely if you're going to write something as
presumptious as a "paper", you use a profiler to check that the performance gap
isn't just some quirk of how you personally wrote your program, yes?
16:13 -!- napsy [~luka@] has quit [Ping timeout: 255 seconds]
16:14 < ArgonneIntern> zippoxer: what is Case
16:14 < zippoxer> a struct
16:14 < ArgonneIntern> hmm
16:15 < zippoxer> I tried *[]interface and []*interface too
16:15 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has joined #go-nuts
16:15 < zippoxer> only interface{} works, but than I can't use it as a
16:16 -!- GeertJohan [~Squarc@ip4da06866.direct-adsl.nl] has joined #go-nuts
16:16 < zippoxer> (in the function)
16:16 < Namegduf> "In fact, in Hundt's paper, he explains that the Java
program needed just this change to get anything like reasonable performance, but
he did not make the same change in the other garbage-collected implementations."
16:16 < Namegduf> WTF?
16:16 < vegai> => Java ftw yay!
16:17 < ArgonneIntern> zipper is cases an array of structs
16:17 < ArgonneIntern> or an array of stuct pointers
16:17 < zippoxer> cases is []*Case
16:18 < zippoxer> but when I pass it to the func with &cases, it's *[]*Case
16:18 < ArgonneIntern> right
16:18 < ArgonneIntern> cause you're sending the address
16:18 < zippoxer> yeah I need the address
16:18 < zippoxer> but
16:18 < zippoxer> the func doesn't accept it!
16:18 < ArgonneIntern> not really
16:18 < zippoxer> y?
16:18 -!- awidegreen [~quassel@h-170-226.A212.priv.bahnhof.se] has joined #go-nuts
16:18 < ArgonneIntern> cause the array is static and will be copied without
the &
16:19 < ArgonneIntern> but whats in the array are pointers
16:19 < ArgonneIntern> so you will change your original data
16:19 < zippoxer> I want to re assign the array
16:19 < ArgonneIntern> unless you plan on removing or adding some
16:19 < zippoxer> not it's values
16:19 < ArgonneIntern> ok
16:19 < zippoxer> it will work too without the &?
16:19 < zippoxer> (re-assigning)
16:20 < ArgonneIntern> func (something *[]*Case) doesn't work?
16:20 < zippoxer> it works of course, but I need it to accept more kinds of
16:20 < zippoxer> *[]*AnotherStruct
16:20 < zippoxer> etc..
16:21 < ArgonneIntern> ahh I see
16:21 < zippoxer> func (something interface{}) works, but than something
isn't a slice and I can't append to it
16:21 < zippoxer> sad :(
16:22 < ArgonneIntern> can I ask how you would know what interface is coming
in if it did work
16:22 < ArgonneIntern> I'm unfamiliar with using interfaces as parameters
16:23 < zippoxer> mmm that's my problem actually
16:23 < ArgonneIntern> in C++ you could use typeid if it was pointers to
it's parent, but I havn't seen anything like that in go
16:24 < chomp> well you would use a type assertion in this case
16:24 -!- alsvidr [~user@2a00:1398:2:4006:21f:16ff:fe28:b064] has left #go-nuts
["ERC Version 5.3 (IRC client for Emacs)"]
16:24 < ArgonneIntern> does that return an error if it fails?
16:24 < chomp> it can, it has a multivalued version
16:24 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has left #go-nuts []
16:24 < ArgonneIntern> interesting
16:24 < chomp> foo, ok := value.(InterfaceName)
16:25 < ArgonneIntern> hah well now that, that's settled how do we get it
able to pass an &[]*struct as *[]*interface{}
16:26 < zippoxer> we can pass &[]*struct as interface{}
16:26 < chomp> yeahm you just do
16:26 < zippoxer> but than, that interface value isn't a slice :(
16:26 < zippoxer> then*
16:27 < chomp> why does it need to be a slice?
16:27 < ArgonneIntern> prob so he can append
16:27 < zippoxer> so I can append to it :)
16:27 < zippoxer> maybe I found a conversation about that:
16:27 < zippoxer> but I gtg for 20 min~
16:28 < zippoxer> so thanks for the help for now
16:31 < ArgonneIntern> yes perhaps there is no resonable conversion of type
[]*Case to type []*Interface
16:31 < ArgonneIntern> as the conversation says some ways down
16:31 < magn3ts> Anyone have godag building with go tip?
16:35 < ArgonneIntern> zippoxer:
http://research.swtch.com/2009/12/go-data-structures-interfaces.html, bring it in
as type interface{} and type it once inside to an array of choice, as chomp
16:35 -!- mrsrikanth [~mrsrikant@] has joined #go-nuts
16:36 < chomp> no, that doesn't work
16:36 < chomp> you can't "type it", you can only assert its type
16:36 < ArgonneIntern> "static type interface{}, meaning no guarantee of any
methods at all: it could contain any type" quoted from the link above
16:36 < chomp> it's an array, and you can assert that it's an array and
that's fine
16:36 < ArgonneIntern> that's what I mean
16:36 < chomp> but it's not a slice.
16:36 < ArgonneIntern> oh
16:36 < ArgonneIntern> so you would know what it is but not be able to
16:38 < chomp> i'm skeptical that passing an interface{} receiving a slice
would somehow actually receive only the underlying array
16:38 < magn3ts> Are there docs like are available on golang.org for tip?
16:38 < chomp> magn3ts, you can run godoc locally in your tip tree
16:38 < ArgonneIntern> couldn't you slice the assertion?  I believe I've
done this with linked list
16:38 < chomp> magn3ts, and it will serve formatted html docs just like
golang.org has
16:38 -!- sl0 [none@sp.inri.net] has joined #go-nuts
16:38 < chomp> directly from the source code
16:39 < GeertJohan> Hum...  how do I declare a slice inside a struct?
16:39 -!- lucian [~lucian@78-86-217-168.zone2.bethere.co.uk] has quit [Remote host
closed the connection]
16:39 < chomp> struct { myslice []type }
16:39 < GeertJohan> ah ok:) and then, is the sliced make'd when I initialize
the struct using new?  or do I need to "make" the struct?  or do I initialize the
struct and then make the slice in the struct?
16:40 < chomp> you can use new or an initializer list
16:40 < ArgonneIntern> someInterface =
append(someInterface.(*[]*Case).[number:number2], "samething")
16:40 < chomp> i always use intiializer syntax, i.e foo := &StructName{}
16:41 < chomp> with intializers optionally specified either in-order or
by-name inside the {}
16:41 -!- wchicken [~chicken@c-71-235-58-74.hsd1.ct.comcast.net] has joined
16:41 < GeertJohan> ok, so say Ihave a slice then I should put "myslice:
make(slice etc.)" between de {} ?
16:41 < GeertJohan> *de=the
16:41 -!- prip [~foo@kimochi.ath.cx] has joined #go-nuts
16:42 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-153-41.clienti.tiscali.it] has
joined #go-nuts
16:43 < ww> GeertJohan: hou kom nie?
16:44 < magn3ts> If I want to switch back from tip...  do I do `hg update
release` ?
16:44 < ww> hg up -r release
16:45 < GeertJohan> ww: ?
16:45 < chomp> ArgonneIntern, zippoxer, peep this: http://pastie.org/2129918
16:45 < ww> yes why not?
16:46 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-155-41.clienti.tiscali.it] has
quit [Ping timeout: 260 seconds]
16:51 -!- mattn_jp [~mattn@112-68-51-161f1.hyg1.eonet.ne.jp] has quit [Quit:
16:54 -!- fabled [~fabled@] has quit [Quit: Ex-Chat]
16:55 < magn3ts> If I have src/main.go and src/gopcap/pcap/pcap.go...
16:56 < magn3ts> wouldn't I do import "./gopcap/pcap/pcap" ?
16:57 -!- niemeyer [~niemeyer@] has joined #go-nuts
16:58 < chomp> only if you have a pcap binary package actually built in
16:58 < chomp> essentially when you say "./path/to/module" the compiler will
look for ./path/to/module.a
16:59 -!- nekschot [~bla@a78242.upc-a.chello.nl] has joined #go-nuts
16:59 < ww> your life will be easier if you set things up from the beginning
with paths like gitbucket.baz/magn3ts/gopcap
16:59 < chomp> ^
16:59 < chomp> and use goinstall for your own packages
16:59 < magn3ts> It's not my own package.
17:00 -!- pyrhho [~pyrhho@host-92-27-75-48.static.as13285.net] has quit [Quit:
17:00 < chomp> well, then use goinstall for whoever's package it is
17:00 < chomp> goinstall github.com/xb95/gopcap
17:00 < magn3ts> and then use the domain/path in the import like ww listed?
17:00 -!- comex [~ec2-user@ec2-67-202-46-7.compute-1.amazonaws.com] has joined
17:00 < chomp> then import in your code with import "github.com/xb95/gopcap"
17:00 < magn3ts> or goinstall gopcap.googlecode.com/hg/
17:01 < chomp> either way...
17:01 < magn3ts> I see.
17:01 < magn3ts> very clean/neat :)
17:01 < chomp> and actually i guess the import would be import
17:04 < magn3ts> Hm, and what if the package fails to build with goinstall
but builds okay normally?  (it uses a C library if it matters)
17:05 < chomp> might need some changes
17:05 < magn3ts> http://pastebin.com/raw.php?i=mEiVkn9i
17:05 < chomp> there are comment flags that can be added to make
goinstall+cgo play nicely
17:05 < chomp> yeah...
17:05 < magn3ts> :S
17:06 < chomp> guess it hasn't been tested with goinstall?  o_O
17:06 < chomp> basically there should be a
17:06 < ww> see https://bitbucket.org/ww/zoom/src/381984a756b6/zoom.go#cl-1
for example
17:06 < chomp> /#cgo LDFLAGS: -lpcap
17:06 < chomp> err //
17:07 < chomp> before the import "C"
17:07 < magn3ts> Oh I see.
17:07 < chomp> and then goinstall would know how to link
17:07 < ww> iirc the plan is to get rid of gomake so eventually you'll have
to do that anyways
17:08 < chomp> sounds good to me
17:08 < magn3ts> get rid of gomake?  to promote the use of?  godag?
17:08 < ww> just goinstall i think
17:09 -!- powerje_1 [~powerje@nat/google/x-qwesxtviwkmhfzyq] has joined #go-nuts
17:09 -!- powerje_1 [~powerje@nat/google/x-qwesxtviwkmhfzyq] has left #go-nuts []
17:09 -!- powerje_1 [~powerje@nat/google/x-qwesxtviwkmhfzyq] has joined #go-nuts
17:09 < skelterjohn|work> gb will work wherever goinstall does O:-)
17:09 < kevlar_work> for lack of a better name, I've been calling it
gomake++ lol
17:10 < kevlar_work> but I think there are going to be two separate
commands, goinstall and gomake
17:10 < kevlar_work> one builds the current directory, the other searches
GOPATH and does a build/install
17:10 < skelterjohn|work> i believe the intent is to rename goinstall as
gomake at some point
17:10 < skelterjohn|work> and if you goinstall something that can be found
locally, it will do it
17:11 < kevlar_work> no, I think the team is pretty invested in the
"goinstall" name :)
17:11 < skelterjohn|work> i guess it's possible, but i'm quoting a
golang-dev message
17:11 < skelterjohn|work> but that was a while ago, so they may have changed
their minds
17:11 < kevlar_work> oh?
17:11 < kevlar_work> I'm building on what I've seen in the go/build
17:12 < kevlar_work> which is pretty recent
17:12 < skelterjohn|work> that's more recent
17:12 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts
17:12 < kevlar_work> I've just seen lots of presentations and heard lots of
comments from the team about how they want goinstall to be super-duper easy to use
17:12 < skelterjohn|work> they also changed their minds about whether
go/build should exist...  when i suggested it they told me to not waste my time
17:13 * ww hasn't bneen paying attention to the list recently
17:13 < kevlar_work> skelterjohn|work, I had a similar experience, but what
I was actually told in retrospect was "don't bother doing it now until we have a
better idea about what a project should actually look like"
17:13 < skelterjohn|work> it's hard to track golang-dev, since so much of it
is code-review requests
17:13 < skelterjohn|work> what i was told was "won't it just invoke
17:14 < kevlar_work> since I'm using Go at work, I think it's in my own best
interest to keep an eye on all of the mailing lists ;-)
17:14 < kevlar_work> I don't want to get surprised by something and have the
rest of my team use it as ammunition to not use Go in the future.
17:15 < skelterjohn|work> sensible
17:17 < kevlar_work> I can only imagine how difficult it would be to start a
project in go at a company that *didn't* invent it.  There still seems to be some
friction even here.
17:17 -!- powerje_1 [~powerje@nat/google/x-qwesxtviwkmhfzyq] has quit [Quit:
17:18 < magn3ts> I'm curious what the "right" way to handle this pkg is now.
Should I clone the repo and fix it and then goinstall from there?  Or fix locally
and install (how?)
17:18 < skelterjohn|work> you work at google?
17:18 < kevlar_work> but I guess people are always going to be resistant to
change, so I'm resigned to that.
17:18 < skelterjohn|work> magn3ts: if the project sets its makefile up
correctly, it should be installable locally using the makefile or remotely using
17:18 < skelterjohn|work> to the same target
17:19 < skelterjohn|work> if you're interested in contributing and it's a
github project, then the thing to do is clone, fix, and make a pull request back
17:19 < skelterjohn|work> then the original can incorporate your changes (if
they want)
17:19 < kevlar_work> magn3ts, you could (a) fork it on whatever hosting site
it uses, (b) maintain a GOPATH directory in which you install all local forks, or
(c) submit a patch to the maintainer and just `make install` in the mean-time.
17:19 < magn3ts> heh, it's googlecode and I don't like how it handles clones
17:19 < skelterjohn|work> me neither - that's why i switched to github for
my projects
17:20 < kevlar_work> I heart github.
17:20 -!- niemeyer [~niemeyer@] has quit [Ping timeout: 240 seconds]
17:20 < kevlar_work> you also aren't limited to 10 projects on github.
17:22 < kevlar_work> (oh, and github allows you to, you know, use git)
17:22 -!- zaero [~eclark@servo.m.signedint.com] has quit [Ping timeout: 264
17:28 -!- wchicken [~chicken@c-71-235-58-74.hsd1.ct.comcast.net] has quit [Ping
timeout: 244 seconds]
17:29 -!- pjacobs [~pjacobs@] has quit [Ping timeout: 246 seconds]
17:29 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has quit [Ping
timeout: 252 seconds]
17:29 -!- Halavanja [~chatzilla@anlextwls002-095.wl.anl-external.org] has joined
17:30 < Halavanja> do golang templates for plain text or html support
conditionals in the template itself
17:30 -!- NiteRain [~kvirc@c-98-254-236-21.hsd1.fl.comcast.net] has joined
17:30 -!- iant [~iant@] has joined #go-nuts
17:30 -!- mode/#go-nuts [+v iant] by ChanServ
17:30 < Halavanja> such as if {something} >2 Do this
17:30 < skelterjohn|work> i don't believe so
17:30 < Halavanja> okay
17:30 < skelterjohn|work> you can check for the zero-value
17:30 < skelterjohn|work> i think
17:31 < Halavanja> ok
17:31 < kevlar_work> Halavanja, go templates are designed to completely
decouple logic from the template
17:31 < Halavanja> okay so its not like the python genshi templates in that
17:31 < kevlar_work> it's like jsontemplate
17:31 < kevlar_work> iirc
17:32 < kevlar_work> all you get is {field}, {.section struct}, and
{.repeated section list}
17:32 < Halavanja> Ill take a look at that then
17:32 < Halavanja> Thats all i found in the documentation too
17:32 < Halavanja> I just wanted to be sure I wasn't missing something
17:32 < kevlar_work> that's because the documentation is all there is ;-).
17:32 < Halavanja> haha
17:32 < kevlar_work> there are some other goinstallable template packages
that do more
17:32 < kevlar_work> moustache, I believe, is a common one
17:33 < Halavanja> ill give that one a look
17:33 < Halavanja> I'm not sure if i want to deviate from the standard
library yet
17:33 < kevlar_work> you should probably try to use the standard template to
make sure it can't do what you want
17:33 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has quit [Ping timeout:
240 seconds]
17:33 < kevlar_work> I haven't really found it lacking in my own experience
17:34 < kevlar_work> and what few things it's missing I've been able to hack
in using formatters or niladic functions.
17:34 -!- napsy [~luka@] has joined #go-nuts
17:34 < ArgonneIntern> So funny story, one of my college mates got hired at
a company called Epic in madison WI. So more of my friends applied and failed.
They posted their failure on facebook.  So of course I joked in their dispair and
said I had an interview.  Well my friend was apparently so good of friends with me
he put my name in to the company as a recommended potential employee, he thought I
was serious.
17:34 < Halavanja> I have skimmed over those as well and thought it would be
a solution
17:35 < ArgonneIntern> So feeling bad I actually tossed a resume to them.  I
ended up getting a phone interview, which resulted in a knowledge and logic test.
Which has now, today culminated in an on site interview
17:35 < ArgonneIntern> all the while I never actually cared to be hired by
them and was half assing it the entire time
17:35 < kevlar_work> ArgonneIntern, no interest in working there?
17:35 < ArgonneIntern> so this joke has gotten way out of hand
17:35 < kevlar_work> lol.
17:35 < Halavanja> haha
17:36 < ArgonneIntern> well now I don't know, the starting salary is 72k
17:36 < skelterjohn|work> ArgonneIntern: this puts you in a really good
bargaining position if they offer you a job
17:36 < ArgonneIntern> indeed it does
17:36 < skelterjohn|work> say you won't accept anything less than 90
17:36 <+iant> but if you are definitely not going to work for them, you
should tell them that before the interview
17:36 < kevlar_work> that's not bad at all.  Especially for Madison, which
has relatively low Cost of Living.
17:36 < ArgonneIntern> well on the prog test, I literally said in my head,
"some of these aren't very efficient, but I don't care cause I'm not that
17:37 < ArgonneIntern> and still they are paying for me to go up there
17:37 <+iant> I only say that because I once interviewed a candidate, and at
the end he told me he had already taken another job and was only doing the
interview for practice
17:37 <+iant> wow that was annoying
17:37 < ArgonneIntern> originally I counted on them not wanting me, but now
I don't know.  My friend does work there, and they do weed out a ton of candidates
17:37 < kevlar_work> iant, wow.  If you want practice, find a local
university and hit up their career people.  that's a dick move.
17:37 < ArgonneIntern> so maybe I would like working there
17:37 <+iant> of course if there is a possibility of taking the job, go
ahead and do the interview
17:38 <+iant> you'll learn more about the company
17:38 < ArgonneIntern> it's just funny how a joke turns into a flight to
madison all espense paid
17:38 < skelterjohn|work> how far away from madison are you?
17:39 < ArgonneIntern> I don't even graduate till december lmao I wasn't
even going to start applying until sept
17:39 < ArgonneIntern> currently I'm at argonne for internship so 2 and a
half hours
17:39 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has joined #go-nuts
17:39 < skelterjohn|work> where's argonne?
17:39 < ArgonneIntern> but my real house is is about 6 hours away
17:39 < ArgonneIntern> argonne national labs in IL
17:40 < kevlar_work> ArgonneIntern, woo, midwest.
17:40 < ArgonneIntern> they kind of invented commercial nuclear power
17:40 < kevlar_work> I used to be from there.
17:40 < Halavanja> Argone is in the Chicago area
17:40 < ArgonneIntern> yes
17:40 < ArgonneIntern> like 20-30 mins south depending on traffic
17:40 -!- bakedb [~kel@] has quit [Ping timeout: 258
17:40 < kevlar_work> Chicago was always too cold and windy and crowded for
17:41 < ArgonneIntern> I love it here.  I would accept a full time position
here for much less than Epic is about to offer me
17:41 < skelterjohn|work> you must be unmarried
17:41 < ArgonneIntern> no I'm married
17:41 < ArgonneIntern> wife has a degree
17:41 < ArgonneIntern> I'd rather take happiness over money
17:41 < Halavanja> Good way to live life
17:41 < skelterjohn|work> certainly happiness has value
17:41 < ArgonneIntern> it would be a dream job to work here
17:42 < skelterjohn|work> but i'm assuming that epic isn't the pit of hell
17:42 <+iant> but everybody knows that money can buy happiness
17:42 < ArgonneIntern> which is why I'm seriously considering taking the job
if they offer it to me
17:42 < ArgonneIntern> lmao
17:42 < skelterjohn|work> especially if you can bump it up to 80
17:42 -!- awidegreen [~quassel@h-170-226.A212.priv.bahnhof.se] has quit [Remote
host closed the connection]
17:42 < ArgonneIntern> the way my friend says 72 is basically what they
17:42 < skelterjohn|work> are you finishing up undergrad?
17:42 < magn3ts> I got it to install with goinstall, but now it fails to see
the import with the same pattern
17:42 < ArgonneIntern> they don't like bargaining so they just pay you well
up front
17:43 < skelterjohn|work> ArgonneIntern: that just means he wasn't a good
negotiator ;)
17:43 < magn3ts> can't find import: github.com/colemickens/gopcap/pcap
17:43 < ArgonneIntern> yes I made it clear I'm finishing my ungrad first
17:43 < skelterjohn|work> magn3ts, look in $GOROOT/pkg/$GOOS_$GOARCH
17:43 < skelterjohn|work> find the .a file representing the project
17:43 < ArgonneIntern> I spent 8 years in the military to pay for my ungrad
lol, no one is taking that away from me
17:43 < kevlar_work> ArgonneIntern, I originally accepted my current job
because I have, uh, ridiculous student debt to pay off, but the longer I'm here
the more I think I could make a career out of it.  I wouldn't say money can buy
happiness, but it can certainly give you the freedom to be happy later.
17:43 < skelterjohn|work> if the package is at
$GOROOT/pkg/$GOOS_$GOARCH/X/Y.a, then you import "X/Y"
17:44 -!- awidegreen [~quassel@h-170-226.A212.priv.bahnhof.se] has joined #go-nuts
17:44 < magn3ts> ah
17:44 < ArgonneIntern> kevlar_work: yea I know what you mean.  Stability is
happiness for me a lot of the time
17:44 < ArgonneIntern> and epic can def offer that
17:44 < magn3ts> I see now >_> strange that the import name hinges on
the path rather than package name, is that typical for go style?
17:44 < skelterjohn|work> yes.
17:44 < skelterjohn|work> there is no package database
17:44 < skelterjohn|work> other than the filesystem
17:45 < magn3ts> hm, ok
17:45 < skelterjohn|work> it's convention to have the package name be the
last token in the import path, though
17:45 < skelterjohn|work> so people don't get confused
17:45 < magn3ts> heh
17:45 -!- powerje_ [~powerje@nat/google/x-wfbbcszdhmkcajos] has quit [Quit:
17:47 -!- Fish [~Fish@9fans.fr] has joined #go-nuts
17:49 < magn3ts> hm goinstall seems to install to repo-name.a even if I put
the go files in a subdirectory in my repo.  How do I get the package name to be
the last token via a github repo
17:50 -!- robteix [~robteix@nat/intel/x-vmrusavikismhzxk] has joined #go-nuts
17:52 < kevlar_work> magn3ts, you have to make it a subdirectory, e.g.
17:52 < magn3ts> yeah I did that:
17:53 < kevlar_work> so if the files in pcap/* are "package pcap" then you
can goinstall github.com/colemickens/gopcap/tree/master/pcap and import
17:53 < magn3ts> hm.  ok
17:54 < skelterjohn|work> yeah - generally if you "goinstall X" then you
import "X"
17:54 < magn3ts> I was missing the tree/master bit
17:54 < skelterjohn|work> i bet you could goinstall
17:55 < skelterjohn|work> without tree/master
17:55 < magn3ts> neither are working here still
17:55 < skelterjohn|work> yes definitely
17:55 < magn3ts> :s
17:55 < skelterjohn|work> i get an error about pcap.h, but otherwise that
goinstall line worked
17:55 < magn3ts> really?
17:56 < magn3ts> goinstall: github.com/colemickens/gopcap/pcap: open
/home/cole/Code/go/src/pkg/github.com/colemickens/gopcap/pcap: no such file or
17:56 < skelterjohn|work> try
17:56 < skelterjohn|work> goinstall -u -clean
17:56 < skelterjohn|work> if there was a previous version of the code
alreayd downloaded, it doesn't get the new version unless you add -u
17:57 < magn3ts> how was it tracking it?  I was puring
17:57 < magn3ts> oh well, that worked :)
17:57 < skelterjohn|work> i don't follow
17:57 < skelterjohn|work> puring?
17:57 < magn3ts> purging*
17:57 < skelterjohn|work> did you set GOPATH?
17:57 * magn3ts chuckles
17:58 < magn3ts> there's a gopath too?
17:58 < skelterjohn|work> not setting GOPATH isn't a problem
17:58 < skelterjohn|work> but it lets you put downloaded packages somewhere
other than $GOROOT/src
17:58 < magn3ts> oh, I had been wondering about that.
17:59 < GeertJohan> what is the largest integer type in go ?
17:59 < GeertJohan> uint64 ?
17:59 < skelterjohn|work> int64
17:59 < GeertJohan> ok
17:59 < skelterjohn|work> and its unsigned partner uint64
17:59 < GeertJohan> ok :) thx
17:59 < skelterjohn|work> np
17:59 < GeertJohan> unsigned will do best :) won't go negative :)
17:59 < magn3ts> thanks for the help
18:01 < skelterjohn|work> magn3ts: i'm surprised purging the source didn't
work - maybe it checks if the .a file exists, first?
18:02 < kevlar_work> w.r.t this current thread on golang-nuts; what's so
freaking "time critical" about finance?
18:02 < kevlar_work> when I think time-critical, that's definitely not what
my mind goes to
18:02 < skelterjohn|work> auto-traders
18:03 < kevlar_work> I think routers, mars rovers, and moving vehicles.
18:03 < skelterjohn|work> they are extremely time-critical
18:03 < skelterjohn|work> mars rovers are *not* time critical :)
18:03 < exch> sniping eachother on sub-millisecond timescales
18:03 < xb95> It's called 'high frequency trading'.
18:03 < xb95> http://en.wikipedia.org/wiki/High-frequency_trading
18:04 < ArgonneIntern> facebook is time critical, finance can take a back
18:05 < ArgonneIntern> gotta get those status updates man
18:05 < ArgonneIntern> I want to know the second someones kid falls over, my
happiness depends on it
18:05 < kevlar_work> I still don't see how high-frequency trading is
something that Go couldn't do.  If you really don't want the stop-the-world, then
structure your program such that you can run it without the GC
18:06 < skelterjohn|work> yes - i mentioned that in the ML thread
18:06 < skelterjohn|work> coding in such a way to avoid allocations is just
as challenging as manual memory management
18:06 < skelterjohn|work> that is, not particularly, but you need to be
18:06 < kevlar_work> I do see that Go can't be used in real-time
applications which require determinism because it relies so much on memory
18:06 < kevlar_work> but determinism isn't a requirement in time critical
applications, just being "fast enough"
18:06 < Namegduf> Go is not really designed for "hard realtime"
18:06 < Namegduf> I think.
18:06 < kevlar_work> Namegduf, precisely.
18:06 < Namegduf> But hard realtime is relatively rare.
18:07 < Namegduf> Even if it could do it, it'd probably be bad at it.
18:07 < kevlar_work> things like mars rovers and routers and moving vehicles
18:07 < Namegduf> Routers aren't hard realtime
18:07 < Namegduf> They're "soft".
18:07 < Namegduf> Other examples of "soft" are video rendering.
18:08 < kevlar_work> past a certain bandwidth point, I would say routers do
become hard realtime
18:08 < Namegduf> Where being behind is bad but odd cases are tolerable, the
key thing is speed
18:08 < skelterjohn|work> i have to say again, mars rovers do not really
have time-critical code
18:08 < kevlar_work> skelterjohn|work, having worked on a mars rover, they
are hard real-time systems.
18:08 < skelterjohn|work> what on there needs hard real-time?
18:08 < Namegduf> Hmm.
18:09 < skelterjohn|work> certainly not the control
18:09 < kevlar_work> skelterjohn|work, at a minimum, the
18:09 < skelterjohn|work> they don't go fast
18:09 < Namegduf> Constant sending of information?
18:09 < skelterjohn|work> oh that's not the rover
18:09 < kevlar_work> skelterjohn, who do you think controls EDL?
18:09 < skelterjohn|work> but i can see that stuff needing it
18:09 < kevlar_work> skelterjohn, and running on a slow CPU makes the
real-time even more important
18:09 < Namegduf> Proper high speed routers aren't even programmed in a
general programming language anyway.
18:09 < skelterjohn|work> i guess as someone who doesn't work on rovers, i
thought of the rover bit as being the bit that tooled around on the martian tundra
18:10 < skelterjohn|work> go this way for a bit, go that way for a bit
18:10 < ArgonneIntern> the best part is how it's what, 5 year old tech, once
it gets there lol
18:10 < Namegduf> What do they call that weird thing that routes straight
from NIC to NIC bypassing the CPU?
18:10 < kevlar_work> ArgonneIntern, it's only a 7 month flight, but the
technology freeze happens 1-2 years before launch
18:10 < Namegduf> All I remember is that when it turns off, due to filtering
or such, if you're putting a lot of bandwidth through it, Bad Things happen.
18:10 < ArgonneIntern> kevlar_work: so why is everyone freaking about a
manned mars flight taking years to get there?
18:11 < Namegduf> I think special programmable hardware is used anyways
18:11 < skelterjohn|work> no one thinks it takes years to get there...
18:11 < ArgonneIntern> kevlar_work: if we can be there in 7 months
18:11 < skelterjohn|work> it just takes a really long time
18:11 < kevlar_work> ArgonneIntern, the problem is that it's a 7 month
flight, 140 day stay, and then 7 month flight back if you take optimal
18:11 < kevlar_work> wow, trajectories*
18:11 < ArgonneIntern> I like the first version better
18:11 < Namegduf> Anyways, I think whether Go can do hard realtime is a
18:11 < kevlar_work> indeed.
18:12 -!- icy [~icy@lighttpd/icy] has joined #go-nuts
18:12 < Namegduf> Not a problem designed to solve, often not a problem
solved with regular languages anyway
18:12 < kevlar_work> yeah.
18:12 < kevlar_work> or a regular operating system.
18:12 < ArgonneIntern> did google guys intend for go to be used at NASA?
18:12 < skelterjohn|work> heh
18:12 < kevlar_work> ArgonneIntern, lol no.
18:12 < Nisstyre> yes
18:12 < kevlar_work> well, not for hard real time programming at NASA.
18:12 -!- pjacobs [~pjacobs@rrcs-24-73-248-196.sw.biz.rr.com] has joined #go-nuts
18:13 < zippoxer> if NASA uses python somewhere in their systems...
18:13 < ArgonneIntern> ROFL
18:13 < zippoxer> so they'll probably switch to go
18:13 < skelterjohn|work> go was intended to be a lang that could take
advantage of multi-core systems
18:13 < kevlar_work> but let me tell you, there are plenty of things that
are written in disgusting masses of Python at JPL that should be rewritten, and Go
would be a candidate.
18:13 < ArgonneIntern> my boss thinks go is excellent for systems
18:13 < Halavanja> Kevlar_work: lol
18:14 < skelterjohn|work> especially multi-core servers
18:14 < ArgonneIntern> skelterjohn|work: yes, which is basically what I'm
doing lol
18:14 < zippoxer> the truth is that for most simple web system, python is
much better in most perspectives
18:14 < zippoxer> systems*
18:14 < skelterjohn|work> if you want to serve a page to a few buddies
18:14 < skelterjohn|work> then html is the language for you
18:14 < zippoxer> I said system!
18:14 < icy> I have a simple http server using http.ListenAndServe which
does some tiny work upon requests.  right now it gets about 2-3 req/s but I see
240 goroutines (runtime.Goroutines()).  this number seems a bit excessive.  how
can I find out what those goroutines are doing?
18:15 < skelterjohn|work> but writing complex programs in python has perils
18:15 < Namegduf> "system" doesn't convey meaning.
18:15 < skelterjohn|work> i've done it, and it's easy for the code to lose
shape and become unmanageable
18:15 < kevlar_work> icy, ^\
18:15 < Namegduf> And whether Python is "better" is very much a matter of
18:15 < zippoxer> ur right
18:15 < Namegduf> I happen to disagree.
18:15 < skelterjohn|work> different tools for different tasks
18:15 < icy> kevlar_work: ctrl+\ will give me stack traces?
18:15 < skelterjohn|work> i consider both python and go to be in my toolbelt
18:15 < Namegduf> Go's ridiculously cheap and easy
synchronous-IO-in-concurrent-goroutines makes everything servery easy
18:16 < ArgonneIntern> icy: 2-3 reuqests should def not give you 240 go
routines lol
18:16 < skelterjohn|work> it depends on what he's doing with the requests
18:16 < ArgonneIntern> unless you told it to do that
18:16 < ArgonneIntern> right
18:16 < icy> ArgonneIntern: I even force Connection: close on them
18:16 < zippoxer> when the code grows up you'll want some static typed
18:16 < skelterjohn|work> perhaps there are goroutines that have gotten
untethered from the rest of the runtime
18:16 < skelterjohn|work> and just sit there taking up memory
18:16 < skelterjohn|work> (though they won't take up any cycles at all)
18:17 < Namegduf> I reject the premise that writing down an extra token (the
type) when declaring variables, only sometimes, makes prototyping that much
slower.  :P
18:17 < kevlar_work> icy, yes, it will dump stack traces for all of your
goroutines.  you're probably not closing the Bodu
18:17 < kevlar_work> Body*
18:18 < skelterjohn|work> kevlar_work: interesting about ctrl+\ I didn't
know that
18:18 < ArgonneIntern> error = request.Body.Close()
18:18 < kevlar_work> skelterjohn, I believe SIGQUIT triggers a panic, which
triggers a stack trace.
18:18 < skelterjohn|work> gotcha
18:18 < kevlar_work> at least that's how it seems.
18:18 < skelterjohn|work> not a terminal expert
18:19 < skelterjohn|work> i only know ctrl-c and kill -9
18:19 -!- zaero [~eclark@173-28-217-101.client.mchsi.com] has joined #go-nuts
18:19 < skelterjohn|work> there is no middle ground.
18:19 < ArgonneIntern> kill -9
18:19 < ArgonneIntern> ^win
18:20 < icy> I guess sending a SIGSEGV would trigger a panic too
18:21 < icy> kevlar_work: so even if the handler function returns, I have to
close the Body?
18:22 -!- ijknacho [~goofy@cpe-72-190-64-3.tx.res.rr.com] has joined #go-nuts
18:22 < kevlar_work> icy, you always have to close the body
18:22 < icy> well I expected it to be garbage collected
18:23 < skelterjohn|work> goroutines aren't garbage collected (yet,
18:24 < ArgonneIntern> so we have to delete memory manually in them?
18:24 < skelterjohn|work> not what i meant, exactly
18:24 < ArgonneIntern> well if a variable points to something..
18:24 < skelterjohn|work> but if you do something like, "ch := make(chan
int); go func() { ch <- 2 }()" and then do nothing with ch from then on
18:24 < skelterjohn|work> there is a hanging goroutine
18:24 < skelterjohn|work> ch won't get cleaned
18:24 < ArgonneIntern> oh crap...
18:25 < ArgonneIntern> yeah, that's my situation, better clean that up
18:25 < skelterjohn|work> i don't know if this has been changed
18:25 < chomp> really?  o_O
18:25 < ArgonneIntern> I'm glad someone mentioned that
18:25 < ArgonneIntern> lol
18:25 < skelterjohn|work> but it's certainly possible to clean this up
18:25 < skelterjohn|work> like i said, this may have been fixed, but it used
to be an issue
18:25 < chomp> even if someone reads from ch and the goroutine finishes?
18:25 < skelterjohn|work> if the goroutine finishes, then it's a different
18:25 < chomp> ah ok.
18:26 < chomp> blew my mind for a second there.  :p
18:26 < skelterjohn|work> i'm talking about when a goroutine hangs, and can
never ever finish
18:26 < ArgonneIntern> well in icy's situation the goroutine finishes
18:26 < icy> well, my goroutines finish
18:26 < skelterjohn|work> i thought you had 240 of them
18:26 < icy> I have
18:26 < skelterjohn|work> i'm not saying you spawned them all
18:26 < icy> but the function that the goroutines runs, returns
18:26 < zozoR> go func() {ch := make(ch int); ch <-2} <-- would hang
right?  :D
18:26 < skelterjohn|work> zozoR: right
18:26 < kevlar_work> skelterjohn, ArgonneIntern, that's still the behavior
18:26 < icy> and there is no channel stuff like in your example
18:26 < zozoR> awesome :D
18:27 < kevlar_work> bradfitz suggests using buffered channels when that
might happen
18:27 < skelterjohn|work> kevlar_work: do you know if there has been any
more thought on it?
18:27 < chomp> ok, i can see why you'd expect that to be collected, but it
looks more like programmer error :p
18:27 < ArgonneIntern> so a go routine can return and not...  end itself?
18:27 < skelterjohn|work> this is something that the runtime can figure out
18:27 < kevlar_work> so the goroutine writes successfully and then the
goroutine exits and if the channel isn't used anywhere, it gets GC'd
18:27 < chomp> unbuffered channel though
18:28 < chomp> ah nevermind
18:28 -!- pjacobs [~pjacobs@rrcs-24-73-248-196.sw.biz.rr.com] has quit [Quit:
18:28 < skelterjohn|work> if you can't get from a goroutine to an actively
running goroutine through shared memory, then it can never resume
18:28 < kevlar_work> skelterjohn, it's currently still impossible for the GC
to know that a goroutine is completely disconnected from the world
18:28 < skelterjohn|work> when you say impossible, you mean it doesn't do
it?  or there is a fundamental reason
18:28 < ArgonneIntern> so if a channel is still open, the go routine won't
18:29 < kevlar_work> ArgonneIntern, well, if it's closed, it will panic ;-)
18:29 < kevlar_work> currently a goroutine must return to be deleted
18:29 < icy> hm my goroutine number is increasing slowly (though not with
the same rate as I get req/s)
18:29 < skelterjohn|work> ArgonneIntern: only close channels if you're the
18:29 < icy> now I have 247 of them
18:29 < ArgonneIntern> how do you see num of go routines?
18:30 < icy> runtime.Goroutines()
18:30 < kevlar_work> icy, did you ^\ and look through the traces?
18:30 < icy> I'm going to add a defer req.Body.Close() to the top of the
handler function and see if that helps
18:31 < skelterjohn|work> kevlar_work: i'd think the problem would be not
that hard - you take an inactive goroutine and figure out what channel it's
waiting on, and see what goroutines know about that channel
18:31 < skelterjohn|work> if no other goroutines know about it, then the
goroutine is lost
18:31 < skelterjohn|work> if an active goroutine knows about it, the
goroutine is not lost
18:31 < skelterjohn|work> if only inactive goroutines know about it, you
keep searching
18:31 < skelterjohn|work> via the same method
18:32 < skelterjohn|work> of course there is a "will this instruction ever
execute" question there, which is not answerable (halting problem), but you can
get most of them
18:32 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
18:32 < chomp> there is no doubt it would be possible to implement as far as
i can tell
18:32 < skelterjohn|work> and you won't clean up something that needs to
stay (no false positives)
18:32 < chomp> but is it worth implementing
18:32 < chomp> there are a lot of resources a coroutine could be blocking on
18:32 < icy> hm now I need to find out how to scroll in this screen session
18:32 < icy> to see the traces
18:32 < chomp> that might never be unblocked, and might have a means of
detecting that
18:33 < kevlar_work> skelterjohn, it's possible for another goroutine to
reference something in the halted goroutine that is able to trigger sending the
channel to another goroutine which could then unblock it
18:33 < skelterjohn|work> that wouldn't be messed up by what i'm suggesting
18:34 < chomp> the runtime would know that the goroutine is the only one who
has a reference to the channel
18:34 < GeertJohan> I still haven't really figured out how to solve the
whole no-inheritance problem :s I do know about the "sub-interfaces" thing ''type
Foo interface{a() string};; type Bar interface{Foo; b() string}'' But I still
didn't really figure out what I really need...  I explained my problem/question
here: http://pastebin.com/wK1KTawR
18:34 < chomp> which would make it the only goroutine capable of passing it
off to someone else, and yet it's blocking on that channel already
18:34 < skelterjohn|work> whatever it is that the goroutine is blocking on
(channel, sync.mutex) you look for references in the other goroutines
18:34 < ArgonneIntern> yea my http.handlerfuncs don't close either
18:35 < kevlar_work> skelterjohn, there's also the small problem that there
is no notion of "owning" data, so you can't see what goroutines "own" references
to the channel.
18:35 < ArgonneIntern> I'm explicitely closing the request body and my go
routines hang
18:35 < skelterjohn|work> what i'm saying has nothing to do with ownership
18:35 < chomp> what about a resource that can be unblocked by external
influence but still may never be unblocked
18:35 < kevlar_work> some of this will come when we get escape analysis, so
you might be able to build on that, but I rather doubt it will even be easy with
18:35 < skelterjohn|work> just knowledge-of
18:35 < chomp> liek say reading a net.Conn
18:35 -!- pjacobs [~pjacobs@] has joined #go-nuts
18:35 < chomp> whose opposite end is supposed to be fed by another goroutine
that is for whatever reason not operating
18:35 < skelterjohn|work> that wouldn't get cleaned
18:35 < icy> ArgonneIntern: so you see the same as I do?
18:35 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has joined
18:35 < skelterjohn|work> unless you can prove it won't happen
18:36 < ArgonneIntern> icy: yes
18:36 < skelterjohn|work> i'm not saying there're be no false negatives
18:36 < ArgonneIntern> icy: mine hang until I end the http connections from
the client
18:36 < skelterjohn|work> just that there would be no false positives (where
positive is "clean this goroutine up"
18:36 < skelterjohn|work> )
18:36 < icy> ArgonneIntern: the weird thing is that it seems to happen just
with some of them as it does not increase at the same rate as I get requests
18:36 < kevlar_work> skelterjohn, you're welcome to try to implement it ;-)
18:36 < icy> ArgonneIntern: ah no, yours will be just http keep-alive
18:36 < skelterjohn|work> the runtime is complicated :<
18:36 < icy> try req.Close = true
18:36 < skelterjohn|work> if someone showed me how it worked i probably
would try
18:37 < skelterjohn|work> but i've looked..
18:37 < kevlar_work> skelterjohn|work, me too :(
18:37 < skelterjohn|work> i can't follow it
18:37 < kevlar_work> I am always tempted to go to Go office hours and ask
whoever is there to walk me through it ;)
18:37 < skelterjohn|work> haha
18:37 < kevlar_work> but I'm either not available or I convince myself
that'd be a bad use of their time.
18:38 < skelterjohn|work> wait...
18:38 < skelterjohn|work> there are actually go office hours?
18:40 < ArgonneIntern> wow this sucks
18:40 < ArgonneIntern> this is a serious issue IMO
18:41 < chomp> what?
18:41 < ArgonneIntern> the fact that go routines stay open
18:41 < chomp> it sounds like you're doing it wrong
18:41 < ArgonneIntern> I know I am
18:41 < ArgonneIntern> but it shouldn't be this unintuitive
18:41 < ArgonneIntern> it should work like the rest of the language, just as
a general flow of it all
18:42 < chomp> i'm not sure what you mean
18:42 < chomp> i've never had this problem with anything
18:42 < ArgonneIntern> my go routines are staying open for, what I'm
assuming is, data not being garbage collected?
18:42 < chomp> did i miss a paste somewhere?
18:42 < ArgonneIntern> I'm still a bit confused as the convo went crazy for
18:42 < chomp> that's nonsensical
18:42 < icy> so I've started the daemon again with "defer req.Body.Close()"
added, now it has 30 goroutines.  I'll see if it keeps on slowly growing
18:43 < skelterjohn|work> ArgonneIntern: it's usually not a problem - just
be careful about spawning things that just send to channels...  if the reader of
that channel might stop halfway through, you have a dangling goroutine
18:43 < ArgonneIntern> http://www.pastie.org/2130443 this routine stays open
and never ends.  When I would think it should
18:44 < ArgonneIntern> :'(
18:44 < skelterjohn|work> tl;dr
18:44 < skelterjohn|work> i don't think it says "go" in there
18:44 < ArgonneIntern> that's an http handler func
18:44 < ArgonneIntern> that is spawned when a request comes in
18:44 < ArgonneIntern> so that is the routine
18:44 < skelterjohn|work> so one of the locks are never released to it?
18:45 < icy> skelterjohn|work: http.ListenAndServer() calls go on your
handler funcs automatically
18:45 < ArgonneIntern> no they are both released
18:46 < skelterjohn|work> i suggest adding some defers
18:46 -!- hargettp_ [~hargettp_@dhcp-161.mirrorimage.net] has joined #go-nuts
18:46 < skelterjohn|work> well, maybe not
18:46 < skelterjohn|work> currentRequests is a channel?
18:46 < chomp> i would in any case defer func() { request.Close = true }()
18:46 < ArgonneIntern> there is nothing there that screams, hey keep this
routine open
18:46 < ArgonneIntern> no
18:46 < skelterjohn|work> a slice?
18:46 < ArgonneIntern> currentRequests is a map
18:46 < skelterjohn|work> no a map
18:47 < icy> chomp: why would you defer that?
18:47 < ArgonneIntern> sorry, sometimes I type faster than I can think
18:47 < chomp> because he wants it to happen regardless of how the goroutine
18:47 < chomp> presumably
18:47 < ArgonneIntern> it's just natural to hit the enter key at the end of
a thought
18:47 -!- GeertJohan [~Squarc@ip4da06866.direct-adsl.nl] has quit [Quit: Leaving.]
18:47 < chomp> same with request.Body.Close(), no?
18:47 < icy> so just do it in the beginning :)
18:48 < skelterjohn|work> in his code there are only two ways to return, and
only one of them sets request.Close = true
18:48 < chomp> well, touche there
18:48 < icy> no, Body.Close() actually closes it
18:48 < chomp> i assumed printError would panic or something, i guess that's
a poor assumpition
18:48 < icy> req.Close just tells it to close it after writing to it (aka
disable http keep-alive)
18:48 < ArgonneIntern> skelterjohn|work: I was testing the Close = true, I
never get into that return in the data I'm testing it with
18:48 < chomp> none of this would keep the goroutine hanging around in any
case anyway
18:49 < skelterjohn|work> yeah...  does this function always return?
18:49 -!- Dr_Who [~tgall_foo@linaro/tgall-foo] has joined #go-nuts
18:49 < ArgonneIntern> skelterjohn|work: it seems to, it returns all the
data I ask it to
18:49 < skelterjohn|work> are you and icy working on the same code?
18:49 < ArgonneIntern> skelterjohn|work: no
18:50 < ArgonneIntern> skelterjohn|work: I don't know him at all, his
questions just made me check my code and see if I had the same problem, and I do,
18:50 < skelterjohn|work> what if you added defer request.Body.Close()?
18:50 < ArgonneIntern> I'll try it
18:50 < skelterjohn|work> since you don't close it in the line 15 clause
18:51 < ww> func pub(i) { for _; !closing() { i <-pint } }
18:51 < ArgonneIntern> but if I don't get into that if it shouldn't matter
18:51 < ww> go pub(me)
18:51 < chomp> ww, excellent.  i still have about 7 hours before that
happens >.>
18:52 < chomp> me := make(chan beer) ?
18:52 < ArgonneIntern> defering the close does nothing
18:52 < ww> chomp: make(chan pint) yes :)
18:52 < skelterjohn|work> ArgonneIntern: what makes you think that this is
the goroutine that is sticking around?
18:53 < chomp> i assumed pint was simply a value of type beer :)
18:53 < ArgonneIntern> because I have test programs that call just this
18:53 < skelterjohn|work> oh, outside of the context of a server?
18:53 < icy> http://go.paste.lighttpd.net/2117 this is my current code
18:53 < ArgonneIntern> and the routine numbers go up
18:53 < ArgonneIntern> yes
18:53 < skelterjohn|work> that is odd
18:53 < ArgonneIntern> but after the request is served it doesn't end the
18:53 < skelterjohn|work> well, try commenting out bits until it stops
happening :)
18:53 < ArgonneIntern> but once the client is closed the routines close
18:53 < skelterjohn|work> i see
18:54 < skelterjohn|work> then my guess is there are goroutines trying to
read from the request body
18:54 < ArgonneIntern> 1 routie per request
18:54 < ArgonneIntern> and I explicitely close it
18:54 < skelterjohn|work> what if you try it with a handler that just
returns immediately
18:54 < ArgonneIntern> lemme see
18:55 < chomp> and then iteratively move your return down by one line and
see what happens :)
18:55 < skelterjohn|work> right :)
18:55 < skelterjohn|work> also, i think the request.Body.Close() is
unnecessary - it must already be closed if ioutil.ReadAll(request.Body) returns
18:56 < chomp> hmm gdb can poke around individual coroutine stacks can it
18:56 < ArgonneIntern> does the client have to close the connection or
18:56 < skelterjohn|work> ArgonneIntern: i don't know enough about http to
answer that
18:56 < ArgonneIntern> I changed it to do nothing but return and it still
18:56 < ArgonneIntern> so it must be something with the client
18:57 < icy> ArgonneIntern: no it should not have to close the connection.
if the server sends "Connection: close" header
18:57 < chomp> hmmm
18:57 < ArgonneIntern> icy: i'm not sending that
18:57 < ArgonneIntern> icy: maybe I should lol
18:57 < chomp> looking at ServeHTTP source in src/pkg/http/server.go
18:57 < icy> req.Close = true does it
18:58 < chomp> it seems possible that this is a bug
18:58 < icy> well actually if you send data before setting this flag, then
it can't send the header because it already sent the body
18:58 < ArgonneIntern> aha!  let me tryt his
18:59 < icy> but I do set it immediately in my src :)
18:59 < ArgonneIntern> didn't help
18:59 < icy> chomp: where exactly do you spot a bug?
18:59 < chomp> i might not, just trying to make sense of this
19:00 < chomp> what happens if timeout is selected before done
19:00 < chomp> seems the goroutine that calls the handler will block writing
to done
19:00 < icy> I checked if it's keeping any file descriptors open which is
100% not the case so those are all closed
19:01 < ArgonneIntern> it seems wierd to me that I close the client and the
routines end
19:01 < chomp> it wouldnt preclude all fds being closed
19:01 < ArgonneIntern> something isn't closing
19:01 < chomp> but yeah that doesnt make sense then
19:02 < chomp> hmm
19:03 < ArgonneIntern> yea this kinda sucks...cause if I don't figure this
out I can't have this happening over 1000 node request a day
19:03 < ArgonneIntern> that will bog down very fast
19:03 < skelterjohn|work> actually...  not that fast :)
19:03 < skelterjohn|work> the go runtime can track 100s of thousands of
goroutines without issue
19:03 -!- bakedb [~kel@cpc4-lea21-0-0-cust755.6-3.cable.virginmedia.com] has
joined #go-nuts
19:03 < skelterjohn|work> but yes...it's still not ideal
19:04 -!- Crnobog [~crnobog@cpc3-nmal12-0-0-cust48.croy.cable.virginmedia.com] has
quit [Read error: Connection reset by peer]
19:04 < chomp> it seems like it's possible for closeAFterReply to maybe not
be set to true?
19:04 < ArgonneIntern> well they do close when the client ends, but I would
certainly like them to close before that
19:04 < chomp> even if Connection: close is set in the header?
19:04 -!- keithcascio [~keithcasc@nat/google/x-ltlbsdrbeynkaznn] has joined
19:04 < ArgonneIntern> yes chomp
19:04 < ArgonneIntern> err wait, who has to set that?
19:04 < ArgonneIntern> the server or the client
19:04 < chomp> it's internal to http
19:04 -!- Crnobog [~crnobog@cpc3-nmal12-0-0-cust48.croy.cable.virginmedia.com] has
joined #go-nuts
19:04 < chomp> go code
19:05 < icy> both can set that :)
19:05 < icy> req.Close = true at the beginning will make it send that as the
response header
19:05 < chomp> no the actual flag in http
19:05 < chomp> in the http.Response
19:06 -!- virtualsue [~chatzilla@nat/cisco/x-gypngijjkedteudn] has quit [Read
error: Operation timed out]
19:06 < ArgonneIntern> request is of type http.Response in a handler func
19:06 < ArgonneIntern> so request.Close = true sets it
19:07 < chomp> honestly i'm not seeing how that's true
19:07 < icy> so I had it running for a while now and I see 65 goroutines
19:08 < chomp> looking at the http package sources, it looks like
response.closeAfterReply does not get set properly in all cases
19:08 < icy> with 27 file descriptors open
19:09 -!- gnuvince|work [8e544424@gateway/web/freenode/ip.] has quit
[Quit: Page closed]
19:09 < ArgonneIntern> ahhhhh
19:09 < ArgonneIntern> I see what you're saying chomp
19:09 < icy> chomp: even if it would be looping one more time, trying to get
another request from the client, it should detect it when the client goes away
(timeout, connection close)
19:09 < chomp> that's true icy, i was just realizing that
19:09 < ArgonneIntern> chomp: you mean in the header data type in the
request type
19:09 < chomp> in fact if Connection: close is in the response, the client
should close the connection and the read should fail
19:10 < chomp> unless the client is being stupid
19:11 < icy> eh if I see this right, the timeouts are by default 0?
19:11 < chomp> ArgonneIntern, actually i mean the closeAfterReply flag in
the response struct defined in server.go at line 120 of src/pkg/http/server.go
19:11 < skelterjohn|work> shouldn't depend on the client not being stupid
19:11 < skelterjohn|work> i think that's "software for business 101"
19:11 < chomp> skelterjohn|work, heh
19:12 < chomp> in this case it appears to?  if the client leaves a
connection open, there's no way to force it closed short of using HTTP < 1.1
19:12 < chomp> or i guess setting a short timeout ?
19:12 -!- tncardoso [~thiagon@] has quit [Quit: Leaving]
19:13 < icy> chomp: the server will close the connection too if you send
Connection: close
19:14 < icy> or well, it should
19:14 < chomp> well there sure isn't any code here to make that happen
19:14 < chomp> it only explicitly sets closeAfterReply to false iff
Connectoin == keep-alive
19:14 < chomp> but it defaults to false anyway and is only set true in a few
unrelated cases
19:15 < ArgonneIntern> it's certainly not closing connections for me, no
matter what I do
19:15 < ArgonneIntern> only thing that closes it is the client ending
19:15 < ArgonneIntern> which is crap
19:15 -!- virtualsue [~chatzilla@host81-148-52-109.in-addr.btopenworld.com] has
joined #go-nuts
19:15 < chomp> can you change your client to use an HTTP 1.0 request
19:15 < chomp> just to test this
19:15 -!- dreadlorde [~dreadlord@c-68-42-82-10.hsd1.mi.comcast.net] has quit [Ping
timeout: 240 seconds]
19:16 < ArgonneIntern> my client is also in go lol
19:16 -!- huin [~huin@] has joined #go-nuts
19:16 < ArgonneIntern> Imean, in my situation it won't hurt, because the
clients always eventually end when requests have been met
19:16 < ArgonneIntern> but it's def not the optimal situation
19:17 < ArgonneIntern> I essentially have go routines doing nothing
19:17 < ArgonneIntern> since that go routines end when the client ends, it
just has to be be connection related
19:18 < skelterjohn|work> sounds like the issue has been diagnosed...  maybe
someone should file an issue, and fix it
19:18 < ArgonneIntern> hah...I'm still betting it's something we don't know
19:19 < chomp> no this is pretty clearly what's going on.
19:19 < icy> I don't think it's diagnosed
19:19 < chomp> after your request is served, the server continues to block
reading on the connection
19:19 < chomp> so unless the client closes the connection, your goroutines
will hang
19:19 < icy> I'm trying to find the src of ReadRequest as seen invoked in
line 177 of server.go
19:19 < chomp> there is actually -no way- to force the server to close after
19:19 < crunge> I want to create a generator that can be "cancelled" before
having produced all the data it can.  My first thought is a to make a goroutine
that sends the data on a channel and have the recipient close the channel, but it
looks like the sender can't properly detect that.  Do I give the sender a
"finished" channel?  Is there a more idiomatic way of doing this?
19:20 < skelterjohn|work> crunge: yes a finished channel
19:20 < skelterjohn|work> that's the idiomatic way
19:20 < skelterjohn|work> having the receiver close the channel is
specifically frowned upon
19:20 < skelterjohn|work> (since it induces a race condition)
19:21 < ArgonneIntern> does go even support the receiver ending it
19:21 < crunge> skelterjohn|work: yeah, since detecting a closed channel is
done with the receive operator, the sender would have to receive the data it might
have stuffed in
19:21 < ArgonneIntern> I don't think it does
19:21 < chomp> sure, anyone can close a channel
19:21 -!- Dr_Who [~tgall_foo@linaro/tgall-foo] has quit [Quit: Dr_Who]
19:21 < ArgonneIntern> oh you're talking channels
19:21 < skelterjohn|work> crunge: i'm not really following what you said
there, but i'm glad you have it under control :)
19:22 < crunge> skelterjohn|work: yeah, I was signalling that I understand
the reason
19:22 < skelterjohn|work> cool :)
19:22 < skelterjohn|work> ah, yes i follow you now
19:22 < skelterjohn|work> the sender could also detect it by trying to send
and catching the panic
19:22 < skelterjohn|work> but that seems a bit clunky
19:22 < crunge> yeah
19:23 -!- virtualsue [~chatzilla@host81-148-52-109.in-addr.btopenworld.com] has
quit [Ping timeout: 250 seconds]
19:23 < crunge> I can at least see that as un-idiomatic
19:23 < skelterjohn|work> i wrote some stuff to run a process, and when the
process returned a value would be sent on a channel.  there was also another
channel for killing the process - if you sent an int on it, it would get killed
with that signal
19:24 < ArgonneIntern> chomp: you wanna report this?
19:24 < chomp> ArgonneIntern, i'm going to put together a test case and make
sure i've got a solid understanding of it
19:24 < chomp> and maybe also a good working solution for it
19:24 < ArgonneIntern> ok
19:24 < chomp> but sure, i'll post something on dev
19:25 < chomp> it's unclear to me what the "correct" solution is
19:25 -!- cafesofie [~cafesofie@ool-18b97779.dyn.optonline.net] has joined
19:25 < crunge> So with the "finished" channel, am I trying to read a
boolean from it or just wait for it to be closed.  I don't want to have to send a
"not finished" signal for the generator to produce the next item.
19:25 < skelterjohn|work> i have a 2d geometry library i've been working
on...  is "geom" an acceptable name or would "geom2d" be better?
19:25 < chomp> but maybe there'll be some insight from others
19:25 -!- yebyen [~yebyen@martyfunkhouser.csh.rit.edu] has quit [Ping timeout: 276
19:25 < chomp> skelterjohn|work, geom sounds nice to me
19:25 < crunge> skelterjohn|work: goem/2d?
19:26 < skelterjohn|work> implies that one day i'd add a geom/3d :)
19:26 < chomp> crunge, good luck importing that ;)
19:26 < crunge> skelterjohn|work: someone else might
19:26 < chomp> (without a name override)
19:26 < chomp> i do agree that more general geom is better
19:26 < skelterjohn|work> and yeah - couldn't have 2d as a package name
19:26 < chomp> it will obviously be extended one day
19:26 < ArgonneIntern> chomp: shouldn't the solution be to for request.Close
= true to actually do something
19:26 < chomp> and you can worry about dimensionality when that day comes :)
19:26 < crunge> well, geom/g2d if a leading digit makes an illegal
19:27 < chomp> ArgonneIntern, looking at the documentation, that certainly
seems like a good idea :P
19:27 < crunge> so how do I check a channel without blocking?
19:28 < ArgonneIntern> chomp: I mean looking at the docs it doesn't look
like it actually does anything
19:29 < skelterjohn|work> crunge: select
19:29 -!- virtualsue [~chatzilla@nat/cisco/x-jvwyxhzxuhrljvtn] has joined #go-nuts
19:29 < icy> ArgonneIntern: I'm looking at the src I can't spot .Close being
referenced anywhere
19:29 < skelterjohn|work> if you add a default: case to your select, it will
fire instead of blocking on the channel read/send
19:29 < chomp> ive found plenty of references to .Close, just not in
19:30 < icy> chomp: where?
19:30 < crunge> skelterjohn|work: so the default case is what triggers work
to be done, the specific case causes the return
19:30 < skelterjohn|work> sounds about right, yeah
19:30 < chomp> persist.go, transfer.go, transport.go
19:30 < chomp> actually transfer.go is irrelevant
19:30 -!- bakedb [~kel@cpc4-lea21-0-0-cust755.6-3.cable.virginmedia.com] has quit
[Ping timeout: 250 seconds]
19:30 < chomp> persist.go appears to be relevant though
19:31 < crunge> select { case iAmFinished := <- finished_chan: return;
default: doMoreCrap() }
19:31 < aiju> iHaveFinished
19:31 < chomp> unfortunately setting req.Close = true in your reponse
function will not elicit an effect until the -next- successful read on the
connection, so it seems
19:31 < skelterjohn|work> case <- finished_chan: return
19:31 < aiju> ah fuck, that joke doesn't work in english
19:31 < skelterjohn|work> don't need to actually store it
19:31 < crunge> skelterjohn|work: word
19:32 < ArgonneIntern> I set it to true and readall from it
19:32 < ArgonneIntern> and it doesn't do anything
19:32 < chomp> ?
19:32 < crunge> aiju: in English I think it makes a reasonable double
entendre.  The work is done, and the goroutine is destined to die
19:32 < chomp> not the same
19:32 < skelterjohn|work> crunge: i bet he's making a sexual referense
19:32 < skelterjohn|work> reference
19:32 < aiju> haha
19:32 < aiju> "ich habe fertig" is stereotypical bad german
19:33 < crunge> skelterjohn|work: I find the default case for a channel read
to be simple and clean, but non-obvious
19:33 < chomp> func (*ServerConn) Read() is what ultimately matters here
19:33 < skelterjohn|work> crunge: i hear you
19:33 < crunge> skelterjohn|work: thanks for the guidance
19:33 < skelterjohn|work> it used to be "val, ok := <- ch" for
non-blocking, and ok would be false if nothing was read
19:34 < skelterjohn|work> but that got changed to be blocking, with ok =
false for if the channel was closed
19:34 < skelterjohn|work> since select could already do a non-blocking read
19:34 < skelterjohn|work> and no problem
19:35 < chomp> so
19:35 < skelterjohn|work> "ich habe fertig" -> "i have farted"?
19:35 < chomp> yeah
19:35 < ArgonneIntern> chomp: do you know where header map[string]string
keys and values are set
19:35 < chomp> setting Close has no effect
19:35 < chomp> it's only used before your handler is callled
19:35 < chomp> and is set based on incoming headers from the client
19:35 < aiju> skelterjohn|work: "i have done"
19:35 < ArgonneIntern> chomp: yes I suspected that
19:35 < aiju> instead of the correct "ich bin fertig"
19:36 < ArgonneIntern> the server tells the client to close in the response
19:36 < chomp> which makes sense.  i wouldn't expect modifications to the
request object to have any effect on behavior
19:36 < skelterjohn|work> and fertig can't turn into a verb, like "done"
19:36 < TheSeeker> I keep hoping that if I hang out in this channel long
enough I'll learn Go by osmosis.  I don't think it's working though.  :(
19:36 < ArgonneIntern> but I can't find where map[string]string header keys
are predifined
19:36 < ArgonneIntern> what is the key for telling the client to close
19:36 < skelterjohn|work> TheSeeker: gotta code
19:36 < chomp> w.Header().Set("Connection", "close")?
19:37 < ArgonneIntern> I don't know
19:37 < chomp> it is.
19:37 < ArgonneIntern> I can't see where it is defined
19:37 < ArgonneIntern> where do you see that
19:37 < chomp> where what's defined
19:37 < chomp> that's code you would need to write
19:37 < chomp> in your handler function.
19:37 < chomp> or even in your client-side request header if you so choose
19:38 -!- yebyen [~yebyen@martyfunkhouser.csh.rit.edu] has joined #go-nuts
19:39 < ArgonneIntern> cleaner in server
19:39 < icy> but still, shouldn't it leak a) faster and b) also file
19:39 < ArgonneIntern> it would appear that is the solution if those keys
19:39 < ArgonneIntern> lemme try it
19:40 < chomp> well yeah it should definitely leak file descriptors
19:41 -!- prip [~foo@kimochi.ath.cx] has quit [Ping timeout: 240 seconds]
19:41 < ArgonneIntern> MFer setting that key didn't doa nything
19:41 < chomp> ArgonneIntern, yes but it shouldnt alone...  read the docks
at http://golang.org/pkg/http/#Response
19:42 < chomp> docs* geez
19:42 < chomp> that should cause the Close flag to be true in the Response
your client receives.  Close is merely "advice" - http will never force close
based on that response
19:43 < icy> req.Close = true does send Connection: close for me btw
19:43 -!- tgall_foo [~tgall@] has quit [Quit: This computer has gone
to sleep]
19:43 < icy> chomp: what do you mean by that last sentence?
19:43 -!- photron [~photron@port-92-201-42-18.dynamic.qsc.de] has quit [Ping
timeout: 276 seconds]
19:44 < chomp> if a response header sets Connection: close, then the Reponse
received by a go http client will have the Close flag set to true
19:44 < chomp> beyond that, the header elicits no additional behavior by the
http implementation
19:44 < icy> oh you mean specificly in go
19:44 < icy> go clients that is
19:44 < chomp> in other words, it's up to you to actually close the
19:44 < chomp> yes
19:45 < icy> I don't have go clients
19:45 < icy> the server should close the connection aswell as the client
with this header set
19:45 < ArgonneIntern> well....so what is the damn point then lol
19:45 < chomp> well, the point is communicatoin.
19:45 < chomp> what exactly is wrong with closing your own connections?
19:46 < ArgonneIntern> i'm using an http.Client
19:46 < ArgonneIntern> and it doesn't have a close
19:46 < ArgonneIntern> sadface
19:46 < ArgonneIntern> "Client is not yet very configurable."
19:46 < chomp> maybe you want a ClientConn?
19:47 < ArgonneIntern> yes I might have to change to client Conn
19:47 < chomp> it's a ReadWriteCloser
19:47 < ArgonneIntern> is it
19:47 -!- tgall_foo [~tgall@] has joined #go-nuts
19:47 < chomp> looking at the http docs I can't help but parse a very
juvenile message directly under "type Client"
19:48 < ArgonneIntern> lol
19:48 < chomp> in the index that is
19:50 < chomp> it's actually not a proper ReadWriteCloser, but it does
provide a Read, a Write and a Close :)
19:51 < ArgonneIntern> Client?
19:51 < chomp> ClientConn
19:51 < ArgonneIntern> ohhh
19:51 < ArgonneIntern> wow I thought I was really stupid
19:51 < ArgonneIntern> I was trying to close it, saying to myself....it
doesn't have a close ffs!
19:51 -!- prip [~foo@host22-24-dynamic.43-79-r.retail.telecomitalia.it] has joined
19:51 < ArgonneIntern> but yes I see the clientconnc lose
19:52 < chomp> unfortunately clientconn is pretty low level
19:52 < ArgonneIntern> Id on't see why you would institute a client package
without a close
19:52 < ArgonneIntern> yea
19:53 < chomp> are you just using Get?
19:53 < ArgonneIntern> no mostly i'm posting
19:54 < ArgonneIntern> wonder if they would except a change to http.Client
that auto closes on the close connection in the response header
19:55 < ArgonneIntern> clientConn shouldn't as it's lower level, but
http.Client is much higher level so maybe it would be appropriatte?
19:56 -!- Halavanja [~chatzilla@anlextwls002-095.wl.anl-external.org] has quit
[Ping timeout: 240 seconds]
19:58 < ArgonneIntern> icy: server won't close the connection using
19:58 < ArgonneIntern> icy: and there does not appear to be a close in that
package.  Same with http.Client.  So you need to switch to clientConn, and/or
19:59 < chomp> well as he said he's not using go clients
19:59 < chomp> a proper http client will adhere to the Connection: close
20:01 < icy> the server should adhere to what he says too :)
20:01 -!- tncardoso [~thiago@] has joined
20:01 < ArgonneIntern> icy: listenAndServe definitely doesn't
20:02 < ArgonneIntern> in fact none of them do implicitely, only some do
20:02 -!- bakedb [~kel@cpc4-lea21-0-0-cust755.6-3.cable.virginmedia.com] has
joined #go-nuts
20:02 < icy> I just tried it with telnet btw, the server does not close the
20:02 < icy> even though it advertises Connection: close
20:03 < ArgonneIntern> in the response?
20:03 < ArgonneIntern> or in the request
20:03 < icy> the response
20:03 < ArgonneIntern> doesn't matter, there isn't a go package that
explicitly will close the connection on either client or server
20:03 < icy> if I send Connection: close in the request, then the server
closes the connection properly
20:04 < ArgonneIntern> we just spent the last hour and a half proving that
20:04 < ArgonneIntern> err implictly
20:04 < chomp> icy, actually if the client request coming into the go http
server has Connection set to close, it looks like the server will close the
connection...  maybe.
20:04 < ArgonneIntern> sorry
20:04 < icy> chomp: what I just said too :)
20:04 < chomp> ah yeah
20:04 < icy> you can try it with golang.org and telnet hehe
20:04 < chomp> setting req.Close = true in your handler does nothing - go
doesnt care about the request at all once it's handed it off to you
20:05 < icy> chomp: well, it does seem to trigger a Connection: close header
in the response
20:05 < ArgonneIntern> there isn't a way to set the http.Client request
header is there?
20:05 < ArgonneIntern> for the go client
20:05 < chomp> not that i can tell ArgonneIntern
20:06 < icy> you can use http.Client.Do() with your own request
20:06 < ArgonneIntern> looks like I'm switching to client conns, since
http.Client is useless?
20:07 -!- dgnorton [~dgnorton@] has quit []
20:07 < ArgonneIntern> actually icy that might work
20:08 < chomp> oh snap
20:08 < ArgonneIntern> :P
20:08 < xb95> http://en.wikipedia.org/wiki/High-frequency_trading
20:08 < xb95> Dammit, sorry.
20:08 < chomp> xb95, well hello
20:08 < chomp> gief money please.
20:09 < icy> :)
20:11 -!- bakedb [~kel@cpc4-lea21-0-0-cust755.6-3.cable.virginmedia.com] has quit
[Quit: Ex-Chat]
20:11 -!- prip [~foo@host22-24-dynamic.43-79-r.retail.telecomitalia.it] has quit
[Ping timeout: 276 seconds]
20:11 < ArgonneIntern> icy: so if you send close to the server in the header
it closes?
20:12 < ArgonneIntern> for the request
20:13 < icy> yes
20:14 < ArgonneIntern> so you solved your massive go routines?
20:14 -!- Halavanja [~chatzilla@mcswl207.mcs.anl.gov] has joined #go-nuts
20:16 < icy> well I have no control over the clients, they are flash :/
20:16 < icy> and you can't send headers from flash
20:17 < icy> I think though that after a long timeout, the connections get
closed and the goroutines collected
20:18 < icy> problem is I have to wait ages to see the effects
20:19 < skelterjohn|work> is there no way to kill the connection serverside?
20:19 < skelterjohn|work> maybe have your own timeout mechanism with
20:20 < icy> that would be ugly
20:20 < skelterjohn|work> you think so?  it seems fine to me
20:21 < skelterjohn|work> go func(aConnection ConnectionType) {
<-time.After(TimeoutLength); aConnection.ForceClosed() }(aConnection)
20:22 < icy> well I mean you should not have to do this
20:23 < icy> the default http.Server has both timeouts set to 0 making them
infinite, I think that's one issue
20:23 < icy> then there is w.closeAfterReply not properly being set
20:24 < skelterjohn|work> can you change the timeout length?
20:25 < chomp> icy, have you tried adding a simple patch to server.go which
sets closeAfterReply in to true when Connection == "close"?
20:26 < chomp> just to see if the understanding is actually correct
20:26 < icy> manually yes.  by using srv := &Server{Addr: ..., Handler: ...,
ReadTimeout: ..., WriteTImeout: ...}; srv.ListenAndServe()
20:27 < ArgonneIntern> skelterjohn|work: you can close the connection server
side, ify ou don't use http.Listenandserve
20:27 < icy> I think I will have to set those timeouts to something low
anyways because my daemon can get massive numbers of requests at times
20:27 < ArgonneIntern> which he wants to use because it's really easy to set
20:27 < skelterjohn|work> ah, yes ListenAndServe hides some things from you,
but that's the price of convenience
20:27 < ArgonneIntern> skelterjohn|work: IMO the problem isn't
20:27 < ArgonneIntern> it's http.Client
20:28 < ArgonneIntern> why that doesn't have a .Close() is not right
20:28 < ArgonneIntern> or at least an easy way to set that field and in the
Post and Gets
20:28 < skelterjohn|work> does it even make sense for it to have a .Close()
20:28 < ArgonneIntern> not really which is why I just said what I did
20:29 < ArgonneIntern> what we really want to do set the header
20:29 < skelterjohn|work> don't Post() and Get() calls each create their own
connections and close them when done?
20:29 < ArgonneIntern> no
20:29 < skelterjohn|work> o_O
20:29 < ArgonneIntern> connection is default set to keep-alive
20:29 < skelterjohn|work> i see
20:29 < ArgonneIntern> and there is no way to change it unless you do an
20:29 < ArgonneIntern> err http.Client.Do()
20:29 < icy> the problem with the simple interface is that I think you could
DoS a server super easily as it has no way to close away connections
20:30 < skelterjohn|work> then it might be worth filing an issue about that
20:30 < ArgonneIntern> also icy has a point
20:30 < ArgonneIntern> it would be SUPER easy to do that
20:30 < chomp> to be fair keep-alive is the standard default behavior of an
HTTP/1.1 connection.  but yeah it should be possible to change that behavior even
with a high level interface like Client
20:31 < icy> you can't even effectively implement "N connections per IP"
20:31 < ArgonneIntern> I have t personally thank icy lol, I wouldn't have
noticed this until my daemon had 10k go routines
20:32 < icy> well, I get at peaks several thousand req/s so I'm worried
about performance :)
20:32 -!- pharris [~Adium@rhgw.opentext.com] has quit [Quit: Leaving.]
20:33 < ArgonneIntern> I'm concerned about ticketing it because it says in
http.Client that it's not finished yet
20:33 < icy> it's not only an issue of http.Client
20:33 < ArgonneIntern> so they may already know about it
20:33 < ArgonneIntern> "Client is not yet very configurable."
20:33 < ArgonneIntern> well I know
20:33 < ArgonneIntern> it's both really
20:33 -!- kfeng [~kfeng@host-58-114-183-56.dynamic.kbtelecom.net] has joined
20:33 < ArgonneIntern> the handler funcs should have a way to close
connection also
20:34 < icy> in the server you get a ResponseWriter and Request, and you
can't close them :)
20:34 < skelterjohn|work> ArgonneIntern: don't let that stop you from filing
an issue
20:34 < icy> it doesn't expose any type of client or connection to you
20:34 < skelterjohn|work> the issue tracker serves as both a bug tracker and
todo list
20:35 < ArgonneIntern> i'll report it lol
20:35 < ArgonneIntern> why not I have nothing to lose, people already know
I'm a noob
20:36 < ArgonneIntern>
20:36 < ArgonneIntern> nvm
20:36 < icy> imho Request.Close = true should result in
ResponseWiter.closeAfterReply to be set to true
20:36 < ArgonneIntern> apparently it's a known issue
20:36 < ArgonneIntern> yes
20:36 < ArgonneIntern> read the link I just posted
20:36 < ArgonneIntern> it was accepted
20:37 < skelterjohn|work> be sure to check out brad's solution
20:37 -!- dreadlorde [~dreadlord@c-68-42-82-10.hsd1.mi.comcast.net] has joined
20:38 < icy> this is a related bug but not the same
20:39 < ArgonneIntern> it would solve the issue
20:39 < ArgonneIntern> as the server could close the connection
20:39 < ArgonneIntern> by moving the TCP close up in the interface
20:40 < ArgonneIntern> read down in the comments
20:40 < ArgonneIntern> also please star the issue
20:40 < icy> I did read it
20:40 < icy> but it's not the same
20:40 < icy> even if all data from the body was sent and it was closed, the
connection remains open
20:41 < icy> as it does not realize it's not a keep-alive connection and
tries to read another request
20:41 < icy> which by default has a timeout of 0 so it wait...  well, a long
20:42 < chomp> ah yeah it is not the same issue
20:42 < ArgonneIntern> there is a way for the client to not keep alive
20:42 < ArgonneIntern> brad you smart man you
20:42 < icy> but not for the server :)
20:43 < ArgonneIntern> http.Client.RoundTripper.DisableKeepAlives = true
20:43 -!- alsvidr [~textual@dslb-188-099-240-157.pools.arcor-ip.net] has joined
20:44 < chomp> and what i learned from that thread is that tip.goneat.org
hosts a tip godoc site
20:44 < ArgonneIntern> imma try that.  I'll still help you icy if it works
for me, maybe we can find a similar 3-4 chain deep solution lol
20:44 < brad_> heh
20:44 < ArgonneIntern> it's brad!
20:44 < ArgonneIntern> brad this bug/issue is so annoying
20:44 < ArgonneIntern> lol
20:45 < brad_> ha
20:45 < brad_> I am not the same brad
20:45 < brad_> :)
20:45 < ArgonneIntern> oh
20:45 < ArgonneIntern> it's ok, you're still cool in my book
20:46 < brad_> anyone who likes go is a friend of mine
20:46 < brad_> :)
20:47 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-153-41.clienti.tiscali.it] has
quit [Read error: Connection reset by peer]
20:47 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-153-41.clienti.tiscali.it] has
joined #go-nuts
20:48 -!- zozoR [~Morten@2906ds2-arno.0.fullrate.dk] has quit [Remote host closed
the connection]
20:49 -!- alehorst [~alehorst@] has quit
[Quit: Leaving.]
20:49 -!- Transformer [~Transform@ool-4a59e397.dyn.optonline.net] has joined
20:50 -!- alsvidr [~textual@dslb-188-099-240-157.pools.arcor-ip.net] has quit
[Quit: Textual IRC Client: http://www.textualapp.com/]
20:50 -!- kamaji [~kamaji@cpc2-aztw22-2-0-cust775.aztw.cable.virginmedia.com] has
joined #go-nuts
20:51 < kamaji> hi all, quick question: trying to build go on my laptop but
the getting started guide doesn't produce a binary
20:51 < kamaji> what do?
20:51 < kamaji> when running all.bash
20:51 < kamaji> i've tried deleting the entire repository and re-downloading
20:52 -!- Transformer [~Transform@ool-4a59e397.dyn.optonline.net] has quit [Excess
20:52 < ArgonneIntern> grr so that doesn't work
20:53 < ArgonneIntern> RoundTripper is not of a type transport
20:53 < ArgonneIntern> MFER
20:53 < ArgonneIntern> this is so annoying lol
20:53 < str1ngs> kamaji: what error?
20:53 < kamaji> str1ngs: no error
20:53 < str1ngs> kamaji: also do you have the prereqa?
20:53 < skelterjohn|work> kamaji: does it take 5 minutes to run?
20:53 < str1ngs> ed bison gcc make etc
20:53 < kamaji> skelterjohn|work: nope
20:53 < kevlar_work> kamaji, do you have ed and bison installed?
20:54 < skelterjohn|work> someone should really add something to make.bash
to check that dependency....
20:54 < kamaji> I did last time
20:54 < kamaji> let me chekc
20:54 < kamaji> I'm guessing no
20:54 < kamaji> goddamnit
20:54 < skelterjohn|work> :)
20:54 < kamaji> thanks :p
20:54 -!- virtualsue [~chatzilla@nat/cisco/x-jvwyxhzxuhrljvtn] has quit [Ping
timeout: 252 seconds]
20:54 < kamaji> cba to run tests, make.bash will run as well, right?
20:54 < str1ngs> kamaji: pacman -S base-devel
20:55 < skelterjohn|work> yes
20:55 < str1ngs> but you still need ed iirc
20:55 < skelterjohn|work> i almost never run all.bash
20:55 < str1ngs> kamaji: if you are still running arch of course :P
20:55 < kamaji> of course :D
20:55 < kamaji> I think I have base-devel already
20:55 < str1ngs> so probably just ed
20:55 < kamaji> jeap
20:55 < kamaji> it's taking a billion years to run now, so that looks like a
20:56 < str1ngs> why I like ./make.bash
20:56 -!- virtualsue [~chatzilla@nat/cisco/x-etbdllocgpwjcxbs] has joined #go-nuts
20:56 < kamaji> hooray for the Atom processor
20:56 < str1ngs> atom
20:56 < str1ngs> oh use ./make.bash imo
20:56 < kamaji> I am
20:56 < kamaji> I don't know if this netbook would ever finish all.bash
20:56 < kamaji> it might just melt instead
21:01 < kevlar_work> skelterjohn, it's been added to tip, maybe weekly
21:01 < kevlar_work> skelterjohn, also, the ed dependency is going away in
tip too.
21:02 < skelterjohn|work> oh...  good, then
21:05 < kevlar_work> at least, I think it got checked in.
21:05 -!- robteix [~robteix@nat/intel/x-vmrusavikismhzxk] has quit [Ping timeout:
255 seconds]
21:05 < kevlar_work> now that I think about it, I'm not sure if I saw the
*** SUBMITTED message.
21:07 < kamaji> oh bugger, there appears to be an error in some code
21:07 < kevlar_work> kamaji, in what code?
21:07 < kevlar_work> everything (woah) is green on
21:08 < kevlar_work> I'm not sure I've ever seen a full page of OK on there
21:08 < kamaji> haha
21:08 < kamaji> it was complaining there was a char where it wanted const
21:08 -!- Nitro [~Nitro@unaffiliated/nitro] has quit [Ping timeout: 240 seconds]
21:08 < kamaji> I just changed it, i'll see if that works~
21:08 < kevlar_work> kamaji, you need bison not bison++
21:08 -!- virtualsue [~chatzilla@nat/cisco/x-etbdllocgpwjcxbs] has quit [Ping
timeout: 250 seconds]
21:08 < kamaji> I just assumed the arch package "bison" was that
21:08 < kamaji> lemme look
21:09 -!- alkavan [~alkavan@IGLD-84-228-136-116.inter.net.il] has joined #go-nuts
21:09 < kamaji> yeah, seems to be regular bison?
21:10 < kevlar_work> what version?
21:10 < kamaji> 2.5
21:11 < kevlar_work> what's the error message?
21:11 < kevlar_work> I know I've seen this on the ML but can't find it.
21:11 < icy> haha I think I found a hack to force closing of connections.  I
can overwrite req.ProtoMinor to 0 which makes it set w.closeAfterReply to true and
close the connection :D
21:12 < kamaji> kevlar_work: rebuilding, hang on
21:12 < kamaji> y.tab.c:5203:9: error: passing argument 1 of 'yyerror'
discards 'const' qualifier from pointer target type [-Werror]
21:13 < icy> ArgonneIntern
21:13 < ArgonneIntern> icy:
21:13 < kamaji> oh, issue with 2.5 apparently
21:13 < icy> read what I just wrote, might help you too
21:13 < kevlar_work> either that or too recent GCC
21:13 <+iant> kamaji: that is fixed on tip, I believe, perhaps not in a
release yet
21:14 -!- fvbommel [~fvbommel_@] has quit [Read error: Connection
reset by peer]
21:14 < kevlar_work> oh, nevermind.
21:14 < kevlar_work> I didn't read far enough down the thread >:-)
21:14 < ArgonneIntern> icy: what is protominor
21:14 < kamaji> hehe
21:14 < icy> ArgonneIntern: HTTP/1.1 <- second number
21:14 < kevlar_work> ArgonneIntern, the minor protocol (HTTP/1.1) version
21:14 < huin> i'm wondering about the heap profiling stuff.  is it showing
me how much memory has been allocated (and potentially been freed), or is it
telling me how much is still in use?
21:14 < ArgonneIntern> oh
21:14 < icy> HTTP/1.0 does not do keep-alive by default
21:14 < ArgonneIntern> lmao
21:14 < kevlar_work> http/1.0 had much different ideas about connections
21:14 < ArgonneIntern> hmm let me try
21:15 < kevlar_work> huin, Go (almost) never returns memory to the operating
system after it allocates
21:15 < kamaji> iant: oh, release is the one I have
21:15 < ArgonneIntern> wait...this is from the client tot he server
21:15 < icy> I do it on the server
21:15 < ArgonneIntern> this doesn't solve the server issue
21:15 < huin> kevlar_work: well i mean "freed" as in malloc-freed
21:15 < ArgonneIntern> on request?
21:15 -!- virtualsue [~chatzilla@nat/cisco/x-zqffhnrlbirfforn] has joined #go-nuts
21:15 < ArgonneIntern> that seems odd
21:15 -!- exch [~blbl@] has quit [Ping timeout: 264 seconds]
21:15 < icy> I overwrite the protominor of the request :)
21:15 < icy> hence why I said it's a hack :D
21:16 < kevlar_work> huin, afaik, it doesn't report anything about the few
small things that do get free()d
21:16 < kevlar_work> in general, if you make([]int, 1024*1024), that memory
is never going back to the OS.
21:16 < huin> it's not about going back to the OS that worries me
21:16 <+iant> kamaji: hmmm, actually the patch was committed May 26, isn't
that in a release yet?
21:17 < ArgonneIntern> icy: omfg you are a genius
21:17 < huin> it's about memory not being released back to the malloc pool
21:17 < ArgonneIntern> it works
21:17 < ArgonneIntern> that saves me so much work reworking all this code
21:17 < kevlar_work> huin, the OS == the malloc() pool
21:17 < huin> malloc is not a system call
21:17 < kevlar_work> icy/argonne, you might post that solution to the bug
and/or mailing list.
21:18 <+iant> http://code.google.com/p/go/issues/detail?id=1843
21:18 < kevlar_work> huin, what is your actual issue?
21:18 -!- Fish [~Fish@9fans.fr] has quit [Quit: So Long, and Thanks for All the
21:18 < ArgonneIntern> it really should have already read protominor before
giving the func access to the request lol
21:18 < ArgonneIntern> it's kinda fishy that it doesn't
21:18 < kevlar_work> huin, when Go gets memory from the operating system
using malloc(), it is then given to a Go object, which can be reclaimed by the go
runtime by the garbage collector
21:18 < huin> kevlar_work: possible memory leak, and i'm needing to know how
to interpret the heap profile output properly
21:18 < kevlar_work> even if this happens, it is not free()d.
21:18 < icy> it did read it, but it does read it again when finishing the
request :)
21:19 < huin> kevlar_work: okay, well gc'd then
21:19 < ArgonneIntern> so then why doesn't setting close and
connection:close in the request work?
21:19 < kamaji> iant: well I tried tip, same error
21:19 < kamaji> tip is the most recent, right?
21:19 < icy> I'm not sure about that one yet
21:19 < kevlar_work> can you nopaste your heap profile output?  there are a
few different ways to get at it.
21:19 < huin> kevlar_work: although i was under the impression that the GC
uses free() under the hood, and free is just part of the malloc lib
21:19 < ArgonneIntern> I'm going to report this as an issue
21:19 < kevlar_work> kamaji, hg pull -u == tip
21:19 <+iant> kamaji: is it the same error that is in that issue?
21:20 < ArgonneIntern> it is seperate of their issue
21:20 < kamaji> oh, I was doing "hg pull -r tip"
21:20 < kevlar_work> that may work too.
21:20 -!- DisposaBoy [~DisposaBo@] has quit [Ping timeout: 255
21:20 < kamaji> hm, it says "no changes found"
21:20 < icy> ArgonneIntern: to be honest I have a feeling that there can be
many more things dug up in the http package
21:20 < kevlar_work> huin, not in the gc compiler, not sure about gccgo.
21:21 -!- cafesofie [~cafesofie@ool-18b97779.dyn.optonline.net] has quit [Remote
host closed the connection]
21:21 < kamaji> kevlar_work: hg pull -u == tip just errors for me
21:21 < ArgonneIntern> icy: this issue is fairly important though and needs
to be addressed sooner than later, if the package is to be taken seriously
21:21 < kevlar_work> kamaji, I meant: `hg pull -u` is tip
21:21 < huin> kevlar_work: i've got a heap profile sitting on disk at the
moment, although i don't know how much use it is to anyone else unless i upload
the binary with it
21:22 < ArgonneIntern> icy I'm off for the night, good working with you on
this issue
21:22 < kamaji> kevlar_work: oh....  hehe.  well that has no changes
21:22 < icy> ArgonneIntern: agreed, btw I know why the header does not work
21:22 < kevlar_work> huin, I meant the text output you get when you run it.
have you read http://blog.golang.org/2011/06/profiling-go-programs.html ?
21:22 < kamaji> but weirdly, no changes for pull -r release
21:22 < kamaji> so i'm not sure what's going on
21:22 < ArgonneIntern> icy: why
21:22 < huin> kevlar_work: yes
21:22 < kevlar_work> kamaji, pull -r release won't pull anything new
21:22 < icy> look at server.go lines 181 and 192, those are the only lines
that can make it close the connection
21:22 < huin> i'll paste that then
21:22 < kevlar_work> you have to update after pull to get the changes
21:22 < kamaji> oh...
21:22 < icy> and it only gets there if the proto is not 1.1
21:22 < kevlar_work> update -r release will update to release, update will
update to tip
21:23 < kamaji> ah I see.
21:23 < huin> kevlar_work: http://paste.pocoo.org/show/421613/
21:23 < kamaji> third time lucky then maybe :)
21:23 < kevlar_work> (at least I'm pretty sure that's all right; I get
confused by mercurial sometimes after using git for awhile)
21:24 -!- hpvincent [~zig@nap13-11-83-156-121-34.fbx.proxad.net] has quit [Remote
host closed the connection]
21:24 < kevlar_work> huin, okay, so what about this bothers you?
21:24 < huin> kevlar_work: i want to know if the 95MiB allocated by
doDefault has been freed
21:24 < ArgonneIntern> icy: WOW, this handles http 1.1 very poorly lol
21:25 < kevlar_work> huin, is this a short-running program?
21:25 < huin> kevlar_work: nope.  daemon
21:25 -!- flaguy48 [~gmallard@user-0c6s350.cable.mindspring.com] has left #go-nuts
21:25 < huin> well, server anyway
21:25 < kevlar_work> huin, are you using http/pprof?
21:25 < icy> ArgonneIntern: handling http properly is btw pretty hard
21:26 < huin> kevlar_work: not in this case, but i can enable it
21:26 < icy> in fact, I'd bet there is no webserver out there that handles
it *completely* right in every respect :)
21:26 < kamaji> kevlar_work: ah that's worked
21:26 < kamaji> cheers!
21:26 < kevlar_work> kamaji, no problem.
21:27 < kevlar_work> huin, that and
http://golang.org/pkg/runtime/#MemProfile might help you examine some things
21:28 < ArgonneIntern> icy: does line 160 ever get called anywhere
21:28 < kevlar_work> MemProfileRecord has alloc/free/inuse stats for you.
21:29 < icy> ArgonneIntern: yes, if you send it an Expect: 100-continue
21:29 < huin> kevlar_work: yeah.  already got those.  most of the memory is
used up by quite small allocations.  not that it tells me where they were
21:29 < icy> it replaces the req.Body with the expectreader
21:29 < huin> kevlar_work: using the http/pprof method just gives me the
same answer as before
21:30 < kevlar_work> huin, http/pprof can allow you to get an idea over time
of what it looks like, memprofile tells you how much has been freed.
21:30 < kevlar_work> and by freed, I mean garbage collected.
21:30 < kevlar_work> it won't get free()d either way.
21:31 < ArgonneIntern> icy: anyways you have a better grasp on this than I
do.  Maybe you should report it, the bug tracker location is in the orc channel
greeting.title thing
21:31 < huin> indeed.  i have compared the two and the amount of memory that
has been malloc'd and hasn't been freed is consistent with what the heap profiler
tells me
21:31 < ArgonneIntern> icy: make sure to mention the hack in case anyone
else has this issue
21:31 < kevlar_work> huin, you might want to break your thinking away from
21:32 < kevlar_work> they're not helpful concepts when reasoning about
memory in Go.
21:32 < kevlar_work> especially when it comes to the actual memory footprint
of your application.
21:32 < huin> kevlar_work: i honestly don't think that's a useful comment.
memory is allocated, and freed.
21:32 < huin> free is not a system call
21:33 < huin> it's not an important distinction here whether the free is
manual or GC. it can only be by the GC
21:33 -!- ijknacho [~goofy@cpe-72-190-64-3.tx.res.rr.com] has quit [Ping timeout:
240 seconds]
21:36 < kevlar_work> huin, they're not helpful concepts because when/whether
you allocate memory on the heap is out of your control, and when/whether memory
you do allocate is available for reuse is also (unless you explicitly remove
references and call runtime.GC) outside of your control
21:36 < kevlar_work> thus, your reasoning should be more about making sure
you don't maintain spurious references to memory you don't need and keeping things
on the stack when you can
21:37 -!- exch [~blbl@ip34-181-209-87.adsl2.static.versatel.nl] has joined
21:37 < huin> well quite.  and that's the problem i'm trying to track down
as to why this memory is still allocated
21:37 < huin> i don't see why you think my reasoning has a problem
21:38 < kevlar_work> well, tracking down where the memory is in use should
be pretty straightforward given that you have the heap profile
21:38 < kevlar_work> I would take a closer look at whoever is calling
21:39 -!- Halavanja [~chatzilla@mcswl207.mcs.anl.gov] has quit [Quit: ChatZilla
0.9.87 [Firefox 5.0/20110622232440]]
21:40 < huin> kevlar_work: as far as i can tell i'm only compressing in one
place in the program
21:41 < huin> and that place closes the zlib writer when complete
21:41 < kevlar_work> huin, but what are you doing with what's returned from
21:42 -!- ArgonneIntern [82ca0251@gateway/web/freenode/ip.] has quit
[Ping timeout: 252 seconds]
21:42 < huin> it writes bytes into a bytes.Buffer, which should also be
21:43 < huin> the actual data written to the buffer is kept, but the size of
those slices is around the 4k mark
21:43 < huin> those only account for a few MiB
21:44 < huin> it's the internal buffers inside the flate compressor that
don't appear to be freed, and it's not obvious to me why.  that's the problem i'm
trying to figure out
21:44 < kevlar_work> huin, keep in mind that when you write past the end of
the bytes.Buffer, it will be reallocated, and that allocation will probably look
like it's coming from whoever was writing to it
21:45 < huin> i would expect that memory to be attributed to code in
21:45 < huin> bytes.Buffer allocates a new, bigger, slice when it needs to,
then copies the original data and the new data into it
21:45 < kevlar_work> huin, well, have you looked at what lines of code it's
attributing the memory?
21:46 < huin> the 90 to 95MiB?
21:46 -!- virtualsue [~chatzilla@nat/cisco/x-zqffhnrlbirfforn] has quit [Ping
timeout: 264 seconds]
21:47 < kevlar_work> any of them, but sure that seems like a sensible place
to start.
21:47 < huin> yes, that's in that paste i did a while ago
21:47 < kevlar_work> go reread the blog post I linked.
21:47 < huin> on a line-by line basis it's:
21:47 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit:
21:48 < kevlar_work> that's on a function-by-function basis
21:48 -!- chomp [~chomp@dap-209-166-184-50.pri.tnt-3.pgh.pa.stargate.net] has quit
[Quit: Leaving]
21:48 < huin> no, that last paste is on line by line
21:48 < huin> the original was per function
21:48 -!- flaguy48 [~gmallard@user-0c6s350.cable.mindspring.com] has joined
21:48 < kevlar_work> I'm talking about using pprof `list`
21:48 < kevlar_work> which shows you a function with the memory each line of
the function has allocated
21:48 < kevlar_work> as in the blog post
21:48 < huin> that unfortunately does not work for me
21:49 < huin> however the output from top10 for line-by-line gives sane
21:49 < huin> it's just missing filenames, which is presumably why the list
command doesn't work
21:50 < kevlar_work> try it in $GOROOT/src/pkg
21:50 < kevlar_work> though I don't know if that will help.
21:51 < kevlar_work> have you looked at the svg output, as suggested by the
blog post?
21:51 < kevlar_work> that can give you a good idea of who's calling what.
21:51 < huin> sadly not
21:51 < huin> and yes, i'm looking at the SVG
21:51 -!- sniper506th [~sniper506@rrcs-70-61-192-18.midsouth.biz.rr.com] has quit
[Quit: Leaving...]
21:51 < kevlar_work> huin, the other thing to remember is that you probably
don't see the bytes.buffer calls because they're so fast, the memory profiler
can't/doesn't see them
21:51 -!- piranha [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has quit [Quit:
Computer has gone to sleep.]
21:51 < huin> apart from missing the filenames etc.  - the output of the
profiler seems clear enough
21:52 -!- smw [~stephen@unaffiliated/smw] has quit [Ping timeout: 255 seconds]
21:52 < huin> i dunno about that last part though...  the results of it look
consistent with what i'd expect
21:52 < kevlar_work> so I think it's pretty clear that buffers from deflate
are being kept around; whether this is a bug or not I can't tell you.
21:53 -!- mrsrikanth [~mrsrikant@] has quit [Quit: Leaving]
21:53 < huin> there's an entry for bytes.*Buffer.grow() which shows a value
i've seen elsewhere and looks sanely low
21:53 < kevlar_work> (a bug in your code; it's less likely a bug in
21:53 < huin> but yeah - what you say is my conclusion
21:53 -!- prasmussen [pii@rasm.se] has quit [Ping timeout: 255 seconds]
21:53 < kevlar_work> huin, that means only that it didn't see it very many
21:53 < huin> and yeah, my suspicion is on my own code first
21:53 < icy> hehe with my ProtoMinor hack, I'm down to 5 goroutines from 60
21:53 -!- i__ [~none@unaffiliated/i--/x-3618442] has quit [Ping timeout: 244
21:53 -!- russell_h [~russell_h@osuosl/staff/russellh] has quit [Ping timeout: 244
21:54 -!- prasmussen [pii@rasm.se] has joined #go-nuts
21:54 < kevlar_work> icy, did you report your hack?
21:54 -!- i__ [~none@] has joined #go-nuts
21:54 -!- russell_h [~russell_h@ash.osuosl.org] has joined #go-nuts
21:54 < icy> yes and I made a typo in the ticket title...  :(
21:55 < icy> http://code.google.com/p/go/issues/detail?id=2011
21:55 < kevlar_work> lol.  whatever ;-)
21:55 < icy> can't seem to be able to edit it
21:56 < kevlar_work> icy, btw, you're not eating up file descriptors by
having open connections, at least you shouldn't be with epoll/kqueue
21:56 < kevlar_work> but yes, goroutines cost memory.
21:57 < icy> ah damnit another typo in there.  should be Request.ProtoMinor
not w.ProtoMinor.  why can't I edit this thing :(
21:57 < icy> kevlar_work: hu?  epoll/kqueue do not help with file descriptor
21:58 < icy> they just make them less expensive when idle
21:58 < kevlar_work> *shrug* I could be wrong.
21:58 < huin> i'll have to work on this tomorrow.  bedtime for me
21:58 < kevlar_work> icy, you just have to post a comment.
21:58 -!- huin [~huin@] has quit [Quit: bedtime]
22:00 -!- cenuij [~cenuij@] has joined #go-nuts
22:00 -!- cenuij [~cenuij@] has quit [Changing host]
22:00 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts
22:07 < kamaji> alright cheers for the help everyone!
22:07 < kamaji> i'm off to bed
22:07 -!- kamaji [~kamaji@cpc2-aztw22-2-0-cust775.aztw.cable.virginmedia.com] has
quit [Quit: sleeep]
22:08 -!- piranha [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts
22:13 -!- awidegreen [~quassel@h-170-226.A212.priv.bahnhof.se] has quit [Ping
timeout: 240 seconds]
22:16 -!- dreadlorde [~dreadlord@c-68-42-82-10.hsd1.mi.comcast.net] has quit [Ping
timeout: 258 seconds]
22:18 -!- niekie [~niek@CAcert/Assurer/niekie] has quit [Quit: No Ping reply in
180 seconds.]
22:18 -!- niekie [~niek@CAcert/Assurer/niekie] has joined #go-nuts
22:18 -!- KBme [~KBme@2001:470:cabe:666:666:666:666:666] has quit [Quit: KBme
22:18 -!- KBme [~KBme@2001:470:cabe:666:666:666:666:666] has joined #go-nuts
22:20 -!- Xenith [~xenith@xenith.org] has quit [Ping timeout: 260 seconds]
22:20 -!- Xenith [~xenith@xenith.org] has joined #go-nuts
22:21 -!- piranha [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has quit [Quit:
Computer has gone to sleep.]
22:21 -!- Natch| [~natch@c-adcee155.25-4-64736c10.cust.bredbandsbolaget.se] has
quit [Ping timeout: 240 seconds]
22:22 -!- russell_h [~russell_h@ash.osuosl.org] has quit [Changing host]
22:22 -!- russell_h [~russell_h@osuosl/staff/russellh] has joined #go-nuts
22:22 -!- chomp [~chomp@c-67-186-35-69.hsd1.pa.comcast.net] has joined #go-nuts
22:22 -!- Natch| [~natch@c-adcee155.25-4-64736c10.cust.bredbandsbolaget.se] has
joined #go-nuts
22:23 -!- arun_ [~arun@e71020.upc-e.chello.nl] has joined #go-nuts
22:23 -!- arun_ [~arun@e71020.upc-e.chello.nl] has quit [Changing host]
22:23 -!- arun_ [~arun@unaffiliated/sindian] has joined #go-nuts
22:26 -!- chomp [~chomp@c-67-186-35-69.hsd1.pa.comcast.net] has quit [Read error:
Connection reset by peer]
22:27 -!- chomp_ [~chomp@c-67-186-35-69.hsd1.pa.comcast.net] has joined #go-nuts
22:37 -!- Domtron_Vox [~chatzilla@196.sub-174-254-146.myvzw.com] has joined
22:42 -!- Nitro [~Nitro@unaffiliated/nitro] has joined #go-nuts
22:43 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the
22:50 -!- Slant [~scott@124-168-223-48.dyn.iinet.net.au] has joined #go-nuts
22:51 -!- rlab [~Miranda@] has quit [Quit: Miranda IM! Smaller,
Faster, Easier.  http://miranda-im.org]
22:51 -!- r_linux [~r_linux@static.] has quit
[Quit: lalala caindo fora]
22:57 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has quit [Remote host
closed the connection]
22:58 -!- bugQ [~bug@c-71-195-206-249.hsd1.ut.comcast.net] has joined #go-nuts
22:59 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-153-41.clienti.tiscali.it] has
quit [Quit: E se abbasso questa leva che succ...]
23:04 -!- dreadlorde [~dreadlord@c-68-42-82-10.hsd1.mi.comcast.net] has joined
23:06 -!- Adys_ [~Adys@unaffiliated/adys] has joined #go-nuts
23:06 -!- Adys_ [~Adys@unaffiliated/adys] has quit [Client Quit]
23:07 -!- Slant [~scott@124-168-223-48.dyn.iinet.net.au] has quit [Quit: Slant]
23:11 -!- warlock_mza [~warlock@86-91-231-201.fibertel.com.ar] has joined #go-nuts
23:11 -!- pjacobs [~pjacobs@] has quit [Ping timeout: 252 seconds]
23:15 -!- fvbommel [~fvbommel_@] has joined #go-nuts
23:16 -!- franciscosouza [~francisco@] has quit [Quit: franciscosouza]
23:24 -!- StoVoKor [~va3atc@24-246-17-37.cable.teksavvy.com] has joined #go-nuts
23:24 -!- va3atc [~va3atc@24-246-17-37.cable.teksavvy.com] has quit [Read error:
Connection reset by peer]
23:24 -!- napsy [~luka@] has quit [Ping timeout: 276 seconds]
23:28 -!- StoVoKor [~va3atc@24-246-17-37.cable.teksavvy.com] has quit [Ping
timeout: 246 seconds]
23:40 -!- robteix [~robteix@host243.200-82-125.telecom.net.ar] has joined #go-nuts
23:40 -!- purple10 [~Kareem@79-78-93-1.dynamic.dsl.as9105.com] has joined #go-nuts
23:44 -!- graftenberg [~graftenbe@ip69-17-252-231.vif.net] has joined #go-nuts
23:44 < graftenberg> has anyone used the mgo (the go mongo libs)?
23:45 < jessta> graftenberg: briefly
23:45 < kevlar_work> icy, looks like your issue got fixed :o
23:46 < chomp> i noticed that too :p
23:46 < kevlar_work> that was fast.
23:46 < kevlar_work> bradfitz ftw.
23:46 < chomp> three cheers for fitz
23:46 < chomp> on a totally unrelated note, has goinstall or cgo behavior
changed substantially in the last week or so?
23:47 -!- purple10 [~Kareem@79-78-93-1.dynamic.dsl.as9105.com] has left #go-nuts
23:47 < chomp> goinstall is suddenly failing to build a cgo package of mine,
and it appears to be failing to link properly
23:50 < jessta> chomp: I think the go/build package changes broke cgo
23:51 -!- franciscosouza [~francisco@] has joined #go-nuts
23:51 < chomp> hrm
23:51 < jessta> ummm...broke goinstall's ability to use cgo
23:51 < chomp> heh
23:51 < chomp> guess i'll poke around the code
23:53 < kevlar_work> git checkout HEAD^ ftw
23:54 < kevlar_work> (s//insert-hg-equivalent-here/)
23:54 < schmichael> hg update -C default # use with caution
23:54 < chomp> is that the same as tip?
23:54 < chomp> <- mercurial noob
23:54 < schmichael> ah no, default is a branch name
23:54 < schmichael> tip == HEAD
23:55 < schmichael> default == master
23:55 < chomp> ah.  unfortunately my package now also depends on a change
that just went into tip :)
23:57 < chomp> actually i probably just need to rebuild goinstall
23:58 -!- pjacobs [~pjacobs@75-27-133-72.lightspeed.austtx.sbcglobal.net] has
joined #go-nuts
23:58 < kevlar_work> yeah, gotta love it: I needed something new from net,
but really wanted pre-cgo net
23:58 < kevlar_work> alas, Go is a moving target.
23:58 < chomp> yeah that did it.  apparently now goinstall will use a
Makefile to build.  yay.
23:58 < kevlar_work> But that's why it's an exciting time to be working on
23:59 < str1ngs> chomp: you using pkg-config?
23:59 < chomp> it's nice to see a project evolving so rapidly
23:59 < chomp> and yet relatively (!) stable
23:59 < str1ngs> as in the cgo directive
23:59 < kevlar_work> (I mean, hello, what other programming language still
needs its XML marshalling written?)
23:59 < chomp> str1ngs, no, i am only using LDFLAGS
23:59 < kevlar_work> (It's nice to contribute something people might be able
to use)
23:59 < str1ngs> chomp: hmm I know pkg-config is broke but I think LDFLAGS
still works
23:59 < chomp> but recently a -make flag was added to goinstall (true by
default) which uses a Makefile to build instead of whatever it was doing before
--- Log closed Tue Jun 28 00:00:01 2011