<GitHub24>
jruby/master 8e70078 kares: split rubyopt string once + use length == 0 instead of equals ""
subbu has quit [Ping timeout: 276 seconds]
ITXpander has joined #jruby
pitr-ch has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
pitr-ch has joined #jruby
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 276 seconds]
lance|afk is now known as lanceball
yfeldblum has joined #jruby
Lan5432 has joined #jruby
<donV>
Hi all!
<Lan5432>
Hello, donV, anything you need?
<enebo>
donV: I am fairly sure I know what is wrong with #1981
<donV>
Hi lan5432 ! Not really, but thanks for asking :)
<donV>
enebo: Great!
<donV>
What?
<enebo>
donV: we only update this primitive setup array based on encountering a newline node
<enebo>
donV: so in Ruby with source we see one and all the comment lines and unseen lines get nil values
<enebo>
donV: so we know those lines don’t really count as needing coverage
<enebo>
donV: but it your source has no newline nodes encountered we never set up this primitive array
<enebo>
donV: the related issue is any extra comment lines after last encountered newline node also will not get elements in that primitive array
<enebo>
donV: really the first case is just a variant of the second case
<enebo>
donV: so we need to at end up parsing call something to just update the primitive array to add elements form what it already has for the primitive array to the last encountered line in parsing
<enebo>
donV: then I think it will work as expected
<enebo>
donV: this may also be simple to fix on 1.7 as well as 9k since it is not really a big parsing change
<donV>
cool.
<donV>
enebo: Related question: Is coverage affected by the “—debug” flag? I currently get 0% coverage without the “—debug” flag.
<enebo>
donV: you need —debug on jruby at least
blandflakes has joined #jruby
<donV>
enebo: OK, but I think that is jruby only.
<enebo>
donV: coverage will create an array marking code/not-code and then event data while exectuing will end up marking every code line
<enebo>
donV: it is because we do not on-demand instrument the event logic on 9k
<enebo>
donV: on 1.7 we actually use wrappers
<enebo>
donV: so one future in 9k is we might be able to invalidate a compiled method and instrument it on demand
<enebo>
donV: on truffle they have an even less invasive fix perf wise but still you can count eventually on not needing a special flag
<enebo>
donV: at least when we get around to addreassing it
<donV>
enebo: Sounds absolutely great! In the future :)
<enebo>
endless futures :)
<donV>
enebo: Also related: What tests cover coverage, and are we running/passing them?
blandflakes has quit [Client Quit]
<enebo>
donV: yeah that is a good question. I have not checked yet
blandflakes has joined #jruby
<enebo>
donV: I am hoping MRI and spec have some at least
<enebo>
donV: if not then we need some…I am still just making your test case pass
<donV>
You are my hero!
robbyoconnor has joined #jruby
robbyoconnor has quit [Remote host closed the connection]
robbyoconnor has joined #jruby
<chrisseaton>
enebo donV you could just have a switch point on every line couldn't you? would slow down the compiler a bit, but maybe not too much
subbu has joined #jruby
<enebo>
chrisseaton: yeah with invokedynamic we can
<enebo>
chrisseaton: two issues is we are trying to not use indy so much we continue to slow down warmup and secondly and somewhat related it makes the handle chain a bit bigger
<enebo>
chrisseaton: presumably over time perhaps it will be no cost issue
robbyoconnor has quit [Remote host closed the connection]
robbyoconnor has joined #jruby
pitr-ch has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<chrisseaton>
shame you're having to try to avoid indy
<enebo>
chrisseaton: yeah too bad we cannot use it for everything but for now we just have to be more strategic
djellemah has quit [Read error: Connection reset by peer]
<enebo>
chrisseaton: over time it has improved so I am hopeful it will keep improving
<enebo>
donV: looks like I solved this
<donV>
enebo: Woohoo! That was fast!
<Lan5432>
I have a pull request regarding interface and "new" method, can I just do the request or is there anything else to do?
<enebo>
donV: embarrassingly so
<enebo>
donV: this has been open forever
<donV>
:) Yes.
<enebo>
donV: I think we both thought this involved eventing of newlines via line events in TacePoint
<enebo>
donV: If I had to guess I would say since you pass in __LINE__ and it is 3 or so we must be using 3 as our index for coverage so we add those extra lines
<enebo>
err sorry 4 since def a is really a line later than what you specify
<enebo>
donV: so enhavement for you code is probably to use __LINE__+1
<enebo>
donV: I could just reduce the size of coverage primitive array but I suspect everyrthing would go to hell since the line instr emitted would still be +4
<enebo>
donV: so our coverage data would need to store that we are parsing at an offset and not 0
<enebo>
donV: unsure how rough that will be to fix but I think at least I can see the problem fairly clearly
<Lan5432>
Could you help me about pull requests, please?
<donV>
enebo: Sounds hopeful :)
<enebo>
donV: I will look at it quickly after this. I guess on MRI has any tests for coverage
<enebo>
on/only
djellemah has joined #jruby
<donV>
enebo: But we run MRI tests, right?
<enebo>
Lan5432: about opening one?
<enebo>
donV: well we do run MRI tests but not every single one
<Lan5432>
Yes, I wanted to do it along your lines, and it's my first pull request
<enebo>
donV: with luck we exclude a failing test
<Lan5432>
I have a modification on one of the files that fixes the interface "new" problem (or might fix it, at least)
<enebo>
Lan5432: ah yeah. So my recommendation is that you put your patch on a branch
<enebo>
Lan5432: then in github UI you can submit that branch as a PR I think with a click
<enebo>
Lan5432: but as a branch it is simplest since it will not mess up your master until it is resolved
<enebo>
Lan5432: Also any commits you add to the branch suddenly show up in the PR (which is generally a good thing for addressing comments)
<Lan5432>
So in my fork, I set up a branch with that patch, and then submit it as a pull request
<enebo>
Lan5432: yeah
<Lan5432>
Understood, sorry for the newbie question XD
<Lan5432>
I also got a ruby spec for that new behaviour, as requested
<enebo>
Lan5432: yeah no problem. I think this could probably be made easier somehow on github too like selecting a commit be pushed as a PR and have it make the branch for you
<enebo>
Actually perhaps they have something like that :)
<Lan5432>
Yeah, I will search for something like that on my IDE as well. I hope this fix is good enough.
<enebo>
Lan5432: I just tried on web and do not see any UI for that
<enebo>
Lan5432: I guess many people probably don’t have a single commit PR perhaps so maybe not common enough
<enebo>
chrisseaton: in this example bot results fold into a single value right..so this is just the overhead of calling .eval in graal.js?
<chrisseaton>
yeah, it's designed to highlight the overhead, which is zero
<chrisseaton>
Lower down you can see some new functionality though
<enebo>
ah ok
<chrisseaton>
execjs doesn't allow you to return a function to Ruby - we do
<enebo>
chrisseaton: do you know if graal.js has any extra stuff for asm.js?
<enebo>
chrisseaton: I mean no doubt Graal reaches same result anyways mostly but it would be a lot faster to warmup
<chrisseaton>
I don't think so, but not sure
<chrisseaton>
It's kind of against the Truffle philosophy to make any up-front assumptions, even when they make sense, for the sake of implementation simplicity
<chrisseaton>
Like we implement all Ruby calls as if they were a #send, even though the method name can't change if they're normal calls
<enebo>
chrisseaton: I don’t remember but asm.js I think flags the subset usage as such
<enebo>
chrisseaton: so it is not really cheating is properly deliineated I guess
<enebo>
s/is/if
<chrisseaton>
yeah, it's not about cheating, but keeping the impl simple
<enebo>
chrisseaton: do you delineate internal rbx calls vs normally visiable mri ones?
<chrisseaton>
if you can speculate and find the same types, then that's probably better, as long as startup time isn't destroyed
<enebo>
chrisseaton: or do they all show up if tracepoint is on?
<chrisseaton>
no, but we do treat rbx primitives differently as they have different call semantics
<enebo>
ok
<chrisseaton>
yes keeping them out of things like tracepoint is an open question
<enebo>
chrisseaton: it may be that it is a mode
<chrisseaton>
finding them is easy, we just haven't decided what is best yet - I think rbx don't hide them
<enebo>
chrisseaton: since debuggers may not care about what internals a call flows through
<enebo>
debuggers == people debugging
<enebo>
other might
<chrisseaton>
a flag makes sense
<chrisseaton>
we already have a flag to load them from disk rather than the jar, as that makes debugging easier (backtrace lines are normal links you can click in an ide then)
<enebo>
chrisseaton: yeah I think by default I would hide them but make them visible via flag as a nice deeper tool
<enebo>
no one shoudl care what the impl is doing unless the impl is wrong
<enebo>
although in MRI what is happening internally does peek out at times so it is a fuzzy area
yfeldblum has quit [Ping timeout: 268 seconds]
<enebo>
we have been called out on not doing dyndispatch because someone noticed internally mri is making a method call we figured out we can just directly call it
pitr-ch has joined #jruby
<enebo>
that priobably is one problem truffle won’t have except for all the other calls from the extra stuff impld in ruby
<enebo>
donV: If I fix this second bug will you make specs for this stuff?
<enebo>
:)
<donV>
:)
<enebo>
donV: Assuming I can do it without massive work that is
<enebo>
donV: we passed all but two tests in MRI and neither seem to be related to this issue
<enebo>
donV: and spec appears to have no specs for cioverage module
<donV>
I can investigate :) Am a bit swamped at work, but I should be able to justify this :)
<enebo>
donV: yeah I want to finish dstr dedent and windows this week so we can release next week but when I saw how old this issue was and your comment asking I thought I should look at it
<donV>
enebo: So, best place for coverage tests/specs are in Rubyspec (what is current incarnation?)
<enebo>
ruby/spec project on github
<enebo>
donV: I would guess a spec/library/coverage/start_spec.rb and probably result_spec.rb although they seem to both need to execute to work
<enebo>
donV: eregon is hanging out here and he can help guide you on what he is expecting if you get stuck
<chrisseaton>
ah coverage specs - I'm interested in having those
<enebo>
donV: I think primarily I can see four simple tests codeless file with comments or whitespace; first and last line have code; first lines do not ; last lines do not
<donV>
enebo: chrisseaton : OK, I will look into it and ask eregon if I get stuck.
<enebo>
donV: Coverage itself really is only 1 and nil array return so it is not super complicated behavior
<donV>
:)
brauliobo_ has quit [Ping timeout: 264 seconds]
<enebo>
donV: but I guess we also will have __LINE__ as another dimension for your other issue
<GitHub140>
jruby/master dbde0fb Thomas E. Enebo: HEH. Don't continually set hash per every array element in coverage hash creation
djellemah has joined #jruby
<enebo>
donV: ^ I discovered this issue by running coverage on a 0 byte file. So testing “” might also be worthwhile (although I highly doubt any coverage tool can actually do anything with that.
<daicoden>
Sorry, been poking around on the workflow for submitting a patch. Are there more detailed instructions other than https://github.com/jruby/jruby/wiki:Get Involved, I'm not sure of the state of the world. My main question is. Should I submit two PRs, one for jruby 9000, and one for jruby 1.7.x? Are we still trying to support 1.7.x?
skade has joined #jruby
<daicoden>
sorry = sorry if this information is somewhere easy to find
<enebo>
daicoden: you can submit to jruby-1_7 if it is 1.8 or 1.9 behavior and we will merge to master if the semantics still hold for 2.3
<enebo>
daicoden: if it is super invasive aka “risky” then we will likely ask to be submitted only against master
<enebo>
daicoden: a little squishy I know
<enebo>
daicoden: and long time no see
<Lan5432>
enebo, would you happen to know if the mentors of GSoC for JRuby will check proposal drafts?
<enebo>
Lan5432: I think we did not make it as an individual org but I am sure the main ruby gsoc will review all proposals
<enebo>
Lan5432: usually if something is missing you will be contacted to add more info
<Lan5432>
I thought each suborg had his mentors on line for that
donV has quit [Quit: donV]
<Lan5432>
Well, I have the draft (which is meant to be a proper proposal, but I had to upload it like that just in case I missed something) but I still need to contribute with something worthy
brauliobo_ has joined #jruby
<enebo>
Lan5432: I think tarcieri is org admin this year but unfortunately he is not on channel at the moment
<enebo>
I think so anyways
<Lan5432>
I uploaded my proposal draft yesterday or 2 days ago, so I really should wait XD but I was wondering about when I would get feedback or any
<daicoden>
enebo: I know! Hope you are well, jruby-1.7.12 kind of fixed everything/had enough work arounds that I could never get some of the bigger patches done. Trying to carve out some time now :-D.
<Lan5432>
Because I still have to upload that PR and all
<enebo>
daicoden: sweeet
<enebo>
daicoden: and kares has been doing quite a bit of JI hacking lately so he might be a good recourse if you are carving out your time for that
johnsonch is now known as johnsonch_afk
<daicoden>
enebo: awesome, thank you for the introduction. I'll hit him up if things get sticky.
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #jruby
daicoden has quit [Remote host closed the connection]
skade has quit [Client Quit]
bbrowning is now known as bbrowning_away
daicoden has joined #jruby
daicode__ has joined #jruby
daicoden has quit [Read error: Connection reset by peer]
skade has joined #jruby
yfeldblum has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #jruby
daicoden has joined #jruby
daicode__ has quit [Read error: Connection reset by peer]
lanceball is now known as lance|afk
enebo has quit [Quit: enebo]
CaptainHeavy has joined #jruby
brauliobo_ has quit [Ping timeout: 240 seconds]
brauliobo_ has joined #jruby
ITXpander has joined #jruby
CaptainHeavy has quit [Ping timeout: 260 seconds]
daicoden has quit [Remote host closed the connection]
daicoden has joined #jruby
daicod___ has joined #jruby
daicoden has quit [Read error: Connection reset by peer]