<dreinull75>
It looks like I had started the app, it kinda failed to properly daemonize because it was at 100% cpu when I decided to kill it and restart. This is the log from the second try.
<dreinull75>
I'm off though, just leave a note and I'll get back to it later
<dreinull75>
In case thats necessary
<jc00ke>
dreinull75: those are old versions of both Rubinius and Puma. Can you update to the latest (at least rbx) and try again? If you're still seeing the problem please open an issue. Thanks!
elia has joined #rubinius
elia has quit [Quit: Computer has gone to sleep.]
goyox86 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
havenwood has quit [Remote host closed the connection]
bakkdoor has quit [Ping timeout: 245 seconds]
bakkdoor has joined #rubinius
flavorjones has joined #rubinius
flavorjones has quit [Quit: Leaving]
flavorjones has joined #rubinius
JimmySieben has joined #rubinius
flavorjones has quit [Quit: Leaving]
meh` has quit [Ping timeout: 255 seconds]
amclain has quit [Quit: Leaving]
Bwild has quit [Ping timeout: 250 seconds]
dreinull75 has quit [Remote host closed the connection]
JimmySieben has quit [Quit: JimmySieben]
noop1 has joined #rubinius
noop1 has quit [Ping timeout: 245 seconds]
noop1 has joined #rubinius
<yorickpeterse>
morning
elia has joined #rubinius
<yopp>
yorickpeterse, morning
<yopp>
I'll ask again then, is there anything like mmap for rbx?
<yopp>
I'm thinking of trying to make proof-of-concept of db on ruby. But seems like there no mmap, and it will be a huge problem. I can stick with jruby and mapdb, but this seems not so right :|
<yorickpeterse>
yopp: "something like mmap for rbx"?
<yopp>
yeah, memory mapped file access
<yorickpeterse>
Yeah that part I got, but what do you mean with "mmap for rbx"?
<yorickpeterse>
You can call the native mmap function if that's what you mean
<yorickpeterse>
(you'd have to use FFI though)
<yopp>
I mean ruby bindings
<yopp>
FFI, hum.
benlovell has joined #rubinius
<yorickpeterse>
No, there are no Ruby bindings for it
<yopp>
I've seen tenderlove's mmap library, but it seems outdated
<yopp>
and it's not building on modern mri :|
benlovell has quit [Ping timeout: 272 seconds]
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #rubinius
yxhuvud has quit [Read error: Connection reset by peer]
yxhuvud has joined #rubinius
diegoviola has joined #rubinius
dreinull75 has joined #rubinius
<dreinull75>
jc00ke: rbx is 2.4.1, do you mean HEAD?
kfpratt has joined #rubinius
goyox86 has joined #rubinius
robin850 has joined #rubinius
nirvdrum has joined #rubinius
goyox86 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
goyox86 has joined #rubinius
goyox86 has quit [Client Quit]
Bwild has joined #rubinius
goyox86 has joined #rubinius
Bwild has quit [Ping timeout: 264 seconds]
noop1 has quit [Ping timeout: 272 seconds]
noop1 has joined #rubinius
noop1 has quit [Read error: Connection reset by peer]
robin850 has quit [Remote host closed the connection]
<jc00ke>
Yeah, sorry
<brixen>
yopp: the overhead of the internal FFI is way less than the C-API based ffi gem
|jemc| has joined #rubinius
<jc00ke>
dreinull75: I must've saw the (rbx 2.1.0) from the puma log.
<brixen>
heh, that confuses me a lot
<brixen>
and now rbx version is approaching rubygems version
<brixen>
gonna have to get 3.0 out soon
<jc00ke>
Please, release 3.0 solely to clear up my confusion. Thanks ;-)
meh` has joined #rubinius
stass has joined #rubinius
ssedov has quit [Read error: Connection reset by peer]
benlovell has joined #rubinius
benlovell has quit [Ping timeout: 256 seconds]
havenwood has joined #rubinius
enebo has joined #rubinius
<dreinull75>
jc00ke: I've installed latest puma. Will see if it hapens again. But it still is something that made rbx crash...
<brixen>
dreinull75: did you see my comments?
<dreinull75>
brixen no, I can only see what's posted in this channel
<brixen>
dreinull75: I sent them in this channel but IRC / my wifi was being sketchy
<brixen>
and I've repeatedly asked people to tell me what companies are advocating switching to Ruby
<brixen>
or bragging about the tough problems they are solving with Ruby
<diegoviola>
how is it dying then? I mean how can a language even die... I know some people consider Latin a dead language, but then we have things like Perl that are like 27 years old and people still use it
<brixen>
and how much easier Ruby makes that than X language
<diegoviola>
hrm
<brixen>
is there growth in businesses paying people to write Ruby?
<brixen>
I see Twitter, Groupon, Gilt, etc very visibly switching away from Ruby
<brixen>
I'm assured that Ruby isn't dying because some panel at some conference says so
<brixen>
or because someone went to RubyConf and met people who like Ruby too
<diegoviola>
brixen: is concurrency part of the problem you are trying to solve with RBX when you say you are working on Rubinius 3.0 or Rubinius X?
<brixen>
yes
<diegoviola>
yeah makes sense
<brixen>
I'm not saying that those other business don't exist
<brixen>
but it should be easy to point to examples
<diegoviola>
brixen: I mean, it's hard to not agree with the fact that Ruby usage has decreased a lot in the last few years
<diegoviola>
people have switched to the JVM, node, etc
<brixen>
and training people to write Ruby is not an indication that Ruby isn't dying in a commercial sense
<brixen>
all those people learning Ruby would probably like a living wage using it
<brixen>
it's not like they are just hobbyists or something
<diegoviola>
right
<diegoviola>
brixen: so you say that more from a VM/performance perspective than the language itself
<brixen>
from every perspective
<brixen>
I've tried to explain that in the Rubinius X post as well as the Rubinius 3.0 posts
<diegoviola>
and if you chage parts of the language in RBX 3 or RBX X, wouldn't that create issues with MRI? like when we get Rails 6 and it runs on MRI, will it also run on RBX X?
<diegoviola>
brixen: hrm
<diegoviola>
ok will read, ty
<brixen>
diegoviola: I'm not changing Rubinius support for Ruby 2.x
<brixen>
Rubinius 3.0 is specifically about letting people migrate from MRI with zero effort while taking advantage of much better language features
<brixen>
at the same time as getting better technical foundation for Ruby 2.x code
<brixen>
ie JIT, precise GC, etc
<brixen>
concurrency
<diegoviola>
interesting
<diegoviola>
but then MRI won't work with their codebase anymore right? when they start using Rubinius X features
<|jemc|>
diegoviola: s/X/3.0
<brixen>
diegoviola: sure, but so what
<diegoviola>
unless MRI catches on with these features
<brixen>
no one is going to migrate if it's not useful
<brixen>
and no one will migrate back to MRI
<brixen>
I guarantee it
<brixen>
if they do, so what
<diegoviola>
right
<diegoviola>
then it won't be RBX catching on with MRI anymore, it will be the other way around :p
<brixen>
good luck with that
<diegoviola>
rubinius x == 3.0?
<brixen>
no
<brixen>
Rubinius 3.0 is what I talked about in the 5-part series
<brixen>
please read
<brixen>
Rubinius X is RUBY_VERSION = "10.0"
dreinull75 has quit [*.net *.split]
<diegoviola>
ok
kagaro has quit [Excess Flood]
dreinull75 has joined #rubinius
kagaro has joined #rubinius
<brixen>
diegoviola: I do appreciate you questions about it
<brixen>
diegoviola: after you read the posts, please ask more if anything is unclear
<brixen>
s/you/your/
* brixen
grabs lunch
<diegoviola>
brixen: cool, thanks
<|jemc|>
hm... seeing some differing behavior between mri and rbx for using return from inside a lambda
<|jemc|>
I'll see if I can reduce and write a spec
<|jemc|>
ah, I see
<|jemc|>
when you return from inside an iter inside a lambda inside a method
<|jemc|>
on MRI the return "binds to" the lambda
<|jemc|>
on RBX the return "binds to" the method
<|jemc|>
however, without the iter they both "bind to" the lambda
<|jemc|>
I'll write a spec
<chrisseaton>
brixen: when you say "Rubinius X is RUBY_VERSION = "10.0"" - do you literally mean you're going to report the RUBY_VERSION as "10.0", or is it a metaphor? What if MRI has a true version 10.0 far in the future?
<jc00ke>
chrisseaton: metaphor ;)
<chrisseaton>
ah ok, cool
<jc00ke>
Do we really want to wait 70 some years for MRI to release 10.0? ;)
<chrisseaton>
Well they could adopt a Chrome style version number and bump the major version every month
<jc00ke>
They could... and at that point a version number really doesn't mean anything
<yxhuvud>
jc00ke: well, how long have cobol been around?
<slaught>
that is the 2014 updats to the ISO standard.
<jc00ke>
I feel like I'm being punished for something (j/k)
<jc00ke>
I wonder how many COBOL devs there are? More than what leave Ruby each year?
<slaught>
a large amount of code is written in COBOL every year. It is a tradeoff. You have to write a new feature in a system with millions of lines of COBOL. What do you do? take months to try to deploy a new language adn runtime system and development tools or do you just write another 100 lines of cobol.
<jc00ke>
I guess my question is: Is COBOL (and other once-popular languages) *effectively* dead?
<jc00ke>
COBOL, maybe not
<jc00ke>
But might be? I dunno, hard to say because that whole segment is opaque to me
<jc00ke>
Ruby, no, not yet, but maybe in 5 or 10 years?
<slaught>
COBOL is alive and well. Your world runs on it.
<slaught>
I would like to see Ruby have a live span of COBOL. I do not think the MRI team is capable of handling it. I do think the Rubinius team has a shot at it.
<jc00ke>
Is Smalltalk dead? I hear people say that all the time, but I know there are still big businesses (OOCL, UBS, big banks galore) that still use it to this day
<jc00ke>
slaught: sounds like that might depend on Ruby parting ways from MRI... which doesn't seem likely.
<jc00ke>
At least any time soon
<slaught>
I don’t think so. It didn’t get a foot hold in various business. And I think of Squeak as smalltalk.
<jc00ke>
It'd be interesting to determine a set of metrics we could use to impartially determine the status of a language
<slaught>
I would say the departation happened with the ISO standard and with Matz working on other languages. Its just no one has bother to provide a 10x improvement over MRI so ppl are just stuck in a rut.
<jc00ke>
Like, "How much revenue was generated in X last year?"
<|jemc|>
dead/alive is a dramatic oversimplification
<slaught>
well cobol wins that and everything else is a rounding error.
<jc00ke>
Ha, was just going to say that COBOL definitely is alive
<slaught>
i think that metric would be pointless. Software Engineering can barely place a value on its won efforts and outputs let alone break it down to the languages and tools used.
<jc00ke>
slaught: the point would be to have some metric, I'm not suggesting that example was a good one.
<slaught>
maybe C is chunk of the revenue given telcoms and such.
<|jemc|>
usually when people talk about dead/alive they really are asking other questions like: "should I start a new large project that uses X?" or "is it worth it for maintainers to continue to maintain X?"
<|jemc|>
these are very different questions that shouldn't be conflated
<slaught>
jc00ke: I am saying I don’t think the metric is interesting nor useful. If a language solves your problem, why does matter how many other problems it sovles.
pietr0 has joined #rubinius
<slaught>
|jemc|: yeah. ppl are wanting to know what is popular. Without a rubric to actually determine usefulness of tools and languages developers default to popular because they assume “someone” must have analyzed the situation. and at the end of the day the popular languages are a seredipitious selection and not a deliberate choice.
<jc00ke>
slaught: sure, understandable, but I'm saying we would need *something* measurable, if we even wanted to talk about the aliveness/deadness of a language.
<slaught>
jc00ke: i understand what you are saying. And agree with your statement about measurablity. I am saying ‘aliveness/deadness’ is not an interesting attribute of a language in my opinion. Bu if it is interesting to you then finding a good metric is important.
<jc00ke>
I don't particularly care about the subject, personally. But I would want evidence to back up an argument.
<jc00ke>
slaught: Ah, sorry, misunderstood what you were referring to (the example, or aliveness/deadness)
<slaught>
jc00ke: no worries.
<slaught>
jc00ke: I would as well like more hard data from people claiming alive/dead. I think brixen’s use of companies claiming to use Ruby is a good enough proxy for his claim. As he is using it as a rhetorical device to emphasis that w.r.t Ruby something needs to be done. And that inaction is not an option.
<jc00ke>
Agreed
goyox86 has quit [Read error: Connection reset by peer]
goyox86 has joined #rubinius
<yxhuvud>
fwiw, all the examples brixen gave was of companies based on rails, and there are *plenty* using chef and puppet, and claiming those are declining in number is not very believable, imo.
<jc00ke>
yxhuvud: yeah, but didn't Puppet just rewrite a whole bunch of stuff (core server, maybe?) in Clojure? Does that count as a departure?
<brixen>
yxhuvud: is chef server written in Ruby?
<brixen>
people keep talking in generalities
<brixen>
I can give you very visible, public examples of Ruby failing
<brixen>
if there are great successes and those are hidden, that hurts the perception and mindshare of Ruby
<brixen>
a lot
<brixen>
anyone who disagrees with that is not operating in reality
<yorickpeterse>
Puppet is moving to Closure or w/e it was
<brixen>
people are constantly making business decisions about technology to use
<brixen>
not talking very publicly about Ruby being successful will mean fewer decisions made to support Ruby
<yorickpeterse>
* Clojure
<brixen>
Rails did not became popular because some unknown company was using it somewhere
<brixen>
DHH and his video did a ton of marketing
<brixen>
then came all the other people talking about it constantly
<brixen>
which is why it got derided from Java camps, etc for being "hype"
<yxhuvud>
brixen: the parts people actually write themselves is.
<brixen>
this is really basic stuff
<brixen>
I'm amazed how people don't understand it
<yorickpeterse>
Vagrant has also moved away from Ruby
<diegoviola>
isn't puppet a system administration thing?
goyox86 has quit [Read error: Connection reset by peer]
<yorickpeterse>
(I think they're Go nowadays)
<yorickpeterse>
I've personally also spoken to a bunch of local shops that are on the "ZOMG GO" train and are ditching Ruby
<brixen>
yep
<yorickpeterse>
And as always almost none, if any at all, have tried Rubinius/JRuby
<diegoviola>
Puppet and Chef are sysadmin tools, right?
<yxhuvud>
diego: yes
<yorickpeterse>
diegoviola: Yes, they're used for provisioning
<diegoviola>
lol
<diegoviola>
and all the web stuff are like JS today...
<yorickpeterse>
The average converations I've had went like this:
<diegoviola>
people will even use perl on servers... so what
<yorickpeterse>
<they> so we're rewriting our API in Go <me> Oh? Did you look at alternatives to MRI such as Rubinius/JRuby? <they> No, we just rewrote half of everything in Go
<yorickpeterse>
where Go can also be Scala, Node.js, Clojure and soon Rust
<yorickpeterse>
basically everything where the world does not yet know the limits of
<yorickpeterse>
black is the new white basically
<diegoviola>
I want to see a Ruby reimplementation with better concurrency, I don't like the JVM, but I don't want to see something like a Python 2 -> Python 3 anytime soon with Ruby...
<brixen>
the NSA uses Perl, it's obviously not dying
<yorickpeterse>
diegoviola: you can't have both, so pick one of the two :P
<diegoviola>
like some big changes to the language
<brixen>
diegoviola: rbx has better compat with MRI than anything but MRI
<brixen>
diegoviola: there's no worry about Python 2 -> 3
<brixen>
the only thing close to Python 2 -> 3 was MRI itself with 1.8 to 1.9
<diegoviola>
right
<diegoviola>
the "purge the perl" in rubinius-x is the only thing I'm still not sure, I like my one-liners ;)
<diegoviola>
globals suck, sure
<yorickpeterse>
The perl-stuff applies to things like $1, $!, etc
<yorickpeterse>
and BEGIN/END
goyox86 has joined #rubinius
<yorickpeterse>
and basically the stuff you'd hardly ever use anyway
<diegoviola>
do you have any of this already implemented?
<yxhuvud>
uh, you are removing begin/end?!?
<diegoviola>
Rubinius X
<brixen>
diegoviola: you should check out a video of Rich Hickey talking about hammock time
<brixen>
writing some code is the least interesting and least important part of Rubinius X
<brixen>
the most important parts are well-along
<yorickpeterse>
yxhuvud: if one wanted to purge all perlisms, probably
<brixen>
yxhuvud: begin/end are not really perlisms
<yxhuvud>
diego: indeed. mostly due to performance though - most of our pages go 2-10 times faster in 2.0 compared to 1.8 o_O
<diegoviola>
yeah I remember being all excited about YARV back in the day
<yorickpeterse>
I still have a REE app :<
<yorickpeterse>
and a shitty one too
<diegoviola>
lol ree
<yorickpeterse>
It's the reason I have a bottle of wine on my closet
<yorickpeterse>
(actually that's because I got it for christmas but ssshhh)
<brixen>
yorickpeterse: you need to try that REE app on Rubinius 1.4.0
<brixen>
yorickpeterse: when I release 1.4.0 next week :)
goyox86 has quit [Read error: Connection reset by peer]
goyox86 has joined #rubinius
goyox86 has quit [Read error: Connection reset by peer]
<yorickpeterse>
brixen: See, this app has "DANGER ZONE AHEAD" signs all over it
<yorickpeterse>
which I basically put there
<yorickpeterse>
I do not dare to put it on anything other than REE
<brixen>
you should dare :)
<yorickpeterse>
I'm already gambling my employment on PostgreSQL, one step at a time :P
<brixen>
you don't have to hot swap it in production
<brixen>
heh
<brixen>
mongodb -> postgres is a pretty good gamble
<brixen>
sandbag much :p
<yorickpeterse>
risky one too deadline much
<yorickpeterse>
* wise
<yorickpeterse>
I made the mistake of saying "Yeah it should be done around the 2nd week of January"
<brixen>
heh
<yorickpeterse>
of course then everybody expects it's actually done by then
<brixen>
yep
<brixen>
everyone wants results in jan
<yxhuvud>
swapping the other direction seems simpler. mongo is more forgiving (which is not a good thing)
<yorickpeterse>
Having said that we're at, I'd say, ~70%
<brixen>
basically, as the holiday's haze wears off
<yorickpeterse>
yxhuvud: it's equally difficult depending on the complexity of the app
<yorickpeterse>
e.g. the storage is not the biggest issue, it's re-writing every single query and making sure they still spit out the same stuf
<yorickpeterse>
* stuff
<yorickpeterse>
One of the affected apps is said REE app
<yorickpeterse>
The good thing about this is that so far I'm removing more code than adding new code
<yorickpeterse>
I figured it was also a good idea to move all non Rails apps from ActiveRecord to Sequel
<yorickpeterse>
Because why not do more at the same time :P
<yorickpeterse>
which actually so far is paying off pretty well
<yorickpeterse>
so my gamble seems to work so far
* yorickpeterse
knocks wood
<yxhuvud>
well, if you break everything anyhow you might as well break it twice.
<brixen>
|jemc|: hm, I think there may already be a rubyspec for that
<brixen>
|jemc|: issue is probably where raise_return instruction stops
<brixen>
|jemc|: I'd have to look though
<|jemc|>
brixen: if you want to look at it, feel free to un-assign me
<|jemc|>
I won't get to actually working on it until later tonight
<|jemc|>
took a brief look at the raise_return instruction, but the issue wasn't immediately clear so I tabled it for now
<yorickpeterse>
brixen: either way, this REE app is scheduled for a rewrite, though if it's not planned in say a month or two I might just look into rbx 1.x
<yorickpeterse>
At least it would have a decent GC/VM
<brixen>
|jemc|: I probably won't get to it today
<brixen>
|jemc|: if you make progress, please update the ticket
<|jemc|>
brixen: will do
<brixen>
|jemc|: actually, I think it's possible this behavior changed in MRI recently
<|jemc|>
brixen: yes, that's how it's behaving, but to me it seems intuitive that if a lambda stops a return inside of it just like a method, it should stop returns from several layers inside of it, just like a method
<diegoviola>
brixen: interesting, will read
<diegoviola>
brixen: ty
<diegoviola>
brixen: a lot of folks I talked to act indifferent to rbx, sadly
<diegoviola>
brixen: well, not a *lot* but a few
<|jemc|>
it makes me think that a Lambda should be its own AST node instead of modelling it as a Send with an Iter
<diegoviola>
brixen: I'm always testing the apps I work with with rbx
<diegoviola>
brixen: most just tend to work, thanks for your work, btw
<brixen>
when was the last time a benchmark showed you memory use tradeoff, for example
<|jemc|>
brixen: I never claimed proc and lambda should be interchangeable - that's why I'm highlighting the difference in the first and second examples on the ticket
<brixen>
|jemc|: I understand
<brixen>
anyway, so while people don't really want hello world crap, getting what they do want is way harder than it needs to be
<brixen>
saying, "set up this container, run your app with this switch, go to localhost:1234 and see the graphs" is helpful
<brixen>
"oh look, max GC pause is X ms, nice"
<brixen>
real perf, real code, no bullshit benchmark nonsense
<yorickpeterse>
brixen: one of the things we still need to solve there is correlation between the metrics and what the app is doing at that moment
<yorickpeterse>
That is, more than just "metric value X at time Y"
<brixen>
yorickpeterse: say more
<yorickpeterse>
But being able to say "it was due to this code"
<brixen>
so, correlating coverage with the stats?
<yorickpeterse>
(which is very difficult in a concurrent system)
<brixen>
I'm not sure what "it was due to this code" means
<yorickpeterse>
Right, so say you run some method that runs a hefty DB query
<yorickpeterse>
You see the metrics (say GC timings) go up and think "ooh that's bad"
<yorickpeterse>
But you're not really sure if it was that method due to stuff running in parallel
<brixen>
got it
<brixen>
so, the instrumentation bytecode is part of the answer
<yorickpeterse>
Pretty much
<brixen>
instead of the newrelic/skylight approach of having a generic agent, you want to be able to transparently instrument exactly what you want to see
<brixen>
by transparently, I mean without code churn
<yorickpeterse>
Yes
<brixen>
moreover, you want this to happen for you :)
<yorickpeterse>
stuff like New Relic is really just a "monday morning checkup" for me
<brixen>
"oh look", the VM says, "this code is busy, let's instrument it..."
<brixen>
and you see the results
<yorickpeterse>
yup
<brixen>
yup yup :)
<yorickpeterse>
I can get in the right direction using systemtap, but it's a bit tricky to use for proper perf measuring
<yorickpeterse>
especially in concurrent systems
<brixen>
too much actual behavior is opaque to DTrace/systemtap for this
<brixen>
and there's not a reason to go through contortions to make it less opaque for them
<brixen>
just like any other aspect of system engineering, monitoring and analysis needs layers
<brixen>
and you shouldn't use monitoring when you need analysis
<brixen>
which is what the "measure everything" camps tend to do
<yorickpeterse>
True, but at this point it was the only tool I could use so far to get some insight in what's going on without slowing everything down to a crawl
<brixen>
understood
<brixen>
doesn't mean you want to continue that way :)
<brixen>
pick your ruts carefully, you may be in them for a long time
<yorickpeterse>
Oh yeah, I figured that :P
<yorickpeterse>
Pg is one gamble, rbx is the next one
<yorickpeterse>
Granted I still need to fix half of all Gems out there
<yorickpeterse>
well "next one", I'd say "the current one"
<yorickpeterse>
since I've been working towards this for about a year
<brixen>
you mean, concurrency issues?
<yorickpeterse>
Well, it's been a multi-step process
<yorickpeterse>
1) refactor pretty much everything over a 2 year period 2) make sure things can run concurrently 3) get tests running on Rbx, make sure they always pass (instead of treating it as a dirty sock) 4) actually test some non-crucial apps on Rbx
<yorickpeterse>
then came step 5..100: fix a whole bunch of Gems
<brixen>
what does that mean though?
<yorickpeterse>
(or replace them in some cases)
<brixen>
compat issues, other?
<brixen>
are you keeping track of a list somewhere?
<yorickpeterse>
Yeah in my head, gimme a sec :P
<brixen>
heh
<yorickpeterse>
and on random issue trackers on Github
<brixen>
my top 3 are nokogiri, psych, and json
<brixen>
not exactly in that order: psych, nokogiri, json
<brixen>
that order
<brixen>
yorickpeterse: we should centralize that list
<brixen>
in fact, I've been noodling/doodling a dashboard of sorts for Travis
<brixen>
well, Travis/GitHub
<yorickpeterse>
From the top of my head: Nokogiri (obviously this is taking the longest), aws-sdk v1 not being thread-safe, aws-sdk leaking memory, aws-sdk using Nokogiri and most likely crashing, ActiveSupport using ObjectSpace which is slow as shit, euh....I think that's the current list
<yorickpeterse>
basically Nokogiri and aws-sdk v1 are my current targets
<yorickpeterse>
activesupport I've largely taken care of by getting rid of it
<yorickpeterse>
With our background processing apps none of this is really an issue, since they are quite ressiliant. Web apps however require some really careful testing :/
<yorickpeterse>
e.g. our API product currently has a 100% uptime over the past few months, I'd like to keep it that way :P
<yorickpeterse>
One of the biggest wins in this whole process was setting up a CI (Jenkins in this case, brrrr) and making sure that _everything_ we deploy runs on both MRI and Rbx
<yorickpeterse>
and hammering on it every time somebody breaks it so that they fix it
<yorickpeterse>
Instead of "lol it's just rbx I don't care"
<yorickpeterse>
I should really blog about this
<yorickpeterse>
"For those who are interested in such things, I'll note that this grammar is not LL(1); LL(1) grammars are never ambiguous" bingo
<yorickpeterse>
that's the confirmation I needed to ditch operator associativity in LL(1)
<yorickpeterse>
yay
<yorickpeterse>
Allright, parsing question for the general audience (so pg 13+ basically): what ASCII character(s) would be best suited for "epsilon" (basically means nothing/null/nil in the parsing world)
<yorickpeterse>
Right now I'm using "..." but it feels a bit off
<yorickpeterse>
since ɛ is a PITA to type (<- copy-pasted that from Wikipedia because I have no idea how to type it :P)
<|jemc|>
yorickpeterse: make it a \x00 byte - that'll teach 'em! ;)
<|jemc|>
yorickpeterse: are you already using a lone underscore for something?
<yorickpeterse>
|jemc|: No, I thought about using that initially actually
<yorickpeterse>
But it looks a bit weird in cases such as this:
<yorickpeterse>
idents = ident |
<yorickpeterse>
err
<yorickpeterse>
idents = ident+ | _
<yorickpeterse>
Although `idents = ident+ | ...` is not that much better, but it at least stands out a bit more
<yorickpeterse>
It's however confusing due to being a range operator in Ruby
<brixen>
it's confusing to me because I read it as something like "and other things"
<brixen>
or something like that
<brixen>
_ is not bad
<brixen>
I'm reluctant to introduce utf-8 like Agda does
<brixen>
but support is generally pretty good for it and usually you can make a binding of some sort
JimmySieben has quit [Quit: JimmySieben]
<brixen>
yorickpeterse: are you using a literal . for anything?
<yorickpeterse>
brixen: yeah that's another reason for it being confusing
<yorickpeterse>
I want to keep it ASCII-only so it's not a PITA to type
<yorickpeterse>
And no, "." isn't used for anything
<yorickpeterse>
but it's easy to miss
<yorickpeterse>
e.g. some fonts are _really_ bad at rendering commas/dots
<yorickpeterse>
Initially I wanted "$" but that's typically used to signal EOF in grammars
<|jemc|>
yorickpeterse: \x00 byte is in the ASCII table :P
* yorickpeterse
slaps |jemc| and starts getting carried away
<|jemc|>
could always try something like %epsilon
<|jemc|>
or some other way of fulling spelling out what it is but using a marker that differentiates it from rule names or other normal identifiers
<yorickpeterse>
|jemc|: anything that has not a special marker would conflict with defined rules
<yorickpeterse>
e.g. "NULL" could be a ruel
<|jemc|>
yeah, hence the dollar
<|jemc|>
err
<|jemc|>
percent
<yorickpeterse>
so you'd have to use %NULL or %epsilon or w/e, but I don't really want more directives like that
<yorickpeterse>
4 is enough :P
<yorickpeterse>
(I already have %name, %tokens, %inner and %header)
<yxhuvud>
yorickpeterse: you could use ø :D
<yorickpeterse>
heh
<yorickpeterse>
I think I might just use _ in that case
<yxhuvud>
at least it is simple to type at many keyboards.
<yxhuvud>
(altgr-ö for me)
<yorickpeterse>
it's the only character I can see that is 1) easy to type 2) clear to see
<|jemc|>
hey folks, kernel/platform/pointer_accessors.rb says it's automatically generated, but doesn't give tell the names of the file(s) that generate it - anyone know?
<|jemc|>
basic recursive grep is failing me here
<|jemc|>
at this point I'm wondering if the file that generates it has been lost?
<yorickpeterse>
I don't think it's generated anymore
<yorickpeterse>
A certain brixen modified it by hand in 2012
<yorickpeterse>
It hasn't been touched since, and before that it was just added
<|jemc|>
I'm a bit concerned that it doesn't seem to be arch-aware on its own
<|jemc|>
specifically, I'm concerned that it assumes things like int16 == short
<|jemc|>
and I don't know off-hand how all those mappings change on things like ARM or other arches, but I do know you can't take them for granted like kernel/platform/pointer_accessors.rb seems to be doing
<|jemc|>
that is, I think we need to be generating that file at build/install time based on detection of those mappings, or at runtime
<yorickpeterse>
|jemc|: I don't think anybody ever committed the code that generated this :P
<yorickpeterse>
unless the comment is a lie and it was written by hand
<|jemc|>
hmm.. maybe its stolen from the FFI gem where it was being generated
<|jemc|>
I need to see how the gem handles this
<|jemc|>
I mean, I know that rbx doesn't run on ARM yet, but this still seems like a big no-no
<yopp>
Uh. Seems like mmap from ruby-world is not a good idea at all
<yopp>
What's rbx way to handle binary data?
<yorickpeterse>
yopp: capnproto/msgpack/etc
<yorickpeterse>
Rbx provides no built-in mechanism for this, yet
<yopp>
From mmap world?
<yorickpeterse>
The bytecode is some custom made stuff
<yopp>
For example, I've making a big mistake: I'm doing my own data layput
<brixen>
yopp: what are you trying to achieve with mmap?
<yopp>
brixen, I'm experimenting with time-series database. Seems like mmap is very efficient way access storage
<brixen>
sure
<brixen>
but you probably need proper bindings for that
<brixen>
also, there's stuff like capnproto
<brixen>
that can do zero-copy, mmap read directly into data structures
<brixen>
but basically, mmap is going to be a memory pointer
<brixen>
you need some way to read/write structured data
<yopp>
yep
<brixen>
which time-series db?
<yopp>
My own :)
<brixen>
ok heh
<yopp>
I have a problem. Sometimes you need to store changes of some value in time
<yopp>
changes, not "slice of value"
<brixen>
you mean, like a "series"?
<brixen>
I'm not understanding your terminology
<yopp>
To simplify, a "imagine" real-world use-case
<yopp>
You have a barrel, with volume of 2000 liters.
<yopp>
It's empty at the beginning.
<yopp>
You have a sensor, that can detect changes of volume of liquid in this barrel with precision of half of liter (500ml).
<yopp>
At some point of time (X) you're got a truck of fuel (95'), that will fill this barrel
<yopp>
So your sensor will detect changes in that barrel, for example for 10 minutes it takes to fill it full
<yopp>
Since you have a precision of 1/2 of liter, you will have a sequence of changes of this vol by 0.5 in time (jitter, right). For example it took 2000 seconds to fill that barrel
<yopp>
So, ideally, you will have 1000 values
<yopp>
This is time series.
<brixen>
so, you want to update value N of M?
<yopp>
not update. Store history of changes
<brixen>
ie seek to record offset + N * sizeof(N)
<brixen>
history of changes of value N of M?
<yopp>
Yep.
<brixen>
ok, so a sparse matrix
<brixen>
?
<yopp>
More or like
<brixen>
how is your DB better than Tempo, Influx, etc?
<brixen>
ie, what aspect ore you experimenting with?
<brixen>
speed, compression, etc
<yxhuvud>
how many measurements are you talking about? thousands? millions? lots?
<yopp>
yxhuvud, random!
<yopp>
right now a restriction: there only one value per seond
<yopp>
i.e: one value change per second
<yopp>
but, I can store compressed representation of this event: min/max/last/first/first_time/last_time/number_of_events
<yopp>
sum/avg
<yopp>
brixen, haven't seen Tempo, main problem with Inbflux, you can't store all "raw" data. There should be data renention
<yxhuvud>
can't you control what you put into it then?
<yopp>
huh
<brixen>
Defiler linked me to that like a year ago
<brixen>
I forgot the name but he remembered
<brixen>
who needs a memory when your friends have one lol
<yopp>
brixen, I have a real-world problem :)
<brixen>
yopp: what is that re?
<brixen>
the video, memory, rbx, FFI
<brixen>
sorry, I have too many threads today :p
<yopp>
video, but I'm still skipping thought
<yopp>
Guy in the video seems to tell a real story about "real-time" data.
<yopp>
But my problem is not the "real-time" data
<yopp>
It's all about pattrens
<yopp>
It's all about predictions
<yopp>
We have too much data this days
<yopp>
You can measure everything. In realtime, in pasttime in any time
<yopp>
But the problem is: you don't care about exact values of some attribute at some time point
<yopp>
You only care why this value became that value. Why is changed? What make it change?
<yopp>
•it
<yopp>
If you have a lot of data sources, in some cases with some little work, you can tell what the relation between attributes
<yopp>
As a result, if you know what the XYZ value, if you know what the relation between them (F=X*Y-Z), you can predict F.
<yopp>
And that's a point, when fucking terabytes of data will make some sense.
<brixen>
this is basically my point about analysis vs monitoring
<brixen>
either you have a single point in time never to be repeated in the history of the universe, or you have some periodic data
<brixen>
and what you need are the minimum number of measurements to keep tabs on the system
<brixen>
and when you think you have an issue of some sort, you want to perform some analysis
<yopp>
Yeah, I don't care why my server run out of memory. I don't care it was pgsql. I only care that my user_payments_transactions index in pgsql ate all the memory
<brixen>
people think that measure all the things will give you the ability to do any post facto analysis you want
<brixen>
but that's wrong
<yopp>
yep
<yopp>
that's completely wrong
enebo has quit [Quit: enebo]
<yopp>
So basically, you only care about the fact, that next time user_payments_transactions index will hit some point, my server will go out of memory
<yopp>
So I will have that king of "data intelligence", that I want to have
<yopp>
So that's why I want to play with time series data :)
<yopp>
Real-time is easy, mostly
<|jemc|>
brixen: I came back to trying to swap gem FFI for rbx FFI (in case you couldn't tell from my earlier comments)
<|jemc|>
lots of SEGV fun ;)
<brixen>
|jemc|: this is how memory works, you can't write arbitrary values to arbitrary addresses :)
<brixen>
yopp: I think our interests here are remarkable well aligned
<brixen>
er * remarkably
<yopp>
:)
<yopp>
That's good. But I have two problems: I'm a mediocre programmer and very-very shitty mathematician :) (Also my English is bad)
<|jemc|>
brixen: heh, it's just that the exposed APIs are similar, but different enough to be dangerous
<yopp>
And that's a time point when I'm officially drunk and i'll go to sleep :B
<yopp>
G'night
<|jemc|>
I'm curious now to see if the assumptions that pointer_accessors.rb is making about the sizeof various types is even right on my machine...
[spoiler] has joined #rubinius
<|jemc|>
seems okay on my machine
|jemc| has quit [Quit: WeeChat 1.0.1]
|jemc| has joined #rubinius
<|jemc|>
ah, running benchmarks with my laptop crashing from overthermal; just another day in paradise
<|jemc|>
brixen: so API incompatibilities and JIT problems aside, I do see a pretty significant speedup when switching gem FFI for rbx FFI
<|jemc|>
roughly 35% of time spent is shaved off
<|jemc|>
which is a lot more than I expected, to be honest
<|jemc|>
I thought the work wasn't that FFI-bound
<|jemc|>
(from profiling I did several months ago)
<|jemc|>
although I just ran the same benchmark against MRI, and rubinius is still slower
<|jemc|>
although it may not be the fairest benchmark in terms of concurrent load