havenwood has quit [Remote host closed the connection]
goyox86 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
|jemc| has quit [Ping timeout: 252 seconds]
meh` has quit [Ping timeout: 265 seconds]
|jemc| has joined #rubinius
havenwood has joined #rubinius
jbr^ has quit [Quit: Connection closed for inactivity]
zacts has joined #rubinius
Bwild has quit [Ping timeout: 244 seconds]
|jemc| has quit [Ping timeout: 244 seconds]
|jemc| has joined #rubinius
|jemc| has quit [Ping timeout: 250 seconds]
amclain has quit [Quit: Leaving]
havenwood has quit [Remote host closed the connection]
claudiuinberlin has joined #rubinius
houhoulis has quit [Remote host closed the connection]
claudiuinberlin has quit [Quit: Leaving.]
claudiuinberlin1 has joined #rubinius
claudiuinberlin1 has quit [Client Quit]
goyox86 has joined #rubinius
meh` has joined #rubinius
goyox86 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
goyox86 has joined #rubinius
goyox86 has quit [Client Quit]
<yopp>
yorickpeterse, huh
<yopp>
about snow
<yopp>
Couple year ago, in November in St. Petersburg it's "suddenly" started to snow. First thing that gov reps said: "It was unexpected to see snow this time of year".
<yopp>
Yeah, right, snow in Russia in November is so unexpected. But it get much worse: it was snowing hard for weeks, and it was like this EE005998861AL
<yopp>
Even roads was covered with snow. I had 2m of snow near the building entrance.
<yopp>
And then, in April, same reps are said: "You know folks, there too much snow, so we will not be able to clean it approx till June"
<yopp>
Crap, tracking number will be indexed by google, and my secret santa cover will be blown :|
houhoulis has joined #rubinius
machete has quit [Quit: don't panic]
goyox86 has joined #rubinius
JohnBat26 has joined #rubinius
goyox86 has quit [Read error: Connection reset by peer]
|jemc| has joined #rubinius
claudiuinberlin has joined #rubinius
robin850 has joined #rubinius
houhoulis has quit [Remote host closed the connection]
|jemc| has quit [Ping timeout: 252 seconds]
stormbrew has quit [Ping timeout: 256 seconds]
stormbrew has joined #rubinius
houhoulis has joined #rubinius
pd has quit [Ping timeout: 245 seconds]
pd has joined #rubinius
pd has quit [Changing host]
pd has joined #rubinius
goyox86 has joined #rubinius
btcctf_ has quit [Ping timeout: 245 seconds]
pd has quit [Ping timeout: 255 seconds]
pd has joined #rubinius
noop has joined #rubinius
Bwild has joined #rubinius
mbj has joined #rubinius
pzol_ has joined #rubinius
pzol has quit [Ping timeout: 240 seconds]
goyox86 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
diegoviola has joined #rubinius
mbj has quit [Ping timeout: 245 seconds]
amclain has joined #rubinius
noop has quit [Ping timeout: 256 seconds]
robin850 has quit [Remote host closed the connection]
goyox86 has joined #rubinius
goyox86 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
goyox86 has joined #rubinius
zacts has quit [Ping timeout: 258 seconds]
samotarnik has joined #rubinius
<samotarnik>
hey everyone. is there a (non-technical) post somewhere that i could read on the relation between rubinius 3.0, rubinius X, ruby 3.0, etc. ?
dreissig has joined #rubinius
dreinull75 has joined #rubinius
<samotarnik>
i just saw matz's keynote from rubyconf and skimmed through posts on rubinius 3.0 and i'm confused a bit...
<jc00ke>
samotarnik: there isn't, yet. You can think of rbx 3.0 being a badass Ruby implementation, rbx X being Ruby-like in ways. Not sure about Ruby 3.0
<jc00ke>
Ruby 3.0 is still up in the air AFAIK
<jc00ke>
Does that help?
<samotarnik>
hmm... a bit...
<samotarnik>
are there any chances of more intense collaboration between the both implementations in future?
<jc00ke>
samotarnik: what/how do you mean?
<samotarnik>
i.e. could we have a single badass c implementation of ruby w/ some kind of concurrency and/or type checking?
<jc00ke>
That sounds like what MRI is striving to be. Rubinius is striving to be something different, hence the "Ruby in Ruby" motto.
<jc00ke>
One of the tenants of Rubinius is to write as much of Rubinius in Ruby as possible. MRI writes all/nearly all of MRI in C, so totally different.
<samotarnik>
ok
<samotarnik>
what about compatibility? rbx 3.0 will be ruby compatible? rbx X also? and which versions of MRI would you target?
<jc00ke>
Yes, rbx 3.0 will continue to be a Ruby implementation, so the aim is to be compatible with the latest version of MRI. rbx X, no, it's a different beast.
<jc00ke>
You can think of rbx X as "If I could design 'Ruby' from the ground up, how would I do that?"
<samotarnik>
ok
<jc00ke>
So the syntax might be familiar, but the platform will offer much richer tools for building programs. If you haven't read http://x.rubini.us/ give it a read
<samotarnik>
and X is still more or less an idea? i mean the github repo is 'empty'...
<jc00ke>
Correct
<jc00ke>
Well, brixen might have a bunch of code on his laptop, that I don't know ;)
<samotarnik>
ok =)
<samotarnik>
so, i've been using ruby for work for the past couple of years. currently, i'm working on a larger app that gathers data from the web. and i feel that ruby is slowly fading and also that it might not be the best fit for large apps.
<samotarnik>
what i mean by dying is that there are projects out there, that are not being actively developed. and with the app that i'm working on, i think i could really benefit from a compiler or a type checker...
<jc00ke>
samotarnik: why do you think that? There are tons of very large projects written in Ruby that seem to be doing OK. What projects are you referring to? Sounds more like a maintaining problem (which isn't specific to the language) than anything to do with the language itself.
havenwood has joined #rubinius
<samotarnik>
well... the project i'm working on atm is a legacy thing with a large codebase. it's calling a whole bunch of APIs from the outside world. and since it wasn't designed really well (imho) and it's lacking specs, we're having an abundance of production errors we have to deal w/ every day...
<brixen>
samotarnik: this sounds very familiar :)
<samotarnik>
e.g., i see an "undefined method for NilClass" *a lot*
<jc00ke>
samotarnik: ah, one of those projects ;)
<brixen>
samotarnik: yep
<brixen>
samotarnik: what version of Ruby?
<samotarnik>
1.9 =/
<brixen>
ok
<brixen>
well, 1.9 is supposed to be a subset of 2.x in terms of syntax
<brixen>
so, while Rubinius supports only 1.8.7 and 2.1, you may want to try it on Rubinius
<brixen>
samotarnik: since Rubinius has true concurrency, you can use multiple threads in parallel
<brixen>
which helps a ton when talking to external APIs
<brixen>
and we're working on some simple tools that help you identify nil issues
<brixen>
samotarnik: to answer your question re Rubinius 3.0, Rubinius X, and Ruby 3.0: Ruby 3.0 is undefined at the moment
<brixen>
who knows what matz will put in it
<brixen>
Rubinius 3.0 is the next version of Rubinius that will support Ruby 2.x and Rubinius X
<brixen>
Rubinius X is basically Ruby 10.0, and much like 1.8.7 to 1.9, it's a lot different than Ruby 2.x
<brixen>
the rubinius-x org was a place-holder, that's why there's nothing in it
<brixen>
I'm deleting it soon (maybe today)
<samotarnik>
=)
<samotarnik>
brixen: right... thanks for the info...
<brixen>
samotarnik: feel free to email me, brixen at gmail, if you want to talk more about your app but can't do that publicly
<brixen>
samotarnik: I know a lot about issues related to huge app migrations
<samotarnik>
brixen: thanks... i've actually tried to use MRI 2.x (2.0 to be precise) but got a whole bunch of string/iconv related errors in existing specs. as the coverage isn't really great i didn't want to push it...
<brixen>
ah well, that's the thing
<brixen>
having tools to understand your code is a huge help
<samotarnik>
brixen: so, are there any such tools available today that i could use? or should i just switch to scala? ( =P )
<brixen>
switching to scala is an interesting option
<samotarnik>
=D
<brixen>
I'd love to see the ROI on that conversion :)
<brixen>
samotarnik: what you have right now in Rubinius is the ability to generate production coverage at basically zero runtime cost
<brixen>
it's a bit manual now but if that's the most important / useful tool to you right now, I could probably have a prototype next week
<samotarnik>
i don't think that is the correct answer coming from a ruby advocate
<brixen>
I'm a Rubinius advocate
<samotarnik>
right
<brixen>
if I thought Ruby itself were the answer, I wouldn't be working on Rubinius, Rubinius 3.0 or Rubinius X ;)
<brixen>
as you know from reading about Rubinius X, I think Ruby is dying
<brixen>
because of severe technical problems with the language and implementation
<samotarnik>
it's definitely the case, that other langs are gaining traction in comparison and that there are ruby-based projects out there that aren't being properly maintained
<samotarnik>
i actually really like the language... and i sometimes feel bad, that i'm usually just taking and not contributing more...
<yorickpeterse>
re the nil error stuff, it baffles me people consider that such a huge problem
<yorickpeterse>
granted there exists no way to track the origin of a nil, although a certain bird told me that might change when it comes to Rbx
<samotarnik>
yorickpeterse: i mean what i'm seeing in my situation is a whole bunch of api wrappers. some better, some worse. but when we try to bring the data into the app's standard format, you never really know what you'll get back
<samotarnik>
yorickpeterse: it could be a nil, an Exception, a hash response, an object, etc.
<yorickpeterse>
A type system isn't going to help that much though. It might state the return type or what it will raise (Java style, *pukes*) but it won't tell the structure
<yorickpeterse>
e.g. if the return type of something would be "Hash" you're still left in the dark
<samotarnik>
yorickpeterse: (it's not just about the nils popping up everywhere)
<yorickpeterse>
Sounds more like a case of bad docs
<yorickpeterse>
(which is a problem in general sadly)
<samotarnik>
you're probably right
mustmodify_ has joined #rubinius
<yorickpeterse>
But yeah, there's a lot that can be improved regarding visibility of what code does/should do in Ruby
<samotarnik>
it's probably also the case that in another language i would have to implement the various api wrappers myself instead of relying on gems for (almost) everything
<samotarnik>
oh well...
<samotarnik>
thanks for the talk, everyone =)
<mustmodify_>
Something strange is happening. I installed rbx 2.4.1 and gem install rails ( which is 4.2.0 ) ... then when I run bin/rails c I get ... nothing. It just sits there. Is this a known issue? Or am I losing my mind?
<yorickpeterse>
mustmodify_: is there anything happening CPU wise?
<mustmodify_>
Well, my load is 0.1 ...
<goyox86>
Hey guys I've made a small update to the InfluxDB post v2 (the container one) any feedback is more than welcome
<yorickpeterse>
Does that show any new output once the thing hang?
<mustmodify_>
seems like it gets to an anonymous block and then either hangs or ...
<mustmodify_>
whatever.
<yorickpeterse>
or does it just stop after a while?
<mustmodify_>
As far as I know it hangs. I haven't seen it stop so far. I've tried several times, and it has run for as long as 5ish minutes.
<mustmodify_>
I guess I'll try a different version of RBX and if that still fails, a different version of Rails.
<yorickpeterse>
mustmodify_: if you have `pidof` and `strace`, run this: sudo strace -p $(pidof ruby)
<yorickpeterse>
otherwise replace $(pidof ruby) with the PID of the rails console
<yorickpeterse>
that should most likely spit out a bunch of output if it's doing anything
samotarnik has left #rubinius ["Leaving"]
<mustmodify_>
that's interesting.
<mustmodify_>
Process 1161 attached read(10,
<yorickpeterse>
type something like "10" and smack enter
<yorickpeterse>
does the output grow in that case?
<mustmodify_>
no close paren?
<yorickpeterse>
Nah, just anything
<yorickpeterse>
Train of thought: it might be that the IRB shell is actually running, but for some reaosn either the prompt is hidden or it's stuck somewhere before that
<yorickpeterse>
If the input is somehow processed you'd probably see new output from strace
<mustmodify_>
nothing.
<mustmodify_>
That's so strange.
<yorickpeterse>
hm
<yorickpeterse>
Does this work prior to 2.4.1?
<mustmodify_>
I'm getting somewhere.
<mustmodify_>
Yeah, I switched back to 2.2.10, which is what I was using before.
<mustmodify_>
But I also removed 'debugger' and some other things from the Gemfile... Am I correct in thinking that debugger is incompatible with Rubinius?
<yorickpeterse>
Yeah I believe you need to wrap that in a platform :mri block
<mustmodify_>
ok so now we're getting somewhere.
<mustmodify_>
Having removed all the things in that block from the gemfile, I'm able to run `bin/rails c`
<yorickpeterse>
hm
<mustmodify_>
so let me see if I can reproduce this.
houhoulis has quit []
<mustmodify_>
This is truly strange. Now when I try to install the same version of rails, I get a compile error for the gem 'byebug' ... but I *just* installed it.
houhoulis has joined #rubinius
<yorickpeterse>
byebug probably also doesn't work on Rbx
<yorickpeterse>
nope, it won't
<mustmodify_>
which is fine
<mustmodify_>
but
<mustmodify_>
how did I get into a state where I installed it, everything worked, and then ...
<mustmodify_>
that's confusing.
<mustmodify_>
Oh well, I'm sorry to say I can't reproduce this issue.
<yorickpeterse>
np
<mustmodify_>
yorickpeterse: that's going to bother me. :(
<yorickpeterse>
byebug uses a bunch of MRI functions (rb_tracearg_*) we don't have/can't have
<mustmodify_>
yeah, but I don't think that was related to the problem.
<mustmodify_>
bah! Oh well.
mustmodify_ is now known as mustmodify
<mustmodify>
did I fix my nick?
<mustmodify>
hooray
<yorickpeterse>
In unrelated news, writing parser by hand is incredibly boring
<mustmodify>
I bet!
<yorickpeterse>
but it must be done if I want to 1) eat my own dog food 2) bootstrap this parser
<mustmodify>
tell me about that.
<mustmodify>
I assume you mean that if you use a high-level language it won't be optimized?
<yorickpeterse>
No, so I'm working on my own LL(1) parser generator
<yorickpeterse>
In order to parse the grammar files I need a parser (doh)
<yorickpeterse>
but for that I need to either 1) write the parser by hand and leave it at that or 2) bootstrap it
<yorickpeterse>
To bootstrap it you basically write the first parser by hand, have it process a grammar and spit out a new (and basically identical parser)
<yorickpeterse>
if done properly you should be able to then use the generated parser from that point on
<yorickpeterse>
Unless you make substantial changes to the grammar, but that's unlikely
<yorickpeterse>
(e.g. introducing vastly new syntax elements probably requires re-bootstrapping, but I'm not sure)
claudiuinberlin1 has joined #rubinius
claudiuinberlin1 has quit [Client Quit]
<mustmodify>
I have a hazy memory of some of this from college. Sounds like A BLAST. Not really.
claudiuinberlin has quit [Ping timeout: 255 seconds]
<mustmodify>
I am able to reproduce this issue now.