thsig has quit [Remote host closed the connection]
_whitelogger has joined #jruby
<byteit101>
JRuby is clearly doing something strange with JavaCV, my ruby code calling openCV works always, but java .class works never, and java .jar works only if ruby has called openCV.
<enebo>
Aethenelle: I find the feature a big backwards
<enebo>
big=bit
<enebo>
Aethenelle: Or I should say I might want a SizeTMemoryPointer which just has a read/write
<Aethenelle>
that's what I thought at first too. but with the code they linked and the VISA library I'm working on now it makes a little sense. Just not the monkey patch they use.
<enebo>
Aethenelle: Or a typed TypedMemoryPointer.new(size_t, location)
<enebo>
Aethenelle: but would’nt this last line I provided work better then it would just be a read or write with no param and no way to make a mistake
<enebo>
Aethenelle: unless it is an issue of unions?
BobFunk has quit [Read error: Connection reset by peer]
BobFunk has joined #jruby
<enebo>
Aethenelle: I guess I would even think ptr = TypeMethodPointer.new(struct1, mem_addr); … ptr.recast_as(struct1)
<Aethenelle>
I'm not thinking of their size_t problem specifically... In this library attributes don't always have the same size. I can either write this monkey patch or write out each read/write method by hand
<enebo>
Aethenelle: so the pointers themselves change call to call?
<enebo>
Aethenelle: maybe depending on the result
<Aethenelle>
yes, depending on the args, the out pointer might be a int or a short or...
<Aethenelle>
let me see if i can find a link to this library's docs somewhere...
<enebo>
Aethenelle: ah so a generic method might be better (and more specific typed pointer could be made from it)
<enebo>
Aethenelle: I do get the point now
<enebo>
Aethenelle: I think I even used a library or two like this in the distant past (have not been doing C in a long time)
<Aethenelle>
yes, the use case they provide in the ticket can be solved like you say but it reminded me of another for which this is needed...
<enebo>
Aethenelle: So their ptr.read_type(size_t) is a decent base method and makes sense to me
<enebo>
Aethenelle: I am not sure on your question originally though
<enebo>
Aethenelle: The code you linked to me just says struct support is missing
<Aethenelle>
take a look at the C i wrote, I did a better job with read and write than their monkey patch but I'm stuck on write_type :somestruct
<enebo>
Aethenelle: ah ok
<Aethenelle>
right... that's what I need to add in...
dudleyf has joined #jruby
<enebo>
Aethenelle: Your dyndispatch to id_find_type looks fishy to me
<Aethenelle>
might be... I'm still learning the C side of MRI...
<enebo>
Aethenelle: Since you are deferring to Ruby you can get any result back including fixnum 1 or nil or?
<Aethenelle>
that'll just resolve the type, not the value
<enebo>
Aethenelle: but the method find_type can be changed by any Ruby programmer
<enebo>
Aethenelle: and it can return anything
marr has joined #jruby
<Aethenelle>
ahh... then I just use the ivars directly and implement the parts of find_type I need?
<Aethenelle>
... maybe impl find type in C/Java entirely...
<enebo>
Aethenelle: well I don’t know. I just know you may get a VALUE which Data_Get_Struct might not be able to handle for t
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<enebo>
hmm
shellac has quit [Ping timeout: 260 seconds]
JohnBat26 has joined #jruby
BobFunk has quit [Read error: Connection reset by peer]
BobFunk has joined #jruby
johnsonch is now known as johnsonch_afk
tylersmith has joined #jruby
benlovell has joined #jruby
phrinx has joined #jruby
benlovell has quit [Ping timeout: 272 seconds]
colinsurprenant has joined #jruby
zorak8 has joined #jruby
yfeldblum has joined #jruby
colinsurprenant has quit [Quit: colinsurprenant]
yfeldblum has quit [Ping timeout: 246 seconds]
ludyte has joined #jruby
iamjarvo has joined #jruby
teamon has quit [Ping timeout: 260 seconds]
teamon has joined #jruby
ludyte has quit [Quit: ludyte]
mister_solo has joined #jruby
postmodern has joined #jruby
mister_solo has quit [Read error: Connection reset by peer]
mister_s_ has joined #jruby
BobFunk has quit [Ping timeout: 250 seconds]
vyorkin has joined #jruby
diegoviola has joined #jruby
erikhatcher has quit [Quit: erikhatcher]
yfeldblum has joined #jruby
bpmcd has joined #jruby
colinsurprenant has joined #jruby
yfeldblum has quit [Ping timeout: 244 seconds]
<asarih>
enebo can't help but spoil Friday.
<enebo>
asarih: I noticed that tarcieri paste keeps getting slower and slower over time. I think one day it wil take all of friday to complete :)
<enebo>
tarcieri: is that paste logic multitasking on BTC mining?
<tarcieri>
enebo: lol
<tarcieri>
more like getting throttled by freenode
<enebo>
tarcieri: I think the non-color on on rbx goes quicker so ascii codes for bonus throttling
<tarcieri>
hahaha
subbu is now known as subbu|lunch
ludyte has joined #jruby
kfpratt has quit []
subbu|lunch is now known as subbu
subbu has quit [Ping timeout: 258 seconds]
subbu has joined #jruby
vyorkin has quit [Quit: WeeChat 1.0.1]
colinsurprenant has quit [Quit: colinsurprenant]
colinsurprenant has joined #jruby
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
robbyoconnor has quit [Quit: Konversation terminated!]
blinsay_ is now known as blinsay
purezen has joined #jruby
iamjarvo has joined #jruby
<purezen>
Hi guys!
<purezen>
I am an OSS enthusiast and am keen to contribute to Jruby. Please help me with the same.. I am willing to work on any project under the Jruby umbrella as long as I can get some help with it.. and it doesn't have a high contribution bar.. Thanks :)
<headius>
purezen: hi there!
<headius>
purezen: there's lots of issues in the tracker, of course, but a big way to help right would be to help us confirm Ruby 2.0/2.1 features are working as expected
errstr has quit [Ping timeout: 245 seconds]
<purezen>
headius: Hey! Nice to hear from you :)
<headius>
purezen: yes, good to see you here
<purezen>
headius: You mean in the jruby-core, right?
<purezen>
headius: Yeah, thx ;)
<headius>
that's right
<headius>
join the team!
<headius>
right now we're trying to start stabilizing master for a preview release next month
<headius>
I'm working on JIT, enebo and subbu have been working on the new runtime, others are working on 2.0 and 2.1 features
yfeldblum has joined #jruby
<headius>
we need to start verifying that important libraries work, like rails and AR-JDBC
<headius>
and if they don't, make them work :-)
<Aethenelle>
syslog is/was missing a chunk...
<enebo>
purezen: AR-JDBC seems to be a project where they don’t have the time
<purezen>
Hmm.. Cool! I shall look into that.
<headius>
Aethenelle: that would be another good one, since it's just FFI
<purezen>
enebo: Hey, nice to hear from you, too :)
<enebo>
I think latest rails is having issues because not enough to time make sure trunk is ok between various rails versions
<Aethenelle>
headius: yeah... mostly copying the file from rbx but...
<purezen>
enebo: Hmm.. ok..
<enebo>
Things are not coming out of my head clearly but I think that made sense
errstr has joined #jruby
<purezen>
enebo: Haha.. get the idea.
<purezen>
And what about Warbler guys? Had some conversation around the gsoc period with you guys as well.. and you suggested that as well.
<Aethenelle>
purezen: if you feel like a drink from the firehose. I could use another pair of eyeballs on Module#prepend. The PR I already have in place doesn't match MRI and needs to be reworked
mister_s_ has quit [Read error: Connection reset by peer]
mister_solo has joined #jruby
<purezen>
Aethenelle: Hehe.. would like to talk about that with you :)
<Aethenelle>
the current PR or the correct way?
<purezen>
Aethenelle: Umm.. didn't get you there
dfr|work has quit [Ping timeout: 272 seconds]
<Aethenelle>
my current PR for Module#prepend reworks inheritance into a live tree. Unfortunately, I didn't know MRI uses static chains for inheritance and that has some odd consequences
<Aethenelle>
so I get to rewrite it to match MRI behavior because that version won't be in MRI until at least 2.3. Which likely assumes I write a patch for MRI for this as well.
<purezen>
And any other projects that I can get started with? Also, I don't have much idea of working with the core atm.. I hope that this shall be fine for a newbie? headius, enebo
<purezen>
Aethenelle: Well.. can I get a link to the PR?
<Aethenelle>
purezen: You can go through the coercion stuff and make sure it matches MRI. That'd be a good way to get your feet wet in jruby-core
<headius>
purezen: warbler is mostly just the packaging... the real win would be if we could make jruby-rack as fast as the direct alternatives (puma, torqbox)
<Aethenelle>
I have the correct logic started but I haven't pushed it yet cause it's still wonky
<purezen>
headius: Oh, yeah! There was performance work to be done on the jruby-rack and the ar-jdbc iirc.. I also came across the some perf. related work involving the templating libraries of Rails too mentioned in the gsoc idea list for RoR.. Would be great to get into that stuff :)
dfr|work has joined #jruby
<purezen>
Ok guys.. Got to go now. Bye!
purezen has quit [Quit: Page closed]
<headius>
ok JIT status
tylersmi_ has joined #jruby
<headius>
gem install works with normal JIT thresholds...maybe 50 things JIT and must be working ok
tylersmith has quit [Read error: Connection reset by peer]
<headius>
threshold=0 hits signature-length problems in the generated bytecode...I will get that to fail gracefully and *should* be able to come up with a general fix before preview
<headius>
threshold=0 is tricky because it will try to compile class bodies, which often have giant array initialization and stuff
<headius>
subbu, enebo: any reason you can think of that we couldn't have a single piece of code for dispatching blocks AND the others?
<headius>
methods, class bodies, module bodies, script bodies, evals all go into *IRMethod, but blocks end up in *IRBlock with just slightly different logic
<headius>
I know we have to extend BlockBody, but we could have an IRBlockBody that wraps an *IRMethod and then it would get JIT for free
<headius>
though I'm not sure what jitting just a block would look like with our scope and var optimizations
<headius>
chrisseaton: can rubytruffle optimize a block within a method that stays interpreted?
<headius>
i.e. the block compiles before the surrounding method
<headius>
the other possibility I've considered is making block hotness trigger method JIT, similar to how rbx finds inlining paths
<subbu>
headius, compiled blocks should work with interpreted method bodies as long as the opt passes sync up .. but i've recently fixed most passes so that they can be independent.
<subbu>
but, won't know what else needs fixing up without tyring it.
<headius>
yeah
<headius>
I think you're right
<headius>
the local optimizations for block scope should not affect surrounding method
<subbu>
but, it looks odd to inherit blocks from IRMethod.
<enebo>
headius: Per your IM question. What you have on your branch should be fine.
<headius>
I was just thinking in terms of having a single JIT pass
<headius>
rather than some other wonky logic just for blocks
<subbu>
but that can be fixed withe some minor renaming/restructuring of classes.
<headius>
we've wanted blocks to JIT independently for years
<headius>
half the benchmarks out there are just using benchmark.rb and root-scoped blocks that never JIT for us if not run directly
<headius>
subbu: it's not anything I'd make a priority right now
<subbu>
yup, post release.
<headius>
but it's somewhere we should go... 100% independently-JITable scopes
<enebo>
headius: subbu: I would like to unify blocks and methods as one unit per runtime class structure. I don’t know how that affects JIT
<headius>
enebo: any unification should make things simpler
<headius>
there's almost no block-specific logic in JIT now, other than instructions we only encounter in blocks
<enebo>
The second part is considering how JIT can do parameter binding in IR instructions instead of hard-wired code
<enebo>
interp would not want to do that though
<headius>
enebo: FYI, JIT logic just dives right in and does prepareForCompilation, and that seems to be working
<headius>
I'm removing all the remnants of my pessimistic pre-JIT stuff
<headius>
this is looking surprisingly good
<headius>
the actual failure I get with threshold=0 is the same as a spec I'm trying to pass, regarding scoping of defs
<enebo>
headius: yeah that seems appropriate to me. I guess ultimately we might want to talk about JIT queue and remove or change from synchronization on IRScope
<headius>
JIT queue could be made atomic
<headius>
that might be simplest
<headius>
it's probably close now with the JIT turning off threshold-counting before submitting the job, but I think it's probably fairly easy for two JIT threads to do that at once
<enebo>
headius: the interp/JIT access issue is solved as-is but for two threads JIT’ing we need a little more
<headius>
I don't know if it's really justifiable to have IRScope claim to be thread-safe while being mutated
<headius>
right
<enebo>
headius: it is not thread-safe at all
<headius>
right I mean I'm not sure it's valuable enough to do the extra work
<enebo>
headius: It is just that we sync on the prepare methods so interp state is saved off
<subbu>
i think with a queue, we can get around having to make it thread-safe.
<enebo>
headius: oh yeah agreed. Not a short term or perhaps even worthwhile long-term
<headius>
subbu: I think I have two JIT threads by default right now but I've never done any analysis to see if that's too many or too few for typical JIT loads
<subbu>
i will be popping in and out of this channel.
<headius>
JIT tends to come in batches, at 50 calls, 100 calls, 150 calls, etc, trailing off as everything used gets compiled
<headius>
I'm not sure how much value there is in having two threads work on jitting that stuff
<enebo>
headius: most of the mutable state stuff is undesirable at a high level but pragmatic in that there is a ton of information to make safe. So mutable is faster even if more buggy
<headius>
enebo: so did you mean that interpreter has to pass through at least one lock for every entry, yeah?
<enebo>
headius: I am also excited to add some simple JIT profiling to only start JITing once rate of new method defs slow down
<headius>
to get interpreter context etc
<enebo>
well it does go through a synchronized method atm yeah
<headius>
enebo: yeah, that will be useful... maybe a timer that counts down ms and if there's no new defs during that time it flips JIT on
<enebo>
headius: yeah
<headius>
like, 10ms or 100ms "def quiet" period
<headius>
oh btw, interesting side effect of new JIT:
<enebo>
headius: It will not generate a lot of code which is only used at startup which will be neat to see if that changes much
<enebo>
I hope it will lead to much less classes overall
<enebo>
Best case is hot code optimizes better perhaps?
<headius>
I think eval could be made to JIT if we wanted to do caching
<enebo>
headius: yeah the fingerprinting seems like biggest issue there
teamon has quit [Ping timeout: 260 seconds]
teamon has joined #jruby
<cremes>
headius: +1 on block JIT’ing… will make jruby look like a rockstar in the micro-benchmarks :)
<chrisseaton>
headius: yeah blocks have no special treatment and are optimised independently of the method containing them
<headius>
I don't care if we look like a rockstar...I just don't want us to show interpreter numbers when people go benching
<headius>
chrisseaton: ok, figured...sounds like we should be able to as well
<headius>
obviously we'd both have some deopt requirement if the surrounding body wasn't compiled as well
<chrisseaton>
headius: we're going to start compiling loop bodies as if they were independent method soon as well - a kind of OSR
<headius>
ahh yeah, we want to do that for other reasons as well, like breaking a large method into separate JVM-level methods to get around bytecode limits
<chrisseaton>
speaking of benchmarking, we're going to start a kind of speed centre soon - I'll give you a look a few days before it goes public
<headius>
but yeah, hotness of a loop body, definitely useful to us too
<headius>
chrisseaton: sounds great...if we're able to get non-RubyTruffle number trends with that, it would be very useful
<headius>
I think everyone cites the pypy pages as a gold standard for historical benchmark reporting
<enebo>
chrisseaton: headius: We and to make a synthetic_call instr which allows us to do non-backtrace calls. So we can then generate synth calls to BBs to break a scope apart
<headius>
yeah, that would be a good representation
<chrisseaton>
yeah, we're running 15 different configurations/implementations of Ruby I think
<enebo>
but it is more of a soln for breaking big methods than neccesarily making something faster
<chrisseaton>
Truffle doesn't always come out on top! And it highlights out warmup problems so we're not hiding anything.
<headius>
enebo: kinda explicit control transfer to next BB with exit guarantees, so I could turn leave blocks into their own JVM method bodies
<headius>
chrisseaton: sounds great
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<chrisseaton>
we do caching of intermediate representation, so part of the idea is that the loop body has already been optimised and is ready to inline into the parent method by the time we want to start compiling the parent method
<enebo>
chrisseaton: how do you store your cache?
<cremes>
chrisseaton: excited to see your benchmarking site go live
<headius>
chrisseaton: yeah, that's what enebo fixed up for me this week... we keep a master copy of the IR and do opto against clones of it
<enebo>
chrisseaton: Do you persist it?
<headius>
so we can reoptimize or back off
<headius>
some day, anyway :-) nice part about the new IR runtime is that it's going to be much easier to do this stuff
<headius>
JIT took me half a year to get right for JRuby 1.1. I think the bulk of work on this JIT was about a month
<chrisseaton>
not persisted, but generally IR graphs are cached and reused - so if you deoptimise and change one call site, the rest of the graph might still be useful
<chrisseaton>
it also talks about how we prioritise compilation of different methods
<enebo>
chrisseaton: so for us that is possible for us to get to at scope boundaries (e.g. method / closure) but one of our passes has relationship between closure and method which contains it
<enebo>
chrisseaton: but I guess since we said we compile these independently you would have guessed that
<headius>
compilation priority would be good to read through
<enebo>
chrisseaton: oh hotness stuff in it too
<enebo>
chrisseaton: subbu did a hotness profiler based on our thread_poll instr which is not so far off of putting a counter on back edge of a loop (although there are a few places thread_poll is inserted)
<chrisseaton>
enebo: yeah, the block that is compiled can use the interpreted frame from the interpreted method - so locals might slower
<enebo>
chrisseaton: yeah a very real possible scenario for us
<subbu>
ya, that profiler code needs revisiting. it is circa 2011/12, i think. ir has changed a bit since then.
<enebo>
subbu: but the idea I think is pretty good
<headius>
chrisseaton: have you done any work on how to support cross-thread signalling efficiently?
<headius>
specifically Thread#raise and friends
<enebo>
subbu: I have never thought of another one past perhaps counting call invocations from a method
<chrisseaton>
we'll use the same mechanism as we do for ObjectSpace - stop all threads in a safe point and communicate there
iamjarvo has joined #jruby
<enebo>
subbu: since so much of Ruby is actual invocations counting number from a method would probably work
<headius>
chrisseaton: ok...that's the best I have too
* subbu
is distracted in parsoid land for a bit..
<headius>
the polling is done via a switchpoint...it would invalidate the site at that point and any JVM JITed version of it, but ideally that would just affect one thread using that code
<chrisseaton>
that's free of course - it reuses the GC safepoint, and it works within a free hundred instructions max so it's as quick as you could want
<headius>
I'm not sure how bad it starts to look if you trigger it often :-\
<enebo>
ok distracting myself to beer store
<headius>
most people aren't doing a ton of kill/raise though
<enebo>
afk a while
<chrisseaton>
i should implement that though - someone might try and ambush me with it saying it will slow us down when we do
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<headius>
chrisseaton: it would be worth getting around to :-)
colinsurprenant has quit [Quit: colinsurprenant]
teamon has quit [Ping timeout: 260 seconds]
zorak8 has quit [Ping timeout: 245 seconds]
e_dub has quit [Quit: ZZZzzz…]
erikhatcher has joined #jruby
teamon has joined #jruby
<blinsay>
hey y'all. got an annoying little interop bug. Using a Java library (the AWS SDK) that expects to be able to close an input stream twice, but closing an InputStream I got via IO.to_inputstream throws an exception
<headius>
blinsay: hmmm
<blinsay>
should I throw up an issue or try to take a stab at PR?