[spoiler] has joined #rubinius
<|jemc|> brixen: you should be able to run the command shown in the README (without even cloning the repo)
<|jemc|> back in a bit
Bwild has joined #rubinius
josh-k has joined #rubinius
josh-k_ has quit [Ping timeout: 258 seconds]
josh-k_ has joined #rubinius
josh-k has quit [Ping timeout: 245 seconds]
josh-k has joined #rubinius
josh-k_ has quit [Ping timeout: 245 seconds]
<brixen> |jemc|: saweeet!
omninonsense has joined #rubinius
[spoiler] has quit [Ping timeout: 240 seconds]
diegoviola has quit [Quit: WeeChat 1.0.1]
omninonsense is now known as [spoiler]
<brixen> |jemc|: added service hooks for both influxdb-grafana and rubinius repos
diegoviola has joined #rubinius
<|jemc|> brixen: Now I'm wondering if the name is obvious enough - maybe something like rubinius/metrics-dashboard would be a bit more obvious/descriptive?
<|jemc|> especially because after dealing with influxdb/grafana I have no desire to go back to ugly, clunky graphite :)
<brixen> heh, I can understand that
<brixen> I think metrics-dashboard is way too general though
<|jemc|> well, it's up to you - just thought I'd bring it up
<brixen> yeah, it's something to consider
<|jemc|> I'll just focus on adding to the README and writing up a short blog post
<brixen> awesome
<brixen> we can iterate
<brixen> the name is specific enough now not to clash with other things as we refine it
<|jemc|> also, I copied goyox86's dashboard settings directly but it may be worth putting some more time into organizing/sprucing up the dashboard layout
<brixen> certainly
<|jemc|> of course, users can always rearrange and export/import their own settings
<brixen> yeah, would be a good start to outline how one does that
<|jemc|> yeah, was going to include that in the README
<brixen> the metrics themselves are going to evolve a bit
<brixen> and I plan to simplify the GC quite a bit so those will ultimately be easier to consume
<brixen> the raw metrics themselves also are not that interesting
<brixen> I've got some sketches I'll play with once you finish up the container
<|jemc|> k
<|jemc|> the container should be pretty much ready for you to tweak what you want to tweak
<|jemc|> I was just going to make sure automated builds get going and then document
<|jemc|> you're now an owner on the dockerhub organization
<|jemc|> weird, the automated repo ended up under jemc instead of rubinius
<|jemc|> fixing...
<brixen> ok
<brixen> thanks
<|jemc|> automated build should be in place now
josh-k_ has joined #rubinius
josh-k has quit [Ping timeout: 255 seconds]
pd_ has joined #rubinius
pd has quit [Ping timeout: 240 seconds]
pd_ is now known as pd
pd has joined #rubinius
pd has quit [Changing host]
blowmage has quit [Ping timeout: 240 seconds]
blowmage has joined #rubinius
meh`_ has quit [Ping timeout: 264 seconds]
diegoviola has quit [Read error: Connection reset by peer]
diegoviola has joined #rubinius
diegoviola has quit [Client Quit]
diegoviola has joined #rubinius
havenwood has quit [Remote host closed the connection]
<brixen> Your branch is ahead of 'origin/1.8.7' by 1493 commits.
<brixen> I hope this doesn't break anything...
<brixen> I ran the specs twice
GitHub78 has joined #rubinius
<GitHub78> [rubinius] brixen pushed 16 new commits to 1.8.7: http://git.io/Bgtm2w
<GitHub78> rubinius/1.8.7 071db22 Brian Shirai: Updated kernel to master.
<GitHub78> rubinius/1.8.7 f5dc2f8 Brian Shirai: Updated vm/builtin to master.
<GitHub78> rubinius/1.8.7 7dc782e Brian Shirai: Updated vm/llvm to master.
GitHub78 has left #rubinius [#rubinius]
bennyklo1z has joined #rubinius
lbianc_ has joined #rubinius
pd_ has joined #rubinius
pd has quit [*.net *.split]
lbianc has quit [*.net *.split]
bennyklotz has quit [*.net *.split]
andrewstewart has quit [*.net *.split]
sbryant has quit [*.net *.split]
cpuguy83 has quit [*.net *.split]
mrb_bk has quit [*.net *.split]
Y_Ichiro has quit [*.net *.split]
alexsuraci has quit [*.net *.split]
cezarsa has quit [*.net *.split]
yipdw has quit [*.net *.split]
jc00ke has quit [*.net *.split]
[spoiler] has quit [*.net *.split]
|jemc| has quit [*.net *.split]
cremes has quit [*.net *.split]
gtemple has quit [*.net *.split]
evan has quit [*.net *.split]
yorickpeterse has quit [*.net *.split]
Spakman has quit [*.net *.split]
pd_ is now known as pd
pd has joined #rubinius
pd has quit [Changing host]
travis-ci has joined #rubinius
<travis-ci> rubinius/rubinius/1.8.7 (f66ff69 - Brian Shirai): The build was broken.
travis-ci has left #rubinius [#rubinius]
<brixen> gotta love gcc
<brixen> gcc compiles the same file on master without error?
<brixen> oh yeah, -Wno-unused-result
<brixen> which some other version of gcc chokes on
<brixen> fuck me
[spoiler] has joined #rubinius
cremes has joined #rubinius
gtemple has joined #rubinius
evan has joined #rubinius
Spakman has joined #rubinius
yorickpeterse has joined #rubinius
jc00ke has joined #rubinius
alexsuraci has joined #rubinius
sbryant has joined #rubinius
cezarsa has joined #rubinius
cpuguy83 has joined #rubinius
yipdw has joined #rubinius
andrewstewart has joined #rubinius
mrb_bk has joined #rubinius
Y_Ichiro has joined #rubinius
havenwood has joined #rubinius
GitHub90 has joined #rubinius
<GitHub90> [rubinius] brixen pushed 1 new commit to 1.8.7: http://git.io/bkVKvg
<GitHub90> rubinius/1.8.7 cc10d86 Brian Shirai: Substitute for the missing -Wstfu-gcc switch.
GitHub90 has left #rubinius [#rubinius]
andrewstewart has quit [*.net *.split]
sbryant has quit [*.net *.split]
cpuguy83 has quit [*.net *.split]
mrb_bk has quit [*.net *.split]
Y_Ichiro has quit [*.net *.split]
alexsuraci has quit [*.net *.split]
cezarsa has quit [*.net *.split]
yipdw has quit [*.net *.split]
jc00ke has quit [*.net *.split]
sbryant has joined #rubinius
cezarsa has joined #rubinius
yipdw has joined #rubinius
Y_Ichiro has joined #rubinius
cpuguy83 has joined #rubinius
andrewstewart has joined #rubinius
jc00ke has joined #rubinius
alexsuraci has joined #rubinius
mrb_bk has joined #rubinius
travis-ci has joined #rubinius
<travis-ci> rubinius/rubinius/1.8.7 (cc10d86 - Brian Shirai): The build was fixed.
travis-ci has left #rubinius [#rubinius]
josh-k_ has quit [Remote host closed the connection]
havenwood has quit []
havenwood has joined #rubinius
saline has quit [Remote host closed the connection]
saline has joined #rubinius
diegoviola has quit [Quit: WeeChat 1.0.1]
djellemah_ has joined #rubinius
parndt has joined #rubinius
parndt has quit [Ping timeout: 258 seconds]
josh-k has joined #rubinius
josh-k_ has joined #rubinius
max96at|off is now known as max96at
josh-k has quit [Ping timeout: 258 seconds]
havenwood has quit []
dzhulk has joined #rubinius
lucasmartins has joined #rubinius
lucasmartins has left #rubinius [#rubinius]
lucasmartins has joined #rubinius
<yorickpeterse> CAPI (vect): 49040.8 i/s
<yorickpeterse> CAPI: 44542.8 i/s - 1.10x slower
<yorickpeterse> Racc: 41555.1 i/s - 1.18x slower
<yorickpeterse> Ruby: 35329.1 i/s - 1.39x slower
<yorickpeterse> :D
<yorickpeterse> although 1,2 still isn't the hoped 2x/3x
<lucasmartins> who's the guy on the twitter handle @rubinius?
dzhulk has quit [Quit: Leaving.]
dzhulk has joined #rubinius
<yorickpeterse> that be brixen
<yorickpeterse> He's probably still asleep though
josh-k_ has quit [Remote host closed the connection]
<lucasmartins> yorickpeterse: thanks
meh` has joined #rubinius
<yorickpeterse> I think I wrote more C this weekend than I have done in the past month
<yorickpeterse> and so far it seems impossible to cross the 1,5x faster mark (of my code vs Racc) :<
carlosgaldino has joined #rubinius
<brixen> lucasmartins: howdy
<lucasmartins> brixen: ahoy
<lucasmartins> I'm @nevemartins
<brixen> I was guessing :)
<brixen> good to chat with you
<brixen> happy to hear more about how rbx is working for you
<brixen> btw, are you using the statsd output by chance?
<brixen> I'd love to see your graphs
<brixen> |jemc| just put this together yesterday https://github.com/rubinius/influxdb-grafana/
<brixen> in case you need something like that
<lucasmartins> I'm building a platform and we're about to scale up users, so I started some perf improvements
<brixen> cool
<lucasmartins> we're still on heroku and have no metrics for the live system yet
<brixen> is it heavy API or more traditional server-side html?
<lucasmartins> since it didn't make any sense while we have no external users
<lucasmartins> API
<brixen> ok
<lucasmartins> it's mainly a system to process PDF files (already converted to txt with s3_pdf2txt)
<brixen> part of my reason for adding the statsd stuff is to help diagnose problems when we can't see your code
<brixen> oh cool
<lucasmartins> we extract data from invoices
<brixen> neat
<lucasmartins> and build a big database with so we can extract value from it
<lucasmartins> so lots of rejects and String IO
<lucasmartins> regex*
<brixen> perhaps I'll allow myself to dream of a future where I don't have to fax expense reports :)
<lucasmartins> you mean for you employer?
<brixen> yeah
<lucasmartins> this is actually a product we want to expando to the US
<lucasmartins> it takes care of your bills for you
<brixen> ah sounds cool
<lucasmartins> in the sense you get the most value from what you pay
<lucasmartins> it works nice for cellphone bills
<brixen> interesting, it analyzes the plans based on your bill?
<lucasmartins> yep
<brixen> very cool
<lucasmartins> check wrongdoing from the carrier
<lucasmartins> and optimises your plans to your usage profile
<brixen> can't expect the carrier to do that ethically
<brixen> sounds great
<brixen> when do you launch in the US? ;)
<lucasmartins> yeah, everybody get anxious about it when we explain it
<lucasmartins> I'm hoping next year
<lucasmartins> but it depends more on the carriers
<lucasmartins> we could do it till next christmas
<lucasmartins> I mean 2015
<brixen> ok
<lucasmartins> but right now we'll have high load for the local market already
<lucasmartins> our goal is to process all phone calls from the country
<brixen> I think the NSA is already doing that :p
<lucasmartins> yeah, but they suck at it...
<lucasmartins> XP
<brixen> haha
<brixen> good answer
<brixen> nothing like a gov monopoly to totally suck at quality
<lucasmartins> I'll gather some metrics, it may be useful for somebody else
<brixen> ok coo
<brixen> er cool
<brixen> feel free to ping me (brixen at gmail) any time
<lucasmartins> sure
<brixen> I have a few cool things in the pipeline that will help String related processing
<lucasmartins> <3
<brixen> did you see the rbx 3.0 blog posts?
<lucasmartins> nope
<lucasmartins> checking out...
carlosgaldino has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<chrisseaton> brixen: I'm looking forward to the string parsing instructions - I think informing the JIT about parsing is a good way ahead to speed up 'real' applications that do things like processing HTTP headers etc
<brixen> parts 3-5 are the most technical
<brixen> chrisseaton: yep
<lucasmartins> oh, I have read part I & II long ago, totally forgot about it
<brixen> lucasmartins: anyway, please do let me know how things are going
<lucasmartins> brixen: :thumbsup:
<brixen> lucasmartins: btw, have you hit any issues with psych on heroku?
<brixen> heroku doesn't install libyaml unless they see psych in your Gemfile
<brixen> which is a total PITA, since psych is needed to install gems and psych is a gem
<lucasmartins> brixen: I'm yet to deploy the new codebase (using rbi) to Heroku
<brixen> ok
<lucasmartins> I'm considering leaving Heroku BTW
<brixen> I'm redoing the vendoring of libyaml now so we can use psych to bootstrap on heroku, too
<lucasmartins> it is too painful to use rbx there
<brixen> really?
<brixen> which part?
<brixen> I build the binaries for them
<brixen> and test heroku on every release
<lucasmartins> hang on, I'll get a log file of my last deploy
<brixen> ok cool
<lucasmartins> btw, I don't mean the runtime is the problem, rbx install fine but bundle install always give me headaches
<brixen> ok
<brixen> one thing that I'm not sure about is why it still uses bundler 1.6.3 to bundle
<brixen> I should ping terrence about that
<lucasmartins> scratch the Heroku problem, I just tried again and it worked
<lucasmartins> weeeird...
<brixen> we include the latest bundler in every release as a pre-installed gem
<brixen> hm, ok
<brixen> could I see the error anyway?
<brixen> it could be the threading error in rubygems or the autoload bug fixed in 2.4.1
<lucasmartins> couldn't find it, that's why I retried the deploy
<brixen> ah ok, no worries
<brixen> if you see it recur, let me know
|jemc| has joined #rubinius
<lucasmartins> I remember pthread log lines...
<brixen> ahh, hm
<lucasmartins> I was trying to find out how to run bundle single-threaded
<brixen> --jobs=1
<lucasmartins> because I was suspicious it was related to the --jobs=4 thing
<brixen> but not sure you can affect that
<brixen> at least, I don't know where it gets the bundler command line it runs
Bwild has quit [Quit: leaving]
elia has joined #rubinius
enebo has joined #rubinius
[spoiler] has quit [Read error: Connection reset by peer]
djellemah has joined #rubinius
djellemah__ has joined #rubinius
djellemah__ has quit [Client Quit]
<|jemc|> ugh, so many regressions from qt 5.3 to 5.4 - so much for semantic versioning
* |jemc| shakes his fist at the idea that a strictly structured development process leads to a well-structured product
<brixen> |jemc|: honestly, barely a fan of semantic versioning
<brixen> nearly 30 yrs of dealing with versions and no discipline actually solves much
<brixen> release small enough deltas and fixes become orders of magnitude simpler
<brixen> every attempt to make a single component reliable will ultimately, and utterly, fail
<brixen> reliability is in the system
<brixen> basically, comes to this: semantic versioning will fail; what do you do then?
<|jemc|> I mainly blame myself for not making the time to check for these regressions in the release candidates over the past few months
<|jemc|> now the release has happened this past week and I've got a lot of issue tickets to write >_<
<brixen> well, as a maintainer, I'll happily pile the blame on you as well :)
<brixen> but it's not your fault, sorry
<brixen> this. happens. every. time.
<brixen> release candidates are bullshit
<brixen> |jemc|: check this out sometime https://www.youtube.com/watch?v=PGLYEDpNu60
<|jemc|> brixen: I suppose my optimism gets the better of me :)
<brixen> this I understand
<brixen> or I definitely wouldn't have been working on rbx this long :)
<brixen> interesting time though, I've got people trying recruit me to build stuff for MRI that I'm already building in rbx
<|jemc|> heh
<|jemc|> the Rasmussen's system model he's talking about here is a nice way to think about it
<brixen> indeed
<|jemc|> especially nice to get this in my head while much of what I'm working on is still in the R&D phase and nto being actively deployed yet
<brixen> nice
<brixen> should probably start a support group for every engineer who believed, "if I work hard enough, I can make my little component reliable enough"
<brixen> man, cannot get libyaml to build with configure args as expected
<brixen> I think this is where I gave up and threw it against the wall last time
havenwood has joined #rubinius
elia has quit [Quit: Computer has gone to sleep.]
enebo has quit [Quit: enebo]
djellemah_ has quit [Quit: Leaving]
johnmuhl has joined #rubinius
<yorickpeterse> Hmpf, it seems I've simply hit the limits of Ruby in my parsing adventures
<yorickpeterse> My stuff is 1,35x faster than Racc, but I can't seem to get it to be any better
<yorickpeterse> and 1,35x isn't going to help a lot when that only saves 100-200 ms
<yorickpeterse> (out of 3,5 seconds)
<|jemc|> yorickpeterse: this is still testing with the json grammar and not the XML grammar?
<yorickpeterse> Yes
<yorickpeterse> I basically now have 3 C implementations: 1 using the Ruby CAPI, 1 using a mix of the CAPI with some vector library I yanked off the web, and one using said vector library + a bunch of C arrays (to remove Array#[] calls)
<yorickpeterse> The latter is 1,35x faster than racc
<yorickpeterse> The other two are also faster, though a bit less
<yorickpeterse> lemme gist this winter wonder
<yorickpeterse> ll_driver_parse3 is the fastest one
<|jemc|> seems like using the XML grammar instead of the json one may give you different, possibly more favorable performance ratios
<yorickpeterse> something something I wish resizing arrays in C wasn't such a fucking pain
<yorickpeterse> Most likely the ratio will be similar
<yorickpeterse> I certainly don't expect it to perform widely better with that grammar
<yorickpeterse> s/widely/way
diegoviola has joined #rubinius
<|jemc|> well, it certainly matters a great deal with PEG, but I'm not well-versed on LL, so it might well not matter much with LL
<yorickpeterse> In theory it would be faster if the state/goto tables were in pure C, but that means I'd have to generate C _and_ Ruby files, instead of just Ruby files
<|jemc|> and don't forget Java ;)
<yorickpeterse> or if I could somehow cache the C structures in the parser class
<yorickpeterse> Yeah Java is going to be fun as well
GitHub197 has joined #rubinius
<GitHub197> [rubinius] brixen pushed 3 new commits to master: http://git.io/OpfRZw
<GitHub197> rubinius/master b209e38 Brian Shirai: Fixed building with gcc 4.6.3. Fixes #3235.
<GitHub197> rubinius/master 8798016 Brian Shirai: Vendored libyaml 0.1.5 (again).
<GitHub197> rubinius/master d7b4a3a Brian Shirai: Added configure options for vendored libyaml.
GitHub197 has left #rubinius [#rubinius]
<brixen> now to try to re-bootstrap with psych on heroku
<yorickpeterse> |jemc|: a few fun things that this did teach me: loop { ... } is slow as shit
<yorickpeterse> and manually inlining methods in MRI makes a pretty big difference too
GitHub52 has joined #rubinius
<GitHub52> [rubinius] brixen pushed 1 new commit to master: http://git.io/j-BXYQ
<GitHub52> rubinius/master 39f25b9 Brian Shirai: Use bundler 1.7.9.
GitHub52 has left #rubinius [#rubinius]
<chrisseaton> yorickpeterse: is loop { ... } just slow in MRI or Rbx and JRuby as well? I would have though it would be the same as while in the JIT.
<yorickpeterse> chrisseaton: I've only tested it in MRI so far
lucasmartins has quit [Quit: lucasmartins]
<brixen> yorickpeterse: you can save yourself a bunch of that manual work if you just implement a JIT for MRI first
<|jemc|> lol
<yorickpeterse> brixen: I heard somebody is already working on that :P
<brixen> yorickpeterse: I'm confident it will be as high quality as the garbage collector ;)
<|jemc|> yorickpeterse: yeah, myco doesn't have any flow control other than && and || at the moment, so I have no while and have to use loop { } at the moment, which isn't ideal
<chrisseaton> The JIT was mentioned in Matz's keynote - I think he has a really good goal here actually - he's looking for 2x, so not the best JIT in the world, just a decent one that improves MRI a bit. So maybe that's achievable with a simple template compiler.
<yorickpeterse> Funny enough, on Rbx my pure Ruby code is basically as fast as Racc
<yorickpeterse> Although my C hacks are about 1,6x faster
* yorickpeterse goes to play with unlikely()/likely()
<|jemc|> when I add while and other "builtin" flow control they will be macro AST "plugins" that can be removed or altered later
amclain has joined #rubinius
<brixen> based on my local build, I'd expect CI to pass with the yaml stuff
<brixen> but hey, there's gcc and Travis in the mix, so who knows
<brixen> gotta run though
<brixen> will hopefully get 2.4.2 with bootstrapped psych out tonight or tomorrow
<yorickpeterse> I always forget which one was the new one
<yorickpeterse> Although judging from the remarks I guess psych is the one using libyaml :P
<yorickpeterse> hm, using likely/unlikely (as per Linux kernel) seem to only make a tiny difference
travis-ci has joined #rubinius
<travis-ci> rubinius/rubinius/master (d7b4a3a - Brian Shirai): http://travis-ci.org/rubinius/rubinius/builds/44013916: The build has errored.
travis-ci has left #rubinius [#rubinius]
<yorickpeterse> hihi, apt timeouts
<yorickpeterse> I'll restart it
<yorickpeterse> heh, judging from the profiler output (MRI
<yorickpeterse> * MRI's profiler) it seems my actual callback code is currently the bottleneck
travis-ci has joined #rubinius
<travis-ci> rubinius/rubinius/master (d7b4a3a - Brian Shirai): http://travis-ci.org/rubinius/rubinius/builds/44013916: The build has errored.
travis-ci has left #rubinius [#rubinius]
<yorickpeterse> Although changing that doesn't really help optimize the parser itself
<|jemc|> yorickpeterse: here's an idea that may help with big parses + multithreading
<yorickpeterse> |jemc|: impossible
<yorickpeterse> parsers keep track of an internal state, you can't multi-thread that without locking
<yorickpeterse> and the locking/unlocking overhead would most likely nullify the benefits
<|jemc|> hear me out; instead of building the AST in your callbacks, record indices and AST types
<|jemc|> (as symbols)
<|jemc|> then, in a separate step, do what the callbacks would have done
<|jemc|> (which can be multithreaded safely, if you do it right)
<yorickpeterse> Well, callbacks can depend on other callbacks, which would require it to be sequential
<yorickpeterse> You might be able to gain something if the callbacks take seconds, but otherwise the difficulty of implementing it outweights the benefits
<|jemc|> ideally, you'd be able to split it up into separate dependent trees
<|jemc|> *independent
<|jemc|> for example, if you have a root node with four trees of nodes inside, you could use a thread for each of those trees then join at the end
travis-ci has joined #rubinius
travis-ci has left #rubinius [#rubinius]
<travis-ci> rubinius/rubinius/master (39f25b9 - Brian Shirai): http://travis-ci.org/rubinius/rubinius/builds/44014265: The build has errored.
<yorickpeterse> darn travis
<|jemc|> for a simpler-to-implement approach that still might help a bit, you could try two concurrent steps of parsing and building if your parser runs in a single thread and dumps those indices and types in a Queue as it goes and the builder runs in a single thread at the same time and consumes from the Queue
<|jemc|> or, using a Rubinius::Channel on rbx might(?) be speedier than using Queue
<|jemc|> just a thought
<|jemc|> the main idea being, there's no reason your callbacks have to happen in-line with parsing if it helps to push them out-of-line
<yorickpeterse> right, time for some Satriani and food to clear my head up
elia has joined #rubinius
elia has quit [Quit: Computer has gone to sleep.]
<johnmuhl> could anyone weigh in on https://github.com/terlar/fry/issues/32 - specifically should rbx/bin or rbx/gems/bin be first in PATH or does it even matter?
<yorickpeterse> rbx/VERSION/bin should be first I believe
<yorickpeterse> At least that's the case with chruby:
<yorickpeterse> Snippet of my PATH: /home/yorickpeterse/.gem/rbx/2.1.0/bin:/home/yorickpeterse/.rubies/rbx-git/gems/bin:/home/yorickpeterse/.rubies/rbx-git/bin:/
enebo has joined #rubinius
dzhulk has quit [Quit: Leaving.]
<johnmuhl> thanks
parndt has joined #rubinius
parndt has quit [Ping timeout: 245 seconds]
parndt has joined #rubinius
parndt has quit [Client Quit]
max96at is now known as max96at|off
dzhulk has joined #rubinius
enebo has quit [Quit: enebo]
enebo has joined #rubinius
enebo has quit [Client Quit]
havenwood has quit [Ping timeout: 250 seconds]
josh-k_ has joined #rubinius
elia has joined #rubinius
havenwood has joined #rubinius
[spoiler] has joined #rubinius
omninonsense has joined #rubinius
elia has quit [Quit: Computer has gone to sleep.]
meh` has quit [Ping timeout: 260 seconds]
meh` has joined #rubinius
[spoiler] has quit [Ping timeout: 255 seconds]
dimday has joined #rubinius
dimday has left #rubinius [#rubinius]
havenn has joined #rubinius
havenwood has quit [Ping timeout: 250 seconds]
[spoiler] has joined #rubinius
josh-k has joined #rubinius
omninonsense has quit [Ping timeout: 258 seconds]
josh-k_ has quit [Ping timeout: 265 seconds]