00:00
<
enebo[m] >
headius: I will try and build it in the morning. I was going to say I was not sure if I had it installed but I definitely did it for the false-positive virusy thing
00:42
<
headius[m] >
if I am bored this evening I might try to get it set up myself
00:42
<
headius[m] >
I hate this project, needs to be replaced
00:43
lucasb has quit [Quit: Connection closed for inactivity]
01:58
_whitelogger has joined #jruby
05:08
henry_bone has quit [Quit: henry_bone]
06:44
ur5us has quit [Ping timeout: 240 seconds]
07:14
ur5us has joined #jruby
07:27
<
rg_3[m] >
> rg_3: I believe so but they're kind of low priority while we try to wrap up the JRuby 9.2.11 series. I believe enebo fixed at least the `c-call` issue for 9.2.11 but he'll have to confirm that
07:27
<
rg_3[m] >
Thanks! 🙂
07:59
ur5us has quit [Ping timeout: 256 seconds]
08:56
shellac has joined #jruby
09:20
drbobbeaty has quit [Ping timeout: 240 seconds]
09:35
drbobbeaty has joined #jruby
11:28
_whitelogger has joined #jruby
12:44
lucasb has joined #jruby
15:17
claudiuinberlin has joined #jruby
15:54
<
headius[m] >
g'day folks
16:01
<
kares[m] >
enebo: that Range IRubyObject[] boxing thingy looked weird
16:01
<
kares[m] >
anyhow what did you mean by "just using java_import" ?
16:03
xardion has quit [Remote host closed the connection]
16:08
<
headius[m] >
what Range boxing thingy?
16:08
xardion has joined #jruby
16:12
<
headius[m] >
kares: I think that's not a problem of java_import but how constants are looked up
16:19
<
kares[m] >
oh really, hmm that might explain why I thought it worked some time ago ...
16:21
<
headius[m] >
that's basically what java_import is doing but constant searches are lexical first, and a block scope isn't a constant (cref) scope
16:23
<
kares[m] >
right, I posted a `Class.new {}` version there ... but there's still a (possibly different) issue
16:24
<
kares[m] >
yeah I extracted the wrong thingy ... will need to update the issue.
16:30
<
kares[m] >
the problem I think is java_import from an instance method
16:30
<
kares[m] >
it ends up putting a 'global' constant vs a class method puts it correctly ... which should be an easy fix
16:31
<
kares[m] >
but not for 9.2 as it might be considered breaking
16:32
<
headius[m] >
could be it's just using Object if called against a non-class?
16:32
<
headius[m] >
should that even be defined in an instance method?
16:34
<
kares[m] >
should not for sure but shit happens ...
16:34
<
kares[m] >
I mean there's a warning but I guess it got lost
16:35
<
kares[m] >
will need to think about this - does not strike me as that much of an issue now that I got it reduced
16:36
<
kares[m] >
there's 2 patterns here: either import globally or in an instance method ... than there's no wonder conflicts happen :)
16:36
<
headius[m] >
huh yeah, we do define it on Object
16:37
<
headius[m] >
a decade later and I realize it should be defined on Module and toplevel only
16:38
<
headius[m] >
and it does evals, omg
16:38
<
headius[m] >
I have not looked at this code in a long time apparently
16:39
<
headius[m] >
kares: yeah it's clear why this works the way you are seeing
16:39
<
headius[m] >
if self is module it does a class eval of this string that defines the constant
16:40
<
headius[m] >
class_eval is unnecessary but there it is
16:40
<
headius[m] >
if it's not a module it does an eval with the current binding, which is java_import inside Object, so it defines it in Object
16:41
<
headius[m] >
we need to deprecate java_import against a non-module
16:47
<
headius[m] >
I'm daring to patch this
16:47
<
headius[m] >
feels like brain surgery
17:08
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
17:08
<
headius[m] >
kares: I have a patch that passes and deprecates Object#java_import
17:11
<
headius[m] >
passes spec:ji that is
17:36
<
enebo[m] >
kares: That single arg path may still be forcing boxing and could doCall maybe
17:36
<
enebo[m] >
kares: it was totally just in a recursive loop until that commit though
17:40
<
headius[m] >
aha one failure in -Ptest
17:40
<
headius[m] >
something is using java_import in a peculiar way
17:45
<
headius[m] >
not passing block through the wrapper java_import defs
17:48
rusk` has quit [Remote host closed the connection]
17:59
<
enebo[m] >
yeah I was wondering since I do not think people had seen any notifications yet on talks
18:00
<
enebo[m] >
it was >1000 so we were not going to be able to do it anyways
18:00
<
headius[m] >
gonna get so much done this spring
18:01
<
headius[m] >
the timing wasn't great for me anyway with my kid's birthday the day before
18:08
<
rdubya[m] >
yeah, it was rather late this year
18:39
<
headius[m] >
it's green now
18:44
<
kares[m] >
looking good, but will visibility stay the same?
18:44
<
headius[m] >
negotiable
18:44
<
headius[m] >
you have a specific concern?
18:45
<
kares[m] >
testing things out ...
18:46
<
kares[m] >
oh right, this should work as before
18:46
<
kares[m] >
why do we need to also add java_import on main?
18:47
<
enebo[m] >
please think of what will specifically change here :)
18:47
<
kares[m] >
(java_import was only on Object before)
18:47
<
enebo[m] >
Seems reasonable to me generally as we should have done it this way to begin with
18:48
<
headius[m] >
it doesn't appear any code we have uses java_import against a non-module, other than obvious top-level calls
18:48
<
enebo[m] >
is there anything else which got some behavior difference from being done via module_eval which won't happen now?
18:49
<
enebo[m] >
self is self so I would assume a new constant would go to same place
18:49
<
headius[m] >
well it will parse using ConstDecl etc where I'm using the reflective calls now
18:49
<
headius[m] >
this code should be pretty close to equivalent but the syntactic constructs probably have minor differences
18:49
<
headius[m] >
it may be faster without the evals but I have not tried to measure that
18:50
<
enebo[m] >
I mean that is fine but I am hoping people are not doing millions of java_import
18:50
<
enebo[m] >
I say land it for 9.3 and hopefully something will shake out if we get it in
18:51
<
enebo[m] >
well hopefully nothing will shake out but the more time the better
18:51
<
headius[m] >
the eval cost is likely lost in the overhead of loading a Java class proxy
18:51
<
headius[m] >
but less eval is always good
18:51
<
enebo[m] >
yeah I just doubt we will see it in anything other than a microbench
18:54
subbu is now known as subbu|lunch
19:06
<
headius[m] >
ok I'll merge
19:08
<
headius[m] >
I'm moving on to other things
19:08
<
headius[m] >
enebo: anything from virus people?
19:09
<
headius[m] >
I'd like to pop this launcher issue off my stack
19:09
<
kares[m] >
fine by me
19:09
sagax has quit [Read error: Connection reset by peer]
19:24
<
enebo[m] >
headius: nope
19:25
sagax has joined #jruby
19:27
<
headius[m] >
kares: perhaps 9.3 should change Object#java_import to import into the self class?
19:27
<
headius[m] >
I'd rather just get rid of it (via deprecation) but that's another option
19:28
<
headius[m] >
so it would work like assigning a constant in a method (if that weren't a syntax error...)
19:34
claudiuinberlin has joined #jruby
20:03
subbu|lunch is now known as subbu
20:17
ur5us has joined #jruby
20:55
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
20:58
claudiuinberlin has joined #jruby
21:22
travis-ci has joined #jruby
21:22
travis-ci has left #jruby [#jruby]
22:57
ur5us has quit [Ping timeout: 256 seconds]
23:16
henry_bone has joined #jruby
23:19
ur5us has joined #jruby
23:56
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]