<yorickpeterse>
It sends it to a queue, which then submits it to Insights
<yorickpeterse>
but the meat is just loop { JSON.dump(Rubinius::Metrics.data) }
<yorickpeterse>
(in a separate thread)
Guest19 has joined #rubinius
<goyox86>
yorickpeterse: Nice GIF :p
jnh has joined #rubinius
<goyox86>
yorickpeterse: If I have 3 RBX processes how can I read stats separately (Lets say I want to make a dashboard, basically a gem that spwna a sinatra app that looks for each RBX process)
<goyox86>
In the past Iwas doing it with the agent which opens a file
<yorickpeterse>
goyox86: for Insights, or RPM?
<goyox86>
a stand alone tool
<yorickpeterse>
oh, well you can just dump it to JSON
<goyox86>
I don't know if explaining well
<yorickpeterse>
or send it to statsd/graphite (support for that is built-in)
<yorickpeterse>
graphite is a nightmare to set up though
<goyox86>
Indeed, (About the JSON dump). But let I have 3 VM running in the machine then I fire up my gem cmooand which starts another VM process. How I do access the metrics of the other 3 VM's running?
<yorickpeterse>
Well, you can't access them from the outside just yet
<yorickpeterse>
So you'd have to dump them somewhere from the process itself
<goyox86>
yorickpeterse: That is what I was thinking.
<yorickpeterse>
So in a process, you could do something like this:
<goyox86>
yorickpeterse: That seems easy for start playing around :)
<yorickpeterse>
Yeah
<yorickpeterse>
The beauty of it is that because we have this thing called "multi-threading" you can really put it anywhere you like :P
<yorickpeterse>
so e.g. you could smack it directly into a database
<yorickpeterse>
mpapis: your particular OpenSUSE problem appears to be gcc once more getting options it doesn't understand. I recall we've had various problems like these in the past where llvm-config adds crap some gcc version doesn't support
<yorickpeterse>
if gcc has some way to list all supported options we could whitelist against that, but other than that I'm not sure how to solve the particular problem
meh` has joined #rubinius
Caius has quit [Ping timeout: 260 seconds]
<mpapis>
yorickpeterse, maybe rbx could prefer clang first and fallback to gcc?
<mpapis>
but still there is error in clang build too
<yorickpeterse>
mpapis: brixen did mention he wanted to just drop gcc support because of reasons like this, though I'm not so sure yet if that's such a good idea
Caius has joined #rubinius
Caius has joined #rubinius
<mpapis>
yorickpeterse, maybe it's a good idea, gcc is also slower in compiling rubinius - so overall experience should improve
mamantoha has quit [Ping timeout: 240 seconds]
jnh has quit [Ping timeout: 255 seconds]
goyox86_ has joined #rubinius
goyox86 has quit [Ping timeout: 265 seconds]
Guest19 has quit [Ping timeout: 245 seconds]
carlosgaldino has joined #rubinius
postmodern has quit [Quit: Leaving]
leehambley has quit [Quit: Leaving...]
goyox86_ has quit [Quit: WeeChat 1.0.1]
josh-k has quit [Remote host closed the connection]
JohnBat26 has quit [Remote host closed the connection]
JohnBat26 has joined #rubinius
benlovell has joined #rubinius
jnh has joined #rubinius
jnh has quit [Ping timeout: 265 seconds]
_elia has joined #rubinius
<cremes>
brixen: so how can the rest of us help with cutting new releases? your write-up mentioned near-constant releases so there should be a 2.3.1
<cremes>
already. also some talk about (almost) every commit to master resulting in a release.
<cremes>
what do you need from the community to make this a reality? is the rbx team going to work out the kinks and
<cremes>
then turn it over to the rest of us? inquiring minds…
<Guest19>
I'm in with cremes here count on me
Guest19 is now known as goyox86
<goyox86>
I'm in with cremes here count on me
<yorickpeterse>
cremes: right now the only blocker I believe are the JIT interrupts
<yorickpeterse>
which are being worked on
<cremes>
yorickpeterse: coolio. do you have the inside scoop on the faster release cycle? any details to add?
<yorickpeterse>
Nope, sadly not
<cremes>
ok
<cremes>
i’m curious how that is going to be practical with travis-ci. if people want to test against rubinius, then the travis folks would need to make all of these releases/nightlies available.
<cremes>
they may not go for it
<yorickpeterse>
They don't have to follow directly, they can update whenever they want
<brixen>
cremes: releases have some requirements that may not allow them to be generally done by anyone
<brixen>
eg signing binaries
<brixen>
but anyone can fix issues so that releases are ready to go
<yorickpeterse>
"Binary signed by: Totally brixen <yorickpeterse@gmail.com>"
mamantoha has quit [Ping timeout: 245 seconds]
jnh has joined #rubinius
benlovell has quit [Ping timeout: 264 seconds]
jnh has quit [Ping timeout: 240 seconds]
|jemc| has joined #rubinius
<yorickpeterse>
brixen: in all seriousness, we might want to set up things for multiple signers at some point. That way if you get hit by a bus we can still release things
<yorickpeterse>
(yes yes I know that sounds rather morbid :P)
<Rotonen>
for that to be convenient (a new contributor not requiring an in-person visit somewhere which stays offline for all eternity to come), you will need quite the intermediary cert setup
<yorickpeterse>
Rotonen: what I meant was that multiple people could sign/release things, that's not too difficult with GPG
<yorickpeterse>
also bbl, meetup/social things
amsi has joined #rubinius
<Rotonen>
ah well if you go for a multi-trusted-root setup and place the trust in each and every contributor individually, sure
slaught has joined #rubinius
slaught has quit [Quit: slaught]
_elia has quit [Quit: Computer has gone to sleep.]
noop has joined #rubinius
josh-k has quit [Remote host closed the connection]
jnh has joined #rubinius
jnh has quit [Ping timeout: 264 seconds]
Guest19 has joined #rubinius
josh-k has joined #rubinius
goyox86 has quit [Ping timeout: 264 seconds]
Guest19 has quit [Ping timeout: 256 seconds]
postmodern has joined #rubinius
arrubin has joined #rubinius
mattgreenrocks has joined #rubinius
postmodern has quit [Quit: Leaving]
postmodern has joined #rubinius
mattgreenrocks has quit [Quit: mattgreenrocks]
mattgreenrocks has joined #rubinius
mattgreenrocks has quit [Client Quit]
mattgreenrocks has joined #rubinius
noop has quit [Ping timeout: 255 seconds]
tenderlove has joined #rubinius
yipstar has joined #rubinius
tenderlove has quit [Remote host closed the connection]
jnh has joined #rubinius
jnh_ has joined #rubinius
jnh has quit [Read error: Connection reset by peer]
<yorickpeterse>
hngngngn profiling racc
<yorickpeterse>
is hard stuff
<yorickpeterse>
So annoying that any profiling solution, besides a sampling profiler, slows down things to a crawl
<yxhuvud>
any conclusions? have you found any part slower than it should be?
<headius>
yorickpeterse: I'd strongly recommend allocation tracing as first line of attack
<headius>
it's almost certainly the main issue
<headius>
we may not be able to fix excessive allocation in racc easily, but we may be able to fix it in your stuff
jnh_ has quit [Remote host closed the connection]
elia has joined #rubinius
tenderlove has joined #rubinius
tenderlove has quit [Remote host closed the connection]
<yorickpeterse>
headius: I'd be surprised if allocations add 3 seconds to the runtime (on top of the lexer)