<headius>
yeah I think this is something wrong in the sh
<byteit101[m]>
headius: "Bikeshedding mostly." (re the name of the configuration)
<byteit101[m]>
I strongly disagree that it's bikeshedding. This is the one way users will interact with this functionality, and it's important to design the API correctly now so that we don't have to worry about fixing it later when people are actually using it.
<byteit101[m]>
I think it's right to fret over the name a bit
<byteit101[m]>
I'll put my reasoning in the PR
<headius>
enebo: it was a shell bug... referencing command line args past $9 without appropriate quoting
<headius>
so -Xbacktrace.style=mri (arg 1) was re-passed for $10 and $11 as ${1}0 and ${1}1 ðĪŠ
<headius>
byteit101: fair enough... like matz says, names are important
<headius>
I just don't want to seem petty about it
<byteit101[m]>
Not at all
<headius>
we get once chance to pick a name ð
<headius>
one
<byteit101[m]>
And we can discuss trying to pull the reified bits out of RubyClass, but as I discovered when I did the concrete extension, it's so tightly coupled that you end up having to pass lots of parameters around everywhere like the old (replaced) concrete extension code, and inner classes made it much simpler from that point of view
<headius>
yeah I get that so I didn't want to press the issue too hard
<headius>
we should prefer private when possible for internals, but if it's not possible right now then it's not possible
<headius>
it is kinda sorta RubyClass functionality, just Java visibility and encapsulation makes it hard for us to break it up into multiple classes
<byteit101[m]>
Yes, also it has to be public enough to be called by ruby code (class.rb)
<byteit101[m]>
I moved those two methods to vartablemanager, but had to make both public now as they must call each other and are in different packages
<byteit101[m]>
I wish Java had C# partial classes
<byteit101[m]>
I also wished several times for C++ "friend" scoping :-D
<headius>
yeah modules are supposed to help this but there's still nothing on the granularity of "friend"
<byteit101[m]>
> Java can't be your friend
<byteit101[m]>
:-(
<headius>
hah
<byteit101[m]>
headius: added comment about my naming ideas
<headius>
that weird shell script error is fixed by mrnoname's PR
<headius>
OOM is now visible
<headius>
byteit101: ok
adam12 has joined #jruby
<headius>
these failures are all over the place
<headius>
spec:compiler core dumped on 8 and 11, that should never happen
<byteit101[m]>
!!!
<byteit101[m]>
Trying to clean up the JRubyFX working dir I have, and one question I have is: "is rubyobj. going to ever change or should I try to hide it?"
<headius>
it will probably change
<headius>
we will want to emit that stuff under a JRuby-controlled package for module support, or else make it configurable to a known package
<headius>
in any case I just threw that prefix at it so no classes would end up in the default package
<byteit101[m]>
I had issues with that, fxmlloader only calls loadClass
<headius>
of course it does
<headius>
hmm docs say that should call findClass though
<byteit101[m]>
The black art of it is why I wanted more eyes on it though
<headius>
do you have an example error that results when it fails to load?
<byteit101[m]>
can make one real quick
<headius>
// to find the class.
<headius>
long t1 = System.nanoTime();
<headius>
// If still not found, then invoke findClass in order
<headius>
c = findClass(name);
<headius>
that's from java.lang.ClassLoader.loadClass, after it fails to get a class from parent
<byteit101[m]>
Wait which type of error do you want? if I remove findclass? or if I try to load "dsfjkladsfjkdsfajkladsf"? or both?
<headius>
if you remove loadClass
<byteit101[m]>
Well I'll be that works. Unsure what I did to cause it to error back then to make me add both
<headius>
nice
<headius>
it seems fine to me albeit a little terrifying to see ClassLoader extended from Ruby
<headius>
but that's what we're here for
<byteit101[m]>
:-D
<byteit101[m]>
no wait wrong emoji
<headius>
ð
<byteit101[m]>
aw drat it's a slack icon, not an emoji I was thinking of. Oh well, here's close: ð
<byteit101[m]>
Oh one question is: should the else going to the jruby classloader call load class or find class?
<byteit101[m]>
Oh I know why I started with loadClass: all the chaining class loader examples I saw only override loadClass
<headius>
yeah I think they are wrong
<headius>
black art
<headius>
I think the only reason to override loadClass is if you do not want to search parents
<headius>
so they may be shortcutting that or intentionally preventing it
<byteit101[m]>
Ah
<byteit101[m]>
Should my findClass call the jruby findClass or loadClass?
<byteit101[m]>
oh wait...
<byteit101[m]>
I should use the new super support
<byteit101[m]>
I like that better (see updated gist)
<byteit101[m]>
a new question, though, is should become_java! be idempotent? currently it's not
<headius>
OOM looks like a new Enumerator::Lazy test
<headius>
byteit101: probably
<headius>
it is a known issue but people probably shouldn't be loading this stuff in parallel either
<headius>
actually, definitel
<headius>
y
<headius>
there are some rules about concurrent classloading that we should consider too... though I think without specifying that the classloader is concurrency-safe it won't be used to load more than one class at a time
<headius>
ugh, you know you've got a memory leak when ever other process on the system has been paged out
<byteit101[m]>
yes I saw you had to do some registering, so though I was safe
<headius>
yeah probably fine in that regard then
<headius>
enebo: OOM is in TestEnumerator#test_lazy_chain, I will exclude and file a bug
<headius>
after I confirm that the suite can finish
<headius>
weirdly I would have expected it to be a thread starvation on an Enumerator test
<byteit101[m]>
Is there a "self" module at the root level? something that is `::` but with a java-acceptable name?
<headius>
for the default package?
<headius>
not sure what you mean by root level
<byteit101[m]>
::Foo == Something::Foo
<headius>
ah no there is not
<byteit101[m]>
Object may be usable for my purposes
<headius>
Object maybe would work ok
<headius>
yeah
<headius>
I guess that is it
<headius>
::Foo logic grabs Object and looks up from there
<byteit101[m]>
but Iam not sure how I feel about <?import Object.* ?> in fxml
<byteit101[m]>
Oh that's disturbing to look at: finding class Object.My$Module$TestClass
<headius>
we will want to reconsider the use of $ in the future too because it messes with tools that think that means inner classes
<headius>
it is fine at JVM level but e.g. javap and jdb treat it like it should be a dotted inner class and it is not
<headius>
on the to-do list somewhere
<headius>
enebo: with that one test excluded test:mri:core completes with 401 failures, 149 errors
<headius>
new tests pulled in a bunch of extra failures obviously
<headius>
interesting to note how few new failures have come from spec updates... 3.1 is not really in there yet
<headius>
ruby-core committers still generally add to the test/unit suite âđïļ
<headius>
ugh what did we do now dependabot
<byteit101[m]>
Oh this is coming from java, I have to deal with it
<headius>
bleh just integration tests using old puma, rake, bouncycastle
<byteit101[m]>
enebo: ^ ivar jrubyfx integration commit (using current PR, likely will change)
<byteit101[m]>
still some things I want to fix before 2.0 is released though
<headius>
CI looking better now
<headius>
hmm rake spec:ji running for 1h24m seems ungood
_whitelogger has joined #jruby
bensheldon[m] has quit [Ping timeout: 250 seconds]
oblutak[m] has quit [Ping timeout: 250 seconds]
oblutak[m] has joined #jruby
bensheldon[m] has joined #jruby
klobuczek[m] has quit [Quit: Bridge terminating on SIGTERM]
AndyMaleh[m] has quit [Quit: Bridge terminating on SIGTERM]
headius has quit [Quit: Bridge terminating on SIGTERM]
rebelwarrior[m] has quit [Quit: Bridge terminating on SIGTERM]
ssaschaa[m] has quit [Quit: Bridge terminating on SIGTERM]
kroth_lookout[m] has quit [Quit: Bridge terminating on SIGTERM]
puritylake[m] has quit [Quit: Bridge terminating on SIGTERM]
katafrakt[m] has quit [Quit: Bridge terminating on SIGTERM]
byteit101[m] has quit [Quit: Bridge terminating on SIGTERM]
Albertico[m] has quit [Quit: Bridge terminating on SIGTERM]
jamesgecko[m] has quit [Quit: Bridge terminating on SIGTERM]
daveg_lookout[m] has quit [Quit: Bridge terminating on SIGTERM]
rdubya[m] has quit [Quit: Bridge terminating on SIGTERM]
MattWelke[m] has quit [Quit: Bridge terminating on SIGTERM]
jtarvydas[m] has quit [Quit: Bridge terminating on SIGTERM]
mattpatt[m] has quit [Quit: Bridge terminating on SIGTERM]
kovyrin[m] has quit [Quit: Bridge terminating on SIGTERM]
basshelal[m] has quit [Quit: Bridge terminating on SIGTERM]
andreimaxim[m] has quit [Quit: Bridge terminating on SIGTERM]
nilsding has quit [Quit: Bridge terminating on SIGTERM]
marcheiligers[m] has quit [Quit: Bridge terminating on SIGTERM]
kares[m] has quit [Quit: Bridge terminating on SIGTERM]
enebo[m] has quit [Quit: Bridge terminating on SIGTERM]
oblutak[m] has quit [Quit: Bridge terminating on SIGTERM]
bensheldon[m] has quit [Quit: Bridge terminating on SIGTERM]
ahorek[m] has joined #jruby
ahorek[m] has quit [Remote host closed the connection]
ahorek[m] has joined #jruby
ahorek[m] has quit [Remote host closed the connection]
ahorek[m] has joined #jruby
enebo[m] has joined #jruby
lopex[m] has joined #jruby
subbu[m] has joined #jruby
andrea[m] has joined #jruby
Albertico[m] has joined #jruby
kroth_lookout[m] has joined #jruby
mattpatt[m] has joined #jruby
kares[m] has joined #jruby
katafrakt[m] has joined #jruby
AndyMaleh[m] has joined #jruby
bensheldon[m] has joined #jruby
basshelal[m] has joined #jruby
daveg_lookout[m] has joined #jruby
rdubya[m] has joined #jruby
rebelwarrior[m] has joined #jruby
oblutak[m] has joined #jruby
jamesgecko[m] has joined #jruby
MattWelke[m] has joined #jruby
byteit101[m] has joined #jruby
marcheiligers[m] has joined #jruby
kovyrin[m] has joined #jruby
puritylake[m] has joined #jruby
klobuczek[m] has joined #jruby
ssaschaa[m] has joined #jruby
jtarvydas[m] has joined #jruby
andreimaxim[m] has joined #jruby
nilsding has joined #jruby
headius has joined #jruby
subbu[m] has quit [Quit: Client limit exceeded: 20000]
ahorek[m] has quit [Quit: Client limit exceeded: 20000]
lopex[m] has quit [Quit: Client limit exceeded: 20000]
andrea[m] has quit [Quit: Client limit exceeded: 20000]
enebo[m] has quit [Quit: Client limit exceeded: 20000]
<headius>
good morning!
<headius>
ahorek: I've pushed the baseline GHA workflow to jcodings and will add the Java 11 build like in your workflow... you can then rebase and the PRs should switch over
<headius>
there's one failure in TestCP51932ToCP50220 that has probably been there for a while
<headius>
ahorek: I cherry-picked your workflow to master
<headius>
rebase and we'll see how things look on the PRs
<headius>
basshelal: looking at your January PRs for jnr-ffi now
<headius>
all generally look great
<headius>
everything merged, the test changes and documentation updates look great, thank you!
<headius>
it occurred to me we could hook up the Apple M1 instance we're using for JRuby testing to also test jnr-*, since that's pretty critical to M1 support... I will try to do that today
<headius>
as in try to do it right now
<headius>
hmm looks like runners can be shared across an organization but not outside that org
<headius>
I may be able to just run a second instance for jnr-* and since those tests are pretty clean it shouldn't interfere with JRuby CI
enebo[m] has joined #jruby
<enebo[m]>
headius: did you push that SNAPSHOT for master of JRuby?
<enebo[m]>
I don't think it will fix tons of tests but it will fix a handful
<headius>
snapshot?
<headius>
enebo: what do you mean
<enebo[m]>
of jcodings to pick up new encodings
<enebo[m]>
CESU-6 and new uniciode stuff
<headius>
oh no, I have not because ahorek PRs are not merged
<headius>
I can do a release once those are in and tests are passing
<headius>
basshelal: success, we have CI on Apple M1 for jnr-ffi
<enebo[m]>
Is Web3 actually real and even if it is...Could there really be this much interest?
<enebo[m]>
Also Railsconf CFP is up
<headius>
indeed it is, Feb 28 deadline
<enebo[m]>
I don't hold high hopes I will be travelling in May
<headius>
yeah I didn't think so, but I am willing
<enebo[m]>
We shall see how the world turns I guess
<headius>
I will need help putting it together, but the talks are only 30 min
<headius>
not sure if that includes Q&A or if that is punted to online forum
<enebo[m]>
This would be like old times since it is over my birthday like in the old days
<headius>
lopex: hey bud hope you are staying safe and health out there... there's a few PRs to jcodings from ahorek that you might be able to assist with
<enebo[m]>
lopex: Go lopex Go!
<headius>
enebo: and Portland! I haven't been back since the last time I did OSCON I think
lopex[m] has joined #jruby
<lopex[m]>
yeah, I've seen it
<enebo[m]>
headius: yeah railsconf at the same time and place. Nostalgic. Only that pesky pandemic which will not be over by then
<headius>
lopex: how have you been? I may be in your general region this summer
<enebo[m]>
It could be much better though. I long for the days of 2 cases per 100k
<headius>
enebo: here's hoping for an Extra Action Band half-time show
<basshelal[m]>
headius: Holy crap, the day my phone decides to not send me notifications smh
<basshelal[m]>
Also excellent that you merged the test PRs, this will really help me improve the upcoming tests much better since I won't have to worry about merge conflicts and other git complexities and what-not
<basshelal[m]>
Thanks a lot for this, this is a huge step for JNR, more to come!
<basshelal[m]>
This is excellent news regarding Apple M1! Let's go for more I say! GNU/Linux aarch64 and Windows x86_64 too, GitHub actions has both I believe
<headius>
yeah linux/arm64 for sure and whatever else we can get working in GHA
<headius>
ahorek: merged everything except the escape PR that has a mystery failure
<headius>
after my meeting I will have a look at that and the existing failure on master
ahorek[m] has joined #jruby
<ahorek[m]>
hey headius thanks, that mystery failure is the same as testXMLWithCharref, which started to fail after a unicode tables update (unrelated to my other changes)
<headius>
this complicates the handling of that rogue break in a thread
<headius>
might necessitate doing a stack search or tagging frames with a thread ID to be able to raise the LJE early
<headius>
though I am highly dubious about this use case
<headius>
I'm going to spike a thread ID. It will make frame larger but the field only gets set once at create time
<headius>
hmmm not frame though... scope... that is not as good
<headius>
enebo: do you remember why we have break target a scope and not a frame? I think we have gone back and forth but I can't remember why it uses scope now
<enebo[m]>
I don't recall but I would think perhaps we have more scopes around more often?
<headius>
this is the reduced example: def foo(&p); t = Thread.new { begin; p.call; rescue LocalJumpError; p 1; end }; t.join; end; foo { break }
<headius>
the block has not "escaped" like with a proc so the break would be valid, if it weren't across threads
<headius>
yeah we used to have a frame ID for this
<enebo[m]>
hmm perhaps the commit will have a message explaining why
<headius>
it goes back to IR transition I believe
<headius>
I'll just spike a change to frame and see what happens
<headius>
if break_spec and block_spec are reliable, then this breaks nothing so far