<|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
<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 :)
<|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>
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
<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
<|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:/