nanoyak has quit [Quit: Computer has gone to sleep.]
<subbu>
headius, it occured to me .. regarding super ... super can get the impl class without fetching it from the frame .. it can simply re-run the logic to get the method-container.
<subbu>
as long as the right self and dyn-scope are present there.
<subbu>
=> you can simply kill frame class.
benlovell has quit [Ping timeout: 246 seconds]
<subbu>
it is okay to make super just a tad more expensive, i think, if that simplifies other logic.
jrhe_ has quit [Quit: Connection closed for inactivity]
<headius>
subbu: yeah maybe
<headius>
the implementer search is only needed for included modules, to find the wrapper
<headius>
other cases won't do the search, and just use impl class
<headius>
hmmm
<subbu>
but, i meant: impl-class itself is not available there.
<subbu>
that will have to be looked up via the container logic.
<subbu>
should i expt with it over the weekend and see if i can get rid of frame.class? ... but you said it is used in another place too.
<headius>
you know there is another place we need impl class....
<headius>
doesn't affect IR or JIT....but core methods that have super need it
marr has quit [Ping timeout: 240 seconds]
<headius>
maybe an orthogonal discussion
<headius>
subbu: I only saw super
<subbu>
you said: "apparently the RAISE event hook"
<headius>
oh, that...I don't think it's necessary
<subbu>
oh, core methods .. do they fetch it from context and hence frame?
<subbu>
i saw some references in tracing too, i think.
<headius>
there's only a handful of core methods that do Ruby super...they're marked with frame = true
postmodern has quit [Remote host closed the connection]
jsvd has quit [Ping timeout: 240 seconds]
kgerman has quit [Quit: kgerman]
lidaaa has quit [Ping timeout: 246 seconds]
nirvdrum_ has quit [Ping timeout: 240 seconds]
fridim_ has joined #jruby
noop has joined #jruby
lid__ has joined #jruby
anaeem1 has quit [Remote host closed the connection]
lid_ has quit [Ping timeout: 268 seconds]
skade has quit [Quit: Computer has gone to sleep.]
pgokeeffe has joined #jruby
purplefox has joined #jruby
tlarevo_ has joined #jruby
skade has joined #jruby
tlarevo has quit [Ping timeout: 252 seconds]
kares7 has joined #jruby
kares has joined #jruby
kares_ has joined #jruby
jsvd has joined #jruby
benlovell has joined #jruby
jsvd has quit [Ping timeout: 240 seconds]
benlovell has quit [Ping timeout: 255 seconds]
anaeem1 has joined #jruby
pgokeeffe has quit [Quit: pgokeeffe]
pwned has joined #jruby
<pwned>
hi, is there a standard way of bundling jars with a gem? perhaps an automated way of downloading them from maven repository ?
<pwned>
I found some old gems and this: https://github.com/mkristian/jbundler but I couldn't figure out if it already comes with jruby bundler or I should install this as a gem as well
<pwned>
OK it's another gem, so perhaps jruby's bundler already has similar functionality?
ephemerian has joined #jruby
GregMefford has quit [Ping timeout: 276 seconds]
yosafbridge has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
kwando has quit [Read error: Connection reset by peer]
kwando has joined #jruby
GregMefford_ has joined #jruby
fridim_ has quit [Remote host closed the connection]
benlovell has joined #jruby
yosafbridge has joined #jruby
yfeldblum has quit [Ping timeout: 272 seconds]
anaeem1 has quit [Remote host closed the connection]
skade has quit [Quit: Computer has gone to sleep.]
lid__ has quit [Ping timeout: 268 seconds]
jsvd has joined #jruby
elia has joined #jruby
jsvd has quit [Ping timeout: 268 seconds]
joelmheim has quit [Ping timeout: 245 seconds]
joelmheim_ has joined #jruby
jsvd has joined #jruby
brettporter has quit [Remote host closed the connection]
brettporter has joined #jruby
yfeldblum has joined #jruby
shellac has joined #jruby
brettporter has quit [Ping timeout: 255 seconds]
marr has joined #jruby
e_dub has quit [Max SendQ exceeded]
yfeldblum has quit [Remote host closed the connection]
<electrical>
pwned: I'm using a sub gem of that project called jar-dependencies... jbundler is an application like bundler but does handle the jar dependencies.
<electrical>
assuming they are specified in the gemspec
<electrical>
pwned: jruby's bundler is the standard bundler
<pwned>
electrical:does it have a way of installing mvn jars?
<pwned>
I haven't found any
<pwned>
I'm gonna check out jar-dependencies
<electrical>
pwned: jbundler is basically made to install rubygems which hava jar dependency specified in them. if you want to download maven jars on its own its best to look at ruby-maven ( also from mkristian )
<pwned>
I was generally confused about whether if there is an official way of handling external jars, which seems not to be the case, but augmenting gems seem to help
<electrical>
pwned: yeah indeed. We ( Elasticsearch ) are using jar-depenencies for our Logstash project to handle jar dependencies for all the plugins
<electrical>
that way we don't have to put them inside the gem files :-)
<pwned>
exactly what I'm after :-)
<electrical>
our process is pretty much: install a gem from rubygems. the gemspec contains a jar dependency. when that happens the jar-dependency gem hooks into the gem installer and downloads + installs the jar for us
<headius>
planning on getting a little Ruby group together at The Trappist during J1
<Aethenelle>
yes, I had IncludeModuleWrapper delegating getMethodLocation to origin
<rtyler>
headius: I know her, but she doesn't know me :P
<rtyler>
trappist would be good, there's another place that has lots of sours in Oakland too
<nirvdrum>
Stalker?
skade has quit [Quit: Computer has gone to sleep.]
<rtyler>
nirvdrum: conference attendee :P
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<rtyler>
i'm always up for The Trappist though
<headius>
oh, enebo loves sours
<rtyler>
i've not seen them commercially much outside the bay area TBH
<headius>
there will definitely be much beer touring that week
<headius>
Mikkeller is a second home for us
* rtyler
tries to find out what that sours place was called
toady00 has joined #jruby
<rtyler>
headius: dependig on the weather and how long you guys are here, I'm north of Oakland with a big backyard; I'd totally be down for hosting a Ruby BBQ :D
<rtyler>
with fresh produce of course!
<nirvdrum>
It's a trap! He wants to lure you into his dungeon.
<headius>
that's a great idea
<headius>
we get in mid-day Saturday
<headius>
no responsibilities that day, and Sunday is all keynotes
<rtyler>
headius: OAK or SFO?
<headius>
SFO, and then straight to our hotel in SF
<headius>
I imagine we'll be looking to get out and about before the conf starts Monday
kfpratt has quit [Remote host closed the connection]
<headius>
rtyler: started a twitter convo
kfpratt has joined #jruby
<headius>
ahh, such fun...a JIT crash that only happens when doing multiple assignment into an instance variable
<headius>
oh sorry, masgn into an instance variable and a variable from an outer scope at the same time
subbu|breakfast is now known as subbu
<Aethenelle>
sounds like an annoying ball of scope changes...
yfeldblum has joined #jruby
nirvdrum has quit [Ping timeout: 255 seconds]
kfpratt has quit [Ping timeout: 260 seconds]
maleghast has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
indeed
<headius>
subbu: I think this needs IR help
<headius>
a = nil; 1.times { a, @c = nil }; a
<subbu>
headius, in a meeting, back in a bit.
<headius>
no problem, I'll just mind dump
<headius>
access of the external 'a' requires populating it in dynscope before leaving the block
<headius>
that triggers exception-handing to ensure the last value of 'a' gets set into dynscope
kgerman has joined #jruby
<headius>
however the sole assignment is part of the masgn, which gets put in the exception-handled body, so the tmp var for a isn't initialized
yfeldblum has quit [Ping timeout: 252 seconds]
<headius>
maybe my DCE is removing null assignments again
<headius>
er DCE is removing my...
roidrage has joined #jruby
<Aethenelle>
DCE?
<headius>
dead code elimination...a pass in the IR optimizer
<Aethenelle>
ahh...
<Aethenelle>
is that line you full test?
<headius>
in order to ensure all vars are assigned before use (JVM bytecode requirement) I insert null assignments at the top of the method (a hack)
<headius>
but DCE removes them
<headius>
yeah that line blows up bytecode compiler right now
<headius>
or rather, the resulting bytecode blows up
<headius>
subbu: maybe nevermind...I think my "ensure temps assigned" pass isn't handling closures
<Aethenelle>
that a var definitely looks like the sort of thing a compiler would ditch...
calavera has joined #jruby
<Aethenelle>
what happens with a = nil; a ?
<Aethenelle>
(is the output both statements or just a = nil?)
kgerman has quit [Quit: kgerman]
<headius>
if a is just a local variable, the compiler will just emit nil
<headius>
if it's a variable from an enclosing scope, the compiler will load nil and then assign it in the outer scope
<Aethenelle>
is that actually what it does or your understanding? (also possible this isn't a useful investigation...)
dumdedum has quit [Ping timeout: 246 seconds]
<subbu>
headius, i should be in meetings more often so problems resolve themselves ;-)
nirvdrum has joined #jruby
<headius>
subbu: indeed!
<headius>
Aethenelle: that's what it actually does
<headius>
local variables are not visible unless passed to another call or returned, so the IR will optimize their use
roidrage has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
roidrage has joined #jruby
diegoviola has quit [Quit: WeeChat 1.0]
dfr|work has quit [Remote host closed the connection]
benlovell has quit [Ping timeout: 246 seconds]
bbrowning has quit [Ping timeout: 276 seconds]
<subbu>
nirvdrum, reg. the new issue, is 'rubber' a private app of yours?
<subbu>
is that what you were trying to repro? or this is something else?
<nirvdrum>
subbu: Different issue. Rubber is a public project.
<nirvdrum>
I think I linked it in the issue.
<subbu>
ok. thanks.
<subbu>
looks like variable counting is broken somewhere .. so fewer slots are allocated than are required.
<headius>
subbu: I think this will fix it but closures that access surrounding scope already have some loads in entry block, and that's going in the exception handling
<headius>
I think I need to make the var init stuff always push a new entry block in
<subbu>
so, you were ignoring the entry block so far then?
<subbu>
it is normally empty, but the local var pass stuff inits there.
<headius>
my pass plus DCE will work fine once we add appropriate backedges from exception handlers to the tmp assignment block
<headius>
a bit hacky, though
<lopex>
tarcieri: and nobody dared to interrupt
<headius>
lopex: I waited patiently
<tarcieri>
woop
<subbu>
headius, maybe take a look at addGlobalEnsureBB in CFG.java and skip adding ane xception edge for the entry block ... maybe it is as simple as that.
elia has quit [Quit: Computer has gone to sleep.]
<headius>
subbu: ahh ok, I will try
<subbu>
that is a suggestion without paging in all that code into memory ... but if it works, why not?
<headius>
yeah that would be nice
<headius>
I think this may be the last major issue with closures in JIR
<headius>
JIT
<subbu>
nice.
<headius>
real close now
<nirvdrum>
subbu: I'm gonna go mingle for a bit. I'll be back on ~35 min., if you need any other info from me.
<subbu>
k. thanks.
<lopex>
does the IR have a persistent representation ?
<lopex>
and does it saturate with types etc ?
<headius>
SATURATE
<headius>
it does have a persisted format enebo has been working on
<lopex>
hey, that's a good word
<subbu>
lopex, enebo started work on it based on an earlier gsoc project ... but it is pending right now .. it has bit rotted a little bit with recent IR changes.
<headius>
pretty sure it *was* 100% at some point thouhg
<subbu>
it was i think.
phrinx has joined #jruby
<headius>
I've tried to update it for any IR changes I mad
<headius>
made
* subbu
is guilty
<headius>
hah
<headius>
it's all subbu's fault
<subbu>
:)
<headius>
subbu: maybe we should have a rule that entry block never gets any operations that are side-effecty
<headius>
do any operations other than initial heap var loads get put in there right now?
<subbu>
nothing right now.
<headius>
easy peasy
<headius>
bam, that worked
<lopex>
ship it!
<headius>
21 failures
<subbu>
add-load-store is the only thing that uses it .. but future opts might change that .. but hopefully by then, we'll have found a different solution to the initialization problem.
<headius>
tick tock!
<subbu>
nice. great. :)
<headius>
subbu: all good for this case now
<subbu>
i'm glad the design is overall working out well ...
nanoyak has joined #jruby
nirvdrum has quit [Ping timeout: 252 seconds]
<headius>
oh hells yeah
<headius>
I'm filling in the last gaps in JIT now and it's a million times easier to maintain this than the old JIT
<headius>
I blame myself
<Aethenelle>
hrmm..... java.lang.respond_to? is going to the std respond to method...
nanoyak has quit [Client Quit]
<headius>
subbu: can you confirm a refactoring is safe for me? IRScope.nestedClosures gets assigned in two places: constructors, and initNestedClosures
<headius>
the latter seems unnecessary...it's done at CFG building time I think and just ends up re-assigning an empty list
<headius>
so I removed it
<subbu>
let me look.
<headius>
I'm just not sure if it intentionally clears it there or if it's just trying to make sure a list is ready
<subbu>
it is used by inlining.
<subbu>
which is currently also a bit bit-rotted.
<subbu>
inlining changes what closures are nested.
<headius>
ok, so I can't remove that, no problem
<lopex>
subbu: is full lambda lifting possible in ruby ?
<subbu>
in restricted scenarios probably, but i haven't thought about it in a while.
kfpratt has joined #jruby
<lopex>
subbu: one would have to assume lambda/Proc etc are not changes right ?
<headius>
do you even lambda lift, brah?
<lopex>
*changed
skade has joined #jruby
<subbu>
i am not sure what happens with escaped bindings where the caller can manipulate binding ... that happens through blocks.
<lopex>
but limited escape analysis would work ?
<subbu>
if that weren't there, it feels like is possible to hoist/lift blocks out and convert them to regular methods ...
<subbu>
not sure.
<lopex>
or it would have to deoptimize ?
<headius>
if we could see through the target of the closure, I don't see any problem
<headius>
have to make sure it's that target before following the lifted logic of course
<subbu>
in hotspot jvm, it is a pain to try to de-opt.
<lopex>
but you do that right ?
<subbu>
because jruby operates on top of the bytecode interface.
<headius>
subbu: we should chat about what nashorn is doing
<lopex>
*that, right
nanoyak has joined #jruby
<headius>
their stuff is *insane*
<subbu>
deopt by adding alternate paths.
<subbu>
yes, we should.
<subbu>
but, not true deopt in the sense it is meant and done if it were inside /underneath.
<lopex>
headius: how insane!?
<headius>
optimistic numeric unboxing...boxed requirement triggers exeption that saves all method state (vars, ip), unrolls method, dynamically recompiles with boxing, enters that body, restores method state, and starts executing at original ip
<headius>
I want to do that
<headius>
I think it would be much easier for us with IR than for them with AST
<lopex>
but that smells a bit like truffle type feeding
<headius>
at any given moment in IR we could pack up shop and switch to another method or interpreter
<lopex>
now, asm.js for nashorn
* subbu
will have to escape the jruby orbit for a while and enter the parsoid orbit for a while.
<lopex>
and this ceivilisation is comeplete
<headius>
subbu: have fun :-) free later this week?
kares has joined #jruby
<headius>
oh
kares7 has joined #jruby
kares_ has joined #jruby
<headius>
heh
<headius>
friday
<headius>
next week then
<subbu>
headius, yes, we should catch up on all that stuff at some point soon.
<headius>
ok
<headius>
I'll have jit done by then
<headius>
indy version anyway
<subbu>
yes, next week works.
<subbu>
k
<lopex>
is the indy warmup still an issue ?
nipra has quit [Quit: Leaving.]
<headius>
it is, but I've got my best people on it
<dfr|work>
as in are we plannign a 1.7.16 release soon? ;)
<dfr|work>
[I'm considering upgrading the version currently checked into my main repo]
<dfr|work>
'cause 1.7.8 sucks ;)
etehtsea has quit [Ping timeout: 252 seconds]
<headius>
1.7.15 seems pretty stable...a few pathing bugs
<headius>
1.7.16 probably right after enebo returns from RubyKaigi
cremes has quit [Quit: cremes]
tylersmith has joined #jruby
<dfr|work>
headius, maybe I ought to upgrade to 1.7.13 then in meantime.
<dfr|work>
althugh not sure whether pathing bugs will affect me much [and if they do more incentive to fix them]
cremes has joined #jruby
<headius>
indeed..you should go straight to 1.7 head :-D
<headius>
you're a key contrib now, gotta eat the dogfood
<headius>
heh
<headius>
# Your branch is ahead of 'origin/master' by 17 commits.
<headius>
Soon.
<Aethenelle>
i'm going to be running off master soon enough...
<dfr|work>
headius, hmm... Maybe I should indeed try 1.7.15 and see if I run into any issues and can dogfood it
<dfr|work>
although my dogfood will be quirky.. 1.8.7 and all ;)
<headius>
do it!
bbrowning has joined #jruby
quarters has joined #jruby
lidaaa has quit [Ping timeout: 255 seconds]
nanoyak has quit [Read error: Connection reset by peer]
nanoyak has joined #jruby
nanoyak has quit [Read error: Connection reset by peer]
e_dub has quit [Quit: ZZZzzz…]
nanoyak has joined #jruby
postmodern has joined #jruby
postmodern has joined #jruby
postmodern has quit [Changing host]
<subbu>
i haven't understood why humans would eat dogfood, but i haven't had dogs either.
lidaaa has joined #jruby
<mberg>
The myth is that the president of Kal Kan would eat a can of their product at the annual shareholder meeting. But as far I've yet to see any reliable documentation of that claim.
<mkristian>
subbu, there are stories that people bought "tuna-dog-food" thinking it is tuna and were not able to read the whole label to understand it is dogfood
<subbu>
mkristian, interesting, but doesn't have the same implication as 'dogfooding' though?
<headius>
I think we might be considered elitist if we started saying we drink our own champagne
<subbu>
:)
<subbu>
i think so.
<headius>
what do you all think of making the actual 9k version number 9.0.0.0?
<headius>
I don't think we can actually use 9000 because semantic versioning would be hard to figure out
<subbu>
9.0.0.0 seems nightmarish ... the never ending major version.
<dfr|work>
how about 9.0?
<nirvdrum>
I kinda thought 9k was just a codename.
<dfr|work>
or 9k.0? or can't do alphas?
<nirvdrum>
I don't think JRuby 2.0 is all that confusing *shrug*
<dfr|work>
I kind of agree
<Aethenelle>
we can go the Sun route... 1.9
<headius>
alphas screw with various packagers
<dfr|work>
plus, I'll have the opportunity to feel smug explaining between Ruby version 2.0 and JRuby binary version 2.0
yfeldblum has joined #jruby
<headius>
yeah, that's why we don't like 2.0
<headius>
JRuby 2.0, now with support for 2.2
<headius>
wat
<nirvdrum>
Does anyone really get confused by that though?
<dfr|work>
headius, but to be frank, I don't think it'll be THAT much of a problem. uninformed people will still think that jruby only supports 1.8.6 and informed people will know the difference.
<headius>
nirvdrum: it comes up more than you'd think
<Aethenelle>
worst case people only use 2.0 syntax...
<nirvdrum>
Not sure how a 9.0.0.0 solves that :-/
<dfr|work>
headius, the fact that JRuby supports multiple Ruby versions in one binary is already confusing =/
<headius>
well, we won't in 9k
<dfr|work>
headius, but only confusing to people who're just reading about JRuby for the first time. Once you start using it a bit, all that confusion fades, imo
<dfr|work>
headius, so you won't support 1.9 in 9k?
<headius>
no, all the multi-version logic has already been ripped out
<nirvdrum>
FWIW, I've seen several comments on the ruby-build repo about people being confused by the 9000 version.
<headius>
9k will be 2.2 support out of the box, and that's it
<dfr|work>
headius, so if I'll want older version of ruby language, I won't be able to upgrade?
<headius>
we will maintain 1.7 for at least another year after 9k release
<headius>
longer if community steps up to help
<dfr|work>
headius, gotcha. I think it makes sense, but sucks for me specifically. :)
<headius>
yeah, it was more confusing for us than almost anyone
yfeldblum has quit [Ping timeout: 246 seconds]
nipra has joined #jruby
<mkristian>
what about 90.0.0 which is closer to 9000 and could have proper semantic versioning
<headius>
90!
<headius>
maybe we should figure out how many of our releases should have been major and go with that number
<headius>
e.g. 1.1.0 through 1.1.6 were all pretty major, but we didn't semver well
<chrisseaton>
I vote for 9.0 - it's not too wacky, but it also solves the problem with conflicting with MRI versions - simple
<nirvdrum>
Or, screw semantic versioning. I generally like the idea of it, but since it has no teeth, it falls apart pretty often. Particularly in ruby becuase there's no static typing to enforce anything.
<SynrG>
is 9000 a deliberate reference to Hal?
<chrisseaton>
Or how about JRubyX?
<Aethenelle>
lets just call it flamingo or something like that...
<nirvdrum>
Heh.
<nirvdrum>
The ubuntu model.
<nirvdrum>
Paired with a date-based release.
<Aethenelle>
i say we go 3.0 and stick to semver from there...
<nirvdrum>
Aethenelle: But if the overlapping versions is a concern, you'll run into it again the moment MRI goes 3.0.
<dfr|work>
headius, if you're only supporting 2.1 there, may as well call it 2.1 and use minor releases for additional releases.
etehtsea has joined #jruby
<nirvdrum>
If it's not a concern, 2.0 is just as valid as 3.0 then :-P
<dfr|work>
and once we only support 3.0 or whatever, then call it 3.0
<headius>
dfr|work: we don't want to be tied to MRI's version numbers for our semver
<Aethenelle>
nirvdrum: nah I was thinking apple... call it flamingo maybe have some sane version number that's hidden in the backgroud...
<mkristian>
counting the major releases so far and start from there sounds like 26.0 or so - sounds good to me
<headius>
I like ubuntu model myself
<headius>
it doesn't easily adapt to minor version changes though
<nirvdrum>
headius: That's predicated on a predictable release cycle though.
<dfr|work>
headius, I'm sure you can use minnesota lake names for codenames ;)
<mkristian>
but we also publish jruby-jars.gem would be nice to have sem-versions somehow/more or less
<nirvdrum>
Although the major versions do seem to take about 2 years to release, just like an LTS.
* nirvdrum
ducks
<Aethenelle>
i find ubuntu's rather annoying ... my real suggestion is to just do 2.0 (maybe 2.0.1)
<dfr|work>
also, with me butchering code I'm pretty sure we'll be up to 2.0.17 in no time.
<nirvdrum>
dfr|work: Stop trynig to help!
<nirvdrum>
*trying, even
<mkristian>
just stick to 9000.0.0 - still like the idea
<headius>
nirvdrum: well, there's major versions and there's rewrites...9k falls somewhere between the two
<nirvdrum>
mkristian: methinks you just don't want to fight with the pom again :-P
<lopex>
9000.0.(0.0001)
<nirvdrum>
headius: I'm just poking fun because I expressed concern early on about not a prolonged cycle like 1.7 was and enebo assured me that wouldn't be the case.
<mkristian>
nirvdrum, I will fight for replacing the "dev" with SNAPSHOT but anything else I can deal with ;)
<subbu>
SynrG, yes, I believe so (Hal reference)
<nirvdrum>
Or however that sentence makes sense. 4 hours of sleep hasn't made me terribly cogent today.
* SynrG
nods
<nirvdrum>
I guess there's always "JRuby ME"
<headius>
nirvdrum: we realized it would take longer, which is why we've kept 1.7 going...I think we're doing better at that than we did with 1.6
<headius>
maintaining 1.7 just slows down 9k work
<nirvdrum>
Yeah, double-edged sword.
<nirvdrum>
But I appreciate 1.7 is still maintained.
havenwood has joined #jruby
<subbu>
for headius and other northern hemisphere folks ... a good aurora showing tonight likely.