--- Log opened Wed Dec 08 00:00:37 2010
00:01 -!- thomas_b [~thomasb@cm-84.215.47.51.getinternet.no] has quit [Ping
timeout: 265 seconds]
00:03 < cbeck> Before I get too much further into the guts of fftw, does
anyone know of an existing wrapper package?  (or any FFT package for that matter)
00:07 -!- MX80 [~MX80@cust222.253.117.74.dsl.g3telecom.net] has joined #go-nuts
00:14 -!- terrex [~terrex@84.122.72.127.dyn.user.ono.com] has quit [Quit:
Leaving.]
00:20 -!- kanru [~kanru@2001:c08:3700:ffff::2b:dbc8] has joined #go-nuts
00:24 < foocraft> okay, I just had the worst parallel implementation of
mergeSort in parallel run on my machine
00:24 < foocraft> (the one I wrote)
00:24 < foocraft> I think it was creating new arrays like crazy and I ran
out of memory
00:24 -!- iant [~iant@nat/google/x-rdnxuijpctgaulvu] has quit [Ping timeout: 272
seconds]
00:25 < exch> :p
00:25 < exch> allocaiton is not your friend
00:25 < exch> *allocation
00:26 < foocraft> yeah I think I should figure out how to use a slice
00:26 < exch> You should probably not deal with fixed size arrays at all.
Pretty much everything in Go is handled with slices
00:26 < foocraft> my split basically returns an array of arrays ( because I
didn't know you can return multiple values when I wrote it :p), so now I want it
to return two slices
00:27 -!- noff [~noff@89-55.79-83.cust.bluewin.ch] has quit [Ping timeout: 240
seconds]
00:27 -!- rejb [~rejb@unaffiliated/rejb] has quit [Quit: .]
00:28 -!- noff [~noff@89-55.79-83.cust.bluewin.ch] has joined #go-nuts
00:30 -!- iant [~iant@66.109.105.230] has joined #go-nuts
00:30 -!- mode/#go-nuts [+v iant] by ChanServ
00:31 < krutcha> if you're resizing slices a lot you may be allocating new
arrays under the hood, and relinquishing old ones to the garbage collector
00:32 < krutcha> but what did you do before to run out of memory?
00:32 < foocraft> http://fpaste.org/pZue/
00:33 < krutcha> I'm not 100% on where allocations take place with slices, I
just assume if/when I resize a slice the underlying array gets released and a new
one is created.
00:33 < foocraft> I think when you resize a slice, it will just have a
different length and there will be no allocation, its memory range will just
change
00:34 < foocraft> so I would imagine a slice to be implemented using two
values, "low" and "high"
00:34 < exch> Anytime you do a make(), an allocation takes place.  the
append() funciton does that internally if and when necessary (eg: the capacity of
the target slice insufficient to contain all values pushed into it)
00:34 < krutcha> I doubt that, a slice sits on an actual array which is
contiguous memory.  you can't just go farther off the end without reallocating.
00:35 < foocraft> yeah that makes sense, but only because the range it's
representing is less than the range you're asking it to represent
00:36 < exch> that's when a resize happens.  which means: allocate new array
with new size -> copy old data to new array -> discard old array
00:36 < foocraft> damn.  that seems expensive
00:36 < exch> It is
00:36 < exch> specially the copy() bit is very expensive
00:36 < foocraft> does it double the array size?
00:37 < foocraft> I think a simple check with cap should show the answer
00:37 < krutcha> it creates a new array of the needed size for what you
added
00:37 < exch> len(slice) == current length.  cap(slice) == max capacity
00:38 < krutcha> if you have a slice of 10, and append a slice of 2, you
create a new slice of 12, with the 10 and 2 elements copied into it
00:38 < krutcha> afaik
00:38 < KirkMcDonald> Doubling the capacity means that appends happen in
amortized constant time.
00:38 < krutcha> the original 10 and 2 still kicking around unless you don't
reference them anymore
00:38 < foocraft> okay so I ran my parallel implementation with the new
split, and I can still type here.  That's a good sign :p
00:38 < foocraft> KirkMcDonald, interesting.  so is that what it's doing?
00:39 -!- nighty__ [~nighty@210.188.173.245] has joined #go-nuts
00:39 < exch> You also don't have to loop over the slice to copy it's values
over.  Go has a builtin copy() function for that: copy(newslice, oldslice); You
can even copy into or from slice subsets: copy(newslice[123:], oldslice[2:7])
00:39 < KirkMcDonald> The spec only says that it is "sufficiently large."
00:39 < foocraft> or does it increase by fibo numbers?  :p (which, I think,
would be better)
00:40 < krutcha> hmm, so append has the freedom to allocate beyond the
request in a forward-looking way?
00:40 < foocraft> of course it should do that
00:40 < KirkMcDonald> krutcha: I see no reason why it would not.
00:40 < KirkMcDonald> In fact I would be very surprised if it did something
other than doubling the capacity.
00:41 < krutcha> well..  in C/C++ on the systems I work on, I could see why
not..  there's often no more memory than what I request :P
00:41 < foocraft> they want to avoid doing that expensive, allocate + copy.
00:41 < KirkMcDonald> I'm pretty sure that std::vector::push_back doubles
the capacity when it is required.
00:41 < exch> foocraft: from your paste, I also don't see why you should
create 2 new slices.  You can just return two new slices of the original
@allItems..  as in: split := len(allitems)/2; return allItems[:split],
allItems[split:]
00:41 < KirkMcDonald> Although that's probably implementation-defined.
00:42 < exch> That does no allocations or copies at all btw
00:42 < foocraft> shouldn't they both return the same thing, exch?
00:43 < foocraft> yeah I don't want it to copy :)
00:43 < exch> Well, I'm not entirely sure what your split does, but if it
just cuts the allitems in half, then that will do it
00:43 < krutcha> :split is start of slice to the offset split, split: is
offset split to end of slice
00:43 < exch> indeed
00:43 < krutcha> what did the original code do?
00:44 < exch> In full that would read [0:split] and [split:len(allItems)],
but the 0 and len(..) bits are implied and automatically fille din by the compiler
00:44 < foocraft> it's insanely slow still :(
00:45 < foocraft> I think it's the way I go about creating new threads
00:45 < foocraft> it's almost as if I'm fork-bombing my machine
00:45 < foocraft> http://fpaste.org/gSu9/
00:45 < krutcha> did you set GOMAXPROCS to something?
00:45 < foocraft> http://fpaste.org/ioxL/
00:46 < foocraft> I didn't
00:46 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3]
00:47 -!- progettino [~Marvin@82.84.79.101] has quit [Quit: E se abbasso questa
leva che succ...]
00:47 < foocraft> that's the serial and the parallel implementation
00:47 < krutcha> your split shouldn't need to return a slice of slices, it
could just return two slices no?
00:47 < foocraft> yeah it could, let me fix that
00:47 < foocraft> but I think I'm spawning too many threads
00:49 < krutcha> possibly there's overhead to creating goroutines, thread
scheduling, etc
00:50 < krutcha> it isn't necessarily worth it for a quick calculation
(albeit cool), but better to keep the system busy while things are blocking on
resources
00:51 < foocraft> I'm running that on big data, just to see the speed up I
get with a serial vs parallel implementation
00:51 -!- skelterjohn [~jasmuth@c-68-45-238-234.hsd1.nj.comcast.net] has quit
[Quit: skelterjohn]
00:51 < krutcha> you could try maybe N go routines with channels, and
sending slices out to them and collecting the results instead
00:51 < nictuku> I can't reproduce
http://code.google.com/p/go/issues/detail?id=386 anymore (related to Xen).  can
anyone else try?
00:51 < krutcha> via channels, just for a fun alternative
00:52 -!- skelterjohn [~jasmuth@c-68-45-238-234.hsd1.nj.comcast.net] has joined
#go-nuts
00:52 < krutcha> ie batch processing your sort to a smaller amount of
goroutines
00:52 < krutcha> to prevent the thread flooding 1 thread per simple work
request
00:52 < adg> anyone got any suggestions for a screencast i should put
together?
00:52 < foocraft> adg, thinking in Go!
00:53 < adg> short topics, something i can cover in 5 minutes
00:53 < foocraft> or, "doing things the go way"
00:53 < adg> foocraft: yes!  i'd like to do something that explores go
idioms, a bit like the blog posts do
00:53 -!- antonkovalyov [~antonkova@75-101-56-240.dsl.static.sonic.net] has quit
[Remote host closed the connection]
00:53 < adg> what topic, though?  concurrency?  the type system?
00:53 < foocraft> I'm very interested in concurrency
00:54 < foocraft> you can see my failed experiment up there :p
00:54 < krutcha> the stuff that still wigs me out is use of empty
interfaces, which I see floating all over the place and don't know what to do with
:P
00:54 < foocraft> a serial merge sort works better than my parallel
implementation in Go :p because there's "Something" I'm not doing right
00:54 < adg> foocraft: are you setting GOMAXPROCS ?
00:55 < foocraft> no
00:55 < adg> foocraft: well it won't execute the goroutines in parallel if
you don't
00:55 < foocraft> is that a compile-time flag or something?
00:55 < nictuku> adg, maybe something related to unmarshaling.  json comes
to mind.
00:55 < krutcha> its a setting in the system package, can be done at runtime
00:55 < adg> foocraft: it's a runtime flag.  either set the environment
variable before running your program, or import runtime and call
runtime.GOMAXPROCS at the beginning
00:55 < krutcha> oops runtime, not system
00:55 < adg> krutcha: so a little primer on interface types?  hmm
00:56 < krutcha> adg: perhaps, I get general 'methods on types' interface
use, but that's still useful for people
00:56 < adg> krutcha: i can see introducing the idea of type assertion and
the type switch being useful
00:57 < adg> nictuku: that sounds like a good one
00:57 < adg> nictuku: there definitely is a trick to using the json package
00:57 < exch> foocraft: running your code, it seems to work ok here
00:57 < exch> I dont have a lot of input data thogh
00:57 < exch> *though
00:57 < foocraft> yeah, I just set the environment variable to 2
00:58 < foocraft> I run it on data generated randomly 1000000 numbers
00:58 < adg> thanks for the suggestions guys
00:58 < foocraft> http://fpaste.org/2GO9/
00:58 < adg> very helpful
00:58 < krutcha> foocraft: I still wonder if spawning like 4 goroutines,
then sending them work in channels and collecting results might not be better
00:58 < foocraft> run that and pipe everything to the parallel
implementation
00:58 < foocraft> krutcha, that's what I want to find out :)
01:00 < foocraft> okay so I'm still alive and it's not slowing up my machine
IT IS)
01:01 -!- noff [~noff@89-55.79-83.cust.bluewin.ch] has quit [Ping timeout: 245
seconds]
01:02 -!- noff [~noff@89-55.79-83.cust.bluewin.ch] has joined #go-nuts
01:04 < foocraft> okay so I've depressing results so far
01:04 < foocraft> cuz time ./genData 10000 | ./mergeSortParallel is like 3x
more than with mergeSortSerial
01:05 < skelterjohn> merge sort is really data intense
01:05 < skelterjohn> pastebin the code?
01:06 < foocraft> http://fpaste.org/Ngco/
01:06 -!- Tv [~tv@cpe-76-168-227-45.socal.res.rr.com] has joined #go-nuts
01:06 < foocraft> http://fpaste.org/XFjW/
01:06 -!- kanru [~kanru@2001:c08:3700:ffff::2b:dbc8] has quit [Ping timeout: 260
seconds]
01:06 < foocraft> the parallel and the serial implementations
01:07 < skelterjohn> you could do it without triggering the GC, and use only
O(2N) space instead of N lg N space
01:07 < foocraft> hmm how do I turn off GC?
01:08 < skelterjohn> not what i meant
01:08 < foocraft> (also, sorry about how the tabs turned out to be in the
paste)
01:08 < skelterjohn> i meant that by doing the 2N space version, GC won't
get triggered
01:08 < skelterjohn> since you won't let go of memory
01:08 <+iant> foocraft: you can turn off the GC by setting the environment
variable GOGC to off
01:08 < foocraft> skelterjohn, gotcha
01:08 < skelterjohn> but my guess is something that has lots of GC action on
memory shared between two goroutines can cause blocking
01:09 < foocraft> can I just turn it off and turn it back on after my
mergeSort is over, within a program?
01:10 <+iant> foocraft: set runtime.MemStats.EnableGC to false to turn it
off temporarily
01:10 -!- thomas_b [~thomasb@cm-84.215.47.51.getinternet.no] has joined #go-nuts
01:11 < skelterjohn> also...10000 items?  means that 2^13 goroutines are
spawned, i think
01:11 < foocraft> think 1000000
01:11 < foocraft> so I want to limit that, somehow
01:11 < foocraft> like say "only spawn two at a time or something
01:11 < skelterjohn> ack, i mean with N items, you spawn N goroutines
01:12 < skelterjohn> because at one level you are splitting N/2 pairs of
items and giving each to a goroutine
01:12 < foocraft> I spawn 2^log_n = N yes
01:12 < skelterjohn> so, 2N-1 total
01:12 < skelterjohn> that this only takes 3x as long is quite impressive :)
01:13 < foocraft> for a million, it doesn't terminate and I can barely type
:p
01:13 < skelterjohn> maybe only spawn a new one if the number of active
goroutines is less than or equal to the number of cores available
01:14 < foocraft> I want something that's a clean way of doing "if threads
spawned == limit, run this code in the same thread, otherwise, go thisThread()"
01:14 < nictuku> ugh, the compilation of the program generated by
test/64bit.go takes 134Mb of RSS :-(
01:14 < skelterjohn> otherwise with each goroutine you add overhead for no
speed
01:14 < skelterjohn> foocraft: i think the straightforward way is probably
best
01:14 < foocraft> I *think* there should be a compilation flag
01:14 < skelterjohn> but make sure to say >=
01:15 < skelterjohn> since there is a possible race condition
01:15 < exch> lol 1 million completely trashes my system
01:15 < exch> 6gb of ram
01:15 < foocraft> well, the way it's written, there can't be a race
condition, because reading from the channel two items will block until both
mergeSorts are done
01:15 < |Craig|> foocraft: for N cores, I'd split the array into roughly N
parts, send those slices off to go routines to sort, then merge them
01:16 < foocraft> hmm an N-way mergeSort.  I only heard about that in class
01:16 < skelterjohn> foocraft: i don't think that prevents race conditions
in this case
01:16 < skelterjohn> not the way your code is written
01:16 < foocraft> but since I'm on a 2 core machine, then I'm actually doing
that
01:16 < |Craig|> foocraft: when using more than one core, lots of go
routines = very slow due to context switching overheads
01:17 < skelterjohn> |Craig|: unless you're using gccgo, you don't context
switch when going between goroutines
01:17 < skelterjohn> not necessarily, anyway
01:17 < foocraft> yeah, I'm aware of that.  so is there a way to "cleanly"
limit the number of threads spawned, and by clean, I meant that if we reach the
limit, just run it in the same thread, otherwise, run it on a separate thread
01:17 < |Craig|> skelterjohn: how can it have more than one core loaded
then?
01:18 < skelterjohn> you can have many goroutines on one core (and some
others on a different one)
01:18 < skelterjohn> when you switch between goroutines on that one core,
there shouldn't be a big context switch
01:18 < foocraft> skelterjohn, context switching isn't a compilation option,
the os decides which thread to swtich to
01:18 < skelterjohn> the go runtime just jumps the program counter to a
differnet part of the program
01:18 < skelterjohn> goroutines are not threads or processes
01:18 < |Craig|> for long running tasks, the overhead is not too bad, but if
you make a goroutine to just merge sort 2 or 4 numbers, it would be faster to just
sort them instead
01:18 < skelterjohn> they're much more lightweight
01:19 < foocraft> hmm |Craig|, I like that idea
01:19 < skelterjohn> foocraft: i didn't suggest it was a compilation option.
but 6g/8g do goroutines as the nice lightweight bit
01:19 < skelterjohn> gccgo does a thread per goroutine (unless iant has been
busy)
01:19 -!- mbohun [~user@ppp115-156.static.internode.on.net] has joined #go-nuts
01:20 < |Craig|> skelterjohn: then making many really short lived ones will
be even slower
01:20 < skelterjohn> for gccgo?
01:21 < skelterjohn> making many short lived goroutines, with the 6g model,
is much faster than doing the same thing with threads
01:21 < skelterjohn> must less memory, much less time
01:21 < |Craig|> creating a thread and waiting for a response has to have
more overhead than an method call regardless.  As long as you have at least as
many go routines as processors, spewing them all over trying to parallelize won't
help performance (but in some cases can help desing)
01:22 < |Craig|> so a recursive sort than spawns go rountines at each
iteration is not going to run fast
01:22 < skelterjohn> but you do *not* create a thread when you create a
goroutine
01:22 < foocraft> hmm with |Craig|'s idea, I get a deadlock
01:22 < skelterjohn> though i agree that even goroutines have prohibitive
overhead with merge sort
01:24 -!- niemeyer [~niemeyer@189.73.142.213] has quit [Ping timeout: 245 seconds]
01:26 < |Craig|> you could make some sorting go routines, and have a load
balanced system for feeding slices to merge into them, and make as many of them as
you have processors
01:27 < foocraft> http://fpaste.org/pMj4/
01:27 < |Craig|> they would copy the slices, and merge them back into place,
and then pull in another pair of slices form their channel
01:27 < |Craig|> I'll be back later
01:27 < foocraft> thanks |Craig|
01:28 < foocraft> wait, there's a bug there
01:30 < foocraft> it deadlocks
01:30 < krutcha> I'd like to point out that it's dead easy in go to sit here
and switch between parallel, serial, differen't numbers of goroutines, etc with
minimal effort.  Which is pretty awesome.
01:31 < foocraft> :) yeah I'm lovin it hehe
01:31 < foocraft> like, in C, I'd probably have to get throw in a bunch of
semaphores, with minor design decisions like we just did
01:34 -!- krutcha [~krutcha@remote.icron.com] has quit [Quit: Leaving]
01:40 -!- tvw [~tv@e176006039.adsl.alicedsl.de] has quit [Ping timeout: 245
seconds]
01:40 < foocraft> if I get this one to work without thrashing my system, I
think I'm going to spend next semester doing parallel algorithms with Go
01:45 < foocraft> http://fpaste.org/ozMO/ so as soon as I start spawning a
thread in this function, I run into a deadlock
01:45 < foocraft> I think it's how I'm limiting my thread count
01:49 -!- antonkovalyov [~antonkova@adsl-75-18-220-88.dsl.pltn13.sbcglobal.net]
has joined #go-nuts
01:51 -!- ExtraSpice [~XtraSpice@88.118.33.48] has quit [Ping timeout: 240
seconds]
01:55 < skelterjohn> foocraft: you aren't popping values off of ch until
after the funciton returns
01:55 < skelterjohn> when you run that function in a diff goroutine it's ok
01:55 < skelterjohn> but since the sender and receiver for ch are in the
same goroutine, and it's an unbuffered chan, there is deadlock
01:59 -!- shvntr [~shvntr@113.84.151.193] has joined #go-nuts
02:00 -!- Kashia [~Kashia@port-92-200-8-147.dynamic.qsc.de] has quit [Ping
timeout: 260 seconds]
02:03 < plexdev> http://is.gd/imU06 by [Alex Brainman] in
go/src/pkg/runtime/windows/ -- runtime: fix windows build
02:06 -!- Kashia [~Kashia@port-92-200-108-107.dynamic.qsc.de] has joined #go-nuts
02:08 -!- iant [~iant@66.109.105.230] has quit [Quit: Leaving.]
02:11 -!- shvntr [~shvntr@113.84.151.193] has quit [Quit: luck]
02:13 -!- itrekkie [~itrekkie@ip72-200-115-40.tc.ph.cox.net] has joined #go-nuts
02:13 -!- itrekkie [~itrekkie@ip72-200-115-40.tc.ph.cox.net] has quit [Client
Quit]
02:21 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has quit [Ping
timeout: 245 seconds]
02:22 -!- ios_ [~ios@180.191.43.229] has joined #go-nuts
02:25 -!- antonkovalyov [~antonkova@adsl-75-18-220-88.dsl.pltn13.sbcglobal.net]
has quit [Remote host closed the connection]
02:29 -!- kanru [~kanru@2001:c08:3700:ffff::2b:ec7c] has joined #go-nuts
02:32 -!- noktoborus [debian-tor@gateway/tor-sasl/noktoborus] has joined #go-nuts
02:36 -!- liwei [~liwei@180.110.78.49] has joined #go-nuts
02:55 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has joined #go-nuts
03:00 -!- krutcha [~krutcha@S010600045a27676a.vs.shawcable.net] has joined
#go-nuts
03:16 -!- boscop [~boscop@f055006106.adsl.alicedsl.de] has quit [Ping timeout: 245
seconds]
03:18 -!- boscop [~boscop@f055199010.adsl.alicedsl.de] has joined #go-nuts
03:19 -!- vermi [959f7527@gateway/web/freenode/ip.149.159.117.39] has joined
#go-nuts
03:19 < vermi> at compile time, I get an error with this code fragment
http://pastebin.com/k2d0m5s5
03:19 < vermi> tells me nsfw is undefined, and also nsfw declared but not
used
03:20 < rmmh> vermi: you need to declare nsfw outside of the scope of the if
statements
03:20 < vermi> as in var nsfw string ?
03:20 < |Craig|> vermi: its declared twice, but both are inside an inner
scope
03:21 < rmmh> vermi: for example: nfsw := ""; if url..."q" { nsfw =
"[NFSW"]; }
03:21 < vermi> oh i see
03:22 < rmmh> also interesting, an IRC bot written in Go
03:22 -!- mandragor [~ergudicsu@cpe-174-109-112-159.nc.res.rr.com] has joined
#go-nuts
03:23 < rmmh> dynamic reloading is *really* nice with IRC bots, so I prefer
scripting languages for them
03:23 < vermi> i still get a nsfw declared but not used
03:23 < |Craig|> vermi: make sure in your if you use = not :=
03:24 < |Craig|> := makes another one
03:24 < rmmh> vermi: also, you might want to do http.URLEscape(tag) instead
of http.URLEscape(site)
03:24 < vermi> ah yes, i see your point there
03:24 < vermi> rmmh: the original bot was written in Python, in fact; but we
thought it'd be fun to fotz around with Go
03:26 < rmmh> just curious, is the framework open source?
03:26 < rmmh> I have my own Python IRC bot and I'm always interested in
stealing^Wborrowing ideas
03:27 < vermi> for the Python one?  Sure; it's not very impressive though:
http://github.com/vermi/mpu
03:27 < rmmh> ah, irclib
03:27 < vermi> our main thought was to move fro irclib to twisted
03:28 < rmmh> (mine is http://github.com/rmmh/skybot)
03:28 < rmmh> irclib isn't multithreaded, right?
03:29 < vermi> no it isn't
03:29 < vermi> that's why we were going to move to twisted
03:30 -!- skelterjohn [~jasmuth@c-68-45-238-234.hsd1.nj.comcast.net] has quit
[Quit: skelterjohn]
03:30 < vermi> then we decided to mess with Go instead for no real reason
03:30 < rmmh> :)
03:30 -!- rhencke [~rhencke@ppp-70-247-243-221.dsl.ltrkar.swbell.net] has joined
#go-nuts
03:31 < rmmh> twisted felt too bloated, so I just wrote my own IRC netcode
based on asynchat
03:31 < Tv> rmmh: twisted core is pretty tiny, feel free to ignore the
rest..
03:31 < Tv> rmmh: (and asynchat is just broken, compared to twisted...)
03:32 < rmmh> err, wait, I don't use asynchat
03:33 < rmmh> I'm just using raw sockets and threads with Queues for I/O
03:33 < rmmh> twisted's "everything is an object/factory" was annoying to me
03:36 < plexdev> http://is.gd/in6ir by [Andrew Gerrand] in 2 subdirs of go/
-- release.2010-12-08
03:36 < plexdev> http://is.gd/in6iz by [Andrew Gerrand] in go/ -- tag
release.2010-12-08
03:37 -!- skelterjohn [~jasmuth@c-68-45-238-234.hsd1.nj.comcast.net] has joined
#go-nuts
03:37 < rhencke> anyone ever get a program blow up on runtime.morestack?
03:38 < adg> rhencke: that has happened to me; can't remember what the
solution was
03:38 < rhencke> adg: thanks.  if you happen to remember what you did at
some point, i appreciate it :)
03:39 < adg> how are you triggering it?
03:40 < rhencke> i'm calling go->c->go then it hates me
03:41 < rhencke> haven't managed to reproduce with a simple test case; it
currently involves some c bindings i have
03:41 -!- niemeyer [~niemeyer@189.73.142.213] has joined #go-nuts
03:42 -!- `Wiz126 [Z@h62.126.232.68.ip.windstream.net] has joined #go-nuts
03:42 -!- Wiz126 [Z@h62.126.232.68.ip.windstream.net] has quit [Ping timeout: 265
seconds]
03:42 -!- foocraft [~dsc@89.211.184.236] has quit [Quit: Leaving]
03:43 < adg> rhencke: i guess it'd be helpful if you can boil it down to a
minimal test case.  i know that's not necessarily easy
03:44 < rhencke> adg: i will see if i can reduce the case down
03:44 -!- vermi [959f7527@gateway/web/freenode/ip.149.159.117.39] has quit [Quit:
Page closed]
03:44 -!- gnuvince_ [~vince@220.252-ppp.3menatwork.com] has joined #go-nuts
03:47 -!- gnuvince [~vince@70.35.162.131] has quit [Ping timeout: 260 seconds]
03:48 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has joined #go-nuts
03:48 -!- mode/#go-nuts [+v iant] by ChanServ
03:49 < rhencke> adg: woo, i did it :)
03:57 < rmmh> is there a variant of all.bash that doesn't do a make clean?
03:58 -!- vermi [959f7527@gateway/web/freenode/ip.149.159.117.39] has joined
#go-nuts
03:58 < adg> rmmh: make.bash
04:00 < rmmh> make.bash seems to clean everything as well?
04:00 < adg> rmmh: which part is being cleaned?
04:00 < adg> oh right, sorry, yes make.bash will run clean.bash
04:01 < vermi> so using the same code (http://pastebin.com/VdwPSTDQ) I've
discovered that the image-searching site I'm using often returns an error for no
apparent reason
04:01 < rmmh> go compiles fast, but a full recompile gets old quick
04:01 < vermi> so what I want to do is run the http.Get() again until err =
nil
04:01 < rmmh> also is the build broken for anyone else
04:01 < vermi> but i'm not sure how to accomplish that
04:02 < rmmh> vermi: are you sure you want to loop infinitely?  one retry
would be more sane
04:02 < vermi> well i've been testing it out in my browser
04:02 < vermi> and sometimes it takes 10 or 15 retries
04:03 < Namegduf> Make sure you add a delay.
04:03 < rmmh> that seems like an easy way to make your bot flood the server
04:04 < vermi> i wish i knew why it was giving an error in the first place
04:04 < vermi> then i could correct for that
04:05 -!- kanru [~kanru@2001:c08:3700:ffff::2b:ec7c] has quit [Ping timeout: 260
seconds]
04:12 -!- vermi [959f7527@gateway/web/freenode/ip.149.159.117.39] has quit [Quit:
Page closed]
04:18 -!- kanru [~kanru@2001:c08:3700:ffff::2b:f9ac] has joined #go-nuts
04:20 < rhencke> man, today was a lot of go changes
04:24 < adg> rmmh: "is the build broken?" http://godashboard.appspot.com/
04:24 < rmmh> yeah I saw
04:24 < rmmh> was my own fault :)
04:24 < rhencke> stuff like the printf changes make me wonder about the line
between compiler and program analyzer
04:24 -!- hoverbear [~Hoverbear@unaffiliated/hoverbear] has left #go-nuts
["WeeChat 0.3.4-dev"]
04:28 < rhencke> or if i overthink stuff :P
04:35 -!- lasersbambam [~krum@ruby.cat.pdx.edu] has quit [Ping timeout: 264
seconds]
04:39 -!- kanru [~kanru@2001:c08:3700:ffff::2b:f9ac] has quit [Ping timeout: 260
seconds]
04:40 < vsmatck> Is there any reason to stop goroutines before program exit
if you don't care when they exit?
04:41 < Tv> vsmatck: unless there's a possibility they have pending tasks to
finish, no
04:42 < vsmatck> Tv: Hm. That's what I was thinking.  But had a funny
feeling.  Thanks for the advice.
04:42 -!- prip [~foo@host196-135-dynamic.43-79-r.retail.telecomitalia.it] has quit
[Ping timeout: 240 seconds]
04:46 -!- ymasory [~ymasory@c-76-99-55-224.hsd1.pa.comcast.net] has quit [Quit:
Leaving]
04:50 -!- [noff] [~noff@88-190.78-83.cust.bluewin.ch] has joined #go-nuts
04:52 -!- kanru [~kanru@2001:c08:3700:ffff::2b:fb8c] has joined #go-nuts
04:53 -!- noff [~noff@89-55.79-83.cust.bluewin.ch] has quit [Ping timeout: 255
seconds]
04:56 -!- prip [~foo@host241-9-dynamic.7-79-r.retail.telecomitalia.it] has joined
#go-nuts
04:57 -!- devrim1 [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has joined #go-nuts
04:57 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has quit [Read error:
Connection reset by peer]
04:59 -!- ios_ [~ios@180.191.43.229] has quit [Quit: Leaving]
05:00 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has quit [Ping
timeout: 255 seconds]
05:06 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has joined #go-nuts
05:11 -!- mandragor [~ergudicsu@cpe-174-109-112-159.nc.res.rr.com] has quit [Read
error: Connection reset by peer]
05:14 -!- liwei [~liwei@180.110.78.49] has left #go-nuts ["Leaving"]
05:14 < krutcha> erm silly question, can you have multiple initializers in
the first statement of a for loop?
05:16 < rhencke> yes
05:16 < rhencke> for a, b := 1, 2; ...
05:17 < krutcha> hmm I thought as much, but what about with multiple returns
involved
05:17 < krutcha> like a,b,c := func(),d
05:17 < rhencke> i think you can do that
05:18 < krutcha> where func returns _,_ two values
05:18 < rhencke> hm, maybe you can't
05:19 -!- kanru [~kanru@2001:c08:3700:ffff::2b:fb8c] has quit [Ping timeout: 260
seconds]
05:19 -!- bmizerany [~bmizerany@208.66.27.62] has quit [Remote host closed the
connection]
05:19 < krutcha> yeah I'm not clear on that..  I'm looking at the spec
05:20 < krutcha> specifically in my case, naturally I want to go i, x, y :=
0, range mymap {
05:20 < rhencke> when i try it, i get 'multiple-value x in single-value
context'
05:20 < krutcha> because map doesn't return an index, only a key and a value
05:21 < krutcha> and I need to iterate linearly through a second structure
as I walk key/value pairs in the map
05:22 < rhencke> i'm not sure if you can do that all in the for statement
05:22 < krutcha> I get: syntax error: unexpected range
05:22 < krutcha> hehe yeah it was a bit wishful
05:22 < krutcha> but seemed allllmost plausible in go
05:23 < rhencke> i guess it might get ambiguous in some cases
05:23 < rmmh> krutcha: for i := 0, x, y := range mymap ?
05:23 < krutcha> well..  thats the thing
05:23 < rmmh> err
05:23 < plexdev> http://is.gd/inj5P by [Alex Brainman] in
go/src/pkg/syscall/ -- syscall: restrict access rights param of OpenProcess() to
the minimum needed
05:23 < rmmh> krutcha: for i := 0; x, y := range mymap ?
05:23 < krutcha> thats two statements
05:23 < krutcha> in a for, one is init, the other is condition
05:23 < krutcha> isn't it?  hmm
05:23 < krutcha> thats different with ranges
05:24 < krutcha> rmmh: you might be right for a range
05:24 < rmmh> err no
05:24 < rmmh> poor you, you'll have to use another line
05:25 < krutcha> crap
05:25 < rmmh> krutcha: specifically, RangeClause = Expression [ ","
Expression ] ( "=" | ":=" ) "range" Expression
05:26 < krutcha> hmm
05:27 -!- niemeyer [~niemeyer@189.73.142.213] has quit [Ping timeout: 245 seconds]
05:28 < krutcha> ah well, another line it is!
05:33 -!- kanru [~kanru@2001:c08:3700:ffff::2c:841a] has joined #go-nuts
05:46 -!- [noff] [~noff@88-190.78-83.cust.bluewin.ch] has quit [Ping timeout: 264
seconds]
05:54 < plexdev> http://is.gd/inmrG by [Robert Griesemer] in
go/src/pkg/go/token/ -- token/position.go: provide FileSet.File(), minor
optimizations
05:55 < plexdev> http://is.gd/inmrP by [Robert Griesemer] in
go/src/cmd/godoc/ -- godoc: use file instead of file set for computing line info
05:55 -!- piyushmishra [~piyushmis@117.200.228.221] has quit [Ping timeout: 272
seconds]
05:56 < krutcha> almost got my jabber client useful as a package, a lot of
cleanup, I had gone a bit go-routine and channel happy and must learn moderation
when faced with shiny new toys
05:59 < rhencke> krutcha: very hard to do, but very true
06:00 < rhencke> otoh, trying them for everything lets you figure out what
they're good for
06:00 < krutcha> absolutely
06:01 -!- kanru [~kanru@2001:c08:3700:ffff::2c:841a] has quit [Ping timeout: 260
seconds]
06:13 -!- kanru [~kanru@2001:c08:3700:ffff::2c:8846] has joined #go-nuts
06:13 -!- _nil [~aiden@c-24-147-65-44.hsd1.ma.comcast.net] has quit [Ping timeout:
264 seconds]
06:14 -!- kanru [~kanru@2001:c08:3700:ffff::2c:8846] has quit [Client Quit]
06:14 -!- keithcascio [~keithcasc@nat/google/x-fzmhavrjyzmrefpc] has quit [Quit:
Leaving]
06:21 -!- yugui [~yugui@yugui.jp] has joined #go-nuts
06:24 < vsmatck> XMPP seems like it'd be a good thing to have in the
standard library.
06:24 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has joined #go-nuts
06:26 < Tv> vsmatck: not convinced, it's a complex protocol..
06:26 < rhencke> plus the umpteen million extensions
06:26 < rhencke> maybe in a lib like protobuf
06:27 < Tv> i'd rather see a healthy ecosystem of add-ons, than a bloated &
obsolete stdlib
06:27 < krutcha> after looking at xmpp a bit I'd tend to agree
06:27 < vsmatck> Hm, perhaps XMPP hasn't really been around long enough and
is not adopted widely enough.
06:28 < krutcha> there's umpteen bajillion RFC's and also slight
implementation variations on servers
06:28 < vsmatck> I guess it's not exactly on the level of HTTP.
06:28 < rhencke> xmpp has a lot of adoption, but its not http level
06:28 < rhencke> google talk is xmpp
06:29 < rhencke> xmpp gets a lot of internal corporate use, too
06:34 < adg> vsmatck: we have a websocket library, that's been around for
less time than xmpp
06:34 < adg> xmpp is huge
06:34 < adg> but i'd rather see a high quality xmpp library outside the
standard library than in
06:34 < adg> frankly websockets could go elsewhere, too
06:34 < adg> we need to make the whole third-party library experience better
06:35 * adg out
06:35 * vsmatck tries to get pprof working.
06:37 -!- Eridius [~kevin@unaffiliated/eridius] has quit [Ping timeout: 250
seconds]
06:49 -!- zozoR [~zozoR@56344bf6.rev.stofanet.dk] has joined #go-nuts
07:07 -!- rhencke [~rhencke@ppp-70-247-243-221.dsl.ltrkar.swbell.net] has quit
[Quit: rhencke]
07:22 -!- piyushmishra [~piyushmis@117.200.231.121] has joined #go-nuts
07:23 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has quit [Ping
timeout: 272 seconds]
07:33 -!- [noff] [~noff@pub1.heig-vd.ch] has joined #go-nuts
07:33 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
07:35 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|]
07:39 -!- sacho [~sacho@87-126-42-243.btc-net.bg] has quit [Ping timeout: 240
seconds]
07:43 -!- sacho [~sacho@95-42-99-232.btc-net.bg] has joined #go-nuts
07:50 -!- tdc [~santegoed@host86-156-182-103.range86-156.btcentralplus.com] has
joined #go-nuts
07:56 -!- photron [~photron@port-92-201-103-85.dynamic.qsc.de] has joined #go-nuts
08:00 < krutcha> erm, whats the deal with umask, ioutil.writefile, and
permission values?  I am definitely experiencing weird
08:01 < krutcha> ioutil.WriteFile(filename, avatar.Photo, 0x644) ->
---x--Sr-T (linux)
08:01 < Tv> krutcha: octal not hex
08:03 < krutcha> ahh..  hmm all the code examples I've seen used hex, one
sec
08:04 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has quit [Quit:
leaving]
08:04 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has joined
#go-nuts
08:05 < krutcha> yeah that did it, thx
08:05 -!- Tv [~tv@cpe-76-168-227-45.socal.res.rr.com] has quit [Quit: Leaving.]
08:06 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
08:14 -!- tensorpudding [~user@99.148.202.191] has quit [Remote host closed the
connection]
08:21 -!- zozoR [~zozoR@56344bf6.rev.stofanet.dk] has quit [Quit: Morten.  Desu~]
08:30 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has quit [Quit:
leaving]
08:30 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has joined
#go-nuts
08:31 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 265 seconds]
08:33 -!- napsy [~luka@88.200.96.18] has joined #go-nuts
08:34 -!- noktoborus [debian-tor@gateway/tor-sasl/noktoborus] has quit [Ping
timeout: 245 seconds]
08:43 -!- Project_2501 [~Marvin@82.84.79.101] has joined #go-nuts
08:44 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
08:48 -!- nighty__ [~nighty@210.188.173.245] has quit [Remote host closed the
connection]
08:54 -!- rlab [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller,
Faster, Easier.  http://miranda-im.org]
08:56 -!- noktoborus [debian-tor@gateway/tor-sasl/noktoborus] has joined #go-nuts
09:11 -!- noam [noam@77.124.236.67] has quit [Ping timeout: 255 seconds]
09:11 -!- noam [noam@77.124.236.67] has joined #go-nuts
09:17 -!- ExtraSpice [~XtraSpice@88.118.33.48] has joined #go-nuts
09:18 < krutcha> threw current state of go pkg for XMPP I've been playing
with up here https://github.com/krutcha/go-jabber , don't expect much, it's pretty
basic and I didn't know anything about go OR xmpp when I started :P
09:27 < plexdev> http://is.gd/inKn5 by [Peter Mundy] in go/doc/ -- doc: fix
installation $GOOS choices
09:44 -!- Innominate [~sirrobin@cpe-076-182-074-143.nc.res.rr.com] has quit [Ping
timeout: 240 seconds]
10:08 -!- tdc [~santegoed@host86-156-182-103.range86-156.btcentralplus.com] has
quit [Quit: tdc]
10:14 -!- wrtp [~rog@92.17.77.11] has joined #go-nuts
10:14 -!- noam [noam@77.124.236.67] has quit [Read error: Connection reset by
peer]
10:15 -!- noam [noam@77.124.236.67] has joined #go-nuts
10:18 -!- Kashia [~Kashia@port-92-200-108-107.dynamic.qsc.de] has quit [Quit: This
computer has gone to sleep]
10:24 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has joined #go-nuts
10:43 -!- ios_ [~ios@180.191.130.187] has joined #go-nuts
10:55 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
10:57 * wrtp is in dylib hell
10:59 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
11:27 -!- tvw [~tv@212.79.9.150] has joined #go-nuts
11:27 -!- gnuvince_ [~vince@220.252-ppp.3menatwork.com] has left #go-nuts []
11:29 < nsf> go/parser.ParseFile new interface is creepy
11:29 -!- Project_2501 [~Marvin@82.84.79.101] has quit [Quit: E se abbasso questa
leva che succ...]
11:30 < nsf> it starts to look like Java
11:30 -!- niemeyer [~niemeyer@189.73.142.213] has joined #go-nuts
11:34 < nsf> no, it's not creepy, it simply sucks
11:34 -!- snearch [~snearch@f053003059.adsl.alicedsl.de] has joined #go-nuts
11:40 < Namegduf> Is there already a parser.File?
11:40 < Namegduf> Or a parser.SomeOtherFile?
11:41 < nsf> No
11:41 < nsf> there is a token.File
11:41 < Namegduf> Odd, then.
11:41 < Namegduf> Maybe it looked ugly within the package?
11:41 < nsf> the whole interface is ugly now
11:42 < nsf> Position is compressed and because of that it depends on a
context
11:42 < nsf> and this context is FileSet
11:42 < nsf> so..  now if I want to use position I need to carry this
FileSet everywhere
11:42 -!- Soultaker [~Soultaker@infinity.student.utwente.nl] has quit [Ping
timeout: 255 seconds]
11:44 < nsf> fuck..  it breaks my app completely
11:45 < nsf> (gocode)
11:49 -!- noff_ [~noff@pub1.heig-vd.ch] has joined #go-nuts
11:52 -!- [noff] [~noff@pub1.heig-vd.ch] has quit [Ping timeout: 240 seconds]
12:01 -!- Soultaker [~Soultaker@infinity.student.utwente.nl] has joined #go-nuts
12:04 -!- rlab_ [~Miranda@91.200.158.34] has joined #go-nuts
12:05 -!- tdc [~santegoed@host86-156-182-103.range86-156.btcentralplus.com] has
joined #go-nuts
12:05 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 240 seconds]
12:05 -!- DarthShrine [~angus@pdpc/supporter/student/DarthShrine] has quit [Quit:
DarthShrine]
12:14 -!- Soultaker [~Soultaker@infinity.student.utwente.nl] has quit [Ping
timeout: 245 seconds]
12:15 < nsf> gocode became 10-20% slower
12:19 < nsf> now autocompletions take 50ms instead of 30ms
12:20 < nsf> although, memory behaviour is a bit better now
12:20 < nsf> which is good
12:23 < nsf> nope, it's worse
12:24 < nsf> I think I will have to fork go/parser :\
12:25 < MaybeSo> do you talk to the primary author at all?  provide
feedback?
12:25 < MaybeSo> they might be interested in hearing that your use case
shows 2x slowdown.
12:25 < nsf> I don't like to talk much
12:26 < exch> :p
12:26 < exch> Luckily you dont have to talk on the interwebz, just type
12:27 -!- noam [noam@77.124.236.67] has quit [Ping timeout: 264 seconds]
12:27 < nsf> currently I'm just very unhappy with the GC
12:27 < nsf> sequence of dropping cache and filling it again in gocode
quickly leads to memory consumption over 450 megs
12:27 < nsf> not good
12:29 < nsf> but maybe I'm just stupid and have no idea how to work with
GCed languages
12:34 -!- noam [noam@77.124.236.67] has joined #go-nuts
12:35 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has joined #go-nuts
12:51 < wrtp> the GC is changing very soon
12:52 -!- mbohun [~user@ppp115-156.static.internode.on.net] has quit [Ping
timeout: 255 seconds]
12:52 < wrtp> surely 1/20th of a second is an acceptable speed?
12:55 < nsf> I'm fine with speed, I don't like memory behaviour
12:57 -!- Soultaker [~Soultaker@infinity.student.utwente.nl] has joined #go-nuts
12:58 < nsf> and I've seen recent Russ' changesets for GC
12:58 < nsf> looks like he only speeds up sweeping part
12:58 < nsf> and doesn't change anything in general
13:01 -!- javax [~javax@galaxy.infidyne.com] has left #go-nuts []
13:02 < nsf> and well, there is a possibility of a memory leak, but I think
it's very unlikely
13:02 < nsf> I have only one global variable in gocode
13:02 < nsf> and drop-cache command clears it
13:02 < nsf> still, memory consumption grows
13:03 -!- skejoe [~skejoe@188.114.142.162] has joined #go-nuts
13:05 < nsf> and go memory allocator uses tcmalloc's algorithms as far as I
know, I'm sure they are very good for a system-wide allocator, but on a per
application basis..  probably not a very good idea
13:05 -!- xash [~xash@d126025.adsl.hansenet.de] has joined #go-nuts
13:06 < nsf> unless it's a dedicated server software
13:07 -!- zozoR [~zozoR@56344bf6.rev.stofanet.dk] has joined #go-nuts
13:08 < nsf> and sadly for me, this is what google targets with this
language :)
13:18 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3]
13:20 -!- rlab_ [~Miranda@91.200.158.34] has quit [Ping timeout: 240 seconds]
13:27 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
13:38 -!- noff_ [~noff@pub1.heig-vd.ch] has quit [Ping timeout: 240 seconds]
13:42 -!- grumpytoad [~niel@t1004.greatnet.de] has quit [Ping timeout: 276
seconds]
13:46 -!- virtualsue [~chatzilla@nat/cisco/x-gswngtutzufwebyy] has joined #go-nuts
13:49 -!- Maxdamantus [~Maxdamant@203.97.238.106] has quit [Ping timeout: 260
seconds]
13:57 -!- plainhao [~plainhao@208.75.85.237] has joined #go-nuts
13:58 -!- xash [~xash@d126025.adsl.hansenet.de] has quit [Read error: Operation
timed out]
14:03 -!- grumpytoad [~niel@t1004.greatnet.de] has joined #go-nuts
14:07 -!- virtualsue [~chatzilla@nat/cisco/x-gswngtutzufwebyy] has quit [Ping
timeout: 260 seconds]
14:12 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has quit [Quit:
Leaving.]
14:12 -!- virtualsue [~chatzilla@nat/cisco/x-vzfibmjcxqbuykle] has joined #go-nuts
14:12 -!- tdc [~santegoed@host86-156-182-103.range86-156.btcentralplus.com] has
quit [Quit: Leaving]
14:15 -!- artefon [~thiago@189.59.204.192] has joined #go-nuts
14:19 -!- skejoe [~skejoe@188.114.142.162] has quit [Quit: Lost terminal]
14:19 -!- Innominate [~sirrobin@cpe-076-182-074-143.nc.res.rr.com] has joined
#go-nuts
14:20 -!- xash [~xash@d126025.adsl.hansenet.de] has joined #go-nuts
14:23 -!- Maxdamantus [~Maxdamant@203.97.238.106] has joined #go-nuts
14:24 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Quit: WeeChat
0.3.2]
14:33 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
14:34 -!- ExtraSpice [~XtraSpice@88.118.33.48] has quit [Quit: Leaving]
14:48 -!- ExtraSpice [~XtraSpice@88.118.33.48] has joined #go-nuts
14:50 -!- skelterjohn [~jasmuth@c-68-45-238-234.hsd1.nj.comcast.net] has quit
[Quit: skelterjohn]
14:53 -!- Tv [~tv@cpe-76-168-227-45.socal.res.rr.com] has joined #go-nuts
14:57 -!- noam [noam@77.124.236.67] has quit [Ping timeout: 276 seconds]
14:59 -!- wrtp_ [~rog@92.17.77.11] has joined #go-nuts
14:59 -!- wrtp [~rog@92.17.77.11] has quit [Read error: Connection reset by peer]
15:00 -!- wrtp_ [~rog@92.17.77.11] has joined #go-nuts
15:00 -!- wrtp [~rog@92.17.77.11] has quit [Read error: Connection reset by peer]
15:02 < plexdev> http://is.gd/iou52 by [Rob Pike] in go/src/pkg/path/ --
path: fix printf glitch in test
15:02 -!- wrtp [~rog@92.17.77.11] has quit [Read error: Connection reset by peer]
15:02 -!- wrtp [~rog@92.17.77.11] has joined #go-nuts
15:02 -!- noam [noam@77.124.236.67] has joined #go-nuts
15:13 -!- iant [~iant@67.218.110.2] has joined #go-nuts
15:13 -!- mode/#go-nuts [+v iant] by ChanServ
15:32 -!- wrtp [~rog@92.17.77.11] has quit [Ping timeout: 276 seconds]
15:38 -!- wrtp [~rog@92.17.77.11] has joined #go-nuts
15:49 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Quit: Leaving.]
15:49 -!- ymasory [~ymasory@SEAS205.wlan.seas.upenn.edu] has joined #go-nuts
15:52 -!- Venom_X [~pjacobs@99-8-218-190.lightspeed.hstntx.sbcglobal.net] has
joined #go-nuts
15:52 -!- awidegreen [~quassel@c-eacae555.08-2-73746f39.cust.bredbandsbolaget.se]
has joined #go-nuts
15:54 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts
15:54 -!- zeroXten [~zeroXten@0x10.co.uk] has quit [Ping timeout: 276 seconds]
15:55 -!- zeroXten [~zeroXten@0x10.co.uk] has joined #go-nuts
16:10 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has quit [Ping timeout:
624 seconds]
16:31 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 265 seconds]
16:33 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
16:35 -!- krutcha [~krutcha@S010600045a27676a.vs.shawcable.net] has quit [Quit:
Leaving]
16:40 -!- iant [~iant@67.218.110.2] has quit [Quit: Leaving.]
16:42 -!- ios_ [~ios@180.191.130.187] has quit [Quit: Leaving]
16:43 -!- Fish [~Fish@coss6.exosec.net] has joined #go-nuts
16:45 -!- ymasory [~ymasory@SEAS205.wlan.seas.upenn.edu] has quit [Ping timeout:
240 seconds]
16:53 -!- skelterjohn [~jasmuth@dsl092-234-022.phl1.dsl.speakeasy.net] has joined
#go-nuts
16:56 -!- Venom_X [~pjacobs@99-8-218-190.lightspeed.hstntx.sbcglobal.net] has quit
[Quit: Venom_X]
17:00 -!- skelterjohn [~jasmuth@dsl092-234-022.phl1.dsl.speakeasy.net] has quit
[Quit: skelterjohn]
17:01 -!- sahid [~sahid@LNeuilly-152-21-22-10.w193-253.abo.wanadoo.fr] has quit
[Quit: Ex-Chat]
17:07 -!- ville- [~ville@a107.ath.cx] has quit [Ping timeout: 240 seconds]
17:14 -!- thiago__ [~thiago@189.59.204.192] has joined #go-nuts
17:15 -!- emjayess [~emjayess@pix1.i29.net] has quit [Read error: Connection reset
by peer]
17:16 -!- artefon [~thiago@189.59.204.192] has quit [Read error: Connection reset
by peer]
17:24 -!- saschpe [~quassel@opensuse/member/saschpe] has joined #go-nuts
17:27 -!- ville- [~ville@a107.ath.cx] has joined #go-nuts
17:32 -!- keithcascio [~keithcasc@nat/google/x-kpczuhrtfljslfms] has joined
#go-nuts
17:41 -!- skelterjohn [~jasmuth@c-71-230-156-50.hsd1.nj.comcast.net] has joined
#go-nuts
17:43 -!- Venom_X [~pjacobs@66.54.185.131] has joined #go-nuts
17:45 -!- sauerbraten [~sauerbrat@p508CADF8.dip.t-dialin.net] has joined #go-nuts
17:46 -!- ct529 [~quassel@77-44-78-159.xdsl.murphx.net] has joined #go-nuts
17:48 -!- ct529 [~quassel@77-44-78-159.xdsl.murphx.net] has quit [Remote host
closed the connection]
17:50 -!- krutcha [~krutcha@remote.icron.com] has joined #go-nuts
17:51 -!- jhawk28 [~jhawk28@user-387c58d.cable.mindspring.com] has joined #go-nuts
17:52 -!- jhawk28_ [~jhawk28@user-387c58d.cable.mindspring.com] has joined
#go-nuts
17:52 -!- jhawk28 [~jhawk28@user-387c58d.cable.mindspring.com] has quit [Read
error: Connection reset by peer]
17:55 -!- Kashia [~Kashia@port-92-200-108-107.dynamic.qsc.de] has joined #go-nuts
17:57 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has quit [Read error:
Connection reset by peer]
18:04 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts
18:07 -!- deso [~deso@x0561a.wh30.tu-dresden.de] has joined #go-nuts
18:09 -!- tvw [~tv@212.79.9.150] has quit [Remote host closed the connection]
18:24 -!- zozoR [~zozoR@56344bf6.rev.stofanet.dk] has quit [Quit: Morten.  Desu~]
18:27 -!- TheMue [~TheMue@p5DDF755E.dip.t-dialin.net] has joined #go-nuts
18:30 -!- iant [~iant@nat/google/x-xhlzsswkddgorbtx] has joined #go-nuts
18:30 -!- mode/#go-nuts [+v iant] by ChanServ
18:36 -!- thiago__ [~thiago@189.59.204.192] has quit [Ping timeout: 250 seconds]
18:37 -!- thiago__ [~thiago@187.114.48.78] has joined #go-nuts
18:40 -!- skelterjohn_ [~jasmuth@c-71-230-156-50.hsd1.nj.comcast.net] has joined
#go-nuts
18:40 -!- skelterjohn [~jasmuth@c-71-230-156-50.hsd1.nj.comcast.net] has quit
[Read error: Connection reset by peer]
18:41 -!- virtualsue [~chatzilla@nat/cisco/x-vzfibmjcxqbuykle] has quit [Ping
timeout: 265 seconds]
18:44 -!- xash [~xash@d126025.adsl.hansenet.de] has quit [Ping timeout: 240
seconds]
18:50 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 240 seconds]
18:51 < plexdev> http://is.gd/ip1hN by [Russ Cox] in go/src/cmd/ld/ -- ld:
re-add ELF symbol tables
18:51 < plexdev> http://is.gd/ip1i0 by [Russ Cox] in go/src/cmd/ld/ -- ld:
reading of ELF object files
18:51 < plexdev> http://is.gd/ip1il by [Russ Cox] in 3 subdirs of
go/src/cmd/ -- 6l, 8l: minor changes & cleanup
18:51 < plexdev> http://is.gd/ip1iT by [Russ Cox] in go/src/cmd/gopack/ --
gopack: allow ELF/Mach-O objects in .a files without clearing allobj
18:51 < nsf> here we go :)
18:51 < plexdev> http://is.gd/ip1ja by [Russ Cox] in 2 subdirs of
go/src/pkg/debug/ -- debug/elf, debug/macho: add ImportedLibraries,
ImportedSymbols
18:51 < plexdev> http://is.gd/ip1jh by [Russ Cox] in go/src/cmd/ld/ -- ld:
reading of Mach-O object files
18:51 -!- piyushmishra [~piyushmis@117.200.231.121] has quit [Quit: Leaving.]
18:51 < plexdev> http://is.gd/ip1kq by [Russ Cox] in 3 subdirs of
go/src/pkg/ -- runtime/cgo: runtime changes for new cgo
18:51 < nsf> new cgo is coming
18:52 -!- tvw [~tv@e176005135.adsl.alicedsl.de] has joined #go-nuts
18:56 < kimelto> :)
18:56 -!- ville- [~ville@a107.ath.cx] has quit [Remote host closed the connection]
19:01 -!- ct529 [~quassel@77-44-78-159.xdsl.murphx.net] has joined #go-nuts
19:03 -!- wrtp [~rog@92.17.77.11] has quit [Ping timeout: 265 seconds]
19:08 < plexdev> http://is.gd/ip3A5 by [Russ Cox] in 3 subdirs of
go/src/cmd/ -- 6l, 8l: support for linking ELF and Mach-O .o files
19:08 < plexdev> http://is.gd/ip3Ak by [Russ Cox] in 2 subdirs of go/src/ --
cgo: new cgo
19:08 < plexdev> http://is.gd/ip3B0 by [Russ Cox] in go/src/pkg/runtime/cgo/
-- runtime/cgo: take 2
19:09 -!- wrtp [~rog@92.17.77.11] has joined #go-nuts
19:16 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
19:16 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Quit: Leaving]
19:27 -!- emjayess [~emjayess@pix1.i29.net] has joined #go-nuts
19:27 -!- araujo [~araujo@190.38.50.25] has joined #go-nuts
19:27 -!- araujo [~araujo@190.38.50.25] has quit [Changing host]
19:27 -!- araujo [~araujo@gentoo/developer/araujo] has joined #go-nuts
19:32 < exch> adg: Are those 'go t.shirt()' shirts for sale somewhere?  :p
19:37 -!- retybok [~retybok@i03m-212-195-151-239.d4.club-internet.fr] has joined
#go-nuts
19:40 < plexdev> http://is.gd/ip83U by [Russ Cox] in go/src/pkg/syscall/ --
syscall: fix linux/arm build
19:40 < plexdev> http://is.gd/ip841 by [Russ Cox] in 3 subdirs of go/src/ --
libcgo: delete (replaced by runtime/cgo)
19:40 < plexdev> http://is.gd/ip84T by [Russ Cox] in go/src/ -- fix build:
more libcgo references
19:42 -!- skelterjohn [~jasmuth@c-71-230-156-50.hsd1.nj.comcast.net] has quit
[Quit: skelterjohn]
19:42 -!- Project_2501 [~Marvin@82.84.79.101] has joined #go-nuts
19:45 -!- rbraley [~rbraley@ip72-204-243-89.ph.ph.cox.net] has quit [Ping timeout:
260 seconds]
19:46 -!- noam [noam@77.124.236.67] has quit [Read error: Connection reset by
peer]
19:46 -!- virtualsue [~chatzilla@nat/cisco/x-tbqhjlzttmcesixt] has joined #go-nuts
19:46 -!- noam [noam@77.124.236.67] has joined #go-nuts
19:47 -!- rbraley [~rbraley@ip72-204-243-89.ph.ph.cox.net] has joined #go-nuts
19:48 < wrtp> nsf: i haven't seen anything changing the GC yet.  which CLs
are you referring to?
19:49 < nsf> http://codereview.appspot.com/user/rsc
19:49 < nsf> http://codereview.appspot.com/3435041/
19:49 -!- plainhao [~plainhao@208.75.85.237] has quit [Quit: plainhao]
19:50 -!- xash [~xash@d201245.adsl.hansenet.de] has joined #go-nuts
19:52 -!- antonkovalyov [~antonkova@75-101-56-240.dsl.static.sonic.net] has joined
#go-nuts
19:54 -!- tensorpudding [~user@99.148.202.191] has joined #go-nuts
19:55 -!- anticw [~anticw@c-67-169-68-180.hsd1.ca.comcast.net] has quit [Read
error: Connection reset by peer]
19:55 -!- anticw [~anticw@c-67-169-68-180.hsd1.ca.comcast.net] has joined #go-nuts
19:58 -!- ct529 [~quassel@77-44-78-159.xdsl.murphx.net] has quit [Remote host
closed the connection]
20:01 < uriel> 12:58 < nsf> and I've seen recent Russ' changesets for
GC
20:01 < uriel> nsf: where have you seen that?
20:01 < uriel> nsf: and AFAIK the changes in go/parser were supposed to
speed things up, and certainly lower memory usage
20:02 < nsf> uriel: second link below
20:03 < uriel> nsf: if you are seeing leaks, are you using 8g or 6g?  I seem
to remember that there are some GC issues with 8g
20:03 < nsf> uriel: they made things slower and memory usage is another
issue
20:03 < nsf> 8g
20:03 < nsf> they are not leaks
20:03 < nsf> these*
20:03 < uriel> then you might be tickling some bug, let me see if I can fin
dit
20:03 < nsf> these are just free memory owned by GC
20:04 < nsf> oops, I meant 'above' earlier :D
20:04 < GilJ> Speaking of GC, does Go have fully working GC or not?  I read
somewhere that the garbage collecting part wasn't implemented
20:04 < GilJ> Don't remember where though :(
20:04 < nsf> 'below' is slightly different direction :D
20:04 < nsf> GilJ: it works
20:04 < GilJ> nsf: Ok thanks :)
20:04 < nsf> just not the way I want
20:05 < exch> It's a simplistic GC, but it works.  New one in the works
20:05 < uriel> nsf: http://code.google.com/p/go/issues/detail?id=909
20:05 < GilJ> What would you like to see different, nsf?
20:05 < uriel> (and I think there are other related issues)
20:05 < uriel> 20:04 < GilJ> Speaking of GC, does Go have fully
working GC or not?  I read somewhere that the garbage collecting part wasn't
20:05 < uriel> implemented
20:05 < uriel> GilJ: you read wrong
20:05 < nsf> GilJ: I want it to minimize system memory usage
20:06 < nsf> because I have plans to implement desktop apps using Go
20:06 < nsf> and less memory they use - better
20:06 < uriel> GilJ: the GC is fully implemented, but it is being rewritten
too
20:06 < nsf> currently Go mostly works for server software
20:06 < uriel> nsf: I don't see what the problem might be for client
software...
20:07 < nsf> 450 megabytes of system memory usage, 60-120 megabytes is
allocated, everything else is free and owned by GC in free lists
20:07 < nsf> something like that
20:07 < nsf> I can give you exact numbers if you want to
20:08 < GilJ> "Free lists?"
20:08 < nsf> yes
20:08 < kimelto> what is planned for the new GC? something like garbage
first?
20:09 < nsf> GilJ: http://nsf.github.com/go/runtime.html?t:MemStatsType!
20:09 < nsf> see this structure
20:09 < GilJ> nsf: Thanks :)
20:09 < nsf> at the end it has a list
20:09 < nsf> 'BySize'
20:09 < nsf> GC keeps all of them under its control, it simply doesn't
release memory back to OS
20:10 < nsf> it's ok for system-wide allocator
20:10 < nsf> and not a very good idea for per application basis
20:11 < GilJ> Ok I get it now, thanks nsf
20:11 < uriel> nsf: as i said, if you are going to complain about the GC,
use 6g, becauxe 8g is known to be buggy
20:12 < nsf> my complains are not about bugs :)
20:12 < uriel> nsf: it not doing a good job is a bug
20:12 < plexdev> http://is.gd/ipcyO by [Adam Langley] in
go/src/pkg/crypto/elliptic/ -- crypto/elliptic: remove mistakenly commited code
20:14 < wrtp> nsf: the GC will get better.  just go with it for now.
20:15 < nsf> yeah, I know :)
20:15 -!- jhawk28_ [~jhawk28@user-387c58d.cable.mindspring.com] has quit [Ping
timeout: 240 seconds]
20:17 -!- ct529 [~quassel@77-44-78-159.xdsl.murphx.net] has joined #go-nuts
20:19 < nsf> uriel: and maybe you're right as well
20:19 < nsf> I mean a lot of these memory usage comes from a bug, it is
possible
20:19 < nsf> http://code.google.com/p/go/issues/detail?id=1210
20:19 -!- ct529 [~quassel@77-44-78-159.xdsl.murphx.net] has quit [Remote host
closed the connection]
20:19 < nsf> especially that example kind of interesting
20:21 < nsf> I will download some 64bit linux distro and will try gocode
with it
20:24 -!- xash [~xash@d201245.adsl.hansenet.de] has quit [Ping timeout: 245
seconds]
20:24 -!- coldturnip1 [~COLDTURNI@118-166-68-180.dynamic.hinet.net] has joined
#go-nuts
20:25 -!- coldturnip [~COLDTURNI@118-166-70-93.dynamic.hinet.net] has quit [Ping
timeout: 245 seconds]
20:26 -!- enherit [~enherit@cpe-98-149-170-48.socal.res.rr.com] has joined
#go-nuts
20:27 < uriel> haha, funny name: http://code.google.com/p/rsc/
20:29 < sl> haha!
20:29 -!- thiago__ [~thiago@187.114.48.78] has quit [Read error: Connection reset
by peer]
20:38 -!- thiago__ [~thiago@187.114.48.78] has joined #go-nuts
20:39 -!- Eridius [~kevin@unaffiliated/eridius] has joined #go-nuts
20:39 -!- DarthShrine [~angus@60-242-109-62.tpgi.com.au] has joined #go-nuts
20:39 -!- DarthShrine [~angus@60-242-109-62.tpgi.com.au] has quit [Changing host]
20:39 -!- DarthShrine [~angus@pdpc/supporter/student/DarthShrine] has joined
#go-nuts
20:44 < plexdev> http://is.gd/ipgUr by [Russ Cox] in go/src/cmd/5l/ -- 5l:
fix build
20:44 < plexdev> http://is.gd/ipgUG by [Russ Cox] in 3 subdirs of
go/src/cmd/ -- 5l (and 6l, 8l, ld): more arm build fixes
21:00 -!- photron [~photron@port-92-201-103-85.dynamic.qsc.de] has quit [Read
error: Operation timed out]
21:00 -!- sauerbraten [~sauerbrat@p508CADF8.dip.t-dialin.net] has quit [Remote
host closed the connection]
21:06 < adg> exch: i would like them to be.  no plans as yet
21:07 < exch> aww
21:09 -!- boscop [~boscop@f055199010.adsl.alicedsl.de] has quit [Read error:
Connection reset by peer]
21:10 -!- boscop [~boscop@f055199010.adsl.alicedsl.de] has joined #go-nuts
21:10 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has joined #go-nuts
21:13 -!- deso [~deso@x0561a.wh30.tu-dresden.de] has quit [Remote host closed the
connection]
21:15 -!- boscop [~boscop@f055199010.adsl.alicedsl.de] has quit [Read error:
Connection reset by peer]
21:15 -!- boscop [~boscop@f055199010.adsl.alicedsl.de] has joined #go-nuts
21:29 -!- noam [noam@77.124.236.67] has quit [Ping timeout: 240 seconds]
21:31 < plexdev> http://is.gd/ipnn9 by [Rob Pike] in 2 subdirs of
go/src/pkg/ -- a few more errors caught by the print checker
21:36 -!- noff [~noff@88-190.78-83.cust.bluewin.ch] has joined #go-nuts
21:36 -!- noam [~noam@77.124.236.67] has joined #go-nuts
21:37 -!- TheMue [~TheMue@p5DDF755E.dip.t-dialin.net] has quit [Quit: TheMue]
21:44 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
21:47 -!- saschpe [~quassel@opensuse/member/saschpe] has quit [Read error:
Connection reset by peer]
21:48 < plexdev> http://is.gd/ippHc by [Russ Cox] in go/src/pkg/runtime/cgo/
-- runtime/cgo: adapt files copied from libcgo
21:48 < plexdev> http://is.gd/ippHo by [Russ Cox] in 2 subdirs of
go/src/pkg/ -- arm: more fixes
21:50 -!- meanburrito920 [~john@unaffiliated/meanburrito920] has quit [Quit:
leaving]
21:52 < rmmh> how do I add a file to a pending codereview :|
21:53 -!- ronnyy [~quassel@drsd-4db3d4fc.pool.mediaWays.net] has joined #go-nuts
21:55 -!- jhawk28 [~jhawk28@user-387c58d.cable.mindspring.com] has joined #go-nuts
21:56 -!- jhawk28 [~jhawk28@user-387c58d.cable.mindspring.com] has quit [Read
error: Connection reset by peer]
21:56 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has joined
#go-nuts
22:02 <+iant> rmmh: run "hg change NNNN" and edit the list of files
22:03 < GilJ> If I have a package called unionfind, that implements a basic
data structure, an interface with a Union and Find method, and a struct that
contains the actual data, which one do I name UnionFind?  The struct or the
Interface?
22:04 <+iant> I think it depends on what you expect or want users of the
package to use
22:04 < plexdev> http://is.gd/ipsdd by [Andrew Gerrand] in go/doc/ -- doc:
fix invalid id attribute in faq
22:05 < GilJ> iant: ok, that makes sense, thanks alot!
22:06 < rmmh> GilJ: is this a disjointset?
22:07 < rmmh> someone with commit access should do s/for (.*), _ := range
(.*)/for \1 := range \2/ to the tree
22:08 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has quit [Quit:
hcatlin]
22:08 < GilJ> rmmh: No
22:09 < rmmh> why not
22:09 < rmmh> it's 100% useless
22:10 < GilJ> rmmh: It is, but I just wanted to play around with an
interface
22:11 < rmmh> oh, sorry, I thought you said "no" in response to my regex :)
22:11 < GilJ> Ah sorry
22:11 < krutcha> what's useless?  ranges?
22:14 -!- ronnyy [~quassel@drsd-4db3d4fc.pool.mediaWays.net] has quit [Remote host
closed the connection]
22:15 -!- beneth` [~beneth`@ks358244.kimsufi.com] has quit [Quit: AnonOps]
22:15 -!- beneth` [~beneth`@ks358244.kimsufi.com] has joined #go-nuts
22:16 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 276 seconds]
22:18 -!- SRabbelier [~SRabbelie@188.142.63.148] has quit [Ping timeout: 250
seconds]
22:21 < plexdev> http://is.gd/ipva4 by [Rob Pike] in go/src/pkg/exp/nacl/av/
-- event.go: another print glitch from gocheck.
22:24 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
22:27 -!- fhs [~fhs@pool-74-101-63-115.nycmny.east.verizon.net] has joined
#go-nuts
22:30 -!- watr_ [~watr@66.183.100.58] has joined #go-nuts
22:33 -!- retybok [~retybok@i03m-212-195-151-239.d4.club-internet.fr] has quit
[Quit: leaving]
22:34 -!- boscop [~boscop@f055199010.adsl.alicedsl.de] has quit [Read error:
Connection reset by peer]
22:34 -!- boscop [~boscop@f055199010.adsl.alicedsl.de] has joined #go-nuts
22:44 -!- awidegreen [~quassel@c-eacae555.08-2-73746f39.cust.bredbandsbolaget.se]
has quit [Read error: Connection reset by peer]
22:45 -!- napsy [~luka@88.200.96.18] has quit [Quit: Lost terminal]
22:49 -!- Venom_X [~pjacobs@66.54.185.131] has quit [Quit: Venom_X]
22:51 -!- rlab [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller,
Faster, Easier.  http://miranda-im.org]
23:05 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit:
Verlassend]
23:07 -!- thiago__ [~thiago@187.114.48.78] has quit [Quit: bye]
23:25 -!- Scorchin [~Scorchin@host109-152-113-87.range109-152.btcentralplus.com]
has joined #go-nuts
23:33 -!- raylu [raylu@c-24-131-193-106.hsd1.pa.comcast.net] has quit [Read error:
Connection reset by peer]
23:33 -!- raylu [raylu@c-24-131-193-106.hsd1.pa.comcast.net] has joined #go-nuts
23:34 < nsf> having a CPU without virtualization technology sucks..
23:35 < nsf> qemu is like 20 times slower :D
23:36 -!- Scorchin [~Scorchin@host109-152-113-87.range109-152.btcentralplus.com]
has quit [Ping timeout: 245 seconds]
23:49 -!- Scorchin [~Scorchin@host86-135-213-179.range86-135.btcentralplus.com]
has joined #go-nuts
23:50 -!- Scorchin [~Scorchin@host86-135-213-179.range86-135.btcentralplus.com]
has quit [Client Quit]
--- Log closed Thu Dec 09 00:00:37 2010