<brixen>
yorickpeterse: you do have to install psych from a gem
<brixen>
the correct approach is to have it in the Gemfile
<brixen>
also, I'm removing the vendored syck in rubysl-yaml and vendoring libyaml in rbx for Heroku
<brixen>
and pre-installing psych
<brixen>
hopefully in 2.4.2, if I can fix the JIT for kw args
|jemc| has joined #rubinius
<|jemc|>
the more I read about MCJIT, the more it seems like it's going to be a pain in the arse
<|jemc|>
if you compile each new function into its own module, you've got some inefficiency from the extra module overhead for each one
<|jemc|>
and you've got to link them all together so that can call eachother
<|jemc|>
if you compile more than one function in a pass into a single module per pass, you've possibly got some extra weird logic to deal with the arbitrary groupings of functions in modules
<|jemc|>
and again, link them together
<brixen>
|jemc|: hmm
<|jemc|>
it'd be nice if LLVM provided you with an interpreter-oriented wrapping API that lets you compile functions into a single "meta-module" that handles the module grouping and linking internally
<|jemc|>
and add more functions on the fly
<brixen>
well, it's all "just" C++ code in LLVM, so... :)
<|jemc|>
somebody was asking for such an API in a comment on the MCJIT/Kaleidoscope blog post, but searching around for any followup to that request hasn't yielded me anything yet
<|jemc|>
brixen: it just seems like they leave you a lot of ways for each language implementer to get this stuff wrong
<brixen>
not entirely surprising
<|jemc|>
maybe we needs to reach out to the julia devs, who recently went through this issue
<|jemc|>
I posted some links to that end on the MCJIT issue ticket in the rubinius repo
<brixen>
rk
<brixen>
er ok
<brixen>
funny when my fingers hit qwerty keys accidentally
<brixen>
funnier still when it's only like one key
<|jemc|>
I was hoping I'd look at this and feel up to making some progress on MCJIT, but I think I still don't trust myself to get this right
<|jemc|>
brixen: maybe you were already planning on this, but I was thinking about what you were saying about pushing the JIT code more into ruby space, and it looks like things like jit.cpp could be moved to ruby using the ruby-llvm bindings
<|jemc|>
err... I didn't mean jit.ccp
<|jemc|>
I was looking at jit_visit.hpp
havenwood has quit [Remote host closed the connection]
<brixen>
I wouldn't use ruby-llvm, but yes, converting bytecode into LLVM IR can be easily done in Ruby
<brixen>
part of the reason it wasn't done that way initially is because rbx still had a GIL
<brixen>
and evan wanted the JIT to impact the interpreter as little as possible
<|jemc|>
ah, that makes sense
<|jemc|>
so, instead of ruby-llvm, we'd have our own internal FFI bindings to the llvm API?
<|jemc|>
or our own internal primitives that wrap and abstract the LLVM API?
<|jemc|>
anyway, I'd be very excited to get to the point where we could add more rbx VM instructions and their corresponding LLVM IR using just ruby
<|jemc|>
essentially monkey-patching more instructions into the VM
<|jemc|>
all without recompiling rubinius (or titanius, or whatever)
<brixen>
not exactly monkey-patching, but at least with minimal effort
<brixen>
although, JIT generating interpreters is not out of the question
<brixen>
evan had that once
<brixen>
it wasn't a gain at the time
<|jemc|>
it sounds like it would be nice to be able to write domain-specific language addons
<brixen>
LLVM IR is just text
<|jemc|>
complete with high-speed instructions
<brixen>
there's an API to read it into C++ structures
<|jemc|>
whether its parsing, or audio processing, or common science/math operations
<brixen>
most domain specific languages are hacks resulting from poor language tools
<brixen>
these tools would support proper languages with a minimum of effort
<brixen>
that's the point of Rubinius
<|jemc|>
well, I perhaps chose my words poorly - I didn't mean domain specific languages
<brixen>
it's also the reason why Rubinius 3.0 is explicitly not only Ruby
<|jemc|>
I meant domain specific addons to the VM
<brixen>
those should be proper languages
<brixen>
I doubt they will need special instructions, but it will be interesting to see
<|jemc|>
well, audio processing is an interesting avenue that I'm wanting to go down in the imaginary future when I have free time to spend on it
<brixen>
heh
<|jemc|>
when I was first getting into ruby I spent some time on an MRI C extension that did high-speed audio processing on the C++ level and patching and parameter changes on the slower ruby level
<|jemc|>
it'd be neat to look at making it an LLVM extension to the rbx VM instead
<brixen>
this is starting to sound deja vu
<brixen>
did I point you to jvoorhis' stuff?
<|jemc|>
I spoke about it in this channel before :)
<|jemc|>
yes, you did
<brixen>
ah ok
<brixen>
heh
<|jemc|>
it's more about the tinkering and having it exactly my way than getting quickly to something that does almost the same thing as what I want it to do
<brixen>
sure
<|jemc|>
there's lots of audio processing libraries and languages around - it's just sort of a passion project for me relegated to the future of free time
<|jemc|>
but first I have to figure out how I can make some guarantees about various parts of the execution model to make it efficient enough to have the in-language parser be fast enough to be reasonable
<brixen>
|jemc|: my only caution is where "better abstraction" starts being a euphemism for "general purpose"
<brixen>
see my baruco 2014 talk :)
<|jemc|>
I haven't seen the talk yet, but my main worry at the moment is that it will be too specific within each purpose for one's knowledge of the language to quickly switch gears between purposes
<|jemc|>
my vision for it ties into what I was talking about earlier with VM "plugins" that let you add instructions for different purposes - except that for myco these would each be a sort of sublanguage whose rules may be different enough to be confusing
<|jemc|>
for example, one of the first applications I'm looking at using it for is C code generation - you declare myco-style objects but each meme in the [methods] category is written in C syntax or a subset/superset of C syntax
<brixen>
why C syntax?
<|jemc|>
I've been doing a lot of C code generation in the zeromq community and in private zeromq projects and I'm trying to figure out ways to make it better, with less overhead and more expressive
<|jemc|>
this system would essentially let you write C only for the method implementations, and it handles all the overhead for you
<|jemc|>
it generates a *.h and *.c with all the glue code, your makefiles, etc..
<brixen>
why is that important though?
<|jemc|>
wouldn't have to worry about forward declarations
<brixen>
if you have FFI directly in the instruction set, you could call C functions directly
<brixen>
almost like rbx already has
<brixen>
where the JIT can make naked C calls
<brixen>
further, if you have syscall support, you can do things without even needing libc
<|jemc|>
brixen: correct, but basic data passing on hot message paths doesn't come close to being fast enough on rbx
<brixen>
which is a rats nest of pain
<|jemc|>
at least for now
<brixen>
oh, I'm not talking rbx now
<brixen>
aren't we talking ideal systems here? :)
<brixen>
like Rubinius 3.0
<brixen>
heh
<|jemc|>
plus the object-oriented style of C that pieter hintjens has developed is pretty expressive and painless to write
<brixen>
have you tried using rbx FFI instead of the MRI C-ext we have to bundle for compat?
<brixen>
there is no C that is painless to write
<brixen>
you are starting to morph into your computer
<|jemc|>
I'm actually enjoying writing C right now - just not enjoying the extra overhead of forward declarations and headers and such
<brixen>
save yourself while there is still time :p
<|jemc|>
you should take a look at the czmq API sometime if it interests you - it is actually really clean C
<|jemc|>
in fact, pieter quotes me now on the czmq website :P
<|jemc|>
(I'm only linking to show off my quote at the top, not telling you to drop what you're doing and look at the API right now)
<brixen>
that's a good quote
<|jemc|>
:P
<|jemc|>
brixen | have you tried using rbx FFI
<brixen>
when you're dealing with something as friendly as C, you have to take what quotes you can get :D
<brixen>
what issues did you have?
<|jemc|>
brixen: I started trying to but got side-tracked
<brixen>
oh ak
<brixen>
er ah ok
<brixen>
jeez fingers
<|jemc|>
I don't think I ever actually got to benchmarking it
<brixen>
I wonder how some raw syscalls would do for ya :)
<|jemc|>
but I needed that one fix I pushed for the recent minor release
<|jemc|>
which you merged, so thanks - just never got around to benching it yet
<|jemc|>
I've spent a lot of time working in C to replace to replace some of the hot code since then
<|jemc|>
it's certainly worth seeing how much raw rbx FFI improves speed, but that's pretty useless to me until I can use it on ARM :)
<|jemc|>
at least for the commercial use I'm trying to use it for
<brixen>
ok heh
<|jemc|>
and the C implementation is at about 85% of where the ruby implementation is now
<|jemc|>
but it's taken me a LOT of code generation to start feeling comfortable and fluid
<|jemc|>
hence, the desire to make the code generation better using myco in the not-too-distant future
<|jemc|>
but the nifty part is I'm now code-generating the ruby FFI bindings for my libraries at basically zero cost
<brixen>
nice
<|jemc|>
and that code is public in zproject, so anyone can benefit from those efforts
<brixen>
sweet
<|jemc|>
basically you define a simple XML model of the API for each class (XML was not my choice, but it's what zproject was already using)
<|jemc|>
and from that XML it generates the C headers, the ruby FFI bindings with object wrappers that coerce to/from FFI types, and QML bindings as well
<|jemc|>
so all the bindings are kept in perfect sync
<jc00ke>
comm64: can you submit an issue? Please provide your OS, the version of Ruby you're using to compile Rubinius, and your config.rb and configure.log files
houhoulis has quit [Remote host closed the connection]
Akanksha08 has joined #rubinius
Akanksha08 has quit [Ping timeout: 256 seconds]
Akanksha08 has joined #rubinius
mbj has joined #rubinius
elia has joined #rubinius
elia has quit [Quit: Computer has gone to sleep.]
mbj has quit [Ping timeout: 252 seconds]
diegoviola has joined #rubinius
houhoulis has joined #rubinius
meh` has joined #rubinius
[spoiler] has quit [Quit: Leaving]
havenwood has joined #rubinius
bennyklotz has quit [Quit: leaving]
bennyklotz has joined #rubinius
Akanksha08 has left #rubinius ["Leaving"]
mbj has joined #rubinius
houhoulis has quit [Remote host closed the connection]
mbj has quit [Ping timeout: 244 seconds]
elia has joined #rubinius
mbj has joined #rubinius
amclain has joined #rubinius
elia has quit [Quit: Computer has gone to sleep.]
goyox86 has joined #rubinius
elia has joined #rubinius
<goyox86>
Hey brixen |jemc| have you taken a look at the blog post updates I've made yesterday xD. I've haven't enough time to look for a server side graphing solution but I think that is material for another blog post :)
mbj has quit [Ping timeout: 240 seconds]
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #rubinius
goyox86 has quit [Ping timeout: 255 seconds]
elia has quit [Quit: Computer has gone to sleep.]
diegoviola has quit [Remote host closed the connection]
goyox86 has joined #rubinius
havenwood has quit [Remote host closed the connection]
Bwild has joined #rubinius
jnh has joined #rubinius
<jnh>
Hrm. Huia no longer works on 2.4.1
<jnh>
:/
<jnh>
Rubinius::InvalidBytecode: stack underflow on read - at /Users/jnh/Dev/Huia/huia/core/object.huia+2
<jnh>
which seems mildly suspicious. It's something to do with the compiled output, because if I rm *.huiac then it all works again, at least until the compiler regenerates the files.