<chrisseaton[m]>
their code or did you tidy it up?
<enebo[m]>
chrisseaton: multiple answers,. k_case was what it was called but I have not bothered to rename them all yet
<enebo[m]>
indentation I did change but it is largely from emacs constantly reindenting everything
<enebo[m]>
over decades we have sometimes not had identical grammars because of unexplained shift/reduce errors but eventually I will figure out what was wrong or it figures itself out
<enebo[m]>
chrisseaton: I did reduce literals/keywords into the grammar to not have to push another production state which is another difference I can recall. tbh I don't think I can measure the difference so I would be willing to undo it if someone wanted them to match identically
<enebo[m]>
(the shift/reduce thing may sound weird but lex_state + the fact we use another implementation of an LALR parser has made it difficult to know what has caused those issues when they occur)
<enebo[m]>
chrisseaton: Also on master that k_case was changed to match MRI with keyword_case (as well as all k_)
<chrisseaton[m]>
I wonder if C and Java could share a grammar file and put all the logic into helpers?
<enebo[m]>
chrisseaton: yeah I have thought about it..how MRI does it with m4 is pretty icky but duplicating files I am sure many would say is worse
<enebo[m]>
chrisseaton: I have over time been increasing the number of helper methods to make it more just grammar but that works well more for productions which are a single body versus ones which save state mid production
Caerus has quit [Ping timeout: 256 seconds]
<boc_tothefuture[>
Hello... Have an odd question. From within a JRuby script being executed via JSR223, is there anyway to access the JRuby engine and in particular the script file? The engine is being invoked with an inputstream reader and I am trying to reconcile the loaded script with the directory the scripts are stored into so I can figure out the name of the script being run for logging reasons..
<enebo[m]>
boc_tothefuture: I would guess by the time it is an InputStream (which I think ends up a Reader in 223 eval or compile) you no longer have the file name itself.
<enebo[m]>
boc_tothefuture: I do see in compile() it looks at the system property javax.script.filename but that seems like a very weird way to impl that
<enebo[m]>
if you are single-threaded in processing this code you may find the filename in that system property
<enebo[m]>
oh and sorry you said inputstreamreader but reader was on the next line :)
Caerus has joined #jruby
<enebo[m]>
boc_tothefuture: not to suggest something evil but if the inputstreamreader has the inputstream and that inputstream is probably a fileinputstream you can setAccessible() on the field path in the fileinputstream
<boc_tothefuture[>
evil is fine.. Yeah, I knew that i lost the file. I was planning to hash the contents of the script and then do the same against each file until I found a match..
<enebo[m]>
boc_tothefuture: reflection back into the fis with accessible will be much faster if you can setAccessible
<boc_tothefuture[>
How can I get to the FIS from within the script itself?
<enebo[m]>
oh within the script. let me think. I mean ultimately I would think about ripping the name out before the eval happens and putting it somewhere ruby can easily see it
<enebo[m]>
I am rusty if 223 but there is a binding I think which can store stuff
<boc_tothefuture[>
I don't have access, its within a broader system.
<enebo[m]>
In Ruby you could I think so SCRIPT_LINES feature and the entire script will get saved
<enebo[m]>
You have to define the constant I believe before it starts recording so it may be another issue
<boc_tothefuture[>
yeah, I did find that.. it does seem to imply that it doens't record until you do that.
<enebo[m]>
yep
<enebo[m]>
boc_tothefuture: the thing is our parser will not keep the source around normally as it would take up memory so the script you are currently executing will have no source by the time it starts executing
<boc_tothefuture[>
sounds like might not be possible here..
<enebo[m]>
does __FILE__ print out <script>?
<boc_tothefuture[>
yep
<enebo[m]>
heh _ _ FILE _ _
<boc_tothefuture[>
it does
<enebo[m]>
ok so not even the system env is being set
<enebo[m]>
but you can modify the ruby at some level or you would not be doing this?
<boc_tothefuture[>
I can submit a PR.. but its a system that runs python, js, etc as well.
<enebo[m]>
boc_tothefuture: are you adding code in some library that these scripts happen to call?
<enebo[m]>
I am trying to envision how you tried to use SCRIPT_LINES__
<boc_tothefuture[>
yeah, its a library that gets required
<enebo[m]>
ah but that file is already parsed by the time the require happens so no contents
<enebo[m]>
yeah I am not thinking of anything. we have the ability to dig into our internals itself using 'JRuby::reference' which take evil to another level but I do not see how even that would give you what you want
<boc_tothefuture[>
What property would you set if I had access that would make FILE resolve?
<enebo[m]>
boc_tothefuture: you may need to read JSR223 docs but in looking at source it appears to look at "javax.script.filename"
<boc_tothefuture[>
ok.. Looking at the code here, it brings it back with factory.getScriptEngine()
<enebo[m]>
Actually I am unclear if that is actuall System properties or some properties associated with an engine context
<boc_tothefuture[>
I would hope engine context? because this system runs multiple scripts.
<enebo[m]>
It would be super weird if it was System
<enebo[m]>
but in looking at compile we may be doing it wrong there perhaps...in eval it looks like it is gettign it from the container
<enebo[m]>
This code is a little confusing because it was abstracted to work for 3 different embedding envs
<boc_tothefuture[>
hmm. I can see what happens here when I try and add it.
<boc_tothefuture[>
its interesting, I can't find anything about javax.script.filename when I search.. about where it should be set, context or engine, or property..
<headius[m]>
this one will have to wait until Andrey Somov does another SnakeYAML release, which apparently he only does every six months. Next release will be in February
<headius[m]>
No follow-up from any reporter and I have not been able to see the problem just looking at the code. Indy yields should only directly bind one target and do not stack up so I am not sure how the stack overflow is happening. johnphillips31416 if you are able to provide any more info or reproduce it with some additional flags it could still get some attention before 9.2.14
<headius[m]>
it is possible it has been fixed since 9.2.11 but johnphillips31416 would likely have been on 9.2.13
<headius[m]>
I think this one is down to an issue installing or running rb-inotify 0.10.1 under WSL. Workaround of using an earlier version seems to be ok but something in the newer release has issues. Will need investigation on Windows with WSL
<headius[m]>
and the last one is the JNR update which I'm looking into now
bjfish[m] has joined #jruby
<boc_tothefuture[>
@enobo that worked.
<headius[m]>
enebo:
<enebo[m]>
boc_tothefuture: cool!
<byteit101[m]>
enebo: Integrated your changes
<byteit101[m]>
had to fix one thing (also reverted the formatting as it was conflicting, will do that later as I previously mentioned)
<byteit101[m]>
and then I hit this issue last night:
<headius[m]>
grr... what did we change in multicast on master that isn't on 9.2
<enebo[m]>
byteit101: hmm yeah in interpret() it calls conxtext.getCurrentScope()
<enebo[m]>
So I think I need to play with your branch a little bit
<enebo[m]>
If you are into this though I believe splitInitialized is calling this interpret and it is asking for the current dynamicScope but there isn't one for this particular method so it just takes what is at the top of the stack
<enebo[m]>
normally a method like InterpretedIRMethod has a 'pre()' which will push a new scope for the duration of the method call. We are not doing that for this scope because we are calling it directly from what is a native method
<enebo[m]>
byteit101: You can add context.pushScope(DynamicScope.newDynamicScope(ic.getStaticScope())); before the interpret and context.popScope(); after the second one
<enebo[m]>
That is somewhat of a hack but I suspect you will move onto whatever else is wrong with the new code (since it was never actually tested)
<enebo[m]>
I am doing a curbside pickup in a couple of minutes but will be back and I can dig in too
<enebo[m]>
variable names are probably wrong in that snippet as I just copied pre/post logic into this chat
<byteit101[m]>
I'll try that this evening
<headius[m]>
oh good grief
<headius[m]>
this hangs on OS X on master too
<headius[m]>
enebo: hangs seem to have been related to work that ahorek and I did to shore up socket constants for compat improvements on master... after cherry-picking the relevant commits to the 9.2 JNR update that PR is green now. Do you have any concerns?
<headius[m]>
I don't know why this multicast test hangs on my local macOS but it is nothing new
subbu is now known as subbu|away
<headius[m]>
enebo: I am bumping the bundle exec issue because it is not going to be in an RG release before we would like to get 9.2.14 out, and an RG release needs more time to bake. The issue was not reported by a user and can be worked around a few different ways (ultimately fixed by a manual upgrade of RG) so I don't consider it critical.
<enebo[m]>
headius: sorry I am not fully following. Something on master was combined with something else and once you realized the something else you then backported the original thing
<enebo[m]>
the original thing == some jnr update but not the constants work
<headius[m]>
The PR was updating all of JNR on 9.2 to pick up fixes that have happened over the past few months
<headius[m]>
one or more of those fixes to jnr-constants needed to also pull in JRuby changes so the constants would be installed and used correctly
<headius[m]>
there were a number of hardcoded constants that moved into jnr-constants instead thanks to ahorek
<enebo[m]>
headius: so did you also cp those back?
<enebo[m]>
or just not update the constants?
<headius[m]>
I cp everything that was related to these socket constant updates
<headius[m]>
there was also a fix to support that TCP_CORK thing but that seemed like going a bit far
<enebo[m]>
headius: Was the multicast thing largely just fix windows or was it more pervasive? I can imagine hard-coded values might not work everywhere
<headius[m]>
the windows fix was just for gid and pid
<headius[m]>
it was cp because jnr-posix changed how it handles those functions
<ahorek[m]>
hello there
<headius[m]>
ahorek: hey thanks for that windows pid/gid catch
<headius[m]>
if you can look over that PR above for sanity check I would appreciate it
<ahorek[m]>
sure
<headius[m]>
we had a number of updates for socket constants and I want a minimum set in 9.2.14 so we can update all jnr stuff
<enebo[m]>
headius: but there was a windows multicast bug as well
<enebo[m]>
headius: I wonder if this fixes that issue too
<enebo[m]>
and it supposed worked fine in 1.7
<headius[m]>
enebo: ah yeah sorry I cp several things trying to fix this and mabye not all are necessary
<headius[m]>
I have to run a quick errand, may not be back before you sign off but if you both have a look I think we can feel ok with this
<enebo[m]>
sure. I might wait until tomorrow morning too for that conversation but I will try and find the bug I am thinking of
<enebo[m]>
I am going to look at byteit101 thing quickly since I think I can do pre/post logic there to advance that
<enebo[m]>
In my brain the problem seems obvious :) We shall see
<headius[m]>
ok
<ahorek[m]>
the hang was caused by a wrong IP_ADD_MEMBERSHIP const which is now fixed, but the test was also wrong. It was green just by luck.
<enebo[m]>
ahorek: we deliberate quite a bit about what makes it back and that increases the more time continues
<enebo[m]>
but 2020...so 9.3 has been glacial compared to past work but we are getting closer
<enebo[m]>
native call stuff especially constants are a little scary if I am being honest but hard-coded constants are obviously probably breaking more
<enebo[m]>
byteit101: if you are around do you have a simple test you have been running I can try?
<enebo[m]>
byteit101: I am seeing it ok using spec:ji so I will work from that for now
<byteit101[m]>
Busy, can send you a test in a moment
<byteit101[m]>
specji has ant+1-3 failures
sagax has quit [Remote host closed the connection]