<adam12>
Trying to get a gem running on Github actions. I've got the strangest error that only occurs on Github. Runs fine in locally. The rspec-core dependency "missing" is present in Gemfile.lock. Anybody seen this before? https://github.com/adam12/roda-enhanced_logger/runs/1560878956
<adam12>
Ah. Sorted it out. I ship a Gemfile.lock and because the ruby action sets the deployment flag, it didn't catch the change in dependencies for jRuby. Ran locally, the Gemfile.lock updated, and then worked fine when committed.
bjfish[m] has quit [Ping timeout: 268 seconds]
MarcinMielyskiGi has quit [Ping timeout: 268 seconds]
bjfish[m] has joined #jruby
MarcinMielyskiGi has joined #jruby
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 264 seconds]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 264 seconds]
<jeremyevans>
adam12: You may want to avoid using a lock file. In general it's a bad idea for libraries, as it makes you more likely to miss breakage in newly released dependency versions.
<headius[m]>
wee unpack 'j' support and 250 fewer tags
<adam12>
jeremyevans: I have generally avoided it but lately I saw advice that said it was better for contributors since you knew they were working with the same dependencies as you expected. Double edge sword I suppose.
<jeremyevans>
adam12: that advice is bad, my advice is better :)
<jeremyevans>
adam12: Really, it's a tradeoff. Do you want more robust software, or do you want it to be easier for new programmers to contribute?
<adam12>
jeremyevans: Haha ok. It seemed sound to me; I tried to find the thread but I had an epic one a while back where it was a "works on my machine" scenario; getting the Gemfile.lock helped drill down the failure. I even thought Yehuda had walked back on his suggestion from 100 years ago.
<adam12>
jeremyevans: Can't I have both? :P
<adam12>
jeremyevans: You're right tho. There's other gotcha for shippin a Gemfile.lock; like the version in the lock for that gem being out of date.
<headius[m]>
oy vey
<headius[m]>
I am not going to get anywhere adding 'a' support to printf
<headius[m]>
kares: I saw you added some 'f' logic last year and started 'a', if you finish that we will have a bunch of new passing specs
<headius[m]>
I'm going to look into these blocks of spawn failures since I am more familiar with that code
<kares[m]>
heh totally have no idea about sprintf at this point :) - there might be reason why I did not finish
<headius[m]>
yeah I can't even tie our logic into the CRuby impl which makes translating this 'a' logic pretty frustrating
<headius[m]>
we would like to make an effort to improve pass rate on specs and CRuby tests for 9.3 so that is kinda the holiday side project
bjfish[m] has quit [Ping timeout: 260 seconds]
bjfish[m] has joined #jruby
jmalves has joined #jruby
<jmalves>
Hey all! I could not find this in JRuby issues. Could someone tell me if this is a known bug?
<jmalves>
3: from /Users/jalves/.rvm/rubies/ruby-2.5.0/bin/irb:11:in `<main>'
<jmalves>
2: from (irb):1
<jmalves>
1: from (irb):1:in `shuffle'
<jmalves>
ArgumentError (wrong number of arguments (given 1, expected 0))
<jmalves>
Crucially the shuffle method in JRuby does not fail but also does not use the passed prng!
<jmalves>
(sorry for the confusing formatting above)
<headius[m]>
jmalves: howdy!
<jmalves>
Hey headius! The correct usage is with `random: prng` and that works in both. I did some quick checking and named arguments seem to work fine in JRuby.
<headius[m]>
so that works for both but we should not be taking a prng as an argument
<headius[m]>
I would guess we are just missing an error condition in the logic that checks for the keyword args
<headius[m]>
so it tries to coerce to a Hash, fails, and just moves along
<jmalves>
Yeah, I don't think this is a major issue (but I have to say I spent quick some time trying to figure out how the hell these fuzzy tests were not working :P)
<headius[m]>
hah I bet
<jmalves>
I will create the issue anyway if it is a new thing
<headius[m]>
do that
<jmalves>
ok
<headius[m]>
it is probably a one-liner fix
<headius[m]>
ah yes
<headius[m]>
CRuby logic decrements argc only if it finds a hash, and then does a check for argc == 0
<headius[m]>
we don't do any of that so if you pass something that is not hashable we just ignore it
<jmalves>
I wonder if similar cases could happen on other methods like shuffle that take named arguments
<headius[m]>
it is a case by case thing... we don't have pointers and "out" variables in Java so we have to manually do the two parts of kwargs checking (check for kwargs and decrement total arg count)
<headius[m]>
the prng arg was just added without considering this error condition
<jmalves>
BTW headius I have been trying to find a couple more of this kind and I have noticed that `ArgumentError (wrong number of arguments calling `initialize` (given 3, expected 0..2))` gives wrong results for the expected sometimes
<jmalves>
Not really of any practical inpormance ofc
<headius[m]>
wrong results?
<headius[m]>
like the numbers are wrong?
<jmalves>
Yeah for example, if I run `String.new('hello', 'UTF-8', 25)` it says it expects between 0..2 arguments
<jmalves>
If I run String.new('hello', 'UTF-8') it says it expects 1 argument
<jmalves>
Yeah
<jmalves>
I have noticed this in other methods not just this case
<jmalves>
I can also create an issue for this, if you think it is appropriate.
<headius[m]>
ah yeah that is a side effect of us trying to split up the different arities with their own logic
<jmalves>
Found another discrepancy in keyword arguments also, the following should fail: `String.new('hello', encoding: 'UTF-8', WRONG_METHOD_ARGUMENT: 25)`
<headius[m]>
sometimes the error isn't updated everywhere when a new supported arity happens
<headius[m]>
perhaps you could try a PR for some of these simple ones
<jmalves>
Yeah all this is really minor
<headius[m]>
mostly it is updating what we use for min/max in the error logic
<headius[m]>
so it is consistent
<headius[m]>
and maybe move the error to a util method all paths can call or something
<headius[m]>
they do this in other places too because they can't optimize kwarg calls from ruby to C
<headius[m]>
we need to rework how we bind methods to optimize hash but I'm not going to pollute the system with a bunch of hidden methods to do it
<jmalves>
Ok I see your point
<headius[m]>
we would do it by having something in JRubyMethod annotation like keywords = true and have an extra arg that gets kwargs if present
<headius[m]>
it's on the list, someday
<jmalves>
Yeah like optional = {"random"} instead of optional = 1
<headius[m]>
right
<headius[m]>
the other problem with the MRI way is that we can't share any of that Ruby code unless we also implement these internal names
<headius[m]>
they do this in socket.rb and I have to patch those hidden methods out
<jmalves>
Yeah I see how it can be annoying
ur5us has joined #jruby
subbu|lunch is now known as subbu
jmalves has quit [Remote host closed the connection]
jmalves has joined #jruby
jmalves_ has joined #jruby
jmalves has quit [Read error: Connection reset by peer]
jmalves_ has quit [Remote host closed the connection]
<headius[m]>
ugh what now travis
<headius[m]>
maven builds randomly failing
<headius[m]>
enebo: maven hosed on travis, I cleared all repository caches and restarted some jobs
<headius[m]>
you will need to restart your env builds if you want them to go green
<enebo[m]>
ok I will push some more commits while I am at it
<headius[m]>
not sure what broke but it wasn't our doing
jmalves has joined #jruby
<enebo[m]>
ok pushing restarted it anyways
<headius[m]>
my builds looking better now
<headius[m]>
or not
<headius[m]>
ok travis is just hosed
<headius[m]>
now I have builds just stopping and being marked failed
jmalves has quit [Ping timeout: 268 seconds]
<headius[m]>
well the array fixes are merged for all branches at least
<headius[m]>
back to spawn stuff
<headius[m]>
whittling, whittling away
<enebo[m]>
amazingly nothing is failing from the conversion error message I changed but i guess almost nothing cares about string messages of TypeError
<headius[m]>
fixing up some env related features at the moment but most of these tags are either trivial or impossible
<headius[m]>
heh yeah why would you
<headius[m]>
we are limited by what we can do with posix_spawn
<headius[m]>
I never really did a refactoring pass after porting over all this spawn code
<headius[m]>
it could probably be a lot cleaner and lighter
<headius[m]>
down to 7 failures for Process.spawn, but I think all but the umask spec are fixable
<headius[m]>
this should cascade into system, exec, and some other spawn forms
<headius[m]>
ok either something is up with sequel or I broke something weird
<enebo[m]>
byteit101: as far as last IR question (I will look at others tomorrow) we will just refactor when/if we decide to fully compile
<enebo[m]>
byteit101: The likelihood is we will want this code to JIT and not only be using the startup interpreter since this code could end up hot
<enebo[m]>
but making the JIT split will be a subtantial change so it won't be soon
<enebo[m]>
ok 29 tags in env are done looks like maybe 2 errors for the rest to be fixed
<byteit101[m]>
enebo: sounds good
<headius[m]>
I will have to look into these sequel failures tomorrow
<headius[m]>
everything else seems green so it is a mystery
jmalves has joined #jruby
jmalves has quit [Ping timeout: 260 seconds]
ur5us has quit [Ping timeout: 260 seconds]
<jeremyevans>
headius[m]: Failures occur in the jdbc/sqlite adapter tests, with almost all failing. Broken jdbc driver? No recent release of jdbc-sqlite3, so I don't have a good idea.
<headius[m]>
yeah it is pretty weird, that one just completely blows up
<headius[m]>
I will try before my shuffle/sample changes from today and see if it is green later
<headius[m]>
those changes were all green so I am unsure what's up
<jeremyevans>
Found the problem. In short, eliminating unused variables isn't always a good move :)
ur5us has joined #jruby
<jeremyevans>
I usually test on jdbc before pushing, but I'm working remotely and that is significantly more involved now. Figures that when I skip it is a time it actually matters.
<headius[m]>
isn't that always the way
<headius[m]>
thanks, I was baffled how fixing arity errors in shuffle and sample could break something so badly
<headius[m]>
keeping each other honest for another week
<jeremyevans>
Yep. I works both ways. It was failing in Sequel CI too, but I hadn't received the report yet because the job had been running for over 3 hours without failing
<headius[m]>
ok signing off for now... spawn is down to four failures, three should be fixable, and then I will check other spawn forms for old tags