<JRubyGithub>
[jruby] mkristian pushed 1 new commit to master: http://git.io/vqCuI
<JRubyGithub>
jruby/master 654473a Christian Meier: just omit tests instead of skip when running test with embedded jruby
JRubyGithub has left #jruby [#jruby]
rcvalle has joined #jruby
nirvdrum has joined #jruby
rsim1 has joined #jruby
<enebo>
mkristian: heya
<mkristian>
hi
<enebo>
mkristian: I noticed some build changes on 1.7 branch…has anything changed for making a release on 1.7 branch?
<enebo>
mkristian: also anythng worth highlighting as import for 1.7.21 release notes?
<enebo>
mkristian: or any semantic changes/additions to be aware of?
<mkristian>
enebo, the only change is the reduces dist size
<enebo>
mkristian: well that is always a nice bullet point :)
<mkristian>
enebo, the biggest change is that ruby apps can run much better from an unexploded jar - including rails !
rsim has quit [Ping timeout: 258 seconds]
<mkristian>
though rails has the potential of bringing another issue here and there
<enebo>
mkristian: so rails + gems bundled into the jar will run without complaining because you improved classpath: jar: sorts of filesystem operations?
<enebo>
mkristian: or less complaining
<mkristian>
yes - something like this. most File and Pathname operation now work inside the jar via those uri-like paths
<mkristian>
of course you can have your log files inside the jar :)
<enebo>
mkristian: I may advertise the improvement as File and Pathname work better on files inside a jar file
<mkristian>
thanx
<mkristian>
enebo, so 1.7.21 is coming ? today ? now ?
<enebo>
mkristian: I am hoping today. After rtyler made me realize how long we went and since there is an outstanding 9k issue we might as well get 1.7.21 out earlier than later
<enebo>
mkristian: I have not tried to built it yet so you never know
<headius>
hello all
<headius>
chrisseaton: saw your tweet...is the truffle stuff running in parallel now?
dfr has joined #jruby
<dfr>
the
dfr is now known as dfr|work
<chrisseaton>
Only on eregon's test branches, but yeah we seem to run ok without a GIL I think
<JRubyGithub>
[jruby] headius pushed 1 new commit to test-indy-invokers: http://git.io/vqWe0
<JRubyGithub>
jruby/test-indy-invokers 6d02ba7 Charles Oliver Nutter: Restore generated invokers for now.
JRubyGithub has left #jruby [#jruby]
dumdedum has quit [Ping timeout: 252 seconds]
<rtyler>
here's the daily reminder/annoyance that I'd love a 1.7.21 release xD
bf4 has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] bbelleville opened pull request #3107: [Truffle] Don't create threads in Main for Truffle (master...modify-truffle-main) http://git.io/vqWqf
JRubyGithub has left #jruby [#jruby]
<headius>
rtyler: enebo is working on it for today
<headius>
I'm working on 9k.rc2 items for rc2 release tomorrow or wed
<enebo>
rtyler: I even mentioned you above when talking about it :)
bf4 has quit [Ping timeout: 248 seconds]
<mkristian>
headius, since rc2 is tomorrow. I wonder if I can merge https://github.com/jruby/jruby/pull/3073 after rc2 release ? the last step to stop using old load-service for require
<mkristian>
enebo, also for you -^
<mkristian>
enebo, the rmvn command on the jruby-dist-1.7.21 is currently broken. try to get it fixed
<enebo>
mkristian: yeah I just figured I would try it since I had not in a while…I saw you changing some things so just tried it
<enebo>
mkristian: I am still using versions:set on jruby-1_7 (although I am also update README)
<enebo>
hehe s/README/VERSION/
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius fast-forwarded test-indy-invokers from 6d02ba7 to 8e934e8: http://git.io/vqW3J
<enebo>
headius: mkristian: If we land #3073 I think we should land it today
<mkristian>
enebo, doing both is OK ;)
<headius>
agreed
<enebo>
I do not want to stick that into the final release as a new thing
iamjarvo has joined #jruby
<headius>
ideally there won't be an RC3
<headius>
it's time to get .0 out so we can work on .1
<enebo>
but I am not sure if I fully understand risks so that is one reason I was not weighing in as much
<mkristian>
the risk: the only change is about finding directory listing inside jars
<enebo>
mkristian: OMGZ you magnificient bastard…the finalName in jruby-dist and the other value which was in jruby-complete has been fixed…thank you
<enebo>
mkristian: at least I don’t see any weird values
<mkristian>
those Dir globs are not working right for new LibrarySearcher and then we use the old LoadService for this.
<mkristian>
enebo, I think the build on master has less quirks
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<enebo>
mkristian: yeah we will find that out tomorrow ;)
<mkristian>
yes, please tell ;)
<mkristian>
enebo, headius about #3073 currently assume "." not to be on the LOAD_PATH as MRI - actually it is not a change in LibrarySearcher but old LoadService did add "." to LOAD_PATH (implicitely)
<enebo>
So one expected error report outcome from this change is people using JRuby in an embedded way but depending on a gem which has no knowledge of JRuby file semantics and parsing files based on their knowledge of how a FS works…this is akin to people messing up windows by seeing server:/foo.txt as a relative path
<headius>
mkristian: yeah I think it's a good change to remove .
<headius>
we get bug reports about it being there that are sometimes tricky to investigate...like you require foo.rb from a library but happen to have foo.rb in . too
<enebo>
with that said, it seems people should not be writing their own regexps for dealing with paths and such
<enebo>
headius: mkristian: yeah agreed to removing ‘.’ being a net positive on error repors
<enebo>
we may get people used to the behavior confused bu that will end up being a much shorter list
<mkristian>
enebo, my last Pathname patch was a regex detecting the "/" or "C:\" to be the root of the filesystem ;)
<enebo>
mkristian: yeah…drive letters and unc servers are not well supported by Ruby core much less exernal libraries. So in a sense we need to just acknowledge we are adding more of that (which I am ok with)
<enebo>
I lament that loadpath resolves to strings or that paths in general are not objects
<enebo>
if we could have a File(…) or URI(jar: ) which works across Dir,File,LOAD_PATH I think we would end up with a lot less cross-platform bug reports
<enebo>
(note: I mean File as meaning a File path not Ruby File class itself — I guess what Pathname is)
<mkristian>
another change I have to mention, is that all required jars from within jars are copied to /tmp location. this is already done with those jars from jruby-stdlib.jar/jruby-complete.jar for all 9k release
<enebo>
mkristian: ah we I think depend on similar behavor for jffi to work too
yfeldblum has joined #jruby
<enebo>
mkristian: (which is broken on raspi but that is just a single system)
<mkristian>
yes jffi does the same copy thing
<mkristian>
the copy will take place when the jar comes with any weird url like wsjar: from websphere or bundle:1.0.12:/ etc
<enebo>
mkristian: not related to your patch but isFile seems like it should be asFile…This is to say return itself as a file resource vs looking to see if it is a directory and returning its children, right?
<nirvdrum>
headius: With all the work done to SecureRandom over the past couple years, does it still make sense to have a SecureRandom static reference in ThreadContext rather than the extension itself?
<rtyler>
enebo: sorry didn't see the mentions
<rtyler>
IRC is quite a lossy protocol :)
<enebo>
rtyler: yeah don’t sweat it…I just thanked you for bringing it up
<headius>
enebo: question for you about serialized IR
<enebo>
headius: ok
<headius>
what __FILENAME__ does it use?
<headius>
my logic for loading precompiled stuff in 1.7 loads the script from .class and then sets what its filename should be
<headius>
I don't know what equivalent is for IR, if it exists
<enebo>
headius: heh hmm. I think it encodes it when it writes it
<headius>
mmm that's an issue then
<enebo>
I think it is just a StringLiteral by IR time
<headius>
ok, as I figured
<enebo>
headius: it does not have to be if it is an issue
<enebo>
headius: we can make FileLiteral extends FrozenString perhaps and then encode/decode can replace what it is
<headius>
it is...the filename is going to vary depending on how it's loaded
<headius>
and needs to reflect how it was loaded
<headius>
that makes sense
<enebo>
headius: oh…since it may need to shove jar: etc...
<headius>
so deserializing will need a filename to use etc
<headius>
right
<enebo>
headius: yeah sound simple enough? You just need to make new Operand and in IRBuilder do that for FileNode
<mkristian>
enebo, yes probably asFile is the better name. yes, most lookups are for files via require, and looking for a directory listing is much more work
<headius>
enebo: I'll get this working without it and then see if I can make that change
<enebo>
headius: ok
<enebo>
mkristian: not a huge issue but we should change the name I think since when I was reading just the diff I thought it mean it was physically a real file and not a uri or something (which it was obvious it wasn’t once I read the original source)
<enebo>
mkristian: but it does not need to be changed for the PR
<enebo>
mkristian: headius: I don’t know…I am a pretty paranoid guy but if this fixes a bunch of scenarios in addition to removing reports about ‘.’ in loadpath I saw let’s land this now
<enebo>
mkristian: so you can resolve this when you land your PR :)
iandow has joined #jruby
<headius>
enebo: I'm going dirt simple on this precompiled script loading...all I'm adding is a loadIR static method that produces a deserialized IRScope
<headius>
then it proceeds from there as if it loaded from .rb
<headius>
so .class is just a carrier for the persisted scope
nateberkopec has joined #jruby
<enebo>
headius: sorry I cannot quite parse that
<enebo>
so loadIR -> IR
<enebo>
but how does that solve the filename issue?
<headius>
the .class only had main before...I'm adding loadIR => IRScope
<headius>
it doesn't
<headius>
this is just loading
<headius>
it didn't load at all before
<enebo>
oh
<headius>
the bug is about loading being broken
<enebo>
headius: so we only worked as a main scriptbody before?
<headius>
yeah
<headius>
I guess I got distracted before finishing loading
<enebo>
headius: ah ok so obviously we are missing a test or two
<headius>
they're in expected failures right now I think :-)
<headius>
and now it passes magically
<enebo>
headius: all persisted loads will now use that method too?
<headius>
MAGIC
<headius>
enebo: there's no mechanism for loading persisted IR other than this right now
<enebo>
SPIDER WEBS
<headius>
no .rbj or anyhting
<enebo>
headius: haha ok…I am just confused about Main script body then I guess
<headius>
enebo: filename turned out easier than expected
<headius>
I need you to review though
<enebo>
headius: ok
nateberkopec has quit [Quit: Leaving...]
<mkristian>
nirvdrum, enebo yes you need -Psonatype-oss-release to build source and javadocs. jruby-complete has actually no sources but gets the source from jruby-core for the IDEs
<nirvdrum>
mkristian: Is there any way for me to force source JARs without that profile?
<mkristian>
and this is inside the sonatype-oss-release profile
<nirvdrum>
Okay. Thanks.
<nirvdrum>
mkristian: Is there any reason to limit it to sonatype?
<mkristian>
nirvdrum, let me turn it around: where do you need to build those sources manually ? the reason is the javadocs takes a long time and all the config comes from
<nirvdrum>
mkristian: I don't really care about the javadocs per se. But I'm trying to push 9K snapshots somewhere so people can play with Truffle a bit. And having the source readily available for attaching via IDE would be nice.
nateberkopec has joined #jruby
<nirvdrum>
If we wanted to push regular snapshots to sonatype, my work would be done :-)
<bbrowning>
so a null must be getting passed for the jruby home
<headius>
hmm
<enebo>
bbrowning: ah mkristian had a commit involving jruby.home
<enebo>
headius: This surprises me: mri22 -e 'p __FILE__.frozen?'
<enebo>
headius: I guess enough people munge this actual string?
<enebo>
heh don’t use __FILE__ in a loop
mkristian_ has joined #jruby
<Antiarc>
headius: I rather enjoyed your optimization talk!
<headius>
Antiarc: thank you!
<Antiarc>
When you got to the volatile part, I started grepping around the codebase - are any volatile fields enough to trigger the volatile writes per allocation? String, Hash, and Array all have volatile fields
<Antiarc>
It got me wondering if there might be potential improvements to be had there
<enebo>
headius: I added one comment about a missing hard failure..you e.printStackTrace otherwise my only comment is the parameter proliferation of loadScriptFromFile (not that I can suggest an improvment unless we can pass a *Resource in as the replacement?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian pushed 1 new commit to master: http://git.io/vqlmS
<JRubyGithub>
jruby/master 7c7dfb0 Christian Meier: [build] adds enforcer rule for maven-3.3.x
JRubyGithub has left #jruby [#jruby]
<headius>
yeah the pST just needs to be deleted
<headius>
enebo: not all places that call this have resource available
<headius>
I don't like it either
<enebo>
headius: I think my idea of passing in *Resource and using that may be too difficult
<enebo>
headius: A resource in theory thought know if it is absolute and whether it has this addiitional name but I tried tracing through and I have no idea whether it works
<enebo>
thought=ought
donV has quit [Quit: donV]
<dfr|work>
howdy folks
<dfr|work>
so I see mkristian_ merged the change for the classpath resources. Yay :D
<bbrowning>
we override getJRubyHome() in our own subclass and since that now gets called during RubyInstanceConfig initialization it's null, thus leading to new File(null) which throws NPE
<enebo>
bbrowning: It seems you should call super.getJRubyHome()
<bbrowning>
there's probably a good reason we don't, although it likely relates to older jruby versions
<enebo>
bbrowning: yeah this null check stuff is from 2011
<enebo>
bbrowning: I know I would be a dick and open to reprisals if I mentioned a comment would have helped know why you did not call super :)
<enebo>
bbrowning: but pot, kettle, black
<mkristian_>
so it is matter of checking jrubyHome is null before creating new File(jrubyHome) - no ?
<enebo>
mkristian_: but if he is setting it for sure then it seems something else somehow already picked up null?
<Antiarc>
Huh, why is maven 3.3+ required now? Fedora 21 seems to only offer up through 3.2.2
<enebo>
or something?
<headius>
Antiarc: there's a script in there to fetch mvn 3.3.1 if you don't have it
<enebo>
which came in handy for me on windows because I did not want to install a newer one
<bbrowning>
enebo: well, I set it too late
<bbrowning>
enebo: I set it after initializing the instance but in the constructor it looks for the jruby home
<enebo>
bbrowning: yeah exactly ubt it was not earlier
joast has joined #jruby
<Antiarc>
Cool. Thanks.
<enebo>
bbrowning: so something is getting it before you set it
<bbrowning>
I can workaround this for now by passing it in on the constructor I think - I traced the TB code back to early 2010 and it was this way then
<bbrowning>
no idea why though
<bbrowning>
this was back in jruby 1.5.x probably?
<mkristian_>
Antiarc, I was unsure if this is good idea to check. there were people running into issues building jruby-complete with mvn-3.2.x
<Antiarc>
headius: FWIW, that breaks jruby-head via RVM if you don't already have 3.3 installed
<headius>
rvm needs to update how they build
<Antiarc>
I can get around it since I have the source tree locally and can execute mvnw, but other users may have issues
<enebo>
bbrowning: huge bonus if you can fix it on tb side but with that said people will break immediately if we release right?
<headius>
good point though
<bbrowning>
enebo: people will only break if they upgrade the jruby shipped with tb3
<enebo>
bbrowning: aha cool
<bbrowning>
some people do, but most wait for us to put out a new release
<enebo>
bbrowning: but it is reasonable to say wait for new tb3 bits then
<headius>
Antiarc: I still can't repro from rvm
<headius>
freshly reinstalled jruby-head
<bbrowning>
enebo: I wouldn't worry about delaying your release just for new tb3 - if tb users complain to me we know the issue
<headius>
I tried with and without --dev
<Antiarc>
bah, mvnw doesn't update my global maven version, give me a few to work around this
<enebo>
headius: you removed mvn 3.3 from path?
<headius>
enebo: different issue
<enebo>
bbrowning: well this will be the issue if you find no others…I hope anyways
<enebo>
headius: ah
<headius>
some folks are still seeing AIOOB in variable scope running off head
<headius>
same thing we fixed
<enebo>
bbrowning: sorry again for asking so late
<headius>
I can't repro
<bbrowning>
it's fine
<mkristian_>
headius, I thought mpapis wanted to switch rvm to use mvnw ?!
<headius>
mkristian_: beats me!
<enebo>
headius: yeah crud…that seems like perhaps there is something beyond flip not getting alloc’d during parse time
<enebo>
headius: or we have some path not pulling the growable binding scope
<enebo>
headius: but the later case presumably would fail 100%
<enebo>
headius: former would too
<enebo>
:)
<headius>
enebo: I would expect to be able to repro
<enebo>
yeah
<enebo>
my very idirect way of saying the same thing
<enebo>
IDIRECT
<headius>
Antiarc: you can just unpack maven dist and add to PATH, worst case
<Antiarc>
Yup, done and building
<headius>
iDirect
<Antiarc>
I just prefer to stick to system packages where possible, but the build must go on!
<headius>
yeah, we're bleeding edge here
<headius>
mostly because the build is written in ruby maven now
<headius>
mkristian_: dunno if you ever saw my feature request... when ruby-maven spits out pom.xml it should have a big fat comment saying it's generated
<headius>
I wasn't sure where to file that as an issue
<headius>
mkristian_: oh hah, it does!
<headius>
nevermind
<mkristian_>
I did implement it
<headius>
I had not checked recently because I have not had to mess with pom.xml for a long time :-)
<mkristian_>
so I did see your request :)
<headius>
thank you for that!
<headius>
I may do a reformatting pass on our pom.rb's to make them a bit more idiomatic ruby
<headius>
actually it isn't bad right now
<Antiarc>
headius: Still failing locally for me. The immediate thing I think of is that I'm on Linux, as is Travis, and you're on OS X IIRC?
<headius>
I am
iandow has left #jruby [#jruby]
<Antiarc>
I may see if I can produce a failing build in a docker env :)
<headius>
but that shouldn't make a difference for something like this :-(
<headius>
I will bring up my vm and try to repro there
<enebo>
Antiarc: and lots of people are on linux envs building master right now
<Antiarc>
I'm doing an RVM update and another clean install to limit variables
<Antiarc>
enebo: Can you repro #3102?
<enebo>
Antiarc: I am also on MacOS (but I think largely it is me and headius as the remaining MacOS folks)
<headius>
Antiarc: I have an ubuntu 14.04 build running now
<enebo>
I find it weird this would be system dependent unless the gem itself has a special code path for linux
<Antiarc>
It doesn't
<Antiarc>
And yeah, I agree, it's just the first thing I thought of that I have in common with Travis that headius' env doesn't! :)
<headius>
pretty sure travis is 14.04 too so this better repro
<headius>
Antiarc: JVM version?
<Antiarc>
1.8 openjdk, will get an exact version in a sec
<Antiarc>
openjdk version "1.8.0_25" OpenJDK Runtime Environment (build 1.8.0_25-b18) OpenJDK 64-Bit Server VM (build 25.25-b02, mixed mode)
<enebo>
JRUBY_OPTS? some other initialization?
<Antiarc>
opts are -J-XX:+TieredCompilation
<Antiarc>
yeah, blew up again
<enebo>
Antiarc: this will generate a large file but adding -Xir.debug=true and doing >output 2>&1 and you should be able to see what executed last
<enebo>
Antiarc: it is a little tricky because you need to scroll back to first occurrence of the Exception
<Antiarc>
Sure, give me a few
<headius>
sunuva
<enebo>
Antiarc: but -Xir.debug should be in JRUBY_OPTS since you probably subinvoke
<enebo>
BUG: Got exception java.lang.ArrayIndexOutOfBoundsException: 2 but instr <str(0:2:local=true)> = copy(%cl_4_9) is not supposed to be raising exceptions!
<Antiarc>
That looks like monitor stuff?
<enebo>
Antiarc: Could you add another flag to make an even bigger file?
<enebo>
I see it is trying to call load on binpath of rake
<enebo>
lower in it
<headius>
looks like the rubygems binstub for rake maybe?
<enebo>
but like 20 on the gist is blowing up because however this is execuytring does not have a index 2 for ‘str’ variable
<bbrowning>
enebo: I'm not seeing things like "ActionView::Template::Error (undefined method `initStandardObjects' for :run:Symbol)" in tb3 integs w/ latest jruby
<enebo>
bbrowning: well unfortunately I think this will probably end up being a bisect
<enebo>
Antiarc: crazy
<enebo>
Could -S load this much differently?
<enebo>
Also I see zero closures in here
<enebo>
bbrowning: no pressue on solving this today since Iknow your work day is almost over
<headius>
enebo: where do you see a closure in the IR?
<enebo>
bbrowning: it is a little too late in the day for my tastes to announce a release
<enebo>
headius: all of the temp vars are closure temp vars
<enebo>
%cl_*
<headius>
hmmm
<headius>
this definitely looks like the right source
<headius>
eval'ed into a closure perhaps?
<enebo>
yeah it must be and we are pulling up depth 0
<enebo>
which is maybe replced with closure binding scope or something like that?
<enebo>
headius: so I think the bug here is MacOS is figuring out where this stub is an strarting it differently
<enebo>
headius: it could be environmental where we somehow have a property cheald doesn’t or perhaps somehow fs thing (STAT!!!) works for us so we go down a different path
<enebo>
headius: so we work and he hits this funky eval we are broken on
<headius>
could be
<enebo>
headius: at least it seems a reasonable guess since we see lvar str (0:2) and there are not actually two lvars
<enebo>
I am confused about why these are CL temps
* rtyler
borks
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian pushed 1 new commit to jruby-1_7: http://git.io/vqlMS
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
jruby/jruby-1_7 d0a2955 Christian Meier: adds rmvn command since it comes with ruby-maven and make regular bin/mvn inside the gem executable
<Antiarc>
Lemme throw an exception in there and I'll get a ful lstack trace
<enebo>
we do have some closure types which are not really closures
<headius>
enebo: it's trying to preserve eval scope vars across evals, but for this case with binding it should just be going directly at the existing eval scope (I think)
<enebo>
headius: but that binding can grow and keep growing
<headius>
I have a trivial repro
<headius>
eval 'a = 1'; eval 'b = 1', TOPLEVEL_BINDING
<enebo>
headius: but I am not sure if our staticscope is growing along with it?
<headius>
binding evals should not be looking at the scope around the eval at all
<headius>
but they are
<headius>
this isn't specific to TOPLEVEL_BINDING either
<headius>
I think it would work with any scope + binding eval combination
<headius>
work = break
<enebo>
headius: funny you add p a instead of b = 1 and it does not fail
<enebo>
and behaves as expected
<headius>
yeah there's something weird about how it's doing binding evals
<headius>
it's trying to root them in current lexical
<headius>
or something
<enebo>
headius: so it is weird it is saying b is (0:1)
<headius>
and getting confused thinking they're both the same scope
<enebo>
it should be (0:0) and in its own staticscope
<headius>
yes
travis-ci has joined #jruby
<enebo>
headius: ok so I wonder if we were broken before and happened to work because we just grew large
<enebo>
headius: not meaning we really worked either but we did not crash
<headius>
I don't know
<headius>
this is kinda gnarly in here
<enebo>
less gnarly than it was several months ago
<enebo>
we had two scopes per eval all the time
<enebo>
one seeming never reachable
<headius>
yeah this whole thing looks weird to me
<headius>
IRBindingEvalScript
<enebo>
headius: easily the most complicated scope
<enebo>
headius: if you are not using it…-Xdeubg.parser=true is really useful here
mcclurmc has quit [Remote host closed the connection]
<enebo>
headius: yeah this is flat out wrong although interesting
<enebo>
headius: in that it might work anyways
<enebo>
headius: it statically looks for a saved staticscope
<enebo>
headius: it will find one
<enebo>
headius: it will grow it
<enebo>
headius: eveny eval constantly tries to grow to fit
<enebo>
headius: we deleted the magic which would constantly grow the staticscope
<enebo>
headius: even though all these bindings are different we still universally use the same index for the same name
<headius>
I'm trying to figure out how we should root the TOPLEVEL_BINDING
<enebo>
headius: so even though we actually grab different eval scopes from the binding they all grow big and store properly
<headius>
I think that plays into this
<headius>
because TOPLEVEL_BINDING has its own eval scope, but appears to be rooting at SCRIPT_BODY anyway
<headius>
so the binding parse uses script body's eval variables and then tries to put them in the binding's eval scope
<subbu>
headius, enebo isn't the top level binding pushed in Ruby / Main or one of those files .. i vaguely remember looking at this a year back and seeing it being pushed there.
<headius>
subbu: I could not find it
<enebo>
can you both read my narrative
mcclurmc has joined #jruby
<enebo>
I don’t think this is a great soltuion but I think it explains why it broke recently
<subbu>
enebo, my memory is rusty to respond in any useful way to that. :)
<headius>
I see topStaticScope get pushed in ThreadContext
<headius>
constructor
<subbu>
right, and i think that is probably called from Ruby / Main?
<enebo>
subbu: basically we do not pass staticscope from the binding in so we use the same staticscope at the highest non-binding eval scope to determine offset for new lvars
<enebo>
subbu: this offset just ends up being distinct from any other eval which may use the same name in its eval
<subbu>
i see .. because the shared staticscope is not being passed around?
<enebo>
subbu: so two evals using the lvar ‘frog’ wll both get an offset of n even though they are not the same bindings because we statically always use the same level staticscope
<subbu>
but, what is the current ruby behavior for that anyway?
<enebo>
subbu: so then when we call evalCommon we ask the scope to grow
<subbu>
eval "a = 1"; eval "p a" .. are those 2 different vars or same var?
<enebo>
subbu: so then if gets enough slots to hold all evals which happen at same leve even though that is not what happens
<enebo>
subbu: yeah those are two different vars with two differenty dynamic scopes but the IR processing will use the same static scope to figure out its offset
<enebo>
subbu: which is why we constantly try and grow ‘evalScope.growIfNeeded();'
<enebo>
subbu: if we could pass the staticscope of the binding in our IRBuild we could then create proper staticscope/dynamic scope of proper size BUT I don’t know if we can easily make a change like that
<subbu>
i see. so, the bug is that IREvalBindingScript is not being constructed with the static-scope that it is attached to?
<enebo>
subbu: yeah and maybe it is diffiult
<headius>
maybe...that's what I'm trying to fix now
<subbu>
eval "a = 1" should implicitly translate to eval "a=1", new-static-scope
<enebo>
subbu: we need to get static scope from live bindnig and pass it to the IRBuild of the eval script
<subbu>
so that eval "a=1", some-binding works as expected without special cases
<subbu>
got it.
djbkd has quit [Remote host closed the connection]
<subbu>
yes, so, this is a problem in our modelling of bindings.
<subbu>
maybe because behavior in 1.8 was different or because i never understood this properly.
<enebo>
subbu: if I had to guess at this point it was because you could not change code path to pass it in easliy
<subbu>
yes, that could definitely have been a factor as well.
<enebo>
subbu: 1.8 was different but a simple case since this logic would always work
<enebo>
subbu: ah
<enebo>
subbu: that explains it
<enebo>
subbu: you impld this for 1.8 originally
<subbu>
while i am in jruby land .. let me finish up that patch for that ACP pass bug and push it.
djbkd has joined #jruby
<enebo>
yeah this is messy
<enebo>
it passes in the binding’s staticscope already but then it frets over whether the parent of it is also an eval with binding
<headius>
a binding eval already has a scope it should use
<headius>
I'm not sure why this wants to walk into parents at all
<enebo>
headius: I think to resolve lvars
<subbu>
yes .. to resolve vars.
<headius>
yeah but why is it storing the eval vars at some higher level? we literally just gave it a scope to eval in
<enebo>
headius: intermediate evals will not all have tiehr own var scopes
<headius>
intermediate?
<headius>
we're giving it a binding that has a scope that has an eval scope slot
<headius>
right?
<enebo>
headius: seems like currently we pass the static scope of that slot of the eval holder in
<enebo>
then we walk down
<headius>
or perhaps we should not be using evalScope from binding at all and let IR find it?
<headius>
basicalyl we have to ways to find the eval scope to use, and we're using both of them
<enebo>
headius: we have to use this scope for lvar resolution for repeated binding evals
<headius>
and I don't know which is right
<subbu>
grr .. looks like i have to update mvn to build.
<headius>
enebo: right, but that should still be the same scope every time
<headius>
so it should see the vars from last time
<headius>
we get binding.getEvalScope and pass that in
<headius>
same scope
<enebo>
headius: yeah it is the walking down which is the issuye
<headius>
but then IR takes taht scope and walks away from it
<enebo>
headius: I admit this part really does not make sense at the moment
<subbu>
headius, enebo is this findExistingLocalVar ?
<enebo>
headius: I can see we want a base to look for existing lvars first
<enebo>
headius: and I can see walking to find that
<headius>
subbu: yeah, and the code near it in IRBindingEvalScript
<enebo>
subbu: and the constructor
<headius>
enebo: searching parents for higher-scoped vars is fine but it's starting from the wrong place and using the wrong place to store new vars
<enebo>
public LocalVariable lookupExistingLVar(String name) {
<headius>
it walks up to nearest non-eval scope and uses its eval scope rather than the one we've explicitly passed in
<headius>
because this is TOPLEVEL_BINDING it already has its own IRScope from the script so the new variables are allocated by IR in the wrong place
<enebo>
I think maybe staticScope.getIRScope() will return the proper IRScope assuming it has been set
<subbu>
yes, this is broken.
<headius>
updated gist with more context
<enebo>
that can replace the nearestNonEval business
<enebo>
perhaps first parse wll not have it yet…that is the caveat to that
<enebo>
headius: yeah I think that looks better to me…perfect I don’t know
<subbu>
ok, so, what is the evalscopevars business again? :)
<enebo>
headius: but staticScope matches actual staticScope of the binding
<headius>
I'm just guessing at this
<headius>
just removing the walking up
<enebo>
headius: you are setting this evalscript as the staticScope IREvalScript
<enebo>
\BUT
<subbu>
i think there has to be walking up for vars that aren't found in the scope. but, after the current scope has been looked up.
<enebo>
what happens on the seoncd eval ot the same binding?
<enebo>
you will just replace it again
<enebo>
replace it with a new IRBindingEvalScript
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] eregon pushed 1 new commit to master: http://git.io/vq83G
<JRubyGithub>
jruby/master 539baf0 Benoit Daloze: [Truffle] Allows to require paths starting with "./"...
JRubyGithub has left #jruby [#jruby]
<enebo>
so I think that blankey init could become a conditional and you just use the first IRBindingEvalScript you get and after that you just keep using that one and do not setIRScope() more than once
<enebo>
blankey = blanket although to some people those two words are the same
<enebo>
So seticScope.setIRScope() in Interpreter should be moved in ITBindingvalScript constructor and this.initEvalScopeVariableAllocator(false); should be a check to see if staticScope already has a IRScope
<enebo>
If not it says this instance is its binding var scope and sets ir on the staticScope
<enebo>
If one already exists it searches for vars there
<headius>
enebo: I think you have a better grasp of this than me at this point
<enebo>
headius: I may only be talking a mean game
<enebo>
headius: I will try this
<headius>
ok
<subbu>
so, headius enebo .. why do we have a separate evalScopeVars map right now? isn't that no longer relevant in 2.0+ ruby world?
<headius>
with my patch, the variable is still visible across evals
<subbu>
enebo, headius yes .. i think local vars map is sufficient .. the separate eval scope vars should not be required anymore.
<headius>
using StaticScope as the source of the var
<enebo>
headius: yeah we need all variables as the same instance
<headius>
subbu: it is needed for a single eval to reuse the LocalVariable instance, but it wouldn't get a wrong offset even if we removed it
<Antiarc>
Well, I'm back
<headius>
it would just be wasteful
<Antiarc>
And wow, we're still on this, eh?
<headius>
Antiarc: :-)
<subbu>
k
<headius>
huh
<headius>
I'm just going to remove these overrides
<enebo>
headius:
<enebo>
headius: HAHAHAH I just did that
<enebo>
everything but the constructor
<headius>
still works fine
<headius>
I have not run tests at all though
<enebo>
jruby -X-C -e "eval 'a = 1'; eval 'b = 2', TOPLEVEL_BINDING; eval 'c = 1; p b,c', TOPLEVEL_BINDING"
<enebo>
fine deleting it all
<headius>
nice
<headius>
so what's the difference between this and IREvalScript now?
<headius>
anything?
<headius>
I'm running specs
<headius>
specs pass
<enebo>
headius: well we know it is an eval with binding
<headius>
is that useful?
<enebo>
not horrrible in java stacktrace
<headius>
we don't see it in stack trace anyway
<headius>
do we?
<headius>
I thought interpreter just walked scopes, but we don't call through them
<enebo>
heh…no I guess we wouldn’t
<enebo>
and we do see it in the stack anyways by seeing where it came from higher in the trace
<subbu>
remember the findMethod.<blah>. it needs to know about binding scopes.
<headius>
specs pass with IRBindingEvalScript deleted altogether...trying MRI now
<subbu>
but, i forget if that information is maintained via IRScope or happens in the runtime scope .. seems like 'I dont remember' is my refrain today :)
<enebo>
so could the fatal flaw to removing this be multiple related bindings nested which need to access lvars?
<headius>
huh, they claim they found alien microbes on the rosetta comment
<headius>
comet
<headius>
not comment
<subbu>
rosetta comment?
<subbu>
ah. :)
<Antiarc>
Wow, really? Link?
<Antiarc>
Like, extraterrestrial organics?
<enebo>
eval 'eval "p a; b = 1; eval %q{p b}, three", two', one
<headius>
evidence of
<enebo>
yay…this worked
<headius>
Antiarc: yah, complex organics
<Antiarc>
O_O
<Antiarc>
That's like...news of the millenium so far
<enebo>
COMMENT
<enebo>
eval 'eval "p a; b = 1; eval %q{p b}, three", two', one
<enebo>
^ This is alien life
<enebo>
It works though
<headius>
Antiarc: yeah, sounds like it hasn't been confirmed yet
<headius>
and one of the guys who did the study previously claimed SARS came from space
<headius>
so kernel, module, class, eval have passed
<enebo>
headius: did you leave this: staticScope.setScopeType(IRScopeType.CLOSURE);
cristianrasch has quit [Remote host closed the connection]
<enebo>
headius: I think this should be what EvalScope has
<enebo>
hmmm or should it
<enebo>
It is itself a closure in behavior
<enebo>
subbu: headius: Actually the setScopeType on StaticScope I wish could go
<enebo>
I have not looked lately but is one of those mutating fields
<subbu>
i think that was required so that we could propagate that information through to dyn-scope when we are looking it up for method containers .. or that is my recollection.
<enebo>
On that note I think I need to eat a tripe ration….this dawg is hungry
<subbu>
\o/ to code deletion :)
<enebo>
lively day of not releasing…to be continued…
<enebo>
night night
<headius>
ok
<headius>
I'll push this if it looks ok locally
<enebo>
ok
<headius>
running a couple more suites to be sure
enebo has quit [Quit: enebo]
havenwood has quit [Read error: Connection reset by peer]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius closed issue #3102: Bundle install fails with jruby-head with a Java::JavaLang::ArrayIndexOutOfBoundsException on travis http://git.io/vqfRD
JRubyGithub has left #jruby [#jruby]
<headius>
Antiarc: ^
<Antiarc>
headius: thanks! building now
<Antiarc>
did it turn out to be a gemspec thing?
<headius>
no, bad IR handling of local variables in an eval-with-binding
<Antiarc>
interesting, I wonder why only a few gemspecs were tripping it
<headius>
the simplest repro I found was "eval 'a = 1'; eval 'b = 1', TOPLEVEL_BINDING"
<headius>
I'm not sure, but possibly some don't have a top-level lib variable
<headius>
it was the lib variable in your gemspec that hit the bug
<Antiarc>
ahh, okay!
<headius>
the problem was that it was using a different scope for parsing and determining the offset of new variables than the one it eventually assigned them with
blaines has joined #jruby
<headius>
so when it went to update DynamicScope, it knew nothing about those vars
subbu is now known as subbu|away
<Antiarc>
headius: all fixed. Cheers!
blaines_ has joined #jruby
<headius>
excellent
<headius>
only took half a day for a one-line fix :-)
havenwood has joined #jruby
blaines has quit [Ping timeout: 250 seconds]
<Antiarc>
heh
<Antiarc>
Well, it seems like a worthwhile fix!
fatephd has quit [Read error: Connection reset by peer]
fatephd has joined #jruby
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]