<brixen>
I've already wrestled 3 enterprise applications to the ground and they are crying uncle now
<yorickpeterse>
haha
<brixen>
by 10:30 in the morning
<yorickpeterse>
(I start at ~10:10)
<|jemc|>
brixen: heh, rubymotion faster than swift :P
<|jemc|>
although I guess I shouldn't cackle too much - myco is certainly slower than ruby right now
<brixen>
yeah, Apple will make it fast
<brixen>
|jemc|: so, do you want to help goyox86 write up Part II of Metrics + InfluxDB using docker containers?
<|jemc|>
brixen: sure I'm happy to help; although the act of blogging itself is not really my forte
<|jemc|>
I think goyox86 said he had issues containerizing his solution, so I can certainly help with that
<brixen>
that would be awesome
<brixen>
I don't have any great love of blogging either but the thirst for knowledge is strong :)
josh-k has quit [Read error: Connection reset by peer]
<|jemc|>
heh
josh-k has joined #rubinius
<|jemc|>
so I got pegleromyces compiling pretty fast .rbc parsers last night but my AST building is still slow (it's done as a second step after the parse is done)
<|jemc|>
but the Processor is written in Myco and I think the extra layers of indirection are hurting me there
<|jemc|>
I need to figure out how to speed up the language itself before the processor will get much faster
dzhulk has joined #rubinius
<|jemc|>
the biggest issue is that for virtually every method call in Myco, there is a wrapper method that does a few checks and hash lookups for various kinds of method transformations, then calls the actual method inside
<brixen>
ah yeah, that will be tough to make fast
elia has quit [Quit: Computer has gone to sleep.]
<|jemc|>
I think I need to figure out how to add the wrapped functionality that I need by transforming the bytcode of the method itself
<brixen>
are the lookups strictly necessary at call time?
<brixen>
or can they be cached?
elia has joined #rubinius
<brixen>
one of the things I'm adding to the new bytecode is separate lookup+cache, cache, and call insns
<brixen>
so you can compose your own lookup, cache, call
<|jemc|>
well, not all checks happen for every call
<brixen>
are they cacheable though?
elia has quit [Client Quit]
<|jemc|>
for example, you can turn memoization for a method on and off by setting a property
<|jemc|>
brixen: yes
<|jemc|>
so the instructions sound nice
pwh has joined #rubinius
<brixen>
ok, that's a good approach then
elia has joined #rubinius
<brixen>
2nd, can you use a more efficient search than hash lookup?
<brixen>
another thing I'm adding is a good, fast set :)
<|jemc|>
well it doesn't need to be a ruby Hash - could be another similar data structure
<|jemc|>
with @my_memos being actually an instance variable of the Meme object instead of the instance itself
<|jemc|>
do you think it's feasible (in this, and in other cases) to write some helpers for myself to transform the bytecode of an already-encoded CompiledCode for which I do not have the AST?
<headius>
it's ok if the method gets called twice, right? Because that's obviously not thread-safe
<|jemc|>
headius: yes, the execution is not thread safe yet
<|jemc|>
the mechanisms in place are placeholders for now - I was hoping to get enough of the language in place to bootstrap the parser
<headius>
I'm not sure how you'd make that safe without a lock, though, since it involves a call rather than just a value
<headius>
sure, that's reasonable
<|jemc|>
I'm on the fence about parallel models now - I never really disliked locks before I started working with czmq
<headius>
parallel isn't the problem...shared mutable data is the problem
<locks>
</3
<headius>
locks: hahah
<|jemc|>
(which uses objects that are directly owned by one thread only and pass messages to eachother over in-process sockets)
<headius>
mmm
<headius>
almost an actor model
<|jemc|>
yes
<|jemc|>
zactor is one of the czmq 'classes'
<headius>
makes sense then
<|jemc|>
to approach something like that in ruby, you'd probably use Queues, but you need a way to (1: freeze passed data) or (2: completely transfer ownership of data) to make it safe
<|jemc|>
Queues or Rubinius::Channels
<headius>
basically the same thing
<|jemc|>
in Ruby it always seems like there are easy ways for users to shoot themselves in the foot with threads - it's hard to enforce such rules by anything other than convention and education
<headius>
well, and having the right tools...most of the good threading utilities for Ruby have only been created in the past couple years
<headius>
e.g. there was no thread-safe hash impl until we released thread_safe gem, no atomic references until we released atomic gem
<headius>
people are using them more and more now
<|jemc|>
yeah, so where I was going with this is that I'm still torn about the best way to provide a nice path and good conventions and tools for dealing with parallelism in Myco
<|jemc|>
even though I doubt people will be using it for its speed any time soon ;)
<|jemc|>
would still be nice to have those mechanisms in place from the start
<headius>
ahh yes
<headius>
have you seen how rust handles shared objects?
<|jemc|>
no, haven't dug into rust yet
<headius>
references get handed off explicitly, probably similar to czmq
<headius>
they have the benefit of compile-time errors, which might be harder to do in a dynlang, but it's a nice approach
<|jemc|>
yeah, it pretty much has to be made explicit to do it right
<|jemc|>
but in ruby it's hard (from the library's vantage) to make sure the caller actually gives up its reference
lbianc has joined #rubinius
<|jemc|>
in czmq for example, you always pass in address-of the thing you're passing and it will NULLify your pointer
flavio has quit [Quit: WeeChat 1.0]
<|jemc|>
which doesn't make it impossible to circumvent the protection, but it becomes easier to be protected than to not be protected - and I think that's the hump we have to get over
<|jemc|>
I don't need to fully prevent users from shooting themselves in the foot - I just want it to be easier and more fluid for them to hit their target
<headius>
you could pass current scope and variable name, which would allow clearing it...but that would probably be pretty inefficient
<headius>
nothing you can reallly do about libraries written in other langs though
<|jemc|>
headius: I've also thought about a delegating container that 'knows' what thread owns it and will raise if you try to call anything on it from the wrong thread
<|jemc|>
still not ideal from an efficiency standpoint passing through that extra check, but maybe a bit better
<headius>
yeah, like a thread ID in every object or something
<|jemc|>
yeah, or at least every mutable object
<headius>
sure
<|jemc|>
brixen: *nudge* *nudge* low-level thread ownership in rbx3 *nudge*
<brixen>
|jemc|: yeah, yeah, it's on the list from a long time ago :p
<brixen>
I wos told by ko1 that my idea totally wouldn't work
<brixen>
so, we'll see
havenwood has joined #rubinius
<|jemc|>
sure, I know I'm not the first to come up with such an idea
<|jemc|>
just wanted to get in a few nudges of my own ;)
benlovell has quit [Ping timeout: 256 seconds]
amsi has joined #rubinius
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #rubinius
<headius>
what was your idea?
<headius>
brixen: ^
<headius>
I don't see why a thread owner would be impossible, but it does add size to every object header
lbianc has quit [Quit: ChatZilla 0.9.91 [Firefox 24.8.1/20140923194127]]
<yorickpeterse>
pwh: basically this is related to RubyGems trying to auto-compile native extensions, a anti-feature introduced several months ago. However, it should be disabled by default in current versions
<yorickpeterse>
I don't remember the exact details, but on Rbx it gets super confused and downright fucked up things (inc my production env, leading to downtime)
<|jemc|>
I wonder why Rubinius::Profiler::Instrumenter with graph:false gets my myco module/class names but with graph:true they all show up as <anonymous module>
<|jemc|>
time to check the source...
<pwh>
okay so I set GEM_HOME to the vendor/ dir where everything was being dumped for the rails app
<pwh>
ran gem pristine --all
<pwh>
and that seems to have cleared up those gems
<|jemc|>
pwh: looks like it's trying to parse shell code as ruby code
<pwh>
yeah which is really weird
<pwh>
and I don't know why :(
<|jemc|>
ah, it's your rbenv shim
<yorickpeterse>
pwh: did you rm -rf vendor/bundle before switching to rbx?
GitHub172 has joined #rubinius
<GitHub172>
[rubinius] brixen pushed 1 new commit to master: http://git.io/aupIrQ
<GitHub172>
rubinius/master 891d9dc Brian Shirai: Updated rubygems to 2.4.5....
GitHub172 has left #rubinius [#rubinius]
<pwh>
I did not
<|jemc|>
pwh: you won't be able to run it that way `rbx -S rails s` while using rbenv
<yorickpeterse>
pwh: nuke it, then run bundle install
<pwh>
k lemme try that
<|jemc|>
because `which rails` is your rbenv shim rather than whatever/path/to/bin/rails.rb
<|jemc|>
yorickpeterse: does -S work as an RBXOPT, or is it only the -X opts that work?
<pwh>
should I ever be using -S with rbenv?
<|jemc|>
pwh: you can try `RBXOPT=-S rails s`
<brixen>
|jemc|: RBXOPT should only be -X
<|jemc|>
ah, nvm then
<brixen>
-S is a Ruby option
<brixen>
RUBYOPT should respect it
<|jemc|>
pwh: you can try `RUBYOPT=-S rails s`
<yorickpeterse>
pwh: No, you should just use `ruby` or `brx`
<yorickpeterse>
* rbx
<brixen>
a good solution is to just use chruby and not rbenv
<brixen>
why rbenv even still exists makes me :(
<pwh>
yeah been wondering if that would make my life easier
<brixen>
there is literally no sense in the rbenv shims crap
<yorickpeterse>
but...but...shims
<|jemc|>
pwh: chruby is the rbx-approved approach, but I use rbenv, for what it's worth
<brixen>
you can actually run rbx from a single dir with a *single* env var mod to PATH
<brixen>
|jemc|: monday I ran an internal clinic, out of 40+ people, 5 didn't have rbx installed, 5 were using rbenv, 5 spent 30+ min trying to install it
<brixen>
on os x
<brixen>
makes me so :(
<brixen>
in case you don't realize it, those 5 were the same 5
<|jemc|>
brixen: I take no issue with your arguments against rbenv - personally it hasn't caused me enouigh trouble to switch away from it
<brixen>
I swear I could maintain rbx pkgs for every platform in use in the time I've wasted on RVM and rbenv issues
<brixen>
I hate wasting time on it
<|jemc|>
I have no problem with rbx saying - "just use chruby"
<brixen>
worst part is that most people using rbenv have no idea why they are using it
<brixen>
they have no concept of what the hell shims are
<brixen>
or why they have to do magic steps
<pwh>
yeah... running into a bunch of issues with the shim setup right now
<pwh>
if I switch to chruby, what's the workflow for grabbing a locally built rbx and using that successfully
<brixen>
pwh: super easy
<brixen>
add the path to RUBIES array
<brixen>
in my chruby setup, I've got all that
<brixen>
ruby-install'd rbx and mri, my dev rbx, hand built mri
<brixen>
all mixed happily together
<|jemc|>
brixen: to that point, I honestly didn't realize chruby supported .ruby_version (my main reason for using rbenv)
<|jemc|>
so yeah, your point is well-taken
<brixen>
|jemc|: cool
DanielVartanov_ has quit [Remote host closed the connection]
<brixen>
|jemc|: not to introduce scope creep, but containers for both graphite and influxdb would be stellar :)
<|jemc|>
brixen: the graphite container I linked to earlier should require no rbx-specific configuration; just run the docker container with the sample command from its README, then run rbx with the right RBXOPT
josh-k has quit [Read error: Connection reset by peer]
josh-k has joined #rubinius
<brixen>
yeah, that totally sounds cool
<goyox86>
Hi people!
<brixen>
just saying some people may want to use influxdb
<brixen>
I may play around with it, too
<|jemc|>
brixen: ah, I misread
josh-k__ has joined #rubinius
<brixen>
I'm hoping to advance the idea that SaaS does NOT mean, "I run your code on your servers."
<brixen>
SaaS should be about, uh, *services*, to a subscription model for running your code on your servers
<|jemc|>
hi, goyox86
<brixen>
why should I need to be your customer to use some service that I expect to interoperate with my services
<brixen>
by which, I don't mean I won't pay you, but I don't need to have customer service account with you
<|jemc|>
goyox86: I'm working on docker related stuff - may or may not have some questions for you about influxdb setup - we'll see
<|jemc|>
goyox86: first question is though, you haven't started making any docker containers already, right?
josh-k___ has joined #rubinius
<goyox86>
<|jemc|> nope
<goyox86>
brixen: Do you have any docs you can sahare about the new instrcution set :)