<lucasmartins>
just read the rubinius 3 blog post series, I wish I had the C skills to help that happen
enebo has quit [Quit: enebo]
<|jemc|>
lucasmartins: I believe a big part of the plan is to try to bring a lot of the C stuff closer to Ruby-space for that reason exactly - so that more contributors can feel comfortable understanding and working with the JIT, the bytecode instructions, etc...
tenderlove has quit [Read error: Connection reset by peer]
<|jemc|>
does somebody want to give the rbx metrics dashboard docker container a whirl before I write the blog post explaining it?
<|jemc|>
just to make sure I didn't miss some bit of the Usage in the README for folks who perhaps haven't used docker before
<|jemc|>
(the container is based on the steps from the blog post by goyox86 last week)
dzhulk has joined #rubinius
dzhulk has quit [Client Quit]
<johnmuhl>
|jemc|: trying it now
<|jemc|>
johnmuhl: thanks; let me know if it's not as simple for you as I describe it in those four steps
<johnmuhl>
hmph "2014/12/15 12:31:04 Post http:///var/run/docker.sock/v1.15/containers/create: dial unix /var/run/docker.sock: no such file or directory"
<johnmuhl>
on the second command
<johnmuhl>
not sure my docker setup is legit though
<|jemc|>
johnmuhl - that's what the ntoe in step two about possibly needing to use sudo is about
<|jemc|>
sudo should do it for you
<johnmuhl>
`sudo docker run -d -p 8125:8125/udp -p 80:80 rubinius/influxdb-grafana` was the command I ran
<|jemc|>
ah. hm... sounds like the docker daemon isn't running then
<|jemc|>
what OS?
max96at is now known as max96at|off
<johnmuhl>
OS X 10.10
|jemc| has quit [Read error: No route to host]
|jemc| has joined #rubinius
dzhulk has joined #rubinius
<|jemc|>
OS X? okay, I'll see if there's any special step you need to do
<|jemc|>
should have activated the daemon automatically, but maybe not without a power cycle
<johnmuhl>
doesn't look like any new processes are started when I run the boo2docker app
<yorickpeterse>
headius: it focuses on how we've handled it so far, though part of that most likely also applies to jruby/opal/etc
<headius>
yorickpeterse: ok...your talk will get in but it would be most interesting if it leans toward rbx-specific
<|jemc|>
I don't use OS X, so I haven't had to deal with this yet, but it looks like you'll also have to replace `localhost` in steps three and four with whatever IP address `boot2docker ip` gives you
<headius>
doens't have to be all specific of course
<yorickpeterse>
headius: percentage wise it's 80% rbx specific
<headius>
cool, sounds good
enebo has joined #rubinius
enebo has quit [Remote host closed the connection]
<|jemc|>
johnmuhl - have to go to a meeting, but I'll be back in a few
<yorickpeterse>
lucasmartins: re C skills, we're actively working on trying to move more to Ruby
<yorickpeterse>
So that you _don't_ need the C skills
<chrisseaton>
It would be amazing to have the whole JIT stack in Ruby, that would be an incredible achievement
<chrisseaton>
Couple that with a Ruby AOT compiler and we could bootstrap ourselves into a pure Ruby enviornment
<yorickpeterse>
chrisseaton: that's part of what we want, although I don't think the whole JIT will be in Ruby
<yorickpeterse>
Most likely it will be mostly Ruby with some underlying C++ to glue that to LLVM
<yorickpeterse>
so basically one day the JIT will be able to JIT itself, hopefully :P
<chrisseaton>
yeah but imagine if the IR and backend (the bit in LLVM at the moment) were in Ruby as well
natevick has joined #rubinius
<yorickpeterse>
so we want to abstract parts of LLVM, that could potentially be in Ruby
<headius>
I start writing the new IR JIT for JRuby in Ruby...but it wouldn't provide much benefit
<chrisseaton>
yeah, there would be limited technical benefits, beside being more approachable to Ruby people
<headius>
right
<headius>
it probably wouldn't even be smaller code
<johnmuhl>
|jemc|: now I get "Error: client and server don't have same version (client : 1.15, server: 1.14)" and I give up on docker on os x again
<chrisseaton>
any excuse to write a new compiler from scratch though - 'we could correct all our mistakes from last time' yeah right
<headius>
hah yeah
natevick has quit [Client Quit]
tenderlove has quit [Ping timeout: 258 seconds]
<brixen>
wtf
<brixen>
bundler is now spitting out garbage into .bundle/config
<yorickpeterse>
brixen: sounds like a bug in Rubinius
<yorickpeterse>
:>
tenderlove has joined #rubinius
havenwood has quit [Remote host closed the connection]
<lucasmartins>
yorickpeterse: I should read robins source then
<yorickpeterse>
lucasmartins: robins source?
<lucasmartins>
lol
<lucasmartins>
rubinius
<yorickpeterse>
Ah right
<headius>
robinius
<lucasmartins>
the JIT->JIT recursion sounds nice
<yorickpeterse>
Sometimes I see people spell it "Rubinious"
<yorickpeterse>
which is an odd spelling
<lucasmartins>
old school scriptaculous fans
<headius>
I get "headious" a lot
<lucasmartins>
yorickpeterse: is a feature like Rubinius Console doable without touch the C code from rbx?
<brixen>
lucasmartins: yes
<brixen>
lucasmartins: the basic plumbing is already in rbx
<brixen>
I just need to fix the way interaction points are handled
<lucasmartins>
brixen: I'm feeling tempted to clone rbx
<yorickpeterse>
lucasmartins: now now we don't want any of that :P
<brixen>
lucasmartins: heh, we try to make it very tempting
<brixen>
lucasmartins: give me a couple weeks, the tempting will be irresistible :)
<lucasmartins>
yorickpeterse: I mean git clone
<lucasmartins>
brixen: could you give me some pointer about where should I start? I mean about which area of the codebase should I be reading right now
<yorickpeterse>
brixen: https://github.com/rubinius/rubinius/pull/3077 I'm closing this one. I gave this some more thought and as we more or less agreed on in the past, there's no sane way of handling this without explicitly checking for BasicObject (and every other possible fucked object) everywhere
<yorickpeterse>
unless we have zomg static types
<yorickpeterse>
lucasmartins: do you want to mess with the Ruby side of things, or the C side?
<brixen>
yorickpeterse: ok
<brixen>
yorickpeterse: I have a solution for it that doesn't require static types ;)
<lucasmartins>
yorickpeterse: the Ruby side of things is more feasible right now
<brixen>
yorickpeterse: can you open an issue though, so I don't forget it?
<yorickpeterse>
brixen: is this the basic type stuff bytecode thing we discussed at Baruco?
<brixen>
kinda related
GitHub62 has joined #rubinius
<GitHub62>
[rubinius] YorickPeterse closed pull request #3077: Guards for BasicObject when coercing types (master...basicheadache) http://git.io/Wnn1Rg
GitHub62 has left #rubinius [#rubinius]
GitHub20 has joined #rubinius
<GitHub20>
[rubinius] YorickPeterse deleted basicheadache at d765183: http://git.io/Wcjwyg
<yorickpeterse>
lucasmartins: http://rubini.us/doc/en/bootstrapping/ is worth a read as a start, to get a bit familiar with the structure (for now, since it will change soon (tm))
<yorickpeterse>
lucasmartins: in general, most of the Ruby meat lives in kernel/common
<|jemc|>
johnmuhl: sorry you had trouble with it. hopefully someone who has OS X and can figure out the problems you ran into can give some insight to add to the README
<|jemc|>
if you get a chance, can you try to follow the steps in the README, and add whatever special steps an OS X user needs to do?
<|jemc|>
it's more complicated on OS X compared to Linux, because OS X needs to run boot2docker, a minimal linux VM as the docker host whereas linux machines can act as the docker host natively
<johnmuhl>
|jemc|: this isn't the first trouble I've had trying to use docker on osx so it's probably nothing specific to the rubinius docker file
josh-k has quit [Remote host closed the connection]
<|jemc|>
johnmuhl: yeah, I doubt its specific to this container, I just want to end up with instructions that are easy for an OS X user to use if possible
<johnmuhl>
it was the docker pkg installer that lead to the incompatible versions thing and brew install docker… that lead to whatever the initial error was
<goyox86>
Sure, I will test guys and I will report any findings
<johnmuhl>
I keep waiting for this mac to die so I can upgrade to linux but it just keeps on working
<|jemc|>
heh
<|jemc|>
I have a four-to-five-year-old OS X machine that I used to use for audio multitracking but I get fed up any time I try to set up a development environment on it
<johnmuhl>
of course working is pretty subjective when you can't reliably restart or logout or use docker :(
havenwood has joined #rubinius
<goyox86>
Is fetching the rubinius/influxdb-grafana files
lucasmartins has quit [Quit: lucasmartins]
tenderlove has joined #rubinius
<|jemc|>
goyox86: the OS X issue you'll probably hit is that where I said `localhost` you actually want to use the IP given by `boot2docker ip` - something I read in the OS X docs, but you can confirm
<goyox86>
Yup, I did that
<goyox86>
I'm able to see grafana but cannot fetch datapoints something wrong with statsd
tenderlove has quit [Read error: Connection reset by peer]
<|jemc|>
goyox86: something wrong with rbx->statsd or with statsd->grafana?
<|jemc|>
the latter seems unlikely, but nothing is impossible I suppose
<|jemc|>
I'm re-pulling the latest automated build right now to double check it on my machine
<goyox86>
I remember having problems with rbx->statsd I did not worked with localhost:8125 it worked with 0.0.0.0:8125
<|jemc|>
goyox86: but you want to use the boot2docker ip, not localhost, right?
<goyox86>
I'm invoking my rbx with the boot2docker ip
tenderlove has joined #rubinius
<|jemc|>
goyox86: ah, weird I'm having issues here as well after pulling the latest build
<|jemc|>
I thought I just changed README stuff between then and now, though...
<|jemc|>
I'll take a look inside
<|jemc|>
ah, I think I get it
<|jemc|>
the grafana queries are running client-side in your browser
<|jemc|>
trying to GET from localhost:8086
<|jemc|>
(influxdb)
<|jemc|>
but influxdb is not exposed on the docker container
<|jemc|>
s/influxdb/8086
<|jemc|>
so, on linux it will work by just adding -p 8086:8086 so your local browser can make the request to localhost:8086 successfully
<|jemc|>
but that will fail on OS X
<|jemc|>
because grafana needs to be using the boot2docker ip instead of localhost
<|jemc|>
hm, so how to solve this gracefully...
<|jemc|>
goyox86: can you try something for me?
<|jemc|>
get the IP address from `sudo docker inspect (sudo docker ps -a -q) | grep IP`
<|jemc|>
the 172.X.X.X address of the running container
<|jemc|>
and try to ping it from your OS X host
<|jemc|>
I can do so on my machine, but I want to make sure boot2docker isn't getting in your way there
dzhulk has quit [Quit: Leaving.]
pietr0 has joined #rubinius
Bwild has quit [Ping timeout: 264 seconds]
josh-k has joined #rubinius
tenderlo_ has joined #rubinius
tenderlove has quit [Read error: Connection reset by peer]
tenderlo_ is now known as tenderlove
enebo has quit [Quit: enebo]
havenn has joined #rubinius
dzhulk has joined #rubinius
havenwood has quit [Ping timeout: 250 seconds]
dzhulk has quit [Client Quit]
havenn has quit [Remote host closed the connection]
havenwood has joined #rubinius
schmied has joined #rubinius
schmied has quit [Client Quit]
havenwood has quit [Ping timeout: 250 seconds]
<goyox86>
<|jemc|> `sudo docker inspect (sudo docker ps -a -q) | grep IP` gives me "zsh: unknown user"
<goyox86>
`docker ps -a -q | grep IP` Returns nothing but I'm sure the docker container is running
goyox86_ has joined #rubinius
goyox86 has quit [Ping timeout: 256 seconds]
<goyox86_>
<|jemc|> Grafana is getting connected to my influxdb running in OS X not the one inside the container
<|jemc|>
goyox86: use `docker ps` to get the hash of the container then feed the hash of the container into `docker inspect <hash_here> | grep IP`
<|jemc|>
goyox86_: yeah, the issue here is as I mentioned above grafana is running client-side on the browser (so localhost:8086 is not where the influxdb port of the container is)
<|jemc|>
goyox86_: I screwed up the command I pasted earlier - forgot the dollar sign - should be `sudo docker inspect $(sudo docker ps -a -q) | grep IP`
josh-k has quit [Remote host closed the connection]
<|jemc|>
so, the question would be whether or not you can ping any of those three addresses from your OS X machine or whether boot2docker gets in the way of that
<goyox86_>
And I've ran grafana outside docker pointing to boot2docker ip and I have the graphs live
<goyox86_>
so it confirmed
<goyox86_>
Ok trying
<|jemc|>
yeah, I'm trying to figure out the most elegant/proper way for grafana to know what address to use for its datasources
<|jemc|>
because, obviously using localhost:8086 doesn't work for OSX or in the general case
<goyox86_>
I can't reach them :( <|jemc|>
<|jemc|>
I was afraid of that - so you have to run with `-p 8086:8086`, but that still doesn't solve the problem of grafana knowing the right hostname a priori
<|jemc|>
(Because I don't think you can edit the datasource urls from the UI - just from the .js file - am I right?)
<|jemc|>
I may have to dig through the grafana source a bit to look
<goyox86_>
is there any way of passing parameters when starting the influxdb-grafana container? like $(boot2docker ip)
<|jemc|>
sort of; you can set ENV vars
<|jemc|>
don't know if there is a way for grafana to respect an ENV var though
<goyox86_>
I have to sleep (late here in Dublin)
<goyox86_>
<|jemc|> drop me msgs here with your fidings :)
<|jemc|>
k, thanks for the troubleshooting help
<goyox86_>
findings*
<goyox86_>
NP
goyox86_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
heftig has quit [Read error: Connection reset by peer]