<diegoviola>
I read this recently, what are your thoughts about it
<diegoviola>
static typing? what?
GitHub173 has joined #rubinius
GitHub173 has left #rubinius [#rubinius]
<GitHub173>
[rubinius] jineshkj opened pull request #3135: Fixed build error due to undefined references to class static variables #3134 (master...master) http://git.io/u7OIbQ
GitHub158 has joined #rubinius
GitHub158 has left #rubinius [#rubinius]
<GitHub158>
[rubinius] jineshkj closed pull request #3135: Fixed build error due to undefined references to class static variables (master...master) http://git.io/u7OIbQ
GitHub112 has joined #rubinius
<GitHub112>
[rubinius] jineshkj opened pull request #3136: Fixes #3134 causing linker error due to undefined references (master...master) http://git.io/iTUM3g
GitHub112 has left #rubinius [#rubinius]
j_mcnally has joined #rubinius
j_mcnally has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<yxhuvud>
diegoviola: no thanks. yes thanks to JIT though..
<diegoviola>
will it even still be ruby if they end up adding static typing to the core language?
<diegoviola>
ruby has always been about dynamic/duck typing, etc
<diegoviola>
isn't static typing the complete opposite of that?
<yxhuvud>
I certainly hope they don't. I guess it is a topic due to python adding a variant of it
<yopp>
Gibheer, but he's using plain "update" instead of $addInSet. It's not fair!
|jemc| has quit [Ping timeout: 272 seconds]
<Gibheer>
yopp: I found it very interesting to know the corner cases, so it is totally fair to point out what can go wrong
<Gibheer>
I've played with cassandra and it has an undocumented feature in that it drops messages when overloaded. The manual doesn't mention it at all
<yopp>
huh
<yopp>
rmq is silently dropping all messages if there no disk space left :)
<Gibheer>
thats ugly
havenwood has quit [Ping timeout: 264 seconds]
yxhuvud has quit [Remote host closed the connection]
yxhuvud has joined #rubinius
<yorickpeterse>
diegoviola: the static typing part makes absolutely no sense
<yorickpeterse>
it's the result of a fad of people going "HNGNGNGNGNGN STATIC TYPING SOLVES ALL THIRD-WORLD PROBLEMS"
<diegoviola>
yeah
<diegoviola>
it sounded like bullshit
<yorickpeterse>
it's the same as that vague tweet from matz about concurrency and actors
<yorickpeterse>
That's not going to happen in at least 5-10 years
<yopp>
hum
<yopp>
`const_get': wrong constant name
<yopp>
1.9's const_get can't resolve full constant path?
GitHub199 has joined #rubinius
GitHub184 has joined #rubinius
<GitHub184>
[rubinius] YorickPeterse closed pull request #3136: Fixes #3134 causing linker error due to undefined references (master...master) http://git.io/iTUM3g
<GitHub199>
[rubinius] YorickPeterse pushed 2 new commits to master: http://git.io/5rx0Vg
GitHub199 has left #rubinius [#rubinius]
<GitHub199>
rubinius/master d7ed420 jinesh: Fixes #3134 causing linker error due to undefined references...
<yorickpeterse>
yopp: No, that was added in 2.0/2.1
<yopp>
uh.
<yopp>
is it possible to backport this whout re-implementing AS "constantize"?
<yorickpeterse>
possibly, not that difficult
<yxhuvud>
yorickpeterse: I still prefer them talking about stuff like tracing jits and threads instead of stuff like refinements ..
<yxhuvud>
because some of it actually may end up implemented
<yorickpeterse>
heh, refinements
<yorickpeterse>
pretty sure the world will have forgotten those 1-2 years from now
<yorickpeterse>
Some day there will be a blog post from somebody saying "Hey look what I found deep in the MRI core, refinements!"
<yxhuvud>
:D
<yopp>
refinements still not implemented, right?
<yopp>
tr/imlemented/in production/
travis-ci has joined #rubinius
travis-ci has left #rubinius [#rubinius]
<travis-ci>
[travis-ci] rubinius/rubinius/master (25554dc - Yorick Peterse): The build has errored.
<yorickpeterse>
yopp: they are in MRI, not Rubinius
<yorickpeterse>
we have no plans on implementing them
<yopp>
why?
<yorickpeterse>
They pose all kinds of problems regarding scoping, even after their initial revision
<yxhuvud>
there is no real need to until people actually start using them. Have anyone seen them used?
<yorickpeterse>
It's also a huge anti-feature that doesn't solve any problems
<yopp>
yorickpeterse, for moped logging, I need to refine "to_\as_json" methods to support mongo-shell style representation. With refiniments I can isolate this shit to scope where to_json is actually called
<yopp>
luckely, to/as_json accept arguments and it's possible to patch it in alias_method_chain style
<yopp>
but still, it's ugly
<yorickpeterse>
You can just overwrite the method?
<yorickpeterse>
If you're overwriting it, even using refinments, to output something that is not JSON, you're doing it really badly wrong
<yorickpeterse>
"This method is called to_json but it really just outputs some plain text shit" for example
<yopp>
no, it's not, untill you do it like to_json(mongo_shell: true)
<yorickpeterse>
Using refinements you'd have a method that, based on the _file_ it was called from, behaves completely differently (potentially)
<yorickpeterse>
how is that _not_ hugely confusing?
<Gibheer>
yorickpeterse: imagine refinements with static typing for ... performance ;)
<yorickpeterse>
That would nullify each other
<Gibheer>
or would result in a huge hadache when trying to figure out what is going on
<yopp>
yorickpeterse, yeah, that's why I hoped for block form: using BreakTheWrold { code }
<yopp>
ªworld
<yorickpeterse>
yopp: that doesn't change anything
<yorickpeterse>
the method still behaves differently based on the context of where it was called
<yorickpeterse>
To me that's the core problem of refinements: they give the illusion of fixing a problem but in reality make things a lot harder
<yorickpeterse>
If people spent more time thinking about them, instead of introducing them quickly (and then changing them on a fucking minor version) perhaps they might've been less of a joke
<yopp>
I'm not agree. Right now when I do require "3rd_party_library" I have no way to know what changed.
<yopp>
And it's hard to isolate who and how monkeypatched what
<yorickpeterse>
yopp: refinements don't solve that problem
<yopp>
refiniments at least point you to who
<yorickpeterse>
Say a library would scope everything in refinements
<yopp>
and where
<yorickpeterse>
e.g. activesupport
<yorickpeterse>
So you require it, then in every file you use it you'd have 15 "using" statements
<yorickpeterse>
you still don't know what's changed until you look at the code/documentation
<yorickpeterse>
it's exactly the same as before, only now you not only have to require() something, but you also have to call using() in every file
<yopp>
Method#refinements => [Mod1, ModB]
<yorickpeterse>
You can do the exact same using Method#source_location
<yorickpeterse>
or Method#included_modules
<yorickpeterse>
errr
<yorickpeterse>
Module#included_modules
<yorickpeterse>
That's exactly the point, it adds nothing that wasn't already there
<yopp>
source_location is not the same as Module
<yopp>
you can't compare with source location :)
<yorickpeterse>
source_location solves the problem of"where does this method come from"
<yorickpeterse>
A list of included modules doesn't, it just shows what's included (or refined, etc)
havenn has joined #rubinius
<yopp>
if you lucky enough and change made with module
<yopp>
if it's made by simply reopening class, it's sucks
elia has joined #rubinius
elia has quit [Client Quit]
<yorickpeterse>
source_location works fine in that case too
<yopp>
compare to imarinary "method(:foo).refiniments.include? HacketyHack"
<yopp>
•imagenary
<yorickpeterse>
A module being included means nothing about where it came from
<yorickpeterse>
You only know module/refinement X was included
<yorickpeterse>
You still have to solve the problem of 1) who created it 2) where was it created
<yopp>
For example, I know that some stuff from AS breakes something. And I need to deal with it
<yorickpeterse>
Again, refinements _don't_ solve the problem of "Where did change X come from?"
havenn has quit [Ping timeout: 264 seconds]
<yorickpeterse>
I'm also willing to bet 9 out of 10 people who state that refinements help with their monkeypatching problems actually didn't have any monkeypatching problems
<yopp>
if solve the problem: libarary A breakes method B, and when there library A, I need to fix it.
<yorickpeterse>
The problem of libraries overwriting each other methods can also be fixed with existing tooling
<yorickpeterse>
So again, refinements don't solve already unsolved problems
<yopp>
yorickpeterse, by parsing source_location?
<yorickpeterse>
No you just check if a method exists before defining it
<yopp>
yeah, right
<yorickpeterse>
(if you're patching some global class that is)
<yorickpeterse>
Oh you want to define String#snake_case? Check if it's there, only add if this is not the case
<yorickpeterse>
problem solved
<yorickpeterse>
If Ruby were to have true namespaces things would be easier in certain cases
<yorickpeterse>
Because then everything would be explicit out of the box, instead of an opt-in (and broken) alternative
<yopp>
and if I need to change how snake_case? behave in some corner cases?
<yorickpeterse>
More importantly, if inheriting core classes in MRI wasn't downright broken this would be a non issue too
<yorickpeterse>
yopp: then you're still fine?
<yorickpeterse>
It's core behaviour would still be to snake case things
<yorickpeterse>
If you rely on that corner case, and the method is otherwise compatible, you can just overwrite it
<yorickpeterse>
There's also nothing stopping you from _not_ patching String
<yopp>
Okay, I required "lib_a". It changed snake_case? beh. in some cornes cases, in the way I don't like
<yorickpeterse>
and instead using either MyStringClass, or some helper module like StringHelper.snake_case '....'
<yorickpeterse>
yopp: then you swap the require() around, problem solved. Or you file a bug to the library asking them not to break things
<yorickpeterse>
Again, we have perfectly adequate tools to fix these problems today
<yorickpeterse>
We don't need refinements, static typing or any of that
<yopp>
there no way to know that method changed somwhere
<yopp>
source_location isn't relaible source of information
<yorickpeterse>
....how's it not?
<yorickpeterse>
You have method X defined somewhere in your own code base, you know the location. You check #source_location, it's something different than you'd expect
<yorickpeterse>
Boom, you know where to look
<yorickpeterse>
The path will give you the Gem name, file name, file line, etc
<yorickpeterse>
Unless you're writing everything in C #source_location is good enough for finding where a method came from
<yopp>
yeah
<yopp>
very user friendly way
<yopp>
also, there no guarantee that file names on all platforms are the same
<yopp>
they can be symlinked
<yorickpeterse>
that argument makes literally no fucking sense
<yorickpeterse>
if it's a symlink you still get to the actual file
<yopp>
they can be on filesystem where path is in smiles
<yorickpeterse>
and you can still open it?
<yorickpeterse>
and see where it comes from?
<yopp>
yeah
<yorickpeterse>
Seriously, that argument makes absolutely no sense
<yopp>
and there no sense in parsing source_location
<yorickpeterse>
I've given you plenty of arguments and examples. You can continue being oblivious to them, but refinements wont bring you the salvation you're looking for
<yorickpeterse>
Today's tooling we have solves these problems in a perfectly fine way. They can be improved, yes, but refinements don't help with that
<yopp>
parsing souce_location is not anything close to "perfectly fine way"
<yopp>
refiniments is not a silver bullet. I see them more like labels: "Foo changed this"
<yopp>
that's it
<yopp>
Having this label > not having this label.
<yopp>
Also, since I can refine only in given scope, I can do whatever I want to do, without risking breaking code in outside scope
<yopp>
ªexternal
diegoviola has quit [Remote host closed the connection]
<yorickpeterse>
Last time before I'm off doing some things: read above, I've given plenty of explanations
<yorickpeterse>
I also never said something about parsing source_location, you just need to look at the output
<yorickpeterse>
["/tmp/test.rb", 2] # => boom you know where it came from, done
<yorickpeterse>
anyway, I'm going to see if I can fix this bloody JIT issue
<yorickpeterse>
does anybody here have llvm < 3.5 installed?
<yorickpeterse>
gah, --system-libs isn't available prior to 3.5
<yorickpeterse>
Fucking LLVM
<yorickpeterse>
hmpf, our build system could also use a clean up
GitHub24 has joined #rubinius
<GitHub24>
[rubinius] YorickPeterse pushed 1 new commit to master: http://git.io/87a7cg
GitHub24 has left #rubinius [#rubinius]
<GitHub24>
rubinius/master a724e8c Yorick Peterse: Support linking to LLVM 3.5....
heftig has quit [Quit: heftig]
heftig has joined #rubinius
heftig has quit [Client Quit]
heftig has joined #rubinius
<yorickpeterse>
brixen: about that JIT issue, I have my doubts if it's actually the JIT. I'm running things with -Xint and it still manifests
<yorickpeterse>
currently digging into this
GitHub144 has joined #rubinius
<GitHub144>
[rubinius] YorickPeterse pushed 1 new commit to master: http://git.io/AssaFQ
GitHub144 has left #rubinius [#rubinius]
<GitHub144>
rubinius/master 6e97298 Yorick Peterse: Added configuration file for EditorConfig....
Spakman_ has quit [Quit: leaving]
Spakman has joined #rubinius
travis-ci has joined #rubinius
<travis-ci>
[travis-ci] rubinius/rubinius/master (a724e8c - Yorick Peterse): The build has errored.
travis-ci has left #rubinius [#rubinius]
Spakman has quit [Client Quit]
Spakman has joined #rubinius
Spakman has quit [Client Quit]
Spakman has joined #rubinius
<yorickpeterse>
brixen: so it's not the JIT by the looks of it, it's the console forever waiting for events
<yorickpeterse>
basically what seems to happen is: 1) fork 2) Console::stop_threads() gets called, joining all threads 3) some other thread for the metrics stuff hangs in a read()
<yorickpeterse>
which then prevents the Console::stop_threads() part from continueing
<yorickpeterse>
if I kill the read() thread it continues onto the next fork()
travis-ci has joined #rubinius
travis-ci has left #rubinius [#rubinius]
<travis-ci>
[travis-ci] rubinius/rubinius/master (6e97298 - Yorick Peterse): The build has errored.
havenwood has joined #rubinius
<yorickpeterse>
hm wait, the console only joins the thread it runs in...interesting
<yorickpeterse>
brixen: ok it 100% is the inotify stuff in the FSEvent class
<yorickpeterse>
oh wait, it's doing stuff in parallel
<yorickpeterse>
welp, at least rbx compiled now
<yorickpeterse>
but yeah, it causes one CPU core to go nuts :/
<yorickpeterse>
probably the event polling
<yorickpeterse>
blegh, I need to think, bbl
DanielVartanov has joined #rubinius
<yorickpeterse>
Yeah so basically when the console stops the threads (and thus calls pthread_join()) it needs to somehow tell FSEvent::wait_for_event() to interrupt the read() call
DanielVartanov has quit [Ping timeout: 272 seconds]
|jemc| has joined #rubinius
postmodern has quit [Quit: Leaving]
DanielVartanov has joined #rubinius
DanielVartanov has quit [Ping timeout: 260 seconds]
<|jemc|>
time to look at generating rbx bytecode from the grammar ast like pegarus does
jaffachi_ has quit [Quit: Computer has gone to sleep.]
<Benny1992>
cool
<Benny1992>
wanted to target the rubinius vm as next too for cake_lang ^^
<Benny1992>
but never had time to get something done
<|jemc|>
my hope is to get a usable speed comparable to kpeg, but gain the ability to mutate the grammar at runtime, which I can't really do with kpeg (at least the way I want to be able to do it)
<Benny1992>
mutate the grammar at runtime? not sure if I know why you would need something :D
<yxhuvud>
jemc: I should make my marpa inspired parser hack functional.
<|jemc|>
Benny1992: well, technically, I don't _need_ to be making a language either
<Benny1992>
true :)
<|jemc|>
my hope is that users would be able to load in extra syntax that they want in a given scope
<Benny1992>
sounds really cool
<|jemc|>
rather than making their DSLs be constrained to the existing syntax of the language, as in Ruby
<|jemc|>
yxhuvud: link?
<yxhuvud>
my hack is unfortunately not functional enough to create parse trees yet - only to recognize valid parses. if you have a higher tolerance for creating c bindings, you might want to look at http://savage.net.au/Marpa.html
<yxhuvud>
I'm not certain the c lib can handle adding grammars during runtime though there is nothing that really prevents mounting arbitrary subtrees of new parsing rules at specific points in the grammar. the worst that can happen is that you get an ambigous result.
<|jemc|>
but based on these profiler results, it looks like I'm going to have to break out Module#dynamic_method and do some bytecode generation to make any speed progress :/
<|jemc|>
heh, 2 minutes to parse 20 lines
havenwood has quit [Remote host closed the connection]
havenwood has joined #rubinius
havenwood has quit [Ping timeout: 264 seconds]
<yorickpeterse>
Benny1992: that's on ongoing problem
<yorickpeterse>
it's being looked into
<yorickpeterse>
|jemc|: re parsing, ragel+racc should be able to process 3 lines in a few ms
<yorickpeterse>
I mean, I can parse 10MB in about 3,5 seconds :P
<|jemc|>
yorickpeterse: yeah, I have a working ragel-racc parser that works really fast
<|jemc|>
yorickpeterse: I'm just doing some dogfood-eating here with the language - as well as trying to come up with a solution that lets me mutate at runtime
<yorickpeterse>
Ah, writing an LL/LALR parser is something I've yet to do
<yorickpeterse>
first I need to fix racc as much as possible, when I have time for that
<|jemc|>
yes, please do :P
<|jemc|>
but yeah, I've found a bunch of pesky parts about the language while doing this, so at least the dogfood portion of this week's little side project has been very productive even if I end up scrapping it eventually
<yorickpeterse>
brixen: ok so this console thing is a race I think
<yorickpeterse>
brixen: that is, a race in the Console class, not the JIT. It seems it does one final read() before request_exit_ is set to `true`
<yorickpeterse>
which then blocks for whatever reason
<yorickpeterse>
Hm, I wonder what happens if I smack a mutex against the wall
<yorickpeterse>
well fuck
<yorickpeterse>
I think I might've fixed it
<yorickpeterse>
oatmeal does wonders
<yorickpeterse>
lemme verify this
jaffachi_ has quit [Quit: Computer has gone to sleep.]
jaffachi_ has joined #rubinius
<yorickpeterse>
sweeeeeeet, this seems to work
havenwood has joined #rubinius
GitHub140 has joined #rubinius
<GitHub140>
rubinius/master 646b214 Yorick Peterse: Lock when calling Console::stop_threads()....
<GitHub140>
[rubinius] YorickPeterse pushed 1 new commit to master: http://git.io/DWZ0zA
GitHub140 has left #rubinius [#rubinius]
<yorickpeterse>
merry christmas
<yorickpeterse>
now we wait for Travis to error
<yorickpeterse>
shit
<yorickpeterse>
I have teh dumb
<yorickpeterse>
._.
<yorickpeterse>
I swear one day brixen will find some broomstick and whack me with it
<yorickpeterse>
(if I don't whack myself before then)
jaffachi_ has quit [Quit: Computer has gone to sleep.]
<yorickpeterse>
gah fuck, so that didn't actually solve the problem
GitHub25 has joined #rubinius
GitHub25 has left #rubinius [#rubinius]
<GitHub25>
[rubinius] YorickPeterse pushed 1 new commit to master: http://git.io/fTb_ww
<GitHub25>
rubinius/master 34cc556 Yorick Peterse: Revert "Lock when calling Console::stop_threads()"...
havenwood has quit [Remote host closed the connection]
travis-ci has joined #rubinius
travis-ci has left #rubinius [#rubinius]
<travis-ci>
[travis-ci] rubinius/rubinius/master (646b214 - Yorick Peterse): The build has errored.
DanielVartanov has quit [Remote host closed the connection]
travis-ci has joined #rubinius
travis-ci has left #rubinius [#rubinius]
<travis-ci>
[travis-ci] rubinius/rubinius/master (34cc556 - Yorick Peterse): The build has errored.
jaffachi_ has joined #rubinius
Bwild_ has joined #rubinius
Bwild has quit [Ping timeout: 272 seconds]
nirix has quit [Ping timeout: 272 seconds]
nirix has joined #rubinius
<yorickpeterse>
prfftt I give up, I can't find it
<yorickpeterse>
It's probably something super dumb but ugh
jnh has joined #rubinius
jaffachi_ has quit [Quit: Computer has gone to sleep.]
shingara has quit [Ping timeout: 245 seconds]
jaffachi_ has joined #rubinius
shingara has joined #rubinius
elia has joined #rubinius
elia has quit [Client Quit]
elia has joined #rubinius
elia has quit [Client Quit]
meh` has quit [Quit: I don't want to live on this planet anymore.]
jaffachi_ has quit [Quit: Computer has gone to sleep.]
jaffachi_ has joined #rubinius
jaffachi_ has quit [Quit: Computer has gone to sleep.]