<headius>
enebo: need to decide if we are updating stdlib too... gems are mostly current but there's some remaining stdlib files
<headius>
it's a risk last minute but unsure how much of a risk
<headius>
byteit101: PR looks fine, but I missed something with the removal of pty.rb... does subspawn handle the fallback case where we can't use LFP?
<byteit101[m]>
do you mean windows? or posix but no LFP?
razetime has joined #jruby
<byteit101[m]>
hmm.. do any windows envs (msys, cygwin, etc) have today-working pty.open impls?
<headius>
I mean you delete most of the contents of our old ffi-based pty.rb, is that old logic still a fallback somewhere or unnecessary?
<headius>
* ideally we would not add to the base set of files in LOADED_FEATURES... that's why we use `load` forms for the ruby parts of JRuby core
<headius>
in this case it's not super important since you have to opt in
<headius>
* Windows should probably not load AND warn
<byteit101[m]>
ah excellent, I did have questions about how to load
<headius>
yeah if you can use load that might be best, but these are also coming from stdlib and not the ruby kernel
<headius>
I think we leave it for now and maybe chat with enebo tomorrow
<byteit101[m]>
^key fact
<byteit101[m]>
i don't really want to publicize the ENV, as it should only be used for internal JRuby & subspawn testing. normal users should instead call `require 'subspawn/replace'`
<headius>
load really only works if: A. the file you load doesn't proceed to require other files and B. the loaded files WILL NOT be loaded later on and confuse things
<headius>
ok that's fair
<byteit101[m]>
Oh no, load won't work. Huge chain of almost circular deps
<headius>
right that's what I figured
<headius>
so what you have is good for now
<headius>
I'm fine merging it
<headius>
pretty much zero impact since you have to opt into the new spawn, and pty.rb was so broken before it's unlikely to get worse
<byteit101[m]>
I only required the top level gem from the pom, not the other 3 dependant gems
<byteit101[m]>
pty.open could break in theory
<byteit101[m]>
> Though given that I seem to report like 50% of the critical PTY issues in the past several years, I'm not sure how many users there are
<byteit101[m]>
^ but then again :-)
<headius>
ahh hmm I guess I don't know if the build handles transitive default gem deps... does it put those other gems in stdlib too?
<byteit101[m]>
it pusts them in gems and complete jars work
<byteit101[m]>
I was unsure too
<headius>
so if gems are not activated what happens
<byteit101[m]>
activated?
<headius>
run with --disable-gems
<headius>
default gems in stdlib should still work
<byteit101[m]>
ah, let me go back to my branch, hold please
<headius>
we might need to explicitly put all the transitive gems in default gems too
<headius>
so they get copied in and work without RG loaded
<headius>
yeah
<byteit101[m]>
bin/jruby --disable-gems ?
<byteit101[m]>
also, did I put it in the right section?
<headius>
looks like it is in the default gems section, which is right if we want it to be loadable from stdlib without RG
<headius>
and since pty.rb is in stdlib that seems right
<byteit101[m]>
rebuilding. mvn clean package -Pcomplete usually fails when I switch branches and I have to run it again
<headius>
yeah I usually keep a separate working copy for major branches
<headius>
the build and IDEs get screwy with too many changes
<headius>
ugh I have to fix this laptop to default to function keys
<byteit101[m]>
oh so annoying when it defaults to media keys
<headius>
ctrl+shift+fn+Fkey ffs
<byteit101[m]>
build success, lets try
<byteit101[m]>
LoadError: no such file to load -- subspawn/posix
<byteit101[m]>
indeed, no transitives
<byteit101[m]>
should I add the other 3 in the pom, or where would I go to also copy transtivies?
<headius>
ok so we will need to have them in there explicitly, which then begs the question of whether they should be default or bundled
<headius>
yeah I think default is still right
<headius>
so pty stuff can load before RG loads
<headius>
if necessary
<headius>
so just add the other gems in that same section
<byteit101[m]>
making sure this builds...
<byteit101[m]>
pushed. Also made windows warning
<headius>
excellent
<byteit101[m]>
Didn't tset complete jar with this change, though
<headius>
should work the same I expect
<byteit101[m]>
Augh! the reline irb doesn't like being run inside maven. No echo nor prompt until after enter :-/
<headius>
Run inside Maven or the complete jar?
<byteit101[m]>
I dumped a require 'irb'; binding.irb into pom.rb
<headius>
Interesting
<headius>
Did that work before?
<byteit101[m]>
idk
<byteit101[m]>
I can try in 9.3 head
<byteit101[m]>
same thing in 9.3
<headius>
Probably something to do with how Maven uses standard in and out
<headius>
Nothing to worry about right now in any case
<headius>
I'm going to merge
<headius>
Full speed ahead
<headius>
Awesome it's in
<byteit101[m]>
Yay!
razetime has quit [Ping timeout: 256 seconds]
razetime has joined #jruby
razetime has quit [Ping timeout: 256 seconds]
razetime has joined #jruby
razetime has quit [Ping timeout: 256 seconds]
razetime_ has joined #jruby
<headius>
enebo: new sprintf work ever get merged in?
genpaku has quit [Remote host closed the connection]
genpaku has joined #jruby
<enebo[m]>
headius: that is not ready but actually in what does work passes way more tests than our current one. It does not support float/double yet
<enebo[m]>
I do even have a start on implementing float parsing from a paper but it is not working. This I plan on introducing with a point release with a fallback ENV. Once confident we will delete the old impl
<enebo[m]>
I should qualify that sprintf is really really odd. I would say 99.9% of new passing things are strange formats that probably no one actually uses. You can see we have some strange padding issues in some current test errors which shows the 01% where it might matter
<enebo[m]>
It also may sound hyperbolic but I think it is passing hundreds of tests the old one cannot
<enebo[m]>
sprintf is a really good example of how pure compatibility usually doesn't matter
razetime has joined #jruby
razetime has quit [Remote host closed the connection]
razetime has joined #jruby
razetime has quit [Remote host closed the connection]
<headius>
I haven't looked at it closely but I'm sure the new implementation is much cleaner than the old one too
<headius>
enebo: we should chat through the remaining issues when you're back from lunch
<enebo[m]>
This appears to be first one which shows it too
<enebo[m]>
So I don't know if this is something weird with windows getting confused for unrelated reasons of this merge caused it
<enebo[m]>
HEADIUS commit it was green which I think preceded this one
<headius>
Strange, I did not notice failures in the PR but perhaps I missed something
<enebo[m]>
so I think a big item is to still whittle down our CI problems
<enebo[m]>
Another is to make it through rails unit tests just to make sure nothing it broken
<enebo[m]>
I am working through what apparently is dozens to hundreds of issues with ripper but that is going well ... just surprised to not see ruby impl suites fail
<enebo[m]>
This test suite has some other interesting thing happening where it will run and then just exit and it will mention synchronize in the exit backtrace
<enebo[m]>
There are so many other issues with ripper proper that I have not tracked that down but it could be an interesting problem 9.4 needs to resolve
<enebo[m]>
In my mind we largely are just trying to avoid day 1 reports because feature X is a) not there b) broken but we can only test what we have
<enebo[m]>
Once I get more of the ripper stuff a bit more solid (perhaps not perfect) I want to sample more popular gems looking for errors
<enebo[m]>
As I see if we need to make it to a green state but that is not just excluding the remaining stuff yet (although many failes like opeensl will just be excluded). We are close.
<enebo[m]>
Second half is just trying to find likely to be found problems after a release and fix them beforehand
<enebo[m]>
making some coffee quick
<headius>
these definitely weren't failing on byteit101 branch
<headius>
what do you mean by whittling down CI problems?
<headius>
most of CI has been stable since I moved the WIP excludes out
<enebo[m]>
I am talking about wip itself
<headius>
ok
<enebo[m]>
some portion of those are 3.x support some are important and some are not
<headius>
something is causing stderr to get closed on Windows, that's the cause of all those failures
<headius>
right so just continued auditing what's there and picking the highest value
<enebo[m]>
I have not aggressively tried to remove because it seemed like someone may fix them
<enebo[m]>
yeah like missing methods of things which are doable
<enebo[m]>
just to expand the footprint
<headius>
right
<enebo[m]>
yeah the windows thing maybe will clear up on next thing but if not something in loading pty or something like that is causing that issue
<headius>
I will figure out this windows thing and then I can work on more WIP stuff
<enebo[m]>
ok
<headius>
I don't know how pty would affect these but it must be
<enebo[m]>
I would like us to have no wip by end of Monday and hopefully do the dreaded weekend release Weds
<enebo[m]>
And if there is a big issue then we work on Monday so there is a little time to address issues befoer you leave (which you have have left already)
<headius>
giving thanks for 9.4
<enebo[m]>
haha
<enebo[m]>
yeah took me a second to figure that line out
<enebo[m]>
until last week I forgot thanksgiving was coming up
<headius>
so temp fix would be to restore the old pty.rb contents and use that on Windows, otherwise loading subspawn
<enebo[m]>
(note: I ordered a nice pumpkin pie with a suet crust upon that discovery)
<headius>
I can give that a quick shot
<headius>
nice
<headius>
I got thanksgiving pasties from Potter's
<headius>
need to pick those up this weekend
<enebo[m]>
nice
<headius>
you know it's the little things I miss on Linux, like the terminal app not having a way to region select
<enebo[m]>
HAHAH
<enebo[m]>
I was thinking, "What like timezone?"
<enebo[m]>
I cracked myself up
<headius>
oh nevermind I just found it... ctrl+alt+mouse
<headius>
haha
<headius>
not that kind of region
<enebo[m]>
yeah I am still laughing a bit
<enebo[m]>
I am actively debugging while talking so my brain is not really fully engaged in either activity
<headius>
trackpad ergonomics still suck too
<headius>
but the new trackpad is better
<enebo[m]>
that's good to hear. I am too into using a dock and I need new glasses
<enebo[m]>
so mouse is great
<headius>
I use a dock usually
<headius>
with mouse
<headius>
and trackpoint is good for fine movements
<headius>
it's just not the same
<enebo[m]>
This 34" monitor has perfect resolution for non-hidpi dev windows
<enebo[m]>
3440x1440 is allows a lot of non-overlapping things
<enebo[m]>
Any wider and I think I would get neck issues
<enebo[m]>
So it could be a little more vertical resolution like 1800 or so
<headius>
I need a monitor
<enebo[m]>
good fucking luck and by fucking I mean I hated the research aspect of it
<headius>
I got used to using my 43" 4k TV as a monitor and now I'm back to just laptop screen
<headius>
I kinda just want to go to Target and get another TV
<headius>
cheaper than monitor and I don't need it for gaming
<enebo[m]>
I still have my old 1080p tv and I loathe the idea of buying a new one
<enebo[m]>
I want dumb appliances
<headius>
if you're not picky just buy any old thing
<headius>
$400 you can get an LG 4k 65"
<headius>
tis the season
<enebo[m]>
Honestly my next tv is likely to just be a monitor
<headius>
my next monitor is likely to just be a TV
<enebo[m]>
damn
<enebo[m]>
yeah they are cheaper though
<enebo[m]>
I mean inexpensive but I think I would dislike any dynamic interpolating stuff on a tv
<headius>
it worked reasonably well but old mac could not drive 4k so I had to downscale
<enebo[m]>
I guess you can turn that off
<headius>
but nobody needs true 4k
<enebo[m]>
refresh is probably not great but if 4k that is not really an issue
<enebo[m]>
most tvs bullshit their refresh rate
<headius>
these cheap TVs can all do 4k 60 now anyway
<enebo[m]>
yeah 60 is good unless it is 30 interped
<headius>
yeah so bit of research to make sure
<enebo[m]>
I mean 60 is not great but it is totally fine (especially in talking about a work display)
<enebo[m]>
for gaming it passes unless you are playing something like pubg (or valorant or ???)
<headius>
apparently I get the libutil error with or without subspawn
<headius>
when loading pty.rb
<headius>
enebo: you and byteit101 discussed this a little bit yeah? I see that libutil is in lib64 but FFI doesn't pick i tup
<byteit101[m]>
Oh yea I need to release that change
<byteit101[m]>
head has it, 0.1.0/0.5.1.0 doesn't have it
<headius>
byteit101: I am not getting into debugging subspawn pty windows issue right now but this PR will put the old pty.rb back for now: https://github.com/jruby/jruby/pull/7461
<headius>
due to a change by nobu for unknown reasons, it expects this sort to take at least 6 iterations, but our TimSort does not
<headius>
and it doesn't pass CRuby 3.1 on my machine either
<enebo[m]>
haha
<headius>
hash wip excludes are fixed
<headius>
string wip is some freeze+dedup logic that differs from CRuby and I don't think I want to change it... they will use the given string as the global dedup if it is frozen and "bare" but we avoid that due to concurrency and always return a new string if thi sis the first time we dedup
<headius>
array wip has only the one failure that's a bad test
<headius>
I figured getting the most important core class wip's fixed would be a good value
<enebo[m]>
yeah definitely
<headius>
comparable wip is fixed
<headius>
enebo: ran into a case where the [] call path rejects keywords dur to arity