subbu has quit [Ping timeout: 260 seconds]
subbu has joined #jruby
<headius> enebo: small bug in ruby2_keywords prevents celluloid from loading... my proposed fix is small but we should chat about whether it's the right way
subbu has quit [Ping timeout: 272 seconds]
<kares[m]> <enebo[m]> "kares: Commit of interest: https..." <- thanks - will look into that. that test specifically assumed what is fuzzy territory - relying on to_java to return the RubyThread internals (by default) ... I would not fear "breaking" that in 9.4 esp. since there's still a way to get the internals by being explicit ...
<kares[m]> un-pended (and adjusted) at https://github.com/jruby/jruby/pull/7557
<enebo[m]> kares looks like a fine change but is there any expectation as a public API that native_thread() should still exist?
<enebo[m]> hahah
<enebo[m]> I really feel like there is a better signalling possible to know if you are in a code/text or just a message in this UI
<headius> what even did that?
<enebo[m]> It is funny because it clearly formatted kares after I typed it and somehow pushed it into that
<enebo[m]> headius: dsjkfhsdjk
<enebo[m]> headius:
<headius> you are using element client?
<enebo[m]> yeah
subbu has joined #jruby
<headius> weird
<headius> ```enebo:
<enebo[m]> I cannot even get it to code now...I thought it was tab
<headius> hmm I dunno
<headius> hmm
<enebo[m]> dsfjklfjskl
<headius> `enebo:
<headius> nope
<enebo[m]> dlsfkjdgfkl
<enebo[m]> kares: `sdflkj`
<enebo[m]> headius:
<enebo[m]> [headius](https://matrix.to/#/@headius:matrix.org):
<enebo[m]> I guess I do remember we realized they use markdown but I completed your name then highlighted the whole line and got a context menu which specified I could do 'code block'
<enebo[m]> dfjklsklfjdlkdfjs
<enebo[m]> ctrl-e is code block
<headius> aha so it still does completion in that mode
<headius> enebo:
<headius> hmm might be something different on mac
<enebo[m]> weirdly
<enebo[m]> So C-e will make a gray box for me as 'code'
<enebo[m]> how do you make the other color box
<enebo[m]> dsfhjkdfjskdfhsjk
<enebo[m]> dsfkljdskl
<enebo[m]> > foo
<enebo[m]> > hahaha wow
<enebo[m]> > this is pretty odd
<enebo[m]> > headius: does this work?
<enebo[m]> lol
<headius> not sure what mac shortcut is for that
<headius> asdf
<headius> supposed to be cmd+E but doesn't work
<enebo[m]> for me dsklfjdfjkl
<enebo[m]> ctrl-e will work if you highlight first
<headius> asdf
<enebo[m]> kdlfjdskl
<headius> oh yeah
<headius> so I can do [enebo](https://matrix.to/#/@enebo:matrix.org) and then ctrl+e
<headius> there it is
<headius> funny glitch
<enebo[m]> ok so summary '> something' is just vertical bar. `something` is code. '<tab>something' is gray box
<enebo[m]> My only remaining question is how to do a literal tab in this client
<enebo[m]> the code is using `
<enebo[m]> but on both sides of the text
<headius> yeah tab just flashes the text field for me
<headius> and then two tabs goes to the emoji button
<enebo[m]> dfjklsklf
<enebo[m]> I get the flash but it does not work
<enebo[m]> > `headius: `
<enebo[m]> I was hoping to get the trifecta
<headius> ha
subbu has quit [Ping timeout: 252 seconds]
adam12 has quit [Quit: Ping timeout (120 seconds)]
adam12 has joined #jruby
<nilsding> just wait until you figure out how to use colours :D
<enebo[m]> Jyrki: I hope that did not take you 2 minutes to write 🎉
subbu has joined #jruby
<nilsding> thankfully not
<enebo[m]> haha
* nilsding knows about element's /rainbow shortcut 😇
<enebo[m]> the more you know 🎉
<headius> wat
<enebo[m]> HAHA those both are perfect
<enebo[m]> @headius:matrix.org
<enebo[m]> I wonder if that pinged you
<headius> aww, none of the old mirc commands
<headius> I was looking at it so i don't know if it pinged
* headius slaps enebo around with a large trout
<enebo[m]> `def foo
<enebo[m]> "foo"
<enebo[m]> end`
<enebo[m]> ok code did not keep newlines
<enebo[m]> or actually be code at all
<nilsding> you can use the usual markdown code-fences here, even with syntax highlighting and all
<enebo[m]> emote seems to be pervasive in all slash command systems...even server management
<nilsding> def foo = "foo"
<enebo[m]> def foo = "bar"
<enebo[m]> yeah and the facebook shift-return
<enebo[m]> which I suppose happened way before facebook
<headius> def foo
<headius> end
<headius> a = 1
<headius> ahh it recognizes ```ruby now
<enebo[m]> I wonder how they highlight ruby since they got endless methods
<headius> noice
<enebo[m]> I am not surprised since they have existed for years
<enebo[m]> but still wonder what is doing it
<headius> it didn't work when I tried it last, probably a year ago
adam12 has quit [Ping timeout: 272 seconds]
<nilsding> i don't think a code highlighter needs to do anything special to support endless methods... at least the one from Kate didn't need any change for that
<nilsding> it still wants to indent after one though, need to somehow teach it to not do this
<headius> this pulls in some code from master for handling n == 0 (with n << m or n >> m) but we'll see if that affects tests
<headius> more duplication than I'd like but it's fine
<enebo[m]> ok
adam12 has joined #jruby
<headius> enebo: I see no code in MRI to ignore invalid Etc.sysconf values and it does indeed raise when I give it a totally bogus request
<headius> We are pretty much just propagating the sysconf errno here
<headius> that is pretty much it... only error case that gets through is errno=0 and EINVAL clearly is not that
<enebo[m]> headius: you saw though that 9.4 works and 9.3 does not
<headius> yeah I don't get it
<headius> perhaps those constants are getting bad values now?
<headius> master has a slightly newer version of jnr-constants
<enebo[m]> well it is mysterious
<enebo[m]> HAHAH
<enebo[m]> SC_SYMLOOP_MAX is 173 for both 9.3 and 9.4
<headius> what you have is different from CI
<headius> CI is like this
<headius> Errno::EINVAL: Invalid argument - No message available
<headius> 1)
<headius> EINVAL
<headius> Etc.sysconf returns the value of POSIX.1 system configuration variable SC_SYMLOOP_MAX ERROR
<enebo[m]> yeah it is different
<enebo[m]> what would an invalid argument even be here
<headius> well I get the same with Etc.sysconf(99999999)
<headius> seems like a sysconf constant that is no longer supported on whatever flavor of Linux GHA updated to
<enebo[m]> so bad constant value I suppose whereas for 9.3 on my machine it is an unknown error
<enebo[m]> 173 is something on my system but not the right thing perhaps
<headius> can you check what errno is when it fails?
<enebo[m]> and on CI it nothing at all
<enebo[m]> but what could have changed to make 9.4 work
<headius> like 0
<headius> i fit is zero that may be a missing piece for your case... SystemCallError only gets raised when we don't recognize the Errno
<headius> which is valid for sysconf to return if there's no limit set
<headius> I mean valid for errno.. sysconf return -1 and errno = 0 means no limit
<headius> that is handled in the MRI C code
<enebo[m]> oh so perhaps updated constants has more errnos
<headius> I'm not sure when this started failing on 9.3
<enebo[m]> but the theory here is that CI stopped having that constant available
<headius> Operating System
<headius> Ubuntu
<headius> 22.04.1
<headius> LTS
<headius> so they upgrade to a very recent Ubuntu at some point
<enebo[m]> The other obvious issue is that we probably have the wrong value
<enebo[m]> Or it is a possible problem
<headius> yeah master checks errno == 0
<headius> I bet that is your issue
<headius> 9.3 should add that but it won't fix the CI fail
<headius> the CI failure seems like legit invalid sysconf values but I am confused why MRI running rubyspecs does not fail it
<enebo[m]> headius: looks like errno == 0 on 9.3
<headius> ok so that explains that one
<lavamind[m]> I've seen Etc.sysconf return values differ whether the test is running in a chroot, container, VM, so its not only OS-specific but seems affected by the platform too
<enebo[m]> which I guess you figured out from looking at code but I guess this confirms it
<headius> yeah thanks
<enebo[m]> why does intellij make it hard to select commit
<enebo[m]> I fixed this in 10/31
<headius> lavamind: yeah I dunno if that could also make some values invalid
<headius> the errors on CI and apparently on those Debian builds seem like legit EINVAL
<enebo[m]> 357e078
<enebo[m]> So this has two fixes in it
<headius> yeah never applied to 9.3?
<headius> I wonder if the posix.errno(0) is the missing bit for 9.3
<enebo[m]> nope. It was just me seeing this error on 9.4 CI and not realizing we needed it on 9.3
<headius> could it be picking up old errno
<enebo[m]> probably since in last 2 months we have not did much on 9.3
<headius> I will try a PR for 9.3 that does both
<headius> I have it partially done already
<enebo[m]> Just cp this commit
<headius> I'll just cp your commit
<enebo[m]> it has both things in it
<enebo[m]> but is ret == -1 it is surprising to see sysconf not set errno
<enebo[m]> but it required that set to make something work
<lavamind[m]> 9.3 also has a pending security fix I think
<lavamind[m]> would be nice to be able to push that into Debian
<headius> yeah 9.3.9.1 milestone is still open
<lavamind[m]> I'm getting close to fixing CI for Debian, only armel and armhf still have errors
<headius> enebo: 9.3.9.1 or 9.3.10 next week perhaps while I finish refinement fixes
<enebo[m]> yeah 9.3.9.1 for sure
<enebo[m]> 9.4.1.0 I think we need to fix a few more reported issues
<headius> ugh wtf gha
<headius> only queued one job
<enebo[m]> but we may get those done soon
<headius> ok nevermind it just took a long time
<headius> 9.4.1.0 could be week after easily enough
<enebo[m]> It really just depends on progress
<enebo[m]> I think we both agree user reported issues we should do before release
<enebo[m]> which I think there is like 4-5 open still
<headius> yeah I have been trying to stay on top of them other than over break
<enebo[m]> probably ~10 already fixed
<headius> there's that indy super one and other refinement issues on my plate
<enebo[m]> the indy super is unclear how to repro
<enebo[m]> It might be simple to repro with a small controller
<enebo[m]> I fixed the other super issue yesterday
<headius> ok
<headius> we have gotten no feedback from indy super reporter either so I dunno
<enebo[m]> I think if we run mri or spec with compile.invokedynamic on we may see it
<headius> lshift/rshift overflow thing is merged on 9.3 but I want to get that branch green before merging to 9.4
<enebo[m]> I don't think we matrix that anywhere do we?
<headius> we do
<headius> I think
<enebo[m]> hmm
<headius> hmm I thought we did
<headius> we have other suites doing indy
<headius> I guess only test:jruby and spec:compiler
<enebo[m]> headius: so we may see it running super in mspec with indy on
<enebo[m]> headius: MRI will have a lot more super tests too
<enebo[m]> so that one is even more likely to hit it
<headius> yeah we should add a run of each
<headius> that's a couple day project probably... there may be other small failures
<enebo[m]> I mean I agree in spirit :)
<headius> a good project though
<enebo[m]> we should definitely strive to run in all supported modes but our CI is biggish
<headius> when we drop 8 and possibly 11 it will be much more smallish
<headius> we could probably drop 11 now even
<headius> unlikely that it would fail if 8 and 17 pass
<headius> "unlikely"
<headius> progressives suck for lap coding
<headius> rubyspec is passing with your commit on 9.3
<headius> other tests still failing with that libutil thing
<enebo[m]> dropping 11 is fine by me
<enebo[m]> but the other thing is if we do not have the rake tasks it would be good to just be able to spec:ruby:fast:indy
<enebo[m]> which perhaps is there now
<headius> it is not but that would be nice
<headius> I modified the ffi_lib line for libutil to match subspawn, so with any luck that will fix it
<headius> byteit101: did you do anything else to fix the libutil issue?
<headius> also wondering if we could use subspawn in 9.3 after all
<byteit101[m]> Just that
<headius> at least for pty
<byteit101[m]> The benefits of a library.
<byteit101[m]> btw I think I mentined this, but I will have some time to work on win32 subspawn closer to the middle of this month
<headius> yeah it would be nicer than hacking the existing poor pty impl
<headius> removing 11 from CI kills one test:mri, two spec:ruby:fast, and one spec:ji
<headius> I only removed where we are testing 8 and 17 also
<headius> ahh and a couple mvn runs
subbu has quit [Ping timeout: 272 seconds]
<headius> PR looks green!
<headius> 9.3 merged to master and lshift/rshift change is done everywhere
<headius> enebo: did you look into the sequel failure at all?
<headius> on 9.3
<headius> it seems to be real
<enebo[m]> on 9.3?
<headius> yes
<enebo[m]> oh perhaps sequel was not our regression then
<enebo[m]> I was really confused how any recent commit could have done it
<enebo[m]> running on head of another project I guess gives us advanced notice
<enebo[m]> I will look a bit. It must be uncovering something
<headius> well it could be our fault but not a regression... something new on sequel we aren't doing right
<enebo[m]> oh I assume it is our fault :)
<enebo[m]> but if it hits something people do not typically do then it is just sort of our cross to bear
<headius> yeah
<enebo[m]> did a pull and running specs in project
<enebo[m]> zero bugs ship it
<enebo[m]> That is 9.4 but that was not passing yesterday
<headius> also this one seems to be consistent: https://github.com/jruby/jruby/actions/runs/3858018142/jobs/6576067750
<headius> might be another env change triggering it on GHA
<headius> 1) Failure:
<headius> Exception raised:
<headius> <#<Errno::EOPNOTSUPP: Operation not supported - No message available>>.
<headius> TestFileUtils#test_cp_r_symlink_preserve [/home/runner/work/jruby/jruby/test/mri/fileutils/test_fileutils.rb:428]:
subbu has joined #jruby
<enebo[m]> hmm ok so same error in 9.3 and 9.4 and it is hitting I am guessing sqlite3
<headius> enebo: I proposed a fix for this last night but not sure about it: https://github.com/jruby/jruby/issues/7556
<enebo[m]> I was green locally but I did not do a fresh bundle install
<enebo[m]> headius: hmm. That is a tough one
<enebo[m]> So they made their own method type and it does not implement MethodArgs
<headius> yeah
<headius> no it is our type
<headius> from include JRuby::Synchronized to wrap all methods with synchronization
<headius> SynchronizedMethod does not impl IRMethodArgs
<enebo[m]> Let's walk through this a bit
<enebo[m]> SynchronizedMethod is a wrapper around the real method
<enebo[m]> and can you still call the real method AND the synchronized method?
<enebo[m]> like def foo; alias something_else, foo; sync foo
<enebo[m]> Weird unrealistic case of making a method which you have two entry paths AND one should be ruby2_keywords and one shouldn't?
<enebo[m]> I suppose those alias is a bad example
<enebo[m]> since it will obey the original definition so ruby2_keywords will happen affect the alias
<enebo[m]> perhaps synchronized is the same
<enebo[m]> I do not see this IRMethodArgs for AliasMethod either so I wonder if we can crash on ruby2_keywords :alias_name
<enebo[m]> jruby -e 'def foo(*r); end; alias :bar :foo; ruby2_keywords :bar'
<enebo[m]> BOOM!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<headius> enebo: the synchronized thing happens at lookup time... it adds in a later that wraps all methods with the wrapper
<headius> ah same thing
<headius> so maybe what we need to do is move this method up into DynamicMethod and some just won't do anything?
<headius> the delegating wrappers will just delegate
<enebo[m]> I think maybe it is ok to getRealMethod
<headius> I'm ok with that too as long as there's no wrapper that should have this set directly
<headius> I don't think there is
<enebo[m]> I am trying to nail this down in seeing how MRI behaves but it woudl be weird if an alias could behave like ruby2_keywords but the original didn't
<enebo[m]> It would be nice if both types did have it though
<enebo[m]> This should just be encapsulated in the method type
<headius> the wrappers could implement it but they'd need all contained methods to implement it
<enebo[m]> At the time I remember thinking non-native methods would all implement this so I think what I missed was that we have alias (and I guess sync)
<enebo[m]> but those are wrappers around the real thing
<headius> yeah
<enebo[m]> alias and sync can get the method they delegate through so I think they just delegate.setRuby2KJeywords
<enebo[m]> The actual guard is in ruby2_keywords just against isNative
<enebo[m]> public boolean isNative() {
<enebo[m]> }
<enebo[m]> return entry.method.isNative();
<enebo[m]> So this is aliasmethod
<headius> yeah
<headius> I think it could move up
<enebo[m]> I believe if we just roll with how this is written now synchronizedmethod needs isNative. We could push this down to NativeMethod as well I guess and perhaps raise or something
<enebo[m]> I think either way setRuby2Keywords is impld on both alias and sync
<enebo[m]> which just calls same method on its delegate
<enebo[m]> but we could mark it as abstract on dynamicMethod and remove the case
<headius> yeah it just can't appear there unless they implement IRMethodArgs which pulls in other stuff (that might also be valid)
<enebo[m]> cast
<enebo[m]> or making a raising impl but I would rather audit uses
<headius> is this an IR thing or a general method thing
<enebo[m]> general method feature
<headius> then I think it should move up to DynamicMethod and be unimplemented where appropriate
<enebo[m]> IR will implement the behavior on passing and not unmarking keywords status to args passed into a rest arg
<enebo[m]> but the notion of this is ruby semantic and not really IR
<headius> arguably all methods should implement args interface too but that's a larger discussion and we use that interface to switch logic sometimes
<enebo[m]> you make a good point the cast makes it look like this is purely IR
<headius> right
<enebo[m]> yeah we have the issue that we migrate to newer things over time and this is a newer thing
<enebo[m]> So I believe we have to make a concrete setRuby2Keywords now too
<enebo[m]> and probably a no-op
<enebo[m]> If anyone has made their own DynamicMethod anywhere it will stop working if abstract
<enebo[m]> That is unlikely but not impossible
<headius> ok, do you want to fix sequel or this 😀
<headius> it won't be abstract, it just won't do anything in base impl
<enebo[m]> I can fix this
<enebo[m]> I have a pretty good idea on what is needed
<headius> ok
<headius> sequel is the only thing red on master
<enebo[m]> sequel though I will help with when I finish if you get stuck
<headius> those other ones are intermittent
<headius> lavamind: that one seems to be intermittent, maybe you have seen that
<enebo[m]> it appears to be connecting to what I am guessing is sqlite3 and getting lots o options
<headius> yeah I have to relearn where things are in sequel every time this comes up
<enebo[m]> which could also be something with sqlite3 gem on our side
<enebo[m]> sequel is testing against activemodel 7.x
<enebo[m]> and we are not 100% against it in unit tests
<headius> ah true, is that a recent change?
<enebo[m]> although this test may not be using activemodel
<enebo[m]> I don't know. Until an hour ago I assumed this was a recent regression on 9.4
<enebo[m]> So semantically no one considered this
<enebo[m]> oh wait hahaha...my fault
<enebo[m]> gist updated
<enebo[m]> So marking the alias to be ruby2_keywords will in fact mark the original version
<enebo[m]> This seems right and it is simpler
<headius> ah yes
<headius> there was some major reorg of sequl sources on dec 21
<headius> this failing test appeared that day and I have no lineage for where it cam from
<headius> oh nevermind, I didnt notice this CI script only goes ten deep
subbu has quit [Ping timeout: 260 seconds]
<headius> so it was still pretty recent
<headius> looks good
<enebo[m]> that looks fun.
<enebo[m]> Have you been able to run this locally and have it fail?
<enebo[m]> I just did rake specs and everything was fine
<headius> gotta be some logic just not dropping these keys in a hash
<headius> they are meta keys it uses to box the numeric values and then shouldn't be in the key list
<enebo[m]> err wait. I had just reran bundle install fresh
<enebo[m]> I have to run again to see if I see the error
<headius> I do not have mysql and it seems to fail during that
<headius> there's a line in this commit about sqlite not limiting integer values so it may be a no-op there
<enebo[m]> so zero failures for me this time too
<enebo[m]> It maybe is skipping these tests for me
<headius> I don't see where it is removing these keys from the schema
<enebo[m]> can you repro this locally?
<headius> there's another commit
<headius> no
<headius> I have not reproduced
<headius> taking a first look at the commits that added this functionality
<headius> this is a later commit
<enebo[m]> It would appear to have conditional db logic here
<headius> this could be his bug
<enebo[m]> This is mysql issue
<headius> something different about jdbc that is causing this to not work right
<enebo[m]> if DB.send(:supports_check_constraints?)
<headius> I'm pinging Jeremy
<enebo[m]> If this is true then it will have non-empty decimal types and this check will not even happen
<headius> I don't see anything in this code that would indicate it's our bug
<enebo[m]> If it is false then it does
<headius> it may be making this constraints calculation wrong for JDBC
<enebo[m]> yeah does he call jdbc directly?
<headius> somewhere in here
<headius> yes
<enebo[m]> yeah then unless we broke JI in some way this is just a JDBC thing
<headius> right
<headius> that's what I figure
<enebo[m]> it is strange looking at this because he is using same names as Rails for some of this
<headius> some feature in jdbc that isn't mapped right or has different metadata
<headius> your PR is green
<headius> CI time definitely reduced by removing 11
<headius> enebo: I'm going to wait to hear from Jeremy on this one and see about getting some indy runs in CI
<headius> enebo: it is older mysql
<headius> his CI passes on 9.1-9.4 but uses latest mysql
<headius> it is a bug in sequel otherwise
<headius> it should not be returning these columns on earlier mysql... he's going to fix that
<headius> and I am doing this PR to update our CI to closer match his
<enebo[m]> coolio
<headius> green
<headius> oh I should have set postgresql to latest too
<headius> well with any luck these should all go green
pcarlisle[m] has joined #jruby
pcarlisle[m] has left #jruby [#jruby]