<cremes>
step 1, convert vm/builtin/io.hpp and vm/builtin/io.cpp to pure Ruby
<goyox86>
cremes setep 1 of?
<goyox86>
:)
elia has quit [Quit: Computer has gone to sleep.]
goyox86__ has joined #rubinius
elia has joined #rubinius
goyox86 has quit [Ping timeout: 246 seconds]
goyox86__ has quit [Read error: Connection reset by peer]
goyox86 has joined #rubinius
Bwild has quit [Read error: No route to host]
<brixen>
dreinull75: tell me what you like about skylight sometime
<brixen>
dreinull75: with the Rubinius::Metrics and coming instrumentation bytecode, we'll likely be able to build something better modeled after the influxdb-grafana docker container
<brixen>
dreinull75: real software-as-a-service
<brixen>
I understand paying someone to manage a deployment of something like that, but not just to "run your software on your servers"
<brixen>
especially with stuff like making MRI-specific agents
havenwood has quit [Remote host closed the connection]
havenwood has joined #rubinius
<cremes>
goyox86: hard to say… step 1 of 20 probably but that’s just a guess.
<cremes>
time for a movie break. i’ll hit this again tomorrow and probably monday too (half work day).
<goyox86>
cremes Heh but what are u working on removing the io locks?
<goyox86>
nevermid enjoy the movie!
<cremes>
goyox86: i’m working on moving all of IO over to using FFI and eliminating any C++ (though there will be some in the FFI paths).
<goyox86>
:)
<goyox86>
Sweet cremes
<cremes>
and once i get that working, then i’ll move to using memory-mapped files for file i/o… should be *way* faster than what we have now, though
locks has left #rubinius [#rubinius]
<cremes>
i don’t know what kind of perf hit we’ll get on moving ot pure ruby. but then that problem falls into brixen’s lap and getting the JIT tuned up. :)
<cremes>
time to deliver on the promise of Ruby-in-Ruby… turtles all the way down, man! ;)
<brixen>
cremes: Ruby in Rubinius X all the way down ;)
<cremes>
brixen: preach it, brotha! and now, time to watch “gone girl” (or whatever the wife picks…)
<brixen>
I've heard that's good
<brixen>
probably should see it
GitHub160 has joined #rubinius
<GitHub160>
[rubinius] brixen pushed 1 new commit to master: http://git.io/gEKRVQ
<GitHub160>
rubinius/master a585b6d Brian Shirai: Reset release date.
GitHub160 has left #rubinius [#rubinius]
goyox86__ has joined #rubinius
elia has quit [Quit: Computer has gone to sleep.]
goyox86 has quit [Ping timeout: 255 seconds]
goyox86__ has quit [Read error: Connection reset by peer]
goyox86 has joined #rubinius
goyox86 has quit [Client Quit]
goyox86_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<cremes>
I’ve only listened to the first 5m, but already it sounded interesting enough to potentially explore for rbx-x.
<|jemc|>
cremes: could be a part of the titanius platform, but showcased in rbx-x - no reason to restrict it to rbx-x
<cremes>
|jemc|: maybe. i’m still fuzzy on what is titanius versus rbx-x versus rbx, etc.
<cremes>
:)
<|jemc|>
cremes: darnit, cremes, now I want to stop everything else I'm doing today to play around with clang
<cremes>
|jemc|: you are welcome!
<|jemc|>
although maybe it's not too much of a stretch - most of what I'm doing today is writing czmq code in C with the intention of calling it from Ruby
noop has joined #rubinius
meh` has joined #rubinius
cpuguy83 has joined #rubinius
goyox86__ has quit [Ping timeout: 240 seconds]
<cremes>
brixen: i started looking into how to do memory-mapped pipes & sockets but i can’t find anything useful that could be translated to Ruby.
<cremes>
unfortunately, it is written in German and the code is against a very old linux kernel.
<cremes>
the kernel patch is in english so with a LOT of work i could probably piece together the technique, but…. i don’t see that happening without some help.
<cremes>
so for now, i’ll continue to use read/write for pipes & sockets.
<|jemc|>
cremes: but still try to use mmap for files?
<cremes>
yes
elia has quit [Quit: Computer has gone to sleep.]
<brixen>
cremes: baby steps :)
GitHub28 has joined #rubinius
<GitHub28>
[rubinius] brixen deleted jit-method-without-calling at d198fb3: http://git.io/DO2OPw
GitHub28 has left #rubinius [#rubinius]
Prathame_ has joined #rubinius
Pratham__ has joined #rubinius
<cremes>
brixen: yesterday you said: “brixen: cremes: also, ByteArray objects will have the ability to simply index another memory space”
Prathame_ has quit [Ping timeout: 245 seconds]
<cremes>
does that mean ByteArray currently does *not* have this capability? Looking at the code it doesn’t appear to support this but my C is rusty.
elia has joined #rubinius
GitHub42 has joined #rubinius
<GitHub42>
[rubinius] brixen pushed 2 new commits to master: http://git.io/F103qA
<GitHub42>
rubinius/master b5a83fa Brian Shirai: Set macosx_version_min when building Homebrew binary.
<GitHub42>
rubinius/master 88a2179 Brian Shirai: Add Rubinius to matrix as a build Ruby.
GitHub42 has left #rubinius [#rubinius]
<brixen>
cremes: it doesn't at the moment, a ByteArray is a single contiguous region of memory
<brixen>
cremes: all it needs is a function interface to compute the start of the bytes
elia has quit [Client Quit]
<brixen>
any sh experts want to help remove Ruby as a build dependency?
<cremes>
brixen: so if I have an FFI pointer returned, how might I add this function to ByteArray to index that pointer?
<brixen>
with some magic that doesn't yet exist, unfortunately :)
<cremes>
ok
<brixen>
that's why I said you'll have to just copy for now
<cremes>
ah, ok.
<brixen>
but, if you have the copying version working, swapping it will be trivial
<brixen>
for real values of trivial :)
<cremes>
i don’t have anything working yet. heh.
<brixen>
ahh hammock time phase, huh? :)
<brixen>
hopefully, you've got a nice scotch there for inspiration
<cremes>
heh, no scotch (or any booze) for me in January. It’s my dry month. :)
<brixen>
I'm sorry
<cremes>
don’t. it will be over soon and i make up for it the remaining 11 months.
<brixen>
heh
<brixen>
I'd try to make up for you but seem to have caught a cold
<brixen>
hm, hot toddy sounds good
<brixen>
maybe I'll make up for you after all
<cremes>
it’s this *warm* weather we’ve been having lately.
<brixen>
yeah, pretty hilarious weather
<brixen>
well, considering I only have experience with two Chicago winters
<cremes>
yeah, you’re still a chicago newbie
<cremes>
although last year was the worst/coldest i remember in my 42 years.
Pratham__ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jeregrine has quit [Ping timeout: 265 seconds]
<cremes>
Looks like FFI::Pointer#read_string will be sufficient for now. We’ll probably want a FFI::Pointer#map_string at some point to avoid copying.
jeregrine has joined #rubinius
cezarsa_ has quit [Read error: Connection reset by peer]
andrewstewart has quit [Read error: Connection reset by peer]
jeregrine has quit [Read error: Connection reset by peer]
dlackty__ has quit [Read error: Connection reset by peer]
jeremyevans has quit [Quit: leaving]
<yopp>
cremes, blame BP
cezarsa has joined #rubinius
andrewstewart has joined #rubinius
dlackty__ has joined #rubinius
jeregrine has joined #rubinius
<brixen>
I think the blame goes a bit wider than BP
<yorickpeterse>
brixen: please tell me you're not replacing Ruby with Bash
<yorickpeterse>
Bash is the worst language to write a moderately complex build system in
<yorickpeterse>
well, shell script in general
<|jemc|>
yorickpeterse: no, he's not replacing it with bash, he's replacing it with sh :P
<yxhuvud>
I disagree. m4 is clearly worse.
<yorickpeterse>
|jemc|: that's even worse
<|jemc|>
if it was bash, I might feel tempted to help out with the work, but every time I try to restrict myself to sh-only for a complicated script I go temporarily insane
<|jemc|>
yorickpeterse: brixen: I wonder if a decent alternative might be to do use ruby to code-generate the sh script
<|jemc|>
still gets rid of ruby as a build dep if the code-generated file is in version control, but allows it to be maintained more sanely
<yorickpeterse>
It doesn't matter what you do, if you end up with sh/bash you'll end up in a nightmare
<yorickpeterse>
it works if your build system doesn't extend beyond "clang some_file -o ...."
<yorickpeterse>
but not if you have to generate the instruction files, generate another bunch of cpp/hpp files, run various tests, check for compiler flags, etc, etc
chrisseaton has quit [Ping timeout: 265 seconds]
<|jemc|>
yorickpeterse: I've been using code generation for build systems and C code as part of the 'zproject' project and I think code generation might be the best option here if ruby as a build dep is off the table
<brixen>
yorickpeterse: all those tasks will remain Ruby
<brixen>
but we can't have Ruby as build dependency
<yorickpeterse>
what?
<brixen>
it causes way too many problems
<yorickpeterse>
that makes no sense
<brixen>
it will ;)
<yorickpeterse>
If you use Ruby for generating the files then it's still a build dependency
<brixen>
nope, it's not
<brixen>
it's a special dev mode dependency
<brixen>
possibly something that must run once before a release
<brixen>
but not the typical build system
<yorickpeterse>
ugh, tracking generated files is equally painful
<|jemc|>
they don't necessarily need to be VCS tracked
<yorickpeterse>
I can guarantee people are going to commit to the wrong files
<yopp>
brixen, build the mruby
<|jemc|>
as brixen mentioned, it could be in release only
<yopp>
and then script with it
<yorickpeterse>
|jemc|: They have to be for those cloning the repo
<yorickpeterse>
as otherwise it's still a build dependency
<yorickpeterse>
but a git-clone-only build dependency
<brixen>
I've seen about every imaginable kind of build pain that exists working on rbx
<yorickpeterse>
"If you grab a tarball run X. If you grab a git copy then run X, Y, Z because reasons"
<yorickpeterse>
Getting rid of the need to generate things in the first place would simplify things a lot already
<|jemc|>
well, I have no issue tracking some generated files in version control if they have a warning header
<yorickpeterse>
Up to a point where you don't even need sh, just a makefile
<yorickpeterse>
I don't oppose the removal of Ruby, the less code to worry about the better. However, replacing the existing system as is (more or less) with sh is just batshit insane
<yorickpeterse>
The amount of mistakes you can make in sh/bash make C look like a baby
<|jemc|>
yorickpeterse: I'd agree with that sentiment, which makes me suggest code generation of the sh
<yorickpeterse>
or NPM removing /usr/local because of paths not being quoted
<brixen>
it's pretty easy to remove your home directory in Ruby
<yorickpeterse>
|jemc|: that only makes things more complicated
<brixen>
I've probably written that bug twice in the rbx build system
<yorickpeterse>
because now not only do you have to set up a shell build system, you also have to setup a shell generator
<yorickpeterse>
and then probably documentation so it actually makes sense
<yorickpeterse>
it's a shame m4/autotools suck so badly, they had good intentions
<yorickpeterse>
just horribly executed
<yorickpeterse>
really horribly
chrisseaton has joined #rubinius
<brixen>
well, they chose m4 over sh :p
<|jemc|>
yorickpeterse: there's already examples of code generation in the rbx repo
<|jemc|>
and you don't need to generate sh build systems in the generic case, just for the rbx case
<brixen>
it's possible to write decent sh
<yorickpeterse>
I know, I have a CI running on Bash
<yorickpeterse>
and it's ok-ish
<yorickpeterse>
but it's not something you want to use for the complexity of our current system
<yorickpeterse>
Not unless we first remove everything we don't strictly need
<|jemc|>
brixen: yeah, but for large systems, having the consistency of a code generator helps
<|jemc|>
code generators don't make consistency mistakes
<brixen>
believe me, I don't want to add complexity
<brixen>
but we *must* fix the build for packagers and average people
<brixen>
even Homebrew is blocked on having Ruby as a build dep
<brixen>
at least Homebrew doesn't blacklist rbx anymore
<yorickpeterse>
oh I don't disagree with that, but before we rewrite all the things we need to take a hard look at what we _actually_ need
<yorickpeterse>
e.g. I think the instructions.def stuff is downright confusing
<yorickpeterse>
take that out, one generation process less to worry about
<brixen>
something being confusing isn't an argument against it
<brixen>
it's a gem now, I just haven't finished with it
<yorickpeterse>
No, but it can lead to the build process being vastly easier to understand
<brixen>
the instruction.def stuff is a pretty good use of codegen
<|jemc|>
I'd agree that it's appropriate there
<brixen>
everything from the jit utils and docs are generated from a single cannonical source
<|jemc|>
although the process could be better documented
<brixen>
er canonical
<yorickpeterse>
You don't need a separate syntax or anything for that, you can pull it from C++ docs if needed
<yorickpeterse>
My point being, replacing the current system as is (or close to it) with sh _might_ make it easier for others to build, but it will land us in maintenance hell
<yorickpeterse>
Up to a point where just as with the current system almost everybody stays away from it
<brixen>
my priority is solving the build problems
<brixen>
since that's what makes it hard for people to try rbx
<brixen>
99% of people who build it will never want to or need to maintain the build system
<brixen>
so ease of maintaining the build system is not a critical consideration
<brixen>
talk to any packager and ask them how much they enjoy the Ruby build dependency
<brixen>
boy, travis UI is ridiculously slow these days
<brixen>
oh for fucks sake travis/rvm
<brixen>
how did it get 2.5.0 in one build and 2.2.6 in another
<yorickpeterse>
Like I said I don't disagree with solving the problem, but you don't solve it by replacing a pile of poop with an even bigger pile of poop
<yorickpeterse>
Even if said pile of poop is only visible to those working on Rbx
<|jemc|>
if you want to do code generation while avoiding introducing new complexity that maintainers have to learn, just use ERB + some seed data
<brixen>
ah crap, need to build rvm a binary for osx
<brixen>
ugh
<|jemc|>
then any maintainer who understands ERB and sh is already good to go
<brixen>
ok, gonna revert that
GitHub131 has joined #rubinius
<GitHub131>
[rubinius] brixen pushed 1 new commit to master: http://git.io/hxGKbQ
<GitHub131>
rubinius/master 0aab1fb Brian Shirai: Revert "Add Rubinius to matrix as a build Ruby."...
GitHub131 has left #rubinius [#rubinius]
<brixen>
why ask people to understand both ERB and sh?
<|jemc|>
brixen: because it means reading less sh :P
<brixen>
bahawahah
<brixen>
uh no
<brixen>
there is nothing wrong with sh
<|jemc|>
erb isn't my favorite way to generate code, but it's at least well-known
<brixen>
RVM and chruby are good examples of this problem
<brixen>
and RVM 2 is omgwtfbbq
<brixen>
so, yes, simple sh with simple as possible tasks, not a bunch of ornate bullshit
<jc00ke>
Mmm, omgwtfbbq, now I'm hungry
<brixen>
me too!
josh-k has quit [Remote host closed the connection]