<fzakaria[m]>
but the Gemfile parses with JRuby fine using `jruby -c`
<fzakaria[m]>
The gemfile it's failing on is using `:path =>`
<headius[m]>
That's a new one to me
<fzakaria[m]>
looks to be failing at calling relative_path in bundler
<headius[m]>
Running with complete jar?
<fzakaria[m]>
yea
<headius[m]>
Aha
<fzakaria[m]>
runs fine otherwise --
<fzakaria[m]>
my path is relative -- i'm trying it non relative
<fzakaria[m]>
`:path => "gems/a-gem"` instead
<fzakaria[m]>
vs `:path => "./gems/a-gem"`
<headius[m]>
Yeah ok so there is probably a path resolution problem that doesn't handle classloader uri the same as something else
<fzakaria[m]>
in the above `some-folder` is the root project
<headius[m]>
It is trying to resolve a file path based on a file in the jar
<headius[m]>
That should go in JRuby issue tracker
<fzakaria[m]>
ugh -- im hoping i can figure a hack resolution :(
<fzakaria[m]>
i'll open issue though
<fzakaria[m]>
upgrading JRuby for us is ... pretty tough
<headius[m]>
Sample report or example plus full output
<fzakaria[m]>
ok
<headius[m]>
Upgrading from what?
<fzakaria[m]>
we're on jruby 9.1.17.0 atm
<fzakaria[m]>
another question :)
<fzakaria[m]>
I was trying to figure out how to also use a different bundler -- our Gemfile says "BUNDLED WITH 2.0.2" but it keeps pulling in the version attached to the JRuby installation.
<fzakaria[m]>
but i ran `gem uninstall bundler` but it still works hmm.
<fzakaria[m]>
Interested -- I see now Warbler has on the README
<fzakaria[m]>
Warbler supports Bundler for gems and git repositories, but not for plain path components. Warbler will warn when a :path component is found in the Gemfile and will refuse to include it in the archive.
<headius[m]>
if it fails again we can try running jruby head locally
<headius[m]>
but yeah I want to get this merged in
<fzakaria[m]>
cool starred it!
<fzakaria[m]>
Shared it with some colleagues
<headius[m]>
enebo: this is bringing back memories... I'll basically just add to compiled scripts "load" and "run" methods that know how to set up scope and such
<headius[m]>
trying to figure out if there's any reason I can't create a new dynscope rather than passing one in, so we can really just run directly from the class file
<headius[m]>
enebo: do you know the current sequence of events for setting up the root node and its scope? I see we pass in getCurrentScope but is that used? I mean the root node will have its own static scope with its own variables so this seems like it's just a dummy scope above toplevel
<headius[m]>
return parseFileFromMain(fileName, in, getCurrentContext().getCurrentScope());
<headius[m]>
fzakaria: green!
<headius[m]>
that might be an intermittent failure, which we should investigate, but clearly your patch is not related
rusk has quit [Remote host closed the connection]
<fzakaria[m]>
yes! You can't merge right ? Gotta wait for PItr
<fzakaria[m]>
I still plan to look at my Warbler issue and #6045
<fzakaria[m]>
If you have advice on where to start for #6045 appreciate it.
<fzakaria[m]>
Might turn out to be some interesting bug between bundler vs. jruby expectations for classloading
<headius[m]>
I can push the button but I have not been a maintainer on this project in a long time
<headius[m]>
and I can't release anyway
sagax has quit [Remote host closed the connection]
<fzakaria[m]>
okay -- maybe i'll ping him on the PR
<headius[m]>
I will mention to Pitr as well
nirvdrum has quit [Ping timeout: 268 seconds]
<enebo[m]>
sorry I was not looking here pending fixing serialization bugs but those are done now
<enebo[m]>
headius: as to earlier questions my only posit would be that maybe passing dynamic scope vs creating is for evalish uses if it is not an eval then we should be able to make it
<enebo[m]>
I am not very confident on that but evals definitely allow the eval to scope back into what called it
<enebo[m]>
headius: both the failures still in spec:compiler come from within indy trying to setup For and END (which are both IRClosure). I believe this is because possibly the parent StaticScope should be the script or whatever is above the perceived scope...with that said the duplicate on the staticscope should mean it should naturally go up the chain so....
<enebo[m]>
who knows
sagax has joined #jruby
<headius[m]>
Yeah yeah yes yes yes yes yes
<headius[m]>
Oops okay my microphone is working
<enebo[m]>
HAHAHA
<headius[m]>
Yeah, I saw those end failures last
<headius[m]>
They should not be too hard to fix, because the block set up logic required me to pass in a parent scope
<enebo[m]>
I think I may work tomorrow since I plan on working out soon and file stuff is not resolved (and may be a little tricky to get right)
<headius[m]>
What does not resolved mean
<enebo[m]>
well I am trying to use StaticScope.getFile instead of using IRScope
<headius[m]>
I realized early today I was running basic Ruby commands without any of the scope setting turned on, and things were working
<headius[m]>
So this stuff is really close to just running
<enebo[m]>
yeah we are getting pretty close
<headius[m]>
I will be working over the weekend to make it possible to dump class files and reload them
<headius[m]>
And starting to put together slides since I feel like I have a good picture of what the talk should be
<enebo[m]>
ok yeah I will not work Sunday but will be tomorrow