gistfile1.txt

2014-12-05 03:45 brixen changed the topic of #rubinius to: 2.4.1 - http://releases.rubini.us/rubinius-2.4.1.tar.bz2 : logs - http://irclog.whitequark.org/rubinius
00:48 <GitHub192> [rubinius] brixen pushed 4 new commits to master: http://git.io/s-7dMw
00:48 <GitHub192> rubinius/master 5c61993 Brian Shirai: Revert "Removed most rubinius:bug calls from JIT."...
00:48 <GitHub192> rubinius/master b6016f4 Brian Shirai: Reworked handling JIT failures....
00:48 <GitHub192> rubinius/master 1d34aa5 Brian Shirai: Added spawn specs for STD{IN, OUT, ERR}.
01:08 <travis-ci> rubinius/rubinius/master (b0134e8 - Brian Shirai): http://travis-ci.org/rubinius/rubinius/builds/44891148: The build passed.
06:40 <|jemc|> yopp: the error you see when trying to start the docker container means that it can't bind to port 80 because something else already is bound to it (which could be one of the other parts of your app, or it could be a dead version of the docker container that is persisting around - check the output of `docker ps -a` to see what containers are still "around")
06:42 <|jemc|> you can also modify the command given in the README to use a port other than port 80, or leave off the port assignment entirely and use `docker inspect <container id>` to see what arbitrary port docker gave it
06:46 <|jemc|> goyox86, brixen, jc00ke: regarding the docker container and blog post - I'm not entirely happy with the influxdb/grafana solution - goyox86, weren't you looking into a server-side graphing solution that would help us to avoid some of the problems with the fact that the grafana graphig/querying runs client-side? If we can come up with a cleaner solution, I'd like to promote that instead
09:26 <yorickpeterse> morning
12:10 <yopp> |jemc-bot|, yeah, I've already found out that it's listening on boot2docker ip, not on localhos
12:13 <goyox86> Morning!
15:03 max96at|off is now known as max96at
15:53 <brixen> the keyword argument parsing is total sweetness
15:53 <brixen> MRI 2.1.5 still fails a keyword spec
15:53 <brixen> despite opening several issues related to keyword parsing
15:53 <yorickpeterse> but if MRI fails that means it's a feature
15:54 <brixen> pretty obvious MRI is never going to consider or contribute to rubyspec
15:54 <brixen> which means there's no point wasting time maintaining it as a separate project
15:54 <yorickpeterse> brixen: I'd disagree
15:54 <yorickpeterse> There's opal, jruby, topaz in the past, etc
15:55 <chrisseaton> brixen: we really appreciate having RubySpec as a project we can use - it's invaluable to us
15:55 <brixen> they don't contribute to it either
15:55 <brixen> whether or not it's invaluable to some other project does not make it valuable to rubinius
15:55 <chrisseaton> brixen: that's simply not true - I've got open PRs, and eregon has contributed work as well
15:55 <brixen> a few PRs is not contributing
15:55 <yorickpeterse> wat
15:56 <yorickpeterse> I normally don't disagree, but that's a bit shortsighted
15:56 <brixen> I don't think it is
15:56 <brixen> I've been working on this a very long time
15:56 <yorickpeterse> I'd argue that the primary reason more Rbx people work on it (today) is due to us having more control
15:56 <brixen> I've wasted an enormous amount of time and effort on it
15:56 <yorickpeterse> That is, we typically sync things, etc
15:56 <brixen> that's not true
15:57 <chrisseaton> I even reformatted and contributed the bibliography I put together for RubySpec because you suggested it
15:57 <brixen> chrisseaton: yep, that was nice
15:57 <brixen> if this was money though, it would be very simple
15:58 <brixen> "I have you $5"
15:58 <brixen> cool, it costs 2000 to keep the lights on
15:58 <chrisseaton> brixen: if you need some help maintaining RubySpec, suggest some tasks for us to help with
15:58 <chrisseaton> brixen: I can't promise anything radical but I'll lend a hand
15:58 <brixen> write specs
15:58 <brixen> it's that simple
15:58 <brixen> there's a ton of MRI behavior that no one writes specs for
15:59 <brixen> despite implementing it
15:59 <yorickpeterse> brixen: that's like saying "just fix the world", I'd start with cleaning up the existing issues where possible
15:59 <brixen> and write specs in way that conforms to the standards I set
15:59 <chrisseaton> brixen: I actually opened a PR just yesterday that fixed a spec so it conforms to your standards
15:59 <brixen> the existence of a project doesn't give you some magical entitlement to it
16:00 <brixen> gotta do a call, bbl...
16:00 <yorickpeterse> chrisseaton: right now one of the bigger issues (besides kwargs) is https://github.com/rubyspec/rubyspec/issues/286
16:01 <yorickpeterse> and at some point I want specs for the entire CAPI, but that's _a lot_ of work
16:01 <yorickpeterse> I at some point toyed with the idea of a tool that converts MRI's test-unit tests into rubyspec, but it would be an equal amount of work to get that going compared to just doing things by hand
16:02 <chrisseaton> brixen: I can't imagine at all where you're getting 'entitlement' from - I said I love your work and if you need more help maintaining it let me know - but I've already got open PRs that conform to your standards
16:02 <brixen> chrisseaton: you're extremely new to this
16:02 <brixen> you have a few PRs
16:02 <brixen> that's nice
16:03 <brixen> again, put that in monetary terms and see what you come up with
16:03 <yorickpeterse> chrisseaton: heh, I completely forgot about that PR
16:03 <brixen> I have decisions to make about what benefits Rubinius
16:03 <brixen> the biggest waste of time for us is keeping track of MRI crap
16:04 <brixen> MRI has had almost 8 years to get on the ball using rubyspec
16:04 <brixen> they aren't, it's extremely unlikely they will and I'm not wasting more time with them
16:04 <yorickpeterse> brixen: unrelated, we have those fucking bundler Git issues on Rubyspec, I believe that could be fixed by adding a Gemfile.lock, any objections against that?
16:04 <yorickpeterse> brixen: I messed with that on a branch at some point, but for some reason never merged it
16:11 <enebo> brixen: I agree you should do what you want with rubyspec, but you keep saying other projects never helped and it is flat out weird. nurse #5 contrib commitwise, mame #12, ujihisa #13, yugui #17, akr #22. I think they stopped largely because you keep saying they don’t contribute
16:12 <enebo> (I omitted drbrain #20 because he used to work on rbx full time)
16:25 <enebo> whoops missed kachick at #8
16:33 max96at is now known as max96at|off
16:45 max96at|off is now known as max96at
16:53 <yorickpeterse> chrisseaton: another thing that would help: jruby 9k claims to have (almost) full 2.2 compatibility, rubyspecs for that would be tremendously useful
16:56 <chrisseaton> yorickpeterse: good idea - I don't know anything about how they've tested the 2.2 stuff personally though
17:05 <brixen> enebo: number of commits is meaningless
17:05 <brixen> enebo: go sum # of lines of current specs by contributor
17:05 <brixen> I've had to fix a ton of crap committed by many people
17:09 <brixen> enebo: also, a disconnect between your perception and reality is not "flat out weird"
17:09 <brixen> ad hominem much
17:09 <enebo> brixen: hahahahga
17:10 <enebo> brixen: well you have zero interest in acknowledging that contributions are contributions and you say I cannot use weird?
17:10 <enebo> brixen: like I said you can you do what you want I just wanted to point out the fallacy of your statement.
17:11 <brixen> did you go sum # of current lines by contributor?
17:11 <brixen> I pointed out the flaw in your supporting evidence
17:11 <brixen> you tell me I'm wrong
17:12 <brixen> but you don't actually follow the argument or look at the evidence
17:12 <enebo> brixen: My only burden was to show that MRI have active contributors by a common metric (commits). I really feel I only have the burden of not-zero
17:12 <brixen> also, "you have zero interest in acknowledging that contributions are contributions..." is ad hominem
17:12 <brixen> don't impute my interest or motivations
17:13 <enebo> heh
17:13 <tenderlove> a few PRs isn't contributing, and number of commits doesn't seem to matter. I guess you can't win.
17:13 <enebo> tenderlove: no one wins against brixen
17:13 <brixen> put it in monetary terms and make your argument
17:13 <brixen> there are ~20,000 specs
17:13 <tenderlove> brixen: what is the criteria to be considered "a contributor"
17:13 <brixen> a PR that changes one is 1/20,000
17:14 <brixen> tenderlove: what would you define it to be?
17:14 <tenderlove> brixen: doesn't matter what I think. *you* define the rules for this project, obviously
17:15 <brixen> enebo: again, stop with the ad hominem or leave
17:15 <brixen> tenderlove: why are you in this discussion?
17:15 <tenderlove> I'm on the MRI team, I want to know
17:15 <brixen> you want to know what?
17:15 <brixen> what is your question?
17:15 <tenderlove> brixen: what is the criteria to be considered "a contributor"?
17:16 <brixen> ok
17:16 <brixen> if you actually want to have this discussion, I have some questions
17:16 <brixen> do you actually want to, or are you trolling?
17:16 <tenderlove> ya, I actually want to know
17:16 <brixen> ok, cool
17:17 <brixen> so, what is the value of defining the term "a contributor"?
17:18 <tenderlove> idk, you're the one using the word
17:18 <brixen> no, I said contribute
17:18 <chrisseaton> you said MRI and JRuby don't contribute - I don't believe that's true
17:18 <chrisseaton> but I'm open to being convinced otherwise
17:18 <brixen> since yugui said, MRI 1.9.2 won't ship until it passes rubyspec, MRI devs have contributed very very little, or not at all
17:19 <yopp> yay, rubyspec fight!1
17:19 <brixen> chrisseaton: go look at the commits in the past 2 years
17:19 <brixen> a useful metric for contributor impact is not # of commits
17:19 <brixen> it's # of current lines in the project
17:19 <chrisseaton> would you at least agree it's hyperbole? that you meant they don't contribute as much as you think they should
17:19 <brixen> part of the problem with rubyspec quality is letting people commit without adequate review
17:19 <brixen> that costs the project a lot
17:20 <brixen> tenderlove: are we discussing this or not?
17:20 <tenderlove> my attention span is way too short for socratic dialogue
17:20 <tenderlove> just tell me what we should be shooting for
17:20 <brixen> I want to understand your opinion?
17:20 <brixen> that's not valid?
17:21 <tenderlove> my opinions don't matter. *you* define what are considered useful contributions to your project.
17:21 <brixen> has MRI spec'd any features since 1.9.2?
17:22 <tenderlove> ¯\_(ツ)_/¯
17:22 <brixen> and if they have, what is the % of features they spec'd versus features implemented
17:22 <brixen> tenderlove: this isn't abstract
17:22 <brixen> and your funny emoji isn't helpful
17:22 <brixen> you attitude is obviously hostile
17:22 <tenderlove> ok, so the yard stick for contribution is the % of spec'e features vs implemented featues?
17:22 <brixen> the Thread::Backtrace::Location bug is a big deal
17:22 <brixen> it breaks a lot of 4.1 apps
17:23 <brixen> MRI doesn't even have a test for Thread::Backtrace::Location#path
17:23 <brixen> and this is just one tiny case
17:24 * yopp reseting "Ruby community without drama" counter
17:24 <brixen> tenderlove: a useful metric for whether MRI is contributing is the % of specs they add for features they implement
17:24 <brixen> tenderlove: do you disagree with that?
17:24 <tenderlove> nope, it makes sense to me!
17:24 <brixen> ok
17:24 <brixen> so, how much has MRI contributed in the past 3-4 years?
17:25 <brixen> any specs for ObjectSpace::WeakMap?
17:25 <brixen> any specs for keywords?
17:25 <brixen> any specs for Thread::Backtrace?
17:25 <brixen> etc etc
17:25 <brixen> I don't think I'm being unreasonable if you look at this metric
17:25 <brixen> furthermore, matz could say, "use rubyspec"
17:25 <brixen> he doesn't
17:26 <brixen> it is what it is
17:26 <yopp> Maybe it's time to crowdsource some devs, to do that?
17:26 <brixen> yopp: please do!
17:27 <brixen> and ensure they abide by my quality requirements
17:27 <jc00ke> Do we know why Matz, et al, don't use or contribute to RubySpec? I'd sure like to know the reason, if there is one.
17:28 <jc00ke> Sorry, didn't mean to use "contribute" like that. Meant more in the "actively" sense.
17:29 <brixen> chrisseaton: I made a comment on your PR
17:29 <yopp> brixen, also planting a secret agents to MRI core might help :B
17:29 <brixen> tenderlove: 2.1.5 still fails a keyword spec
17:29 <brixen> tenderlove: despite opening tickets, despite the specs being there, etc
17:29 <jc00ke> There has to be some barrier; what is it and how do we address it?
17:30 <brixen> tenderlove: I recently tried to address the rubyspec failures on 2.1 and there are really obscure things that I can't find in redmine
17:30 <brixen> tenderlove: it takes a ton of my time to do this because MRI devs don't contribute
17:30 <enebo> brixen: or they no longer contribute
17:31 <brixen> enebo: what is your point?
17:31 <brixen> do they get perennial credit for having contributed?
17:31 <brixen> is 1.9.2 still used?
17:31 <brixen> it's not even supported by MRI any more
17:31 <brixen> they don't contribute
17:31 <enebo> brixen: most OSS people do get credit if the contributed at one time
17:31 <brixen> present tense, relevant context
17:31 <chrisseaton> brixen: (aside from the argument) are you happy with PRs that change spec names to correct spelling and grammar? I often see problems but not sure about changing them, because I guess it will invalidate people's tag files?
17:32 <brixen> chrisseaton: all changes to improve the quality and clarity are needed
17:32 <brixen> people can very easily retag
17:32 <enebo> brixen: I also think the fact they stopped is the crux of the problem and realizing they used to means something made them stop
17:33 <brixen> enebo: so please go find out why
17:33 <brixen> instead of blaming me
17:34 <enebo> hmmm
17:34 <enebo> brixen: ok well I said my piece whether you got anything from it or not. I am done…for now
17:37 <brixen> enebo: it's interesting to me how quickly you defend whether other contribute
17:37 <enebo> brixen: ok
17:38 <brixen> enebo: 15 commits, most recent in jan 2011 https://github.com/rubyspec/rubyspec/commits?author=enebo
17:38 <chrisseaton> well I'll put my money where my mouth is today and write some specs for #local_variables - is there a style guide?
17:38 <brixen> enebo: you've implemented basically all of the jruby parser
17:38 <brixen> I know how thorny eg keywords are
17:38 <enebo> brixen: but I told you back then I stopped contributing because I did not like working with you. I do still encourage people contribute to rubyspec though. I say virtually every time I speak at a conference.
17:38 <brixen> and know MRI tests don't cover the edge cases
17:39 <brixen> enebo: I'm in #jruby
17:39 <brixen> I see all the discussions
17:39 <enebo> brixen: ok
17:39 <brixen> it's as if there's an alternate reality
17:40 <brixen> anyway, back to the original point
17:40 <brixen> I have a budget of 24 hours every day
17:41 <brixen> I have to make decisions about how to spend that in the context of what is actually valuable for rubinius
17:41 <brixen> MRI devs clearly make a decision about what is valuable to them
17:41 <brixen> enebo: as do you, whatever reason you want to label it with
17:42 <enebo> brixen: I agree with that btw
17:42 <enebo> brixen: My original statement said I think you should do what you feel wrt to rubyspec
17:43 <brixen> |jemc-bot|: can you send me the creds for the Rubinius docker account, please
17:43 <brixen> |jemc-bot|: you can use keybase.io if you have it, or I can send you an invite if you need it :)
17:43 <brixen> cpuguy83: got a sec?
17:43 <cpuguy83> brixen: Yep
17:44 <brixen> cpuguy83: ok, sorry for going over this like the third time, but I'd like to get the docker situation squared away
17:44 <cpuguy83> sgtm
17:45 <brixen> cpuguy83: so, if I put this Dockerfile in rbx repo root https://github.com/cpuguy83/docker-rbx/blob/master/Dockerfile
17:45 <brixen> and we tag a release, that will automatically build?
17:45 <brixen> for Docker Hub?
17:46 <brixen> cpuguy83: |jemc-bot| made an account for rbx
17:46 <cpuguy83> brixen: If you want to have an account and an automated build yes. It would actually happen at every commit currently (limitation in DockerHub)
17:47 <brixen> ah hmm
17:47 <brixen> that's gonna be a lot of builds
17:47 <brixen> cpuguy83: what would be the best way to do only release tags?
17:47 <brixen> could we have travis ping the docker hub hook on release?
17:47 <brixen> instead of docker hub listening to github directly?
17:47 <cpuguy83> brixen: Yes, indeed.
17:48 <brixen> ah ok
17:48 <brixen> any doc on that?
17:48 <cpuguy83> one sec
17:48 <brixen> sweet
17:49 <yopp> brixen, what the most up to date ruby-building tool for rbx?
17:49 <yopp> with latest versions
17:49 <cpuguy83> brixen: https://docs.docker.com/docker-hub/builds/#remote-build-triggers
17:49 <brixen> yopp: what do you mean?
17:49 <yopp> I have ruby-install from HEAD, but it's still 2.3
17:50 <brixen> cpuguy83: oh awesome, thank you!
17:50 <brixen> yopp: ruby-install includes the most recent release it knows about when released
17:50 <brixen> yopp: which makes it kinda suck if you just ruby-install rbx
17:50 <brixen> you need to give it a version
17:50 <brixen> eg ruby-install rbx 2.4.1
17:50 <yopp> ah, wow
17:50 <brixen> yopp: what platform are you on?
17:50 <yopp> osx
17:51 <brixen> ok, you can use my binary builds
17:51 <cpuguy83> brixen: And if you like, we can also do a top-level image as well, but this is a more manual process
17:51 <brixen> yopp: in brew
17:51 <yopp> just brew install rubininius?
17:51 <brixen> yopp: brew update && brew tap rubinius/apps && brew install rubinius
17:51 <cpuguy83> brixen: Ala https://registry.hub.docker.com/_/jruby/, which I currently maintain from here https://github.com/cpuguy83/docker-jruby
17:51 <brixen> yopp: it's keg only but if you already have ~/.rubies/, the recipe will put the binary there
17:52 <yopp> nice
17:52 <cpuguy83> Up to you if you want to do that. It's significantly more manual.
17:52 <brixen> cpuguy83: ok
17:52 <brixen> cpuguy83: well, it's better to only build releases, I think
17:52 <brixen> cpuguy83: we push multiple times a day
17:53 <brixen> cpuguy83: so how does https://registry.hub.docker.com/_/rubinius/ come into existence?
17:53 <brixen> yopp: are you on yosemite?
17:53 <yopp> yep
17:53 <brixen> ok, good
17:53 <brixen> I messed up the -macosx_version_min for 2.4.1
17:53 <cpuguy83> brixen: We merge a build manifest here: https://github.com/docker-library/official-images/tree/master/library
17:53 <brixen> but it should run on yosemite
17:54 <cpuguy83> brixen: This has to be updated each release.
17:54 <yopp> ABORT: unable to set up LLVM :B
17:54 <brixen> cpuguy83: ok, so I need to send a PR each release?
17:54 <yopp> (i've tried via ruby-install)
17:54 <brixen> yopp: brew install llvm?
17:54 <cpuguy83> brixen: Yes, with the commit sha to point to.
17:54 <yopp> brixen, it should be already there. I'll try to get in from the keg
17:55 <brixen> cpuguy83: ok, is it ok if I automate that via travis release?
17:55 <cpuguy83> brixen: That would be amazing
17:56 <brixen> ok
17:56 <brixen> cpuguy83: sorry, I have many silly questions :P
17:56 <brixen> so dockerhub and the https://registry.hub.docker.com/_/rubinius/ are separate?
17:56 <cpuguy83> brixen: All good, it can be a lot.
17:56 <brixen> ie, anyone can put up a pkg, but the "official" ones need a PR to that repo?
17:57 <cpuguy83> brixen: Yes, those top-level images are gated at the linked git repo
17:57 <brixen> ahh ok
17:57 <brixen> it's all making sense
17:57 <cpuguy83> And vetted by Docker, Inc.
17:57 <brixen> just need to transfer it to my notes so it makes sense tomorrow :)
17:57 <brixen> ok
17:58 <cpuguy83> brixen: Here is the process for that: https://docs.docker.com/docker-hub/official_repos/
17:58 <cpuguy83> official-repos == top-level repos
17:58 <brixen> ah, very nice, thanks
18:00 <yopp> invalid option in RUBYOPT: -2 (RuntimeError)
18:00 <yopp> :|
18:00 <brixen> yopp: do you have a space in your directory name?
18:01 <yopp> ah, it's just I'm an idiot
18:01 <brixen> I've been considering adding support for EIDIOT :)
18:01 <yopp> :D
18:02 <yopp> okay, seems like keg version is running just fine
18:02 <brixen> sweet
18:02 <yopp> what should I do to get stats to grafana?
18:02 <brixen> yopp: I'll be improving the key asap and hopefully get it back into official brew
18:03 <brixen> yopp: just gotta kill Ruby from the build reqs
18:03 <brixen> trying to get as far away from source building as possible on all platforms
18:04 <brixen> yopp: er s/key/keg/
18:05 <brixen> unfortunately, the recipe will have to be keg only but the option to brew link is decent
18:05 <brixen> a more ambitious goal would be to get chruby to understand brew kegs
18:06 <brixen> so it could select a ruby installed there (similar to detecting /opt/local or w/e)
18:06 * brixen foods
18:06 <yopp> nice idea
18:07 <yopp> is there any way to check, that rbx connected to grafanadb?
18:11 <yopp> hum
18:11 <yopp> getting stats
18:12 <yopp> but logging is broken: log writing failed. Device not configured
18:53 <brixen> yopp: logging failed for which? rbx?
18:54 <brixen> yopp: you can set logging to stdout/stderr
18:54 <brixen> I think that's the docker way
18:54 <brixen> yopp: -Xsystem.log=console
18:58 <yopp> brixen, for our app when running under rbx
19:01 <brixen> yopp: er ok
19:01 <yopp> for some reason
19:01 <brixen> yopp: what's it using for logging?
19:01 <yopp> rails default logger
19:01 <yopp> unicorn logging just fine
19:01 <yopp> but seems like rails can't open file for some reason
19:02 <brixen> rails default logger is SyslogLogger no?
19:02 <brixen> yopp: which version of rbx?
19:02 <yopp> rubinius 2.4.1
19:02 <yopp> I've checked with 2.2.10 couple days ago, it was fine
19:02 <yopp> let me check again
19:02 <brixen> hmm
19:03 <brixen> I will release 2.4.2 as soon as I fix this keywords issue
19:03 <brixen> there are some important fixes in master
19:04 <yorickpeterse> brixen: re rubyspec guidelines being ignored, I think we need to be much stricter on that matter. That is, if somebody submits a PR that doesn't match the requirements and doesn't really want to fix it, we close it
19:04 <yopp> yep, it's working just fine on 2.2.10
19:04 <yopp> and can't open logs on 2.4.1
19:04 <brixen> yopp: any chance you could throw up a repo with the same rails version and logging setup?
19:04 <brixen> yopp: if that repros it
19:05 <yopp> let me try with blank rails app, but it might be anything, it's huge project with a lot of deps :|
19:05 <brixen> yopp: ok
19:05 <brixen> yorickpeterse: I have been, people bitch about that, too
19:05 <yorickpeterse> brixen: well, then I'd say "fuck em"
19:05 <brixen> I do ;)
19:06 <yorickpeterse> brixen: perhaps this is Dutch honesty, but I couldn't care less about drive-by commits
19:08 <yorickpeterse> I've dealt with those in the past for some of my own stuff, I just close them
19:08 <yorickpeterse> if somebody can't be arsed to change a few bytes I can't be arsed spending 30 minutes reviewing and merging things
19:11 <yorickpeterse> I'm personally very fond of closing things after a certain period (e.g. a month), but I'm reluctant applying that to rbx/rubyspec/rubysl unless we have some sort of consensus on the matter
19:12 <brixen> yep
19:12 <brixen> the problem with all the open PRs is that they will take a significant effort to make useful
19:12 <brixen> generally, I just rewrite the specs at a certain point because that takes less of my time
19:13 <yorickpeterse> well yeah, that's what I've done in the past as well: basically hijack what somebody was doing and do it right
19:14 <yopp> ah, it was bundle issue
19:14 <yorickpeterse> heh
19:14 <yorickpeterse> where have we heard that before :P
19:15 <brixen> yopp: what issue exactly?
19:15 <yopp> with logging
19:15 <brixen> heh
19:15 <brixen> I guessed that much
19:15 <brixen> can you describe it more than "bundle issue"?
19:16 <yopp> I've started app without fucking bundle exec, so it used some random version of rails
19:16 <brixen> sweet
19:16 <yopp> but seems like it's working with rails 4.2.1!
19:16 <brixen> cool
19:16 <yopp> (apart of broken logging)
19:17 <brixen> wait, logging is still broken?
19:17 <yopp> No-no. with bundled deps it's working
19:17 <yopp> Without bundled deps, with random gems, it's not.
19:18 <yopp> hum
19:19 <yopp> rbx responds in 1500ms, mri 2.1.2 in 250 :|
19:19 <brixen> yopp: show me those stats :p
19:20 <yorickpeterse> yopp: hit F5 a bunch of times
19:20 <brixen> yopp: oh, you could try running with RBXOPT=-Xprofile
19:20 <yorickpeterse> or run siege or something like that
19:20 <brixen> start the app, run a few requests, exit the app, and you'll get the profile on stdout
19:20 <brixen> show me that
19:20 <brixen> yopp: if you're running "hello, world", I swear to god...
19:20 <brixen> :p
19:20 <yopp> :B
19:20 <yopp> nope
19:21 <brixen> I didn't think you were
19:21 <brixen> anyone using Boundary?
19:22 <yopp> where it will flush thre profiles?
19:22 <brixen> the -Xprofile will write the results to stdout when the process exits
19:22 <brixen> you can get fancier if you want
19:23 <brixen> http://rubini.us/doc/en/tools/profiler/
19:23 <brixen> need to make a rack middleware for this
19:23 <brixen> but integrated in the Console
19:24 <brixen> which I'd have more time for if I weren't wasting it implementing this bonkers keyword argument behavior
19:25 <yopp> https://gist.github.com/y8/44d3c4bae811fa963cba
19:25 <yopp> ah
19:26 <yopp> seems like it's unicron's stats
19:26 <brixen> oh, I thought you were running this on puma
19:26 <brixen> die, unicorn, die
19:27 <brixen> yopp: could you try running on puma?
19:27 <yopp> it's not that easy
19:27 <brixen> why not?
19:27 <yopp> we have our own wrapper, to boot all the stuff
19:27 <yopp> who knows how many shot it might set in ENV before actually starting something
19:27 <yopp> •shit
19:28 <yopp> but lemme check
19:28 <yorickpeterse> brixen: I once hacked this together https://gist.github.com/YorickPeterse/1724eb9184e27a23e6df
19:29 <yorickpeterse> note the emphasis on "hacked"
19:29 <brixen> yorickpeterse: https://github.com/nikitapp/nikita-middleware
19:29 <brixen> mar 2011
19:29 <brixen> lol
19:30 <brixen> wycats gave me the template
19:30 <brixen> clearly I've wasted far too much time on irrelevant MRI compat
19:30 <yorickpeterse> well my thing at least does something :P
19:30 <brixen> yeah, put your 3 lines in there
19:30 <brixen> rack middleware is pretty simple
19:31 <brixen> I do like the idea of a sampling profiler accessible at any time better, though
19:33 <yopp> brixen, seems like it's working, but still, there only Puma in profiler report
19:34 <yopp> Is there any way to tell profiler to write to specific file?
19:34 <brixen> are you using threaded puma or worker process puma?
19:34 <brixen> you can pass an IO to the profiler
19:34 <yopp> dunno, I've just did "bundle exec puma"
19:35 <brixen> see eg https://gist.github.com/YorickPeterse/1724eb9184e27a23e6df
19:35 <brixen> or the docs I linked
19:35 <brixen> I think puma tells you when it boots up
19:35 <brixen> what does it say?
19:36 <yopp> * Version 2.10.2 (rbx 2.1.0), codename: Robots on Comets
19:36 <yopp> * Min threads: 0, max threads: 16
19:36 <yopp> * Environment: development
19:38 <brixen> yeah, should be threaded
19:38 <brixen> what does profile output look like?
19:39 <yopp> https://gist.github.com/y8/44d3c4bae811fa963cba
19:39 <yopp> that with yorickpeterse's middleware
19:39 <yorickpeterse> Yeah that profile output looks familiar
19:40 <yorickpeterse> That is, Hash/String#tr being high in the profile output is not very surprising to me
19:40 <yorickpeterse> (having seen lots of similar profiler output before)
19:40 <brixen> Arrays and Hashes sittin' in a tree, using all the CPU...
19:40 <yorickpeterse> interesting enough the time spent is rather low
19:40 <brixen> why is Dir.glob that high in the profile
19:41 <yopp> hum
19:41 <yorickpeterse> Yeah I was about to ask the same :P
19:41 <yorickpeterse> stat'ing the disk on every request is not going to help a lot
19:41 <yopp> https://gist.github.com/y8/44d3c4bae811fa963cba
19:41 <brixen> yopp: any chance you could make me a repo that does close to the real thing?
19:41 <yopp> brixen, nope :|
19:42 <brixen> heh, oh c'mon how proprietary can it be, are they going to kneecap you
19:42 <yopp> Dir.glob was there, because it was the first request, perhaps it's autoloaded some stuff
19:42 <brixen> but anyway, I mean, does the "same thing" where "same thing" means eg renders JSON
19:42 <brixen> ok, that's plausible
19:42 <yorickpeterse> 0.79 1.36 0.03 2464 0.01 0.55 Builder::XChar.encode
19:42 <yorickpeterse> where's that coming from?
19:43 <yopp> I bet it's Rails XML builder
19:43 <yorickpeterse> "Mongoid::Attributes#respond_to?" oh boy
19:43 <yorickpeterse> But yeah, it looks like a lot of hashing is going on
19:43 <brixen> yeah, thrashin' the hashin'
19:44 <brixen> yopp: in 2.4.2 I'll be able to see more about how the JIT is working on that
19:44 <brixen> yopp: so, could you save your test env so you can re-run for me?
19:45 <yorickpeterse> yopp: can you run the app with -Xhash.hamt
19:45 <brixen> you could try
19:45 <brixen> but this is insertion heavy: 8.67 0.55 0.30 78974 0.00 0.01 Hash#new_bucket
19:45 <brixen> and that's more expensive right now in HAMT
19:46 <yorickpeterse> hm
19:46 heftig_ is now known as heftig
19:49 <yopp> brixen, sure
19:49 <brixen> down to 6 F on keywords
19:50 <yopp> Yeah, it's building a lot of hashes
19:50 <yopp> And one huge hash for xml
19:50 <brixen> yopp: what is building them
19:50 <brixen> which xml generator is used?
19:50 <yopp> rabl, mongoid and serialization stuff
19:50 <yopp> rabl + nokogiri
19:50 <brixen> oh that thing
19:50 <yopp> yeah, this pice of crap
19:50 <yorickpeterse> Hm, I should probably benchmark how fast Oga is in _generating_ XML
19:51 <brixen> yorickpeterse: uh yeah ;)
19:51 <yopp> If my contract will be extended to next year, I'll try to fix rabl. Because I don't know why it takes 250ms to generate 25kb of xml
19:51 <yorickpeterse> Granted it might be a bit unfair since it's just `Oga::XML::Element.new(:name => 'div').to_xml`
19:51 <brixen> yorickpeterse: could you also fix rubygems so an Oga wrapper can "provide" Nokogiri?
19:51 <yorickpeterse> brixen: I won't be providing a compatibility layer for Nokogiri
19:51 <yopp> yorickpeterse, I can give you a hash
19:52 <brixen> yorickpeterse: you don't have to
19:52 <yopp> to serialize it to xml
19:52 <yorickpeterse> brixen: or do you mean an adapter in RubyGems so it can use Oga?
19:52 <yorickpeterse> (does RubyGems even use nokogiri?)
19:52 <yorickpeterse> yopp: ah, that it can't do out of the box, you have to build the nodes yourself
19:52 <brixen> yorickpeterse: no, I mean, fix rubygems so it's possible to specify that a different gem "provides" a dependency
19:53 <yorickpeterse> brixen: euh, not sure if I'm following.
19:53 <brixen> so that Rails dependency on nokogiri can be satisfied by oga-nokogiri
19:53 <yorickpeterse> Hmm
19:53 <brixen> it's a simple facility
19:53 <brixen> using the new index metadata
19:53 <brixen> and, of course, fixing dependency resolution to consider it
19:53 <yorickpeterse> Well, I first have to fix my parser generator, then I have to fix the fkn aws-sdk (or replace it with their v2), then I have to fix a bunch of other things :P
19:53 <brixen> haha
19:53 <brixen> indeed
19:53 <brixen> so, you'll need to prioritize your time
19:53 <yorickpeterse> So maybe by next christmas
19:54 <brixen> hmm, takes me back to an earlier conversation today
19:54 <brixen> heh, next christmas is still only 2 days away :)
19:55 <yorickpeterse> nah, tomorrow is spent on putting data through an entire new DB stack and having christmas brunch at the office
19:55 <yopp> so rubygems are ended with xml?
19:57 <yorickpeterse> ended with?
19:59 <yopp> last time I've heard discussions about rubygems, it was about having plain text stuff
19:59 <yopp> with content-disposition support
20:00 <yorickpeterse> oh right
20:00 <yorickpeterse> I think that's in now
20:00 <yorickpeterse> but not sure how much it's used
20:22 <brixen> anyone got MRI trunk build handy? https://gist.github.com/brixen/fbd4a1cebb23ef6b4d85
20:22 <brixen> pretty sure the new index is flat files
20:22 <brixen> with a simple format
20:23 <brixen> yopp: ^^^
20:23 <yorickpeterse> brixen: I think my current trunk is at least a year old, but I can build it, gimme a sec
20:23 <brixen> yorickpeterse: no worries, I can build it
20:23 <yorickpeterse> July 15 2014, not too bad
20:26 <brixen> interesting what one discovers writing specs for MRI features
20:27 <headius> that should be reported as a bug
20:28 <brixen> it's unconfirmed
20:28 <headius> unconfirmed?
20:29 <brixen> yorickpeterse: build done yet?
20:29 <headius> confirmed in trunk build from Sept anyway
20:29 <brixen> yorickpeterse: mine is processing rdoc :p
20:29 <yopp> hum
20:31 <yorickpeterse> brixen: mine is what appears to be compiling extensions
20:31 <yorickpeterse> currently doing openssl
20:31 <brixen> yorickpeterse: done :)
20:31 <yorickpeterse> curses
20:31 <yorickpeterse> ah, rdoc
20:34 <brixen> existing keyword parsing bug that I opened an issue for still exists in trunk
20:36 <brixen> hm, issue is closed
20:36 <brixen> I wonder if a comment on a closed bug gets noticed
20:36 <slaught> was it closed as fixed?
20:36 <brixen> https://bugs.ruby-lang.org/issues/10016
20:38 <headius> I get what you expect on head
20:38 <headius> for both bugs
20:38 <slaught> they claim it is done. so it must be. :)
20:38 <brixen> I'm running it on head and I get the same output as the repro
20:39 <brixen> of course, there's not a single comment in the ticket
20:40 <brixen> this is so not fixed
20:40 <headius> the builds you reported against are very old
20:40 <headius> ruby 2.2.0dev (2014-12-24 trunk 48948) [x86_64-darwin14]
20:40 <headius> 2300 commits off, if what you put in those bugs is the last time you tested
20:41 <yorickpeterse> fuck, I have to recompile Ruby since I forgot to set a prefix ._.
20:41 <brixen> https://github.com/rubyspec/rubyspec/blob/master/language/block_spec.rb#L62-L68
20:41 max96at is now known as max96at|off
20:42 <brixen> whatever is trunk of github/ruby/ruby is what I'm testing
20:42 <brixen> unless this didn't install
20:42 <headius> trunk of github matches mine
20:43 <headius> my build was from rvm, but it appeared to get current head
20:43 <headius> no problem
20:43 <brixen> chruby wtf
20:43 <yorickpeterse> lemme check
20:43 <yorickpeterse> ...once compiling is done that is
20:44 <brixen> hmm, I have two entries in chruby
20:45 <headius> brixen: you might notice your version string says it's from June
20:45 <headius> a good indicator you're not on current head
20:45 <brixen> oh good, this is fixed
20:46 <yorickpeterse> brixen: https://gist.github.com/YorickPeterse/b4b9b3fd853120653b7a
20:46 <brixen> jesus chruby
20:46 <brixen> yorickpeterse: yep, that's what I get on trunk
20:49 <brixen> haha
20:49 <brixen> ran the specs on trunk, immediate segv
20:50 <brixen> oh well, on to something useful
20:50 <headius> you're not going to report it?
20:52 <brixen> report that MRI doesn't run rubyspec?
20:52 <brixen> hm, that might work
20:52 <headius> report a segfault that might affect others
20:53 <yorickpeterse> brixen: oh yeah, I had a segfault on Travis too
20:53 <yorickpeterse> also I think Rbx also segfaulted somewhere down the line
20:53 <yorickpeterse> "also also also"
20:53 <yorickpeterse> heh
20:56 <yorickpeterse> "This pull request can be automatically merged." oh now Github is lying about PRs
20:56 <yorickpeterse> boom, one page of issues down, one more to go
21:30 <brixen> no way 1 file, 123 examples, 316 expectations, 0 failures, 0 errors
21:31 <brixen> now for blocks
21:48 <brixen> hmm, another obscure edge case possibly bug who knows
21:50 <brixen> hmm hmm
22:03 <yorickpeterse> https://github.com/rubyspec/rubyspec/pull/231#issuecomment-68001572 oh hey where have I seen this before
22:04 <yorickpeterse> oh yeah that's right https://github.com/YorickPeterse/oga/pull/55#issuecomment-58198646
22:27 <yorickpeterse> brixen: any objections against me mass-adding MRI licenses to all rubysl Gems in the file MRI_LICENSE?
22:27 <yorickpeterse> (it would be a copy of the COPYING file of MRI trunk)
23:03 <yorickpeterse> meh, here we go
23:03 <yorickpeterse> (going to bed soon)
23:04 <brixen> yorickpeterse: LICENSE.mri would be better, I think
23:04 <brixen> yorickpeterse: but that's an easy rename
23:04 <yorickpeterse> Not a huge fan of using custom extensions though
23:05 <yorickpeterse> Though I guess we could do LICENSE.mri.txt
23:05 <yorickpeterse> but that's equally wack
23:07 <yorickpeterse> brixen: I don't have push access to https://github.com/rubysl/rubysl-continuation
23:07 <yorickpeterse> (apparently)
23:07 <brixen> uh
23:07 <yorickpeterse> huh wtf I do
23:07 <brixen> heh
23:07 <brixen> yorickpeterse: I'm commenting on https://github.com/rubyspec/rubyspec/pull/231
23:07 <yorickpeterse> oh no, that's rubysl-coverage
23:08 <brixen> le'me double check
23:08 <yorickpeterse> hm, Github is also super slow so perhaps it doesn't like me pushing 120 commits in sequence
23:08 <yorickpeterse> "Read from socket failed: Connection reset by peer" ah
23:09 <brixen> yorickpeterse: yeah, seeing a bit of lag from github
23:09 <brixen> you definitely have access to all of rubysl
23:09 <yorickpeterse> hm
23:09 <yorickpeterse> oh, can't comment now either
23:09 <yorickpeterse> D: I broke Github
23:09 <yorickpeterse> or maybe it's north korea
23:11 <yorickpeterse> brixen: I'm trying to comment on the same PR :P
23:12 <yorickpeterse> but it's not working
23:12 <yorickpeterse> So much for Git being decentralized but Github being anything but
23:20 <brixen> yorickpeterse: https://github.com/rubyspec/rubyspec/pull/231#issuecomment-68009548
23:21 <yorickpeterse> oh hm, I thought you were talking about the Dir.glob spec
23:21 <yorickpeterse> heh
23:23 <yorickpeterse> brixen: it's indeed not intentionally bad, but I'd say it's extremely lacking. That is, this would basically be the first, rough iteration of the spec
23:24 <yorickpeterse> There's also some really questionable shit in there
23:24 <yorickpeterse> e.g. why the heck is "Thread.pass if rand(100) >= 99" there
23:24 <yorickpeterse> that has a 1% chance to run (assuming it were to be called 100 times at least)
23:25 <yorickpeterse> err not sure, either way that line is really confusing
23:25 <yorickpeterse> also the use of "::File.open" is odd since the specs are not namespaced
23:26 <yorickpeterse> and I just can't figure out what it's actually meant to test
23:26 <yorickpeterse> is it testing that it shouldn't raise "Errno::EEXIST"? that the file is simply there?
23:29 <yorickpeterse> But yeah, this is basically where I draw a line and I'm not going to bother figuring it out, there's far too much going on
23:34 <yorickpeterse> yay push done
23:39 <brixen> yorickpeterse: yep
23:39 <brixen> yorickpeterse: thanks for all the work on those
23:42 <yorickpeterse> all in a day's work
23:45 <yorickpeterse> right I'm off for the night to dream about parser grammars and software bugs, toodles